Build the Right Thing: Product Engineering (Part 2) — Kent C. Dodds, EpicProduct.engineer

한 줄 핵심

AI 에이전트가 구현 난이도를 낮춰도 경쟁력은 여전히 무엇을 만들지 정하는 능력에 달려 있으므로, 제품 요구를 진짜 사용자 과업과 우선순위로 번역하는 법을 익혀야 한다.

시간별 요약

1. 0:00
   워크숍 제품으로 돌아가기 기능 요청이 빠르게 쏟아지는 상황을 가정하고, 예시로 얼굴 인식을 들며 요청 뒤에 숨은 실제 문제를 파악하는 흐름으로 들어간다. 단순한 기능 추가가 아니라 제품 판단이 필요한 국면임을 전제로 전체 강의의 문제의식을 세운다.
2. 2:23
   기능 요청 아래의 문제 파고들기 요청을 받으면 계속 왜 그런지 질문해 원인을 한 단계씩 내려가야 한다. 문제를 충분히 거슬러 올라가지 않으면 해결책이 다른 문제를 더 키우는 문제 트리를 만들 수 있다.
3. 6:04
   Jobs to be done 제품은 기능 요청을 그대로 구현하는 것이 아니라, 사람들이 특정 상황에서 진전을 만들기 위해 제품을 고용한다는 관점으로 봐야 한다. 요청은 해결할 과업이 아니며, 각 요청에는 제품 비전과 시스템 비용을 고려한 판단이 필요하다.
4. 8:52
   직무 진술 작성하기 누구를 위한 것인지, 언제 발생하는지, 어떤 진전을 원하는지, 현재는 무엇을 하는지를 정리하면 직무 진술이 된다. 예시로는 워크숍 시작 20분을 놓치지 않고 빠르게 입장하게 해 달라는 요구가 핵심이며, 얼굴 인식 자체는 본질이 아니다.
5. 11:34
   기능적, 사회적, 감정적 필요 과업은 기능적·사회적·감정적 세 차원으로 나눠 봐야 하며, 이 차원들은 구현 방식과 아키텍처 결정에 직접 영향을 준다. React의 확산 사례처럼 기능적 우위가 사회적 요인과 감정적 만족으로 넘어가면 채택이 굳어질 수 있다.
6. 15:00
   사용자 피드백 수집하기 Slack 채널이나 특정 피드 수집 통로를 만들어 사용자 불만과 마찰을 한곳에 모아야 한다. 반복되는 불편과 종이처럼 얇은 마찰을 보면 제품이 실제 과업을 제대로 돕고 있는지, 시스템을 어떻게 바꿔야 하는지 감이 잡힌다.
7. 17:29
   얼굴 인식 요구사항 살펴보기 얼굴 인식을 도입하면 데이터베이스, 암호화, 수용 인원, 줄 관리처럼 시스템 수준 요구가 늘어난다. 사회적으로는 체크인 담당자와 주변 사람들, 감정적으로는 사생활 침해 불안이 생기므로 대안이 더 나은지 판단해야 한다.
8. 20:42
   반복적 진전 측정하기 첫 구매만이 아니라 실제 사용이 반복되는지가 중요하며, 성공은 반복적 진전으로 정의해야 한다. 요청을 해결책에 고정하지 말고, 어떤 변경을 만들고 어떤 계측을 추가하거나 미루어야 하는지 과업 기준으로 결정해야 한다.
9. 23:35
   검증과 장애 대응에 대한 질의응답 아직 사용자와 지표가 없는 단계에서는 문제 검증과 간단한 프로토타입 테스트가 우선이며, 기존 제품은 고객과 직접 접점이 있어야 한다. 인시던트 대응은 사업 규모에 따라 다르지만, 시스템 구조를 이해할수록 에이전트를 더 잘 이끌 수 있고 보안 문제도 더 쉽게 드러난다.
10. 31:25
    소프트웨어 변경 우선순위 정하기 모든 기능 요청이 같은 가치를 만드는 것은 아니며, 핵심 기능이 빠진 상태에서 새 기능만 늘리면 제품이 약해진다. Kano model을 통해 기본 기능, 성능 기능, 매력 기능을 구분해 우선순위를 정해야 한다.
11. 33:14
    Kano model 기본 기능은 완전 구현 전까지 만족을 만들지 못하고, 성능 기능은 더 잘할수록 만족이 늘며, 매력 기능은 적은 구현만으로도 놀라움을 준다. 다만 분류는 고정되지 않으며 시간이 지나면 기능의 기대 수준이 달라질 수 있다.
12. 35:00
    음식 배달 기능 분류하기 주문 확인 이메일과 정확한 배달 ETA, GPS 추적, 할인, 공유 장바구니를 Kano model에 놓고 분류한다. 이메일과 현재 위치 추적은 기본에 가까워지고, ETA는 성능, 할인과 공유 주문은 매력 기능 또는 점차 성능 기능으로 이동할 수 있다.
13. 41:49
    기대가 시간에 따라 변하는 방식 2015년에는 GPS가 매력 기능이었지만 지금은 기본 기능처럼 기대되듯, 기능의 위치는 시장과 경쟁 상황에 따라 변한다. 한때 놀라웠던 기능도 결국 기본으로 내려가므로, 기본을 다지고 경쟁사의 변화를 계속 살펴야 한다.
14. 45:03
    우선순위를 공학적 결정으로 바꾸기 제품 관리자는 가치의 방향을 찾고, 제품 엔지니어는 그것을 신뢰성·되돌림 가능성·성능 제약 같은 기술 요구로 번역해야 한다. 기본에는 신뢰성과 완전성, 성능에는 측정 가능한 품질 기준, 매력 기능에는 실험적 투자 정도를 적용한다.
15. 47:22
    무관심 기능과 원치 않는 기능 무관심 기능은 유지 비용만 남기므로 가능한 빨리 제거해야 하고, 원치 않는 기능은 아예 제품에 들어가면 안 된다. 특히 얼굴 인식과 소셜 공유처럼 사용자가 싫어할 수 있는 기능은 엔지니어가 분명히 거절해야 한다.
16. 50:17
    올바른 것을 만들기 Mom test, Jobs theory, Kano model은 각각 초기 검증, 요청 재정의, 우선순위 결정을 돕는 도구다. AI 에이전트가 구현을 평준화할수록 차별점은 무엇을 만들지 판단하는 능력이며, 사용자 문제와 기술을 연결하는 사람이 가장 큰 가치를 만든다.

실무 인사이트

• 기능 요청을 받으면 바로 설계하지 말고, 사용자 과업과 반복 진전 기준을 먼저 문장으로 정리하면 불필요한 구현을 크게 줄일 수 있다.
• 기본·성능·매력 기능을 구분해 투자 수준을 달리하면, 불필요한 과설계와 유지 비용을 줄이면서도 사용자 만족을 지킬 수 있다.
• AI 에이전트를 써도 제품 경쟁력은 구현 속도가 아니라 문제 정의와 우선순위 판단에서 나오므로, 엔지니어는 요구사항 해석 역량을 강화해야 한다.