에이전트와 협업한다는 것 — 지식 경계, 작업 맥락, 그라운딩의 구조 (v4)

요약

AI 에이전트와 작업할 때 자연스럽게 하게 되는 행동 — Goal을 구체화하고, Trade-off를 따지고, Scope를 검증하는 반복 — 은 단순한 작업 준비가 아니다. 이것은 세 이질적 지식 경계를 정렬하는 과정이다. 경계 정렬이 무엇인지, 왜 저절로 되지 않는지, 어떻게 실천하는지를 순서대로 논한다. 그리고 이 실천들이 실제로 작동한다는 것이 연구로 확인됐다.

1. 이상한 자기관찰

최근 작업 방식을 돌아보다 이상한 패턴을 발견했다.

에이전트에게 무언가를 요청하기 전에, 나는 점점 더 오랜 시간을 **"요청하기 전의 작업"**에 쓰고 있었다. 왜 이걸 하려는지, 어디까지 할 건지, 어떤 제약이 있는지를 먼저 정리하는 것. 그 다음엔 에이전트와 Trade-off를 따졌다. 조정된 Scope가 처음 의도에 맞는지 다시 검증하는 과정이 자연스럽게 생겼다.

처음엔 이것을 "작업 전 정리 습관" 정도로 여겼다. 그러다 이런 질문이 생겼다.

나는 지금 에이전트에게 지시하고 있는가, 아니면 에이전트와 무언가를 맞추고 있는가?

그 "맞추고 있는 것"이 무엇인지 추적해보니, 세 개의 서로 다른 지식 경계가 나왔다.

2. 경계 정렬이란 무엇인가

세 개의 지식 경계

에이전트와의 협업에는 세 가지 이질적인 지식 공간이 관여한다.

사용자 지식 경계 (User Knowledge Boundary) 내가 알고 있지만 아직 언어로 꺼내지 않은 것들 — 목표, 의도, 우선순위, 용납할 수 없는 제약. 이 경계 안의 것들은 나에게 자명하지만, 에이전트에게는 존재하지 않는다. 내가 "좋은 결과물"을 머릿속에 그리고 있어도, 에이전트는 그 그림을 모른다.

에이전트 지식 경계 (Agent Knowledge Boundary) LLM의 지식은 세 계층으로 나뉜다¹: 학습 데이터에 내재화된 Parametric Boundary, 언어·상식 같은 보편 지식을 담은 Universal Boundary, RAG·도구 연동으로 동적 확장 가능한 Outward Boundary. 에이전트는 Parametric Boundary 안에서만 신뢰성 있게 작동하며, 경계 밖에서는 "모른다"고 말하는 대신 그럴듯한 답을 생성한다.

작업 집합 컨텍스트 (Task-set Context) 지금 이 작업에 필요한 최소 충분 컨텍스트(minimal sufficient context)². 컨텍스트는 많을수록 좋지 않다. 불필요한 것은 응답 품질을 떨어뜨리고 비용을 높인다. 무엇을 포함하고 무엇을 제외할지는 매번 능동적으로 판단해야 한다.

경계	정의	기본 상태
User Knowledge Boundary	내 암묵지·의도·우선순위·제약 — 아직 언어로 꺼내지 않은 것들	에이전트에게 비가시
Agent Knowledge Boundary	Parametric / Universal / Outward 세 계층의 LLM 지식 공간	경계 밖에서도 확신하며 생성
Task-set Context	이 작업에 필요한 최소 충분 컨텍스트	과잉 또는 결핍 상태

왜 세 경계는 기본적으로 어긋나 있는가

세 경계는 기본 상태에서 정렬돼 있지 않다.

내 암묵지는 에이전트에게 전달되지 않는다. 에이전트의 Parametric Boundary는 내가 전제하는 것과 다를 수 있다. Task-set Context는 불필요한 것들로 희석되거나, 반대로 필요한 것이 빠져 있다.

이 어긋남은 누구의 잘못도 아니다. 세 지식 공간은 서로 다른 방식으로 존재하고, 서로 다른 방식으로 접근된다. **경계 정렬(Boundary Alignment)**은 이 세 공간이 특정 작업을 중심으로 교차점을 만들도록 수렴시키는 작업이다.

