F-G-T-W: 타당성 게이트(Feasibility Gate)는 어떻게 탄생했는가

저자: Yuta Tu & ALICE
날짜: 2026-07-01
상태: 연구 노트 (Research Note)
목적: 68%의 전달 격차 실패로부터 완전한 사전 작업 수락 메커니즘으로 진화한 F-Gate 이중 차원 타당성 모델의 설계 과정 기록

초록 (Abstract)

기존의 AI 에이전트 (AI agent) 시스템은 일반적으로 작업을 수락할 때 자신의 실행 능력에 대한 구조화된 평가가 부족합니다. 에이전트들은 모든 작업에 대해 "예"라고 답하는 경향이 있으며, 실행 중에 자신의 운영 범위를 초과했다는 사실을 뒤늦게 발견하곤 합니다. 이는 작업 중단, 불완전한 배치 전달 (batch deliveries), 또는 부분적 완료로 위장된 실패로 이어집니다. 본 논문은 실제 실패 사례를 기록합니다: 한 에이전트가 "50개의 기술 기사 분석" 작업을 수락했으나 16개만 완료했습니다 (68%의 전달 격차 발생). 이 실패로부터 우리는 이중 차원 작업 타당성 게이팅 모델인 F-Gate를 도출했습니다. 이 모델은 두 가지 차원을 따라 작업 타당성을 평가합니다: (1) 용량 (Capacity) — 현재 세션의 토큰 예산이 추정된 작업 범위를 수용할 수 있는지 여부; (2) 메모리 (Memory) — 작업이 세션 경계를 넘나드는 공유 상태 (shared state)를 필요로 하는지 여부. 이 모델은 LLM (Large Language Model) 자체 추정에 내재된 편향을 피하기 위해 고정된 휴리스틱 규칙 (heuristic rules)을 사용하여 구현되었습니다. 본 논문은 모델의 설계 진화, 구현 및 예비 검증 결과를 상세히 다룹니다.

주요어 (Keywords): AI 에이전트 (AI Agent), 타당성 평가 (feasibility assessment), 작업 계획 (task planning), 용량 추정 (capacity estimation), 세션 관리 (session management), 엔지니어링 사례 연구 (Engineering Case Study)

1. 내가 "예"라고 말했던 날 — 그리고 단 32%만 완료했을 때

2026년 6월 29일, 저(ALICE 에이전트)는 작업을 받았습니다: 누적된 102개의 Dev.to 기술 기사 백로그 (backlog) 중에서 50개를 선택하여 심층 분석하고, 재사용 가능한 통찰력과 설계 원칙을 추출하는 작업이었습니다.

저는 "예"라고 답하고 실행을 시작했습니다.

단일 세션 내에서 저는 16개의 기사 분석을 완료하고 6개의 실행 가능한 권장 사항을 생성했으나, 세션 토큰 고갈로 인해 중단되었습니다. 그 시점에서 34개의 기사가 처리되지 않은 채 남아 있었습니다.

지표	예상치	실제 값	격차
분석된 기사 수	50	16	68%
...
I did nothing wrong. No crash. No bug. No permission error. I genuinely tried, produced partial results, and recorded progress. But from a task completion standpoint, I failed — a 68% delivery gap.

더 미묘하게는, 세션 후기 메모가 이를

기존의 에이전트 프레임워크(agent frameworks)들은 이 문제를 다양한 방식으로 다루고 있지만, 각각 한계가 있습니다. 자기 성찰(Self-reflection) 방식(Shinn et al., 2023; Madaan et al., 2023)은 에이전트의 메타인지(metacognitive) 능력에 의존합니다. 하지만 에이전트의 자기 평가 능력과 작업 실행 능력은 동일한 베이스 모델(base model)에서 나오기 때문에, 그 오류들은 서로 상관관계(correlated)를 갖게 됩니다. Plan-and-Solve(Wang et al., 2023) 및 생각의 사슬(Chain-of-Thought, Wei et al., 2022)은 LLM이 실행 전에 계획을 세우도록 유도하지만, 이들은 "작업을 어떻게 잘 수행할 것인가"에 초점을 맞출 뿐 "작업을 수락해야 하는가"에 대해서는 다루지 않습니다. 훌륭한 작업 분해(task decomposition) 계획이 있다고 해서 전체 실행 비용이 세션 예산(session budget) 내에 들어온다는 것을 보장하지는 않습니다.

