AI 엔지니어링 4년의 진화: 프롬프트 엔지니어링부터 하네스 엔지니어링까지 완전 정리

여러분, 2022년 GitHub Copilot이 처음 등장했을 때 많은 개발자들은 “AI가 코드를 자동 완성해 준다”는 사실만으로도 충분히 놀라워했습니다. 그런데 불과 4년이 지난 지금, AI 에이전트는 스스로 이슈를 생성하고 브랜치를 따고 PR을 올리는 수준까지 왔습니다. 이 변화의 속도는 단순히 모델 성능 향상만으로는 설명이 안 됩니다. 그 이면에는 AI를 어떻게 다루고, 어떻게 제어할 것인가에 대한 엔지니어링 패턴의 진화가 있었거든요.

이 글에서는 AI 에이전틱(Agentic) 패턴의 역사를 시간순으로 짚어 보겠습니다. 프롬프트 엔지니어링(Prompt Engineering)에서 시작해 컨텍스트 엔지니어링(Context Engineering), 바이브 코딩(Vibe Coding), 그리고 가장 최근의 하네스 엔지니어링(Harness Engineering)까지, 각 개념이 왜 등장했고 핵심 원리가 뭔지 하나씩 풀어 보려고 합니다. 특히 하네스 엔지니어링의 실제 구축 방법(커맨드 → 룰 → 스킬 → 훅)을 단계별로 안내하니까, 에이전트 기반 개발 워크플로를 고도화하고 싶은 분들께 도움이 될 거라고 봅니다.

핵심 요약

• 2022년 GitHub Copilot 출시가 AI 코딩 어시스턴트 시대를 열었고, 같은 해 ChatGPT 등장으로 프롬프트 엔지니어링 연구가 폭발적으로 증가했다.
• 프롬프트 엔지니어링은 모델 성능이 낮던 시절, “질문을 어떻게 잘 설계하느냐”로 출력 품질을 끌어올리는 기법이었으나, 컨텍스트 윈도우 한계라는 구조적 문제에 부딪혔다.
• 컨텍스트 엔지니어링은 단일 프롬프트 최적화를 넘어 LLM의 한정된 컨텍스트 윈도우를 시스템 수준에서 설계·관리하는 접근법으로, 시스템 프롬프트·메모리·RAG·MCP 등이 모두 이 범주에 포함된다.
• 바이브 코딩은 AI에 전적으로 의존해 코드를 이해하지 않고 수용하는 방법론으로 주목받았지만, 한계가 뚜렷해 빠르게 인기가 식었다.
• 하네스 엔지니어링은 자율적으로 동작하는 AI 에이전트가 의도를 벗어나거나 보안 위험을 초래하지 않도록 안전 장치(harness)를 설계하고 구축하는 엔지니어링 패턴이다.
• 하네스는 커맨드(Command) → 룰(Rule) → 스킬(Skill) → 훅(Hook) 순서로 단계적으로 구축하는 것이 가장 효율적이다.
• 팀마다 코딩 스타일과 워크플로가 다르기 때문에, 범용 플러그인보다 자신의 프로젝트에 맞는 하네스를 직접 구축하는 것이 장기적으로 더 효과적이다.

---

1. 시작점: 2022년, AI 코딩의 원년

GitHub Copilot의 등장 (2022년 6월)

2022년 6월, GitHub Copilot이 월 10달러의 구독 모델로 정식 출시되었습니다. 이는 역사상 최초의 AI 코딩 어시스턴트로 평가받으며, 편집기에서 코드를 입력하는 도중 다음에 올 코드를 자동으로 제안해 주는 ‘고스트 텍스트(Ghost Text)’ 기능을 선보였습니다. 오늘날 Cursor의 탭(Tab) 자동완성과 동일한 개념의 원형입니다. 당시 개발자 커뮤니티는 AI가 실제로 맥락에 맞는 코드를 제안한다는 사실 자체에 큰 충격을 받았습니다.

ChatGPT의 폭발적 등장 (2022년 11월)

GitHub Copilot 출시 약 5개월 뒤인 2022년 11월 30일, ChatGPT가 공개됐습니다. 출시 5일 만에 100만 명이 넘는 사용자를 모으며 전례 없는 반향을 일으켰죠. 이때 ChatGPT의 기반 모델은 GPT-3.5였는데, 지금의 GPT-4o나 Claude 3.5 Sonnet과 비교하면 성능 차이가 상당했습니다.

