1년 반 동안 LLM을 탓했는데, 문제는 대개 harness 쪽이었습니다

2024년 11월 말에 처음 AI 대화창을 열었습니다. 특별한 기대는 없었습니다. 그냥 써보자는 거였습니다.

그 1년 반 사이에 제가 AI를 다루는 방식은 세 번 완전히 바뀌었습니다.

처음엔 복붙이었습니다. "이 코드 짜줘"라고 하면 대화창에 코드가 나오고, 복사해서 에디터에 붙여넣고, 안 되면 다시 묻고. 이 사이클을 무한 반복했습니다. 그나마 효율을 높이려면 프롬프트를 잘 써야 한다는 말을 들었고, 맞는 말이었습니다. 모호하게 물으면 모호한 답이 나왔고 맥락을 잘 줄수록 쓸 만한 코드가 나왔습니다. 그래서 프롬프트 엔지니어링을 공부했습니다. 역할 부여, 예시 몇 개 넣기, 사고 과정 유도하기, 출력 형식 지정하기. 꽤 공을 들였습니다.

그러다 Claude Code가 나왔고 Codex가 나왔습니다. CLI에서 AI가 직접 파일을 읽고 수정하고 실행하고 디버깅까지 합니다. 그 순간 프롬프트 엔지니어링 공부가 갑자기 허탈해졌습니다.

허탈했던 이유가 하나 더 있습니다. 역프롬프트 엔지니어링이라는 게 이미 있습니다. AI한테 "이 결과물을 만든 프롬프트가 뭔지 역으로 추론해줘"라고 하면 꽤 그럴듯하게 뽑아줍니다. 프롬프트를 사람이 직접 최적화하는 게 아니라 AI가 AI를 위한 프롬프트를 만드는 구조입니다. 복붙하면서 쌓은 경험도, 프롬프트를 공들여 쓰던 습관도 도구가 대부분 흡수해버렸습니다.

그때 좀 억울했는데, 그 억울함이 맞았는지 나중에 제 글을 다시 세어본 적이 있습니다. 결론부터 말하면 헛것은 아니었습니다. 다만 남은 게 프롬프트 작성 기술은 아니었습니다.

지금 시점에서 AI 활용의 최전선은 또 다릅니다. 코드 하나 짜는 게 아니라 에이전트가 계획을 세우고 실행하고 테스트하고 계획을 수정합니다. 사람이 개입하는 건 방향을 잡아주는 것뿐입니다. 더 나아가면 상위 에이전트가 비전을 받아서 하위 에이전트를 세팅하고, 각 에이전트가 다시 팀을 구성해서 업무를 분배하는 구조까지 갑니다. 사람 한 명이 AI 조직 하나를 굴리는 셈입니다.

1년 반 전에 대화창에서 코드 복사하던 것과 같은 도구의 이야기입니다.

변화의 속도 자체가 변하고 있습니다

처음 AI를 쓰기 시작했을 때 큰 변화는 반년에 한 번쯤 왔습니다. 새 모델, 새 기능, 새 패러다임. 그게 석 달로 줄었고, 지금은 한 주가 멀다 하고 뭔가 나옵니다.

변화의 주기가 짧아지는 게 아니라 변화의 속도 자체가 가속되고 있습니다. 반년 전 최신이 지금은 레거시가 되는 속도입니다. 따라잡으려고 공부하는 사이에 또 다른 게 나와 있습니다.

이게 과도기가 불편한 진짜 이유라고 보고 있습니다. 변화가 오는 게 아니라 변화가 멈추지 않습니다.

프롬프트로는 안 풀리는 문제가 보이기 시작했습니다

프롬프트 엔지니어링 얘기는 이제 좀 오래된 느낌이 납니다. 한때는 그게 전부인 것처럼 말하던 시기가 있었습니다. 질문을 어떻게 쓰느냐, 역할을 어떻게 부여하느냐, 예시를 몇 개 넣느냐. 그 조합 하나로 결과가 꽤 달라졌으니 그럴 만도 했습니다. 실제로 2023년과 2024년에는 그게 맞았습니다. 같은 모델을 써도 프롬프트를 잘 짠 사람이 더 나은 결과를 뽑았습니다.

