스마트폰을 엔지니어링 컨트롤 플레인으로, OpenAI Codex Remote 모바일 활용 공식 가이드

9bow · 7월 21, 2026, 9:30오후

Codex Remote 소개

OpenAI의 코딩 에이전트 Codex는 이제 터미널(CLI), IDE 확장, 클라우드에 이어 ChatGPT 앱 안에서도 동작합니다. 그중 Remote는 ChatGPT 모바일 앱에서, 내 개발 머신 위에서 돌아가는 Codex 작업을 시작하고, 방향을 잡고, 검토하고, 정리하는 기능입니다. 이 글은 OpenAI가 직접 공개한, Remote를 "전화기로 코딩 채팅을 들여다보는 도구"가 아니라 진지한 엔지니어링 작업을 지휘하는 도구로 쓰는 방법을 정리한 필드 가이드입니다.

Remote는 얼핏 보면 과소평가하기 쉬운 기능입니다. 원문 저자의 표현을 빌리면, 처음 볼 때는 전화기로 코딩 채팅의 진행 상황을 확인하는 방법처럼 보이지만 그것은 더 큰 그림을 놓친 것입니다. 지난 몇 년간 코딩 도구의 무게 중심은 자동완성에서 출발해, 사람이 자리를 비운 사이에도 스스로 코드를 읽고 고치고 테스트를 돌리는 에이전틱 코딩(agentic coding) 으로 옮겨 왔습니다. 작업이 몇 초가 아니라 몇 분씩 이어지다 보니, 개발자가 늘 책상 앞 큰 화면에 붙어 있을 필요가 줄었습니다. 바로 이 지점에서 "어디서든 에이전트를 지휘한다"는 모바일의 가치가 생깁니다.

이 변화의 무게 중심은 도구의 지능보다 "실행의 길이"에 있습니다. 코딩 에이전트가 어떤 구성요소로 이루어지는지는 코딩 에이전트의 6가지 핵심 구성 요소를 다룬 글에 잘 정리되어 있는데, 요지는 에이전트가 한 번의 자동완성이 아니라 여러 턴에 걸친 자율 실행 루프로 동작한다는 점입니다. 루프가 길어질수록, 그것을 언제 멈추고 어디로 틀고 무엇을 승인할지 정하는 사람의 판단이 병목이 됩니다. Remote는 바로 그 판단을 책상 밖으로 끌어낸 결과물입니다.

지난 두 달 동안 OpenAI는 이 흐름에 놀라울 만큼 많은 깊이를 더했습니다. 원격 호스트 연결, 워크트리(worktree), 골(Goal), 사이드 챗(side chat), 인라인 코드 리뷰, 큐(Queue)와 스티어(Steer) 프롬프트, 첨부 파일, 스킬과 플러그인, 보관된 채팅, 보안 제어, 그리고 앱을 진짜 업무 도구로 만들어 주는 자잘한 디테일들이 그것입니다. 이 글은 그 기능들을 하나하나 짚어보면서, 어떻게 엮어야 매끄러운 하나의 작업 흐름이 되는지를 설명합니다.

올바른 멘탈 모델: 스마트폰은 컨트롤 플레인이다

핵심은 코드가 실행되는 곳과 그것을 지휘하는 곳을 분리하는 것입니다. 코드는 여전히 있어야 할 곳, 즉 여러분의 Mac이나 Windows 머신, 데브박스(devbox), 혹은 연결된 다른 호스트에서 돌아갑니다. ChatGPT 모바일 앱의 Remote는 그 작업을 제어하는 네이티브 인터페이스를 제공할 뿐입니다.

이 구분은 쿠버네티스(Kubernetes) 같은 인프라에서 말하는 컨트롤 플레인(control plane) 과 데이터 플레인(data plane) 의 구분과 닮았습니다. 실제 연산(트래픽)은 데이터 플레인에서 처리되고, 무엇을 어떻게 처리할지 결정하는 정책은 컨트롤 플레인이 담당합니다. Remote의 목표도 작은 화면에 터미널의 모든 기능을 우겨넣는 것이 아니라, 에이전트가 막혔을 때 그 병목을 푸는 결정을 어디서든 쉽게 내리도록 만드는 것입니다.

