잡소리 정복기

"이거 왜 안 됐어요?" 대신 "어디서 막혔어요?" – 개발자와 기획자가 협업하는 커뮤니케이션은 달라야 한다

문노베 2025. 5. 5.

"이거 왜 안 됐어요?" 대신 "어디서 막혔어요?" – 개발자와 기획자가 협업하는 커뮤니케이션은 달라야 한다

“개발자에게 다시 묻지 않으려고 그만큼 준비했는데도, 왜 ‘이게 안 돼요’라고 말할 수밖에 없었을까?”

 

"이거 왜 안됐어요?" 대신 "어디서 막혔어요?" – 개발자와 기획자가 협업하는 커뮤니케이션은 달라야한다

 

안녕하세요, 문노베입니다.

 

기획자와 개발자의 갈등 중 가장 대표적인 상황은 아마도 "이건 왜 안 되죠?"라고 물어보는 순간일 거예요.

 

실제로 그때마다 개발자들은 고구마를 100개 먹은 듯 한 답답함에, 기획자들 역시 일정의 압박에서 화가 치미는..

 

이 글에서는 그 ‘막히는 순간’에 우리가 놓친 중요한 것들, 그리고 그 해결책에 대해 이야기하려 해요.

 

조금 더 나은 협업을 위해서는 말 그대로 ‘이걸 왜 못 해?’보다는 '어디서 막혔는지'를 찾는 게 더 효과적입니다.

 

이전 글에서 ‘기획자와 개발자의 언어 차이’를 다뤘다면, 이번엔 그 언어를 어떻게 조정하고 변환할지에 대해 깊이 들어가겠습니다.

 

2025.04.23 - [잡소리 정복기] - 개발자가 진짜 듣고 싶은 요구사항 정리법 – 노베이스 문과 기획자의 설명이 닿지 않는 이유

 

개발자가 진짜 듣고 싶은 요구사항 정리법 – 노베이스 문과 기획자의 설명이 닿지 않는 이유

개발자가 진짜 듣고 싶은 요구사항 정리법 – 노베이스 문과 기획자의 설명이 닿지 않는 이유기획서는 다 썼다. 피그마 링크도 보냈다. 그런데 개발자는 “이거 어떤 의도인가요?”라고 다시 묻

nobe-moon.tistory.com

 

‘왜 안 됐나요?’라는 질문의 한계

기획자와 개발자가 겪는 가장 흔한 갈등 중 하나는, 문제가 생겼을 때 기획자가 ‘왜 안 됐나요?’라고 질문하는 순간이에요.

 

그런데 이 질문은 문제 해결의 열쇠가 되지 않죠. 왜냐면 그 질문은 그저 결과만을 묻고 있기 때문입니다.

 

문제가 생겼을 때 우리는 우선 그 문제를 진단하고, 어떤 원인으로 인해 문제가 발생했는지에 집중해야 합니다.

 

결과에만 집중하면, 실질적으로 해결을 위한 첫걸음도 떼지 못하는 거죠.

‘막혔다’는 문제를 이해하는 법

“왜 안 됐어요?”라고 묻는 대신, 우리는 ‘어디에서 막혔는지’를 묻는 것이 중요합니다.

 

이 질문은 문제의 구체적인 위치를 확인하고, 그것을 해결하기 위한 방법을 찾는 첫걸음이죠.

 

다음의 테이블은 이 두 질문이 어떻게 다른지, 그리고 ‘막혔다’는 문제를 어떻게 다르게 접근할 수 있는지 보여줍니다.

‘왜 안 됐나요?’ ‘어디서 막혔나요?’
결과에 대한 질문 원인 분석을 위한 질문
문제를 더 큰 범위에서 봄 세부적인 문제 구체화에 집중
상대방의 답변에 의존하는 질문 자신이 문제를 정의하고 해결책을 찾는 질문

결과를 묻는 것보다 문제의 세부를 짚어내는 것이 더 실질적인 해결을 이끌어냅니다.

 

이 질문이 협업의 시너지를 키우는 중요한 키포인트가 될 수 있어요.

‘어디서 막혔는지’를 찾는 방법

문제를 ‘왜 안 됐는지’가 아니라, ‘어디서 막혔는지’를 찾기 위해서 기획자는 다음과 같은 방법을 활용할 수 있어요:

  • 문제 발생 지점과 그 원인을 구체적으로 기록해 보세요.
  • 각각의 업무 흐름을 시각적으로 그려보며, 어디에서 문제점이 발생했는지 파악해 보세요.
  • 각 단계별로 간단한 질문을 던지며, 문제를 작은 단위로 분리해 보세요.

이러한 방법을 통해, 문제의 근본적인 원인을 파악하고, 그 해결을 위한 단계별 접근을 시작할 수 있습니다.

더 나은 질문을 던지는 커뮤니케이션 전략

문제가 발생했을 때 가장 중요한 건, “정확한 질문”을 던지는 겁니다. 그냥 "왜 안 돼요?"가 아니라, 이런 식으로 물어볼 수 있어요.

  • “해당 API 호출에서 에러가 나는 건가요?”
  • “사용자 조건 A일 때만 안 되는 건가요?”
  • “디자인 상 반영은 됐는데, 동작은 아직 연결 전인가요?”

