brunch

You can make anything
by writing

C.S.Lewis

by 진토끼 Nov 14. 2024

프로젝트가 산으로 가지 않게 하는 Scope 설정법

"하는 김에 이것도 추가해주세요"에 흔들리지 않도록

서비스 기획 또는 PM을 하다 보면 한 번쯤은 들어본 말이 있다.


“이왕 하는 김에 이 기능도 넣어주세요!”


가벼운 요청 같지만, 기획자나 PM 입장에서는 적지 않은 부담이 되는 말이다. 듣는 순간 속으로 깊은 한숨을 내쉬며(...) 추가 작업의 파급효과를 설명해야 한다. 자칫하면 프로젝트가 산으로 갈 수도 있는 요청이기 때문이다. 사실 이런 요청이 반복되는 이유는 프로젝트 스코프(Scope)가 명확히 정의되지 않은 상태라서 그럴 것이다. 

하는김에 이것도 넣고 저것도 넣고 오? 저것도 

스코프가 불분명하면 프로젝트 진행 중 새로운 요구가 계속 추가되고, 범위가 끝없이 확장되면서 일은 무한정으로 늘어난다. 이 글에서는 ‘하는 김에 이것도 넣어달라’라는 말이 왜 자주 나오는지, 이런 요청이 프로젝트에 어떤 영향을 주는지, 그리고 이를 막기 위해 스코프를 어떻게 명확히 정의할 수 있는지에 대해 알아보겠다.

이번 프로젝트는 "사용자가 좋아하는 가수의 노래를 쉽게 찾도록 가수 검색 기능을 추가하는 것"이라고 가정해보자.





1. '하는 김에 이것도 넣어 주세요!' - 이 요청이 자주 발생하는 이유?


이런 요청은 왜 그렇게 자주 나오는 걸까? 이유는 크게 두 가지로 나눠볼 수 있다.  



1) 추가 요청의 공수와 복잡성에 대한 이해 부족 


“이 기능도 추가하면 어때요?”라는 말은 요청하는 쪽에선 아주 간단해 보일 수 있다. 

"그럼 추천 검색어 기능도 추가하자!”는 요청이 들어온 상황을 떠올려 보자. 
이것도 추가하면 좋은거 맞잖아~~

이게 생각보다 간단한 기능이 아닐 수 있다는 것을 요청자가 생각하지 못하는 경우가 많다. 하지만 생각하지 못하는게 죄가 아니다프로덕트 담당자가 아니고 개발팀과 긴밀하게 일하지 않는 부서일 경우에는 해당 기능의 공수와 복잡성에 대해 당연히! 모를 수 있다. 




2) 모호한 프로젝트 목표와, 초기 목표에서 벗어난 요청 


프로젝트 목표가 명확히 공유되지 않으면, 진행 중에 처음 계획과 다른 요청이 쉽게 추가될 수 있다. 

프로젝트의 목적이 “사용자가 원하는 가수의 노래를 더 쉽게 찾을 수 있도록 하는 것”이었지만,
이해관계자들에게는 단순히 “검색 기능을 추가한다”는 사실만 강조된 상황을 생각해보자. 

원래는 가수 이름을 검색하는 기능만 추가하려던 프로젝트였지만, 목적이 명확히 공유되지 않다 보니 검색 기능 자체에만 초점이 맞춰져 “추천 검색어 기능도 추가하자”는 요청까지 나오게 되는 것이다.




2. 스코프를 명확히 정의해야 하는 이유


단순히 기획자의 골치를 아프게 한다는 이유뿐 아니라, 스코프를 명확히 해야 하는 이유를 구체적으로 살펴보자.  


1) 프로젝트 범위 변동 방지

프로젝트 스코프가 불명확하면 일정과 자원 관리가 어려워진다. 스코프를 명확히 정의하면 처음 설정한 목표에 맞춰 범위를 고정하고, 불필요한 추가 요청을 걸러낼 수 있다. 

사업팀: 이왕 일정도 연장했는데, 추천 검색어도 만들어주세요.

개발자: 아니.. 추천 검색어는 그냥 만들어지는게 아니라니까요? 추천을 무슨 기준으로 어떻게 할건지는 생각해보셨어요?

기획자: (마른 세수)
내가 잘못했어.. 그만 싸워...