바로 이 성능의 한계가 프롬프트 엔지니어링 연구를 촉발한 핵심 동기였습니다. 모델이 완벽하지 않으니, 질문을 잘 설계해서 최대한 좋은 답변을 이끌어내야 했던 거죠.

---

2. 프롬프트 엔지니어링: 질문을 잘하는 기술

프롬프트 엔지니어링(Prompt Engineering)이란 거대 언어 모델(Large Language Model, LLM)에게 원하는 결과를 얻기 위해 입력 질문(프롬프트)을 체계적으로 설계하고 최적화하는 기술입니다. 모델의 내부 구조를 바꾸지 않고 입력만 정교하게 다듬어 출력 품질을 높인다는 점이 특징입니다.

주요 프롬프트 엔지니어링 기법

역할 부여 (Role Prompting)

LLM에게 특정 직업·전문가·페르소나를 부여하고 그 역할에 맞는 답변을 요청하는 기법입니다. “당신은 10년 경력의 시니어 백엔드 개발자입니다. 다음 코드를 리뷰해 주세요”와 같이 역할을 명시하면, 모델이 해당 관점에서 더 전문적이고 구체적인 답변을 생성하는 경향이 있습니다. 이는 모델이 역할에 맞는 어휘와 추론 방식을 활성화하기 때문으로 이해됩니다.

생각의 사슬 (Chain of Thought, CoT)

생각의 사슬(Chain of Thought, CoT)은 프롬프트에 “이 문제를 단계별로 천천히 생각해 줘”라는 지시 한 줄을 추가하는 것만으로 LLM이 마치 추론 모델처럼 단계적 사고를 수행하게 만드는 기법입니다. 모델이 최종 답변을 바로 출력하는 대신, 중간 사고 과정을 거치도록 유도함으로써 복잡한 수학 문제나 다단계 논리 추론에서 정확도가 크게 향상됩니다.

일반 프롬프트	CoT 적용 프롬프트
”이 수학 문제의 답을 알려줘"	"이 수학 문제를 단계별로 천천히 풀어줘”
즉각적 답변 출력	풀이 과정 → 중간 검토 → 최종 답변
복잡한 문제에서 오류율 높음	복잡한 문제에서 정확도 향상

ReAct: 추론과 행동의 반복

ReAct는 오늘날 Claude Code, Codex, Cursor, Gemini 등 거의 모든 AI 코딩 에이전트의 원형이 되는 프롬프팅 기법입니다. 이름은 Reasoning(추론)과 Action(행동)의 합성어로, LLM이 사용자의 요청을 처리할 때 다음 과정을 반복합니다.

1. [Thought] 현재 상황에 대한 추론 수행
2. [Action] 필요한 외부 도구 호출 (웹 검색, DB 조회, 코드 실행 등)
3. [Observation] 도구 실행 결과 수신
4. [Thought] 결과를 바탕으로 다시 추론
5. ... (반복) ...
6. [Final Answer] 최종 응답 생성

모델이 스스로 판단해서 외부 도구를 쓰기 때문에, LLM의 고질적 문제인 환각(Hallucination) 현상을 줄이고 실제 데이터에 기반한 더 정확한 답변을 만들어 낼 수 있습니다. 지금 우리가 쓰는 거의 모든 코딩 에이전트가 이 ReAct를 원형으로 두고 있다고 보시면 됩니다.

기타 기법

연구에 따르면 LLM에게 반말로 지시하듯 명령하는 것이 오히려 정확도가 올라간다는 흥미로운 결과도 있었습니다. 이 시기에는 이처럼 다양하고 때로는 직관에 반하는 프롬프팅 기법들이 쏟아졌습니다.

프롬프트 엔지니어링의 한계: 컨텍스트 윈도우 문제

프롬프트 엔지니어링은 단일 응답의 품질을 높이는 데는 효과적이었지만, 구조적 한계를 피할 수 없었습니다. 바로 컨텍스트 윈도우(Context Window) 문제입니다.

컨텍스트 윈도우란 LLM이 한 번에 기억하고 처리할 수 있는 텍스트의 최대 크기를 의미합니다. Gemini, GPT, Claude(Anthropic)의 Sonnet 등 모델마다 이 크기가 다릅니다. ChatGPT로 대화를 계속하면 이전 대화가 모두 누적되어 다음 요청에 함께 전달되는데, 이 누적된 컨텍스트가 윈도우를 가득 채울수록 모델 성능이 오히려 저하되는 현상이 발생합니다.

[1차 대화]
입력(Q1) + 출력(A1) → 총 500 토큰

