AI가 보고서를 만들다가 멈췄습니다. 다음 날 대화 요약을 읽고 이어서 실행했는데, 어제 확인하지 못한 수치를 완료한 것으로 취급합니다. 작업 기록에는 “보고서 작성 중”이라고 적혀 있지만 실제 파일의 위치와 검사를 끝낸 항목은 연결되어 있지 않습니다. 금요일 회의에서 미확인 수치를 사실로 사용하게 될 수 있습니다.
가상의 업무 장면입니다. 여기서 필요한 것은 대화를 더 많이 기억하는 기능과 함께 현재 작업 상태를 확인할 수 있는 연결입니다. 중단한 일이 어디까지 끝났고, 무엇이 아직 확인되지 않았으며, 다음 행동을 무엇으로 시작할지 알아야 합니다.
이 글에서는 하네스를 모델이 일할 수 있도록 도구, 상태 보존, 검사와 피드백을 연결하는 실행 환경으로 다룹니다. 공개 개발 사례마다 범위와 구성은 다릅니다. 가상 보고서 업무의 구체적인 구성 예시로 장기 업무의 실패를 어떻게 다룰지 살펴봅니다.
01대화 요약이 있어도 진행 상태는 잘못 이어질 수 있습니다
Anthropic은 2025년 11월 장기 실행 웹 앱 개발 실험에서 한 번에 너무 많은 일을 시도하거나 일부 구현을 보고 전체 일을 완료로 판단하는 실패를 공개했습니다. 요약 기능이 있어도 작업이 어디까지 완료됐는지 잘못 이어받을 수 있음을 보여준 사례입니다. 다른 업무의 성과를 직접 입증한 실험은 아니지만, 인계의 조건을 생각할 근거가 됩니다. 장기 실행 에이전트 사례
보고서 업무로 돌아오면 “이번 주 보고서 작성 중”이라는 요약은 목표를 기억하게 할 수 있습니다. 그러나 어떤 자료를 확인했는지, 어떤 수치를 검사했는지, 파일이 실제로 만들어졌는지는 이 문장만으로 알 수 없습니다. 대화의 핵심을 기억하는 일과 환경의 현재 상태를 확인하는 일이 함께 필요합니다.
요리를 멈춘 뒤 다른 사람이 이어받는 장면에 비유할 수 있습니다. “채소 손질 중”이라는 메모보다 손질한 재료, 불의 상태, 다음 조리 단계가 남아 있어야 합니다. 메모에는 불을 껐다고 쓰여 있어도 실제 불이 켜져 있으면 메모를 믿고 다음 단계로 넘어가면 안 됩니다. 기록과 현재 상태를 대조해야 합니다.
가상 보고서에서 필요한 인계는 목적과 기준, 완료한 작업의 근거, 실제 산출물의 위치, 미확인 항목, 다음 행동을 연결합니다. 기록을 남겼다는 사실보다 다른 실행이 그 기록으로 무엇을 확인하고 재개할 수 있는지가 중요합니다.
가상 업무의 최소 구성은 승인 계획과 이번 주 기록을 읽는 조회 기능, 보고서 파일을 저장하는 기능, 수치를 원자료와 대조하는 검사, 다음 실행이 읽을 진행 기록으로 생각해 볼 수 있습니다. 실행을 시작할 때 진행 기록과 실제 파일을 읽고, 남은 작업을 수행하고, 검사를 반영해 상태를 갱신합니다. 이런 연결 전체가 여기서 말하는 하네스의 예입니다.
한 가지 구현 예를 더 구체적으로 그려 봅니다. 조회 기능은 승인 계획과 작업 기록의 CSV 파일을 읽는 프로그램, 저장 기능은 보고서 문서 파일을 만드는 프로그램, 검사는 원자료와 보고서의 합계를 비교하는 프로그램이 될 수 있습니다. 진행 기록은 다음 실행이 읽는 메모 파일로 남깁니다. 이 기능들을 호출하고 실패를 처리하며 재개할 때 메모와 파일을 대조하는 실행 프로그램이 이 예의 하네스입니다. 제품으로 기능을 연결하거나 개발자가 프로그램으로 구성할 수 있으며, 메모 파일 하나만으로 완성되는 것은 아닙니다.
진행 기록은 다음처럼 구체적일 수 있습니다.
목표: 금요일 회의의 일정 조정 판단. 기준: 승인 계획 v3와 이번 주 작업 기록. 결과: 보고서 초안 저장. 확인: 합계는 원자료와 일치. 미확인: 테스트 지연 원인. 다음: 해당 작업 기록을 다시 읽고 근거가 없으면 담당자 확인 질문으로 남김.
이 기록은 다른 실행이 무엇을 확인해야 하는지 알려 줍니다. 실제 파일과 근거를 찾을 수 있어야 같은 일을 불필요하게 반복하거나 미확인을 완료로 바꾸는 오류를 발견할 수 있습니다.
02기억한 상태와 실제 상태를 대조하며 재개합니다
진행 기록에 “합계 확인 완료”라고 적혔다고 해 봅니다. 어제의 원자료와 합계가 일치했다는 근거가 있어도 그 뒤 원자료가 바뀌었다면 현재 보고서에는 다시 확인이 필요할 수 있습니다. 기록은 그 시점에 무엇을 확인했는지 알려 줄 뿐 미래의 상태까지 보증하지 않습니다.
따라서 재개할 때에는 기준이 바뀌지 않았는지, 실제 파일이 기록과 맞는지, 남은 항목의 상태가 달라지지 않았는지 살펴야 합니다. 변하지 않는 기준을 매번 모두 읽는 비용과 변한 자료를 놓치는 비용 사이에서 업무별 선택이 필요합니다. 어느 정보를 다시 확인할지 조건을 정하면 기록의 쓰임이 분명해집니다.
외부 작업이 끊겼을 때는 또 다른 문제가 생깁니다. 보고서 저장 도구에 생성을 요청했지만 응답을 받기 전에 실행이 멈추었다면 실제 생성 여부가 불확실할 수 있습니다. 이 상태에서 바로 같은 요청을 다시 보내면 중복 결과가 생길 수 있습니다. 먼저 해당 작업의 저장 위치와 결과 목록을 조회해 파일이 생성됐는지 확인하고, 없다면 다시 실행하는 조건을 정할 수 있습니다.
성공 여부를 모르는 상태를 실패로 단정해 다시 시도하는 것과, 실제 실패를 확인한 뒤 복구하는 것은 다릅니다. 하네스 설계에는 이런 차이를 상태로 남기고 다음 행동에 반영하는 일이 포함됩니다. 이는 공개 장기 실행 사례를 업무에 적용한 설계 제안이며 특정 서비스의 기능 설명은 아닙니다.
인계 기록에는 사람이 허용한 범위도 남아 있어야 합니다. 자료를 읽고 보고서를 작성하도록 허용받은 작업이 다음 실행에서 자동 발송까지 이어져서는 안 됩니다. 목표와 진행 상태를 복원하는 일은 실행 권한을 새로 만드는 일과 구분해야 합니다. 업무가 길어질수록 이 경계도 현재 상태의 일부가 됩니다.
03지식과 도구와 검사가 연결되어야 실행 환경이 됩니다
OpenAI의 2026년 2월 하네스 개발 글은 코드 저장소에 정리한 업무 지식, 도구 접근, 자동 검사와 피드백이 연결된 환경을 설명합니다. 이 사례를 읽을 때 관심을 둘 곳은 지침 파일의 분량보다 에이전트가 실제 자료를 찾고 실행하고 결과를 확인할 수 있도록 환경이 구성됐다는 점입니다. OpenAI 하네스 개발 사례
가상의 보고서 업무에서도 작성 규칙만 존재하는 것으로는 충분하지 않습니다. 규칙이 어떤 원자료를 기준으로 하는지, 그 자료에 접근할 수 있는지, 결과를 어디에 저장할지, 수치나 항목을 어떻게 확인할지가 이어져야 합니다. 문서에 “수치는 정확해야 한다”고 적는 일과 실제 대조가 가능한 환경을 만드는 일은 함께 필요합니다.
여기서 업무의 유효한 기준 문서가 여러 사본으로 갈라지면 실행의 기준도 흔들립니다. 승인 계획의 사본이 여러 곳에 있고 각자 수정된다면 모델이 찾은 파일이 유효한 기준인지 판단하기 어렵습니다. 기준 문서의 위치와 갱신 책임을 정하고, 보고서 같은 결과가 어느 기준에서 만들어졌는지 돌아갈 수 있게 해야 합니다. 이런 연결은 사람의 검토에도 필요합니다.
검사 결과는 다음 행동을 바꿀 수 있어야 합니다. 수치가 맞지 않으면 근거를 다시 읽거나 해당 항목을 미확인으로 남겨야 합니다. 검사 실패를 기록만 하고 그대로 보고서를 완료 처리하면 검사 도구를 추가한 효과가 없습니다. 어떤 실패를 발견했고 어떻게 처리했는지가 실행의 일부가 되어야 합니다.
2026년 9월 공개된 하네스 서베이의 초록도 워크플로, 메모리, 스킬, 다중 에이전트 조정 같은 요소를 함께 분류합니다. 확인한 범위는 발행처의 초록과 서지이며 논문 전문이나 비교 실험을 읽은 것으로 주장하지 않습니다. 하네스가 하나의 프롬프트를 넘어 여러 실행 조건을 다루는 용어라는 점을 보조하는 자료로 사용합니다. 하네스 서베이 공개 초록
04구성 요소를 늘린 만큼 효과와 유지 비용을 다시 평가합니다
작업을 오래 이어가야 한다고 다중 에이전트가 항상 필요한 것은 아닙니다. 역할을 나누면 각 작업에 집중할 수 있지만 인계와 결과 조정이 더해집니다. 조사 결과의 근거가 다음 역할에 전달되지 않으면 분업이 오히려 확인 부담을 늘릴 수 있습니다. 현재 업무의 실패가 분리로 줄어드는지 확인해야 합니다.
상태 기록과 검사에도 유지 비용이 있습니다. 업무가 바뀌면 오래된 기준과 도구 응답 형식을 갱신해야 하고, 모델이 바뀌면 이전에 필요했던 우회 절차가 불필요해질 수 있습니다. 환경을 갖췄다는 이유로 구성 요소를 영구적으로 유지할 필요는 없습니다.
Anthropic의 2026년 3월 하네스 설계 글은 모델 변화에 따라 기여하지 않는 구성 요소를 재평가하는 관점을 제시합니다. 가상 업무에서는 같은 사례와 성공 기준을 두고 요소 하나를 뺐을 때 어떤 실패가 다시 생기는지 비교할 수 있습니다. 품질이 유지되면 유지 비용을 줄일 후보가 되고, 특정 실패가 늘면 해당 요소가 맡던 역할을 확인할 수 있습니다. 하네스 설계와 모델 변화
처음부터 요소를 많이 넣으면 어떤 것이 도움이 됐는지 분리하기 어렵습니다. 최근 중단한 업무에서 가장 큰 실패를 골라 필요한 연결을 보완하고, 재개와 확인이 나아졌는지 관찰하는 편이 구체적입니다. 하네스의 품질은 문서와 도구 수보다 실제 인계와 복구, 결과 확인에서 드러납니다.
05마치며: 기록만 보고 다른 사람이 이어갈 수 있는지 확인합니다
최근 멈춘 AI 업무 하나를 골라 다른 사람이 기록만 보고 재개해 보게 하거나 스스로 다음 날 다시 확인해 보시길 권합니다. 목표와 기준을 알 수 있는지, 실제 파일과 확인 근거를 찾을 수 있는지, 미확인 항목과 다음 행동이 분명한지 살펴봅니다.
그 과정에서 어제의 기록과 오늘의 상태가 다르면 무엇을 다시 확인할지도 정합니다. 이 검사가 가능한 환경을 갖추는 것이 장기 작업에서 하네스가 맡는 중요한 역할입니다.
다음 편에서는 AI가 완료했다고 말한 일과 실제로 남은 결과를 어떻게 평가할지, 품질과 비용을 함께 판단하는 방법을 살펴봅니다.
이 글은 AI의 도움을 받아 작성했습니다.