이런 질문은 문제를 명확하게 만들고, 해결 속도를 높이는 데 엄청난 역할을 해요.

 

개발자의 시간을 아껴주고, 우리도 빠르게 다음 단계로 갈 수 있게 도와주죠.

실제 사례: 문제를 진단하는 대화법

제가 실제로 겪었던 커뮤니케이션 상황입니다.

 

이 대화는 기획자와 개발자 사이의 의사소통 방식이 결과에 어떤 영향을 주는지를 보여줘요.

기존 질문 개선된 질문 효과
"왜 안 나와요?" "지금 로그인 상태에서만 오류가 나는 건가요?" 조건별 이슈로 빠르게 원인 파악 가능
"이거 개발됐어요?" "지금은 API만 연결된 상태인가요, UI까지 완료된 상태인가요?" 개발 범위 명확화, 일정 조율 쉬워짐
"언제 되나요?" "현재 작업 우선순위상 언제쯤 배포 예상하나요?" 일정 조율 및 현실적인 기대치 형성

이처럼 질문의 구조를 조금만 바꾸면, 상대방은 ‘이해받았다’는 감정을 느끼고 훨씬 협조적인 분위기가 형성돼요.

 

협업은 결국 사람이 하는 일이니까요.

다음 단계: 협업을 위한 실천 포인트

지금 당장 적용할 수 있는 커뮤니케이션 전략을 정리해 봤어요.

  • ‘왜 안 됐는지’ 대신 ‘어디서 막혔는지’를 먼저 묻기
  • 질문을 구체적으로 쪼개서 던지기
  • 상대방이 답하기 쉬운 방식으로 질문하기
  • “지금 어디쯤까지 됐나요?”라는 중간 점검 질문 활용
  • 해결책보다는 상황 이해부터 시작하기

질문은 상대방을 공격하는 도구가 아니라, 함께 길을 찾는 나침반이에요. 우리가 만드는 제품도 결국 사람을 위한 거니까요.

문노베의 협업 FAQ – 커뮤니케이션 편

“개발자한테 뭐 물어보면 다 짜증 내는 것 같아요...”

질문 방식이 문제였을 수도 있어요. 추궁이 아니라 협업을 위한 질문이라는 뉘앙스를 전달하는 게 중요해요. '어디서 막혔을까?'라는 질문은 훨씬 부드럽고요.

 

“슬랙으로 그냥 ‘되나요?’만 물어보면 안 되나요?”

'되나요?'는 애매한 질문이에요. 어디까지 됐는지, 어떤 조건에서 안 되는 건지 구체적으로 물어봐야 정확한 대답이 와요. 질문을 분해해 보세요.

 

“QA에서 자꾸 기획 누락이 나요...”

커뮤니케이션이 텍스트 위주로만 이뤄졌다면, 미묘한 맥락이 빠졌을 수 있어요. 중간 점검 회의, 혹은 간단한 피그마 녹화 코멘트도 꽤 도움이 됩니다.

 

“기획자가 기술적인 질문 해도 괜찮을까요?”

너무 당연히 괜찮죠! 다만 정답을 요구하지 말고, “내가 이해한 게 맞을까요?”처럼 대화로 던지면 훨씬 좋은 협업이 됩니다.

 

“정확히 어디까지 확인하고 물어보는 게 좋을까요?”

자신이 확인한 범위를 말해주는 게 가장 좋아요. “여기까지는 확인했는데, 이후 동작이 막혀요”라는 식이면, 개발자도 훨씬 빠르게 대응할 수 있어요.

 

“그래도 결국 답답한 건 못 참겠어요...”

그럴 땐 솔직하게 감정을 표현하되, 책임을 넘기지 않는 말투를 써보세요. “지금 상황이 잘 이해가 안 되어서 그런데, 혹시 한 번만 같이 봐주실 수 있을까요?” 이 한마디가 분위기를 바꿉니다.

 

 

협업은 결국 ‘말’에서 시작해서 ‘사람’으로 끝나는 것 같아요.

 

내가 던지는 질문 하나가 상대를 이해하게도 만들고, 지치게도 하니까요.

 

"이거 왜 안 됐어요?"가 아니라 "어디서 막혔어요?" 이 단어 하나만 바꿔도, 팀 전체의 분위기가 달라지더라고요.

 

저도 아직 완벽하진 않지만, 그걸 아는 만큼 더 좋은 질문을 연습하고 있어요.

 

여러분도 오늘부터, 한 번 질문을 바꿔보지 않으실래요? ‘잘 묻는 기획자’가 결국 가장 실력 있는 기획자일지도 모르니까요.

 

2025.04.17 - [잡소리 정복기] - 왜 기획자는 개발자와 싸우게 되는가? – 노베이스 문과 기획자가 일하는법

 

왜 기획자는 개발자와 싸우게 되는가? – 노베이스 문과 기획자가 일하는법

왜 기획자는 개발자와 싸우게 되는가? – 노베이스 문과 기획자가 일하는법"이거 되게 간단한 거잖아요!"라고 말한 순간, 개발자의 표정이 굳었다. 나는 그게 무슨 뜻인지 그땐 몰랐다. 안녕하세

nobe-moon.tistory.com

 

반응형

댓글