회사 업무 · 팀 협업 · 2026.09
영업 업무 멀티 에이전트
에이전트가 무엇을 조회하고 언제 저장할 수 있는지 경계를 정했습니다.
개요
- 기간
- 2026.09
- 참여 형태
- 회사 업무 · 팀 협업
- 담당
- 에이전트 구성·실행 검증
- 목적
- 영업 담당자가 미팅 준비와 기록에 쓰는 반복 작업을 에이전트가 근거와 함께 처리하게 하는 것
- 대상
- 영업 담당자
- 사용 기술
- LLM 도구 호출 · SQL · RAG
구현 기능과 기술 선택
- 미팅 준비와 조건 대응 코칭
- 내부 근거와 공개 자료를 구분해 표기하는 초안 작성
- 사용자 승인 후 활동 기록 저장
- 오케스트레이터가 분류·준비·코칭·초안·기록·검증 에이전트에 위임하는 구조 구성, 에이전트별 도구 범위(SQL 조회·문서 검색·외부 API·쓰기) 분리
- 자유 텍스트 필터 대신 대상 ID에서 SQL 비교 기준을 도출하는 도구 입력 설계, 사용자 승인 뒤에만 실행되는 쓰기 도구
- 역할별 에이전트 분리
- 하나의 에이전트에 조회와 쓰기 도구를 모두 주면 조회 요청에서도 쓰기 도구가 호출될 수 있어, 역할별로 도구 범위를 나눴습니다.
- 승인 후 쓰기
- 에이전트의 응답만으로는 실제 저장 여부를 알 수 없어, 저장할 내용을 먼저 보여 주고 승인 뒤 실행하며 결과를 DB 행 수로 확인합니다.
트러블슈팅
에이전트별 도구 범위와 승인 후 쓰기
문제 상황
영업 담당자의 미팅 준비부터 활동 기록까지 처리하는 업무 에이전트를 팀으로 만들었습니다. 하나의 에이전트에 조회와 쓰기 도구를 모두 주면 단순 조회 요청에서도 쓰기 도구가 호출될 수 있었고, '저장했다'는 답만으로는 실제 저장 여부를 알 수 없었습니다.
해결 과정
프롬프트로 쓰기를 자제시키면 결국 모델의 판단에 기대야 했습니다. 그래서 오케스트레이터가 분류·준비·코칭·초안·기록·검증 6개 역할 에이전트에 위임하고, 역할마다 쓸 수 있는 도구 자체를 나눴습니다. 유사 사례 비교는 자유 텍스트 필터 대신 대상 ID에서 SQL 조건을 도출하게 했고, 기록 도구는 저장할 내용을 먼저 보여 주고 사용자가 승인해야 실행됩니다. 단계가 하나 늘어나는 대신 사람이 확인한 내용만 저장됩니다.
결과
조회·초안·저장 경로가 분리됐고, 답변에는 내부 근거와 공개 자료가 구분돼 표시됩니다. 저장 여부는 DB 행 수로 판정합니다.
멀티턴 상태 유실 분석과 상태 설계
문제 상황
후보 목록에서 번호로 대상을 선택하면 다음 턴이 그 번호를 이름 검색어로 처리했습니다. 지시어와 되묻는 질문의 맥락도 이어지지 않았고, 프롬프트 형식에 따라 결과가 달라졌습니다.
해결 과정
원인을 상태·라우팅·검증 구조로 분류했습니다. 선택 후보, 대상 ID, 진행 단계, 미응답 질문을 프롬프트가 아닌 세션 상태로 저장하고, 재시도 횟수를 제한하며, 해결되지 않으면 사용자에게 넘기는 경로를 설계했습니다.
결과
승인 단계가 잘못된 대상에 대한 저장을 차단해 데이터 오염은 발생하지 않았습니다. 분석 결과는 포스트모템과 상태 설계 문서로 정리했습니다.
결과와 성과
- 쓰기 경로 검증: 거절 시 0건, 승인 시 1건 증가를 대상 테이블의 행 수로 확인
- 멀티턴에서 선택 대상이 유실되는 원인을 상태·라우팅·검증 구조로 분류, 세션 상태 설계와 포스트모템 문서화
회고
- 배운 점
- 대화 상태를 프롬프트에 기대지 않고 세션 상태로 명시해야 한다는 점을 배웠습니다. 승인 단계가 잘못된 대상에 대한 저장을 막아 준 것도 확인했습니다.
- 아쉬운 점
- 멀티턴 상태 유실은 분석과 설계까지만 진행했고, 프롬프트 형식에 따라 결과가 달라지는 문제가 남아 있습니다.
- 보완 계획
- 선택 후보·대상 ID·진행 단계를 세션 상태로 저장하고 재시도 횟수를 제한하는 설계를 구현에 반영하는 것이 다음 단계입니다.