……라고 호언장담했지만, 정확히는 12일이 걸렸습니다. 제목 사기입니다. 죄송합니다.

하지만 '인간이 거의 코드를 작성하지 않고, AI 에이전트의 병렬 개발만으로 결제/2FA/AI 기능이 갖춰진 웹 서비스를 프로덕션 출시까지 끌고 갈 수 있는가?'라는 실험 자체로는 충분히 '해냈다!!'라고 말할 만한 결과였기에, 실록으로 정리합니다.

scrum for freelance(https://scrumfreelance.com)

이것은 프리랜서 대상의 프로젝트 매칭 서비스입니다.

서비스 이름인 '스크럼(Scrum)'은 럭비의 스크럼에서 따왔습니다.

이 서비스에서는 한 번 매칭된 상대와는 이후 수수료 없이 몇 번이라도 계약할 수 있습니다. 즉, 프로젝트에 참여할 때마다 '다음부터는 직접 협업할 고객'이 하나씩 늘어납니다. 일하면 할수록, 튼튼하게 협력할 상대가 쌓여갑니다—참여한 프로젝트 자체가 프리랜서의 자산이 되는 것입니다. 이런 근무 방식에 대한 염원을 담아 이름을 지었습니다.

※애자일 개발 방법론의 '스크럼(Scrum)'과는 관련이 없습니다.

• 법인이 프로젝트를 내놓고, 프리랜서가 받는 일방향 매칭
• 수수료는 '새로운 상대와의 첫 번째 매칭'에만 부과됩니다. 같은 상대와의 지속 계약, 단가 인상, 정규직 전환 시 중개 수수료는 전혀 발생하지 않습니다(이 부분이 기존 에이전시에 대한 반론입니다.) - 면담 조정, 계약, 거래 조건 명시 서면, 리뷰까지 사이트 내에서 완결
• AI 기능 (경력서 임포트/분석/자기 분석/프로젝트 매칭 분석) 포함

구조는 이렇습니다.

인간(나)
└─ Claude Code 메인 세션 ← 나는 거의 이것과만 대화합니다
├─ 서브 에이전트 A (worktree로 BE 구현)
...

제가 한 일은 정말 이것뿐입니다.

• '아바타 기능 필요 없다', '채팅창 높이를 가변으로 해달라' 같은 요구를 한국어로 던지는 것 - AWS, Stripe, Cloudflare 등의 대시보드를 클릭하는 것(스크린샷을 붙이면 다음에 누를 버튼을 알려줍니다) - 도중에 나오는 의사결정에 답하는 것(요금 모델은 어떻게 할까? 등)

코드는 한 줄도 작성하지 않았습니다. 에디터조차 열지 않았습니다. 진행 상황은 Agent view에서 병렬 에이전트의 움직임을 지켜보는 것뿐입니다. 겸손하게 말해 관람 스포츠에 가깝습니다.

이렇게 메인 세션이 레인표를 보여주면서 병렬 에이전트를 구동하고 있습니다.

• 인증(cookie session + TOTP 2FA + 계정 잠금)
• 프로젝트/프리랜서 검색(AND/OR・저장 검색)
• 면담 조정(Google Meet 연동)
• 채팅(기능 카드를 시계열 인라인 표시)
• 계약/거래 조건 명시 서면 PDF(prawn)
• Stripe Checkout 결제(성과 보수 + 월간 구독)
• 평가/신고/차단
• AI 경력서 임포트/분석/자기 분석(그래프 포함)
• admin 관리 화면
• Sentry・레이트 제한・PII 스크래빙

구조는 Rails (API 모드) + Next.js (App Router)의 리포지토리 분리입니다.

BE와 FE를 별도 리포지토리를 만든 이유는 병렬 개발과 궁합이 좋아서, 'BE PR을 머지 → FE 에이전트에게 사양을 전달하여 추종'이라는 계주가 깔끔하게 돌아가기 때문입니다.

티켓 관리는 **GitHub의 칸반(Projects)**으로, 이슈를 ToDo → In Progress → Done으로 흐르게 하는 단순한 운영이지만, AI가 스스로 보드를 업데이트하기 때문에 항상 실황 상태가 됩니다.

인프라는 Vercel + Render + RDS (MySQL) + Cloudflare R2 + SES + Stripe입니다. 작업 큐는 Redis를 계약하지 않고 **Solid Queue (MySQL 공유・추가 비용 0원)**을 사용했습니다.

하지만 단순히 '만들어달라'고 말하는 것만으로는 12일이 끝나지 않습니다. 효과적이었던 규칙은 5가지입니다.

'버튼 문구 수정해 달라' 수준의 요청이라도 GitHub 이슈를 생성한 후에 착수했습니다. 이는 AI 측의 규칙으로 학습시켰습니다. 병렬 개발의 교통정리와, 나중에 '무엇을 했는지'가 모두 추적 가능한 감사 로그 역할을 합니다.

각 에이전트는 전용 worktree + 전용 브랜치 + 전용 테스트 DB에서 작업합니다. 메인 작업 트리와 .env에는 건드리지 않습니다. 이렇게 해야 6레인 병렬로 해도 서로를 망가뜨리지 않습니다.

구현 에이전트는 PR(Pull Request)을 만드는 단계까지 담당합니다. 머지(Merge)는 메인 세션이 하나씩 리뷰하여 수행하며, 컨플릭트(Conflict) 해결도 그곳에서 일원화합니다. 병렬 개발 시 발생하는 "schema.rb가 매번 충돌하는" 문제는 여기서 흡수했습니다.

Rails의 spec은 이 글을 쓰는 시점에 2,177개입니다. 에이전트는 매번 모든 spec을 전용 DB에서 돌려 green(통과) 상태를 확인한 뒤에 PR을 내는 제약을 두었습니다. 병렬 개발은 "옆의 레인이 토대를 바꾸는 것"이 일상이기 때문에, 이것이 없으면 확실히 붕괴합니다.

tsc/lint/build를 통과해도 화면은 깨질 수 있습니다. FE(Frontend) 계열 에이전트에게는 반드시 dev 서버를 기동하여 Playwright로 시나리오를 확인(스크린샷 육안 확인까지)하게 했습니다. "seed 사용자로 로그인 → 검색 → 카드 → 상세 → 그래프 그리기 확인"까지 통과한 후에 PR을 올리는 방식입니다.

전자동이라고는 해도 사고는 발생합니다. 전부 그날 안에 복구할 수 있었지만, 공유할 가치가 있어 공개합니다.

R2의 시크릿 키를 채팅창에 붙여넣음 (본인 실수): AI가 즉시 지적하여 그 자리에서 키를 무효화하고 재발급했습니다. 이후 "시크릿은 채팅에 붙여넣지 말고 대시보드에서 직접 ENV로"라는 규칙이 만들어졌습니다. 인간이 가장 위험합니다.

운영 환경에서 메모리 초과 → 17분 주기 재시작 루프: Render 512MB 환경에 대해, puma(클러스터 모드) + Solid Queue가 공존하면서 Rails 프로세스가 5개 떠 있었습니다. 싱글 모드로 전환 + MALLOC_ARENA_MAX=2 + jemalloc 도입 + 인스턴스 증설로 해결했습니다.

운영 배포 즉시 실패: Solid Queue의 필요 DB 연결 수(5) > 풀(Pool)(3) 상황이라 puma까지 함께 다운되었습니다. 풀을 "Web 스레드 수 + 작업 워커 수"로 자동 계산하도록 수정했습니다.

2FA(2단계 인증)가 통과되지 않음: TOTP의 허용 드리프트(Drift)가 ±30초로 너무 엄격했던 점 + 설정 화면을 다시 열면 시크릿이 재발급되어 이전 QR 코드가 무효화되는 함정이 있었습니다. 멱등화(Idempotency)를 통해 해결했습니다.

게시판에 "0808157타타타0804 이쪽으로 연락 주세요"가 작성됨: 숫자 사이에 노이즈를 섞는 난독화된 전화번호를 정규 표현식 강화(노이즈 흡수 + 유도 문구 사전)를 통해 차단했습니다.

페이지 전환이 느림 → 조사 결과 인프라가 3개 대륙을 횡단 중:
SSR은 Vercel의 기본 리전(미국 동부), API는 Render(싱가포르), DB는... 왜인지 시드니(SES를 도쿄라고 생각하고 시드니에 만들었던 과거의 실수를 반복한 것입니다. 리전 선택은 인간을 가장 믿을 수 없습니다). 요청 한 번에 태평양과 타스만해를 몇 번이나 왕복하고 있었습니다. AI에게 실측하게 했더니 즉시 특정되었고, Vercel의 함수 리전 고정 + RDS 싱가포르 재생성을 통해 모두 같은 지역에 두었습니다. API 응답 속도가 일제히 수백 ms 단위로 개선되었습니다.

가장 많이 질문받을 것 같은 부분이지만, 체감상으로는 반대로 인간의 취미 코딩보다 더 견고합니다.

• 테스트 30,700행(앱 코드의 1.5배)이 항상 green 상태 유지
• 신용카드 거래 보안 대책 협의회의 체크리스트(Stripe 운영 환경 신고)에 맞춰 계정 잠금, 속도 제한(Rate Limiting), admin 다층 방어, PII 스크러빙(Sentry에 개인정보를 보내지 않음)까지 구현
• 그리고 머지 버튼 앞에는 반드시 인간(나)의 눈과 메인 세션의 리뷰가 배치됨

"AI가 멋대로 운영 환경을 망가뜨리는 것"이 아니라, "AI가 준비한 근거(테스트, 실기 확인, 설계 판단의 명문화)를 인간이 고속으로 승인해 나가는" 경험에 가깝습니다.

이 글에서 가장 실용적인 섹션일지도 모릅니다. 토큰과의 싸움에 관한 이야기입니다.

저는 처음에 아끼려고 낮은 플랜으로 시작했다가, 이틀 만에 Fable 5 사용량을 다 써버려서 울며 겨자 먹기로 Max 20x로 업그레이드했습니다. 병렬 에이전트를 돌리는 스타일은 상상 이상으로 토큰을 많이 소비합니다. 나중에 깨달은 사실이지만, 도중에 세션 제한에 걸려 개발이 몇 시간 동안 멈추는 손실을 생각하면, 처음부터 Max 20x로 시작하는 것이 결과적으로 더 싸고 편합니다. 특히 단기 집중적으로 작업한다면 더욱 그렇습니다.

메인 세션에 Fable 5를 사용하면 토큰 사용량이 급증합니다. 체감상 구현 작업의 9할은 Opus로도 충분합니다. Fable 5는 "결정적인 설계 판단" 시에만 아껴 쓰는 것이 가성비 측면에서 정답이었습니다.

서브 에이전트(Sub-agent)를 6개 병렬로 돌리다 보면, 토큰이 녹아내리는 소리가 들립니다(비유). 저는 항상 사용량 페이지를 열어둔 채, 남은 잔량을 확인하며 "오늘은 몇 개의 병렬로 돌릴 것인가"를 결정하곤 했습니다. 사용량에 여유가 있는 날은 6개 레인, 불안한 날은 2~3개 레인으로 좁히는 식의 운전법입니다.

기본 설정 상태에서는 에이전트가 명령을 실행할 때마다 허가를 요청하기 때문에, 잠시 눈을 뗀 사이에 "실행해도 될까요?"라며 멈춰 있어서, 돌아와 보면 아무것도 진행되지 않은 상황이 발생합니다. bypass permissions를 on으로 설정해 두면 밤중에도 알아서 진행됩니다. 물론 이는 "비밀 정보(Secret) 취급 및 접근 가능 범위"에 대한 규칙을 먼저 학습시키는 것과 세트로 이루어져야 합니다. 아무런 준비 없이 진행하는 것은 권장하지 않습니다.

• Claude Code:
  Max 20x 플랜(앞서 언급했듯, 단기 집중이라면 이것뿐입니다) - 인프라: Render+RDS+Vercel로
  월 1만 엔 전후. R2·SES·Sentry·Solid Queue는 거의 0엔 - 도메인: 연 10달러 정도

인건비로 환산해 생각하면, 뭐랄까, 파괴적인 가격입니다.

요청은 "무엇을 하고 싶은가"로 전달한다. 구현 방법은 AI에게 설계하게 하고, 판단만 내린다 -
규칙은 학습시킨다(티켓 기반(Ticket-driven)·비밀 정보 취급·테스트 게이트). 한 번 익히면 모든 레인에 적용된다 -
병렬화하려면 분리한다(worktree·테스트 DB·포트). 이 부분을 소홀히 하면 (비용이) 녹아내린다 -
머지(Merge)와 의사결정은 직렬로. 병렬로 진행하는 것은 구현뿐이다 -
대시보드 작업(AWS/Stripe 등)은 인간의 일. 스크린샷을 붙여넣으면 절차를 전부 안내해 준다

그런 이유로, 완성된 scrum for freelance는 이렇습니다.

• 프리랜서 분들: 수수료는 최초 매칭 시 1회만 발생합니다.
  지속 계약·단가 협상·정규직 전환 시 중개 수수료는 평생 발생하지 않습니다. AI 이력서 임포트·자기 분석 포함 → https://scrumfreelance.com - 사실 고백하자면, 프리랜서 측은 정말로 전부 무료로 만들고 싶었습니다. 다만 AI 기능(이력서 임포트·자기 분석·案件 매칭 분석)만은, 백엔드에서 LLM을 호출할 때마다 실비가 나가기 때문에, 무료로 개방했다가 연타를 당하는 순간 제가 죽습니다. 그래서 AI 기능만 Pro(월 980엔·횟수 제한 있음)로 설정했습니다. 검색, 응모, 채팅, 계약 등 AI 이외의 기능은 전부 무료입니다. "AI 기능이 어떤지 시험해 보고 싶다"는 분은 한 달만 결제하고 바로 해지하셔도 괜찮습니다(기간 말까지 사용 가능합니다). 아마 그런 분은 없겠지만요. (웃음)

발주하고 싶은 법인 분들: 성과 보수제만 적용(성사될 때까지 0원). 아직 갓 태어난 서비스이므로, 초기 유저로서 함께 키워주신다면 기쁘겠습니다!!

또한, 사용해 보시고 "이런 기능이 있으면 좋겠다" 하는 점이 있다면 요구사항 게시판을 구현해 두었으니 그쪽으로 올려주세요! 🙏

개발의 연속은 X(@e8GU641fyp8wtVS)에서 build in public으로 진행하겠습니다. "이 기능은 어떻게 만들었나요?"라는 질문이 있다면 댓글로 물어봐 주세요. 대답은 대부분 "AI에게 물어보니 만들어 주었다"이지만, 프롬프트(Prompt)와 규칙 설계에 대한 이야기는 나눌 수 있습니다.

할 수 있다!!

추신: 사실 이 글도 Claude Code에게 쓰게 시켰다는 것은 비밀입니다... (웃음)

(티켓 수, PR 수, 테스트 수도 전부 본인(?)이 git과 GitHub에서 집계한 실측값이므로, 어떤 의미에서는 가장 정확한 저자이기도 하다)