"내가 쓴 기술 문서는 동료 개발자가 이해하는데, PM은 왜 못 알아들을까요?" 주니어 개발자분들에게 가장 자주 듣는 고민 중 하나예요. 코드 실력은 빠르게 느는데, PM·디자이너·운영팀과의 협업은 여전히 벽처럼 느껴지는 순간이 있죠.
커뮤니케이션은 성격 문제가 아니에요. 연습 가능한 스킬이에요. 이번 글에서는 비개발자와 일할 때 바로 써먹을 수 있는 5가지 상황별 기법을 정리해봤어요. 오늘 오후 스탠드업부터 적용해볼 수 있는 실전 템플릿 중심이에요.
왜 개발자-비개발자 소통이 특히 어려울까요?
이유는 단순해요. 서로 다른 축을 보고 있거든요. 개발자는 기술적 복잡도·유지보수성에 민감한데, 비개발자는 비용·일정·사용자 경험에 관심이 더 크죠. Nick Morgan이 잘 지적했어요 — "Your CFO will care about something other than what makes the tech choice superior; they care about its costs."[2]
게다가 우리가 쓰는 기술 용어 자체가 비개발자에게는 진입 장벽이에요[1]. 개발자는 "기능"에 흥분하고, 비개발자는 그 기능이 자기에게 주는 혜택에 반응해요[1]. 이 간극을 메워주는 게 바로 커뮤니케이션이에요.
상황별 커뮤니케이션 기법 5가지
1. 요구사항을 받을 때 — "제가 이해한 게 맞나요?" paraphrase
구두로 받은 요구사항은 항상 모호해요. 그대로 구현하면 스프린트 끝날 때쯤 "이거 말고 저거였는데요"가 나오죠.
해결책은 paraphrasing이에요. 들은 내용을 내 말로 다시 정리해 확인하는 기법이에요. 핵심은 정확한 반복이 아니라 의미 전달이에요 — "Paraphrasing is simply repeating what the speaker said in your own words. It can clarify misunderstandings and misconceptions."[3]
바로 쓸 수 있는 템플릿:
"제가 이해한 요구사항은 X이고, 우선순위는 Y예요. 혹시 Z 같은 예외 케이스가 발생하면 어떻게 처리할까요?"
여기서 중요한 건 엣지 케이스 한두 개를 역질문하는 거예요. 요구사항의 구멍이 바로 드러나거든요.
2. 기술 제약을 설명할 때 — "비용 + 대안 + 추천" 3단 구조
"기술적으로 불가능해요"는 협력 관계를 깨뜨리는 말이에요. 비개발자 입장에선 "왜 안 되는지"도 모르고 "뭘 할 수 있는지"도 모른 채 그냥 거절당한 거예요.
더 나은 답변은 비용 → 대안 → 추천 3단 구조예요[2].
예시:
"이 방식은 구현에 2주가 필요해요. 대안이 두 개 있는데요. A는 3일, B는 5일이 걸려요. 저는 B를 추천해요. 나중에 확장할 때 코드 변경이 적거든요."
이렇게 말하면 비개발자도 판단할 수 있어요. 기술이 아니라 트레이드오프로 이야기하는 거죠.
3. 진행 상황을 공유할 때 — 상태 + blocker + 다음 단계
"열심히 하고 있어요"는 정보가 아니에요. QAT Global 가이드도 콕 짚어요 — "Commit to regular status updates even if there's no major progress."[1]
추천 템플릿 (슬랙 스탠드업 용):
🟢/🟡/🔴 상태: 녹색(순조) / 노랑(약간 지연) / 빨강(블로커 있음)
Blocker: 지금 막힌 것 (없으면 "없음")
다음 단계: 오늘/내일 할 것
상태 색(RAG) 표기는 많은 제품팀에서 쓰는 관례예요. 한 줄만 봐도 지원이 필요한지 바로 판단돼서 PM이 좋아해요.
4. 버그나 장애를 보고할 때 — "영향 먼저, 원인 나중"
기술 디테일부터 말하면 비개발자는 패닉해요. incident.io의 장애 커뮤니케이션 가이드는 명확해요 — 외부 템플릿은 impact를 맨 앞에 둬요.[4] 기술적 내부 사항보다 "누가, 어떤 피해를 입었는지"가 먼저라는 뜻이에요.
추천 순서:
사실(What): 어떤 기능에서 무슨 일이 일어났는지
영향(Impact): 몇 명/어느 기능에 영향, 얼마나 심각
원인(Why): 파악된 원인 (미파악이면 "조사 중"이라고 명시)
대응(Next): 지금 하고 있는 일과 예상 복구 시점
그리고 한 가지 더 — 침묵하지 마세요. incident.io의 "heartbeat 룰"은 이래요: "Update every 30 minutes for SEV1 incidents, even if the update is 'We're still investigating.'"[4] 정보가 없더라도 "아직 조사 중입니다"라는 업데이트 자체가 stakeholder를 안심시켜요.
5. 기술 문서를 쓸 때 — 첫 줄에 독자 명시
하나의 문서로 모든 독자를 만족시키려 하면 아무도 못 읽어요. Diátaxis 프레임워크는 문서를 독자의 목적에 따라 네 가지로 나누라고 권해요 — 학습(tutorial), 문제 해결(how-to), 조회(reference), 이해(explanation). "Each content type serves a different user need and has a distinct purpose."[5]
완벽히 분리할 수 없어도, 문서 첫 줄에 누구를 위한 문서인지는 꼭 적어주세요.
예시:
이 문서는 PM이 기능 범위를 이해하기 위한 것입니다. 구현 디테일은
README.md를 참고해주세요.
이 한 줄만으로 문서의 기대 수준이 정리돼요.
협업 체크리스트
내일 아침부터 바로 쓸 수 있는 다섯 가지예요.
[ ] 요구사항을 받으면 paraphrase 한 번
[ ] 기술 제약 설명 시 대안 최소 1개 제시
[ ] 진행 상황 공유 시 상태 색 + blocker 명시
[ ] 장애 보고는 영향 먼저, 원인 나중
[ ] 문서 첫 줄에 독자 명시
마무리
커뮤니케이션은 리팩터링과 비슷해요. 한 번에 완벽해지지 않지만, 반복하며 점점 나아지는 스킬이에요. 오늘 스탠드업에서 한 가지만 골라 시도해보세요. 작은 습관이 3개월 뒤면 "비개발자와 잘 일하는 개발자"라는 평판으로 돌아올 거예요.
그리고 이런 협업 경험은 이력서에 쓸 가장 강력한 소재예요. 매일의 협업 순간을 트리업의 경험 관리에 간단히 기록해두면, 나중에 면접 때 STAR 방식으로 꺼내 쓸 수 있는 든든한 자산이 돼요.
작은 노력들이 모여 큰 성장을 만들어요. 꾸준히 연습해보세요!
