퇴근 후에도 계속되는 AI 에이전트: 18시간 장기 실행 에이전트를 위한 리뷰 프로세스 설계

오후 4시에 리팩터링을 시작하고 6시에 노트북을 덮습니다. 다음 날 아침, 실행이 완료되었을 수도 있고, 여전히 진행 중일 수도 있으며, 아니면 밤 9시 40분에 질문을 던진 채 답해 줄 사람이 없어 그대로 멈춰 있었을 수도 있습니다. 전혀 다른 세 가지 상황이지만, 밤새 겉으로 보기에는 똑같아 보였습니다.

Anthropic은 Claude Opus 5.5가 18시간 이상 작업에 집중할 수 있다고 말합니다. 이 말을 있는 그대로 받아들여야 합니다. 퇴근 무렵 시작한 실행은 다음 날 출근할 때까지도 끝나지 않습니다. 자리를 비운 11시간 동안 에이전트는 계속 결정을 내려왔으며, 잘못된 결정을 막아줄 유일한 장치는 퇴근 전에 남겨둔 지침뿐입니다.

근무 시간 안에 끝나는 작업은 사람이 직접 감독할 수 있습니다. 하지만 근무 시간을 넘겨 이어지는 작업은 다음 날 다시 돌아와 확인해야 합니다. 이 둘은 완전히 다른 시스템이지만, 대부분의 팀은 여전히 전자의 방식으로 운영하고 있습니다.

TL;DR

장시간 실행되는 에이전트 작업은 사람이 자리를 비운 뒤에도 계속 이어지므로, 에이전트가 스스로 내릴 수 없는 모든 결정은 아무도 보지 않는 터미널 프롬프트가 아니라 기록된 상태(state)로 대기해야 합니다. 이를 안전하게 운영하려면 세 가지 조건이 반드시 충족되어야 합니다. 사람이 없어도 에이전트가 스스로 적용하는 중단 조건, '작업 중'이나 '실패'와 명확히 구분되는 '사람 대기(waiting-for-human)' 상태, 그리고 아침에 담당자가 확인하는 인박스(수신함)입니다. 에이전트는 조사, 실행, 테스트, 보고를 담당합니다. 사람은 방향을 설정하고 권한을 부여하며 결과를 승인합니다. Sharkly는 태스크(Task)에서 이 세 가지를 모두 관리합니다.

2026년 9월 22일, 무엇이 달라졌는가

같은 날 두 AI 연구소가 새로운 모델을 출시하면서, 작업의 실행 시간과 비용이 모두 크게 바뀌었습니다.

Anthropic에 따르면 Opus 5.5는 Opus 5에 비해 실행 비용이 40% 저렴하고, 출력 속도는 약 30% 더 빠르며, 최대 출력 토큰은 128k에 달하고 18시간 이상 작업에 집중할 수 있습니다. OpenAI는 Sol과 Luna가 각각 GPT-5.6 프로모션 가격보다 50% 저렴하다고 밝혔습니다. '프로모션'이라는 표현은 OpenAI가 직접 사용한 단어로, 정가가 아닌 할인된 요금 대비 비교한 수치입니다. 또한 OpenAI는 GPT-6의 캐시된 입력 읽기에 90% 할인이 적용되며, 추론 강도(reasoning effort)나 도구 가용성을 변경해도 더 이상 캐시가 무효화되지 않는다고 전했습니다. 이는 밤새 실행되는 작업에 특히 큰 의미를 갖습니다.

이제 작업 실행은 장시간이면서도 저렴해질 수 있게 되었습니다. 하지만 이에 맞춰 사람의 근무 시간이 늘어난 것은 아니며, 결과를 검토할 수 있는 역량이 늘어난 것도 아닙니다.

리뷰 방식의 역전

작업 실행을 직접 지켜보고 있을 때는 사람이 곧 예외 처리기(error handler) 역할을 합니다. 에이전트가 엉뚱한 파일을 열려고 하면 즉시 개입해 중단시킵니다. 이런 수정은 로그에 기록될 필요조차 없었기에 어디에도 남지 않습니다.

하지만 밤사이에는 그런 식의 개입이 불가능합니다. 사람이 개입했을 법한 모든 수정 사항은 에이전트에 미리 지정된 규칙으로 처리되거나, 아니면 작업을 멈추게 해야 합니다. 제3의 선택지는 없습니다. 장시간 실행되는 에이전트는 사람이 자리를 비운 사이 혼자 알아서 작업을 끝마친 에이전트를 뜻하는 것이 아닙니다. 여러분이 자고 있는 동안 사람이 직접 내려야 하는 결정의 순간에 직면하게 될 에이전트입니다. 따라서 '완료'가 아니라 '중단'을 기준으로 설계해야 합니다.

