프롬프트 엔지니어링은 죽었다: 하네스 엔지니어링 시대의 개발자 생존 가이드

티스토리 뷰

실제 경험과 인사이트를 AI와 함께 정리한 글

프롬프트 엔지니어링은 죽었다: 하네스 엔지니어링 시대의 개발자 생존 가이드

pak2251 2026. 2. 22. 16:57

작성일: 2026년 2월 22일
카테고리: AI Engineering, Developer Productivity, Agent Architecture
키워드: Harness Engineering, Context Engineering, Prompt Engineering, AI Agent, Claude Code, MCP

요약

AI 개발 패러다임이 빠르게 진화하고 있다. 프롬프트 엔지니어링(2022-2024)에서 컨텍스트 엔지니어링(2025)으로, 다시 하네스 엔지니어링(2025-2026)으로 무게중심이 이동했다. OpenAI는 3명의 엔지니어가 5개월간 100만 줄의 코드를 하네스 엔지니어링만으로 생산했고, Anthropic은 자사 엔지니어링 팀의 코드 70-90%를 Claude Code가 작성한다고 밝혔다. 이 글에서는 각 단계의 핵심 차이, 하네스 엔지니어링의 실체, 그리고 개발자가 지금 준비해야 할 것을 정리한다.

왜 프롬프트만 잘 쓰면 되는 시대는 끝났는가

프롬프트 엔지니어링의 한계

2023년, "프롬프트 엔지니어"라는 직함이 등장했다. 연봉 3억 원 이상을 제시하는 공고가 화제가 되었고, 프롬프트 한 줄의 차이가 결과를 좌우하던 시기였다.

그런데 문제가 있다. 프롬프트 엔지니어링은 본질적으로 단일 질문의 최적화다.

프롬프트 엔지니어링 = "질문을 잘 하는 기술"

식당에서 주문할 때 "맛있는 거 주세요"보다 "매운 거 빼고, 국물 있는 한식으로, 1인분 주세요"가 낫다는 것과 같다. 분명 유용하지만, 한 끼 주문을 잘한다고 해서 레스토랑을 운영할 수 있는 건 아니다.

실제 프로덕션 환경에서 AI를 활용하려면 단일 프롬프트로는 부족하다:

모델이 10분 전 대화를 기억하지 못한다
외부 API를 호출해야 하는데 프롬프트만으로는 불가능하다
에이전트가 3시간짜리 작업을 수행하다가 실패하면 처음부터 다시 시작해야 한다
팀원 5명이 같은 모델을 쓰는데 결과물 품질이 천차만별이다

Andrej Karpathy(OpenAI 공동 창립자)는 이렇게 정리했다:

"사람들은 프롬프트를 일상적으로 LLM에게 주는 짧은 작업 설명과 동일시한다. 하지만 산업용 LLM 애플리케이션에서 프롬프트는 빙산의 일각이다."

3단계 진화: 프롬프트 → 컨텍스트 → 하네스

1단계: 프롬프트 엔지니어링 (2022-2024)

핵심: 모델에게 보내는 텍스트를 정교하게 다듬는 기술

사용자 → [프롬프트] → LLM → 응답

Chain-of-Thought, Few-shot, Zero-shot 같은 기법이 여기에 해당한다. "단계별로 생각해보세요"라는 한 줄을 추가하면 수학 문제 정답률이 올라가던 시기다.

한계: 단일 상호작용에 국한. 한 단어만 바꿔도 결과가 예측 불가능하게 변하는 취약함.

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

핵심: 모델이 "보는" 모든 정보를 설계하는 기술

2025년 6월, Shopify CEO Tobi Lutke가 트위터에 올린 한 줄이 업계를 뒤흔들었다:

"나는 '프롬프트 엔지니어링'보다 '컨텍스트 엔지니어링'이라는 용어를 훨씬 선호한다. 이것이 핵심 역량을 더 잘 설명한다: LLM이 작업을 그럴듯하게 해결할 수 있도록 모든 컨텍스트를 제공하는 설계 기술."

프롬프트가 "질문을 잘 하는 것"이라면, 컨텍스트 엔지니어링은 "시험지와 함께 참고 자료, 계산기, 사전을 적절히 배치하는 것"이다.

컨텍스트 엔지니어링이 관리하는 7가지 요소:

