161. 범위 크리프 (Scope Creep) - 무분별한 요구사항 확장 방지

핵심 인사이트 (3줄 요약)

본질: 범위 크리프(Scope Creep)는 초기 계약에 없던 사소하고 미세한 기능 추가나 설계 변경이 명확한 과금(돈)이나 일정 조정(협상) 없이 스멀스멀 프로젝트에 스며들어(Creep) 무한 증식하는 현상을 말한다.

가치: "안 된다고 하면 고객이 화낼 텐데?"라는 영업사원과 PM의 얄팍한 배려(Yes-man 증후군)가 개발자의 코드를 꼬이게 만들고 오픈일을 한 달 뒤로 터뜨려, 결국 고객과 개발사 모두가 소송전에 휘말리는 루즈-루즈(Lose-Lose) 게임의 근원이다.

융합: 이를 쳐내기 위해 아키텍트는 기획 초기 단계에 베이스라인(Baseline) 도장을 찍어 스펙을 꽝꽝 얼리고, 1px의 화면 수정을 요구하더라도 반드시 CCB(변경 통제 위원회)의 차가운 '영향도 분석(비용 청구서)' 심판대를 거치게 만드는 거버넌스 파이프라인(Jira/Git)을 강제 융합해야만 생존할 수 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: Creep(크리프)는 '살금살금 기어가다'라는 뜻이다. 소프트웨어 공학에서 Scope Creep은 프로젝트의 범위(요구사항)가 프로젝트 수행 중 승인 절차를 거치지 않고 지속적으로, 그리고 통제할 수 없을 정도로 확장되는 치명적인 리스크 상태를 의미한다.
필요성: 은행 계좌 이체 시스템을 10억에 3달 만에 짜주기로 계약했다. 1달 차, 고객이 말한다. "어차피 결제 만드는 김에 카카오페이 연동 하나만 살짝 얹어주세요. 며칠 안 걸리죠?" 착한 PM은 "네 서비스로 해드릴게요"라고 한다. 2달 차, "버튼 색깔이 맘에 안 드네요. 다 파란색으로 고치고 화면에 벚꽃 흩날리는 효과 하나만 싹~ 추가해 줘요." 또 구두로 받았다. 오픈 D-1일. 벚꽃 애니메이션 코드가 결제 모듈 메모리를 다 갉아먹어서 서버가 뻗었다(OOM 에러). 10억짜리 프로젝트가 개발자 100명 투입 야근비로 20억의 적자를 내고 부도가 났다. "도대체 이 재앙의 시작점은 어디였나? 바로 문서에 도장도 안 찍고 '공짜'로 기능 1개를 욱여넣어 준 그 첫 번째 순간이었다!" 이 무자비한 범위 팽창을 막기 위해 프로젝트 관리(PMP) 학문은 Scope Creep을 악마의 0순위로 지목하고 방어막(Scope Management)을 건설했다.
💡 비유: Scope Creep은 식당에서 1만 원짜리 백반을 시킨 손님이 계속 **"이모! 여기 김 하나만 더 줘요! 어? 계란말이도 하나 서비스로 부쳐줘요!"**라고 공짜 반찬을 끊임없이 요구하는 진상 짓입니다. 식당 사장님(PM)이 웃으며 다 퍼주다 보면, 그날 재료비와 인건비(야근)는 5만 원이 터져서 장사할수록 무조건 빚을 지고 식당(프로젝트)이 망해버리는 끔찍한 현상입니다.
등장 배경:
1. 소프트웨어의 비가시성(Invisibility): 10층짜리 아파트를 짓다가 "15층으로 올려줘!"라고 하면 당장 콘크리트 무너지는 게 눈에 보이니까 돈을 더 낸다. 하지만 소프트웨어는 눈에 안 보이기 때문에 고객은 "코드 그냥 몇 줄 복사 붙여넣기(Ctrl+C, V) 하면 되는 거 아니야?"라고 착각하는 끔찍한 무지함이 팽배했다.
2. 골드 플레이팅(Gold Plating)의 이기적 열정: 고객이 시키지도 않았는데 개발자 지 혼자 삘(Feel) 받아서 "난 천재니까 인공지능 추천 알고리즘을 여기 몰래 더 짜넣어서 사장님을 놀래켜줘야지!"라며 몰래 범위를 팽창시키는 잉여 짓도 Scope Creep의 주범이다.