이것이 가능한 이유는 Remote가 원격 데스크톱처럼 화면 픽셀을 중계하는 방식이 아니라, Codex 작업을 실제로 구동하는 백엔드(이른바 App Server)와 구조화된 방식으로 통신하기 때문입니다. 이 App Server를 어떻게 만들었는지는 Codex 하네스의 비밀 풀기 구축기에 자세히 나와 있습니다. 덕분에 전화기는 diff, 승인 요청, 컨텍스트 사용량처럼 결정에 필요한 정보만 골라 받고, 무거운 연산은 호스트에 맡길 수 있습니다.

그 결정들은 대체로 다음과 같습니다.

어떤 저장소와 워크스페이스를 쓸 것인가?
현재 브랜치에서 돌릴 것인가, 새 워크트리에서 돌릴 것인가?
다음 메시지를 기다리게 할 것인가, 진행 중인 작업의 방향을 바꿀 것인가?
이 명령은 승인해도 안전한가?
무엇이 바뀌었고, 나는 그 변경에 동의하는가?
이건 지속적인 목표(goal)로 삼을 것인가, 별도 채팅으로 뺄 것인가, 아니면 가벼운 곁가지 질문으로 둘 것인가?

이런 방식으로 앱을 쓰기 시작하면, Remote는 원격 데스크톱 소프트웨어가 아니라 하나의 엔지니어링 컨트롤 플레인처럼 느껴지기 시작합니다.

1. 올바른 경계부터 설정하고 대화를 시작하기

좋은 에이전트 작업은 올바르게 범위가 잡힌 환경에서 시작합니다. Remote에서는 첫 프롬프트를 보내기 전에 연결된 호스트와 워크스페이스를 고를 수 있습니다. 새 채팅이라면 브랜치를 선택하고, 별도의 Git 워크트리(worktree)를 만들고, 그 워크트리에 연결된 환경 설정(environment setup)을 실행하는 것까지 가능합니다.

이런 선택이 몇 가지 유용한 패턴을 만들어 냅니다.

빠른 조사에는 현재 체크아웃을 그대로 사용합니다.
격리되어야 할 변경에는 새 워크트리를 만듭니다.
Git 상태를 나중에 바로잡는 대신, 처음부터 의도한 베이스 브랜치에서 시작합니다.
Codex에게 빌드나 테스트를 시키기 전에 환경 설정이 먼저 돌도록 합니다.

이것이 파워 유저의 가장 중요한 습관 중 하나입니다. 저자는 이를 한 문장으로 요약합니다. "올바른 실행 컨텍스트를 고르는 데 10초를 쓰면, 나중에 정리하는 데 드는 10분을 아낀다."

작성창(composer)은 단순 텍스트보다 더 많은 맥락을 실어 나를 수 있습니다. 파일이나 사진을 첨부하거나, 그 자리에서 카메라로 찍은 화면을 붙일 수 있습니다. 스킬(skill)과 플러그인(plugin)은 작성창에 인라인으로 표시되어, 내가 의도한 기능을 프롬프트가 정말로 호출하고 있는지 확인하기가 훨씬 쉬워집니다.

저자의 규칙은 단순합니다. "스크린샷, 파일, 혹은 이름 붙은 스킬 하나가 모호함을 없앨 수 있다면, 첫 턴을 보내기 전에 그것을 첨부하거나 언급하라." Codex의 스킬과 플러그인 생태계가 최근 어떻게 확장되었는지는 OpenAI가 공개한 플러그인, 사이트, 주석 기능 소개에서 더 자세히 볼 수 있습니다.

2. 큐(Queue)와 스티어(Steer)의 차이를 익히기

이것은 아마 Remote에서 가장 눈에 잘 띄지 않으면서도 영향력이 큰 설정일 것입니다. Codex가 이미 작업 중일 때, 후속 프롬프트는 두 가지 중 하나로 동작할 수 있습니다.

큐(Queue): 현재 응답이 끝날 때까지 기다렸다가, 여러분의 프롬프트를 다음 턴으로 보냅니다.
스티어(Steer): 이미 진행 중인 작업에 지침을 주입합니다.

큐는 안전한 기본값입니다. 두 번째 작업, 추가 테스트 요청처럼 현재 작업이 끝난 뒤에 일어나야 할 일에 사용합니다. 반면 스티어는 잘못된 방향으로 계속 가는 비용이 아직 커지고 있을 때 방향을 바로잡기 위한 것입니다. 예를 들면 다음과 같은 개입입니다.

