AI 코딩 도구를 본격적으로 쓰기 시작하면 누구나 같은 벽에 부딪힌다. 작업이 하나둘 늘어나면서 대화창이 뒤섞이고, 어제 어디까지 진행했는지 찾기 어려워지며, 새 작업을 시작할 때마다 같은 맥락을 다시 설명해야 한다. 터미널 기반 도구에서는 세션을 닫는 순간 쌓아둔 컨텍스트가 사라지기도 한다. 이런 비효율을 정면으로 겨냥한 것이 OpenAI Codex 앱에 추가된 스레드(Threads) 생성·관리 기능이다.
핵심은 단순하다. Codex에게 "스레드를 직접 만들고 관리해 달라"고 맡길 수 있게 된 것이다. 하나의 메인 스레드가 전체 작업의 관제탑 역할을 하면서, 새 프로젝트가 생기면 별도 작업 스레드를 만들고, 각 스레드의 진행 상황을 확인하며, 필요한 정보를 전달한다. 사용자 사이에서 화제가 된 활용법이 바로 메인 스레드를 하나의 Chief of Staff(비서실장)처럼 운영하는 방식이다.
이 문서는 Codex 스레드 기능이 정확히 무엇이고, 어떤 업데이트로 들어왔으며, AI 코딩에서 왜 필요한지, 로컬·워크트리·클라우드 모드가 어떻게 다른지, 핀·검색·자동화를 어떻게 엮어 쓰는지, 그리고 실제 사용자들이 어떤 반응을 보였는지를 한 번에 정리한다. Codex를 막 시작한 사람도 따라갈 수 있도록 개념부터 풀어서 설명한다.
1. 스레드가 무엇이고 왜 핵심인가
Codex 앱은 IDE처럼 생긴 데스크톱 프로그램이다. 왼쪽에 프로젝트 사이드바가 있고, 그 안에 여러 개의 스레드가 들어간다. 가장 윗단위가 프로젝트이고, 각 프로젝트 안에서 스레드를 만든다. 스레드 하나가 곧 에이전트 인스턴스 하나다. 터미널에서 codex 명령을 한 번 실행하는 것이 스레드 하나에 해당한다고 보면 된다.
터미널 도구와의 가장 큰 차이는 지속성이다. Codex 앱을 강제 종료했다가 다시 열어도 모든 스레드와 그동안 쌓인 컨텍스트가 캐시되어 그대로 남아 있다. 터미널에서는 탭을 닫으면 맥락이 날아가지만, 앱에서는 특정 작업을 위해 투자한 컨텍스트가 보존된다. 사이드바에서 어떤 스레드가 로컬인지, 클라우드 실행인지, 워크트리인지 한눈에 구분된다.
1.1. 스레드 관리가 기능으로 들어온 변화
- 기존에는 사용자가 직접 스레드를 열고 닫으며 수동으로 관리해야 했다.
- 이제 Codex에게 자연어로 "관련 스레드를 찾아줘", "기존 스레드를 이어서 진행해줘", "이 스레드를 핀(고정)하거나 보관(아카이브)해줘" 같은 지시를 맡길 수 있다.
- 별도 백그라운드 스레드가 필요하면 명시적으로 요청한다. 예를 들어 이 프로젝트의 워크트리에 테스트를 갱신하는 백그라운드 스레드를 따로 만들어 달라고 지시하면 된다.
- 2026년 5월 업데이트(Windows 26.527 등)에서 로컬 프로젝트와 워크트리를 위한 스레드 코디네이션이 정식으로 추가되었고, 명시적으로 요청할 때 분리된 백그라운드 스레드를 생성하도록 동작이 확장되었다.
핵심 포인트: 스레드 기능의 본질은 "맥락의 분리와 보존"이다. 작업마다 별도 스레드로 컨텍스트를 격리하면 한 대화가 다른 대화를 오염시키지 않고, 종료 후에도 맥락이 살아 있어 다시 설명하는 비용이 사라진다. AI 코딩에서 컨텍스트는 곧 결과의 품질이다.
2. AI 코딩에서 스레드가 필요한 이유
AI 코딩에서 가장 자주 언급되는 문제가 컨텍스트 로트(context rot)다. 하나의 대화에 잡다한 작업과 노이즈가 쌓이면 모델이 핵심을 놓치고 엉뚱한 방향으로 흐른다. 스레드 분리는 이 문제를 구조적으로 막는 장치다.
실무에서 권장되는 운영 원칙은 명확하다. 한 스레드에 한 작업(one thread, one task)을 지키면 범위가 좁아져 결과가 깔끔해진다. 제품 개발, 콘텐츠 작성, 리서치, 버그 수정처럼 성격이 다른 작업은 각각 별도 스레드에서 진행하는 편이 낫다. 메인 스레드는 전체 진행 상황을 관리하는 프로젝트 매니저 역할을 맡는다.
2.1. 컨텍스트 보호와 병렬 처리
- 컨텍스트 보호: 소음이 많은 작업, 즉 메인 흐름을 어지럽힐 만한 작업은 서브 스레드로 떼어내고 결과만 보고받는다. 메인 스레드를 깨끗하게 유지하는 것이 목적이다.
- 병렬 처리: 여러 작업을 동시에 돌릴 수 있다. 리서치를 하는 서브 작업은 가벼운 모델로, 핵심 계획을 세우는 메인 스레드는 풀 모델로 두는 식으로 연산을 작업 난이도에 맞춰 배분한다.
- 컨텍스트 정리: 스레드가 길어지면 압축 명령으로 맥락을 다듬고, 분기(fork)로 곁가지 탐색을 따로 떼어 메인 스레드 오염을 막는다.
아래 표는 터미널 세션과 Codex 앱 스레드의 차이를 정리한 것이다.
| 구분 | 터미널 세션 | Codex 앱 스레드 |
|---|---|---|
| 지속성 | 닫으면 컨텍스트 소멸 | 종료 후에도 캐시되어 유지 |
| 시각적 구분 | 텍스트 위주 | 로컬·클라우드·워크트리 구분 표시 |
| 관리 방식 | 사용자가 직접 | Codex에게 위임 가능(찾기·이어가기·핀·보관) |
| 병렬 작업 | 탭 수동 관리 | 사이드바에서 병렬 가시화 |
| 리뷰 | 별도 도구 필요 | 인라인 diff·리뷰 패널 내장 |
3. 메인 스레드를 Chief of Staff로 만드는 법
사용자 사이에서 가장 화제가 된 활용법이 메인 스레드를 Chief of Staff(비서실장)로 세우는 방식이다. 메인 스레드에게 전체 작업을 조율하는 역할을 부여하고, 새 프로젝트가 생기면 직접 작업 스레드를 만들게 한 뒤, 각 스레드 진행 상황을 점검하고 필요한 정보를 전달하도록 맡기는 구성이다.
예를 들어 제품 개발, 콘텐츠 작성, 리서치, 버그 수정을 각각 별도 스레드에서 진행하고, 메인 스레드는 이 모든 작업의 상태를 종합 관리하는 프로젝트 매니저로 둔다. 일부 사용자는 여기에 스레드 자동화를 결합해 30분마다 Chief of Staff 스레드를 깨워, 자리를 비운 사이 가장 느린 단계인 컨텍스트 수집을 미리 끝내 두게 한다. 돌아오면 무엇을 출시할지 판단만 하면 되는 구조다.
3.1. 실제 구성 흐름
- 데스크톱 앱을 설치하고, 작업에 필요한 플러그인·스킬을 붙인다.
- 메인 스레드에 비서실장 역할을 지시하는 프롬프트를 넣어 오케스트레이션과 판단을 맡긴다.
- 메인 스레드는 직접 판단하지 않아도 되는 실무를 서브 스레드로 분배하고, 그 결과만 받아 종합한다.
- 장기 작업에는 스레드 자동화를 걸어 주기적으로 같은 대화로 복귀하며 상태를 갱신하게 한다.
X(트위터)에서 공유된 한 운영자는 이를 "하나의 메인 팀원 스레드 + 몇 개의 장수(長壽) 서브에이전트 스레드" 구조로 설명했다. 메인 스레드는 오케스트레이션과 판단을, 서브에이전트는 실제 실행을 담당한다. 판단과 실행을 분리한다는 점이 이 방식의 핵심이다.
4. 로컬·워크트리·클라우드 모드의 차이
스레드를 만들 때 실행 모드를 선택한다. 각 모드는 작업 위치와 격리 수준이 다르다.
| 모드 | 실행 위치 | 특징 | 적합한 상황 |
|---|---|---|---|
| 로컬(Local) | 내 컴퓨터, 현재 프로젝트 디렉터리 | 가장 단순, 현재 작업에 직접 반영 | 일반적인 단일 작업 |
| 워크트리(Worktree) | 내 컴퓨터, 분리된 Git worktree | 현재 작업을 건드리지 않고 격리 | 병렬 작업, 위험한 시도 |
| 클라우드(Cloud) | OpenAI 원격 환경 | 노트북을 닫아도 진행, GitHub 연결 필요 | 장시간·원격 실행 |
워크트리는 현재 브랜치를 별도의 Git worktree로 복제해 두 개의 병렬 로컬 환경을 만든다. 같은 코드베이스에서 두 에이전트를 돌려도 서로 파일을 건드리지 않는다. 새 아이디어를 현재 작업에 영향 없이 시험하거나, 독립적인 작업을 나란히 돌릴 때 적합하다. 자동화는 Git 저장소의 경우 전용 백그라운드 워크트리에서, 버전 관리되지 않는 프로젝트는 프로젝트 디렉터리에서 직접 실행된다.
클라우드는 실행을 OpenAI 서버로 보낸다. 작업을 시작해 두고 노트북을 닫았다가 돌아와 이어받을 수 있다. 다만 GitHub 연결이 전제이고, 워크플로가 GitHub로 푸시하는 흐름을 중심으로 돈다는 점이 로컬 철학과 다르다.
핵심 포인트: 같은 파일을 동시에 편집하는 두 스레드는 충돌을 부른다. 병렬로 파일을 손봐야 한다면 같은 브랜치에서 스레드를 둘로 나누지 말고 워크트리를 써서 환경을 분리하는 것이 안전하다.
5. 핀·검색·자동화로 스레드를 엮기
스레드가 많아지면 관리 자체가 일이 된다. Codex는 이를 위한 보조 기능을 함께 갖췄다.
핀(고정)은 중요한 스레드를 사이드바 상단에 묶어 두는 기능이다. 핀 고정된 스레드는 지속적인 작업 컨텍스트로 쓰이기 때문에, 사용자들은 데스크톱과 모바일 간 핀 상태 동기화가 되어야 중요한 세션을 잃지 않는다는 요청을 활발히 내고 있다.
검색은 최근 추가되며 빠르게 강화된 부분이다. 과거 Codex 앱 스레드를 검색하는 기능과 사이드바 단축, 최근 스레드로 점프하는 키보드 단축키가 들어왔고, 이후 검색 범위가 대화 내용과 Git 브랜치 이름까지 확장되었다. CLI 쪽에서도 로컬 대화 기록 전반에 대한 대소문자 무시 검색과 결과 미리보기가 추가되었다.
5.1. 자동화와의 결합
- 스레드 자동화(thread automation): 특정 스레드에 붙는 반복 호출이다. 스레드의 컨텍스트를 보존한 채 주기적으로 깨어나 장기 작업을 점검하거나, 소스를 폴링해 새 정보를 가져오거나, 후속 루프를 이어간다. 다음 실행이 현재 대화에 의존할 때 쓴다.
- 독립·프로젝트 자동화: 매번 새로 시작하는 반복 작업에 쓴다. 하나 이상의 프로젝트에 대해 신선한 작업을 주기적으로 돌릴 때 적합하다.
- 자동화의 강점은 해당 프로젝트에 쌓아 둔 스킬과 컨텍스트를 그대로 활용한다는 점이다. 다만 로컬 자동화는 컴퓨터가 켜져 있어야 하고, 켜 두지 않아도 되는 경우엔 클라우드 자동화를 쓴다.
6. 실제 사용자 반응과 한계
실사용 평가는 대체로 우호적이되 도구 철학에 따라 갈린다. 한 상세 가이드 작성자는 "개인적으로는 여전히 터미널을 선호하지만, 대다수 사용자에게는 버튼과 미리보기가 있는 앱 방식이 이긴다고 본다"고 평했다. 거대한 diff를 터미널에서 검토하는 고통을 떠올리면 Codex의 시각적 리뷰 패널이 분명한 강점이라는 것이다.
Claude Code에서 넘어온 사용자들은 처음엔 "느리고 자신감이 없으며 머뭇거린다"고 느끼지만 적응하면 "코드 리뷰와 스킬 활용 면에서 뛰어나다"는 평이 많다. Codex가 주변에 구성한 스킬과 하네스를 알아서 활용해 매번 떠밀지 않아도 된다는 점을 장점으로 꼽는다.
반면 명확한 한계와 불만도 있다. 한 커뮤니티 보고에 따르면 특정 업데이트 이후 새 스레드가 약 4만 입력 토큰으로 시작해, 기존 스레드는 괜찮은데 새 스레드의 초기 토큰 소모가 문제라는 지적이 나왔다. 또한 새 스레드가 General, 홈/프로젝트 미지정, 특정 프로젝트 중 어디서 시작되는지 흐름이 불명확하고 되돌리기 어렵다는 개선 요청, 핀 상태가 기기 간 동기화되지 않는다는 요청, 스레드 제목과 대화 내용을 아우르는 전역 검색이 필요하다는 요청 등이 GitHub 이슈로 올라와 있다.
6.1. 도입 전 점검할 것
- 모드 선택 기준: 단순 작업은 로컬, 병렬·실험은 워크트리, 장시간·원격은 클라우드로 나눈다.
- 토큰 비용: 새 스레드의 초기 컨텍스트 비용을 고려해 무분별하게 스레드를 양산하지 않는다.
- 검증 기준: 각 스레드에 "무엇이 끝나면 완료인지"를 명시해 에이전트가 스스로 점검하게 한다.
- 권한 설정: 안전한 명령은 미리 승인해 두면 에이전트가 더 오래 자율 실행하며 레버리지가 커진다.
7. 마무리
위에서 살펴본 Codex 스레드 기능의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- 스레드는 Codex 앱의 작업 단위이며, 하나가 곧 에이전트 인스턴스다. 종료 후에도 컨텍스트가 보존되는 지속성이 터미널과의 결정적 차이다.
- 2026년 5월 업데이트로 로컬·워크트리 스레드 코디네이션이 정식 추가되어, Codex에게 스레드 찾기·이어가기·핀·보관·백그라운드 생성을 자연어로 맡길 수 있다.
- 메인 스레드를 Chief of Staff로 두고 작업별 서브 스레드를 분배·관리하는 운영법이 화제이며, 판단과 실행을 분리하는 것이 핵심이다.
- 로컬·워크트리·클라우드 모드는 실행 위치와 격리 수준이 다르므로 작업 성격에 맞춰 선택해야 한다.
- 핀·검색·자동화를 결합하면 다수 스레드를 효율적으로 운영할 수 있고, 특히 스레드 자동화는 컨텍스트를 보존한 채 장기 작업을 이어간다.
- 시각적 리뷰와 스킬 활용은 강점이지만, 새 스레드 초기 토큰 소모, 핀 동기화 미흡, 신규 스레드 시작 위치의 불명확함 등은 개선이 진행 중인 한계다.
도입을 고민한다면, 먼저 한 프로젝트 안에서 한 스레드 한 작업 원칙으로 작업을 분리해 보고, 익숙해지면 메인 스레드를 비서실장으로 세워 서브 스레드를 위임하는 구조로 확장하는 것이 안전한 순서다. 병렬 편집이 필요하면 같은 브랜치에서 스레드를 나누지 말고 워크트리를 쓰고, 장시간 작업은 클라우드 모드와 스레드 자동화로 넘기는 것이 효율적인 선택이다.
자주 묻는 질문
- Codex 스레드 기능은 정확히 무엇인가요?
Codex 앱에서 작업의 기본 단위인 스레드를 생성하고 관리하는 기능입니다. 스레드 하나가 에이전트 인스턴스 하나에 해당하며, 2026년 5월 업데이트로 로컬·워크트리 스레드 코디네이션이 정식 추가되어 Codex에게 관련 스레드 찾기, 기존 스레드 이어가기, 핀 고정, 보관, 별도 백그라운드 스레드 생성을 자연어로 맡길 수 있게 되었습니다.
- 메인 스레드를 Chief of Staff로 쓴다는 게 무슨 의미인가요?
하나의 메인 스레드에 전체 작업을 조율하는 비서실장 역할을 부여하는 방식입니다. 새 프로젝트가 생기면 직접 작업 스레드를 만들게 하고, 각 스레드의 진행 상황을 점검하며 필요한 정보를 전달하도록 맡깁니다. 제품 개발, 콘텐츠 작성, 리서치, 버그 수정 같은 작업을 각각 별도 스레드에서 진행하고 메인 스레드가 프로젝트 매니저처럼 전체를 관리하는 구성으로, 판단과 실행을 분리하는 것이 핵심입니다.
- AI 코딩에서 스레드를 분리하면 무엇이 좋아지나요?
가장 큰 이점은 컨텍스트 로트를 막는 것입니다. 한 대화에 잡다한 작업이 쌓이면 모델이 핵심을 놓치는데, 한 스레드에 한 작업 원칙으로 분리하면 범위가 좁아져 결과가 깔끔해집니다. 소음이 많은 작업을 서브 스레드로 떼어내 메인 스레드를 깨끗하게 유지하고, 여러 작업을 병렬로 돌리며, 종료 후에도 컨텍스트가 보존되어 다시 설명하는 비용이 사라집니다.
- 로컬, 워크트리, 클라우드 모드는 어떻게 다른가요?
로컬은 내 컴퓨터의 현재 프로젝트 디렉터리에서 직접 작업해 가장 단순합니다. 워크트리는 현재 브랜치를 별도 Git worktree로 복제해 현재 작업을 건드리지 않고 격리하므로 병렬 작업이나 위험한 시도에 적합합니다. 클라우드는 OpenAI 원격 환경에서 실행되어 노트북을 닫아도 진행되지만 GitHub 연결이 필요합니다.
- 스레드 자동화는 일반 자동화와 무엇이 다른가요?
스레드 자동화는 특정 스레드에 붙어 그 컨텍스트를 보존한 채 주기적으로 깨어나는 반복 호출입니다. 장기 작업을 점검하거나 소스를 폴링해 새 정보를 가져오거나 후속 루프를 이어갈 때, 즉 다음 실행이 현재 대화에 의존할 때 씁니다. 반면 독립·프로젝트 자동화는 매번 새로 시작하는 반복 작업에 쓰며 신선한 작업을 주기적으로 돌립니다.
- Codex 스레드 기능에 한계나 불만은 없나요?
있습니다. 특정 업데이트 이후 새 스레드가 약 4만 입력 토큰으로 시작해 초기 토큰 소모가 크다는 지적이 나왔고, 핀 상태가 데스크톱과 모바일 간 동기화되지 않는다는 요청, 새 스레드가 어디서 시작되는지 흐름이 불명확하고 되돌리기 어렵다는 개선 요청, 스레드 제목과 대화 내용을 아우르는 전역 검색이 필요하다는 요청 등이 GitHub 이슈로 올라와 있습니다.