들어가며
커뮤니케이션은 어떻게 하면 잘할까? 개인적으로 항상 고민하는 문제이고, 아직도 어려워 하는 문제이다.
같은 업계 사람이라면 한번쯤 생각해 봤을 법한, 개발자의 커뮤니케이션에 대해서 포스팅 하고자 한다.
정작 본인도 남중 -> 남고 -> 공대 -> 군대 -> 개발자…어떻게 보면 전형적인? 개발자 코스프레 코스로
개발자가 되어서 이러한 포스팅을 하는게 조금은 부끄럽기도 하다…ㅠ
다만 학창시절에 만났던 친구들이나 지인들이 모두 영업, 마케터, 체육, 제조 등 개발과는 다소 거리가 먼
업종에 있고 그 사람들이 개발자와의 소통에서 어려웠던 점이나 열받았던? 경험들을 들어보면
이해가 되면서도 한편으로는 서글픈 생각이 들었다.
개발자의 커뮤니케이션은 위에서 서술했듯이 항상 어떻게 잘할수 있을까? 고민하는 문제이기 때문에
포스팅 주제로 선택하였으며,
이 포스팅은 업계에 있으면서 꽤 주관적인 시선으로 느낀바를 기술하는 터라 내용은 가볍게 참고만 하면 될것 같다.
개발자란 무엇인가
어떤 칼럼니스트 분이 쓴 개발자의 생명은 커뮤니케이션 능력 글이 있는데, 여기 글을 보면,
프로그래머와 개발자의 대한 나름대로의 정의를 내려주셨는데, 이 부분이 개인적으로는 꽤 맞는 것 같다는 생각이 든다.
개발자는 기업이나 큰 프로젝트에 속해서 다른 사람과 협업을 통해서 코드를 만들어낸다.
이러한 협업은 프로그래밍과 다른 차원의 원리와 원칙, 그리고 경험을 필요로 한다.
예컨대 프로그래머 혹은 해커를 강호를 혼자 떠돌며 칼을 쓰는 무사라고 한다면,
개발자는 거대한 군사 조직에 속한 정규군이다. 외톨이 무사에게 생명은 칼솜씨이고 정규군의 생명은 규칙과 규율이다.
회사에 속한 개발자라면, 코딩 실력/아키텍쳐 실력 뿐 아니라 커뮤니케이션 능력도 반드시 필요하다.
1인 회사가 아닌 이상, 어떠한 조직 또는 어떠한 그룹에 반드시 속해 있을것이고 그러기 때문에 협업이 진행되며,
상대방이 로봇이 아닌 사람이기 때문에 어떻게든 협업시에 커뮤니케이션은 늘 존재한다.
사실 난 코딩만 열심히 할꺼야~ 라는 건 현실 사회에서, 특히 여러 협업부서와 일이 필요로 하는 회사에는 잘 통하지 않는것 같다.
나쁜 예
개발자가 커뮤니케이션 할때 나쁜 예를 들어보자.
아래와 같이 어떤 요구사항이 발생했다고 가정하자.
(요청자는 기획자 일수도 있고, 마케터 일수도 있고, 사업부서 일수도 있다.)
A라는 기능이 필요한데, 이 부분 구현 가능하신가요?
답변 :
A라는 기능을 개발하려면, 각 서버에 health check를 날려서 connection이 되는지 봐야하는데
이렇게 되면 구성하기도 힘들고 서버 부하가 있으니, 앞단 javascript에서 구현을 하면 될것 같습니다.
당췌….상대방은 이게 대체 무슨 말이지? 라고 생각할 것이다.
예시를 과하게 든 것도 있지만, 정말 기술적인 용어를 덕지덕지 붙여서 커뮤니케이션 하는 개발자들이 꽤 있다.
나도 개발자지만 이러한 모습을 보면 꽤 답답한 생각이 든다.
상대방이 개발자가 아니면 최대한 보수적으로 기술적 용어는 삼가하되, 상대방이 이해 할 수 있는 단어를 선택해야 한다.
위에 나쁜예를 보다 쉽게 표현하면 아래와 같이 간결히게 표현이 가능하다.
네 시스템적인 이슈가 있긴 하지만 해결은 가능할듯 하니, 기능 구현에는 문제 없을것 같습니다.
혹은, 현재 시스템 구조상 기능 구현은 어렵습니다.
라고 표현할수 있을것 같다.
사실 상대방은 앞단, 뒷단 서버등등 대한 지식이 개발자보다 당연히 떨어질수 밖에 없고,
묻는 의도 자체가 가능한지 불가능한지 혹은 이슈가 있는건지가 궁금한 것이기 때문에 그에 대한 피드백만 간략히 전달하면 좋을것 같다.
상대방 의도 파악하기
A라는 기능 개발 자체에 처음부터 초점을 두지 말고, A라는 기능이 왜 필요한지
또는 어떠한 계기로 A라는 기능이 필요하게 된건지 등,
상대방의 의도 및 목적을 먼저 파악하면 보다 쉽게 대화가 될수 있을 것이다.
의외로 어떠한 일에 대한 의도나 목적에 대해서 묻는 개발자는 많이 없다.
경험상 상대방의 의도나 목적을 정확히 파악하면 굳이 A라는 기능추가가 아니고 더 쉽고 빠르게 해결될수 있는 일들이 많았다.
커뮤니케이션시 상대방의 의도/목적을 먼저 파악하는 습관을 기르자!
공감하기 그리고 기다려주기
사실 공감은 일상 생활에서도 필요하듯이 사람간 사이에 꽤 중요한 포인트이다.
흔히 개발자는 상대방의 말을 듣고 있으면 머리속으로 휙휙 시스템을 구상하고 안돼는 포인트들을 있나 없나 머리속이 바빠진다.
(나 또한 그러하다 ㅠㅠ)
그리고 이슈가 있는 포인트가 있으면 이건 안돼지! 라고 벌써 부터 마음 준비하는 상황이 오는데 사실 이런 부분은
막상 나중에 생각해도 별 탈이 없다.
설령 구현이 안돼는 부분이 있어도, 먼저 상대방이 왜 이런 이야기를 하는지 어떠한 상황에 있는지 어렵지만 공감을 한번 해보자.
그리고 입이 간질간질해도 상대방의 얘기가 끝날때까지 공감하면서 끝까지 기다려보자.
공감대가 조금이라도 이루어 진다면, 커뮤니케이션이 확실히 보다 편안하게 진행되며 민감하고 어려운 얘기들을
보다 쉽고 편안하게 서로간 오해없이 할 수 있는 여건이 마법같이 생긴다.
나의 생각을 명확히 전달하기
커뮤니케이션을 하다 보면, 나의 생각을 정확히 전달해야 하는 상황이 꽤 발생하는데,
만약 상대방에게 내 생각이 잘 전달되지 않는다면, 상대방의 의도대로 그냥 끌려가는 경우가 발생하는 경우도 있고,
아니면 논점을 벗어나 산으로 기는 경우가 생길수도 있다.
그만큼 나의 생각을 명확하게 전달하는게 꽤 중요하다.
안돼는 사유가 있으면 왜 안돼는지, 이 이슈에 대해서 나는 어떻게 생각하는지 명확히 전달해야 상대방도 나의 얘기를 듣고,
스펙등을 조정 할수도 있으며 또한 반대로 이슈에 대해서 더욱더 나은 방향으로 디벨롭 할 수가 있다.
반대로 예를들어, 어떠한 플랫폼 또는 신규 기술 혹은 개발 언어 등 시스템 적인 업데이트가 꼭 필요한 상황이 있다고 가정하자.
왜 해야하는지 개발자는 너무나 잘 알고 있지만, 그 필요성에 대해서 개발자가 아닌 다른 사람에게 명확히 전달하는건
생각보다 어렵다.
우리도 신기술을 써봅시다!! 우린 뒤쳐져 있습니다!!! 이런건 사실 억지에 가까우며…. 왜 써야하는지 쓰면 어디가 좋고 어떠한 결과가 예상되는지,
기존과 비교해서 어떠한 점이 월등해 지는지를 명확히 잘 전달하고, 설득을 해야 우리가 원하는 방향으로 나아 갈수가 있다.
마치며
첫번째로 코딩실력이 조금 부족하지만 커뮤니케이션을 잘하는 개발자.
두번째로 코딩실력이 좋지만, 커뮤니케이션이 부족한 개발자
개인마다 다르겠지만 이 두가지 중에 뽑으라면 난 여지없이 첫번째 이다.
생각해보면 두번째 케이스는 꽤 많이 만나봤지만 의외로 첫번째 케이스는 많이 못본거 같다.
블라블라블라…. 말만 잘하는 개발자가 되서는 당연히 안돼겠지만, 적어도 [난 개발자니까 커뮤니케이션은 못해도 돼!] 라는
마인드는 적어도 피해야 할것 같다.
좋은 개발자가 되려면 개발자들이 항상 새로운 기술에 민감하게 반응하고 항상 고민하듯이,
커뮤니케이션에도 항상 투자를 해야 한다고 생각한다.