기획자가 개발자와 좋은 관계를 유지하는 법
“이게 왜 이렇게 오래 걸려요?”라는 말이 불러오는 전쟁
프로젝트 초반, 저는 개발자 분들께 이런 말을 한 적 있습니다.
“이거 기능 하나만 추가하면 되잖아요?”
“이 버튼이 왜 이렇게 오래 걸리는 거죠?”
“이 정도는 바로 되는 줄 알았어요…”
그때 개발자의 표정이 말했죠.
“아, 오늘도 한 명 잃었다.”
그 이후로 저는 마음을 고쳐먹었습니다.
개발자와 잘 지내는 건 ‘센스’가 아니라 ‘스킬’입니다.
그리고 이 스킬은 일을 더 빨리, 더 정확하게, 덜 피곤하게 만들어줍니다.
왜 기획자와 개발자는 자주 충돌할까?
1. 단어는 같지만, 의미가 다릅니다
기획자가 말하는 “기능 하나” = 버튼 추가
개발자가 듣는 “기능 하나” = 화면 추가 + API 호출 + DB 수정 + 테스트 + 배포까지의 연쇄작업
2. 업무 시간의 흐름이 다릅니다
기획자는 계획 기반
개발자는 실행 기반
기획자는 “이번 달 말까지 이걸 해주세요” 하고 말하지만,
개발자는 “이번 달에 개발하려면 10일까지 기획이 나왔어야…” 하고 생각합니다.
3. 둘 다 ‘자기 일’에 자부심이 있습니다
기획자는 “생각한 대로 안 나오면” 답답하고,
개발자는 “알지도 못하면서 지시하듯 말하면” 서운합니다.
즉, 둘 다 틀린 게 아니라 체질이 다른 존재들인 거예요.
기획자가 하면 개발자가 좋아하는 말 TOP 5
1. “이거 구현 난이도 어느 정도일까요?” 의견을 묻는 기획자 = 존중하는 사람
2. “이건 나중에 넣어도 괜찮아요.” 우선순위 조정 가능 = 시간 배려하는 사람
3. “기획은 이렇게 생각했는데, 기술적으로 어려우면 말해주세요.” 협업할 준비된 사람
4. “이거 구현하면서 불편한 거 있었나요?” 나만 고생한 게 아니라는 이해
5. “덕분에 빠르게 끝났어요. 고맙습니다.” 공감과 감사는 매번 새롭고, 정말 효과 큼
반대로, 개발자가 싫어하는 말 TOP 5
1. “그냥 빨리 되게 해 주세요.” 그냥 빨리 = 아무 생각 없음으로 해석됨
2. “이게 왜 안 돼요?” “그걸 기획자가 알아야지”라는 눈빛 소환
3. “이거 금방 될 것 같은데요?” 근거 없는 시간 추측 = 위험한 스포츠
4. “그냥 디자인대로 만들어주세요.” 디자인이 기획을 대신할 수는 없음
5. “그냥 이건 기존 API 쓰면 되죠?” 정확히 모르면서 단정해버리는 말 = 협업 부담을 주는 말
기획자가 협업할 때 신경 쓰면 좋은 습관
기획서에 ‘기술 검토 필요’ 문구 넣기 : 일방 통보 아님을 보여줌
기획 의도를 말할 때, 사용자 입장에서 설명하기 : “왜 이게 필요했는지”를 알면 개발자도 덜 억울함
미리 일정을 공유하고, 개발 여유 시간을 고려하기. 특히 변경사항은 ‘사전에’ 공유하는 게 핵심
테스트 후 고마움을 표현 : 별거 아닌데 정말 효과 큼
개발자는 조용한데 민감한 타입들이 많음
(불만은 쌓이면 폭발식임)
개발자와의 관계, 결국 사람이 만든다
“기획자가 기술을 완벽히 알길 바라진 않아요.
다만, 우리가 뭘 왜 고민하는지 알아주면 좋겠어요.”
이 말에 저도 깊이 공감합니다.
기획자는 모든 기술을 이해할 수는 없지만,
개발자가 ‘어디서 고민하고 있는지’를 이해하려는 태도는 가질 수 있어요.
그리고 사실은 이런 말보다 더 중요한 게 하나 있죠.
같이 밥 한 번 먹은 기획자냐, 아닌가.
아는 사람의 기획은 더 집중해서 보고,
요청이 빡세도 “그래도 그 사람이니까” 하며 신경 써주는 경우도 분명 있습니다.
결국 협업은 관계 위에 쌓이는 거고,
좋은 관계는 ‘좋은 기획서’보다 더 큰 힘을 발휘할 때도 있습니다.
마무리하며
기획자와 개발자의 갈등은,
일이 아니라 ‘일하는 방식’과 ‘관계’에서 시작됩니다.
좋은 기능보다, 좋은 팀워크가 더 멀리 갑니다.
개발자는 기획자를 기억합니다.
함께 고민해 준 기획자
먼저 의견을 물어본 기획자
고생에 공감해 준 기획자
그리고 다음 프로젝트에서,
그 기획자의 요청은 더 빠르고, 더 정확하게, 더 즐겁게 진행됩니다.
