맥락에서 소프트웨어 공장까지: Codex로 만드는 개발 루프

URL: https://www.youtube.com/watch?v=FwiS44-xyYw
날짜: 2026-10-06
채널: AI Engineer (aiDotEngineer)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코딩 에이전트에게 한 번의 요청을 던지는 수준을 넘어, 맥락·도구·검증·사람의 승인을 연결한 반복 가능한 소프트웨어 생산 시스템을 어떻게 만들 것인가?==

• 좋은 결과의 출발점은 정교한 마법의 프롬프트가 아니라 문서·대화·코드·화면·개인 선호를 포함한 충분한 맥락이다.
• 플러그인(plugins), 컴퓨터 사용(computer use), Chrome 확장 프로그램, 앱 내 브라우저, Sites, 모바일·원격 기능을 조합하면 에이전트의 작업 범위가 코딩을 넘어선다.
• 장기 작업은 구체적이고 검증 가능한 목표(goal), 진행 대시보드, 별도 스레드와 서브 에이전트, 훅(hooks), 하트비트 자동화로 감독 가능하게 만들어야 한다.
• 최종 방향은 피드백을 읽고 작업을 분해하고 테스트·PR·승인까지 이어 가는 소프트웨어 공장(software factory)이다.

찰리 구오(Charlie Guo)와 가브리엘 추아(Gabriel Chua)는 OpenAI 개발자 경험(Developer Experience) 팀의 워크숍에서 Codex를 ‘요리’에 비유했다. 재료는 맥락이고, 레시피는 재사용 가능한 스킬과 플러그인이며, 맛보기는 테스트와 검증이다. 실시간 번역 macOS 앱, 코드베이스 시각화 사이트, 대시보드 데이터 추출, 피드백 폼, 실시간 Q&A 사이트, 내부 폼 빌더, Rust 백엔드 Python 패키지를 차례로 보여 주며 이 원칙을 설명한다.

1. 워크숍의 배경과 Codex의 확장된 사용 범위

Codex의 핵심 가치는 코드 자동 생성 자체보다 다양한 작업을 하나의 에이전트 루프에 연결하는 데 있다.

1.1. ‘쿠킹’ 워크숍의 시작

1. 행사와 사례 소개

   1. 약 300명이 참석한 세션에서 Ableton용 신시사이저 플러그인, Premiere Pro 영상 편집, 게임의 오디오·아트·메커니즘·난이도 조정, 자율주행 골프 카트 같은 결과물이 소개됐다.
   2. Codex는 회의 중 노트북에서만 쓰는 도구가 아니다. 모바일 앱, ChatGPT 앱, 원격 노트북과 서버, 오픈 소스 앱 서버를 통해 이동 중에도 작업을 이어 갈 수 있다.
   3. 일본의 사용자는 고속열차나 산책 중 아이디어를 주고받았고, Daniel은 여러 기기에 Codex를 설치했다. 기존 에이전트의 설정도 가져와 바로 시작할 수 있다.

2. 세션의 진행 방식

   1. 첫 부분에서는 새 기능과 Codex 활용의 ‘6가지 요리 단계’를 소개하고, 뒤의 미니 해커톤에서는 참가자가 직접 라이브 쿠킹을 진행한다.
   2. 영화 《라따뚜이》의 “누구나 요리할 수 있지만 두려움 없는 자만이 위대한 요리를 만든다”는 문장이 창의적 시도의 태도를 상징한다.

1.2. 6단계 활용 프레임

1. 맥락 제공(Context): 문서, 대화, 코드베이스, 화면 상태와 개인 선호를 전달하며 플러그인·App Shot·받아쓰기·메모리로 입력 형식을 넓힌다.
2. 빌드(Build): 목표와 맥락을 바탕으로 앱·사이트·코드·문서·스프레드시트·슬라이드를 만들고 Sites로 공유한다.
3. 행동 수행(Take Action): API가 없는 데스크톱 소프트웨어나 반복 웹 UI를 컴퓨터 사용으로 조작하고 로그인 상태가 필요한 Chrome 작업은 확장 프로그램으로 처리한다.
4. 협업(Collaborate): 장기 프로젝트를 목표·마일스톤·스레드·서브 에이전트로 분해하고 로컬·원격 세션의 테스트를 연결한다.
5. 자동화(Automate): 하트비트로 서버·Slack·파일·화면을 반복 확인하고 예약 작업으로 요약·메모 업데이트·피드백 분류를 실행한다.
6. 내장과 확장(Embed and Scale): App Server로 Codex의 에이전트 하네스를 제품에 내장하고 여러 에이전트와 사람의 승인이 있는 생산 라인을 만든다.

