Codex를 사용해 28일 만에 Android용 Sora를 구축한 방법

2026년 4월 26일 기준으로 Sora 제품은 더 이상 사용할 수 없습니다.

11월에 Sora Android 앱을 전 세계에 출시하여 Android 기기를 가진 누구나 짧은 프롬프트를 생생한 동영상으로 변환할 수 있게 했습니다. 출시 당일, 해당 앱은 Play 스토어 1위를 기록했습니다. Android 사용자는 첫 24시간 동안 100만 개가 넘는 동영상을 생성했습니다.

출시 비하인드 스토리: Sora의 프로덕션 Android 앱 초기 버전은 어떤 팀이나 개발자든 사용할 수 있는 동일한 에이전트인 Codex 덕분에 28일 만에 완성되었습니다.

2025년 10월 8일부터 11월 5일까지, Codex와 함께 작업하며 약 50억 토큰을 사용한 소규모 엔지니어링 팀은 프로토타입에서 글로벌 출시까지 Android용 Sora를 완성했습니다. 이러한 규모에도 불구하고 앱은 99.9%의 크래시 프리 비율을 기록했으며, 자랑할 만한 아키텍처를 갖추고 있습니다. 비밀 모델을 사용했는지 궁금하다면, 우리는 GPT‑5.1‑Codex의 초기 버전을 사용했습니다. 이 모델은 현재 어떤 개발자나 기업도 CLI, IDE 확장, 웹 앱을 통해 사용할 수 있는 동일한 버전입니다.

Sora가 iOS에 출시되었을 때 사용량은 폭발적으로 증가했습니다. 사람들은 즉시 동영상을 연속적으로 생성하기 시작했습니다. 반면 Android에서는 작은 내부 프로토타입만 있었고 Google Play에서 사전 등록 사용자 수만 늘어나고 있었습니다.

높은 위험과 시간 압박이 있는 출시 상황에서 흔한 대응은 리소스를 대거 투입하고 프로세스를 추가하는 것입니다. 이 정도 규모와 품질의 프로덕션 앱은 보통 수개월 동안 많은 엔지니어가 참여하며, 조율로 인해 속도가 느려집니다. 

미국의 컴퓨터 아키텍트 Fred Brooks는 “지연된 소프트웨어 프로젝트에 사람을 더 투입하면 더 늦어진다”고 경고한 바 있습니다. 즉, 복잡한 프로젝트를 빠르게 출시하려 할 때 엔지니어를 더 추가하면 커뮤니케이션 오버헤드, 작업 분산, 통합 비용이 늘어나 오히려 효율이 떨어질 수 있습니다. 우리는 이 통찰을 무시하지 않고 적극적으로 활용했습니다. Codex를 갖춘 네 명의 강력한 엔지니어 팀을 구성해 각 엔지니어의 영향력을 크게 높였습니다.

이렇게 작업하여 18일 만에 직원들에게 Android용 Sora의 내부 빌드를 배포하고 10일 후에 공개적으로 출시했습니다. Android 엔지니어링 모범 사례에 대한 높은 기준을 유지하고 유지보수성에 투자했으며, 기존 프로젝트와 동일한 신뢰성 기준을 적용했습니다. (현재도 앱을 발전시키고 새로운 기능을 추가하는 데 Codex를 광범위하게 사용하고 있습니다.)

Codex와 어떻게 협업했는지를 이해하려면 Codex의 강점과 지도가 필요한 부분을 아는 것이 도움이 됩니다. 신입으로 합류한 시니어 엔지니어처럼 대하는 접근 방식이 효과적이었습니다. Codex의 역량 덕분에 직접 코드를 작성하는 대신 방향을 제시하고 리뷰하는 데 더 많은 시간을 쓸 수 있었습니다.

Codex가 지침이 필요한 부분

