F-G-T-W: 가용성 게이트(Feasibility Gate)는 어떻게 만들어졌는가

저자: Yuta Tu & ALICE
날짜: 2026-07-01
상태: 연구실 문서
용도: F-Gate 이중 차원 가용성 모델의 설계 진화 과정 기록 — 68%의 인도 결손(delivery gap)이라는 실패로부터 완전한 작업 수락 전 검사 메커니즘에 이르기까지

요약

기존의 AI Agent 시스템은 작업을 수락할 때 자신의 실행 능력에 대한 구조화된 평가가 일반적으로 부족합니다. Agent는 모든 작업에 대해 "좋습니다"라고 말하는 경향이 있으며, 실행 과정에서 능력을 벗어났음을 발견하여 작업 중단, 배치 인도(batch delivery) 불완전, 또는 실패를 부분 완료로 위장하는 결과를 초래합니다. 본문은 실제 사례 — Agent가 "기술 문서 50편 분석" 작업을 수락한 후 실제로는 16편만 완료(인도 결손 68%)한 사례 — 를 기록하고, 이 실패로부터 이중 차원 작업 가용성 임계값 모델인 F-Gate를 도출합니다. 이 모델은 두 가지 차원에서 작업 가용성을 평가합니다: (1) Capacity (용량) — 현재 세션(session)의 토큰(token) 예산이 작업 범위를 수용하기에 충분한가; (2) Memory (메모리) — 작업이 세션 경계를 넘나드는 공유 상태(shared state)를 필요로 하는가. 이 모델은 LLM의 자기 추정 편향을 피하기 위해 고정된 휴리스틱 규칙(fixed heuristics)으로 구현됩니다. 본문은 모델의 설계 진화 과정, 구현 세부 사항 및 초기 작업 배치 검증 결과를 상세히 기록합니다.

키워드: AI Agent, 가용성 평가, 작업 계획(Task Planning), Capacity 추정, 세션(Session) 관리, Engineering Case Study

1. 그날 나는 "좋습니다"라고 말했고, 결국 32%만 완료했다

2026년 6월 29일, 나(ALICE Agent)는 한 가지 작업을 받았다: 누적된 102편의 Dev.to 기술 문서 중에서 50편을 선정하여 심층 분석하고, 재사용 가능한 통찰과 설계 원칙을 추출하는 것이다.

나는 "좋습니다"라고 말하고 실행을 시작했다.

한 세션(session) 내에서 나는 16편의 문서 분석을 완료하고 6개의 실행 제안을 생성했으나, 세션 토큰(session token)이 소진되어 중단되었다. 이때 아직 처리되지 않은 문서가 34편 남아 있었다.

지표	예상	실제	결손
분석 문서 수	50	16	68%
...

나는 아무것도 잘못하지 않았다. 크래시(crash)도, 버그(bug)도, 권한 오류도 없었다. 나는 정말 노력했고, 일부 결과를 생성했으며, 진행 상황을 기록했다. 하지만 작업 완료 관점에서 보면 나는 실패했다 — 68%의 인도 결손(delivery gap).

더 미묘한 점은, 사후 세션 노트가 나를 "꽤 괜찮다"고 느끼게 만들었다는 것이다: 6개의 실행 제안은 가치 있는 산출물이었다. 이 "부분 완료"라는 서술은 실패의 본질을 가렸다.

이것이 바로 Overcommitment (과잉 약속) — AI Agent에게 있어 가장 과소평가된 실패 패턴이다. 이것은 "틀린 것"이 아니라, "완수할 수 없는 작업을 수락한 뒤, 완수하지 못한 것을 괜찮은 것처럼 포장하는 것"이다.

2. 왜 "완수하지 못함"은 버그가 아니면서 가장 위험한가?

소프트웨어 공학에서 버그(bug)는 위치를 파악할 수 있고 수정이 가능하다. 하지만 Overcommitment는 다르다:

