GPT-5.6 입문, 완전 기초 | Chat, Codex, Spark 활용 하는 법(Chat·Work·Codex 구분하여 사용하기)

안녕하세요. 갓대희 입니다.

 

 

이번 포스팅은 [ GPT-5.6을 Chat·Codex·Spark로 나눠 쓰는 방법 ] 입니다. : )

앞선 글에서는 GPT-5.6의 Sol·Terra·Luna 차이를 정리했다.

GPT-5.6 리뷰 - Sol vs Terra vs Luna: 성능, 가격, 요금제, 접근 권한, 105만 토큰 컨텍스트와 새로운 Max 모드 등

 

새 모델이 나오고 한동안은 이것저것 눌러보느라 토큰을 꽤 많이 소비했을 것이다. 나 역시 처음에는 무조건 강한 모델부터 켜고 마구잡이로 사용해 보았다.

 

그런데 실제 작업을 시작해 보니 모델 선택만큼이나 Chat, Work, Codex 중 어디에서 시작할지가 중요했다.

같은 GPT-5.6을 쓰더라도 기획부터 코드 수정까지 한곳에서 밀어붙이는 것보다, 일의 성격에 따라 나누는 편이 토큰도 덜 들고 결과 확인도 쉬웠다.

 

이번 글에서는 여러 작업에 직접 적용해 보며 정착한 Chat에서 기획 → Codex에서 실행 → GPT-5.3-Codex-Spark로 작은 후속 작업 → 마지막은 직접 검수하는 흐름을 정리해 보려 한다.

 

솔직히 말하면 나도 Sol을 써본 지 2~3일밖에 안 됐다. 그 짧은 시간 동안 Threads, X(트위터), Reddit을 꽤 뒤졌는데, 커뮤니티에서 반복적으로 올라오는 패턴이 몇 가지 눈에 들어왔다.

그 중에서 나한테 가장 와닿은 것들만 추려서, 내 방식으로 다시 정리한 게 이 글이다.

 

커뮤니티에서 공통적으로 나오던 패턴 4가지

① “Chat은 '무엇을 할지', Codex는 '어떻게 할지'”
가장 많이 보인 표현이었다. 목표나 방향은 Chat에서 대화로 잡고, 실제 파일을 건드리는 실행은 Codex로 넘긴다는 것. 처음엔 그냥 Codex에 바로 시키면 되지 않나 싶었는데, 막상 해보니 Chat에서 한 번 정리하고 넘기는 게 훨씬 결과가 깔끔했다.

 

② “Sol을 모든 작업의 기본값으로 두지 마라”
X에서 꽤 공감 받던 글이었다. 간단한 수정에 Sol·Ultra를 쓰면 토큰이 훅 나가면서 품질이 오히려 애매해지는 경우가 있다고. 나도 실제로 간단한 수정에 Sol·높음 설정이 Sol·Ultra보다 결과가 더 군더더기 없었다. 추론 강도를 max·ultra로 올렸을 때 오히려 과하게 해석하고 불필요한 코드를 끼워 넣는 느낌이 들었다.

 

③ “Work랑 Codex 한도 분리되는 줄 알았다가 낭패봤다”
Reddit r/ChatGPT에서 꽤 공감 댓글이 달렸던 글이다. Work를 쓰면 Codex 한도를 아낄 수 있을 거라 생각했는데, 실제로는 둘이 같은 풀(pool)을 공유한다는 것. 나도 이걸 모르고 Work와 Codex를 왔다 갔다 했다가 생각보다 빠르게 한도가 찼다.

 

④ “Spark는 작고 되돌리기 쉬운 일에만 쓴다”
Threads에서 나온 얘기인데, Spark에 큰 일을 시키거나 “고쳐줘” 한 마디만 던지면 테스트를 자동으로 건너뛰는 경우가 있다고 했다. 수정 범위가 좁고 결과를 바로 확인할 수 있는 것만 맡기는 게 맞더라.

 

이 네 가지가 내 흐름에도 거의 그대로 들어맞았다. 나머지 세부 내용은 아래에서 순서대로 풀어보겠다.

이 글은 Codex·Work·Spark가 처음인 분을 기준으로 작성했습니다.

Chat, Work, Codex가 무엇이고 어떻게 다른지부터 차근차근 살펴봅니다.

이미 Codex나 Work를 자주 사용하고 있다면 앞부분은 가볍게 읽어도 됩니다.

