Codex 신규 기능으로 일하는 방식을 바꾸다 - 스레드 팀 구조 완전 정복

📺 원본 영상: 대부분 모르는 코덱스 신규 기능, 일하는 방식이 바뀝니다! 🎙️ 채널: 시민개발자 구씨 📅 정리 일자: 2026-06-06 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.


개요

Codex는 그동안 단일 스레드 안에서 리서치, 기획, 검토를 모두 처리하거나, 반대로 여러 스레드를 수동으로 나눠 관리해야 했다는 점에서 운용 효율의 한계가 있었다. 이번 업데이트는 그 문제를 정면으로 해결한다. Codex 스레드 내부에서 프롬프트만으로 다른 스레드를 생성하고 관리하는 기능이 추가된 것이다. 이 영상은 해당 기능을 활용해 복잡한 멀티스텝 업무를 마치 실제 팀 조직처럼 분업하고 조율하는 시스템을 구축하는 방법을 단계별로 시연한다.


Codex를 AI 조직으로 바라보기: 새로운 패러다임

강연자는 Codex를 단순한 바이브 코딩(vibe coding) 도구로 보는 시각에서 벗어나, AI 조직으로 재정의할 것을 제안한다. 이 개념의 핵심은 ‘부서를 나눠서 작업을 시킨다’는 것인데, 이는 실제 기업 조직 운영 방식과 직접적으로 맞닿아 있다.

구조는 단순하다. 최상단에 **팀장 스레드(Main Thread)**를 하나 두고, 이 스레드는 직접 리서치나 글쓰기를 수행하지 않는다. 대신 어떤 담당자 스레드에 어떤 업무를 시킬지 결정하고, 각 스레드에 지시를 내리고, 결과를 보고받아 최종적으로 사용자에게 전달하는 역할을 전담한다. 팀장 스레드 아래에는 리서치 방, 글쓰기 방, 이미지 제작 방 같은 담당자 스레드들이 배치된다. 각각의 스레드는 자신의 전문 영역에 집중하며, 필요에 따라 내부에서 서브 에이전트(sub-agent)를 추가로 호출해 작업을 더욱 세분화할 수도 있다.

팀장 방과 담당자 방의 조직 구조 다이어그램 - 리서치/글쓰기/이미지 방의 역할 분담

01:14 - 팀장 방과 담당자 방의 조직 구조 다이어그램 - 리서치/글쓰기/이미지 방의 역할 분담

이 구조가 이전 방식과 본질적으로 다른 점은 스레드 간 커뮤니케이션이 자동화된다는 데 있다. 각 담당자 스레드의 업무가 완료되면 팀장 스레드로 보고가 이루어지고, 팀장은 사용자의 피드백을 받아 다시 해당 스레드에 추가 작업을 지시하는 흐름이 자연스럽게 형성된다.


스레드 분리의 세 가지 판단 기준

강연자는 무조건적인 스레드 분리를 권장하지 않는다. 짧고 단순한 업무는 하나의 스레드에서 진행하는 것이 가장 빠르고 단순하다는 점을 명시적으로 인정한다. 그렇다면 언제 스레드를 나눠야 하는가?

첫째, 병렬 처리가 가능한 업무인지를 살펴봐야 한다. 리서치 작업처럼 여러 방면을 동시에 조사해도 무리가 없는 경우, 스레드를 나눠 병렬로 실행하면 최종 결과물을 더 빨리 받아볼 수 있다. 둘째, 일의 종류가 다른지를 확인해야 한다. 리서치, 글쓰기, 대시보드 제작은 각기 다른 특성과 전문성을 요구한다. 회사로 치면 팀이 다른 업무인 만큼, 스레드를 분리해 각 영역의 컨텍스트를 독립적으로 유지하는 것이 효율적이다. 셋째, 중간 결과물을 다음 단계에 넘겨야 하는지를 고려해야 한다. 리서치 결과를 바탕으로 글쓰기를 진행하는 것처럼, 단계별 핸드오프(handoff)가 필요한 업무라면 스레드를 나눔으로써 각 단계의 결과물을 명확히 관리할 수 있다. 이 세 가지 중 하나라도 해당된다면 스레드 분리를 적극적으로 검토할 만하다.


실전 데모: AI 트렌드 뉴스레터 제작