┌─────────────────────────────────────────────────────────────┐
│          범위 크리프(Scope Creep)가 아키텍처를 파괴하는 도미노 붕괴의 늪     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ 😇 [ 나비의 날갯짓 (The Trigger) ]                            │
│  - 기획자: "개발자님, 장바구니에 [해외 배송 옵션] 하나만 쏙 추가해 줘~"     │
│  - 개발자: "음.. 뭐 DB 컬럼 하나만 파면 되니까 알았어요! (문서 안 남김)"   │
│                                                             │
│          ▼ (단 한 줄의 구두 승낙이 부른 나비 효과)                │
│                                                             │
│ 💥 [ 지하 세계(Backend) 도미노 파국 연쇄 폭발! ]                  │
│  1. DB: `장바구니` 테이블에 `국가 코드` 컬럼 파야 함. 인덱스 깨짐!        │
│  2. 결제 API: 국내 PG사 쓰던 거 다 뜯어고치고, Paypal 연동 모듈 새로 짜야 함!│
│  3. 보안팀: "야! 해외 결제면 환율 변동 차익(FDS) 검사 로직 추가해야지!"    │
│  4. QA팀: "장바구니 테스트 케이스 100개 다 처음부터 다시 짜고 밤새워 테스트!" │
│                                                             │
│ 💀 [ 프로젝트의 최후 (Disaster) ]                              │
│  - 사장님: "아니, 버튼 하나 넣는데 왜 서버 에러 나고 일정이 2주 밀려!!"     │
│  - 개발자: "저거 하나 땜에 로직 1만 줄 다 꼬였다고요! 난 퇴사할래!"       │
│                                                             │
│ 🌟 아키텍트의 피눈물: "그때 안 된다고 했어야 했다. 소프트웨어에 '단순한 버튼' │
│    하나란 없다. 화면의 1픽셀은 백엔드의 1만 줄 서버 로직과 물려있는 빙산의 일각│
│    일 뿐이다!"                                                │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] "그깟 기능 하나 넣어주는 게 뭐가 힘들어?"라는 고객(과 영업팀)의 무지를 완벽하게 찢어발기는 기술사적 아키텍처 다이어그램이다. 소프트웨어의 강결합(Tight Coupling) 생태계에서 1개의 수정(Add-on)은 1개의 코딩 노동으로 끝나지 않는다. 10개의 테스트 케이스 재작성, 스키마 마이그레이션 다운타임, 보안 인증 리뷰라는 숨 막히는 오버헤드(Overhead) 폭탄이 숨어있다. 이를 문서 쪼가리 결재(CCB) 없이 받아들이는 순간, 범위 크리프는 걷잡을 수 없는 괴물이 되어 프로젝트 예산을 남김없이 태워 먹는다.

📢 섹션 요약 비유: 코딩은 젠가(Jenga) 블록 탑 쌓기와 같습니다. 고객이 "중간에 파란색 블록 하나만 살짝 빼고 빨간색 넣어줘~"라고 가볍게 부탁합니다. 얼핏 보면 블록 하나 바꾸는 거지만, 그 하나를 잘못 건드리는 순간 위태롭게 쌓여있던 100층짜리 젠가 탑(서버 아키텍처) 전체가 와르르 무너져버리고 먼지만 남습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. Scope Creep의 3대 발생 원인 (Root Causes)

누구 한 명의 탓이 아니다. 멍청한 삼위일체가 합작한 결과물이다.