그런데 2025년쯤부터 이상한 일이 생겼습니다. 프롬프트를 아무리 잘 써도 안 풀리는 문제가 눈에 들어오기 시작한 겁니다.

모델은 분명 좋아졌고 CLI 기반 도구나 에이전트형 인터페이스도 계속 나왔는데, 막상 실제 작업을 시켜보면 엉뚱한 데서 무너졌습니다. 구현은 시작하는데 끝을 못 보고, 파일은 만지는데 상태를 잃고, 스스로 테스트까지 하라고 하면 이상할 정도로 낙관적이 됐습니다. "잘했다"고 말하는데 결과물은 별로인 상황이 반복됐습니다.

이게 몇 번 쌓이니까 문제의 중심이 프롬프트가 아니라는 게 보였습니다.

그다음에 나온 말이 컨텍스트 엔지니어링이었고, 이건 꽤 설득력이 있었습니다. 결국 모델이 똑똑하게 일하려면 질문을 잘 쓰는 것보다 뭘 보여주느냐가 더 중요하다는 얘기였으니까요. RAG, MCP, 메모리 시스템, 히스토리 관리, 각종 검색 레이어가 전부 그 흐름 위에 있었습니다. 저도 한동안은 여기서 정리가 끝나는 줄 알았습니다.

그런데 올해 들어서는 그것도 부족하다는 쪽으로 생각이 바뀌었습니다.

에이전트를 실제로 오래 굴려보면 컨텍스트조차 전체의 일부일 뿐이기 때문입니다. 어떤 파일에 접근할 수 있는지, 코드를 어디서 실행하는지, 실패했을 때 무엇으로 검증하는지, 상태를 어디에 남기는지, 언제 멈추게 할지, 어느 지점에서 사람에게 넘길지. 이건 "무엇을 보여줄까"보다 더 바깥의 문제입니다. 말 그대로 환경입니다.

하네스라는 단어가 꽤 정확합니다

이 환경을 설계하는 일을 가리키는 이름으로, 지금은 하네스 엔지니어링이라는 표현이 꽤 정확해 보입니다.

하네스라는 단어부터가 좋습니다. 말에게 씌우는 마구입니다. 고삐, 안장, 등자. 말의 힘을 없애는 장비가 아니라 그 힘이 엉뚱한 데로 새지 않게 방향을 주는 장비입니다. AI 에이전트도 비슷합니다. 모델이 강력해질수록 더 그렇습니다. 힘이 세다고 좋은 게 아니라 어디에 그 힘을 전달하게 만들지를 설계해야 합니다.

그러니까 하네스 엔지니어링은 모델을 더 똑똑하게 만드는 일이 아니라 모델이 일할 수 있는 외부 환경을 설계하는 일에 가깝습니다.

이걸 가장 짧게 쓰면 이렇게 됩니다.

Agent = Model + Harness

모델이 아닌 나머지 전부가 하네스입니다. 시스템 프롬프트, 도구 정의, 샌드박스, 실행 환경, 오케스트레이션 로직, 파일 시스템, 메모리 관리, 훅, 미들웨어, 피드백 루프. 그러니까 하네스 엔지니어링은 프롬프트 엔지니어링의 후속편이 아니라 훨씬 바깥쪽 레이어입니다. 프롬프트와 컨텍스트를 품고 그 위에서 굴러가는 전체 시스템입니다.

세 층위를 한 줄에 놓으면 이렇게 갈립니다. 프롬프트 엔지니어링은 "무엇을 물어볼까"의 문제입니다. 컨텍스트 엔지니어링은 "무엇을 보여줄까"의 문제입니다. 하네스 엔지니어링은 "이 전체 환경을 어떻게 설계할까"의 문제입니다.

저는 이 셋을 대체 관계로 보지 않습니다. 포함 관계에 가깝습니다. 프롬프트는 아직도 필요하고 컨텍스트도 여전히 중요합니다. 다만 지금의 에이전트 시스템에서는 그 둘만 잘한다고 해결되지 않는 영역이 너무 커졌습니다. 그래서 관심의 중심이 바깥으로 이동한 겁니다.

