0. 에이전트 기획 레슨런: 인트로
채용 에이전트를 만들며
회사에서 채용 에이전트를 기획한 지 벌써 3개월이 넘었다. 이제는 출시를 앞두고 세미나를 열어 고객들에게 제품을 소개하고 있다.
예전에는 LLM을 활용한 단발성 기능을 주로 만들었다.
사용자가 기존 채용 공고나 워드 문서를 업로드하면 지원자를 검색할 때 쓰기 좋은 공고 형태로 바꿔주거나, LLM을 활용해 구직자 프로필을 분석해서 리포트로 가공해 주거나, 혹은 사용자가 페이지에 방문하면 로그를 분석해서 적절한 콘텐츠를 추천하거나.
인재 매칭 서비스 일부 ©H.X하지만 지금 만들고 있는 건 그런 단편적인 기능이 아니라 진짜 에이전트 구조다. 에이전트가 직접 본인의 판단 하, 제품의 API를 조작하며 데이터를 생성하거나 조회하는 등 능동적으로 움직이는 제품이다.
당연하게도 과정이 순탄치만은 않았다. 구조만 벌써 3~4번을 엎었다. 멀티 에이전트 구조로 전환도 해보고, 사용자의 의도를 세세하게 분석하겠다며 오케스트레이터와 플래너를 두는 복잡한 구조도 짜봤다.
이리저리 연구하던 에이전트 구조 ©작가편집수많은 시행착오 끝에 내린 결론은, 실제 운영되는 제품에 에이전트를 붙일 때 가장 중요한 건 결국 '고객이 허용하는 시간과 기대하는 품질의 타협점'을 찾는 일이 가장 중요하다는 것
예를 들어, 사용자가 채용 계획을 세우다가 "지원서 블라인드 평가 설정해 줘"라고 입력했다고 치자.
이때는 굳이 오케스트레이터, 플래너, 서브 에이전트로 이어지는 무겁고 거창한 구조를 태울 필요가 없다.
그냥 단일 구조의 에이전트가 기능을 사용할 수 있는 화면을 바로 띄워주거나, 시맨틱 서치로 기능을 빠르게 찾아주기만 해도 충분하다. 즉, 상황에 맞는 적정 기술과 구조가 따로 있다는 뜻이다.
결국 에이전트를 기획한다는 것은 '고객이 기다려주는 시간과 노력' 대비 '고객이 얻게 될 가치의 크기'를 끊임없이 저울질하고 조율하는 과정이다.
마냥 헷갈리던 도구의 개념도 이제야 명확해졌고, 구조를 수없이 엎고 검증 환경을 세팅하며 개발자와 부대끼다 보니 꽤 쓸만한 노하우가 여럿 쌓였다. 그래서 이 과정에서 겪은 고민과 경험을 하나씩 풀어보려 한다.
실무에서 에이전트를 서비스에 붙이려다 보니 아래 내용들이 인상 깊게 남았다.
어떤 LLM을 가져다 쓸 것인가?
LLM과 툴을 어떻게 엮어서 최적의 아키텍처를 짤 것인가?
프롬프트 엔지니어링은 어느 수준까지 고도화할 것인가?
데이터 서빙은 어떤 방식으로 할 것인가?
에이전트가 목표를 달성하도록 필요한 API를 에이전트의 손에 어떻게 쥐여줄 것인가?
이렇게 만든 에이전트의 품질은 대체 어떻게 검증하고 테스트할 것인가?
운영 단계에서 지속적인 개선은 어떻게 만들 것인가?
사용자에게 어떤 상황에서 무슨 UI/UX가 효과적인가?
앞으로 발행할 글에서 이 질문들에 대한 나름의 해답과 삽질의 기록을 공유할 생각이다. 동시에 PM에게 적합한 에이전트 하네스를 만들며 기획 때 어떻게 도움을 받는지 내부 생산성 향상에 대한 글도 같이 작성할 것이다
© 2026. 327roy All rights reserved.