먼저 짧게 정리하면

• GPT-5.6은 모델 제품군이고, Chat·Work·Codex는 그 모델을 사용하는 환경이다.
  Chat의 Sol은 현재 Plus·Pro·Business·Enterprise에서 제공된다. (출처: OpenAI GPT-5.6 발표)
• 질문이나 아이디어 정리는 Chat, 긴 자료 조사와 문서 작업은 Work, 실제 파일과 코드를 고치는 일은 Codex가 편했다.
• Work와 Codex는 같은 agentic usage·credit pool을 사용한다. 둘을 번갈아 쓴다고 한도가 분리되지 않는다. (출처: OpenAI 사용량 문서)
• GPT-5.3-Codex-Spark는 현재 ChatGPT Pro 대상 research preview이며 자체 rate limit을 쓴다. 단, 무료·무제한은 아니다. (출처: OpenAI Spark 발표)
• “Task로 Codex에 넘긴다”는 것은 Chat 대화 전체를 복사하는 일이 아니다. 목표와 범위, 완료 조건을 짧게 정리해 전달하면 된다.

목차

1. 직접 써보며 정착한 작업 흐름
2. Chat, Work, Codex, Spark는 무엇이 다를까?
3. 내가 실제로 일을 나누는 순서
4. Chat에서는 어디까지 정리할까?
5. Chat에서 정한 내용을 Codex로 넘기는 방법
6. Codex App과 CLI에서 작업하는 순서
7. Spark는 언제 사용하면 좋을까?
8. 직접 써보며 줄인 토큰 낭비
9. 상황별로 적용해 본 예시
10. 바로 바꿔 쓸 수 있는 프롬프트
11. 자주 낭비한 패턴과 궁금한 점
12. 처음 적용한다면 이 순서로
13. 참고 자료

1. 직접 써보며 정착한 작업 흐름

ChatGPT에서 GPT-5.6 Sol로 대화하며 방향을 잡고,
실제 작업은 Task로 나누어 Codex에 넘긴다.

끝나고 남은 작은 수정은 사용량이 별도인 GPT-5.3-Codex-Spark로 처리하고 있다.

여러 방식으로 써본 뒤 개인적으로 가장 편했던 흐름은 이렇다.

 

기획 단계에서는 ChatGPT와 편하게 대화하며 생각을 정리하고, 실제로 만들 일은 Task로 쪼개어 Codex에 맡기는 방식이다. 

(물론 개발자분들은 기획과 계획부터 Codex Plan 모드에서 진행하는 편이 더 익숙할 수도 있다.) 

 

모델과 추론 강도는 현재 다음 설정이 나에게 가장 잘 맞았다.

 - 모델 : GPT-5.6 Sol

 - 추론 강도 : 높음

 

추론 강도를 max나 ultra로 올리면 모든 작업에서 체감 성능이 좋아진다기보다 토큰 소모가 먼저 커지는 느낌이었다.

 

작업 중간에 생기는 간단한 수정은 5.3 Codex Spark로 빼두는 편이 속도나 토큰 사용량 면에서 더 나았다.

 

그렇다면 업무(Work) 모드는 언제 사용하면 좋을까? 

 - 여러 자료를 모아 표, 문서, 발표 자료로 정리할 때

 - 보고서와 표가 필요하지만 로컬 코드를 직접 고칠 일은 없을 때

 

이럴 때는 Work부터 시작하면 편했다. 반대로 파일을 실제로 수정하고 테스트 결과까지 확인해야 한다면 Codex가 맞다.

짧은 사실, 간단한 대화로 끝날 내용은 굳이 긴 작업을 만들지 않고 Chat에서 끝내면 된다.

 

나도 작업 성격에 따라 중간중간 업무(Work) 모드로 바꾸어 사용한다. ( Codex App에서 다음과 같이 Codex > 업무 선택)

기존에 Claude CoWork를 써보셨다면 거의 비슷한 용도로 생각해도 무리가 없다.

시작하기 전에 모델이 보이는지부터 확인

이 글은 Sol과 Spark를 선택할 수 있는 계정을 기준으로 설명한다.

Chat에서 Sol이 보이지 않으면 표준 Chat에서 현재 선택 가능한 모델로 기획하고 Work·Codex에서 Terra가 보이면 Terra를 선택하면 된다.

Spark가 보이지 않으면 같은 작은 작업을 범위가 좁은 Codex Task로 처리한다.

