Codex Has Left The Laptop

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Codex는 작업을 클라우드에서 이어가고 웹·모바일·협업 도구로 관리하면서, 노트북을 계속 켜 두어야 하는 개발 방식에서 벗어나도록 확장된다.

📌 핵심 요점

1. Codex Cloud는 장시간 실행되는 에이전트 작업을 노트북 밖으로 옮겨, 별도 개발 장비를 확보하고 유지하는 부담을 줄이는 방향으로 소개된다.
2. 클라우드 환경은 저장소와 의존성을 살펴 초기 설정을 준비하고, startup skill과 실행 스크립트를 생성한다. 파일 시스템 스냅샷과 백그라운드 업데이트는 환경 재사용을 돕는다.
3. 기존 플러그인을 활용한 Figma 디자인 구현과 테스트, Tailscale을 통한 비공개 API 접근, OIDC 지원이 소개된다. 다만 시연의 Linux 환경에서는 iOS 앱 실행과 테스트가 제한된다.
4. Space는 팀과 에이전트가 계획·진행 상황을 함께 관리하는 공간이다. dots는 개인의 지속 업무를 맡고, @ChatGPT는 공유 클라우드 환경을 이용한 팀 협업에 초점을 둔다.
5. 데스크톱의 PR 리뷰 기능, CLI의 병렬 작업 관리와 음성 기능, 웹의 클라우드 작업 접근을 통해 작업 지시·실행·검토를 여러 인터페이스에서 이어가는 흐름을 제시한다.

🧩 배경과 문제 정의

발표자 Dominic은 OpenAI의 개발자 경험 업무를 담당한다고 소개한다. 최근 다수의 기능이 추가되면서 개발 방식은 바뀌었지만, 이를 자신의 작업 흐름에 어떻게 적용할지 따라가기 어렵다는 문제에서 출발한다.

Codex 앱으로 여러 작업을 위임하기 쉬워지고, 모델이 컴퓨터 사용과 장시간 작업에 더 능숙해지면서 에이전트에게 맡기는 문제도 커졌다. 그 결과 노트북을 반쯤 열어 둔 채 이동하거나 Mac Mini·Raspberry Pi·VPS를 추가로 운영하는 상황이 생겼다고 설명한다. 장비가 늘면 업데이트, 저장 공간, 용량 확보 등 관리 부담도 함께 증가한다.

발표가 제시하는 방향은 익숙한 에이전트와 도구를 유지하면서 사용 인터페이스와 실행 장소를 선택하는 것이다. Codex Cloud, dots, 협업 도구 연동, Space, 리뷰 기능을 실제 개발 사례와 연결해 보여준다.

🕒 시간순 섹션별 상세정리

1. 기능 증가와 작업 흐름의 변화

• Dominic은 OpenAI의 개발자 경험 담당자로 자신을 소개하고, 앞서 발표된 약 20개 기능과 지난 1년간 출시한 약 300개 기능이 개발 방식을 바꿨다고 보여준다. [00:47]
• 기능을 따라가기 어렵고 실제 업무에 적용하는 방법도 혼란스러울 수 있어, 원하는 방식으로 어디서든 Codex를 쓰는 사례를 보여주겠다고 한다. [01:22]

2. 병렬 에이전트가 만든 장비 관리 부담

• 연초에는 한두 작업을 실행하는 것이 익숙했지만, Codex 앱이 위임과 작업 전환을 쉽게 만들면서 여러 에이전트의 동시 실행이 일반적인 사용 방식이 됐다고 보여준다. [01:54]
• 컴퓨터 사용과 장시간 작업 능력이 향상되면서 수시간 또는 수일이 필요한 더 큰 문제를 맡기게 됐고, 실행을 유지하려 노트북을 반쯤 열어 두거나 별도 장비를 운영하는 상황이 생겼다. [02:29]
• 장비가 늘수록 저장 공간·업데이트·처리 용량 관리와 추가 확보가 필요해진다. 발표자는 작업 위임이 단순한 지시만으로 가능해야 한다고 주장한다. [02:54]

