서론

위탁 개발을 하다 보면 거의 모든 프로젝트에서 '납품 후 추가 요구사항 러시'를 만납니다. 저도 예외는 아니어서, 심할 때는 '이것으로 완료'에 합의했다고 생각한 기능에 납품 후 3주 만에 30건 이상의 추가 요구사항이 쌓인 적이 있습니다.

저희 회사(AI-CEO Framework 운영 회사)는 2026년 3월에 위탁 매출 ¥1,937,635를 기록했습니다. X사 ¥880K, C사 ¥933K, A사 ¥110K, H사 ¥15K로 내역이 나뉘는데, 이 모든 프로젝트가 '스코프는 어디까지이고, 여기부터는 추가 견적'이라는 선을 명확히 긋고 나서야 성립할 수 있었습니다.

본 글에서는 제가 10개 사업 동시 운영에 실패하고 3개 사업에 집중하는 전략으로 전환한 경험을 바탕으로, 왜 추가 요구사항이 멈추지 않는지, 어떻게 경계를 설정해야 하는지, 그리고 AI(Claude Code)를 어떻게 활용할 것인지 작성합니다.

왜 추가 요구사항은 멈추지 않는가

1. 클라이언트는 '완성상'을 본 후에야 진정한 요구사항을 말할 수 있다

소프트웨어는 집이나 브로슈어와 달리, 움직이는 것을 만져보지 않으면 '여기가 이상하다', '이렇게 하고 싶다'라는 말이 나오지 않습니다. 이것은 클라이언트가 나쁜 것이 아니라, 소프트웨어라는 상품의 특성입니다.

즉, 납품 후 추가 요구사항이 0건인 것은 구조적으로 불가능합니다. 전제 조건으로 '나올 것'이라고 각오해야 합니다.

2. '간단한 수정'이라는 말이 함정이다

'버튼 색상만 바꿀게요', '항목을 하나 추가할게요'. 이것들이 정말 5분 만에 끝난다면 문제는 없습니다. 하지만 실제로는,

• 버튼 색상 변경 → 디자인 시스템 전체의 일관성 체크 → 관련 화면 5개 확인
• 항목 1개 추가 → DB 스키마 변경 → 마이그레이션 → 기존 데이터 처리 → API 수정 → 프론트 수정 → 테스트

와 같은 연쇄 반응이 일어납니다. 클라이언트 관점에서는 '간단한 것'이라도, 실제 공수는 수 시간~수 일이 됩니다. 여기서 '서비스로 하겠습니다'를 반복하면, 프로젝트는 확실하게 적자 구조가 됩니다.

3. 계약서에 '스코프'가 쓰여 있지 않다

이것이 최대 원인입니다. '웹사이트 제작 일체', '○○ 시스템 개발'이라고만 쓰여 있는 계약서로는, 무엇이 포함되고 무엇이 포함되지 않는지가 완전히 해석에 달립니다.

제가 하는 스코프 관리 실전

단계 1: 제안 단계에서 '하지 않을 것'을 명문화한다

제안서에 '본 프로젝트의 스코프'뿐만 아니라, '본 프로젝트의 스코프 외(추가 견적 대상)'를 반드시 작성합니다. 예를 들어,

스코프 내:

• 로그인 기능 (이메일 + 비밀번호)
• 관리 화면 (사용자 목록, 상품 CRUD)
• 결제 기능 (Stripe 연동, 카드 결제만)

스코프 외(별도 견적):

• SNS 로그인 (Google/X 등)
• 다국어 대응
• 은행 송금, 편의점 결제
• 관리 화면 권한 분리 (관리자/일반)
• 감사 로그 기능

'하지 않을 것'을 이렇게 구체적으로 적으면, 상담 중에 '아, SNS 로그인도 받고 싶습니다'라는 이야기가 나와서 견적에 반영할 수 있습니다. 나중에 트러블이 생기지 않습니다.

단계 2: 검수 조건을 '인수 테스트 항목'으로 정의한다

'납품 = 검수'가 아니라, '사전에 합의한 인수 테스트 전 항목이 통과 = 검수'로 정의합니다. 테스트 항목은 클라이언트와 함께 만듭니다. 이것을 하지 않으면, 납품 후에 '생각했던 것과 다르다'가 무한히 나옵니다.

단계 3: 납품 후 추가 요구사항은 '무료 수정'인지 '추가 견적'인지 즉시 판정한다

판단 기준은 단 두 가지입니다.

• 검수 항목에 쓰인 요건을 충족하지 못한 경우 → 무료 수정 (버그)
• 검수 항목에 쓰여 있지 않은 것 → 추가 견적 (신규 기능/개수)

이 규칙을 처음에 공유해두면, 추가 요구사항이 왔을 때 '이거 버그인가요, 추가 기능인가요?'라는 대화가 가능합니다. 트러블이 생기는 건 '서비스로 해줘'가 암묵적인 전제가 되어 있을 때입니다.

단계 4: 유지보수 계약 형태로 '예상되는 추가 요구사항'을 월 단위로 만든다

납품 후 추가 요구사항이 반드시 나올 것이라는 걸 알고 있다면, 처음부터 월별 유지보수 계약을 세트로 제안하는 것이 합리적입니다. 월 ¥50,000~¥150,000으로 '월 X시간까지 대응'이라는 틀을 파는 것입니다.

