점심 전에 세 개의 실행(런)을 디스패치했습니다. 90초 후, 세 개의 터미널 중 두 개는 아무것도 출력하지 않았습니다. 그중 하나는 리포지토리를 추론하는 중입니다. 다른 하나는 나가는 길에 504를 맞고 다시는 돌아오지 않을 겁니다. 당신이 앉아 있는 자리에서 보기에는, 둘 다 커서만 깜빡이는 똑같은 스크롤백 사각형일 뿐입니다.
이건 새로운 문제가 아니지만, 2026-09-22에 공개된 모델들은 특정하고 측정 가능한 방식으로 이 문제를 악화시켰습니다. 새 모델들의 최고 추론 설정은 무언가를 말하기 전에 오랫동안 생각함으로써 정확도를 얻습니다. Artificial Analysis는 GPT-6 Sol의 "max" 추론 변형이 첫 토큰까지 102.15초, GPT-6 Luna가 124.23초를 기록했다고 측정했습니다. 이는 특정 구성에 대한 제3자 측정치이며 벤더가 제공한 수치가 아니라는 점, 그리고 그 단서는 중요합니다. 하지만 방향성은 의심의 여지가 없습니다. 실행 시작 시점의 정적은 이제 실패와 구분할 수 없을 만큼 길어졌습니다.
TL;DR
첫 토큰까지의 시간은 요청을 보낸 시점과 응답의 첫 문자가 도착한 시점 사이의 지연이며, 고강도 추론 모델에서는 이 지연이 대부분의 사고가 일어나는 곳입니다. 터미널은 생각 중인 실행, 사람을 기다리는 실행, 2분 전에 죽은 실행을 구분해서 알려주지 못합니다. 셋 다 아무것도 출력하지 않기 때문입니다. 상태(status)라면 구분할 수 있습니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 받아들입니다. 이 계약이 작동하려면 누군가 지켜보지 않아도 보이는 실행 상태가 필요합니다. Sharkly는 요청부터 릴리스까지 컨텍스트, 진행 상황, 블로커, 결과, 사람의 리뷰를 Task에 유지하므로, 긴 사고와 죽은 실행이 더 이상 비슷해 보이지 않습니다.
대기는 길어졌고, 저렴한 모델이 빠른 모델이 아니다
두 신형 GPT-6 모델을 최대 추론 설정으로 돌렸을 때 제3자 측정치가 말하는 내용은 다음과 같습니다.
| 모델 | API id | 출력 속도 | 첫 토큰까지의 시간 | 100만 토큰당 입력 / 출력 |
|---|---|---|---|---|
| GPT-6 Sol (max) | gpt-6-sol |
115.2 tokens/s | 102.15s | $2 / $10 |
| GPT-6 Luna (max) | gpt-6-luna |
153.9 tokens/s | 124.23s | $0.10 / $0.50 |
마지막 두 열을 함께 읽어보세요. Luna는 토큰당 비용이 Sol의 20분의 1인데도 말을 꺼내기까지 더 오래 기다리게 합니다. 비용과 지연은 별개의 축이며, 저렴한 모델이 더 빠릿한 모델이라는 직관은 여기서는 그냥 틀렸습니다.
누군가 이 수치를 바탕으로 대시보드를 만들기 전에 두 가지 솔직한 단서를 달아둡니다. 첫째, 이 수치는 OpenAI가 아니라 Artificial Analysis에서 나온 것이고, 특히 "max" 추론 변형을 설명합니다. 더 낮은 effort 설정은 완전히 다른 존재이고, 여러분 자신의 수치는 프롬프트 크기, 도구 사용 가능 여부, 트래픽이 도착하는 위치에 따라 달라질 것입니다. 둘째, 첫 토큰까지의 시간은 출력 속도와 같은 측정이 아닙니다. Anthropic은 Claude Opus 5.5가 Opus 5보다 약 30% 빠르게 출력을 생성한다고 밝히는데, 이는 첫 토큰 이후의 토큰에 대한 이야기입니다. 모델이 빠르게 스트리밍하면서도 1분 30초 동안 아무것도 없는 화면을 뚫어지게 보게 만들 수 있습니다.
조용한 터미널은 상태가 아니다
터미널에서의 침묵에는 최소 네 가지 원인이 있으며, 터미널은 이 모두를 동일하게 렌더링합니다:
- 런타임이 작업 중입니다. 추론이 진행 중이고 아직 출력이 없습니다.
- 실행이 한참 전에 끝났고 사람이 질문에 답하기를 기다리는 중입니다.
- 요청이 실패했습니다. Sharkly 문서는 이것이 얼마나 쉽게 오독될 수 있는지에 대해 단호합니다: "Timeout / 408 / 504는 요청이 느렸거나, 취소되었거나, 게이트웨이에 의해 지연되었음을 의미합니다. 이는 Computer가 오프라인인 것과 같은 것이 아닙니다."
- Computer가 정말 사라졌거나, 실행에 필요했던 디렉토리가 결코 비지 않았습니다.
에이전트 하나, 터미널 하나라면 1분만 더 기다리면 해결됩니다. 세 개의 리포지토리와 두 개의 Computer에 걸쳐 다섯 개의 에이전트가 있다면, 창 사이를 탭으로 오가며 추측하는 것으로 해결하게 됩니다. 이것이 에이전트 혼돈의 평범한 모습입니다: 극적인 실패가 아니라, 한 팀이 한 시간에 여러 번 "이거 살아 있나?"라는 질문에 주의를 쏟는 것입니다.
사람들이 본능적으로 하는 행동은 죽이고 다시 실행하는 것입니다. 높은 추론 effort에서는 이 본능이 두 배로 비쌉니다. 첫 토큰 대기 시간을 통째로 다시 지불하고, 막 도착하려던 사고를 버리게 됩니다.
상태가 분리해야 할 것
Sharkly 자체의 모델은 Sharkly를 쓰든 안 쓰든 따라 할 가치가 있습니다. 왜냐하면 터미널이 하나로 융합하는 두 가지를 분리하기 때문입니다. 이는 실행 상태, 로그, 실패 신호를 애초에 읽을 수 있게 만드는 바로 그 분할이기도 합니다. 실행에는 실행 상태(execution state)가 있습니다: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled. Task에는 수명 주기 상태가 있고, 그 위에 Agent의 작업 상태가 있습니다: Working, Waiting for human reply, Waiting for human review, Error. 문서는 이 경계를 명확히 밝힙니다: 이 실행 상태들은 "Task가 동일한 워크플로 상태를 가진다고 자동으로 암시하지 않습니다."
이 분할이 바로 멈춘 건지 생각 중인 건지에 대한 질문의 전체 답입니다.
| 터미널이 보여주는 것 | 실제로는 무엇일 수 있는지 | 둘을 구분해주는 것 | 다음에 누가 행동하는가 |
|---|---|---|---|
| 아무것도 없음, 100초 경과 | Running, 첫 토큰 이전 | 실행 상태가 Running, 로그에 디스패치 타임스탬프가 있음 | 아무도. 그냥 놔둠. |
| 아무것도 없음, 10분 경과 | 사람의 답변을 기다리는 중 | 작업 상태가 변경됨, Task가 Inbox에 주의 항목을 올림 | 담당자가 컨텍스트 안에서 답변 |
| 아무것도 없음, 영원히 | Failed | 실행 상태가 Failed, 실행 로그에 제목과 원래 모델 서비스 응답이 담김 | 담당자가 재시도 전에 로그 확인 |
| 아무것도 없음, 시작조차 안 됨 | Queued 혹은 Waiting for local directory | 실행 상태, 그리고 어떤 디렉토리 풀이 바쁜지 | 디렉토리를 비우거나 병렬 용량을 늘림 |
이 네 행 중 어느 것도 상태가 바뀌는 순간 누군가 지켜보고 있을 필요가 없습니다. 그게 핵심입니다. 상태는 기록되고, "생각 중인가 멈춘 건가?"라는 질문은 앉아서 견뎌야 하는 것이 아니라 찾아볼 수 있는 것이 됩니다.
3월에 설정한 Task별 타임아웃
Sharkly의 Agent는 최대 병렬 실행 Task 수와 Task별 타임아웃을 가집니다. 대부분의 팀은 이 타임아웃을 초기에 한 번, 터미널을 얼마나 오래 뚫어지게 볼 의향이 있는지를 기준으로 설정합니다. 그 숫자가 2분인데 그 이후에 Agent를 max 추론 설정으로 옮겼다면, 생각 단계에서 실행을 취소하고 실패로 보고하는 정책을 구성한 셈입니다.
이번 주에 여러분의 설정을 확인해 보세요. 하한선은 "내가 얼마나 오래 기다릴 의향이 있는가"가 아니라, "내가 실제로 사용하는 effort 수준에서 이 Runtime이 얼마나 걸리는가, 거기에 작업 자체까지 더하면"입니다. 첫 토큰 하나에만 100초 이상 걸릴 수 있는 실행에서 5분 미만의 타임아웃은 정책으로 위장한 동전 던지기입니다.
같은 점검 대상으로 볼 만한 두 가지 관련 설정이 있습니다. 최대 병렬 실행 Task 수는 여러분의 실제 동시성 한도이고, 구성된 모든 디렉토리가 바빠지면 새 실행은 실패하는 대신 Waiting for local directory에 머무릅니다. 이는 올바른 동작이지만, 터미널만 보고 있다면 멈춘 것처럼 보입니다.
캐싱이 이걸 해결해줄까?
부분적으로요, 그리고 여러분이 원하는 그 부분은 아닙니다. GPT-6용 OpenAI의 프롬프트 캐싱은 캐시된 입력 읽기에 90% 할인을 제공하고 기본적으로 더 높은 적중률을 보이며, 명시적 중단점을 추가해 캐시된 프리픽스가 어디서 끝날지 선택할 수 있게 하고, 추론 effort나 도구 사용 가능 여부를 변경해도 더 이상 캐시를 깨뜨리지 않습니다. GitHub는 수십억 건의 요청에서 새로 처리해야 하는 프롬프트 토큰이 50% 이상 줄었다고 보고합니다. 이는 프롬프트에 대한 실질적인 비용 및 지연 개선이며, effort 변경 관련 수정은 작업 도중에 저렴한 설정에서 비싼 설정으로 에스컬레이션하는 에이전트에게 진짜로 유용합니다.
하지만 추론 패스 자체를 없애주지는 않습니다. 캐시가 따뜻하다는 것은 여러분의 프롬프트 중 처음부터 처리되는 부분이 줄어든다는 뜻입니다. 모델이 이미 여러분의 버그에 대해 생각해 뒀다는 뜻은 아닙니다. 어차피 대기 시간은 예산에 넣어두세요.
언제 대기를 지불하고, 언제 지불하지 말아야 하는가
다시 돌리고 싶지 않은 작업에는 최대 추론 설정을 사용하세요: 마이그레이션, 횡단 관심사 리팩터링, 잘못된 답이 90초보다 더 비싼 모든 작업 말입니다. OpenAI는 Sol이 xhigh 설정에서 AutomationBench 1.0.6에서 33.2%를 기록했고 과제당 비용이 $0.27이라고 보고하는데, 이것이 바로 그 트레이드의 형태입니다. 정확도는 이제 돈으로는 저렴하고 실시간으로는 비쌉니다.
사람이 답을 기다리며 앉아 있을 때는 더 낮은 effort 설정을 사용하세요. 대화형 작업, 파일에 대한 빠른 질문, 작은 범위가 한정된 수정: 낮은 effort에서는 침묵 문제가 대부분 사라집니다. 질문한 내용을 아직 기억하고 있을 때 첫 토큰이 나타나기 때문입니다.
그리고 솔직한 경계선: 하나의 Task에 하나의 에이전트를 돌리고 있다면, 이걸 위한 보드는 필요 없습니다. 로그를 tail 하세요. 상태 문제는 실행 수가 의미 있게 지켜볼 수 있는 터미널 수를 넘어서는 시점부터 시작하는데, 대부분의 사람에게는 약 세 개 정도입니다.
이것이 해결하지 못하는 것
상태는 실행이 Working이라고 알려줍니다. 실행이 유용한 일을 하고 있다고는 알려주지 않으며, 자신 있게 틀린 에이전트는 실행이 지속되는 동안 좋은 에이전트와 똑같은 초록색 상태를 보여줍니다. Opus 5.5에서는 그것이 18시간 이상일 수 있습니다. "실행 중"과 "잘 실행 중"을 구분하는 것은 여전히 리뷰 문제이고, 리뷰는 여전히 사람의 일입니다. 자동화는 팀의 판단이 필요한 지점에서 멈춥니다.
이미 여러 에이전트를 동시에 돌리고 있다면, 이번 주에 할 수 있는 가장 작은 유용한 변화는 새 모델이 아닙니다. 터미널을 열지 않고도 모든 실행의 상태를 읽을 수 있게 만드는 것입니다. 그러면 다음 90초의 침묵이 질문이 아니라 정보가 됩니다.