플랜과 롤아웃은 바뀔 수 있으니, 글만 믿기보다 내 계정의 모델 선택 화면도 함께 확인하길 바란다.

① Chat

대화하면서 무엇을 만들지 정한다.

② Codex

실제 파일을 고치고 검증한다.

③ Spark

작고 확인하기 쉬운 일을 마무리한다.

④ 사람

결과와 테스트를 직접 확인한다.

여기서 사용량은 꼭 구분해서 봐야 한다. Work와 Codex는 같은 agentic usage·credit pool을 사용하므로 둘을 번갈아 쓴다고 한도가 따로 생기지 않는다.

Spark는 research preview 동안 별도 rate limit을 쓰지만, 무료나 무제한이라는 뜻은 아니다. 수요가 몰리면 대기하거나 접근이 제한될 수 있다.

 

1.1 가장 헷갈렸던 사용량 관계

사용 환경	공식 사용량 관계	실전에서 기억할 점
ChatGPT Work	Codex와 같은 agentic usage·credit pool	Work를 거친다고 한도가 따로 생기지 않는다.
Codex App·CLI	Work와 같은 agentic usage·credit pool	작업 크기·복잡도·모델에 따라 실제 소모량은 달라진다.
GPT-5.3-Codex-Spark	research preview 자체 rate limit	표준 한도와 별도지만 무료·무제한은 아니다.

그래서 Work와 Codex를 한도 분리 목적으로 오가는 것은 별 도움이 되지 않았다. Spark도 별도 한도일 뿐 무제한은 아니다.

 

2. Chat, Work, Codex, Spark는 무엇이 다를까?

앞선 글에서 Sol·Terra·Luna의 차이를 살펴봤다면, 이제는 그 모델을 어디에서 사용할지 구분할 차례다. 이름이 한꺼번에 보이면 모델과 제품이 뒤섞여 꽤 헷갈린다.

Sol·Terra·Luna는 성능과 비용이 다른 모델이고, Chat·Work·Codex·Spark는 그 모델로 어떤 일을 할지 정하는 사용 환경이다. 모델을 고르는 일과 작업할 곳을 고르는 일은 따로 생각하면 이해하기 쉽다. (OpenAI 공식 발표)

 

처음에는 모든 일을 Sol로 처리했지만, 오탈자 수정이나 링크 확인까지 무거운 모델을 붙잡고 있을 필요는 없었다. 판단을 많이 해야 하는 일에는 Sol을 쓰고, 정답과 확인 방법이 분명한 일은 가벼운 모델로 내리는 편이 훨씬 효율적이었다.

도구	잘 맞는 일	결과물	검수 포인트
Chat	질문, 검색, 브레인스토밍, 결정 정리	대화, 요약, 기획안	전제·우선순위·빠진 질문
Work	긴 리서치, 분석, 문서·표·슬라이드	완성 파일과 리포트	출처·수치·누락
Codex App	로컬 프로젝트, 여러 thread, diff 검토	파일 변경, 테스트, Git diff	변경 범위·테스트·회귀
Codex CLI	터미널 중심 반복 작업과 자동화	명령 결과, 코드, 로그	종료 코드·Git 상태
Spark	작은 수정, 빠른 탐색, 짧은 코딩	최소 diff, 빠른 답	테스트를 명시했는지

글에서 자주 나오는 용어

• agentic usage·credit pool: Work와 Codex의 에이전트 작업 사용량·크레딧이 함께 차감되는 묶음이다.
• rate limit: 일정 시간 동안 사용할 수 있는 작업·호출의 제한이다.
• thread: Codex App에서 하나의 작업을 이어가는 대화 단위다.
• worktree: 같은 Git 저장소의 변경이 서로 섞이지 않도록 나눈 작업 폴더다.
• viewport: 브라우저에서 현재 보이는 화면 영역을 말한다.
• built-in: 별도로 설치하지 않아도 앱에 기본으로 들어 있다는 뜻이다.
• handoff brief: 목표와 범위, 완료 조건만 추려 다음 작업에 넘기는 짧은 인계서다.

 

3. 내가 실제로 일을 나누는 순서