이렇게 하면 클라이언트는 안심하고 상담할 수 있고, 저는 예측 가능한 매출이 생깁니다. Win-Win의 형태로 만들 수 있습니다.

AI(Claude Code)로 스코프 관리 강화하기

여기부터가 본론입니다. 저는 위탁 프로젝트의 스코프 관리를 거의 Claude Code에 맡기고 있습니다.

활용 1: 제안서 초안에서 '스코프 외'를 자동 추출

클라이언트 인터뷰 메모를 전달하며, "이 내용으로 개발할 경우, 스코프 외 (Scope out) 항목으로 명시해야 할 사항을 리스트업해줘"라고 AI에게 요청합니다.

사람은 "말하지 않은 것"을 의식에서 놓치기 쉽지만, AI는 유사 프로젝트의 패턴을 바탕으로 "이것은 보통 포함되지 않는 기능이죠?"라는 점을 망라하여 제시해 줍니다. 덕분에 누락이 거의 제로(0)가 되었습니다.

활용 2: 인수 테스트 (Acceptance Test) 항목 자동 생성

요구사항 정의서(Requirement Definition Document)로부터 인수 테스트 항목을 기계적으로 생성하게 하고 있습니다. 프로젝트당 50~150개 항목을 AI가 만들게 하고, 제가 리뷰합니다. 처음부터 직접 쓰는 것과 비교하면 시간이 1/10로 단축됩니다.

활용 3: 추가 요청 발생 시 '공수 산정 (Estimation)' 자동화

클라이언트로부터 추가 요청 메일이 오면, 그 내용을 요구사항 정의서 및 기존 코드베이스와 함께 Claude Code에 입력하여,

• 영향 범위 (변경이 필요한 파일 목록)
• 예상 공수 (Estimated Man-hours)
• 리스크 (기존 기능에 미치는 영향)
• 견적 금액 (시간당 단가 × 공수)

를 출력하게 합니다. 이를 초안으로 삼아 제가 리뷰하여, 견적서 드래프트(Draft)를 5분 만에 만듭니다.

활용 4: 과거 프로젝트 스코프 판례 DB 구축

이것이 가장 효과적이었습니다. 과거 프로젝트에서 "이것은 추가 견적 대상으로 처리했다", "이것은 무료 대응으로 했다"라는 판단 기록을 Markdown으로 쌓아두고, 새로운 요청이 왔을 때 "과거 판례에서는 어떻게 판단했었지?"라고 AI에게 묻습니다.

판단의 흔들림이 없어졌고, "그 프로젝트 때는 공짜로 해줬으면서"라는 클라이언트의 지적에도 일관된 답변을 할 수 있게 되었습니다.

실패를 통해 배운 점

저는 과거에 AI의 출력을 그대로 전송했다가, 경어 사용이 부적절한 영업 메일을 거래처에 보내버린 실수가 있습니다. 그 후, 모든 대외 액션은 "초안(Draft) → 승인 → 실행"의 파이프라인을 거치도록 규칙을 세웠습니다.

스코프 관리도 마찬가지입니다. AI가 "추가 견적 대상입니다"라고 판정한 것을 그대로 클라이언트에게 보내는 것이 아니라, 반드시 제가 리뷰합니다. AI는 실행 도구이며, 판단은 인간입니다. 이것은 제 안에서 고정된 원칙입니다.

또 하나, "사소한 수정 정도는 서비스로"라는 마음이 너무 강하면 프로젝트는 확실히 적자로 돌아섭니다. 10개 사업을 동시에 운영하다 실패했을 때, 9개 사업의 매출이 0이었던 반면, 유일하게 돌아가던 사업은 "무료 대응을 하지 않는다"라는 선긋기가 철저히 되어 있었습니다. 친절함 때문에 선을 긋지 않는 것은 장기적으로 누구에게도 도움이 되지 않습니다.

요약

• 납품 후 추가 요청은 제로(0)로 만들 수 없다는 전제하에 설계한다
• 제안 단계에서 '스코프 외'를 명문화한다
• 검수 조건은 사전에 합의된 인수 테스트로 정의한다
• 추가 요청은 '검수 항목에 포함되는가'를 기준으로 기계적으로 판정한다
• 유지보수 계약을 통해 예측 가능한 매출로 전환한다
• Claude Code로 스코프 외 추출, 테스트 항목 생성, 공수 산정, 판례 DB를 자동화한다
• 최종 판단은 인간. AI는 실행 도구

수탁(Outsourcing)은 매출을 올리기 쉬운 반면, 스코프 관리를 소홀히 하면 쉽게 적자로 전환됩니다. 선긋기는 냉정함이 아니라, 서로 기분 좋게 일을 계속하기 위한 시스템입니다.

서적 안내

저희 회사는 AI-CEO Framework(10개 부문의 AI 에이전트로 회사를 운영하는 시스템)를 실천한 서적을 Zenn에서 공개하고 있습니다. 수탁 개발을 포함한 사업 운영의 자동화, Claude Code의 실전 활용, 월 5만 엔의 AI 투자로 회사를 운영하는 방법 등을 다루고 있습니다.

📚 Zenn 서적 목록: https://zenn.dev/joinclass?tab=books

관심 있는 분들은 꼭 한 번 살펴보시기 바랍니다.

Discussion