수정은 모바일 패키지 안에서만 해라. 공유 렌더러(shared renderer)는 리팩터링하지 마라.

재현은 재연결(reconnect) 이후에만 발생한다. 라이브 경로가 아니라 재개된(resumed) 경로를 테스트해라.

UI 조사는 멈춰라. 재개 과정에서 서버가 항목을 제거했는지부터 확인해라.

이 기능은 전화기를 단순한 상태 표시 화면 이상으로 만들어 줍니다. 실행에 판단이 필요한 바로 그 순간에 개입할 수 있기 때문입니다. 기본 후속 동작은 설정에서 고를 수 있는데, 저자는 큐를 기본값으로 두고 스티어는 의도적으로만 사용합니다. 실수로 턴 중간에 방향을 틀어버리는 비용이 대개 기다리는 비용보다 크기 때문입니다.

3. 사이드 챗(Side Chat)을 생각의 곁가지로 쓰기

오래 이어진 코딩 채팅에는 값진 맥락이 쌓입니다. 곁가지 질문이 생길 때마다 메인 대화를 끊으면 본 기록이 어수선해지고, 에이전트가 목표에서 멀어질 수 있습니다. 사이드 챗은 바로 이 문제를 풉니다.

/side 로 현재 채팅에 연결된 가벼운 대화를 열 수 있습니다. /side <프롬프트> 처럼 질문을 미리 담아 열 수도 있습니다. 더 좋은 방법은 기록에서 텍스트를 선택한 뒤 사이드 챗에서 묻기(Ask in side chat) 를 고르는 것입니다. 선택한 구절이 그대로 새 대화의 출발 맥락이 됩니다.

저자가 사이드 챗을 쓰는 질문들은 이런 것입니다.

Codex는 왜 이 아키텍처를 골랐을까?
이 오류는 실제로 무슨 뜻일까?
이 동작이 데스크톱 앱과 일관적인가?
이 구현 세부사항을 릴리스 노트 버전으로 정리해줘.
이 명령을 승인하기 전에 무엇을 확인해야 할까?

구분은 유용합니다. "메인 채팅은 작업을 소유하고, 사이드 챗은 그 작업을 이해하도록 돕는다."

4. 경로는 플랜(Plan)으로, 결과는 골(Goal)으로

플랜 모드와 골은 서로 다른 문제를 풉니다. 플랜 모드(Plan mode) 는 코드를 바꾸기 전에 Codex가 구현 경로를 먼저 제안하도록 합니다. 작업이 불명확하거나, 위험하거나, 여러 시스템을 건드릴 가능성이 있을 때 유용합니다.

반면 골(Goal) 은 지속적입니다. 여러 턴에 걸쳐 계속 추구해야 할 결과가 무엇인지 Codex에게 알려줍니다. 모바일에서는 /goal 로 그 목표를 만들고 관리하며, 작업이 진행되는 동안 진척 상황이 계속 보입니다.

실전에서 유용한 패턴은 이렇습니다.

위험한 변경은 플랜 모드로 시작합니다.
제안된 경계(boundary)를 살펴봅니다.
여러 번의 반복이 필요한 작업이라면, 합의된 결과를 골로 전환합니다.
목표를 매번 다시 말하지 않고도 Codex가 구현, 테스트, 리뷰 반영, 정리까지 이어가게 둡니다.

한마디로, "플랜은 어떻게 접근할 것인가에 답하고, 골은 무엇이 참이어야 끝난 것인가에 답한다"고 정리할 수 있습니다.

5. 대화를 떠나지 않고 코드 리뷰하기

리뷰 루프야말로 Remote가 단순히 편리한 도구를 넘어 진짜 엔지니어링 도구가 되는 지점입니다.

완료된 턴은 변경된 파일 요약을 보여줄 수 있습니다. 거기서 diff를 열고, 개별 파일을 살펴보고, 섹션을 펼치거나 접고, 긴 줄을 줄바꿈하고, 문법 강조가 적용된 소스 파일을 열 수 있습니다. 해당 줄에 인라인 코멘트를 달아 그 리뷰 맥락을 Codex에게 다시 보내는 것도 가능합니다.

이 워크플로우에는 여러 단계의 깊이가 있습니다.