Anthropic은 또한 Opus 5.5에서 가드레일 우회 시도(boundary-circumvention)의 성공률이 85% 감소했다고 발표했습니다. 하지만 확률이 낮아졌다고 해서 그것이 중단 조건이 될 수는 없습니다. 지침을 벗어나도록 유도하기가 더 어려워진 모델이라 해도, 새벽 2시에 발생한 의문점을 남겨둘 곳은 여전히 필요합니다.

반드시 갖추어야 할 세 가지 조건

1. 사람 없이도 에이전트가 적용할 수 있는 중단 조건

여기에는 두 가지 축이 있습니다. 플랫폼이 강제하는 상한선(hard ceiling)과 에이전트가 스스로 적용하는 명문화된 조건입니다.

상한선은 설정값입니다. Sharkly 에이전트는 개별 실행이 아니라 에이전트 단위로 병렬 실행 태스크의 최대 개수와 태스크당 타임아웃을 설정합니다. 타임아웃은 의도한 최대 실행 시간보다는 길게, 기꺼이 비용을 감당할 수 있는 최대 실행 시간보다는 짧게 설정해야 합니다. 이는 작업 일정이 아니라 서킷 브레이커(차단기)입니다.

명문화된 조건은 많은 팀들이 간과하는 부분입니다. 결코 멈추지 않는 에이전트는 성실한 것이 아니라 방치된 것입니다.

Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.

When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.

태스크의 변경 범위가 명확하고 작업 완료 여부를 판단할 테스트가 갖추어져 있다면 타임아웃을 길게 설정하세요. 반면 태스크가 탐색적이거나, 인수 기준이 논쟁의 여지가 있는 문장 수준이거나, 검토 없이 변경되어서는 안 되는 부분을 건드릴 수 있다면 타임아웃을 한두 시간 정도로 유지하십시오. 에이전트가 스스로 확신하더라도 작업을 멈춰야 하는 시점은 승인 게이트(Approval gates)에서 다룹니다.

2. '작업 중'과 명확히 구분되는 '대기' 상태

Sharkly에서는 태스크의 수명 주기 상태(lifecycle status)와 에이전트 작업 상태(working state)를 별도로 기록합니다. 태스크가 In Progress 상태에 머물러 있는 동안에도 에이전트는 Working, Waiting for human reply, Waiting for human review, Error 등의 상태를 가질 수 있습니다. 그 아래에서 실행되는 런(run) 역시 자체적인 상태를 가집니다: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.

밤새 8개의 실행을 돌려보기 전까지는 이것이 단순한 기록 관리처럼 보일 수 있습니다. 하지만 이러한 구분이 없다면 오전 9시에 대시보드를 열었을 때 한창 수정 중인 에이전트와 질문 하나에 대한 답변을 기다리며 11시간 전에 멈춰버린 에이전트 모두 똑같이 In Progress로 표시됩니다. 결국 어느 쪽인지 확인하기 위해 8개를 일일이 열어봐야 합니다.

실행 로그는 다음 날 아침 작업 중단 사유를 명확히 파악할 수 있게 해줍니다. 실행이 대기열에 추가된 이유, 시작 및 종료 시점, 도구 호출과 런타임 이벤트, 트리거 소스, 실패나 취소 관련 세부 사항 등이 여기에 포함됩니다. 이는 전날 자신이 무엇을 요청했는지 기억이 나지 않는 상태에서도 차분히 읽고 파악할 수 있는 정보입니다. 이를 직접 구축하고자 할 때 무엇을 수집해야 하는지는 상태, 로그, 실패 신호를 참조하세요.

3. 명확한 담당자 한 명이 확인하는 인박스

담당자가 지정되지 않은 대기 상태는 영원히 대기할 뿐입니다. 침묵을 알아차릴 사람이 아무도 없기 때문에, 밤샘 실행은 낮 시간대의 실행과 달리 조용히 실패합니다.

Sharkly의 Inbox는 태스크 활동을 모아 보여주는 개인화된 대기열이며, Primary 탭에는 사람의 개입이 필요한 신호들이 모입니다. 사용자의 답변 대기, 검토 대기, 실패하거나 차단된 작업, 직접 멘션, 사용자에게 할당된 작업 등이 이에 해당합니다. 실행 실패 및 차단 신호는 모든 구독자에게 무작위로 전송되는 대신 담당자에게 전달되므로, 새벽 3시의 실행 실패는 모두에게 전송되어 결국 아무도 확인하지 않는 상황 없이 반드시 특정 담당자에게 도달합니다.

아침 업무는 저장된 두 개의 뷰(View)가 이끌어갑니다. 바로 검토 대기 중인 태스크와 에이전트에 할당되었으나 현재 차단된 태스크입니다. 이 뷰들을 확인할 담당자를 반드시 지정하십시오. '팀 전체'라는 이름으로는 아무도 인박스를 열어보지 않습니다.

아침 검토 절차

순서가 중요하며, 대시보드가 보여주는 순서와는 다릅니다.

