
👋 시작하며
기획자라면 피할 수 없는 순간이 있습니다.
바로, “끝났다고 생각한 기획이 다시 열리는 순간”이죠.
“이거 이번에 같이 넣을 수 있을까요?”
“요청이 하나 더 생겼는데요…”
“이 화면 조금만 바꿀 수 있을까요?”
“이 기능만 살짝 추가되면 딱 좋을 것 같은데…”
디자이너, 개발자, 사업팀, CS팀까지
거의 모든 이해관계자가 돌아가며 "추가 요청"을 해옵니다.
한두 번도 아니고요.
예전에는 이런 요청들이 꽤나 스트레스였습니다.
‘이미 확인한 걸 왜 지금 다시?’
‘현재 타임라인으로도 빠듯한데…’
어떤 말로 대응해야 할지,
무엇까지 수용하고 어디서 선을 그어야 할지 고민스러웠죠.
하지만 지금은 조금 다릅니다.
요청이 들어오면 저는 이렇게 말합니다.
“안 되는 건 없죠.
다만, 시간과 돈이 더 들 뿐입니다.”
이 마인드셋을 가지게 된 이후로,
이런 상황들이 더는 부담스럽지 않습니다.
이 글은,
기획 변경 앞에서 매번 흔들리고 고통받는 기획자분들께
저만의 기준과 대응 방식을 나누고자 작성합니다.
조금이나마 도움이 되기를 바랍니다.

🧩 기획자에게 필요한 건 “거절 기술”이 아니예요
기획 변경, 수정, 추가 요청이 들어올 때
여러분은 어떻게 답하시나요?
제가 가장 자주 하는 말은 이겁니다.
“안 되는 건 없죠. 다만…”
이 말을 꺼낸 뒤에는 네 가지를 빠르게 정리합니다
- 왜 바꾸려는가? (변경 이유)
- 우려되는 점은 없는가? (리스크 요소)
- 기존 테스크들과 비교해 우선순위가 어떻게 되는가? (우선순위)
- 추가적으로 필요한 리소스는 무엇인가? (리소스 조건)
이 네 가지를 함께 확인하고 설명하며
결정을 ‘함께’ 하도록 유도합니다.
요청을 무작정 수용하지도,
무턱대고 거절하지도 않아요.
그 대신 이렇게 말하죠.
“안 되는 건 없죠. 가능합니다.
다만, ○○을 고려해야 해요.
혹시 이걸 바꾸려는 목적이 어떤 건지 알 수 있을까요?
이걸 하려면 △△가 더 들어가고, 일정은 ◇◇ 정도 밀릴 수 있어요.
괜찮으시다면 함께 조율해보면 좋을 것 같아요 :)”
기획자는 ‘되게 하느냐, 안 되게 하느냐’를 판단하는 사람이 아니라고 생각해요.
‘되게 만들기 위한 조건’을 정리하고, 우선순위를 잡는 사람입니다.
저는 그게 기획자의 역할이라고 믿습니다.
세상에 안 되는 일은 거의 없습니다.
기획을 수정하거나 추가하는 것도 마찬가지예요.
중요한 건,
그만큼의 시간과 자원을 들일 만큼 가치 있는 변경인가?
이걸 함께 체크하고 결정하는 것이라고 생각합니다.
1️⃣ “왜 바꾸려 하시나요?”
변경 요청이 들어오면, 저는 가장 먼저 이렇게 묻습니다.
“혹시 이걸 바꾸려는 이유가 뭘까요?”
“변경 목적이 어떻게 되시나요?”
이건 단순한 확인이 아닙니다.
‘무엇을 바꾸고 싶은지’보다
‘왜 바꾸고 싶은지’를 듣는 것이 훨씬 중요하다고 생각하기 때문이에요.
예를 들어,
처음엔 “UI 버튼 위치를 좀 바꿔주세요”였던 요청이
이유를 들어보면 “유저가 이탈한다는 우려 때문”일 수 있고,
“이 기능 꼭 넣어야 해요!”라는 강한 피드백도
들어보면 “내부 팀에서 데이터를 수집하기 어렵다”는 실무상의 어려움 때문일 수 있습니다.
이처럼 변경의 목적을 명확히 하면,
오히려 처음 요청한 방식보다
더 효과적인 해결책을 찾을 수 있는 경우도 많습니다.
그래서 저는 기능이든 화면이든
요청의 형태보다 그 배경과 맥락을 먼저 듣는 편입니다.
이 과정을 거치면,
무작정 추가하거나 수정하지 않고도
더 나은 방식으로 문제를 해결할 수 있는 길이 열리곤 하더라고요 :)
2️⃣ “이 변경으로 생길 수 있는 우려는 없을까요?”
다음으로는, 저는 이렇게 묻습니다.
“혹시 이걸 바꾸면 생길 수 있는 리스크는 없을까요?”
“유저 입장에서 혼란이 생기진 않을까요?”
“이건 기획 방향 자체를 바꾸는 일 같은데, 어떻게 생각하세요?”
기획 변경은 결국 기존 설계를 흔드는 일입니다.
기획자는 단순히 ‘넣을 수 있느냐’를 판단하는 사람이 아니라,
그 변화가 전체 구조에 어떤 연쇄 반응을 일으킬지 먼저 상상해야 하는 사람이라고 생각해요.
예를 들어,
- 조건 하나를 추가하면 전체 플로우가 바뀌거나
- API 호출 방식이나 횟수가 달라지고
- 프론트/백엔드 로직이 엉킬 수 있고
- QA 스펙까지 다시 짜야 하는 경우도 흔하죠
이런 우려를 사전에 짚고 이야기해보면,
요청한 쪽에서도 “이 정도까지 영향이 있을 줄은 몰랐네요”라는 반응이 나올 때가 많습니다.
그래서 저는 ‘안 됩니다’라고 잘라 말하기보다
“가능은 한데, 이런 우려들이 있다”라고 공유하는 편입니다.
이렇게 말하면, 상대방도 자연스럽게
기획이 단순 요청 반영이 아니라, 전체를 고려한 판단이라는 점을 이해하게 되더라고요.
3️⃣ “우선순위가 어떻게 될까요?”
변경 요청을 듣고, 이유와 우려를 확인했다면
그다음엔 반드시 우선순위를 따져볼 차례입니다.
“이걸 이번 릴리즈에 꼭 넣어야 할까요?”
“지금 진행 중인 작업들과 비교하면 우선순위는 어느 정도일까요?”
“지금이 아니더라도, 다음 스프린트에서 다뤄도 괜찮을 것 같아요.”
요청자 입장에서는 언제나 ‘지금’이 가장 중요해 보입니다.
하지만 기획자는 전체 일정과 맥락 속에서 ‘지금’이 맞는지를 판단해야 하는 사람이죠.
지금 반영하는 것이 좋을 수도 있고,
오히려 지금 넣었다가 기존 기능의 안정성이 흔들리거나
다른 핵심 작업들이 지연될 수도 있습니다.
그래서 저는 요청이 들어왔을 때
단순히 “넣는다 / 안 넣는다”를 결정하지 않고,
현재 진행 중인 우선순위들과 비교해서 이야기합니다.
예를 들면
- “지금은 XX 기능 개선이 핵심 목표라 이건 다음 릴리즈에 포함시키는 게 좋을 것 같아요.”
- “긴급한 건은 아니니, 다음 릴리즈로 스케줄 조정해보면 어떨까요?”
- “이걸 우선 진행하려면 기존 테스크 일부를 다음 스프린트로 미뤄야 할 것 같은데, 전체 스프린트 일정을 다시 정리해볼게요.”
이렇게 말하면,
요청도 존중하면서도 전체 일정의 흐름과 전략적 목표를 놓치지 않을 수 있습니다.
‘지금 꼭 해야 하는가?’라는 질문은
단순한 일정 관리가 아니라,
제품 방향성과 리소스 밸런스를 이어주는 중요한 연결점입니다.
4️⃣ “그럼 이걸 하려면, 무엇이 더 필요할까요?”
마지막으로 꼭 짚는 건 리소스 조율입니다.
요청이 아무리 타당하고, 우선순위도 높다고 해도
리소스가 없다면 실행은 불가능하니까요.
예를 들어 이렇게 말하곤 합니다.
- “해당 기능을 이번 릴리즈에 넣으려면, 프론트엔드 일정이 약 1주일 정도 더 필요해요.”
- “디자인 수정 범위가 커서, 이번 주 내 반영은 어려울 수 있을 것 같아요.”
- “이 변경으로 QA 범위도 넓어져서, 별도 테스트 일정이 추가로 필요할 것 같아요.”
- “해당 작업을 추가한다면 이 정도 리소스가 들어가는데, 이 정도 투자가 필요한 가치 있는 일일까요?”
요청에 단순히 "가능합니다"라고 답하는 건 쉽습니다.
솔직히 말하면, 저도 대부분의 요청에 "오케이" 하고 싶어요 😅
하지만 정말 중요한 건,
그 요청을 실제로 가능하게 만들기 위해 어떤 리소스가 필요한지 설명하고,
그 현실적 조건을 조율해가는 것이라고 생각합니다.
리소스를 중심에 두고 대화를 나누면,
기획 변경이 단순히 ‘한 줄 고치면 되는 일’이 아니라는 점도
자연스럽게 전달할 수 있습니다.
무엇보다,
그 변경이 ‘이 정도 리소스를 들일 만큼의 가치가 있는가’를 다시 한번 점검하는 계기가 되기도 하죠.
요청을 실현시키는 데 있어
‘사람’과 ‘시간’ 즉 '돈'은 언제나 가장 중요한 자원입니다.