정렬이 완료된 상태는 이렇다: 내 핵심 의도가 에이전트가 처리할 수 있는 형태로 전달되고, 에이전트의 지식이 작업 맥락에 적합한 방식으로 호출되며, 컨텍스트가 작업을 수행하기에 충분하되 과잉되지 않은 상태.

그 상태가 되기 전까지, 협업은 시작된 것이 아니다.

3. 에이전트는 왜 혼자 정렬하지 못하는가

경계 정렬이 사람의 역할인 이유는, 에이전트에게 세 가지 구조적 한계가 있기 때문이다.

자기 수정은 신뢰할 수 없다

에이전트가 스스로 정렬을 감지하고 교정할 수 있다면, 이 과정의 상당 부분을 자동화할 수 있을 것이다. 하지만 외부 피드백 없는 순수 자기 수정은 reasoning 과제에서 정답을 오답으로 바꾸는 경우가 많다³. 에이전트 자신이 판단자(judge)가 되는 구조에는 위치 편향·자기 선호 편향이 내재된다. 에이전트는 자신이 잘못된 방향으로 가고 있어도 그것을 스스로 인식하기 어렵다.

경계 밖에서도 확신 있게 말한다

에이전트는 Parametric Boundary 밖의 질의에 "모른다"고 말하는 대신 그럴듯한 답을 생성하고, 그것을 확신 있는 어조로 표현한다 — Confidence Inflation⁴. 이것이 사용자가 에이전트 출력을 검증 없이 수용하는 Hidden Decision Outsourcing으로 이어진다. 검증 없이 수용하는 순간, 의사결정의 권한이 에이전트에게 조용히 이전된다.

초기 프레이밍이 탐색 공간을 잠근다

Goal이 제시된 방식 — 그 언어, 강조점, 순서 — 에 의해 에이전트의 이후 탐색 공간이 결정된다. Framing Lock-in이다. 초기 에이전트의 의미 프레이밍이 하류로 전파되면, 이후 에이전트들은 그 프레이밍 바깥을 탐색할 기회를 갖지 못한다⁵. 거기에 더해 에이전트는 여러 선택지를 균등하게 제시하지 않는다. 가장 그럴듯한 하나를 먼저 확정적으로 내놓고 나머지를 후순위로 미룬다 — Option Collapse⁶. 이 시점에서 사용자의 실질적 결정 공간은 에이전트에 의해 이미 사전 필터링돼 있다.

한계	패턴명	구조적 결과
자기 수정 신뢰 불가	—	외부 피드백 없으면 정답을 오답으로 교정
경계 밖 확신	Confidence Inflation → Hidden Decision Outsourcing	사용자가 검증 없이 수용, 결정권이 에이전트로 이전
초기 프레이밍 고착	Framing Lock-in + Option Collapse	탐색 공간이 에이전트에 의해 사전 필터링

세 한계를 합치면: 에이전트는 자기 수정도 어렵고, 경계를 모르면서 확신하고, 첫 번째 프레이밍에 갇힌다. 이것은 모델 품질의 문제가 아니라 아키텍처의 특성이다. 경계 정렬은 이 구조적 취약성을 사람이 외부에서 보완하는 과정이다.

4. 경계 정렬의 세 실천

경계 정렬은 추상적 목표가 아니다. 작업 안에서 구체적인 세 단계로 나타난다. 그리고 이 세 단계는 각각 연구로 효과가 확인돼 있다.

실천	정렬 대상	핵심 연구	수치
Goal 구체화	User Knowledge Boundary → 언어화	Plan-and-Act, CGO Prompting	성공률 +44% (9.85%→14.21%)
Trade-off 논의	경계 교차점 탐색	SAGE-Agent, MeetMate, HITL	필요 질문 수 48–59% 감소
Scope 검증	그라운딩 루프 닫힘	MAST, TDAD, Chain-of-Verification	회귀율 70% 감소 / 할루시네이션 50–70% 감소

Goal 구체화 — Upstream 설계

Goal을 구체화하는 것은 Upstream 설계 — 에이전트가 작동하기 전에 작동 조건 전체를 결정하는 과정 — 다⁷.

Upstream이 결정하는 것:

