엔터프라이즈 졸업, 그 다음 — Notion·Nextdoor·LSEG가 Codex로 바꾼 것

안녕하세요, Tom입니다.

지난주에 저는 5월의 엔터프라이즈 AI 발표들이 '파일럿'을 졸업했다고 썼어요. Cisco·MUFG·KPMG가 AI를 데모가 아니라 틀리면 책임이 따르는 핵심 업무에 박기 시작했다는 주장이었죠. 그런데 6월 들어 올라온 Codex 사례들을 보면서, 저는 한 칸 더 들어가야겠다고 느꼈어요. 5월 이야기가 "어디에 도입할까"였다면, 6월 이야기는 "도입한 다음, 엔지니어의 시간과 병목이 어디로 옮겨갔나"예요. 한마디로 졸업 다음은 재배치예요. 오늘은 Notion·Nextdoor·LSEG 세 사례로 그 주장을 해보려고 해요.

"도입했다"가 아니라 "무엇이 달라졌다"를 말하는 사례들

세 사례가 흥미로운 건, 화제가 계약 규모나 도입 인원이 아니라는 점이에요. 발표의 무게중심이 "우리가 Codex를 쓴다"에서 "Codex가 들어온 뒤 우리 일이 이렇게 바뀌었다"로 옮겨가 있어요.

가장 선명한 게 Notion이에요. OpenAI의 Notion 사례와 관련 인터뷰에 따르면, Notion에서 AI 제품 엔지니어링을 이끄는 Ryan Nystrom이 'Notion AI Voice Input'이라는 기능을 거의 one-shot으로 만들었다고 해요. 모바일 앱에 이미 있던 기능을 Codex에 가리키니, 그걸 웹·데스크톱 클라이언트로 통째로 옮겨오는 작업을 혼자서 서너 시간 만에 끝냈다는 거예요. 팀을 관리하면서요. 여기서 제가 주목하는 건 "빨랐다"가 아니에요. 원래 여러 엔지니어와 몇 주가 필요했을 기능을, 팀을 이끄는 한 사람이 짬을 내서 혼자 출시했다는 점이에요. 작은 팀의 엔지니어링 역량이 곱셈으로 늘어나는 모습이죠.

Nextdoor는 다른 각도에서 같은 이야기를 해요. OpenAI의 Nextdoor 사례에 따르면, Nextdoor 엔지니어들은 Codex와 GPT-5.5로 재현하기 어려운(hard-to-reproduce) 이슈를 파고들어요. 임베디드 Rust 데이터베이스, 빡빡한 레이스 컨디션처럼 사람이 며칠을 붙잡아도 원인이 안 잡히는 영역이에요. 깨끗한 환경과 조사용 하니스를 에이전트에게 주면, Kubernetes 파드가 왜 안 뜨는지부터 데이터 분석의 추세선까지 끈질기게 파고들어 근본 원인에 도달한다고 해요. Engineering 책임자인 Cory Dolphin은 이걸 "에이전트에게 반복적으로 프롬프트를 던지는 방식에서, 원하는 결과를 정하고 에이전트와 함께 그 결과를 설계하는 outcome engineering으로의 이동"이라고 표현했어요. 그리고 생산성이 너무 올라가서, 이제 병목이 엔지니어링이 아니라 "다음에 무엇을 만들 것인가"라는 전략적 질문으로 넘어갔다고 했고요.

LSEG는 스케일 쪽 증거예요. OpenAI·LSEG의 협업 발표와 LSEG 공식 보도자료에 따르면, 런던증권거래소그룹은 초기 약 4,000명의 직원에게 ChatGPT Enterprise를 제공하고, MCP 커넥터로 자사 금융 데이터를 ChatGPT 안에서 다룰 수 있게 했어요. 보수적인 금융 인프라 기업이 신뢰할 수 있는 AI를 글로벌 사업 전반으로 확장하면서 인사이트를 가속하고 릴리스 주기를 줄이겠다는 방향이에요.

흩어진 사례가 가리키는 한 가지: 시간의 재배치

여기서 제 해석을 더할게요. 세 사례는 산업도, 규모도, 쓰는 방식도 달라요. 그런데 겹쳐 놓으면 같은 문장이 보여요. Codex가 한 일은 코드를 더 빨리 친 게 아니라, 엔지니어의 시간과 병목을 옮긴 거예요.

Notion에서는 "여러 명이 몇 주"가 "한 명이 몇 시간"이 됐어요. 그러면 남은 엔지니어들의 시간은 어디로 갈까요. 더 많은 기능을 찍어내는 데가 아니라, 무엇을 만들지 고르는 데로 가요. Nextdoor가 그걸 대놓고 말했어요. 병목이 엔지니어링에서 전략으로 옮겨갔다고요. 사람이 며칠씩 매달리던 재현 어려운 버그를 에이전트가 끈질기게 추적하니, 엔지니어는 디버깅이 아니라 "이 제품을 어디로 끌고 갈까"에 시간을 쓰게 돼요. LSEG의 릴리스 주기 단축도 결국 같은 말이에요. 빨라진 주기만큼 확보된 시간이 어디로 가느냐가 핵심이지, 빨라졌다는 사실 자체가 핵심이 아니에요.

