OpenAI Codex 제품 책임자가 직접 밝힌다: 규범도 로드맵도 없이 우리는 어떻게 제품을 만들었을까?
정리 & 번역: TechFlow
게스트: Alex, Codex 제품 책임자; Romain, Codex 개발자 경험 담당자
진행자: Peter Yang
팟캐스트 출처: Peter Yang
원제목: How OpenAI's Codex Team Builds with Codex (43 Min) | Alex & Romain
방송일: 2026년 4월 5일
핵심 요약
Alex는 Codex의 제품 책임자이며, Romain은 개발자 경험을 담당한다. 이들은 Codex 팀이 실제로 어떻게 운영되는지, Codex를 사용해 제품을 어떻게 구축하는지, 그리고 전통적인 제품 사양서나 로드맵 없이 어떻게 제품을 출시하는지를 낯설지만 귀중한 시각으로 보여주었다. Alex는 또한 제품 매니저(PM)의 미래 진화 방향과 채용 과정에서 진정으로 중요한 요소들에 대한 독특한 통찰을 공유했다.
주요 통찰 요약
실시간 구축 및 Codex Spark의 ‘사고 속도’
- “무언가를 구축하려 할 때… 빠른 모드 또는 Codex Spark로 전환하면 그야말로 미친 듯한 사고 속도로 무엇이든 만들 수 있습니다. 왼쪽은 GPT-5.4이고, 오른쪽은 Codex Spark입니다. 초당 약 1200개의 토큰(token)을 처리하죠. 정말 엄청난 속도예요.” — Romain
사양 문서와 의사결정 프로세스에 관하여
- “저희 Codex 팀에서는 사양 문서를 거의 쓰지 않습니다. 사실 대부분의 작업은 실제 현장에 가장 가까운 사람이 가능한 한 많은 결정을 내리도록 하는 데 집중합니다. 따라서 문제가 한 사람의 머릿속에 담기 어려울 정도로 복잡해질 때만 사양서를 작성합니다.” — Alex
직업 경계의 흐림과 디자이너의 진화
- “우리 팀의 디자이너들이 지금 작성하는 코드량은 6개월 전의 엔지니어보다 더 많습니다. 이제 우리의 초점은 ‘코드를 생성할 수 있는가’가 아니라, ‘무엇을 하기로 결정했는가’, 그리고 ‘제품의 품질을 어떻게 보장할 것인가’에 맞춰져 있습니다. 그래서 매우 복잡한 기능의 경우, PM이 해당 시스템의 구현 및 유지보수를 맡기보다는, 신뢰할 수 있는 담당자를 선임해 관리하도록 하는 편이 낫다고 생각합니다.” — Alex
제품 설계 철학: 모델을 ‘투명하게’ 만들기
- “핵심 기능 설계에는 매우 신중하게 접근해, 사용자와 모델 사이의 장애물이 되지 않도록 합니다. 대신 모델이 더욱 지능적으로 작동해 자동으로 더 많은 작업을 수행하도록 만듭니다.” — Alex
- “그런 다음 이를 바탕으로 고급 사용자에게 최대한 설정 가능한 방식으로 제품을 패키징해, 스스로 탐색하고 활용할 수 있도록 합니다. 예를 들어, 현재 일부 사용자는 이미 sub-agents(서브 에이전트)를 구현했습니다.” — Romain
계획 철학: ‘중기적 어색함’ 거부하기
- “OpenAI에서는 단기 목표나 장기 목표만 계획하지, 중기 계획은 하지 않습니다. 중기 계획은 너무 복잡하기 때문입니다. 단기 계획은 일반적으로 현재로부터 최대 8주까지의 목표를 의미하며, 이것이 우리가 설정할 수 있는 최장 기간입니다. 동시에 우리는 장기 비전도 수립합니다. 예를 들어, 1년 후의 미래를 상상해보면, 그때의 모델은 훨씬 더 지능적이 될 것입니다. 그러나 중기 계획은 다소 어색하게 느껴집니다. 보통 상세한 제품 로드맵 형태로 나타나는데, 저희는 그런 것을 거의 갖지 않습니다. 대신 장기 비전을 바탕으로, 그 목표 달성으로 이끄는 구체적인 작업에 집중합니다.” — Alex
‘지능형 에이전트 위임(agentic delegation)’이 가져올 인터페이스 혁명
- “코딩은 ‘지능형 에이전트 위임’ 방식으로 이루어질 것입니다. 터미널에서 여러 탭을 열어 몇 시간 동안 실행하는 것은 매우 이상한 상호작용 방식입니다. 우리는 완전히 새로운 인터페이스가 필요하며, 지금이 바로 그 적절한 순간입니다.” — Romain
직업 승진 경로의 소멸과 ‘인재 스택 붕괴(collapse the talent stack)’
- “이는 거의 모든 전통적인 직업 승진 경로를 흐릿하게 만들고 있습니다. 우리 각자는 모두 ‘빌더(builder)’이며, 함께 협력해 구축해 나갑니다. 만약 초기 스타트업에 PM이 있고 엔지니어가 약 20명 미만이라면, 이는 위험 신호일 수 있습니다. 관심사와 자율성은 AGI 시대에 인간이 지녀야 할 가장 핵심적이고 중요한 자질입니다.” — Romain / Alex
채용 기준: 이력서보다 작품이 우선
- “누군가 DM을 통해 우리 팀에 합류하고 싶다고 표현할 때, 제가 가장 먼저 확인하는 건 링크가 있는지 여부입니다. 링크가 있다면 항상 클릭해 그들이 실제로 무언가를 구축하고 있는지 확인합니다. 저는 그들의 아이디어와 실제로 구축한 것들을 보는 데 더 큰 관심이 있습니다. 그들이 어느 대학을 졸업했는지는 전혀 알지 못합니다.” — Alex
현장 데모: Codex Spark로 몇 초 안에 게임 구축하기
진행자 Peter: 오늘 Alex와 Romain을 모시고 OpenAI의 Codex 팀에 대해 이야기 나눌 수 있어 정말 기쁩니다. 그들은 Codex의 새 기능을 어떻게 구축하는지, Codex가 어떤 능력을 갖추고 있는지, 또 Codex 팀이 어떻게 끊임없이 제품을 출시하는지를 시연할 예정입니다. 일회성 프롬프트(one-shot prompt)로 실제로 무엇을 구축할 수 있는지 간단히 보여주시겠습니까?
Romain:
물론입니다. 제 화면을 공유해 드릴게요. 보여드릴 수 있는 것이 정말 많지만, 빠르게 한 가지 예시를 살펴보겠습니다—예를 들어, 제가 지금 구축 중인 iOS 앱이 있습니다. 이 앱에 새 기능을 추가하려면, 간단히 음성으로 말할 수 있습니다. “헤이, NASA의 달 귀환 임무를 위한 새 화면을 추가해 줄 수 있나요?” 그런 다음 GPT-5.4로 이 프롬프트를 보내면, 모델이 해당 앱을 위해 특별히 새 화면을 생성해 줍니다.
하지만 저희는 Codex Spark라는 모델도 보유하고 있어, 어떤 것이라도 몇 초 안에 구상하고 반복할 수 있게 도와줍니다. Spark 모델의 빠른 응답 차이를 보여드리겠습니다. 왼쪽은 GPT-5.4이고, 오른쪽은 Codex Spark입니다. 초당 약 1200개의 토큰을 처리합니다. 정말 엄청난 속도죠. 따라서 게임 같은 무언가를 구축하려 할 때—이 대화를 시작하기 직전, 저는 실제로 Codex 앱에 들어가서 간단한 프롬프트 하나로 Animal Crossing과 유사한 작은 2D 게임을 만들었습니다.
제 사고가 명료할 때 제가 Codex에서 특히 좋아하는 또 다른 기능은, Codex를 열고 대화 창을 화면 상단에 고정하는 것입니다. 이렇게 하면 게임을 직접 개발하면서 계속해서 반복하고 더 많은 아이디어를 얻을 수 있습니다. Peter님, 이 게임에 어떤 변화를 원하시나요?
Peter: 아마 더 많은 장식, 집, 나무 등을 추가해 좀 더 생동감 있게 만들어 주면 좋겠네요.
Romain:
그럼 이 작업을 전송하겠습니다. 기본적으로 몇 초 안에 Codex Spark가 편집을 완료하고, 실시간으로 변화를 확인할 수 있습니다. 잘됐네요, 새로운 나무가 나타났습니다.
그래서 제가 Codex에 이렇게 흥분하는 이유는, GPT-5.4처럼 최첨단 모델을 사용해 수백만 줄의 코드 분석이나 마이그레이션 같은 매우 복잡한 작업을 맡길 수 있기 때문입니다. 하지만 영감이 샘솟고 사고가 명료할 때는 빠른 모드 혹은 Codex Spark로 전환해, 어떤 것이라도 만들 수 있는 미친 듯한 사고 속도를 얻을 수 있기 때문입니다.
제품 사양서는 약 10개 항목만 작성합니다. 그뿐입니다.
진행자 Peter: 정말 흥미롭습니다. Alex님, 실제로 Codex 팀에서 어떻게 Codex를 사용해 제품을 구축하는지 궁금합니다. 여전히 사양서를 작성하시나요? 아니면 GPT에게 사양서를 작성하게 하시나요? 이런 작업을 위해 어떤 모델을 사용하시나요?
Alex:
저희 Codex 팀에서 작성하는 사양서는 정말 거의 없습니다. 사실 대부분의 작업은 현장에 가장 가까운 사람이 가능한 한 많은 결정을 내리도록 하는 데 집중합니다. 따라서 문제가 한 사람의 머릿속에 담기 어려울 정도로 복잡해질 때만 사양서를 작성합니다. 참고로, 지금은 한 사람이 머릿속에 담을 수 있는 것이 훨씬 많아졌습니다. 그들은 대부분의 코딩 작업을 위임하기 때문에, 한 사람이 지금은 훨씬 더 많은 일을 할 수 있습니다. 하지만 결국 여러 사람이 조율해야 할 문제로 발전하거나, 우리가 내려야 할 매우 까다로운 결정이 되었을 때, 아마도 사양서를 작성할 수도 있습니다. 다만 이런 경우에 작성하는 문서는 대개 매우 짧습니다. 보통 10개 항목 정도의 요약만 적고 끝냅니다.
진행자 Peter: 그렇군요. 이 방식이 어떻게 작동하는지 보여주실 수 있나요? 예를 들어, Codex에 몇 개의 항목을 입력하면, 그것으로부터 실제 요구사항을 먼저 작성해 주는 건가요?
Romain:
물론입니다! 다만, 먼저 더 간단한 예시를 보여드리겠습니다. 우리가 iOS 앱을 개발 중이고, 이미 일부 기능을 완료했다고 가정해 봅시다. 이제 이 프로젝트에 대한 새 기능 아이디어는 있지만, 구체적인 방향이 아직 불확실합니다. 이때 Codex의 강점은 다음 단계의 작업 계획을 도와주는 데 있습니다. 예를 들어, Shift+Tab 키를 눌러 ‘계획 모드(Plan Mode)’로 진입한 후 ‘우리가 무엇을 구축할 것인가?’라고 입력하면, Codex가 자동으로 초기 계획을 생성해 줍니다. Codex는 기존 코드베이스를 분석하고 프로젝트의 현재 상태를 파악한 후, 잠재적인 아이디어를 제안합니다. 동시에 제가 직접 아이디어를 덧붙여, 더 완성도 높은 계획을 유도할 수도 있습니다.
이 과정에서 Codex가 현재 코드와 파일을 바탕으로 조언을 제공하는 것을 확인하실 수 있습니다. 예를 들어, “이전에 언급된 기능을 계속 다듬을 것인가, 아니면 신뢰성 대시보드를 최적화할 것인가?”라고 질문할 수 있습니다. 만약 신뢰성 대시보드 최적화를 선택한다면, Codex는 추가로 ‘최적화 대상 사용자는 누구인가?’ 같은 질문을 통해 더 깊이 생각하도록 유도합니다. 이 전체 과정은 마치 두뇌세포를 자극하는 협업 파트너와 함께 일하는 것과 같습니다.
저는 종종 이런 방식으로 아이디어를 유도합니다. 예를 들어, 간단한 변경 사항의 경우, 바로 프롬프트를 입력해 Codex가 코드를 생성하게 합니다.
Alex:
중간 수준의 복잡도를 가진 변경 사항의 경우, 저는 구체적인 계획을 생성하거나 구현 방식을 추론해 주도록 요청할 수 있습니다. 그리고 막연한 아이디어만 있을 때는, 그냥 Codex를 열어 문제 해결 방법을 함께 고민하게 합니다. 구체적인 기능 요구사항조차 머릿속에 없더라도, Codex는 질문과 탐색을 통해 제 사고를 정리해 줍니다.
솔직히 말해, 복잡한 변경 사항의 경우 Codex가 생성한 솔루션을 직접 사용하지 않을 때도 있습니다. 저는 Codex의 ‘계획 모드’를 탐색해 명확한 사고 흐름을 형성한 후, 이 아이디어를 엔지니어 팀과 공유합니다. 결국 이 사고 과정 자체가 생성된 계획보다 훨씬 중요합니다.
참고로, 우리 팀의 디자이너들이 지금 작성하는 코드량은 6개월 전의 엔지니어보다 더 많습니다. 이건 과거에는 상상도 못했던 일이죠. 이는 도구의 진보 덕분에 디자이너가 개발에 훨씬 더 깊이 참여할 수 있게 되었기 때문입니다. 다만, 지난해 제가 제출한 PR(코드 병합 요청)이 너무 적다는 팀원들의 농담을 종종 듣기도 합니다. 많은 변경 사항이 사소한 조정일 뿐이지만, 저는 확실히 더 많이 해야 한다고 느낍니다.
현재 우리의 초점은 ‘코드를 생성할 수 있는가’가 아니라, 에이전트(agent)가 대부분의 코딩 작업을 이미 수행할 수 있다는 점을 고려해, ‘무엇을 하기로 결정했는가’와 ‘제품의 품질을 어떻게 보장할 것인가’에 맞춰져 있습니다. 그래서 매우 복잡한 기능의 경우, PM이 해당 시스템의 구현 및 유지보수를 맡기보다는, 신뢰할 수 있는 담당자를 선임해 관리하도록 하는 편이 낫다고 생각합니다.
디자이너가 6개월 전 엔지니어보다 더 많은 코드를 작성한다
진행자 Peter:Codex 애플리케이션은 매우 직관적이고 간단하게 사용됩니다. 외부의 전문 제품들과 비교해 보면, Codex의 학습 곡선은 훨씬 낮습니다. 다른 전문 제품들은 기능은 강력하지만, 익히는 데 상당한 시간이 걸립니다. 심지어 제가 트위터에서 관련 정보를 따로 챙기지 않으면, 어떻게 사용해야 할지도 모르겠을 정도입니다.
하지만 Codex가 저를 인상 깊게 만든 점은, 단순히 쉬운 사용성뿐 아니라 skills(기술) 및 automations(자동화) 같은 고급 기능도 풍부하다는 점입니다. 여러분 팀 내부에서도 이러한 기능을 자주 사용하시나요?
Romain:
네, 매우 자주 사용합니다. 사실 skills는 Codex 애플리케이션에서 가장 흥미로운 기능 중 하나라고 생각합니다. 예를 들어, 지금 Figma와 디자이너가 함께 작업 중이라면, Figma skill을 열기만 하면 Figma 파일에서 모든 React 컴포넌트와 변수 등 세부 정보를 자동으로 추출하고, Codex가 이에 맞는 코드를 즉시 생성합니다. 또 애플리케이션을 개발 중인데 Vercel, Cloudflare 또는 Render에 배포하거나 공유하려면, skills를 통해 간단한 명령어만 입력하면 Codex가 자동으로 모든 작업을 완료합니다.
최근 친구와 대화를 나누던 중, 그가 제품을 개선할 수 있는 많은 아이디어가 있다고 말했습니다. 그래서 그는 Codex에게 “이 모든 작업을 Linear에 기록해, 내가 쉽게 추적할 수 있게 해줘”라고 말했습니다. 그리고 Linear skill을 사용했습니다. 이어서 “이제 자러 갈 테니, 우리가 방금 논의한 모든 작업을 완료하고 완료 표시해줘”라고 요청했습니다. 다음 날 아침 그는 모든 작업이 실제로 완료된 것을 확인했습니다.
Alex:
방금 말씀하신 애플리케이션의 단순성에 관해, 우리가 어떻게 설계를 고민했는지 말씀드릴 수 있습니다. 이 분야에서는 개발자들이 자신을 위한 자동화 도구를 구축하는 것을 매우 즐깁니다. 우리는 제품의 핵심 특성 중 하나가 높은 설정 가능성(highest configurability)을 가져야 한다고 믿습니다. Codex는 마치 오픈소스 도구상자처럼, 사용자가 자신의 필요에 따라 깊이 파고들어 맞춤화할 수 있도록 설계되었습니다.
새 기능을 출시할 때마다, 트위터에서는 아직 공식 출시도 되지 않은 기능에 대해 불평하는 사용자들이 종종 있습니다. 문제의 원인은 대개 그들이 직접 코드를 수정하거나 fork했기 때문입니다. 그러나 저로서는 이것이 오히려 제품의 성공을 입증한다고 봅니다. 앞선 사용자들이 미래를 함께 탐색하고 제품을 발전시키고 있다는 증거이기 때문입니다.
하지만 동시에 우리는 고급 사용자만을 위한 제품을 만드는 것으로는 부족하다는 점도 인식하고 있습니다. 그렇지 않으면 제품은 결국 복잡하고 이해하기 어려워질 것입니다. 우리는 고급 사용자의 요구를 충족시키면서도 일반 사용자에게는 단순하고 직관적인 제품을 만들기 위한 균형점을 찾아야 합니다. 따라서 핵심 기능 설계에는 매우 신중하게 접근해, 사용자와 모델 사이의 장애물이 되지 않도록 합니다. 대신 모델이 더욱 지능적으로 작동해 자동으로 더 많은 작업을 수행하도록 만듭니다.
Romain:
그런 다음, 고급 사용자에게 최대한 설정 가능한 방식으로 제품을 패키징해, 스스로 탐색하고 활용할 수 있도록 합니다. 예를 들어, 현재 일부 사용자는 이미 sub-agents(서브 에이전트)를 구현했습니다. 이러한 기능은 우리가 의도적으로 설계한 것이 아니라, 사용자 스스로 발견하고 실험한 결과입니다. 사용자가 이 기능을 어떻게 활용하는지 관찰함으로써, 우리는 많은 것을 배웁니다.
그리고 나서 우리는 ‘이 기능을 다른 사용자에게도 얼마나 쉽게 만들 수 있을까?’를 고민합니다. Codex 앱은 좋은 예시입니다. GPT-5.2 Codex가 작년 12월에 출시되면서, 모델의 능력이 점차 안정화되기 시작했고, 동시에 한계를 넘는 전환점(critical point)을 맞이했습니다. 이제 사용자는 더 오랜 시간, 더 복잡한 작업을 모델에 위임할 수 있게 되었으며, 모델은 이를 한 번에 완료할 수 있습니다.
우리는 일부 사용자가 tmuxing(터미널에서 여러 병렬 작업을 실행하는 방식)을 사용하고 있음을 주목하기 시작했습니다. 이는 터미널 창을 분할해 여러 작업을 동시에 실행하는 방식입니다. 소셜미디어에서는 매우 흥미로운 사례들이 올라왔습니다. 예를 들어, Peter Steinberger의 사진에는 18개의 터미널 창이 세 개의 모니터에 걸쳐 있으며, 마치 ‘창의적인 열린 발톱’처럼 보입니다. Codex를 이렇게 고도로 활용하는 사용자들을 보며, 우리는 매우 흥분했습니다.
한편, CLI와 같은 기본 제품의 작업 위임 기능을 계속해서 최적화해, 잘 작동하도록 하고 있습니다. 그러나 이 방식으로 작업하는 건 아마 최상위 1%의 엔지니어에 불과할 것이라는 점도 인식했습니다. 그래서 우리는 ‘이 기능을 어떻게 더 직관적으로 만들 수 있을까?’를 고민했습니다. 이것이 Codex 앱을 개발하게 된 이유입니다.
Codex 앱을 처음 열면, 단순한 채팅 창처럼 보입니다. 바로 사용을 시작할 수 있고, 정상적으로 작동합니다. 하지만 시간이 지나면서 사이드바, 여러 작업 동시 실행, 작업 간 전환 등 더 많은 기능을 점차 발견하게 됩니다. 그렇게 하면 자신이 매우 효율적으로 일하고 있다는 느낌을 받게 됩니다. 그러다 보면 ‘skills’ 탭을 눈치 채고, 클릭해 더 많은 기능을 탐색하게 됩니다. 우리는 사용자가 Codex 앱을 사용할 때, 마치 게임을 하듯 새로운 가능성을 끊임없이 발견하는 경험을 하기를 바랍니다.
Romain:
완전히 동의합니다. 그리고 이것은 우리 팀이 처음부터 가지고 있었던 비전이기도 합니다. 코딩은 ‘지능형 에이전트 위임(agentic delegation)’ 방식으로 이루어질 것입니다. 사실, 우리가 거의 1년 전 Codex 개발을 시작했을 때부터 이 미래를 고민해 왔습니다. 우리는 엔지니어가 여러 작업을 동시에 처리하고, 모델이 복잡한 세부 작업을 담당할 수 있을 것이라고 믿습니다.
솔직히 말해, 당시 모델의 능력은 아직 이 수준에 도달하지 못했습니다. 우리는 GPT-5.2 Codex 출시와 이후의 전환점까지 기다려야 했습니다. 모델이 몇 시간 혹은 며칠 동안 매우 철저하고 신뢰성 있게 작동할 수 있게 된 순간, 우리는 전통적인 터미널 인터페이스가 더 이상 이 작업 방식에 적합하지 않다는 것을 깨달았습니다. 터미널에서 여러 탭을 열어 몇 시간 동안 실행하는 것은 매우 이상한 상호작용 방식입니다. 따라서 우리는 완전히 새로운 인터페이스가 필요했고, 그 적절한 시기가 바로 지금이었습니다.
Alex:
Codex의 발전 과정을 돌아보면, 두 가지 중요한 ‘vibe shift’(분위기 전환점)가 있었습니다. 첫 번째는 작년 8월, Codex Cloud 제품을 출시한 때였습니다. 이는 매우 훌륭한 아이디어였고, 당시 사용자들은 매우 흥분했지만, 아마 조금 이른 감이 있었습니다. 그래서 우리는 8월에 매우 훌륭한 대화형 코딩 모델인 GPT-5를 출시하고, 모델이 현재 처리할 수 있는 문제에 집중하기로 결정했습니다. 이에 따라 Codex CLI와 IDE 플러그인을 출시했고, 몇 달 만에 사용자 수가 20~30배 급증했습니다. 정말 놀라운 일이었습니다.
두 번째 전환점은 작년 12월에서 올해 1월 사이였습니다. 이때 우리는 마침내 초기 비전—작업을 모델에 위임하는 것—을 실현했습니다. 모델의 능력이 새로운 수준에 도달해, 더 복잡한 작업을 독립적으로 완료할 수 있게 되었고, 이는 완전히 새로운 단계로 진입한 것을 의미합니다.
우리의 계획은 단기 및 장기로 나뉘며, 중기 계획은 전혀 하지 않는다
진행자 Peter: Codex 앱은 어떻게 개발된 것인지 정말 궁금합니다. 1년 전에 ‘어느 시점에 Codex 앱을 출시하겠다’는 연간 로드맵을 세웠습니까? 아니면 시장 수요를 관찰하고, 빠르게 프로토타이핑한 것입니까?
Alex:
사실 둘 다 아닙니다. 우리 연구원 Andre로부터 들은 아주 훌륭한 조언이 있습니다. OpenAI에서는 단기 목표나 장기 목표만 계획하지, 중기 계획은 하지 않습니다. 중기 계획은 너무 복잡하기 때문입니다.
단기 계획은 일반적으로 현재로부터 최대 8주까지의 목표를 의미합니다. 8주는 우리가 설정할 수 있는 최장 기간입니다. 이 시간 범위 내에서는 구체적인 목표를 정해 팀 전체가 집중해 그것을 달성합니다. 이는 OpenAI의 강점 중 하나입니다—우리는 명확한 목표 주변에 팀을 조직하는 데 매우 능숙합니다.
반면, 우리는 장기 비전도 수립합니다. 예를 들어, 1년 후의 미래를 상상해볼 수 있습니다. 그때의 모델은 훨씬 더 지능적일 것입니다. 우리는 미래의 모델이 더 이상 우리 컴퓨터 자원을 빌리지 않고, 한 번에 한 가지 작업만 수행하는 데 국한되지 않고, 독립적으로 작동할 수 있을 것이라고 상상할 수 있습니다. 우리는 무한히 많은 모델을 갖고 싶습니다. 이 모델들은 작업을 독립적으로 수행하고, 코드를 스스로 검증하며, 스스로 배포하고 모니터링할 수 있어야 합니다. 우리는 모델에게 수동으로 프롬프트를 줄 필요조차 없어야 합니다.
하지만 중기 계획은 다소 어색합니다. 보통 상세한 제품 로드맵 형태로 나타나지만, 우리는 그런 것을 거의 갖지 않습니다. 대신 장기 비전을 바탕으로, 그 목표 달성으로 이끄는 구체적인 작업에 집중합니다.
Codex 앱을 예로 들면, 당시 우리의 전략적 목표 중 하나는 사용자를 특정 워크스페이스(workspace)에서 해방시키는 것이었습니다. 전통적인 개발 도구(예: VS Code)는 일반적으로 특정 워크스페이스—즉, 특정 코드베이스 체크아웃 포인트나 폴더—에 묶여 있습니다. git worktree를 사용하더라도 한 번에 하나의 워크디렉토리만 열 수 있고, CLI도 유사한 제약이 있습니다.
하지만 우리의 비전은 다음과 같습니다. 사용자가 클라우드 기반의 지능형 에이전트(agent)와 협업할 수 있어야 하며, 이 에이전트는 독립적으로 작동할 수 있어야 합니다. 우리는 사용자가 여러 에이전트와 동시에 상호작용할 수 있도록 하고, 하나의 에이전트가 여러 에이전트를 조율해 사용자에게 서비스를 제공하는 경험을 자연스럽고 직관적으로 만들어야 합니다.
한편, 우리가 처음부터 클라우드에 완전히 의존한다면, 개발자들이 환경 설정이 번거롭거나, 모델이 작업을 수행할 때 수동 개입이나 조정이 필요할 경우 불편함을 느낄 수 있다는 점도 인식했습니다. 따라서 우리는 로컬 파일 폴더와 원활하게 협업하면서도 클라우드 기반의 지능형 에이전트와 연결될 수 있는 로컬 기반의 경험을 개발하기로 결정했습니다.
이 애플리케이션 개발을 시작할 때, 우리는 이런 ‘비전적 사고’를 담은 여러 아이디어를 가지고 있었습니다. 이는 다소 추상적인 개념들이었습니다. 동시에, 우리 엔지니어들은 다양한 프로토타입을 만들기 시작했습니다. 그들은 “우리가 애플리케이션을 가져야 한다”고 말하며, 서로 다른 버전의 애플리케이션을 개발하기 시작했습니다. 실제로 우리는 ‘해커 주간(Hacker Week)’ 행사를 열어, 여러 엔지니어가 독립적으로 다양한 버전의 애플리케이션을 개발했습니다. 아마 당신도 참여하셨을 겁니다. 저는 잘 기억나지 않습니다.
이 프로젝트가 본격적으로 시작되었을 때, 우리가 명확히 적어둔 유일한 내용은 ‘왜 우리가 애플리케이션을 개발하는 것이 좋은 생각인지’였습니다. 이 애플리케이션을 위한 구체적인 제품 사양서는 작성하지 않았고, 실제 개발 작업을 통해 점차 제품의 방향을 명확히 해 나갔습니다.
그러나 당시 이 프로젝트는 여전히 논란의 여지가 있었습니다—우리가 정말로 애플리케이션을 개발해야 할까요? 우리 IDE 플러그인은 이미 매우 인기 있었고, 플러그인의 품질을 향상시키는 데 집중해야 할까요? CLI도 잠재력이 큽니다. 그렇다면 애플리케이션을 개발한다면, 그 의미는 무엇이며, 어디로 나아가야 할까요? 이것이 이 프로젝트 시작 시 우리가 직면한 몇 가지 질문이었습니다.
Romain:
네, 다행히도 당시 우리는 이미 매우 성숙한 IDE 플러그인 솔루션을 보유하고 있었고, 이를 깊이 최적화했습니다. 사용자는 VS Code, Cursor, Windsurf 및 기타 IDE에서 이러한 플러그인을 사용할 수 있습니다. 우리는 IDE 플러그인의 코드베이스에서 많은 경험을 쌓았고, 이것이 Codex 앱 개발에 매우 견고한 출발점을 제공했습니다.
Alex:
맞습니다. 실제로 Codex 앱과 IDE 플러그인은 밑바닥에서 많은 코드를 공유합니다. 둘 다 동일한 핵심 Codex harness에 연결되어 있으며, 이는 Rust로 작성된 오픈소스 프레임워크입니다. CLI 역시 이를 사용합니다. 우리는 계층형 설계를 의도적으로 채택해, 다양한 도구 간 코드 공유 및 기능 확장을 가능하게 했습니다.
진행자 Peter: Codex 앱 개발을 결정한 과정… 지금 돌이켜보면, 터미널 창을 여러 개 열어 사용하는 것보다 훨씬 직관적인 Codex 앱을 사용하는 것이 당연해 보입니다. 그러나 당시 우리가 이 결정을 내린 주된 이유는, Codex 앱이 초보자에게 더 친숙할 뿐 아니라, 여러 지능형 에이전트 간 협업을 관리하기에 최적의 인터페이스라는 점이었습니다.
Alex:
저는 우리 팀의 사고방식이 AGI(범용 인공지능) 비전에 깊이 영향을 받았다고 생각합니다. 우리는 끊임없이 미래의 작업 방식이 어떨 것인지를 고민합니다.
사실, 제가 다른 각도에서 말하자면, 우리는 반드시 필요한 인터페이스가 있다는 것을 분명히 알고 있습니다. 즉, 사용자가 여러 지능형 에이전트에게 작업을 자연스럽게 위임할 수 있는 인터페이스입니다. 우리는 미래의 모델이 이런 능력을 갖추리라는 것을 알고 있습니다—사실 이미 사용자들이 여러 에이전트 간 작업 위임을 시도하고 있는 것을 보았습니다. 우리는 이 협업 방식이 자연스럽게 느껴지고, 클라우드로 원활하게 확장될 수 있는 인터페이스가 필요합니다.
우리는 이 인터페이스가 인체공학적으로 설계되어, 사용자가 여러 지능형 에이전트와 협업하는 것이 복잡한 조작이나 기술을 필요로 하지 않는, 직관적이고 자연스러운 경험을 제공하기를 바랍니다.
Romain:
네, 그리고 이 애플리케이션의 대상은 단순히 초보자에 국한되지 않습니다. 실제로 OpenAI 내부의 최고 수준의 엔지니어—Peter, OpenClaw, Greg Brockman 등—조차 지금은 Codex 앱을 주요 개발 도구로 사용하고 있습니다. 이는 우리의 ‘지능형 에이전트 위임(agentic delegation)’ 비전이 점차 현실이 되고 있음을 보여주는 증거입니다.
Alex:
네. 우리는 Peter를 언급한 이유가, 그가 최근 OpenAI에 합류했기 때문입니다. 우리는 이 사실을 매우 흥분하고 있습니다. 작년 10월, 저는 샌프란시스코 포트 메이슨에서 그와 산책하며 새 인터페이스 개발 아이디어를 제안했습니다. 당시 저는 ‘작업 위임(delegation)을 더욱 자연스럽게 만드는 새 인터페이스’를 원한다고 말했습니다. 그런데 그는 ‘그런 건 절대 쓰지 않을 것’이라고 말했습니다.
하지만 지난 주말, 그는 ‘사실 이 애플리케이션이 꽤 괜찮고, 지금은 마음에 든다’는 트윗을 올렸습니다.
Alex가 Codex 제품 매니저(PM)로서 일상적으로 하는 일은 무엇인가?
진행자 Peter: Alex님은 이전에 Codex 팀에서 유일한 제품 매니저(PM)였다고 하셨죠? 지금 Codex 팀은 몇 명 정도인가요? 대략 50~100명 사이인가요?
Alex:
대략 그 정도입니다. 5월에는 약 8명 정도였고, 정확한 숫자는 기억나지 않습니다. 하지만 그 이후 팀은 매우 빠르게 성장해 지금은 50~100명 정도입니다.
진행자 Peter: 그렇다면 평소에 시간을 어떻게 분배하시나요? 일상적인 업무는 무엇인가요? 아니면 일반적인 하루가 존재하지 않나요?
Alex:
저도 최근 이 질문을 스스로에게 던졌습니다. 왜냐하면 제 스스로도 답하기 어려웠기 때문입니다. 저는 제 일하는 방식이 단계별로 나뉜다는 것을 깨달았습니다. 이는 제 개인적인 방식일 뿐, 모든 사람에게 적용되는 것은 아닙니다.
예를 들어, Codex 앱을 출시할 때는 저는 완전히 실행 모드(execution mode)에 있었습니다. 그때는 제품 품질에 모든 집중력을 기울여, 아무 사소한 세부 사항도 놓치지 않고, 모든 일을 완벽히 처리하는 데 전념했습니다. 이 모드에서는 Codex 도구를 사용하는 데 많은 시간을 보냈습니다.
저희는 Codex를 사용해 피드백을 수집했습니다. 예를 들어, Slack에서의 토론 내용과 사용자 피드백을 Codex에 입력해 요약하게 한 후, 이를 Linear에 기록했습니다. 또한 Codex를 사용해 코드 품질을 분석하고, 직접 작은 코드 수정도 진행했습니다. 왜냐하면 간단한 문제를 Codex로 바로 처리하는 것이, 다른 사람에게 작업을 위임하고 우선순위를 정해 달라고 요청하는 것보다 훨씬 빠르기 때문입니다. 특히 애플리케이션을 2주 안에 출시한다는 목표 아래에서는 더욱 그렇습니다.
물론 이 과정에는 사람을 대하는 일도 많았습니다. 팀을 격려하고, 동기를 부여하며, 동시에 우리가 개발 중인 제품에 대해 비판적인 시각을 유지하는 것도 중요했습니다. 사실 제가 실행 모드에 있는지 아닌지를 판단하는 지표 중 하나는 트위터 사용 빈도입니다. 왜 그런지는 모르겠지만, 사람들과 소통이 필요할 때 저는 트위터를 더 많이 사용합니다.
또 다른 모드도 있습니다. 예를 들어, 지금은 제가 매우 명확하게 인식하고 있습니다. 우리는 새로운 단계에 도달했습니다. 지금은 GPT-5.4와 같은 매우 강력한 모델을 보유하고 있으며, 이 모델의 성능은 탁월합니다. 애플리케이션 경험도 기대를 훨씬 뛰어넘었고, Windows를 포함한 모든 플랫폼을 지원합니다. 따라서 지금은 클라우드로 진정으로 돌아가고, 그곳에 더 많은 노력을 기울일 때라고 생각합니다.
이 단계에 들어서면, 저는 앞으로 무엇을 해야 할지, 현재 상황을 파악하는 데 더 많은 시간을 씁니다. 이것은 조율 모드(coordination mode)입니다. 이 모드에서는 Codex를 사용하는 시간이 줄어들고, 대신 Codex를 통해 소통하는 데 더 집중합니다. 따라서 저는 적어도 두 가지 일하는 방식이 있고, 아마 더 있을 수도 있습니다.
진행자 Peter: 얼마나 많은 다기능 조율(cross-functional alignment) 작업이 필요합니까?
Alex:
팀 내부에서는 거의 다기능 조율 작업이 필요하지 않습니다. 우리는 스스로를 ‘해적선(pirate ship)’처럼 보는 것을 일부러 선택했습니다. 심지어 Codex 팀 내부에서도, 지금은 저와 최근에 합류한 두 명의 새로운 제품 매니저만 있습니다. 책임자들도 있지만, 최근까지는 거의 모두 저에게 직접 보고했고, 우리는 다소 흐릿한 방식으로 함께 프로젝트를 추진해 왔기 때문에, 팀 내 조율 작업은 거의 없었습니다.
하지만 점점 더 명확해지는 것은, Codex를 구축하는 중요한 부분 중 하나가 이 코딩 에이전트(coding agent)를 개발하는 것이라는 점입니다. 그리고 이제 모두가 이 코딩 에이전트가 코드 작성뿐만 아니라 다른 작업에도 매우 유용하다는 것을 점점 더 잘 인식하고 있습니다.
예를 들어, 사용자들이 Codex 앱을 단순히 코드를 작성하기 위해 사용하는 것이 아니라, 전체 소프트웨어 개발 라이프사이클의 다양한 작업을 위해 사용한다는 것을 발견했습니다. 이제 OpenAI의 대부분의 직원—비기술자들도—Codex 앱을 사용하고 있으며, 저는 종종 비기술자들이 이 애플리케이션을 사용하는 모습을 보게 됩니다.
이러한 인식은 우리가 Codex를 단순히 개발자에게만 유용하도록 만드는 것이 아니라, 더 넓은 범위의 사용자에게도 유용하게 만들어야 한다는 점을 깨닫게 해줍니다. 이는 더 많은 다기능 조율이 필요하다는 것을 의미합니다. 왜냐하면 OpenAI는 ChatGPT도 운영하고 있고, 많은 사용자들이 이를 사용하고 있기 때문에, 이러한 제품들을 어떻게 더 잘 결합할 것인가를 매우 신중하게 고민해야 하기 때문입니다.
Romain:
제 관점에서 보면, 우리 개발자 경험(DevX) 팀은 지금 Codex 팀의 연장선처럼 보입니다. 우리의 대부분의 에너지는 Codex에 집중되고 있으며, 그 이유는 여러 가지입니다.
첫째, 이는 매우 흥미로운 제품이며, 개발자들이 Codex를 매우 좋아하고, 우리는 그것을 더욱 훌륭하게 만들고 싶습니다. Alex가 말했듯이, 우리도 몇 가지 단계로 나뉜 작업 방식을 가지고 있습니다. 우리는 Codex 팀과 함께 제품 출시 준비 작업에 투입되며, 출시에 필요한 자료를 준비하고, 개발자가 Codex를 최대한 활용하는 방법을 가르칩니다. 출시 후에는 개발자가 다양한 시나리오에서 Codex를 어떻게 활용할 수 있는지 안내합니다.
또 다른 흥미로운 점은, 전체 OpenAI 플랫폼을 보면, 오늘날 이미 수백만 명의 개발자가 우리의 API를 사용해 이미지, 음성 등 다양한 모달리티의 애플리케이션을 구축하고 있다는 점입니다.
지금 최고의 개발 방식은 Codex를 진입점(entry point)으로 삼는 것입니다. 작년 여름 GPT-5를 처음 출시했을 때로 돌아가면, 우리는 GPT-5에 대한 프롬프트를 작성하는 방법을 설명하는 많은 가이드를 작성해야 했습니다. GPT-5는 추론 능력이 매우 뛰어난 모델로, GPT-4와는 크게 다릅니다. 그러나 지금은 이러한 사용 사례에서도 개발자가 Codex와 skills를 통해 작업을 완료할 수 있도록 하려고 노력하고 있습니다.
예를 들어, 통합 시스템을 업데이트해야 한다면, 우리는 Codex와 그 기술 기능을 사용하라고 권장합니다. 결과적으로 Codex가 거의 모든 작업을 완전히 도와줄 수 있습니다. 따라서 우리 팀은 다기능 협업을 매우 중시하며, Codex를 전체 OpenAI 개발자 플랫폼의 기반이라고 보고 있습니다.
Alex:
저는 Codex 팀의 일하는 방식에 대해 흥미로운 특징이 하나 있다고 생각합니다—제게 가장 멋진 부분은 커뮤니티와의 상호작용입니다. 온라인상에서든 실제 행사장에서든, 우리는 커뮤니티와의 연결을 매우 중요하게 여깁니다.
제품 출시 시, 우리의 작업은 매우 출시 중심적(release-oriented)—어떤 것을 언제 출시할 것인가를 명확히 하는 것—이며, 동시에 매우 피드백 중심적(feedback-oriented)입니다—커뮤니티가 피드백을 주면, 우리는 즉시 행동을 취해 문제를 해결하고 그들과 소통합니다. 따라서 우리 팀은 항상 높은 온라인 상태를 유지하고 있으며, 이는 매우 중요하다고 생각합니다.
예를 들어, Codex 앱을 출시할 때, 우리는 Dom과 그의 팀과 매우 긴밀히 협력했습니다. 그들은 대규모 알파 테스트를 조직해 많은 사용자를 초대하고, 함께 제품을 개발했습니다. 그들의 피드백을 통해 우리는 애플리케이션뿐 아니라 skills와 문서 등 관련 자료도 개선했습니다.
저는 이것이 바로 Codex 팀의 독특한 강점이라고 생각합니다. 왜냐하면 우리는 오픈소스이며, 우리가 하는 모든 일에 대해 높은 투명성을 유지하고, 커뮤니티도 이러한 접근 방식에 엄청난 지지와 피드백을 주고 있기 때문입니다.
진행자 Peter: Peter(OpenClaw 창립자)에 대해 이야기해 봅시다. 저는 OpenClaw의 초기 사용자입니다. 당신들은 Peter를 팀에 어떻게 통합했습니까? 이 개인 에이전트(personal agent) 비전은 그의 현재 업무와 관련이 있습니까? 어떻게 계획하셨습니까?
Alex:
두 가지 측면에서 말씀드릴 수 있습니다. 첫째, Peter는 Codex의 매우 헤비 유저입니다. 사실 OpenClaw는 대부분 Codex를 사용해 구축되었습니다. 그는 자신의 사용 경험을 바탕으로 팀에 많은 피드백을 제공했는데, 이는 Codex 개선에 큰 도움이 되었습니다. 이는 그의 ‘부업’이었지만, 그는 정말 열정적으로 참여했고, 우리는 이를 매우 흥분스럽게 생각합니다.
둘째, 지금은 구체적인 세부 사항을 많이 밝힐 수는 없지만, 그는 차세대 개인 에이전트(personal agent)를 구축하고, 이를 직접 ChatGPT에 통합하는 데 도움을 주고 있습니다.
Romain:
Peter의 업무에서 제가 가장 매료된 점은, 사람들이 OpenClaw를 사용할 때 미래의 가능성을 암시적으로 보고 있다는 점입니다. 하지만 제가 충격을 받은 것은 Peter가 훨씬 이른 시점에서 이 비전을 이미 보았다는 점입니다.
2025년 전체를 되돌아보면, 그는 작년에 40개 이상의 오픈소스 프로젝트를 개발했는데, 이 모든 프로젝트는 하나의 핵심 비전을 중심으로 합니다. 즉, 명령줄 인터페이스(CLI)를 통해 자신의 일정, 트윗, Gmail 등 개인 도구에 접근하는 것입니다. 그는 이러한 프로젝트를 통해 skills와 명령줄 도구의 비전을 현실로 만들었습니다. 우리가 오늘 사용하는 프로그래밍 에이전트(coding agent)는 바로 이 비전을 바탕으로 구축된 것입니다.
앞으로 이 에이전트는 단순한 프로그래밍 도구를 넘어, 어떤 형태의 개인 에이전트(personal agent)가 될 것입니다. 따라서 Peter는 이 과정에서 우리에게 매우 귀중한 피드백을 제공해 주었습니다. 왜냐하면 그는 이미 지금 오픈소스 생태계의 핵심이 되는 많은 도구를 개발했기 때문입니다.
진행자 Peter:
Peter처럼 훌륭한 오픈소스 커뮤니티를 구축할 수 있는 사람들은 정말 존경스럽습니다. 그의 도구는 너무 훌륭해서, 저는 다른 어떤 애플리케이션도 열고 싶지 않을 정도입니다. 저는 그냥 제 작은 로봇과 대화하고 싶습니다.
Alex:
그걸 어떤 시스템에 연결하셨나요? 모든 시스템에 연결하셨나요?
진행자 Peter:
네, 정말 많은 서비스에 연결했습니다. 예를 들어, 제 은행 정보, YouTube 계정, 음성 어시스턴트, 일정, Google 서비스 등에 접근할 수 있습니다. 제가 침대에 누워 있을 때, 제 아내가 “누구랑 대화하고 있니?”라고 물으면, 저는 “제 OpenClaw 로봇과 대화하고 있어”라고 대답합니다.
하지만 지금은 OpenClaw 설정을 도와주는 데 5000달러까지 받는 ‘투기꾼’들이 많습니다. 따라서 여러분이 그것을 더 대중화하고 더 쉽게 사용할 수 있도록 만들면, 그것은 엄청난 돌파구가 될 것이며, 여러분은 분명 올바른 방향으로 나아가고 있습니다.
전통적인 직업 승진 경로는 더 이상 적용되지 않는다
진행자 Peter: 여러분이 ‘지금 대부분의 팀은 더 이상 많은 PM이 필요하지 않다’는 비슷한 말을 했던 것 같았는데요?
Romain:
이 도구들이 저를 가장 놀라게 만드는 점은, 단순히 PM이 필요한가 아닌가 하는 문제를 넘어서는 것입니다. 이것은 거의 모든 전통적인 직업 승진 경로를 흐릿하게 만들고 있습니다. 과거에는 디자이너는 디자인을, 엔지니어는 개발을, PM은 관리를 담당하는 명확한 역할 분담이 있었습니다. 아마 ‘황금 비율’처럼 특정 비율이 존재했을 수도 있습니다.
하지만 지금은, 엔지니어라면 생산성이 크게 향상됩니다. 디자이너라면 이러한 도구를 통해 초능력을 얻고, 더 기술적으로 변할 수 있습니다. PM이라면 과거에는 전략 문서만 작성했지만, 지금은 직접 프로토타이핑할 수 있습니다. 이는 수십억 명의 사용자를 위한 기능을 책임지는 것을 의미하지는 않지만, 분명히 이러한 도구를 사용해 실제로 무언가를 구축하고, 팀에 자신의 비전을 보여줄 수 있습니다.
따라서 제가 가장 매료되는 점은, 이제 모든 직업 경로 사이의 경계가 흐려지고 있다는 점입니다. 우리 각자는 모두 ‘빌더(builder)’이며, 함께 협력해 구축해 나갑니다.
Alex:
저는 어디선가 ‘스타트업에 PM이 있고, 엔지니어가 약 20명 미만이라면, 이는 위험 신호일 수 있다’고 말한 적이 있습니다. 아마 실제로 그런 말을 했을 수도 있습니다.
제가 말씀드린 것처럼, 이제 모든 역할이 점차 융합되고 있습니다. 디자이너는 더 많은 엔지니어링 작업을 수행할 수 있고, 엔지니어는 디자인에 관여할 수 있으며, PM도 구축에 참여할 수 있습니다. 하지만 엔지니어는 일반적으로 코드 작성에 집중해야 하기 때문에, 과거에는 작업 분류나 다른 PM의 프로젝트 관리 업무를 처리하지 않았습니다.
하지만 지금은 이러한 일이 매우 쉬워졌습니다. Codex 같은 에이전트에게 피드백과 우선순위를 분석하도록 지시하면, 엔지니어는 자신의 작업에 더 집중할 수 있습니다. 저는 이제 누구나 다른 사람의 일을 할 수 있다고 생각합니다.
Scott Belsky는 ‘인재 스택 붕괴(collapse the talent stack)’라는 아이디어를 제안했습니다. 저는 이 아이디어를 좋아하며, 이것이 실제로 일어나고 있다고 생각합니다. 방 안에 필요한 사람이 적을수록, 일이 더 원활하게 진행되고, 각 결정도 더 명확해집니다.
그렇다면 이제 PM은 무엇을 할 수 있을까요? 저는 많은 PM들이 다른 역할로 전환을 고려해야 한다고 생각합니다. 예를 들어, PM이지만 엔지니어가 되고 싶은데, 사람 관리에는 능숙하지만 엔지니어링 능력은 부족하다면, 지금은 엔지니어링 매니저(engineering manager)가 될 수 있습니다. 지능형 에이전트 덕분에, 이는 당신에게 더 명확한 역할이 될 수 있습니다. 마찬가지로, 어떤 PM은 디자이너가 되는 것을 선호할 수 있으며, 실제 구축 작업에 더 가까이 다가갈 수 있습니다.
궁극적으로는 개인의 관심사에 달려 있습니다. 저에게는 관심사와 자율성이 AGI 시대에 인간이 지녀야 할 가장 핵심적이고 중요한 자질입니다. 따라서 코드 작성이 더 흥미로운데, 단지 누군가가 PM의 역할을 해야 한다는 이유로 그 자리를 맡았다면, 지금은 엔지니어로 전환해 동일한 일을 엔지니어링 관점에서 계속 수행할 수 있습니다. 디자인 분야도 마찬가지입니다.
하지만 진정으로 사용자와의 상호작용에 관심이 있다면, 이는 실제 구축 작업에서 멀어질 수 있지만, 사용자 요구사항을 이해하거나 시장 동향을 파악하는 등의 활동이 될 수 있습니다. 이 경우, 팀 규모가 충분히 크다면 PM은 여전히 역할을 할 수 있습니다.
Romain:
한 가지 더 보태고 싶은 것은, 모든 문제는 여전히 인간이 담당해야 한다고 생각하지만, 그 사람이 반드시 PM일 필요는 없다고 생각합니다. 이는 제품의 성격에 크게 좌우됩니다.
우리는 Codex를 위해 일한다는 점에서 매우 운이 좋습니다. 이는 개발자를 대상으로 하는 도구입니다. 우리는 스스로가 최고의 사용자입니다. 그리고 오픈소스이기 때문에, 커뮤니티와 직접 소통하고 공동 개발할 수 있습니다.
하지만 10년 전, 제가 Stripe에서 일할 때로 돌아가면, 당시 회사는 250명이었고, PM은 한 명도 없었으며, AI 도구도 전혀 없었습니다. 왜일까요? Stripe는 API 제품이었고, 우리 모두는 엔지니어였으며, 우수한 API가 무엇인지에 대해 매우 직관적인 이해를 갖고 있었습니다. 우리는 우리가 꿈꾸던 API—몇 줄의 코드로 구현할 수 있는 우아한 솔루션—을 구축하고 있었습니다.
하지만 엔지니어가 사용자 요구사항에 대해 직관적인 이해를 갖지 못하는 다른 분야라면, 고객과 소통하고 그들의 요구사항을 이해하기 위해 더 많은 PM이 필요할 수 있습니다. 특히 엔지니어의 직관과 완전히 일치하지 않는 산업이나 분야를 서비스할 때, PM의 역할은 더욱 중요해집니다. 그러나 우리는 Codex 팀에서 매우 운이 좋습니다. 왜냐하면 우리가 구축하고자 하는 것은 바로 우리가 자신도 사용하고 싶은 도구이기 때문입니다.
Alex:
이러한 환경에서, PM의 역할은 단지 ‘사용자에게 가장 관심이 많고, 사용자 요구사항을 가장 걱정하는 사람’을 가리키는 라벨일 뿐입니다. 이 사람은 사용자와 매우 가까운 엔지니어일 수도 있습니다. 따라서 저는 이러한 직업 라벨이 점차 전통적인 의미를 잃어가고 있다고 생각합니다. 약간 혼란스럽긴 하지만, 이는 나쁜 일이 아닙니다.
진행자 Peter:
저도 제 팀에서 비슷한 것을 발견했습니다. 최고의 엔지니어는 ‘다음에 무엇을 구축해야 할까요?’라고 저에게 묻지 않습니다. 그들은 스스로 사용자와 소통해 무엇을 개발해야 할지 알아낸 후, 저와 논의합니다. 이 방식은 모두의 목표를 매우 일치시킵니다.
Romain:
이것이 바로 Codex 팀의 일하는 방식입니다. 오늘 Codex 앱에서 사용되는 많은 기능은 실제로 엔지니어가 하향식(bottom-up)으로 제안한 훌륭한 아이디어들입니다. 왜냐하면 그들 자신도 이러한 기능이 필요했기 때문입니다.
Alex:
한 가지 말씀드리고 싶은 것은, 제가 매우 좋아하는 유형의 엔지니어가 있습니다. 그들은 사용자와 소통하고, 무엇을 구축할지 고민하는 것을 좋아합니다. 이런 사람들은 일반적으로 시스템 구축에도 매우 능숙하며, 빠르고 강력하며, 사고가 명료합니다. 그러나 사용자와의 상호작용에 전혀 관심이 없고, 시스템 구축에만 집중하려는 엔지니어도 있습니다. 저는 이런 사람들도 매우 큰 성장 가능성을 가지고 있다고 생각합니다.
다시 강조하지만, 이것이 제가 AI 시대에 대해 갖는 관점입니다—우리는 모두 더 ‘자신다운’ 존재가 될 수 있습니다. AI와 팀이 당신이 하기 싫은 일을 대신해 주어, 당신은 자신의 관심사와 강점에 집중할 수 있습니다.
진행자 Peter:
저는 분명히 ‘빌더(builder)’라는 라벨이 매우 중요하다고 생각합니다. 많은 PM이 리더가 되고 싶어하지만, 전통적인 직업 승진 경로는 VP 같은 자리에 오르면 오히려 구축할 시간이 없어진다는 점입니다. 매일 제품 검토에만 매달리고, 피드백만 주고, 실제로 개발할 시간은 없습니다. 저는 많은 PM이 이런 상황을 원하지 않으며, 저는 항상 사용자와 가까이 있고, 실제로 제품을 출시하고 싶습니다.
Alex:
저는 완전히 동의합니다. 저는 PM을 리더 역할이라고 보지 않으며, 오히려 ‘빈 공간을 채우는 역할’로 봅니다. 때때로 이 역할은 일정한 리더십 책임을 수반할 수 있지만, 그 리더십은 천재적인 해결책을 한 사람에게 기대하기보다는, 팀이 의견을 모으도록 돕는 데 더 큰 역할을 합니다.
한 가지 확실한 점은, OpenAI에서 가장 훌륭한 PM은 구체적인 세부 사항까지 깊이 파고듭니다. 또한, 고위 리더십 직책으로 OpenAI에 입사하는 것은 매우 도전적인 일입니다. 왜냐하면 여기 문화는 여전히 세부 사항에 대한 집중을 강조하기 때문입니다. 따라서 가장 좋은 방법은 처음부터 바로 세부 사항에 깊이 파고드는 것입니다.
Codex 팀이 채용할 때 중시하는 것은? (정답은 이력서가 아님)
진행자 Peter: Codex 팀을 위해 채용할 때, 후보자가 Codex의 헤비 유저라는 점 외에도, 어떤 자질을 중시하나요?
Alex:
저는 이전에 언급한 바와 같이, 후보자의 ‘자율성(agency)’을 매우 중시합니다. 우리는 스스로 행동하는 사람을 찾고자 하며, 이것이 가장 중요한 자질 중 하나입니다.
OpenAI, 특히 Codex 팀의 문화는 ‘당신이 합류하면, 12개의 점진적으로 어려워지는 과제를 차례대로 주겠다’는 식의 문화가 아닙니다. 우리의 스타일은 더 다음과 같습니다. ‘환영합니다! 이제 탐색을 시작하세요.’
따라서 우리는 자기 주도적인 사람을 선호합니다—그들은 행동력이 있고, 자신만의 아이디어를 갖고 있으며, 무엇을 해야 할지 알고, 기존 아이디어를 도전하는 것을 두려워하지 않습니다. 왜냐하면 솔직히 말해, 기존 아이디어 중 일부는 잘못된 것이거나, 단지 우리가 우연히 내린 결정일 수도 있기 때문입니다.
제가 이상적으로 생각하는 팀원은 자발적으로 추가 책임을 맡고, 심지어 알려지지 않은 분야까지 담당하려는 사람입니다. 이러한 자질은 우리가 특히 중시하는 것입니다. 구체적인 기술 면에서는, 일반적으로 기술력이 뛰어나고 엔지니어링과 관련된 후보자를 우선 고려합니다.
Romain:
저도 완전히 동의합니다. 제 개발자 경험(DevX) 팀에서는 일반적으로 높은 자율성을 갖춘 사람을 찾습니다. 그들은 기술적으로 매우 강해야 하며, 특히 Codex 같은 도구를 능숙하게 사용할 수 있어야 합니다. 그러나 그 외에도, 개발자와 빌더(builder)들과 함께 일하고, 지식을 공유하는 데 열정을 가진 사람을 특히 중시합니다.
예를 들어, 이번 주 우리는 Thomas가 제 팀에 합류한다고 발표했습니다. 그는 오픈소스 Codex monitor를 개발한 사람입니다. 그는 매우 창의적일 뿐만 아니라 Codex의 헤비 유저이며, Codex를 사용해 도구를 구축하는 방법을 공유하는 데 열정적입니다.
우리는 바로 이런 인재가 필요합니다. 왜냐하면 우리는 수백만 명의 개발자를 Codex가 대표하는 밝은 미래로 이끌고자 하기 때문입니다. 저는 지능형 에이전트 프로그래밍(agentic coding)이 소프트웨어 개발, 애플리케이션, 제품 구축에 대한 전통적인 사고방식을 완전히 바꾸고 있다고 믿습니다. 우리의 목표는 이 가능성을 전 세계에 보여주고, 개발자가 이러한 도구를 활용해 자신의 아이디어를 실현하는 법을 배울 수 있도록 돕는 것입니다. 이것이 제가 찾는 자질입니다.
Alex:
보충하자면, 제 관점에서 DevX 팀의 이상적인 후보자는 간단히 ‘매우 훌륭한 엔지니어이면서, 소셜미디어를 통해 커뮤니티와 효과적으로 소통할 줄 아는 사람’으로 설명할 수 있습니다.
Romain:
그 말씀은 일부 맞습니다. 다만 보충하고 싶은 것은, 후보자가 커뮤니티에 대한 강한 책임감을 가져야 하며, 전 세계 다양한 지역의 소셜미디어 사용 습관도 고려해야 한다는 점입니다. 예를 들어, 일부 지역에서는 개발자가 LinkedIn이나 다른 플랫폼을 Twitter보다 더 선호할 수 있습니다. 따라서 우리는 이 정의를 확장해야 합니다. 후보자는 전 세계의 소셜미디어에서 우수한 활동을 해야 합니다. 특히 커뮤니티와 상호작용하고, 교육과 지식 공유에 열정적인 사람을 중시합니다.
진행자 Peter:
사실, 한 사람의 자율성은 면접 전에도 드러납니다. 예를 들어, 그들이 온라인에 작품을 게시했는가? 자신의 사이드 프로젝트(side projects)를 가지고 있는가?
Alex:
누군가 DM을 통해 우리 팀에 합류하고 싶다고 표현할 때, 제가 가장 먼저 확인하는 건 ‘링크가 있는가?’입니다. 링크가 있다면 거의 항상 클릭해 봅니다. 저는 그들의 작품을 확인하고, 그들이 실제로 무언가를 구축하고 있는지 확인합니다.
물론 어떤 이는 자기소개서를 첨부해 이 직책에 관심을 갖는 이유를 설명하거나, 이력서를 첨부하기도 합니다. 하지만 저는 그들의 아이디어와 실제로 구축한 것들을 보는 데 더 큰 관심이 있습니다. 최근에 재미있는 사실을 깨달았는데, 저는 그들이 어느 대학을 졸업했는지 전혀 모릅니다.
진행자 Peter: 누가 신경 쓰겠어요? 누가 신경 쓰겠습니까? 저는 지금 이 어리석은 학력이 더 이상 그렇게 중요하지 않은 시대에 살고 있다는 점이 정말 기쁩니다. 단지 제가 실제로 구축한 것을 보여주기만 하면 충분합니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
深潮TechFlow
