요즘 소프트웨어 개발의 판이 바뀌고 있다는 건 다들 공감하실 겁니다. GitHub 역사상 가장 빠른 속도로 스타를 모은 프로젝트 중 하나인 'OpenClaw(구 Clawd/Moltbot)'의 창시자 피터 스타인버거(Peter Steinberger)는 최근 이런 선언을 했습니다.

"나는 내가 짠 코드를 읽지 않고 배포한다(I ship code I don't read)."

그냥 AI 예찬론자의 허세가 아닙니다. 그는 전 세계 10억 개 이상의 기기에서 사용되는 PDF 프레임워크 PSPDFKit을 창업하고 70명 규모의 팀을 이끌었던 정통 엔지니어 출신입니다. 극심한 번아웃으로 3년간 개발에서 손을 뗐다가, AI 코딩 도구의 폭발적인 발전에 이끌려 복귀한 인물이죠. 돌아온 그는 혼자서 수십 명분의 결과물을 내며, 개발 커뮤니티에 적지 않은 충격을 던지고 있습니다.

이번 글은 팟캐스트 'The Pragmatic Engineer'에서 진행자 게르겔리 오로스(Gergely Orosz)가 피터와 나눈 심층 대화를 중심으로, 피터의 AI 네이티브 워크플로우를 분석해 봤습니다.

미리 요점만 콕 집어보면?

피터 스타인버거는 "나는 내가 짠 코드를 읽지 않고 배포한다"며, 2026년 1월 한 달 동안 혼자서 6,600개 이상의 커밋을 기록했습니다.
그는 AI 에이전트가 스스로 컴파일·린트·테스트를 수행하는 "루프 닫기(Close the Loop)"와 "게이트(Gate)" 시스템을 통해 검증을 자동화합니다.
전통적인 PR 대신 프롬프트를 공유하고, 코드 리뷰 대신 아키텍처 토론에 집중하며 AI 군단을 설계하고 지휘하는 아키텍트로의 전환을 강조합니다.

한 달에 6,600커밋, 1인 기업의 착시

피터는 2026년 1월 한 달 동안 혼자서 6,600개 이상의 커밋을 기록했습니다. 대규모 개발팀 전체의 생산량과 맞먹는 수치입니다. 그는 이를 두고 이렇게 말합니다.

"커밋 내역만 보면 회사가 운영되는 것처럼 보이겠지만, 사실 집에서 혼자 즐기고 있는 것이다."

이 생산성의 비결은 AI 도구 자체가 아닙니다. 과거 70명 팀을 운영하면서 얻은 한 가지 깨달음이 핵심입니다. 바로 "모든 코드가 내 마음에 들 수는 없다"는 것이죠. 과거 PSPDFKit을 만들 때의 피터는 PDF 페이지 넘김 애니메이션의 미세한 느낌까지 집착하는 완벽주의자였습니다. 하지만 팀이 커지면서 자신이 모든 코드를 제어할 수 없다는 현실을 받아들여야 했고, 이 경험이 AI 시대에 가장 중요한 자산이 되었습니다. 코드의 '구현 디테일'보다 '결과물'과 '아키텍처'에 집중하는 사고 전환이 먼저 일어난 셈이죠.

OpenClaw 검색량 — 지난 달 글 검색에서 'Clawd'에 대한 검색량이 'Claude Code'와 'Codex'를 합친 것보다 많았습니다. <출처: 구글 트렌드>

핵심 원칙: "루프 닫기(Close the Loop)"

AI가 생성한 코드를 읽지 않고 배포한다니, 무책임한 이야기 아닐까요? 여기엔 명확한 시스템이 있습니다. 피터가 말하는 "루프 닫기(Close the Loop)" 메커니즘입니다.

검증의 고리를 기계에게 맡기다

많은 개발자가 AI가 작성한 코드를 신뢰하지 못해 한 줄 한 줄 눈으로 검토합니다. 피터의 접근은 다릅니다. AI 에이전트가 코드를 작성하는 것에서 멈추지 않고, 스스로 컴파일하고, 린트(lint)를 돌리고, 테스트를 수행하도록 시스템을 설계합니다. 에이전트가 오류를 발견하면 스스로 디버깅하고 수정합니다. 이 자동화된 검증의 고리가 닫혀 있기 때문에, 인간이 코드를 라인 단위로 읽을 필요가 사라지는 것입니다.

"게이트(Gate)" 시스템

피터는 이 검증 과정을 "게이트(Gate)"라고 부릅니다. 에이전트에게 "풀 게이트(Full Gate)를 실행해"라고 명령하면, 린트·빌드·테스트 등 모든 검증 절차를 통과해야 하는 구조입니다. 게이트를 통과한 코드는 사람이 눈으로 확인한 것보다 오히려 신뢰할 수 있다는 것이 그의 판단입니다.

여기서 중요한 포인트가 있습니다. 피터는 원격 CI를 기다리지 않고, 에이전트가 로컬에서 직접 테스트를 실행하게 합니다. 원격 CI 파이프라인에 올리면 10분 이상 기다려야 하는데, 에이전트가 로컬에서 바로 돌리면 즉각적인 피드백이 가능하기 때문입니다. 이 속도 차이가 에이전트 주도 개발에서는 결정적이죠.