요소	역할	비유
시스템 프롬프트	기본 규칙과 행동 지침	사원 핸드북
사용자 입력	즉각적인 요청	오늘의 업무 지시
대화 이력	이전 맥락	회의록
장기 기억	과거 정보와 선호도	경력 기록
RAG	외부 문서와 데이터베이스	회사 위키
도구 정의	호출 가능한 기능	업무용 소프트웨어
출력 형식	응답 포맷 정의	보고서 템플릿

Karpathy는 이를 컴퓨터에 비유했다:

"LLM을 CPU, 컨텍스트 윈도우를 RAM이라고 생각하라. 엔지니어로서 당신의 역할은 운영체제와 같다: 작업 메모리에 적절한 코드와 데이터를 로드하는 것."

한계: 여전히 단일 세션 범위. 컨텍스트 윈도우가 리셋되면 모든 것이 사라진다.

3단계: 하네스 엔지니어링 (2025-2026)

핵심: AI 모델을 감싸는 전체 소프트웨어 인프라를 설계하는 기술

하네스 엔지니어링은 컨텍스트 엔지니어링을 포함하면서 그 너머로 확장된다.

하네스 엔지니어링 ⊃ 컨텍스트 엔지니어링 ⊃ 프롬프트 엔지니어링

경주마에 씌우는 마구(harness)를 생각해보자. 말(모델)이 아무리 빠르더라도, 마구(하네스) 없이는 마차를 끌 수 없다. 마구는 말의 힘을 올바른 방향으로 전달하고, 속도를 제어하고, 안전하게 운행할 수 있게 한다.

AI에서 하네스가 관리하는 영역:

┌─────────────────────────────────────────────────┐
│                  Agent Harness                   │
│                                                  │
│  ┌──────────────┐  ┌──────────────────────────┐ │
│  │  도구 통합    │  │  상태 및 메모리 관리       │ │
│  │  (MCP, API)  │  │  (세션 간 상태 유지)       │ │
│  └──────────────┘  └──────────────────────────┘ │
│  ┌──────────────┐  ┌──────────────────────────┐ │
│  │  컨텍스트     │  │  검증 및 가드레일          │ │
│  │  엔지니어링   │  │  (품질 검증, 안전 필터)    │ │
│  └──────────────┘  └──────────────────────────┘ │
│  ┌──────────────┐  ┌──────────────────────────┐ │
│  │  계획 및      │  │  서브 에이전트             │ │
│  │  태스크 분해   │  │  오케스트레이션            │ │
│  └──────────────┘  └──────────────────────────┘ │
│                                                  │
│              ┌────────────────┐                  │
│              │   LLM Model    │                  │
│              │ (Opus, Sonnet) │                  │
│              └────────────────┘                  │
└─────────────────────────────────────────────────┘

Philipp Schmid(前 Hugging Face)는 이 관계를 명확하게 정리했다:

컴퓨터 비유	AI 대응	역할
CPU	LLM 모델	원시 연산 능력
RAM	컨텍스트 윈도우	제한된 작업 메모리
운영체제	에이전트 하네스	컨텍스트 관리, 부트 시퀀스, 표준 드라이버
애플리케이션	에이전트	사용자 로직

같은 CPU(모델)를 쓰더라도 운영체제(하네스)에 따라 성능이 극적으로 달라진다. Windows에서 돌리든 Linux에서 돌리든 CPU는 같지만, 결과물은 완전히 다르듯이.

3단계 비교: 한눈에 보기

차원	프롬프트 엔지니어링	컨텍스트 엔지니어링	하네스 엔지니어링
시기	2022-2024	2025	2025-2026
범위	단일 프롬프트	전체 컨텍스트 윈도우	에이전트 전체 생명주기
초점	무엇을 말할 것인가	모델이 무엇을 볼 것인가	에이전트가 어떻게 동작할 것인가
비유	시험 문제 작성	시험지 + 참고 자료 배치	운영체제 설계
지속 시간	일회성 상호작용	단일 세션	멀티 세션, 장기 실행
핵심 역량	언어적 정밀함	정보 아키텍처	시스템 아키텍처
실패 원인	잘못된 문구	누락된 컨텍스트	끊어진 연속성
개발자 역할	프롬프트 작성자	컨텍스트 설계자	에이전트 아키텍트