강연자는 이 구조를 검증하기 위해 **‘비개발자를 위한 AI 트렌드 뉴스레터 제작’**을 시나리오로 선택했다. 뉴스레터가 데모에 적합한 이유는 자료조사, 팩트 체크, 목차 작성, 글쓰기, 이미지 구성, 최종 HTML 패키징이라는 단계가 명확하게 구분되기 때문이다. 각 단계는 성격도 다르고 순차적 의존성도 가지며, 일부는 병렬 처리도 가능하다.

팀장 스레드 설정: 지휘 체계 구축

데모의 첫 단계는 로컬에 뉴스레터 프로젝트를 생성하고, 해당 프로젝트의 첫 번째 스레드를 팀장 방으로 지정하는 것이다. 팀장 스레드에 입력하는 프롬프트는 매우 구체적이다. 강연자는 “이 스레드는 프로젝트의 팀장 방이며, 직접 리서치하거나 글을 쓰지 말고 일은 담당자 방에 나눠서 맡기고, 지시·보고·취합·다음 단계 진행 결정만 담당한다”고 역할을 명확히 부여했다.

이에 더해 어떤 스레드를 어떻게 나눌지, 각 단계에서 언제 멈추고 사용자 확인을 받을지에 대한 게이트(gate) 설정과 보고 규칙도 프롬프트에 포함시켰다. 보고 규칙의 경우 “각 담당자 방은 결론을 먼저 제시하고 근거는 나중에 설명하라”는 방식으로 커뮤니케이션 효율을 높였다. 또한 이전 단계의 완료 여부를 폴링(polling)으로 체크하고, 완료되면 자동으로 보고하도록 설정했다.

💡 [영상 참조] 강연자는 이 시점에서 팀장 스레드에 입력한 전체 프롬프트 내용을 화면에 표시하며 설명합니다. 해당 프롬프트는 영상 설명란에 가이드 문서로 제공된다고 언급했습니다. 📺 원본 영상에서 확인하세요.

리서치 단계: 병렬 작업의 시작

팀장 스레드에 작업을 지시하자, Codex는 프로젝트 내에 리서치 스레드 3개를 자동으로 생성하고 병렬로 실행했다. 강연자에 따르면 Codex가 다른 스레드에서 요청을 보낼 때는 인터페이스에 “sent by Codex from another thread”라는 표시가 나타난다. 세 개의 리서치 스레드는 각각 뉴스 동향, AI 도구(Tools) 분석, 실전 사례(Use Cases) 리서치를 담당했다.

뉴스레터 프로젝트 안에 3개의 리서치 스레드가 병렬로 생성되는 화면

06:44 - 뉴스레터 프로젝트 안에 3개의 리서치 스레드가 병렬로 생성되는 화면

여기서 강연자가 강조한 중요한 포인트가 있다. 기존에는 이런 병렬 리서치를 서브 에이전트로 처리했는데, 서브 에이전트 방식은 나중에 작업 이력을 확인하기가 어렵다는 단점이 있었다. 반면 스레드를 나눠 진행하면 뉴스 리서치 내용은 ‘리서치 뉴스’ 탭에, 도구 분석은 ‘툴스’ 탭에, 사례 연구는 ‘유즈 케이스’ 탭에 영구적으로 보존된다. 이는 단순한 속도 향상이 아니라 **작업 이력 관리와 감사 가능성(auditability)**을 동시에 확보하는 방식이다.

리서치 결과 요약 보고에 따르면, AI 트렌드 측면에서는 AI의 흐름이 단순 챗봇(chatbot) 인터페이스 자체보다 검색, 광고, 쇼핑, 계약, 업무 자동화 안에서 능동적으로 행동하는 에이전트 방향으로 이동 중이라는 내용이 핵심 뉴스로 수집되었다. 도구 분석에서는 ChatGPT-4, Excel, Google Sheets, Canva, Claude for Business, Adobe Firefly 등이 리서치되었으며, 강연자의 추가 요청으로 Claude Code, Codex, [불명확] 에이전트에 대한 심층 리서치도 보완되었다.

팀장 스레드에서 3개 리서치 스레드의 결과를 취합 요약 보고하는 화면

08:07 - 팀장 스레드에서 3개 리서치 스레드의 결과를 취합 요약 보고하는 화면