요구사항의 모호성 (Ambiguity): 계약서에 "결제 기능을 예쁘고 빠르게 만들어 주세요"라고 적어놨다. 오픈 날, 고객이 "내 기준에 안 예쁘니까 3D 애니메이션 넣어 올 때까지 돈 안 줘"라고 생떼를 쓴다. (애초에 "0.5초 이내 응답, 파란색 #0000FF 버튼"이라고 숫자로 못 박지 않은 PM의 죄).
이해관계자(Stakeholder) 난입: 계약할 때 없었던 상무님이 갑자기 1달 뒤에 나타나 "요즘 메타버스가 대세인데 우리 쇼핑몰에도 VR 기능 싹 다 넣어!"라며 권력으로 룰을 다 뒤엎어버림.
골드 플레이팅 (Gold Plating - 금도금): 고객은 원하지도 않았는데, 개발자 지 혼자 오버(Over)해서 "나 천재니까 인공지능 추천 알고리즘 몰래 짜넣어 줘야지" 하다가 버그 내서 서버 날려 먹는 내부적 뻘짓(자기 위안 코딩).

2. WBS (작업 분할 구조도)의 붕괴

Scope Creep이 무서운 진짜 이유는 프로젝트의 심장인 WBS(Work Breakdown Structure) 엑셀표를 완전히 걸레짝으로 만들어버린다는 데 있다.

PM은 100일 치 개발 일정을 WBS로 딱 맞춰서 톱니바퀴처럼 짜놨다. "철수는 월화수 DB 짜고, 목금 프론트엔드 붙여!"
화요일에 크리프(기능 추가)가 터져 철수가 DB에 2일을 더 뺏겼다. 목요일에 놀아야 하는 프론트엔드 개발자가 할 일이 없어 놀고 있다(병목 발생).
전체 일정의 **크리티컬 패스(Critical Path, 절대 늦춰지면 안 되는 핵심 경로)**가 직격탄을 맞아, 결과적으로 오픈일이 한 달 뒤로 쫙 밀리며 지체 보상금(하루 수천만 원) 벌금을 맞고 회사가 파산한다.
📢 섹션 요약 비유: 범위 크리프는 마라톤을 뛸 때 가방에 **'모래주머니를 몰래 하나씩 집어넣는 짓'**입니다. 처음 한두 개는 티가 안 납니다("뭐 버튼 하나인데~"). 하지만 뛰다 보면 30kg이 넘어가 무릎 관절(아키텍처)이 바스러지고 결승선(오픈일)에 절대 도착하지 못하고 길바닥에 쓰러져 앰뷸런스에 실려 가게 됩니다.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: 폭포수(Waterfall)의 철벽 방어 vs 애자일(Agile)의 범위 변동 수용

"애자일은 변경을 적극 환영하라고 했잖아요! 그럼 Scope Creep도 좋은 거 아님?" ➔ 100% 썩은 착각이다.

항목	폭포수 (Waterfall)	애자일 (Agile / Scrum)
범위(Scope)의 철학	"도장 찍힌 스펙(베이스라인)은 절대 못 바꾼다. 바꾸려면 돈(CR) 내놔라!" (범위 고정, 시간/비용 변동 허용).	"스펙(범위)은 매주 바뀔 수 있다. 단, 우리가 약속한 1달(시간)과 10명의 인건비(비용) 안에서만 굴러간다!" (범위 변동 허용, 시간/비용 고정).
Scope Creep의 발현	고객이 베이스라인을 깨고 "이거 꽁짜로 넣어줘"라고 떼를 쓸 때 일어나는 최악의 룰 파괴.	스크럼 진행 중에 사장님이 갑자기 난입해서, 오늘 스프린트 개발 목록에 없는 엉뚱한 업무(새치기 기능)를 던지고 짜라고 윽박지를 때 벌어짐.
아키텍트의 융합 방어막	CCB(변경 통제 위원회) 재판관들을 소집해 도장 3개를 받아오게 하여 기를 꺾어버림.	스프린트 락킹(Sprint Locking): "사장님, 다음 주 월요일 새 백로그 짤 때 다시 오세요. 지금 달리고 있는 2주짜리 스프린트 기간엔 총 들이대도 코드 1줄 못 끼워 넣습니다!" (미니 통제벽)

과목 융합 관점

