Home / 하네스 엔지니어링 / 하네스 엔지니어링
Note

하네스 엔지니어링

패러다임 진화, 하네스 구성 요소, 설계 패턴, 프로덕션 성숙도

⏱ 30분 143 / 189

하네스 엔지니어링

패러다임 진화, 하네스 구성 요소, 설계 패턴, 프로덕션 성숙도

Agent = Model + Harness

도구 · 메모리 · 오케스트레이션 · 가드레일 · 평가 — 에이전트 실행 환경 전체의 설계

패러다임 진화

Prompt → Context → Harness — 넓어지는 설계 범위

PART 1 · 패러다임 진화

패러다임 진화

입력에서 실행 환경으로 — 최적화 대상이 한 겹씩 넓어져 온 진화의 흐름

프롬프트에서 하네스로

최적화 대상이 입력 텍스트에서 실행 환경 전체로 넓어져 온 흐름을 짚습니다.

  • 프롬프트 엔지니어링 — "어떻게 물어볼까"
  • 컨텍스트 엔지니어링 — "무엇을 보여줄까"
  • 하네스 엔지니어링 — "어떤 환경에서 실행할까"
  • 공식화 — Martin Fowler · ThoughtWorks (2026)
takeaway

세 패러다임은 대체가 아니라 포함 관계(Harness ⊃ Context ⊃ Prompt)입니다 — 설계 범위가 한 겹씩 넓어집니다.

PART 1 · 패러다임 진화

엔지니어링 패러다임 3단계

입력 최적화에서 실행 환경 설계까지 — 한 겹씩 넓어진 최적화 대상

takeaway

Harness Engineering 용어는 2026년 Martin Fowler와 ThoughtWorks가 정립했습니다 — 모델이 에이전트가 되면서 필연이 된 확장입니다.

PART 1 · 패러다임 진화

포함 관계 — Prompt ⊂ Context ⊂ Harness

대체가 아니라 확장 — 안쪽 겹은 그대로 두고 설계 범위가 한 겹씩 넓어지는 구조

takeaway

하네스를 설계하면 컨텍스트와 프롬프트도 그 안에서 함께 설계됩니다 — 바깥 겹이 안쪽 겹을 포함합니다.

PART 1 · 패러다임 진화

세 패러다임 비교

초점 · 최적화 대상 · 결과물 · 포함 관계 4축으로 본 차이

항목PromptContextHarness
초점입력 텍스트컨텍스트 윈도우실행 환경 전체
최적화 대상지시 품질정보 선별·압축행동 범위·안전·확장
결과물단일 호출 개선정보 활용도 개선자율 에이전트 동작
포함 관계Prompt ⊂ ContextContext ⊂ Harness
takeaway

상위 개념이 하위를 포함합니다 — 하네스를 잘 설계하면 컨텍스트와 프롬프트 품질도 자연스럽게 따라옵니다.

PART 1 · 패러다임 진화

하네스까지 왔는가

모델이 도구를 호출하고 반복하고 위임하는 에이전트가 되면서 생긴 변화

단일 호출 시대 에이전트 시대
실행 단위 프롬프트 → 응답 1회 지속적 루프 — 호출·반복·위임
제어 수단 지시문 품질 도구 선택 · 메모리 · 보안 · 스케일링
품질 결정 요인 모델 성능 하네스 설계
takeaway

단일 호출이 아닌 지속적 루프를 관리하는 시대입니다 — 프롬프트가 아니라 실행 환경이 설계 과제가 됩니다.

하네스의 정의와 구성 요소

Agent = Model + Harness · Tool · Orchestrator · Memory · Guard · Eval

PART 2 · 하네스의 정의와 구성 요소

정의와 구성 요소

모델을 감싸는 실행 환경의 정의와 다섯 구성 요소

Agent = Model + Harness

