하네스 엔지니어링
패러다임 진화, 하네스 구성 요소, 설계 패턴, 프로덕션 성숙도
하네스 엔지니어링
패러다임 진화, 하네스 구성 요소, 설계 패턴, 프로덕션 성숙도
Agent = Model + Harness
도구 · 메모리 · 오케스트레이션 · 가드레일 · 평가 — 에이전트 실행 환경 전체의 설계
패러다임 진화
Prompt → Context → Harness — 넓어지는 설계 범위
패러다임 진화
입력에서 실행 환경으로 — 최적화 대상이 한 겹씩 넓어져 온 진화의 흐름
프롬프트에서 하네스로
최적화 대상이 입력 텍스트에서 실행 환경 전체로 넓어져 온 흐름을 짚습니다.
- 프롬프트 엔지니어링 — "어떻게 물어볼까"
- 컨텍스트 엔지니어링 — "무엇을 보여줄까"
- 하네스 엔지니어링 — "어떤 환경에서 실행할까"
- 공식화 — Martin Fowler · ThoughtWorks (2026)
세 패러다임은 대체가 아니라 포함 관계(Harness ⊃ Context ⊃ Prompt)입니다 — 설계 범위가 한 겹씩 넓어집니다.
엔지니어링 패러다임 3단계
입력 최적화에서 실행 환경 설계까지 — 한 겹씩 넓어진 최적화 대상
Harness Engineering 용어는 2026년 Martin Fowler와 ThoughtWorks가 정립했습니다 — 모델이 에이전트가 되면서 필연이 된 확장입니다.
포함 관계 — Prompt ⊂ Context ⊂ Harness
대체가 아니라 확장 — 안쪽 겹은 그대로 두고 설계 범위가 한 겹씩 넓어지는 구조
하네스를 설계하면 컨텍스트와 프롬프트도 그 안에서 함께 설계됩니다 — 바깥 겹이 안쪽 겹을 포함합니다.
세 패러다임 비교
초점 · 최적화 대상 · 결과물 · 포함 관계 4축으로 본 차이
| 항목 | Prompt | Context | Harness |
|---|---|---|---|
| 초점 | 입력 텍스트 | 컨텍스트 윈도우 | 실행 환경 전체 |
| 최적화 대상 | 지시 품질 | 정보 선별·압축 | 행동 범위·안전·확장 |
| 결과물 | 단일 호출 개선 | 정보 활용도 개선 | 자율 에이전트 동작 |
| 포함 관계 | — | Prompt ⊂ Context | Context ⊂ Harness |
상위 개념이 하위를 포함합니다 — 하네스를 잘 설계하면 컨텍스트와 프롬프트 품질도 자연스럽게 따라옵니다.
왜 하네스까지 왔는가
모델이 도구를 호출하고 반복하고 위임하는 에이전트가 되면서 생긴 변화
단일 호출이 아닌 지속적 루프를 관리하는 시대입니다 — 프롬프트가 아니라 실행 환경이 설계 과제가 됩니다.
하네스의 정의와 구성 요소
Agent = Model + Harness · Tool · Orchestrator · Memory · Guard · Eval
정의와 구성 요소
모델을 감싸는 실행 환경의 정의와 다섯 구성 요소
Agent = Model + Harness
모델을 감싸는 실행 환경 전체가 하네스입니다 — 도구, 메모리, 오케스트레이션, 가드레일, 평가.
- Model = 엔진 · Harness = 도로 · 신호 · 규칙 · 정비소
- 5대 구성 요소 — Tool · Orchestrator · Memory · Guard · Eval
- 핵심 역할 — 행동 범위 · 안전장치 · 확장성 · 관측성
- 요소 선택 — 태스크 복잡도에 따라 점진 추가
모델 성능만으로는 에이전트 품질이 결정되지 않습니다 — 실행 환경 전체가 프로덕션 품질을 결정합니다.
하네스 정의 — 수식 한 줄
프로덕션 에이전트의 최소 정의 — 모델 하나로는 항이 부족한 수식
모델은 엔진, 하네스는 실행 환경
프롬프트 확장이 아닌 행동 범위·안전장치·확장성의 시스템 설계
Model — 엔진
추론 능력
- 계획 · 판단 · 생성의 원천
- 교체 가능한 부품 — 프로바이더 전환 가능
- 엔진 단독으로는 목적 달성 불가
자동차의 엔진, 극장의 배우, 우주선의 추진체에 해당합니다. 핵심 능력이지만 주변 시스템 없이는 목적지에 도달하지 못합니다.
Harness — 실행 환경
도로 · 신호 · 규칙 · 정비소
- 행동 범위 정의 — 할 수 있는 것의 경계
- 안전장치 — 잘못된 행동의 사전 차단·사후 교정
- 확장성 — 메모리 · 도구 · 하위 에이전트
- 관측성 — 무엇을 했는지 추적·분석·개선
변속기·브레이크·내비게이션·안전벨트처럼 엔진을 감싸 속도와 안전, 목적지를 결정합니다. 하네스는 프롬프트를 잘 쓰는 기술이 아니라 시스템 설계입니다.
하네스 없는 모델은 비포장 도로 위의 스포츠카입니다 — 같은 엔진이라도 도로가 속도와 안전, 목적지를 결정합니다.
하네스 5대 구성 요소
Tool·Orchestrator·Memory·Guard·Eval — 상호작용·지휘·기억·안전·품질을 맡는 다섯 레이어
다섯 요소가 전부 필수는 아닙니다 — 태스크 복잡도에 따라 선택 적용하고, 요소 간 상호작용이 하네스 품질을 결정합니다.
구성 요소 선택 기준
단순 봇에서 프로덕션 에이전트까지 — 복잡도에 따른 점진 확장 경로
-
1
단순 Q&A 봇
Model + Tool 1~2개면 충분합니다. 검색이나 조회처럼 행동이 단순하면 무거운 하네스는 과잉 설계가 됩니다.
-
2
도구 사용 에이전트
Orchestrator를 더해 3요소로 구성합니다. 여러 도구의 선택과 실행 순서를 제어해야 하는 단계입니다.
-
3
프로덕션 에이전트
Guard · Eval · Memory까지 5요소 전부를 갖춥니다. 안전과 품질, 세션 간 기억이 서비스 신뢰성을 좌우합니다.
처음부터 다 넣지 않습니다 — 복잡도가 올라갈 때 요소를 점진적으로 추가하는 것이 하네스 설계의 기본기입니다.
에이전틱 루프와 오케스트레이션
Plan → Act → Observe → Reflect · 제어 전략 3가지
에이전틱 루프
루프 4단계와 이를 제어하는 오케스트레이션 전략
Plan → Act → Observe → Reflect
에이전트의 심장은 단일 호출이 아닌 반복 루프입니다 — 루프의 제어 방식이 곧 오케스트레이션 전략입니다.
- 루프 4단계 — 계획 · 행동 · 관찰 · 성찰
- ReAct — 즉흥적 반복, 빠른 응답
- Plan-and-Execute — 전체 계획 후 순차 실행
- Tree of Thought — 여러 경로 탐색 후 최선 선택
루프가 에이전트를 만들고, 오케스트레이션 전략이 루프를 제어합니다 — 프로덕션에서는 반복 상한이 필수입니다.
루프를 도는 4단계
단일 호출(Prompt → Response)이 아닌 반복 루프가 에이전트의 핵심 — 매 순환마다 행동을 결정하고 결과를 관찰
오케스트레이션 3가지 전략
루프의 제어 방식을 결정하는 세 전략과 각각의 적합 상황
ReAct
Think → Act → Observe 반복
- 즉흥적 — 매 스텝마다 다음 행동 결정
- 구현 단순, 응답 빠름
- 긴 다단계 계획에는 부적합
언제 — 단순 도구 호출, 빠른 응답이 중요한 대화형 에이전트
Plan-and-Execute
전체 계획 수립 → 순차 실행
- 계획 단계와 실행 단계를 분리
- 복잡한 다단계 태스크에 강함
- 중간 상황 변화 시 재계획 필요
언제 — 단계가 많고 의존 관계가 있는 복잡한 태스크
Tree of Thought
여러 경로 탐색 → 최선 선택
- 후보 경로를 병렬 탐색·평가
- 정답이 불확실한 추론에 강함
- 토큰 비용이 가장 큼
언제 — 탐색과 백트래킹이 필요한 불확실한 추론 문제
기본은 ReAct입니다 — 태스크가 복잡해질수록 계획형·탐색형으로 확장하되, 비용과 지연을 함께 계산합니다.
ReAct 루프 — Strands 기본 동작
@tool 함수와 Agent 조립만으로 자동 구동되는 에이전틱 루프
from strands import Agent, tool
from strands.models import BedrockModel
model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6")
@tool
def check_inventory(item: str) -> str:
"""재고를 확인합니다."""
return f"{item}: 재고 12개"
# ① 에이전트 조립 — tools를 전달하면 에이전틱 루프가 자동 구동
agent = Agent(
model=model,
system_prompt="재고 문의를 처리하는 에이전트입니다.",
tools=[check_inventory],
)
# ② 실행 — Plan→Act→Observe→Reflect 반복, limits가 반복 상한
result = agent("A4 용지 재고 있어?", limits={"turns": 10})
print(str(result)) # ③ 결과 텍스트 추출
- tools 자동 루프 — 리스트만 전달하면 루프가 자동 구동, 별도 while 루프를 작성하지 않습니다
- 루프 상한 — Agent 생성자에는 max_iterations가 없습니다, 호출 시 limits(turns·토큰 예산)가 정본 — Hooks(BeforeToolCallEvent)는 도구 호출 개입용 보조 수단
- str(result) — 결과 텍스트 추출
설계 패턴
Self-Correcting · Human-in-the-Loop · Checkpoint · Progressive Delegation
설계 패턴
반복 검증된 설계 패턴과 상황별 선택 기준
검증된 하네스 구성 방법론
반복적으로 검증된 패턴을 조합해 태스크 복잡도와 위험도에 대응합니다.
- Self-Correcting — 결과 자체 평가 후 재시도
- Human-in-the-Loop — 고위험 액션 승인 게이트
- Checkpoint — 중간 상태 저장 · 복구
- Progressive Delegation — 신뢰도 따라 권한 확대
패턴은 배타적이지 않습니다 — 하나의 에이전트에 여러 패턴을 조합하고, 단순한 것부터 점진 적용합니다.
핵심 패턴 7가지
반복 검증된 일곱 패턴 — 조합 가능하며, 프로덕션 적용은 Self-Correcting까지가 안전선
| 패턴 | 핵심 아이디어 | 적합 상황 |
|---|---|---|
| Retrieval-Augmented | RAG(검색 증강 생성) + 도구 호출 결합 | 문서 기반 질의응답 |
| Self-Correcting | 결과 자체 평가 후 재시도 | 코드 생성, 정확도 중시 |
| Human-in-the-Loop | 고위험 액션 전 인간 승인 | 결제 · 삭제 · 프로덕션 변경 |
| Checkpoint | 중간 상태 저장 · 복구 | 장기 실행, 장애 복구 |
| Progressive Delegation | 신뢰도에 따라 권한 확대 | 점진적 자율성 부여 |
| Context Offloading | 큰 결과는 외부 저장, 요약만 유지 | 대용량 결과, 토큰 절약 |
| Self-Modifying | AI가 자신의 하네스를 수정 — 연구 단계 | Meta FAIR Hyperagents |
상황별 패턴 선택
위험도 → 정확도 → 실행 시간 순으로 좁혀가는 선택 흐름
Self-Correcting — 자기 교정 루프
coder가 생성하고 reviewer가 검증하는 두 에이전트의 자기 교정 루프
from strands import Agent
from strands.models import BedrockModel
model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6")
# ① 역할 분리 — 생성하는 에이전트와 검증하는 에이전트
coder = Agent(
model=model,
system_prompt="Python 코드를 작성합니다. 간결하고 테스트 가능하게.",
)
reviewer = Agent(
model=model,
system_prompt="코드를 리뷰합니다. 버그, 보안, 성능 문제를 지적합니다.",
)
# ② 자기 교정 루프 — 리뷰어가 승인할 때까지 반복 개선 (상한 필수)
def self_correcting_loop(task: str, max_attempts: int = 3) -> str:
code = str(coder(task))
for _ in range(max_attempts):
review = str(reviewer(f"다음 코드를 리뷰하세요. 문제없으면 PASS만 출력:\n{code}"))
# ③ 종료 조건 — 리뷰 통과 시 루프 탈출
if "PASS" in review.upper():
return code
code = str(coder(f"리뷰 피드백을 반영하세요:\n{review}\n원본:\n{code}"))
return code
- 역할 분리 — coder와 reviewer의 시스템 프롬프트가 서로 다른 관점을 강제, 같은 모델이라도 역할이 나뉩니다
- max_attempts — 최대 시도 횟수가 무한 루프를 차단, 자기 교정 패턴의 필수 안전장치
- PASS 판정은 예시 — 실전에서는 테스트 실행이나 Structured Output으로 판정합니다
구현 스펙트럼과 프로덕션 성숙도
코드 vs 선언 · 체크리스트 · 성숙도 5단계
스펙트럼과 성숙도
구현 방식 선택과 프로덕션 성숙도 로드맵
코드 ↔ 선언, 그리고 성숙도
구현 스펙트럼에서 프로젝트의 위치를 정하고, 프로덕션 성숙도를 단계적으로 끌어올립니다.
- 스펙트럼 — 코드 제어 vs 선언적 구성
- 체크리스트 — 안전 · 안정 · 복원 · 비용 · 관측 · 품질
- 성숙도 5단계 — 프롬프트만 → 자율 운영
- 브리지 — 도구별 구현은 전용 모듈에서
정답 위치는 없습니다 — 제어력 vs 속도의 트레이드오프와 성숙도 단계로 프로젝트마다 판단합니다.
구현 스펙트럼 — 코드 vs 선언
제어력과 구성 속도의 트레이드오프 — 프로젝트에 맞는 위치 선택
코드로 제어
Strands · LangGraph
- 제어력 최고 — 루프와 상태를 코드로 정의
- @tool · Hooks · 그래프 등 커스텀 자유
- 인프라 배포와 운영은 직접 책임
커스텀 오케스트레이션과 복잡한 상태 머신이 필요할 때 선택합니다. 코드가 곧 하네스의 명세가 됩니다.
선언으로 구성
관리형 하네스
- 구성 속도 최고 — 설정 선언으로 완성
- 모델 · 도구 · 메모리를 관리형으로 제공
- 커스텀 범위는 제공 옵션 안으로 제한
AgentCore Managed Harness처럼 하네스 자체를 서비스로 받습니다. 프로토타입과 표준화된 에이전트에 유리합니다.
트레이드오프는 제어력 vs 속도입니다 — 선언으로 빠르게 시작하고, 세밀한 제어가 필요해지면 코드로 전환합니다.
프로덕션 체크리스트
배포 전 반드시 확인하는 안전 · 안정 · 복원 · 비용 · 관측 · 품질 6항목
여섯 항목은 전부 5대 구성 요소와 짝을 이룹니다 — 체크리스트가 곧 Tool · Orchestrator · Memory · Guard · Eval의 점검표입니다.
성숙도 5단계
프롬프트만 있는 Level 1에서 자율 운영 Level 5까지의 성장 계단
한 번에 Level 5를 노리지 않습니다 — Level 2에서 시작해 점진적으로 올려야 복잡성이 통제됩니다.
구현은 전용 모듈에서
Strands·LangGraph·AgentCore·Kiro — 코드·그래프·선언·개발 시점을 각각 대표하는 네 갈래 하네스
도구별 구현은 전용 모듈이 본령
이 모듈은 하네스의 개념과 설계까지 다룹니다 — 각 구현 도구의 상세는 전용 모듈에서 이어집니다.
- Strands Agents SDK — 코드 레벨 하네스 (Strands 계열 모듈)
- LangGraph — 그래프 상태 머신 하네스 (LangChain · LangGraph 모듈)
- AgentCore Managed Harness — 선언적 관리형 하네스 (AgentCore 계열 모듈)
- Kiro — 개발 시점 하네스 (Kiro 계열 모듈)
스펙트럼 위 어느 위치든 원리는 같습니다 — Agent = Model + Harness, 프로덕션 품질은 하네스가 결정합니다.
진화 · 정의 · 루프 · 패턴 · 성숙도 — 하네스 엔지니어링의 핵심