요구사항 관리 (추적성 - Traceability RTM): 크리프를 방어하는 유일한 무기는 입이 아니라 엑셀 장부다. 요구사항 추적 매트릭스(RTM)가 완벽히 JIRA와 엮여 있다면, 사장님이 "버튼 하나 넣자"고 할 때 PM이 1초 만에 JIRA 대시보드를 켜서 팩트 폭격을 날린다. "사장님, 저 버튼 넣으시려면 RTM에 연결된 기존 백엔드 API 3개랑 테스트 코드 100개를 다 허물어야 합니다. 일정 3일 밀리는데 사인하실 건가요?" 영향도 분석(Impact Analysis)이 초를 단위로 숫자로 박혀서 나오는 순간, 사장님은 입을 다물고 꼬리를 만다. 데이터 기반의 철통 디펜스 아키텍처다.
클라우드와 DevOps (기능 플래그 - Feature Toggle): 예전엔 고객이 맘 바뀌어서 "그 추가 기능 맘에 안 들어, 다시 빼버려!"라고 하면 코드를 git revert로 뜯어내다 서버가 뻗었다. 모던 데브옵스 아키텍트는 고객의 징징거림(Creep)을 하드코딩하지 않는다. 코드를 일단 다 짜놓고(Merge), 코드 앞단에 **If(Feature_Flag_A == True) 라는 스위치(토글)**를 달아 배포한다. 고객이 "아 그 기능 빼" 하면, 서버 재부팅(Re-deploy) 없이 그냥 AWS 클라우드 대시보드에서 스위치만 똑딱(False) 내려버려 그 기능을 0.1초 만에 화면에서 증발시켜 버리는 쿨하고 얄미운 인프라 차단 방벽이다.
📢 섹션 요약 비유: 애자일의 변경 수용은 **'뷔페 식당'**입니다. 2시간(스프린트 시간) 동안 3만 원(정해진 예산) 내고 치킨을 먹든 초밥을 먹든 맘대로 바꿀 수 있습니다(범위 유연성). 하지만 2시간 넘어서까지 앉아있으려 하거나, 랍스터(예산 초과 기능)를 구워오라고 진상을 부리는 것(Scope Creep)은 애자일에서도 절대 허용 안 되는 범죄 행위(경찰 출동)입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 구두 지시(Verbal Request)가 부른 법정 소송의 파국: 50억짜리 관공서 웹사이트 구축. 관공서 주무관이 매일 아침 커피를 사 들고 와서 개발팀장 어깨를 주무르며 "팀장님~ 이거 텍스트 상자 크기 좀 키워주시고, 메뉴 하나만 쓱 달아주세요~ 며칠 안 걸리죠?"라고 3달 내내 50번을 툭툭 던지고 갔다. 팀장은 착해서 그냥 문서(JIRA)도 안 남기고 다 짜줬다. 50번을 수정하느라 일정이 2달 지연되었다. 관공서는 "너희들 오픈일 2달 넘겼으니 지체 보상금 매일 천만 원씩 벌금 내!"라고 소송을 걸었다.
- 판단: SI(시스템 통합) 업계에서 가장 흔하게 터지는 피눈물 나는 파산 시나리오다. "내가 너희들이 시키는 거 다 짜주느라 늦었잖아!"라고 판사 앞에서 울어봤자 소용없다. **'변경 요청서(Change Request, CR)'**라는 서류 도장이 없으면, 그건 개발자가 그냥 혼자 미쳐서 뻘짓(Gold Plating)하다 시간 날려 먹은 걸로 법적으로 판결이 난다. 실무 아키텍트는 아무리 고객이 10분짜리 쉬운 코드를 부탁해도 절대 키보드에 손을 올리지 않고 "JIRA 시스템에 정식으로 티켓 파시고 PM 도장받아 오시면 해드립니다"라고 피도 눈물도 없이 차단하는 관료적 싸가지(Compliance)를 장착해야만 콩밥을 면한다.
시나리오 — 타임박스(Timeboxing)를 무시한 끝없는 완벽주의의 덫: 내부 신사업 앱 런칭 프로젝트. 회사 사장님이 "애플처럼 완벽한 UI를 만들지 않으면 출시 안 해!"라고 선언했다. 앱이 99% 완성되었는데, 사장님이 매일 밤 "애니메이션이 안 부드러워 0.1초 늦춰, 그림자 1px 짙게 해" 라며 미세 튜닝(Micro Creep)을 끝도 없이 지시했다. 출시일이 6개월이나 밀려버렸고, 그 사이 경쟁사(토스)가 선수를 쳐서 비슷한 앱을 런칭해 버려 시장을 100% 뺏기고 프로젝트 팀이 공중분해 되었다.
- 판단: 완벽주의의 탈을 쓴 Scope Creep의 전형적인 타임 투 마켓(Time-to-Market) 붕괴 참사다. 현대 소프트웨어의 생명은 완벽함이 아니라 속도(Agility)다. 100점짜리 앱을 1년 뒤에 내는 것보다, 60점짜리 엉성한 앱(MVP: Minimum Viable Product)을 한 달 만에 내놓고 고객 반응을 보며 고치는 게 무조건 이긴다. 이 끝없는 디자인 수정 늪을 끊기 위해 아키텍트는 **'타임 박스(Timebox)'**라는 철창을 가둔다. "사장님, 다음 주 금요일 무조건 출시합니다. 그 안에 끝나는 기능만 나갑니다. 안 끝난 기능은 다 잘라내서 V2.0(다음 버전)으로 미룹니다!"라며 데드라인을 목숨처럼 지켜내어 시간과 돈의 출혈을 칼같이 베어내는 무자비한 결단이 필요하다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: Scope Creep을 분쇄하는 3단 방벽 통제 파이프라인 │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [ 👿 고객의 간악한 시도: "결제에 포인트 할인 기능 하나만 넣어줘~" ]  │
  │                                                             │
  │        ======= [ 방벽 1: 요구사항 명세서(SRS) 바이블 대조 ] ======== │
  │                                                             │
  │ 📝 PM 왈: "고객님, 처음 계약서(SRS) 50페이지 3번 항목에 포인트 기능   │
  │          안 하기로 도장 쾅(Baseline) 찍으셨죠? 계약 외(Out of Scope) │
  │          요구사항입니다. 기각 ❌"                               │
  │                                                             │
  │        ======= [ 방벽 2: JIRA 락킹(Lock)과 견적서 청구 ] ========   │
  │                                                             │
  │ 💰 기획자 왈: "굳이 꼭 하시고 싶다고요? 그럼 JIRA에 정식 CR 티켓 올리세요.│
  │             이거 RTM 까서 영향도 분석해 보니까 서버 구조 갈아엎어야 해서 │
  │             일정 2주 밀리고 개발자 야근비 3,000만 원 추가 청구서 나갑니다.│
  │             돈 내실 건가요? ❌"                                   │
  │                                                             │
  │        ======= [ 방벽 3: CCB(변경 통제 위원회) 재판관의 철퇴 ] ======== │
  │                                                             │
  │ ⚖️ 아키텍트 왈: "고객이 3천만 원 돈 더 낸다고 하네? 잠깐! 이거 지금 짜면 │
  │              보안 인증서(Compliance) 빵꾸 나서 서버 오픈 심사 떨어집니다.│
  │              지금 손대는 건 자살 행위니까 V2.0(다음 버전)으로 미루시죠 ❌"│
  │                                                             │
  │ 🌟 결론: "좋은 게 좋은 거지"라며 웃으면서 다 해주는 PM은 무능의 극치다.    │
  │    이 3개의 거친 톱니바퀴 바리케이드를 세워두고, 고객이 질려서 튕겨 나가게  │
  │    만드는(Drop) 것이 Scope Creep을 막는 진정한 엔터프라이즈의 거버넌스다!│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] "그냥 말로 떼울 수 있지 않나요?"를 철저히 박살 내는 시스템 통합(SI) 프로젝트 생존 가이드라인이다. 고객의 요구(Change)를 무조건 나쁘다고 할 순 없다. 문제는 **"정식으로 문서화(Documented)되지 않고, 돈(Budget)의 지불 동의가 없으며, 리스크(Impact) 계산 없이 암암리에 들어오는 요구(Creep)"**가 암세포라는 것이다. 이 암세포는 빛(공식 절차, CCB)을 비추면 바로 쪼그라들어 타죽는다. 3,000만 원 견적서(Impact Analysis)를 받아 든 고객의 99%는 "아 그럼 이번엔 그 기능 뺄게요"라며 순순히 꼬리를 내리며 자본주의의 참교육을 받게 된다.