모델을 감싸는 실행 환경 전체가 하네스입니다 — 도구, 메모리, 오케스트레이션, 가드레일, 평가.

  • Model = 엔진 · Harness = 도로 · 신호 · 규칙 · 정비소
  • 5대 구성 요소 — Tool · Orchestrator · Memory · Guard · Eval
  • 핵심 역할 — 행동 범위 · 안전장치 · 확장성 · 관측성
  • 요소 선택 — 태스크 복잡도에 따라 점진 추가
takeaway

모델 성능만으로는 에이전트 품질이 결정되지 않습니다 — 실행 환경 전체가 프로덕션 품질을 결정합니다.

PART 2 · 하네스의 정의와 구성 요소

하네스 정의 — 수식 한 줄

프로덕션 에이전트의 최소 정의 — 모델 하나로는 항이 부족한 수식

PART 2 · 하네스의 정의와 구성 요소

모델은 엔진, 하네스는 실행 환경

프롬프트 확장이 아닌 행동 범위·안전장치·확장성의 시스템 설계

Model — 엔진

추론 능력

  • 계획 · 판단 · 생성의 원천
  • 교체 가능한 부품 — 프로바이더 전환 가능
  • 엔진 단독으로는 목적 달성 불가

자동차의 엔진, 극장의 배우, 우주선의 추진체에 해당합니다. 핵심 능력이지만 주변 시스템 없이는 목적지에 도달하지 못합니다.

Harness — 실행 환경

도로 · 신호 · 규칙 · 정비소

  • 행동 범위 정의 — 할 수 있는 것의 경계
  • 안전장치 — 잘못된 행동의 사전 차단·사후 교정
  • 확장성 — 메모리 · 도구 · 하위 에이전트
  • 관측성 — 무엇을 했는지 추적·분석·개선

변속기·브레이크·내비게이션·안전벨트처럼 엔진을 감싸 속도와 안전, 목적지를 결정합니다. 하네스는 프롬프트를 잘 쓰는 기술이 아니라 시스템 설계입니다.

takeaway

하네스 없는 모델은 비포장 도로 위의 스포츠카입니다 — 같은 엔진이라도 도로가 속도와 안전, 목적지를 결정합니다.

PART 2 · 하네스의 정의와 구성 요소

하네스 5대 구성 요소

Tool·Orchestrator·Memory·Guard·Eval — 상호작용·지휘·기억·안전·품질을 맡는 다섯 레이어

takeaway

다섯 요소가 전부 필수는 아닙니다 — 태스크 복잡도에 따라 선택 적용하고, 요소 간 상호작용이 하네스 품질을 결정합니다.

PART 2 · 하네스의 정의와 구성 요소

구성 요소 선택 기준

단순 봇에서 프로덕션 에이전트까지 — 복잡도에 따른 점진 확장 경로

  1. 1
    단순 Q&A 봇

    Model + Tool 1~2개면 충분합니다. 검색이나 조회처럼 행동이 단순하면 무거운 하네스는 과잉 설계가 됩니다.

  2. 2
    도구 사용 에이전트

    Orchestrator를 더해 3요소로 구성합니다. 여러 도구의 선택과 실행 순서를 제어해야 하는 단계입니다.

  3. 3
    프로덕션 에이전트

    Guard · Eval · Memory까지 5요소 전부를 갖춥니다. 안전과 품질, 세션 간 기억이 서비스 신뢰성을 좌우합니다.

takeaway

처음부터 다 넣지 않습니다 — 복잡도가 올라갈 때 요소를 점진적으로 추가하는 것이 하네스 설계의 기본기입니다.

에이전틱 루프와 오케스트레이션

Plan → Act → Observe → Reflect · 제어 전략 3가지

PART 3 · 에이전틱 루프와 오케스트레이션

에이전틱 루프

루프 4단계와 이를 제어하는 오케스트레이션 전략

Plan → Act → Observe → Reflect

에이전트의 심장은 단일 호출이 아닌 반복 루프입니다 — 루프의 제어 방식이 곧 오케스트레이션 전략입니다.

  • 루프 4단계 — 계획 · 행동 · 관찰 · 성찰
  • ReAct — 즉흥적 반복, 빠른 응답
  • Plan-and-Execute — 전체 계획 후 순차 실행
  • Tree of Thought — 여러 경로 탐색 후 최선 선택
