AI 에이전트는 4년 만에 이렇게 바뀌었다

영어가 가장 핫한 프로그래밍 언어였던 시절

2023년, 테슬라 AI 디렉터 출신 Andrej Karpathy가 이런 말을 합니다.

"가장 핫한 새 프로그래밍 언어는 영어다."

GPT-3.5가 세상을 놀라게 했고, 프롬프트를 어떻게 쓰느냐에 따라 결과가 크게 달라졌습니다. 사람들은 "단계별로 생각해봐"라는 한 문장을 추가하는 것만으로 추론 성능이 3배 이상 올라가는 걸 목격했습니다. Chain-of-Thought라 불린 이 기법은 AI 에이전트 시대의 출발점이었습니다.

1막: 프롬프트 엔지니어링 (2022~2024)

이 시기의 핵심 질문은 단순했습니다. "어떤 말을 해야 하나?"

모델에게 보내는 지시문의 품질이 성공을 결정한다고 믿었습니다. 실제로 그랬습니다. ReAct 패턴이 등장해서 AI가 "생각하고, 행동하고, 관찰하는" 루프를 돌기 시작했고, Andrew Ng 교수는 AI 에이전트의 4가지 핵심 패턴을 정리했습니다.

Reflection: 자기 출력을 다시 평가하는 것
Tool Use: 외부 도구를 호출하는 것
Planning: 작업을 단계로 분해하는 것
Multi-Agent: 여러 에이전트가 협업하는 것

GitHub Copilot이 코드를 자동완성하고, ChatGPT가 모든 사람의 일상에 들어왔습니다. 프롬프트만 잘 쓰면 뭐든 할 수 있을 것 같았습니다.

그런데 문제가 생겼습니다.

같은 프롬프트를 넣어도 매번 다른 결과가 나왔습니다. 측정 기준 없이 시행착오만 반복했습니다. 그리고 결정적으로, 프롬프트 품질은 좋아도 모델이 볼 수 있는 정보가 부족하면 어쩔 수 없었습니다. 프롬프트만으로는 한계가 명확해졌습니다.

2막: 컨텍스트 엔지니어링 (2025)

2025년 6월, Shopify CEO Tobi Lütke가 "context engineering"이라는 용어를 제안합니다. 일주일 만에 업계 전체가 동의했습니다. 그만큼 모두가 같은 벽에 부딪히고 있었던 것입니다.

핵심 질문이 바뀝니다. "어떤 정보를 넣어야 하나?"

프롬프트를 어떻게 쓸지보다, 컨텍스트 윈도우에 무엇을 채울지가 핵심이 됩니다. Anthropic은 WSCI 원칙을 제시합니다.

원칙	설명
Write	시스템 프롬프트를 명확하고 구조화된 형태로 작성
Select	필요한 정보만 선택적으로 주입
Compress	대화 히스토리를 요약하여 토큰 효율성 확보
Isolate	서브에이전트에 필요 정보만 제한적 전달

이 시기에 중요한 인프라가 등장합니다. **MCP(Model Context Protocol)**는 에이전트가 외부 도구와 소통하는 표준 규격이 됩니다. API 문서를 실시간으로 검색해서 주입하는 Context Hub, 복잡한 작업을 전문 단위로 쪼개는 서브에이전트 구조가 자리잡습니다.

재미있는 지표가 하나 있습니다. KV-cache Hit Rate. LLM API의 컨텍스트 접두어(시스템 프롬프트, 도구 정의)가 같으면 이전 계산을 재활용합니다. 캐시 히트 시 비용이 10분의 1로 줄어듭니다. 프롬프트의 "품질"보다 "안정성"이 더 중요해진 겁니다.

이 시기의 현실을 요약하는 문장이 있습니다.

"프로덕션에서 성공하는 대부분의 AI 에이전트는 마법적 자율 존재가 아니라, 잘 설계된 전통적 소프트웨어다."

하지만 또 벽에 부딪힙니다.

개별 API 호출은 완벽해도, 전체 루프 설계가 허술하면 결과가 엉망이었습니다. 도구 호출이 실패하면? 모델이 환각을 일으키면? 비용이 폭주하면? 이런 것들에 대한 체계적 처리가 없었습니다.

3막: 하네스 엔지니어링 (2026~)

2026년 2월, HashiCorp 창업자 Mitchell Hashimoto가 이런 원칙을 공유합니다.

