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

OpenAI가 9월 29일 DevDay에서 GPT-6.1 Sol을 출시했습니다. 정가는 GPT-6 Sol과 동일하게 입력 토큰 100만 개당 2달러, 출력 토큰 100만 개당 10달러이며, 캐시된 입력 비용은 절반인 0.10달러로 낮아졌습니다. 하지만 여러 Codex 에이전트를 운용하는 팀에게 가장 결정적인 변화는 비교적 조용히 찾아왔습니다. Codex CLI 문서의 시작 화면에 이제 gpt-6.1-sol medium이 표시된다는 점입니다. 특정 모델을 고정(pin)해 두지 않은 컴퓨터(Computer)에서는, 모델 변경을 의도하지 않았더라도 누군가 해당 컴퓨터에서 Codex를 업데이트하는 즉시 에이전트(Agent)가 사용하는 모델이 변경됩니다.

Sharkly 화면에서는 이러한 변화가 직접 드러나지 않습니다. 에이전트는 런타임(Runtime)의 기본 모델을 그대로 따르며 모델명을 별도로 표기하지 않기 때문에, 이번 주 이후로는 동일한 지침을 설정한 두 에이전트가 두 대의 컴퓨터에서 서로 다른 모델로 실행되더라도 보드상의 태스크(Task)는 겉보기에 똑같이 보일 수 있습니다. 어떤 에이전트가 어떤 모델로 실행 중인지, 특정 결과물이 어느 모델에서 생성되었는지를 오직 기억에만 의존해 파악해야 하는 상황이 발생하는 것입니다. 본 가이드에서는 이전의 GPT-6 Sol 가이드 이후 변경된 핵심 차이점만을 집중적으로 다룹니다. 새로운 기본 모델이 도입된 배경, 모델 고정 시점, 변경된 두 가지 설정, 그리고 중간 계층 모델의 성능이 최상위급에 가까워진 환경에서 크루(Crew)가 작업을 어떻게 라우팅해야 하는지 안내합니다.

핵심 요약 (TL;DR)

GPT-6.1 Sol은 컴퓨터의 Codex 런타임을 통해 Sharkly에 반영되며, 적용되더라도 Sharkly 상에서는 아무런 외형적 변화가 나타나지 않습니다. 각 컴퓨터가 어떤 Codex 빌드를 실행하고 있는지, 그리고 ~/.codex/config.toml 파일에 특정 모델이 고정되어 있는지 확인하세요. 모델이 고정되지 않은 컴퓨터는 CLI 기본값을 따르며, 현재 문서상 기본값은 medium effort의 gpt-6.1-sol입니다. 이전 가이드에 따라 구성된 컴퓨터는 설정 파일의 한 줄을 직접 수정하기 전까지 gpt-6-sol로 유지됩니다. none 추론 강도는 low로 변경해야 하며, 절반으로 줄어든 캐시 비용은 플랜 로그인 환경이 아닌 API 키가 등록된 컴퓨터에만 적용됩니다. 아울러 아래의 라우팅 표는 고정불변의 규칙이 아니라 각자의 태스크에 맞춰 직접 검증해 볼 가이드라인으로 삼으시기 바랍니다.

Codex 런타임 내부의 주요 변화

에이전트 관련 문서에서는 이 글이 에이전트 대신 컴퓨터를 중점적으로 다루는 이유를 다음과 같이 설명합니다. "에이전트는 런타임의 기본 모델을 따릅니다. 특정 모델명을 보장하거나 표시하지 않습니다. 모델 변경은 에이전트가 아니라 런타임 또는 컴퓨터 도구 설정에서 진행해야 합니다." 즉, 이번 업데이트는 런타임 차원의 이벤트입니다. 크루 구성원이 직접 체감하게 될 차이점은 다음과 같습니다.