✅ 마무리하며 – 기획 변경은 피할 수 없지만, 대응은 선택할 수 있다
서비스 기획을 하다 보면
‘한 번 정리한 기획이 다시 열리는 일’은 피할 수 없습니다.
그건 현실이에요 🥲
중요한 건,
그 순간마다 어떻게 반응하고 어떤 기준으로 판단하느냐입니다.
위에서 소개한 네 가지 기준을 함께 점검하며 이야기해보세요.
그러면 기획자는 더 이상 ‘변경 요청을 막는 사람’이 아니라,
“될 수 있게 만드는 조건을 설계하는 사람”이 되지 않을까요?
이 역할을 명확히 할수록
기획자 스스로도 수많은 요청 속에서
흔들리지 않는 기준을 세울 수 있게 될 것이라 믿습니다.
그러니 오늘도 이렇게 말해보는 건 어떨까요?
“안 되는 건 없죠.
다만, 시간과 돈이 더 들 뿐입니다.”
'서비스 기획' 카테고리의 다른 글
| 🗣️ 찝찝함을 설계해서 사용자의 행동 바꾸기: 자이가르닉 효과, UX (0) | 2026.01.31 |
|---|---|
| PM으로 일하며 느낀, 꼭 필요한 역량 5가지 (3) | 2025.05.26 |
| 🧩 PM으로 일하며 실제로 도움이 되었던 우선순위 정하기 기법들 (1) | 2025.05.23 |
| 🔎 기획자는 어떻게 팀의 공통 언어를 만들까? - 흐름과 화면설계서 이야기 (2) | 2025.04.20 |
| 📝 기획자는 어떻게 시작할까 – 새로운 프로덕트를 만드는 기획의 흐름 (5) | 2025.04.17 |