Sharkly에서 GPT-6 Sol 에이전트 실행하는 방법

OpenAI는 9월 22일 GPT-6 Sol을 공개했습니다. 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러이며 API id는 gpt-6-sol, 컨텍스트 윈도우는 872k입니다. 여러분의 보드를 바꿔 놓아야 할 숫자는 토큰 단가가 아닙니다. 바로 완료된 작업당 비용입니다. OpenAI의 AutomationBench 1.0.6 결과에서 xhigh 추론 강도의 Sol은 작업당 0.27달러로 33.2%를 기록한 반면, max 강도의 Claude Opus 5는 작업당 비용이 Sol의 11.1배인데도 26.9%에 그쳤습니다.

이 수치를 순위표가 아니라 예산 명세서로 읽어야 합니다. 전체 실행 비용이 비싸서 에이전트 실행 횟수를 아껴 왔다면, 그 제약은 방금 옮겨갔습니다. 다음 제약은 돈으로 해결할 수 없는 것입니다. 사람이 여전히 diff를 읽고 작업을 승인해야 한다는 점입니다. 이 가이드는 설정을 위한 가장 작고 유용한 경로를 안내하고, 가격 인하로도 해결되지 않는 부분은 솔직하게 짚습니다. 하나의 Computer에서 Codex에 Sol을 설정하고, Agent 하나를 만들고, 실제 Task 하나를 할당하세요.

TL;DR

연결된 Computer의 Codex에서 model = "gpt-6-sol"을 설정하고, Sharkly에서 Codex Runtime이 Available로 표시되는지 확인하고, Agent의 작업 디렉터리는 Temporary 모드로 두고, 첫 장시간 실행을 신뢰하기 전에 Task당 타임아웃을 늘린 다음, Task 하나를 할당하세요. Sharkly는 모델 이름을 표시하지 않습니다. 대신 실행, 로그, 질문, 그리고 Task의 결과를 보여줍니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다.

모델 설정은 어디에 있는가

Sharkly는 모델을 직접 고르지 않습니다. Agents 문서에도 분명히 나와 있습니다. "Agent는 Runtime의 기본 모델을 따릅니다. 특정 모델 이름을 보장하거나 표시하지 않습니다. 모델은 Agent가 아니라 Runtime이나 Computer 도구 설정에서 변경하세요."

Agent에는 모델 드롭다운도, 사고 깊이 조절 기능도 없으니 찾아 헤매지 마세요. 네 가지 역할이 있고 각자 할 일이 하나씩입니다. Agent는 작업을 어떻게 처리할지 정의합니다. Computer는 호스트와 로컬 리소스를 제공합니다. Runtime은 실제 에이전트 세션을 수행하며, 여기서는 Codex가 Runtime입니다. Task는 팀을 위한 공유 기록으로 남습니다.

1단계: Computer의 Codex에 GPT-6 Sol 설정하기

실행을 담당할 Computer에서 Codex를 업데이트하고, Sol 접근 권한이 있는 계정이나 API 키로 로그인하세요. OpenAI는 Sol을 ChatGPT Work와 Plus, Pro, Business, Enterprise, Edu 플랜의 Codex에서 사용할 수 있게 했으며, 아직 Chat에는 없습니다. 해당 호스트의 일반 터미널에서 codex -m gpt-6-sol로 세션이 시작된다면 Sharkly에서도 사용할 수 있습니다.

그런 다음 이 Computer의 모든 실행이 이를 사용하도록 기본값을 설정하세요:

# ~/.codex/config.toml
model = "gpt-6-sol"
model_provider = "openai"
model_reasoning_effort = "xhigh"

이 스니펫에는 주의할 점이 두 가지 있습니다. 추론 강도(reasoning effort) 키 이름은 Codex 버전마다 다르므로, 해당 Computer에 설치된 Codex 빌드의 샘플 구성과 대조해 확인하세요. 그리고 강도 수준은 비용 결정이지, 항상 최대로 둬야 하는 품질 다이얼이 아닙니다. OpenAI가 공개한 결과에서도 벤치마크마다 서로 다른 강도 수준을 사용했고, 위의 작업당 0.27달러 수치는 xhigh 행입니다. [VERIFY]

