개발자의 커뮤니케이션 1
다양한 관점으로 바라보기
개발자로 약 10여 년을 일하면서 여러 회사에서 많은 환경들을 겪어왔다.
무슨 회의를 이렇게나 많이 할까 싶을 정도로 회의를 좋아하는 집단. 매일 기획자와 실랑이를 벌이는 집단.
정리되지 않은 요구사항을 메신저로 중구난방 식으로 요청하는 집단. 업무시간에 집중하지 않고 매일 야근을 필수적으로 하는 집단. 회사마다, 팀마다 각자 일하는 방식이 가지각색이었다.
여러 회사를 다니며 일하는 방식은 달랐지만, 공통적으로 힘들었던 건 커뮤니케이션이었다.
물론 모든 개발자가 그런 건 아니지만, 내가 만난 개발자들은 대체로 체계적이고 논리적이며 합리적인 상황을 선호했다. 예를 들어, 기획자가 어떤 기능이 필요하다는 요구사항을 구상해 온 기획안을 보며 '저건 우리 시스템에 전혀 맞지 않는 기능인데..', '저 기능 들어가면 성능 이슈 분명 생기는데..'등의 생각들을 하며 불안한 상황들을 자꾸 생각하게 된다. 사실 당연한 일이다. 기능 하나 잘못 만들면 전체 시스템에 영향을 줄 수 있고, 심하면 회사에 큰 손해를 입힐 수도 있기 때문이다. 그러다 보니 기획자와 개발자는 항상 의견 충돌이 잦을 수밖에 없다. 기획자의 입장에서는 이 기능과 UI는 우리 시스템을 위해 꼭 있어야 하는 기능이지만, 개발자 입장에서는 정말 저 기획이 최선인가에 대한 의문이 들곤 한다. 또는, 기획자뿐만이 아니라 개발자와 개발자 사이에서도 자신의 이해 범주에 벗어나는 업무 성향을 보일 때는 그들마저도 잦은 충돌을 하게 된다.
그럼 어떤 방향으로 커뮤니케이션을 해야 얼굴 찌푸리지 않고 최대한 모두에게 좋은 결과로 업무가 진행될 수 있을까? 나는 개발자로서 기술적인 역량이 강하다고 말하기엔 부족하지만 커뮤니케이션 능력만큼은 강점이라고 할 수 있을 정도로 자신이 있다.
내가 실무에서 직접 겪어본 상황과 그 상황들을 해결하며 얻은 커뮤니케이션 스킬들을 정리해 보려고 한다.
무조건 안된다보다는 새로운 방안 제시하기
우리는 간혹 회의실에서 이런 성향의 개발자들을 만날 때가 있다.
"그거 안돼요.", "그거 하다가 문제 생기면 책임질 거예요?" 등의 말을 하며 여러 사람들이 있는 회의실에서 공격적인 말투와 무시하는 말투로 타인의 기를 죽이는 성향의 사람이 있다. 물론 나조차도 정말 이상한 기획안을 가지고 오거나 성능상 큰 이슈가 있을 것 같은 내용을 보여주면 이대로 개발했다가는 위험할 것 같다는 생각이 들 때가 있다. 그런 경우 '무조건 안 돼요'라는 표현은 감정만 상하게 하고, 협업을 어렵게 만든다. "A 방법은 사용성도 편리하고 UI도 예쁘지만 이슈 발생의 확률이 크므로 B 방안으로 한 번 해보는 게 어떨까요? 아무리 예쁜 UI라고 해도 사용 자체에 문제가 생기면 유저들은 불편함을 겪고 이탈할 수밖에 없을 것 같습니다." 등의 방식으로 발표한 기획안이 굉장히 좋지만 이슈 발생의 위험이 있으므로 다른 방안으로 조금만 바꾸면 어떨지 의견을 구한다면 회의 분위기가 유하게 흘러갈 수 있고, 더 나은 결론에 도달할 수 있을 것이다.
빠른 대답보다는 신중한 답변을, 그리고 최대한 문서화하기
요즘은 서류, 메일 등으로 업무 협업을 하기보다는 사내 메신저를 통한 커뮤니케이션을 주로 하는 회사들이 많다. 메신저를 통한 커뮤니케이션은 긴급한 상황에 빠르게 대처할 수 있고, 장황하게 쓰이던 메일 내용을 보다 축약해서 전달할 수 있는 이점이 있다.
그렇지만 특정 사람들은 업무 메신저를 주변 지인들과 대화하듯이 정리하지 않고
"이건 이렇게 하시면 되고요."
"저건 저렇게 하시면 됩니다."
"아 그리고 이 부분은 이런 방식으로 해야 되니까 예외처리 해주세요."
처럼 무분별하게 엔터를 치며 빠른 답변만 늘어놓곤 한다.
아무리 메신저라고 하더라도 업무 협업을 위한 커뮤니케이션을 할 때는 답변에 조금 시간이 걸리더라도 "잠시만요. 정리해서 전달드리도록 하겠습니다."라고 상대방에게 미리 양해를 구하고 정리된 답변을 준비한다.
"A 케이스 - xx 데이터 저장.
B 케이스 - yy 데이터 저장.
C 케이스 - zz 데이터 저장. (숫자가 아닌 경우 오류메시지 반환)
방식으로 데이터 저장해 주시면 됩니다. 진행하시다가 문의 있으시면 말씀 주세요."와 같은 방식으로 하나의 메시지 안에 정리된 형태의 답변이 들어갈 수 있게 전달한다. 만약 이렇게 간단히 정리되기 어려운 형태의 답변이라면 이를 문서화하여 구글시트나 프레젠테이션 등으로 간략히 정리하고 URL을 전달하는 방법도 굉장히 좋은 커뮤니케이션이다.
확장성 고려하기
빠르게 일을 처리해야 하거나 급한 업무를 처리할 때 우리는 간과하는 사항들이 있다. 바로 확장성이다. 당장 오류가 발생해서 사용자가 불편을 겪고 있다면 그때는 확장성 고려가 무슨 소용일까? 일단 빨리 처리하는 게 먼저다. 그렇지만 업무 수행 중에 조금의 여유가 있다면 미래를 내다보고 일을 해야 할 필요가 있다. 이를 테면, 기획자는 지금 당장 조회 기능이 필요하니까 빨리 만들어 달라고 한다. 그렇지만 조금 더 깊게 생각해 보니 추후에는 조회 기능만이 아닌, 수정 기능도 필요할 것 같다. 이런 경우 나는 개발자이지만 추가 기획을 제안할 때가 많다. "A 프로젝트 진행하면서 비슷한 기능을 개발했었는데, 운영하다 보니 결국 수정 기능도 필요해서 추가 개발을 했습니다. 이 프로젝트에서는 미리 조회, 수정 기능을 같이 개발하면 어떨까요?"와 같이 말이다.
개발자라고 무조건 운영자, 기획자가 전달해 주는 내용만을 개발해야 된다고 생각하지 않는다. 내가 이 분야에서 더 경험이 많다면 그들이 생각하지 못한 부분에서 확장성을 고려하여 같이 이야기 나누고, 개발 착수가 되기 전에 조금 더 다듬은 상태로 일을 진행시키는 부분도 필요하다.
경험이 많은 개발자라면, 주어진 요구사항만 처리하는 걸로 끝나선 안 된다.
운영자나 기획자가 놓친 부분까지 챙기면서 함께 '미래를 준비'하는 것이 진짜 일 잘하는 커뮤니케이션이다.
이런 커뮤니케이션 습관들이 쌓이면 결국 팀워크와 결과물 모두 좋아진다.