이 흐름을 시간축에 올려놓으면 더 분명해집니다. 2022년부터 2024년까지는 프롬프트가 주인공이었습니다. 질문을 어떻게 구성하느냐가 거의 모든 담론을 잡아먹었습니다. 2025년 중반부터는 컨텍스트가 올라왔습니다. RAG니 MCP니 메모리니, 결국 모델에 어떤 토큰을 어떤 타이밍에 주입하느냐가 핵심이라는 얘기가 많아졌습니다. 그러다 2026년에 와서는 아예 에이전트를 둘러싼 외부 시스템 전체를 건드리는 얘기가 전면으로 튀어나옵니다. Mitchell Hashimoto가 2026년 2월에 자기 AI 도입 과정을 정리한 글에서 마지막 단계를 "하네스를 설계한다"로 적었고, 정의도 짧았습니다. 에이전트가 실수하는 걸 보면 그 실수가 다시 불가능해지도록 환경을 고친다는 것입니다. 몇 주 안에 앤트로픽과 OpenAI 쪽에서 같은 방향의 엔지니어링 글이 이어졌고, 사례들도 "모델이 좋아서"보다 "환경을 잘 짜서" 성능을 끌어올린 쪽으로 읽히기 시작했습니다. 흐름이 확실히 바뀌었습니다. (이 글에서 언급하는 외부 사례와 실험 결과는 2026년 9월 11일 확인일 기준입니다. 원문 목록은 글 끝에 모아뒀습니다.)

용어가 하나 더 늘어난 걸 반가워할 사람은 별로 없을 겁니다. 저도 처음엔 또 새 이름 붙이는구나 싶었습니다. 그런데 이 말이 유용한 이유는 개념이 새로워서가 아니라, 문제를 어디서 찾을지를 바꿔주기 때문입니다. 에이전트가 이상하게 굴 때 프롬프트를 고칠지 컨텍스트를 고칠지 환경을 고칠지, 이 셋을 구분해서 물어볼 수 있게 되면 헛수고가 확 줄어듭니다. 이름의 값은 대개 거기서 나옵니다.

왜 지금 이게 중요해졌나

그냥 이름만 새로 붙인 유행어면 금방 사라집니다. 그런데 이건 좀 다릅니다. 모델만으로는 해결이 안 되는 문제가 이미 너무 분명하게 드러났기 때문입니다.

LLM은 세션이 끝나면 상태를 잃습니다. 코드를 직접 실행하지 못합니다. 실시간 정보에 자동으로 접근하지 못합니다. 자기 결과물을 자기 기준으로 검증하는 데도 한계가 큽니다. 우리가 대화창에서 AI와 얘기할 때조차 사실은 원시적인 형태의 하네스를 쓰는 셈입니다. 이전 메시지를 이어붙이고 툴을 부르고 조건이 맞으면 다시 모델을 호출하는 루프. 이건 그냥 대화 UI가 아니라 아주 기초적인 하네스입니다.

문제는 에이전트 작업이 길어질수록 이 기초적인 하네스로는 버티기 어렵다는 점입니다.

앤트로픽이 공개한 사례가 그래서 흥미로웠습니다. Claude에게 "claude.ai의 클론을 만들어라" 같은 고수준 프롬프트 하나만 주고 여러 컨텍스트 윈도우에 걸쳐 돌렸을 때 나타난 패턴을 보면, 모델 자체가 멍청해서가 아니라 환경이 부족해서 무너진다는 게 꽤 노골적으로 드러납니다. 한 번에 다 해내려고 들다가 구현 중간에 컨텍스트가 떨어지고, 그러면 다음 세션이 반쯤 만들어진 기능을 설명도 없이 물려받습니다. 자기 작업을 평가하라고 시키면 형편없는 상태에서도 스스로 만족해버립니다. 앤트로픽이 낸 해법도 모델 교체가 아니었습니다. 첫 세션에 환경을 차려놓는 에이전트와 매 세션 조금씩 진행하면서 다음 세션이 읽을 흔적을 남기는 에이전트로 역할을 나눴습니다.