스코프가 명확히 정해져 있다면, 이런 추가 작업의 필요성 여부를 판단하기 쉬워진다. 예정에 없던 추천 검색어 기능을 추가하려면, 별도의 데이터베이스 구축, 추천 알고리즘 설계 및 추가 연동 작업이 필요할 수 있다. 기획자 입장에서는 범위가 확장되며 프로젝트 자원과 일정 관리가 더 어려워지는 상황에 직면하게 된다. 처음부터 검색 결과 조회 외의 기능들은 제외한다고 명확히 정리해두었다면 거절하기가 훨씬 쉽다.



2) 이해관계자 간의 오해 최소화

스코프가 모호하면 프로젝트 참여자들이 각기 다른 방식으로 이해하고 있을 가능성이 크다. 명확한 스코프 정의는 모든 이해관계자가 같은 내용을 공유할 수 있게 하고, 오해를 줄여준다. 


예를 들어, 관리자 페이지에서 유저가 검색한 키워드 데이터는 하루에 한 번만 업데이트하기로 구현되었지만, 유관 부서에서는 실시간 데이터 갱신을 기대하면서 생길 불필요한 혼란을 방지할 수 있다. 

운영팀: 왜 실시간 데이터가 안 올라오죠?

라는 질문에, 애초에 실시간 갱신은 포함하지 않았다고 설명하면 된다. 명확한 스코프는 이러한 불필요한 논쟁을 예방하는 방패막이 된다.      



3) 리스크와 영향 범위 사전 파악 

명확한 스코프 정의는 프로젝트 시작 전 리스크를 예측하고 대비할 기회를 제공한다. 프로젝트 범위가 명확하면 예상치 못한 위험 요소를 미리 고려해 예방할 수 있다.

개발자: 막상 추천 검색어를 개발하다보니 성능 개선을 위해서는 인덱싱이 필요할 것 같습니다. 그리고 이건 작업기간이 n일 더 추가됩니다.

예를 들어, “대규모 데이터 인덱싱을 필요로 하는 기능은 제외한다”와 같은 스코프가 설정되어 있었다면, 인덱싱이 필요한 추천 검색어 기능 등으로 인해 발생할 수 있는 성능 저하 또는 일정 지연 문제를 미리 방지할 수 있다.





3. 그러면 스코프를 어떻게 설정하죠?


스코프 정의는 프로젝트가 예상치 못한 폭주를 막아주는 방어막이자, 팀원 모두가 같은 목표를 바라보게 하는 나침반이다. 제대로 스코프를 정의하려면 어떤 내용을 포함해야 하는지, 어떤 기준을 세워야 하는지 차근차근 짚어가며 정리해보자.



1) 프로젝트 개요와 목표를 명확히 기술하기

우선, 이 프로젝트가 필요한 이유와 최종 목표를 모두가 명확히 이해하도록 정리하는 것이 중요하다. 이번 프로젝트의 목표는 ‘사용자가 특정 가수의 노래를 쉽게 찾도록 돕는 것’이다. 


회의 진행 시 목표에 대한 공유와 리마인드로 회의를 시작하거나, 문서마다 초입에 목표를 간결하게 적어두면 프로젝트의 목적을 혼동하지 않고 모두가 같은 방향으로 일할 수 있다. 



2) '범위'와 '기준'을 정의하기

꼭 스코프에 한정된 이야기는 아니고, 기획서 작성 시에 공통적으로 적용되는 얘기긴 하지만, 필요한 기능을 구체적으로 명시해야 한다. 


이번 프로젝트의 핵심 범위는 가수 이름을 검색해 해당 가수의 노래 목록을 제공하는 것으로, 추가적으로 노래 목록에 곡 제목과 앨범명, 발매 연도까지 표시하는 기능을 포함할 수 있다. 이 때 검색 결과는 사용자가 2자 이상 입력했을 때 실시간으로 보여지도록 설정한다고 구체화해두자.


또한 각 기능이 완성된 것으로 간주할 기준도 명시해야 한다. 예를 들어, 

"가수 이름의 일부만 입력해도 해당 가수의 이름이 자동완성되어야 한다"
"검색 결과에서 곡 목록이 표시되고 곡 제목, 앨범명, 발매 연도가 포함되어야 한다"

와 같은 구체적인 완료 기준을 정리해두면 혼란이 줄어든다. 이렇게 해두면 나중에 누군가 "앨범 커버 이미지는 왜 표시되지 않죠?"라고 물어봐도, 기준에 없는 항목은 범위에 포함되지 않았다는 것을 확실히 설명할 수 있다.