2. 맥락을 재료로 준비하기

2.1. 실제 대화와 화면을 그대로 전달하기

1. 금요일 오후의 실시간 번역기 아이디어

   1. 찰리, 가브리엘, Christine은 금요일 오후 4시 44분에 워크숍 데모 아이디어가 없다는 사실을 깨달았다. Christine이 실시간 번역기를 제안했고 찰리는 GPT 실시간 번역을 쓰자고 했다.
   2. macOS 앱 경험이 없어도 Codex와 macOS 빌드 플러그인을 사용해 복사·붙여넣기, 웹 검색, AppKit, 서명과 검사 같은 모범 사례를 적용할 수 있었다.
   3. Slack 브레인스토밍 대화를 App Shot으로 캡처해 보냈다. 텍스트가 함께 보존되는 화면 캡처라 아이디어를 처음부터 다시 설명할 필요가 없었다.

2. 맥락의 범위 확장

   1. 슬라이드, GitHub·GitLab 파이프라인, 브라우저 페이지도 맥락이다. Chronicle 연구 프리뷰를 사용하면 “왜 파이프라인이 실패했나?”처럼 사용자가 보던 화면을 전제로 질문할 수 있다.
   2. 받아쓰기는 타이핑보다 빠르게 생각을 길게 풀어 놓는 방법이다. 완벽한 문장보다 모델이 정리할 원재료를 충분히 주는 편이 유리하다.
   3. 찰리는 Slack이나 브라우저를 복사·붙여넣기하는 대신 App Shot으로 바로 보내며, 자신의 경험상 90% 이상은 원하는 대로 처리된다고 말했다.

2.2. 메모리와 개인화

1. Codex 앱의 메모리는 기본적으로 꺼져 있지만 설정에서 켤 수 있다. Python 패키지 관리에 uv를 선호한다는 사실처럼 개인 선호를 시간이 지나며 반영한다.
2. 사용자 지정 지침은 홈 디렉터리의 AGENTS.md와 비슷한 전역 규칙으로 작동한다. “항상 해적처럼 답하라” 같은 지침도 모든 대화에 적용된다.
3. 도구가 장기 보존을 원치 않는 정보를 반환할 수 있으므로 채팅별로 메모리 생성을 건너뛰는 안전 옵션을 고려해야 한다.
4. Memory와 Chronicle은 추가 토큰을 쓰지만 과거 대화를 참고해 협력자처럼 행동하게 한다. 장기적으로 필요한 맥락은 메인 스레드나 파일에도 명시적으로 남겨야 한다.

3. 플러그인과 결과물 만들기

3.1. 플러그인은 재사용 가능한 레시피다

1. 구성: 플러그인은 스킬, 외부 프롬프트, 팀 지침, 앱·설정·외부 서비스 연결, MCP 서버를 한 묶음으로 제공한다.
2. 반복의 축적: 어려운 워크플로를 스킬이나 플러그인으로 만들면 다음에는 호출만 하면 된다. 팀의 반복 절차와 승인 조건을 패키지로 만들수록 생산성이 누적된다.
3. 시연 플러그인: macOS 플러그인은 AppKit·Liquid Glass·서명·검사를 다루고, OpenAI 개발자 플러그인은 API 키를 찾고 로컬에 설정하는 번거로움을 줄인다. Gmail·Outlook·Microsoft Teams·Slack 플러그인은 업무 맥락을 가져온다.

3.2. 4분 2초짜리 실시간 번역 앱

1. Slack 대화와 아이디어가 담긴 App Shot을 넘기고 “이걸 만들어 줄 수 있나?”라고 요청하자 Codex가 macOS 실시간 번역 앱을 만들었다.
2. 완성까지 4분 2초가 걸렸다. 입력은 휴대폰 음성, 출력은 Mac 앱으로 지정했고 독일어 번역과 오디오 출력을 시험했다.
3. 무대에서 “안녕하세요”, 마이크 테스트, 방 안에 있는지 묻는 문장을 실제로 번역했지만 스피커와 마이크 문제로 지연도 발생했다. 에이전트가 앱을 만들었다고 하드웨어와 네트워크까지 완벽해지는 것은 아니다.
4. 데이터 과학자인 Gabriel은 WebRTC·WebSocket과 macOS 앱 경험이 많지 않았지만 플러그인과 Codex로 낯선 영역을 다룰 수 있었다.

3.3. Sites로 공유 가능한 산출물 만들기

1. 오픈 소스 Agents SDK의 최근 기능과 샌드박스 에이전트 변경 사항을 코드 스니펫과 함께 팀이 읽기 쉬운 사이트로 만들었다.
2. Sites는 6월 초 기업·비즈니스 플랜에 프리뷰로 출시된 기능으로 소개됐다. 긴 저장소와 Git 커밋 기록을 시각화하는 맥락→빌드의 사례다.
3. OpenAI 내부에서는 사건·회의·오프사이트 준비를 요약하고 후보 장소의 장단점을 비교하는 사이트를 공유한다.
4. /code-review를 실행하면 커밋되지 않은 변경 사항을 검토하는 작업이 생성된다. 이미지 생성·SVG·스프레드시트·슬라이드도 같은 흐름에 연결할 수 있다.

4. 컴퓨터 사용과 브라우저 제어

4.1. 컴퓨터 사용의 실제 사례

1. 레거시 대시보드: API가 없는 대시보드에서 지난 7일간의 커밋 수를 CSV로, 6월 1일부터 6월 29일까지의 풀 리퀘스트 수를 JSON으로 내려 달라고 했다. Codex는 사용자의 손이 키보드에 없는 상태에서 날짜를 선택하고 버튼을 눌렀다.
2. macOS에서는 Codex가 앱을 조작하는 동안 사용자의 커서를 독점하지 않아 다른 탭에서 Twitter를 보거나 다른 일을 계속할 수 있다.
3. Chrome 확장: Google Docs의 질문을 사용해 Google Form을 만들고 모든 질문을 필수 항목으로 지정했다. 확장은 Chrome의 버튼을 직접 눌러 실제 라이브 폼을 생성한다.

4.2. 세 가지 제어 방식 선택하기

1. 앱 내 브라우저(In-app browser): Codex 앱 옆에 탭을 열고 브라우저 엔진에 깊게 연결되므로 로컬 웹 앱의 레이아웃·상호작용·렌더링을 테스트할 때 적합하다.
2. 컴퓨터 사용(Computer Use): API나 프로그래밍 인터페이스를 노출하지 않는 데스크톱·레거시 소프트웨어를 사람처럼 조작할 때 유용하다.
3. Chrome 확장 프로그램: 로그인한 브라우저의 상태와 권한을 넘겨야 할 때 적합하다. 사용자의 허락을 받은 사이트에서 기존 자격 증명을 활용하므로 헤드리스 브라우저의 로그인 루프를 피할 수 있지만 민감한 세션을 통제해야 한다.

5. 장기·복잡한 프로젝트를 운영하는 방법

5.1. 세 가지 장기 프로젝트

1. 그린필드 실시간 Q&A 사이트: 약 400명을 수용하는 회의실용으로 관리자·참가자·발표자 화면, AI 태그, 승인, 신청서 승인 API를 포함했다.
2. 기존 오픈 소스 폼 빌더의 내부화: SaaS 비용을 원치 않는 소규모 팀을 위해 저장소를 재사용하고 ChatGPT 인증을 붙였다. ‘AI Engineer 워크숍’ 초안, 미리 보기, 게시, 공유 링크, 응답 확인까지 수행했다.
3. 논문 기반 Python 패키지 재구현: 대학원 논문과 Julia·R 구현을 읽고 Rust 백엔드 Python 패키지를 만들게 했다. 동적 프로그래밍은 쓰지 않고 휴리스틱을 사용한다는 제약을 줬다.
4. 실행 시간은 폼 빌더 5시간 57분, 연구 패키지 약 7시간 1분 40초, Q&A 사이트 약 15시간 30분이었다. 40시간 동안 네이티브 Swift로 Doom을 재구현한 Goal 사례도 언급됐다.

5.2. 프롬프트보다 맥락과 경계가 중요하다

