프롬프트 → 컨텍스트 → 하네스 엔지니어링 - AI 시대 엔지니어링 패러다임의 진화

들어가며

2022년 ChatGPT 등장 이후 "프롬프트 엔지니어링"이 AI 시대의 핵심 역량으로 떠올랐다. 하지만 불과 4년 만에, 업계의 시선은 이미 그 너머를 향하고 있다.

2025년에는 컨텍스트 엔지니어링(Context Engineering)이 Anthropic, Shopify 등 주요 기업에서 본격적으로 다뤄지기 시작했고, 2026년에는 하네스 엔지니어링(Harness Engineering)이라는 개념이 AI 엔지니어링 커뮤니티에서 주목받고 있다. 특히 2026년 3월 Claude Code 소스코드 유출 사건 이후 Google Gemma 4 완벽 정리 최신 동향, 에이전트 하네스 설계에 대한 논의가 크게 늘어났다. 다만 "Harness Engineering"이 업계 전체의 표준 용어로 완전히 정착했다고 보기는 아직 이른 단계다.

이 글에서는 AI 엔지니어링 패러다임이 어떻게 진화해왔는지, 각각의 차이는 무엇인지, 그리고 실무에서 어떻게 적용해야 하는지를 정리한다.

1. 세 가지 패러다임 한눈에 보기

구분	프롬프트 엔지니어링	컨텍스트 엔지니어링	하네스 엔지니어링
부각 시기	2022~2024	2025~	2025 후반~2026
핵심 질문	"어떻게 물어볼까?"	"무엇을 알려줄까?"	"어떤 환경에서 일하게 할까?"
대상	단일 LLM 호출	LLM + 정보 파이프라인	자율 에이전트 시스템 전체
범위	입력 텍스트 최적화	정보 생태계 설계	제약, 피드백, 오케스트레이션
비유	좋은 질문을 던지는 것	필요한 자료를 책상 위에 준비하는 것	사무실 전체를 설계하는 것

이 세 가지는 대체 관계가 아니라 계층적 포함 관계다. 프롬프트는 컨텍스트 안에 존재하고, 컨텍스트는 하네스 안에서 동작한다.

2. 프롬프트 엔지니어링 (Prompt Engineering)

정의

LLM에 전달하는 입력 텍스트를 최적화하여 원하는 출력을 얻는 기술이다. Few-shot 예시 제공, 역할 부여("당신은 시니어 개발자입니다"), Chain-of-Thought 유도 등이 대표적인 기법이다.

한계

• 단일 호출 최적화: 입력-출력 한 쌍에만 집중하므로, 복잡한 워크플로우에 적용 불가
• 확장성 부족: 사용자가 늘면 엣지 케이스도 늘어남. 프롬프트만으로는 대응 불가
• 정적 한계: 프롬프트가 아무리 완벽해도, 모델이 필요한 정보를 모르면 무용지물

# 프롬프트 엔지니어링의 전형적 패턴
prompt = """
당신은 시니어 Java 개발자입니다.
아래 코드의 성능 문제를 분석하고 개선안을 제시하세요.

[코드]
{user_code}

출력 형식: JSON
"""

이것만으로도 간단한 작업은 해결된다. 하지만 "대부분의 에이전트 실패는 모델의 실패가 아니라 컨텍스트의 실패"라는 것이 2025년의 결론이었다.

3. 컨텍스트 엔지니어링 (Context Engineering)

정의

Shopify CEO Tobi Lütke의 정의가 가장 널리 인용된다:

"Context Engineering은 LLM이 과제를 그럴듯하게 해결할 수 있도록 모든 컨텍스트를 제공하는 기술이다."

Phil Schmid(전 Hugging Face)는 이를 더 구체적으로 정의한다:

"적절한 정보와 도구를, 적절한 형식으로, 적절한 시점에 제공하는 동적 시스템을 설계하고 구축하는 분야."

7가지 핵심 구성요소

#	구성요소	역할	예시
1	System Prompt	행동 지침, 규칙, 페르소나	"JSON으로만 응답하세요"
2	User Prompt	사용자의 즉각적 요청	"이 코드를 리팩토링해줘"
3	단기 메모리	현재 대화 히스토리	이전 메시지들
4	장기 메모리	대화 간 지속되는 지식	사용자 선호, 프로젝트 요약
5	RAG 정보	외부에서 검색한 최신 데이터	문서, DB, API 결과
6	사용 가능 도구	모델이 호출할 수 있는 함수	check_inventory, send_email
7	출력 구조	응답 형식 지정	JSON Schema, 타입 정의

프롬프트 vs 컨텍스트: "싸구려 데모" vs "마법 같은 경험"

