프로덕션 환경에서도 살아남는 에이전틱 엔지니어링 (Agentic Engineering) 패턴

2026년 코딩 에이전트 (Coding Agents)에 대한 흥미로운 질문은 그것들이 작동하느냐가 아닙니다. 바로 결과가 뒤따르는 코드에 에이전트를 투입했을 때 어떤 패턴이 버텨내느냐 하는 것입니다. Leviathan의 실제 주식 리서치 스택을 대상으로 Claude, Codex, 그리고 다양한 무료 티어 모델들을 약 18개월 동안 운영해 본 결과, 소수의 패턴만이 스스로의 가치를 증명하며 유지되었습니다. 나머지는 일주일 안에 도태되었습니다.

이 노트는 튜토리얼이 아닌 현장 기록(field log)입니다. 프레임워크는 역량이 아닌 엔지니어링에 맞춰져 있습니다. 제가 계속 던지는 질문은 이것입니다: 무엇이 프로덕션 (Production) 환경과의 접촉에서 살아남는가?

컨텍스트 (Context)는 프롬프트 (Prompt)가 아니라 예산이다

가장 먼저 무너진 사고 모델은 컨텍스트를 무료 자원으로 취급하는 것이었습니다. 1M 토큰 윈도우 (Window)가 모델에 1M 토큰의 쓰레기를 스트리밍할 수 있다는 의미는 아닙니다. 그것은 당신에게 예산이 있다는 뜻입니다. 도구 출력 (Tool output)의 모든 토큰, 모든 디프 (Diff), 모든 검색된 청크 (Retrieved chunk)는 모델이 하류 (Downstream) 단계에서 얼마나 많은 추론 (Reasoning)을 할 수 있는지를 결정하는 기금에서의 인출과 같습니다.

버텨내는 패턴은 **도구 경계에서의 구조화된 압축 (Structured compression at the tool boundary)**입니다. 도구가 50KB의 JSON을 반환할 때, 그 50KB를 모델에 그대로 전달하지 마세요. JSON으로부터 구축된 결정론적 요약(Deterministic summary), 즉 개수, 상위 K개 항목(Top-K items), 하류 단계에서 필요한 특정 필드들을 전달하세요. 원본 블롭 (Raw blob)은 핸들 (Handle) 아래 디스크에 보관하십시오. 모델이 더 많은 정보가 필요하다면 요청할 수 있습니다.

Leviathan에서는 이것이 구체적으로 구현되어 있습니다: 읽기 작업이 많은 모든 bash 명령은 RTK를 거칩니다. 이는 Rust 기반 필터로, git status, 테스트 출력, grep 결과, 파일 읽기 내용을 모델의 컨텍스트 윈도우에 닿기 전에 60~90%까지 압축합니다.

토큰 규율 (Token discipline)은 모델 크기보다 중요합니다. 절제된 압축을 사용하는 200K 윈도우는 가공되지 않은 도구 덤프를 사용하는 1M 윈도우보다 성능이 뛰어납니다. 우리는 실제 Claude Code 세션에서 이를 측정했습니다. 가공되지 않은 출력을 사용하는 1M 모델은 200K 모델이 깔끔하게 완료한 것과 동일한 작업을 완료하기 전에 유효한 추론 능력을 모두 소진해 버렸습니다.

더 깊은 원칙은 다음과 같습니다: 모델은 입력값의 함수입니다. '쓰레기가 들어가면 쓰레기가 나온다 (Garbage in, garbage out)'는 원칙이 LLM(Large Language Models)에는 당혹스러울 정도로 문자 그대로 적용됩니다. 에이전트(Agent)를 엔지니어링한다는 것은 대부분 입력값을 엔지니어링하는 것입니다.

도구는 인터페이스 설계의 문제입니다

살아남은 두 번째 패턴은 도구 정의(Tool definitions)를 사후 고려 사항이 아닌, API 설계 연습처럼 다루는 것입니다.

잘못된 도구 설계가 실패 사례의 대부분을 차지합니다. 전형적인 증상은 다음과 같습니다:

너무 많은 정보를 반환하는 도구 (위에서 언급한 50KB JSON 문제).
모호한 파라미터(Parameters)를 사용하여 모델이 추측하게 만드는 도구.
정보를 조용히 잘라내어(Truncate), 모델이 전체 상황을 파악하지 못했음에도 파악했다고 착각하게 만드는 도구.
기능이 중복되어, 모델이 동일한 작업을 수행하는 세 가지 유사한 방식 중 하나를 선택해야만 하는 도구.

