티스토리 뷰

TECH AND AI

LLM 엔지니어링 용어의 계보 3편 - 하네스 엔지니어링 — 최고 모델도 혼자서는 장기 작업에 실패합니다

ebson 2026. 6. 13. 08:26

들어가며 — 02가 열어 둔 질문

앞 글에서 컨텍스트 엔지니어링을 정리하면서, 마지막에 작은 질문 하나를 남겨 두었습니다. 컨텍스트가 길어지면 요약을 떠서 새 윈도우로 다시 시작하고, 윈도우 밖에 메모를 적어 두고, 집중 작업은 서브에이전트에게 떼어 주는 — 02에서 본 그 전략들은 누가 실행하느냐는 질문이었습니다. 모델은 다음 토큰을 예측할 뿐입니다. 요약을 실제로 떠서 다음 호출의 입력을 갈아끼우고, 메모 파일을 디스크에 쓰고, 서브에이전트를 띄웠다가 결과만 받아 오는 일은 전부 모델 바깥의 코드가 합니다.

그 모델 바깥의 코드를 묶어 부르는 이름이 하네스(harness)입니다. 이번 글은 이 하네스가 왜 필요하고, 공식 문서가 제시한 설계가 무엇이며, "하네스 엔지니어링"이라는 말이 어디서 왔는지를 정리해 보려 합니다. 기술적 사실은 Anthropic 엔지니어링 블로그의 공식 글에서 확인되는 범위 안에서만 적고, 확인하지 못한 부분은 그 점을 분명히 밝히겠습니다.

말을 꺼내기 전에 한 가지를 짚어 두고 싶습니다. 하네스가 필요하다는 이야기는 모델이 약하다는 이야기로 들리기 쉽습니다. 그런데 공식 글이 보여 주는 건 정반대에 가깝습니다. 가장 좋은 모델을 가져다 그냥 돌려도 장기 작업은 무너진다는 것, 그러니 성패는 모델이 아니라 그 바깥 시스템의 설계가 가른다는 것입니다.

실패의 양상 — 모델은 과욕을 부리고, 일찍 끝냅니다

이 글의 축이 되는 문장이 하나 있습니다. 2025년 11월 26일 Anthropic이 공개한 Effective harnesses for long-running agents에 적힌 문장입니다.

"even a frontier coding model like Opus 4.5 running on the Claude Agent SDK in a loop across multiple context windows will fall short of building a production-quality web app if it's only given a high-level prompt"


풀어 쓰면 이렇습니다. Opus 4.5처럼 당시 가장 앞선 코딩 모델을, 공식 SDK 위에서, 여러 컨텍스트 윈도우를 넘나드는 반복 루프로 돌려도, "좋은 웹 앱을 만들어 줘" 정도의 추상적인 프롬프트 하나만 던지면 프로덕션 수준의 앱을 완성하지 못한다는 것입니다. 모델이 부족해서가 아닙니다. 같은 모델이라도 그것을 감싸는 시스템이 다르면 결과가 달라진다는 관찰입니다.

그러면 추상적인 프롬프트 하나만 받은 모델은 구체적으로 어떻게 실패할까요. 공식 글은 두 가지 양상을 짚습니다. 둘 다 사람이 같은 자리에서 저지르는 실수와 닮아서, 오히려 이해하기 쉽습니다.

첫째는 한 번에 너무 많이 하려 든다는 것입니다. 글의 표현을 빌리면 에이전트는 "to try to do too much at once—essentially to attempt to one-shot the app", 즉 앱 전체를 한 방에 끝내려고 달려듭니다. 그 결과 여러 기능이 절반만 구현되고 문서도 남지 않은 채로 흩어집니다. 다음 세션이 그 상태를 이어받으면, 무엇이 끝났고 무엇이 안 끝났는지를 추측부터 해야 합니다. 한 사람이 하루에 기능 열 개를 동시에 벌여 놓고 어느 것도 마무리하지 못한 채 자리를 뜬 상황과 같습니다.