5~10개 에이전트를 동시에 지휘하는 법

스타크래프트 프로게이머처럼

피터의 작업 방식은 10개의 체스판을 동시에 두는 그랜드마스터, 혹은 실시간 전략 게임(RTS)의 프로게이머에 가깝습니다. 하나의 작업이 끝나기를 기다리지 않습니다. 서로 다른 기능을 수행하는 5~10개의 에이전트를 동시에 가동하죠.

자신이 직접 설계한 아키텍처 위에서, 에이전트 A는 새로운 기능을 구현하고, 에이전트 B는 버그를 수정하고, 에이전트 C는 문서화를 진행합니다. 피터는 각 에이전트의 진행 상황을 모니터링하다가, 막히는 부분이 생기면 개입하여 방향을 틀어주고 다시 작업을 넘깁니다. 이 과정은 엄청난 정신적 에너지를 요구합니다. 하지만 피터는 이것이 오히려 깊은 몰입(Flow) 상태를 만들어내고, 결과적으로 폭발적인 생산성으로 이어진다고 말합니다.

기획에 가장 많은 시간을 쓰기

흥미롭게도 피터가 가장 많은 시간을 들이는 단계는 코딩이 아니라 기획입니다. 에이전트에게 작업을 넘기기 전, AI와 오랜 시간 대화하며 기획을 다듬습니다. AI가 제안하는 방향에 반론을 제기하고, 수정하고, 확인하는 과정을 반복합니다. 기획이 단단해졌다고 판단하면, 그때서야 에이전트에게 실행을 맡기고 자신은 다음 작업의 계획 수립으로 넘어갑니다.

도구 선택: 왜 Codex를 선호하는가

여기서 피터의 도구 선택이 눈길을 끕니다. 그는 코딩 작업에서 Anthropic의 Claude Code보다 OpenAI의 Codex를 선호합니다. 이유는 작업 스타일의 차이에 있습니다. Codex는 한 번 지시하면 10~20분 동안 묵묵히 파일을 읽고 코드를 작성합니다. 반면, Claude Code는 중간중간 되물으며 대화를 시도하는 경향이 있습니다. 피터처럼 이미 기획을 완료한 상태에서는, 질문보다 실행을 원하기 때문에 Codex의 묵묵한 수행 방식이 더 맞는 것이죠.

물론 이것은 도구의 우열이 아니라, 워크플로우와의 궁합입니다. 기획이 충분히 수립된 뒤 긴 작업을 맡기는 패턴에는 Codex가, 탐색적인 대화를 통해 방향을 잡아가는 패턴에는 Claude Code가 더 적합할 수 있습니다.

MCP 대신 CLI를 선택한 이유

최근 AI 개발자 커뮤니티에서 MCP(Model Context Protocol)가 큰 화제인데요. 피터는 이에 대해 회의적인 입장을 취합니다. 그의 논리는 이렇습니다. MCP는 모든 도구의 정의를 컨텍스트에 로딩해야 하므로 토큰 낭비가 심하고, 결과를 필터링하기 어렵습니다. 대신 피터는 CLI(Command Line Interface) 도구를 직접 만들어 에이전트에게 제공합니다.

AI 에이전트는 리눅스 터미널을 다루는 데 이미 능숙합니다. grep, jq 같은 명령어를 조합해 필요한 데이터만 정확하게 추출하고, 파이프라인으로 연결할 수 있죠. 피터는 구글 검색, 집안 조명 제어, 음악 재생까지 모두 CLI로 만들어 에이전트가 통제하게 했습니다. MCP가 과도기적 기술인가에 대해서는 의견이 분분하겠지만, 적어도 피터의 워크플로우에서는 CLI가 더 효율적인 선택이었다는 점은 참고할 만합니다.

PR은 죽었다, "프롬프트 요청"이 왔다

피터의 워크플로우에서 가장 급진적인 변화는 바로 협업 방식에 있습니다.

코드가 아닌 프롬프트를 공유하라

전통적인 PR(Pull Request) 대신, 피터는 기여자들에게 "어떤 프롬프트로 이 코드를 생성했는지"를 공유해 달라고 요청합니다. 생성된 코드보다, 그 코드를 만들어낸 의도와 명령어가 더 높은 시그널(High Signal)을 담고 있다는 판단입니다.

실제로 피터는 PR에 올라온 코드를 보지 않는 경우도 많습니다. 대신 해당 이슈를 해결하기 위한 프롬프트를 자신의 에이전트에게 입력하여, 처음부터 다시 코드를 생성하게 합니다. 흥미롭게도, 이 방식은 'The Pragmatic Engineer'의 진행자 게르겔리 오로스의 동생이 운영하는 Craft에서도 비슷하게 적용하고 있다고 합니다. Craft 팀은 외부 PR을 대부분 거절하되, 핵심 아이디어만 가져와 나중에 프롬프트로 활용한다고 하죠.

코드 리뷰 대신 아키텍처 토론