변경 파일 요약을 열어 빠르게 온전성을 점검합니다.
diff에 주변 맥락이 부족하면 전체 소스로 넘어갑니다.
정확한 수정을 위해 인라인 코멘트를 답니다.
리뷰 명령으로 로컬 변경을 검토하거나 특정 브랜치와 비교합니다.
Codex가 특정 파일을 두고 추론하길 원하면 그 파일을 채팅에 연결합니다.

그 결과 다음과 같은 촘촘한 모바일 리뷰 루프가 가능해집니다.

Codex가 구현을 마칩니다.
나는 전화기에서 diff를 살펴봅니다.
인라인 코멘트를 두 개 답니다.
Codex가 같은 채팅에서 그것들을 반영합니다.
나는 더 작아진 후속 diff를 리뷰합니다.

중요한 점은 전화기가 깊은 코드 정독을 위해 큰 모니터를 대체한다는 것이 아닙니다. 그렇지 않습니다. 핵심은 많은 리뷰가 한두 개의 결정에서 막혀 있고, 이제 그 결정을 책상에 돌아올 때까지 미룰 필요가 없다는 것입니다.

6. 권한(Permissions)을 워크플로우의 일부로 다루기

원격 작업은 통제가 명시적으로 유지될 때만 유용합니다. Remote는 명령, 파일 변경, 네트워크 접근, 연결된 도구에 대한 승인 요청을 표면으로 끌어올립니다. 요청의 성격과 호스트 설정에 따라, 승인은 한 번만 적용될 수도, 현재 채팅에만 적용될 수도, 더 넓게 적용될 수도 있습니다.

파워 유저의 선택은 모든 것을 승인하는 것이 아니라, 작업을 계속 굴러가게 하는 가장 좁은 권한을 고르는 것입니다. 신뢰할 수 있는 채팅에서 잘 이해된 명령이라면, 채팅 범위 승인이 반복적인 방해를 없애줍니다. 반대로 낯선 명령이거나, 민감한 저장소이거나, 효과가 불분명한 요청이라면 한 번만 승인하거나, 아예 거부한 뒤 Codex에게 설명을 요구하거나 더 안전한 방법을 쓰라고 요청합니다. 작업을 시작하는 시점에 그 채팅의 더 넓은 승인 동작을 미리 정해 둘 수도 있습니다. 이 승인 정책은 호스트, 워크스페이스, 브랜치, 모델과 나란히 놓인 채팅 설정의 일부로 생각하는 편이 좋습니다.

7. 문제가 되기 전에 컨텍스트를 관리하기

에이전트 채팅은 상태를 가지며(stateful), 긴 채팅은 결국 느려지거나 초점이 흐려질 만큼 맥락이 쌓입니다. Remote에는 그 생애주기를 관리하는 작은 도구 모음이 있습니다.

/status 는 세션 정보, 워크스페이스, 컨텍스트 사용량, 그리고 사용 가능한 레이트 리밋(rate limit) 정보를 보여줍니다.
선택적 컨텍스트 표시기는 작성창에 남은 컨텍스트를 계속 보이게 합니다.
/compact 는 유용한 작업 상태는 보존하면서 지나치게 커진 채팅을 압축합니다.
/fork 는 기록은 공유하되 다른 방향으로 가고 싶을 때 현재 채팅에서 새 채팅을 만듭니다.

실전 순서는 이렇습니다. "상태를 확인하고, 목표가 그대로면 압축하고, 목표가 갈라졌으면 포크한다." 사이드 챗과 포크를 혼동해서는 안 됩니다. 사이드 챗은 현재 작업 주위의 가벼운 질문이고, 포크는 원래 채팅의 기록을 물려받은 새로운 주(主) 채팅입니다.

8. 깔끔한 대화 목록 유지하기

저자 자신의 Codex 워크플로우는 점점 작은 운영 데스크(operations desk)처럼 변해 갑니다. 활발히 움직이는 몇 개의 채팅을 고정(pin)하고, 결과 중심으로 이름을 바꾸며, 작업이 끝나면 공격적으로 보관(archive)합니다. 보관된 채팅을 다시 둘러볼 수 있으므로 이 정리는 안전합니다. "보관은 삭제가 아니라 정리"이기 때문입니다.