1. Codex는 아직 명시적으로 알려주지 않은 것들(예: 선호하는 아키텍처 패턴, 제품 전략, 실제 사용자 행동, 내부 규범이나 관행)을 추론하는 데 능숙하지 않습니다.
2. 마찬가지로 Codex는 앱이 실제로 실행되는 모습을 볼 수 없기 때문에 기기에서 Sora를 열어 스크롤이 어색하다는 점을 알아차리거나 사용자 흐름이 혼란스러운지 감지할 수 없습니다. 이러한 경험적 작업은 우리 팀만이 수행할 수 있었습니다.
3. 각 인스턴스에는 온보딩이 필요합니다. 명확한 목표, 제약 조건, 그리고 “우리가 일을 하는 방식”에 대한 가이드를 포함한 컨텍스트 공유는 Codex가 잘 수행하도록 만드는 데 필수적이었습니다.
4. 같은 맥락에서 Codex는 깊이 있는 아키텍처 판단에 어려움을 겪었습니다. 그대로 두면 기존 뷰 모델을 확장해야 할 곳에 새로운 뷰 모델을 추가하거나, 리포지토리에 있어야 할 로직을 UI 레이어로 밀어 넣을 수 있습니다. Codex의 본능은 장기적인 구조적 깔끔함보다는 일단 작동하게 만드는 데 있습니다.

우리는 코드베이스 전반에 걸쳐 Codex가 다수의 AGENT.md 파일을 생성하고 유지하도록 하는 것이 유용하다는 것을 알게 되었습니다. 이를 통해 세션 전반에 동일한 가이드와 모범 사례를 쉽게 적용할 수 있었습니다. 예를 들어 Codex가 우리의 스타일 가이드라인에 맞게 코드를 작성하도록 하기 위해 최상위 AGENTS.md에 다음 내용을 추가했습니다.

Codex의 강점

1. 대규모 코드베이스를 빠르게 읽고 이해함: Codex는 거의 모든 주요 프로그래밍 언어를 알고 있어, 복잡한 추상화 없이 여러 플랫폼에서 동일한 개념을 활용하기 쉽습니다.
2. 테스트 커버리지: Codex는 다양한 경우를 포괄하는 단위 테스트 작성에 유독 적극적입니다. 모든 테스트가 깊이 있는 것은 아니었지만, 폭넓은 커버리지는 회귀를 방지하는 데 도움이 되었습니다. 
3. 피드백 적용: 비슷한 맥락에서 Codex는 피드백에 잘 반응합니다. CI가 실패했을 때 로그 출력을 프롬프트에 붙여 넣고 Codex에게 수정안을 제안하도록 할 수 있었습니다.
4. 대규모 병렬 실행 및 일회성 실행: 대부분은 동시에 실행할 수 있는 세션 수의 한계를 시험하지도 않을 것입니다. 여러 아이디어를 병렬로 테스트하고 코드를 일회성으로 다루는 것이 매우 현실적입니다.
5. 새로운 관점 제공: 설계 논의에서 Codex를 생성 툴로 활용해 잠재적인 실패 지점을 탐색하고 새로운 문제 해결 방식을 발견했습니다. 예를 들어 비디오 플레이어 메모리 최적화를 설계할 때 Codex는 여러 SDK를 검토해 우리가 직접 살펴볼 시간이 없었을 접근 방식을 제안했습니다. Codex의 조사에서 나온 인사이트는 최종 앱의 메모리 사용량을 최소화하는 데 매우 중요했습니다.
6. 고부가가치 작업 가능: 실제로는 직접 코드를 작성하는 시간보다 리뷰하고 방향을 제시하는 데 더 많은 시간을 쓰게 되었습니다. 그럼에도 Codex는 코드 리뷰도 매우 잘 수행하며, 병합 전에 버그를 발견해 신뢰성을 높이는 경우가 많았습니다.

이러한 특성을 인식한 이후 우리의 작업 방식은 훨씬 단순해졌습니다. 명확히 이해된 패턴과 제한된 범위 내의 대규모 작업은 Codex에 맡기고, 우리 팀은 아키텍처, 사용자 경험, 시스템 전반의 변화, 최종 품질에 집중했습니다.

아무리 뛰어난 시니어 인재라도 처음부터 장기적인 트레이드오프를 판단할 올바른 시야를 갖추기는 어렵습니다. Codex를 효과적으로 활용하고 결과물이 견고하고 유지보수 가능하도록 하기 위해, 앱의 시스템 설계와 핵심 트레이드오프는 우리가 직접 관리하는 것이 중요했습니다. 여기에는 앱 아키텍처, 모듈화, 의존성 주입, 내비게이션 설계가 포함되었으며, 인증과 기본 네트워킹 흐름도 직접 구현했습니다. 