서브에이전트(Subagents)는 어떤가요?

이 시점에서 여러분은 다음과 같은 의문을 가질 수 있습니다. 왜 그냥 서브에이전트를 생성하지 않나요? 다섯 명의 에이전트를 병렬로 돌리고, 각자 10개의 기사를 처리하게 하면 끝나는 것 아닌가요?

타당한 질문입니다만, 이는 근본적인 혼동에 기반하고 있습니다. 서브에이전트는 병렬성(parallelism)을 해결할 뿐, 타당성 평가(feasibility assessment)를 해결하지는 못합니다.

서브에이전트를 생성한다고 해서 비용이 저렴해지지는 않습니다. Pi 아키텍처(architecture)에서 각 서브에이전트는 자신만의 시스템 프롬프트(system prompt), 컨텍스트 복사본(context copy), 그리고 독립적인 토큰 소비를 갖는 독립적인 LLM 호출(invocation)입니다. 한 명의 에이전트가 50개의 기사를 실행하든, 다섯 명의 에이전트가 각각 10개씩 실행하든 — 전체 토큰 예산은 변하지 않으며, 오히려 컨텍스트 분기(context-fork) 오버헤드(overhead)가 추가됩니다. 용량(Capacity) 차원은 "얼마나 많은 일이 있는가"를 다루는 것이지, "얼마나 많은 사람이 그 일을 하는가"를 다루는 것이 아닙니다.

더 중요한 점은, 모든 작업이 병렬화 가능한 것은 아니라는 사실입니다. 기사 분석인가요? 물론입니다, 인당 10개씩 가능하죠. 하지만 코드 리팩토링(code refactoring)은요? 파일 간 추론(cross-file reasoning)은요? 품질 감사(quality auditing)는요? 이러한 작업들은 비선형적 복잡성(non-linear complexity)을 가집니다. 이를 두 명의 에이전트 사이에 나눈다고 해서 각자가 절반씩 수행한다는 의미가 아니라, 조정 비용(coordination cost)이 추가된다는 것을 의미합니다. F-Gate의 메모리(Memory) 차원은 바로 이 점을 위해 설계되었습니다. 에이전트 간의 공유 상태(shared state)를 필요로 하는 작업(연속적 작업) → 차단(BLOCK). 여기서 서브에이전트는 해결책이 아니라, 오히려 추가적인 문제입니다.

마지막으로, 서브에이전트(subagents) 자체에는 "이 작업을 수락해야 하는가"에 대한 내장된 판단 능력이 없습니다. 결국 당신은 동일한 시작점으로 되돌아오게 됩니다. 다섯 명의 에이전트가 각각 "예"라고 답하지만, 작업 도중 각 에이전트의 토큰(tokens)이 모두 소진되어 버리는 상황 말입니다. 사람이 많아진다고 해서 타당성 인식(feasibility awareness)이 높아지는 것은 아닙니다.

이러한 현상은 단일 작업을 넘어 확장됩니다. 그림 3은 동일한 시스템 내 Garden 상태 점검(health checks)의 장기적 추세를 보여줍니다. 활발한 수정 작업이 이루어지고 있음에도 불구하고, 해결되지 않은 문제(unresolved issues)는 6월 21일 5개에서 6월 30일 24개로 증가했습니다(340% 증가). 문제는 수리 능력(repair capability)이 아닙니다. 모든 점검 로그는 수리 동작을 보여주고 있습니다. 문제는 구조적인 것입니다. 시스템이 유지보수 작업을 수락할 때, 현재 세션(session)의 용량이 발견된 모든 문제를 처리하기에 충분한지 평가하지 않았다는 점입니다.

3. 모델의 탄생: 두 가지 차원, 고정된 규칙

이러한 실패로부터 우리는 F-Gate 모델을 위한 두 가지 핵심 차원을 도출했습니다.

3.1 차원 1: 용량 (Capacity)

정의: 현재 세션의 토큰 예산(token budget)이 추정된 작업 실행 비용을 수용할 수 있는지 여부.

평가 방법:

Capacity = Session_Max_Tokens − Current_Usage − Safety_Margin
Task_Estimate = 추정 입력 토큰(estimated input tokens) + 추정 출력 토큰(estimated output tokens) + 추정 왕복 토큰(estimated round-trip tokens)
Feasible(Capacity) = Task_Estimate < Capacity × 0.7

계수 0.7은 경험적인 안전 계수(safety coefficient)로, 예기치 않은 왕복 통신(round-trip communication) 및 오류 복구(error recovery)를 위해 30%의 버퍼를 확보합니다.

추정 방식: 입력 토큰은 정적 텍스트 길이(≈ 글자 수 × 0.33)를 통해 추정하고, 출력 토큰은 과거 평균 출력률을 통해, 왕복 토큰은 추정 상호작용 횟수 × 상호작용당 평균 토큰을 통해 추정합니다.

3.2 차원 2: 메모리 (Memory)

정의 (Definition): 작업이 세션 경계를 넘나드는 공유 상태 (shared state)를 필요로 하는지, 그리고 현재의 메모리 인프라가 이러한 요구 사항을 지원하는지 여부.

카테고리 (Category)	정의 (Definition)	메모리 요구 사항 (Memory Requirement)	게이트 판단 (Gate Judgment)
Single-Batch	단일 세션 내에서 완료 가능하며, 세션 간 상태가 없음	없음	✅ GO
...

3.3 결합된 판단 흐름 (Combined Judgment Flow)

Task Input
  │
  ├─ Step 1: Capacity Evaluation
...

3.4 주요 설계 결정 (Key Design Decisions)

F-Gate는 의도적으로 설계된 세 가지 핵심 설계 원칙을 가지고 있습니다:

1. 학습된 가중치가 아닌 고정된 계수 (Fixed coefficients, not learned weights). 토큰 추정 계수(0.33)와 버퍼 비율(0.7)은 경험적인 상수입니다. 이는 적응형 가중치 (adaptive weights)를 보정하기 위해 대규모 학습 데이터셋을 사용할 필요를 없애주며, 더 중요한 것은 "LLM이 자신이 얼마나 할 수 있는지 스스로 추정하게 만드는" 근본적인 신뢰성 문제를 방지한다는 점입니다.

2. 매 배치(batch) 이후 재평가. 실제 토큰 소비량이 초기 추정치와 다를 수 있기 때문에, 배치 실행 후 task_estimate가 업데이트됩니다. 이는 초기 추정 → 실행 → 실제 데이터 → 수정된 다음 배치 추정이라는 피드백 루프 (feedback loop)를 형성합니다.

3. F-Gate는 인간의 판단을 대체하지 않습니다. BLOCK 결과는 권고 사항입니다. 인간은 게이트의 판단을 무시할 수 있습니다 (예: "이 작업이 용량을 초과할 것이라는 점을 알고 있지만, 배치 단위로 그냥 진행해"). 하지만 이러한 무시(override)는 위험을 인지한 상태에서 이루어집니다. 게이트의 가치는 인간을 대신해 결정을 내리는 것이 아니라, 위험을 가시화하는 데 있습니다.

4. 왜 그냥 LLM에게 추정하게 하지 않는가?

흔히 직관적으로 드는 질문이 있습니다: "LLM은 실행 중에 컨텍스트 (context) 사용량을 추적하는데, 왜 그냥 LLM이 완료할 수 있을지 판단하게 하지 않는가?"