이건 모델을 조롱할 일이 아닙니다. 사람한테도 비슷한 조건을 주면 똑같이 벌어질 일입니다. 진행 상황 보드도 없고 테스트도 없고 기록도 없고 상태 인수인계도 없는데 복잡한 프로젝트를 끝내라고 하면 누가 잘하겠습니까.

환경이라는 말을 뜯어보면

막연하게 "환경"이라고만 하면 금방 또 공허해집니다. 앞에서 사람한테 진행 상황 보드도 기록도 인수인계도 없이 프로젝트를 맡기면 똑같이 무너진다고 했는데, 그 없는 것들을 하나씩 채워 넣는다고 생각하면 목록이 저절로 나옵니다.

기억부터입니다. LLM은 대화창이 끊기면 잊어버리는데 파일은 남습니다. 이 사소한 차이가 제일 큽니다. 세션이 끝날 때 어디까지 했고 어떤 파일을 건드렸고 다음엔 뭘 해야 하는지를 텍스트 파일 하나에 적어두면, 다음 세션이 그걸 읽고 이어서 일합니다. 없으면 매 세션이 기억상실에서 출발합니다. 여기에 Git을 붙이면 되돌아갈 지점이 생기고, 실험을 갈라놓을 수 있고, 여러 에이전트가 같은 저장소를 놓고 일할 수도 있습니다. 파일 시스템이 곧 에이전트의 장기 기억입니다.

그다음이 컨텍스트를 어떻게 상하지 않게 유지할 것인가입니다. 긴 컨텍스트가 무조건 좋은 게 아니라는 건 이제 다들 압니다. 관련 없는 정보가 쌓이면 모델은 바늘 대신 건초더미를 더 많이 받습니다. 창이 넓어졌다고 바늘 찾기가 쉬워지지는 않고, 오히려 덜 맞는 정보가 늘면 추론이 흐릿해집니다.

그래서 하네스가 개입합니다. 오래된 히스토리를 눌러 요약하고, 도구 출력을 대화창에 통째로 붓지 않고 파일로 빼두고, 지침은 필요한 순간에만 불러오고, 통과한 테스트는 조용히 넘기고 실패한 것만 올립니다. 마지막 항목이 특히 그렇습니다. 통과 로그 수천 줄을 매번 밀어넣던 걸 실패만 남기게 바꿨더니 에이전트가 눈에 띄게 나아졌다는 얘기는 과장이 아닙니다.

같은 문제의 다른 해법이 서브 에이전트입니다. 이걸 역할 분담 도구로만 보면 절반만 본 겁니다. 프론트엔드 담당, 백엔드 담당, 리서치 담당으로 쓸 수도 있지만 더 중요한 건 격리입니다. 상위 에이전트가 조사 흔적과 실패한 시도와 중간 노이즈를 전부 떠안으면 금방 오염됩니다. 하위 작업을 따로 돌리고 결과만 요약해서 올려보내면 그 자체가 방화벽이 됩니다. 비용 쪽에도 유리합니다. 메인은 비싼 모델로 두고 범위가 좁은 작업은 싼 모델로 돌리면 됩니다. 필요한 건 무한한 컨텍스트가 아니라 더 나은 분리입니다.

손과 발도 있어야 합니다. 코드 실행이 여기 해당하는데, 모든 행동을 미리 도구로 정의해둘 수는 없으니 셸이나 파일 읽고 쓰기 같은 범용 도구가 필요해집니다. 그런데 범용성을 열어주는 순간 보안이 따라붙습니다. 만들어낸 코드를 아무 데서나 돌리면 위험하니까요.

