바이브코딩 슬롭 청소가 $10K/주 비즈니스가 됐다 — 성과제로 파는 폴란드 3인팀의 계산

핵심 요약 (TL;DR)

• 폴란드 3인팀 odra.dev/slopfix가 바이브코딩 리포지토리 청소를 주 $10,000 성과제로 판매 중입니다.
• 50% 축소 약속에서 20%만 달성하면 청구액은 $4,000으로 자동 축소, 2주 워런티에 CLAUDE.md·린트룰·CI룰까지 인계해요.
• 2026-07-07 Hacker News 302 포인트로 프론트페이지에 오르며, '뒷정리도 개별 비즈니스가 된다'는 첫 신호가 됐습니다.

바이브코딩 담론은 오랫동안 "만드는 쪽"에 집중되어 있었습니다. 새 모델, 새 오케스트레이터, 새 배포 파이프라인. 그런데 만드는 층이 커지면 필연적으로 뒷정리의 층도 자란다는 걸, 폴란드 3인팀 odra.dev가 정면으로 상품화했어요.

2026-07-07 Hacker News 302 포인트·238 댓글로 프론트페이지에 오른 slopfix 페이지는 문장이 무뚝뚝합니다. "우리는 AI 생성 코드 청소로 주 $10,000을 받습니다." 이런 문장은 보통 매력적이지 않아요. "청소"라는 단어가 붙어 있으면 프리미엄 서비스로 팔기 어렵거든요. 그런데 이 팀은 계산을 뒤집었습니다.

성과제 청구의 구조

가격 모델의 반전은 이거예요.

• 약속: 리포지토리 크기를 50% 축소
• 달성이 20%뿐이면: 청구액도 20/50 비율로 축소, 즉 $4,000만 청구
• 워런티: 인계 후 2주간 회귀 이슈 지원
• 인계물: CLAUDE.md 파일 + 린트 룰 + CI 체크 룰

50% 청소를 약속해두고 그중 40%(20/50)만 지불받는 계산은 얼핏 손해 같아 보입니다. 팀의 계산은 반대예요. "청소가 안 될 리스크를 클라이언트가 아니라 우리가 진다"는 신호를 걸어두는 게 심리적 방어벽을 낮추는 거죠. 6개월 전 Cursor로 급하게 만든 리포를 손 놓아버린 스타트업 CTO 관점에서, 남에게 맡기려면 "일단 얼마부터 결제하세요"라는 문장을 넘기가 어렵습니다. 성과제는 그 걸음을 없애요.

팀 구성과 포지셔닝

Maciej Zielony(Head of Engineering, GitHub zie1ony) + Kuba Płas(GitHub kubaplas) + Krzysztof(GitHub kpob). 3인 합산 경력 30년. 홈페이지의 자기 소개는 담백합니다. "매뉴얼 오버사이트로 AI 툴을 다룹니다." 재미있는 지점은, 이들이 청소 작업에도 Claude Code를 씁니다. AI로 만들어진 슬롭을 AI로 청소한다는 순환. 다만 매뉴얼 리뷰가 강한 훅으로 붙어 있어요.

왜 지금 '청소 시장'이 등장했는가

이 비즈니스가 지금 성립하는 이유는 몇 가지가 겹칩니다.

• 2024~2025년 Cursor·Lovable·Bolt로 부풀어 오른 리포지토리가 2026년에 유지보수 단계 진입
• 프론티어 모델이 저가화되면서 재작성 비용이 낮아짐
• CTO 개인이 리팩터링에 6주를 못 쓰는 스타트업 구조 (다른 우선순위가 있음)
• 시니어 3인이 개별 계약보다 팀 단위로 계약하는 게 훨씬 마진이 좋음

이 조합은 앞으로 최소 12개월간 유지될 겁니다. 상단(생성 도구)이 커질수록 하단(청소 서비스)이 자라는 게 자연스러워요.

바이브코더에게 남는 실전 질문

1. 자기 리포의 슬롭 지수를 어떻게 측정할까요. 함수당 라인 수, 순환 복잡도, 미사용 export, 중복 로직 클러스터. 이 지표를 CI에 걸어두면 슬롭이 쌓이는 속도가 보입니다.

2. CLAUDE.md 인계 문화를 지금부터 시작해두기. 프로젝트 컨벤션, 금지 패턴, 리팩터링 히스토리. AI 에이전트가 다시 만질 때 참고할 문맥이 문서로 남아 있어야 회귀가 줄어들어요.

3. 자기가 잘하는 청소 각도가 있다면 그것도 상품입니다. 굳이 폴란드 3인팀이 아니라도 시니어 한국 개발자가 국내 스타트업 시장에서 성과제로 청소 서비스를 열 수 있는 공간이 지금 열려 있어요.

FAQ

Q. odra.dev의 실제 케이스 스터디는 공개되어 있나요?

현재 사이트에는 개별 케이스 스터디가 공개되지 않았습니다. HN 스레드에서 팀이 몇 개의 프로젝트 유형을 언급했지만, 코드 규모·업종 등 상세는 미공개. 팀에 컨택해서 최근 3~4건의 성과 지표를 받아보는 게 실질적이에요.

Q. 성과제 산정 기준은 뭔가요?

페이지 문구는 "리포지토리 축소 비율"이라고만 표현되어 있어요. 라인 수인지, 파일 수인지, 사이클로매틱 컴플렉시티인지 세부 정의는 계약 단계에서 협의되는 걸로 보입니다.

Q. 개인 개발자도 비슷하게 시작할 수 있나요?

가능합니다. 단, 성과제는 "약속을 못 지켰을 때 감당할 수 있는 리스크의 크기"에 걸려요. 처음이라면 고정가로 3~5건 쌓으면서 자기 처리 속도의 표준편차를 재고, 이후에 성과제로 옮기는 순서가 안전합니다.

만드는 사람의 서사가 지배하던 시대에서, 청소하는 사람의 계산이 표에 오르는 시대로 넘어가고 있어요. 이번 신호를 놓치면, 다음 12개월간 열릴 두 번째 시장의 진입 창을 남에게 넘겨야 할지도 모릅니다.

소스: odra.dev/slopfix, HN 스레드