Agent는 왜 아는 것도 놓치는가

PEC · PRODUCT ENGINEERING

Agent는 왜
아는 것도 놓치는가

모델의 본질적 한계와 파생된 한계, 그리고 Harness

BOAZ · 2026.07

02 Agent는 왜 뻔한 조건을 놓칠까

INTRO

조건을 분명히 전달했는데,
결과에서는 빠져 있던 경험

정보가 분명히 Context 안에 있는데도 결과에서 빠지는 현상 —
Agent를 써 본 사람이라면 한 번쯤 겪어 봤을 거예요.

잊은 게 아니라면, 무엇이 문제일까요?

03 오늘 다룰 것

PART 1

본질적 한계

토큰 생성과 Attention

PART 2

파생된 한계

상태 · 계획 · 자기 참조 · 오류 전파

PART 3

Harness

모델 밖에서 해결하기

04 Agent가 실제로 하는 일

보이는 동작

목표 이해

계획 수립

실행

결과 확인

수정

실제 동작

지금까지의 모든 토큰을 본다

다음 토큰의 확률을 계산한다

하나를 선택한다

다시 반복한다

"목표"도 "계획"도 "현재 상태"도 "검증 기준"도
전부 Context 안의 토큰 표현입니다. Attention이 토큰 사이의 연관성을 계산할 뿐이에요.

05 Context는 책상이다

Context는 책상입니다

업무 초반

목표 원본 자료 지시사항

업무가 길어질수록

업무 후반

목표 원본 자료 지시사항 계획 해석 중간 결과 오류 로그 수정안 대화 기록 요약 가정

매번 이 자료 전체에서 "지금 다음 토큰을 만들 때 어떤 정보가 중요한지"를 다시 계산해야 해요.

정보 위치에 따른 활용도

앞 — 잘 활용

중간 — 놓치기 쉬움

뒤 — 잘 활용

Context 안에 있다고 해서 항상 정확히 쓰이는 건 아닙니다 — 특히 중간에 있으면 앞이나 뒤에 있을 때보다 잘 못 써요.

06 왜? Attention은 선택적

Attention은 모델이 동작하기 위한 핵심 계산 공식이에요.

Attention(Q, K, V) = softmax( QK^T / √d_k ) V

Q

지금 내가 무엇을 찾고 있는가

K

Context 속 각 정보는 어떤 특징을 지녔는가

QK^T

지금 필요한 것과 각 정보가 얼마나 관련 있는가

softmax

관련 높은 표현 ★

0.68

표현 B

0.17

표현 C

0.10

표현 D

0.05

softmax 가중치의 합은 1 — 어딘가에 크게 주면, 다른 곳은 반드시 작아져요.

08 Attention 동작 예시

지금 생성 중인 문장 — "혁신적인 기능을 제안하면…"

조건 1 — 높은 Attention

고객은 혁신적인 기능을 원한다

0.85

혁신 · 기능 · 차별성 — 지금 만드는 문장과 관련이 높아요.

조건 2 — 낮은 Attention

개인정보를 외부 서버에 저장하면 안 된다

0.08

지금 문맥과 관련이 낮다고 판단 — 비중이 밀려나요.

모델은 이 조건을 Context 안에 분명히 보유하고 있으면서도,
현재 결과에는 충분히 반영하지 못할 수 있습니다.

09 Attention 특징 정리

아래 두 문장은 의미가 달라요.

정보가 Context 안에 있다

≠

정보가 현재 생성 과정에서
충분한 Attention을 받았다

Agent가 중요한 조건을 놓치는 이유는 반드시 잊어서가 아니에요 — 현재 출력을 만드는 과정에서 다른 정보들과 Attention 경쟁을 벌였고, 충분히 높은 비중을 얻지 못했기 때문입니다.

모델은 전체 조건을 한 번에 완벽히 유지하는 것보다, 현재 문맥에 맞는 자연스러운 출력을 만드는 데 더 강해요.

10 파생된 한계 1 — 상태가 없다

상태는 없고, 토큰만 있습니다

우리가 기대하는 "상태"

현재 5단계 중 3단계다
2단계에서 오류가 있었다
이 숫자는 아직 검증되지 않았다
고객 승인이 필요하다
이 부분은 다시 확인해야 한다

Agent 내부에 실제로 있는 것

구조화된 상태가 아니라, Context 속 문장 하나:

고객이승인하기전에는절대로배포하지않는다

"절대 규칙"조차 다른 토큰들과 똑같은 자격의 토큰일 뿐이에요.

11 조건이 토큰이면 생기는 일

긴 대화는 압축(요약)돼요 — 조건이 토큰이면, 압축과 함께 변합니다.

원래 조건 · 강제 규칙

"고객이 승인하기 전에는 절대로 배포하지 않는다"

압축

절차 안내

"배포 전 고객 확인이 필요하다"

추가 압축

일정 조율 — 강제성 소멸

"고객과 배포 일정을 조율한다"

압축되면서 조건의 강도가 약해져요. 의미는 비슷해 보여도, "절대 금지"는 사라졌습니다.

12 파생된 한계 2 — 계획이 없다

계획도 토큰입니다

1

요구사항 확인

2

데이터 조사

3

초안 작성

4

사실 검증

건너뜀

5

정책 검증

건너뜀

6

최종 승인

