에이전트는 밀키트가 아니다
원티드랩 PO의 Wanted HiFive 2026 발표를 듣고 정리한 기록 — AI 에이전트를 제품으로 배포하기까지
AI를 매일 쓰는 사람과 AI 제품을 만드는 사람 사이에는 생각보다 큰 강이 있다. 나는 원티드랩에서 채용 서비스 PO로 일하면서, 그 강을 건너는 순간이 언제인지를 비교적 선명하게 기억한다. 회의록을 정리하고, 메일 초안을 쓰고, 데이터를 분석할 때 AI를 쓰는 건 내가 통제하는 행위다. 마음에 안 들면 다시 물어보면 되고, 프롬프트를 고치면 되고, 결과를 직접 수정하면 된다. 최종 책임은 여전히 나에게 있다.
제품은 다르다. 우리가 만든 에이전트가 1만 명, 10만 명의 유저에게 응답을 한다고 생각해보자. 그 응답을 매번 PO가 고칠 수 없다. 어떤 질문이 들어올지 알 수도 없고, 참조하는 데이터도 매번 다르고, 응답하는 맥락도 매번 달라진다. 이 순간부터 고민의 종류가 완전히 달라진다.
에이전트는 밀키트가 아니다
지금까지 내가 기획해온 제품을 굳이 비유하자면 밀키트에 가깝다. 재료가 정해져 있고, 순서가 정해져 있고, 사용자가 A라는 행동을 하면 시스템은 B를 한다. 예외 케이스가 생기면 C나 D로 분기한다. PO는 이 흐름을 중복 없이, 누락 없이 정리해서 팀이 같은 방향을 바라보게 만드는 일을 해왔다. PRD를 쓰고, 플로우를 정의하고, MECE하게 케이스를 펼치는 것이 핵심 역량이었다.
에이전트는 다르다. 나는 이걸 개인 맞춤 요리사에 가깝다고 생각한다. 단골 손님이 들어오면 “컨디션 괜찮으세요? 오늘 재료가 이러이러한데 이건 어떠세요?”라고 그 자리에서 판단한다. 만약 이 요리사에게 “손님이 누가 오든, 재료가 뭐든 똑같이 만드세요”라고 하면 어떻게 될까. 알레르기가 있는 손님에게도 동일한 음식이 나가고, 재료 상태가 좋지 않아도 동일한 음식이 나간다. 이 요리사가 잘할 수 있는 게 빠져버리는 상태가 된다.
그렇다고 아무 기준 없이 “에이전트 네 마음대로 판단해”가 되어서는 안 된다. 제품으로 배포되는 에이전트에는 반드시 기준이 있어야 한다. 다만 그 기준이 “이 질문에 이 문장으로 응답하라”가 아니라, “어떤 맥락까지 보고, 어디까지 판단해서, 어떤 결과를 좋은 응답으로 볼 건지 네가 판단해라, 내가 가이드라인을 줄게”여야 한다는 것이다.
그래서 나는 AI 에이전트 시대 PO의 역할을 이렇게 정의하게 됐다. 에이전트가 매번 어떻게 판단할지 기준을 세우는 사람. 답변을 하나하나 설계하는 사람이 아니라, 에이전트가 어떤 문제에서 어떤 맥락을 보고 어떻게 판단할지를 설계하는 사람.
그 전에 먼저 해야 할 질문이 하나 있다. 이 문제가 정말 에이전트로 풀어야 하는 문제인가? AI를 붙일 수 있다고 해서 모두 에이전트가 되어야 하는 것은 아니다. 기존 규칙 기반으로 조건을 정의해서 풀 수 있다면 그게 낫다. 단일 LLM 호출이나 RAG로 충분한 경우도 많다. 에이전트는 비용, 지연, 운영 복잡도가 크다. 판단이 틀렸을 때 리스크 관리까지 고려하고 나서야 에이전트가 필요하다는 결론에 이른다. AI 제품을 만들 때 가장 먼저 물어야 할 것은 “어떻게 에이전트를 만들지?”가 아니라 “이게 에이전트가 필요한 문제인가?”다.
아찔했던 그 순간, 그리고 배운 것
원티드에서 나는 포지션 검색 에이전트와 커리어 멘토 에이전트를 담당했다. 커리어 멘토 에이전트는 현직자의 경험과 지식 콘텐츠를 기반으로 사용자의 커리어 고민에 답해주는 제품이다. 멘토 인터뷰 데이터, 멘토가 직접 작성한 콘텐츠, 사용자의 이력서와 커리어 경험까지 끌어와서 설계했다.
배포를 앞두고 테스트를 하던 중이었다. “이직하려면 어떻게 해야 하나요?” 이 질문을 우리 에이전트와 제미나이에 동시에 던졌다. 응답이 거의 비슷했다. 오히려 제미나이가 좀 더 구체적으로 답해줬다. 얼마나 아찔한 상황인지 독자분들도 아실 것 같다. 배포가 얼마 안 남았었다.
멘토 인터뷰도 했고, 지식 콘텐츠도 다 끌어왔고, 가드레일도 잡아놨는데 왜 제미나이가 더 잘 답하지? 팀에서 AI 엔지니어와 함께 멘토 전원에게 했던 수백 개의 질문, 수백 개의 응답 데이터를 전부 까서 분석했다.
처음 가설은 이랬다. 멘토의 경험이 특별할수록 차별화된 답변을 줄 것이고, 내가 질문한 멘토가 비교적 일반적인 경험을 한 분이었을 것이다. 분석 결과는 달랐다. 같은 멘토에게 질문해도, 질문에 따라 응답의 차별성이 크게 달라졌다.
“연차별 역량 변화에 대해 어떻게 생각하세요?” 이 질문은 여러 멘토에게 던져도 응답이 비슷했다. 멘토마다 경험은 달라도, 업계에 통용되는 일반론이 있기 때문이다. 주니어 때는 이런 역량, 시니어 때는 이런 역량, 하는 식으로. 반대로 “회사에서 실패했을 때 어떻게 극복하셨나요?” 이 질문을 던지면 멘토마다 색깔이 선명하게 달랐다. 응답 유사도 히트맵을 보면, 붉을수록 응답이 같고 파랄수록 다른데, 극복 방법에 대한 응답은 자기 자신의 이전 답변과만 빨개지고 나머지는 파랬다. 즉, 질문의 성격이 응답의 차별성을 결정하고 있었다.
이 분석에서 두 가지 방향이 보였다. 교과서적인 질문에도 차별성을 만들어야 하고, 이미 잘 되고 있는 개인적 질문은 더 뾰족하게 만들어야 한다. 그래야 ChatGPT를 두고 원티드에 온다.
시간은 없었다. 나는 에이전트의 모든 흐름과 프롬프트를 바꾸는 대신, 먼저 “유저가 좋은 질문을 던지면 멘토의 경험이 묻어난 답변이 나온다”는 사실에서 출발했다. 그렇다면 유저가 좋은 질문을 던지도록 유도하면 된다. 사용자가 멘토 대화방에 처음 진입할 때 “이런 거 물어보세요”라는 추천 질문을 보여주는 것이다. 단순히 LLM으로 질문을 생성하는 게 아니라, 멘토가 답할 수 있는 경험 영역인지 체크하고, 유저의 연차·직무·이력서·최근 행동 패턴을 참고해서 질문을 만들었다.
그다음에는 응답을 생성할 때 더 다양한 데이터를 참조하게 했다. 사용자의 경력, 관심사, 기업 활동, 조회한 포지션. 이것들을 조합해서 같은 질문, 같은 멘토여도 사용자가 다르면 초개인화된 응답이 나오도록 강화했다.
결국 두 의사결정의 공통점은 하나였다. 우리만의 자산을 더 잘 쓰는 방향. 범용 LLM은 이미 방대한 지식을 갖고 있고 거의 무료다. 유저가 우리 제품을 써야 하는 이유는 우리만 가진 데이터와 맥락에 있다. 멘토 인터뷰 데이터, 실제 합격자 데이터, 유저의 커리어 여정. 이 데이터가 응답에 진하게 배어 있는 것이 범용 LLM과 다른 서비스를 만드는 방법이다.
당시 깨달은 것이 하나 더 있다. 문제가 명확하게 정의되면 해결책도 명확해진다는 것. 엄청난 것을 한 게 아니었다. 프롬프트 맥락을 추가했을 뿐이다.
에이전트를 구조화하는 것과 과하게 통제하는 것은 다른 문제다. 평가 케이스는 다양할수록 좋다. 그런데 그 케이스를 하나의 프롬프트에 다 넣으면 에이전트가 중간에 길을 잃는다. 20번 항목으로 가야 하는데 5번에서 멈추는 식으로. 에이전트가 매번 상황을 판단할 수 있게 하되, 모든 것을 프롬프트로 구조화하진 않는다. PO는 에이전트가 판단할 수 있는 환경과 기준을 만들어준다.
이 기준을 실무에서 정리할 때 나는 AI 스펙이라는 짧은 문서를 PRD 위에 덧댄다. 페르소나(이 에이전트는 누구인가), 대화 범위(무엇을 다루고 무엇을 다루지 않는가), 해피패스(이상적인 한 턴은 어떻게 돌아가는가), 대표 시나리오, 가드레일, 평가 기준, 이 여섯 가지다. 처음부터 완벽하게 채우려 하지 않는 게 중요하다. 이 여섯 항목을 팀과 함께 채워나가면서 논의를 시작하는 도구로 쓴다.
가드레일은 이분법이 아니다. 나는 화이트존, 그레이존, 레드존으로 나눠서 일한다. 화이트존은 에이전트가 자신 있게 답할 수 있는 핵심 문제 영역이다. 커리어 멘토 에이전트에서는 멘토의 이직 경험이나 커리어 전환 기준에 대한 질문이 여기 해당한다. 그레이존은 완전히 차단하지는 않지만 에이전트 자율에 맡기기엔 위험한 영역이다. 특정 회사 PO 연봉을 물어보는 경우처럼, 확정적으로 말하지 않고 신뢰할 수 있는 데이터를 근거로 대략적인 범위를 안내한다. 레드존은 응답 금지다. 멘토 개인정보 요청처럼 법적·윤리적·개인정보 이슈가 있을 때는 정중하게 거절하고 다른 질문으로 전환시킨다.
이 합의가 팀 안에 있어야 제품으로 배포할 수 있다.
결국 남는 건 문제 정의의 힘
에이전트를 두 개 만들면서 앞으로 더 중요해질 것 같다고 느낀 역량이 있다.
첫째는 POC를 빠르게 돌려서 모델에 대한 직관을 쌓는 것이다. AI 제품을 망치는 가장 흔한 패턴이 있다. “이 프롬프트 돌리면 나보다 잘하겠지”라고 막연하게 가정하고 기획을 시작하는 것. 기존 제품에서는 버튼을 누르면 뭘 띄운다, 이건 굳이 POC로 검증하지 않아도 된다. 정의하면 그대로 동작하니까. AI 제품은 다르다. 이 모델이 잘하는 영역이면 한 시간 만에도 가능성이 보이고, 못하는 영역이면 아무리 시간을 들여도 품질이 안 나온다. 앤트로픽의 제품 총괄 캣 우루가 인터뷰에서 “프로토타입 제작과 모델 탐색에서 필요한 품질 수준에 빠르게 도달하고, 모델에 대한 좋은 직관을 갖는 것이 중요하다”고 말한 것과 같은 맥락이다. 나는 지금 내 서비스에서 AI로 풀기 가장 까다롭다고 생각하는 케이스 다섯 개를 정의해서 지금 나와 있는 모델들에게 다 돌려보고, 새 모델이 나올 때마다 같은 시험지로 평가해보기를 권하고 싶다.
둘째는 평가 설계다. AI 제품 기획에서 가장 어려운 부분이 “프롬프트를 바꿨는데 이게 좋아진 게 맞아?”다. 기준이 없으면 팀 전체가 감으로 일하게 된다. “내가 물어봤을 때는 잘 답하던데”와 “제가 물어봤을 때는 못하던데”가 충돌한다. ‘유저에게 도움이 되어야 한다’는 평가 기준이 아니다. 구체성, 정확성, 페르소나 일관성, 사용자 맥락 반영, 차별성, 이런 식으로 쪼개야 하고, 배포 가능한 수준도 숫자로 정의해야 한다.
셋째는 시스템 단위로 진단하는 능력이다. AI 제품이 잘못 동작할 때 원인이 하나인 경우는 거의 없다. 데이터 수집 단계의 노이즈일 수도 있고, 프롬프트가 너무 일반적인 답변을 유도할 수도 있고, RAG 문제일 수도 있다. 나는 ‘응답 부검 노트’를 쓴다. 이름이 좀 우습지만 도움이 됐다. 빈 문서에 입력값, 응답값, 어색한 이유, 예상 원인을 계속 적는 것이다. 처음엔 예상 원인이 잘 안 써진다. 비워두고 계속 쌓다 보면 패턴이 보이기 시작한다.
마지막은 문제 정의의 단단함이다. AI 제품을 만들다 보면 이런 함정에 빠지기 쉽다. “AI로 뭘 만들 수 있을까?” 원래는 “어떤 문제를 풀까?”에서 시작해야 한다. 모델이 좋아질수록 선택지가 많아지기 때문에 오히려 무엇을 안 해야 할지 잘 결정해야 한다. 샌프란시스코의 어떤 회사가 멋진 걸 만든다는 소식에 “우리도 만들자”가 되기 쉬운데, PO가 그 기준을 잡아야 한다. 앤트로픽 제품 총괄의 말이 여기서도 유효하다. “개발 비용이 낮아질수록 PM에게 더 중요해지는 것은 무엇을 만들지 결정하는 일이다.”
오늘 이 발표를 하고 나서 돌아가면 한 가지만 해보셨으면 한다고 말하고 싶었다. 완전히 빈 문서를 열고, 우리 서비스가 유저의 어떤 문제를 해결하고 있었는지 적어보는 것. AI가 많은 것을 대신해줄수록, 우리가 집중해야 하는 자리는 그 질문 앞으로 좁혀진다.
이 글은 Wanted HiFive 2026에서 원티드랩 PO의 발표를 듣고 정리한 기록입니다.