3) 제외 항목(Out of Scope)도 리스트업하기

가수 검색 기능을 구현하는 데 있어 포함하지 않는 기능도 가능하면 리스트업해두는 것이 중요하다. 모든 제외 항목을 나열하기는 어렵겠지만, 혼란이 많을 것으로 예상되는 것들을 미리 제외해둘 수 있다. (함께 일을 오래 하다보면, 저 팀에서는 이 얘기를 하겠지? 하는 감이 생기기도 한다.) 


예를 들어, 이번 프로젝트에서는 "추천 검색어 기능이나 다국어 검색 기능은 포함하지 않는다"라고 적어두면 중간에 추가 요청이 들어왔을 때 쉽게 선을 그을 수 있다. 추가 요청이 들어왔을 때 “이번 프로젝트에서는 그 부분은 포함되지 않아요”라고 분명히 답할 수 있어 프로젝트 범위가 통제되지 않고 지켜질 수 있다.  



4) 변경 관리 절차 설정하기

C레벨: 검색 기능에 '최근 인기 가수 목록'은 꼭 있어야할 것 같은데? 경쟁사 △△에도 있던데?

부득이하게 초기에 정한 스코프에서 벗어난 수정 요청이 있을 수도 있다. 예시로 든 상황처럼 누군가의 강력한 의지일 수도 있고, PM이나 기획자가 초기에 놓친 중요한 포인트일 수도 있다. 아무리 스코프를 정하는게 중요한들, 진행 중에 나온 의견들을 모두 무시하고 처음에 정한 대로만 (경주마처럼..?) 앞만보고 갈 수는 없다. 어떻게 처음에 정한 대로만 일이 진행되겠는가~

나도 그렇게 생각해

이런 요청에 대비해 변경 요청이 들어올 때 어떻게 처리할지 절차를 미리 명시해두면 혼란을 줄일 수 있다.

예를 들어, “모든 변경 요청은 PM에게 전달되며, 우선순위에 따라 검토 후 매주 월요일에 의사결정”와 같은 절차를 포함하면, 중간에 새로운 요구가 생기더라도 기존 일정과 계획에 큰 차질 없이 조율할 수 있다.  



5) 결과물과 성과 측정 방법 명시하기

마지막으로, 이번 프로젝트의 성과를 어떻게 평가할지 기준을 정해두자. 

- 검색 기능 사용 빈도 10% 증가
- 곡 페이지로의 전환율 20% 달성

처럼 구체적인 지표를 정해두는 게 좋다. 성과 기준이 명확하면, 프로젝트의 목표와 일치하지 않는 추가 요구에 흔들리지 않게 된다. 예를 들어 "검색 기능 사용 빈도 증가"라는 목표가 설정되어 있다면, 가수 검색 기능을 넘어서는 추가 요구사항은 스코프에서 제외하기 쉽다. 


또한 성과 목표가 설정되어 있으면 프로젝트 종료 시 어떤 기준으로 성공 여부를 판단할지 명확해지기 때문에 프로젝트가 계획대로 마무리될 가능성이 높아진다. 구체적인 지표가 있기 때문에 성공적인 결과를 얻기 위해 꼭 필요한 요소를 점검하고 유지할 수 있다.






프로젝트 진행 도중 “하는 김에 이것도 해주면 좋지 않을까요?”라는 요청은 프로젝트의 일관성과 일정에 큰 위협(...)이 될 수 있다. 이를 방지하기 위해선 프로젝트 초기 단계에서 명확한 스코프 설정이 필수적이다. 스코프를 명확히 작성하면 불필요한 추가 요청을 막고, 이해관계자 간 기대치를 맞추며, 프로젝트의 목표를 일관되게 유지할 수 있다


모든 프로젝트에서 스코프 문서를 작성하는 것이 항상 필요하지는 않다. (소규모 프로젝트일 경우 오히려 비효율적일 수도 있음) 그리고 나도 이 글을 쓰면서.. 막상 쓴대로 100% 실행하지는 않고 있어서 급 반성하는 계기도 됐다. 특히 중요한 프로젝트일수록 명확한 스코프 정의가 프로젝트의 성공을 보장하는 중요한 요소가 될 것이므로.. 스코프 설정을 똑띠 하는 PM이 되어보도록 하겠다!

작가의 이전글 실무엔 없던 ‘문제-가설-검증’, 경력기술서엔?
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari