🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI 팀은 4명의 소규모 엔지니어가 Codex를 ‘새로 온 시니어 엔지니어’처럼 온보딩·지휘·검토하는 방식으로 Sora Android 앱을 28일 만에 프로토타입에서 글로벌 출시까지 완성했다고 설명한다.

📌 핵심 요약

• Sora Android 앱은 2025년 10월 8일부터 11월 5일까지 약 28일 동안 개발되어 출시됐고, 출시 당일 Play Store 1위에 올랐으며 첫 24시간 동안 Android 사용자들이 100만 개 이상의 영상을 생성했다.
• 팀은 늦은 프로젝트에 인력을 더 투입하면 오히려 늦어진다는 Brooks의 통찰을 받아들여, 많은 엔지니어와 복잡한 프로세스 대신 Codex를 장착한 4명의 강한 엔지니어 팀으로 속도와 품질을 동시에 추구했다.
• Codex는 대규모 코드베이스 이해, 테스트 작성, 피드백 반영, 병렬 실험, 코드 리뷰와 조사에서 강했지만, 제품 전략·아키텍처 취향·실제 사용감·장기적 구조 판단은 인간의 명확한 지침과 검토가 필요했다.
• 팀은 먼저 아키텍처, 모듈화, 의존성 주입, 내비게이션, 인증, 기본 네트워킹 같은 토대를 사람이 직접 설계하고 대표 기능을 작성한 뒤, Codex가 같은 패턴 안에서 대량의 코드를 안정적으로 채우도록 했다.
• 개발 후반에는 여러 Codex 세션을 병렬로 운용하며 재생, 검색, 오류 처리, 테스트 등을 동시에 진행했지만, 병목은 코드 작성이 아니라 의사결정·피드백·통합·품질 검토로 이동했다.

🧩 주요 포인트

1. Sora Android 앱은 2025년 10월 8일부터 11월 5일까지 약 28일 동안 개발되어 출시됐고, 출시 당일 Play Store 1위에 올랐으며 첫 24시간 동안 Android 사용자들이 100만 개 이상의 영상을 생성했다.
2. 팀은 늦은 프로젝트에 인력을 더 투입하면 오히려 늦어진다는 Brooks의 통찰을 받아들여, 많은 엔지니어와 복잡한 프로세스 대신 Codex를 장착한 4명의 강한 엔지니어 팀으로 속도와 품질을 동시에 추구했다.
3. Codex는 대규모 코드베이스 이해, 테스트 작성, 피드백 반영, 병렬 실험, 코드 리뷰와 조사에서 강했지만, 제품 전략·아키텍처 취향·실제 사용감·장기적 구조 판단은 인간의 명확한 지침과 검토가 필요했다.
4. 팀은 먼저 아키텍처, 모듈화, 의존성 주입, 내비게이션, 인증, 기본 네트워킹 같은 토대를 사람이 직접 설계하고 대표 기능을 작성한 뒤, Codex가 같은 패턴 안에서 대량의 코드를 안정적으로 채우도록 했다.
5. 개발 후반에는 여러 Codex 세션을 병렬로 운용하며 재생, 검색, 오류 처리, 테스트 등을 동시에 진행했지만, 병목은 코드 작성이 아니라 의사결정·피드백·통합·품질 검토로 이동했다.

🧠 상세 정리

1. 출시 성과와 28일 개발의 배경

본문은 2026년 4월 26일 기준 Sora 제품이 더 이상 제공되지 않는다는 공지를 먼저 밝힌 뒤, 2025년 11월 Sora Android 앱 출시 사례를 설명한다. 이 앱은 짧은 프롬프트로 생생한 영상을 만들 수 있게 했고, 출시 당일 Play Store 1위에 올랐으며 첫 24시간 동안 Android 사용자들이 100만 개가 넘는 영상을 생성했다. 핵심 주장은 이 규모의 프로덕션 Android 앱 초기 버전이 28일 만에 만들어졌고, 그 과정에서 일반 개발자와 팀도 사용할 수 있는 Codex가 중심 역할을 했다는 점이다. 팀은 2025년 10월 8일부터 11월 5일까지 약 5십억 토큰을 사용하며 프로토타입에서 글로벌 출시까지 진행했고, 앱은 99.9%의 crash-free rate와 만족할 만한 아키텍처를 갖췄다고 설명한다.

2. Brooks의 법칙을 받아들인 소규모 팀 전략

iOS에서 Sora가 출시된 뒤 사용량은 폭발적으로 증가했지만, Android 쪽에는 작은 내부 프로토타입과 Google Play 사전 등록 사용자들이 있는 상황이었다. 보통 이런 고위험·시간 압박 프로젝트에서는 인력을 많이 투입하고 프로세스를 늘리기 쉽지만, 본문은 복잡한 앱을 빠르게 출시하려 할 때 인력 증원이 의사소통 비용, 업무 분절, 통합 비용을 키울 수 있다고 지적한다. 팀은 Fred Brooks의 ‘늦은 소프트웨어 프로젝트에 사람을 더하면 더 늦어진다’는 통찰을 거스르지 않고, Codex를 갖춘 4명의 강한 엔지니어로 구성된 작은 팀을 선택했다. 그 결과 18일 만에 직원용 내부 빌드를 배포했고, 그로부터 10일 뒤 공개 출시까지 이어가면서도 Android 엔지니어링 관행, 유지보수성, 신뢰성 기준을 낮추지 않았다고 설명한다.

3. Codex를 새로 합류한 시니어 엔지니어처럼 다룬 방식

팀은 Codex를 단순 자동 코드 생성기가 아니라 새로 온 유능한 시니어 엔지니어처럼 대하는 접근이 효과적이었다고 말한다. Codex의 역량 덕분에 인간 엔지니어들은 직접 코드를 쓰는 시간보다 방향을 제시하고 결과를 검토하는 데 더 많은 시간을 쓸 수 있었다. 하지만 Codex는 팀의 선호 아키텍처, 제품 전략, 실제 사용자 행동, 내부 규범처럼 명시적으로 알려주지 않은 정보를 스스로 추론하는 데 한계가 있었다. 또한 실제 기기에서 앱을 실행해 스크롤 감각이 어색한지, 어떤 흐름이 혼란스러운지 체험적으로 판단할 수 없었기 때문에, 이런 제품 경험과 맥락 판단은 사람이 맡아야 했다.

4. Codex가 지침을 필요로 한 영역

본문은 Codex가 각 세션마다 온보딩을 필요로 했다고 강조한다. 목표, 제약, 팀의 작업 방식, 코드 스타일을 명확히 전달하지 않으면 Codex는 당장 동작하는 코드를 만들 수는 있어도 장기적으로 바람직한 구조를 보장하지 못했다. 예를 들어 기존 view model을 확장해야 하는 상황에서 불필요한 view model을 만들거나, repository 계층에 있어야 할 로직을 UI 계층에 밀어 넣을 수 있다고 설명한다. 팀은 이런 문제를 줄이기 위해 코드베이스 곳곳에 AGENTS.md 파일을 만들고 유지하게 했으며, 이를 통해 여러 세션에서 같은 지침과 모범 사례가 반복 적용되도록 했다.

5. Codex가 특히 강했던 영역

Codex의 강점으로는 먼저 대규모 코드베이스를 빠르게 읽고 이해하는 능력이 제시된다. 여러 주요 프로그래밍 언어를 폭넓게 다루기 때문에, 복잡한 추상화 없이도 플랫폼 간 개념을 옮겨 이해하는 데 도움이 됐다. 또한 Codex는 다양한 사례를 포괄하는 단위 테스트 작성에 적극적이었고, 모든 테스트가 깊지는 않았더라도 폭넓은 커버리지가 회귀를 막는 데 유용했다. CI 실패 로그를 붙여 넣고 수정안을 요청하면 피드백을 잘 반영했으며, 여러 아이디어를 병렬 세션에서 실험하고 필요하면 버릴 수 있는 일회성 실행 능력도 큰 장점으로 다뤄진다.

6. 사람이 먼저 만든 기술적 토대의 중요성

팀은 장기적 트레이드오프를 판단할 시야는 아무리 유능한 새 엔지니어라도 바로 갖기 어렵다고 보고, 앱의 핵심 시스템 설계는 사람이 직접 주도했다. 여기에는 아키텍처, 모듈화, 의존성 주입, 내비게이션, 인증, 기본 네트워킹 흐름이 포함됐다. 그 뒤 팀은 몇 가지 대표 기능을 처음부터 끝까지 직접 작성하면서 코드베이스 전체가 따라야 할 규칙과 프로젝트 전반의 패턴을 문서화했다. 전체 프로젝트의 약 85%가 Codex에 의해 작성됐다고 추정되는 상황에서, 이처럼 세심하게 계획한 기반은 나중의 큰 되돌림과 리팩터링 비용을 피하게 해 준 중요한 결정이었다.

7. 무작정 생성이 아니라 패턴 안에서 일하게 만들기

팀의 목표는 단순히 ‘동작하는 것’을 가장 빨리 만드는 것이 아니라, ‘우리 팀이 원하는 방식으로 동작하는 코드’를 만들게 하는 것이었다. 본문은 코드를 작성하는 올바른 방식이 여러 가지일 수 있으므로, Codex에게 세세한 명령을 모두 내리기보다 팀에서 무엇을 올바른 것으로 보는지 보여주는 일이 중요했다고 설명한다. 실제로 팀은 ‘iOS 코드를 바탕으로 Sora Android 앱을 만들어라’라는 식의 단발성 프롬프트도 시도했지만, 기술적으로 동작하더라도 제품 경험은 기대에 못 미쳤고 엔드포인트, 데이터, 사용자 흐름 이해가 부족해 신뢰하기 어려웠다고 한다. 반대로 잘 작성된 예시와 명확한 패턴이 있는 샌드박스 안에서 ‘이 화면과 같은 아키텍처와 패턴으로 설정 화면을 만들라’고 요청했을 때 훨씬 좋은 결과가 나왔다.

8. 코딩 전 계획을 함께 세우는 워크플로

초기에는 기능 설명과 관련 파일을 주고 바로 구현을 요청하는 방식도 사용했지만, 이런 접근은 컴파일은 되더라도 아키텍처와 목표에서 벗어나는 코드를 만들 때가 많았다. 그래서 팀은 중요한 변경 전 먼저 Codex에게 관련 파일을 읽고 시스템이 어떻게 작동하는지 요약하게 했으며, API에서 repository, view model, UI로 데이터가 흐르는 방식을 설명하게 했다. 이후 사람이 Codex의 이해를 수정하거나 보강했고, 어떤 파일을 바꾸고 어떤 상태를 추가하며 로직이 어떻게 흘러야 하는지 담은 작은 설계 문서에 가까운 구현 계획을 함께 만들었다. 이 계획을 세운 뒤에야 단계별 구현을 맡겼고, 긴 작업에서는 계획을 파일에 저장해 여러 인스턴스가 같은 방향을 따를 수 있게 했다.

9. 병렬 Codex 세션이 만든 새로운 병목

프로젝트 절정기에는 여러 Codex 세션이 동시에 돌아갔고, 한 세션은 재생 기능을, 다른 세션은 검색을, 또 다른 세션은 오류 처리나 테스트와 리팩터링을 맡았다. 각 세션은 진행 상황과 제안, 큰 diff를 가져왔고, 사람 팀원들은 이를 검토하고 피드백하며 통합해야 했다. 이 흐름은 도구 사용이라기보다 여러 신입 엔지니어를 이끄는 기술 리드의 업무와 비슷했다고 설명된다. Codex 덕분에 수작업 코딩 부담은 줄었지만, 개발 병목은 코드 입력에서 의사결정, 피드백, 변경 통합, 실제 앱 테스트로 옮겨갔고, 추가 세션을 무한히 늘린다고 선형적인 속도 향상이 생기지는 않는다는 점도 Brooks의 법칙과 연결된다.

10. iOS와 백엔드 코드베이스를 활용한 크로스플랫폼 작업

본문 후반부는 Android 프로젝트가 이미 출시된 iOS 버전이라는 큰 디딤돌을 갖고 시작했다는 점을 설명한다. 팀은 Codex가 요구사항과 제약을 이해하도록 iOS 코드베이스와 백엔드 코드베이스를 자주 참조하게 했다. Swift와 Kotlin처럼 구현 언어가 다르더라도, 데이터 모델, 네트워크 호출, 검증 규칙, 비즈니스 로직 같은 애플리케이션의 근본 논리는 공통으로 이어질 수 있다는 점이 작업에 도움이 됐다. 다만 이 역시 단순 복제가 아니라, Android 쪽의 기존 API 클라이언트와 모델 클래스, 팀이 정한 아키텍처 안에서 동등한 동작을 계획하고 구현하게 하는 방식으로 다뤄졌다.

🧾 핵심 주장 / 시사점

• Codex의 효과는 ‘얼마나 많은 코드를 쓰게 했는가’보다, 사람이 먼저 세운 아키텍처·예시·규칙 안에서 얼마나 좁고 명확한 문제를 맡겼는가에 크게 달려 있다.
• AI 코딩 도구를 병렬로 많이 띄우면 작성 속도는 빨라지지만, 최종 병목은 사람의 판단, 리뷰, 제품 경험 검증, 통합 관리로 이동하므로 기술 리드의 역할이 더 중요해진다.
• 성공적인 활용 방식은 한 번에 거대한 앱을 생성하게 하는 것이 아니라, 시스템 이해 → 계획 수립 → 사람의 보정 → 단계별 구현 → 검토라는 협업 루프를 만드는 데 있었다.

✅ 액션 아이템

• Codex 투입 전 4명 핵심 팀이 아키텍처, 모듈화, 의존성 주입, 인증, 기본 네트워킹 토대를 먼저 확정해 작업 경계를 만든다.
• 코드 작성은 패턴을 고정한 뒤 재생, 검색, 오류 처리, 테스트로 구분해 Codex 세션을 병렬 운용해 처리량을 확보한다.
• 개발 후반에는 코드 작성량보다 의사결정, 피드백 반영, 통합, 품질검토 단계가 병목이 되는지 정기적으로 점검한다.

❓ 열린 질문

• 코드 작성 병목이 줄어들었을 때 의사결정·피드백·통합·품질검토 간 우선순위를 어떤 기준으로 정할 것인가?
• Codex가 강한 제품 전략·아키텍처 취향·장기 구조 판단을 보완할 때 인간 검토가 반드시 개입해야 하는 경계는 어디인가?
• Sora Android처럼 28일 출시를 노릴 때 첫 24시간 100만 건 이상 사용량을 감당하려면 사전 점검 지표를 어떤 순서로 두어야 하는가?