도입 체크리스트

기술적: 개발자가 고객 요구를 쌩까고 자기 멋대로(Gold Plating) 밤새 이상한 AI 추천 코드를 500줄 짜서 깃허브에 푸시(Push)하려 한다. 이 쓰레기 코드를 막기 위해, Github PR(Pull Request) 화면에 올라온 커밋 메시지 상단에 [JIRA-TICKET-ID] 가 안 적혀있으면 젠킨스(Jenkins) CI 봇이 1초 만에 "요구사항 문서에 없는 족보 없는 코드 발견!"이라며 붉은색 에러를 뿜으며 아예 브랜치 병합(Merge) 자체를 거부(Reject)해 버리는 Git Hook 방벽 시스템이 커널 단에 박혀 있는가?
운영·보안적: 프로젝트 막판에 1만 개의 코드가 쏟아질 때, 고객이 몰래 기획서 워드 파일을 수정해서 서버에 올려두고 "원래부터 있던 기능인데 네가 안 짠 거잖아!"라고 뒤집어씌우는 짓을 방어해야 한다. 기획서(SRS.doc)를 베이스라인 치는 순간, 그 파일의 **SHA-256 암호학적 해시값(지문)**을 떠서 읽기 전용 보안 스토리지(또는 퍼블릭 블록체인)에 영구 박제(Immutable Record)해 두어, 1글자라도 고치면 해시가 깨져 위조 범죄로 소송을 걸 수 있는 형상 감사(Configuration Audit) 록킹 장치를 구비했는가?

