실제 사례로 이해하는 효과적인 개발자 커뮤니케이션 방법 3가지

📌 글 작성

기술 토론을 좋아하는 F-Lab 백엔드 멘토 Thomas
개발 초기 설계부터 운영 런칭까지 다양한 경험이 있는 아키텍트이자 엔지니어 in 🇨🇦

개발자는 비즈니스의 문제를 기술로 해결하는 엔지니어들입니다. 이 과정에서 우리는 생각보다 커뮤니케이션이 많이 중요하다는 걸 깨닫게 됩니다.

정말로요. 흔히들 개발자는 하루 종일 코딩만 할 것이라고 생각합니다만, 실제로 조직에서 중요한 위치에 오르게 될수록, 프로젝트를 리딩하는 등 중요한 역할을 맡게 될수록 커뮤니케이션의 중요성은 커지게 됩니다. 대다수의 개발 프로젝트는 협업 중심이고, 그래서 많은 기업들은 소통 능력을 개발자의 중요한 재능으로 평가합니다.

그렇다면 어떻게 하면 효과적으로 커뮤니케이션을 할 수 있을까요? 이번 포스팅에서는 필자가 생각하는 효과적으로 커뮤니케이션할 수 있는 몇 가지 방법들을 공유합니다.

1. 알맞은 용어 사용 정의하기

혹시 의사소통이 안된다는 생각이 든다면, 가장 먼저 용어 사용을 어떻게 정의하는지를 점검해 볼 필요가 있습니다.

뛰어난 개발자들은 종종 자신의 기술적인 스펙트럼을 과시하며 전문 용어를 의사소통에 사용하는 경우들이 있습니다. 솔직히 말해서, 개발자들은 이러한 대화를 좋아합니다. 이러한 대화는 엔지니어 사이에서 굉장히 효과적인 대화 방식입니다. 당연히 비기술자 들과 대화할 때는 좋은 방법은 아닙니다. 용어는 상대방이 이해할 수 있는 평이한 수준의 용어부터 설명을 하는 것이 중요합니다. 그리고 이를 위해서는 해당 내용을 기술적으로 먼저 충분히 이해할 필요가 있습니다. 충분한 지식이 수반되어야 이를 쉽게 설명할 수 있기 때문이죠.

그리고 어떤 용어를 사용할 때에는 해당 용어가 가질 수 있는 여러 의미를 같이 고려하는 습관이 중요합니다. 종종 해당 용어가 너무 평이해서 다양하게 해석될 수 있는 것들이 있습니다. 대표적으로 배치 작업, 캐싱과 같은 용어들은 IT 전반에 너무나도 많이 사용되는 용어들입니다. 상황에 따라 헷갈릴 수 있다면, 언급할 때마다 이를 정의하거나 다른 용어로 대체해서 말할 필요가 있습니다. 용어를 잘못 정의해서 회의가 산으로 가거나 오해를 정정하기 위한 회의를 다시 잡아야 할 수도 있습니다.

용어 사용은 상대방의 기준에 맞추고, 헷갈릴만한 용어가 있다면 미리 정의를 하고 시작하는 것은 커뮤니케이션에 생각보다 큰 효과를 가져다줄 수 있습니다.

2. 모호한 문제 정의하기

개발자가 가장 많이 만나게 되는 커뮤니케이션 상황은 모호한 현실의 문제를 정의하는 상황입니다. 특히 기획자 등 창의성이 중요한 직업의 동료들과 일할 때는 더 그렇죠. 서로 다른 생각을 받아서 기술적으로 풀 수 있는 문제로 만들어야 합니다. 이때 가장 중요한 것은 질문입니다. 개발자들 중에는 질문을 부끄럽게 여기는 경우들이 많이 있습니다. 자신이 더 실력이 있었으면 질문하지 않아도 됐을 것이라는 생각이죠. 하지만 문제가 모호할 때에는 최대한 질문해야 합니다. 다음 예시를 상상해 봅시다.

기획자: 버튼을 클릭하면 쇼핑몰 화면에 추천 상품 목록이 나왔으면 좋겠어요.

개발자: 그거 정말 멋지겠네요! 당장 시작하죠.

위와 같은 커뮤니케이션은 좋은 인간관계를 만드는 방법이지만, 기획자가 생각하는 모습과 개발자가 생각하는 모습은 다를 수밖에 없습니다. 이럴 때는 기술적으로, 때로는 기획적으로도 몇 가지를 생각해서 되물어봐야 합니다.

