4. 에이전트 제품 기획·개발은 어떻게 이루어질까?

에이전트 기획을 제품으로 구현하는 방법

프레임워크, 에이전트 구조, 그리고 도구(Tool)의 개념까지 살펴봤다. 그러면 이제 이를 활용해서 어떻게 제품을 기획할 수 있을까? 사용자가 던진 채팅 한 줄이 어떻게 우리 제품의 내부 기능을 조작하고, 사용자에게 좋은 경험을 제공할 수 있을까?

이번 글에서는 기존 화면 기반의 B2B SaaS 제품을 에이전트 기반 경험(AX)으로 전환하는 실제 기획 사례를 풀어보려 한다. 거창하게 새로운 API를 처음부터 다 짜는 것이 아니라, 이미 존재하는 사내 API를 재활용해서 푼 현실적인 사례다.

Before: 기존의 사용자 경험 톺아보기

평가 척도 등록 모달 ©에이치닷 헬프데스크

채용 SaaS에 흔히 있는 '평가 척도(면접 채점표)' 기능을 예로 들어보자.

기존에 사용자가 새로운 평가 척도를 만들려면 꽤 번거로운 과정을 거친다.

1. '설정' 메뉴 어딘가에 숨어있는 '평가 척도 관리' 페이지를 찾는다.

2. '추가' 버튼을 누른다.

3. 폼(Form)이 열리면 항목을 하나씩 손으로 타이핑한다.

4. 대량으로 등록해야 할 때는 엑셀 템플릿을 다운받아 작성한 뒤 '엑셀 업로드' 기능을 쓴다.

요즘처럼 LLM이 보편화된 시대에는 여기에 과정이 하나 더 붙는다. 사용자는 챗GPT를 켜서 "면접 평가 척도 좀 만들어줘"라고 시킨 뒤, 그 결과물을 첨삭하며 기업에 최저화한 후, 우리 제품의 엑셀 템플릿에 붙여넣고 있을 것이다.

After: 에이전트로 페인포인트 없애기

기존 UX의 흐름을 뜯어보면 두 가지 명확한 페인포인트가 보인다.

사용자가 굳이 우리 제품의 메뉴 위치와 사용법을 학습해야 한다.

척도를 설계하는 곳(LLM)과 등록하는 곳(우리 제품)이 분리되어 경험이 단절된다.

이걸 에이전트 경험(AX)으로 합치면 흐름이 완전히 바뀐다.

이렇게 한번 상상해보자.

① 자연어 요청

사용자는 기능 위치를 찾을 필요 없이 채팅창에 바로 입력한다.

"새로운 기획자 채용 시 사용할 평가 척도를 등록할 거야. 7점 리커트 척도로 구성해 주고, 평가자가 '꼼꼼함'과 '경험의 깊이'를 기준으로 채점할 수 있게 설명도 적어줘."

② 에이전트의 제안

에이전트가 요청을 분석해 평가 척도 초안을 먼저 채팅창에 표 형태로 제안한다. (여기서 외부 LLM을 쓸 필요가 없어진다.)

③ 사용자 승인

사용자가 내용을 확인하고 "응, 이대로 만들어줘"라고 대답한다.

④ 도구 호출 및 완료

에이전트가 내부 API를 찔러 데이터를 생성하고, "등록을 완료했습니다"라고 응답한다.

사용자는 그냥 그걸 쓰거나, 피료할 때 에이전트를 활용해서 다시 수정하면 된다.

기획자와 개발자는 어떻게 소통할까?

이렇게 목표와 흐름이 잡혔다면 이제 개발자와 소통할 차례다. 이때 나는 주로 피그마를 이용한다. 기존 디자인 컴포넌트를 활용해서, 사용자가 A라고 입력하면 챗봇이 B라고 대답하고, 그 아래에 C라는 버튼이 생기는 식의 '시뮬레이션한 화면'을 그려서 소통한다.

그리고 에이전트 기획인 만큼 백엔드 개발자와 꼭 짚고 넘어가야 할 정책들을 챙긴다.

가장 대표적인 게 데이터 유효성 검사(Validation)다. 화면 UI에서는 사용자가 글자 수를 넘기거나 빈칸을 제출하려고 하면 프론트엔드 단에서 경고창을 띄워 막아준다. 하지만 에이전트는 프론트엔드를 거치지 않고 다이렉트로 백엔드 API를 찌른다. LLM이 엉뚱한 데이터를 뱉어낼 때를 대비해, 평소보다 훨씬 깐깐하게 백엔드 단의 방어 로직을 세워달라고 요청해야 한다.

