프롬프트에서 하네스까지 — AI와 함께 개발한다는 것
프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링. AI를 활용한 개발이 어떻게 진화하고 있는지, 세 가지 키워드로 정리해봅니다.
2025년 초, Andrej Karpathy가 Vibe Coding 이라는 말을 만들었습니다. AI에게 대충 시키고, 돌아가면 OK. 코드를 직접 읽지 않고 “분위기”로 개발하는 방식이었죠.
재미있는 실험이었지만, 현실은 좀 달랐습니다. 프로젝트가 커지면 AI는 맥락을 잃고, 같은 실수를 반복하고, 아키텍처를 무시한 코드를 쏟아냈습니다. “AI가 코드를 잘 짜게 하려면 뭐가 필요한 거지?”라는 질문이 자연스럽게 따라왔어요.
업계는 이 질문에 답하면서 세 단계의 진화를 거쳐왔습니다.
프롬프트 엔지니어링
AI에게 말 거는 기술
컨텍스트 엔지니어링
AI에게 맥락을 주는 기술
하네스 엔지니어링
AI가 일하는 환경을 설계하는 기술
프롬프트 엔지니어링은 AI 모델에 입력하는 자연어 지시(프롬프트)를 정교하게 설계하는 것입니다. 같은 모델이라도 질문을 어떻게 하느냐에 따라 결과가 극적으로 달라지거든요.
⚠️ ❌ 대충 시키기
“이거 고쳐줘” → AI가 뭘 고쳐야 하는지 모릅니다. 엉뚱한 곳을 건드리기 일쑤예요.
💡 ✅ 구체적으로 시키기
“SRP 원칙에 따라 에러 핸들링을 추가해서, 기존 테스트가 통과하도록 리팩토링해줘” → 원칙, 요구사항, 제약조건이 있으니 AI가 훨씬 정확하게 동작합니다.
대표적인 기법들도 있습니다.
| 기법 | 설명 | 비유 |
|---|---|---|
| Zero-shot | 예시 없이 바로 지시 | “알아서 해봐” |
| Few-shot | 몇 가지 예시를 함께 제공 | “이런 식으로 해” |
| Chain-of-Thought | 단계별로 생각하게 유도 | “하나씩 풀어봐” |
| Role Prompting | 역할을 부여 | “너는 시니어 개발자야” |
프롬프트 엔지니어링은 확실히 효과적이었습니다. 하지만 한계도 분명했어요. 프롬프트가 아무리 정교해도, AI는 우리 프로젝트의 아키텍처, 코딩 컨벤션, 변경 히스토리를 모릅니다. 매번 “우리 프로젝트는 이런 구조고, 이런 규칙이 있고…” 하고 설명해줄 수도 없는 노릇이죠.
비유하자면, 아무리 똑똑한 신입에게 한 줄짜리 업무 지시만 주는 것과 같습니다. “질문을 잘 하는 것”만으로는 부족했어요. AI가 “알아야 할 것”을 체계적으로 알려줄 방법이 필요했습니다.
2025년, MIT Technology Review는 이런 제목의 기사를 냈습니다: “From vibe coding to context engineering”. 느슨한 vibe coding이 컨텍스트를 체계적으로 관리하는 방식으로 전환되고 있다는 거였어요.
컨텍스트 엔지니어링은 프롬프트를 넘어서, AI가 참조해야 할 모든 맥락 — 문서, 코드, 히스토리, 규칙 — 을 체계적으로 관리하는 것입니다.
- 범위: 한 번의 질문
- 성격: 정적, 단발성
- 비유: 신입에게 업무 지시 한 줄
- 범위: AI가 보는 세계 전체
- 성격: 동적, 시스템적
- 비유: 신입에게 위키, 가이드, 아키텍처 문서를 미리 읽혀놓기
구체적으로 어떤 수단들이 쓰이냐면요.
- AGENTS.md / CLAUDE.md — 프로젝트 규칙과 컨벤션을 AI가 매 세션 읽을 수 있도록 파일로 명시
- RAG (Retrieval-Augmented Generation) — 필요한 문서를 검색해서 AI 컨텍스트에 자동 주입
- Memory 시스템 — 이전 대화, 결정 사항, 학습 내용을 기억하게 하는 장치
- MCP (Model Context Protocol) — 외부 도구와 데이터 소스를 AI에 표준 방식으로 연결하는 프로토콜
핵심은 이거예요. 프롬프트는 컨텍스트의 일부일 뿐입니다. 아무리 질문을 잘 해도, AI가 프로젝트에 대해 아무것도 모르면 소용이 없어요. 반대로 적절한 컨텍스트가 갖춰져 있으면, 대충 물어봐도 꽤 좋은 결과가 나옵니다.
비유를 바꿔보면, 맥락 없는 AI는 첫날 출근한 신입이고, 맥락이 풍부한 AI는 3년차 팀원입니다. 차이는 능력이 아니라 정보예요.
2026년 2월, OpenAI Codex 팀이 흥미로운 실험 결과를 발표했습니다.
- 5개월간 프로덕션 애플리케이션을 개발
- 최종 코드량: 100만 줄 이상
- 인간이 직접 작성한 코드: 0줄
- 모든 코드를 AI 에이전트가 작성, 테스트, 배포까지 수행
엔지니어들은 뭘 했을까요? 코드를 쓰지 않았습니다. 대신, AI가 올바른 코드를 쓸 수 있는 환경을 설계했어요. 이 환경 — 제약, 피드백 루프, 검증 시스템, 문서 — 을 업계에서는 하네스(Harness)라고 부르기 시작했습니다.
하네스란?
“하네스”는 말(Horse)에게 채우는 장구에서 온 말입니다. 고삐, 안장, 재갈 — 강하고 빠른 말을 원하는 방향으로 이끄는 장비 일체를 뜻해요.
| 비유 | 대응 | 설명 |
|---|---|---|
| 🐴 말 | AI 모델 | 강력하지만, 혼자서는 어디로 갈지 모릅니다 |
| 🔧 하네스 | 인프라 | 제약, 가드레일, 피드백 루프로 방향을 잡아줍니다 |
| 🧑 기수 | 개발자 | 방향을 정하고, 직접 뛰지는 않습니다 |
하네스의 세 기둥
🔍 컨텍스트
에이전트가 알아야 할 것을 제공
🏗️ 아키텍처 제약
좋은 코드를 기계적으로 강제
🔄 엔트로피 관리
시간이 지나며 쌓이는 혼란을 자동 정리
- 컨텍스트 — AGENTS.md, 아키텍처 문서, 디렉토리 맵, 옵저버빌리티 데이터
- 아키텍처 제약 — 린터, CI 검증, 의존성 규칙, pre-commit 훅
- 엔트로피 관리 — 문서 일관성 검사, 패턴 위반 스캔, 데드코드 제거 에이전트
중요한 건, “AI에게 좋은 코드를 짜라고 말하는 것”과 “좋은 코드만 나올 수밖에 없는 환경을 만드는 것”은 완전히 다른 문제라는 거예요. 프롬프트로 “클린 코드를 작성해줘”라고 하는 건 전자이고, 린터와 CI가 위반을 자동으로 잡아내는 건 후자입니다.
실제 성과
모델 변경 없이 하네스만 개선해서 벤치마크 Top 30 → Top 5로 점프. 자기 검증 루프, 컨텍스트 매핑, 반복 감지를 추가했을 뿐이에요.
내부 에이전트 “Minion”이 주당 1,000개 이상의 PR을 자동 머지. 개발자는 Slack에 태스크를 올리고, 결과 PR만 리뷰합니다.
Google Antigravity — 하네스가 IDE에 녹아들다
흥미로운 건, 이런 하네스의 개념이 개발자가 직접 구축하는 것을 넘어 도구 자체에 내장되는 방향으로도 진화하고 있다는 점입니다.
대표적인 사례가 Google Antigravity예요. 2025년 11월 Gemini 3와 함께 발표된 “에이전트 퍼스트 IDE”인데, 기존 IDE와 접근이 근본적으로 다릅니다.
- 기존 방식: 에디터 안에서 코드 자동완성. 결과는 사람이 직접 확인.
- Antigravity: 에디터 + 터미널 + 브라우저를 에이전트가 자율적으로 넘나들며, 자기 검증 루프(Self-improvement)가 기본 탑재.
Google은 Antigravity를 Trust(신뢰), Autonomy(자율), Feedback(피드백), Self-improvement(자기 개선) 네 가지 원칙으로 설계했다고 밝혔는데, 이 네 가지는 사실상 하네스 엔지니어링의 핵심 요소들이에요.
아직 직접 깊이 써본 건 아니지만, 이런 도구가 나오고 있다는 것 자체가 시사적이에요. **”하네스를 직접 만드는 시대”에서 “하네스가 내장된 도구를 고르는 시대”**로 가고 있다는 뜻이니까요.
개발자의 역할 변화
전통적 개발
- 코드 작성이 본업
- 문서 작성은 부수적
- 디버깅은 코드를 읽고 추적
- 테스트를 직접 작성
- PR 리뷰는 코드 리뷰
하네스 엔지니어링
- 코드 작성 안 함
- 문서 작성이 핵심 인프라
- 에이전트 행동 패턴을 분석
- 에이전트가 실행할 테스트 전략을 설계
- 에이전트 출력 + 하네스 효과 리뷰
여기서 중요한 점이 있습니다. 프롬프트 엔지니어링이 “구식”이 된 게 아니에요. 컨텍스트 엔지니어링이 프롬프트를 대체한 것도 아닙니다.
세 가지는 누적되는 레이어입니다.
잘 물어보기 — 여전히 중요해요
잘 알려주기 — 프롬프트를 감싸는 더 큰 틀
잘 일하게 만들기 — 컨텍스트를 포함한 전체 시스템
안쪽이 사라지는 게 아니라, 바깥이 감싸는 겁니다. 프롬프트를 잘 쓰는 건 여전히 기본기이고, 컨텍스트를 잘 관리하는 건 그 위의 역량이며, 하네스를 설계하는 건 그 전체를 아우르는 시스템 사고예요.
결국 이건 “코드를 잘 짜는 개발자”에서 “AI가 코드를 잘 짜도록 만드는 개발자”로의 전환입니다.
당장 거창한 하네스 시스템을 만들 필요는 없습니다. 작은 것부터 시작할 수 있어요.
- ✅ AGENTS.md 작성 — 프로젝트의 아키텍처, 컨벤션, 주의사항을 AI가 읽을 수 있는 파일로 정리
- ✅ 코딩 컨벤션 문서화 — 암묵적으로 공유하던 규칙을 명시적인 문서로. AI뿐 아니라 새 팀원에게도 도움이 됩니다
- ✅ CI 파이프라인 강화 — 린터, 포맷터, 구조 테스트를 추가해서 “좋은 코드”를 기계적으로 보장
AI 도구는 계속 좋아질 겁니다. 하지만 도구가 좋아질수록 “도구를 어떻게 쓸 것인가”가 더 중요해집니다. 프롬프트를 잘 쓰고, 컨텍스트를 잘 관리하고, 하네스를 잘 설계하는 것 — 이 세 가지가 AI 시대 개발자의 핵심 역량이 될 거라 생각합니다.
참고 자료
- MIT Technology Review — “From vibe coding to context engineering: 2025 in software development” (2025.11)
- OpenAI Codex Team — Harness Engineering 사례 발표 (2026.02)
- Thoughtworks Technology Radar Vol.33 (2025.11)
- LangChain — Terminal Bench 2.0 하네스 최적화 사례
- NxCode — “Harness Engineering: The Complete Guide” (2026.03)