둘째는 다 끝나지 않았는데 끝났다고 판정한다는 것입니다. 이미 어느 정도 기능이 만들어진 뒤에 새 에이전트 인스턴스가 코드를 둘러보면, 진척이 있어 보이니 "작업 완료"라고 선언해 버립니다. 글이 묘사한 그대로입니다. "a later agent instance would look around, see that progress had been made, and declare the job done." 절반쯤 된 일을 보고 다 됐다고 손을 떼는 것입니다.

이 두 가지를 묶어 보면, 모델 자체의 한계라기보다는 작업을 끌고 가는 방식의 문제라는 게 드러납니다. 무엇을 어디까지 했는지에 대한 기준이 없으니 과욕을 부리고, 완료의 정의가 없으니 대충 끝났다고 판단합니다. 그렇다면 해법은 모델을 더 좋은 것으로 바꾸는 게 아니라, 이 두 실수를 막는 장치를 모델 바깥에 두는 쪽이 됩니다. 그 장치가 하네스입니다.

하네스의 뼈대 — 준비하는 에이전트와 진행하는 에이전트

공식 글이 제시한 구조의 핵심은 역할을 둘로 나눈 것입니다. 처음 한 번 환경을 깔아 주는 에이전트와, 그다음부터 조금씩 진척시키는 에이전트를 분리합니다. 앞쪽을 초기화 에이전트(initializer agent), 뒤쪽을 코딩 에이전트(coding agent)라고 부릅니다.

초기화 에이전트는 첫 실행에서 토대가 되는 환경을 세팅합니다. 그 위에서 코딩 에이전트가 세션을 거듭하며 점진적으로 일을 진행합니다. 이 구분이 왜 중요한가 하면, 앞 절에서 본 두 실패가 정확히 여기서 막히기 때문입니다. 환경을 까는 일과 기능을 더하는 일이 한 에이전트 안에 뒤섞여 있으면, 매번 처음부터 판을 다시 깔지 아니면 이어서 진행할지를 모델이 매번 새로 판단해야 합니다. 그 판단이 흔들리는 자리에서 과욕과 조기 완료가 나옵니다. 역할을 갈라 두면 코딩 에이전트는 "이미 깔린 판 위에서 다음 한 걸음"만 생각하면 됩니다.

그 "다음 한 걸음"을 강제하는 장치가 두 가지 더 붙습니다. 하나는 기능 체크리스트입니다. 공식 글의 사례에서는 200개가 넘는 기능을 JSON 파일에 적고, 각 기능에 통과 여부를 나타내는 passes 필드를 두었습니다. 그리고 그 파일에 "It is unacceptable to remove or edit tests."처럼 강한 어조의 지시를 함께 박아 두었습니다. 무엇을 해야 하고 무엇이 끝났는지가 파일 하나에 구조화되어 남아 있으니, 새 세션이 들어와도 추측할 필요가 없습니다. 조기 완료 판정의 해독제입니다. 끝났는지 아닌지를 에이전트의 인상이 아니라 체크리스트의 상태가 정합니다.

다른 하나는 "한 번에 한 기능"이라는 규칙입니다. 글은 코딩 에이전트에게 한 번에 단 하나의 기능만 작업하라고 시켰고, 이 점진적 접근이 결정적이었다고 적습니다. 원문의 표현으로는 "This incremental approach turned out to be critical."입니다. 한 방에 끝내려는 과욕의 해독제가 바로 이 규칙입니다. 작업 단위를 기능 하나로 좁히면, 동시에 열 개를 벌여 놓고 어느 것도 못 끝내는 상황 자체가 생기지 않습니다.