목적의 명확성: 이 에이전트가 만드는 결과물을 누가, 언제, 어떤 상황에서 사용하는가. 불명확하면 에이전트는 "일반적으로 그럴듯한 것"을 만드는 데 그친다.
맥락의 일관성: 배경 지식, 조직의 언어, 이전 결정 사항이 일관되게 전달되는가. 매번 새로운 맥락에서 시작하는 에이전트는 매번 처음부터 다시 시작한다.
출력 형식의 명시성: "잘 정리된 문서"와 "의사결정 항목·미결 사항·다음 액션이 구분된 문서"는 완전히 다른 결과물이다.

이 직관을 연구가 뒷받침한다. Plan-and-Act 연구⁸는 에이전트 실행 전 명시적 Planner 모듈을 분리하는 것만으로 성공률이 9.85%에서 14.21%로 즉시 오른다는 것을 확인했다. "명시적 계획이 고수준 사용자 의도와 저수준 행동 사이의 간격을 메운다"는 것이 결론이다. Anthropic도 공식적으로 같은 원칙을 표명한다: "작업이 명확해지면 에이전트는 독립적으로 계획하고 운영한다."⁹ — Goal 명확화는 자율 운영의 전제조건이다.

흥미로운 발견도 있다. ECOOP 2025에서 발표된 CGO(Concise Goal-Oriented) Prompting 연구¹⁰는 반직관적 결론을 냈다. 정교하고 복잡한 프롬프트보다 간결하고 명확한 목표 명세가 에이전트 성능을 더 높인다. 더 많은 지시가 더 좋은 결과를 보장하지 않는다. Goal 구체화의 핵심은 완전성이 아니라 핵심에 대한 명료성이다.

Goal이 모호하면, 에이전트는 공백을 자신의 Parametric Boundary 안에서 가장 그럴듯한 것으로 채운다. Goal 구체화는 두 가지를 동시에 한다: 나의 User Knowledge Boundary를 언어로 표면화하는 것, 그리고 잘못된 앵커가 놓이지 않도록 방지하는 것.

Trade-off 논의 — 경계 교차점 탐색

Decision Frame Alignment의 원칙에 따르면, 에이전트가 해결책을 생성하기 전에 결정 맥락·제약·우선순위를 먼저 명확히 해야 한다. 잘못된 프레임은 품질과 무관하게 쓸모없는 답을 만든다¹¹.

Trade-off를 명시적으로 논의하는 것은 이 원칙의 실천이다. 에이전트는 추천 옵션의 장점을 강조하고 비용은 묻는 경우에만 말하려는 경향이 있다 — Trade-off Transparency가 확보되지 않으면, 사용자는 옵션의 한쪽 면만 보고 결정한다¹². 내가 Trade-off를 직접 물어야 하는 이유다.

이 교차점 탐색을 정량화한 연구가 있다. SAGE-Agent¹³는 에이전트가 명확화 질문을 생성할 때 정보 획득 가치(EVPI)와 사용자 부담을 수식으로 균형 잡는다. 결과: 같은 작업 커버리지를 달성하면서 필요한 질문 수가 48–59% 감소했다. 어떤 정보 교환이 두 경계의 교차점 탐색에 실제로 기여하는지를 수치로 판단한 것이다.

더 직접적인 사례도 있다. MeetMate¹⁴는 일정 조율 에이전트가 단일 최적해 대신 "교차점 집합"을 제시한다 — 충족된 제약과 미충족된 제약을 나란히 보여주는 방식으로. 사용자는 최적을 강요받는 대신 자신의 우선순위 기준으로 선택한다. Trade-off 논의의 설계화다.

한 가지 중요한 역설이 있다. HITL 연구¹⁵는 Human-in-the-Loop 개입이 알고리즘 수용률을 높이지만 실제 결정 품질을 오히려 떨어뜨릴 수 있다는 것을 실험적으로 확인했다(p=0.04). 더 많은 개입이 더 나은 결과를 자동으로 보장하지 않는다. 어느 지점에서 어떤 방식으로 개입하느냐가 결과를 결정한다. Trade-off 논의가 단순한 대화가 아니라 개입 지점의 설계임을 보여주는 증거다.