3. 인터페이스와 실행 장소를 선택하는 방향

• Codex harness를 원하는 인터페이스에서 사용하고, 작업이 실행되는 장소도 선택해 각자의 필요에 맞는 흐름을 구성하는 것이 목표라고 보여준다. [03:15]
• Codex Cloud, dots, Slack·Teams의 @ChatGPT를 소개하며, 기존에 사용하던 같은 에이전트와 계정에 설치된 플러그인의 도구·정보를 활용한다고 드러낸다. [03:37]

4. 클라우드 환경 생성과 초기 설정 자동화

• 데스크톱 앱에서 로컬·원격 실행에 더해 클라우드 실행을 선택할 수 있고, 팀의 기존 환경을 사용하거나 새 환경을 만들 수 있다고 보여준다. [04:05]
• Blossom Music의 저장소 두 개를 선택하자 Codex가 저장소와 의존성을 조사하고, 프로젝트 작업에 필요한 준비를 시작한다. [04:39]
• 초기 설정 과정에서 환경 사용법을 설명하는 startup skill과 반복 실행을 돕는 startup script도 작성한다고 보여준다. [04:54]

5. 실행 환경의 제약과 재사용 최적화

• iOS와 웹 의존성을 함께 발견하지만, Linux 환경에서는 모바일 앱을 실행할 수 없다고 판단한다. 발표자는 이번 작업에서는 모바일 코드를 참조할 수 있으면 충분하다고 한다. [05:19]
• 향후 자체 클라우드 환경을 연결해 원하는 실행 방식에 맞출 수 있게 될 것이라고 보여준다. [05:33]
• 파일 시스템 스냅샷으로 후속 작업의 시작을 빠르게 하고, 백그라운드에서 최신 저장소 변경과 필요한 업데이트 스크립트를 반영한다고 드러낸다. [05:54]

6. Figma 기반 셰이더 구현과 결과 검토

• 앞서 요청한 작업은 앱 화면 자료를 받아 Figma 플러그인으로 디자인 정보를 가져오고, 셰이더를 구현·테스트한 뒤 영상을 생성한 사례다. 다만 현장에서는 영상이 바로 재생되지 않는다. [06:41]
• 같은 결과를 조정 가능한 playground 사이트로 배포해 실제 사이트 반영 전에 셰이더를 시험하고, 설정 변경을 앱 작업으로 다시 전달하는 흐름을 보여준다. [07:12]
• 클라우드 작업에서도 앱을 통해 변경 코드를 살펴보고 댓글을 남기거나, 해당 작업에 관한 질문을 이어갈 수 있다고 보여준다. [07:35]

7. 비공개 API 접근과 시연 중 장애

• 공개 인터넷에 노출되지 않은 Raspberry Pi의 API를 예로 들며, 클라우드 환경에 Tailscale VPN 접근을 설정해 내부 네트워크 리소스를 이용한다고 보여준다. OIDC를 통한 클라우드 리소스 접근 지원도 보여준다. [08:35]
• 노트북이 같은 Tailscale 네트워크에 연결되기 전에는 API가 응답하지 않고, 연결 후에는 응답하는 모습을 보여준다. [09:05]
• 클라우드 작업 화면에 문제가 생기자 기조연설 중 장애가 있었다고 언급하고, 이전에 실행한 동일 API 요청 결과로 내부 리소스 접근 사례를 보여준다. [09:36]

8. 환경 설정 보완과 노트북 밖의 작업 확인

• 초기 설정 결과는 iOS 변경을 테스트할 수 없지만 모바일 소스 편집은 가능하다고 설명하고, 설치 스크립트와 startup skill을 제안한다. 설정은 직접 수정하거나 Codex와 대화하며 계속 보완할 수 있다. [10:22]
• 네트워크 접근, 시크릿, 환경 변수를 설정하고 환경을 개인용 또는 팀 공유용으로 선택할 수 있다. 개인 vault에 저장된 변수는 팀과 공유되지 않는다고 보여준다. [10:49]
• 작업이 클라우드에서 실행되므로 노트북을 닫아도 휴대전화나 브라우저에서 계속 접근할 수 있다고 드러낸다. [11:02]

