1부 · 하네스 엔지니어링

1. 하네스 엔지니어링 — 업계 지식부터

1.1 하네스란 무엇인가 — 가장 중요한 정의

LLM 단독으로는 다음 토큰 예측만 합니다. 파일을 읽거나 API를 호출하거나 실패를 복구하지 못합니다. Anthropic의 간결한 정의가 핵심을 찌릅니다:

에이전트 = LLM이 루프 안에서 자율적으로 도구를 사용하는 것(LLMs autonomously using tools in a loop).

이 루프를 돌려주는 런타임이 하네스(harness)입니다. 하네스가 모델에게 제공하는 4가지:

• 도구 접근 — 파일·셸·검색·API
• 관찰(observation) 피드백 — 도구 실행 결과를 다시 모델 입력으로
• 반복 제어(loop control) — 작업이 끝날 때까지 판단→실행→관찰 반복
• 컨텍스트 관리 — 무엇을 언제 모델에게 보여줄지 결정 (6장에서 깊이 다룸)

1.2 업계는 이미 이 길로 수렴했다

2025년을 거치며 가장 검증된 에이전트들은 예외 없이 CLI 기반 코딩 하네스 형태로 모였습니다. 우연이 아닙니다.

1.3 왜 하필 “코딩” 하네스인가 — 핵심 통찰

코딩은 에이전트 능력이 가장 먼저·가장 혹독하게 검증된 영역이기 때문입니다. 코드를 다루려면 필연적으로 네 가지를 해야 합니다:

• 여러 파일을 읽고 맥락을 종합
• 어떤 도구(컴파일·테스트·검색)를 쓸지 정확히 선택
• 다단계로 추론
• 실패하면(테스트 깨짐) 원인을 보고 복구

그런데 이 네 가지는 모든 업무 에이전트가 필요로 하는 바로 그 능력입니다. 송장 처리든, 보고서 작성이든, 고객 응대든 근본 메커니즘은 같습니다. Microsoft가 코어를 “coding harness + CLI layer”라고 명시한 건, 코딩에서 단련된 엔진을 일반 업무로 가져왔다는 선언입니다.

1.4 하네스 엔지니어링의 황금률 (Anthropic)

짚고 가기: “과설계하지 마라. 모델이 좋아지면 당신의 스캐폴딩은 낡는다.”

하네스의 모든 구성요소는 ‘모델이 혼자 못 하는 것’에 대한 가정을 인코딩한다. 그 가정은 틀렸을 수도 있고, 모델이 좋아지면서 낡을 수도 있으니 끊임없이 스트레스 테스트하라. … 가능한 가장 단순한 해법에서 출발하고, 필요할 때만 복잡도를 더하라. — Anthropic, Designing harnesses for long-running apps / Building Effective Agents

이건 추상적 조언이 아닙니다. Anthropic은 실제로 Opus 4.5용으로 만든 정교한 스캐폴딩(sprint 분해, context reset)을 Opus 4.6에서 덜어냈습니다. 모델이 스스로 계획을 더 잘 세우게 되자, 하네스가 오히려 가벼워진 것.

교육 포인트(멘탈모델 전환): 메이커의 일이 근본적으로 바뀝니다. 이전에는 대화 흐름(순서도)을 손으로 그렸다면, 이후에는 하네스에게 줄 지침·스킬·도구를 설계하고 처음부터 과설계하지 않습니다. 이것이 2부 실습 전체를 관통하는 철학입니다.