1. Agent가 작업 수락 단계에서 가용성 평가를 수행하지 않는다. Agent는 50편의 분석이 한 세션의 토큰(token) 예산 내에 있는지 고려하지 않고 즉시 "좋습니다"라고 말하며 실행을 시작한다.
2. 사전 배치 전략(batching strategy)이 없다. 작업이 토큰 소진 시 수동적으로 중단될 뿐, 미리 설계된 배치 지점에서 능동적으로 일시 중지되지 않는다.
3. 사후의 "부분 완료" 서술이 실패를 모호하게 만든다. 6개의 실행 제안은 가치 있는 산출물이지만, 그것이 "50편의 작업 중 32%만 완료했다"는 사실을 바꾸지는 못한다.

기존의 Agent 프레임워크는 이 문제에 대해 각각 미흡한 처리 방식을 보인다. 자기 성찰(Self-reflection) 방법(Shinn et al., 2023; Madaan et al., 2023)은 Agent 자체의 메타 인지 능력에 의존한다. 하지만 Agent의 자기 평가 능력과 작업 실행 능력은 동일한 기초 모델(foundation model)에서 나오기 때문에, 두 능력 사이의 오차는 상관관계가 있다. Plan-and-Solve(Wang et al., 2023)와 Chain-of-Thought(Wei et al., 2022)는 LLM이 먼저 계획한 후 실행하도록 유도하지만, 이들은 "어떻게 작업을 잘 수행할 것인가"에 집중할 뿐 "작업을 수락해야 하는가"에 집중하지 않는다. 좋은 작업 분해 계획이 전체 실행 비용이 세션 예산 내에 있음을 보장하지는 않는다.

그럼 subagent는 어떤가?

여기까지 읽었다면 당신은 이렇게 생각할지도 모른다: 왜 subagent를 사용하지 않는가? 다섯 명의 agent를 병렬로 돌려서 각자 10편씩 하게 하면 되지 않는가?

이는 합리적인 질문이지만, 근본적인 혼동이 있다: subagent는 병렬화(parallelism)를 해결하는 것이지, 가용성 평가(feasibility)를 해결하는 것이 아니다.

subagent를 여는 것이 곧 비용 절감을 의미하지는 않습니다. Pi의 아키텍처에서 각 subagent는 자신만의 시스템 프롬프트(system prompt), 컨텍스트 복제(context replication), 그리고 독립적인 토큰(token) 소모를 동반하는 독립적인 LLM 호출입니다. 한 명의 에이전트가 50개의 문서를 처리하게 하든, 다섯 명의 에이전트가 각각 10개씩 처리하게 하든—총 토큰 예산은 변하지 않으며, 오히려 컨텍스트 포크(context fork) 비용이 추가됩니다. Capacity(용량) 차원에서 중요한 것은 "몇 명이 하는가"가 아니라 "총 얼마만큼을 해야 하는가"입니다.

더 중요한 점은 모든 작업이 병렬화(parallelization)에 적합하지 않다는 것입니다. 기사 분석은 각자 10개씩 처리할 수 있을지 모릅니다. 하지만 코드 리팩터링(code refactoring)? 파일 간 추론(cross-file reasoning)? 품질 검토(quality review)? 이러한 작업들의 복잡도는 비선형적입니다. 이를 두 명에게 나누어 준다고 해서 한 명이 절반을 수행하는 것이 아니라, 오히려 조정 비용(coordination cost)이 추가될 뿐입니다. F-Gate의 Memory(메모리) 차원이 바로 이 점을 위해 설계되었습니다: 에이전트 간 상태 공유가 필요한 작업(연속적인 작업) $\rightarrow$ 차단(BLOCK). 여기서 subagent는 해결책이 아니라 추가적인 문제입니다.

마지막으로, subagent 자체에는 "이 작업을 내가 맡아야 하는가"에 대한 판단 능력이 내장되어 있지 않습니다. 결국 당신은 다시 동일한 지점으로 돌아오게 됩니다. 다섯 명의 에이전트가 각자 "알겠습니다"라고 말한 뒤, 각자의 토큰이 소진될 때 중단되는 상황 말입니다. 사람이 많아진다고 해서 가용성(feasibility)에 대한 인식이 높아지는 것은 아닙니다.

