[한영자막] Codex로 요리하기 — OpenAI의 Charlie Guo와 Gabriel Chua

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenAI의 Charlie Guo와 Gabriel Chua가 보여주는 ‘Codex로 요리하기’의 핵심은 충분한 맥락과 검증 가능한 목표를 제공해 앱 제작, 원격 작업, 반복 자동화를 연결하는 것이다.

📌 핵심 요점

1. 좋은 결과는 맥락 전달에서 시작한다. 문서·대화·이메일·화면에 흩어진 정보를 제공하고 원하는 결과를 명확히 설명해야 한다. Appshot은 화면과 텍스트를 함께 전달하며, 메모리와 Chronicle은 선호와 활동을 지속적인 맥락으로 활용한다.
2. 플러그인은 개발 지식과 실행 도구를 묶는다. 스킬·앱·MCP 서버를 결합해 팀 지침과 외부 연결을 재사용한다. Slack 대화에서 출발한 실시간 번역 앱은 4분 2초 만에 제작됐지만, 이후 오디오 설정과 실제 실행을 별도로 점검했다.
3. 실행 수단은 작업 환경에 맞춰 선택한다. Codex Remote는 모바일에서 노트북이나 서버의 작업을 이어간다. 내장 브라우저는 웹 앱의 세밀한 시험에, Computer Use는 API가 없는 소프트웨어 조작에, Chrome 확장 프로그램은 로그인된 브라우저 상태를 활용하는 작업에 적합하다.
4. 장시간 작업에는 목표 관리와 검증이 필요하다. 구체적인 완료 기준, 진행 대시보드, 별도 리뷰·목표 감사 스레드로 작업 이탈을 확인한다. 원격 개발 스레드가 로컬 브라우저 검증을 요청하거나, 사용자가 사이드 스레드에서 차단 요인을 해결하는 방식도 제시된다.
5. 개별 요청은 반복 실행과 제품 통합으로 확장된다. 훅은 정해진 시점의 검사와 정리를 수행하고, 하트비트는 같은 스레드에서 상태를 반복 확인한다. 실행마다 새 스레드를 만드는 예약 자동화도 있으며, 앱 서버는 Codex의 핵심 실행 기능을 자체 제품에 연결한다.

🧩 배경과 문제 정의

• Codex 활용은 코드 작성에서 음악 플러그인, 영상 편집, 게임, 자율주행 골프 카트 제작까지 넓어지고 있다. 여러 스레드와 하위 에이전트는 서로 다른 작업을 나누고 결과를 확인하는 데 활용된다.
• 작업에 필요한 맥락은 코드 저장소뿐 아니라 대화, 이메일, 문서, 화면, 개인의 선호에도 흩어져 있다. 이 정보를 반복해서 설명하는 부담을 줄이는 것이 중요한 과제다.
• 결과물 제작을 넘어 API가 없는 소프트웨어 조작, 이동 중 원격 작업, 복잡한 장기 작업까지 연결하려면 맥락 전달과 실행 수단을 작업에 맞게 선택해야 한다.

🕒 시간순 섹션별 상세정리

1. 음악·영상·게임으로 넓어진 Codex 활용

• 한 세션에서 거의 300개의 하위 에이전트를 사용한 사례와 Ableton용 신시사이저 플러그인 제작, Premiere를 조작하는 영상 편집 사례가 있다. [01:22]
• 게임 제작에서는 오디오, 아트, 게임 규칙, 난이도 조정을 서로 다른 스레드와 하위 에이전트에 나누고 완성된 게임을 점검할 수 있다. 자율주행 골프 카트 제작도 활용 사례에 포함된다. [02:05]

2. 모바일과 오픈소스로 확장되는 작업 장소

• 모바일 Codex는 신칸센으로 이동하거나 개를 산책시키는 동안에도 아이디어와 작업을 이어갈 수 있게 한다. 오픈소스와 앱 서버를 이용하면 기존 앱 밖의 기기에도 Codex를 넣을 수 있다. [03:00]
• 다른 에이전트에서 사용하던 설정을 가져와 시작할 수 있어 기존 작업 환경을 옮기는 부담을 줄인다. [03:19]

3. 맥락 전달부터 반복 작업과 제품 통합까지의 작업 방식