이 기초를 바탕으로 몇 가지 대표 기능을 처음부터 끝까지 직접 작성했습니다. 전체 코드베이스에 적용하고자 하는 규칙을 사용하고, 프로젝트 전반의 패턴을 진행하면서 문서화했습니다. Codex에게 대표 기능을 보여줌으로써, 우리의 기준 안에서 더 독립적으로 작업할 수 있었습니다. 약 85%가 Codex에 의해 작성된 프로젝트에서, 신중하게 계획된 기초는 비용이 큰 되돌림과 리팩터링을 피하는 데 도움이 되었습니다. 이는 우리가 내린 가장 중요한 결정 중 하나였습니다. 

목표는 가능한 한 빨리 “작동하는 것”을 만드는 것이 아니라, “우리가 원하는 방식으로 작동하는 것”을 만드는 것이었습니다. 코드를 작성하는 데에는 많은 “올바른” 방법이 있습니다. Codex에게 정확히 무엇을 하라고 지시할 필요는 없었고, 우리 팀에서 무엇이 “올바른지”를 보여주는 것이 중요했습니다. 출발점과 우리가 선호하는 개발 방식을 확립하자 Codex는 작업을 시작할 준비가 되었습니다.

어떤 결과가 나오는지 보기 위해 “iOS 코드를 기반으로 Sora Android 앱을 만들어줘”라는 프롬프트를 시도해 보기도 했습니다. “시작해”라는 지시였지만, 우리는 곧 이 접근을 중단했습니다 Codex가 만든 결과물은 기술적으로는 작동했지만 제품 경험은 기대에 미치지 못했습니다. 엔드포인트, 데이터, 사용자 흐름에 대한 명확한 이해 없이 생성된 Codex의 단발성 코드는 신뢰하기 어려웠습니다(에이전트를 사용하지 않더라도 수천 줄의 코드를 한 번에 병합하는 것은 위험합니다). 

우리는 Codex가 잘 작성된 예제들로 구성된 샌드박스 환경에서 가장 잘 작동할 것이라고 가정했고, 그 가정은 옳았습니다. 거의 아무런 컨텍스트 없이 Codex에게 “이 설정 화면을 만들어줘”라고 요청하는 것은 신뢰하기 어려웠습니다. 반면 “방금 본 다른 화면과 동일한 아키텍처와 패턴을 사용해 이 설정 화면을 만들어줘”라고 요청하면 훨씬 잘 작동했습니다. 구조적 결정과 불변 조건은 사람이 정하고, Codex는 그 구조 안에서 대량의 코드를 채워 넣었습니다.

Codex의 잠재력을 극대화하기 위한 다음 단계는 Codex가 감독 없이 장시간(최근에는 24시간 이상⁠) 작업할 수 있도록 하는 방법을 찾는 것이었습니다.

Codex를 처음 사용할 때 우리는 “이것이 기능이다. 여기에 몇 개의 파일이 있다. 이것을 만들어 달라.”와 같은 프롬프트를 바로 사용했습니다. 이 방식은 가끔은 작동했지만, 대부분은 컴파일은 되지만 아키텍처와 목표에서 벗어난 코드를 만들어냈습니다.

그래서 우리는 워크플로를 변경했습니다. 중요도가 있는 변경 사항의 경우, 먼저 Codex에게 시스템과 코드가 어떻게 작동하는지 이해하도록 요청했습니다. 예를 들어 관련 파일 세트를 읽고 해당 기능이 어떻게 작동하는지, 즉 데이터가 API에서 리포지토리 레이어와 뷰 모델을 거쳐 UI로 어떻게 흐르는지를 요약하도록 요청했습니다. 그런 다음 Codex의 이해를 수정하거나 보완했습니다. (예를 들어 특정 추상화는 실제로 다른 레이어에 속해야 한다거나, 어떤 클래스는 오프라인 모드 전용이므로 확장해서는 안 된다는 점을 짚어주었습니다.)

새롭고 역량 있는 팀원을 영입할 때와 마찬가지로, 우리는 Codex와 협력하여 탄탄한 구현 계획을 수립했습니다. 이 계획은 어떤 파일을 변경해야 하는지, 어떤 새로운 상태를 도입해야 하는지, 로직이 어떻게 흐를지를 안내하는 작은 설계 문서와 같은 형태였습니다. 그 후에야 Codex에게 계획을 한 단계씩 적용하도록 요청했습니다. 유용한 팁 하나: 작업이 매우 길어 컨텍스트 한계에 도달했을 때 Codex에게 계획을 파일로 저장하게 해 여러 인스턴스에 동일한 방향성을 적용하도록 했습니다.