같은 "회의 일정 잡아줘" 요청에 대해:

# 프롬프트만 있는 경우 (싸구려 데모)
→ "네, 회의 일정을 잡겠습니다. 언제가 좋으세요?"
  (캘린더도 모르고, 참석자 선호도도 모름)

# 컨텍스트가 풍부한 경우 (마법)
→ 캘린더 데이터 + 이전 이메일 톤 + 참석자 관계 + 
  회의실 예약 도구가 사전 로딩됨
→ "김팀장님과 수요일 오후 2시에 3층 회의실을
   예약했습니다. 지난번처럼 아젠다도 첨부했어요."

핵심은 LLM 호출 전에 실행되는 동적 시스템이라는 점이다. 매 요청마다 필요한 정보를 조립하고, 관련 도구를 활성화하고, 적절한 형식을 지정하는 파이프라인을 설계하는 것이 컨텍스트 엔지니어링이다.

4. 하네스 엔지니어링 (Harness Engineering)

정의

AI 에이전트를 프로덕션에서 안정적으로 동작하게 만드는 시스템, 제약, 피드백 루프를 설계하는 분야다. Anthropic은 2025~2026년 공식 블로그에서 "harness", "harness design"이라는 표현을 사용하며 장기 실행 에이전트에서의 중요성을 강조하고 있다.

컨텍스트 엔지니어링이 "모델에게 무엇을 알려줄까"에 집중한다면, 하네스 엔지니어링은 "모델이 어떤 환경에서 작업하게 할까"에 집중한다.

왜 필요한가?

자율 에이전트는 여러 컨텍스트 윈도우에 걸쳐 작업한다. Meta Llama 4 초장문 컨텍스트 활용하기 각 새 세션은 이전 기억 없이 시작된다. 이 "컨텍스트 엔트로피" 문제를 해결하려면, 에이전트 외부에 구조화된 시스템이 필요하다.

5가지 핵심 원칙

1. Constrain (제약): 에이전트가 할 수 있는 것을 제한한다. 권한 모델, 샌드박스, 허용 도구 목록
2. Inform (정보): 에이전트가 알아야 할 것을 제공한다. 진행 상황 파일, Git 히스토리, 기능 목록
3. Verify (검증): 에이전트의 작업을 검증한다. 자동 테스트, 브라우저 자동화, 린트
4. Correct (교정): 실수를 수정한다. Git 되돌리기, 에러 핸들링, 재시도 로직
5. Escalate (에스컬레이션): 고위험 결정은 사람에게 넘긴다. 승인 프롬프트, 권한 게이트

Claude Code에서 드러난 하네스 아키텍처

유출된 Claude Code 소스를 분석한 여러 보도와 커뮤니티 글에서 공통적으로 언급하는 핵심 구성요소는 다음과 같다(정확한 수치는 출처에 따라 다소 차이가 있다):

# Claude Code 하네스 구조 (유출 보도 기반 정리)

1. 권한 게이트 도구 (다수)
   - 파일 읽기/쓰기, Bash 실행, 웹 접근 등
   - 각 도구마다 사용자 승인 레벨 설정

2. 쿼리 엔진
   - LLM API 호출, 토큰 캐싱
   - 컨텍스트 관리, 재시도 로직

3. 다층 메모리 아키텍처
   - CLAUDE.md: 프로젝트 레벨 지침
   - 대화 히스토리: 현재 세션
   - 자동 메모리: 세션 간 지식 축적

4. Hooks 시스템
   - 도구 호출 전/후 셸 명령 실행
   - 린팅, 포매팅, 테스트 자동 실행

Anthropic의 장기 실행 에이전트 하네스 패턴

Anthropic이 공식 블로그에서 제시한 패턴은 다음과 같다:

구성요소	역할
Initializer Agent	init.sh로 환경 구성, 초기 파일 생성, 첫 Git 커밋
Coding Agent	표준화된 워크플로우로 점진적 진행
Feature List (JSON)	기능별 pass/fail 추적, 삭제/수정 방지
Progress File	세션 간 진행 상황 기록 (사람이 읽을 수 있는 형태)
Git History	복구 가능한 코드 상태, 서술적 커밋 메시지

일부 커뮤니티 글에서는 하네스 설계만으로도 에이전트 성능이 크게 개선될 수 있다고 보고하고 있다. 실제로 모델 자체를 바꾸지 않고 하네스만 개선해도 체감 성능이 크게 달라진다는 것이 실무자들의 공통된 경험이다.

5. 그 너머: 떠오르는 새로운 패러다임들

5-1. 에이전트 지향 엔지니어링 (Agent-Oriented Engineering)