다시 Sharkly로 돌아와 Computer 상세를 열고 재검사(rescan) 또는 연결 테스트를 실행하세요. Codex Runtime이 Available로 표시되어야 합니다. Computer가 online으로 표시되는 것은 로컬 서비스가 하트비트를 보내고 있다는 뜻일 뿐입니다. 실행을 시작할 수 있는지는 Runtime 기능 상태가 알려줍니다.

2단계: Crew를 늘리기 전에 캐시부터 설정하기

같은 저장소에서 둘 이상의 Agent가 작업하기 시작하면 가장 중요해지는 GPT-6 변경 사항이며, 대부분의 팀이 건너뛰게 될 부분이기도 합니다.

OpenAI에 따르면 GPT-6는 기본 캐시 적중률이 더 높고, 캐시된 입력 읽기에 90% 할인이 적용되며, 프롬프트 캐싱 대시보드와 진단 도구를 제공합니다. 에이전트 작업에서 특히 중요한 점은 추론 강도나 도구 가용성을 바꿔도 더 이상 캐시가 무효화되지 않는다는 것입니다. 명시적 브레이크포인트를 사용하면 캐시된 프리픽스가 어디서 끝나는지 직접 정할 수 있습니다. OpenAI는 GitHub가 수십억 건의 요청에서 새로 처리해야 하는 프롬프트 토큰을 50% 이상 줄였다고 언급했습니다.

Crew 관점에서 실질적인 형태는 이렇습니다. 같은 저장소에 대한 모든 Agent 실행은 크고 거의 동일한 프리픽스를 다시 전송합니다. 저장소 구조, 사내 규칙, 테스트 명령, 관례 등입니다. 이 프리픽스야말로 캐시가 존재하는 이유이며, 여러 에이전트를 굴려도 실행당 비용이 첫 에이전트 때보다 훨씬 낮아질 수 있는 이유입니다.

공짜 작업이 아니니 판단 기준을 두 가지로 나눠 봅시다. 여러 Agent가 하나의 코드베이스를 상대로 반복 실행하고 Skill과 지침 텍스트가 이미 확정되어 있다면, 안정적인 프리픽스를 고정하고 명시적 브레이크포인트를 설정하세요. 반대로 Agent가 일주일에 몇 번만 실행되거나 지침이 매주 바뀌고 있다면 굳이 할 필요가 없습니다. 경계를 유지하는 데 드는 시간이 절약되는 시간보다 더 크기 때문입니다.

3단계: 느리게 시작하는 실행에 맞춰 Agent 구성하기

Agents를 열고 New Agent를 선택한 뒤 Computer와 Codex Runtime을 고르고, 세 가지를 설정하세요.

Task당 타임아웃. 이건 의도적으로 설정하세요. 높은 추론 모드에서의 Sol 실행은 바쁘게 보이기 전에 죽은 것처럼 보일 수 있습니다. 어느 벤더도 아닌 제3자인 Artificial Analysis는 GPT-6 Sol의 max 추론 변형이 첫 토큰까지 102.15초가 걸린다고 측정했습니다. 이는 대부분의 사람이 뭔가 멈췄다고 생각하기 전까지 기다리는 시간보다 길고, 공유 보드의 상태 표시가 막아주지만 터미널은 막아주지 못하는 바로 그 실패 유형입니다. 생각 중인 실행과 크래시한 실행은 스크롤백에서 똑같이 보입니다. 상태 표시가 읽을 가치가 있으려면 무엇을 담아야 하는지는 coding agent observability를 참고하세요.

작업 디렉터리. Temporary 모드입니다. 각 Task는 격리된 디렉터리를 받고, 저장소 기반 실행은 새 워크트리를 준비하므로 같은 저장소에 대한 두 개의 Sol 실행이 서로 덮어쓸 수 없습니다. 임시 디렉터리의 기본 동시성은 Computer 한도의 50%입니다. 해당 Computer가 실제 실행을 여러 번 처리할 때까지는 그대로 두세요. 동시성을 높이면 CPU, 메모리, 디스크, 그리고 프로바이더 용량을 한꺼번에 소모합니다.