이 추가적인 계획 단계는 시간을 들일 만한 가치가 있었습니다. 계획을 알고 있었기 때문에 Codex를 장시간 사실상 무감독 상태로 실행할 수 있었습니다. 컨텍스트 없이 변경 사항만 보는 대신 계획과 구현을 대조할 수 있어 코드 리뷰도 훨씬 쉬워졌습니다. 문제가 발생했을 때도 먼저 계획을, 그다음에 코드를 디버깅할 수 있었습니다. 

이 과정은 훌륭한 설계 문서가 기술 리드에게 프로젝트에 대한 확신을 주는 방식과 유사하게 느껴졌습니다. 우리는 단순히 코드를 생성한 것이 아니라, 공통 로드맵을 뒷받침하는 코드를 만들고 있었습니다.

프로젝트가 한창일 때는 여러 Codex 세션을 병렬로 실행하는 경우가 많았습니다. 한 세션은 재생 기능을, 다른 세션은 검색을, 또 다른 세션은 오류 처리를 맡았고, 때로는 테스트나 리팩터링을 담당하는 세션도 있었습니다. 툴을 사용하는 느낌보다는 팀을 관리하는 느낌에 가까웠습니다.

각 세션은 주기적으로 진행 상황을 보고했습니다. 어떤 세션은 “이 모듈의 계획을 마쳤고, 이렇게 제안합니다”라고 보고했고, 또 다른 세션은 새로운 기능에 대한 큰 변경 사항을 제시했습니다. 각각에 대해 관심을 기울이고, 피드백을 주고, 리뷰를 해야 했습니다. 여러 명의 신규 엔지니어가 각자 진척을 내면서 동시에 지도가 필요한 상황의 기술 리드가 된 것과 놀라울 정도로 비슷했습니다.

그 결과 협업적인 흐름이 만들어졌습니다. Codex의 순수한 코딩 역량 덕분에 많은 수작업 타이핑에서 벗어날 수 있었습니다. 아키텍처를 고민하고, 풀 리퀘스트를 꼼꼼히 읽고, 앱을 테스트할 시간이 더 많아졌습니다. 

동시에 속도가 빨라지면서 리뷰 대기열에는 항상 처리할 작업이 쌓여 있었습니다. Codex는 컨텍스트 전환에 막히지 않았지만, 우리는 그 영향을 받았습니다. 개발의 병목 지점은 코드 작성에서 의사결정, 피드백 제공, 변경 사항 통합으로 이동했습니다.

이 지점에서 브룩스의 통찰이 새로운 방식으로 적용됩니다. 프로젝트에 엔지니어를 계속 추가한다고 해서 일정이 선형적으로 줄어들지 않는 것처럼, Codex 세션을 늘린다고 해서 선형적인 속도 향상을 기대할 수는 없습니다. 가상의 손을 포함해 손이 하나 늘어날 때마다 조율 오버헤드가 추가됩니다. 우리는 더 빠른 솔로 연주자가 아니라 오케스트라의 지휘자가 되었습니다.

우리는 큰 디딤돌을 가지고 프로젝트를 시작했습니다. Sora는 이미 iOS에 출시된 상태였습니다. 우리는 Codex가 주요 요구 사항과 제약 조건을 이해할 수 있도록 iOS 및 백엔드 코드베이스를 자주 참조하게 했습니다. 프로젝트 내내 우리는 크로스 플랫폼 프레임워크를 새로 발명한 것 같다는 농담을 하곤 했습니다. React Native나 Flutter는 잊으세요. 크로스 플랫폼의 미래는 Codex 그 자체입니다.

이 농담 아래에는 두 가지 원칙이 있습니다.

1. 로직은 이식 가능합니다. 코드가 Swift로 작성되었든 Kotlin으로 작성되었든, 데이터 모델, 네트워크 호출, 검증 규칙, 비즈니스 로직과 같은 기본 애플리케이션 로직은 동일합니다. Codex는 Swift 구현을 읽고 의미를 보존한 Kotlin 코드로 변환하는 데 매우 뛰어납니다.
2. 구체적인 예시는 강력한 컨텍스트를 제공합니다. “이것이 iOS에서 정확히 어떻게 작동하는지”와 “이것이 Android 아키텍처다”를 함께 볼 수 있는 새로운 Codex 세션은 자연어 설명만으로 작업하는 경우보다 훨씬 효과적입니다.