실전 사례: 하네스 엔지니어링은 어떻게 작동하는가

사례 1: OpenAI Codex — 3명이 100만 줄을 만든 방법

2026년 2월, OpenAI는 충격적인 사례를 공개했다. 엔지니어 3명이 5개월간 약 1,500개의 PR을 머지하고 100만 줄의 프로덕션 코드를 생성했다. 수동으로 작성한 소스 코드는 0줄이다.

비결은 모델이 아니었다. 하네스였다.

그들이 설계한 하네스의 핵심 요소:

1. 의존성 흐름 강제

Types → Config → Repo → Service → Runtime → UI

모든 코드가 이 방향으로만 흐르도록 구조 테스트가 자동으로 검증한다. 에이전트가 이 규칙을 어기면 테스트가 실패하고, 에이전트는 스스로 수정한다.

2. 문서가 곧 인프라

docs/ 디렉토리가 에이전트의 "기억"이다. 에이전트는 코드를 작성하기 전에 문서를 읽고, 작업이 끝나면 문서를 업데이트한다. 문서의 불일치를 감지하는 전용 에이전트도 주기적으로 실행된다.

3. 삭제를 전제로 구축

"어제의 로직을 버릴 준비가 된 모듈식 아키텍처를 만들어라."

Manus는 6개월간 하네스를 5번 리팩토링했다. LangChain은 리서치 에이전트를 1년에 3번 재설계했다. Vercel은 에이전트 도구의 80%를 제거하고 오히려 더 나은 결과를 얻었다.

사례 2: Claude Code — 하네스 에이전트의 교과서

Claude Code는 하네스 엔지니어링의 가장 대중적인 구현체다. 개발자가 직접 사용하는 도구이기 때문에 하네스의 각 구성요소가 명확하게 드러난다.

Claude Code 구성요소	하네스 역할	설명
CLAUDE.md	하네스 설정 파일	프로젝트 규칙, 코딩 표준, 아키텍처 결정을 정의
Skills	재사용 가능한 워크플로우	스킬 이름으로 노출, 필요시 내용 로드
MCP 서버	도구 통합 계층	외부 시스템 연결 (Google Drive, Jira, Slack 등)
서브 에이전트	태스크 분해	Explore, Plan 등 전문 에이전트에 작업 위임
컨텍스트 압축	메모리 관리	장기 실행 중 컨텍스트 윈도우 자동 관리
Hooks	실행 전후 처리	커스텀 검증, 자동 포맷팅 등

실제 대화에서 이를 체감할 수 있다:

[개발자가 Claude Code에 요청]
"이 프로젝트에 사용자 인증을 추가해줘"

[Claude Code 하네스가 하는 일]
1. CLAUDE.md 읽기 → 프로젝트 규칙 파악
2. 코드베이스 탐색 (서브 에이전트) → 기존 구조 이해
3. MCP 서버 확인 → 사용 가능한 도구 파악
4. 계획 수립 → 사용자 승인 요청
5. 코드 작성 → 테스트 실행 → 검증
6. 컨텍스트 압축 → 장시간 작업에서도 맥락 유지

Anthropic의 보고에 따르면, 자사 엔지니어링 팀의 코드 70-90%를 Claude Code가 작성한다.

사례 3: LangChain Deep Agent의 하네스 패턴

LangChain은 "추론 샌드위치(Reasoning Sandwich)"라는 하네스 패턴을 제안한다:

[계획 단계] ← 최대 연산 투입
    ↓
[구현 단계] ← 최소 연산
    ↓
[검증 단계] ← 최대 연산 투입

복잡한 사고는 계획과 검증에 집중하고, 구현은 가볍게 처리한다. 마치 건축에서 설계와 검수에 시간을 쓰고, 실제 시공은 효율적으로 처리하는 것과 같다.

개발자가 지금 준비해야 할 6가지

1. CLAUDE.md / AGENTS.md 작성 능력

하네스의 첫 번째 계층은 설정 파일이다. 프로젝트의 규칙, 아키텍처 결정, 코딩 표준을 문서화하는 것이 에이전트 품질을 결정한다.

# 예시: CLAUDE.md 핵심 구조
## 프로젝트 아키텍처
- 모노레포, pnpm workspace
- Feature-Sliced Design 패턴

