나도 주니어 시절에는 정말 많이 까였거든. 열심히 준비한 기획서를 들고 개발팀 자리로 갈 때마다 심장이 터질 것 같았고, "이거 왜 해야 해요?"라는 질문 하나에 머릿속이 하얘지곤 했어. 그때는 그 거절이 마치 나라는 사람에 대한 부정처럼 느껴져서 퇴근길에 속상해서 눈물을 훔치기도 했지.
"이거 왜 해요?"라는 질문에 숨이 턱 막혔던 순간
기획자 2년 차쯤 되었을 때였나, 나름대로 완벽하다고 생각한 신규 기능 기획서를 들고 개발자분들을 찾아갔어. 그런데 한 시니어 개발자분이 기획서를 슥 보더니 "이거 왜 해야 하죠? 유저 데이터는 확인해 보셨어요?"라고 묻더라고. 그 순간 아무 말도 하지 못했어. 그냥 위에서 시켜서, 혹은 경쟁사에 있으니까 해야 한다고 생각했거든. 기획의 '본질'인 '왜(Why)'를 빼놓고 '어떻게(How)'만 가득 채워갔던 거야. 내 기획의 빈틈을 들킨 것 같아 너무 부끄럽고 쥐구멍에라도 숨고 싶었어. 이후로는 기획서 첫 페이지에 반드시 '이 기능을 만드는 이유'와 '기대 효과'를 유저 데이터와 함께 적기 시작했어. 개발자를 설득하기 전에 나 스스로를 먼저 설득하는 과정을 거친 거지.
"구현 불가능해요"를 "대안을 찾아봅시다"로 바꾸는 법
시간이 흘러 어느덧 7년차 기획자가 되고 나니 깨닫게 된 게 있어. 개발자가 말하는 "이건 안 돼요"라는 말은 정말 기술적으로 불가능하다는 뜻이 아니더라고. "주어진 일정 내에, 현재의 시스템 구조로는 리스크가 너무 크다"는 뜻에 가까워. 예전에는 "안 된다"는 말을 들으면 바로 좌절하고 억울해했는데, 이제는 질문을 바꿨어.
- "어떤 부분에서 리스크가 가장 큰가요?"
- "이 기능을 구현하기 위해 백엔드에서 어떤 데이터가 더 필요한가요?"
- "그럼 1단계로 이 부분만 먼저 배포하고, 나머지는 다음 스프린트에 진행하면 어떨까요?" 이렇게 한 발짝 물러서서 개발자의 제약 사항을 먼저 들어주고 타협점을 찾으려고 하니, 개발자분들도 방어적인 태도를 풀고 "그럼 이렇게 우회해서 구현해 볼까요?"라며 적극적으로 대안을 제시해 주더라고.
결국 협업도 사람과 사람이 하는 일이니까
기획자와 개발자는 대립하는 관계가 아니라, 같은 목적지를 향해 달리는 파트너잖아. 나는 기획을 시작하기 전, 아주 초기 단계부터 개발자분들께 아이디어를 가볍게 공유하곤 해. "이런 문제를 해결하고 싶은데, 기술적으로 가볍게 구현할 수 있는 방법이 있을까요?" 하고 미리 커피 한 잔 마시며 슬쩍 던져보는 거지. 이렇게 사전에 공감대를 형성해 두면, 나중에 정식 기획서를 리뷰할 때 "까이는" 일이 눈에 띄게 줄어들어. 오히려 본인들이 낸 아이디어가 반영되어 있어서 더 신나서 개발해 주시더라고. 이 과정을 통해 협업의 즐거움을 알게 되었고, 일하는 매 순간이 든든하고 짜릿해졌어.
💬 예진의 한마디 개발자의 "안 된다"는 말은 너의 기획을 공격하는 게 아니라, 서비스를 더 안정적으로 만들기 위한 방어벽을 세우는 과정이야. 그것을 너에 대한 거절로 받아들이지 마. 지금 많이 깨지고 부딪히고 있다면, 그건 네가 좋은 기획자로 성장하고 있다는 가장 확실한 증거야. 기죽지 말고 다음번엔 개발자 옆자리에 따뜻한 음료수 하나 들고 가서 가볍게 물어봐 봐. 너는 충분히 잘해낼 수 있어. 내가 늘 응원할게.