9. Slack 협업과 PR 리뷰 기능

• Slack에서 동료와 시각적 오류를 논의한 뒤 @ChatGPT에 조사를 요청하자, PR과 Figma 파일을 확인해 이미 해결용 PR이 있음을 발견한다. 공유된 클라우드 환경으로 변경을 테스트해 리뷰 가능한 상태로 진행한 사례를 보여준다. [12:03]
• 에이전트가 더 많은 코드를 작성하면서 리뷰에 쓰는 시간도 늘었다고 말하며, 데스크톱 앱의 리뷰 탭에서 자신에게 배정되거나 자신이 생성한 PR을 확인하는 기능을 보여준다. [12:24]
• 코드 확인, 댓글, 리뷰 제출, Codex 리뷰 실행에 더해 PR 내용과 부수 영향을 질문하고 이해한 뒤 피드백을 제출하는 흐름을 보여준다. [13:08]

10. Space에서 계획과 실행을 함께 관리

• Space는 팀과 에이전트가 함께 계획을 다듬는 공간으로 묶인다. API 레퍼런스 재설계 계획을 공유하고, 팀 피드백을 받으며 Codex에 시스템 다이어그램 추가를 요청한다. [13:55]
• 작업 추적표를 문서에 두고 Codex와 dots가 진행 정보를 갱신하게 해, 팀이 같은 상태를 파악하도록 하는 방식을 보여준다. [14:13]
• 계획이 만족스러우면 Codex에 구현을 맡기고, 작업 진행 정보를 문서로 계속 돌려보내도록 요청할 수 있다고 한다. [14:27]

11. dots의 지속 관찰과 작업 위임

• dots는 기존 Codex 작업을 관리하고 새 작업을 위임하는 동시에, 제품·엔지니어링 논의와 코드 변경을 살피며 필요할 때 작업을 시작하는 기능으로 드러난다. [15:03]
• 놓친 PR 태그를 dot이 Slack에서 알려주자, 발표자는 내용을 묻고 더 깊은 리뷰를 요청한다. dot은 클라우드 작업을 생성해 PR의 문제를 조사하고 결과를 보고한다. [15:49]
• 생성된 작업에는 이후 직접 들어가 추가 질문을 하거나 PR을 마무리하는 데 활용할 수 있다고 보여준다. [16:01]

12. dots와 @ChatGPT의 역할 구분, CLI 확장

• dots는 개인의 업무 맥락과 기억을 가진 확장으로 드러난다. 관심 채널을 관찰하고 허용받은 경우 의견을 내며, 지속 업무와 전달받은 작업을 맡는다. [17:00]
• @ChatGPT는 동료들이 같은 스레드에서 협업하는 용도다. 발표에서는 dot이 개인의 클라우드 환경과 로컬 Codex에 접근하는 반면, @ChatGPT는 공유 클라우드 환경에 접근한다고 구분한다. [17:28]
• CLI 개편에는 여러 작업을 관리하는 agent view, 병렬 실행, 플러그인 멘션, 이미지·텍스트 선택 개선, 다이어그램·LaTeX 표시, 음성 모드가 포함된다. 현장 단말의 마이크는 활성화되지 않아 음성 시연은 진행하지 못한다. [18:51]

13. 웹 사용과 세 가지 도입 제안

• Chrome에서 클라우드 작업, 앞서 생성한 영상, 배포 사이트와 dot에 접근하는 모습을 보여준다. 웹의 리뷰 탭은 가까운 시일 내 제공될 예정이라고 보여준다. [19:50]
• 개발이 개별 작업에서 더 큰 문제의 위임으로 이동했다고 정리하며, 모든 기능을 동시에 도입할 필요는 없다고 드러낸다. 장비 관리 부담에는 Cloud를, 팀과 에이전트의 계획·진행 공유에는 Space를 권한다. [21:21]
• 반복적으로 작업을 전달하는 대신 dot에 지속 책임을 맡겨 업무를 추적하고 진전시키라고 제안하며, 어디서든 Codex로 구상한 것을 만들라는 말로 마무리한다. [21:46]