그래서 샌드박스가 옵니다. 격리된 환경에서 허용된 명령만, 네트워크는 제약을 두고, 필요할 때 잠깐 만들어 쓰고 버리는 구조입니다. 생각하는 쪽과 실행하는 쪽을 아예 나눠서 설명하는 방식도 같은 맥락입니다. 둘을 분리하면 공격 표면이 줄어듭니다. 신뢰할 수 없는 코드가 자격 증명이 들어 있는 컨테이너에서 같이 뛰는 구성은 지금 보면 좀 아찔합니다. 프롬프트 인젝션 한 번이면 환경 변수부터 나갑니다.

마지막이 훅과 백프레셔입니다. 특정 시점에 자동으로 끼어드는 장치입니다. 파일을 고치면 타입 체크를 돌리고, 어떤 파일은 손대기 전에 승인을 받게 하고, 검증을 건너뛰는 커밋 옵션을 막고, 세션이 시작되면 상태 파일부터 읽게 합니다. 일하는 과정 곳곳에 규율을 심는 방식입니다.

백프레셔는 그중에서도 값이 다릅니다. 에이전트가 자기 결과를 스스로 확인하게 만드는 쪽입니다. 테스트, 커버리지, 브라우저 자동화, 타입 체크, 스모크 테스트. "완료"라고 말하기 전에 실제 사용자처럼 한번 눌러보게 하는 것. 이건 QA라기보다 에이전트에게 현실을 되돌려주는 장치에 가깝습니다.

다만 훅을 걸어두면 다 되는 것도 아닙니다. 훅을 열 개 넘게 걸어두고 넉 달 동안 한 번도 안 걸린 적이 있는데, 그때 알았습니다. 안 걸리는 훅은 안전한 게 아니라 그냥 없는 겁니다.

그래서 요즘은 이렇게 일합니다

이런 걸 몇 번 겪고 나서 지난 반년 동안 제가 일하는 방식이 꽤 많이 바뀌었습니다.

거의 모든 개발 작업을 에이전트에 맡기고 있습니다. 제가 에디터에서 직접 코드를 친 시간은 많지 않습니다. Claude Code와 Codex가 주요 실무자처럼 움직였고, 저는 그들이 맥락을 제대로 이해하고 엉뚱한 실수를 덜 하도록 환경을 설계하는 쪽에 붙어 있었습니다. 에이전트가 못 보는 게 코드가 아니라 그 코드 바깥이라는 얘기를 앞에서 했는데, 그 바깥을 떠먹여 주는 일이 실제로는 이런 모양입니다.

실제로 제가 가장 많이 한 일은 코드 작성이 아니었습니다.

ADR을 썼습니다. 왜 이 구조를 선택했고 왜 다른 안을 버렸는지를 기록으로 남겼습니다. ADR이 없으면 AI는 매번 새로운 최적해를 찾으려 들고 기존 결정을 아무 의도 없이 뒤엎습니다. 반대로 ADR이 있으면 반년 뒤에 새 세션이 열려도 같은 판단을 재사용할 수 있습니다. AI 시대의 ADR은 취향 기록이 아니라 기억 장치에 가깝습니다.

문서를 계속 고쳤습니다. AI가 코드를 읽다가 맥락을 놓치는 지점이 보이면 그걸 설계 문서로 끌어올려 명시화했습니다. 코드 주석 몇 줄로 버티려 하지 않았습니다. 주석은 자주 무시되지만 설계 문서는 기준점으로 재사용되기 때문입니다.

스킬 정의도 계속 손봤습니다. AI가 반복적으로 같은 실수를 하면 프롬프트 한 번 고치고 끝내지 않았습니다. 스킬 정의 자체를 바꿨습니다. 한 번 손보면 그 스킬을 호출하는 모든 세션에 같은 개선이 들어갑니다. 이건 일회성 수정이 아니라 반복 가능한 교정입니다.

에이전트 팀도 나눴습니다. 한 에이전트가 모든 걸 하게 두지 않고 전략, 실행, 검수, 발행처럼 역할을 나눴습니다. 사람 팀에서 책임 분리가 필요한 이유와 똑같습니다. 맥락을 너무 많이 쥔 한 에이전트는 금방 흐려집니다.

