작은 수정이 모여서 일정이 밀리는 이유

프로젝트가 시작될 때는 명확했다. 웹사이트 3개 페이지, 배너 5개, 수정은 2회 포함. 그런데 며칠 뒤 메신저가 울린다. '이 버튼 색깔 좀 바꿔 주실 수 있을까요?' 작다. 5분이면 되는 수정이다. 그 다음날 또 온다. '로고 위치 좀 이쪽으로 옮겨 줄 수 없을까요?' 이것도 작다. 그리고 그 다음날, 그 다음날 또 온다.

언제부턴가 원래 일정은 잊혀진다. 매일 들어오는 '작은 것'들이 우선순위를 차지한다. 주말에 끝나기로 했던 프로젝트가 다음 주로 밀린다. 클라이언트는 전혀 미안해하지 않는다. 각각의 요청이 그렇게 크지 않으니까. 근데 누적되면? 원래 견적의 30~50%가 추가로 들어가 있다. 마진은 녹아내린다.

스코프 크리프는 커뮤니케이션 실패다

클라이언트가 나쁜 게 아니다. 대부분의 경우 자신이 요청을 기록했다고 생각한다. 메신저에 남겼으니까. 근데 프로젝트 관리자 입장에서 보면 그건 기록이 아니다. 메신저는 통지이지 시스템이 아니다. 스크롤 하나만 올리면 사라진다.

당신도 마찬가지다. 메신저로 들어온 요청을 일단 받고, 일정표에 언제 할지 못 정했다. 그러다가 '이미 한 작은 수정들'과 '아직 안 한 작은 수정들'이 섞인다. 어디까지가 원래 범위이고 어디부터가 추가 요청인지 경계가 흐려진다. 결국 양쪽 다 '기록의 부재'에서 싸운다. 클라이언트는 '분명히 말했는데', 당신은 '그건 요청인지 아닌지 몰랐는데' 하게 된다.

요청 접수표: 메신저를 시스템으로 만드는 법

스코프 크리프를 막는 방법은 간단하다. 요청이 들어오는 순간, 메신저에서 나와 별도의 문서에 기록하는 것이다. 스프레드시트든, 노션이든, 간단한 텍스트 파일이든 상관없다. 중요한 건 '공식 기록'을 남기는 것이다.

접수표에는 다섯 가지만 기록한다. 날짜, 요청 내용, 현황(대기/작업 중/완료), 원래 범위 포함 여부, 그리고 승인자. 마지막이 중요하다. '버튼 색깔 변경'이 요청되었을 때, 그게 원래 포함된 2회 수정에 드는 건지, 추가 비용이 드는 건지를 '명시적으로' 확인한다. 그리고 그 답변을 기록한다. 이메일이나 메신저에 '확인 메시지'를 남긴다. '버튼 색깔 변경은 추가 요청으로 분류했으며, XX 비용이 발생합니다. 진행해도 될까요?'

이 과정에서 마법이 일어난다. 클라이언트는 '아, 이건 추가 비용이 드는 거구나'를 명확히 인식한다. 그러면 70%는 스스로 필터링된다. 정말 필요한 것만 온다. 남은 30%는? 당신은 이미 기록했으니까 언제 할지, 원래 일정에 얼마나 밀릴지를 예측할 수 있다.

접수표를 공식화하는 방법

첫 미팅이나 계약서에 이 항목을 추가한다. '추가 요청은 별도 문서로 접수 및 확인 후 진행합니다. 메신저 요청만으로는 진행되지 않습니다.' 이건 거절이 아니다. 오히려 '정확한 처리 방식'을 말하는 것이다. 클라이언트 입장에서도 자신의 요청이 누락될 염려가 줄어든다.

매주 1회, 접수표를 정리하는 시간을 정한다. 월요일 10시든, 금요일 오후든 상관없다. 그 시간에 지난주 요청들을 분류하고, 우선순위를 매긴다. 그리고 클라이언트에게 '이번 주 처리할 추가 요청'을 공식 메시지로 알린다. 예를 들어, '지난주 요청 5건 중 3건은 원래 수정 범위에 포함되어 이번 주 반영하고, 2건은 추가 작업이므로 별도 비용 XX원 예상됩니다. 진행 여부를 알려 주세요.' 이렇게 하면 당신도, 클라이언트도 혼란이 없다.

메신저 알림이 줄어드는 부작용

이 방식을 시작하면 신기한 일이 일어난다. 메신저로 들어오는 무분별한 요청이 줄어든다. 클라이언트도 학습한다. '아, 이건 공식으로 접수해야 되는 구나'를 무의식적으로 인식한다. 그리고 진짜 필요한 것인지 다시 한 번 생각하게 된다. 불필요한 수정 요청은 절반 이상 사라진다.

당신은 '이미 원래 범위'를 벗어난 작업이 무엇인지 명확히 안다. 그래서 급할 때는 '미안하지만 현재 범위 내에서는 어렵습니다'라고 당당히 말할 수 있다. 이건 무례함이 아니다. 일의 기준을 정하는 것이다. 클라이언트도 대부분 '아, 그렇구나'하고 받아들인다. 왜냐하면 그 기준이 처음부터 정해져 있었기 때문이다.

접수표 형식: 즉시 쓸 수 있는 템플릿

| 요청일 | 요청 내용 | 요청자 | 범위 분류 | 예상 작업시간 | 비고 | |--------|---------|--------|----------|------------|------| | 2024-01-15 | 버튼 색깔 변경 (파란색→빨간색) | 담당자 A | 추가 | 1시간 | 2025-01-20 승인 | | 2024-01-16 | 로고 위치 조정 | 담당자 B | 원범위 | 30분 | 수정2회차에 포함 | | 2024-01-17 | 페이지 3개 추가 제작 | 담당자 A | 추가 | 16시간 | 별도 비용 산정 필요 |

실제로는 더 간단해도 된다. 노션의 간단한 테이블이나 구글 시트 한 장이면 충분하다. 중요한 건 '메신저 밖의 공식 기록'이다. 이게 있으면 언제든 뒤를 돌아볼 수 있다. '이건 언제 요청 받았고, 어느 상태인가?'를 명확히 한다. 그리고 그 기록은 나중에 분쟁의 증거가 되기도 한다. 하지만 대부분의 경우 분쟁 자체가 일어나지 않는다. 기록이 명확하면 싸울 이유가 없기 때문이다.

이 방식이 제대로 작동하려면

가장 중요한 건 '첫 응답 속도'다. 요청이 들어온 지 2시간 안에 접수표에 기록하고, 클라이언트에게 '받았습니다'라는 확인 메시지를 보낸다. 이건 처리를 약속하는 게 아니라, 기록했다는 걸 알리는 것이다. 그러면 클라이언트도 불안해하지 않는다.

그 다음은 '정기적인 리뷰'다. 주 1회 접수표를 정리하고, 클라이언트에게 '이번주 처리 현황'을 알린다. 이게 습관이 되면, 당신과 클라이언트 사이의 커뮤니케이션 갭이 확 줄어든다. 요청이 누락될 일도, 당신이 깜빡할 일도 없다. 그리고 무엇보다 당신의 일정을 지킬 수 있다. 원래 범위 내에서의 작업을 우선하면서도, 추가 요청을 체계적으로 처리할 수 있기 때문이다.