새롭게 개편된 Codex CLI에는 모든 플랜을 대상으로 음성 기능, /agents 뷰, 프롬프트 편집, 작업 재개(resume), 워크트리(worktree) 기능도 추가되었습니다. 터미널 환경에서 수동으로 Codex를 조작할 때 매우 유용한 기능들입니다. 하지만 작업이 팀 단위로 확장되면 태스크(Task)가 공통의 공유 레코드가 됩니다. Temporary 모드에서 Sharkly는 각 태스크마다 독립된 디렉터리를 할당하며, 저장소 기반 작업의 경우 새로운 워크트리를 준비해 둘 수 있습니다. 또한 작업의 실행 상태, 로그, 질의 사항 및 최종 결과가 해당 태스크로 반환되므로 다음 담당자가 손쉽게 이어받을 수 있습니다.

모델 고정 vs 기본값 유지: 컴퓨터별 최적의 선택

컴퓨터마다 설정 기준이 다를 수 있으므로 현황 파악(인벤토리 점검)부터 시작하는 것이 좋습니다. sharkly computer list 명령어로 조직에 등록된 컴퓨터 목록을 확인하고, sharkly computer show <computer-id>로 특정 컴퓨터와 실행 중인 런타임 목록을 조회할 수 있습니다. 해당 컴퓨터에서 직접 codex를 실행하면 빌드 버전과 설정된 모델이 출력됩니다. Codex 변경 로그에 따르면 9월 29일 배포된 0.159.1 버전부터 GPT-6.1 Sol이 기본값으로 지정되었으며, 공식 문서의 예제 세션에서도 model: gpt-6.1-sol medium으로 안내됩니다.

여기서 점검해야 할 핵심 사항은 두 가지입니다. 첫째, 어떤 실행 바이너리가 구동되고 있는지 확인해야 합니다. macOS 환경에서는 독립형 Codex가 설치되어 있지 않을 경우 ChatGPT 데스크톱 앱에 포함된 Codex CLI를 런타임으로 등록할 수 있으나, Sharkly 문서에서는 별도로 설치하여 PATH에 등록한 정식 Codex를 사용할 것을 권장합니다. 둘째, 모델이 어느 설정 계층에서 지정되고 있는지 확인해야 합니다. Codex 설정 기본 문서에 따르면 개인 기본값은 ~/.codex/config.toml에 저장되며, 저장소 내 .codex/config.toml(신뢰할 수 있는 프로젝트에서만 로드됨)로 이를 재정의할 수 있습니다. 커맨드라인에서 직접 전달하는 -m 또는 --model 옵션은 이 두 설정보다 언제나 최우선 적용됩니다.

선택 기준은 명확합니다. 한 사람이 단독으로 소유하고, 주당 소수의 태스크만 처리하며, 설정 파일을 일일이 관리하기보다는 OpenAI의 최신 권장 모델을 자동으로 추적하고 싶다면 기본값을 따르도록 두는 것이 적합합니다. 반면 여러 작업자가 해당 컴퓨터의 에이전트에 업무를 할당하거나, 여러 대의 컴퓨터에 걸쳐 크루가 구성되어 있거나, 스프린트가 한창 진행 중인 상황이라면 모델을 명시적으로 고정해야 합니다. 예고 없는 모델 변경이 발생하면, 태스크 보드상에서는 동일해 보이지만 화요일 작업 결과와 목요일 작업 결과의 산출 모델이 달라져 일관성을 잃을 수 있기 때문입니다.

모델을 고정하려면 Codex 런타임이 구동되는 컴퓨터의 사용자 설정 파일을 수정합니다.

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

두 키 모두 Codex 설정 문서에 명시된 정식 옵션입니다. 이전 GPT-6 Sol 가이드를 적용하셨다면 해당 파일에 이미 model = "gpt-6-sol"로 지정되어 있으므로, 업데이트가 실행되어도 모델이 임의로 변경되지 않습니다. 준비가 완료되었을 때 해당 라인을 수정하시기 바랍니다.