• Record and Replay는 버튼 조작을 말로 설명하는 대신 직접 보여주어 맥락을 전달한다. 스레드 핸드오프는 클라우드·원격·로컬 사이에서 작업을 옮기며, 일반 공개된 모바일 앱은 기기 간 일대일 페어링을 제공한다. [04:00]
• 문서, 생각, 대화, 이메일, Notion, Linear 등에 있는 맥락을 먼저 제공하고 그 정보를 바탕으로 결과물을 만드는 것이 기본 단계다. [05:19]

4. Appshot으로 Slack 대화를 실시간 번역 앱의 요구사항으로 전달

• Slack에서 나온 실시간 번역기 아이디어에 GPT Realtime Translate와 macOS 개발 플러그인을 결합하고, 해당 대화를 Appshot으로 전달해 앱 제작을 요청한다. [07:03]
• Appshot은 화면 이미지와 함께 텍스트도 포함하므로 대화와 브레인스토밍 내용을 다시 설명하지 않고 작업 맥락으로 사용할 수 있다. [07:24]

5. 저장소의 변경 이력을 공유 가능한 Sites로 전환

• Sites는 Enterprise와 Business 요금제에 프리뷰로 제공된 기능으로, 팀에 공유할 간단한 사이트를 만든다. Agents SDK 예시에는 샌드박스 에이전트, 도구로 사용하는 Codex, 도구 검색, 실시간 에이전트 등의 변경 사항과 코드 예제가 담긴다. [08:15]
• 큰 코드베이스의 커밋과 변경 이력을 맥락으로 제공하면 이를 설명하는 공유용 결과물 제작으로 연결할 수 있다. [08:32]

6. Codex Remote로 휴대전화에서 저장소 작업 실행

• ChatGPT 모바일 앱의 Codex Remote는 노트북이나 원격 서버에 연결해 명령을 실행한다. 예시에서는 Agents SDK 저장소의 기본 구성 요소가 어떻게 연결되는지 IKEA 설명서 스타일로 시각화하도록 요청한다. [09:41]
• 노트북을 켜둔 상태에서 Codex가 백그라운드 작업을 이어가므로 사용자는 컴퓨터 앞에 계속 머무르지 않고 모바일로 진행 상황을 확인할 수 있다. [10:01]

7. 플러그인으로 개발 지식·외부 연결·반복 절차를 묶기

• 플러그인은 모범 사례와 팀별 지침을 담은 스킬, 외부 서비스 연결을 제공하는 앱, 필요한 도구를 제공하는 MCP 서버를 하나로 묶는다. [10:58]
• macOS 개발 플러그인은 AppKit, Liquid Glass, 앱 서명과 검사에 관한 지침을 제공한다. OpenAI Developers 플러그인은 필요할 때 API 키를 직접 생성해 개발 흐름 중 수동 설정을 줄인다. [12:00]

8. 빠른 앱 제작 이후에도 남는 실제 실행 점검

• 실시간 번역 앱은 4분 2초 만에 만들어졌으며 독일어 번역 시험을 준비한다. macOS 앱 제작 경험이 없는 경우에도 플러그인의 개발 지침을 활용해 구현을 진행할 수 있다. [12:51]
• 실제 시험에서는 입력·출력 오디오 설정을 바꾸고 여러 차례 마이크를 확인한다. 앱이 만들어진 뒤에도 현장 장치 설정과 실행 동작을 점검해야 한다. [14:18]

9. 메모리·Chronicle·사용자 지침으로 지속되는 맥락

• 메모리는 기본적으로 꺼져 있으며, 활성화하면 Python 패키지 관리에 uv를 선호하는 것처럼 대화에서 드러난 사용자 선호를 시간이 지나면서 학습할 수 있다. [15:25]
• Pro 구독자용 연구 프리뷰인 Chronicle은 화면과 활동도 맥락으로 활용한다. 실패한 GitLab·GitHub 파이프라인을 보고 있을 때 “왜 실패했는가”라고 물으면 해당 화면을 문제 분석에 연결할 수 있다. [15:46]

10. 외부 서비스·음성·화면을 활용한 맥락 전달의 효율과 비용