1. 모델은 사람의 머릿속을 읽을 수 없으므로 목표·제약·완료 조건을 말해야 한다. 특정 ‘마법의 문구’보다 풍부하고 명확한 맥락이 중요하다.
2. 발표자는 Codex와 전화로 수다를 떠는 것처럼 생각을 쏟아 낸 뒤 “무대에서 보여 줄 수 있게 프롬프트를 다듬어 달라”고 했다. Convex와 AI 플러그인으로 실시간 상호작용과 배포도 붙였다.
3. 긴 작업일수록 모델이 채울 수 있는 경계와 검증 절차를 충분히 제공해야 한다.

6. 목표·스레드·서브 에이전트로 감독 가능한 시스템 만들기

6.1. Goal과 검증 가능한 성공 기준

1. Goal은 사용자가 지정한 검증 기준을 단계마다 확인한다. 기술적으로 요청했지만 기대와 다른 결과를 내는 ‘원숭이 손’ 문제를 줄이려면 성공 조건을 구체적으로 써야 한다.
2. 여러 Goal을 goals.md에 저장하고 progress-dashboard.html로 마일스톤, 완료·진행 중·미착수 항목을 표시한다. M2·M3A에서 코드 리뷰와 Goal 감사를 실행해 목표 이탈을 확인한다.
3. Goal은 코드 마이그레이션, 대규모 리팩터링, 재시도 루프, 실험, 게임, 상세 사양을 가진 원샷 앱에 적용할 수 있다.

6.2. 서브 에이전트와 가시적 스레드

1. 서브 에이전트: 코드 리뷰어·문서 연구원처럼 역할별 지침과 모델을 지정한다. 컨텍스트를 분리하고 결과만 메인 작업에 돌려주므로 세부 대화를 모두 볼 필요가 없을 때 적합하다.
2. 가시적 스레드와 핸드오프: 아트 디렉션·음악·애니메이션·게임 메커니즘을 별도 스레드로 만들고 크리에이티브 디렉터의 승인 후 완료하게 할 수 있다. 사이드 스레드는 일시적이므로 장기 결정은 메인 스레드나 문서에 되돌려야 한다.
3. 로컬·원격 연결: 원격 Q&A 스레드가 로컬 Chrome 확장에 클릭·브라우저·E2E QA를 요청하고 결과를 돌려받는다. 새벽 3시에 클라우드 Chrome이 폼 생성을 끝까지 실행한 사례도 소개됐다.

6.3. 압축과 훅

1. 5~15시간짜리 작업은 여러 컨텍스트 윈도우를 거치므로 필요한 정보를 남기는 압축이 핵심이다. GPT-5.1 Codex Max의 네이티브 압축이 긴 스레드에서 토큰 효율과 맥락 보존을 높인다고 소개됐다.
2. config.toml의 훅은 로깅, 입력·출력 스캔, 보안 검사, 턴 종료 후 유효성 검사를 삽입한다.
3. API 키가 프롬프트에 들어갔는지, 도구가 허용 목록에 있는지 확인하고 완료 전에 린터나 저장소 정리 스크립트를 강제할 수 있다. 자율성이 커질수록 결정론적 가드레일이 중요하다.

7. 하트비트와 예약 자동화로 루프를 연결하기

7.1. 인프라 상태를 기다리는 하트비트

1. DigitalOcean 플러그인으로 원격 Droplet을 프로비저닝하면 Codex가 기다리는 대신 하트비트 자동화를 만든다.
2. 약 5분마다 준비 여부를 확인하고 준비되면 다음 단계로 넘어간다. 딥 링크는 SSH 인스턴스 설정과 키 생성 위치까지 안내한다.
3. 배포 파이프라인도 5분·10분마다 검사하고 준비되었을 때 다음 작업을 만들 수 있다.

7.2. Slack 피드백을 개발 작업으로 바꾸기

1. 번역 앱의 Slack 피드백에는 화면이 선명하다는 칭찬, 시작점을 알기 쉽다는 평가, 자막 전 사운드 체크 요청이 있었다.
2. 30분마다 채널의 댓글과 제안을 칭찬·버그·기능 요청으로 분류하고, 버그나 기능 요청이면 작업 트리에 스레드를 만든다.
3. 수정·테스트·PR 생성·Dom에게 리뷰 요청을 진행하고 24시간 내 승인이 없으면 다시 알리도록 만들 수 있다. Slack 플러그인·스레드 통신·브라우저 테스트·승인을 연결하면 아침에 PR이 준비된 소프트웨어 공장이 된다.