폴링 주기에 대해 강연자는 실용적인 조언을 덧붙였다. 기본 설정에서 약 30초 간격으로 체크가 이루어졌는데, 작업의 유형에 따라 폴링 간격을 더 길게 설정해 불필요한 중간 보고 메시지를 줄일 수 있다.

팩트 체크와 아웃라인: 단계적 게이트 통과

리서치 단계에 만족하면 다음 단계로 진행해달라는 지시 하나로 팩트 체크 스레드가 자동 생성된다. 팀장 스레드는 검증 대상 파일을 첨부하고 “검증 원칙에 따라 내용을 검증하고 팩트 체크 문서를 생성해 달라”고 명확하게 업무를 위임했다. 사용자가 입력한 것은 단순히 “팩트 체크 진행해줘”라는 한 마디였지만, 팀장 스레드가 맥락을 이해하고 적절한 작업 위임 프롬프트를 스스로 생성했다는 점이 인상적이다.

팩트 체크 스레드 완료 후 검증 결과 문서를 확인하는 화면

10:28 - 팩트 체크 스레드 완료 후 검증 결과 문서를 확인하는 화면

팩트 체크가 완료된 후에는 아웃라인 단계로 넘어간다. 팀장 스레드는 팩트 체크를 통과한 자료만을 사용해 뉴스레터의 목차와 섹션 구조를 잡는 작업을 아웃라인 전용 스레드에 위임했다.

💡 [영상 참조] 강연자는 이 시점에서 아웃라인 스레드가 제시한 여러 제목 후보 중 하나를 선택하는 화면을 보여줍니다. 📺 원본 영상에서 확인하세요.

강연자가 선택한 최종 아웃라인 제목은 **“작은 회사가 봐야 할 AI 트렌드 - 대화형 검색부터 업무 에이전트까지”**였다. 이 제목을 기반으로 이후 단계가 진행되었다.

라이팅과 이미지: 또 한 번의 병렬 처리

아웃라인이 확정되자 팀장 스레드는 라이팅과 이미지 두 개의 스레드를 동시에 생성해 병렬로 작업을 진행했다.

라이팅과 이미지 스레드가 병렬로 생성되어 동시 작업 진행 중인 화면

12:19 - 라이팅과 이미지 스레드가 병렬로 생성되어 동시 작업 진행 중인 화면

라이팅 스레드는 뉴스레터의 실제 본문을 작성하고, 이미지 스레드는 실제 이미지를 생성하는 것이 아니라 히어로 이미지와 각 섹션에 어울리는 이미지에 대한 생성 프롬프트를 구조화하는 작업을 담당했다. 이 프롬프트 구조체를 별도의 이미지 생성 도구에 입력하면 실제 이미지를 완성할 수 있는 형태다.

라이팅 결과물에는 뉴스레터 본문과 함께 검증 출처 목록도 포함되었으며, 이미지 스레드 결과물에는 섹션별 이미지 생성 프롬프트가 체계적으로 정리되었다.

최종 뉴스레터 패키징: 팀장의 역할이 빛나는 순간

마지막 단계는 라이팅과 이미지 자료를 취합해 HTML 버전과 PDF 버전으로 최종 패키징하는 것이었다. 강연자는 이 과정에서 Codex 팀장 스레드가 진정한 팀장 역할을 수행하는 장면을 포착했다. 패키징 스레드에서 작업이 완료되었는데 design.md 파일이 반영되지 않은 것을 팀장 스레드가 스스로 감지하고, 루트 폴더가 아닌 다른 위치에 design.md가 존재한다는 사실을 확인한 뒤 패키징 스레드에 재작업을 자동으로 요청한 것이다. 사용자가 지시한 사항이 하위 스레드에서 누락되었을 때, 팀장이 이를 감지하고 수정 지시를 내리는 자동 품질 관리 루프가 작동한 셈이다.

최종 완성된 HTML 버전 뉴스레터 미리보기 - Claude 테마 디자인 적용

13:49 - 최종 완성된 HTML 버전 뉴스레터 미리보기 화면 - Claude 테마 디자인 적용


agents.md와 스킬: 워크플로의 시스템화