에이전트 기획 6단계 프로세스

앞선 고민을 바탕으로 실제 도구(Tool)를 코드에 붙여 기능을 완성하기까지, 실무에서는 대략 아래의 6단계를 거친다.

① 시나리오 기획 및 시뮬레이션 (PM)

기능 AX 예시 ©작가편집

특정 기능을 대화형 경험으로 어떻게 풀지 정의한다. 화면 기반의 정책을 텍스트 핑퐁으로 어떻게 비틀지 분석하고, 피그마로 챗봇 흐름을 그려 개발자에게 전달한다.

② 인터페이스 합의 (Front/Back/PM)

단순히 API를 찔러서 텍스트 결괏값만 주면 백엔드만 작업하면 된다. 하지만 에이전트 응답에 '생성된 척도 확인하러 가기' 같은 액션 버튼을 달아야 한다면? 버튼 클릭 시 어떤 모달(Modal) 창을 열어줄지 프론트-백엔드가 인터페이스를 정밀하게 맞춰야 한다.

③ 도구 개발 및 연동 실험 (Back)

백엔드 개발자가 사용자 스토리를 분석하고, 기존 API를 LLM이 호출할 수 있는 형태의 도구 코드로 래핑(Wrapping)하여 테스트 환경에 붙인다.

④ 프롬프트 깎기 및 1차 검증 (PM)

구현 예시 ©채용 에이전트

도구가 붙으면 기획자의 늪이 시작된다. 사용자가 입력할 법한 엣지 케이스들을 다양하게 던져보며, 에이전트가 적절한 도구를 쓰고 의도한 답을 내놓도록 시스템 프롬프트를 깎는다.

⑤ 추적(Tracing) 및 최적화 (PM/Back)

데이터독 LLM Observability ©데이터독

데이터독(Datadog) 같은 모니터링 툴을 열고 에이전트의 실행 궤적(Traces)을 파고든다. 엉뚱한 도구를 호출하진 않는지, 토큰 비용은 얼마인지, 응답 속도(Latency)는 어떤지 뜯어본다. 특히 도구가 뱉어낸 응답값이 너무 커서 맥락이 오염되지 않는지 확인하고 응답값 다이어트를 진행한다.

⑥ 벌크 테스트 및 마무리 (QA)

에이전트 QA 백오피스 ©작가편집

도구의 파라미터와 설명을 최종적으로 다듬고, 수백 개의 테스트셋으로 벌크 테스트를 돌려 품질을 검증한다.

중요한 건

사용자가 에이전트에 익숙해질수록, 정해진 화면과 메뉴 트리의 제약을 받지 않는 자유로운 사용자 경험이 훨씬 더 중요해진다. "평가 척도를 등록했습니다." 하고 덜렁 대화가 끝나버리면 사용자는 길을 잃는다. '그래서 그건 어디서 확인하지?' 하고 화면을 헤매게 된다. 에이전트가 성공적으로 액션을 완수했다면, 방금 등록한 데이터를 바로 확인하거나 수정할 수 있는 링크, 혹은 바로가기 버튼을 결과 메시지와 함께 뱉어주도록 설계해야 한다. 이처럼 대화의 끝은 단절이 아니라, 항상 다음 행동을 자연스럽게 이어주는 시작점이 되어야 한다. 에이전트 서비스를 기획할 때, 이 매끄러운 연결 경험을 내 머릿속의 기획 기준으로 삼고 있다.

이제 여기까지 해봤다면 에이전트는 제법 그럴싸하게 일을 해낸다. 하지만 아래와 같은 생각이 머릿속을 맴돌 것이다.

"얘가 항상 이렇게 일을 잘 처리할까?"

"혹시 엉뚱한 데이터를 지워놓고 뻔뻔하게 성공했다고 거짓말하는 건 아닐까?"

그래서 다음 글에서는 에이전트 기획의 가장 중요한 '품질 검증'에 대해 다룰 생각이다. 눈알 빠지도록 수백 개의 케이스를 직접 테스트하던 과정을 거쳐, 이제는 QA 백오피스를 기획/개발하여 자동화한 상태인데, 이 경험을 공유할 것이다.

ⓒ 2026. 327roy All rights reserved.