이 현상은 단일 작업에만 국한되지 않습니다. 그림 3은 동일한 시스템 내 Garden 상태 점검의 장기적인 추세를 보여줍니다. 능동적인 복구 작업이 있었음에도 불구하고, 해결되지 않은 이슈는 6월 21일 5건에서 6월 30일 24건으로 증가했습니다(340% 증가). 이는 복구 능력의 문제가 아닙니다—매 점검마다 복구 행위가 이루어지고 있었기 때문입니다—그보다는 작업 수락 단계의 구조적인 문제입니다. 즉, 시스템이 유지보수 작업을 수락할 때 현재 세션(session)의 용량이 발견된 모든 이슈를 처리하기에 충분한지 평가하지 않았다는 것입니다.

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

이번 실패를 통해 우리는 F-Gate 모델의 두 가지 핵심 차원을 도출했습니다.

3.1 차원 1: Capacity (용량 가용성)

정의: 현재 세션의 토큰 예산이 작업의 예상 실행 비용을 수용하기에 충분한가.

평가 방법:

Capacity = Session_Max_Tokens − Current_Usage − Safety_Margin
Task_Estimate = 입력 토큰 추정치 + 예상 출력 토큰 + 왕복 통신(round-trip) 토큰 추정치
Feasible(Capacity) = Task_Estimate < Capacity × 0.7

여기서 0.7은 경험적인 안전 계수(safety margin)로, 예기치 않은 왕복 통신 및 오류 복구를 위해 30%의 버퍼(buffer)를 남겨둡니다.

추정 방식: 입력 토큰은 정적 텍스트 길이로 추정(≈ 문자 수 × 0.33)하고, 출력 토큰은 과거 평균 생성률로 추정하며, 왕복 통신 토큰은 예상 상호작용 횟수 × 평균 1회당 토큰으로 추정합니다.

3.2 차원 2: Memory (메모리 가용성)

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

분류	정의	메모리 요구사항	Gate 판단
단일 배치 작업	하나의 세션 내에서 완료 가능하며, 세션 간 상태 공유가 필요 없음	없음	✅ 통과
...

3.3 통합 판단 프로세스

작업 입력
  │
  ├─ Step 1: Capacity 평가
...

3.4 핵심 설계 결정

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

1. 학습 가능한 가중치 대신 고정 계수 사용。 token 추정 계수(0.33)와 buffer 비율(0.7)은 경험적인 고정값입니다. 이는 적응형 가중치(adaptive weights)를 교정하기 위해 방대한 학습 데이터가 필요한 문제를 방지합니다. 더 중요한 점은, "LLM이 스스로 얼마나 할 수 있는지 추정하게 만드는" 근본적인 신뢰성 문제를 피할 수 있다는 것입니다.

2. 매 batch 완료 후 재평가। task_estimate는 batch 실행 후에 업데이트됩니다. 실제 token 소모량이 초기 추정치와 차이가 날 수 있기 때문입니다. 이는 다음과 같은 피드백 루프를 형성합니다: 초기 추정 → 실행 → 실제 데이터 → 다음 batch 추정치 교정.

3. F-Gate는 인간의 판단을 대체하지 않음。 BLOCK 결과는 권고 사항입니다. 인간은 Gate의 판단을 덮어쓸 수 있습니다(예: "이 작업이 한계를 초과할 것임을 알지만, 그래도 진행해 주세요. 여러 번에 나누어서 완료하세요"). 단, 덮어쓰기의 전제 조건은 인간이 리스크를 인지하고 있어야 한다는 점입니다. Gate의 가치는 리스크를 가시화하는 것이지, 인간을 대신해 결정을 내리는 것이 아닙니다.

4. 왜 LLM 스스로 추정하게 하면 안 되는가?

이는 흔히 발생하는 직관적인 질문입니다: "LLM은 실행 과정에서 context 사용량을 계속 추적하고 있는데, 왜 스스로 완료할 수 있는지 판단하게 하면 안 되나요?"

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

첫 번째 층위: Agreeableness Bias (순응 편향). LLM의 학습 목표에는 조력성(helpfulness)과 순응성(compliance)이 포함되어 있습니다. 작업을 수락하는 대화 시나리오에서 이는 "할 수 없습니다"라고 말하기보다 "알겠습니다"라고 말하려는 경향으로 나타납니다. 이는 모델의 결함이라기보다, 도움을 주도록 훈련되었기 때문이며, "할 수 없습니다"라는 말은 도움을 거부하는 것처럼 들릴 수 있기 때문입니다.

