AI한테 큰 일을 시켜놓고 기다려보신 적 있으세요?
저는 있어요. 한참 뒤에 돌아와 보니 반쯤 하다 멈춰 있거나, 다 됐다는데 열어보면 엉망이었어요. 그동안 저는 모델 성능 탓이라고 생각했어요.
아니더라고요. 앤트로픽이 장기 실행 에이전트를 굴리는 법을 여러 편에 걸쳐 공개했는데, 문제는 모델이 아니라 하네스였어요.
하네스는 모델을 감싸는 환경 전부를 가리켜요. 지시문, 파일, 검사 절차 같은 것들이요.
결론부터 한 줄로 적으면 이래요. 모델을 바꾸기 전에 하네스부터 보세요. 개발사 글 네 편을 제 언어로 옮겨뒀으니, 읽는 데는 오래 안 걸려요.
밤샘 작업이든 두 시간짜리 위임이든 마찬가지예요. 저는 이제 모델 탓을 하기 전에 제 파일부터 봐요.
매 교대마다 기억이 없는 직원이 출근하면
지난해 가을 앤트로픽의 저스틴 영이 쓴 글에 이런 비유가 나와요. 매 교대마다 이전 교대의 기억이 없는 엔지니어가 출근하는 소프트웨어 프로젝트요. AI 에이전트가 처한 상황이 정확히 그렇대요.
Effective harnesses for long-running agents
길게 일하다 보면 컨텍스트가 차서 대화가 요약되잖아요. 요약만으로는 부족하다고 글이 못 박아요. 요약본은 어디까지나 요약본이라, 새 교대가 정확히 어디서부터 이어야 하는지 알기 어려워요.
그래서 처방은 기억을 모델 밖에 두는 거예요. 해야 할 기능 목록을 JSON 파일로 만들고, 200개 넘는 기능 전부를 처음엔 통과 안 함으로 시작해요.
전부 통과 안 함인 이유는 분명해요. 새 교대가 뭐가 남았는지 한눈에 봐야 하니까요.
JSON을 쓰는 까닭도 재밌어요. 모델이 마크다운보다 JSON 파일을 함부로 고치거나 덮어쓸 가능성이 낮다는 거예요. 인수인계 문서는 함부로 못 고치는 재질로 만들어두는 거죠.
한 세션이 하는 일은 단순해요. 목록에서 통과 안 된 기능 하나를 골라 만들고, 확인한 뒤 통과로 바꿔둬요. 다음 교대가 또 다음 기능을 집는 거예요.
거기에 진행 노트 파일과 깃 커밋을 붙여요. 새 세션이 시작하면 순서가 정해져 있어요. 작업 폴더 확인, 깃 로그와 진행 노트 읽기, 기능 목록에서 다음 기능 고르기까지 딱 세 단계예요.
깃 커밋도 기억 장치예요. 코드를 한 줄도 본 적 없는 새 교대도 커밋 로그만 읽으면 지난 교대가 뭘 했는지 알아요.
테스트를 지우거나 고치는 건 용납할 수 없다는 문구까지 프롬프트에 박아요. 왜 이렇게까지 하냐면, 끝내기 조급해진 에이전트가 통과를 위해 규칙을 바꾸는 사고가 있거든요.
여기서 반전이 하나 있어요. 이 관행들의 영감은 잘하는 소프트웨어 엔지니어들이 매일 하는 일에서 왔대요. 첨단 기술이 아니라 인간 업계의 상식이었던 거죠.
제 얘기로 바꿔보면 이래요. AI한테 일을 시켜놓고 자고 일어나면, 새 세션은 어제 제가 뭘 시켰는지 몰라요. 제 머리에만 있던 진행 상황이 파일에 없으면 그날 작업은 거기서 끝이에요.
자기가 만든 걸 자기가 채점하면
올해 봄 나온 프리트비 라자세카란의 글은 한 걸음 더 가요. 계획하는 에이전트, 만드는 에이전트, 검수하는 에이전트를 나눈 3인 체제예요.
Harness design for long-running application development
왜 굳이 나누냐면, 자기가 만든 걸 평가해달라고 하면 AI는 자신 있게 칭찬한대요. 사람이 보기에 뻔히 그저 그런 물건인데도요. 아무 설정 없이는 클로드가 형편없는 검사관이라고 글이 직접 못 박아요.
실험이 구체적이에요. 2D 레트로 게임 메이커를 만들게 했어요. 혼자 굴리면 20분에 9달러였는데, 결과는 핵심 게임 런타임이 깨져서 입력에 반응도 없는 물건이었죠.
풀 하네스로 돌리면 6시간에 200달러예요. 대신 16개 기능과 10개 스프린트 계획을 거쳐 실제로 플레이되는 게임이 나왔어요.
검수자의 솜씨도 인상적이에요. 버그를 감으로 찍은 게 아니라 LevelEditor.tsx의 892번째 줄까지 짚어서 잡아냈어요.
역할이 갈리면서 생기는 것도 있어요. 만드는 쪽은 깔린 설계도를 따라가기만 하면 돼요. 검수하는 쪽은 만들어본 적이 없으니 제 편을 들 이유가 없고요.
저자의 결론이 와닿았어요. 따로 떼어놓은 검수자를 의심 많게 조율하는 게, 만드는 애한테 자기 일을 비판하게 만드는 것보다 훨씬 쉽다는 거예요. 검사는 남이 해야 한다는 제 평소 생각이 개발사 연구로 확인된 셈이죠.
하네스도 유통기한이 있어요
하네스를 잘 만들었다고 끝이 아니에요. 역시 올해 봄에 나온 랜스 마틴, 게이브 세마이, 마이클 코언의 글에 뼈아픈 일화가 있어요.
소네트 4.5 시절, 모델이 컨텍스트 한계가 가까워진다고 믿으면 일을 조기에 마무리해버리는 버릇이 있었어요. 이른바 컨텍스트 불안이요. 그래서 팀이 하네스에 컨텍스트 리셋을 심어뒀어요.
컨텍스트 불안이 뭐냐면 이런 거예요. 할 일이 꽤 남았는데 곧 잊힐 걸 걱정해서 슬슬 정리하고 마치려는 버릇이요. 우리가 밤샘 작업에서 본 바로 그 장면이죠.
그런데 오푸스 4.5가 나오자 그 리셋이 쓸모없어졌어요. 모델이 스스로 알아서 해내게 됐거든요. 글의 표현 그대로 리셋이 짐이 돼버린 거예요.
하네스의 모든 부품은 모델이 이건 혼자 못 한다는 가정을 새겨둔 거예요. 그리고 그 가정은 모델이 좋아지면 상해요. 머리인 모델은 갈아끼워지는데 손인 하네스가 남는 구조라, 이 문제는 반복될 수밖에 없어요.
클로드 코드 팀의 타릭 시히파도 같은 결론이에요. 클로드 코드의 시스템 프롬프트를 80퍼센트 넘게 지웠는데 코딩 평가에서 잃은 게 없었대요.
The new rules of context engineering
새 모델이 나오면 지시를 더하기 전에 빼기부터 해보라는 게 그의 원칙이에요.
80퍼센트를 지우고도 평가가 그대로였다는 건, 그 지시들이 모델을 위한 게 아니라 옛 가정을 위해 있었다는 뜻이에요.
제 CLAUDE.md를 뒤져보니 비슷한 게 보였어요. 옛날 모델이 자주 틀리던 자리를 우회하려고 적어둔 지시들이요. 그 모델은 한참 전에 안 쓰는데 지시만 남아 있었어요.
복잡함은 제 몫을 해야 해요
그렇다고 무조건 복잡한 하네스가 답은 아니에요. 아까 숫자를 다시 볼게요. 9달러짜리 작업과 200달러짜리 작업, 스무 배가 넘게 차이 나요.
검수자를 붙일 값어치가 있는 건, 그 일이 현재 모델이 혼자 믿음직하게 해내는 범위를 넘어설 때뿐이에요. 그리고 그 경계는 모델이 좋아질수록 바깥으로 밀려나요. 어제 검수가 필요했던 일이 오늘은 혼자 되는 거죠.
반대로 말하면 이래요. 모델이 혼자 해내는 일에 검수자까지 붙이면 돈과 시간만 두 배로 쓰는 거예요. 문구 하나 고치는 일에 3인 체제를 돌릴 이유가 없어요.
타릭의 문장을 빌리면, 복잡함은 제 몫을 해야 해요. 몫을 못 하는 복잡함은 그냥 비용이에요.
경계가 밀려난다는 건 좋은 소식이에요. 하네스를 더 단순하게 가져갈 여지가 계속 생긴다는 뜻이니까요.
제 마크다운 몇 장도 하네스예요
개발사 얘기가 남 일 같지 않더라고요. 저도 클로드 코드로 일하니까요. 제 수준에서 당장 할 수 있는 게 세 가지 보였어요.
첫째, 긴 작업을 시킬 땐 진행 파일을 둬요. 진행 상태 파일과 기능 체크리스트를 만들어두고, 새 세션이 거기서부터 이어가게 해요.
기억상실 교대근무자한테 인수인계 문서를 쥐여주는 거예요. 제 기억은 세션이 끝나면 사라지지만 파일은 남으니까요.
둘째, 만든 세션과 검사하는 세션을 나눠요. 새 세션을 열어서 "이거 검사해줘"라고 던지는 거예요. 만든 사람 눈으로 보면 다 잘 보이니까요.
검사 기준만 미리 적어두면 새 세션이 제 편을 들 이유가 없어요. 판매 글 검사할 때 제가 늘 하던 방식이기도 하고요.
셋째, 모델이 바뀌면 CLAUDE.md와 스킬을 감사해요. 예전 모델의 약점을 우회하려고 박아둔 지시가 다음 모델에선 짐이 돼요.
감사라고 거창할 것도 없어요. 이 지시가 아직 필요한가 한 번씩만 물어보면 돼요. 지난 시즌에 적어둔 문장들을 저도 이번에 다시 읽어봐야겠어요.
셋 중에 하나만 고르라면 진행 파일부터요. 새 파일 하나 만드는 일이라 오늘 밤 작업부터 바로 써먹을 수 있어요.
다만 파일을 만들었다고 끝은 아니에요. 새 세션이 그 파일을 실제로 읽고 시작하는지, 처음 한 번은 지켜보세요.
정리하면 이래요. AI가 긴 작업을 못 끝내는 건 모델이 나빠서가 아니에요. 모델을 감싼 환경이 그 일을 끝내게 설계 안 됐기 때문이에요.
모델 교체가 아니라 하네스 설계가 장기 실행 성능을 가르는 겁니다.
그리고 개발사만의 얘기가 아니에요. 제 폴더에 있는 마크다운 몇 장, 진행 파일과 검사 목록과 CLAUDE.md가 제 하네스예요. 다음 밤샘 작업을 시키기 전에 그 몇 장부터 손봐보려고요.
AI한테 일을 시키는 순서 자체를 정리한 건 『시키는 기술』에 담아뒀어요. 23,500원이고 지금까지 131분이 가져가셨어요.
FAQ
자주 묻는 질문
- 하네스를 만들려면 코딩을 알아야 하나요?
- 아니에요. 앤트로픽 글에 나온 핵심 도구도 결국 파일 몇 개예요. 진행 상태를 적는 텍스트 파일, 해야 할 일을 적은 목록, 검사 기준을 적은 문서요. 말로 시키던 걸 파일로 옮기는 게 전부고, 그 파일은 평범한 문장으로 쓰면 돼요.
- CLAUDE.md에 규칙을 많이 적을수록 좋은 거 아닌가요?
- 꼭 그렇진 않아요. 클로드 코드 팀은 시스템 프롬프트의 80퍼센트 넘게를 지웠는데도 코딩 평가에서 잃은 게 없었대요. 지시 하나하나가 모델은 이걸 혼자 못 한다는 가정인데, 모델이 좋아지면 그 가정이 상하거든요. 새 모델이 나오면 더하기 전에 빼기부터 해보세요.