여기에 상태를 파악하는 방식이 더해집니다. 세션이 시작될 때 에이전트는 git 로그와 진행 상황을 적은 파일을 먼저 읽어, 최근 무슨 작업이 있었는지를 따라잡습니다. 사람이 며칠 만에 프로젝트로 돌아왔을 때 커밋 로그부터 훑는 것과 같습니다. 모델은 이전 세션의 기억을 가지고 있지 않으니, 그 기억의 자리를 git 로그와 진행 파일이라는 외부 기록이 대신합니다. 이 대목은 02에서 본 "윈도우 밖에 메모를 둔다"는 전략이 하네스의 뼈대로 자리 잡은 모습이기도 합니다.

흥미로운 건 이 패턴들이 Claude Code 같은 도구를 매일 쓰는 사람에게 낯설지 않다는 점입니다. 작업을 잘게 쪼개 하나씩 처리하고, 진행 상황을 파일에 적어 두고, 서브에이전트에게 일부를 떼어 주는 흐름은 도구를 쓰다 보면 자연스럽게 만나게 됩니다. 공식 글이 정리한 패턴이 도구에서는 이런 모습으로 보인다, 정도로 연결해 두면 충분할 것 같습니다. 도구의 사용법을 여기서 다 풀어 쓰는 건 이 글의 자리가 아니니까요.

검증을 분리합니다 — 자기 채점은 후합니다

뼈대를 세웠어도 한 가지가 남습니다. 만들어진 결과가 정말 쓸 만한지를 누가 판단하느냐입니다. 가장 단순한 방법은 만든 에이전트에게 직접 물어보는 것인데, 여기에 함정이 있습니다.

2026년 3월 24일 공개된 Harness design for long-running application development는 이 함정을 분명히 짚습니다. 에이전트에게 자기가 만든 결과물을 평가해 보라고 하면, 사람이 보기에 품질이 누가 봐도 그저 그런데도 자신 있게 칭찬하는 쪽으로 반응한다는 것입니다. 글의 표현을 그대로 옮기면 이렇습니다. "When asked to evaluate work they've produced, agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre." 자기 일을 자기가 채점하면 후하게 준다는, 이 역시 사람과 닮은 약점입니다.

해법은 채점하는 쪽을 일하는 쪽에서 떼어 놓는 것입니다. 글은 이를 두고 "Separating the agent doing the work from the agent judging it proves to be a strong lever to address this issue."라고 적습니다. 일하는 에이전트와 판단하는 에이전트를 갈라 두는 것이 이 문제를 다루는 강한 지렛대라는 것입니다. 왜 갈라야 효과가 있는가 하면, 평가자를 따로 두면 그 평가자를 의심 많게 튜닝할 수 있기 때문입니다. 생성하는 에이전트에게 "너 자신에게 가혹하게 굴어라"라고 시키는 것보다, 처음부터 회의적인 태도로 세팅한 별도의 평가자를 두는 편이 잘 통합니다.

이 분리는 앞 절의 체크리스트와 결이 같습니다. 완료 여부를 에이전트의 인상이 아니라 외부 기준에 맡긴다는 점에서 그렇습니다. 체크리스트는 "무엇이 끝났나"를 파일에 적힌 상태로 정하고, 평가자 분리는 "끝난 것이 쓸 만한가"를 다른 에이전트의 판단에 맡깁니다. 자기 채점의 편향을 구조로 비껴가는 것입니다.

검증을 외부에 맡기는 또 다른 축은 사람이 쓰는 도구를 그대로 쥐여 주는 것입니다. 첫 번째 글은 브라우저 자동화로 앱을 실제로 끝까지 눌러 보게 했더니 버그를 찾아내는 성능이 크게 올랐다고 적습니다. 모델이 "이 정도면 됐다"고 자평하는 대신, 실제로 화면을 띄워 클릭해 보고 깨지는 곳을 확인하는 것입니다. 코드를 읽고 괜찮아 보인다고 판단하는 것과, 돌려 보고 정말 도는지 확인하는 것은 다른 일입니다. 검증을 모델의 자기 판단 밖으로 꺼낼수록 결과가 단단해진다는 점에서, 평가자 분리와 브라우저 검증은 같은 방향을 가리킵니다.