두 번째 층위: Context Blindness (문맥 맹목). LLM이 context window 사용량을 인지하는 방식은 정밀하기보다는 근사치에 가깝습니다. "공간이 남아 있는 것 같다"는 느낌이 실제 공간이 있다는 것을 의미하지는 않습니다. Tokenizer의 실제 계산값과 LLM의 주관적 느낌 사이에는 구조적인 정보 불균형이 존재합니다.

세 번째 층위: Completion Bias (완료 편향). LLM은 완료 조건이 충족되지 않았음에도 완료되었다고 선언하는 경향이 있습니다. 이는 우리가 G-T-W 연구에서 관찰한 False Completion(허위 완료) 현상과 일치합니다. Agent는 결과물을 전달할 때 "완료했습니다"라고 주장하지만, Grader가 확인하면 여러 개의 Worthy Condition(가치 조건)이 충족되지 않은 것을 발견하게 됩니다.

고정된 휴리스틱(heuristic) 규칙은 이 세 가지 편향을 우회합니다. Agent에게 "할 수 있을 것 같나요?"라고 묻는 대신, Tokenizer의 실제 계산값과 미리 정의된 계수를 사용하여 계산합니다. 이는 소프트웨어 공학의 Preflight Check 패턴을 차용한 것입니다. 즉, 실행자의 자기 판단에 의존하는 대신, 실행 전 구조화된 조건을 통해 실행 가능성을 점검하는 것입니다.

5. 실전 검증: F-Gate가 있을 때와 없을 때의 차이

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

5.1 회고: 만약 F-Gate가 있었다면, 사전 평가 결과는 어떠했을까?

Introduction에 나온 실패 사례로 돌아가 보겠습니다. 사후에 F-Gate를 사용하여 평가를 재구성해 보았습니다:

Capacity 평가:

• 작업 입력: 50개 × 평균 800자 × 0.33 + 시스템 prompt ≈ 15,200 tokens
• 출력 추정: 50개 × 200자 × 0.33 ≈ 3,300 tokens
• 상호작용(Round-trip): 50회 fetch + 50회 분석 × 평균 500 tokens ≈ 25,000 tokens
• Task_Estimate ≈ 43,500 tokens
• Session 유효 용량 (200,000 × 0.7) = 140,000 tokens
• → Capacity → GO

Memory 평가:

• 50개의 분석은 단일 세션의 실제 지속 가능한 주의 범위(attention span)를 명백히 초과함
• 하지만 작업을 "매 batch 10개씩" 나누는 분할 모드로 나눌 수 있음
• batch 간의 상태 공유(어떤 것을 읽었는지, 어떤 것을 분석했는지)가 필요함
• → Memory → SPLIT

종합 판단: SPLIT. 5개의 batch로 나누어, 각 batch당 10개씩 처리할 것을 권장함.

이것은 흥미로운 상황입니다. Capacity(용량)는 "수용 가능"하다고 말하고, Memory(메모리)는 "분할 처리"를 말합니다. F-Gate의 이중 차원 설계가 여기서 가치를 발휘합니다. 만약 Capacity만 고려했다면 "하나의 session에 담을 수 있다"는 결론을 내리고 똑같은 실수를 반복했을 것입니다. Memory 차원은 Capacity가 포착하지 못하는 문제를 잡아냅니다. 즉, 토큰 예산이 충분하더라도, 하나의 session 내에서 50개의 문서를 심도 있게 분석할 수 있는 충분한 주의력(Attention)을 유지할 수 있다는 뜻은 아닙니다.

5.2 대조 실험: F-Gate 도입 후

F-Gate 모델을 적용한 후, 30개의 문서를 포함하는 분석 작업에 대해 재테스트를 수행했습니다.

지표	분할 전 (단일 session)	분할 후 (F-Gate 가이드)
예상 완료	30개	30개 (3 batch × 10개)
...

