본 기사는 필자의 개인적인 이해를 바탕으로 한 요약입니다.
이 분야는 새로운 용어가 계속 생겨나고 있으며, 같은 단어라도 사람이나 기업에 따라 지칭하는 범위가 다릅니다. 엄밀한 정의가 필요하다면 각 방법론의 제창원 정보를 확인해 주십시오. 오류나 보충할 점이 있다면 댓글로 알려주시면 감사하겠습니다.
'프롬프트 엔지니어링(Prompt Engineering)' 다음에는 '컨텍스트 엔지니어링(Context Engineering)', 그 다음은 '하네스 엔지니어링(Harness Engineering)'입니다. 게다가 '바이브 코딩(Vibe Coding)', '명세 주도 개발(Specification-Driven Development)', 'AIDD' 등 AI를 활용한 개발 방법론 용어가 지난 1~2년 동안 급증했습니다.
솔직히 필자 자신도 '이거랑 저거가 뭐가 다른 거지?'라며 혼란스러웠기 때문에, 자신의 머릿속을 정리하는 겸해서 대략적으로 요약해 봅니다.
많은 방법론들을 필자는 다음 세 가지 계층으로 나누어 파악하고 있습니다.
| 계층 | 질문 | 주요 방법론 |
|---|
| ① 입력/환경 설계 | AI에게 무엇을 주고, 어떤 환경에서 구동시킬 것인가 | 프롬프트 / 컨텍스트 / 하네스 / 플로우 엔지니어링 (Flow Engineering) |
| ② 개발 진행 방식 | AI와 어떻게 역할을 분담하여 개발을 진행할 것인가 | 바이브 코딩 / 에이전틱 코딩 (Agentic Coding) / 명세 주도 개발 / AIDD・AI-DLC / 멀티 에이전트 (Multi-agent) |
| ③ 품질 및 지속적 개선 | AI의 출력을 어떻게 신뢰할 수 있는 것으로 만들 것인가 | AI×TDD / 평가 주도 개발 (Evaluation-Driven Development) / Compound Engineering |
※ 이 구분 자체도 필자의 독자적인 정리입니다.
각 방법론들은 독립적이지 않고 상당히 겹치는 부분이 많습니다. 필자는 다음과 같이 파악하고 있습니다.
상단: AI가 구동되는 환경은 '프롬프트 ⊂ 컨텍스트 ⊂ 하네스'의 중첩 구조이며, 다른 많은 방법론들은 이 중 어느 한 계층을 강화하는 장치라고 생각됩니다. -
하단: 개발 진행 방식은 얼마나 구조화하고 통제할 것인가의 스펙트럼으로 배열될 수 있습니다. 오른쪽으로 갈수록 상단의 메커니즘(명세・테스트・승인)을 더 많이 사용하게 됩니다.
다루는 범위가 '1회 지시'에서 'AI를 둘러싼 환경 전체'로 확장되어 온 흐름으로 보면 이해하기 쉽다고 생각합니다.
프롬프트 ⊂ 컨텍스트 ⊂ 하네스
(1회 지시) (전달하는 정보 전체) (구동되는 환경・메커니즘 전체)
필자의 이해: AI에게 '1회 지시문' 작성 방식을 고안하는 기술.
- 역할을 부여하기('당신은 시니어 엔지니어입니다')
- 출력 형식을 지정하기(JSON, 목록 등)
- 예시 보여주기(Few-shot)
- 단계적으로 생각하게 하기(Chain-of-Thought)
ChatGPT가 등장했을 때 가장 주목받았던 계층입니다. 모델이 똑똑해지면서 세부적인 테크닉의 중요도는 낮아지는 인상도 있지만, '원하는 바를 명확히 전달한다'는 기본은 여전히 중요하다고 생각합니다.
필자의 이해: 프롬프트뿐만 아니라 AI에게 전달되는 '정보 전체'를 설계하는 사고방식.
AI가 참조하는 정보에는 프롬프트 외에도 여러 가지가 있습니다.
- 프로젝트의 규칙 파일(
CLAUDE.md, AGENTS.md 등)
- 관련 소스 코드나 문서
- 대화 기록
- 도구 실행 결과(검색 결과, 테스트 결과 등)
'필요한 정보를 필요한 만큼, 적절한 타이밍에 전달하는 것'이 핵심입니다. 정보를 너무 많이 채워 넣으면 오히려 정확도가 떨어질 수도 있습니다. 2025년경부터 급격히 사용되기 시작한 용어라는 인상입니다.
필자의 이해: AI 에이전트가 스스로 올바르게 작업을 진행할 수 있도록 주변의 '메커니즘'을 정비하는 것.
하네스(harness)는 '마구'라는 의미로, AI라는 말의 힘을 올바른 방향으로 이끄는 도구 세팅이라는 이미지가 있습니다.
- 사용할 도구나 권한 설정
- 훅(Hook)(예: 파일 저장 시마다 자동으로 Lint・테스트 실행)
- 테스트나 CI 등, AI가 자신의 성과를 점검할 수 있는 메커니즘
- 에이전트의 실행 루프나 서브 에이전트 구성
'AI에게 지시하는 것을 잘한다'에서 한 단계 나아가, 'AI가 스스로 실수를 발견하고 고칠 수 있는 환경을 만드는' 방향의 사고방식이라고 이해합니다.
필자의 이해: 1회의 긴 프롬프트에 의존하지 않고, '생성 → 테스트 → 수정'과 같은 다단계 흐름을 설계하는 것.
AlphaCodium 논문에서 사용된 용어입니다. 하네스 엔지니어링과 상당 부분 중첩되는 부분이 있다고 느낍니다.
필자의 이해: 코드를 거의 읽지 않고 AI에게 맡겨서, 감(느낌)으로 만들어나가는 스타일.
Andrej Karpathy가 언급한 용어입니다.
- 👍とにかく 빠르다. 프로토타입이나 개인 툴에 적합함
- 👎 내용(본질)을 파악하지 못했기 때문에, 유지보수성이나 보안에 불안감이 남음
'실제 상용 제품에는 부적합하지만, 시제품 제작에는 최고'라는 위치로 이해하고 있습니다.
필자의 이해: Claude Code나 Codex 같은 AI 에이전트에게 계획-구현-테스트-수정까지 자율적으로 맡기는 개발 스타일.
바이브 코딩(Vibecoding)과의 차이는, 인간이 설계-리뷰-판단의 책임을 확실히 지는 부분이라고 파악하고 있습니다. AI는 '손을 움직이는 사람', 인간은 '방향을 결정하고 리뷰하는 사람'으로 역할을 분담합니다.
필자의 이해: 바로 코드를 작성하게 하는 것이 아니라, 먼저 AI와 함께 '명세서(Specification)'를 만들고, 그것을 기반으로 구현시키는 방법.
요구사항 정의 → 설계 → 태스크 분해 → 구현
↑ 각 단계에서 인간이 리뷰/승인
AWS의 Kiro나 GitHub의 Spec Kit 등이 대표적인 툴입니다. 'AI는 지시가 모호하면 제멋대로 만들어 버린다'라는 문제에 대한 대책으로, 매우 논리적이라고 느낍니다.
필자의 이해: AI를 단순한 보조 도구가 아니라 '개발의 주역'으로 두고, 인간은 승인과 의사결정에 집중하는 개발 프로세스 전체의 사고방식.
AIDD (AI-Driven Development): AI를 중심으로 삼는 개발이라는 넓은 의미로 사용되는 경우가 많음 -
AI-DLC (AI-Driven Development Lifecycle): AWS가 제창한 방법론. 요구사항 정의부터 운영까지, 라이프사이클 전체를 AI 주도형으로 돌리는 것을 상정하고 있음
개별적인 테크닉이라기보다는, 팀이나 조직의 개발 프로세스를 어떻게 바꿀 것인가라는 한 단계 위의 이야기라고 이해합니다.
필자의 이해: 여러 AI 에이전트에게 역할을 나누어(구현 담당/리뷰 담당/테스트 담당 등), 병렬로 작업을 시키는 방법.
git worktree
작업 공간을 분리하여, 여러 에이전트가 각기 다른 태스크를 동시에 진행하도록 사용하는 방식이 자주 소개되고 있습니다. 인간의 역할은 점점 '매니저'에 가까워지는 인상입니다.
필자의 이해: 같은 프롬프트를 사용하여 에이전트를, 태스크가 끝날 때까지 반복적으로 루프 실행시키는 단순한 방법.
구조는 간단하지만, 테스트 등의 '완료 조건'을 확실히 마련해 두면 놀라울 정도로 진도가 나간다는 점이 흥미롭습니다.
필자의 이해: 먼저 테스트를 작성하게 하거나(또는 인간이 작성), 그 테스트가 통과하도록 구현시키는 방법.
AI는 '그럴듯하지만 틀린 코드'를 작성할 수 있기 때문에, 정확성을 기계적으로 판별할 수 있는 테스트가 AI를 활용한 개발에서는 이전보다 훨씬 중요해지고 있다고 느낍니다. 하네스 엔지니어링(Harness Engineering)과도 궁합이 좋습니다.
필자의 이해: LLM을 결합한 기능을 평가용 데이터셋(evals)으로 점수를 매기면서 개선해 나가는 방법.
LLM의 출력은 매번 조금씩 바뀌기 때문에, '어느 정도 좋아진 것 같다'가 아니라, 숫자로 비교하기 위한 사고방식입니다. 오히려 AI를 활용해서 만드는 이야기보다는, AI를 결합한 앱을 만들 때의 이야기입니다.
필자의 이해: 작업할 때마다 배운 것(실패/규칙/요령)을 문서나 규칙 파일에 기록하여 되돌려주고, AI가 점차 똑똑하게 움직이도록 만드는 생각.
'복리(compound)'와 같이 개선이 쌓여서 효과를 발휘하는 이미지입니다. CLAUDE.md
혹은 스킬에 지식을 키워나가는 운용 방식은 바로 이것이라고 이해하고 있습니다.
방법 자체는 아니지만, 자주 함께 언급되기 때문에 간략하게 소개합니다.
| 키워드 | 필자의 이해 |
|---|
| MCP (Model Context Protocol) | AI와 외부 툴/데이터(GitHub, DB, Slack 등)를 연결하기 위한 표준 사양 |
| Agent Skills / 커스텀 명령어 | 자주 사용하는 절차나 노하우를, AI가 재활용할 수 있는 형태로 모아두는 시스템 |
| 서브 에이전트 (Sub-agent) | 조사나 리뷰 등의 작업을, 다른 AI 에이전트에게 분리하여 맡기는 시스템 |
| RAG | 검색해 온 정보를 컨텍스트에 넣어 답변하게 하는 방법 |
| 계층 | 방법 | 한마디로 |
|---|---|
① 입력/환경 | 프롬프트 엔지니어링 | 지시문을 고안하는 것
...|
유행어에 휘둘리기보다는, 자신의 팀이나 프로젝트에 맞는 것을 조합해서 시도해 보는 것이 좋을 것 같습니다.
-
Effective context engineering for AI agents (Anthropic Engineering Blog)
-
컨텍스트 엔지니어링을 프롬프트 엔지니어링의 다음 단계로 설명한 글
-
Harness engineering: leveraging Codex in an agent-first world (OpenAI, 2026년 2월)
-
손으로 코드를 전혀 사용하지 않고 제품을 개발한 사례를 바탕으로 하네스 엔지니어링을 소개한 글
-
Harness Engineering - first thoughts (martinfowler.com)
-
위 OpenAI 기사에 대한 고찰
-
Code Generation with AlphaCodium: From Prompt Engineering to Flow Engineering (arXiv, 2024년 1월)
-
플로우 엔지니어링이라는 용어가 사용된 논문입니다. 구현은 GitHub에서 공개되어 있습니다.
-
Andrej Karpathy 씨의 X 게시물 (2025년 2월)
-
'바이브 코딩'이라는 용어가 탄생한 게시물
-
Spec-driven development with AI: Get started with a new open source toolkit (GitHub Blog, 2025년 9월)
-
GitHub Spec Kit 소개 글
-
Kiro 공식 사이트
-
요구사항 기반 개발(Spec-driven development)을 전면에 내세운 AWS의 에이전트형 IDE
-
AI-Driven Development Life Cycle: Reimagining Software Engineering (AWS DevOps Blog)
-
AI-DLC를 소개한 AWS의 글. 일본어 버전도 있습니다.
-
Ralph Wiggum as a "software engineer" (Geoffrey Huntley, 2025년 7월)
-
Ralph 루프가 된 계기가 된 글
-
Compound Engineering: How Every Codes With Agents (Every)
-
Plan → Work → Review → Compound 사이클을 소개한 글
-
Compound Engineering 가이드 (Every)