인간 근무일당 3.1 에이전트 근무일: 아무도 하지 않는 리뷰 처리 역량 계산

OpenAI가 이번 주에 공개한 숫자 하나는 그 옆에 붙은 달러 금액보다 더 눈여겨볼 가치가 있습니다. 8월 중순 기준으로 OpenAI의 연구 조직은 사람이 일하는 하루당 3.1 에이전트 근무일(agent-workday) 분량의 작업을 소화합니다. 인용된 문장은 지출이었습니다. 중간값에 해당하는 연구원은 API 가격 기준으로 하루 600달러가 넘는 추론 비용을 씁니다. 하지만 팀을 운영하는 사람에게 중요한 문장은 나머지 하나입니다.

사람 하루당 에이전트 3일이라는 말은, 이제 사람의 하루가 병목이라는 뜻입니다. 에이전트가 만들어낸 모든 결과는 누군가가 읽고 판단하고 승인해야 하는데, 그 누군가에게 주어진 것은 세 개의 근무일이 아니라 단 하나의 근무일뿐입니다. 이 글에서는 그 계산을 직접 해보고, 대기열이 어디에서 생기는지 보여드립니다.

핵심 요약

OpenAI의 "Research acceleration" 글은 에이전트 작업량이 사람 근무일당 3.1 근무일에 달한다고 밝히고, 연구원들이 한 번에 네 개 이상의 에이전트를 돌리는 추세를 언급하며, 성공한 4~8시간짜리 작업의 절반 이상이 최소 한 번의 사람 개입을 필요로 했다고 보고합니다. 이를 종합하면, 하루 업무 시간 안에는 에이전트가 멈춰서 사람을 기다리는 순간이 여러 번 있고, 승인을 기다리는 완료된 작업이 끊임없이 쌓입니다. 가득 차는 대기열은 '사람을 기다리는 결과물'이며, 대부분의 도구는 이를 보여주지 않습니다. Sharkly는 이 대기열을 명시적으로 드러냅니다. Task의 대기 상태, 해당 상태를 담당자에게 라우팅하는 Inbox, 그리고 기록된 상태 변경으로서의 승인입니다.

숫자로 보기

아래 내용은 별도 표시가 없는 한 모두 OpenAI의 글에서 가져왔습니다.

같은 글을 읽은 Simon Willison은 곡선의 모양을 덧붙입니다. 연구원 1인당 지출은 2월의 거의 0달러에서 8월 말 약 600달러로 늘었고, 7월과 8월 사이에는 가파른 상승이 있었는데, 그는 이것이 나중에 GPT-6 Astra로 출시된 모델에 대한 내부 접근과 시기가 맞물린다고 추측합니다.

이 수치들은 제품을 출시하는 코딩 팀에 관한 것이 아니고, OpenAI의 연구원들도 일반적인 집단이 아닙니다. 그러나 이 비율은 다른 곳에도 적용됩니다. 터미널 하나에서 에이전트 하나를 쓰다가 동시에 여러 에이전트를 돌리는 단계로 넘어간 팀이라면, 누구든 몇 달 뒤처진 같은 곡선 위에 있습니다.

계산해 보기

이 비율을 액면 그대로 받아들여 봅시다. 사람의 8시간 근무일 동안 에이전트는 대략 25시간 분량의 작업을 만들어냅니다. 그 전부가 사람을 필요로 하는 것은 아닙니다. 어떤 실행은 실패하고, 어떤 것은 탐색용이며, 어떤 것은 다른 에이전트에게 입력으로 들어갑니다. 하지만 누군가 실제로 배포할 변경으로 끝나는 모든 실행에는 사람의 결정이 필요하고, 개입 관련 수치는 그 결정이 종종 실행이 끝나기 전에 필요해진다는 것을 보여줍니다.

길고 성공적인 작업의 절반 이상이 최소 한 번의 개입을 필요로 했다면, 에이전트 네 개가 돌아가는 상황에서 한 사람은 작업 하나가 진행되는 동안 두세 개의 에이전트로부터, 그것도 자신이 선택하지 않은 시점에 방해를 받을 각오를 해야 합니다. 이런 방해는 실패가 아닙니다. 멈춰서 물어보는 에이전트가 추측해서 배포해버리는 에이전트보다 낫습니다. 문제는 그 질문이 어디에 도착하느냐입니다.