🧾 결론

• 발표의 핵심은 작업을 지시하는 인터페이스와 실제 실행 장소를 선택할 수 있게 하는 것이다. 클라우드에서 실행되는 작업은 노트북을 닫아도 계속되고, 휴대전화나 브라우저로 확인할 수 있다.
• 재사용 가능한 환경, 공유 계획, 지속 업무를 맡는 dots가 연결되면서 개별 요청 중심의 사용에서 더 큰 문제를 장기간 위임하는 방식으로 확장된다.
• 에이전트가 작성하는 코드가 늘수록 검토 부담도 커진다는 문제가 함께 제기된다. PR 질문·댓글·리뷰 기능은 사람이 변경 내용과 영향을 이해하는 과정을 지원한다.
• 발표자는 모든 기능을 한꺼번에 도입하기보다, 장비 유지 부담에는 Cloud, 계획 공유에는 Space, 반복적인 업무 전달에는 dots를 시험해 보라고 권한다.

📈 투자·시사 포인트

• 개발 도구를 평가할 때 코드 생성 능력과 함께 실행 환경 준비, 장시간 작업 운영, 결과 검토까지 살펴볼 필요가 있다는 시사점을 준다.
• 같은 에이전트와 기존 플러그인을 여러 인터페이스에서 사용하는 구조는 계정에 축적된 도구와 업무 맥락의 재사용 가치를 보여준다. 실제 도입 효과는 팀의 기존 작업 흐름과 연결해 확인해야 한다.
• 클라우드 실행으로 줄일 수 있다는 장비 관리 부담과 새로 발생하는 서비스 비용을 함께 비교해야 한다. 영상에는 가격이나 정량적인 비용 절감 자료가 제시되지 않는다.
• 비공개 리소스 접근과 개인·팀 환경의 구분은 조직 도입에서 중요한 평가 항목이다. 시연만으로 권한 관리의 전체 범위나 운영 안정성을 판단하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• 발표 내용만으로 각 기능의 실제 제공 대상, 요금, 사용량 제한, 지역별 이용 가능 여부를 확인할 수 없다.
• 자체 클라우드 환경 연결은 향후 기능으로 설명됐고, 웹의 코드 리뷰 탭도 가까운 시일 내 제공될 예정으로 언급됐다. 시연 시점에 제공된 기능과 구분해야 한다.
• Linux 환경에서는 iOS 소스 편집은 가능하지만 앱 실행과 변경 사항 테스트는 할 수 없다고 설명한다. 프로젝트별 검증 가능 범위를 별도로 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 노트북이나 별도 개발 장비에서 계속 실행 중인 작업 하나를 골라, 클라우드 실행이 필요한 이유와 완료 기준을 정리한다.
• 시험 환경에서 생성된 startup skill과 설치·실행 스크립트를 검토하고, 필요한 의존성과 테스트가 실제로 동작하는지 확인한다.
• iOS처럼 환경 제약이 있는 프로젝트는 소스 편집과 실행·테스트 단계를 나누고, 별도 검증 장소를 정한다.
• 공유 환경과 개인 환경의 범위를 정하고, 네트워크 접근·시크릿·개인 vault 변수의 설정을 검토한다.

❓ 열린 질문

• 클라우드 실행 비용과 장비 유지 시간까지 포함하면, 어떤 작업 규모에서 도입 효과가 커지는가?
• 자체 클라우드 환경 연결은 언제 제공되며, 어떤 실행 환경과 검증 요구를 지원하게 되는가?
• 개인 맥락을 가진 dots와 팀 협업용 @ChatGPT 사이의 접근 범위는 실제 조직에서 어떻게 관리할 수 있는가?