처음에는 Chat 다음에 Work를 거쳐야 Codex로 넘어가는 줄 알았는데, Work는 꼭 지나야 하는 단계가 아니었다. 자료를 많이 조사해 문서나 표를 만들어야 할 때만 Work를 사용하고, 코드 작업이 중심이라면 Chat에서 정리한 내용을 Codex로 바로 넘긴다. 어차피 Work와 Codex는 같은 agentic pool을 사용하므로 한도를 아끼기 위해 중간에 Work를 끼워 넣을 이유도 없다.

1) Chat에서 생각을 정리한다

무엇을 만들지, 누가 볼지, 어디까지 다룰지 먼저 대화한다. 대화가 길어져도 마지막에는 목표와 범위, 기준 자료, 완료 조건만 남긴 짧은 brief로 정리한다.

2) Codex Ask Mode에서 실제 파일을 확인한다

Chat은 저장소 안의 실제 상황까지 알지 못한다. Codex가 관련 파일과 호출 관계, 테스트 명령을 읽은 뒤 계획을 다시 맞추게 한다. OpenAI 팀도 Ask Mode에서 만든 구현 계획을 Code Mode 작업에 이어서 사용한다고 설명한다.

3) Code Mode에서 고치고 바로 확인한다

“구현해줘”라고만 하면 결과를 어디까지 확인해야 하는지 애매하다. 수정할 범위와 함께 테스트, lint, HTML validator, 브라우저 확인처럼 끝났다고 판단할 기준도 같이 적어준다.

4) 남은 작은 일은 Spark로 뺀다

문장 하나 다듬기, 실패한 테스트 한 건 살펴보기, 누락된 패턴 찾기, diff 요약처럼 결과를 바로 확인할 수 있는 일만 따로 맡긴다.

마지막은 직접 확인한다

에이전트가 “완료했다”고 말한 것만 믿지는 않는다. diff와 테스트 출력, 브라우저 화면, 출처 링크를 직접 보고 마무리한다. 특히 Spark를 쓸 때는 어떤 검증을 실행할지도 함께 적어두는 편이 안전했다.

 

4. Chat에서는 어디까지 정리할까?

Chat에서 기획한다고 해서 대화를 끝없이 이어갈 필요는 없다. 여러 번 해보니 Codex가 작업하면서 다시 추측하지 않아도 될 정도만 정하면 충분했다. 나는 아래 일곱 가지가 채워지면 Codex로 넘긴다.

1. 원하는 결과: “블로그를 써줘” 대신 어떤 주제의 어떤 파일을 완성할지 한 문장으로 쓴다.
2. 읽을 사람: 입문자와 숙련자 중 누구를 위한 글인지 정하면 설명의 깊이가 흔들리지 않는다.
3. 다룰 범위: 이번 글에 넣을 내용과 앞 글로 넘길 내용을 구분한다.
4. 기준 자료: 공식 문서, 기존 파일, 디자인 시안과 자료의 기준일을 함께 적는다.
5. 작업 크기: 한 번에 확인하기 어려운 일은 사람이 검수할 수 있는 단위로 나눈다.
6. 완료를 확인할 방법: 테스트, validator, 링크 수, 화면 크기처럼 눈으로 확인할 조건을 쓴다.
7. 멈춰야 할 때: 권한이 없거나 사실이 충돌하거나 삭제·배포가 필요하면 먼저 멈추도록 한다.

작업 크기는 어느 정도가 좋을까? OpenAI 내부 가이드는 사람이 약 한 시간에 처리할 일이나 수백 줄 규모의 변경을 Codex에 맡기기 좋은 범위로 설명한다. 한 번에 검수하기 어렵다면 이미 너무 큰 작업일 가능성이 높다.

 

5. Chat에서 정한 내용을 Codex로 넘기는 방법

이 부분이 처음에는 가장 헷갈렸다. Chat에서 계획을 잘 세워도 모든 계정에서 Codex로 바로 보내는 범용 원클릭 기능은 현재 공식 문서에서 확인하지 못했다. 그래서 나는 Chat 결과를 Codex의 새 thread 첫 메시지에 붙여 넣거나, brief.md로 저장해 프로젝트 폴더에서 읽게 한다.

같은 종류의 작업을 반복한다면 파일로 남기는 편이 더 편했다. 대화가 압축되거나 새 thread를 열어도 내용이 사라지지 않고, Git으로 변경 이력도 확인할 수 있기 때문이다.

# Handoff brief