"에이전트가 실수할 때마다, 그 실수가 구조적으로 다시 발생할 수 없도록 시스템을 변경한다."

핵심 질문이 다시 바뀝니다. "어떤 시스템을 만들어야 하나?"

이제 에이전트 = 모델 + 하네스로 정의됩니다. 모델이 CPU라면, 하네스는 OS입니다. 컨텍스트를 관리하고, 도구를 제어하고, 권한을 설정하고, 에러를 복구하는 전체 시스템이 승부처가 됩니다.

실제 사례를 보면 이해가 빠릅니다.

Anthropic의 3-에이전트 구조

Planner → Generator → Evaluator → (실패 시) Generator → Evaluator → ...

Planner: 간단한 요청을 상세 스펙으로 확장
Generator: 기능을 한 번에 하나씩 구현
Evaluator: 자동 테스트를 돌려서, 미달이면 구체적 피드백과 함께 Generator에 반환

비용은 22배 증가하지만, 완성도는 비교할 수 없는 수준이 됩니다.

OpenAI Codex 프로젝트의 교훈

수동 코드 작성 0줄, 생성 코드 약 100만 줄, 개발 속도 약 10배 향상. 엔지니어들이 한 일은 코드를 쓴 게 아닙니다. 에이전트가 안정적으로 코드를 생성할 수 있는 환경을 설계한 것입니다.

모든 아키텍처 원칙을 마크다운으로 문서화
커스텀 린터로 규칙을 기계적으로 강제
전체 문서 대신 지도를 제공하고, 에이전트가 필요한 정보를 스스로 찾아가게 함

4년 진화의 패턴

시대	핵심 질문	엄밀함의 위치	실패 모드
프롬프트 (2022-2024)	어떤 말을 하나?	프롬프트 텍스트	비결정론성, 환각
컨텍스트 (2025)	어떤 정보를 넣나?	컨텍스트 윈도우 구성	정보 오염, 누락
하네스 (2026~)	어떤 시스템을 만드나?	전체 아키텍처	오케스트레이션 버그

여기서 중요한 통찰이 있습니다. 각 시대는 이전 시대를 대체하지 않습니다. 포함합니다. 하네스 안에 컨텍스트가 있고, 컨텍스트 안에 프롬프트가 있습니다. 프롬프트 엔지니어링이 죽은 게 아니라 하네스의 서브모듈이 된 것입니다.

"엄밀함은 사라지지 않는다. 이동할 뿐이다."

보안: 세 가지가 동시에 존재하면 위험하다

하네스 시대에 새롭게 부각된 개념이 있습니다. Lethal Trifecta — 다음 세 가지가 동시에 존재하면 보안 사고는 필연입니다.

신뢰할 수 없는 입력 처리
민감한 시스템/데이터 접근
상태 변경 능력

Meta AI는 Rule of Two를 제안합니다. 에이전트는 이 중 최대 2가지만 가질 수 있고, 3가지 모두 필요하면 반드시 사람의 승인이 필요합니다.

방어의 깊이: Fowler의 2x2 분류

하네스의 검증 체계는 4가지 레이어로 나뉩니다. Chad Fowler가 정리한 이 분류는 프로덕션 에이전트 설계의 기본 프레임워크가 되었습니다.

	사전(피드포워드)	사후(피드백)
결정론적	가이드 (AGENTS.md, .cursorrules)	연산적 (컴파일러, 린터, 정적 분석)
비결정론적	시스템 프롬프트 (역할, 제약, few-shot)	추론적 (LLM-as-a-judge, 의미론적 리뷰)

실제 프로덕션 하네스는 이 네 레이어를 모두 조합합니다.

예를 들어 코드를 생성하는 에이전트라면:

사전 결정론적: AGENTS.md에 "절대 rm -rf를 쓰지 마라" 같은 규칙 명시
사전 비결정론적: "너는 시니어 백엔드 개발자야. 보안을 최우선으로 한다" 같은 역할 부여
사후 결정론적: 생성된 코드를 린터와 타입 체커로 검증
사후 비결정론적: 다른 LLM이 "이 코드에 보안 취약점이 있는가?" 리뷰

한 레이어에서 놓친 에러를 다음 레이어에서 잡습니다. 마치 스위스 치즈 모델처럼, 구멍이 일직선으로 정렬되지 않는 한 사고는 발생하지 않습니다.

클린 컨텍스트 패턴: 매번 새로 시작하는 이유