해결책은 새벽 3시에 졸고 있는 주니어 엔지니어를 위한 CLI(Command Line Interface)를 설계하듯 도구를 설계하는 것입니다. 각 도구는 하나의 작업만 수행해야 합니다. 명확한 파라미터 이름, 정직한 에러 메시지, 사전 검증된 입력값(Pre-validated inputs)이 필요합니다. 출력은 적절한 크기로 제한되어야 하며, 더 많은 정보가 필요한 경우 명시적인 페이지네이션(Pagination)을 제공해야 합니다.

# 나쁜 예: 과부하되어 있고, 모호하며, 가공되지 않은 API 응답을 쏟아냄
def search(query: str, options: dict = None) -> dict: ...

...

제 테스트 결과에 따르면, 두 번째 형태가 에이전트 루프(Agent loops)에서 대략 3배 더 신뢰할 수 있었습니다. 이유는 명확합니다. 모델이 틀릴 수 있는 경로가 줄어들기 때문입니다.

Anthropic의 기술 문서에서 얻은 유용한 직관적 점검법은 다음과 같습니다: 만약 도구가 무엇을 하는지 한 문장으로 설명할 수 없다면, 그 도구는 너무 광범위한 것입니다. 분리하십시오.

플래너(Planner)와 실행자(Executor): 작동하는 가장 단순한 분리

도구 호출이 몇 번 이상 필요한 모든 작업에 대해, 유효하게 작동하는 패턴은 **플래너-실행자 분리 (Planner-executor separation)**입니다. 하나의 모델(또는 하나의 모델 호출)이 계획을 세우고, 별도의 호출(또는 호출 풀)이 계획을 단계별로 실행합니다.

구체적으로, Leviathan의 연구 파이프라인에서는 다음과 같습니다:

**Planner (플래너)**가 목표("$TICKER의 경제적 해자 역학을 설명하라")를 읽고, 각 단계에서 사용할 것으로 예상되는 도구(tool)와 함께 순차적인 하위 작업(subtask) 목록을 작성합니다.
**Executor(s) (실행기)**가 각 하위 작업을 격리된 상태로 실행합니다. 각 실행기는 하위 작업 설명과 이전 단계에서 생성된 결과물(artifacts)만 볼 수 있습니다. 이들은 전체 목표(global goal)를 보지 못합니다.
**Synthesizer (합성기)**가 결과물들을 하나로 엮어 최종 출력을 생성합니다.

이를 통해 세 가지 이점을 얻을 수 있습니다:

플래너가 긴 컨텍스트 추론(long-context reasoning)을 반복하는 대신 단 한 번만 사용합니다.
실행기들은 작고 집중된 컨텍스트 창(context window)을 가지며 비용이 저렴하게 실행됩니다.
실행기들을 병렬로 확장(fan out)할 수 있습니다. 독립적인 하위 작업들은 전체 작업 시간의 합이 아니라, 가장 느린 작업에 비례하는 실제 시간(wall-clock time) 내에 완료됩니다.

비용은 간접 계층(indirection)이 하나 더 추가된다는 점입니다. 이점은 대략 5달러짜리 작업 대신 0.50달러짜리 작업으로 만드는 것이며, SWE-bench Verified와 같은 표준 에이전틱 벤치마크에서 8~14점의 성능 향상을 가져오는 것입니다.

이 패턴은 Anthropic의 Building Effective Agents 포스트에서 설명된 오케스트레이터-워커 분해(orchestrator-worker decomposition)와 가장 유사합니다. 변형 방식은 주로 플래너가 얼마나 엄격한지, 그리고 각 실행기가 어느 정도의 자율성을 갖는지에 달려 있습니다.

주의해야 할 실패 모드(failure mode)는 **플래너 과적합(planner overfitting)**입니다. 플래너가 그럴듯해 보이지만 실제로 실행할 수 없는 단계(도구가 존재하지 않거나, 데이터를 사용할 수 없거나, 가정이 틀린 경우)를 포함하는 계획을 작성하는 것입니다. 해결책은 실행기가 컨텍스트를 포함한 구조화된 실패(structured failures)를 반환하도록 만들고, 해당 실패 내용을 입력값에 포함하여 플래너를 다시 실행하는 것입니다.

평가는 아무도 만들고 싶어 하지 않는 부분이다

내가 출시했거나 출시되는 것을 지켜본 모든 에이전트 시스템은 팀이 고려했던 사례에서는 작동하지만, 고려하지 않았던 사례에서는 실패하는 지점에 도달했습니다. 유일한 탈출구는 평가(evaluation)뿐입니다.

유지되는 패턴은 다음과 같습니다: 모든 변경 사항에 대해 실행되는 작고 빠른 평가 하네스 (evaluation harness)입니다. Kaggle 스타일의 리더보드가 아닙니다. 연구용 벤치마크 (benchmark)도 아닙니다. 결정론적 검사기 (deterministic checker)를 갖춘 몇 가지 표준적인 작업들로 구성되며, 1분 이내에 실행하여 에이전트의 성능이 저하되었는지 여부를 알려줍니다.