[2차 대화]
입력(Q1) + 출력(A1) + 입력(Q2) + 출력(A2) → 총 1,200 토큰

[N차 대화]
모든 이전 대화 누적 → 컨텍스트 윈도우 포화 → 성능 저하

아무리 프롬프트를 정교하게 써도, 대화가 길어질수록 컨텍스트가 오염되고 모델 성능이 떨어집니다. 이 한계는 단순한 프롬프팅 기법만으로는 풀 수 없었던 거죠.

---

3. 컨텍스트 엔지니어링: 시스템 수준의 설계

컨텍스트 엔지니어링의 등장

OpenAI 공동 창립자 Andrej Karpathy와 Shopify CEO Tobias Lütke가 X(트위터)에서 언급하면서 빠르게 확산된 개념이 바로 컨텍스트 엔지니어링(Context Engineering)입니다.

“프롬프트 엔지니어링이 ‘무엇을 말할 것인가’를 연구한다면, 컨텍스트 엔지니어링은 ‘모델이 그 말을 들을 때 무엇을 알고 있게 할 것인가’를 설계하는 것이다.”

즉, 단일 프롬프트를 잘 쓰는 것에서 벗어나, LLM의 한정된 컨텍스트 윈도우 전체를 어떻게 최적으로 채울 것인가를 시스템 수준에서 설계하는 접근법입니다.

컨텍스트 엔지니어링의 구성 요소

구성 요소	설명
시스템 프롬프트	에이전트의 역할, 규칙, 행동 방침을 정의하는 기본 지침
채팅 히스토리 관리	불필요한 이전 대화를 압축(Compaction)하거나 제거하여 컨텍스트 최적화
장기 메모리	컨텍스트 윈도우 밖의 정보를 별도 저장소에 보관하고 필요 시 주입
RAG	검색 증강 생성(Retrieval-Augmented Generation, RAG)으로 외부 지식을 동적으로 주입
MCP	에이전트가 외부 도구를 활용할 수 있게 해주는 표준 프로토콜 MCP (Model Context Protocol)

프롬프트 엔지니어링과 컨텍스트 엔지니어링의 핵심 차이는 관점의 전환에 있습니다. 전자가 “좋은 질문 한 방”에 집중한다면, 후자는 입력 파이프라인 전체를 시스템으로 설계하죠. 제가 AI 모델을 활용할 때 늘 강조하는 게 바로 이 문맥(컨텍스트)입니다. 좋은 컨텍스트를 최적의 구조로 잘 유지하는 것, 이게 컨텍스트 엔지니어링의 핵심이라고 봅니다.

바이브 코딩의 등장과 한계

컨텍스트 엔지니어링과 비슷한 시기, 바이브 코딩(Vibe Coding)이라는 용어도 Andrej Karpathy의 트윗 한 줄에서 출발해 급속도로 퍼졌습니다. 바이브 코딩의 정의는 명확합니다.

“인공지능에 전적으로 의존해 소프트웨어를 개발하는 새로운 방법론. 개발자가 AI가 작성한 코드를 완전히 이해하지 못한 채로 수용한다.”

Lovable, Replit, v0, Bolt 등 수많은 바이브 코딩 서비스가 쏟아졌고, 초기에는 Lovable이 폭발적인 트래픽을 기록했습니다. 그런데 코드를 이해하지 않고 받아들이는 방식은 유지보수, 디버깅, 보안 측면에서 한계가 명확했죠. 그래서 관련 서비스들의 트래픽도 빠르게 식기 시작했습니다.

---

4. 하네스 엔지니어링: AI 에이전트를 위한 안전 장치 설계

하네스 엔지니어링이란?

하네스 엔지니어링(Harness Engineering)은 Terraform, Ghostty 등의 도구를 만든 개발자 Mitchell Hashimoto가 블로그에 올린 글을 계기로 주목받기 시작했습니다. 개념의 본질은 이렇습니다.

AI 에이전트가 점점 자율적으로 동작하게 되면서, 의도하지 않은 방향으로 작동하거나 보안상 위험한 행동을 하는 경우가 생긴다. 이를 방지하기 위해 에이전트의 동작 환경 전체에 안전 장치(harness)를 설계·구축하는 것이 하네스 엔지니어링이다.

과거 개발자의 주된 업무가 “직접 코드를 작성하는 것”이었다면, 이제는 “에이전트가 안전하고 효율적으로 동작하는 환경을 구축하는 것”이 주된 업무가 되고 있습니다. 제 생각엔 올해까지는 개발자들이 이 하네스 엔지니어링을 주요 패턴으로 가장 많이 연구하게 될 것 같습니다.