강연자는 이 스레드 구조를 매번 긴 프롬프트로 설정하는 방식이 비효율적이며 관리하기도 어렵다는 점을 지적한다. 이에 대한 해결책이 agents.md 파일이다. 오늘 시연에서 사용한 전체 업무 프로세스, 즉 스레드 구성, 게이트 설정, 보고 규칙, 단계별 작업 흐름을 agents.md 파일에 문서화해두면, 이후에는 단순히 “이번 주 뉴스레터 생성해줘”라는 한 마디 프롬프트만으로도 동일한 워크플로가 자동으로 실행된다.

agents.md 파일 생성 후 VSCode에서 워크플로 프로세스 문서 확인하는 화면

15:31 - agents.md 파일 생성 후 VSCode에서 워크플로 프로세스 문서 확인하는 화면

한 단계 더 나아가면 **스킬(Skill)**을 활용한 품질 관리가 가능해진다. 현재 시연에서는 각 담당자 스레드에 전달되는 세부 프롬프트를 Codex가 자체적으로 생성했다. 이미지 원칙이나 라이팅 가이드라인 같은 세부 지침도 Codex가 스스로 제안한 것이다. 하지만 더욱 일관된 결과물을 원한다면, 각 스레드의 작업 방식을 스킬로 미리 정의해두면 된다. 이미지 작업을 요청할 때는 ‘이미지 준비 스킬’을, 라이팅 작업을 요청할 때는 ‘라이팅 스킬’을 자동으로 활용하는 방식으로 설정하면, 각 담당자 스레드가 수행하는 작업의 품질과 일관성을 사용자가 훨씬 세밀하게 통제할 수 있다.


한계와 주의사항: 솔직한 평가

강연자는 이 기능의 유용성을 강조하면서도 현재의 한계를 솔직하게 공유한다. 첫째, 안정성 문제다. 테스트 과정에서 원하지 않는 세션이 백그라운드로 전환되거나, 모바일 연동 환경에서 스레드 생성 요청이 제대로 처리되지 않는 오류가 발생하기도 했다. 출시된 지 얼마 안 된 기능인 만큼 예상하지 못한 방식으로 스레드가 관리될 수 있다는 점을 감안해야 한다.

둘째, 추가 토큰 비용이다. 팀장 스레드가 주기적으로 폴링을 수행하고 중간 보고를 받는 과정에서 불가피하게 토큰이 소모된다. 강연자는 이를 실제 조직에서 관리자를 채용하는 비용에 비유했다. 관리자 한 명이 생기면 커뮤니케이션 비용은 줄지만, 그 관리자를 유지하는 데 드는 비용이 새로 발생하는 것과 같은 이치다. 따라서 이 구조는 업무의 복잡성과 규모가 충분히 클 때, 즉 병렬 처리의 이득과 컨텍스트 분리의 이득이 추가 토큰 비용을 상회할 때만 도입하는 것이 바람직하다.


마무리 / 핵심 정리

이 영상이 전달하는 핵심 메시지는 단순하다. Codex에서 복잡한 업무를 스레드로 쪼개서 진행하고, 메인 스레드에서 전체 프로세스를 관리하는 구조를 활용하면 기존의 단일 스레드 방식과는 질적으로 다른 생산성을 경험할 수 있다는 것이다.

메인 스레드에는 단계별 결과물과 피드백만 남고, 세부 실무 작업은 각각의 스레드에 격리되어 관리된다. 이 구조는 사용자가 세부 작업의 노이즈에 매몰되지 않고 전체 흐름을 조망하며 의사결정에 집중할 수 있도록 해준다. agents.md와 스킬을 결합하면 이 워크플로는 반복 가능하고 일관된 시스템으로 발전한다.

물론 모든 업무에 이 구조가 필요한 것은 아니다. 병렬 처리가 의미 있고, 업무 성격이 명확히 구분되며, 단계별 핸드오프가 필요한 업무일 때 이 접근이 비로소 진가를 발휘한다. 그 조건이 맞아떨어지는 순간, Codex는 단순한 AI 도구를 넘어 실제로 함께 일하는 AI 조직이 된다.


📚 출처 및 참고

구분내용
원본 영상대부분 모르는 코덱스 신규 기능, 일하는 방식이 바뀝니다!
채널시민개발자 구씨
리포트 작성2026-06-06
작성 방식YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.