스캐폴딩은 영원하지 않습니다

하네스를 이렇게 쌓다 보면 한 가지 오해에 빠지기 쉽습니다. 장치를 많이 붙일수록 좋다는 생각입니다. 두 번째 글은 여기에 제동을 겁니다. 하네스의 모든 구성 요소는 모델이 혼자서는 못 하는 무언가를 가정하고 있고, 그 가정은 모델이 좋아지면 금세 낡는다는 것입니다.

글의 문장을 옮기면 이렇습니다. "every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing...because they can quickly go stale as models improve." 하네스의 각 부품은 "모델이 스스로 못 하는 것"에 대한 가정을 담고 있으니, 그 가정을 정기적으로 시험해 봐야 한다는 것입니다. 모델이 나아지면 어제까지 꼭 필요했던 받침대가 오늘은 거추장스러운 군더더기가 됩니다.

글의 저자는 이를 직접 보여 줍니다. 작업을 스프린트 단위로 나누던 장치가 있었는데, 모델을 Claude Opus 4.6으로 올리고 나니 그 스프린트 구조가 일부 작업에서는 더 이상 필요 없어졌다는 것입니다. 새 모델이 그만큼을 스스로 감당하게 되었기 때문입니다. 그래서 그 받침대를 걷어 냈습니다.

이 대목이 하네스를 바라보는 시각을 바꿔 줍니다. 하네스는 한 번 잘 쌓아 두면 끝나는 구조물이 아니라, 모델이 바뀔 때마다 다시 들여다보고 조정하는 대상입니다. 받침대 하나하나가 "모델이 이건 못 해"라는 가정이라면, 모델이 좋아질 때마다 그 가정 중 일부는 틀린 것이 됩니다. 틀린 가정을 그대로 두면 시스템만 무거워집니다. 그래서 하네스 엔지니어링은 "쌓는 일"이라기보다 "쌓은 것을 주기적으로 걷어 내며 조정하는 일"에 가깝습니다. 02에서 본 전략들을 실행하는 시스템을 짜는 일도 결국 한 번 세우면 끝나는 영구 구조물을 만드는 게 아니라, 모델이 바뀔 때마다 다시 손보는 대상을 다루는 일이라는 뜻입니다.

개념은 공식, 이름은 비공식

여기까지 "하네스"라는 단어를 계속 썼는데, 이 말의 출처를 한 번 정리하고 넘어가는 게 좋겠습니다. 지금까지 인용한 Anthropic 공식 글 2편은 harness라는 단어와 개념을 분명히 씁니다. 제목부터 Effective harnesses for long-running agents, Harness design for long-running application development입니다. 모델을 감싸 장기 작업을 끌고 가는 시스템이라는 개념도, 그 시스템을 가리키는 harness라는 단어도 공식 문서 안에 있습니다.

다만 "하네스 엔지니어링(harness engineering)"이라는, 방법론에 붙은 이름까지 공식 문서가 쓰는지는 다른 문제입니다. 제가 확인한 두 공식 글은 harness를 개념과 설계의 대상으로 다루지만, 그것을 하나의 분야 이름으로 명명하지는 않습니다. 그 명명은 바깥에서 왔습니다.

개인 블로그를 운영하는 Addy Osmani가 Agent Harness Engineering이라는 글에서 이 방법론에 이름을 붙였습니다. 그 글의 표현으로는 "Agent = Model + Harness. If you're not the model, you're the harness."입니다. 에이전트는 모델과 하네스의 합이고, 당신이 모델을 만드는 사람이 아니라면 당신이 만드는 건 하네스라는 것입니다. 다만 이 인용은 공식 출처가 아니라 개인 블로그의 정리라는 점을 분명히 해 두어야겠습니다. 이 글에서 Osmani의 문장은 기술적 사실의 근거가 아니라, "이 방법론에 이런 이름이 붙었다"는 명명의 기록으로만 가져온 것입니다.

