AI로 첫 제품을 만든 팀이라면 다음 기능을 정하기 전에 고객이 실제로 쓰는 모습을 봐야 한다. 작동하는 화면을 만드는 일과 고객의 일에 자리를 잡는 일 사이에는 아직 확인할 것이 많다.
앤드루 응은 2026년 9월 11일 공개한 「AI Engineering Skills Map: Shaping the build」에서 AI 엔지니어가 제품을 구현하는 동시에 무엇을 만들지 결정하는 데 참여해야 한다고 말했다. 그가 짚은 역량은 개발과 피드백의 반복을 이끄는 일, 제품 판단, 소통과 리딩, 결과를 끝까지 책임지는 태도다. AI 도구로 구현할 수 있는 범위가 넓어질수록 사용자와 사업을 이해하는 능력도 함께 필요하다는 관점이다.
데모가 끝난 뒤에도 남는 질문
데모를 본 고객이 검색창이나 엑셀 다운로드 같은 기능을 요청할 수 있다. 모두 만들 수 있는 요청이라도 먼저 해결할 문제는 다를 수 있다. 고객이 그 화면을 다시 열 이유가 무엇인지부터 찾아야 한다.
초기 제품인 MVP는 핵심 가정을 시험할 수 있는 최소한의 제품이다. 화면 수가 적다고 저절로 MVP가 되는 것은 아니다. 어떤 고객의 어떤 행동을 확인할지 정해야 기능을 어디까지 만들지도 결정할 수 있다.
첫 사용자에게 보여주기 전에 팀이 합의할 문장은 짧아도 된다. “담당자가 새 견적 문의를 받았을 때, 이 화면을 열어 필요한 정보를 확인하는지 본다.” 여기에는 사용자, 상황, 관찰할 행동이 들어 있다. 고객이 좋아할 것이라는 기대를 실제로 볼 수 있는 장면으로 바꾸는 것이다.
견적 요청서 정리 도구로 생각해 보자
가상의 제조업체에서 견적 요청서를 정리하는 도구를 생각해 보자. 고객은 메일에 문서나 사진을 붙여 보낸다. 담당자는 품목, 수량, 희망 납기를 확인하고 빠진 내용을 다시 묻는다. 이 상황에서 첫 제품의 범위를 “요청서에서 필요한 항목을 꺼내 담당자가 확인하도록 돕는 것”으로 잡을 수 있다.
데모에서는 문서 한 장을 넣고 깔끔한 표가 나오는 모습을 보여주기 쉽다. 실제 업무에서는 다른 장면을 봐야 한다. 고객이 보낸 사진을 읽지 못했을 때 담당자가 원문을 바로 찾는지, 애매한 수량을 확정값으로 오해하는지, 추출 결과를 고치는 데 얼마나 수고가 드는지다.
초기 확인에는 동의를 받은 자료를 쓰거나 민감한 내용을 가린 예시를 쓸 수 있다. 담당자가 평소 방식으로 문의를 처리하는 모습과 새 도구를 쓰는 모습을 함께 살펴보면 비교할 지점이 생긴다. “편하네요”라는 반응에 이어, 다음 문의가 왔을 때 다시 사용하는지도 볼 수 있다.
이 예시에서 자동 견적 계산과 고객 메일 발송은 다음에 따로 판단할 일이다. 품목을 잘못 읽은 채 가격 계산까지 이어지면 검증해야 할 범위가 갑자기 커진다. 우선 정보 확인 과정을 충분히 살펴보면, 고객이 다음에 원하는 기능이 계산인지 원문 검색인지도 더 구체적으로 알 수 있다.
다음 기능을 정할 때 남겨야 할 기록
고객을 만난 뒤 모든 의견을 기능 목록에 넣으면 제품의 범위가 빠르게 넓어진다. 관찰한 사실과 팀의 다음 결정을 나란히 적어 두면 우선순위를 논의하기 쉬워진다.
| 기록할 것 | 견적 요청서 도구에서의 예시 |
|---|---|
| 고객의 현재 업무 | 메일 첨부에서 품목·수량·납기를 옮겨 적는다 |
| 이번에 볼 행동 | 추출 결과와 원문을 확인한 뒤 견적 준비에 쓴다 |
| 계속 진행할 조건 | 다음 문의에서도 사용하고, 확인·수정 부담을 감당할 수 있다 |
| 다시 고칠 조건 | 원문을 찾기 어렵거나 잘못 읽은 항목을 알아차리기 어렵다 |
이 표는 팀이 미리 정해 둘 수 있는 판단 틀이다. 실제 수치나 고객 반응은 관찰한 뒤 채워야 한다. 처리 시간도 측정할 수 있지만, 작업이 빨라지는 동안 중요한 항목을 놓치는지 함께 봐야 한다. 사용이 이어져도 비용을 지불할 의사가 있는지는 별도로 확인할 문제다.
기획과 개발이 같은 고객을 보고 있을 때
앤드루 응의 글은 개발자가 PM으로 전환해야 한다는 주장을 담고 있지 않다. 제품 명세에 적혀 있지 않은 결정을 내릴 때 사용자에 대한 이해와 소통 능력이 필요하다고 설명한다. DeepLearning.AI도 같은 역량을 소개하며 고객 공감과 사업 판단을 함께 강조했다.
작은 팀이라면 창업자와 개발자가 같은 고객의 작업을 함께 보는 방식으로 시작할 수 있다. 고객이 원문을 찾아 헤매는 장면을 둘 다 봤다면 다음 논의는 더 구체적이 된다. 디자인을 손볼지, 원문으로 돌아가는 링크를 먼저 붙일지, 문서 인식 방식을 고칠지 같은 선택이다.
매번 완성된 기획서를 기다리거나 바로 기능을 추가하기보다, 이번 변경으로 확인하려는 행동을 함께 정해 두면 좋다. 구현 담당자는 기술적 제약을, 창업자는 고객과 비용 조건을 보탤 수 있다. 결정할 담당자와 다시 확인할 시점도 남겨야 다음 실험이 이어진다.
첫 고객에게 건넬 준비가 됐다면
시연할 기능을 더 늘리기 전에 실제 업무 한 건을 부탁해 보자. 고객이 어디에서 멈추고, 무엇을 다시 확인하고, 어떤 결과를 다음 담당자에게 넘기는지 관찰할 수 있다. 그 기록을 바탕으로 팀이 다음 변경 하나를 정하는 데까지 가면 첫 MVP가 제 역할을 하기 시작한다.
자주 묻는 질문
첫 MVP에는 고객 요청을 모두 넣어야 하나요?
이번에 확인하려는 업무를 마칠 수 있는 범위를 먼저 정해 보자. 요청서의 내용을 확인하는 실험이라면 자동 발송은 다음에 판단할 수 있다. 고객 요청은 기록하되 다음 실험에 필요한 기능부터 고르면 된다.
고객이 편하다고 말하면 검증이 끝난 건가요?
좋은 반응은 다음에 확인할 단서가 된다. 실제 업무에서 다시 쓰는지, 오류를 발견하고 고칠 수 있는지, 확인에 드는 부담이 줄어드는지까지 관찰해야 한다. 사용 의사와 구매 의사도 나눠서 확인하는 편이 좋다.
함께 읽을 글
참고한 글
- Andrew Ng의 LinkedIn 게시물
- AI Engineering Skills Map: Shaping the build — Andrew Ng, 2026년 9월 11일
- DeepLearning.AI의 관련 LinkedIn 게시물
자료 확인: 2026년 10월 7일.
댓글 남기기