5월 칼럼에서 저는 "AI가 틀리면 회사가 손해 보는 자리에 들어갔는가"를 졸업의 기준으로 봤어요. 6월 사례들은 그 자리에 들어간 다음의 질문을 던져요. 들어갔으면, 사람은 이제 무엇을 하는가. Notion의 답은 "기획·판단", Nextdoor의 답은 "전략", LSEG의 답은 "데이터를 사업 의사결정에 더 빨리 연결". 자리는 다 다른데, 사람의 무게중심이 실행에서 판단으로 옮겨간다는 방향은 똑같아요. 이건 제가 Virgin Atlantic이 고정 마감일에 맞춰 Codex로 앱을 재출시한 사례를 다룰 때 봤던 것과도 이어져요. 그때도 핵심은 "코드를 빨리 짰다"가 아니라 "테스트 커버리지와 품질 책임을 에이전트에 맡기고 사람은 출시 판단에 집중했다"였거든요.

반론: 이것도 결국 벤더가 고른 성공 사례예요

솔직하게 한계를 짚을게요. 세 사례 모두 OpenAI가 공개한 자료예요. 잘 안 된 부분이 들어 있을 리 없어요. Notion의 "서너 시간 one-shot"은 인상적이지만, 그게 어느 정도 복잡도의 기능이었고, 코드 리뷰와 QA에 얼마나 시간이 더 들었는지는 공개되지 않았어요. "한 사람이 혼자 만들었다"는 서사는 강력하지만, 그 한 사람이 Notion의 AI 제품 엔지니어링 리드라는 점도 같이 봐야 공정해요. 평균적인 엔지니어의 평균적인 기능에서 같은 결과가 나온다는 보장은 없어요.

Nextdoor의 "병목이 전략으로 넘어갔다"도 멋진 문장이지만, 재현 어려운 버그를 에이전트에 맡기는 건 잘 풀렸을 때의 이야기예요. 에이전트가 엉뚱한 가설을 길게 파고들거나 잘못된 수정을 자신 있게 내놓을 때의 시간 낭비, 즉 안 풀렸을 때의 비용은 이런 성공 사례에 결코 안 적혀요. LSEG의 4,000명도 5월 칼럼에서 짚었듯 접근 권한이 부여된 인원이지 매일 쓰는 인원이 아니에요. "릴리스 주기 단축"이라는 표현도 구체적으로 무엇이 며칠에서 며칠로 줄었는지는 공개된 수치가 보이지 않아서, 정성적 방향으로만 받아들이는 게 안전해요. 그래서 저는 이 글의 "재배치" 주장도 "이미 완료됐다"가 아니라 "그 방향으로 무게가 실리기 시작했다"로 읽는 게 정확하다고 봐요.

한국 개발자 입장에서

한국 개발자 입장에서 이 흐름을 어떻게 받아들여야 할까요. 저는 "one-shot으로 기능을 찍어내는 능력"을 부러워할 게 아니라, 그 능력이 만든 빈 시간을 누가 가져가느냐를 봐야 한다고 생각해요. Notion·Nextdoor의 공통 메시지는 결국 "엔지니어가 실행에서 판단으로 이동한다"는 거예요. 그런데 한국 조직 다수는 아직 엔지니어를 "티켓을 빨리 쳐내는 사람"으로 평가하는 경우가 많아요. 만약 평가 기준이 그대로인 채로 도구만 들어오면, 절약된 시간은 판단이 아니라 더 많은 티켓으로 채워질 거예요. 그러면 졸업도 재배치도 아니고, 그냥 같은 일을 더 빨리 하는 데서 끝나요. 반대로 "무엇을 만들지 정하고, 에이전트 출력을 검증하고 책임지는" 능력을 키워두는 사람은, 이 변화가 본격화될 때 가장 비싼 자리를 차지하게 될 거예요. 이건 영어권만의 변화가 아니에요.

구체적 takeaway

총평 대신 행동 가능한 걸로 마무리할게요.

첫째, "얼마나 빨라졌나"가 아니라 "빈 시간이 어디로 갔나"로 회고하세요.

Codex나 다른 에이전트를 한 달 써봤다면, "PR 수가 늘었다"가 아니라 "그 시간이 기획·설계·검증 중 어디로 갔는가"를 적어보세요. 만약 답이 "더 많은 PR"뿐이라면, 도구는 들어왔는데 재배치는 아직 안 일어난 거예요.

둘째, '재현 어려운 버그'를 에이전트의 첫 임무로 골라보세요. Nextdoor가 Codex를 붙인 자리는 새 기능이 아니라 사람이 며칠 매달려도 안 잡히던 레이스 컨디션·임베디드 DB 이슈였어요. 깨끗한 재현 환경과 조사용 하니스를 먼저 만들어 주는 게 핵심이에요. 신기능 생성보다 이쪽이 투자 대비 효과를 체감하기 쉬워요.

셋째, one-shot 결과물에는 검증 단계를 명시적으로 끼우세요. Notion 사례에서 빠진 건 리뷰·QA 시간이에요. 혼자 서너 시간에 만든 기능일수록 "누가, 어떤 기준으로 검토하는가"를 워크플로우에 박아두지 않으면, 절약한 시간을 나중에 버그로 토해내게 돼요. 속도는 검증 루프와 한 묶음일 때만 진짜 생산성이 돼요.

근거가 된 소식: What Codex unlocks for Notion, How engineers at Nextdoor use Codex to build without limits, LSEG and OpenAI, LSEG announces new collaboration with OpenAI