7.3. 예약 작업과 지식의 누적

1. 예약 페이지에서 새 스레드로 매일 Slack·이메일·알림을 읽어 Obsidian 일일 메모를 업데이트하거나 매주 구성원 작업과 시스템 분석을 요약할 수 있다.
2. 매주 금요일 대화를 돌아보고 새 스킬이나 AGENTS.md에 추가할 모범 사례를 찾게 할 수 있다. 이메일 초안 자동화와 최종 답장 검증 자동화를 분리하면 프로세스가 개선된다.
3. 반복 루프가 맥락을 파일에 축적하므로 과거 데모와 메모의 진행 상황을 즉시 확인할 수 있다.

8. App Server와 Retrodex: Codex를 제품에 내장하기

8.1. App Server의 역할

1. App Server 프로토콜은 Codex 앱·CLI·VS Code 확장 프로그램의 기반이며 클라이언트가 핵심 Codex 시스템과 통신하게 한다.
2. 도구 호출·플러그인·컨텍스트 압축을 포함한 에이전트 하네스를 제품 안에서 쓸 수 있고 ChatGPT 구독과 토큰 예산을 활용하는 제품도 만들 수 있다.
3. 데스크톱 특화 컴퓨터 제어는 포함되지 않지만 핵심 에이전트 루프는 제공된다. 오픈 소스로 공개된 이유는 개발자가 원하는 위치와 사용 사례에 통합하게 하기 위해서다.

8.2. Retrodex 데모와 생태계

1. App Server 위에 Codex UI를 직접 만드는 네 번째 장기 프로젝트로 Retrodex를 구축했다. 추론 노력 수준에 따라 작은 반짝임·색상 변화·강한 효과가 나타난다.
2. Retrodex에서 “안녕하세요”를 보내고 권한을 허용하면 같은 App Server의 Codex 스레드가 답하며, Codex 앱에서도 같은 프로젝트와 스레드를 확인했다.
3. 대규모 조직의 여러 AI 공급자를 통합할 레이어로 App Server가 유용하다. openai/codex를 클론해 App Server·Windows 샌드박스·에이전트 루프를 직접 탐구할 수도 있다.

9. 결론 및 시사점

1. “Codex에게 이 작업을 요청해 보았나?”를 반복해서 묻고 성공한 절차는 스킬·플러그인·사용자 지침으로 저장한다.
2. 단일 요청에서 루프로 이동한다. 입력·검증·승인·실패 시 다음 행동을 정의하면 에이전트가 반복 실행할 수 있다.
3. 맥락 부족·권한·인증·API 키 같은 막힘의 원인을 기록하고 플러그인이나 스킬에 해결법을 통합한다.
4. 컴퓨터 사용·Chrome 확장·앱 내 브라우저는 대상에 맞는 도구다. 로컬 UI 테스트, 로그인된 브라우저, API 없는 레거시 앱을 구분해 선택한다.
5. 장기 작업에는 Goal의 검증 가능한 성공 조건, 마일스톤, 진행 대시보드, 압축, 서브 에이전트, 가시적 스레드, 훅을 함께 배치한다.
6. 서브 에이전트는 세부 작업을 숨기고 결과에 집중할 때, 가시적 스레드는 사람이 방향과 창의적 품질을 감독할 때 사용한다.
7. 하트비트와 예약 자동화는 서버 준비, Slack 피드백, 이메일, 일일 메모 같은 시간 기반 루프를 연결하고 사람은 인증·권한·품질 승인에 개입한다.
8. 사람이 필요한 단계는 남기되 반복적인 조작과 검증은 기계를 만드는 기계로 전환한다.
9. Codex로 소프트웨어 하나를 만드는 것과 소프트웨어 공장을 만드는 것은 다르다. 후자는 에이전트와 도구가 조립 라인처럼 구성 요소를 만들고 결과를 검사하는 시스템이다.
10. 후속 세션에서는 Codex 하네스·음성 에이전트·운영 환경의 LLM 추론을 다루며 참가자에게 Codex 크레딧 100달러와 API 크레딧 100달러를 제공한다고 안내했다.

주요 발언 모음

“누구나 요리할 수 있지만, 두려움 없는 자만이 위대한 요리를 만들 수 있다.”

“Codex는 여러분의 생각을 읽을 수 없습니다. 원하는 바를 명확하게 전달해야 합니다.”