훅과 MCP도 만들었습니다. 실수 가능성이 높은 지점에 자동화된 가드레일을 심었습니다. 특정 파일을 건드릴 때 필요한 문맥을 자동으로 주입하고, 커밋 전에 특정 규칙을 검사하고, 위험한 경로를 막는 식입니다. 이건 "AI에게 잘 설명하기"와는 다른 종류의 일입니다. 설명은 무시될 수 있지만 구조는 우회하기 어렵습니다.

그리고 계속 신경 쓰는 게 하나 더 있습니다. 토큰 낭비입니다. 어떤 문맥을 언제 주입할지, 어떤 일을 어떤 에이전트에 맡길지, 어디까지 자동화하고 어디서 끊을지. 이 결정들이 품질도 정하고 비용도 정합니다. 적은 토큰이면 끝날 일을 열 배로 돌린다고 결과가 꼭 더 좋아지지 않습니다. 오히려 흐려질 때도 많습니다. 그래서 이제는 결과물만 보는 게 아니라 그 결과가 얼마의 비용과 얼마의 복잡도로 나왔는지도 같이 봅니다. 이건 예전엔 거의 없던 감각입니다.

코드를 덜 치게 됐다고 일이 줄어든 건 아닙니다. 무게중심이 완전히 다른 쪽으로 옮겨갔을 뿐입니다.

하네스가 모델 위에 얹는 얇은 래퍼가 아니라는 것

"그래서 이게 정말 그렇게 차이를 만드나?"라는 질문이 나올 만합니다. 저도 처음엔 약간 회의적이었습니다. 도구 인터페이스 하나 바꿨다고 점수가 그렇게 뛰나 싶었으니까요.

그런데 실험 사례들을 보면 생각보다 큽니다. LangChain 쪽에서 자기 코딩 에이전트의 하네스만 손본 결과를 공개했는데, 검증 루프를 넣고 완료 전 체크리스트를 강제하고 반복 편집을 탐지해 끊는 장치를 붙였습니다. 모델은 gpt-5.2-codex 그대로 뒀고 가중치는 한 바이트도 안 건드렸습니다. Terminal Bench 2.0 점수가 52.8%에서 66.5%로 올랐고, 발표 시점 기준으로 순위가 서른 위권에서 다섯 위권까지 올라갔습니다.

파일 편집 인터페이스 쪽 사례는 더 노골적입니다. Can Bölük이 줄마다 두세 글자짜리 내용 해시를 붙여서 모델이 원문을 그대로 재현하지 않고 해시로 위치를 가리키게 바꿨습니다. 열여섯 개 모델을 180개 작업에 붙여봤더니 평균 15퍼센트포인트가 올랐고, 제일 약했던 모델 하나는 6.7%에서 68.3%로 뛰었습니다. 열 배입니다. 그러면서 출력 토큰은 오히려 줄었습니다. 모델이 편집을 실패하고 다시 시도하는 데 쓰던 토큰이 사라졌기 때문입니다.

이건 모델이 갑자기 천재가 됐다는 얘기가 아닙니다. 일이 잘 풀리도록 손잡이를 바꿔준 결과입니다. 사용자가 도구를 이해하기 쉽게 만든 게 아니라 모델이 도구를 덜 헷갈리게 만든 겁니다.

이 두 사례를 붙여놓고 보면 공통점이 하나 있습니다. 둘 다 모델이 뭘 더 알게 만든 게 아니라 모델이 덜 헷갈리게 만든 쪽입니다. 앞쪽은 언제 멈추고 무엇을 확인할지를 정해줬고, 뒤쪽은 어디를 고치라고 말하는 방법을 바꿨습니다. 성능이 올라간 만큼 토큰이 줄어든 것도 그래서입니다. 헤매는 데 쓰던 걸 안 쓰게 됐으니까요. 하네스 손질이 듣는 자리는 대개 이런 모양인 것 같습니다. 능력을 더해주는 게 아니라 낭비를 걷어내는 쪽입니다.