3단계 초안이 잘 나옴 → 다음 토큰: "완성된 제안서는 다음과 같습니다."

초안이 잘 나오면 자연스럽게 다음으로 넘어가고 싶은 확률이 높아져요.
그러면 4번과 5번의 검증을 수행하지 않고도 종료할 수 있습니다.

13 모델의 기본 목적

왜 이런 일이 생길까요?

"모든 업무 절차를 반드시 완료하라"

가 아니라

"지금까지의 Context에 이어질 가능성이 높은
다음 토큰을 생성하라"

모델의 기본 목적이 이것이기 때문이에요.

14 본질적 한계 더 자세히 — 토큰 선택

최선의 토큰이 최선의 문장은 아니에요

첫 토큰만 보면

매우

40%

대체로

35%

조건부로

25%

지금 순간의 1등은 "매우"

전체 문장으로 보면

"매우 성공 가능성이 높습니다."

경로 확률: 0.40 × 0.20 × 0.10 × …

"조건부로 실행할 수 있습니다."

경로 확률: 0.25 × 0.80 × 0.75 × …

전체로 보면 "조건부로…"가 더 자연스럽거나 정확할 수 있어요.

현재 순간의 최선과 전체 결과의 최선은 같지 않을 수 있습니다.

15 파생된 한계 3-1 — 자기 참조적 Context

원본 사실

Agent의 해석

Agent가 만든 중간 결과

Context가 길어질수록 뒤섞임

모델에게는 결국 전부 같은 Context

원본 사실

해석

추론

가정

"새로운 사실"처럼 재사용

자기가 만든 해석을 자기가 다시 근거로 삼는, 자기 참조적 Context가 됩니다.

16 파생된 한계 3-2 — 오류가 전파된다

"고객 예산은 10억 원이다"

현실 — 실제 예산은 1억 원

이후 Context에 전파 — 다음 단계는 사실처럼 참고

10억 규모
아키텍처 설계

10명
운영팀 제안

대규모 인프라
비용 계산

고가 솔루션
추천

실행 일정
확대

전부 앞뒤가 맞아 보이지만 — 결과가 내부적으로 일관적이라는 것이 정확하다는 의미는 아닙니다.

17 왜 스스로 오류를 못 잡나 — 이유 1

생성자와 검토자가 같은 표현을 공유해요

작성 단계

"고객 예산은 10억 원이다"

같은 Context

검토 단계

"10억 원의 예산 기준으로 구성이 적절하다"

✗ 원본 문서에서 예산을 다시 확인하지 않았다

○ 앞서 만들어진 결과를 다시 읽고 논리적 일관성만 검사했다

즉, 사실 검증이 아니라 자기 일관성 검증을 수행한 거예요.

18 왜 스스로 오류를 못 잡나 — 이유 2

무엇이 틀렸는지 알려주는 외부 신호가 없어요

코딩 — 외부 신호가 강함

컴파일 에러
테스트 실패
런타임 예외

전략 보고서 — 외부 신호가 약함

정말 시장성이 있는가?
고객이 설득될 것인가?
중요한 위험을 빠뜨리지 않았는가?

그래서 "검토해라"라고 하면 사실 여부보다 문장이 자연스러운가 · 논리가 연결되는가 · 형식이 맞는가 · 모순이 눈에 띄는가를 점검하기 쉬워요.

그럴듯함을 평가하는 능력과 현실의 정확성을 검증하는 능력은 다릅니다.

19 Harness로 어떻게 해결하는가

모델 밖으로 분리

목표 저장소
상태 저장소
원본 데이터
실행 결과
검증 기준
승인 상태

강제되는 흐름

1

원본 자료 로딩

2

Agent 실행

3

필수 항목 검사

4

사실 출처 확인

5

계산 도구 검증

6

정책 엔진 검사

7

실패 시 원인별 재실행

8

기준 충족 시에만 완료

Agent에게 "검증을 잊지 마"라고 말하는 것과
검증을 통과하지 않으면 다음 단계로 갈 수 없게 만드는 것은 전혀 다릅니다.

20 파생된 한계 정리 — 4가지 불확실성

검증 불확실성

모델 내부에는 현실의 정답을 직접 검증할 방법이 없다

Context 불확실성

필요한 정보가 없거나, 잘못됐거나, 요약 과정에서 손실됐을 수 있다

Attention 불확실성

정보가 있어도 현재 시점에서 충분히 활용되지 않을 수 있다

추론 경로 불확실성

초기 토큰 선택과 중간 판단에 따라 다른 결론을 낼 수 있다

네 가지 모두 "다음 토큰을 생성하라"는 본질에서 파생된 한계예요.

21 구체적 해결책 5가지

1

Context를 작게 나눈다

2

중요한 정보를 구조화한다 (JSON 등)

3

원본과 생성 결과를 분리한다

4

검증을 Attention 밖으로 꺼낸다

5

종료 조건을 외부에서 관리한다

22 Harness의 정의

DEFINITION

Harness란 —

Agent의 Context를 설계하고
Attention이 처리할 범위를 줄이며
상태와 검증을 모델 밖으로 분리하는
시스템

Harness 직접 설계해보기

오늘 정리한 원리를 실제 Agent 업무 흐름에 적용해 봅니다 —
Context 설계 · 검증 게이트 · 종료 조건 관리를 직접 만들어 봐요.

To be continued —

BOAZ · PEC · Product Engineering