9/02/2025

사람들은 AI로 분류된 제품을 싫어한다.


포스팅 제목이 자극적이라고 생각할 수 있지만, 내가 한 말은 아니기에 오해 마시라.

흥미로운 연구 논문이 있다. 워싱턴 주립대와 템플 대학교의 연구원들은 제품에 AI 기능을 추가했을 때의 효과에 대한 연구를 발표했다. 

100명의 참여자로 구성된 두 개의 그룹을 만들고, 가상 광고를 이용하여 "AI" 가 붙은 제품이나 "AI 기반" 제품을 구매할 의향이 더 높은지, 아니면 "첨단 기술"이나 "신기술"이 붙은 제품을 구매할 의향이 더 높은지를 측정했다.

"AI 관련 문구를 본 그룹은 다른 그룹에 비해 광고 된 제품이나 서비스를 사용/구매하거나 적극적으로 찾고 싶은 가능성이 낮았다."

특히, 자동차나 의료 관련 서비스와 같은 고위험 제품의 경우에 더욱 높았다고 한다. 연구를 시작하기 전에 연구원들은 AI 라벨이 사람들의 제품 구매 가능성을 낮추는 것이 아니라 오히려 높일 것이라고 생각했지만, 정 반대의 결과가 나온 것이다.

연구자들이 저위험군으로 분류한 품목, TV나 일반적인 상품의 경우에는 차이가 적었다고 한다.

연구진들은 의사결정이 머리보다는 가슴으로 하는 것으로 보인다고 밝혔다. 즉, 대부분 감정에 기반을 둔 의사결정을 한다는 이야기이다. 부정적인 시각을 가진 사람들은 AI기반 제품과 서비스를 신뢰하지 않았으며, 특히 AI가 어떤 기능을 하는지 이해하지 못하거나 안전에 위험을 초래할 수 있는 제품이나 서비스는 신뢰하지 않았다.

AI 도구를 한 번 이상 사용해 본 사람들은 그 도구들이 얼마나 신뢰할 수 없는지 잘 알고 있다. 어떤 일을 할 때 인간보다 뛰어나지만, 실패할 때는 비인간적인 방식으로 실패하곤 한다. 이런 부분이 무섭게 느껴질 수 있다.

현 시점에 "AI"는 마법의 키워드가 되었기에., 거의 모든 앱/서비스에는 AI 기능이 탑재되어 있다. 때로는 정말 유용하지만, 어쩔때는 귀찮을 수도 있고, 제품의 성능을 저하시키기도 한다.

AI에 대한 부정적인 태도의 원인을 파악하기 위해 추가적인 프로젝트를 진행한다고 했지만, 개인정보에 대한 우려도 있을것이라 추측한다고 했다.

예를 들어, 스마트 냉장고의 경우는 고가이고, 소프트웨어 업데이트가 필요하고, 식습관을 추적할 경우 개인정보 보호에 문제가 발생할 수 있다. 대부분의 사람들은 냉장고에 AI가 탑재되는 의미를 이해하지 못할 수 도 있다.

기업들은 자사 제품에 AI를 적용하는데 앞으로 더 적극적으로 나설것이다. AI기반 서비스/기기는 이론적으로는 매력적이지만, AI를 이용한 구체적인 장점이 명확하고 가치가 있어야 할 것이다.

오늘은 회사 앞 편의점을 가기위해 횡단보도를 건너는데., 횡단보도 전봇대 앞에 AI 피트니스라는 광고판이 보였다. 처음에는 무슨 세미나를 하는지 알았는데., 알고 보니 피트니스 홍보였다. 이 광고판을 제작할 때, AI가 피트니스 모객을 위해서 큰 도움이 될 것이라고 생각했을까? 이미 내 주변에는 "AI"라는 용어를 많이 쓰고 있다.

프로그래머가 비즈니스 문제를 해결해야 할까?


대부분의 조직은 R&R로 나눠져있다. 그리고 업계에 만연하는 것중 프로그래머는 비즈니스 문제 해결에 관여해서는 안된다는 얘기가 있다. 비즈니스 니즈에 집중하는 것이 프로그래밍의 순수한 기술적 본질을 훼손한다는 이야기이다.

나는 이런 관점에 반대한다.

