Agentic Engineering
TL;DR
- Agentic Engineering Context Engineering Harness Engineering Prompt Engineering Vibe Coding ReAct Agent Loop Multi-Agent Orchestration MCP (Model Context Protocol) Tool Use Guardrails Human-in-the-Loop LangGraph CrewAI AutoGen Claude Code OpenAI Agents SDK Google ADK A2A Andrew Ng Andrej Karpathy SWE-bench AGENTS.md Observability Structural Tests Mechanical Enforcement > - ICSE 2026 AGENT Workshop - Agentic Software Engineering > - Harness Engineering - OpenAI - Codex 팀의 실전 사례 > - Harness Engineering - Martin Fowler - 비판적 분석 > - Building Effective Agents - Anthropic - 오케스트레이션 패턴 > - State of AI Agents - LangChain - 2025 산업 조사 > - Andrew Ng - Agentic Design Patterns - 4가지 에이전트 패턴 > - Andrej Karpathy - Vibe Coding, Context Engineering, Agentic Engineering 용어 > - OpenAI Agents SDK - 에이전트 프레임워크 > - Model Context Protocol - MCP 공식 문서
-
- Harness Engineering - OpenAI - Codex 팀의 실전 사례
- 원문 전체는 아래 상세 내용에 그대로 포함했다.
1. 개념
Agentic Engineering Context Engineering Harness Engineering Prompt Engineering Vibe Coding ReAct Agent Loop Multi-Agent Orchestration MCP (Model Context Protocol) Tool Use Guardrails Human-in-the-Loop LangGraph CrewAI AutoGen Claude Code OpenAI Agents SDK Google ADK A2A Andrew Ng Andrej Karpathy SWE-bench AGENTS.md Observability Structural Tests Mechanical Enforcement > - ICSE 2026 AGENT Workshop - Agentic Software Engineering > - Harness Engineering - OpenAI - Codex 팀의 실전 사례 > - Harness Engineering - Martin Fowler - 비판적 분석 > - Building Effective Agents - Anthropic - 오케스트레이션 패턴 > - State of AI Agents - LangChain - 2025 산업 조사 > - Andrew Ng - Agentic Design Patterns - 4가지 에이전트 패턴 > - Andrej Karpathy - Vibe Coding, Context Engineering, Agentic Engineering 용어 > - OpenAI Agents SDK - 에이전트 프레임워크 > - Model Context Protocol - MCP 공식 문서
2. 배경
- ICSE 2026 AGENT Workshop - Agentic Software Engineering
3. 이유
- Harness Engineering - OpenAI - Codex 팀의 실전 사례
4. 특징
- Harness Engineering - Martin Fowler - 비판적 분석
5. 상세 내용
Agentic Engineering
1. Agentic Engineering이란?
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Agentic Engineering │
│ = 인간이 목표, 제약, 품질 기준, 아키텍처를 정의하고 │
│ 자율적인 AI 에이전트가 코드를 계획, 작성, 테스트, │
│ 디버그, 반복하는 소프트웨어 엔지니어링 분야 │
│ │
│ 키워드 분해: │
│ ├── "agentic" = 개발자가 직접 코드를 쓰는 게 아니라 │
│ │ AI 에이전트를 오케스트레이션 │
│ └── "engineering" = 전문성, 방법론, 엄밀성이 필요한 │
│ 학습 가능한 기술 │
│ │
│ 학술적 정의 (ICSE 2026 AGENT Workshop): │
│ "기반 모델(LLM) 위에 구축된 목표 지향적 자율 시스템의 │
│ 설계, 개발, 운영에 초점을 맞춘 신흥 분야" │
│ │
│ 배경: │
│ ├── Andrej Karpathy가 2026년 초에 용어 대중화 │
│ ├── "vibe coding"에서 "agentic engineering"으로의 성숙 │
│ └── 엔지니어의 작업 방식 자체가 근본적으로 전환 │
│ │
│ 핵심 전환: │
│ ├── Before: 키보드로 직접 코딩 │
│ └── After: 시스템 설계 + 목표 정의 + 품질 검증 │
│ │
│ 한 줄 요약: │
│ "AI가 구현하고, 인간이 아키텍처/품질/정확성을 소유한다" │
│ │
└─────────────────────────────────────────────────────────────────┘
2. 등장 배경: 3단계 진화
Stage 1: Prompt Engineering (2020-2023)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Prompt Engineering (2020-2023) │
│ = 짧고 정확한 지시문으로 LLM에서 좋은 일회성 출력 추출 │
│ │
│ 특징: │
│ ├── "마법의 문장 찾기" — 어떤 단어 조합이 최적 결과를? │
│ ├── 대부분 단일 턴: 분류, 생성, 요약 │
│ ├── Few-shot, Chain-of-thought 등 프롬프트 기법 발전 │
│ └── 입력 텍스트 최적화에 집중 │
│ │
│ 한계: │
│ ├── 복잡한 멀티 스텝 작업에 부적합 │
│ ├── 컨텍스트 윈도우 관리 전략 부재 │
│ └── 단발성 — 장기 작업 지속 불가 │
│ │
└─────────────────────────────────────────────────────────────────┘
Stage 2: Context Engineering (2024-2025)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Context Engineering (2024-2025) │
│ = "다음 단계에 딱 맞는 정보로 컨텍스트 윈도우를 채우는 │
│ 섬세한 기술과 과학" — Andrej Karpathy (2025년 중반) │
│ │
│ 핵심 인사이트: │
│ ├── 프롬프트는 하나의 구성요소일 뿐 │
│ ├── 시스템 프롬프트, 검색 문서, 대화 기록, 도구, 예시, │
│ │ 압축 전략 전체를 관리해야 함 │
│ └── Prompt Engineering의 상위집합(superset) │
│ │
│ 5가지 구성요소: │
│ ├── 1. 적절한 "고도"로 보정된 시스템 프롬프트 │
│ ├── 2. 토큰 효율성을 위해 설계된 도구 │
│ ├── 3. 정전(canonical) 데모로 선택된 예시 │
│ ├── 4. Just-in-time 검색 전략 │
│ └── 5. 압축(compaction): 기록을 요약하여 컨텍스트 예산 확보 │
│ │
│ Prompt Engineering과의 차이: │
│ ├── Prompt Eng. → "어떤 단어를 쓸까?" │
│ └── Context Eng. → "모델이 언제 무엇을 봐야 하는가?" │
│ │
└─────────────────────────────────────────────────────────────────┘
Stage 3: Agentic Engineering (2026-현재)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Agentic Engineering (2026-현재) │
│ = 멀티 스텝, 장기 작업에서 에이전트를 사용하는 │
│ "시스템을 어떻게 구축할지" │
│ │
│ Context Engineering과의 관계: │
│ ├── Context Eng. = 컨텍스트 윈도우에 "무엇을" 넣을지 │
│ ├── Agentic Eng. = 멀티 스텝 시스템을 "어떻게" 구축할지 │
│ └── Context Eng.이 "뇌를 준비"한다면 │
│ Agentic Eng.은 "행동할 수 있는 몸을 만드는 것" │
│ │
│ 포괄 범위: │
│ ├── 에이전트 루프 설계 │
│ ├── 오케스트레이션 패턴 │
│ ├── 도구 설계 및 통합 │
│ ├── 가드레일과 안전 │
│ ├── 메모리와 상태 관리 │
│ └── 하네스(인프라) 구축 │
│ │
└─────────────────────────────────────────────────────────────────┘
진화 타임라인
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 2020 2022 2024 2025 2026 │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ GPT-3 ChatGPT Claude 3 Karpathy Karpathy │
│ 등장 등장 등장 Context Eng. Agentic Eng. │
│ 용어 제안 용어 대중화 │
│ │
│ ┌────────────────────────┐ │
│ │ Stage 1 │ │
│ │ Prompt Engineering │ "어떤 단어가 최적 출력?" │
│ │ (2020~) │ 단일 LLM 호출 최적화 │
│ └────────┬───────────────┘ │
│ ↓ │
│ ┌────────────────────────┐ │
│ │ Stage 2 │ │
│ │ Context Engineering │ "모델이 언제 무엇을 봐야?" │
│ │ (2024~) │ 컨텍스트 윈도우 전체 관리 │
│ └────────┬───────────────┘ │
│ ↓ │
│ ┌────────────────────────┐ │
│ │ Stage 3 │ │
│ │ Agentic Engineering │ "자율 시스템을 어떻게 구축?" │
│ │ (2026~) │ 전체 시스템 아키텍처 설계 │
│ └────────────────────────┘ │
│ │
│ 핵심 차이: │
│ ├── Prompt Eng. → "뭘 말하느냐" (입력 최적화) │
│ ├── Context Eng. → "뭘 보여주느냐" (정보 제공) │
│ └── Agentic Eng. → "어떤 시스템에서 일하느냐" (시스템 설계) │
│ │
└─────────────────────────────────────────────────────────────────┘
3. 관련 개념 비교
4가지 엔지니어링 분야 비교
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 개념 │ 초점 │ 범위 │ 핵심 질문 │
│ ──────────────────┼───────────────────┼─────────────┼────────── │
│ Prompt │ 최적의 지시문 │ 단일 LLM │ "어떤 │
│ Engineering │ 작성 │ 호출 │ 단어가 │
│ │ │ │ 최적 │
│ │ │ │ 출력?" │
│ ──────────────────┼───────────────────┼─────────────┼────────── │
│ Context │ 컨텍스트 윈도우 │ 단일~ │ "모델이 │
│ Engineering │ 토큰 관리 │ 멀티 턴 │ 언제 │
│ │ │ │ 무엇을 │
│ │ │ │ 봐야?" │
│ ──────────────────┼───────────────────┼─────────────┼────────── │
│ Agentic │ 목표 지향 자율 │ 전체 시스템 │ "신뢰성 │
│ Engineering │ 시스템 설계 │ 아키텍처 │ 있게 │
│ │ │ │ 동작하는 │
│ │ │ │ 시스템을 │
│ │ │ │ 어떻게?" │
│ ──────────────────┼───────────────────┼─────────────┼────────── │
│ Harness │ 에이전트를 감싸는 │ 에이전트 │ "에이전트 │
│ Engineering │ 환경/도구/제약/ │ 인프라 │ 를 생산적 │
│ │ 피드백 루프 │ │ 으로 │
│ │ │ │ 유지하는 │
│ │ │ │ 비계는?" │
│ │
│ 계층 관계: │
│ ├── Prompt Eng. ⊂ Context Eng. ⊂ Agentic Eng. │
│ └── Harness Eng. = Agentic Eng.의 인프라 구현 레이어 │
│ │
└─────────────────────────────────────────────────────────────────┘
Vibe Coding vs Agentic Engineering
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Vibe Coding vs Agentic Engineering │
│ │
│ 차원 │ Vibe Coding │ Agentic Engineering │
│ ───────────┼──────────────────────┼──────────────────────────── │
│ 접근 │ 자유로운 프롬프팅, │ 목표 분해 + │
│ │ 출력 수용 │ 명세 정의 │
│ ───────────┼──────────────────────┼──────────────────────────── │
│ 감독 │ 최소 │ 구조화된 품질 게이트 │
│ │ │ + 감사 추적 │
│ ───────────┼──────────────────────┼──────────────────────────── │
│ 테스트 │ 즉석, 비체계적 │ 포괄적 테스트 슈트 필수 │
│ ───────────┼──────────────────────┼──────────────────────────── │
│ 위험 │ 보안 허점, │ 거버넌스와 추적성 내장 │
│ │ 기술 부채 축적 │ │
│ ───────────┼──────────────────────┼──────────────────────────── │
│ 적합 │ MVP, 해커톤, 실험 │ 프로덕션 시스템, │
│ │ │ 엔터프라이즈 │
│ │
│ Andrej Karpathy의 관점: │
│ ├── Vibe Coding: "AI에게 코드를 쓰게 하고 │
│ │ 대충 작동하면 수용하는 방식" │
│ ├── 프로토타이핑에는 훌륭하나 프로덕션에는 위험 │
│ └── Agentic Engineering은 vibe coding의 │
│ "성숙하고 책임감 있는 형태" │
│ │
└─────────────────────────────────────────────────────────────────┘
4. 5가지 핵심 원칙
원칙 1: Planning First (계획 우선)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 원칙 1: Planning First (계획 우선) │
│ │
│ "아키텍처를 생각하라, 분위기(vibes)가 아니라" │
│ │
│ 실천: │
│ ├── 에이전트 프롬프트 전에 설계 문서와 명세서로 작업 분해 │
│ ├── plan.md, AGENTS.md 등 사전 문서화 │
│ └── 에이전트가 "무엇을, 왜, 어떤 순서로" 해야 하는지 명확화 │
│ │
│ OpenAI의 ExecPlan: │
│ ├── "초보자도 읽을 수 있는 수준의 자립형 설계 문서" │
│ ├── 에이전트에게 작업 전에 계획서를 먼저 작성하게 함 │
│ └── 계획 → 검토 → 승인 → 구현 순서 │
│ │
│ 왜 중요한가: │
│ ├── 에이전트가 방향 없이 코드를 쏟아내는 것 방지 │
│ ├── 복잡한 태스크를 관리 가능한 단위로 분해 │
│ └── 인간이 실행 전에 방향을 검증할 기회 확보 │
│ │
└─────────────────────────────────────────────────────────────────┘
원칙 2: Human-Owned Architecture (인간이 아키텍처 소유)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 원칙 2: Human-Owned Architecture │
│ │
│ "AI가 구현하고, 인간이 아키텍처/품질/정확성을 소유한다" │
│ │
│ 개발자 역할 전환: │
│ ├── Before: 코드를 직접 작성 │
│ └── After: 시스템 설계, 목표/가드레일 정의, 출력 검증 │
│ │
│ 인간이 소유해야 하는 것: │
│ ├── 시스템 아키텍처 결정 │
│ ├── 모듈 간 인터페이스 정의 │
│ ├── 비기능 요구사항 (성능, 보안, 확장성) │
│ ├── 기술 스택 선택 │
│ └── 최종 품질 판단 │
│ │
│ 에이전트에게 위임 가능한 것: │
│ ├── 구현 세부사항 │
│ ├── 테스트 코드 작성 │
│ ├── 리팩토링 실행 │
│ └── 문서 생성 │
│ │
│ 핵심 메시지: │
│ "에이전트는 점점 더 많이 코딩하지만, │
│ 아키텍처 결정은 인간의 영역으로 남는다" │
│ │
└─────────────────────────────────────────────────────────────────┘
원칙 3: Testing as Core Differentiator (테스트가 핵심 차별점)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 원칙 3: Testing as Core Differentiator │
│ │
│ "Agentic Engineering과 Vibe Coding의 │
│ 가장 큰 차별점은 테스트" │
│ │
│ 논리: │
│ ├── 견고한 테스트 슈트가 있어야 │
│ ├── 에이전트가 테스트 통과할 때까지 반복 가능 │
│ └── 테스트 슈트 = 정확성 오라클(oracle) │
│ → 안전한 위임의 핵심 조건 │
│ │
│ 테스트의 역할 변화: │
│ ├── 전통적: 코드 작성 후 검증 │
│ └── Agentic: 코드 작성 전 명세 — 에이전트의 "합격 기준" │
│ │
│ 에이전트 + 테스트 워크플로우: │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ 테스트│ → │ 구현 │ → │ 실행 │ → │ 통과?│ │
│ │ 작성 │ │ │ │ 테스트│ │ │ │
│ └──────┘ └──────┘ └──────┘ └──┬───┘ │
│ No ↓ ↓ Yes │
│ ┌──────┐ ┌──────┐ │
│ │ 수정 │ │ 완료 │ │
│ └──┬───┘ └──────┘ │
│ └─→ (반복) │
│ │
│ 테스트 없는 에이전트 코딩 = Vibe Coding │
│ 테스트 있는 에이전트 코딩 = Agentic Engineering │
│ │
└─────────────────────────────────────────────────────────────────┘
원칙 4: Transparency and Observability (투명성과 관찰성)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 원칙 4: Transparency and Observability │
│ │
│ 에이전트 추론의 모든 단계가 가시적이어야 한다 │
│ │
│ 근거 (LangChain 조사, 2025): │
│ ├── 프로덕션 에이전트 팀 89%가 관찰성 구현 │
│ ├── 62%가 단계별 추적(step-by-step tracing) │
│ └── 관찰성 없는 에이전트 = 블랙박스 → 디버깅 불가 │
│ │
│ 관찰성의 3가지 축: │
│ ├── 1. Tracing: 각 에이전트 스텝의 입출력 기록 │
│ ├── 2. Logging: 구조화된 로그로 의사결정 추적 │
│ └── 3. Metrics: 토큰 사용, 지연, 성공률 측정 │
│ │
│ 인간이 할 수 있어야 하는 것: │
│ ├── 감사(audit): 모든 에이전트 행동 사후 검토 │
│ ├── 리플레이(replay): 실패한 실행 재현 │
│ └── 이해: 왜 그런 결정을 했는지 추론 가능 │
│ │
│ OpenAI의 교훈: │
│ "에이전트에게 눈을 줘라" │
│ → DOM 스냅샷, 스크린샷, 로그, 메트릭을 에이전트가 볼 수 있게 │
│ │
└─────────────────────────────────────────────────────────────────┘
원칙 5: Mechanical Enforcement (기계적 강제)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 원칙 5: Mechanical Enforcement │
│ │
│ 아키텍처 규칙을 린터, 구조적 테스트, CI 체크로 인코딩 │
│ │
│ 왜 문서화만으로는 불충분한가: │
│ ├── 에이전트가 문서를 읽을 수도, 안 읽을 수도 있음 │
│ ├── 수천 개의 에이전트 기여에 걸쳐 일관성 유지 불가 │
│ └── 런타임에 제약을 강제할 수 없음 │
│ │
│ 기계적 강제 수단: │
│ ├── Custom Linters: 팀/프로젝트 규칙을 코드로 강제 │
│ ├── Structural Tests: 의존성 방향, 모듈 경계 검증 │
│ ├── CI Validation: 린터 + 구조 테스트를 파이프라인에 통합 │
│ └── Pre-commit Hooks: 커밋 시점에 규칙 위반 차단 │
│ │
│ 비유: │
│ ├── 문서 = "여기서 과속하지 마세요" 표지판 │
│ └── 기계적 강제 = 과속 카메라 + 자동 벌금 │
│ │
└─────────────────────────────────────────────────────────────────┘
5. 핵심 기술 개념
5-1. Agent Loop (에이전트 루프)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Agent Loop = 에이전트의 기본 실행 사이클 │
│ │
│ 기본 패턴: │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 환경 관찰 │ → │ 추론 │ → │ 행동 선택│ │
│ └──────────┘ └──────────┘ └────┬─────┘ │
│ ↑ ↓ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 결과 관찰│ ←──────────── │ 도구 실행 │ │
│ └──────────┘ └──────────┘ │
│ └─────→ (목표 달성까지 반복) │
│ │
│ ReAct 패턴 (Reasoning + Acting, Yao et al., 2022): │
│ ├── 언어 추론(reasoning)과 도구 실행(acting)을 인터리빙 │
│ ├── Thought → Action → Observation → ... 반복 │
│ └── Chain-of-thought만으로는 환각 위험 │
│ → 도구 결과로 그라운딩하여 환각 감소 │
│ │
│ ReAct 실행 예시: │
│ ├── Thought: "사용자의 파일에서 버그를 찾아야 한다" │
│ ├── Action: read_file("src/main.py") │
│ ├── Observation: [파일 내용 반환] │
│ ├── Thought: "37번째 줄에 off-by-one 에러가 있다" │
│ ├── Action: edit_file("src/main.py", ...) │
│ ├── Observation: [파일 수정 완료] │
│ ├── Thought: "수정이 맞는지 테스트해야 한다" │
│ ├── Action: run_tests() │
│ └── Observation: "All tests passed" │
│ │
└─────────────────────────────────────────────────────────────────┘
5-2. 오케스트레이션 패턴
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Anthropic의 5가지 오케스트레이션 패턴 │
│ │
│ 1. Prompt Chaining (프롬프트 체이닝) │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │LLM 1│ → │Gate │ → │LLM 2│ → │Gate │ → ... │
│ └─────┘ └─────┘ └─────┘ └─────┘ │
│ ├── 순차적 LLM 호출 │
│ ├── 각 호출이 이전 출력을 처리 │
│ └── 게이트(Gate)로 중간 결과 검증 후 진행 │
│ │
│ 2. Routing (라우팅) │
│ ┌──────────┐ │
│ │ LLM 분류기│ │
│ └────┬─────┘ │
│ ┌───────┼───────┐ │
│ ↓ ↓ ↓ │
│ ┌──────────┐ ┌──────┐ ┌──────┐ │
│ │전문가 A │ │전문가B│ │전문가C│ │
│ └──────────┘ └──────┘ └──────┘ │
│ ├── LLM 분류기가 입력 유형 판별 │
│ └── 전문 하류 에이전트로 라우팅 │
│ │
│ 3. Parallelization (병렬화) │
│ ├── Sectioning: 독립 서브태스크 병렬 실행 │
│ │ ┌──────┐ │
│ │ │태스크│ → ┌─────┐ + ┌─────┐ + ┌─────┐ → 합산 │
│ │ └──────┘ │서브A│ │서브B│ │서브C│ │
│ │ └─────┘ └─────┘ └─────┘ │
│ └── Voting: 같은 태스크를 복수 실행 후 합산 │
│ ┌──────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │태스크│ → │LLM 1│ │LLM 2│ │LLM 3│ → 다수결 │
│ └──────┘ └─────┘ └─────┘ └─────┘ │
│ │
│ 4. Orchestrator-Workers (오케스트레이터-워커) │
│ ┌────────────────┐ │
│ │ Orchestrator │ │
│ │ (중앙 분해) │ │
│ └───┬────┬───┬──┘ │
│ ↓ ↓ ↓ │
│ ┌────┐┌────┐┌────┐ │
│ │W(1)││W(2)││W(3)│ │
│ └──┬─┘└──┬─┘└──┬─┘ │
│ └─────┼─────┘ │
│ ↓ │
│ ┌────────────────┐ │
│ │ 합성(Synthesis)│ │
│ └────────────────┘ │
│ ├── 중앙 오케스트레이터가 동적으로 분해/위임 │
│ └── 결과를 합성하여 최종 출력 생성 │
│ │
│ 5. Evaluator-Optimizer (평가자-최적화자) │
│ ┌──────┐ ┌──────┐ │
│ │생성자│ → │평가자│ → 승인? → Yes → 완료 │
│ │ LLM │ ← │ LLM │ No ↩ │
│ └──────┘ └──────┘ │
│ ├── 생성자 LLM이 출력 생성 │
│ ├── 평가자 LLM이 품질 평가 │
│ └── 평가자 승인까지 생성-평가 반복 │
│ │
└─────────────────────────────────────────────────────────────────┘
5-3. Andrew Ng의 4가지 에이전트 디자인 패턴
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Andrew Ng의 4가지 에이전트 디자인 패턴 (2024) │
│ │
│ 1. Reflection (반성) │
│ ├── 에이전트가 자기 출력을 비판하고 반복 개선 │
│ ├── 자체 리뷰 → 피드백 → 수정 → 재리뷰 사이클 │
│ └── 단순하지만 효과적 — 코드 품질 크게 향상 │
│ │
│ 2. Tool Use (도구 사용) │
│ ├── API 호출, 웹 검색, 코드 실행, 파일 접근 │
│ ├── 에이전트에게 "손"을 주는 것 │
│ └── 현실 세계와 상호작용하는 능력 부여 │
│ │
│ 3. Planning (계획) │
│ ├── 복잡한 태스크를 단계로 분해 │
│ ├── 실행 순서 결정, 의존성 관리 │
│ └── 장기 작업에서 방향 유지의 핵심 │
│ │
│ 4. Multi-Agent Collaboration (멀티 에이전트 협업) │
│ ├── 전문 에이전트들이 협업, 토론, 분업 │
│ ├── 각 에이전트가 고유 역할과 전문성 보유 │
│ └── 복잡한 문제를 전문가 팀처럼 해결 │
│ │
│ 조합의 힘: │
│ ├── 각 패턴을 단독으로 사용해도 효과적 │
│ └── 조합하면 시너지: 예) Multi-Agent + Tool Use + Planning │
│ → 전문 에이전트 팀이 도구를 사용하며 │
│ 계획적으로 복잡한 프로젝트를 수행 │
│ │
└─────────────────────────────────────────────────────────────────┘
5-4. 메모리와 상태 관리
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 에이전트의 메모리 체계 │
│ │
│ 유형 │ 저장 내용 │ 구현 방식 │
│ ───────────────┼──────────────────────┼──────────────────────── │
│ Working │ 활성 컨텍스트, │ 컨텍스트 윈도우 │
│ Memory │ 현재 태스크 상태 │ (단기, 휘발성) │
│ ───────────────┼──────────────────────┼──────────────────────── │
│ Episodic │ 과거 경험, 궤적, │ 벡터 스토어, │
│ Memory │ 성공/실패 이력 │ 검색 가능한 기록 │
│ ───────────────┼──────────────────────┼──────────────────────── │
│ Semantic │ 사실, 도메인 지식, │ RAG + 지식 베이스 │
│ Memory │ 개념 │ │
│ ───────────────┼──────────────────────┼──────────────────────── │
│ Procedural │ 스킬, 정책, │ 시스템 프롬프트, │
│ Memory │ 행동 방법 │ CLAUDE.md, 도구 정의 │
│ │
│ 핵심 과제: │
│ ├── 컨텍스트 윈도우는 유한한 자원 │
│ ├── 컨텍스트 길이 증가 시 수익 체감 (성능 저하) │
│ └── "적절한 정보를 적절한 시점에" 제공해야 함 │
│ │
│ 해결 전략: │
│ ├── 압축(Compaction): 기록을 요약하여 토큰 절약 │
│ ├── Just-in-time 검색: 필요할 때만 관련 정보 가져오기 │
│ ├── 구조화된 노트 테이킹: 핵심 결정/발견을 명시적 기록 │
│ └── 멀티에이전트 분산: 각 에이전트가 자기 컨텍스트만 관리 │
│ │
└─────────────────────────────────────────────────────────────────┘
5-5. 도구 사용 (Tool Use)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Tool Use = 에이전트에게 "손"을 주는 것 │
│ │
│ 도구의 종류: │
│ ├── 파일 시스템: 읽기, 쓰기, 검색 │
│ ├── 코드 실행: 터미널, REPL, 테스트 러너 │
│ ├── 웹 검색: 문서 검색, API 호출 │
│ ├── 데이터베이스: 쿼리, 스키마 조회 │
│ └── 외부 서비스: CI/CD, 모니터링, 배포 │
│ │
│ 도구 설계 원칙: │
│ ├── 1. 인지 부하 최소화: 도구 수를 필요 최소로 유지 │
│ ├── 2. 기능 중복 방지: 비슷한 도구 → 에이전트 혼란 │
│ ├── 3. 철저한 문서화: 도구 이름, 파라미터, 반환값 명확히 │
│ └── 4. 사용 오류 테스트: 에이전트가 잘못 사용할 경우 대비 │
│ │
│ MCP (Model Context Protocol): │
│ ├── Anthropic이 2024년 11월 출시 │
│ ├── AI 모델과 외부 도구/데이터 소스의 표준 연결 프로토콜 │
│ ├── OpenAI, Google, Microsoft 등 주요 기업 채택 │
│ ├── 2025년 12월 Linux Foundation AAIF에 기부 │
│ └── "USB-C of AI" — 도구 연결의 표준화 │
│ │
│ MCP 아키텍처: │
│ ┌────────┐ MCP ┌────────────┐ │
│ │AI Model│ ←──────→ │ MCP Server │ │
│ │(Client)│ Protocol │ (Tool/Data)│ │
│ └────────┘ └────────────┘ │
│ ├── Client: AI 모델이 도구를 호출 │
│ ├── Server: 특정 기능/데이터를 제공 │
│ └── Protocol: 표준화된 JSON-RPC 기반 통신 │
│ │
└─────────────────────────────────────────────────────────────────┘
5-6. 가드레일과 안전
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 에이전트 안전의 3가지 축 │
│ │
│ 1. Guardrails (가드레일) │
│ ├── 유해하거나 범위를 벗어난 행동 방지 │
│ ├── 실시간 정책 강제 │
│ ├── 입력 가드레일: 악성/부적절 입력 필터링 │
│ └── 출력 가드레일: 생성 결과의 안전성 검증 │
│ │
│ 2. Permissions (권한) │
│ ├── 에이전트 권한의 정확한 경계 설정 │
│ ├── 최소 권한 원칙 (Principle of Least Privilege) │
│ ├── 파일 시스템: 읽기 전용 vs 읽기/쓰기 │
│ └── 네트워크: 허용된 도메인만 접근 가능 │
│ │
│ 3. Auditability (감사 가능성) │
│ ├── 완전한 추적성 — 모든 행동 로깅 │
│ ├── 누가, 언제, 왜 어떤 행동을 했는지 재구성 가능 │
│ └── 사후 분석과 개선에 필수 │
│ │
│ ─────────────────────────────────────────────────────────────── │
│ │
│ 핵심 위협: Indirect Prompt Injection │
│ ├── 외부 콘텐츠(웹페이지, 문서, 이메일)에 숨겨진 악성 지시 │
│ ├── 에이전트가 외부 데이터를 처리할 때 악성 지시를 실행 │
│ ├── 에이전트 행동을 탈취할 수 있는 가장 위험한 취약점 │
│ └── 방어: 입력 검증, 권한 제한, 행동 모니터링 │
│ │
│ ─────────────────────────────────────────────────────────────── │
│ │
│ Human-in-the-Loop (HITL) 패턴: │
│ ├── 모든 행동에 인간 승인 → 비효율적, 비현실적 │
│ ├── 해결: 가장 위험한 약 2%의 행동에만 경량 HITL │
│ │ │
│ │ ┌──────────┐ │
│ │ │에이전트 │ → 행동 의도 │
│ │ │행동 요청 │ │
│ │ └────┬─────┘ │
│ │ ↓ │
│ │ ┌──────────┐ │
│ │ │ 위험도 │ → 저위험 → 자동 승인 │
│ │ │ 판별기 │ → 고위험 → 인간 확인 필요 │
│ │ └──────────┘ │
│ │ │
│ ├── 모든 에이전트 행동을 실행 전 가로채는 미들웨어 │
│ └── 저위험 자동 승인, 고위험 인간 확인 │
│ │
└─────────────────────────────────────────────────────────────────┘
6. Harness Engineering (OpenAI)
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Harness Engineering — OpenAI (2026년 초 랜드마크 문서) │
│ │
│ 실적: │
│ ├── 3명의 엔지니어로 약 100만 줄의 프로덕션 코드 작성 │
│ ├── 엔지니어당 일일 평균 3.5 PR │
│ ├── 모두 에이전트 생성, 수작업 코드 없음 │
│ └── Codex 에이전트를 활용한 실제 대규모 프로젝트 │
│ │
│ 정의: │
│ 하네스 = "에이전트를 생산적이고 올바른 궤도에 유지하는 │
│ 제약, 도구, 문서, 피드백 루프의 집합" │
│ │
│ 비유: │
│ ├── 추론 모델(LLM)이 뇌라면 │
│ └── 하네스가 손과 발 │
│ → 뇌가 아무리 좋아도 손발 없이는 일을 못 한다 │
│ │
└─────────────────────────────────────────────────────────────────┘
Martin Fowler의 3가지 분해
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Martin Fowler (Birgitta Boeckeler)의 Harness 분해 │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ HARNESS │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │
│ │ │ 1. Context │ │ 2. Arch. │ │ 3. Garbage│ │ │
│ │ │ Engineering │ │ Constraints │ │ Collection│ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ 에이전트가 │ │ 에이전트가 │ │ 에이전트가│ │ │
│ │ │ 보는 것 │ │ 할 수 있는 것│ │ 만든 잔재 │ │ │
│ │ │ │ │ │ │ 정리 │ │ │
│ │ └──────────────┘ └──────────────┘ └───────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 1. Context Engineering (에이전트가 보는 것) │
│ ├── AGENTS.md: ~100줄의 코드베이스 지도 │
│ ├── docs/ 디렉토리: 단일 진실 소스 │
│ └── 환경 정보, 도구 문서, 관찰성 데이터 │
│ │
│ 2. Architectural Constraints (에이전트가 할 수 있는 것) │
│ ├── Custom linters: 팀 규칙을 코드로 강제 │
│ ├── Structural tests: 의존성 방향 검증 │
│ └── CI validation: 자동화된 아키텍처 준수 검사 │
│ │
│ 3. Garbage Collection (에이전트가 만든 잔재 정리) │
│ ├── 문서-코드 불일치 자동 감지 │
│ ├── 아키텍처 위반 주기적 스캔 │
│ └── 기술 부채 모니터링 및 정리 │
│ │
└─────────────────────────────────────────────────────────────────┘
OpenAI의 5가지 원칙
┌─────────────────────────────────────────────────────────────────┐
│ │
│ OpenAI의 Harness Engineering 5가지 원칙 │
│ │
│ 원칙 1: "에이전트가 볼 수 없으면 존재하지 않는다" │
│ ├── 모든 결정, 계획, 아키텍처를 레포 내 마크다운으로 │
│ ├── 암묵적 지식 = 에이전트에게는 없는 지식 │
│ └── 구전 전통(oral tradition)을 문서로 변환 │
│ │
│ 원칙 2: "에이전트가 왜 실패하는지가 아니라 │
│ 어떤 능력이 부족한지 물어라" │
│ ├── 에이전트 실패 = 환경의 문제 │
│ ├── 환경을 계기화(instrument)하여 부족한 것 파악 │
│ └── 에이전트를 탓하지 않고 하네스를 개선 │
│ │
│ 원칙 3: "문서화보다 기계적 강제" │
│ ├── 린터와 구조적 테스트로 아키텍처 규칙 자동 강제 │
│ ├── 문서만으로는 에이전트가 무시할 수 있음 │
│ └── 코드로 인코딩된 규칙은 위반 불가능 │
│ │
│ 원칙 4: "에이전트에게 눈을 줘라" │
│ ├── DOM 스냅샷, 스크린샷, 로그, 메트릭 접근 제공 │
│ ├── 에이전트가 자기 행동의 결과를 직접 관찰 │
│ └── 관찰 → 추론 → 수정의 자율 사이클 가능 │
│ │
│ 원칙 5: "매뉴얼이 아닌 지도" │
│ ├── 간결한 아키텍처 개요 제공 │
│ ├── 각 레이어에 "존재하지 않는 것"도 정의 │
│ └── 거대한 지시서 대신 ~100줄의 포인터 모음 │
│ │
│ ─────────────────────────────────────────────────────────────── │
│ │
│ Agentic Engineering과의 관계: │
│ ├── Harness Engineering은 Agentic Engineering의 │
│ │ 하위 분야이자 구현 레이어 │
│ ├── Agentic Eng. = "무엇을 만들 것인가" (시스템 설계) │
│ └── Harness Eng. = "어떻게 만들 것인가" (인프라 구축) │
│ │
└─────────────────────────────────────────────────────────────────┘
7. 주요 프레임워크와 도구
프레임워크 비교
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 주요 에이전트 프레임워크 비교 │
│ │
│ 프레임워크 │ 아키텍처 │ 적합한 상황 │ 복잡도 │
│ ───────────────┼──────────────────┼─────────────────┼────────── │
│ LangGraph │ 상태 유지 그래프 │ 복잡한 프로덕션 │ 중-상 │
│ │ │ 워크플로우 │ │
│ ───────────────┼──────────────────┼─────────────────┼────────── │
│ CrewAI │ 역할 기반 크루 │ 빠른 프로토 │ 저-중 │
│ │ │ 타이핑, 구조화 │ │
│ │ │ 된 태스크 │ │
│ ───────────────┼──────────────────┼─────────────────┼────────── │
│ AutoGen 0.4 │ 이벤트 드리븐 │ 감사 가능한 │ 중-상 │
│ │ 메시징 │ 대화형 시스템 │ │
│ ───────────────┼──────────────────┼─────────────────┼────────── │
│ OpenAI │ 프리미티브 기반 │ 범용, 공급자 │ 저-중 │
│ Agents SDK │ (agents, │ 비의존 │ │
│ │ handoffs, │ │ │
│ │ guardrails) │ │ │
│ ───────────────┼──────────────────┼─────────────────┼────────── │
│ Claude Code │ 파일시스템/ │ 코딩 에이전트, │ 중 │
│ + Agent SDK │ 터미널 접근 │ 오케스트레이션 │ │
│ │ + MCP │ │ │
│ ───────────────┼──────────────────┼─────────────────┼────────── │
│ Google ADK │ 크로스 프레임 │ 엔터프라이즈 │ 중 │
│ + A2A │ 워크 상호운용 │ 멀티벤더 │ │
│ │
└─────────────────────────────────────────────────────────────────┘
프레임워크별 상세 설명
┌─────────────────────────────────────────────────────────────────┐
│ │
│ LangGraph (LangChain) │
│ ├── 상태 머신 기반의 에이전트 워크플로우 그래프 │
│ ├── 노드 = 에이전트/함수, 엣지 = 전환 조건 │
│ ├── 체크포인팅, 브랜칭, 인간 개입 지점 내장 │
│ ├── LangSmith와 통합된 관찰성 │
│ └── 가장 성숙한 프로덕션급 프레임워크 │
│ │
│ CrewAI │
│ ├── 역할(Role), 목표(Goal), 백스토리(Backstory)로 에이전트 정의│
│ ├── 직관적인 멀티에이전트 협업 모델 │
│ ├── 태스크 기반 워크플로우 │
│ └── 빠른 프로토타이핑에 최적화 │
│ │
│ AutoGen 0.4 (Microsoft) │
│ ├── 이벤트 드리븐 아키텍처로 전면 재설계 │
│ ├── 에이전트 간 비동기 메시지 패싱 │
│ ├── 대화 기록의 완전한 감사 추적 │
│ └── 그룹 채팅, 중재자(Mediator) 패턴 지원 │
│ │
│ OpenAI Agents SDK │
│ ├── 3가지 핵심 프리미티브: Agent, Handoff, Guardrail │
│ ├── Agent: 지시, 도구, 가드레일이 포함된 LLM │
│ ├── Handoff: 에이전트 간 제어 이전 │
│ ├── Guardrail: 입/출력 검증 │
│ └── 공급자 비의존적 설계 (다른 LLM도 사용 가능) │
│ │
│ Claude Code + Agent SDK (Anthropic) │
│ ├── 파일시스템, 터미널, 브라우저 직접 접근 │
│ ├── MCP를 통한 외부 도구 연결 │
│ ├── /oh-my-claudecode 같은 오케스트레이션 레이어 │
│ └── 코딩 에이전트 영역에서 가장 강력한 도구 │
│ │
│ Google ADK + A2A │
│ ├── ADK: Agent Development Kit — 에이전트 개발 프레임워크 │
│ ├── A2A: Agent-to-Agent — 크로스 프레임워크 에이전트 통신 │
│ ├── 벤더 중립적 멀티에이전트 상호운용 │
│ └── 엔터프라이즈 환경에서 이기종 에이전트 통합 │
│ │
└─────────────────────────────────────────────────────────────────┘
8. 프로덕션 현황 (2025-2026 데이터)
LangChain 조사 결과
┌─────────────────────────────────────────────────────────────────┐
│ │
│ LangChain State of AI Agents 조사 (1,340명, 2025) │
│ │
│ 배포 현황: │
│ ├── 57.3%의 조직이 에이전트를 프로덕션에 배포 │
│ ├── 대기업(10,000+ 직원) 67%가 프로덕션 사용 │
│ └── 전년 대비 급격한 채택 증가 │
│ │
│ 최대 장벽: │
│ ├── 품질/정확성: 32% (가장 큰 장벽) │
│ ├── 보안: 24.9% │
│ ├── 지연(Latency): 20% │
│ └── 비용: 그 외 │
│ │
│ 관찰성: │
│ ├── 89%가 관찰성 구현 │
│ ├── 62%가 단계별 추적(step-by-step tracing) │
│ └── 관찰성 = 프로덕션 에이전트의 기본 요구사항 │
│ │
│ 모델 사용: │
│ ├── 76%+ 여러 모델을 혼합 사용 │
│ └── 태스크 복잡도에 따라 모델 선택 (haiku/sonnet/opus 등) │
│ │
│ 주요 용도: │
│ ├── 고객 서비스: 26.5% │
│ ├── 연구/데이터 분석: 24.4% │
│ └── 내부 워크플로우 자동화: 18% │
│ │
└─────────────────────────────────────────────────────────────────┘
산업 전반 데이터
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 산업 전반 에이전트 AI 현황 (2025-2026) │
│ │
│ 채택 현황: │
│ ├── 62% 기업이 에이전트 AI 실험 중 │
│ ├── 그러나 14%만 프로덕션 준비 완료 │
│ └── 실험 → 프로덕션 전환에 큰 격차 존재 │
│ │
│ 실패 원인: │
│ ├── 2025년 기업 AI 실패의 51%가 RAG 관련 │
│ ├── RAG without reranking → 품질 저하의 주범 │
│ └── 검색 품질 = 에이전트 품질의 기반 │
│ │
│ 멀티에이전트 현실: │
│ ├── 5개 에이전트 초과 시 │
│ │ 75%+ 멀티에이전트 시스템 관리 어려움 │
│ ├── 에이전트 수 증가 → 복잡도 기하급수적 증가 │
│ └── "단순하게 시작" 원칙의 중요성 재확인 │
│ │
│ 코딩 에이전트 데이터: │
│ ├── SWE-bench: 최고 성능 에이전트 72% 달성 │
│ ├── OpenAI Codex 팀: 3.5 PR/엔지니어/일 │
│ ├── 84%가 AI 코딩 도구 사용 │
│ └── 그러나 3%만 높은 신뢰도로 사용 │
│ │
│ 교훈: │
│ ├── 에이전트 기술은 이미 프로덕션 수준 │
│ ├── 그러나 신뢰와 거버넌스가 병목 │
│ └── Agentic Engineering의 원칙이 이 격차를 해소 │
│ │
└─────────────────────────────────────────────────────────────────┘
9. 베스트 프랙티스 vs 안티패턴
베스트 프랙티스
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 8가지 베스트 프랙티스 │
│ │
│ 1. 단순하게 시작, 복잡성을 의도적으로 확대 │
│ ├── Anthropic: "가장 단순한 해결책을 먼저 시도하라" │
│ ├── 단일 에이전트로 시작 → 필요 시에만 멀티에이전트로 │
│ └── 5개 에이전트 초과 = 관리 불가 위험 구간 │
│ │
│ 2. 코딩 전에 명세와 계획 작성 │
│ ├── plan.md, AGENTS.md 등 사전 문서화 │
│ ├── 에이전트에게 방향과 제약을 명확히 전달 │
│ └── "코딩은 계획의 실행일 뿐" │
│ │
│ 3. 에이전트와 테스트 우선 개발 │
│ ├── 테스트 슈트를 먼저 작성 │
│ ├── 테스트 슈트 = 정확성 오라클 │
│ └── 에이전트가 테스트 통과까지 반복하게 함 │
│ │
│ 4. 아키텍처를 기계적으로 잠금 │
│ ├── 린터, CI, 구조적 테스트로 규칙 강제 │
│ ├── 문서만으로는 에이전트가 무시 가능 │
│ └── 코드로 인코딩된 규칙만이 확실 │
│ │
│ 5. Day 1부터 관찰성 구축 │
│ ├── Tracing, Logging, Metrics를 처음부터 포함 │
│ ├── 나중에 추가하면 이미 디버깅 불가능한 상황 발생 │
│ └── "관찰성은 나중에"는 안티패턴 │
│ │
│ 6. 도구에 최소 권한 원칙 적용 │
│ ├── 에이전트가 필요한 최소 권한만 부여 │
│ ├── 파일 시스템: 작업 디렉토리만 접근 │
│ └── 네트워크: 필요한 엔드포인트만 허용 │
│ │
│ 7. 장기 워크플로우에 체크포인트 삽입 │
│ ├── 긴 작업의 중간 상태를 저장 │
│ ├── 실패 시 처음부터 재시작 방지 │
│ └── 비용과 시간 절약 │
│ │
│ 8. 컨텍스트를 능동적으로 관리 │
│ ├── 압축(compaction): 기록 요약으로 토큰 절약 │
│ ├── JIT 검색: 필요할 때만 관련 정보 가져오기 │
│ └── 구조화된 노트 테이킹: 핵심 결정을 명시적 기록 │
│ │
└─────────────────────────────────────────────────────────────────┘
안티패턴
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 8가지 안티패턴 (피해야 할 것) │
│ │
│ 1. 에이전트 출력 과신 │
│ ├── 84%가 AI 코딩 도구를 사용하지만 │
│ ├── 3%만 높은 신뢰도로 사용 │
│ └── 항상 검증: "신뢰하되 확인하라" │
│ │
│ 2. Agent Sprawl (에이전트 난립) │
│ ├── 5개 에이전트 초과 시 75%+ 관리 불가 │
│ ├── 에이전트 수 ≠ 성능 │
│ └── 적은 수의 잘 설계된 에이전트가 더 효과적 │
│ │
│ 3. 거버넌스를 문서에만 의존 │
│ ├── 코드로 인코딩하지 않으면 런타임에 제약 불가 │
│ ├── "이렇게 하세요" 문서 → 에이전트가 무시 가능 │
│ └── 린터 + CI + 구조적 테스트로 강제해야 │
│ │
│ 4. Indirect Prompt Injection 무시 │
│ ├── 외부 데이터를 처리하는 에이전트의 가장 큰 위협 │
│ ├── 악성 지시가 에이전트 행동을 탈취 │
│ └── 입력 검증, 권한 제한, 샌드박싱 필수 │
│ │
│ 5. RAG without reranking │
│ ├── 2025년 기업 AI 실패의 51%가 RAG 관련 │
│ ├── 검색 결과를 그대로 전달 → 노이즈 포함 │
│ └── Reranking, 필터링, 관련성 점수 적용 필수 │
│ │
│ 6. 타임아웃 없이 에이전트 실행 │
│ ├── 무한 루프 위험 — 비용과 시간 소모 │
│ ├── "doom loop": 같은 실패를 반복하는 패턴 │
│ └── 반드시 타임아웃과 루프 감지 메커니즘 적용 │
│ │
│ 7. 평가(evals) 없이 배포 │
│ ├── "동작하는 것 같다" ≠ "정확하다" │
│ ├── 체계적인 평가 파이프라인 필수 │
│ └── 회귀 테스트, 벤치마크, A/B 테스트 활용 │
│ │
│ 8. 불안정한/니치한 기술 위에 구축 │
│ ├── 에이전트는 학습 데이터에 기반하여 코드 생성 │
│ ├── 학습 데이터가 부족한 기술 → 에이전트 성능 저하 │
│ └── 주류 기술 스택이 에이전트 친화적 │
│ │
└─────────────────────────────────────────────────────────────────┘
10. 실제 활용 사례
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 도메인별 에이전트 활용 현황 │
│ │
│ 도메인 │ 활용 사례 │ 성과 │
│ ────────────────┼────────────────────────┼────────────────────── │
│ 소프트웨어 │ Claude Code, Copilot, │ SWE-bench 72%, │
│ 엔지니어링 │ Cursor, Codex │ 3.5 PR/엔지니어/일 │
│ │ 자율 코딩 에이전트 │ │
│ ────────────────┼────────────────────────┼────────────────────── │
│ 고객 서비스 │ 자율 지원 해결, │ 비용 60% 절감, │
│ │ 멀티채널 응대 │ 2029년까지 80% │
│ │ │ 자율 해결 예측 │
│ ────────────────┼────────────────────────┼────────────────────── │
│ 금융 │ KYC 자동화, │ 지속적 모니터링으로 │
│ │ 신용 평가, │ 수동 리뷰 대체 │
│ │ 컴플라이언스 │ │
│ ────────────────┼────────────────────────┼────────────────────── │
│ 의료 │ 임상 워크플로우, │ 멀티 스텝 행정 │
│ │ 문서화 자동화 │ 워크플로우 지원 │
│ ────────────────┼────────────────────────┼────────────────────── │
│ 법률 │ 문서 검토, │ 엔터프라이즈 │
│ │ 계약 분석, │ 법무팀에서 │
│ │ 판례 조사 │ 활발히 활용 중 │
│ │
│ 소프트웨어 엔지니어링 상세: │
│ ├── OpenAI Codex: 3명 → 100만 줄, 에이전트가 모든 코드 작성 │
│ ├── Claude Code: 파일시스템/터미널 직접 접근, MCP 통합 │
│ ├── GitHub Copilot: 인라인 코드 완성 → 에이전트 모드 확장 │
│ └── Cursor: IDE 내장 에이전트, 컨텍스트 인식 코딩 │
│ │
│ 고객 서비스 상세: │
│ ├── Gartner: 2029년까지 고객 서비스 상호작용 80% │
│ │ AI 에이전트가 자율 해결 예측 │
│ ├── 현재: 티켓 분류, FAQ 자동 응답, 감정 분석 │
│ └── 미래: 복잡한 문제도 에이전트가 자율 해결 │
│ │
│ 금융 상세: │
│ ├── KYC(Know Your Customer): 서류 검증 자동화 │
│ ├── 실시간 거래 모니터링과 이상 탐지 │
│ └── 규제 보고서 자동 생성 │
│ │
└─────────────────────────────────────────────────────────────────┘
11. 정리
핵심 요약
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Agentic Engineering 핵심 요약 │
│ │
│ 정의: │
│ AI 에이전트가 자율적으로 멀티 스텝 태스크를 실행하는 │
│ 시스템을 설계하고 운영하는 소프트웨어 엔지니어링 분야 │
│ │
│ 진화 경로: │
│ Prompt Engineering → Context Engineering → Agentic Engineering │
│ "어떤 단어?" → "무엇을 보여줄까?" → "시스템을 어떻게?" │
│ │
│ Harness Engineering의 위치: │
│ Agentic Engineering의 인프라 구현 레이어 │
│ = 에이전트를 감싸는 제약, 도구, 피드백 루프 │
│ │
│ 인간의 역할 전환: │
│ 코드 작성 → 아키텍처/품질/하네스 소유 │
│ │
│ 5가지 핵심 원칙: │
│ ├── 1. 계획 우선 (Planning First) │
│ ├── 2. 인간이 아키텍처 소유 (Human-Owned Architecture) │
│ ├── 3. 테스트가 핵심 차별점 (Testing as Differentiator) │
│ ├── 4. 투명성과 관찰성 (Transparency and Observability) │
│ └── 5. 기계적 강제 (Mechanical Enforcement) │
│ │
└─────────────────────────────────────────────────────────────────┘
계층 관계
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 개념 간 계층 관계 │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Agentic Engineering │ │
│ │ "목표 지향 자율 시스템 설계" │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ Harness Engineering │ │ │
│ │ │ "인프라 레이어: 제약, 도구, 피드백 루프" │ │ │
│ │ │ │ │ │
│ │ │ ┌────────────────────────────────────┐ │ │ │
│ │ │ │ Context Engineering │ │ │ │
│ │ │ │ "컨텍스트 윈도우를 적절한 │ │ │ │
│ │ │ │ 토큰으로 채우기" │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ ┌──────────────────────────────┐ │ │ │ │
│ │ │ │ │ Prompt Engineering │ │ │ │ │
│ │ │ │ │ "최적의 지시문 작성" │ │ │ │ │
│ │ │ │ └──────────────────────────────┘ │ │ │ │
│ │ │ └────────────────────────────────────┘ │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────┘ │
│ │
│ 포함 관계: │
│ Prompt Eng. ⊂ Context Eng. ⊂ Harness Eng. ⊂ Agentic Eng. │
│ │
│ 진화 방향: │
│ Prompt Engineering │
│ ↓ (진화) │
│ Context Engineering ← "컨텍스트 윈도우를 적절한 토큰으로" │
│ ↓ (멀티 스텝 시스템에 적용) │
│ Agentic Engineering ← "목표 지향 자율 시스템 설계" │
│ ↑ (구현 레이어) │
│ Harness Engineering ← "제약, 도구, 피드백 루프 인프라" │
│ │
└─────────────────────────────────────────────────────────────────┘
한 줄 요약
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Agentic Engineering = │
│ "AI 에이전트가 자율적으로 일하는 시스템을 설계하되, │
│ 인간이 아키텍처, 품질, 안전의 최종 소유자로 남는 것" │
│ │
│ 실천 원칙: │
│ ├── 계획 먼저 → 에이전트에게 명확한 방향 제공 │
│ ├── 테스트가 오라클 → 에이전트의 합격 기준 │
│ ├── 기계적 강제 → 문서가 아닌 코드로 규칙 적용 │
│ ├── 관찰성 내장 → 블랙박스를 투명 박스로 │
│ └── 하네스 투자 → 모델이 아닌 환경을 개선하라 │
│ │
└─────────────────────────────────────────────────────────────────┘
관련 키워드
Agentic Engineering Context Engineering Harness Engineering Prompt Engineering Vibe Coding ReAct Agent Loop Multi-Agent Orchestration MCP (Model Context Protocol) Tool Use Guardrails Human-in-the-Loop LangGraph CrewAI AutoGen Claude Code OpenAI Agents SDK Google ADK A2A Andrew Ng Andrej Karpathy SWE-bench AGENTS.md Observability Structural Tests Mechanical Enforcement
참고 자료
- ICSE 2026 AGENT Workshop - Agentic Software Engineering
- Harness Engineering - OpenAI - Codex 팀의 실전 사례
- Harness Engineering - Martin Fowler - 비판적 분석
- Building Effective Agents - Anthropic - 오케스트레이션 패턴
- State of AI Agents - LangChain - 2025 산업 조사
- Andrew Ng - Agentic Design Patterns - 4가지 에이전트 패턴
- Andrej Karpathy - Vibe Coding, Context Engineering, Agentic Engineering 용어
- OpenAI Agents SDK - 에이전트 프레임워크
- Model Context Protocol - MCP 공식 문서