알림도 이 시스템의 일부입니다. 완료 알림은 관련 Codex 채팅을 바로 열어주므로, "에이전트가 끝났다"에서 "사람이 리뷰한다"로 넘어가는 인계가 한 번의 탭으로 끝납니다. 스포트라이트(Spotlight)와 단축어(Shortcuts) 앱으로 Remote를 곧장 열 수도 있습니다. 아이패드에서는 키보드 단축키 덕분에 앱이 놀랄 만큼 효율적입니다. 새 채팅 만들기, 채팅 간 이동, 변경 파일 열기, 고정, 이름 변경, 보관을 매번 컨트롤에 손을 뻗지 않고도 처리할 수 있습니다.

이것이 Remote의 "비서실장(chief of staff)" 활용 사례입니다. 앱은 프롬프트를 던지는 곳일 뿐 아니라, 어떤 엔지니어링 작업이 진행 중이고, 막혀 있고, 리뷰를 기다리고, 끝났는지를 한눈에 파악하는 곳이 됩니다.

한눈에 보는 선택 지도, 언제 무엇을 쓸까

지금까지의 기법을 관통하는 것은 결국 세 가지 갈림길입니다. 컨트롤 플레인에서 내리는 결정이 대부분 이 셋으로 수렴하므로, 앞에서 다룬 대비를 한 장으로 정리하면 다음과 같습니다.

갈림길	선택 A	선택 B	고르는 기준
진행 중인 작업에 후속 지시	큐(Queue), 다음 턴으로 대기	스티어(Steer), 지금 작업에 주입	잘못된 방향으로 가는 비용이 커지는 중이면 스티어, 그 외에는 큐
작업을 시작하는 방식	플랜(Plan), 구현 경로를 먼저 제안	골(Goal), 지속 추구할 결과를 설정	"어떻게 접근하지?" 면 플랜, "무엇이 참이어야 끝이지?" 면 골
대화를 나누는 방식	사이드 챗(Side chat), 가벼운 곁가지 질문	포크(Fork), 기록을 물려받은 새 주 채팅	현재 작업을 이해하려는 것이면 사이드 챗, 방향이 갈라지면 포크

숨은 명령 팔레트, 슬래시(/)로 여는 지름길

/ 를 입력하면 앱의 고급 동작 상당수로 가는 가장 빠른 경로가 드러납니다. 사용 가능 여부는 연결된 호스트, 앱 버전, 계정 설정에 따라 달라질 수 있습니다.

명령어	용도
`/plan`	구현 전에 플랜 모드를 켜고 끕니다.
`/goal <목표>`	지속적인 목표를 생성하거나 갱신합니다.
`/side [질문]`	메인 채팅을 방해하지 않고 곁가지 질문을 합니다.
`/review`	로컬 변경을 검토하거나 브랜치와 비교합니다.
`/status`	세션, 워크스페이스, 컨텍스트, 레이트 리밋을 확인합니다.
`/compact`	긴 채팅의 컨텍스트를 압축합니다.
`/fork`	현재 기록에서 새 주 채팅을 만듭니다.
`/fast`	가능할 때 표준 실행과 빠른 실행을 전환합니다.
`/feedback`	현재 세션에 연결된 제품 피드백을 보냅니다.

명령 팔레트를 익힐 가치가 있는 이유는, 그것이 제품의 진짜 개념 모델을 그대로 드러내기 때문입니다. 계획하고(Plan), 추구하고(pursue), 갈라지고(branch), 리뷰하고(review), 들여다보고(inspect), 복구하는(recover) 것입니다.

모바일에서 특히 잘 통하는 5가지 워크플로우

앞의 기능들은 따로 쓸 때보다 하나의 시나리오로 엮을 때 진가를 발휘합니다. 저자가 모바일에서 특히 잘 통한다고 꼽은 다섯 가지 워크플로우는 다음과 같습니다.

릴리스 캡틴 (The release captain)

릴리스나 풀 리퀘스트(pull request)를 위한 전용 채팅을 시작합니다. Codex에게 현재 브랜치, CI 상태, 열린 리뷰 피드백, 릴리스 포함 여부를 확인하게 합니다. 그 채팅을 고정해 둡니다. 새 정보가 들어오면 진행 중인 조사를 무효화하는 경우에만 스티어하고, 그 외에는 큐에 넣습니다. 최종 diff나 릴리스 노트를 전화기에서 리뷰하고, 릴리스가 안착하면 채팅을 보관합니다.

