왜 다들 AI 에이전트를 쓰는데 생산성이 안 오르는 걸까요?
Claude Code 쓰고, Cursor 쓰고, GitHub Copilot도 써봤는데… 뭔가 제대로 안 되는 느낌이에요.
“AI가 코드를 짜주는데 왜 이렇게 느릴까?” “에이전트가 자꾸 엉뚱한 방향으로 가는데?” “코드 리뷰하는 시간이 오히려 더 늘었어요.”
이런 고민, 다들 하시죠?
저도 마찬가지였어요. AI 코딩 도구를 쓰기 시작한 지 3개월쯤 됐는데, 처음엔 “와 이거 진짜 신기하다” 했지만, 시간이 지나니까 뭔가 아쉬운 게 많더라고요.
그런데 최근에 MoltBot 제작자 Peter Steinberger의 인터뷰를 읽었어요. 이 사람, 2026년 1월 한 달에만 6,600건 이상의 커밋을 기록했다고 하더라고요.
한 사람이요. 한 달에요.
“이게 실화냐?” 싶었는데, 읽어보니까 답이 나왔어요.
AI 에이전트의 워크플로우가 가장 중요하다.
코드가 아니라, 도구도 아니라, 워크플로우가 핵심이었던 거예요.
MoltBot 제작자는 누구인가?
Peter Steinberger는 PSPDFKit이라는 글로벌 개발자 도구 비즈니스를 성장시킨 창업자예요. 70명 이상의 개발팀을 운영한 경험이 있고, 3년간의 휴식 후 복귀했는데 이번엔 LLM과 AI 에이전트를 워크플로우의 중심에 배치했어요.
그 결과가 MoltBot이에요.
MoltBot은 GitHub에서 역대 가장 빠른 스타 성장률을 기록했고, 지난 주 Google 검색량에서 Claude Code와 Codex를 합친 것보다 많은 검색량을 기록했다고 해요.
Peter의 표현이 인상적이었어요:
“커밋만 보면 회사처럼 보이겠지만, 사실은 집에서 재미로 코딩하는 한 사람”
한 사람이 6,600건의 커밋을 기록했다는 건, 단순히 AI 도구를 잘 쓰는 게 아니라 워크플로우를 완전히 재설계했다는 의미예요.
AI 에이전트 워크플로우의 10가지 핵심 교훈
Peter의 인터뷰에서 나온 교훈들을 정리해봤어요. 이게 바로 AI 시대 개발자가 알아야 할 워크플로우 설계 원칙이에요.
1. 완벽주의를 버리기
“코드가 항상 자신의 취향에 맞지 않을 수도 있다는 사실을 받아들이면, 에이전트를 다룰 때 더욱 효율적으로 일할 수 있다.”
이거 진짜 공감돼요.
처음에 AI가 코드를 짜주면, “아 이 스타일이 아니야”, “이 네이밍이 마음에 안 들어” 하면서 계속 수정했어요. 그런데 이게 시간을 엄청 잡아먹더라고요.
Peter는 이걸 명확히 말했어요. 완벽주의를 버려야 한다는 거예요.
AI가 짠 코드가 내 취향과 다르더라도, 동작만 하면 OK라는 마인드셋이 필요해요. 특히 지루한 데이터 변환 같은 반복 작업은 더욱 그렇고요.
2. 루프를 닫을 것 (가장 중요!)
“AI 에이전트가 스스로 컴파일, 린트, 실행, 검증할 수 있도록 시스템 설계 필요”
이게 제일 중요한 포인트예요.
많은 개발자들이 AI에게 “이 기능 만들어줘” 하고 코드만 받아요. 그런데 그 코드가 실제로 동작하는지, 린트 에러는 없는지, 테스트는 통과하는지… 이걸 사람이 직접 확인하잖아요?
Peter는 이걸 에이전트가 스스로 하도록 설계했어요.
에이전트가 코드를 작성하면 → 자동으로 컴파일 → 린트 체크 → 테스트 실행 → 에러 나면 수정 → 다시 검증… 이 루프를 에이전트가 스스로 돌리도록 만든 거예요.
이게 바로 “루프를 닫는다”는 의미예요.
왜 이게 중요할까요?
에이전트가 스스로 검증하지 못하면, 사람이 중간에 끼어들어야 해요. 그러면 몰입(flow) 상태가 깨지고, 생산성이 떨어져요.
반대로 에이전트가 자동으로 검증하면, 사람은 아키텍처와 큰 결정에만 집중할 수 있어요.
3. Pull Request는 죽었고, “Prompt Request”가 부상
“코드 자체보다 코드를 생성한 프롬프트를 보는 것이 더 중요”
이거 정말 충격적이었어요.
전통적인 개발 프로세스에서는 코드 리뷰가 핵심이었어요. PR(Pull Request)을 열고, 코드를 리뷰하고, 수정 요청하고… 이 과정이 개발의 중심이었죠.
그런데 AI 시대에는 이게 바뀌었어요.
코드 자체를 리뷰하는 게 아니라, 그 코드를 만든 프롬프트를 리뷰해야 한다는 거예요.
왜냐하면:
- 코드는 AI가 생성한 거라서, 매번 다를 수 있어요
- 하지만 프롬프트는 재사용 가능하고, 개선할 수 있어요
- 프롬프트가 좋으면 코드 품질도 좋아져요
그래서 Peter는 Discord에서도 코드가 아닌 아키텍처와 큰 결정만 논의한다고 했어요.
4. 코드 리뷰는 사라지고 아키텍처 논의가 대체
이건 위와 연결되는 얘기예요.
코드 리뷰에 시간을 쓰지 말고, 아키텍처 논의에 집중하라는 거예요.
- ❌ “이 변수명이 마음에 안 들어요”
- ❌ “이 함수가 너무 길어요”
- ✅ “이 기능을 추가하려면 어떤 아키텍처가 좋을까요?”
- ✅ “이 결정이 시스템 전체에 어떤 영향을 줄까요?”
AI가 코드 스타일은 알아서 맞춰주니까, 사람은 시스템 설계에만 집중하면 되는 거예요.
5. 5~10개 에이전트를 동시에 운영하며 “몰입(flow) 상태” 유지
이거 진짜 놀라웠어요.
Peter는 5~10개의 에이전트를 동시에 운영한다고 했어요. 각 에이전트가 서로 다른 기능을 병렬로 작업하는 거죠.
예를 들어:
- 에이전트 A: 사용자 인증 기능 개발
- 에이전트 B: API 엔드포인트 구현
- 에이전트 C: 프론트엔드 컴포넌트 작성
- 에이전트 D: 테스트 코드 작성
- 에이전트 E: 문서화 작업
이렇게 여러 에이전트가 동시에 작업하면, 사람은 전체적인 흐름을 관리하고, 각 에이전트의 결과를 통합하는 역할만 하면 돼요.
이게 바로 “몰입 상태”를 유지하는 방법이에요.
한 번에 하나씩 하면, 기다리는 시간이 생기고 몰입이 깨져요. 하지만 여러 에이전트를 동시에 돌리면, 계속해서 작업할 게 생기니까 몰입 상태를 유지할 수 있어요.
6. 계획 수립에 상당한 시간 투자
“에이전트와 반복적으로 대화하며 견고한 계획 수립. 계획에 도전하고, 수정하고, 반박한 후 만족하면 실행하고 다음으로 이동”
이거도 중요한 포인트예요.
많은 사람들이 AI에게 “이거 만들어줘” 하고 바로 실행시키는데, Peter는 계획 단계에 시간을 많이 투자한다고 했어요.
계획을 세우고 → 에이전트와 논의하고 → 계획을 수정하고 → 다시 논의하고… 이 과정을 반복해서 견고한 계획을 만든 다음에야 실행하는 거예요.
왜 이렇게 할까요?
계획이 명확하지 않으면, 에이전트가 엉뚱한 방향으로 갈 수 있어요. 그러면 나중에 수정하는 데 시간이 더 걸리죠.
반대로 계획이 명확하면, 에이전트가 정확하게 작업할 수 있고, 사람은 그 결과를 검증만 하면 돼요.
7. 의도적으로 덜 구체적인 프롬프트를 사용
이건 의외였어요.
보통은 프롬프트를 구체적으로 쓸수록 좋다고 생각하잖아요? 그런데 Peter는 의도적으로 덜 구체적인 프롬프트를 사용한다고 했어요.
왜냐하면, 예상치 못한 솔루션을 발견할 수 있기 때문이에요.
너무 구체적으로 프롬프트를 쓰면, AI가 그대로만 따르게 돼요. 하지만 어느 정도 여유를 주면, AI가 창의적인 해결책을 제시할 수 있어요.
물론 이건 경험이 필요한 부분이에요. 어느 정도까지 덜 구체적으로 쓸지, 이건 직접 써보면서 감을 잡아야 해요.
8. 로컬 CI가 원격 CI보다 우수
“원격 CI의 10분 대기 시간 대신 에이전트가 로컬에서 테스트 실행”
이거도 실용적인 조언이에요.
원격 CI(예: GitHub Actions)를 쓰면, 코드를 푸시하고 → CI가 실행되고 → 결과를 기다리는 데 10분 이상 걸려요.
그런데 에이전트가 로컬에서 테스트를 실행하면, 몇 초 만에 결과를 확인할 수 있어요.
이게 왜 중요할까요?
빠른 피드백 루프가 생산성의 핵심이에요. 10분 기다리는 동안 다른 일을 할 수 있지만, 몰입 상태가 깨질 수 있어요.
반대로 로컬에서 바로 확인하면, 즉시 수정하고 다시 실행할 수 있어서 몰입 상태를 유지할 수 있어요.
9. 대부분의 코드는 지루한 데이터 변환
“집착할 필요 없고, 에너지는 시스템 설계에 집중해야 함”
이거 정말 공감돼요.
실제로 개발하다 보면, 대부분의 코드가 지루한 반복 작업이에요:
- API 응답을 프론트엔드 형식으로 변환
- 데이터베이스 쿼리 결과를 가공
- 폼 데이터 검증
- 에러 처리
이런 건 AI가 알아서 하면 되고, 사람은 시스템 설계에 집중해야 해요.
어떤 기능을 추가할지, 어떤 아키텍처가 좋을지, 어떤 기술 스택을 쓸지… 이런 큰 결정에 에너지를 써야 한다는 거예요.
10. 구현 세부사항보다 결과물에 관심을 가진 엔지니어가 AI와 잘 협업
“알고리듬 퍼즐 풀기를 좋아하는 엔지니어는 ‘AI 네이티브’ 전환에 어려움을 겪음”
이거 좀 아픈 얘기일 수 있어요.
전통적인 개발자는 코드의 세부사항에 집착하는 경향이 있어요. “이 알고리즘이 최적인가?”, “이 자료구조가 효율적인가?” 이런 걸 고민하죠.
그런데 AI 시대에는 이게 바뀌었어요.
결과물이 중요해요. 코드가 어떻게 구현됐는지는 AI가 알아서 하니까, 사람은 결과가 원하는 대로 나오는지에만 집중하면 돼요.
물론 성능이 중요할 때는 최적화를 해야 하지만, 대부분의 경우에는 “동작만 하면 OK”예요.
내가 느낀 점: 워크플로우가 정말 핵심이었어요
이 글을 읽고 나서 한참을 멍하니 앉아있었어요.
제가 지금까지 AI 코딩 도구를 쓰면서 뭔가 아쉬웠던 게 뭐였을까요?
- 코드 스타일에 집착했어요
- 에이전트가 만든 코드를 계속 수정했어요
- 한 번에 하나씩만 작업했어요
- 계획 없이 바로 실행시켰어요
- 원격 CI 결과를 기다렸어요
모두 워크플로우 문제였어요.
도구가 문제가 아니라, 도구를 쓰는 방식이 문제였던 거예요.
Peter의 교훈을 보면, 핵심은 이거예요:
- 루프를 닫기: 에이전트가 스스로 검증하도록
- 아키텍처에 집중: 코드 스타일은 AI에게 맡기기
- 병렬 작업: 여러 에이전트 동시 운영
- 계획 우선: 실행 전에 명확한 계획 수립
이게 바로 AI 시대 개발자가 알아야 할 워크플로우예요.
솔직한 마음: 불안하지만 방향은 찾았어요
솔직히 말하면, 이 글을 읽으면서 좀 불안했어요.
“내가 지금까지 개발한 방식이 틀렸나?” “AI가 다 대체하는 건 아닐까?” “나는 어떻게 해야 하지?”
이런 생각들이 들었어요.
하지만 Peter의 얘기를 보니까, 대체가 아니라 협업이라는 게 명확해졌어요.
AI가 코드를 짜주는 건 맞지만, 어떤 코드를 짜야 할지, 어떤 아키텍처가 좋을지는 여전히 사람이 결정해야 해요.
그리고 그 결정을 내리려면, 시스템 전체를 이해해야 해요. 이건 AI가 못 하는 일이에요.
그래서 워크플로우가 중요한 거예요. AI가 할 수 있는 건 AI에게 맡기고, 사람은 사람만 할 수 있는 일에 집중하는 거죠.
앞으로 내가 할 것들: 워크플로우 재설계
이 글을 읽고 나서, 제 워크플로우를 완전히 바꾸기로 했어요.
1. 에이전트 자동 검증 루프 만들기
에이전트가 코드를 작성하면, 자동으로:
- 컴파일/빌드 실행
- 린트 체크
- 테스트 실행
- 에러 있으면 수정 요청
이 루프를 만들어야 해요. 지금은 수동으로 하고 있는데, 이걸 자동화하면 생산성이 엄청 올라갈 것 같아요.
2. 여러 에이전트 동시 운영 시도
지금은 한 번에 하나씩만 작업하는데, 이제는 여러 에이전트를 동시에 돌려보려고 해요.
예를 들어:
- 에이전트 A: 백엔드 API 개발
- 에이전트 B: 프론트엔드 컴포넌트 작성
- 에이전트 C: 테스트 코드 작성
이렇게 병렬로 작업하면, 기다리는 시간 없이 계속 작업할 수 있을 거예요.
3. 계획 단계 시간 늘리기
지금은 계획 없이 바로 실행시키는 경우가 많은데, 이제는 계획 단계에 시간을 더 투자하려고 해요.
에이전트와 대화하면서:
- 어떤 기능이 필요한지
- 어떤 아키텍처가 좋을지
- 어떤 기술 스택을 쓸지
이런 걸 명확히 한 다음에 실행하는 거예요.
4. 코드 스타일 집착 줄이기
이건 좀 어려울 것 같아요. 개발자라면 코드 스타일에 집착하는 게 당연하잖아요?
하지만 Peter의 조언대로, 동작만 하면 OK라는 마인드셋을 가져야 해요. 특히 지루한 반복 작업은 더욱 그렇고요.
대신 아키텍처와 큰 결정에 집중하는 거예요.
5. 로컬 CI 환경 구축
원격 CI를 기다리는 대신, 로컬에서 바로 테스트할 수 있는 환경을 만들어야 해요.
이렇게 하면 피드백 루프가 빨라져서, 몰입 상태를 유지할 수 있을 거예요.
결론: 워크플로우가 AI 시대 개발의 핵심
AI 코딩 도구를 쓰는 건 이제 선택이 아니라 필수가 됐어요.
하지만 도구를 쓰는 것만으로는 부족해요. 도구를 쓰는 방식, 즉 워크플로우가 핵심이에요.
MoltBot 제작자 Peter Steinberger가 1월에만 6,600건의 커밋을 기록한 비밀은 바로 이 워크플로우에 있었어요:
- ✅ 루프를 닫기: 에이전트가 스스로 검증하도록 설계
- ✅ 아키텍처에 집중: 코드 스타일은 AI에게 맡기기
- ✅ 병렬 작업: 여러 에이전트 동시 운영
- ✅ 계획 우선: 실행 전에 명확한 계획 수립
- ✅ 완벽주의 버리기: 동작만 하면 OK
이게 바로 AI 시대 개발자가 알아야 할 워크플로우예요.
도구는 계속 발전하지만, 워크플로우는 지금 당장 적용할 수 있어요.
여러분도 한번 시도해보세요. 생산성이 엄청 올라갈 거예요.