## 목표
- 최종 결과를 한 문장으로 쓴다.
## 현재 상태
- 이미 존재하는 파일과 확인한 사실을 적는다.
## 작업 범위
- 읽을 경로, 수정 가능한 경로, 새 파일을 적는다.
## 변경 금지
- 건드리지 않을 파일, 삭제 금지, 외부 게시 금지를 적는다.
## 기준 자료
- 공식 URL, 기존 구현, 디자인, 데이터 기준일을 적는다.
## 완료 기준
- 실행할 테스트와 validator, 화면 확인 조건을 적는다.
## 중단 조건
- 권한 부족, 사실 충돌, 파괴적 작업이 필요한 경우를 적는다.
## 완료 보고
- 변경 파일, 실행 명령, 결과, 남은 위험을 보고한다.

 

OpenAI도 Codex 프롬프트를 GitHub Issue처럼 작성하고 파일 경로·컴포넌트·참고 구현을 포함하라고 권한다. (출처: OpenAI Codex 활용 가이드) 위 brief도 그 내용을 Chat에서 Codex로 넘기기 쉽게 줄여 쓴 형식이다.

 

6. Codex App과 CLI에서는 이렇게 작업했다

6.1 App과 CLI 중 무엇을 쓸까?

여러 thread를 한눈에 보고 diff를 검토하거나 worktree로 작업을 나누고 싶을 때는 App이 편했다. Codex 앱은 여러 agent 작업과 built-in worktree를 지원한다. (출처: Codex 앱 소개)

반대로 터미널에서 명령과 로그를 계속 지켜보거나, 기존 셸 자동화와 이어서 쓸 때는 CLI 쪽이 손에 더 잘 맞았다. 어느 쪽이 더 똑똑한 것이 아니라 작업 화면이 다른 셈이다.

 

6.2 실제로 사용한 순서

1. Ask Mode: 먼저 저장소를 읽고 어떤 파일이 영향을 받는지, 어떤 테스트를 돌릴지 확인한다.
2. 수정 범위 확인: 고칠 파일과 건드리지 않을 파일을 나눈다.
3. Code Mode: 확인한 계획대로 실제 파일을 수정한다.
4. 자동 검증: 테스트·lint·typecheck·validator를 실행한다.
5. 직접 확인: 웹이면 브라우저, API면 실제 요청처럼 사용자가 쓰는 화면에서 한 번 더 확인한다.
6. 마무리: 바뀐 파일과 검증 결과, 아직 남은 위험을 짧게 기록한다.

작업 중 방향이 틀어졌다고 매번 새 thread를 만들 필요는 없었다. Codex에서는 새 지시를 입력한 뒤 Steer로 진행 중인 작업을 바로 교정할 수 있다.

 

7. Spark는 언제 사용하면 좋을까?

Spark는 빠르다고 해서 아무 일이나 맡기는 모델은 아니었다. 내가 주로 넘긴 것은 변경 범위가 한두 파일로 좁고, 테스트나 diff를 보면 정답을 바로 확인할 수 있는 일이다.

실패하더라도 쉽게 되돌릴 수 있고 긴 배경 설명 없이 현재 파일만 보고 판단할 수 있다면 잘 맞았다. 반대로 작은 수정처럼 보여도 인증, 결제, 보안처럼 실패 비용이 큰 일은 Spark에 가볍게 넘기지 않았다.

작업	Spark 추천	이유
오탈자·링크·HTML 속성 수정	높음	범위와 정답이 분명하다.
한 테스트 실패 원인 좁히기	높음	빠른 대화형 탐색에 맞는다.
작은 함수 리팩터링	보통	회귀 테스트를 지정해야 한다.
여러 모듈 아키텍처 변경	낮음	긴 맥락과 설계 판단이 필요하다.
인증·결제·보안 정책	낮음	작은 diff여도 위험이 크다.
출처가 많은 장문 리서치	낮음	빠른 코딩 모델의 장점과 맞지 않는다.

Spark를 고를 때는 코드가 몇 줄인지보다 범위가 좁은지, 결과를 빨리 확인하고 되돌릴 수 있는지를 보았다.

사용하기 전에 확인할 점: Spark는 research preview 동안 자체 rate limit을 사용하고 표준 한도에 포함되지 않는다. 그렇다고 무료나 무제한은 아니며, 수요가 높으면 접근이 제한되거나 대기할 수 있다. 테스트도 기본으로 자동 실행하지 않으므로 프롬프트에 검증 명령을 직접 적어주는 편이 좋다.

(출처: OpenAI Spark 발표)

 