인터럽트 기반 버그 수정 (The interrupt-driven bug fix)

스크린샷, 로그, 캡처한 파일을 첨부합니다. Codex에게 편집 전에 먼저 진단하게 합니다. 사이드 챗으로 의심스러운 오류 하나를, 메인 조사에서 벗어나지 않으면서 캐묻습니다. 원인이 분명해지면 메인 채팅으로 돌아와 좁은 범위의 수정을 승인합니다.

모바일 리뷰어 (The mobile reviewer)

의도한 브랜치를 대상으로 리뷰를 돌리고, 변경 파일 요약을 살펴보고, 중요한 파일을 열고, 인라인 코멘트를 답니다. Codex에게 그 코멘트만 반영하게 한 뒤, 후속 diff를 리뷰합니다.

장기 목표 (The long-running objective)

구체적인 완료 조건을 가진 골을 만듭니다. 테스트 통과, 리뷰 피드백 해소, 혹은 재현 가능한 성능 기준 달성 같은 것입니다. "다 됐어?"를 반복해서 묻는 대신 알림과 상태로 진척을 확인합니다. 추가 작업에는 큐 프롬프트를 쓰고, 스티어는 교정을 위해 아껴 둡니다.

멀티 머신 운영자 (The multi-machine operator)

호스트 이름을 명확하게 두고, 작업을 머신과 워크스페이스별로 정리합니다. 올바른 체크아웃, 자격 증명, 시뮬레이터, 운영체제를 가진 머신에서 채팅을 시작할 때 전화기를 씁니다. 한 채팅은 Mac이 필요하고 다른 채팅은 Windows 호스트가 필요할 때 특히 유용합니다.

작지만 큰 영향을 주는 기능들

저자가 가장 좋아하는 추가 기능 몇 가지는 헤드라인급 기능이 아닙니다.

수정 턴을 새로 추가하는 대신, 마지막으로 보낸 프롬프트를 직접 편집합니다.
채팅의 렌더링된 이미지를 저장하거나 복사합니다.
Codex가 아직 실행 중일 때 큐에 든 프롬프트를 확인합니다.
알림에서 완료된 채팅을 바로 엽니다.
활성 목록을 붐비게 두지 않고 보관된 채팅을 둘러봅니다.
좁은 화면에서 읽을 때 긴 diff 줄을 줄바꿈합니다.
Face ID나 기기 암호로 ChatGPT 모바일 앱을 보호합니다.
보내기 전에 작성창에서 스킬과 플러그인을 인라인으로 확인합니다.
실물 객체가 맥락일 때 사진을 프롬프트에 바로 촬영해 넣습니다.
질문을 다시 설명하는 대신, 선택한 기록 텍스트에서 사이드 챗을 시작합니다.

이 중 어떤 것도 근본적인 에이전트 모델을 바꾸지는 않습니다. 하지만 함께 모이면, 원격 워크플로우를 취약하게 느끼게 만들던 마찰을 걷어냅니다.

더 큰 교훈

최고의 모바일 소프트웨어는 데스크톱 인터페이스를 그저 축소하지 않습니다. 책상을 떠나 있을 때 정말로 중요한 결정이 무엇인지 짚어내고, 그 결정을 빠르고, 읽기 쉽고, 안전하게 내리도록 만듭니다.

이것이 저자가 지금 Remote를 바라보는 방식입니다. Remote는 올바른 환경을 고르고, 목표를 세우고, 실행의 방향을 틀고, 승인에 답하고, 결과를 살펴보고, 엔지니어링 작업의 전체 큐를 일관되게 유지할 수 있는 곳입니다. 저자의 마지막 문장이 이 모든 것을 압축합니다. "컴퓨터는 여전히 일을 하고, 전화기는 나를 통제의 자리에 둔다."

이 사고방식은 특정 도구에 한정되지 않습니다. Claude Code를 비롯한 다른 에이전틱 코딩 도구를 쓰는 개발자에게도, "무엇을 실행하느냐"만큼이나 "어디서 어떻게 그 실행을 지휘하느냐"가 생산성을 가른다는 점은 똑같이 유효합니다.

Mastering remote engineering work from your phone 원문 블로그

Codex 공식 문서

OpenAI Codex CLI GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~