“마법의 문구보다 중요한 것은 맥락입니다.”

“Codex에게 이 작업을 요청해 보았는가?”

“개별적인 요청에서 소프트웨어 공장으로 이동해야 합니다.”

핵심 데이터 & 수치

• 약 300명: 워크숍 참석 규모다.
• 4분 2초: Slack 맥락으로 실시간 번역 macOS 앱을 만든 시간이다.
• 6월 초: Sites가 기업·비즈니스 플랜에 프리뷰로 출시된 시점이다.
• 90% 이상: App Shot 맥락이 원하는 대로 처리된다는 발표자의 체감 성공률이다.
• 약 400명: 실시간 Q&A 사이트가 상정한 회의실 수용 규모다.
• 5시간 57분 / 약 7시간 1분 40초 / 약 15시간 30분: 폼 빌더·연구 패키지·Q&A 사이트의 장기 실행 사례다.
• 약 40시간: 네이티브 Swift Doom 재구현 Goal 사례다.
• 약 5분: DigitalOcean Droplet 하트비트 간격이다.
• 30분: Slack 피드백 자동화 주기 예시다.
• 100달러 + 100달러: 참가자에게 제공된 Codex 크레딧과 API 크레딧이다.

핵심 요약 (20줄)

1. Codex 활용의 출발점은 마법의 프롬프트가 아니라 문서·대화·코드·화면·선호를 포함한 풍부한 맥락이다.
2. Slack 브레인스토밍을 App Shot으로 전달하면 아이디어를 다시 설명하거나 복사·붙여넣기할 필요가 줄어든다.
3. 받아쓰기는 생각을 빠르게 길게 전달하고 모델이 정리하도록 만드는 저평가된 입력 방식이다.
4. 메모리와 Chronicle은 과거 대화와 화면 맥락을 활용해 Codex를 개인 작업 방식에 맞춘다.
5. 플러그인은 스킬·프롬프트·팀 지침·앱·MCP 서버를 묶어 반복 가능한 개발 레시피를 만든다.
6. macOS 빌드 플러그인은 AppKit·Liquid Glass·서명·검사 같은 모범 사례를 낯선 개발자에게 제공한다.
7. Slack 맥락을 바탕으로 만든 실시간 번역 macOS 앱은 4분 2초 만에 작동하는 데모로 완성됐다.
8. Sites는 코드베이스와 Git 기록을 공유 가능한 시각화 사이트나 의사결정 자료로 바꾸는 배포 경로다.
9. 컴퓨터 사용은 API가 없는 레거시 대시보드에서 날짜를 선택하고 CSV·JSON 데이터를 다운로드하는 작업을 수행한다.
10. Chrome 확장 프로그램은 사용자의 로그인 상태와 권한을 활용해 Google Form 같은 실제 웹 앱을 조작한다.
11. 앱 내 브라우저는 로컬 웹 앱의 레이아웃과 렌더링을 깊게 테스트할 때 가장 적합하다.
12. 장기 프로젝트에는 구체적이고 검증 가능한 성공 기준을 가진 Goal을 먼저 정의해야 한다.
13. 마일스톤·Goal 감사·진행 대시보드는 수시간 동안 실행되는 작업의 상태와 방향 이탈을 보여 준다.
14. 서브 에이전트는 컨텍스트를 분리해 코드 리뷰·문서 조사 같은 역할을 맡고 결과만 메인 작업에 돌려준다.
15. 가시적 스레드는 사람이 아트·음악·UX·QA의 진행을 직접 감독하고 승인해야 할 때 유용하다.
16. 훅은 API 키 스캔·허용 목록 확인·린터·정리 스크립트 같은 결정론적 안전장치를 제공한다.
17. 하트비트 자동화는 서버 프로비저닝과 배포 상태를 일정한 간격으로 확인해 준비된 다음 단계로 넘긴다.
18. Slack 피드백을 분류해 버그 수정·기능 요청·PR·리뷰·승인으로 연결하면 소프트웨어 공장이 시작된다.
19. App Server는 Codex 앱·CLI·VS Code 확장의 핵심 하네스를 제품과 사용자 인터페이스에 내장하게 한다.
20. 최종 목표는 한 번의 코딩 요청이 아니라 여러 에이전트·도구·사람의 승인으로 이어지는 반복 가능한 생산 루프다.