라인 단위의 코드 리뷰는 이 워크플로우에서 사라졌습니다. 피터는 디스코드에서 핵심 팀원들과 대화할 때도 코드에 대한 이야기는 거의 하지 않는다고 합니다. 대신 시스템의 전체 구조, 확장성, 모듈화 전략 등 아키텍처에 대한 심도 있는 토론에 시간을 쏟습니다. 구현은 AI가 하지만, 그 방향을 결정하는 설계자로서의 역할은 훨씬 중요해진 셈입니다.

"직조(Weaving)"하는 코딩

피터는 새로운 기능을 기존 코드베이스에 통합하는 과정을 "직조(Weaving)"라고 표현합니다. 에이전트에게 "이 기능을 기존 CLI 프로젝트에 짜 넣어서(weave in) 플러그인 아키텍처로 만들어줘"라고 지시하면, 에이전트가 기존 구조를 분석해 매끄럽게 통합합니다. 때로는 일부러 모호한 프롬프트를 던져서, 자신이 생각하지 못한 방향의 해결책을 AI가 찾아내도록 유도하기도 합니다.

AI 시대에 살아남는 엔지니어의 조건은?

이처럼 피터의 워크플로우는 미래 개발자상에 대한 중요한 시사점을 던집니다.

알고리즘 퍼즐보다 '제품 출시'를 즐기는 사람이 유리하다

피터의 관찰에 따르면, 알고리즘 퍼즐 푸는 것을 즐기는 엔지니어일수록 AI 네이티브 워크플로우에 적응하기 어려워합니다. 반대로, 제품을 만들어내고(Shipping) 사용자에게 가치를 전달하는 것을 즐기는 엔지니어가 훨씬 유리합니다. 대부분의 애플리케이션 코드는 결국 "데이터를 다양한 형태로 가공하는 것"에 불과하고, 이런 작업은 AI가 더 잘하기 때문입니다.

소프트웨어 엔지니어링은 죽지 않았다

'The Pragmatic Engineer'의 진행자 게르겔리 오로스도 강조하는 바이지만, 피터의 사례는 오히려 소프트웨어 엔지니어링의 중요성을 보여줍니다. 피터는 프로젝트 전체의 고수준 구조를 머릿속에 유지하면서, 기술 부채를 관리하고 확장성과 모듈화를 고민하는 '소프트웨어 아키텍트' 역할을 수행합니다. OpenClaw가 빠르게 성장할 수 있었던 이유 중 하나도, 피터가 프로젝트의 확장성을 처음부터 신경 쓰며 '자비로운 독재자(Benevolent Dictator)'로서 일관된 방향성을 유지했기 때문입니다.

미래 기업은 30%의 인원으로 운영된다

피터는 미래의 기업이 현재 인원의 30%만으로 운영될 수 있다고 예측합니다. 다만 그 30%는 단순한 코더가 아니라, 높은 수준의 주체성(High Agency), 제품 비전, 기술적 이해도를 모두 갖춘 소수 정예가 될 것이라고 말합니다.

OpenClaw 피터 스타인버거 — <출처: https://openclaw.ai/>

마치며: 돌덩이에서 조각상을 깎아내는 과정

OpenClaw(구 Clawdbot)는 단순한 생산성 도구를 넘어선 프로젝트입니다. 최근에는 Google 검색량에서 Claude Code나 Codex를 넘어설 만큼 주목받고 있고, GitHub 스타 증가 속도에서도 전례 없는 기록을 세우고 있습니다. 피터는 모로코 여행 중 인상적인 경험을 했습니다. 에이전트에게 사진을 전송했더니, 에이전트가 스스로 파일 헤더를 분석하고, FFmpeg와 OpenAI Whisper API를 찾아내 음성을 텍스트로 변환해 답변하는 '창발적 능력'을 보여준 것입니다.

피터는 현재의 개발 과정을 "돌덩이에서 조각상을 깎아내는 것"에 비유합니다. 처음에는 투박하지만, 에이전트와 끊임없이 대화하고 다듬어가며 원하는 형상을 만들어내는 과정이라는 것이죠.

"개발은 이제 일종의 게임이 되었습니다. 더 잘하고 싶어서 끊임없이 플레이하게 되는, 중독성 있는 게임 말이죠."

물론 피터의 사례가 모든 개발자에게 그대로 적용될 수는 없을 겁니다. 실험적인 프로젝트에서 빠르게 전진하는 전략과, 안정성이 최우선인 프로덕션 환경에서의 전략은 다를 수밖에 없으니까요. 하지만 AI 에이전트가 개발 워크플로우의 중심으로 들어오고 있다는 흐름은 분명합니다.

이제 코드를 한 줄 한 줄 직접 짜는 장인으로 남을 것인지, AI 군단을 설계하고 지휘하는 아키텍트로 전환할 것인지, 그 선택의 시간은 계속 다가오고 있습니다.

<출처>

The Pragmatic Engineer - Gergely Orosz, The creator of Clawd: "I ship code I don't read"
The Pragmatic Engineer - Youtube, The creator of Clawd: "I ship code I don't read"