MoltBot 제작자: “나는 읽지 않은 코드를 배포한다”
(newsletter.pragmaticengineer.com)- AI 에이전트를 활용해 혼자서 1월에만 6,600건 이상의 커밋을 기록한 Peter Steinberger의 워크플로우를 다룬 인터뷰 기사
- Moltbot(구 Clawdbot)은 현재 GitHub 역대 가장 빠른 스타 성장을 기록 중이며, Google 검색량에서 Claude Code와 Codex를 넘어섬
- Peter는 5~10개의 에이전트를 동시에 운영하며, 코드 리뷰 대신 아키텍처 논의에 집중하는 방식으로 개발
- AI와 효과적으로 협업하려면 에이전트가 스스로 컴파일, 린트, 테스트를 수행해 검증할 수 있는 루프 설계가 필수
- 세부 구현보다 결과와 시스템 설계 중심적 사고를 가진 엔지니어가 AI 네이티브 개발에 더 잘 적응함
Peter Steinberger 는 누구인가
- PSPDFKit을 글로벌 개발자 도구 비즈니스로 성장시킨 창업자
- 3년간의 휴식 후 복귀했으며, 이번에는 LLM과 AI 에이전트를 워크플로우의 중심에 배치
- 70명 이상의 개발팀을 운영한 경험이 완벽주의를 내려놓는 법을 가르쳤고, 이 능력이 현재 AI 에이전트 작업에서 효율성을 높여줌
- 2026년 1월 한 달에 6,600회 이상의 커밋을 기록하며 개인 개발자로서 이례적인 생산성을 보임
- 모든 작업이 회사가 아닌 개인 프로젝트에서 이뤄졌으며, 개발 자체를 즐기고 있음
Moltbot과 폭발적 성장
- GitHub에서 역대 가장 빠른 스타 성장률을 기록했으며, Tailwind CSS와 비교해도 성장 곡선이 전례 없는 수준
- 지난 주 Google 검색량에서 Claude Code와 Codex를 합친 것보다 많은 검색량 기록
- Peter의 표현: "커밋만 보면 회사처럼 보이겠지만, 사실은 집에서 재미로 코딩하는 한 사람"
AI 에이전트 기반 워크플로우의 10가지 핵심 교훈
- 완벽주의를 버리기: 코드가 항상 자신의 취향에 맞지 않을 수도 있다는 사실을 받아들이면, 에이전트를 다룰 때 더욱 효율적으로 일할 수 있음
- 루프를 닫을 것: AI 에이전트가 스스로 컴파일, 린트, 실행, 검증할 수 있도록 시스템 설계 필요
- Pull Request는 죽었고, "Prompt Request"가 부상: 코드 자체보다 코드를 생성한 프롬프트를 보는 것이 더 중요
- 코드 리뷰는 사라지고 아키텍처 논의가 대체: Discord에서도 핵심 팀과 코드가 아닌 아키텍처와 큰 결정만 논의
-
5~10개 에이전트를 동시에 운영하며 "몰입(flow) 상태" 유지
- 각 에이전트가 서로 다른 기능을 병렬로 작업
-
계획 수립에 상당한 시간 투자, Codex 선호
- 에이전트와 반복적으로 대화하며 견고한 계획 수립
- 계획에 도전하고, 수정하고, 반박한 후 만족하면 실행하고 다음으로 이동
- Codex는 장시간 작업을 독립적으로 수행하지만, Claude Code는 명확화를 위해 자주 돌아와서 산만해짐
- 의도적으로 덜 구체적인 프롬프트를 사용해 예상치 못한 솔루션을 발견하기도 함
- 로컬 CI가 원격 CI보다 우수: 원격 CI의 10분 대기 시간 대신 에이전트가 로컬에서 테스트 실행
- 대부분의 코드는 지루한 데이터 변환: 집착할 필요 없고, 에너지는 시스템 설계에 집중해야 함
-
구현 세부사항보다 결과물에 관심을 가진 엔지니어가 AI와 잘 협업
- 알고리듬 퍼즐 풀기를 좋아하는 엔지니어는 "AI 네이티브" 전환에 어려움을 겪음
- 제품 출시를 좋아하는 사람이 더 잘 적응
소프트웨어 엔지니어링의 미래에 대한 견해
- AI로 소프트웨어 엔지니어링이 죽은 것이 아니라 오히려 그 반대
- Peter는 프로젝트의 고수준 구조를 머릿속에 유지하는 소프트웨어 아키텍트
- 아키텍처, 기술 부채, 확장성, 모듈성에 깊이 신경 씀
- Moltbot 성공 이유 중 하나는 확장성이 뛰어남
- 새로운 기능 추가가 쉽도록 에너지를 투자
- 프로젝트의 "선량한 독재자"로서 방향과 스타일 일관성 유지
맥락과 한계
- Moltbot은 실험적이고 빠른 반복을 전제로 한 프로젝트이며, 아직 작업 진행 중
- "빠르게 움직이고 부수기"가 이런 프로젝트의 유일한 성공 방법
- 모든 팀이나 제품에 동일하게 적용하기는 어려움
- 그럼에도 대형 AI 연구소조차 예상하지 못한 수요를 발견한 사례로 평가
계산기는 결정론적 알고리즘을 기반으로 동작하기 때문에, 해당 비유는 적절하지 않다고 생각합니다.
그리고 저는 AI를 사용하는 것에 반대하는 것이 아니라, 이 글에서 소개하는 AI를 사용하는 방식에 문제가 있다고 봅니다.
우리가 생각하는 구조로 만들었기 때문입니다.
뇌세포끼리 연결되는 방식을 그대로 가져온 것이 기본이고, 어떤 과정으로 생각을 하는지 명확히 볼 수가 없습니다.
"생각"도 뇌에서 어떤 과정을 통해 나오는 지 모르기에 기본생김새와 현상이 동일합니다.
그래서 인간의 뇌는 예측기계와 동일하다고 보는 겁니다.
우리가 생각한다고 하는 것이 기계적인 현상이라고 보고 브레인해킹도 가능하다고 보는 분야도 있더라구요.
완전히 동일한 것은 아니고 동시에 완전히 다른 것도 아닙니다.
비슷하다는 것은 공통적인 부분이 있다는 뜻이니
결국 사람들끼리 이견이 있다는 것은 얼마나 비슷한지 보는 관점에 따른 것일 거에요
동일하다고는 볼 수 없지만 비슷하다고 보고
geek12356님의 댓글인 예측과 생각에 대한 관점에서 그렇다고 생각합니다.
저는 동시에 지능이 인간보다 높아서 인간과 다르다는 관점도 가지고 있습니다.
그렇게 싸지른 코드가 문제라도 생긴다면 그걸 대체 누가 뒤치닥거리 할것인가... 이런식으로 코드가 만들어지다간.. 언제가 그런 지옥이 반드시 올것이다.
Pull Request 대신 "Prompt Request" 라니 놀랍네요.
아주 예전에 MDA 에 관심많았다가 비현실적이라 포기했었는데, 이게 이렇게 실현되는군요.
"빠르게 움직이고 부수기"
- 구현 세부사항보다 결과물에 관심을 가진 엔지니어가 AI와 잘 협업
- 알고리듬 퍼즐 풀기를 좋아하는 엔지니어는 "AI 네이티브" 전환에 어려움을 겪음
- 제품 출시를 좋아하는 사람이 더 잘 적응
문장이 공감되네요
몰트봇들이 자가 수리 PR을 얼마어마하게 올려제끼는데 그걸 다 본인이 검수할 수가 없을 듯 합니다 ㅋㅋ 이슈랑 PR수가 비슷한게 이슈 쓰고 기다릴 시간에 몰트봇한테 PR만들어서 푸시해줘 하면 끝나는 문제라 ㅋㅋ