AX 프로젝트를 시작하며
1. 잘 나가는 제품팀으로 오다.
2. AI 서비스 기획의 재미와 어려움
3. Agent 시대, 제품은 무엇을 해결해야 하는가
직전 근황 글에서 말한 것처럼 신규 제품, 인재 매칭 솔루션 H.X의 PoC를 종료했다. 11월 말에 2026년 전사 사업 방향이 구체화되며 인사이동이 있었고, 내가 속해있던 TF 팀원들과도 잠깐 안녕했다. 그중 나는 백엔드 2명, 프론트 1명과 함께 40명 규모의 팀으로 이동했다.
이동한 팀의 기획자들과는 기술인재, 핵심인재 활동을 거치며 어느 정도 라포가 있었고, 새로 만나게 된 팀장님과도 안면이 있는 사이다. 한번 일해보고 싶었던 사람인데 이번에 기회가 돼서 함께하게 되니 감회가 새롭다. 다만 이전 프로젝트 종료로 인한 씁쓸함, 다시 이 조직에서 신뢰자산을 쌓고 증명해야 한다는 부담감, 새로운 프로젝트에 대한 설렘이 여전히 공존 중.
이제 맡게 되는 제품은 이전엔 '공채(대규모) ATS'라고 불렸고, 내가 에이치닷에 있을 때 리브랜딩하며 'H.채용'이란 이름을 가진 제품이다. 대기업/중견기업 고객사가 많고, 꾸준히 높은 수익을 내는 10년 정도 된 캐시카우 제품이다. (그린하우스, 그리팅이 유사 서비스를 제공 중이다.)
이 제품은 전통적인 B2B SaaS 솔루션의 특징을 가지고 있다. 제품이 발전하며 존재하는 거대한 레거시들, 고객사가 늘어나며 생긴 전용 개발과 VoC, 보안 규격, 신규 사업에선 경험하기 힘든 매일 발생하는 계약/재계약건. 내 입장에선 오랜만에 잘 운영 중인 제품팀에 온 거라고 할 수 있다.
나는 그중 AX 프로젝트를 전담하게 됐다. 레거시 기능과 제품 구조를 파악하는 것도 필요하지만, 핵심은 Agent를 활용해 채용담당자가 1) 러닝커브 없이 '채용 과정'을 잘 수행하고, 2) 채용을 '잘' 할 수 있게 만드는 전환 작업이다.
덕분에 현재는 'AI 기획'을 많이 하는 중이다. 이전처럼 제품 화면 그리는 시간이 많았던 기획과 달리, 백엔드 개발자와 더 밀접하게 일하며 플로우를 그리고 직접 코드를 짜서 테스트하는 일이 많아졌다. 오히려 지금이 가장 재밌는 흐름에 올라탄 것 같기도 하다.
1분기 동안 제품의 AX를 진행하고, 매출을 높이는 제품을 만들며 전사에서 Agent 기획을 한다면 우리 팀에게 자문을 구할 정도로 성공적인 레퍼런스를 만드는 게 목표다. 2026년도 마음 다잡고 파이팅해야지.
팀을 이동하며 '채용에이전트'라는 제품을 맡게 됐다. 기존에 홍보하던 것과는 사용자 경험이 완전히 다르다. 기존 제품이 'ATS에 에이전트가 더해지는 형태'였다면, 지금 개발 중인 것은 '에이전트를 중심으로 채용에 필요한 사용자 경험이 추가되는 형태'다. 올 상반기 새로운 브랜딩과 함께 고객 레퍼런스를 확보하고, 본격적으로 프로젝트 규모가 커질 것으로 예상하고 있다.
프로젝트 특성상 기획의 성격도 다소 발전했다. 과거에는 화면 중심의 서비스 기획이 많았고, AI를 활용해도 '워크플로우' 정도의 기획이었다. 현재는 본격적으로 사용자가 어떤 질의를 하던 대응해야 하는 Agentic System을 기획하는 만큼 개발자만큼 Agent의 동작 원리를 알고 있어야 한다. 무엇보다 대중화되지 않은 기획/개발인 만큼 개발자들과 함께 학습하며 좌충우돌 시도하는 게 많다.
화면 그리는 시간은 줄고, 다른 작업이 많아졌다. Agent Flow의 목적과 검증 기준을 설정하고, 플로우차트와 데이터 처리 프로세스를 기획한다. Input 가능한 데이터를 분석하고, 필요하면 직접 코드를 짜서 PoC로 검증한다.
Agent의 목적을 기획하는 것만큼 중요하다고 생각하는 게 두 가지 있다. 첫째, Agent와 Tool을 얼마나 쪼개거나 합칠 것인지. 둘째, Agentic Flow의 개선 프로토콜이다. 결국 Agentic System은 속도, 안정성, 정확성, 비용이 핵심인데, 이를 어떻게 달성하고 어떤 기준을 충족하면 개선할 것인지 판단할 수 있어야 한다.
학습할 것도 많지만, 이론으로만 알고 혼자 뚝딱거리던 걸 실전에 접목하니 도파민이 돈다. AI 서비스 기획 레퍼런스를 공유할 수 있는 공간도 1월 중에 찾아보려 한다.
워크플로우와 Agentic System의 차이
워크플로우는 개발자가 미리 정한 고정 단계(예: 입력 → LLM 요약 → Tool 검색 → 출력)를 순차적으로 진행하는 형태다.
Agentic System은 AI가 자율적으로 계획을 세우고 Tool 선택/피드백 루프를 돌며 동적으로 행동하는 '자율적'인 구조다. 워크플로우의 상향식 확장형이라고 할 수 있다.
2025년은 모두가 Agent에 달려들던 해였다. 2026년은 이제 증명해야 하는 시기다.
현 시점 기준으로 서비스에서 제공하는 AI Agent의 사용성은 다들 비슷하다. 생성하거나, 대신 찾거나. 결국 뭔가를 대신하는 것. 그런데 그 '대신해주는 것'이 어딘가 애매한 느낌을 준다. 나의 주도권을 AI에게 넘긴 만큼 데이터의 근거를 신뢰하기 힘들 때도 있고, 실제로 Output이 틀린 경우도 많다. 아무리 사람의 역할이 '판단'으로 돌아선다고 하지만, 여전히 AI에게 모든 걸 위임하기엔 불안하다.
사용자 경험도 점점 '채팅'이라는 형태로 수렴하고 있다. 채팅으로 실행하고, 결과물을 컨펌한다. 그러다 보니 어떤 도메인이든 Agent가 붙었을 때의 결과물이 비슷비슷해진다. 카카오뱅크의 AI든, 내가 만드는 채용에이전트든 마찬가지다. 도메인의 고유한 맥락이 희석되고, 모든 서비스가 범용 챗봇처럼 느껴지는 역설이 생긴다. 사용자는 채용에이전트에서 성과관리에 대한 내용을 묻고, 뱅크에이전트에서 증권가 이슈를 찾는다.
사용자가 기대하는 건 '뭐든지 완벽하게 수행하는 Agent'다. 하지만 현재 기술로는 그 기대를 온전히 충족하기 어렵다고 생각한다. 그렇다면 우리는 어떤 제품을 만들어야 하는가?
지금 시점에서 내 생각은 이렇다. Agent가 모든 걸 대신하는 방향보다, 사용자가 더 잘 판단할 수 있도록 돕는 방향이 현실적이다. 완벽한 자동화가 아니라 신뢰할 수 있는 보조로서의 역할. 왜 이런 결과가 나왔는지 근거를 투명하게 보여주고, 사용자가 최종 결정을 내릴 수 있는 여지를 남겨두는 것. 결국 Agent의 가치는 '대신해주는 것'이 아니라 '더 나은 판단을 가능하게 하는 것'에 있다고 본다.
물론 이건 현재 기술 수준에서의 판단이다. Agent가 정말로 완벽해지는 시점이 오면 이야기가 달라질 수 있다. 다만 그 시점이 올 때까지 불완전함을 인정하면서도 효용을 만들어내는 제품을 설계해야 한다. 이게 가장 큰 고민이고 풀고 있는 문제다.
ⓒ 2025. 327roy All rights reserved.