5장. 소통력 있는 개발자가 되는 길
회사에는 두 종류의 개발자가 있다.
말없이 일만 하는 사람
일과 생각을 짧고 명확하게 말할 수 있는 사람
흔히 “개발자는 말이 없어도 된다”는 편견이 있지만,
실제로 프로젝트가 끝까지 잘 가는지 여부는 소통력에서 갈린다.
소통력이 없는 개발자는 오해를 낳고,
소통력이 있는 개발자는 신뢰를 쌓는다.
신입 개발자가 흔히 하는 실수 중 하나는,
자기가 본 것만 보고 말하는 것이다.
예:
잘못된: “API 안 돼요.”
좋은: “API 호출 시 500 에러가 발생하는데, 요청 파라미터 중 userId가 null로 들어가고 있습니다.”
두 번째 말은 단순한 현상 보고가 아니라 맥락 있는 정보 전달이다.
맥락을 담아 말하면, 상대방은 바로 문제를 이해하고 조치할 수 있다.
소통은 화려한 말솜씨가 아니라, 맥락을 얼마나 명확하게 담아 전달하느냐의 문제다.
좋은 소통력은 말 잘하는 게 전부가 아니다.
오히려 신입일수록 더 중요한 건 잘 듣는 것이다.
한 신입이 회의에서 계속 자기 생각을 내세우다가,
정작 기획자가 처음에 말했던 핵심 조건을 놓쳐버린 일이 있었다.
결국 개발이 끝난 뒤 다시 처음부터 고쳐야 했다.
잘 듣는 건 단순히 입 다물고 있는 게 아니다.
이해한 걸 다시 확인하기 (“정리하면 이런 뜻이 맞나요?”)
필요한 부분을 질문하기 (“이 경우에는 예외 처리도 들어가나요?”)
이 두 가지만 습관화해도 신뢰는 금방 쌓인다.
대면 소통만큼이나 중요한 게 메신저다.
신입은 자주 이런 실수를 한다.
“이거 어떻게 해요?” 라고만 보냄 → 상대방은 추가 맥락을 물어봐야 해서 귀찮아진다.
긴급하지 않은데 @all 태그를 남발 → 동료들의 집중을 깨버린다.
반대로, 소통력이 있는 신입은 이렇게 한다.
“대출 신청 API 호출 시 userId가 null로 들어옵니다. 혹시 이 값이 언제 세팅되는지 알려주실 수 있을까요?”
“이슈가 긴급하진 않지만 오늘 중에 확인 부탁드립니다.”
같은 질문이어도 표현 방식 하나로 상대방의 피로도가 달라진다.
개발자끼리는 코드 한 줄이면 대화가 된다.
“여기서 NPE 터졌어.”
“DAO 쿼리 조건 바꿔야 돼.”
이 정도만 말해도 바로 이해한다.
하지만 기획자, 마케터, 운영팀과는 다르다.
그들에게는 NPE, 쿼리 같은 단어는 낯선 암호에 불과하다.
이럴 때 개발자가 그대로 기술 용어를 던지면,
상대방은 오히려 더 불안해진다.
예를 들어 장애 상황을 보고한다고 해보자.
나쁜 보고: “NullPointerException이 발생해서 서버가 죽었습니다.”
좋은 보고: “현재 로그인 기능이 정상 동작하지 않아 고객이 접속할 수 없습니다. 원인을 확인 중이며 10분 안에 조치 예정입니다.”
같은 사실이지만, 사용자가 어떤 영향을 받는지를 먼저 말해야 한다.
상대방은 코드의 문제가 아니라 “서비스가 어떻게 보이는지”가 더 중요하기 때문이다.
비개발자와 대화할 때는 이렇게 생각해보자.
“이 말로 상대방이 바로 결정을 내릴 수 있을까?”
결정할 수 있다면 충분히 잘 전달한 것이다.
“내가 지금 말하는 걸, 부모님이나 친구도 이해할 수 있을까?”
그 정도로 풀어서 말하면 된다.
기술력은 시간이 지나면 누구나 쌓인다.
하지만 소통력은 커리어의 차이를 만든다.
소통력이 부족한 개발자 → “코드만 잘 짜는 사람”
소통력이 있는 개발자 → “팀을 이끄는 사람, 신뢰를 주는 사람”
신입 때부터 소통의 습관을 들여 놓으면,
10년 후에는 단순한 개발자가 아니라 동료들이 따르는 리더로 성장할 수 있다.
개발자의 언어는 코드지만,
개발자의 커리어를 키우는 언어는 소통이다.
맥락을 담아 말하고, 잘 듣고, 메신저에서도 배려하는 습관.
이것들이 쌓이면, 당신은 어느새
“말이 통하는 개발자”, “함께 일하고 싶은 개발자”로 불리게 된다.