• Slack, Gmail, Linear 같은 외부 서비스를 연결하면 읽지 않은 Slack 메시지를 확인해 하루의 업무 의제를 만드는 작업을 요청할 수 있다. [17:12]
• 음성 입력은 생각을 길게 풀어 설명하는 데 유용하며, 모든 단어를 완벽하게 다듬지 않아도 모델이 대체로 의도를 파악할 수 있다는 평가다. Appshot으로 Slack이나 브라우저 화면을 전달하는 방식도 개인 경험상 90% 이상 적절한 작업으로 이어졌다고 한다. [18:26]

11. Sites·코드 리뷰·문서로 결과물의 활용 범위 확장

• Sites는 행사 내용을 조직에 공유하거나 오프사이트 후보 장소의 장단점을 비교하는 데 쓰인다. 작업 결과를 전달하는 것뿐 아니라 의사결정을 돕는 결과물도 만들 수 있다. [19:21]
• /code review로 커밋하지 않은 변경 사항을 검토하는 작업을 시작할 수 있다. 실시간 번역 앱에도 이 검토를 적용한다. [19:58]

12. API 없는 대시보드에서 기간별 데이터를 직접 내려받기

• 오래된 기업 소프트웨어나 대시보드에는 API가 없을 수 있으며, 기간과 데이터 종류를 바꾸며 내려받으려면 많은 버튼 조작이 필요하다. Computer Use는 이러한 화면 조작을 대신하는 수단이다. [21:27]
• 예시에서는 최근 7일의 커밋 수를 CSV로, 월초부터 당일까지의 풀 리퀘스트 데이터를 JSON으로 내려받도록 요청한다. 두 데이터에 서로 다른 기간과 파일 형식을 적용해야 한다. [22:15]

13. Chrome에서 필수 응답 조건을 포함한 피드백 폼 만들기

• Google Docs에 작성된 질문을 바탕으로 피드백 폼을 만들고 모든 질문을 필수 항목으로 지정하도록 요청한다. 질문과 선택지를 옮기고 필수 여부를 설정하는 반복 조작을 맡기는 작업이다. [24:26]
• Chrome 확장 프로그램이 실제 브라우저 탭을 조작해 폼을 만드는 동안, 사용자는 다른 스레드에서 Codex 메모리에 사용되는 모델과 설정 항목을 질문한다. 화면 조작과 별도의 조사 작업을 동시에 진행할 수 있다. [25:21]

14. 내장 브라우저·Computer Use·Chrome 확장 프로그램의 선택 기준

• 내장 브라우저는 브라우저 엔진에 더 깊게 접근할 수 있어 로컬 웹 앱의 화면 배치, 렌더링, 상호작용을 자세히 시험하는 데 적합하다. [26:24]
• Computer Use는 프로그래밍 인터페이스를 쉽게 제공하지 않는 데스크톱 앱이나 오래된 소프트웨어를 사람이 쓰는 방식으로 조작할 때 유용하다. [27:01]

15. 장시간 실행되는 작업에 구체적인 제품 요구사항 부여

• 복잡한 리팩터링과 장기 작업의 예시로 전날 시작한 네 가지 작업이 준비돼 있다. 그중 원격 인스턴스의 한 목표는 시연 시점에 15시간 30분 55초 동안 실행 중이다. [29:06]
• 해당 작업은 약 400명이 있는 행사장의 실시간 Q&A 사이트를 만드는 신규 프로젝트다. 관리자·참가자·무대용 화면, AI 생성 태그, 조정 기능, 16:9 화면과 Moderation API 사용 등의 요구사항을 포함한다. [29:16]

16. 프롬프트의 핵심은 특별한 문구보다 명확한 맥락이다

• Codex는 사용자의 의도를 저절로 알 수 없으므로 원하는 결과를 명확히 지시해야 한다. 추론 모델에서는 이른바 마법의 문구보다 충분한 맥락이 중요하다는 관점이다. [30:01]
• 휴대전화로 말한 요구사항을 Codex에 다듬게 한 프롬프트로 피드백 폼을 만들었다. Convex 플러그인은 실시간 상호작용에 활용했고, OpenAI 플러그인도 사용했다. [30:24]

17. 기존 프로젝트 개조와 연구 코드 재구현도 장시간 작업에 포함된다