1. 가장 먼저 사람 답변 대기(Waiting for human reply) 확인: 질문에 답변하면 멈춰 있던 에이전트가 다시 작동하지만, 검토는 아무것도 새로 시작시키지 못합니다. SH-312 태스크가 밤 9시 40분부터 대기 중이었다면, 댓글로 답변하는 것이 하루 중 취할 수 있는 가장 빠른 조치입니다. 댓글을 달면 동일한 태스크에서 후속 실행이 대기열에 등록됩니다.
2. 두 번째로 실패 및 차단(Failed and blocked) 확인: 재시도하기 전에 실행 로그 제목과 기술적 세부 정보를 먼저 읽으십시오. 단일 HTTP 상태 코드는 단서일 뿐, 진단 결과가 아닙니다.
3. 세 번째로 검토 대기(Waiting for review) 확인: 이것이 진짜 처리해야 할 대기열이며, 실행 비용이 저렴해질수록 가장 빠르게 늘어나는 항목입니다.
4. 마지막으로 여전히 실행 중(Still running)인 작업 확인: 계속 진행되도록 두거나 취소하십시오. 취소된 실행은 그 자리에서 바로 재개되지 않지만, 태스크와 실행 기록은 그대로 유지되므로 방향이 잘못되었다면 주저 없이 취소해도 됩니다. 다만 취소 전에 로그를 먼저 확인하십시오.

이것으로 해결되지 않는 문제

실행 시간이 길어진다고 해서 검토 부담이 줄어들지는 않습니다. 오히려 한곳으로 집중될 뿐입니다. 18시간 동안 실행된 결과물에는 밤새 내린 수많은 결정들이 담겨 있으며, 사람은 여전히 이를 읽고 판단하고 승인해야 합니다. OpenAI 자체 연구진의 사례는 이것이 어떤 결과를 낳는지 잘 보여줍니다. 연구원 중간값 기준 API 비용으로 하루 600달러 이상의 추론을 실행하며 상위 10%(90번째 백분위수)는 하루 7,000달러를 넘지만, 그 출력물을 읽을 수 있는 사람의 수는 그대로입니다. OpenAI가 이 수치를 발표했을 때 당사 블로그에서 직접 계산해 본 바 있지만, 이번 모델 출시에서도 이 분모(검토할 사람의 수)는 전혀 변하지 않았습니다.

더 저렴하고 길어진 실행 시간이 가져다주는 것은 내려야 할 결정의 감소가 아니라, 더 많은 병렬 시도입니다. 사람의 검토가 곧 병목이며, 가격 인하는 상황을 개선하기 전에 이 병목을 더욱 악화시킵니다. 자동화는 팀의 판단이 필요한 지점에서 멈춰야 하며, 멈출 때는 온전한 맥락과 검증 가능한 근거를 갖춘 결과물을 전달해야 합니다.

FAQ

18시간 동안 작업이 가능한 모델의 경우 태스크당 타임아웃을 얼마나 길게 설정해야 하나요? 원하는 실행 시간보다는 길게, 비용 면에서 후회할 법한 시간보다는 짧게 설정하십시오. 일반적인 작업은 몇 시간 정도로 시작하고, 밤샘 작업이 진정으로 필요한 태스크에 대해서는 에이전트별로 타임아웃을 늘리십시오. 타임아웃은 루프에 빠진 실행을 강제 종료하기 위한 장치일 뿐, 완성도 높은 작업에 걸리는 시간을 결정하는 수단이 아닙니다.

에이전트가 새벽 2시에 질문을 던지면 어떻게 되나요? 터미널 스크롤백 버퍼의 한 줄로 남아서는 안 되며, 사람 답변 대기(waiting-for-human-reply) 상태로 전환되어 담당자의 인박스(Inbox) 항목으로 들어가야 합니다. 현재 환경에서 이를 놓칠 위험이 있다면, 타임아웃을 늘리기 전에 이 문제부터 먼저 해결하십시오.

결론: 무엇을 해야 하는가

어떤 벤더도 여기서 정작 중요한 부분을 기본 제공하지는 않습니다. 중요한 것은 중단이 어디에 기록되고 다음 날 아침을 누가 책임지느냐이기 때문입니다. 이 문제는 Claude Code든 Codex든 다른 어떤 도구든 마찬가지이며, 오너십이 특정 벤더의 세션 내부가 아니라 태스크 수준에 속해야 하는 이유가 바로 여기에 있습니다.

이미 야간에 에이전트를 가동하고 있다면 테스트 방법은 간단합니다. 오전 9시에 대시보드를 열고, 여전히 작업 중인 에이전트와 어젯밤부터 기다리고 있는 에이전트를 구분해 보여주는지 확인해 보십시오. 구분되지 않는다면 그것이 가장 먼저 해결해야 할 과제이며, 바로 이 지점이 Sharkly가 동작하는 레이어입니다. 요청부터 릴리스까지, 태스크는 목표, 실행 상태, 차단 요소, 결과, 그리고 사람의 결정을 모두 담아냅니다.