takeaway

루프가 에이전트를 만들고, 오케스트레이션 전략이 루프를 제어합니다 — 프로덕션에서는 반복 상한이 필수입니다.

PART 3 · 에이전틱 루프와 오케스트레이션

루프를 도는 4단계

단일 호출(Prompt → Response)이 아닌 반복 루프가 에이전트의 핵심 — 매 순환마다 행동을 결정하고 결과를 관찰

PART 3 · 에이전틱 루프와 오케스트레이션

오케스트레이션 3가지 전략

루프의 제어 방식을 결정하는 세 전략과 각각의 적합 상황

ReAct

Think → Act → Observe 반복

  • 즉흥적 — 매 스텝마다 다음 행동 결정
  • 구현 단순, 응답 빠름
  • 긴 다단계 계획에는 부적합

언제 — 단순 도구 호출, 빠른 응답이 중요한 대화형 에이전트

Plan-and-Execute

전체 계획 수립 → 순차 실행

  • 계획 단계와 실행 단계를 분리
  • 복잡한 다단계 태스크에 강함
  • 중간 상황 변화 시 재계획 필요

언제 — 단계가 많고 의존 관계가 있는 복잡한 태스크

Tree of Thought

여러 경로 탐색 → 최선 선택

  • 후보 경로를 병렬 탐색·평가
  • 정답이 불확실한 추론에 강함
  • 토큰 비용이 가장 큼

언제 — 탐색과 백트래킹이 필요한 불확실한 추론 문제

takeaway

기본은 ReAct입니다 — 태스크가 복잡해질수록 계획형·탐색형으로 확장하되, 비용과 지연을 함께 계산합니다.

PART 3 · 에이전틱 루프와 오케스트레이션

ReAct 루프 — Strands 기본 동작

@tool 함수와 Agent 조립만으로 자동 구동되는 에이전틱 루프

python
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

PART 4 · 설계 패턴

설계 패턴

반복 검증된 설계 패턴과 상황별 선택 기준

검증된 하네스 구성 방법론

반복적으로 검증된 패턴을 조합해 태스크 복잡도와 위험도에 대응합니다.

  • Self-Correcting — 결과 자체 평가 후 재시도
  • Human-in-the-Loop — 고위험 액션 승인 게이트
  • Checkpoint — 중간 상태 저장 · 복구
  • Progressive Delegation — 신뢰도 따라 권한 확대
takeaway

패턴은 배타적이지 않습니다 — 하나의 에이전트에 여러 패턴을 조합하고, 단순한 것부터 점진 적용합니다.

PART 4 · 설계 패턴

핵심 패턴 7가지

반복 검증된 일곱 패턴 — 조합 가능하며, 프로덕션 적용은 Self-Correcting까지가 안전선

패턴핵심 아이디어적합 상황
Retrieval-AugmentedRAG(검색 증강 생성) + 도구 호출 결합문서 기반 질의응답
Self-Correcting결과 자체 평가 후 재시도코드 생성, 정확도 중시
Human-in-the-Loop고위험 액션 전 인간 승인결제 · 삭제 · 프로덕션 변경
Checkpoint중간 상태 저장 · 복구장기 실행, 장애 복구
Progressive Delegation신뢰도에 따라 권한 확대점진적 자율성 부여
Context Offloading큰 결과는 외부 저장, 요약만 유지대용량 결과, 토큰 절약
Self-ModifyingAI가 자신의 하네스를 수정 — 연구 단계Meta FAIR Hyperagents
PART 4 · 설계 패턴

상황별 패턴 선택

위험도 → 정확도 → 실행 시간 순으로 좁혀가는 선택 흐름

PART 4 · 설계 패턴

Self-Correcting — 자기 교정 루프

coder가 생성하고 reviewer가 검증하는 두 에이전트의 자기 교정 루프

