핵심 주장 (Main Thesis)
에이전트를 다른 인간처럼 관리하라. AI 신뢰 문제는 새로운 문제가 아니다 — 인간 팀을 효과적으로 관리하는 방식을 그대로 에이전트에 적용하면 된다.
- AI 환각(hallucination) 문제에서 신뢰 문제로 패러다임이 이동했다
- 잘못된 답변이 맞는 답변처럼 보인다 — Claude는 "모르겠습니다"가 아니라 확신에 찬 틀린 답을 낸다
- 해결책은 기술적 최적화가 아니라, 우리가 이미 알고 있는 인간 팀 관리 원칙이다
1. 배경: Agentic GTM의 시대
1.1 Upside.tech 소개
- 포지션: Agentic Go-to-Market(GTM)을 위한 데이터 레이어
- 핵심 기능:
- GTM 데이터를 AI 준비 상태로 만들기 (데이터 파운데이션 + 대시보드)
- 딥 리서치, 멀티터치 어트리뷰션 같은 스케일 불가능했던 작업 자동화
- AI가 비즈니스에 대해 정확하게 알도록 해서 환각 방지
- 데이터를 필요한 모든 곳에 배포
1.2 GTM 팀의 변화
- 역사적으로 GTM 팀은 빌더 밀도가 낮았다 — 마케터, 영업팀은 코딩을 하지 않았음
- 이들에게 도구는 스프레드시트와 PPT가 전부였음
- AI가 이를 바꿨다: Claude는 자전거가 이동성을 민주화한 것처럼 빌딩을 민주화했다
- "저는 위험할 정도만 기술적입니다(technical enough to be dangerous)" — 이 카테고리의 사람들에게 AI는 컴퓨터 사이언스 전공 최우등 인턴을 무한정 공급해주는 것과 같다
1.3 신뢰 문제의 등장
- 비기술 리더들이 이끄는 인턴들이 만들어낸 결과물 = 흥미로운(=위험한) 결과
- 환각 → **신뢰 문제(trust problem)**로 진화
- Claude에게 "매출 보고해줘"라고 하면 → 틀린 답을 맞는 것처럼 내놓는다
- 기술적 최적화나 "마법의 주문 같은 프롬프트"보다 실용적인 접근법이 필요
2. 핵심 원칙: Commander's Intent (지휘관의 의도)
2.1 개념
- 군사 교리에서 나온 개념: 무엇을 할지(WHAT)가 아닌 왜 하는지(WHY)를 전달하라
- 에이전트에게 왜 어떤 작업을 원하는지 알려주면 훨씬 좋은 결과를 낸다
- 인간에게도 동일하게 효과적 — 사람들은 마이크로매니지먼트를 싫어한다
2.2 주의사항
- 에이전트는 다른 인간의 글로 훈련되어 스스로를 마이크로매니지하려 한다
- "스스로를 개선하라"고 하면 → 마이크로매니지먼트 모드 발동
- 해결책: "우리는 WHY에 대해 이야기하고 있다는 걸 기억해"라고 되돌려야 한다
3. 세 가지 실제 사례
3.1 사례 1: 웹사이트 재구축 — 스캐폴딩(Scaffolding)
문제: 전체 웹사이트 재구축 필요
- 이전 회사(600명 규모)에서는 제품 마케터 여러 명 + 디자이너 + 컨설팅 PM + 웹팀 + 2개월 소요
- AI로 "YOLO 모드"(소스 다 줄 테니 웹사이트 만들어봐) → 실패
해결책: 앵커 에셋(Anchor Assets) 체계 구축
- AI가 비즈니스에 대해 알아야 할 것을 문서화
- 핵심 앵커 에셋들:
- 제품 역량 레퍼런스(Product Capabilities Reference)
- 각 기능이 무엇을 하는지
- 다양한 페르소나에게 왜 중요한지
- Claude가 어떻게 이 정보를 찾았는지 인용 추적 (환각 방지)
- 페르소나 정의
- 기타 회사 운영 문서들
- 제품 역량 레퍼런스(Product Capabilities Reference)
원칙: "구조를 먼저 정의하고, 그 다음 Claude를 풀어놓아라. 처음부터 YOLO 하지 마라."
추가 도구:
- Persona Bench: 중요한 페르소나를 구현하는 에이전트 세트 → 온디맨드로 리뷰 요청
- D-SLOOP 스케일: 프롬프트 템플릿 참고
3.2 사례 2: 라이브러리안(The Librarian) — 적시(Just-in-Time) 컨텍스트
문제: 에이전트가 도메인 지식 없이 쿼리를 실행
- 사용자: "Q1 파이프라인이 얼마나 생성됐나요?"
- 에이전트의 기본 해석: "분기 = 1월~3월, 생성일 기준으로 보면 되겠지"
- 실제 정답: 회사의 회계연도는 2월~4월, 파이프라인은 2단계 이상인 딜만 포함
해결책: 라이브러리안 아키텍처
사용자 질문
↓
[에이전트] → 먼저 [라이브러리안] 참조
├─ 회사 문서
├─ 지식 아이템 라이브러리 (도메인 정의)
└─ 과거 실패 쿼리의 스키마
↓
적시(JIT) 메모리 제공
↓
[에이전트] 정확한 쿼리 실행
↓
인용이 포함된 신뢰할 수 있는 답변
핵심 인사이트:
- 에이전트에게 적시(just-in-time) 메모리를 제공
- 에이전트가 틀린 답을 처음 발견하는 것이 아니라, 시작 전에 올바른 컨텍스트를 갖추게 함
- 인용 포함 → 환각 방지 + 검증 가능
- Upside 제품 내부에 구현된 실제 기능
3.3 사례 3: 배심원-판사 워크플로우 (Jury & Judge Workflow)
문제: 멀티터치 어트리뷰션(Multi-Touch Attribution)
- GTM에서 "정답이 없는" 분류 문제의 대표 사례
- 2년 걸려도 해결 못했던 문제 → Claude Opus로 돌파구
배경: 현실 세계의 해결 방식
- 정답이 없는 문제 → 동료 배심원단(jury of peers) 제도
- AI도 동일한 원리 적용
워크플로우:
사용자: "Acme 딜 어트리뷰션 분석해줘"
↓
[에이전트 → 직접 답하지 않음]
↓
[독립 분석가 팀 구성]
분석가 A (독립) 분석가 B (독립) 분석가 C (독립)
↓ ↓ ↓
각자 데이터를 독립적으로 분석
증거 기반 어트리뷰션 의견 도출
↓ ↓ ↓
[컨센서스 판사]
├─ 분석가들의 결과를 "사실"이 아닌 "입력"으로 처리
├─ 각 분석가의 추론 품질 평가
├─ 컨센서스 기반 최종 어트리뷰션 결정
└─ 컨센서스 부족 → 배심원단 확대 (escalate)
↓
최종 결과 + 인용
핵심 인사이트:
- 하나의 에이전트가 혼자 고민하는 것보다 독립적인 여러 연구자 + 종합 판사가 더 낫다
- 인간 세계에서도 동일하게 적용되는 원리
- 판사의 역할: "스스로 리서치하는 것이 아니라, 팀의 독립 연구를 종합하는 것"
4. 보너스: 에이전트 계층 (Agent Tiers)
4.1 핵심 원칙
"바보는 고칠 수 없다" — 중요한 작업에 낮은 지능 모델이나 나쁜 하네스를 사용하지 마라
4.2 사례 연구: Slack MCP 클라이언트
- Slackbot이 MCP 클라이언트 기능 출시 → 기대감
- Upside Librarian을 연결해보니 → "끔찍하게 멍청함"
- 이유: 구독 모델에 끼워 넣은 AI 제품은 마진 때문에 지능형 추론 모델을 쓸 여력이 없음
4.3 Tier 구분
| 계층 | 특징 | 사용 권장 |
|---|---|---|
| Tier 1 (하위) | 기본 채팅, 제한된 기능 | 중요 업무 X |
| Tier 2+ | 강력한 모델, 서브에이전트, 플랜 모드, 전체 MCP 지원, 파일 편집 | 중요 업무 필수 |
Tier 2 요건:
- 강력한 추론 모델
- 서브에이전트 지원
- 플랜 모드(Plan Mode)
- 전체 MCP 지원
- 파일 편집 가능
경고: "팀에 그냥 ChatGPT 웹 인터페이스 쓰고 좋은 결과 기대하지 마라"
5. 전체 프레임워크 요약
신뢰할 수 있는 AI 에이전트 시스템을 위한 4가지 요소:
1. 권한(Permissions) → 무엇을 할 수 있는가
2. 정의(Definitions) → 개념을 어떻게 이해하는가
3. 라이브러리안(Knowledgeable Guide) → 도메인 지식을 어떻게 얻는가
4. 두 번 확인하는 습관 → 배심원-판사 워크플로우
→ 이 네 가지를 하나의 도구(Upside)로 통합
시사점 및 실용적 적용
비기술 조직에게
- 앵커 에셋 먼저: 비즈니스 정의, 페르소나, 제품 역량을 문서화하라
- YOLO 금지: 구조 없이 AI에게 복잡한 작업을 맡기지 마라
- Commander's Intent: WHY를 설명하면 결과가 극적으로 좋아진다
프로덕트 빌더에게
- 라이브러리안 패턴: 에이전트에게 JIT 도메인 컨텍스트를 제공하는 레이어 설계
- 배심원-판사 패턴: 정답이 없는 문제는 독립 에이전트 + 컨센서스 판사 패턴 사용
- 에이전트 계층 선택: 중요한 작업에는 반드시 Tier 2+ 모델 사용
AI 거버넌스
- 환각 문제는 기술이 아니라 시스템 설계로 해결한다
- 인간 조직에서 신뢰를 구축하는 방법(감사, 이중 확인, 전문가 협의)이 AI에도 그대로 적용된다