이런 분이 읽으면 좋습니다
요약: LLM 활용 방법론은 프롬프트 엔지니어링(입력 텍스트 최적화) -> 컨텍스트 엔지니어링(프롬프트+RAG+도구+메모리 통합) -> 하네스 엔지니어링(에이전트 런타임 전체 제어)으로 진화했다. 각 단계는 이전 단계를 포함하며, 2026년 현재 에이전트 기반 시스템을 만드는 팀이라면 하네스 엔지니어링이 필수다.
이 글은 LLM 기반 제품을 만들거나 AI 에이전트를 설계하는 개발자를 위해 썼다. 각 패러다임이 왜 등장했는지, 무엇이 달라졌는지, 실무에서 어떻게 적용하는지를 다룬다.
세 패러다임의 핵심 차이
| 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 | 하네스 엔지니어링 | |
|---|---|---|---|
| 제어 대상 | 입력 텍스트 | 정보 파이프라인 전체 | 에이전트 런타임 전체 |
| 핵심 질문 | 어떻게 물어볼까? | 무엇을 언제 보여줄까? | 에이전트가 어떻게 행동할까? |
| 주요 도구 | 프롬프트 템플릿, few-shot | RAG, 도구 호출, 메모리 | CLAUDE.md, hooks, MCP, 오케스트레이터 |
| 주류 시기 | 2022-2023 | 2024-2025 | 2026- |
| 스킬 레벨 | 개인 개발자 | 백엔드/ML 팀 | 플랫폼 엔지니어링 팀 |
| 실패 모드 | 프롬프트 깨짐, 환각 | 컨텍스트 오염, 검색 실패 | 에이전트 폭주, 권한 초과 |
프롬프트 엔지니어링 — 입력 텍스트 최적화
2022-2023년, ChatGPT와 GPT-4 등장 이후 LLM 활용의 첫 번째 물결이었다. 핵심은 모델에게 보내는 텍스트를 어떻게 구성하느냐다.
주요 기법은 몇 가지로 정리된다. 역할 지정(system prompt에 역할 부여), few-shot 예시(입출력 쌍을 제시), Chain-of-Thought(단계적 추론 유도), 출력 형식 지정(JSON, 마크다운 등 구조 강제)이 대표적이다.
프롬프트 엔지니어링은 지금도 유효하다. 모든 LLM 상호작용의 기초이며, 프롬프트를 잘 쓸 줄 모르면 이후 단계도 무너진다. 하지만 한계가 명확하다.
단일 프롬프트에 모든 맥락을 넣으려면 토큰 한도에 부딪힌다. 외부 데이터가 바뀌면 프롬프트를 수동으로 갱신해야 한다. 여러 단계의 작업을 하나의 프롬프트로 처리하면 품질이 급격히 떨어진다. 이런 한계가 다음 패러다임을 만들었다.
컨텍스트 엔지니어링 — 정보 파이프라인 관리
2024-2025년에 주류가 된 접근이다. Andrej Karpathy가 설명한 것처럼, 컨텍스트 엔지니어링은 모델의 컨텍스트 윈도우를 채우는 모든 정보를 설계하는 것이다. 프롬프트는 그 구성 요소 중 하나일 뿐이다.
네 가지 구성 요소
프롬프트: 시스템 메시지와 사용자 입력. 프롬프트 엔지니어링에서 다루던 영역이 여기에 포함된다.
RAG (검색 증강 생성): 외부 데이터베이스에서 관련 정보를 검색해서 컨텍스트에 삽입한다. 모델이 알지 못하는 최신 정보, 사내 문서, 도메인 데이터를 동적으로 공급한다.
도구 (Tool Use): 모델이 직접 외부 시스템을 호출한다. API 요청, 데이터베이스 쿼리, 코드 실행 등. 모델이 “읽기만 하는” 수동적 상태에서 “행동하는” 능동적 상태로 전환된다.
메모리: 대화 이력, 사용자 선호도, 이전 작업 결과를 저장하고 재활용한다. 단일 세션을 넘어서 연속성을 만든다.
그러나 컨텍스트 엔지니어링도 한계에 부딪혔다. 에이전트가 여러 단계를 자율적으로 수행하면, 어떤 도구를 언제 어떤 순서로 호출할지, 실패 시 어떻게 복구할지, 권한은 어디까지 허용할지를 런타임 수준에서 제어해야 한다. 컨텍스트를 잘 채우는 것만으로는 부족해졌다.
하네스 엔지니어링 — 에이전트 런타임 전체 제어
2026년 현재 형성되고 있는 패러다임이다. 하네스 엔지니어링은 LLM 에이전트가 동작하는 런타임 환경 전체를 설계하고 제어하는 것이다. “harness”라는 단어 자체가 “장치를 올바르게 연결하고 제어하는 체계”를 뜻한다.
하네스의 구성 요소
시스템 지시 파일 (CLAUDE.md 등): 에이전트의 행동 규칙, 코딩 컨벤션, 프로젝트별 맥락을 파일로 관리한다. 프롬프트와 다른 점은 프로젝트 저장소에 커밋되고, 팀 전체가 공유하며, 버전 관리된다는 것이다.
Hooks: 에이전트의 특정 행동 전후에 자동으로 실행되는 스크립트다. 커밋 전 린트 실행, 파일 수정 전 백업 생성, 도구 호출 후 결과 검증 등을 에이전트가 아닌 인프라 레벨에서 강제한다.
MCP (Model Context Protocol) 서버: 에이전트가 사용할 수 있는 도구를 표준화된 프로토콜로 제공한다. 각 MCP 서버가 특정 도메인(파일 시스템, 데이터베이스, 외부 API)에 대한 접근을 캡슐화한다. 도구를 “하드코딩”하는 것이 아니라 “플러그인”으로 교체 가능하게 만든다.
워크플로우 오케스트레이션: 복잡한 작업을 여러 에이전트 또는 여러 단계로 분할하고, 실행 순서, 병렬 처리, 오류 복구, 타임아웃을 관리한다. 단일 LLM 호출이 아니라 다단계 파이프라인을 설계한다.
왜 “하네스”인가
프롬프트 엔지니어링이 “무엇을 말할까”를 설계하고, 컨텍스트 엔지니어링이 “무엇을 보여줄까”를 설계한다면, 하네스 엔지니어링은 “어떤 환경에서 어떤 규칙으로 행동하게 할까”를 설계한다.
비유하자면 이렇다. 프롬프트 엔지니어링은 조종사에게 비행 지시를 내리는 것이다. 컨텍스트 엔지니어링은 조종사에게 계기판, 기상 데이터, 항로 정보를 제공하는 것이다. 하네스 엔지니어링은 비행기 자체를 설계하는 것이다 — 엔진, 자동 조종 장치, 안전 시스템, 비상 프로토콜까지.
실무 적용 가이드
단계 1: 프롬프트 기반으로 시작
프로토타입 단계에서는 프롬프트 엔지니어링만으로 충분하다. system prompt에 역할과 규칙을 명확히 정의하고, few-shot 예시로 품질을 잡는다. 대부분의 PoC는 이 단계에서 검증할 수 있다.
단계 2: 프로덕션 전환 시 컨텍스트 설계
사용자 데이터가 들어오고 외부 정보가 필요해지면, RAG 파이프라인과 도구 호출을 추가한다. 이 시점에서 프롬프트 템플릿을 동적 컨텍스트 조합으로 전환한다. 메모리 레이어로 세션 연속성을 확보한다.
단계 3: 에이전트 자율성이 필요하면 하네스 설계
에이전트가 코드를 작성하고, 테스트를 돌리고, 배포까지 수행해야 한다면, 하네스 엔지니어링이 필수다. CLAUDE.md로 행동 규칙을 코드화하고, hooks로 안전 장치를 자동화하며, MCP 서버로 도구 접근을 표준화한다.
피해야 할 실수
하네스 엔지니어링에서 가장 흔한 실수 세 가지가 있다.
첫째, 에이전트에게 무제한 권한을 준다. 하네스의 핵심 역할은 에이전트의 행동 범위를 제한하는 것이다. hooks로 위험한 명령(삭제, 배포, 외부 전송)에 확인 단계를 강제하고, MCP 서버의 권한을 최소 원칙으로 설정해야 한다.
둘째, 모든 것을 하나의 에이전트로 처리한다. 단일 에이전트에 20개의 MCP 서버를 연결하면 도구 선택 정확도가 급락한다. 역할별로 에이전트를 분리하고, 오케스트레이터가 작업을 라우팅하는 구조가 프로덕션에서 훨씬 안정적이다.
셋째, 하네스 설정을 코드 리뷰에서 제외한다. CLAUDE.md, hooks 설정, MCP 서버 구성은 에이전트의 행동을 결정하는 코드다. 일반 소스 코드와 동일한 수준으로 리뷰하고 테스트해야 한다.
다음에 읽을 글
- LLM 구조화 출력: JSON 모드 vs 함수 호출 vs 제약 디코딩 — 에이전트가 구조화된 데이터를 반환할 때의 선택지
- 프로덕션 AI 서비스의 프롬프트 버전 관리 — 프롬프트와 시스템 지시 파일의 버전 관리 전략
- RAG 파이프라인 설계: 청킹부터 검색 품질 모니터링까지 — 컨텍스트 엔지니어링의 핵심인 RAG 파이프라인 구축