지침. 짧고 안정적으로 유지하세요:

Read the Task description and recent comments before editing.
Keep changes limited to the requested behavior.
Ask a question only when different interpretations would
materially change the result; otherwise proceed with a stated
assumption and record it in your report.
Run the closest relevant checks and report failures without hiding them.
Stop and ask before anything destructive or outside the repositories
attached to this Agent.

4단계: Task 하나를 할당하고, Crew가 제값을 하는지 판단하기

수용 기준이 명확한 Task를 고르세요. Agent를 Assignee로 선택하고 Task를 Backlog에서 '작업 가능' 범주에 속한 상태로 옮기세요. Backlog에서 할당된 Task는 대기합니다. 실행은 queued, dispatched, running 단계를 거치고, Executions 탭에서 로그가 스트리밍됩니다. Agent가 결정을 필요로 하면 질문이 댓글로 Task에 돌아오고, Task는 waiting for human reply를 표시하며, 이는 여러분의 Inbox로 전달됩니다.

범위가 한정된 변경이라면 Agent 하나가 정답이고 복잡한 요소도 0으로 유지됩니다. Crew는 하나의 리더 Agent가 조율하는, 재사용 가능한 People과 Agents의 그룹이며, 리더가 목표를 해석하고 여러 멤버의 결과를 하나의 Task로 모아야 할 때 제 역할을 합니다.

Sol은 그 계산을 바꿉니다. 리더는 대부분 읽고, 계획하고, 할당하고, 검토하는데, 가격표 맨 위에서 정당화하기 가장 어려웠던 작업이 바로 그것이기 때문입니다:

Astra에 대해서도 같은 설정을 running GPT-6 Astra as a Crew leader에서 다뤘습니다. 그때의 논지는 여전히 유효하고, 그 아래의 가격만 달라졌습니다.

가격 인하로 살 수 없는 것

OpenAI는 Sol이 GPT-5.6 프로모션 가격보다 50% 저렴하다고 설명합니다. 이 단서는 OpenAI 스스로 붙인 것이고 중요합니다. 비교 기준이 정가가 아니라 프로모션 요금이기 때문입니다. 같은 맥락에서 짚어야 할 단서가 두 가지 더 있습니다. OpenAI의 출시 벤치마크는 Claude Opus 5와 비교한 것인데, Anthropic은 같은 날 몇 시간 뒤에 Opus 5.5로 교체했습니다. 따라서 그 격차는 이전 세대와 비교한 수치로 읽어야 합니다. 그리고 그 성능은 추론 강도가 만들어냅니다. Sol은 max 강도에서 DeepSWE 1.1 68.8%, Agents' Last Exam V1 56.4%를 기록한 것이지, 일상적인 작업에 계속 켜둘 설정에서 나온 수치가 아닙니다.

그다음은 모델과 전혀 관계없는 부분입니다. OpenAI에 따르면 자사 연구원의 중간값은 코딩 에이전트에 하루 600달러 이상을 쓰고, 90번째 백분위수는 7,000달러를 넘습니다. 작업당 단가가 낮아지는 것은 그런 청구서가 만들어지는 방식이지, 피하는 방식이 아닙니다. 모든 실행은 여전히 사람이 읽고, 의문을 제기하고, 승인해야 하는 변경을 만들어내며, 그 대기열이 이번 주에 11배 저렴해지지는 않았습니다. 모델 선택보다 리뷰 역량을 기준으로 계획하고, 라우팅은 취향이 아니라 규칙으로 적어 두고, 요청부터 릴리스까지 할당, 진행 상황, 블로커, 결과, 사람의 리뷰를 한곳에 유지하세요.

이미 여러 코딩 에이전트를 운영하고 있다면, Computer 하나를 연결하고, Agent 하나를 만들고, 지루한 일을 하나 맡겨 보세요.