터미널에 도착한 질문은 누군가 우연히 그 터미널을 볼 때에야 답이 달립니다. 터미널에 도착한 결과는 누군가 그것이 존재한다는 사실을 기억할 때에야 검토됩니다. 여기에 에이전트 네 개와 사람 하루당 에이전트 3일을 곱해보면, 터미널은 작업이 기다리기 위해 머무는 곳이 됩니다.

아무도 대시보드에 올리지 않는 대기열

에이전트를 운영하는 모든 팀에는 두 개의 대기열이 있습니다. 첫 번째는 에이전트를 기다리는 작업입니다. 팀이 사용하는 트래커에 보이는 백로그죠. 두 번째는 사람을 기다리는 작업입니다. 승인할 결과물, 답해야 할 질문, 분류해야 할 실패입니다. 3.1 대 1의 비율로 늘어나는 것은 두 번째 대기열이며, 대부분의 도구가 보여주지 않는 것도 바로 이 대기열입니다.

Sharkly는 이 대기열을 핵심 대상으로 다룹니다. Task는 작업의 기본 단위이며, Task 상태와 Agent 작업 상태는 분리되어 관리됩니다. Started 상태의 Task는 Working, Waiting for human reply, Waiting for human review, Error 중 하나를 표시할 수 있습니다. 대기 상태는 로그가 조용하다는 이유로 짐작하는 것이 아니라, 그 자체로 명시적으로 표현됩니다.

이 상태들은 어딘가로 라우팅됩니다. Inbox는 개인별 작업 활동 대기열이며, Primary 섹션에는 주의가 필요한 활성 신호가 있는 Task가 담깁니다. 답장 대기, 검토 대기, 실패 또는 차단된 작업, 직접 멘션, 본인에게 할당된 작업 등입니다. 활동을 Task 단위로 묶기 때문에, 하나의 Task에 대해 네 개의 에이전트가 보고해도 네 개의 알림이 아니라 한 개의 행으로 표시됩니다. Slack은 선택적으로 사용할 수 있는 외부 알림 채널이며, Slack에서 그룹을 음소거해도 Inbox 기록은 삭제되지 않습니다.

답장이 곧 작업이 이어지는 방식입니다. 할당된 Agent가 준비된 Task에 댓글을 달면 해당 스레드를 컨텍스트로 후속 실행을 시작할 수 있으므로, 질문에 답하는 것이 작업을 처음부터 다시 시작하는 대신 이어서 진행하게 합니다.

이 비율에서 승인이란 어떤 모습인가

사람 한 명당 에이전트 하나라면 검토는 형식 없이 이뤄져도 됩니다. 사람 하루당 에이전트 3일이라면 그럴 수 없습니다. 검토하는 사람이 실행을 시작한 사람이 아닐 테고, 실행은 몇 시간 전에 이미 끝났을 수도 있기 때문입니다.

Sharkly에서 승인이란 사람이 증거를 확인한 뒤 Task 상태를 바꾸는 것입니다. Agent의 최종 응답은 Task에 저장됩니다. 실행 로그에는 실행이 대기열에 들어간 이유, 시작 및 종료 시각, 도구 호출, Runtime 이벤트, 실패 세부 정보가 기록되며, 이는 댓글 타임라인과 분리된 Executions 탭에 표시됩니다. 요약을 읽고, 그다음 로그를, 그다음 diff를 읽으세요. 연결된 pull request를 병합해도 Task 상태는 바뀌지 않으므로, 병합이 결정으로 오인되는 일은 없습니다. human-in-the-loop 리뷰 워크플로에서 다섯 개의 게이트를 순서대로 설명합니다.