## 코딩 규칙
- 함수형 컴포넌트만 사용
- API 호출은 반드시 error boundary 내에서

## 금지 사항
- any 타입 사용 금지
- console.log 커밋 금지

이 파일이 곧 에이전트의 "업무 매뉴얼"이다. 매뉴얼이 정교할수록 결과물의 품질이 올라간다.

2. MCP 서버 개발

Model Context Protocol(MCP)은 AI와 외부 시스템을 연결하는 개방형 표준이다. 2024년 11월 Anthropic이 출시했고, 2025년 12월 Linux Foundation에 기부되었다. ChatGPT, Cursor, Gemini, VS Code 모두 MCP를 채택했다.

MCP 서버 개발은 웹 개발에서 REST API를 만드는 것만큼 기본 역량이 되고 있다.

[AI 에이전트] ←→ [MCP 프로토콜] ←→ [외부 시스템]
                                     ├── 데이터베이스
                                     ├── 사내 위키
                                     ├── Jira/Slack
                                     └── 커스텀 API

3. 에이전트 오케스트레이션

단일 에이전트가 아닌 여러 에이전트의 협업을 설계하는 능력이 필요하다.

Claude Code의 서브 에이전트 구조가 좋은 예다:

Explore 에이전트: 코드베이스 탐색 전문
Plan 에이전트: 구현 계획 수립 전문
General-purpose 에이전트: 범용 작업 처리

복잡한 작업을 이런 전문 에이전트들에게 분배하고, 결과를 종합하는 것이 하네스의 핵심 역할이다.

4. 관측성(Observability) 구현

LangChain의 2025년 설문조사에 따르면 89%의 조직이 에이전트 관측성을 구현했다. 에이전트가 왜 실패했는지 추적하지 못하면 개선이 불가능하다.

필수 관측 지점:

도구 선택 정확도
컨텍스트 윈도우 사용률
에이전트 실패 패턴 분류
토큰 소비량 대비 결과 품질

Martin Fowler는 이를 이렇게 표현했다:

"에이전트가 어려움을 겪을 때, 그것을 신호로 취급하라. 무엇이 빠져 있는지 파악하라."

5. "삭제를 전제로" 설계하는 습관

모델은 빠르게 개선된다. 오늘 필요한 복잡한 하네스 로직이 내일은 모델 자체 기능으로 대체될 수 있다. Philipp Schmid의 세 가지 지침:

단순하게 시작: 원자적 도구를 만들고 모델이 계획하게 하라. 가드레일과 재시도를 추가하되, 경직된 워크플로우는 피하라.
삭제를 전제로 구축: 어제의 로직을 버릴 준비가 된 모듈식 아키텍처를 만들어라.
하네스를 데이터셋으로: 에이전트의 실패가 다음 세대 모델의 훈련 데이터가 된다. 경쟁 우위는 프롬프트가 아닌 궤적(trajectory) 캡처로 이동한다.

6. 기본기는 여전히 중요하다

하네스 엔지니어링 시대에도 변하지 않는 것들:

코드 리뷰, 테스트, 아키텍처, 보안, 성능
문제를 정확히 정의하는 능력
시스템 전체를 조망하는 설계 역량

AI가 코드를 작성하더라도, 무엇을 만들어야 하는지, 어떤 제약 조건이 있는지, 결과물이 올바른지 판단하는 것은 여전히 개발자의 몫이다. 오히려 코드 작성 자체가 자동화되면서, 이러한 상위 역량의 가치가 더 높아지고 있다.

지금 당장 시작할 수 있는 것들

입문: 하네스를 "사용"하는 단계

현재 가장 접근성이 높은 하네스 에이전트 도구들:

도구	특징	적합한 사용자
Claude Code	터미널 기반, CLAUDE.md/Skills/MCP 완전 지원	터미널에 익숙한 개발자
Cursor	IDE 통합, 코드베이스 인덱싱	빠른 피드백을 원하는 개발자
GitHub Copilot (VS Code Agent Mode)	VS Code 네이티브, 낮은 진입 장벽	VS Code 사용자
Windsurf	대규모 코드베이스 자동 컨텍스트	엔터프라이즈 팀

