여러 세션에 걸친 코딩 에이전트가 매번 환경을 다시 찾고 성급하게 완료를 선언합니다. 장기 실행 harness에는 무엇이 필요한가요?

harness는 모델을 둘러싼 도구·상태·권한·실행·검증 환경입니다. 장기 작업에서는 긴 컨텍스트 하나보다 세션이 바뀌어도 목표와 현재 상태를 재확인하고 작은 단위로 진전할 수 있는 구조가 필요합니다. 시작 절차, 요구별 완료 기준, 진행 기록, 버전 관리와 실제 검증을 함께 두겠습니다.

시작과 종료의 표준 절차

첫 세션은 환경 준비·실행 방법·요구 목록과 기준선을 정리하고, 후속 세션은 작업 디렉터리·최근 변경·진행 기록·미완료 항목을 읽고 기본 동작부터 확인할 수 있습니다. 이전 세션이 정상이라고 기록했어도 환경이나 파일이 바뀌었을 수 있어 기준선 시험이 필요합니다. 한 번에 전체 기능을 만들기보다 작은 항목을 구현·검증한 뒤 상태를 갱신하면 실패 위치를 추적하기 쉽습니다.

진행 기록에는 실제 수정 파일·테스트 명령·결과·미확정 외부 작업·다음 행동을 남깁니다. 코드 작성과 기능 검증을 같은 완료 표시로 합치지 않습니다. 검증 기준은 모델이 쉽게 통과하도록 임의로 바꾸지 못하게 보호하고, 외부에서 관찰 가능한 사용자 흐름을 포함합니다. 예를 들어 UI 버튼이 보이는 것과 클릭 후 데이터가 저장되는 것은 다른 조건입니다.

기억이 아니라 복구 가능한 상태

컨텍스트 압축은 유용하지만 실행 사실의 유일한 저장소가 되어서는 안 됩니다. 작업 ID·체크포인트·파일 버전과 결과물을 별도로 보관하고, 재개 시 원본과 대조합니다. 모델이 다음 세션을 위해 만든 지침도 사용자 승인 범위를 넓힐 수 없습니다. 커밋·게시·배포 같은 외부 영향은 해당 작업의 명시적 권한과 절차를 따릅니다.

2025년 공개된 장기 에이전트 harness 사례는 초기화와 후속 구현 세션의 역할 분리, 기능 목록, 실행 스크립트·진행 기록과 실제 브라우저 검증의 가치를 설명합니다. 이를 모든 도메인에서 증명된 최적 구조라고 일반화하지 않습니다. 작업에 따라 내구 워크플로 엔진이나 단순 파일 기록이 더 맞을 수 있습니다. 평가에서는 세션 경계에서 목표 이탈·중복 작업·기준 훼손·성급한 완료가 줄었는지와 추가 초기화 비용을 함께 봅니다. 좋은 harness는 모델의 잠정 판단을 검증 가능한 실행 상태로 연결하는 환경입니다.

실행 사례로 확인합니다

요구 목록을 JSON으로 저장하면 상태를 검사하고 UI에 표시하기 쉽지만 모델이 파일을 수정할 수 있다면 거짓 완료를 쓰는 것도 가능합니다. 완료 필드만 바꿀 수 있게 제한하거나 외부 검증 결과로 상태를 갱신하는 등 런타임의 집행이 필요합니다. 첫 세션의 설정 스크립트도 영원히 맞는 것이 아니므로 의존성·환경 버전을 확인합니다. 장기 작업이 여러 번 중단돼도 새 세션이 현재 실행 환경을 시작하고 작은 회귀 테스트를 재현할 수 있어야 합니다. 진행 기록이 길어지면 요약과 원문 참조를 나누되, 미해결 실패와 승인 범위를 압축에서 지우지 않겠습니다. 이러한 재개 비용도 전체 성공당 비용에 포함합니다.