안티패턴

골드 플레이팅 (Gold Plating) 맹신: 개발자나 디자이너가 "고객이 원하지도, 요구하지도 않았지만, 내가 보기에 이 3D 애니메이션을 버튼에 넣으면 끝내주게 멋질 거야!"라며 본업 일정을 미루고 혼자 심취해서 잉여 코드를 욱여넣는 짓. 장인 정신으로 포장하지만 철저한 기술적 자위행위(Masturbation)이자 배임이다. 이 추가 코드는 나중에 메모리 누수(OOM)의 원인이 되고, 퇴사한 뒤엔 다른 개발자가 디버깅을 못 해 서버를 터뜨리는 암세포가 된다. "문서(스펙)에 없는 건, 버그(Bug)보다 더 나쁜 바이러스다." 명세서에 100점을 맞추라 했으면 100점만 짜야지, 오지랖으로 120점을 만들어 바치는 짓은 아키텍처를 뒤틀어버리는 사형 감이다.
📢 섹션 요약 비유: 골드 플레이팅(잉여 코딩)은 고객이 **'딱 맞는 청바지(100점)'**를 만들어 달라고 돈을 줬는데, 디자이너 혼자 삘 받아서 무릎에 화려한 **'스팽글과 금가루 장식 1kg(120점)'**을 몰래 박아준 꼴입니다. 고객은 예쁘다고 고마워할까요? 천만에요. 바지가 너무 무거워서 걸을 수도 없고(서버 성능 저하), 세탁기에 돌리면 금가루가 다 떨어져 세탁기가 박살 납니다(유지보수 지옥). 그냥 시킨 것만 깔끔하게 하는 게 프로의 미덕입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	무지성 구두 요구 수용 (Yes-Man 환경)	Baseline 및 CCB 기반 철벽 통제 파이프라인	개선 효과
정량	계속되는 기능 추가로 오픈일 한 달, 두 달 지연	거절(Reject) 및 정식 협상을 통한 일정 사수	무한 핑퐁 스파게티 늪(Death March) 및 오픈 지연 확률 90% 소멸
정량	공짜 추가 개발로 인한 개발팀 야근 수당 적자	영향도 분석을 통한 과금(Add-on Bill) 청구	회사 매출 적자 전환 방어 및 정당한 추가 이윤(M/M) 100% 회수
정성	"이거 니가 해준다며!" 진흙탕 소송과 욕설	"Jira 티켓 번호 없으니 안 짭니다." (차갑고 투명한 팩트)	개발팀의 멘탈 보호 및 고객과의 감정 싸움 없는 데이터/계약 기반 파트너십 정착