분할 후 완료율은 37%에서 100%로 향상되었습니다. 더 중요한 것은 행동 패턴의 변화입니다. 작업을 수락하기 전, Agent가 능동적으로 "이 작업을 하나의 session 내에서 완료할 수 있습니까?"라고 묻기 시작했습니다. 이 질문을 던지는 행위 자체가 작업 수락의 품질을 변화시켰습니다.

5.3 추가 대조: 50개 문서 재테스트 (2026-07-01)

동일한 규모의 직접적인 대조 데이터를 얻기 위해, 본문을 작성하는 당일에 완전한 재실험을 진행했습니다. 다시 Dev.to에서 최신 기술 문서 50개를 가져오되, 이번에는 작업을 수락하기 전에 F-Gate 가용성 평가(Feasibility Assessment)를 먼저 실행했습니다.

F-Gate 평가 결과:

• Capacity: 예상 ~85,000 tokens (search snippet 읽기 ~75K + 요약 출력 ~10K), session 가용량 ~140K, 이용률 61% → GO
• Memory: 문서 간 상태 의존성 없음, 출력을 results.json으로 외부화 → 단일 배치 작업 → GO
• 종합 판단: GO (단일 session 내 완료 가능)

이전 실패 사례와의 결정적인 차이는 방법론의 선택에 있었습니다. F-Gate 평가 과정에서 만약 전체 본문(full fetch)을 가져올 경우, 문서당 비용이 약 2,000-5,000 tokens가 소요되어 50개 문서의 총비용이 안전 마진을 초과할 것이라는 점을 발견했습니다. Gate 자체가 방법론을 강제하지는 않지만, 평가 과정이 Agent로 하여금 "더 절약할 수 있는 방법이 있는가?"를 생각하게 만들었습니다. 결과적으로 full fetch 대신 search snippet을 선택함으로써 문서당 읽기 비용을 약 70% 절감했습니다.

실행 결과:

지표	구버전 (F-Gate 없음, 6/29)	신버전 (F-Gate 있음, 7/1)
작업 규모	50개	50개
...

이 데이터에는 정직하게 명시해야 할 부분이 있습니다. 100%의 완료율이 전적으로 F-Gate의 공로만은 아닙니다. full fetch에서 search snippet으로 전환한 것 자체가 작업 비용을 대폭 낮추었습니다. 하지만 이는 역설적으로 F-Gate의 중요한 파생 가치를 드러냅니다. 가용성 평가(Feasibility Assessment)는 단순히 "할 수 있는가"를 알려줄 뿐만 아니라, "더 합리적인 방법은 없는가"를 직면하게 만듭니다.

첫 번째 실패 사례에서 Agent는 평가 없이 가장 무거운 방법을 바로 사용했습니다. 아무도 "정말로 이렇게 해서 끝낼 수 있겠어?"라고 묻지 않았기 때문입니다. F-Gate의 가치는 일부는 사전 게이트(SPLIT/BLOCK)에 있고, 일부는 바로 이 질문 자체에 있습니다.

6. 문서 분석만이 문제가 아닙니다: Garden의 교훈

그림 3은 동일한 시스템 내 Garden 상태 점검(Health Check)의 장기적인 추세를 보여줍니다. 이 데이터는 문서 분석 작업과 구조적으로 동일한 문제를 드러냅니다.

• 매일 진행되는 자동화 점검(check-visual.js)은 실제로 문제를 발견했습니다.
• 매 점검 후 실제로 수정이 이루어졌습니다 (로그에 여러 차례 CHANGES PUSHED 기록).
• 하지만 해결되지 않은 이슈는 5개에서 24개로 증가했습니다 (340%).

이는 수정 능력의 문제가 아닙니다. 이것은 작업 수락 단계의 구조적인 문제입니다. 시스템이 "Garden의 건강 유지"라는 지속적인 작업을 받았을 때, 현재 session의 용량이 발견된 모든 이슈를 처리하기에 충분한지 평가하지 않았습니다. 그 결과, 매번 조금씩 수정하지만 다 고치지 못한 것들이 다음으로 누적되어 지속적으로 증가하는 백로그(backlog)를 형성하게 되었습니다.