8. 직접 써보며 줄인 토큰 낭비

토큰을 아끼려고 무조건 가벼운 모델만 쓰는 방법은 오래가지 않았다. 잘못 이해한 상태로 작업을 다시 시키면 오히려 더 많이 쓰게 된다. 모델보다 먼저 작업을 전달하는 방식을 바꾸었더니 낭비가 눈에 띄게 줄었다.

1. Chat 대화 전체를 복사하지 않고, 목표·결정·자료·완료 조건만 brief에 남겨 넘긴다.
2. 문체나 테스트처럼 매번 반복하는 규칙은 프로젝트의 AGENTS.md에 적어둔다.
3. 큰 작업은 조사, 설계, 구현, 테스트, 화면 확인처럼 내가 중간 결과를 검수할 수 있는 지점에서 나눈다.
4. Work와 Codex는 같은 agentic pool을 사용하므로 한도를 피하려고 두 환경을 오가지 않는다.
5. Sol은 실패했을 때 손실이 크거나 판단이 복잡한 일에 먼저 쓰고, 단순한 작업까지 기본값으로 두지는 않는다.
6. 작업하다 발견한 오탈자나 경고는 본 작업에 섞지 않고 작업 목록(task queue)으로 빼둔다.
7. 여러 thread를 동시에 돌릴 때는 같은 파일을 고치지 않도록 담당 파일과 worktree를 나눈다.
8. 테스트가 실패했다면 숨기지 않고, 실행한 명령과 오류 한 줄을 완료 보고에 남긴다.
9. 몇 번 직접 실행해 성공한 반복 작업만 skill이나 automation(자동화)으로 옮긴다. 불안정한 작업을 먼저 자동화하면 실패도 그대로 반복된다.

 

9. 상황별로 적용해 본 예시

설명만 읽으면 역할이 딱 나뉘는 것 같지만, 실제로 쓰다 보면 “여기서 Codex로 넘길까, Chat에서 조금 더 이야기할까?” 고민하는 순간이 자주 온다. 내가 반복해서 해본 세 가지 작업은 아래처럼 나누어 사용했다.

9.1 기술 블로그 작성

• 먼저 Chat Sol에서 누가 읽을 글인지, 어떤 각도로 쓸지, 반드시 답할 질문과 과장하지 않을 표현을 정한다.
• 외부 자료가 많아 표나 리포트까지 만들어야 할 때만 Work를 중간에 사용한다.
• Codex에는 기존 글과 로컬 스타일을 읽게 한 뒤 작성 기준(spec), 근거(evidence), 초안(draft), 최종 HTML 파일을 만들게 한다.
• 링크 누락, data-ke 속성, 어색한 문장, 목차 앵커처럼 작은 수정은 Spark로 분리한다.
• 마지막에는 모바일과 데스크톱 화면을 직접 열어보고, 인용한 출처도 다시 확인한다.

9.2 코드 기능 개발

• Chat Sol에서는 사용자가 겪는 문제와 꼭 지켜야 할 조건, 이번에 건드리지 않을 범위를 정리한다.
• Codex Ask Mode로 실제 모듈 경계와 기존 구현 방식, 테스트 위치를 먼저 찾는다.
• 계획이 맞으면 Code Mode에서 기능과 테스트를 함께 구현한다.
• 실패한 테스트 한 건이나 타입 오류, 문구, 작은 접근성 문제는 별도 Spark 작업으로 뺀다.
• 끝나면 실제 UI나 API에 정상 입력과 실패 입력을 모두 넣어본다.

9.3 오래된 콘텐츠 유지보수

• Chat에서 어디까지 업데이트할지, 그대로 남길 문장은 무엇인지 먼저 정한다.
• Codex로 오래된 버전, 링크, 명령을 검색하고 바뀔 파일 목록을 만든다.
• 확인한 목록은 Spark가 파일별 작은 diff로 반영하게 할 수 있다.
• 마지막에는 Git diff를 열어 범위 밖의 문장까지 바뀌지 않았는지 확인한다.

세 작업을 해보고 남은 기준

Chat에서는 무엇을 할지 정하고, Codex에서는 실제 파일을 바꾼다. Spark는 앞의 작업이 끝난 뒤 범위가 분명해진 작은 수정에 붙였을 때 가장 편했다.

 

10. 바로 바꿔 쓸 수 있는 프롬프트

