개발자의 커뮤니케이션 스타일 이해하기
개발자의 소통방식
개발자와의 효과적인 커뮤니케이션을 위해서는 그들만의 독특한 소통 방식을 이해할 필요가 있다. 잠깐 만나서 요점만 전달하면 될 일을 굳이 메일로 요청한다거나, 간단한 yes/no 대신 여러 조건과 가정을 붙여 답하는 모습은 기획자 입장에서 종종 답답하게 느껴진다. 하지만 이러한 소통 방식에는 그들만의 분명한 이유가 있다. 개발자들의 커뮤니케이션 특성을 이해하고 이에 맞춰 소통한다면, 더 효율적인 협업이 가능할 것이다.
개발자들은 직설적인 의사소통을 선호한다. 한국어는 문장 끝에 가서야 의미가 명확해지는 특성이 있지만, 개발자에게는 이런 방식이 비효율적으로 느껴진다. 그들에게 중요한 것은 “되는가, 안 되는가”의 여부다.
“저희가 이번에 새로운 기능을 기획하게 되었는데요, 사용자들의 니즈도 있고 경영진의 요청도 있어서 이번 달 안에 출시했으면 하는데, 가능할까요?“라는 질문보다는 “이번 달 말까지 새로운 기능 개발이 가능한가요?“라고 요점 중심으로 물어보는 것이 더 효과적이다.
특히 일정 협의 시에는 더욱 그렇다. 촉박한 일정을 전달할 때 여러 이유를 설명하기보다는, “이번 프로젝트는 저희 일정이 3주뿐입니다. 혹시 개발팀에서 이 일정 안에 소화가 가능한가요?“라고 명확히 묻는 것이 좋다. 다만 상황 설명과 향후 개선 방안을 덧붙이는 것은 관계 유지를 위해 필요하다. 압박하는 느낌으로 소통하면 누구나 기분이 안 좋을 수 있다. 담백하게 팩트를 전달하는것에 집중하고 압박하듯 이야기하는것은 지양할 필요가 있다. 일정이 부족한것이 기획팀 잘못이 아니라면 개발팀이 3주안에 해낼 수 없다고 해도 이는 개발팀의 잘못은 아닐 가능성이 높으니 비판하는 자세는 최대한 배제할 필요가 있다.
개발자가 질문한 답변에 대답을 할때도 마찬가지다. 작업에 필요한 사항들이 적절한 시점에 준비되지 않아 언제 이것들이 완성되느냐는 개발자의 질문에 지연된 이유보다는 언제 전달받을 수 있는지가 더 의미가 있다. “디자이너분이 이번주 개인사정으로 연차를쓰셔서 조금 더 걸릴 것 같아요.” 보다는 “이미지 리소스는 3일 더 지연될 예정이니 이부분 비워두고 다른작업부터 진행 부탁드립니다. 완료되면 따로 말씀드리고 전달드리겠습니다.”라는 식의 명확한 의사소통이 그들이 바라는 답변 방식일 것이라고 생각한다.
개발자들은 감정이나 직관보다 논리와 데이터에 기반한 대화를 선호한다. “이 정도면 될 것 같아요”라는 애매한 표현보다는 구체적인 판단 근거나 기준을 제시하는 것이 효과적이다.
예를 들어, “닉네임은 적당히 10글자 정도면 될 것 같아요”라고 하기보다는 “경쟁사 세 곳을 조사해본 결과, 닉네임은 8글자를 넘는 사례가 없었고, UI 상 8글자 이상이면 레이아웃이 깨질 수 있어 최대 8글자로 제한하고자 합니다”라고 설명하는 것이 더 설득력 있다.
또 다른 예로, “로딩이 너무 느린 것 같아요”라고 하기보다는 “경쟁 서비스는 평균 2초 내로 로딩되는데, 우리 서비스는 평균 5초가 걸립니다. 이 영향으로 경쟁사보다 이탈률이 20% 높습니다.”라고 구체적인 데이터를 제시하는 것이 문제 해결에 더 도움이 된다. 이렇게 이야기한다면 막연히 로딩속도를 줄이는것이 아닌 구체적인 목표를 설정할 수 있으며, 경쟁서비스와 우리 서비스의 동작방식 차이를 비교하는 출발점도 설정할 수 있다.
구체적인 소통 방식을 들여다보면, 사람에 따라 기호가 있을 수 있지만 보통 개발자들은 비동기적인 의사소통 수단인 이메일이나 메신저를 사용한 것을 좋아한다. 개발자들이 이메일이나 메신저를 선호하는 데는 분명한 이유가 있다. 개발 작업은 높은 집중도를 요구하며, 작업중인 내용은 한번 흐름이 끊기면 다시 집중하기까지 상당한 시간이 필요하다. 따라서 지금 집중하던 일을 마무리한 뒤 확인 할 수 있는 비동기적 방식이 전체 업무시간을 조절하는데 효과적이다.
효과적인 비동기 소통을 위해 아래 사항들을 참고하면 좋다.
• 이메일로 상세 내용을 먼저 전달하고, 메신저로 간단히 확인 요청
• 급한 정도에 따라 응답 기한을 명시
• 하나의 메일에는 하나의 주제만 담기
• 첨부파일이나 참고자료는 깔끔하게 정리해서 제공
다만 긴급한 상황(서비스 장애, 당일 배포 이슈 등)에서는 즉각적인 대면 소통이 필요할 수 있다. 이런 예외 상황을 미리 정의해두면 좋다.
대면 미팅이나 전화통화가 효율적인 시점도 분명 존재한다. 짧은시간 같은 주제로 논의해서 밀도높은 협의를 할 수 있고 이를 통해 서로 오해하는 부분을 최소화 할 수 있다. 따라서 무조건 메일/메신저로만 소통하는것이 답인것은 아니다. 다만 매번 무슨 일이 있을때마다 전화를 하거나 쪼르르 오는 기획자를 선호하지 않을 것 같다는 예상이다.
추가로, 기획자가 기술 용어를 정확히 사용하면 소통이 훨씬 수월해진다. 예를 들어 “팝업”이라고 할 때, 모달(Modal)인지 토스트(Toast) 메시지인지 명확히 구분하면 오해의 소지가 줄어든다.
기획자가 알아두면 좋을 기본 용어에는 이런것들이 있다. 이는 3장에서 상세히 더 알아볼 예정이다.
• 프론트엔드/백엔드
• API
• 캐시(Cache)
• 데이터베이스(DB)
• 서버/클라이언트
• 배포(Deploy)
단, 부적절한 기술용어 사용은 오히려 의사소통을 방해할 수 있다. 정확히 이해하고 있는 용어만 사용하는 것이 좋다. 기획자가 모든 기술용어를 알고있는것은 좋지만 모르는 것도 이상한 것은 아니다. 따라서 어떤 용어가 적절한지 물어보고 즉시 사용하면서 커뮤니케이션 비용을 줄이고 협업에 대한 의지를 보여주는 것도 필요하다.
이러한 개발자들의 커뮤니케이션 특성을 이해하고 적절히 활용한다면, 더 효율적이고 생산적인 협업이 가능할 것이다. 특히 문서화된 소통, 논리적인 근거 제시, 명확한 용어 사용은 개발자들의 신뢰를 얻는 중요한 요소가 된다. 그들의 방식이 더 나은 방식이라서가 아니라 우리가 소통하고자 하는 사람들과 더 잘 소통하기 위해 이런 특성을 학습할 필요가 있다.