하네스 시대의 흥미로운 패턴 중 하나가 클린 컨텍스트 패턴입니다.

전통적인 챗봇은 대화를 이어갑니다. 이전 맥락을 기억하는 것이 장점이라고 생각합니다. 하지만 에이전트가 복잡한 작업을 반복 수행할 때는 이전 컨텍스트가 오히려 오염원이 됩니다. 이전 시도의 실패 경험이 다음 시도를 편향시킵니다.

# Ralph 패턴: 반복 실행의 원칙

1. PRD(제품 요구사항 문서)를 정의한다
2. 에이전트를 실행한다
3. 결과를 검증한다
4. 실패 시, 에이전트를 클린 컨텍스트로 새로 시작한다
5. 상태는 git 히스토리와 파일 시스템에만 저장한다

핵심은 에이전트의 "기억"을 컨텍스트 윈도우가 아닌 외부 시스템(git, 파일)에 저장하는 것입니다. 에이전트는 매번 깨끗한 상태에서 시작하되, 필요한 정보는 파일에서 읽어옵니다.

미래: 감시자 에이전트와 평가 엔지니어링

하네스 이후에는 어떤 변화가 올까요? 몇 가지 흐름이 이미 보이고 있습니다.

Guardian Agent — 에이전트를 감시하는 에이전트

에이전트의 행동을 실시간으로 감시하는 독립 에이전트가 등장합니다. 규제 위반, 보안 침해, 비용 폭주를 실시간으로 차단합니다. 엄밀함이 "실행"에서 "감시"로 이동하는 것입니다.

class GuardianAgent:
    def monitor(self, action):
        # 비용 한도 초과 체크
        if action.estimated_cost > self.budget_limit:
            return Block("비용 한도 초과")
        
        # 민감 데이터 접근 체크
        if action.accesses_pii and not action.has_approval:
            return Block("PII 접근에 승인 필요")
        
        # 위험 명령어 체크
        if action.contains_destructive_command:
            return EscalateToHuman(action)
        
        return Allow(action)

평가 엔지니어링 — 벤치마크 점수는 의미없다

GPT-5가 벤치마크에서 90점을 받아도, 실제 업무에서 70%만 성공할 수 있습니다. 벤치마크 점수가 아닌 실제 업무 완료율이 핵심 메트릭이 됩니다.

더 어려운 문제는 "검증 불가능한 보상"입니다. 코드의 정확성은 테스트로 검증할 수 있지만, 글의 품질이나 디자인의 미학은 어떻게 평가할까요? 이 문제를 푸는 것이 다음 패러다임의 열쇠입니다.

지식 엔진 — 코드를 이해하는 에이전트

지금의 에이전트는 "이 코드를 수정하라"는 지시를 받습니다. 미래의 에이전트는 코드 그래프, 커밋 히스토리, 설계 의도를 결합하여 "이 코드가 왜 이렇게 생겼는지 이해한 상태에서" 수정합니다.

현재	미래
"이 함수의 버그를 고쳐라"	"이 함수가 이런 의도로 작성됐고, 이 PR에서 이렇게 변경됐는데, 현재 이 부분이 원래 의도와 어긋난다"
파일 단위 컨텍스트	프로젝트 전체 의미 그래프
정적 문서 참조	동적 지식 검색

이 흐름이 자동화에 의미하는 것

AI 에이전트의 진화는 자동화 현장에도 직접적인 영향을 줍니다.

프롬프트만으로 자동화를 시도하던 시절은 지났습니다. ChatGPT에 "이 엑셀을 정리해줘"라고 말하는 것은 시작일 뿐입니다. 실제 업무 자동화에는 어떤 데이터를 언제 어떻게 넣을지(컨텍스트), 에러가 났을 때 어떻게 복구할지(하네스)까지 설계해야 합니다.

좋은 소식은, 이 설계가 점점 체계화되고 있다는 것입니다. MCP 같은 표준 프로토콜, AGENTS.md 같은 문서화 규격, Planner-Generator-Evaluator 같은 검증된 패턴이 있습니다. 2022년처럼 프롬프트를 이리저리 바꿔보며 시행착오를 겪을 필요가 없어졌습니다.

3년 전 Karpathy의 말을 다시 떠올려봅니다. 영어는 여전히 중요합니다. 하지만 이제 시스템의 일부일 뿐, 시스템 자체가 아닙니다.