• 오픈소스 폼 빌더를 내부용으로 바꾸는 작업은 5시간 57초 동안 실행됐다. 소규모 팀이 ChatGPT 인증을 이용해 팀 내부에서만 사용하는 폼 빌더를 갖추는 구상이다. [30:54]
• 대학원 시절 연구 논문과 Julia·R로 작성된 코드를 바탕으로 Rust 백엔드를 갖춘 Python 패키지를 만드는 작업은 약 7시간 1분 40초 동안 실행됐다. 동적 계획법을 쓰지 않고 휴리스틱을 사용하라는 제약을 주었고, Codex가 논문을 읽고 구현했다. [31:26]

18. 목표 목록과 별도 검토 스레드로 장시간 작업을 관리한다

• define goal 스킬을 활용해 하나의 목표 대신 여러 목표를 Markdown 파일에 정리하고, 진행 상황을 확인할 HTML 대시보드를 만들게 했다. 여러 시간 동안 진행되는 작업의 상태를 사용자가 직접 확인하기 위한 장치다. [32:05]
• 주요 마일스톤에서는 별도 스레드가 코드 리뷰와 목표 감사를 수행했다. 최초 목표에서 벗어났는지 확인하고, 이탈이 있으면 메인 스레드에 원래 목표를 상기시키거나 계획 재검토를 요구했다. [32:33]

19. 원격 개발 스레드가 로컬 브라우저 검증을 요청한다

• 원격에서 실행 중인 라이브 Q&A 사이트 작업은 사용자 컴퓨터에 로컬 스레드를 생성해 Chrome 확장 프로그램으로 화면을 검사하게 했다. 로컬 스레드는 클릭 조작과 브라우저 QA를 수행하고 결과를 원격 스레드로 돌려보냈다. [33:10]

20. Slack과 사이드 스레드로 진행 상태를 확인하고 방향을 수정한다

• Slack 플러그인으로 완료한 일, 남은 일, 차단 요인을 지정된 스레드에 보고하게 했다. 사용자는 외출 중에도 인증 문제나 API 키 부족처럼 직접 해결해야 할 사항을 확인할 수 있었다. [33:53]
• 사이드 스레드에서는 최근 작업, 다음 계획, 사용자 도움이 필요한 사항을 물을 수 있다. 자격 증명이 이미 준비돼 있다는 확인이나 작업 방향 수정도 메인 스레드에 전달할 수 있다. [34:39]

21. 로컬 검증과 하위 에이전트가 실제 사용자 흐름과 UI 피드백을 확인한다

• 원격 서비스에 있는 메인 스레드는 로컬 메인 스레드에 Chrome 검증을 요청했다. 클라우드에서 개발이 진행되는 동안 노트북의 Chrome으로 폼 생성 과정을 끝까지 실행해 실제 폼을 만들었다. [36:04]
• 채팅 인터페이스가 좋지 않다는 사용자 피드백은 메인 에이전트에서 기존 하위 에이전트로 전달됐다. 새 스크린샷과 지시를 검증 작업에 반영하도록 요청해 역할별 맥락을 분리하면서 수정 방향을 공유했다. [37:04]

22. 진행 대시보드와 인증 절차로 차단된 작업을 재개한다

• 목표 대시보드는 완료·진행·미착수 마일스톤과 스레드별 역할을 보여줬다. 메인 조정, 소통, 시각적 UX, 앱 서버 프로토콜 같은 역할뿐 아니라 인증·테스트·UI 다듬기 등의 작업 흐름도 구분했다. [38:34]
• Convex와 Vercel에 접근할 인증 정보가 없어 핵심 경로가 막히자 Codex는 가능한 작업을 먼저 수행하고 차단 상태를 표시했다. 사용자는 사이드 채팅에서 원인과 해결 절차를 확인한 뒤 CLI 로그인 흐름으로 원격 Codex에 Vercel 접근 권한을 제공했다. [39:09]

23. 내부 폼 빌더는 작성부터 공유·응답 확인까지 연결한다

• 기존 저장소를 개조한 내부 폼 빌더에서는 초안 작성, 미리보기, 게시 링크 복사와 공유가 가능했다. ChatGPT 워크스페이스 접근 권한이 있는 팀원이 폼에 접근해 응답하고, 응답 결과도 확인할 수 있었다. [40:37]
• Rust 백엔드 패키지 재구현, 신규 라이브 Q&A 사이트 개발, 기존 오픈소스 폼 빌더 개조의 세 사례에서 Codex가 요청한 작업을 수행했다. [41:33]