일반적으로 개발자는 크게 3개의 레벨(주니어, 미들, 시니어)로 구분한다. 각 레벨에 대한 정의를 해보자.

  • 주니어: 논란의 여지가 없는 레벨이다. 이론을 배웠고, 이제 업무를 시작하려는 레벨이다.
  • 미들: 기술 스택에 대해 이해하는 숙련된 레벨이다.
  • 시니어: 다양한 경험을 갖추고 있고, 기술 스택에 대한 경험도 많으며, 업계 전반의 폭넓은 이해를 갖추고 있어야 한다.

원하던 원치 않든, 프로그래머는 비즈니스 문제를 해결한다. 사업은 수익을 창출해야 하고, 여기에는 급여 지급도 포함된다. 수익을 창출하려면 문제(비즈니스 과제)를 해결해야 한다. 간접적이던 직접적이던 비즈니스에 "가치"를 부여하여 문제를 해결해야 한다.

몇 가지 예를 들어보자. 새로운 웹사이트를 만들어야 한다고 가정해보자. 업무 흐름은 아래와 같을 것이다.

현업 요구사항 -> 프로젝트 관리자 -> IT 실무자로 이어지는 업무 흐름에서 두 가지 접근 방식이 존재한다.

  • 사례 #1: 요구사항 대로 그냥 코딩 - 모든 사람이 책임 범위내에서 일한다. 프로젝트 관리자는 현업과 논의하고 티겟을 만들고, 시니어는 아키텍처를 설계하고, 주니어는 미들과 개발을 한다.
  • 사례 #2: 업무 시작 전에 프로젝트 관리자, 시니어, 현업등이 비즈니스 문제를 심도 있게 논의하는 회의를 여러 차례 진행한다. 단순히 문제 해결 방법 뿐만 아니라, 비즈니스, 개발자, 디자이너 등 모든 사람이 참여해서 효과적으로 문제를 해결하는 방법을 논의한다. 모두에게 효과적인 방안을 찾은 후에야 개발이 시작된다.

사례#1 에서는 모두가 "그냥 코딩"만 한다. 비즈니스 문제는 비효율적으로 해결된다. 마감일이 정해져 있으면, 허술한 해결책을 찾고, 책임을 전가하고, 장황하게 수정 작업을 하고, "새로운 요구사항"을 추가하는 상황이 발생한다. 이는 사람들이 요구대로만 했기 때문이다. 모두가 자신의 범위내에서 "톱니바퀴"처럼 일했고, 비즈니스 문제 해결에는 참여하지 않았다.

사례#2에서는 항상 발생하는 대부분의 잠재적 문제가 상호작용을 통해 해결된다. 필요한 것을 오해할 수 있기 때문에 개발자가 프로젝트 구현 방식을 근본적으로 변경할 수도 있다는 점은 당연한 것이다. 물론 역량에 따라 크게 달라지겠지만, 문제는 훨씬 줄어들 것이다. 이 시나리오에서 비즈니스 문제는 효과적으로 해결된다.

사례#1과 사례#2의 주요 차이점은 무엇일까?

구현 방식이 아니라 팀워크이다. 여기서 팀이란 단순히 프로젝트내에서 무언가를 구현하는 코더 몇 명이 아니라 참여하는 구성원 전체를 의미한다. 사례#2에서는 모두가 좋은 결과를 얻기 위해 함께 노력한다는 점이 존재한다. 물론 세상은 완벽하지 않지만., 가정적으로 그렇다.

이유는 모르겠지만, 사람들은 종종 문제 해결을 영업과 연관 짓는다. 프로그래머는 "어떻게" 판매될지 생각하는 것이 아니라, "무엇"이 판매될지를 생각해야 한다. 최종 제품의 품질은 아키텍처, 속도, 로직, 디자인 등에 따라 달라진다. 여러가지 것들이 제품의 품질에 담긴다.

본 글의 서두에서 프로그래머는 원하든 원치 않든 비즈니스 문제를 해결한다고 언급했다. 다시 한번 생각해본다. 프로그래머가 비즈니스 문제를 해결해야 할까?

그래야 한다고 생각한다. 역량, 직책 그리고 경험 측면에서 해결해야 한다.

프로그래머가 영업을 해야 할까? 물론 아니다. 그러나 영업이 안고 있는 비즈니스 문제를 해결해주어야 한다.