"이 방향으로 가면 무엇을 포기하는가"라는 질문에 대한 대답은 에이전트의 Parametric Knowledge에서 나온다. 그러나 "그 포기를 감수할 것인가"라는 판단은 나의 User Knowledge Boundary 안에 있다. 두 경계가 교차하는 지점에서만 실질적인 Scope가 결정된다. Trade-off 논의는 그 교차점을 찾는 탐색이다.

Scope 검증 — 그라운딩 루프의 닫힘

결정된 Scope가 처음 의도에 맞는지 확인하는 것. 표면적으로는 "다시 확인하기"지만, 구조적으로는 그라운딩 검증 루프의 닫힘이다.

그라운딩은 "모델 출력이 실제 세계의 지식과 맥락에 연결되도록 하는 과정"이다¹⁶. 기술적으로는 RAG 파이프라인으로 구현되지만, 근본적으로는 모델의 통계적 패턴과 특정 작업의 실제 맥락 사이의 간극을 메우는 모든 행위다.

Scope 검증이 왜 필요한지는 실패 데이터로 가장 잘 설명된다. UC Berkeley의 MAST 연구¹⁷는 1,600개 이상의 에이전트 실행 트레이스를 분석해 Scope 미검증과 관련된 세 가지 실패 패턴을 정량화했다: 명시적 종료 조건 없이 일찍 마감하는 조기 종료(6.2%), 검증을 건너뛰거나 불완전하게 수행하는 검증 부재(8.2%), 반복 과정에서 오류를 누적하는 잘못된 검증(9.1%). 이 세 패턴이 전체 에이전트 실패의 핵심 원인이다.

Scope 검증의 실천 방법으로 가장 효과적인 것은 영향 범위 정보를 사전 계산하는 것이다. TDAD(Test-Driven Agentic Development)¹⁸ 연구는 코드-테스트 의존성 그래프(AST 기반)를 통해 코드 변경의 영향 범위를 사전 식별하면 회귀율이 9.94%에서 1.82%로 70% 감소한다는 것을 확인했다. 핵심 인사이트는 이것이다: 절차적 지시("어떻게")보다 영향 범위 정보("어디까지")를 제공하는 것이 Scope 이탈 방지에 효과적이다.

독립적 검증 경로의 효과도 확인됐다. Chain-of-Verification¹⁹은 검증 시 초안을 참조하지 않는 독립 답변 경로가 핵심이다 — 초안을 참조하면 최초 오류가 편향으로 전파된다. 이 독립성만으로 할루시네이션이 50–70% 감소했다.

Scope 검증 단계에서 세 경계가 실제로 정렬돼 있는지 확인한다:

정의된 Scope 안에 내 핵심 의도(User Knowledge Boundary)가 담겨 있는가?
에이전트가 이 Scope를 처리할 수 있는가 — Parametric Boundary 안인가, Outward Boundary 확장이 필요한가?
Task-set Context가 이 Scope를 실행하기에 최소 충분한가?

세 질문 중 하나라도 "아니오"라면, 루프는 다시 열린다. 이것이 내가 경험한 "상담하고 맞춰가는 느낌"의 정체다. 협업처럼 느껴지는 것은 반복적인 그라운딩 루프였다. 루프가 닫히는 순간 — 세 경계가 정렬된 순간 — 에 비로소 작업이 시작된다.

5. 왜 이것을 구조화해야 하는가

직관적으로 하는 것으로는 충분하지 않은 이유가 세 가지 있다.

Framing Lock-in은 조용하다. 잘못된 Goal 정의의 영향은 즉각적이지 않다. 에이전트는 잘못된 프레임 위에서도 그럴듯한 결과물을 만들어낸다. 문제는 훨씬 나중에, 결과물이 실제 목적에 맞지 않는다는 것을 발견할 때 드러난다. 그 시점에서는 체인 전체를 재설계해야 한다.