개발자: 추천은 얼마 만에 완료되어야 하나요? 추천 상품 목록은 어떤 기준으로 정렬되어야 하나요? 얼마나 자주 추천 목록이 갱신되어야 하나요?

실제 문제는 좀 더 복잡해집니다. 만약 필요한 기술 여력이 충분하지 않은 경우 이에 대한 거절이 필요할 수도 있습니다. 위에서 정의한 답변과 현재 환경에 따라 문제를 좀 더 명확하게 정의해 보겠습니다.

• 버튼 클릭과 동시에 추천 상품 목록이 반환되어야 하며 목록은 알파벳 순서로 정렬. 추천 상품 목록의 갱신은 실시간일 필요가 없음

의도가 좀 더 명확해지면, 아키텍처는 보다 명확해집니다. 예시일 뿐이지만, 위의 상황에서 개발자는 추천 시스템을 매번 호출하는 대신 데이터베이스에 저장해놓고 이를 이용해도 되는 옵션이 생기게 됩니다.

즉각적인 답변을 주거나 바로 기능 구현을 시작하는 대신 먼저 문제를 충분히 풀 수 있는 형태로 정의합니다. 당장 이러한 커뮤니케이션으로 인해 프로젝트가 지연되더라도, 가장 중요한 결과를 얻기 위해서는 충분히 문제를 정의해야 합니다.

3. 의사결정에 기여하기

개발자로서 팀에 기여하는 중요한 역량은 의사결정 과정에 영향을 미치는 일입니다. 특히 수평적인 개발 문화에서 개발자의 이러한 역량은 프로젝트의 방향 설정에 큰 영향을 미칠 수도 있습니다. 이때 중요한 것은 개발자가 풀 수 있는 문제와 가치에 대해 집중하는 점입니다. 위의 예시를 조금 바꾸어봅니다.

기획자: 버튼을 클릭하면 쇼핑몰 화면에 추천 상품 목록이 나왔으면 좋겠어요.

개발자: 추천은 얼마 만에 완료되어야 하나요? 추천 상품 목록은 어떤 기준으로 정렬되어야 하나요? 얼마나 자주 추천 목록이 갱신되어야 하나요?

기획자: 버튼 클릭과 동시에 추천 상품 목록이 반환되어야 하며 목록은 추천도 순으로 정렬되어야 해요. 사용자의 행동 패턴을 분석해서 추천 상품 목록이 자동으로 변경되었으면 좋겠어요.

개발자: 추천 시스템은 현재 구조에서 매번 호출될 수 없어요. 이 기능 구현은 불가능합니다.

위와 같은 상황은 개발자로 일하게 되면 꽤나 자주 마주하게 됩니다. 상호 간에 이해 정도가 다르기 때문에 발생하는 문제이죠. 위와 같은 대화는 개발자로서 문제를 명확히 정의하고 올바른 답변을 했으나, 비즈니스 관점에서는 아무런 이점을 주지 못합니다. 대신 다음과 같이 말할 수 있을 겁니다.

개발자: 추천 시스템은 현재 구조에서 매 요청마다 호출될 수는 없지만, 갱신이 즉각적일 필요가 없다면 우리는 저장해놓고 이를 사용할 수 있어요. 기획을 조금 바꾼다면 시간 내에 충분히 개발이 가능합니다.

동일한 내용이지만, 위의 커뮤니케이션은 현실적인 대안을 함께 제시합니다. 사소한 차이이지만, 앞선 의사소통이 문제 해결에 대한 단절을 유발한다면, 뒤의 예시는 해답을 제시합니다. 필자는 개발자로 근무하면서 이러한 사소한 의사소통 방식의 문제가 쌓여서 프로젝트 단위의 소통 단절로 이어지는 경우를 많이 봐왔습니다.

결국 커뮤니케이션이란 상대방을 위한 의사소통이며, 상대방의 관점에서 기술적으로 기여할 수 있는바를 찾는 것이 개발자의 역할입니다.

이번 포스팅에서는 개발자에게 중요한 여러 스킬 중 의사소통 역량에 대해 알아봤습니다. 의사소통에 왕도는 없다고 생각하지만, 혹시 어려움을 겪고 계실 과거의 필자와 같은 상황에 있으신 개발자들에게 도움이 되었으면 하는 바람입니다.