OpenAI의 글에 대한 Hacker News 논의는 이와 관련된 우려에 집중했습니다. 즉, 에이전트 분류기가 결과를 채점하는데, 측정되는 대상과 그것을 평가하는 주체가 같은 곳에서 나온다는 점입니다. 이는 제품 팀의 문제를 연구 버전으로 옮긴 것입니다. 에이전트가 사람이 읽을 수 있는 양보다 더 많이 만들어낼 때, 사람이 무엇을 읽어야 할지를 에이전트가 정하게 하고 싶은 유혹이 생깁니다. 사람이 담당하는 가시적인 대기열이 그 대안입니다.

사람의 하루를 어디에 써야 할까

사람의 하루는 방향 설정과 승인에 사용하세요. 티켓을 다듬고, 권한을 부여하고, 증거를 읽고, 병합과 릴리스를 결정하는 일입니다. 실행, 테스트, 보고는 에이전트에게 맡기세요. 에이전트는 조사하고 실행하고 테스트하고 보고합니다. 사람은 방향을 정하고 권한을 부여하고 결과를 승인합니다. OpenAI 글에 나온 비율은 이 계약이 제대로 작동할 때의 모습입니다.

사람의 하루를 감독에 쓰는 것은 작업이 실제로 실시간으로 지켜볼 사람을 필요로 할 때만 하세요. 롤백이 없는 프로덕션 변경이나, 다른 작업이 의존하는 디렉터리에서의 실행 같은 경우입니다. Sharkly는 작업을 수행하는 Claude Code, Codex, 또는 Runtime을 대체하는 것이 아닙니다. Sharkly는 요청부터 릴리스까지 컨텍스트, 진행 상황, 블로커, 결과, 사람의 검토를 계속 가시적으로 유지해주는 계층으로, 사람의 하루가 어느 터미널에 질문이 들어 있는지 찾아 헤매는 데 쓰이지 않고 결정에 쓰이게 합니다.

자주 묻는 질문

3.1이라는 수치는 어디서 나온 것인가요? OpenAI의 글 "Research acceleration: the view inside OpenAI"에서 나온 것으로, 8월 중순 기준 연구 조직이 사람 근무일당 3.1 에이전트 근무일의 작업량을 사용한다고 밝히고 있습니다.

이것이 제품 엔지니어링 팀에도 적용되나요? 구체적인 수치는 연구 조직에서 나온 것입니다. 하지만 비율이 가리키는 방향은 에이전트 하나에서 여러 개로 넘어가는 모든 팀에 적용됩니다. 에이전트의 산출물이 그것을 검토할 수 있는 역량보다 빠르게 늘어나기 때문입니다.

개입 관련 수치는 무엇인가요? 2026년 1월부터 7월 사이 성공한 4~8시간 작업 중 절반 이상이 한 번 이상의 사람 개입을 동반했습니다. 긴 실행은 사람이 개입해야 성공하며, 개입 없이 성공하지는 않습니다.

Sharkly는 검토 대기열을 어떻게 보여주나요? Waiting for human reply와 Waiting for human review는 Task의 Agent 작업 상태이며, 담당자의 Inbox Primary 섹션으로 라우팅됩니다. 실패하거나 차단된 작업도 그곳에 표시됩니다.

무엇이 승인으로 간주되나요? 사람이 Agent의 응답, 실행 로그, diff를 확인한 뒤 Task 상태를 바꾸는 것입니다. 병합된 pull request만으로는 상태가 바뀌지 않습니다.

짧게 요약하면

OpenAI의 비율은 에이전트가 이미 사람의 하루당 사흘 분량의 작업을 만들어내고 있다고 말하며, 개입 관련 수치는 대부분의 긴 작업에서 사람이 루프 안에 있다는 것을 보여줍니다. 희소한 자원은 사람의 하루이며, 가득 차는 대기열은 사람을 기다리는 결과물입니다. 그 대기열을 가시적으로 만들고, 담당자에게 라우팅하고, 결정을 기록하세요. Computer 하나를 연결하고, Agent 하나를 만들고, 지루한 일 하나를 맡겨보세요. 각 개념에 대한 더 자세한 설명은 문서에서 확인할 수 있습니다: docs.sharkly.ai.