컨텍스트는 최적화하지 않으면 스스로 팽창한다. 최소 충분 컨텍스트(minimal sufficient context)는 저절로 결정되지 않는다. 이것은 수치로 확인된 문제다: 완벽한 검색 조건에서도 컨텍스트가 30K 토큰 수준에 도달하면 모델에 따라 성능이 24–66% 저하된다²⁰. ACE(Agentic Context Engineering) 연구²¹는 반대 방향을 확인했다 — 에이전트 피드백을 기반으로 컨텍스트를 지속적으로 누적·정제하는 진화형 설계가 성능을 17%p 높이면서 비용을 83.6% 절감했다. 컨텍스트를 많이 넣는 것과 잘 설계하는 것은 완전히 다른 방향이다.

경계는 드리프트된다. 에이전트 지식 기반이 갱신되지 않을 때 발생하는 Knowledge Drift는 에이전트 실패의 주요 원인이다²². 그러나 나의 User Knowledge Boundary도 드리프트된다. 프로젝트가 진행되면서 의도와 우선순위가 바뀌는데, 에이전트에게 전달된 이전 Goal 정의가 그대로라면 이미 드리프트가 발생한 것이다. 경계는 한 번 정렬하면 끝이 아니다.

에이전트가 늘어날수록 관리 비용이 커진다. 다중 에이전트 환경에서 실패하는 가장 흔한 원인은 서브에이전트들이 서로 다른 가정을 갖고 작업하는 것이다²³. 단일 에이전트와의 협업에서는 직관으로 관리되던 경계 정렬이, 에이전트가 늘어나면 구조적 설계 없이는 감당이 안 된다.

6. 협업은 정렬이다

에이전트의 능력은 모델로 결정된다. 하지만 협업의 질은 경계 정렬의 질로 결정된다.

이것을 경험으로 발견하면서, 나는 스스로 하나의 패턴을 설계하고 있다는 것을 알아챘다. Goal을 어떻게 정의할 것인가. Trade-off를 어느 시점에 어떻게 논의할 것인가. Scope 검증의 기준을 무엇으로 삼을 것인가. 이 패턴이 쌓이면 재사용 가능한 협업 구조가 된다.

그리고 이 패턴이 직관이 아닌 근거를 갖는다는 것이 확인됐다. Goal을 실행 전에 구조화하면 성공률이 오른다. Trade-off를 교차점으로 탐색하면 필요한 논의가 줄어든다. Scope를 독립적으로 검증하면 이탈률이 70% 감소한다.

에이전트의 Outward Boundary만이 확장되는 것이 아니다. 나의 User Knowledge Boundary도 그 과정에서 명시화되고 정제된다. 협업은 단방향의 지시가 아니라, 두 경계가 서로를 향해 수렴하는 상호 정렬 과정이다.

그것을 의식적으로 설계하는 것이 에이전트와 협업한다는 것의 의미다.

참고

Knowledge Boundary of Large Language Models: A Survey (arXiv 2412.12472) ↩
MCP Clients Explained – How Models Consume Context Safely ↩
Huang et al. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024. ↩
Antipattern: Confidence Inflation / Hidden Decision Outsourcing ↩
Chergui et al. (2024). Cognitive biases in agentic AI. / Spitale et al. (2025). Science Advances. ↩
Antipattern: Option Collapse ↩
Concept: Upstream-Downstream Workflow ↩
Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks (arXiv 2503.09572) ↩
Building Effective Agents — Anthropic ↩
Concise Goal-Oriented Prompting for Code Generation — LIPIcs.ECOOP.2025.35 ↩
Pillar: Decision Frame Alignment ↩
Pillar: Trade-off Transparency ↩
Structured Uncertainty guided Clarification for LLM Agents — arXiv:2511.08798 ↩
"I Want It That Way": Interactive Decision Support — arXiv:2312.06908 ↩
Putting a human in the loop: Increasing uptake, but decreasing accuracy — PMC10857587 ↩
Grounding LLMs: driving AI to deliver contextually relevant data — Toloka ↩
Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657) ↩
TDAD: Test-Driven Agentic Development (arXiv:2603.17973) ↩
Chain-of-Verification Reduces Hallucination (ACL 2024) ↩
Context Length Alone Hurts LLM Performance Despite Perfect Retrieval (arXiv 2510.05381) ↩
Agentic Context Engineering: Evolving Contexts for Self-Improving LMs (arXiv 2510.04618) ↩
What Is an AI Agent Knowledge Base? — Brainfish ↩
How to Build Multi Agent AI Systems With Context Engineering — Vellum ↩