이 원칙을 적용해 iOS, 백엔드, Android 리포지토리를 동일한 환경에서 접근 가능하게 했습니다. 우리는 Codex에게 다음과 같은 프롬프트를 제공했습니다.

“iOS 코드의 모델과 엔드포인트를 읽고, 기존 API 클라이언트와 모델 클래스를 사용해 Android에서 동일한 동작을 구현하기 위한 계획을 제안해줘.”

작지만 유용한 요령 중 하나는 ~/.codex/AGENTS.md에 로컬 리포지토리의 위치와 내용을 상세히 적어두는 것이었습니다. 이를 통해 Codex가 관련 코드를 더 쉽게 찾고 탐색할 수 있었습니다.

우리는 공통 추상화를 사용하는 대신 번역을 통해 사실상 크로스 플랫폼 개발을 수행하고 있었습니다. Codex가 대부분의 번역을 처리했기 때문에 구현 비용을 두 배로 들이지 않을 수 있었습니다.

더 큰 교훈은 Codex에게 컨텍스트가 모든 것이라는 점입니다. Codex는 기능이 iOS에서 어떻게 작동하는지, 그리고 Android 앱이 어떻게 구성되어 있는지를 함께 이해했을 때 최고의 성과를 냈습니다. Codex가 그런 컨텍스트를 갖지 못했을 때 협조를 거부한 것이 아니라, 추측하고 있었던 것입니다. 새로운 팀원처럼 대하고 올바른 입력을 제공하는 데 투자할수록 Codex의 성과는 더 좋아졌습니다.

4주간의 스프린트가 끝날 무렵, Codex 사용은 더 이상 실험이 아니라 기본 개발 루프가 되었습니다. 기존 코드를 이해하고, 변경 사항을 계획하고, 기능을 구현하는 데 Codex를 활용했습니다. 팀원의 결과물을 리뷰하듯 Codex의 결과물도 동일하게 검토했습니다. 그것이 곧 우리가 소프트웨어를 출시하는 방식이었습니다.

AI 지원 개발은 엄격함의 필요성을 줄이지 않으며, 오히려 더 높인다는 점이 분명해졌습니다. Codex가 아무리 뛰어나더라도, 그 목표는 지금 당장 A에서 B로 가는 것입니다. 이것이 바로 AI 지원 코딩이 인간 없이 작동할 수 없는 이유입니다. 소프트웨어 엔지니어는 시스템의 현실적 제약을 이해하고 적용하며, 최적의 아키텍처를 설계하고, 향후 개발과 제품 계획을 염두에 두고 구축할 수 있습니다. 미래의 소프트웨어 엔지니어가 갖춰야 할 핵심 역량은 깊은 시스템 이해와 장기적인 관점에서 AI와 협업하는 능력입니다. 

소프트웨어 엔지니어링에서 가장 흥미로운 부분은 매력적인 제품을 만들고, 확장 가능한 시스템을 설계하며, 복잡한 알고리즘을 작성하고, 데이터와 패턴, 코드로 실험하는 일입니다. 하지만 과거와 현재의 소프트웨어 엔지니어링 현실은 버튼 정렬, 엔드포인트 연결, 보일러플레이트 작성과 같은 다소 단조로운 작업에 치우쳐 있었습니다. 이제 Codex를 통해 소프트웨어 엔지니어링에서 가장 의미 있는 부분과 우리가 이 일을 사랑하는 이유에 집중할 수 있습니다.

Codex가 목표와 선호하는 개발 방식을 이해하는 컨텍스트가 풍부한 환경에 설정되면, 어떤 팀이든 역량을 배가할 수 있습니다. 이번 출시 회고는 만능 해법이 아니며, AI 지원 개발을 완전히 해결했다고 주장하는 것도 아닙니다. 다만 우리의 경험이 Codex를 통해 여러분의 역량을 확장하는 최적의 방법을 찾는 데 도움이 되기를 바랍니다. 

7개월 전 Codex가 연구 미리보기로 출시되었을 때, 소프트웨어 엔지니어링의 모습은 지금과 매우 달랐습니다. Sora를 통해 우리는 엔지니어링의 다음 장을 탐색할 수 있었습니다. 모델과 하네스가 계속 발전함에 따라 AI는 구축 과정에서 점점 더 필수적인 요소가 될 것입니다. 

여러분은 Codex 팀과 함께 무엇을 만들고 싶으신가요?