아래 문장은 실제로 사용할 때 대괄호 안의 내용만 바꾸면 된다. 그대로 복사하기보다 내 프로젝트의 파일 경로와 검증 명령을 구체적으로 적을수록 결과가 안정적이었다.

10.1 Chat Sol에서 기획을 정리할 때

나는 [xx 결과]를 완성하려 한다. 바로 실행하지 말고 먼저 기획한다.

1. 목표를 한 문장으로 다시 정의해라.
2. 독자/사용자와 해결할 문제를 적어라.
3. 필수로 포함할 것과 제외할 것을 나눠라.
4. 결정이 필요한 질문을 최대 7개로 줄여라.
5. 작업을 사람이 검수할 수 있는 3~5단계로 나눠라.
6. 각 단계의 완료 증거와 중단 조건을 적어라.
7. 마지막에는 Codex에 전달할 handoff brief만 출력해라.

확인하지 않은 사실은 [미확인], 내 선택이 필요한 것은 [결정 필요]로 표시해라.

 

10.2 Codex가 저장소를 먼저 살펴보게 할 때

다음 handoff brief를 읽고 아직 수정하지 마라.

[brief.md 경로 또는 본문]

저장소를 확인해 다음만 보고해라.
- 관련 파일과 현재 동작
- 기존 구현 패턴
- 예상 변경 파일
- 회귀 위험
- 실행할 테스트와 수동 QA
- brief와 저장소 현실이 충돌하는 부분

정보가 충분하면 3~7단계 구현 계획을 제시하고 기다려라.

 

10.3 확인한 계획대로 구현할 때

승인한 계획대로 구현해라.

수정 허용: [경로]
변경 금지: [경로/동작]
완료 기준:
- [테스트 명령]
- [lint/typecheck/validator]
- [실제 UI/API/CLI 수동 QA]

실패하면 원인을 고치고 검증을 다시 실행해라.
완료 후 변경 파일, 실행 명령과 결과, 남은 위험만 보고해라.

 

10.4 Spark에 작은 수정 하나만 맡길 때

작업은 하나뿐이다: [작은 작업].

수정 범위: [한두 파일]
하지 말 것: 주변 리팩터링, 새 의존성, 관련 없는 포맷 변경
검증: [짧은 테스트/검색/화면 확인]

최소 diff로 처리해라. 테스트는 자동으로 생략하지 말고 위 검증을 실행해라.
완료 후 바뀐 줄과 검증 결과만 짧게 보고해라.

 

11. 자주 낭비한 패턴과 궁금한 점

토큰이 많이 든 작업을 되짚어보면 모델을 잘못 고른 경우보다, 목표와 범위를 대충 넘겨 같은 설명을 반복한 경우가 더 많았다. 내가 자주 했던 실수를 표로 정리해 보았다.

낭비	왜 낭비되는가	바꿀 방법
App이나 CLI부터 열고 “알아서” 시킨다	작업하면서 목표와 완료 조건을 계속 다시 묻게 된다.	Chat에서 원하는 결과와 범위를 먼저 정한다.
Chat 로그 전체를 복사한다	지금 작업과 상관없는 대화까지 함께 읽게 된다.	결정한 내용만 짧은 brief로 줄여 넘긴다.
Work와 Codex를 한도 분리용으로 왕복한다	같은 agentic pool을 사용한다.	필요한 결과가 문서인지 코드인지 보고 환경을 고른다.
모든 일을 Sol로 실행한다	작은 수정까지 긴 맥락과 높은 추론 비용을 유지한다.	범위가 분명한 일은 Terra나 Spark로 분리한다.
Spark에 “고쳐줘”만 쓴다	수정은 해도 테스트까지 알아서 실행하지 않는다.	고칠 파일과 실행할 테스트를 함께 적는다.
병렬 thread가 같은 파일을 고친다	나중에 변경을 합치며 충돌을 해결해야 한다.	담당 파일과 worktree를 미리 나눈다.

직접 써보니 토큰은 비싼 모델을 한 번 고른 것보다, 목표·범위·검증을 빼먹어 같은 작업을 다시 할 때 더 많이 샜다.

 

사용하면서 헷갈렸던 질문

Q1. ChatGPT Work는 Codex 한도와 같이 빠지는가?

그렇다. 현재 공식 문서에 따르면 Work와 Codex는 같은 agentic usage·credit pool을 사용한다. 다만 작업 크기와 복잡도, 선택한 모델, 실행 위치에 따라 실제 소모량은 달라질 수 있다.

