2부. 에이전트 회사의 기본 부품

6장. 리서치와 컨텍스트 에이전트: 일하기 전에 맥락을 모은다

에이전트 컴퍼니 v0.4.0

사람이 일을 잘하는 이유는 지능만이 아니다.

맥락을 안다.

이 고객이 왜 예민한지, 지난번에 무슨 일이 있었는지, 어떤 약속을 했는지, 누가 의사결정자인지, 가격을 왜 그렇게 정했는지, 어떤 기능이 아직 불안한지 알고 있다.

에이전트가 실패하는 이유도 여기 있다. 답변은 그럴듯한데 맥락이 없다. 고객에게 이미 설명한 내용을 다시 묻고, 세일즈가 약속하지 말아야 할 것을 말하고, 오래된 자료를 근거로 들고, 이슈의 과거를 모른다.

그래서 리서치 에이전트와 컨텍스트 에이전트가 필요하다.

이 에이전트의 일은 실행이 아니다.

일하기 전에 필요한 맥락을 모아주는 것이다.

상황
영업 미팅 전
모아야 할 맥락
회사 정보, 최근 신호, 이전 대화, 비슷한 성공 사례, 예상 반박
상황
고객지원 답변 전
모아야 할 맥락
계정 상태, 로그, 과거 티켓, 계약 조건, 장애 여부
상황
갱신 협상 전
모아야 할 맥락
사용량, 챔피언, ROI, 미해결 이슈, 경쟁사 언급
상황
채용 인터뷰 전
모아야 할 맥락
후보 이력, 포지션 요구사항, 이전 평가, 보상 범위
상황
제품 우선순위 전
모아야 할 맥락
고객 요청 빈도, 매출 영향, 구현 난이도, 리스크

이 맥락이 쌓이면 사람도 좋아진다. CSM은 더 좋은 고객 대화를 하고, AE는 더 날카로운 질문을 하고, PM은 더 나은 우선순위 결정을 한다.

에이전트 컴퍼니의 핵심 자산은 모델이 아니다.

맥락이다.

조금 더 정확히 말하면 context graph다.

Context graph는 회사의 결정이 실제로 어떻게 만들어지는지 보여주는 지도다. 프로세스 문서에는 "할인은 승인 필요"라고 적혀 있다. 하지만 실제 회사에서는 고객 규모, 경쟁 상황, 갱신일, 챔피언의 정치적 위치, 과거 약속, 대표의 한마디, 법무의 우려가 함께 작동한다. agent가 일을 하려면 이 실제 판단 구조를 알아야 한다.

Context graph는 다음 것들을 연결한다.

노드
업무 객체
예시
account, deal, ticket, invoice, candidate, incident
노드
문서
예시
계약서, 정책, 제안서, 회의록, runbook
노드
대화
예시
Slack, email, call transcript, 고객 피드백
노드
결정
예시
승인, 거절, 예외, 보류, escalation
노드
사람
예시
owner, approver, champion, blocker
노드
권한
예시
누가 무엇을 볼 수 있고 실행할 수 있는가

이 그래프가 없으면 agent는 매번 일반 지식으로 일한다.

이 그래프가 있으면 agent는 우리 회사의 방식으로 일한다.

Early Reader Feedback

원고 피드백 남기기

읽다가 헷갈린 곳, 더 듣고 싶은 사례, 동의하기 어려운 문장을 알려주세요. 공개 댓글이 아니라 저자에게만 전달되는 피드백입니다.

본문에서 문장을 드래그한 뒤 누르면 선택 문장이 함께 저장됩니다.

피드백 유형

BiteMark Press는 Cloudflare Web Analytics로 익명 트래픽을 보고, 동의한 경우에만 GA4와 Microsoft Clarity를 켭니다.