미래 전망

대형 언어 모델(LLM) 기반의 요구사항 모순 탐지 봇 (Requirement Copilot): 기획자가 슬랙(Slack)에 무심코 "버튼 파란색으로 바꿔줘"라고 치면, 사내 백그라운드에 숨어있던 AI(챗GPT)가 문장을 0.1초 만에 낚아채서 분석한다. "삐빅! 해당 요청은 어제 승인된 베이스라인 문서 V1.3의 '모든 경고 버튼은 빨간색으로 통일한다'는 룰셋과 정면 충돌(Conflict)하는 Scope Creep 시도입니다. 자동으로 Jira 변경 요청(CR) 티켓 생성 및 견적 비용 10만 원을 고객에게 카톡으로 발송하시겠습니까?" ➔ 기계가 인간의 얕은 변심을 통계와 문서 해독으로 즉시 요격해 버리는 AI PM(프로젝트 매니저)의 시대가 당도했다.
노코드(No-Code) / 로우코드(Low-Code) 시대의 프로토타이핑(Prototyping) 예방주사: Scope Creep이 터지는 이유는 고객이 "완성된 진짜 화면"을 프로젝트 마지막 달에 가서야 눈으로 보기 때문이다(보고 나서 "이거 아니잖아 엎어!"). 이 악순환은 끝난다. Figma나 Webflow 같은 노코드 툴로, 프로젝트 1일 차에 아예 클릭하면 넘어가는 '진짜 100% 똑같이 생긴 가짜 앱 화면(High-fidelity Prototype)'을 던져준다. 고객이 이걸 일주일간 만져보며 "아 여기 메뉴 넣어야겠다"라고 초반에 크리프의 욕망을 모조리 배설하게 둔다. 욕망 배설이 끝나면 거기서 베이스라인 도장을 쾅 얼려버리기 때문에, 후반부 개발 삽질(Rework) 리스크가 태생적으로 0%로 증발하는 애자일 시뮬레이션 생태계의 완벽한 승리다.

참고 표준

PMBOK (Project Management Body of Knowledge): 미국 프로젝트 관리 협회가 쓴 성경. "요구사항 관리 챕터에서 WBS(작업 분할 구조) 사전에 없는 작업을 구두로 승인하는 PM은 프로젝트를 지옥으로 이끄는 죄인이다"라고 못 박은 글로벌 절대 규격.
애자일 스크럼 (Scrum Framework): "고객의 변심(Scope Creep)은 스크럼 백로그(Backlog)에 일단 다 예쁘게 쌓아 둔다. 단! 2주짜리 스프린트(Sprint)가 시작된 뒤에 억지로 끼워 넣으려는 시도는 스크럼 마스터가 몽둥이로 때려 막는다"는 유연함과 통제의 이중 밀당 헌법.