앤트로픽이 비교한 다중 에이전트 사례는 더 노골적입니다. 같은 요구사항을 주고 단일 에이전트와 세 에이전트 구성을 붙여봤습니다. 단일 쪽은 20분에 9달러로 끝났는데 핵심 기능이 아예 안 돌았습니다. 만든 게임에서 입력에 반응하는 게 없었습니다. 세 에이전트 쪽은 여섯 시간에 200달러를 쓰고 실제로 돌아가는 결과를 냈습니다. 스무 배가 넘는 비용입니다.

숫자만 보면 싼 쪽이 효율적으로 보입니다. 그런데 안 돌아가는 결과물의 단가는 계산에 넣을 수가 없습니다. 그리고 이 세 에이전트가 계획·생성·평가로 나뉘어 있었다는 점이 중요합니다. 평가를 별도 에이전트로 떼어낸 이유가 앞에서 말한 자기 평가 문제입니다. 자기가 만든 걸 자기가 채점하면 후하게 줍니다. 이 차이는 모델의 지능 차이가 아니라 작업을 어떻게 분할하고 누가 검증하게 했느냐의 차이입니다.

이쯤 되면 엔지니어 역할도 바뀔 수밖에 없습니다. 예전엔 좋은 엔지니어를 "코드를 정확히 쓰는 사람"으로 상상했습니다. 물론 지금도 그 능력은 중요합니다. 그런데 에이전트 시대에는 그 엄밀함이 조금 다른 자리로 이동합니다. 한 줄 한 줄 직접 타이핑하는 정밀함이 아니라 에이전트가 제대로 일할 수 있는 환경을 설계하는 정밀함입니다. 어떤 도구를 연결할지, 어떤 파일을 상태 저장소로 삼을지, 어떤 테스트를 매 단계에서 강제할지, 실패했을 때 어디서 되돌릴지, 어떤 수준에서 사람에게 넘길지. 손이 아니라 환경으로 엄밀함이 옮겨가는 겁니다.

다루는 대상에서 쓰는 도구로

여기까지 정리하고 나서 제 쪽에서 바뀐 게 하나 더 있습니다. AI를 대하는 자세 자체입니다.

1단계 때 저는 LLM을 다루고 있었습니다. 어떻게 물어야 잘 답하는지, 어떤 표현에 민감한지, 어디까지 알아듣는지. 관심이 모델 쪽을 향해 있었습니다. 새 모델이 나오면 벤치마크부터 열어봤고 무엇이 얼마나 좋아졌는지 확인했습니다.

지금은 그 관심이 거의 사라졌습니다. 새 모델 발표를 언제부턴가 안 열어보게 됐다고 따로 쓴 적도 있는데, 그때는 피로해서라고 생각했습니다. 지금 보면 그게 아니라 보는 자리가 옮겨간 거였습니다.

도구를 쓰는 사람은 도구의 성능을 감탄하는 데 시간을 안 씁니다. 어디에 놓고 어떻게 잡을지를 봅니다. 목수가 대패 얘기를 할 때 날의 경도를 논하는 게 아니라 어떤 나무에 어느 각도로 쓰는지를 말하는 것과 비슷합니다. 도구가 좋아지는 건 반가운 일이지만 그건 만든 쪽 소관이고, 쓰는 쪽 일은 그걸 어디에 배치하느냐입니다.

그래서 요즘 제가 던지는 질문이 달라졌습니다. 예전엔 "이 모델이 이걸 할 수 있나"를 물었다면 지금은 "이 일을 어떤 조합으로 굴리는 게 맞나"를 묻습니다. 어떤 단계를 자동화하고 어디서 끊을지, 어떤 문맥을 언제 넣을지, 어느 지점에서 사람이 봐야 할지. 모델의 능력치가 아니라 배치의 문제입니다.

다만 이 전환에 불편한 면도 있습니다. 모델을 상대할 때는 잘 안 되면 모델 탓을 할 수 있었습니다. 환경을 만드는 쪽으로 옮기면 잘 안 되는 게 대부분 제가 만든 것 탓이 됩니다. 도구를 탓할 자리가 없어지는 셈입니다. 편하지는 않은데 일이 앞으로 가는 데는 훨씬 낫습니다. 탓할 데가 없으면 고칠 데를 찾게 되니까요. 그리고 찾기 시작하면 대개 찾아집니다. 상태 파일이 없거나, 검증이 없거나, 도구 하나가 손에 안 맞거나 하는 식으로요.

이게 프롬프트 엔지니어링과 하네스 엔지니어링의 진짜 차이라고 보고 있습니다. 프롬프트는 여전히 모델을 상대하는 일입니다. 잘 물어보는 기술이니까요. 하네스는 모델을 상대하지 않습니다. 모델이 놓일 자리를 만드는 일입니다. 상대에서 자재로 바뀌는 셈인데, 그렇게 보기 시작하면 무엇을 공부해야 하는지도 같이 바뀝니다. 모델의 특성을 좇는 게 아니라 우리 일의 구조를 보게 됩니다.

모델이 좋아지면 하네스가 덜 중요해질까

저는 오히려 반대로 봅니다.

프롬프트 엔지니어링이 아직도 완전히 사라지지 않은 것처럼, 하네스도 모델이 좋아질수록 더 중요해질 가능성이 큽니다. 더 강한 모델일수록 더 넓은 자유도를 가지기 때문입니다. 자유도가 커질수록 고삐의 역할이 중요해집니다. 힘이 약한 말은 멀리 못 가지만 힘이 센 말은 방향이 틀리면 더 크게 사고를 냅니다.

그래서 이 얘기는 굉장히 현실적인 조언으로 돌아옵니다. 코딩 에이전트가 기대만큼 작동하지 않을 때 모델부터 탓하지 말라는 것.

물론 모델 차이도 있습니다. 하지만 꽤 자주 문제는 다른 데 있습니다. 상태 파일이 없고, 툴 인터페이스가 거칠고, 검증 루프가 없고, 실패를 걸러줄 훅이 없고, 컨텍스트가 이미 썩어가는데 계속 그 위에 로그를 쌓고 있는 경우입니다. 그럴 때 답은 모델 업그레이드보다 하네스 손질에서 나오는 경우가 많습니다.

한마디로 줄이면 이렇습니다. 모델은 생각보다 괜찮습니다. 자주 문제인 건 그 모델을 일하게 만든 환경 쪽입니다.

태동기는 끝났지만 안정기는 아직 아닙니다. 지금은 과도기고, 뭔가 폭발적으로 바뀌고 있는데 어디서 멈출지 아무도 모릅니다. 이 시기에 제가 배운 것 하나는 어떤 도구를 익히느냐보다 변화를 얼마나 빨리 흡수하느냐가 경쟁력이라는 겁니다.

1년 반 동안 세 번 바뀌었는데, 도구는 계속 바뀌었고 이해하는 능력만 남았습니다. 프롬프트 엔지니어링이 무의미해진 게 아닙니다. 그걸 배우면서 AI가 어떻게 동작하는지 이해하는 감각이 쌓였고, 그 감각이 에이전트 시대에도 그대로 쓰입니다. 다음에 또 뭐가 나와도 아마 같을 겁니다.

확인한 자료

전부 2026년 9월 11일에 원문을 열어 확인했습니다.

• My AI Adoption Journey — Mitchell Hashimoto, 2026년 2월 5일. 「Step 5: Engineer the Harness」 절에 하네스 엔지니어링의 정의가 나옵니다.
• Effective harnesses for long-running agents — 앤트로픽. claude.ai 클론 실험과 초기화 에이전트·코딩 에이전트 분리.
• Harness design for long-running application development — 앤트로픽. 계획·생성·평가 세 에이전트 구성과 단일 에이전트 대비 비용·시간 비교.
• Improving Deep Agents with harness engineering — LangChain, 2026년 2월 17일. gpt-5.2-codex 기준 Terminal Bench 2.0 52.8% → 66.5%.
• The Harness Problem — Can Bölük, 2026년 2월 12일. 열여섯 개 모델을 대상으로 한 편집 도구 비교. 원 주소는 blog.can.ac 였고 지금은 이쪽으로 넘어옵니다.