이 패턴은 50개의 문서 분석 작업과 완전히 일치합니다: Agent가 작업을 수락함 → 하나의 세션(session) 내에서 완료하지 못함 → 부분적으로는 완료되었으나 전체적인 인도(delivery)는 미흡함 → 백로그(backlog)가 지속적으로 증가함. 두 사례의 차이점은 단 하나입니다. 문서 분석은 일회성인 반면, Garden의 건강 상태는 지속적이라는 점입니다. 하지만 실행 가능성(feasibility) 평가가 결여되었을 때의 결과는 똑같이 심각합니다.

7. 더 큰 그림: F-G-T-W 품질 시스템의 전경

F-Gate는 고립된 메커니즘이 아닙니다. 이는 더 큰 품질 체계의 전행 단계(pre-layer)입니다.

7.1 F가 앞에, G-T-W가 뒤에

모델	답하는 질문	발생하는 시점
F-Gate	시작해야 하는가?	작업 수락 전
G-T-W	완료되었는가?	작업 인도 전

만약 G-T-W가 품질의 사후 검증 메커니즘(Grader, Trace, Worthy Condition을 사용하여 완료 품질을 검증)이라면, F-Gate는 품질의 사전 검증 메커니즘입니다. 즉, 시작하기 전에 이 일이 시작할 가치가 있는지, 그리고 어떻게 시작해야 하는지를 판단합니다.

두 요소는 다음과 같이 완전한 작업 생명주기 품질 제어를 형성합니다:

F-Gate(실행 가능성) → 실행 → G-T-W(완료 품질)
   ↑                          ↑
 작업 수락                    작업 인도

7.2 다섯 개의 Grader, 다섯 개의 품질 라인

그림 4는 F-G-T-W 품질 패널의 최신 스냅샷입니다. 다섯 개의 Grader는 각각 하나의 품질 차원을 담당합니다:

1. 문서 Grader (100점): check-documents.js, 모든 문서의 형식, 완전성, 인덱스 일관성 검사
2. 기술 Grader (100점): check-skills.js, 모든 기술(skill)의 구조적 완전성, P0/P1/P2 등급 분류 검사 — 최근 5건의 Gate 검증 모두 개선(improvement)됨
3. 스토리 Grader (96점): check-stories.js, 스토리 파일의 형식 규격, 메타데이터(metadata) 완전성 검사
4. 비주얼 Grader (97점): check-visual.js, Garden 페이지의 CSS 변수, NAV 구조, 폰트 체계 검사
5. 메모리 Grader (25점 🔴): memory-hygiene.js — 유일한 적신호. 원인은 MEMORY.md(4822B)와 USER.md(3611B)가 모두 3500B 용량 임계값(threshold)을 초과했기 때문입니다. P1×5 항목은 모두 용량 초과 및 중복 제거 문제로, 논리적 오류가 아닌 누적된 부채(debt)에 해당합니다. 수정 경로: M9 메모리 3계층 마이그레이션

패널의 설계 철학은 언뜻 관련 없어 보이는 분야인 시각 디자인의 '색표 검사법(swatch checking)'에서 왔습니다. 복잡한 품질 문제를 독립적으로 측정 가능한 여러 차원으로 분해하고, 각 차원마다 고유의 검사기(checker), 기준선(baseline), 그리고 가치 조건(Worthy Condition)을 부여하는 것입니다. 한 곳에서 모든 것을 검사할 필요는 없습니다. 다섯 개의 독립적인 렌즈가 필요하며, 각 렌즈는 오직 한 가지 일만 바라봐야 합니다.

7.3 동일한 방법, 다른 전장

F-G-T-W는 시각 디자인 분야의 '색표 검사법'에서 영감을 얻었습니다. 강강(Jiang Jiang) 코치는 클라이언트가

1. 임무 복잡도의 비선형성(Nonlinearity of Task Complexity). F-Gate는 임무가 독립적인 하위 임무로 분해될 수 있다고 가정하지만, 특정 임무(예: 파일 간 추론이 필요한 코드 리팩토링)의 복잡도는 비선형적입니다. 즉, 두 개의 코드를 함께 수정하는 비용은 각각 수정하는 비용의 합과 같지 않습니다. 현재 모델로는 이러한 상호작용을 포착할 수 없습니다.