이 구분이 사소해 보일 수 있지만, 용어가 빠르게 늘어나는 요즘에는 한 번씩 짚어 둘 가치가 있다고 느낍니다. 개념과 그 개념을 다룬 공식 자료는 Anthropic 블로그에 있고, 그것을 "하네스 엔지니어링"이라는 분야 이름으로 부르는 명명은 외부 개인 글에서 시작됐습니다. 어느 쪽을 인용하든 출처의 무게가 다르다는 걸 알고 쓰는 편이, 나중에 그 말이 어떻게 자리 잡든 흔들리지 않게 해 줍니다. 이 "개념은 공식, 이름은 비공식"이라는 구도는 다음 글에서 한 번 더, 더 또렷한 형태로 만나게 됩니다.

마무리 — 하네스를 돌리는 건 여전히 사람입니다

이 글을 정리하면서 가장 또렷해진 생각은, 하네스의 모든 장치가 결국 사람의 실수를 모델에게서 막아 내는 형태로 생겼다는 것이었습니다. 한 번에 너무 많이 하지 말 것, 끝났다고 섣불리 단정하지 말 것, 자기 일을 자기가 후하게 채점하지 말 것. 사람이 일을 그르치는 방식과 모델이 장기 작업을 그르치는 방식이 닮았고, 그 닮은 실수를 막는 장치도 사람이 협업에서 쓰는 방식 — 작업을 쪼개고, 진행 상황을 기록하고, 검토자를 따로 두는 — 과 닮았습니다. 그래서 하네스 설계는 새로운 발명이라기보다, 익숙한 협업의 규율을 모델 바깥의 코드로 옮겨 적은 일처럼 보였습니다.

그리고 한 가지가 끝까지 남습니다. 하네스가 아무리 잘 짜여 있어도, 그것을 언제 시작하고 언제 멈추고 언제 다시 시킬지는 여전히 사람이 정한다는 것입니다. 초기화 에이전트를 띄우는 것도, 체크리스트가 다 찰 때까지 코딩 에이전트를 다시 부르는 것도, 모델이 좋아졌으니 스캐폴딩을 걷어 내자고 판단하는 것도 사람의 몫입니다. 하네스는 모델 바깥의 시스템이지만, 그 시스템을 돌리는 손은 아직 사람의 손입니다.

그렇다면 그 손마저 시스템으로 바꾸려는 시도는 어디까지 와 있을까요. 하네스를 시작하고 멈추고 다시 거는 일 자체를 코드로 적으면, 우리는 하네스 위의 또 한 층으로 올라갑니다. 그 한 층을 사람들이 어떤 이름으로 부르기 시작했는지, 그리고 그 이름이 정말 공식적인 것인지를 다음 글에서 따라가 보려 합니다.

참고한 공식 문서

용어 유래 참고 자료 (공식 출처 아님 · 명명 기록으로만 인용)

'TECH AND AI' 카테고리의 다른 글

LLM 엔지니어링 용어의 계보 4편 - 프롬프트·컨텍스트·하네스·루프 — 네 용어의 계보를 한 글에 정리하기  (0) 2026.06.13
LLM 엔지니어링 용어의 계보 2편 - 컨텍스트 엔지니어링 — 설계 대상이 문장에서 토큰 구성으로 넓어진 이유  (0) 2026.06.13
LLM 엔지니어링 용어의 계보 1편 - 프롬프트 엔지니어링 — 문장 쓰기가 엔지니어링이 된 출발점  (1) 2026.06.13
LLM Agent는 왜 같은 Tool을 30번 호출했을까 2편: LLM Agent의 Tool Loop를 막는 3계층 방어 패턴  (1) 2026.03.20
LLM Agent는 왜 같은 Tool을 30번 호출했을까 1편: LangChain4j 기반 Agent의 Tool Loop 문제 발생과 근본 원인 분석  (1) 2026.03.20