하네스의 4가지 구성 요소

하네스는 다음 네 가지 구성 요소를 단계적으로 쌓아 올리는 방식으로 구축합니다.

1단계: 커맨드 (Command), 재사용 가능한 프롬프트 템플릿

개발하다 보면 반복적으로 입력하는 프롬프트 패턴이 생기죠. 커맨드는 이런 반복 프롬프트를 재사용 가능한 템플릿으로 저장해 두고, 필요할 때 호출하는 기능입니다.

• 반복되는 작업 패턴을 파악한다
• 해당 패턴에 맞는 프롬프트를 정제해 커맨드로 저장한다
• 다음번 동일한 작업 시 커맨드를 호출해 즉시 실행한다

커맨드는 직접 호출해야만 동작하는 수동 워크플로라는 점이 특징입니다.

2단계: 룰 (Rule), 에이전트 행동 규칙 정의

룰(Rule)은 에이전트가 항시 참고하는 규칙 파일입니다. CLAUDE.md, AGENTS.md, GEMINI.md 등의 마크다운 파일 형태로 작성하며, 프로젝트의 코딩 컨벤션·아키텍처 원칙·금지 행동 등을 정의합니다.

# CLAUDE.md 예시

## 코딩 컨벤션

- TypeScript strict 모드 사용
- 함수형 컴포넌트만 사용 (클래스 컴포넌트 금지)

## 워크플로 규칙

- 기능 개발 전 반드시 이슈 생성
- 테스트 코드 없이 커밋 금지
- main 브랜치 직접 푸시 금지

룰은 팀원과 함께 버전 관리하면서 지속적으로 업데이트하는 것이 권장됩니다. 단, 룰은 에이전트에게 행동을 유도하는 수준이며, 100% 강제 보장은 하지 못한다는 한계가 있습니다.

3단계: 스킬 (Skill), 고도화된 복합 작업 패키지

커맨드 하나로 처리되지 않는 복잡한 작업이 있습니다. 예를 들어 특정 예시 템플릿을 첨부해야 하거나, 코드 기반 스크립트를 실행해야 하는 경우입니다. 스킬(Skill)은 이런 작업을 위해 예시 템플릿, 스크립트, 참조 문서 등을 하나의 패키지로 묶은 단위입니다.

실제 개발 워크플로 예시:

1. 이슈 생성 스킬 → GitHub 이슈를 자동으로 생성
2. PR 생성 스킬 → 완성된 브랜치의 Pull Request를 자동으로 작성
3. 리팩토링 스킬 → 복잡도 분석 후 구조 단순화 제안

스킬들이 쌓이면, 이를 조합해 하나의 완성된 워크플로를 구성할 수 있습니다.

4단계: 훅 (Hook), 프로그래밍 로직으로 강제하는 안전 장치

훅(Hook)은 특정 시점에 특정 동작을 코드 수준에서 강제하는 메커니즘입니다. 룰이 “권고”라면 훅은 “강제”라고 보시면 됩니다. AI의 판단에 맡기는 게 아니라, 프로그래밍 로직으로 동작을 보장하는 거죠.

훅이 동작하는 대표적인 시점:

• 특정 파일을 읽기 전
• Bash 명령어를 실행하기 전
• 커밋을 수행하기 전

훅에 포함할 수 있는 주요 기능:

훅 유형	설명	예시
Protection	보안·안전 위반 행동을 원천 차단	특정 파일 접근 금지, main 브랜치 직접 푸시 차단, 테스트 없는 커밋 차단
Reminder	AI가 규칙을 망각할 때 강제로 상기	TDD 방식으로 테스트 코드 먼저 작성하도록 강제하는 체크 훅
Workflow Trigger	특정 조건에서 커맨드·스킬 자동 호출	세션 시작 시 자동으로 이슈·브랜치 생성 워크플로 실행

---

5. 실전: 하네스 구축 사례와 단계별 접근법

실제 개발 워크플로 예시

Claude Code를 활용한 실제 하네스 기반 개발 워크플로는 다음과 같이 구성할 수 있습니다.

[세션 시작]
    ↓
[이슈 & 브랜치 생성] ← 스킬 호출
    ↓
[디자인 리뷰] ← 요구사항 명확화 커맨드
    ↓
[플랜 문서 작성]
    ↓
[TDD 방식으로 개발] ← 테스트 코드 선작성 룰 + 훅으로 강제
    ↓
[개발 완료 단위별 리팩토링 검토]
    ↓