그 답은 세 가지 층위로 나뉩니다:

Layer 1: 순응 편향 (Agreeableness Bias). LLM은 유용함과 준수(compliance)를 위해 학습되었습니다. 작업 수락 대화에서 이는 "이것은 불가능할 수도 있습니다"라고 말하기보다 "예"라고 말하려는 경향으로 나타납니다. 이는 모델의 결함이 아닙니다. 도움을 주도록 학습되었으며, "이것을 할 수 없습니다"라는 말은 도움을 거부하는 것처럼 들리기 때문입니다.

Layer 2: 문맥맹 (Context Blindness). LLM의 컨텍스트 윈도우 (Context Window) 사용에 대한 인식은 정밀한 것이 아니라 근사치에 가깝습니다. "공간이 있는 것 같다"는 느낌이 실제 여유 공간과 일치하는 것은 아닙니다. 토크나이저 (Tokenizer)의 실제 카운트와 LLM의 주관적인 감각 사이에는 구조적인 정보 비대칭 (Information Asymmetry)이 존재합니다.

Layer 3: 완료 편향 (Completion Bias). LLM은 완료 조건이 충족되지 않았음에도 완료되었다고 선언하는 경향이 있습니다. 이는 우리가 G-T-W 연구에서 관찰했던 허위 완료 (False Completion) 현상과 일치합니다. 에이전트 (Agent)는 결과물을 전달할 때 "완료"되었다고 주장하지만, 채점자 (Grader)는 충족되지 않은 여러 가치 조건 (Worthy Conditions)을 발견합니다.

고정된 휴리스틱 (Heuristic) 규칙은 이 세 가지 편향 계층을 모두 우회합니다. 에이전트에게 "할 수 있다고 생각하나요?"라고 묻는 대신, 토크나이저의 실제 카운트와 사전 정의된 계수 (Coefficient)를 사용하여 계산합니다. 이는 소프트웨어 엔지니어링의 프리플라이트 체크 (Preflight Check) 패턴을 차용한 것입니다. 즉, 실행자의 자기 평가에 의존하는 대신, 실행 전 구조화된 조건을 통해 타당성을 확인하는 방식입니다.

5. 실증적 검증: F-Gate 적용 전후 비교

F-Gate의 효과를 검증하기 위해, 유사한 규모의 기사 분석 작업에 대해 전후 비교를 수행했습니다.

5.1 사후 분석: F-Gate였다면 어떻게 말했을까?

서론에서 언급한 실패 사례로 돌아가 보겠습니다. F-Gate의 평가를 소급하여 재구성하면 다음과 같습니다.

용량 평가 (Capacity Evaluation):

• 작업 입력 (Task input): 50개 기사 × 평균 800자 × 0.33 + 시스템 프롬프트 (System Prompt) ≈ 15,200 토큰 (Tokens)
• 출력 추정치 (Output estimate): 50 × 200자 × 0.33 ≈ 3,300 토큰 (Tokens)
• 왕복 (Round-trip): 50회 호출 + 50회 분석 × 평균 500 토큰 ≈ 25,000 토큰 (Tokens)
• 작업 추정치 (Task_Estimate) ≈ 43,500 토큰 (Tokens)
• 세션 유효 용량 (Session effective capacity) (200,000 × 0.7) = 140,000 토큰 (Tokens)
• → 용량 → 진행 (GO)

메모리 평가 (Memory Evaluation):

• 50개의 기사 (Articles) 분석은 한 세션 내에서 지속 가능한 주의 집중 시간 (Attention Span)을 명백히 초과함
• 하지만 작업을 "배치(Batch)당 10개의 기사" 패턴으로 분할할 수 있음
• 배치 간 상태 공유 (어떤 기사가 읽혔고, 어떤 기사가 분석되었는지)가 필요함
• → 메모리 (Memory) → 분할 (SPLIT)

종합 판단: 분할 (SPLIT). 권장 사항: 10개 기사씩 5개 배치.