2026년 1월 근황
H.채용 에이전트 기획과 검증, 그리고 성장
목차
1. 신규 상품 출시 준비
2. 10년 된 제품을 베이스로 에이전트 제품을 출시한다는 것은
3. AI 기획 업무
4. 에이전트 검증 노하우가 생기고 있다.
5. 오랜만의 외출, PM들의 수다 발표
1. 신규 상품 출시 준비
이번에는 회고 업로드가 많이 늦었다.
팀을 이동한 지 두 달째인데, 팀 적응이라는 단어를 꺼내기도 힘들 만큼 정신없이 흘러간 것 같다. 3월부터 기업 채용 시즌이 시작되는 만큼 데드라인이 목 끝까지 차오른 상태에서 1월은 채용에이전트라는 신규 상품 출시의 줄타기가 이어졌던 느낌이다.
현재 속한 팀은 기존에 있던 팀 중에서 가장 규모가 크다. 그래서 마이너 배포마다 6~7개 정도의 프로젝트가 동시에 돌며, 아주 많은 양의 개발을 쏟아내고 있다. 특히 코앞에 다가온 3월 시즌 준비로 인해 구성원의 몰입도와 속도가 다르다.
단순히 기능을 만드는 걸 넘어서 서비스에 딱 맞는 에이전트 시스템을 어떻게 만들고, 사용자에게 어떤 경험을 줄 수 있을 것인지. 기획과 PoC 개발을 하며 느꼈던 막막함, 그리고 뚫어보려 했던 발버둥이 가득했던 한 달이었다.
https://h.place/product/recruit-agent
2. 10년 된 제품을 베이스로 에이전트 제품을 출시한다는 것은
이전 회고에도 언급한 것처럼 새로 합류한 팀의 제품은 10년 넘게 살아남은 장수 서비스다. 좋게 말하면 기능이 정말 풍부하고 자유도가 높다. 채용사이트 제작, 맞춤형 지원서 설정부터 그 안에 들어가는 각종 동의서, 채용 전형별 설정, 채용 성과 리포트 세팅까지. 제품의 러닝커브만 지나면 기업의 채용 담당자가 정말 원하는대로 할 수 있다. SaaS 제품의 정석 같은 느낌?
하지만 다르게 말하면 미로같이 복잡하다. 이건 오래된 B2B SaaS 제품들이 가지고 있는 고질적인 문제라고도 생각한다. 그래서 제품이 계약된 후에는 고객에게 배정된 영업 담당자가 기업에 방문하여 제품 교육을 진행하거나, 실제 고객이 기능을 사용할 때 실시간으로 기술지원 업무를 진행하곤 한다. 한 페이지에 버튼과 기능이 수십 개고 기획자인 나도 가끔 길을 잃는데, 처음 온 사용자는 오죽할까 싶다.
채용에이전트가 해결하려고 하는 문제는 이와 맞닿아있다. 우리가 자동차에 열쇠를 꽂았을 때 차 시동이 걸리는 원리를 굳이 몰라도 되는 것처럼, 고객이 제품을 배우는데 신경을 쓰는 것보다 '좋은 채용을 효율적으로 하는 것 그 자체'가 이 제품의 목적이기 때문이다.
채용에이전트는 단순히 "채용 공고 어떻게 올려요?"라고 물으면 매뉴얼 읊어주는 챗봇이 아니다. "개발자 채용 공고 세팅해 줘"라고 말하면, 에이전트가 채용 세팅을 위한 각종 도구(Tool)를 호출해서 직접 세팅하고, 사용자에게 경험을 제공한다.
에이전트가 변화시키는 사용자 경험 ©작가편집단발성으로 기능을 실행하는 역할을 넘어 채용을 설계하고 운영하는 과정 속에서 계속 상호작용하는 형태를 지향하고 있다. 이 관점에서 주위에 레퍼런스로 삼을 에이전트 서비스가 부족하다는 게 아쉽지만, 단발성 LLM 기능을 넘어 진짜 에이전틱한 경험이 무엇인지 진지하게 고민하며 나아가고 있다.
그래서 설계하고, 깨지고, 다시 고치는 과정이 매일 반복되는 듯. 투입되는 노력과 시간이 많지만 눈에 보이는 결과는 적을 때가 더 많다. 다만 이런 지식이 조직에 레퍼런스로 쌓이며 점차 프로젝트 구성원 전체가 함께 성장하고 있다. (이제 다들 내부 API를 활용한 에이전트의 도구를 설계하는 데는 도가 텄다. 이제 아이디어 싸움을 하는 중)
3. AI 기획 업무
에이전트 기획을 하다 보니 업무의 포션이 이렇게 나누어지는 것 같다.
화면설계 5% - 에이전트 구조·프롬프트·도구 설계 25% - 검증 및 개선 70%
화면설계 관점에선 어떤 컴포넌트를 만들고, 공통화할 것인지 고민하는 게 주된 포인트인 것 같다. 사용자가 채팅을 쳤을 때 멀티 셀렉트를 줄 것이냐, 싱글 셀렉트를 줄 것이냐, 혹은 테이블을 줄 것이냐 등 MD 에디터를 사용하지 않는 만큼 디자인 컴포넌트를 뽑아내는 과정이 존재한다.
그다음이 에이전트 구조·프롬프트·도구를 설계하는 것. 이 세 개가 진짜 같이 굴러간다. 에이전트가 달성해야 하는 목적/목표가 무엇인지, 이에 맞춰 몇 개의 에이전트가 체이닝되고, 어떤 프롬프트를 짤 거고, 어떤 도구를 사용해야 하는지 등.
특히 에이전트에게 어느 정도의 도구를 쥐어줄 것인지 기획하는 게 정말 아이디어 싸움이라고 생각한다.
도구는 AI 에이전트가 LLM의 한계를 넘어 실시간 작업을 수행할 수 있도록 하는 함수나 외부 리소스를 의미하는데, 이 때문에 개발자와 기획자가 함께 브레인스토밍하는 경우가 많아진 듯.
가령 피그마 MCP를 사용한다면, 에이전트가 사용자 요청 + 본인의 프롬프트에 따라 피그마 MCP를 통해 제공되는 다양한 '도구'를 사용하게 된다.
피그마 MCP 도구 목록 ©Figma만약 채용에이전트가 채용 진행 과정을 사용자에게 제공하려면? '채용 현황' 데이터를 조회하는 도구를 어떤 빈도로 호출시킬 것인지 에이전트의 프롬프트에 녹아있어야 한다.
그리고 가장 중요한 게 남았다. 검증과 개선을 반복하는 것. 당장 이번에만 하더라도 1월 동안 멀티 에이전트 구조(에이전트 병렬 호출 + 통합)를 채택해서 실험하다가, 속도와 정확도란 목표 달성이 안되어서 다른 구조로 피봇팅 했다. 진짜로 설계한 구조가 생각한 것처럼 동작하는지 실험하며 프롬프트를 깎아내는 과정이 필요하다.
검증에서 가장 중요한 건 '검증의 기준'을 정의하는 것이다. 에이전트는 100% 정확하기 힘들다. 어제는 내가 원하는 기능과 답변을 제공하던 질의가 어떨 땐 잘 안 될 수도 있다. 그래서 우리가 이상적으로 생각하는 질의(Happy path), 예외 상황(Edge case), 공격 상황(Adversarial case) 셋을 미리 만들어둔다.
그리고 이를 대용량으로 테스트하며 지표를 뽑아낸다. 이 과정을 겪으며 에이전트 기획과 검증에 있어 노하우를 더 쌓을 수 있게 된 것 같다.
AI 기획 업무는 보편적으로 진행되는 '서비스 기획' 업무와는 거리가 좀 있는 듯. 어떤 목적을 달성하는 일꾼을 사고방식부터 설계하고, 그 일꾼이 사용하는 도구까지 만드는 게 AI 기획인 것 같다.
4. 에이전트 검증 노하우가 생기고 있다.
위에서 말한 것처럼 AI 기획에서 7할은 '검증과 개선'이라고 생각한다. 특히 이번 에이전트는 SSE(Server Sent Event) 방식을 통해 API의 결괏값을 실시간으로 내려주는 구조라 검증 난이도가 더 높았다.
30초 단위로 Heartbeat API를 통해 프론트-백엔드의 구독 상태를 체크하는데, SSE의 구독 연결 시간을 줄일수록 서비스 단에는 안정성이 생기지만, 벌크로 검증을 진행해야 하는 AI 기획자 입장에선 난처해진다. (답변받기 전에 연결이 끊기면 답변을 전달받지 못하기 때문)
특히 '이동', '위키', '통계분석', '실행' 등 각기 다른 목적의 에이전트 플로우가 나오는 상황에서 이걸 채팅방에 직접 치고 데이터독에서 일일이 에이전트 로그를 확인하는 건?
입력 → 답변 대기 → 데이터독 확인 → 엑셀에 기록 과정으로 질의 150개를 검증하는데 150분 정도가 걸렸다.
그래서 1월 초에는 주말 동안 Cursor + Gemini 3.0 Pro + Python Streamlit 라이브러리를 사용해서 검증용 백오피스를 직접 만들었다. 덕분에 검증 돌려놓고 다른 기획을 병렬로 수행할 수 있게 됐다.
실제 제품에서 사용하는 API에 액세스 토큰을 실어서 호출하는 방식으로 프론트를 구축했다고 보면 될 것 같다. '질의 → API 호출 → 로우 데이터 파싱'이 기본이고, 여기에 LLM을 통한 평가 기능까지 구현했다.
덕분에 질의 업로드 후 딸칵 한 번이면 150분 걸리던 테스트가 5분으로 줄었다. 돌려놓고 화장실 다녀오면 프로그램이 150개 케이스를 다 돌리고 결과 리포트까지 뱉어내도록 세팅한 게 의미 있었다.
이 경험 덕분에 검증 과정에서 개발자와의 소통에 설득력이 크게 생기게 된 듯. "이거 되게 해 주세요"가 아니라, "API 구조가 이러니까 테스트는 이렇게 자동화해 보시죠."라고 제안하는 쪽으로 말이다.
5. 오랜만의 외출, PM들의 수다 발표
발표 자료 일부 ©작가편집1월 24일, 'PM들의 수다' 커뮤니티 초청으로 마이크를 잡았다. 서울 올라와서 맨땅에 헤딩할 때부터 의지했던 곳이라 감회가 새로웠다. 주제는 "PM의 퍼스널 브랜딩". 짧지만 내 경력이 이어지는 동안 어떤 성공경험을 했는지, 왜 한 것 같고 그 노하우가 무엇인지 여태 고찰했던 내용을 정리하여 공유하는 시간이었다.
사실 청중을 위한 강의였지만, 나 자신에 대한 검증이기도 했다. 내가 해온 경험과 고민들이 다른 PM들에게도 울림이 있는지 확인하는 게 목표였다.
준비는 힘들었지만, 현장에서 반짝이는 눈들과 질문, 그리고 발표 종료 후 네트워킹 자리에서의 소통 덕분에 오히려 내가 에너지를 얻어왔다.
역시 가끔은 동굴 밖으로 나와야 한다.
ⓒ 2025. 327roy All rights reserved.