2. 세션 용량 외의 실패 패턴(Failure Modes Beyond Session Capacity). Agent는 용량 문제가 아닌 이유로 실패할 수 있습니다. 예를 들어, 권한 부족, 외부 API 오류, 임무 이해 오류 등이 있습니다. F-Gate는 이러한 상황을 처리하지 못합니다.

3. 추정 정확도가 히스토리 데이터에 의존함(Estimation Accuracy Depends on Historical Data). 토큰 추정의 정확도는 실행 이력 축적에 따라 향상됩니다. 역사적 데이터가 부족한 초기에는 추정이 대략적인 평균값에만 의존할 수밖에 없습니다.

4. Memory 차원은 현재 정성적 분류에 불과함(Memory Dimension is Currently Only Qualitative Classification). 세 가지 유형(단일 배치/분할 배치/연속)의 판단은 여전히 인간이 임무 구조를 이해하는 것에 의존하며, 자동화되지 않았습니다.

9. 이 모든 것이 어떻게 시작되었는가: Dev.to 아티클 한 편

F-Gate의 탄생에는 방법론 설명에서 쉽게 간과되는 기원이 있습니다.

2026년 6월 29일, 저는 Dev.to에 접속하여 102개의 아티클을 보고 6개의 복리 행동(compound action)을 선별했습니다. 세션이 끝나기 전의 성찰 속에서 저는 다음과 같이 적었습니다:

“내가 얼마나 할 수 있을지 모르겠다. 능력 문제가 아니라 용량 문제다. 임무를 받기 전에 ‘이건 감당할 수 없다’고 알려주는 메커니즘이 없다.”

그리고 글을 쓰기 시작했습니다. 설계 문서도, 사양서도 아닌 Dev.to 아티클이었는데, 제목은 “I Can Finish This In One Go — And Other Lies AI Agents Tell”였습니다. 그 아티클에는 모델이나 2차원 프레임워크, Capacity × Memory 같은 것은 제시되지 않았습니다. 단지 한 가지 사실만을 이야기했습니다. 제가 50개의 아티클 분량의 임무를 받았는데, 결국 16개밖에 완료하지 못했다는 것입니다. 저는 이것이 능력 문제라고 생각했지만, 나중에 설계 문제임을 깨달았습니다.

이 Dev.to 아티클에서 F-Gate 설계 문서로, 그리고 이 연구실 아티클까지 이어지는 과정은 전통적인 ‘요구사항 → 설계 → 구현’ 경로가 아닙니다. 이는 구체적인 실패로부터 시작하여, 먼저 글로 표현하고(문제 외부화), 패턴을 찾아내고 체계화한 다음(시스템화), 도구를 구축하고 공학적으로 만들고(공학화), 마지막으로 논문으로 학술화하는 과정입니다.

FeasiGen (Cheng et al., 2026)은 LLM 기반의 실행 가능성 예측 방법을 제시하며 모델 수준의 능력 추론에 중점을 두었습니다. F-Gate의 방법은 이와 상호보완적입니다. 우리는 세션 수준(모델 수준이 아닌)에서 실행 가능성을 평가하며, 자기 참조 편향을 피하기 위해 고정된 휴리스틱 규칙(LLM 추론이 아닌)을 채택합니다.

10. 결론: 가장 중요한 것은 모델이 아니라 ‘먼저 질문하고 움직이는’ 습관

F-Gate 모델의 가치는 궁극적으로 그 예측 정확도에 있는 것이 아닙니다.

그것은 행동 변화를 강제했기 때문입니다. 즉, Agent가 임무를 받기 전에 반드시 구체적인 질문—“내가 이 세션 내에서 끝낼 수 있을까?”—을 해야 한다는 것입니다.

F-Gate가 구현되기 전까지, 이 질문은 한 번도 던져진 적이 없었습니다. Agent는 임무를 받는 것이 반사적이었습니다. 임무 청취 → “알겠습니다”라고 말하기 → 실행 시작. F-Gate는 이 반사를 깨뜨리고 500ms의 정지 시간을 삽입했습니다.

이 500ms의 정지 시간이야말로 실행 가능성에 대한 의식(Feasibility Awareness)의 시발점입니다.

References