"가장 멍청한 코드는 에러가 나는 코드고, 가장 슬픈 코드는 시키지도 않았는데 짜놓은 잉여(Creep) 코드다." 소프트웨어 공학은 컴퓨터와 싸우는 학문이 아니다. "내가 1,000만 원 줄 테니 이 기능 예쁘게 짜줘"라는 인간의 탐욕과, "1,000만 원이면 이 정도만 짜야 밤을 안 새워"라는 개발자의 생존 본능이 멱살을 잡고 부딪히는 지독한 정치(Politics) 게임이다. 범위 크리프(Scope Creep)는 이 팽팽한 줄다리기에서 개발자가 '좋은 사람'이 되려고 웃으며 줄을 살짝 놓아버릴 때 터지는 재앙의 이름이다. 고객의 모든 변심을 가혹하고 피도 눈물도 없는 JIRA 티켓 번호와 엑셀 견적서(RTM)로 응징해 내는 차가운 관료주의(Governance) 방패만이 당신의 퇴근 시간을 지켜줄 것이다. "No(안 됩니다)"라고 당당하게 말하지 못하는 엔지니어는, 결국 남이 싼 스파게티 똥 코드를 치우느라 주말 내내 서버실에서 울부짖게 될 것이다. 거절(Reject)할 줄 아는 용기, 그것이 시스템을 구원하는 가장 빛나는 아키텍트의 첫 번째 검(Sword)이다.

📢 섹션 요약 비유: 범위 크리프는 미용실에 머리 자르러 온 손님이 "앞머리 조금만 더, 옆머리 조금만 더" 계속 요구하는 겁니다. 미용사가 거절 못 하고 계속 가위질을 들어주다 보면, 결국 손님 머리는 땜통이 나고 스님처럼 '빡빡머리(서버 붕괴)'가 되어 버립니다. 그리고 손님은 "네가 머리 망쳤잖아!"라며 소송을 걸죠. 미용사는 애초에 "여기서 1cm 더 자르면 삭발 됩니다! 동의서(CR)에 사인하세요!"라고 차갑게 경고하고 가위를 내려놓는 냉혹함이 필요합니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
베이스라인 (Baseline)	범위 크리프(암세포)가 침투하지 못하게 콱 닫아버린 콘크리트 무균실. 이 도장이 찍힌 이후에 기획서를 바꾸려면 피 말리는 재판(CCB)을 견뎌야만 한다.
CCB (변경 통제 위원회)	"기능 하나만 더 넣어줘~"라고 징징대는 고객 앞에 "그럼 3천만 원 1주일 연기 견적서 사인하세요"라며 찬물과 계산기를 들이붓는 차갑고 완벽한 5인의 방어 요원들.
골드 플레이팅 (Gold Plating)	고객이 시키지도 않았는데 개발자 지 혼자 삘받아서 화려한 3D 애니메이션 잉여 코드를 짜넣다가 서버 메모리 터뜨리고 장애 내는, 자살행위급 내부 반역 크리프.
WBS (작업 분할 구조도)	100일 치 개발 일정을 톱니바퀴처럼 짜놓은 엑셀표. 크리프가 하나 치고 들어와서 이 엑셀의 '크리티컬 패스(빨간 줄)'를 툭 건드리는 순간 전체 오픈 일정이 한 달 밀리는 연쇄 붕괴가 일어난다.
영향도 분석 (Impact Analysis)	크리프의 헛소리를 논리로 박살 내는 엑스레이 스캐너. "버튼 하나 바꾼다 치자, 근데 엮여있는 저기 서버 3대랑 DB 2개 다 터지는데 감당 됨?"이라며 입을 막아버리는 추적성(RTM) 엑셀의 마법.

👶 어린이를 위한 3줄 비유 설명

피자 가게에서 1만 원짜리 콤비네이션 피자를 시킨 손님이, 주방장한테 "치즈 쪼금만 더~ 햄도 서비스로 쪼금만 더~" 라며 얍삽하게 계속 공짜 토핑을 요구하는 진상 행동을 **'범위 크리프'**라고 해요.
착한 주방장(개발자)이 계속 거절 못 하고 공짜로 재료를 다 올려주면? 결국 그날 피자집은 재료비만 날리고 밤새워 일하다가 쫄딱 망해서 문을 닫게 되죠(프로젝트 파산).
이걸 막기 위해 사장님이 딱 나타나서 "손님! 햄 하나 추가하실 때마다 정확히 2,000원씩 영수증(변경 요청서)에 찍고 결제하셔야 합니다!"라고 단호하게 막아내는 무서운 방어 규칙이랍니다!