중급: 하네스를 "설정"하는 단계

프로젝트에 CLAUDE.md 또는 AGENTS.md 작성
MCP 서버 연동 (기존 것 활용)
스킬(Skills) 작성으로 반복 작업 자동화
서브 에이전트 활용 패턴 학습

고급: 하네스를 "구축"하는 단계

커스텀 MCP 서버 개발
LangGraph 등으로 상태 기반 에이전트 워크플로우 설계
멀티 에이전트 오케스트레이션 구현
관측성 파이프라인 구축 (LangSmith 등)

업계 동향: 하네스가 해자(moat)다

Aakash Gupta는 "2025년은 에이전트, 2026년은 에이전트 하네스"라고 선언했다. 그의 핵심 주장:

"모델은 상품(commodity)이다. 하네스가 해자(moat)다."

이를 뒷받침하는 데이터:

57%의 조직이 파인튜닝 대신 오케스트레이션을 선택 (LangChain 설문, 2025.12)
75% 이상의 조직이 단일 모델이 아닌 다중 모델을 사용
89%의 조직이 모델 개선보다 관측성 인프라를 우선시
Gartner: 멀티에이전트 시스템 문의 1,445% 급증 (2024 Q1 → 2025 Q2)
Gartner: 2026년까지 40%의 엔터프라이즈 앱에 태스크별 AI 에이전트 포함 예측

표준화도 빠르게 진행되고 있다. 2025년, Anthropic, Block, OpenAI가 공동 설립한 Agentic AI Foundation(AAIF)에 Google, Microsoft, AWS, Cloudflare가 참여했다. MCP, AGENTS.md, goose 같은 프로젝트가 이 재단 아래에서 관리된다.

교훈

1. 개발자의 역할이 "코드 생산자"에서 "제약 조건과 피드백 시스템의 설계자"로 변하고 있다

OpenAI의 하네스 엔지니어링 보고서에서 가장 인상적인 문장:

"인간이 직접 코딩하지 않는 것은 다른 종류의 엔지니어링 작업을 만들어냈다. 시스템, 스캐폴딩, 레버리지에 초점을 맞춘 작업이다."

2. 하네스 품질이 모델 선택보다 결과에 더 큰 영향을 미친다

같은 Claude Opus를 사용하더라도 CLAUDE.md가 잘 작성된 프로젝트와 그렇지 않은 프로젝트의 결과물은 극적으로 다르다. 모델을 바꾸는 것보다 하네스를 개선하는 것이 더 높은 ROI를 보인다.

3. 변화 속도가 빠르므로, 유연한 아키텍처가 필수다

Manus가 6개월에 5번 하네스를 리팩토링한 것은 실패가 아니라 전략이다. 모델이 개선될 때마다 하네스도 함께 진화해야 한다. "삭제를 전제로 구축"하는 것이 이 시대의 설계 원칙이다.

참고 자료

핵심 아티클

Harness engineering: leveraging Codex in an agent-first world - OpenAI (2026.02)
Effective harnesses for long-running agents - Anthropic
Harness Engineering - Martin Fowler (2026)
The importance of Agent Harness in 2026 - Philipp Schmid
Improving Deep Agents with harness engineering - LangChain (2026)
2025 Was Agents. 2026 Is Agent Harnesses. - Aakash Gupta

영상 자료

How Agents Use Context Engineering - LangChain
From Context Engineering to AI Agent Harnesses - High Signal by Delphina (게스트: Lance Martin, LangChain)
Building Agents with MCP - Full Workshop - AI Engineer (Mahesh Murag, Anthropic)
OpenAI's Codex Redefines AI-Native Engineering - StartupHub.ai

Markdown Mermaid Viewer 개인정보처리방침 (Privacy Policy) (0)	2026.02.28
3단계 (Tailscale): Kubernetes + Cilium 클러스터 구축 — Native Routing (0)	2026.02.28
Claude Code 사용 리포트: 1월 29억, 2월 10일만에 30억 토큰 (0)	2026.02.11
GitHub Superpowers v1.2.0: Opus 쿼터 100%가 만든 토큰 효율화 (0)	2026.02.11
GitHub Superpowers v1.1.0: Agent Team 오케스트레이션과 Plan Mode (0)	2026.02.07

imprun engineering

티스토리 뷰