24. 컨텍스트 압축이 여러 시간에 걸친 작업을 뒷받침한다

• 장시간 작업 중에는 컨텍스트 창을 여러 번 압축한다. GPT 5.1 Codex Max는 압축 과정을 통해 여러 컨텍스트 창에 걸쳐 작업하도록 학습됐으며, 이를 장시간 실행을 뒷받침하는 기술로 보여준다. [42:09]
• 여러 번 압축하는 긴 스레드에서도 문제가 거의 없었다거나 내용을 덜 잊는다는 사용자 평가가 소개됐다. 필요한 정보만 유지하는 방식이 토큰 효율에도 도움이 될 수 있다는 해석은 추정 수준으로 제시됐다. [42:40]

25. Goal에는 구체적이고 검증 가능한 완료 기준이 필요하다

• 이미 15시간 동안 실행 중인 목표 사례와 함께, 모델이 완료 여부를 판단할 기준을 구체적이고 검증 가능하게 정해야 한다는 원칙이 제시됐다. 기준이 불충분하면 요청을 기술적으로 충족해도 사용자가 기대한 방식과 다른 결과가 나올 수 있다. [43:19]
• Goal은 매 턴 성공 기준에 비추어 완료 여부를 평가하고, 미완료라면 계속 진행할지 판단한다. 40시간 동안 네이티브 Swift로 Doom을 재구현한 사례가 있으며, 코드 마이그레이션·대규모 리팩터링·반복 실험·상세 사양을 갖춘 앱 개발도 활용 대상으로 거론됐다. [44:02]

26. 하위 에이전트와 스레드 간 위임은 사용자가 볼 필요에 따라 선택한다

• 하위 에이전트에는 코드 리뷰어·문서 조사자 같은 역할과 별도 지시를 지정할 수 있다. 빠른 경량 모델을 쓸지, 더 철저한 검토를 위한 모델을 쓸지도 설정할 수 있다. [44:45]
• 하위 에이전트는 모델이 위임 작업을 관리하고 맥락을 분리하기에 적합하다. 스레드 간 전달은 사용자가 각 작업을 직접 살펴보고, 작업들을 별개의 흐름으로 관리하고 싶을 때 유용하다. [45:31]

27. 훅은 특정 시점의 검사와 정리를 일관되게 실행한다

• Codex 홈의 config.toml에 훅을 설정하면 개발 과정의 특정 시점에 정해진 동작을 실행할 수 있다. 대화 로깅, 입력·출력 검사, API 키 노출 확인, 도구 허용 목록 검사 등이 활용 예시다. [47:38]
• 턴이 끝날 때 사용자 정의 검증을 수행할 수도 있다. 복잡한 검증에는 훅을 활용하고, 모델에는 성공 기준과 경계를 충분히 제공해 그 안에서 작업하게 하는 접근이다. [48:32]

28. 하트비트 자동화는 인프라 준비를 기다린 뒤 다음 단계를 실행한다

• DigitalOcean 플러그인으로 원격 호스트를 준비하는 작업은 시간이 걸리므로, 하트비트 자동화로 준비 상태를 확인하도록 했다. 완료된 예시에서는 약 5분 뒤 같은 작업을 재개하고 이후에도 5분마다 상태를 확인했다. [50:35]
• Droplet이 준비되자 Codex 앱 설정으로 연결되는 딥 링크를 제공했다. 링크를 누르면 SSH 연결 설정을 미리 구성하고 필요하면 SSH 키도 생성하는 흐름이다. [51:35]

29. Slack 피드백을 분류하고 수정 작업과 PR 검토로 연결한다

• macOS 번역 앱의 Slack 피드백을 30분마다 확인하고 답하도록 자동화를 요청했다. 칭찬, 버그 보고, 기능 요청 등을 분류하는 구상이며, 실제 피드백에는 화면의 명확성에 대한 긍정 평가와 자막 공개 전 소리 확인 기능 요청이 있었다. [52:23]
• 요청을 보낸 뒤 실행 도중 지시를 추가해, 버그나 기능 요청에는 별도 워크트리 스레드를 만들고 수정한 뒤 PR을 열도록 했다. Dom에게 리뷰와 24시간 내 승인을 요청하고 미응답 시 계속 알리는 조건도 추가했으며, 이는 익살스러운 예시로 제시됐다. [53:41]