[커밋 & 푸시] ← 보호 훅: 테스트 통과 확인, main 직접 푸시 차단
    ↓
[PR 생성] ← 스킬 호출

하네스 구축의 단계별 접근 원칙

하네스 구축에서 제가 가장 강조하고 싶은 건 처음부터 완벽하게 설계하려 하지 말라는 겁니다. 작은 것부터 단계적으로 쌓아 가는 게 훨씬 효율적이거든요. 권장하는 순서는 이렇습니다.

1. 커맨드부터 시작: 반복적으로 입력하던 프롬프트를 하나씩 커맨드로 저장한다
2. 스킬로 발전: 커맨드 하나로 부족한 복잡한 작업은 스킬 패키지로 확장한다
3. 룰로 통합: 쌓인 스킬들을 조합해 팀의 워크플로 규칙을 룰 파일로 정의한다
4. 훅으로 강제: 반드시 지켜야 하는 규칙은 훅으로 코드 수준에서 보장한다

기성 플러그인 vs. 직접 구축

시장에는 이미 완성된 하네스 프레임워크(예: ohmyclaude, superClaude 등)가 있습니다. 이걸 설치해 바로 쓰는 방법도 있죠. 그런데 저는 개인적으로 이미 만들어진 프레임워크를 가져다 쓰는 걸 그렇게 좋아하지는 않습니다.

각 개인과 팀마다 코딩 스타일, 컨벤션, 워크플로, 아키텍처 원칙이 다릅니다. 범용 플러그인은 이 다양성을 충족시키기 어렵고, 불필요한 규칙이 오히려 에이전트의 동작을 방해할 수 있습니다.

제가 말하고 싶은 건 이겁니다. 하네스 엔지니어링은 거창하거나 복잡한 개념이 아닙니다. 이미 알고 있는 기능들(커맨드, 룰, 스킬, 훅)을 자신의 팀과 프로젝트에 맞게 조합하는 것, 그게 전부입니다.

---

6. AI 엔지니어링 패턴의 흐름 정리

4년간의 흐름을 한눈에 정리하면 다음과 같습니다.

시기	패턴	핵심 질문	대표 도구/개념
2022년	프롬프트 엔지니어링	”모델에게 무엇을 어떻게 말할까?”	CoT, ReAct, 역할 부여
2023~2024년	컨텍스트 엔지니어링	”모델이 무엇을 알고 있게 할까?”	RAG, MCP, 메모리 관리
2024~2025년	바이브 코딩	”AI에 전적으로 맡기면 어떨까?”	Lovable, Replit, v0
2025~2026년	하네스 엔지니어링	”에이전트를 어떻게 안전하게 제어할까?”	커맨드, 룰, 스킬, 훅

각 패턴은 이전 패턴을 대체하는 것이 아니라 포괄하며 확장합니다. 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 일부가 되고, 컨텍스트 엔지니어링은 하네스 엔지니어링의 구성 요소가 됩니다. 이 모든 것을 아우르는 개념이 에이전틱 엔지니어링(Agentic Engineering)입니다.

---

마무리: 지금 당장 하네스를 시작하는 법

결론부터 말하면, 하네스 엔지니어링은 이미 많은 개발자들이 하고 있는 행동들(반복 프롬프트 저장, 규칙 파일 작성, 워크플로 자동화)을 하나의 체계로 묶어서 이름 붙인 것일 뿐입니다. 처음 접하는 분이라면 오늘 당장 다음 세 가지부터 시작해 보면 좋겠습니다.

1. 자주 입력하는 프롬프트를 커맨드로 저장한다 (5분 투자, 즉시 효과)
2. 프로젝트 루트에 CLAUDE.md 또는 AGENTS.md를 생성하고 팀의 코딩 규칙을 한 줄씩 추가한다
3. 절대 어겨서는 안 되는 규칙 하나를 골라 훅으로 구현한다 (예: 테스트 없는 커밋 차단)

AI 에이전트는 앞으로 더 자율적으로 발전할 겁니다. 그 자율성이 강해질수록 우리가 설계하는 하네스의 품질이 프로젝트의 안전성과 생산성을 결정하게 된다고 봅니다. 완벽한 하네스를 한 번에 만들려 하지 말고, 오늘 커맨드 하나부터 시작해 조금씩 쌓아 나가 보면 좋겠습니다. 그게 제가 생각하는 가장 현실적이고 효과적인 길입니다.

---

관련 영상

이 글과 연결된 영상은 개발동생 유튜브 채널에서 보기에서 확인할 수 있습니다.