문서에 안내된 통합 설치 스크립트로 Codex를 설치 및 업데이트하거나, Sharkly를 통해 특정 런타임의 CLI 업데이트를 요청할 수 있습니다.

curl -fsSL https://chatgpt.com/codex/install.sh | sh
# or, from anywhere with the Sharkly CLI:
sharkly computer update <computer-id> <runtime-id>

이후 컴퓨터 상세 정보에서 재검색(rescan) 또는 연결 테스트를 실행하여 Codex 런타임이 Available 상태로 표시되는지 확인합니다. 마지막으로, 고정한 모델명을 에이전트 설명란에 명시해 두세요. 변경 사항(diff)을 검토하는 리뷰어가 어떤 모델이 코드를 작성했는지 파악하기 위해 다른 컴퓨터의 셸에 접속해야 하는 번거로움을 피할 수 있습니다.

주목해야 할 두 가지 설정 변경: 추론 강도와 캐시 비용

none 옵션이 완전히 제외되었습니다. GPT-6.1 Sol은 low, medium, high, xhigh, max만 지원하며, none이나 minimal은 허용되지 않습니다. 이전 GPT-6 Sol 환경에서 빠른 처리를 위해 none을 사용하던 컴퓨터라면 버전을 전환하기 전에 반드시 low로 변경해야 합니다. 또한 low 설정 역시 추론 연산을 수행하므로 결과물을 면밀히 재검토할 필요가 있습니다. 만약 이전 설정으로 인해 작업이 실패하더라도 실행 로그에 작업 제목과 모델 서비스의 원본 응답이 그대로 유지됩니다. 이때 무작정 재시도하기보다는 Sharkly의 문제 해결 지침에 따라 모델 및 요청 옵션이 올바르게 지정되었는지 확인하시기 바랍니다.

캐시 비용 절감은 실질적으로 큰 이점입니다. OpenAI는 캐시된 입력 비용을 100만 토큰당 0.10달러로 책정했습니다. 이는 "표준 입력 요금 대비 95% 저렴하며, GPT-6 Sol의 캐시 입력 요율보다 50% 낮은 가격"입니다. 장시간 구동되는 에이전트일수록 절감 효과가 뚜렷합니다. 동일한 저장소에서 1시간 동안 연속 실행되는 작업은 대부분 동일한 컨텍스트를 반복 전송하며, 공통된 프로젝트 구조, 코딩 규칙, 테스트 명령을 공유하는 크루 구성원들은 하루 종일 동일한 접두사(prefix)를 재사용하기 때문입니다.

단, 정확한 예산 설계를 위해 다음 세 가지 주의점을 확인해야 합니다. 첫째, 토큰당 비용 절감 혜택은 Codex가 API 키를 통해 과금되는 컴퓨터에만 적용됩니다. ChatGPT 플랜 로그인 방식을 사용하는 컴퓨터는 플랜 사용량이 차감되며, 이에 대한 상세 내용은 자매 글인 API 키 없이 GPT-6.1 Sol 에이전트 운용하기를 참조하세요. 둘째, 기본 정가 자체는 변동이 없으므로 캐시되지 않은 입력 작업은 이전과 동일한 요금이 부과됩니다. 셋째, 긴 컨텍스트에 대해서는 추가 할증이 발생합니다. OpenAI는 272K 입력 토큰을 초과하는 요청 전체에 대해 입력 및 캐시 요율을 2배, 출력 요율을 1.5배로 책정합니다. 따라서 대규모 컨텍스트를 매 턴마다 전달하는 에이전트라면 작업 예산을 무작정 늘리기 전에 접두사를 작고 안정적으로 분리하는 작업이 선행되어야 합니다.

크루를 위한 모델 라우팅 전략: Astra, 6.1 Sol, Luna, Claude 런타임 배분

