지난 6개월간 직접 작성한 코드 0줄로 22개 레포에서 560개 이상의 PR을 머지하고 약 97만 줄을 수정한 기록이다. 최대 10개 작업을 병렬로 진행하며 하루에 10개 이상의 PR을 처리하기도 한다. 1인 팀으로 시작해 이런 규모의 산출물을 만든 경험을 공유하는 데 의미가 있다고 밝히며, 정답은 아닐 수 있다고 전제한다.
핵심 포인트- 맥락이 사람의 머리가 아니라 LLM의 컨텍스트 윈도우 안에 있어, 작업 간 전환할 때 기억을 더듬을 필요가 없다.
- 각 작업은 Git worktree로 독립된 디렉터리에 물리적으로 분리해 서로 간섭하지 않게 한다.
- 프롬프트는 "이 기능 만들어줘" 수준으로 간단히 던지고, AI가 스스로 어떤 파일을 어떤 순서로 고칠지 분석해 계획을 세우게 한다.
- LLM은 "일단 이것만 해봐, 다음에 고칠게"보다 "전체 그림은 이거고 여기서부터 여기까지 한 번에 만들어줘"를 받았을 때 더 좋은 코드를 만든다.
- 3만 줄 이상을 수정하며 Go 컨벤션을 전면 교체한 리팩터링에서도 기존 기능이 모두 정상 작동했고, 다른 개발과 병렬로 진행됐다.
상세 정리- 팀 상황: 2025년 8월 말 합류해 약 4개월간 혼자 일했고 2026년 1월에 한 명이 더 합류해 현재 2인 팀이다.
- 작업 흐름: worktree 생성 → 한 줄 프롬프트 → AI가 계획 수립 → 사람이 계획 검토와 승인 → 의사결정이 필요할 때만 개입 → 각 단계마다 커밋 → 완료 후 추가 검토 지시 → PR과 CI 확인.
- 계획 단계의 이점: 사람이 전달해주면 굳이 찾아보지 않을 내용까지 AI가 디테일하게 이해하고 컨텍스트 윈도우에 저장해둔다.
- 계획 검토 기준은 기존 코드와 일관성이 있는지, 기획 의도에 맞는지다.
- 중간 개입은 "이 부분은 A 방식으로 할까요 B 방식으로 할까요" 같은 질문에 답하는 정도로 제한한다.
- 커밋을 단계마다 하는 것을 게임의 세이브 포인트에 비유한다.
- 리뷰 반영: PR 후 CI 통과를 확인하고 CodeRabbit의 피드백을 LLM이 직접 읽어 수정 계획을 세워 반영하며, CI가 깨끗해질 때까지 반복한다.
- 역할 변화: 코드 작성자에서 의사결정자이자 시스템 설계자로 바뀌었다. 코드를 한 줄도 직접 쓰지 않지만 어떤 아키텍처를 고를지, 어떤 트레이드오프를 감수할지, 기획 의도에 맞는지는 여전히 사람의 몫이다.
- 병렬화의 계기: 위임이 늘면서 AI가 코드를 짜는 동안 할 일이 없어졌고, 2개로 시작해 문제가 없자 3개, 4개로 늘려 현재 최대 10개까지 왔다.
- 병렬화의 전제: 작업 간 의존성 해소가 중요해 A가 끝나야 B를 할 수 있는 상황을 최소화해야 한다. 한 프로젝트 안에서도 의존성을 파악해 순서대로 진행시키고, 병렬 가능한 태스크에는 한계가 있어 독립적으로 진행 가능한 프로젝트를 여러 개 들고 있다.
- 태스크 부여 방식: 명확한 스펙을 먼저 주고 설계에서 구현, 테스트까지 한 번에 구현시키는 편이 반복 피드백으로 점진적으로 만드는 것보다 훨씬 효과적이다.
- 다만 프로젝트 전체를 완벽히 설계하고 시작하라는 뜻은 아니고, 최소한의 컨벤션만 지키며 일단 동작하게 만든 뒤 실제로 잘 작동해 코드에 남아야 한다면 그때 리팩터링한다.
- 리팩터링도 별도 일정을 잡는 것이 아니라 다음 프로젝트를 하면서 병렬로 돌리는 일 중 하나로 다룬다.
- 담당 범위로 자체 앱 개발과 여러 내부 도구가 언급된다.
왜 읽나AI 코딩 도구를 개인 생산성 향상 수준에서 쓰고 있는 개발자에게, 병렬 작업과 계획 검토 중심 워크플로우가 실제로 어디까지 가는지와 그 전제 조건을 보여준다.
채널톡·
NHN Cloud·
Stack Overflow Blog·
포스타입·