Q2. 기획은 무조건 일반 Chat에서 해야 하나?

꼭 그렇지는 않다. 저장소와 상관없이 문제를 정리할 때는 Chat이 편하지만, 실제 파일 구조에 따라 계획이 달라진다면 처음부터 Codex Ask Mode에서 살펴보는 편이 정확하다.

Q3. Spark는 표준 한도를 전혀 쓰지 않는가?

공식 발표는 research preview 동안 자체 rate limit을 사용하고 표준 한도에는 포함되지 않는다고 설명한다. 하지만 별도 한도라고 해서 무료나 무제한은 아니다. 실제 사용 전에는 계정의 Usage 화면도 함께 확인하는 것이 좋다.

Q4. Chat 계획을 Codex로 자동 전송할 수 있는가?

모든 계정에서 통하는 범용 원클릭 전송 기능은 공식 문서에서 확인하지 못했다. 그래서 brief를 새 thread의 첫 메시지로 전달하거나 프로젝트 파일로 저장하는 방식을 사용하고 있다.

Q5. 반복 업무마다 별도 에이전트 프로젝트를 만들어야 하는가?

반복 규칙만 담은 프로젝트라면 AGENTS.md·skills·automations로 옮길 수 있는 부분이 많아졌다. 다만 독자적인 데이터 모델이나 제품 UI, 배포와 권한 체계가 필요하다면 별도 프로젝트로 유지할 이유가 충분하다. 기존 프로젝트를 한 번에 없애기보다 규칙, 연결, UI, 배포로 나누어 대체 가능한 부분부터 줄이는 편이 안전하다.

 

12. 처음 적용한다면 이 순서로

처음부터 작업 방식을 전부 바꿀 필요는 없다. 오늘 자주 맡기는 일 하나만 골라 아래 순서대로 해보면 Chat과 Codex를 어디에서 나눌지 금방 감이 온다.

오늘 바로 해볼 것

1. 반복해서 맡기는 작업 하나를 고른다.
2. Chat에서 원하는 결과, 범위, 기준 자료, 완료 조건을 정리한다.
3. brief.md를 만든다.
4. Codex Ask Mode에서 실제 파일 기준으로 계획을 보정한다.
5. 한 개의 작은 작업만 실행하고 테스트한다.

익숙해진 다음

• 자주 반복하는 규칙을 AGENTS.md로 옮긴다.
• 본 작업 중 발견한 작은 수정은 별도 작업 목록(task queue)으로 모은다.
• 어떤 일을 Spark에 맡길지 팀이나 개인 기준을 정한다.
• 완료 보고에는 테스트 결과와 아직 확인하지 못한 부분을 함께 남긴다.

반복 작업까지 이어갈 때

• 여러 thread를 함께 쓴다면 담당 파일과 worktree 규칙을 만든다.
• Usage 화면을 보며 작업별로 어떤 모델이 잘 맞았는지 간단히 기록한다.
• 직접 여러 번 성공한 작업만 skill이나 automation으로 옮긴다.

 

앞선 글에서 Sol·Terra·Luna를 비교했다면, 이번 글에서는 그 모델을 실제 일에 어떻게 나누어 붙일지 정리해 보았다. 직접 써보니 “무조건 Sol”보다 판단이 어려운 곳에는 Sol과 높은 추론 강도를 쓰고, 실제 파일 작업은 Codex로 넘긴 뒤, 범위가 작은 수정만 Spark로 빼는 방식이 나에게 가장 잘 맞았다.

 

토큰을 아끼는 특별한 공식이 따로 있는 것은 아니었다. brief를 짧게 남기고, 한 번에 맡길 범위를 나누고, 끝났는지 직접 확인하는 것. 이 세 가지만 지켜도 같은 작업을 다시 시키는 일이 많이 줄었다. : )

 

참고 자료

공식 문서

• OpenAI - GPT-5.6 공식 발표
• OpenAI Help - ChatGPT Work and Codex
• OpenAI Help - ChatGPT 플랜에서 Codex 사용하기
• OpenAI - GPT-5.3-Codex-Spark 발표
• OpenAI - How OpenAI uses Codex
• OpenAI Academy - Working with Codex
• OpenAI - Introducing the Codex app

커뮤니티·관련 글

• 갓대희 - GPT-5.6 리뷰: Sol vs Terra vs Luna