Leviathan의 주식 리서치 에이전트의 경우, 이 하네스는 네 가지 작업 형태를 가집니다:

$$
\text{score} = \frac{1}{N} \sum_{i=1}^{N} \mathbb{1}{\text{checker}_i(\text{agent output}_i) = \text{pass}}
$$

네 가지 형태는 다음과 같습니다:

포렌식 회계 (Forensic accounting): 알려진 사기 신호가 있는 티커 (ticker)가 주어졌을 때, 에이전트가 올바른 위험 신호 (red flags)를 찾아내는가?
DCF 재구성 (DCF reconstruction): 공시 자료가 주어졌을 때, 에이전트가 애널리스트 컨센서스 (analyst consensus)의 허용 오차 범위 내에 있는 내재 가치를 가진 DCF (현금흐름할인법)를 생성하는가?
피어 선정 (Peer selection): 대상 티커가 주어졌을 때, 에이전트가 사람이 선별한 큐레이션된 피어 세트 (peer set)와 최소 60% 이상 중복되는 피어 세트를 선택하는가?
인용 규율 (Citation discipline): 출력물 내의 모든 정량적 주장이 검색된 소스 (retrieved source)로 거슬러 올라갈 수 있는가?

마지막 항목이 중요합니다. 모델은 인용을 환각 (hallucinate)합니다. 자동화된 검사가 없다면, 이러한 부패는 프로덕션 (production) 환경에서 누군가 알아차릴 때까지 조용히 축적됩니다.

이 하네스는 대략 800줄의 Python 코드로 이루어져 있습니다. 이는 코드베이스에서 가장 가치 있는 800줄입니다.

제거되는 것들

2025년에 유망해 보였던 몇 가지 패턴들은 유지되지 못했습니다:

체크포인팅 (checkpointing) 없는 긴 자율 루프 (Long autonomous loops). 인간이나 평가자 (evaluator)의 개입 없이 도구 호출 (tool calls)이 약 10회를 넘어가면 경로를 이탈하기 시작합니다. 해결책은 몇 단계마다 체크포인팅을 수행하고 "다음 행동이 여전히 목표를 향한 경로 위에 있는가?"라고 묻는 것입니다.
모델의 판단에만 의존하는 자기 수정 (Self-correction) 루프. 모델은 자신이 실수를 저지른 동일한 컨텍스트 윈도우 (context window) 내에서 자신의 실수를 알아차리는 데 서툽니다. 비판자 (critic)가 새로운 컨텍스트일 때 자기 비판 (Self-critique)은 훨씬 더 잘 작동합니다.
모든 것을 기억하려고 시도하는 메모리 시스템 (Memory systems). 대부분의 "에이전트 메모리" 구현체는 결국 오래된 정보를 노출하는 비용만 많이 드는 벡터 데이터베이스 (vector databases)로 전락합니다. 명시적인 명명 규칙과 명시적인 무효화 (invalidation)를 갖춘 영구 파일 (Persistent files)이 대개 더 낫습니다.

살아남은 패턴들을 관통하는 핵심은 모델을 마법 같은 신탁 (oracle)이 아니라, 시스템에 내장된 추론 구성 요소 (reasoning component)로 취급한다는 점입니다. 엔지니어링 작업은 시스템에 집중됩니다. 모델은 하나의 구성 요소입니다. 훌륭한 구성 요소이지만, 단지 하나일 뿐입니다.

향후 전망

Claude 4.6, 4.7, 그리고 GPT-5.5가 잇따라 출시되는 것을 지켜본 후 제가 걸고 있는 베팅의 궤적은 다음과 같습니다. 모델은 계획 (planning)과 도구 호출 (tool calling) 능력이 계속해서 좋아지겠지만, "데모 에이전트 (demo agent)"와 "프로덕션 에이전트 (production agent)" 사이의 간극은 여전히 넓게 유지될 것입니다. 그 간극은 대부분 엔지니어링의 영역입니다. 컨텍스트 규율 (Context discipline), 도구 인터페이스 설계 (tool interface design), 플래너-실행자 분해 (planner-executor decomposition), 그리고 평가 하네스 (evaluation harnesses)가 하중을 견디는 핵심 요소들입니다.

향후 2년 동안 승리할 팀은 가장 큰 모델을 가진 팀이 아닙니다. 그 모델들을 규율 있게 사용할 수 있는 인프라를 구축한 팀입니다.

어쨌든, 그것이 저의 베팅입니다. 시간이 흐른 뒤 어떻게 변할지 지켜보겠습니다.