1부: 워크숍 입장 과정에서 드러난 제품 문제
Kent C. Dodds는 행사장 입구에 길게 늘어선 줄과 좁은 입장 지점을 보며, 엔지니어들이 모인 자리에서도 이런 병목이 생긴다고 지적한다. 입장 처리가 느려 사람들이 강의를 들으러 왔는데도 방 안으로 들어오지 못하는 상황이다. 방 안에는 빈 좌석이 있지만 밖에는 여전히 사람이 많고, 대기자 전원이 들어올 수 있을지도 확실하지 않다. 뒤에 이어지는 제품 실습은 이 현장의 문제를 대상으로 삼는다.
이 워크숍에서 다루려는 것은 소프트웨어 구현 자체보다 무엇을 만들어야 하는지를 판단하는 프로덕트 엔지니어링이다. Kent는 참가자들 가운데 직접 실무를 수행하는 사람, 에이전트에게 코드를 작성하도록 지시하는 사람, 그런 엔지니어들을 이끄는 사람, 제품 책임자와 경영자가 함께 있다는 점을 확인한다. 제품을 만들 가치가 있는지 판단하는 일은 특정 직함을 가진 한 사람에게만 필요한 일이 아니다.
1부: AI가 바꾼 교육자의 역할
Kent는 BYU를 2014년에 졸업한 뒤 전문적으로 소프트웨어를 개발해 왔고, 강연 시점에는 졸업 후 12년이 지났다고 설명한다. 그 전에도 파트타임으로 개발했으며, 개발 경력을 쌓는 동안 일찍부터 교육에 참여했다. 2019년에는 전업 교육자가 되었다. 그의 교육은 이미 소프트웨어를 만드는 사람에게 새로운 기술을 사용하는 경험을 더 빨리 쌓게 해 주는 데 초점이 있었다. 테스트를 작성해 본 적이 없는 개발자에게 테스트를 가르치고, React를 모르는 개발자에게 React를 가르치며, 풀스택 경험이 없는 개발자에게 풀스택 개발을 가르치는 방식이었다.
올해 에이전트의 코딩 능력이 크게 좋아지면서 그는 두 차례 실존적 위기를 겪었다고 말한다. 크리스마스 휴가 무렵 에이전트를 사용해 보니 자신보다 코딩을 잘하는 것처럼 느껴지거나, 적어도 이전보다 훨씬 잘한다는 사실을 확인했기 때문이다. 그는 실제로 소프트웨어를 만드는 엔지니어인 동시에 숙련된 엔지니어에게 구현 기술을 가르치는 사람이었다. 그러므로 이 변화는 개발자로서의 역할과 교육자로서의 역할을 한꺼번에 흔들었다.
그는 이미 Vue 같은 기술을 사용해 본 숙련된 개발자가 React를 사용하는 프로젝트로 옮기는 경우를 든다. 지금은 그런 개발자가 React 과정을 반드시 들어야 한다고 생각하지 않는다. 숙련된 개발자는 에이전트를 지휘해 필요한 것을 구현할 수 있고, 올바른 구성 요소가 있으면 훨씬 많은 것을 만들 수 있기 때문이다. 그는 자신의 React 과정을 판매하는 입장에서 이런 발언이 자신에게 경제적으로 불리하다고 인정하면서도, 그 경우에 강좌가 필요하지 않다는 판단을 유지한다. useState 같은 개별 구현 세부사항을 익히는 일이 예전과 같은 가치를 갖는지 의문을 제기하는 것이다.
이 주장은 모든 사람이 기술을 몰라도 된다는 단정으로 제시되지 않는다. 그의 출발점은 이미 기술 경험이 있는 엔지니어가 다른 구현 기술을 익히는 데 교육이 얼마나 필요한지가 달라졌다는 것이다. 이후 그는 기술 전문성과 시스템 이해가 여전히 중요하다고 여러 차례 설명한다. 교육자로서 찾아야 할 것은 매번 바뀌는 도구 사용법보다 장기간 도움이 될 능력이다.
1부: 오래 남는 능력과 엔지니어링 판단
Kent는 도구와 사람이 맡는 일을 지지대 위에 놓인 물체로 설명한다. IDE와 CI 같은 도구가 일을 떠받치고, 사람은 도구가 처리하지 못하는 나머지 부분을 맡는다. 시간이 흐르면서 에이전트가 사람이 하던 일을 점점 더 많이 처리한다. 그 자체는 좋은 변화이다. 직접 해야 할 일이 줄고 더 많은 일을 해낼 수 있기 때문이다. 다만 사람에게 남는 역할이 무엇인지 다시 물어야 한다.
그는 프롬프트 엔지니어링, 추론, 루프 엔지니어링, 플로 엔지니어링 등 계속 등장하는 이름들을 보며 압도감을 느낀다고 말한다. 교육자가 매번 새 방법을 강좌로 팔고, 2주 뒤에 방법이 바뀌면 또 다른 강좌를 파는 방식으로 돈을 벌 수도 있다. 여섯 자녀를 돌보는 입장에서 수입은 중요하지만, 그는 그런 교육보다 오랫동안 사용할 수 있는 능력을 가르치고 싶다고 설명한다.
미래가 어떤 모습일지는 모른다. Kent는 AGI가 일을 전부 하는 미래도 가능하다고 보지만, 그런 시점의 세계나 인간의 역할을 예측하기 어렵기 때문에 그 상태를 전제로 현재의 교육을 설계하는 일은 유용하지 않다고 말한다. 대신 AGI가 모든 것을 하기 직전의 상태를 상상한다. AI가 거의 모든 일을 처리해도 마지막 작은 공백을 채우지 못한다면, 사람이 그 부분을 맡아야 전체 일이 성립한다. 그 마지막 영역으로 그가 선택한 것은 판단이며, 특히 무엇을 만들고 어떤 일에 집중할지를 결정하는 프로덕트 엔지니어링이다.
이 변화를 그는 궁수와 화살에 비유한다. 이전의 엔지니어는 제품 관리자가 지정한 표적을 향해 바람을 계산하고 정확하게 쏘는 능력을 길렀다. 어떤 사람은 작은 고리 사이로 표적을 맞힐 만큼 뛰어났다. 그러나 화살이 유도 장치처럼 바뀌면 같은 표적을 맞히는 데 예전만큼 뛰어난 솜씨가 필요하지 않다. 더 나아가 이전에는 상상하지 못했던 수많은 표적을 맞힐 수 있게 된다.
그는 에이전트가 실수한다는 사실을 알고 있으며 이 비유가 현실의 일부를 단순화한다고 인정한다. 여기서 강조하는 것은 현재의 완벽함보다 발전 방향이다. 모든 표적의 가치는 같지 않았고, 앞으로도 같지 않다. 어떤 표적을 맞히는 것이 가장 가치 있는지 아는 능력이 차이를 만든다. Kent는 이를 마지막까지 남을 소프트웨어 엔지니어에게 필요한 지속적인 능력이라고 부른다.
1부: 구현의 희소성이 줄어든 뒤의 제품 선택
Kent의 핵심 주장은 AI 에이전트가 구현 능력의 차이를 줄이면 무엇을 만드는지가 차별점이 된다는 것이다. AI가 이 판단까지 익힌 뒤에 사람들이 어떤 일을 하게 될지는 자신도 모르지만, 현재는 올바른 것을 만드는 능력에 집중할 수 있다.
실습에서는 참가자들이 제안하고 투표한 하나의 앱을 대상으로 여러 프레임워크를 적용한다. Kent는 준비한 정답을 전달하는 대신 현장에서 선택된 제품을 함께 검토하는 방식을 택한다. 참가자들에게도 각 프레임워크가 자신이 만드는 앱에 어떻게 적용되는지 생각해 보라고 요청한다. 하나의 예제를 이해하는 것에 그치지 않고, 자신의 제품에서 같은 질문을 해 보는 것이 목적이다.
그가 보는 변화는 희소한 자원의 이동이다. 구현은 점점 상품화되고, 무엇을 만들지와 애초에 만들 가치가 있는지를 결정하는 일이 상대적으로 더 가치 있어진다. 에이전트가 완벽하지 않고 실수한다는 점은 다시 인정하지만, 능력이 좋아지고 있으며 앞으로도 개선된다는 방향을 강조한다.
이 판단은 새 스타트업이나 완전히 새로운 앱에만 적용되지 않는다. 대기업에서 내부 시스템을 만드는 사람, 기존 제품에 기능을 추가하는 사람도 같은 문제를 겪는다. Kent는 오히려 그런 기존 조직의 사용 사례에도 큰 관심이 있다고 말한다. 질문은 만들 수 있는가에서 만들 가치가 있는가로 옮겨 간다. 사실 이 질문은 AI 이전부터 중요했고, 가장 가치 있는 엔지니어들은 회사가 이 질문에 답하도록 도와 왔다.
에이전트 덕분에 더 많은 표적을 맞힐 수 있어도 자금과 관심은 무한하지 않다. Kent는 자신에게 모든 표적을 노릴 돈이 없다고 말한다. 설령 모든 기능을 구현할 자원이 있더라도, 기능을 너무 많이 추가하면 사용자에게 부담을 주고 제품을 실패하게 만들 수 있다. 구현 가능성이 늘어난 만큼 선택의 책임도 커진다.
1부: 빠른 구현이 고객 가치로 이어지지 않는 이유
Kent는 자신이 진행한 팟캐스트의 여러 견해를 이 논의와 연결한다. 한 출연자는 개발이 저렴하고 쉬워져 비기술자도 할 수 있는 일이 되면 결국 어떤 아이디어를 갖고 있는지가 중요해진다고 말했다. Kent는 현재 도구를 비기술자에게 주고 35년 동안 유지할 수 있는 실질적인 소프트웨어를 만들 것이라고 기대하지는 않는다. 다만 그런 상태에 도달할 가능성이 있고, 구현 능력의 차이가 줄어드는 과정에 있다는 점은 받아들인다. 실행은 여전히 중요하지만 아이디어의 가치는 실행에 비해 상대적으로 커진다는 설명이다.
T3 Code와 T3 관련 작업을 하는 Julius는 기능이 존재할 가치가 있는지, 장기적으로 어떤 결과를 가져오는지를 결정하는 것이 어려운 질문이라고 말했다. Kent는 이 판단을 소유권과 책임의 일부로 본다. 명세대로 구현한 뒤 넘기고 다음 티켓을 가져오는 것을 자신의 일 전부로 생각한다면, 그 모습은 에이전트와 매우 비슷해진다. 티켓을 구현으로 바꾸는 기능만 수행하는 사람은 쉽게 대체될 수 있다는 것이 그의 견해이다.
프로덕트 엔지니어는 구현을 끝내고도 실패할 수 있다는 점을 알아야 한다. 결과물이 고객 가치를 만들지 못하면 개발 완료는 성공이 아니다. 이를 검토하는 것은 제품 관리자만의 일이 아니다. Wayne Allen은 제품의 관심사가 올바른 것을 만드는 것이고 엔지니어링의 관심사는 그것을 올바르게 만드는 것이라고 설명했다. Kent가 최종적으로 정리한 관계는 올바르게 만드는 일이 올바른 것을 만드는 판단 이후에 온다는 것이다. 엔지니어가 회사의 성공과 자신이 계속 급여를 받기를 원한다면, 자신이 구현할 내용에 영향을 주는 상위 단계의 결정이 실제 가치로 이어지는지 관심을 가져야 한다.
OpenCode를 만든 Dax Rad는 새 코딩 에이전트의 능력이 기본적으로 잘못된 일을 하는 데 쓰이기 쉽고, 제품이 예전보다 빠르게 나빠질 수 있다고 말했다. Kent는 이 경고에 공감한다. 에이전트가 시스템이 지나치게 확장되고 있다는 이유로 항상 작업을 중단시키는 것은 아니다. 무엇을 추가할지 의도적으로 판단하고, 제품이 불필요하게 커지지 않게 속도를 늦추는 책임은 사람에게 있다. 그는 다른 출연자의 지적과도 연결하며, 에이전트가 코드베이스 안의 나쁜 관행을 더 빠르게 확산할 수 있으므로 통제해야 한다고 설명한다.
Cloudflare에서 제품 관련 고위 직무를 맡은 Rita는 겉모습과 사용감을 빠르게 구현할 수 있어서 곧바로 출시하고 싶어지기 쉽다고 말했다. 그러나 표면상으로 작동하는 것과 확장 가능하며 예외 상황을 처리하는 것은 다르다. Kent는 여기에서 프로덕트 엔지니어의 소유권과 책임이 중요해진다고 본다. 프로토타입을 검토한 뒤 버리고, 자신의 문제 정의와 시스템 관점을 적용해 Claude나 Cursor 같은 도구로 2시간 안에 다시 구현하는 선택도 가능하다. 여기서 재구현은 겉모습을 복제하는 일이 아니라, 자신이 책임질 수 있는 시스템을 만드는 일이다.
새벽 2시에 장애 호출을 받고 대응해야 할 사람이라면, 에이전트가 작업할 시스템을 더 신중히 만든다. 적절한 구조와 조건을 갖춰 에이전트가 성공하도록 하는 것이 운영 책임과 연결되기 때문이다. Aaron Francis의 표현대로 잘못된 일을 매우 빠르게 하면서도 자신이 엄청난 진전을 이루고 있다고 느낄 수 있다. 이미 많은 일을 했기 때문에 멈추기 어렵다는 감각도 생긴다. Kent는 이런 매몰 비용의 문제를 경고하며, 잘못된 기능을 하루에 1만 줄씩 작성하는 것보다 적어도 방향이 맞는 일을 빠르게 하는 것이 중요하다고 말한다.
1부: 고객 이해를 기술 결정으로 연결하는 역할
Kent가 말하는 프로덕트 엔지니어링은 모든 엔지니어가 제품 관리자가 되어야 한다는 주장이 아니다. 프로덕트 엔지니어는 고객이 무엇을 필요로 하는지 이해하고, 그 이해를 기술 선택에 연결한다. 이를 통해 나중에 바꾸기 어려운 구조에 갇히거나 필요 이상으로 구축하는 일을 피한다. 데이터 모델, 워크플로의 형태, 관측 가능성, 제약, 실패 유형, 그리고 가장 작지만 유용한 구현 범위는 모두 엔지니어가 결정하는 기술 문제이다. 요청과 아이디어가 어디에서 왔는지를 알면 이런 결정을 더 잘할 수 있다.
그는 가장 작은 유용한 범위를 설명하는 그림을 소개한다. 워터폴에서는 마지막에 가서야 쓸 수 있는 결과가 나오고, 애자일에서는 단계마다 유용한 결과를 내지만 형태가 달라져 새로 만드는 일이 생긴다. AI에서는 큰 전체 결과물이 먼저 나와서, 그 안에서 실제로 필요한 부분까지 줄여 가는 일이 중요해진다는 설명이다. 많은 것을 만들 수 있게 되었으므로 작은 범위를 만드는 능력이 오히려 중요해진다.
Kent는 Instagram이 처음에는 Burbn이라는 Foursquare와 비슷한 체크인 앱이었다는 사례를 든다. 사용자 행동을 관찰한 결과 실제로 사람들이 관심을 보이는 기능은 사진 공유였고, 나머지를 제거해 사진 공유에 집중했다는 설명이다. 그는 원래 앱이 술과 관련되었는지에 대해서는 자신이 그 분야를 잘 모른다고 덧붙인다. 사례에서 중요한 것은 처음 만들었던 기능 수가 아니라 실제로 쓰이는 기능을 발견하고 나머지를 줄였다는 점이다.
Uncle Bob의 경험도 고객을 직접 관찰하는 가치로 제시한다. 그는 전화선 관련 회사에서 전신주에 올라가 수리하는 작업자가 사용할 소형 컴퓨터용 소프트웨어를 만들었다. 상사는 그에게 현장 차량에 타 보고 작업을 직접 본 적이 있는지 물었고, 없다는 답을 듣자 실제 현장으로 보냈다. 전신주에 매달린 사람이 자신의 소프트웨어를 사용하는 모습을 보니, 더 쉽게 사용할 수 있도록 바꿀 만한 점이 약 30가지나 떠올랐다는 경험이다. Kent는 사용자가 소프트웨어를 실제로 쓰는 모습을 보면 개발자가 겸손해질 수밖에 없다고 말한다.
Uncle Bob은 프로덕트 엔지니어가 절반은 기술 안에서, 절반은 고객의 집 안에서 살아야 한다고 표현했다. Grady Booch 역시 기술 경험과 인간의 문제를 함께 이해해야 엔지니어링 판단이 형성된다고 보았다. Kent는 이것이 제품 관리자가 되는 것과 다른 점이라고 설명한다. 실제 사람의 필요를 자신의 기술 전문성과 연결하는 것이 엔지니어의 역할이다.
또 다른 출연자는 멋진 API 자체보다 제품을 출시하는 것이 중요하다고 말했다. Kent에게도 자신이 만든 해결책의 기능을 계속 설명하는 사람들이 있다. 그러나 그 기능들이 자신에게 중요하지 않거나, 이미 쓰는 방법보다 충분히 낫지 않다면 기존 워크플로를 바꿀 이유가 없다. 그는 이런 대화에서 상대가 해결책에 몰두한 나머지 사용자의 문제를 잊었다고 느낀다. 엔지니어에게도 쉽게 생기는 위험이다.
1부: 제품 맥락이 아키텍처를 바꾸는 방식
Kent는 기술 역량을 갖추면서 사용자와 회사가 해결하려는 문제도 이해하는 엔지니어가 조직에서 두각을 나타낼 수 있다고 말한다. 엔지니어가 내리는 결정이 최종 제품의 모습을 형성하고, 아키텍처를 바꾸는 비용은 크기 때문이다.
AI가 있으니 데이터베이스를 바꾸거나 모놀리스를 마이크로서비스로 바꾸는 일이 100만 또는 몇백만 토큰이면 끝난다는 반론도 가능하다. 그는 앱의 규모에 따라 코드 변경 자체는 그렇게 할 수 있다고 인정한다. 그러나 변화가 다른 팀원과 사용자에게 미치는 영향까지 사라지는 것은 아니다. 조직과 사용자가 감당해야 할 변경 비용이 있다. 처음부터 제품을 이해하고 적절한 선택을 하는 사람을 채용할 수 있다면, 계속 뒤집어야 하는 사람보다 그 사람이 비용을 줄인다는 판단이다.
그는 올바른 기반 요소, 즉 프리미티브가 중요하다는 출연자의 설명을 인용한다. 잘못된 구성 요소 위에서 아주 좋은 해결책을 만드는 일은 어렵다. 에이전트가 코드를 대신 작성해도 어떤 구성 요소를 제공하고 어떤 조합을 허용할지를 판단하는 기술 전문성은 여전히 중요하다.
WorkOS를 만든 Michael의 인증 플랫폼 선택은 이 원리를 보여 준다. 그는 라이선스를 판매하고 고객이 직접 운영하는 온프레미스 방식과, 오픈소스에 상용 사업을 결합하는 방식 등을 검토했다. 많은 고객과 대화한 뒤, 보안 문제가 생기면 즉시 수정 사항을 배포해야 한다는 요구를 확인했다. 고객이 npm 패키지를 각자 업그레이드할 때까지 기다릴 수 없으므로 호스팅 서비스 형태를 선택했다는 설명이다.
이 결정은 어느 배포 방식이 기술적으로 더 멋진지에서 나오지 않았다. 보안 수정이 사용자에게 제때 전달되어야 한다는 실제 문제와 기술 판단이 결합해 제품 방향을 바꾼 것이다. 제품 관리자와 프로덕트 엔지니어의 역할에는 경계가 있지만, 둘 다 사용자의 실제 문제를 깊이 이해해야 한다.
1부: 에이전트가 성공할 시스템과 사용자 오류
Kent는 프로덕트 엔지니어가 다른 작업자가 성공할 수 있는 시스템을 만드는 사람이라고 설명한다. AI 이전에도 팀 리드는 팀이 효율적으로 일하도록 좋은 테스트와 아키텍처를 갖추고, 어떤 레고 블록을 조합해야 기능을 만들 수 있는지 분명하게 해야 했다. 이제 엔지니어는 동시에 실행하는 여러 에이전트의 팀 리드가 된다. 에이전트가 작업하기 좋은 환경과 명확한 기반 요소를 제공하고, 실수를 적게 하도록 만드는 일이 사람에게 남는다.
그는 Don Norman의 Three Mile Island 사례를 제품과 시스템 이해에 연결한다. Kent의 설명에 따르면, 1979년 펜실베이니아의 원자로에서 기술 문제가 생겼고 운영자들이 상황에 대응하면서 나쁜 결정을 내렸다. 이후 Don Norman은 왜 운영자들이 그런 판단을 했는지 살폈다. 그는 문제를 다른 관점으로 보았다. 운영자들은 똑똑하고 유능했으며, 잘못된 것은 시스템이었다는 주장이다.
Kent는 사용자 오류가 존재하지 않는다는 표현을 Don Norman의 주장으로 소개한다. 단순히 사용자를 탓하기보다 시스템이 왜 그런 행동과 판단을 낳았는지 살펴야 한다는 관점이다. 그는 Don Norman이 Apple에서 사용자 경험이라는 용어를 만든 사람이라고 소개하고, 이 관점을 더 알고 싶다면 『The Design of Everyday Things』를 읽거나 들을 것을 권한다. 『Design for a Better World』도 함께 언급한다.
1부: MVP 범위와 채용, 협업을 판단하는 질문
MVP에 기능이 몇 개까지 있어도 되는지 묻는 질문에 Kent는 기능 수 자체가 적절한 질문이 아니라고 답한다. 대신 대상 사용자에게 어떤 문제를 해결할 수 있다는 것을 보여 주는 최소한의 결과가 무엇인지 물어야 한다. 이미 경쟁이 많은 시장에 들어가는 경우에는 대상 사용자도 더 좁게 정해야 한다. 누구에게 어떤 문제를 해결할지와 최소 범위는 함께 결정된다.
프로덕트 엔지니어를 채용할 때도 기술 전문성은 여전히 중요하다. 다만 그는 코딩 챌린지를 하지 않겠다고 말하며, 특히 에이전트 사용을 금지하는 과제는 채용 후 실제로 하게 할 일과 어긋난다고 본다. 대신 시스템을 논의하겠다는 것이다. 예제를 주고 핵심 문제를 알아내기 위해 어떤 질문을 할지 묻고, 문제가 밝혀지면 그 발견이 시스템에 어떤 영향을 미치는지 설명하도록 하는 방식이 그가 생각하는 인터뷰이다.
언제 고객과 대화하는 일을 멈추고 개발을 시작해야 하는지에 대해서는 두 일을 계속 함께 해야 한다고 답한다. 고객 대화와 구현은 한 번씩 끝내는 단계가 아니라 지속하는 피드백 순환이다. 무엇을 만들지뿐 아니라 사용자가 쓰도록 어떻게 유통할지, 사용자를 얻는 일이 새로운 경쟁 우위가 되는지에 관한 질문도 나온다. Kent는 유통이 어렵다는 점은 인정하지만, 이번 워크숍에서 자세히 다룰 주제가 아니고 자신도 충분한 답을 준비하지 못했다고 말한다. 광고와 마케팅에 많은 돈을 쓰는 사례를 들었다고 할 뿐, 검증된 해결책을 제시하지는 않는다.
제품 관리자는 제품팀에, 엔지니어는 별도 팀에 두는 것이 좋은지 묻자 그는 애플리케이션이 조직도를 닮는 일이 많다고 설명한다. 개인적인 견해로는 제품 관리자가 엔지니어링과 매우 긴밀히 연결되어야 한다. 동시에 엔지니어가 조직 내 다른 엔지니어와 격리되어서도 안 된다. 자신의 기능 범위만 보면 다른 팀에서 이미 만든 기반 요소를 모르고 같은 것을 다시 구현할 수 있기 때문이다. 적어도 옆 팀, 위와 아래로 연결되는 범위까지는 알아야 한다.
그는 이를 React 개발자가 JavaScript와 브라우저를 알아야 하는 이유에 비유한다. 프레임워크가 일부 기능을 대신 처리하더라도, 한 단계 아래의 환경을 알아야 프레임워크를 효과적으로 쓸 수 있다. 조직의 다른 구성 요소를 이해하는 일도 자신의 범위 안에서 좋은 선택을 하기 위한 조건이다.
질문 도구를 사용하는 과정에서도 이 관점이 드러난다. 질문을 처리하다가 아직 답하지 않은 질문에 완료 표시를 한 것인지 헷갈리고, 질문이 이동해 내용을 놓친 경험을 그는 나쁜 사용자 경험이라고 지적한다. 이어 참가자가 질문을 강조 표시할 수 있다고 알려 주지만, 그는 어디를 눌러야 하는지 즉시 알아내지 못한다. 기능이 있어도 사용자가 발견하고 사용할 수 있는지가 별도의 제품 문제임을 보여 주는 작은 현장 사례이다. 그는 이를 사용자 오류라고 부르려다가 Don Norman의 관점을 다시 적용한다.
모든 엔지니어가 프로덕트 엔지니어여야 하는지에 대해 Kent는 자신의 판단을 밝힌다. 제품 감각이나 디자인 감각 없이 남이 시킨 것을 코드로 바꾸는 일만 한다면, 에이전트가 계속 유능해질수록 대체되기 쉽다고 본다. 그는 불안을 조장하려는 것은 아니지만, 제품을 이해하지 못하면 시스템이 사용자의 문제를 해결하지 못한다고 강조한다.
1부: 워크숍 입장 앱의 고객 발견
실습에 사용할 세 가지 프레임워크는 초기 아이디어 검증을 위한 The Mom Test, 사용자 요청을 정의하는 Jobs Theory, 소프트웨어 변경의 우선순위를 정하는 Kano 모델이다. 참가자 투표에서 가장 많은 선택을 받은 아이디어는 콘퍼런스 워크숍에 사람들이 들어가도록 돕는 앱이었다. 현장에서 겪은 입장 병목을 그대로 문제로 삼는다. 이름은 참가자 제안에 따라 Just Get In the Workshop으로 정한다.
Kent는 대기 줄에 있는 사람들을 만나 이 아이디어를 어떻게 검증할지 질문한다. 참가자들은 왜 앱이 필요한지, 이것이 문제인지, 얼마나 기다렸는지, 왜 기다리는지, 사전 등록이면 더 좋지 않은지, 마지막으로 입장하지 못한 때가 언제인지, 예상 최대 대기 시간이 얼마인지, 빈 좌석이 있는지를 제안한다. 기다리는 동안의 경험을 묻거나, 이미 해결된 문제인지와 더 빠르게 처리하는 다른 앱을 알고 있는지 묻는 제안도 나온다.
이 질문들로 모두 같은 종류의 답을 얻는 것은 아니다. Kent는 얼마나 기다렸는지라는 질문이 좋은 질문에 가까워지고 있다고 보고, 마지막으로 막혔던 경험을 묻는 질문이 The Mom Test의 관점에 맞는다고 반응한다. 기다리는 동안 어떤 경험을 했는지는 전체 경험을 파악하고 해결책을 구상하는 데 필요한 정보가 될 수 있다.
그러나 사람은 자신이 생각한 앱이 좋다는 답을 듣고 싶어 한다. 상대가 이 문제가 매우 크고 편하게 입장하기 위해 많은 돈을 낼 것이라고 말해 주기를 바라는 것이다. Kent는 사용자에게 자신의 아이디어를 평가하거나 문제를 대신 진단해 달라고 요청해서는 안 된다고 설명한다.
그가 재현하는 흔한 사고 과정은 먼저 모바일 앱을 만들겠다고 정하는 것이다. 사용자가 휴대전화에 설치해야 한다고 생각하다가, 한 번만 쓰는 기능이라면 웹사이트도 있어야겠다고 판단한다. 이어 여러 제공자와 연동하고, 행사 앱에 통합하거나 행사 안내 링크를 붙이면 더 편한지 묻기 시작한다. 이 과정에서는 아직 해결할 가치가 있는 문제인지 확인하지도 않았는데 자신의 해결책 안에서 세부적인 해결 방법만 논의하고 있다. 모바일과 웹 중 하나가 정답이라는 이야기가 아니라, 너무 이른 단계에 특정 해결책으로 사고가 좁아지는 모습을 설명하는 예이다.
1부: The Mom Test로 과거 행동과 비용을 확인하기
Kent는 사용할 것인지, 이것이 문제인지, 문제가 무엇인지 묻거나 자신을 위해 문제를 정의해 달라고 요청하는 질문을 약한 질문으로 제시한다. 더 나은 질문은 마지막으로 이 일이 일어났을 때를 구체적으로 말해 달라고 하고, 그때 무엇을 대신 했으며 그 대안에 어떤 비용이 들었는지 확인하는 것이다. 워크숍 참가자는 돈을 내고 행사에 왔는데도 줄에서 기다리느라 강의의 첫 20분을 놓칠 수 있다. 비용은 별도의 구매 금액만이 아니라 이미 돈을 내고 얻으려 했던 가치의 손실이기도 하다.
이 단계에서는 자신의 해결책을 설명하지 말아야 한다. 무엇을 할 것인지 예측하게 하기보다, 실제로 무엇을 했는지와 어떤 우회 방법을 사용했는지를 물어야 한다. 앞으로 돈을 낼 것인지, 얼마를 낼 것인지 묻는 질문은 특히 믿기 어렵다. 상대가 대화를 빨리 끝내고 싶어서 모든 질문에 그렇다고 답할 수 있기 때문이다. Kent는 이 책이 이런 반응을 칭찬이라고 설명한다고 말한다. 검증하는 것처럼 보이지만 사실은 칭찬을 구하고 있는 셈이다.
Don Norman의 견해도 같은 맥락에서 소개한다. 사용자에게 문제가 무엇인지 막연하게 물으면 증상을 말하고, 종종 해결책까지 제안하지만 그 해결책 역시 충분히 형성되지 않았을 수 있다. 그래서 구체적인 행동을 물어야 한다. 마지막에 어떤 일이 일어났는지, 누가 관련되어 있었는지, 무엇 때문에 기억할 만큼 불편했는지 확인한다. 문제를 설명할 책임을 사용자에게 전부 맡기지 않고 실제 경험에서 근거를 수집하는 방식이다.
워크숍 대기 줄은 특수한 상황이다. 질문받는 사람이 바로 그 순간 문제를 겪고 있어서 생생한 답변을 직접 얻을 수 있다. 대부분의 인터뷰에서는 상대가 현재 그 문제를 겪고 있지 않으므로 과거를 떠올리게 해야 한다. 상대가 언제 겪었는지 기억하지 못하는 것 자체도 신호이다. 기대하던 긍정적 신호가 아닐 수 있지만, 듣고 싶지 않은 신호도 필요하다.
확인할 내용은 대안, 비용, 발생 빈도, 지금까지 해결하려고 들인 노력이다. 이미 많은 노력과 돈을 우회 방법에 투입한다면, 그 문제를 해결할 가치가 있다는 강한 근거가 된다. 반대로 마지막 경험을 기억하지 못하고 포기한 채 지낸다면, 새로운 해결책을 위해 돈을 내거나 자신의 워크플로를 바꿀 가능성이 낮다는 신호일 수 있다. Kent는 이를 모든 사람에게 적용되는 확정적 법칙이 아니라 검증 과정에서 살펴야 할 증거로 설명한다.
그는 소프트웨어 엔지니어가 아무와도 대화하지 않고 Jira 티켓만 구현하면 된다고 생각하는 관점에 반대한다. 혼자서 훌륭한 코드를 만들 수 있다는 점은 인정하지만, 가장 뛰어난 엔지니어는 예전부터 사람과 대화하고 문제를 이해하는 사람이었다고 본다. 실제 문제를 이해한 사람이 그 문제를 더 잘 해결하는 시스템을 만들기 때문이다.
WorkOS의 Michael 역시 서비스를 만들기 전에 많은 사람과 이야기하며 아이디어를 검증했다고 설명한다. 그가 물은 것은 해결책이 없어서 무엇을 놓치고 있는지와, 해결하지 못할 때 드는 비용이었다. 칭찬보다 실제 증거를 얻는 질문이다. The Mom Test라는 이름은 자신을 사랑하는 어머니가 아이디어가 훌륭하고 꼭 쓰겠다고 말하기 쉽다는 데서 나온다. 그렇게 자신과 부모 두 명을 사용자로 확보한 듯 보여도, 실제 시장의 행동을 입증한 것은 아니라는 뜻이다.
1부: 검증 없는 대규모 개발의 비용
Kent는 호주에 사는 Wayne이 부동산 회사에서 겪은 프로젝트를 소개한다. 큰 조직 안에서 실험적인 제품을 만드는 팀이었는데, 처음부터 호주의 모든 사람이 동시에 로그인해도 처리할 수 있어야 한다고 판단했다. 마이크로서비스를 포함한 확장성이 높은 시스템을 만드는 데 1년을 썼고, 비용은 120만 호주 달러로 거의 90만 미국 달러에 해당했다고 설명한다.
그러나 출시한 결과 사용자가 한 명도 없었다. 전국 동시 접속을 감당할 필요가 없었을 뿐 아니라 한 명의 사용자를 처리할 필요도 없었던 것이다. Wayne은 이후 통합 작업을 수동으로 처리하는 형태로 2주 안에 출시할 수도 있었겠다고 생각했다. 통합은 원래 가장 고통스러운 부분인 경우가 많다. 먼저 수동으로 처리하며 시장을 시험했다면, 팀 전체가 1년을 투자하기 전에 많은 것을 빠르게 배울 수 있었을 것이라는 반성이다.
Kent는 이 사례를 스타트업 전체 제품뿐 아니라 기존 회사에서 요청받는 기능에도 적용한다. 기능 요청에 그것이 왜 필요한지를 검증한 근거가 없다면, 프로덕트 엔지니어는 제품 관리자에게 더 자세한 이유를 물어야 한다. 엔지니어링 시간을 쓸 가치가 있는지 확인하는 목적도 있고, 그 요청이 나온 맥락을 알아야 시스템의 형태를 정할 수 있기 때문이기도 하다.
한 번 해 보는 실험인지, 사업의 핵심 기능인지에 따라 기술적 절충이 달라진다. 1년을 들여야 하는지, 없으면 사업이 유지되지 않을 만큼 중요한 기능인지 물어야 한다. 사업에 필수적인 기능이라면 더 많은 시간과 세심한 검토를 투입하되, 여전히 최소한의 형태로 검증하는 균형을 유지한다. 실험이라는 이유만으로 무조건 허술하게 만들거나 중요하다는 이유만으로 바로 대규모 구축을 하는 선택을 권하는 것은 아니다.
혼자 방에서 몇 주씩 재미있게 개발하다 보면 좋은 아이디어라고 스스로 믿기가 쉽다. Kent는 Michael의 경험과도 연결하며 반드시 사람들에게 보여 주라고 말한다. 보여 주었는데 상대가 왜 자신이 신났는지 이해하지 못하면, 더 이야기하기 싫어서 혼자 작업만 계속하고 싶어질 수 있다. 그 불편한 감정과 상대의 반응 자체가 검토해야 할 신호이다. 재미있게 만드는 경험이 사용자의 필요를 증명하지는 않는다.
1부: 초기 사용자 피드백으로 해결 효과 확인하기
초기 아이디어 검증과 해결책 검증은 서로 다른 질문에 답한다. The Mom Test는 애초에 해결할 가치가 있는 문제인지 확인한다. 그다음에는 자신이 만든 해결책이 실제로 그 문제를 해결하는지 알아야 한다. Kent는 Ruben의 견해를 인용하며 사용자 피드백이 그 답을 제공한다고 설명한다.
초기 사용자에게 프로토타입을 제공해 반응을 본다. 초기 수용자는 빈틈이 많은 제품도 받아들일 수 있다. 많은 부분이 부족한데도 제품이 원하는 결과에 거의 도달하게 하거나 실제로 원하는 결과를 얻게 해서 사용자가 계속 기대를 걸고 있다면, 이는 매우 의미 있는 신호이다. 반대로 작은 불편 몇 가지를 겪고 바로 포기한다면 그 반응 역시 유용하다. 문제 해결의 중요성이 불편을 감수할 정도인지 확인할 수 있기 때문이다.
Kent는 해결할 가치가 큰 문제를, 사람이 상처를 입으면서도 유리를 통과해 목적지에 도착하고 기뻐하는 모습에 비유한다. 이는 사용자를 고통스럽게 해야 한다는 권고가 아니라, 큰 필요가 있으면 부족한 초기 해결책이라도 쓰려는 행동이 나타난다는 설명이다. 프로토타입을 통한 조기 피드백은 그 필요와 실제 효과를 관찰할 기회를 준다.
프로덕트 엔지니어에게 The Mom Test가 필요한 이유는 제품 관리자의 요구를 자신이 구축할 시스템의 형태로 번역하는 데 도움이 되기 때문이다. 현재 사용자나 잠재 고객이 어떤 방법으로 문제를 해결하는지 알면 아키텍처도 달라진다. 예를 들어 업무가 얼마나 오래 중단될 수 있는지 알면 마이그레이션을 어떻게 수행할지 더 신중히 선택할 수 있다. 그런 맥락이 없으면 잘못된 추상화를 만드는 일이 쉽다.
1부: 기술 전문성, 역할 분담과 성장
프로덕트 엔지니어와 제품 관리자를 구별하는 세 가지 특성을 묻는 질문에 Kent는 정확히 세 가지를 채워 말하기보다, 가장 큰 차이를 중심으로 설명한다. 프로덕트 엔지니어는 코드와 시스템을 중심으로 일한다. 직접 모든 코드를 읽지 않더라도 데이터 타입과 사용 가능한 기반 요소를 생각하고, 현재 인프라의 제약과 한계를 안다.
예를 들어 cron 작업 시스템이나 큐가 이미 있어도 어떤 문제가 있고 어떤 제한이 있는지 알아야 한다. 새로운 요청의 목적을 이해한 뒤에는 기존 아키텍처에 들어맞는지, 시스템을 확장해야 하는지 분류할 수 있다. 사용자의 최종 목표를 알면 기존 요소를 재사용할지, 새로운 프리미티브를 몇 개 추가할지 판단할 수 있다. Kent는 이런 기술 전문성과 시스템 이해를 제품 관리자와 구별되는 가장 큰 특성이라고 본다. 제품 관리자가 AI와 계속 이야기하며 기술 지식을 익힐 수는 있지만, 역할상 다른 일에도 집중해야 한다는 설명이다.
두 역할을 반드시 서로 다른 사람이 맡아야 하는지는 회사의 성장 단계에 달려 있다. Kent 자신은 자영업자로서 제품 관리자, 프로덕트 엔지니어, CFO 같은 역할을 모두 수행한다. 세 사람이 시작한 스타트업에서도 전원이 기술자일 수 있고, 한 사람은 사업을 맡을 수도 있다. 회사가 커지면 책임을 나누고 여러 직무로 분화한다. 어느 규모까지 성장하려는지도 역할 분리에 영향을 준다.
그는 이제 예전보다 작은 조직으로 더 큰 사업을 만들 수 있다고 생각한다. 팀이 얼마나 작아질 수 있는지에 대해서는 꽤 작을 수 있다고 답하지만 구체적인 인원수를 예측하지는 않는다. AI가 있으니 특정 규모가 정답이라는 수치도 제시하지 않는다.
AI 시대에 주니어가 어떻게 시니어로 승진하는지 묻자, Kent는 그 질문에 확정적인 답을 갖고 있지 않다고 말한다. 주니어와 시니어는 궁극적으로 같은 목표를 향하고 있으며, AI 이전에도 주니어는 시니어의 행동을 따라 배우고 시간이 지나면서 시니어가 되었다. 그 과정 자체가 바뀌었다고 보지는 않는다. 실제 승진 기준과 결정은 자신의 조직에서 관련 책임자와 대화해야 한다는 수준으로 답한다.
2부: 워크숍 입장 앱에 들어온 기능 요청
Kent C. Dodds는 앞선 실습에서 선택한 Just Get In the Workshop 앱이 이미 구현되었고, 사용자 요청에 따라 기능을 빠르게 추가하는 단계에 이르렀다고 가정한다. 이제 처음 만들 가치가 있는지 검증하는 단계에서, 이미 존재하는 제품에 들어온 요청을 판단하는 단계로 옮겨 간다.
참가자들은 입장 대기 줄의 길이를 알 수 있는 기능, Disney FastPass처럼 원격으로 대기할 수 있는 목록, 방 안에서 얼마나 많은 이산화탄소를 마시게 될지 확인하는 기능 등을 제안한다. 그중 입장 처리를 빠르게 할 것이라는 이유로 얼굴 인식이 실습의 요청으로 선택된다. Kent는 이 요청을 그대로 구현하는 대신, 이후 프레임워크를 적용할 대상으로 삼는다.
2부: 요청 뒤에 있는 문제와 문제의 연쇄
Kent는 Jack Ryan의 견해를 인용하며 요청받은 버튼이나 기능의 구현을 넘어, 그 요청의 이유를 더 깊이 살펴야 한다고 말한다. 왜 중요한지 계속 물어야 한다는 것이다. 얼굴 인식이 앱에서 왜 필요한지 묻자 참가자는 현재 과정이 느리다고 답한다. 다시 목적을 찾다 보면, 단순히 얼굴을 인식하는 것이 아니라 사람을 방 안으로 들여보내고 누가 들어왔는지 아는 것이 핵심이라는 설명에 도달한다.
그는 하나의 기능에 다른 목적이 붙을 수도 있다고 덧붙인다. 입장하면서 사진을 찍어 소셜 미디어에 게시하는 아이디어도 가능하지만, 그것은 사용자에게 불쾌한 기능일 수 있다. 행사 일정 자체가 문제라면 입장 속도를 최적화하는 일만으로는 풀리지 않을 수도 있다. 얼굴 인식을 요청한 이유를 좁게 가정하기 전에 더 큰 맥락을 알아야 한다.
실습에서 누구의 관점으로 질문하고 있는지도 확인한다. 참가자는 프로덕트 엔지니어 역할을 맡고 있다. 요청하는 사용자에게 직접 질문할 수도 있고, 제품 관리자가 사용자와 대화한 뒤 그 관리자에게 다시 질문하는 상황일 수도 있다. 그 일을 하는 동기는 앱과 사업이 자신의 급여를 지급한다는 경제적인 이유일 수도 있다. 사람들이 워크숍의 첫 20분을 놓치는 것을 싫어하는 개인적인 동기일 수도 있다. Kent는 사용자의 문제를 해결하는 일과 자신의 일에 관심을 가져야 할 이유가 연결되어 있다고 설명한다.
더 근본적인 질문은 왜 가상 대기 줄이 존재하느냐는 것이다. 엔지니어는 주어진 시스템에 들어가 최적화를 하려는 경향이 있지만, 처음부터 이 시스템이 왜 필요한지 돌아봐야 한다. 어느 문제를 해결하려고 만들었고, 그 문제는 왜 존재하는지 확인한다. 어떤 해결책을 채택하면 그 해결책에서 새로운 문제가 여럿 생기고, 각각의 새 문제를 푸는 동안 또 다른 문제가 생긴다.
Kent는 이를 문제 트리라고 부른다. 원래 문제를 하나의 방식으로 해결하면 여러 하위 문제가 갈라져 나오고, 충분히 작아질 때까지 각 문제를 해결해 간다. 그러나 아래쪽에서 매우 어려운 문제를 만났을 때, 그 비용을 처음부터 알았더라면 다른 방향을 택했을 수 있다. 그럴 때는 지금의 가지를 계속 최적화하는 대신 앞 단계로 돌아갈 수 있어야 한다. 실제로는 이런 재검토를 하지 않는 경우가 많다고 그는 지적한다.
왜라는 질문을 여러 번 하다 보면 사용자가 궁극적으로 해내려는 일, 즉 Job to Be Done에 도달한다. Kent는 이 이론을 Clay Christensen의 Jobs Theory로 소개하며 『Competing Against Luck』을 관련 책으로 든다. 핵심은 요청한 구현 형태가 아니라 그 요청이 나온 목적을 밝히는 것이다.
2부: 기능 요청과 사용자가 해내려는 일의 차이
Jobs Theory의 관점에서는 사람이 특정한 상황에서 진전을 이루기 위해 제품을 고용한다. 얼굴 인식은 요청된 기능이지만 그 자체가 사용자의 일은 아니다. Rita의 설명대로 사용자가 이런 기능을 만들어 달라고 말하면, 첫 답변은 무엇을 해결하려고 하는지 묻는 것이어야 한다.
모든 요청에 예라고 답하면 제품의 복잡성이 크게 늘어난다. Kent는 사용자의 요청을 에이전트에 보내 자동으로 구현하게 하는 앱을 가정하고 그런 방식은 좋지 않다고 강하게 말한다. 다만 실제로 누군가가 그런 앱을 만들고 있는지는 자신도 모른다고 덧붙인다. 그가 경고하는 대상은 검증된 특정 회사가 아니라, 판단을 건너뛰고 요청을 곧바로 구현으로 연결하는 설계이다. 그런 제품은 방향과 취향이 없고 제품 판단이 사라져 형편없는 결과가 될 수 있다는 것이 그의 의견이다.
각 기능 요청에는 판단이 필요하다. 요청된 기능을 현재 제품에 그대로 붙이는 것은 좋은 제품을 만드는 과정이 아니다. 제품 관리자가 먼저 요청을 받을 때가 많으므로, 그 단계에서 제품의 비전을 적용하고 더 좋은 형태로 정리해 주는 것이 바람직하다. 그러나 제품 관리자가 정리해 전달했다는 이유만으로 엔지니어가 모든 요청을 그대로 받아야 하는 것은 아니다.
기능은 자신이 설계한 시스템에 영향을 주고, 장기간 유지해야 할 책임을 만든다. 그 책임은 나중에 더 중요한 작업을 하는 속도를 늦출 수 있다. 프로덕트 엔지니어는 모든 요청을 사용자가 해내려는 일의 관점으로 검토해야 한다. 실제 문제를 이해하고, 그 문제가 해결할 만한 가치가 있는지도 확인해야 하는 것이다.
2부: 상황, 진전과 결과를 적는 일의 정의
요청에서 사용자의 일을 찾아낼 때 Kent는 몇 가지 질문을 제시한다. 누구를 위한 기능인지, 문제가 언제 생기는지, 그 사람이 어떤 진전을 원하는지, 지금은 어떻게 하고 있는지 확인한다. 얼굴 인식 입장 기능은 참가자를 위한 것이지만, 입구를 지키며 입장 처리를 하는 사람을 위한 것이기도 하다. 궁극적으로 서비스를 받는 사람은 참가자이고, 기능을 실제로 운영하는 사람도 설계에 영향을 준다.
문제는 참가자가 워크숍에 들어갈 때 발생한다. 원하는 진전은 방 안에 들어가는 것이다. 지금은 QR 코드를 스캔하고, 그 과정의 요청이 완료될 때까지 기다려야 하는 방식이라고 참가자들이 설명한다. 여기서 Kent는 병렬 처리도 같은 문제를 해결할 수 있다고 지적한다. 얼굴 인식을 추가하는 것만이 유일한 해결 방향이 아니라, 기존 입장 처리 방식을 병렬화하는 선택도 생긴다.
그는 이 내용을 일의 정의 문장으로 적는다. 상황이 생길 때 어떤 진전을 하도록 도와주고, 그 결과 무엇을 이루려는지 쓰는 것이다. 필요하면 피하고 싶은 결과도 덧붙인다. 실습에서는 10시 10분에 워크숍이 열릴 때, 제품 엔지니어링을 배우기 위해 빨리 입장하게 도와주고, 강의 첫 20분을 놓치지 않게 해 달라는 문장이 된다. 이 문장에는 얼굴 인식이 등장하지 않는다. 목적을 구현 방법과 분리한 것이다.
이 목적을 알고 나면 어떤 방향으로 진행할지 결정하는 데 도움이 된다. 제품 관리자가 이런 문장을 제공해야 하는 것 아니냐는 반론에 Kent는 그 역할 자체를 부정하지 않는다. 그러나 요청에 일의 정의가 붙어 있지 않거나, 어느 목적에서 나온 요청인지 자신이 모른다면 문제를 충분히 이해하지 못하고 있다고 보아야 한다.
제품 관리자가 그 단계를 건너뛰었을 수도 있다. 그런 상태에서 개발하면 실제 사용자에게 효과가 없는 것을 3개월 동안 만들 수 있다. 또는 한 사람에게는 좋아 보였지만 다른 사람에게 널리 적용되지 않는 문제를 풀 수 있다. 왜 필요한지 추적하고 일의 정의 문장으로 정리하는 것은 이런 낭비를 줄이는 방법이다.
그다음에는 하나의 일을 기능적·사회적·감정적인 세 차원으로 나눈다. 기능적으로는 제품이 실제로 필요한 일을 하는지를 본다. 사회적으로는 제품을 쓰는 상황에 누가 관련되는지를 본다. 감정적으로는 사용하면서 부끄럽거나 소극적이 되는지, 기대감을 느끼고 흥분하는지 같은 느낌을 확인한다. 이 질문들은 제품 설명을 풍부하게 만들기 위한 장식이 아니라 다음 단계의 기술 결정에 영향을 주는 정보이다.
2부: 기능적·사회적·감정적 필요와 React의 선택
Kent는 세 차원에서 확인한 내용이 실제로 프로덕트 엔지니어의 기술 결정과 연결되므로 답을 알아야 한다고 강조한다. 그는 소프트웨어 라이브러리도 제품이라는 점을 설명하기 위해 React가 널리 선택된 과정을 이 틀로 해석한다.
React가 이겼다는 표현은 그의 견해이다. 그는 React를 좋아하며, React 이후 다른 기술이 나올 수 있지만 개발자가 그 구현 기술을 예전처럼 직접 배워야 하는지는 달라졌다고 본다. 에이전트에게 어떤 도구를 주었을 때 잘 작업하는지가 더 중요해질 수 있다는 주장이다. 이것은 후속 프레임워크의 출현이 불가능하다는 설명이 아니다.
처음 React가 선택된 이유는 기능적인 측면이었다. 당시 Backbone, Ember, AngularJS 등을 쓰던 개발자에게 React는 상당히 빨랐다고 Kent는 회상한다. 자신은 AngularJS를 사용하고 있었다. 현재는 재렌더링을 많이 논의하지만 당시 비교 대상보다 빨랐고, 상태 관리의 정신 모형이 단순했으며, 조합이 좋았다는 것이다.
그가 특히 높이 평가하는 것은 캡슐화와 조합이다. 내부 구현이 복잡하더라도 바깥에 안정적인 인터페이스를 제공하면 내부의 복잡함이 다른 부분으로 퍼지지 않는다. 작은 부분을 만들고 결합하는 방식은 당시에도 좋았고 지금도 좋다고 그는 말한다.
2015～2016년 무렵 React가 매우 널리 쓰이게 되면서 선택 이유는 사회적인 차원으로 확장되었다. 다른 사람들이 사용하고, 상사가 사용하기를 원하고, 팀이 사용하며, 업계에서 취업하려면 배워야 한다고 생각하게 된다. Angular 2나 다른 선택지도 있었지만 React의 지배력과 생태계가 큰 이유가 되었다는 설명이다.
감정적인 이유도 있었다. 남들과 같은 기술을 사용한다는 느낌, 관련 콘퍼런스에 참가해 다른 사람들과 함께 기대하는 경험이 선택을 강화했다. 지금은 누군가 React를 싫어할 수 있어도, 당시에는 그런 사회적·감정적 만족이 중요했다고 Kent는 본다.
그는 이후 React의 기능적인 측면이 조금 흔들리고 SolidJS처럼 렌더링 문제를 줄이는 도구나 Vue처럼 배우기 쉽다고 주장하는 도구가 나와도, 기능 차이만으로 상황이 뒤집히지는 않았다고 설명한다. Vue의 학습 난이도에 대해서는 논쟁할 수 있다고도 덧붙인다. 이미 형성된 네트워크 외부성이 React의 지위를 굳건하게 유지했기 때문이다. 이 사례는 기능이 조금 더 좋다는 것만으로 제품을 선택하는 사회적·감정적 맥락을 대체할 수 없다는 그의 해석을 보여 준다.
2부: 사용자 피드백을 지속해서 접하는 방법
Jack Ryan은 사용자 피드백을 모아 보는 Slack 채널이나 다른 장치를 두라고 제안한다. Kent는 PayPal에서 변경 사항을 출시하면 곧바로 수백만 사용자에게 전달되는 경험이 흥미로웠다고 말한다. 반면 그렇게 큰 사용자 집단의 피드백을 얻는 것은 어려웠다. 그는 당시 큰 회사이니 자신이 무엇을 하든 사업이 계속 잘될 것처럼 생각해 사용자 피드백에 충분한 시간을 쓰지 않았다는 자신의 태도도 돌아본다.
피드백을 모으는 방식은 여러 가지일 수 있다. 판단을 신뢰하는 사람이나 가치가 큰 고객을 골라 전용 채널을 둘 수 있다. Reddit, X를 비롯한 소셜 미디어의 글을 한곳으로 모을 수도 있다. 모든 글에 답하는 것이 반드시 엔지니어의 일은 아니지만, 내용을 계속 보면 제품에서 다듬어지지 않은 부분과 작은 불편, 반복되는 문제가 무엇인지 알 수 있다.
그 정보는 제품이 고용된 목적을 실제로 달성하고 있는지 이해하는 데 도움이 된다. 사용자의 불만을 보며 왜 그 부분을 문제로 느끼는지 파악한다. Kent는 Don Norman의 사용자 오류가 없다는 관점을 다시 적용한다. 사용자가 잘못하고 있다는 판단으로 끝내는 대신, 사용자가 기대하는 일을 시스템이 지원하려면 무엇을 바꿔야 하는지 생각한다.
때로는 버튼을 다른 위치에 두는 작은 변경으로 사용이 쉬워진다. 때로는 현재 시스템으로는 할 수 없고, 두 시스템이 서로 통신할 수 있도록 구조를 바꿔야 한다. 피드백을 계속 접하면 작은 인터페이스 문제와 더 큰 시스템 문제를 구별하고, 자신의 시스템 관점으로 해결 방향을 검토할 수 있다.
Michael은 자신이 만드는 제품이 사용자의 삶에서 어떤 이야기를 갖는지 생각하는 일이 중요하다고 말했다. 사용 중에 어떤 감정을 느끼는지만이 아니라, 다른 사람이 자신이 그 제품을 쓰는 것을 안다는 사실에 어떤 감정을 느끼는지도 봐야 한다. 사용 자체가 부끄럽게 느껴질 수 있는 제품이라면 그 감정을 구현과 제공 방식에 반영해야 한다. Kent는 이를 설명하려고 예를 떠올리지만 적절한 예를 들지 못했다고 인정한다. 핵심은 기능적 작동뿐 아니라 제품의 사회적 노출과 감정을 설계에 포함하는 것이다.
2부: 얼굴 인식 입장 기능에서 발견한 요구와 대안
실습의 원래 요청은 얼굴 인식이었지만, 이제 목적은 사람들을 더 빨리 방 안으로 들여보내는 것으로 정의되어 있다. Kent는 이 목적을 위해 어떤 상태와 워크플로, 통합을 고려해야 하는지 참가자에게 묻는다.
참가자는 정시에 시작하는 것을 제안한다. Kent는 처음에는 발표자의 시작 시간에 대한 말처럼 받아들이다가, 해결책이 궁극적인 문제를 푸는지 보여 주는 좋은 측정값이라고 판단한다. 워크숍이 얼마나 자주 정시에 시작하는지 추적하면, 입장 방식이 실제 학습 기회 손실을 줄이는지 알 수 있다는 것이다.
얼굴 인식을 구현한다고 가정하면 어떤 데이터를 유지해야 하는지도 검토한다. Kent는 잠깐 NFC를 제안했다가, 뒤의 설명을 위해 얼굴 인식 예제를 계속 사용하기로 한다. 참가자는 모든 사람의 얼굴 데이터베이스, 암호화, 좌석 수를 제안한다. 행사장 수용 인원과 참가자 수 같은 정보도 필요하다. 얼굴 데이터베이스를 둔다는 결정만으로 많은 부분에 영향이 생기고, 암호화와 데이터 처리도 기술 설계의 대상이 된다. 암호화가 있으면 정부의 모든 요구를 충족할 수 있다는 말은 농담으로 제시되며 확정적 규칙으로 설명되지 않는다.
사회적인 차원에서는 누가 누구와 상호작용하는지 확인한다. 입장을 확인하는 직원, 실제로 입장하는 사람, 주변에서 기다리는 사람들이 있으며, 경우에 따라 발표자도 관련된다. 두 개의 줄을 만들자는 제안도 나온다. Kent는 이것이 병렬 처리이며 같은 목적을 달성하는 다른 해결책이라고 설명한다. 얼굴 인식이라는 특정 기술을 더 잘 만드는 질문에서, 입장 처리 전체를 어떻게 나눌지라는 질문으로 선택지가 넓어진다.
감정적인 차원에서 모두가 빠른 입장에 만족하리라고만 생각할 수는 없다. 행사가 자신의 얼굴 인식 정보를 갖고 있다는 사실을 불편하거나 섬뜩하게 느끼는 사람이 있을 수 있다. Kent는 이때 프로덕트 엔지니어가 얼굴 인식을 하지 말고 같은 목적을 위한 다른 해결책을 찾자고 제안할 수 있다고 말한다. 감정적 필요는 기능을 어떻게 제시할지에 관한 문제에 그치지 않고, 아예 특정 기술을 선택하지 않는 이유가 될 수 있다.
2부: 구매 이후의 반복적인 진전을 측정하기
Jobs Theory에는 제품이 고용되는 두 종류의 순간이 있다. 큰 고용은 고객이 돈을 내고 제품을 구매할 때이고, 작은 고용은 실제로 사용할 때이다. Kent는 근처에서 먹은 햄버거를 예로 든다. 돈을 내고 햄버거를 받은 것은 큰 고용이고, 한 입씩 먹는 것은 작은 고용이다. 중간에 그만 먹고 버렸다면 무대에서 맛있었다고 추천하지 않았을 것이다. 처음에 샀다는 사실과 끝까지 만족하며 사용했다는 사실은 다르다.
소프트웨어도 고객에게 돈을 받는 것만으로 끝나지 않는다. 사용자가 실제로 사용하며 진전을 이루는지가 중요하다. 성공을 반복적인 진전으로 정의하고, 진전을 어떻게 측정할지와 사용자가 그 일을 한 번 이상 수행하는지 질문해야 한다.
어떤 제품은 한 사람에게 한 번만 사용될 수도 있다. 워크숍 참가자가 이번 행사 뒤에는 다시 워크숍에 가지 않는다면 앱을 반복해서 쓰지 않을 수 있다. 다만 이 앱을 실제로 사업화하면 돈을 내는 고객은 개별 참가자가 아니라 콘퍼런스일 것이라고 Kent는 설명한다. 그러므로 콘퍼런스가 다음 행사에서도 이 제품을 쓰는지도 중요한 질문이다. 사용자와 구매자가 다를 수 있다는 점이 반복 사용과 성공 측정을 바꾼다.
그는 무엇을 만들거나 바꿔야 하는지, 무엇을 계측해야 하는지, 무엇을 미루거나 만들지 말아야 하는지 묻는다. 목적을 이해하고 나면 얼굴 인식은 어떻게 되는지도 다시 살핀다. Kent는 이제 얼굴 인식의 복잡성이 필요하지 않을 수 있고, 배지 안에 NFC 칩을 넣는 방식이 대안이 될 수 있다고 생각한다. 그러나 NFC도 관련된 새로운 문제들을 만든다. 얼굴 인식은 무조건 잘못이고 NFC가 정답이라는 결론은 아니다.
목적을 이해하면 문제에 집중하면서 가능한 해결책의 범위가 넓어진다. 그런 다음 문제 트리에서 어떤 방향으로 문제를 해결해 갈지 선택할 수 있다. 앞에서 얼굴 인식 예제를 유지한 것은 학습을 위해서였고, 이 단계의 대안 검토는 실제 사용자 목적과 복잡성, 감정적 부담을 고려해 판단을 바꾸는 과정이다.
프로덕트 엔지니어에게 이 이론이 필요한 이유는 시스템의 형태에 관한 질문을 할 언어를 제공하기 때문이다. 작업이 들어왔는데 목적이 정의되어 있지 않으면, 좋은 시스템을 설계할 만큼 내용을 모르겠다고 제품 관리자에게 말할 수 있다. 기능적 영향, 사회적인 관계, 감정적인 진전이 구현과 아키텍처에 어떤 요구를 만드는지 물어야 한다. 그 목적을 모르면 요청된 기능은 완성해도 사용자가 실제로 필요로 하는 시스템이나 기반 요소를 만들지 못할 수 있다.
2부: 지표가 없을 때의 검증과 사용자의 대표성
아직 출시하지 않아 사용자도 지표도 없는 단계에서 무엇을 만들지 결정하는 질문에 Kent는 The Mom Test가 유용하다고 답한다. 먼저 문제가 존재하며 충분히 중요한지 확인한다. AI 덕분에 빠르게 프로토타입을 만들 수 있으므로, 문제가 확인되면 작은 불편이 많은 간단한 해결책을 만들어 사람에게 보여 주고 실제 사용을 관찰한다. 아무도 시도해 보려 하지 않는다면 그것도 신호이다. 사람들이 써 보고 싶어 할 만큼 중요한 문제를 찾아야 한다.
기존 회사에서 제품의 새 기능을 검토할 때도 과정은 비슷하다. 이미 제품을 쓰는 고객이 있으므로 그 고객과 소통할 수 있어야 한다. 제품 관리자에게 그런 연결 수단이 있기를 기대할 수 있다. 고객을 통해 문제를 충분히 이해하고, 프로토타입을 만들어 반응을 보는 것이다. 지표가 없다는 이유로 바로 구현하거나 아무것도 판단할 수 없다고 멈추는 대신, 행동과 반응에서 초기 근거를 얻는다.
제품 관련 직무에서 프로덕트 엔지니어 직무로 옮기려는 사람에게는 엔지니어와 시스템에 관해 많이 이야기하라고 조언한다. Kent는 자신이라면 엔지니어링을 하고 싶으니 이 회사의 시스템과 알아야 할 것을 설명해 달라고 직접 말하겠다고 한다. 인프라의 제약과 설계 구조를 이해하는 데 시간을 쓰고, 엔지니어링팀과 점심을 먹거나 함께 지내며 역할의 격리를 줄이는 방식이다. 질문은 세 가지 팁을 요구하지만 그는 정해진 세 항목으로 나누기보다 실제로 시스템을 이해할 방법을 설명한다.
사용자가 문제라고 하지만 동료는 문제가 아니라고 할 때, 사용자가 항상 옳은지에 관한 질문도 나온다. Kent는 그렇지 않다고 답한다. 예를 들어 기업 고객이 50곳인데 그중 한 곳만 특정 문제의 해결을 강하게 요구할 수 있다. 그 한 곳이 수입의 90%를 책임진다면 사업적으로 그 고객의 요구를 중요하게 볼 것이라고 농담을 섞어 설명한다. 그러나 보통 한 사람의 강한 요구가 다른 사용자를 대표하는 것은 아니다.
다른 고객에게도 The Mom Test의 방식으로 마지막으로 그런 문제를 겪었는지와 어떻게 대처했는지 물어야 한다. 많은 사람이 같은 문제를 겪지 않는다고 확인되면, 처음 요청한 사용자의 주장이 전체 제품에 적용되지는 않는다고 판단할 수 있다. 사용자가 생각하는 방향은 맞을 수 있어도, 그 사람이 요청한 기능이 정답이거나 모두에게 필요한 것은 아니다.
예를 들어 사용자가 특정 위치에 PDF 내보내기 버튼이 필요하다고 말할 수 있다. 엔지니어는 그 버튼을 만드는 데서 끝내지 않고 무엇을 하려는지 물어야 한다. 목적을 알아낸 뒤 다른 고객도 마지막에 그 불편을 겪었을 때 무엇을 했는지 조사한다. 그 결과 메뉴 항목 50개를 클릭해야 같은 일을 할 수 있었다면, 실제로 해결할 가치가 있다는 좋은 신호가 된다. 이때도 직접 이 문제가 있느냐고 유도하기보다 과거 경험과 행동을 확인한다.
2부: 장애 대응에서 필요한 시스템 이해
코드와 아키텍처를 몰라도 장애를 완화할 수 있다면 반드시 그 내용을 이해해야 하는지 묻는 질문에 Kent는 사업의 규모와 손실 속도에 달려 있다고 답한다. PayPal에서 일할 때 자신이 맡은 분야는 국경 간 거래였다. 국경 간 거래 시스템이 고장 나면 사람들이 서로 돈을 보낼 수 없고, 빠르게 수백만 달러를 잃는 상황이 될 수 있다. 그런 환경과 개인 웹사이트의 장애를 같은 방식으로 볼 수는 없다.
그는 최근 자신의 개인 웹사이트가 돌아가는 DigitalOcean 서버가 봇의 공격을 받은 경험을 소개한다. 에이전트에게 프로덕션이 다운되었으니 원인을 찾아보라고 말했고, 에이전트는 봇 공격이 원인이라고 설명했다. 수정할 수 있는지 물은 뒤 고치라고 지시하자 에이전트가 문제를 해결했다. 대부분의 진단과 수정이 에이전트에 의해 이루어진 사례이다.
그 사이트도 중요하지 않은 것은 아니다. 트래픽이 많고, 사람들이 그의 Discord 서버에 참여할 수 있는 유일한 경로이므로 사업의 일부이다. 단순히 Cloudflare Pages에 올린 정적 사이트처럼 설명할 수 없는 복잡성도 있다. 그러나 장애가 지속되는 매 순간 막대한 손실이 발생하는 환경은 아니었다. 에이전트가 해결하는 동안 자신은 다른 일을 해도 된다고 판단했다.
매우 중요한 시스템이라면 이야기가 달라진다. Kent는 그런 경우 시스템이 어떻게 작동하는지 알고, 빠르게 원인을 진단하며 에이전트를 안내할 수 있어야 한다고 말한다. 에이전트가 디버깅하고 최종 수정을 하더라도, 사람이 코드와 아키텍처를 이해하면 훨씬 성공적으로 대응할 수 있다. 에이전트가 장애를 해결해 준 개인적인 경험을 모든 장애 대응에 그대로 적용하지 않는다는 조건이 중요하다.
AI 때문에 시스템의 보안, 안정성, 신뢰성이 나빠졌는지에 대해서는 AI가 본질적으로 문제를 바꾸었다고 보지는 않는다고 답한다. 보안 문제는 이전에도 있었다. 다만 AI로 취약점을 찾아내고 악용하기가 쉬워졌다. 보안을 신경 쓰지 않던 개발자가 더 넓은 범위에 피해를 줄 수 있다는 점에서는 위험이 커질 수 있다. 그는 이를 새로운 문제의 탄생보다 기존 문제를 더 쉽게 식별하고 공격하며 확대하는 변화로 설명한다.
2부: 성장한 제품에서 변경의 가치를 구분하기
다음 실습에서는 제품이 초기 수용자 단계를 지나 더 넓은 대중에게 쓰이는 상황을 가정한다. 이제 많은 기능 요청이 들어온다. Kent는 모든 요청이 같은 방식으로 가치를 만드는 것은 아니라고 설명한다.
그는 Wayne과 Bun에 관해 이야기한 경험을 든다. Bun은 흥미롭고 유용한 새 기능을 많이 출시했지만 몇 가지 기본적인 요구를 놓쳤다는 것이 Wayne의 견해였다. Kent 역시 일부 용도로 Bun을 사용하면서도, 기존 Node 작업을 전부 옮기지 못했다. 자신에게 필요한 핵심 기능이 빠져 있었기 때문이다. 새 기능이 많고 흥미롭다는 사실만으로 기존 사용 방식을 대체할 수는 없다.
Kent는 인수 이후 Bun의 출시 속도가 상당히 느려진 듯하다는 자신의 인상도 말한다. 다른 참가자의 동의를 얻지는 못하므로 이를 검증된 경향으로 단정하지 않는다. 이 부분과 별개로, 그가 Bun을 사례로 선택한 실질적인 이유는 매력적인 부가 기능과 기초 요구의 충족이 서로 다르다는 데 있다.
이 차이를 설명하는 정신 모형이 Kano 모델이다. Kent는 1984년의 매력적 품질과 당연한 품질에 관한 논문에서 나온 모델로 소개한다. 기능이 모두 같은 방식으로 가치를 만드는 것은 아니므로, 스프린트 계획에서도 단순한 요청 목록 이상의 구분이 필요하다.
2부: Kano 모델의 구현 수준과 만족도
Kano 모델의 도표는 얼마나 구현되었는지와 사용자가 얼마나 만족하는지를 두 축으로 놓는다. Kent는 전체 범주가 다섯 개라고 설명한다. 도표에서 강조하는 것은 기본 요구, 성능 요구, 기쁨을 주는 요소의 세 가지이다. 나머지 두 범주는 제품이나 코드베이스에 남기지 않는 것이 좋다고 말하며 뒤에서 설명한다.
기본 요구는 충분히 구현되기 전에는 사용자가 만족하지 못한다. 사람들이 당연히 있어야 한다고 기대하는 기능이므로 조금 구현했다고 기뻐하지 않는다. 다만 완전히 구현한 뒤에도 계속 더하는 것은 가능하고, 그렇게 과하게 구현하면 오히려 문제가 될 수 있다. 기본 요구를 충족하는 것과 같은 기능을 끝없이 늘리는 것은 다르다.
성능 요구는 기본적인 수준에 도달하면 사용자가 괜찮다고 느끼고, 그 이상으로 개선하면 만족도도 높아진다. Kent는 여기에 한계가 있을 수 있다고 덧붙인다. 어느 지점부터 좋아진 정도가 더는 중요하지 않을 수 있다는 것이다. 그럼에도 구현 품질의 차이가 만족도의 차이로 연결된다는 점이 기본 요구와 구별된다.
기쁨을 주는 요소는 사용자가 기대하지 않았던 것이다. 아주 조금만 구현되어도 좋은 반응을 얻을 수 있다. 이후 계속 보완하면 성능 요구에 가까운 관계가 된다. Kent는 도표에 단위가 없다는 점을 짚고, 정확한 수치 관계를 보여 주는 계량 모형으로 읽어서는 안 된다고 설명한다. 범주별 가치의 차이를 이해하는 개념적인 그림이다.
실습에서는 음식 배달 앱을 예제로 바꾼다. 준비된 요청은 가끔 전송되지 않는 주문 확인 이메일, 실시간 운전기사 GPS 추적, 예상 도착 시간의 정확도, 다음 주문에 주는 깜짝 할인, 함께 점심을 주문할 때 사용하는 공유 장바구니이다. ETA가 2분 이내로 정확해야 하는지 10분 정도면 되는지도 질문한다. 공유 장바구니는 메시지 40개를 주고받고 나중에 돈을 달라고 어색하게 말하는 수고를 줄이려는 기능이다.
2부: 음식 배달의 기본 요구와 성능 요구
참가자는 GPS와 ETA를 기본 요구로 제안한다. Kent는 GPS를 일단 기본 요구에 놓되 뒤에서 다시 검토하기로 하고, ETA의 분류도 곧바로 확정하지 않는다. 먼저 자신이 찾는 다른 기본 요구로 주문 확인 이메일을 설명한다.
일부 이메일만 오고 일부는 오지 않는 상태는 만족스럽지 않다. 음식 배달뿐 아니라 다른 앱에서도 신뢰할 수 있는 이메일을 기대하기 때문에, 확인 메시지는 당연히 있어야 한다. 참가자가 꼭 이메일이 아니라 알림일 수도 있다고 지적하자 Kent는 그 구분을 받아들인다. 필요한 확인이 안정적으로 전달되는 것이 핵심이며, 이름이나 전달 채널 자체만이 목적은 아니다.
ETA를 기본 요구라고 말한 참가자의 의견과 달리 Kent는 성능 요구로 분류한다. 합리적인 범위 안에서 맞으면 괜찮지만, 정확도를 더 높이면 만족을 추가로 만들 수 있기 때문이다. 예를 들어 예정된 도착 시간과 실제 도착 시간이 2분 정도 차이 나는 것은 신호등 등의 사정을 생각하면 받아들일 수 있다.
10분 뒤에 온다고 했는데 30분 걸리면 불만이 생긴다. 반대로 30분 뒤에 온다고 했는데 10분 만에 와도 반드시 좋은 것은 아니다. 사용자가 아직 집에 도착하지 않았을 수 있다. 따라서 보수적으로 약속하고 예상보다 더 빨리 보내는 것만으로는 해결되지 않는다. 사용자가 필요로 하는 것은 계획할 수 있는 적정한 정확도이다.
그 수준을 넘어, 휴대전화에 표시된 남은 시간이 기사의 이동에 맞춰 줄어들다가 0이 되는 순간 문 앞에 음식이 도착하면 인상적일 수 있다. 사용자가 계속 휴대전화를 보고 있지는 않더라도 이런 정밀함은 만족을 더할 수 있다. 어느 정도의 개선을 원하는지에 따라 가치가 달라지는 성능 요구의 사례이다.
웹사이트 로딩 속도도 같은 유형이다. Kent는 웹에서는 1초보다 오래 걸리면 사용자가 떠난다고 강하게 표현한다. 이어 실제 기준은 무엇을 만드는지와 상황에 따라 다르다고 설명한다. 어떤 상황에서는 1초면 만족할 만하지만, 250밀리초나 100밀리초로 줄이면 더 인상적으로 느낄 수 있다. 네이티브 앱의 큰 다운로드와 비교하는 과정에서 30GB와 20분을 언급하지만, 이는 웹과 네이티브에서 기대하는 성능이 다르다는 농담 섞인 대비이지 모든 앱의 실제 측정값은 아니다.
기본 요구는 더 많이 제공한다고 계속 좋아지는 것이 아니다. 주문 관련 알림을 받는 것은 필요하지만, 기사가 물건을 받았고 출발했으며 정지 표지판을 지났다는 식으로 계속 알림이 오면 지나치게 많다. 성능 요구와 기본 요구의 차이는 같은 항목을 더 제공하거나 개선할 때 그것이 실제로 만족을 계속 높이는지에 있다.
2부: 기쁨을 주는 기능과 대중 시장의 기초 조건
깜짝 할인과 그룹 주문은 실습에서 기쁨을 주는 요소로 분류된다. 주문을 마친 뒤 다음 주문에 25% 할인이 나타나면 예상하지 못한 좋은 경험이 된다. Kent는 5% 할인도 반갑고 90% 할인은 더 신날 수 있다고 예를 들지만, 지나치게 큰 할인은 회사에 문제가 있는지 걱정하게 할 수도 있다고 덧붙인다. 기쁨을 주는 기능도 끝없이 강하게 제공한다고 언제나 더 좋은 것은 아니다.
그룹 주문은 해당 기능이 있다는 것만으로도 좋고, 쓰기 편하면 더 좋아진다. 다만 Kent는 협업 기능이 점점 익숙해지고 있어서 그룹 주문이 성능 요구 쪽으로 이동하기 시작했다고 본다. 같은 기능의 분류는 영구적으로 고정되어 있지 않다.
기쁨을 주는 기능은 개발하기 가장 흥미로운 경우가 많다. 반대로 안정적인 알림 같은 기본 기능은 재미없게 느껴질 수 있다. 그러나 기본이 없으면 사용자는 만족하지 않으며 떠날 수 있다. Kent는 흥미로운 부가 기능을 많이 만들어도 기본 기능의 부족함을 상쇄할 수 없다고 강조한다.
여기에는 초기 수용자라는 예외가 있다. 처음에는 사람들이 중요한 해결책을 얻기 위해 작은 불편과 빈틈을 견딜 수 있다. 그러나 제품의 사용 대상을 대중으로 확장하는 단계에서는 그런 관용에 기대면 안 된다. 기본 요구가 충족되어야 널리 쓰이는 제품으로 성장할 수 있다는 것이다.
2부: 시간이 지나면서 당연해지는 기능
GPS 추적은 분류가 달라지는 사례이다. Kent는 현재 기본 요구라는 참가자의 의견에 동의하지만, 2015년이라면 기쁨을 주는 요소였을 것이라고 말한다. ETA만 보는 것과 달리 운전기사가 어디에 있는지 직접 보고 판단할 수 있었기 때문이다. 예를 들어 기사가 기차역에 가까워지는 모습을 보면 통과하지 못하고 멈출 수 있겠다고 사용자가 직접 예측할 수 있다.
한때 새롭고 놀라웠던 기능은 시간이 지나며 성능 요구로 옮겨 가고, 이제는 있어야 하는 기본 기능이 된다. Kent는 GPS가 성능과 기본 사이에 있을 수도 있다고 숙고한다. 더 정확하면 좋아질 수 있지만 경쟁 제품보다 조금 더 정확한 것까지 사용자가 크게 신경 쓰지는 않을 수 있다. 합리적인 정확도 안에 있으면 충분히 구현된 것으로 볼 수 있다는 설명이다.
이 과정에서 그는 기능이 Kano 모델의 한 방향으로 이동한다고 주장한다. 기쁨을 주는 요소가 성능 요구가 되고 이후 기본 요구가 된다. 한편 처음에 새로운 기능으로 만들었지만 아무도 관심을 보이지 않으면 도표에서 사라지고 제거될 수도 있다. 실제 사용하지 않는 기능을 계속 유지할 이유는 없다는 것이다.
그러므로 한 번 우선순위를 정했다고 그대로 두어서는 안 된다. 경쟁 제품이 무엇을 하는지 정기적으로 보고, 새로 추가한 매력적인 기능이 어떤 문제를 해결하는지 살펴야 한다. 자신도 같은 문제를 자신의 방식으로 해결할 수 있을지 검토한다. 경쟁사의 기능을 그대로 복사하라는 설명이 아니라, 기대가 변하는 동안 기본과 성능의 기준을 다시 살피라는 것이다.
Wayne은 기본 요구를 호텔의 화장지에 비유했다. 화장지가 없으면 나쁜 경험이지만, 100롤이 있어도 경험이 100배 좋아지지는 않는다. 오히려 음식에 문제가 있는지 걱정하게 할 수 있다. Kent는 기본 요구의 곡선을 완전 구현 이후로 계속 연장한다면 과잉 제공 때문에 만족도가 내려갈 수 있겠다고 해석한다.
그는 매력적인 기능에 많은 시간을 쓰기 전에 기반과 프리미티브를 제대로 만들라고 강조한다. 기본 요구를 놓치지 않았는지 알 수 있는 좋은 피드백 시스템도 필요하다. 구현을 끝냈다는 사실만으로 충분하지 않고, 사용자가 기본 기능을 실제로 안정적으로 이용할 수 있는지 알아야 한다.
2부: 기능의 가치 유형에 맞는 기술 투자
제품 관리자는 가치가 어디에서 생기는지 찾아내는 책임을 맡고, 프로덕트 엔지니어도 그 일에 일부 책임을 갖는다. 이상적인 상황에서는 제품 관리자가 찾은 가치를 엔지니어에게 전달한다. 엔지니어는 그 가치를 충분히 이해하고 기술 요구로 바꿔야 한다.
Kano 모델은 어떤 일을 먼저 할지뿐 아니라, 각 기능에 얼마나 많은 기술적 노력을 기울이고 투자할지도 결정하게 한다. 신뢰성, 되돌릴 수 있는 정도, 성능 제약, 실패가 얼마나 중요한지 같은 판단이 범주에 따라 달라진다.
기본 요구에서는 신뢰성, 완결성, 책임을 중요하게 본다. 알림이 가끔 오지 않는 상황을 남겨서는 안 된다. 당연히 제공되어야 하는 기능을 확실하게 수행하고, 누가 그 동작을 책임지는지 정해야 한다. 매력적인 실험처럼 일부 사용자에게만 작동해도 된다고 보기 어렵다.
성능 요구에서는 측정 가능한 품질의 차이를 다룬다. ETA의 정확도가 어느 정도부터 만족스러운지, 최소 기준은 어디인지 알아야 한다. 기준 아래에 있으면 문제가 되고, 기본 요구와 함께 성능도 최소 만족 수준까지 올려야 한다. 계측을 통해 실제로 그 목표를 달성하는지 확인한 뒤, 더 개선하거나 새로운 요소를 더하는 선택을 할 수 있다.
기쁨을 주는 요소는 실험으로 다룰 수 있다. 제품의 정체성에 중요하다고 생각해도 그것이 기본 요구는 아니므로, 먼저 기본을 충족했는지 확인해야 한다. 물론 모든 것이 안정적으로 동작하면 좋지만 시간과 토큰은 한정되어 있다. 새 실험이 얼마나 견고해야 하는지, 어느 정도까지 투자할지 결정해야 한다.
이런 실험에서는 아키텍처를 확정하는 결정을 줄일 수 있다. 기존 시스템에 깊이 통합하기보다 다른 시스템에서 많은 것을 배워 볼 수도 있다. 새로운 기능의 형태를 알아낸 뒤에 전체 시스템으로 통합하는 방법을 찾는 것이다. 실험의 가치와 불확실성에 맞춰 초기 결합을 줄이고, 배운 뒤 구조를 정하는 선택이다.
2부: 무관심한 기능과 사용자가 원치 않는 기능
Kano 모델의 나머지 두 범주는 무관심과 역기능이다. 무관심한 기능은 사용자가 있어도 없어도 별 차이가 없다고 느끼고 필요로 하지 않는 기능이다. Kent는 그런 기능을 제품의 영구적인 일부로 두지 말고 가능한 한 빨리 빼는 것이 좋다고 말한다. 엔지니어에게 유지해야 할 부담만 남기고 쓸모가 없기 때문이다.
예를 들어 어떤 기능을 유지하는 데 2주를 쓰거나 새 시스템으로 옮기느라 2주를 쓰고 있다면, 제품 관리자나 상사에게 실제로 누가 쓰는지와 누가 관심을 보이는지 물을 수 있어야 한다. 아무도 쓰거나 중요하게 여기지 않는다면 그 기능을 이식하는 작업을 계속할 이유가 없을 수 있다. 우선순위는 새 기능을 추가하는 데만 적용되지 않고, 필요 없는 유지와 마이그레이션을 중단하는 데도 적용된다.
역기능은 사용자가 제품에 추가되기를 원치 않는 기능이다. 앞서 검토했던 얼굴 인식 입장 기능에 소셜 미디어 자동 게시가 붙는 경우를 다시 든다. 체크인하면 자신이 그 행사에 간다는 내용이 자동으로 올라가는 기능은 사용자가 매우 싫어할 수 있다. Kent 자신도 그런 기능을 크게 싫어할 것이라고 말한다. 단순히 관심이 없는 기능보다 더 나쁜 반응을 만드는 경우이다.
그는 사용자가 싫어하는 수상한 동작을 하는 제품이 존재한다는 점을 지적하며, 그것을 실제로 만든 사람이 누구인지 묻는다. 소프트웨어 엔지니어들이 만들었다는 답이다. 책임이 엔지니어에게만 있는 것은 아닐 수 있지만, 엔지니어가 직접 구현한다는 점에서 책임을 피할 수 없다고 그는 본다.
소프트웨어는 사람의 삶을 훨씬 좋게 할 수 있지만, 같은 엔지니어가 그 반대의 결과도 만든다. Kent는 사용자의 삶을 나쁘게 만드는 아이디어에 이의를 제기하고 만들지 않겠다고 말할 것을 촉구한다. 자영업자인 자신은 쉽게 말할 수 있지만 고용된 사람은 다를 수 있다는 반론도 인정한다. 그래도 자신을 존중하고 반대할 수 있어야 한다는 것이 그의 개인적인 의견이다.
2부: 올바른 것을 만드는 판단의 지속적인 가치
Kent는 The Mom Test가 초기 아이디어를 검증하는 데 도움이 되며, 스타트업뿐 아니라 회사 안에서 생긴 새 제품 아이디어에도 적용된다고 설명한다. Jobs Theory로 요청을 정의하면 사용자가 전달한 해결책을 그대로 만드는 대신 여러 요청을 하나의 해결책으로 풀 수 있다. Kano 모델은 이어지는 변경의 우선순위를 판단하고, 적어도 역기능 범주에 속하는 것을 출시하지 않도록 돕는다.
그는 AI 에이전트가 구현 능력의 차이를 줄일 때 차별점은 올바른 것을 만드는 것이라는 처음의 주장을 다시 제시한다. 이를 마지막으로 배워야 할 능력이라고 부르는 이유이다. 에이전트가 이 판단까지 수행하게 된 뒤의 업계가 어떻게 될지는 자신도 모른다.
다만 그의 AI 전망이 틀릴 수도 있다. 에이전트가 지금 수준에서 멈추고 더 발전하지 않으며, 사람이 계속 감독해야 할 수도 있다. 그런 경우에도 제품 판단의 가치는 사라지지 않는다고 Kent는 강조한다. 제품 판단은 기술 전문성을 사용자의 실제 문제와 결합하는 사람이 팀과 회사에서 가장 가치 있는 구성원 중 하나가 되도록 하는 능력이기 때문이다. 이 주장의 유용성은 AGI가 반드시 등장한다는 미래 예측에만 달려 있지 않다.