python
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단계

PART 5 · 구현 스펙트럼과 프로덕션 성숙도

스펙트럼과 성숙도

구현 방식 선택과 프로덕션 성숙도 로드맵

코드 ↔ 선언, 그리고 성숙도

구현 스펙트럼에서 프로젝트의 위치를 정하고, 프로덕션 성숙도를 단계적으로 끌어올립니다.

  • 스펙트럼 — 코드 제어 vs 선언적 구성
  • 체크리스트 — 안전 · 안정 · 복원 · 비용 · 관측 · 품질
  • 성숙도 5단계 — 프롬프트만 → 자율 운영
  • 브리지 — 도구별 구현은 전용 모듈에서
takeaway

정답 위치는 없습니다 — 제어력 vs 속도의 트레이드오프와 성숙도 단계로 프로젝트마다 판단합니다.

PART 5 · 구현 스펙트럼과 프로덕션 성숙도

구현 스펙트럼 — 코드 vs 선언

제어력과 구성 속도의 트레이드오프 — 프로젝트에 맞는 위치 선택

코드로 제어

Strands · LangGraph

  • 제어력 최고 — 루프와 상태를 코드로 정의
  • @tool · Hooks · 그래프 등 커스텀 자유
  • 인프라 배포와 운영은 직접 책임

커스텀 오케스트레이션과 복잡한 상태 머신이 필요할 때 선택합니다. 코드가 곧 하네스의 명세가 됩니다.

선언으로 구성

관리형 하네스

  • 구성 속도 최고 — 설정 선언으로 완성
  • 모델 · 도구 · 메모리를 관리형으로 제공
  • 커스텀 범위는 제공 옵션 안으로 제한

AgentCore Managed Harness처럼 하네스 자체를 서비스로 받습니다. 프로토타입과 표준화된 에이전트에 유리합니다.

takeaway

트레이드오프는 제어력 vs 속도입니다 — 선언으로 빠르게 시작하고, 세밀한 제어가 필요해지면 코드로 전환합니다.

PART 5 · 구현 스펙트럼과 프로덕션 성숙도

프로덕션 체크리스트

배포 전 반드시 확인하는 안전 · 안정 · 복원 · 비용 · 관측 · 품질 6항목

takeaway

여섯 항목은 전부 5대 구성 요소와 짝을 이룹니다 — 체크리스트가 곧 Tool · Orchestrator · Memory · Guard · Eval의 점검표입니다.

PART 5 · 구현 스펙트럼과 프로덕션 성숙도

성숙도 5단계

프롬프트만 있는 Level 1에서 자율 운영 Level 5까지의 성장 계단

takeaway

한 번에 Level 5를 노리지 않습니다 — Level 2에서 시작해 점진적으로 올려야 복잡성이 통제됩니다.

PART 5 · 구현 스펙트럼과 프로덕션 성숙도

구현은 전용 모듈에서

Strands·LangGraph·AgentCore·Kiro — 코드·그래프·선언·개발 시점을 각각 대표하는 네 갈래 하네스

도구별 구현은 전용 모듈이 본령

이 모듈은 하네스의 개념과 설계까지 다룹니다 — 각 구현 도구의 상세는 전용 모듈에서 이어집니다.

  • Strands Agents SDK — 코드 레벨 하네스 (Strands 계열 모듈)
  • LangGraph — 그래프 상태 머신 하네스 (LangChain · LangGraph 모듈)
  • AgentCore Managed Harness — 선언적 관리형 하네스 (AgentCore 계열 모듈)
  • Kiro — 개발 시점 하네스 (Kiro 계열 모듈)
takeaway

스펙트럼 위 어느 위치든 원리는 같습니다 — Agent = Model + Harness, 프로덕션 품질은 하네스가 결정합니다.

모델이 아니라 하네스가 프로덕션 품질을 결정합니다.

진화 · 정의 · 루프 · 패턴 · 성숙도 — 하네스 엔지니어링의 핵심