OpenAI가 강조하는 6.1 Sol의 핵심 가치는 극히 낮은 비용으로 Astra에 필적하는 성능을 제공한다는 점이며, 발표된 모든 벤치마크 수치는 OpenAI의 자체 테스트에 기반합니다. DeepSWE v1.1에서 6.1 Sol은 약 5분의 1 수준의 비용으로 Astra와 대등한 성과를 보였고, 더 낮은 추론 강도에서도 GPT-6 Sol의 최고 점수를 6.4점 앞선 것으로 나타났습니다. 컴퓨터 조작 벤치마크인 OSWorld 2.0에서는 max effort 기준 태스크당 약 7분의 1 비용으로 Astra와의 점수 차이를 2.1점 이내로 좁혔습니다. 한편 한계점 또한 분명히 제시되었습니다. Terminal-Bench Science 평가에서는 Astra가 68.1%로 여전히 최고 점수를 유지하고 있으므로, 고도의 과학적 추론이 필요한 영역에는 Astra를 사용할 것을 권장하고 있습니다.

OpenAI의 모델 선택 가이드에서도 동일한 체계로 라인업을 구분합니다. 모호하고 구조화되지 않은 문제에는 Astra, 시간과 비용 효율이 중요한 복잡한 엔지니어링에는 6.1 Sol, 명확히 한정된 작업과 이슈 분류(triage)에는 Luna를 배치하도록 권장하며, 이러한 가이드는 어디까지나 실무 적용을 위한 시작점임을 강조합니다. 모델 적용은 런타임 설정에 종속되므로, Sharkly의 라우팅 규칙은 곧 컴퓨터 설정 규칙과 같습니다. 즉, Codex 기본값이 Astra로 구성된 컴퓨터에 할당된 에이전트는 Astra로 실행됩니다. 실무에 바로 적용해 볼 수 있는 초기 권장 규칙은 다음과 같습니다.

마지막 행은 단순한 벤치마크 주장이 아니라 특정 벤더에 종속되지 않는 전략적 원칙을 담고 있습니다. Claude Sonnet 5.5는 6.1 Sol 출시 하루 전 동일한 가격대($2 및 $10)로 공개되었으나, OpenAI의 공식 게시글에서는 6.1 Sol을 Opus 5.5 및 Fable 5.1과만 대조했을 뿐 Sonnet 5.5와의 직접 비교는 다루지 않았습니다. 두 모델 간의 객관적인 정면 비교 데이터가 부재한 상황이므로, 실제 팀의 태스크를 바탕으로 직접 수행한 비교 검증만이 유효한 판단 기준이 됩니다. 수동 에스컬레이션 절차를 갖춘 체계적인 라우팅 규칙에 대한 자세한 분석은 크루를 위한 모델 라우팅 가이드에서 확인하실 수 있습니다.

이러한 변화 속에서도 변하지 않는 핵심이 있습니다. Astra급의 고성능을 더 저렴하게 활용할 수 있다는 것은 매일 처리 완료되는 작업 수가 늘어남을 의미하며, 그 모든 작업의 최종 종착지는 여전히 코드 변경 사항을 검토하는 사람이라는 점입니다. 에이전트는 조사, 실행, 테스트 및 보고를 담당합니다. 사람은 작업의 방향을 결정하고, 실행 권한을 부여하며, 최종 결과를 승인합니다. 이번 주에 집중해야 할 업무는 어떤 컴퓨터가 어떤 모델을 실행했는지, 정상 완료된 작업과 구형 effort 설정 오류로 실패한 작업은 무엇인지, 그리고 어떤 태스크가 검토(review)를 대기 중인지 보드를 통해 한눈에 파악할 수 있도록 정비하는 일입니다. 여전히 여러 터미널을 열어두고 Codex를 수동으로 전환하고 계신다면, 혼선 없이 다중 Codex 에이전트 관리하기를 통해 기본적인 관리 흐름을 먼저 익혀보세요.

워크트리를 활용해 이러한 워크플로를 직접 구축할 수도 있고, Sharkly를 활용해 전체 프로세스를 통합 관리할 수도 있습니다.