30. 자동화로 발표 진행을 점검하고 반복 작업의 기준을 개선한다

• 발표 중에는 5분마다 Chrome에 표시된 프레젠테이션 화면을 캡처해 시간 초과 가능성을 추정하는 자동화가 실행됐다. 점검 결과는 발표가 다소 뒤처질 수 있다고 판단했다. [55:21]
• 매주 금요일 대화 스레드를 검토해 스킬 개선, AGENTS.md 보완, 사용하지 않는 스킬 제거 후보를 찾는 자동화가 제안됐다. [55:58]

31. 지속적으로 맥락을 쌓는 자동화와 독립 실행 자동화를 구분한다

• 하트비트 자동화는 하나의 스레드에서 타이머에 따라 반복 실행된다. Slack·이메일·Linear의 최신 소식을 확인해 로컬 Obsidian의 일일 노트와 작업별 노트를 계속 갱신하고, 이후 마지막 확인 시점부터의 변화를 조회하는 데 활용한다. [56:56]
• Codex 앱의 예약 페이지에서는 실행마다 별도 스레드를 만드는 자동화도 설정할 수 있다. 주간 팀원 활동 요약이나 시스템 분석처럼 결과를 한 번 검토한 뒤 스레드를 보관하는 작업에 적합하다. [57:51]

32. 앱 서버 프로토콜로 Codex의 핵심 기능을 제품에 내장한다

• 앱 서버 프로토콜은 Codex 앱·CLI·VS Code 확장과 핵심 실행 환경을 연결한다. 도구 호출, 플러그인, 컨텍스트 압축을 통합하며, 공개된 생태계 구성 요소를 바탕으로 개발자가 자신의 사용 사례에 맞게 구축하도록 지원한다. [58:18]
• 앱 서버를 이용하면 제품에 Codex를 내장하고, 사용자의 ChatGPT 구독과 토큰 예산으로 해당 제품의 기능을 구동할 수 있다. [59:00]

33. 앱 서버로 자체 인터페이스와 통합 플랫폼 구축

• 전날 밤 시작한 Retroex는 Codex 앱 서버를 사용하는 자체 인터페이스이며 아직 개발 중이다. 모델과 추론 강도를 선택할 수 있고, 추론 강도에 따라 반짝임과 색상이 달라지도록 구성했다. 메시지를 보내고 접근을 허용하면 응답을 받는 동작도 시연했다 [1:00:26]
• 앱 서버는 클라우드 에이전트를 구축하거나 여러 에이전트 제공자를 관리하는 조직에서 통합 계층을 만드는 데 활용할 수 있다. 오픈소스 Codex 저장소를 복제한 뒤 Codex에 앱 서버 구조를 물으며 자체 애플리케이션과 연동 기능 개발을 시작할 수 있다 [1:01:03]

34. 개별 요청을 검증 루프와 다중 에이전트 작업으로 확장

• 작업을 Codex에 요청해 봤는지 확인하는 데서 출발해, 개별 대화 요청을 반복 실행하는 루프로 발전시킬 수 있다. 이때 루프가 매회 무엇을 확인해야 하는지 정의하는 것이 핵심 질문이다 [1:02:12]
• 작업이 막히면 필요한 맥락이나 권한이 부족했는지 점검해야 한다. 반복해서 필요한 맥락을 스킬이나 플러그인으로 만들면 다음에 같은 문제를 만났을 때 재사용할 수 있다 [1:02:45]

35. 필요한 인간 개입을 남기고 소프트웨어 생산 시스템 설계

• API 키를 플랫폼에서 직접 가져와 환경에 붙여 넣는 과정에도 반드시 사람이 필요한 것은 아니다. 개발자 플러그인은 API 키를 가져와 로컬에 설정할 수 있어 이러한 수동 단계를 줄일 수 있다 [1:03:28]
• 인간이 필요한 지점에는 개입을 유지하되, 나머지 단계에서 인간 의존성을 줄이는 것이 확장 방향이다. 코딩 에이전트와 소프트웨어 하나를 만드는 수준을 넘어, 개별 소프트웨어를 조립 라인처럼 생산하는 ‘소프트웨어 공장’을 구축하는 구상으로 계속된다 [1:03:44]