2026년 등장한 개념으로, 자연어가 새로운 프로그래밍 인터페이스가 되는 패러다임이다. 엔지니어는 코드를 직접 작성하는 대신 AI 에이전트 포트폴리오를 오케스트레이션하는 역할로 전환한다.

# 전통적 개발 (코드 직접 작성)
git checkout -b feature/login
vim src/auth/LoginService.java
# ... 수백 줄 코딩 ...

# 에이전트 지향 개발 (2026)
"로그인 서비스를 구현해줘. OAuth2 + JWT 기반,
 Spring Security 6 사용, 테스트 포함"
→ 에이전트가 구현, 테스트, PR 생성까지 자동 수행

5-2. 스캐폴드 엔지니어링 (Scaffold Engineering)

에이전트의 초기 작업 구조를 설계하는 분야다. 프로젝트 템플릿, 디렉토리 구조, 설정 파일, 테스트 프레임워크 등 에이전트가 일을 시작할 수 있는 발판을 만드는 것에 초점을 맞춘다.

5-3. 워크플로우 아키텍처 (Automated Workflow Architecture)

OpenAI 커뮤니티에서는 "프롬프트 엔지니어링은 죽었고, 컨텍스트 엔지니어링도 이미 구식"이라며 자동화된 워크플로우 아키텍처를 주장하는 목소리도 있다. LLM을 워크플로우의 하나의 노드로 취급하고, 전체 파이프라인을 설계하는 접근이다.

6. 실무에서의 적용: 백엔드 개발자를 위한 가이드

레벨 1: 프롬프트 엔지니어링 활용

// AI 코딩 도구에 좋은 프롬프트 쓰기
"이 Spring Boot 서비스에 Redis 캐시를 적용해줘.
Cache-Aside 패턴으로, TTL은 5분,
@Cacheable 어노테이션 사용"

레벨 2: 컨텍스트 엔지니어링 활용

// CLAUDE.md (프로젝트 컨텍스트 파일)
# 프로젝트 개요
- Spring Boot 4 + Java 26
- PostgreSQL 17 + Redis 7
- 헥사고날 아키텍처

# 코딩 규칙
- 모든 public 메서드에 단위 테스트 필수
- DTO → Domain 변환은 MapStruct 사용
- 예외는 GlobalExceptionHandler에서 처리

# 절대 하지 말 것
- System.out.println 사용 금지 (SLF4J 사용)
- 하드코딩된 설정값 금지 (application.yml 사용)

레벨 3: 하네스 엔지니어링 활용

// .claude/settings.json (하네스 설정)
{
  "hooks": {
    "post-tool-use": [{
      "matcher": "Edit|Write",
      "command": "./gradlew spotlessCheck"
    }],
    "pre-tool-use": [{
      "matcher": "Bash",
      "command": "echo 'Bash 실행 감지' >> audit.log"
    }]
  },
  "permissions": {
    "allow": ["Read", "Glob", "Grep"],
    "deny": ["Bash(rm -rf*)"]
  }
}

7. 패러다임 선택 가이드

상황	적합한 접근
단순 코드 생성, 일회성 질의	프롬프트 엔지니어링
RAG 파이프라인, 챗봇, 멀티턴 대화	컨텍스트 엔지니어링
자율 코딩 에이전트, 장기 실행 태스크	하네스 엔지니어링
팀 단위 AI 기반 개발 프로세스	에이전트 지향 엔지니어링

마치며

AI 엔지니어링의 진화는 놀라울 정도로 빠르다. 2026 백엔드 기술 스택 총정리에서 AI 통합 확인하기

• 프롬프트 엔지니어링: 모델에게 좋은 질문을 던지는 것
• 컨텍스트 엔지니어링: 모델에게 필요한 모든 정보를 제공하는 시스템을 만드는 것
• 하네스 엔지니어링: 모델이 안정적으로 작동하는 전체 환경을 설계하는 것

중요한 것은 이 세 가지가 서로를 대체하는 것이 아니라는 점이다. 좋은 프롬프트는 여전히 필요하다. 다만 그 프롬프트가 잘 설계된 컨텍스트 레이어 안에 존재하고, 그 컨텍스트가 견고한 하네스 안에서 동작할 때 비로소 프로덕션 수준의 신뢰성을 달성할 수 있다. MCP로 AI 에이전트 도구 통합 표준화하기

백엔드 개발자라면, 지금 당장 자신의 프로젝트에 Spring AI로 RAG와 Function Calling 구현하기 CLAUDE.md를 만들어보는 것부터 시작하자. 그것이 컨텍스트 엔지니어링의 첫걸음이다.