36. 후속 학습과 현장 실습을 위한 지원

• 후속 일정에는 다음 날의 기조연설, Jason의 일상적인 Codex 활용 강연과 플러그인 설정·앱샷 등을 단계별로 다루는 워크숍이 포함된다. 이어 Codex 하네스 위에서 개발하는 방법과 내부 구조, 음성 에이전트, OpenAI의 프로덕션 LLM 추론을 다루는 세션도 예정돼 있다 [1:04:40]
• 현장 실습을 시작하기 위해 Codex 앱 다운로드를 안내하며, Codex 크레딧 100달러와 API 크레딧 100달러를 제공한다. 참가자는 화면의 QR 코드를 촬영해 안내를 확인할 수 있다 [1:05:57]

🧾 결론

• 특별한 프롬프트 문구보다 작업 맥락, 원하는 결과, 검증 가능한 완료 기준을 명확히 전달하는 것이 핵심이다.
• 빠른 구현 뒤에도 코드 리뷰, 실제 사용자 흐름, 장치 설정과 인증을 확인해야 한다. 생성 속도만으로 사용 준비가 끝났다고 판단하기 어렵다.
• 반복해서 필요한 지식은 스킬·플러그인으로 만들고, 검사는 훅과 자동화로 연결할 수 있다. 발표는 필요한 인간 개입을 유지하면서 소프트웨어 생산 과정을 확장하는 구상을 제시한다.

📈 투자·시사 포인트

• 도입 가치는 전체 작업 흐름으로 평가할 필요가 있다. 코드 작성뿐 아니라 맥락 수집, 화면 조작, 검증, 피드백 반영까지 연결되는지가 실무 활용의 판단 기준이 된다.
• 제품 통합의 접점은 앱 서버와 플러그인이다. 자체 인터페이스와 조직의 통합 계층을 구축할 수 있다는 시사점이 있지만, 사용자 컴퓨터에 있어야 하는 Computer Use 같은 기능은 앱 서버에 포함되지 않는다.
• 자동화의 효율은 비용과 운영 조건을 함께 봐야 한다. 메모리·Chronicle의 추가 토큰 사용, 인증 부족으로 생기는 차단, 실제 실행 점검에 필요한 개입을 함께 평가해야 한다. 자료에는 투자 수익률이나 기업 가치 평가를 뒷받침할 수치가 없다.

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

• Sites는 Enterprise·Business 프리뷰, Chronicle은 Pro 연구 프리뷰로 소개된다. 이 자료만으로 현재 제공 범위와 이용 조건을 확정할 수 없다.
• Appshot이 개인 경험상 90% 이상 적절한 작업으로 이어졌다는 평가는 통제된 성능 측정이 아니다. 긴 스레드에서 내용을 덜 잊는다는 평가와 압축의 토큰 효율 해석도 구분해서 봐야 한다.
• 15시간 이상 실행된 Q&A 사이트 작업은 소개 시점에도 진행 중이었다. 후반에 작업 수행 사례가 제시되지만, 모든 요구사항의 완성도와 안정성까지 확인된 것은 아니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복해서 수행하는 작업 하나를 고르고, 원하는 결과와 구체적으로 검증할 완료 기준을 적는다.
• 관련 문서·대화·화면·사용자 선호를 모아 전달하고, 재사용할 지침은 스킬이나 플러그인으로 정리한다.
• 웹 앱 시험, 데스크톱 조작, 로그인 상태 활용 중 필요한 작업을 구분해 내장 브라우저·Computer Use·Chrome 확장 프로그램을 선택한다.
• 결과물에 코드 리뷰와 실제 사용자 흐름 검증을 적용하고, 장치 설정·인증·배포 접근 권한을 확인한다.

❓ 열린 질문

• 장시간 작업이 사용자의 기대대로 끝났다고 판단하려면 어떤 기능·사용자 흐름·검증 결과를 완료 기준에 포함해야 할까?
• 하위 에이전트에 위임할 작업과 사용자가 직접 살펴볼 별도 스레드는 어떤 기준으로 나누는 것이 좋을까?
• 지속적인 맥락의 이점과 추가 토큰 사용, 메모리 보존 범위 사이에서 어떤 설정이 적절할까?