위코드에서 진행하는 "개발자 답게 소통하는 법" 이라는 주제의 세미나를 참석하게 되었다. 어떤 내용인지 궁금해서 참석했는데, 세미나를 듣고 많은 생각을 하게 되었고, 개발자로써 한걸음 더 성장할 수 있도록 세미나를 진행해주신 "장준"님께 감사를 표하고 싶다.

주제 별로 설명을 해주셨는데, 내가 개발자로 일하며 동일한 방식으로 소통, 고민했던 것도 있었고, 생각하지 못한 부분도 있었기 때문에 매 주제마다 여러가지 생각을 했던것 같다.

세미나를 들으면서 주제별로 생각했던 내용을 정리하였다.

소통을 잘하는 특징

첫번째는 소통은 잘하는 사람의 특징에 대해 몇가지 말씀해주셨다.

1. 심리적 안정감을 보장

   소통하는 상대방에게 심리적인 안정감을 주면서 소통해야 된다는 내용이였는데,
   내가 개발을 처음 할때에 느꼈던 감정과 그 이후에 신경썼던 부분이 생각이 났다.
   내가 프론트엔드로써 첫 직장생활을 할때 프론트엔드 개발자는 나혼자 였었고 
   회의를 할 때, 아무도 나를 압박하지 않았지만 
   셀프로 내 생각을 100% 잘 전달해야 된다는 압박을 느꼈던거 같다
   
   - 혹시나 내가 말실수를 해서 일정에 차질이 생기지 않을까?
   - 내 지식밖에 있는 장애물들이 있지는 않을까?
   
   라는 생각들을 하면서 회의에 임했다.
   그런 불안한 마음을 가지며 회의를 진행하다보니 속사포로 내 의견을 이야기 하거나 경직되서 이야기를 했던거 같다.
   
   그렇게 회의 시간이 끝나면 
   "내가 평소에는 이렇게 말하지 않는데, 왜 이렇게 뭐에 쫏기듯 이야기 했지?"
   라는 생각이 자주 들던 와중에,
   회의를 이끌어가시는 전략팀장님을 보고 마인드를 바꿨었다.
   
   새로운 주제에 대해 답을 찾아가는 과정을 보면, 
   그때 답을 내지 않고 서로의 의견을 듣고
   그걸 함께 고민해 나가면서 모두가 생각하는 답에 가까워 지는 방식으로 소통을 하셨는데,
   모두가 편안하게 의견을 냈던 경험이 있어서 마인드를 바꿔야 겠다는 결심을 하게 되었다
   
   "소통은 맞춰가는거다. 그때 꼭 완벽한 답을 내놓지 않더라도 알아보고 다시 회의를 잡으면 되겠다"
   라는 생각을 하며 조금 여유를 가지려고 했고 이전보다 편한 분위기 속에서 회의에 임했던거 같다

2. 논리적 근거로 소통을 준비한다.

   공감이 많이 됐던 부분이다.
   개발하며 소통을 할때 꼭 필요한 부분이라고 생각한다.
   
   무언가를 이야기 할때 
   - 이건 안될거 같아요.
   - 이건 이런방식으로 해야 될거 같습니다.
   와 같이 이야기 하는 경우가 많은데,
   
   "왜요?" 라고 물어봤을때 내가 그렇게 생각한 논리적인 근거가 필요하다.
   
   예를 들면, 
   - 컨텐츠 반복 시작시간(매일 16시) 
   - 한 컨텐츠 마다 반복되는 초(n)
   이 두 가지 값을 드릴테니까
   n초마다 반복하는 컨텐츠 시작시간, 종료시간을 프론트에서 계산해주세요
   
   라는 요청을 받았을 때,
   "음 프론트에서 계산하는건 안될거 같은데..." 라고만 생각하는것과
   "'컨텐츠 반복 시작시간'과 '한 컨텐츠 마다 반복되는 초'를 관리자페이지에서 제어할 수 있는데 
   그렇게 된다면, 어느 순간까지는 몇초, 어느 순간부터는 몇초인지 
   프론트에서 알수 있는 방법이 없을거 같은데 다른 방법이 있을까요?" 라고 하는것은
   
   내가 고민했던 부분을 더 잘 나타낼수 있고, 
   상대방이 생각하지 못한 부분, 내가 생각하지 못한부분을 
   맞춰 나갈수 있는 방법이라고 생각하기 때문에 공감이 갔던것 같다.

3. 소통의 히스토리를 파악한다

   이 부분은 내가 신경써서 소통하지 않았던 부분으로 앞으로는 좀 신경써야 겠다고 생각하게 되었다.
   
   "왜 이런 이야기를 하게 되었는지?"
   에 대한 생각을 하면서 소통을 해야 된다고 말씀해주셨는데,
   내 생각에 무슨 이야기 나눌때 왜 이런 이야기를 하게 되었는지를 모르지는 않을것 같고,
   이런 이야기를 하게 된 배경을 생각하며 소통을 해 나아가야겠다는 생각을 했다.
   
   소통을 하다 보면, 고민안에서 고민이 생겨나고 문제 안에서 문제가 생겨나면서
   소통을 할수록 문제가 쌓여 간다는 느낌을 받은 적이 있었는데
   그때 소통의 히스토리를 생각하면서 이야기 했다면 뭔가 정리 된 느낌을 받을거 같다.

4. 공감의 오아시스를 만든다

   내가 화자일때는, 내가 무슨 이야기를 하고 싶은지 상대방이 알 수 있게 설명해야 되고
   내가 청자일때는, 상대방이 무슨 말을 하려고 하는지를 예상하면서 들으면서 이해한 부분은 이해한게 맞는지 의견을 줘야된다.
   라고 말씀을 해주셨는데, 
   
   내가 말하는 입장일 때는 당연히 내가 하고 싶은 이야기에 대한 내용을 전달하는게 당연하다고 생각한다.
   (아까 논리적 근거를 준비한다에서 나온 내용을 함께 이야기 하는것)
   
   내가 듣는 입장일 때가 더 느낀점이 많았던거 같다. 듣는입장일 때 말씀해주신대로 하는게 중요하다고 생각한다.
   무슨 말을 하려고 하는지 예상하면서 들으면 이야기에 더 집중하게 되고,
   이해한 부분은 이해한게 맞는지 의견을 주게 되면 더 확실한 소통이 되기 때문이다.
   
   집중하지 않는 동료와 일하게 되면 소통하는게 굉장히 힘든것 같다.
   회의록을 남긴다고 해도, 이야기 할때마다 다시 회의록을 보면서 소통해야 되고,
   회의록이 없으면, 다시 이해 시키고 다시 목적을 향해 소통해야 되기 때문이다.
   
   집중하지 않는 동료가 내가 되지 않도록 항상 주의하면서 소통해야겠다.

5. 다름의 배경을 먼저 설명한다

   지식, 이해, 환경의 수준이 다르기 때문에 결과나 경험 중심적으로 이야기 하지 않아야 되며, 
   다른 배경을 먼저 설명하고 소통하는것이 좋다는 말씀을 해주셨다.
   
   이전에 기획자분과 긴급서버 점검에 대한 이야기를 나누었던게 떠올랐다.
   
     ---
     A서비스처럼 관리자페이지에서 긴급서버점검 가동하면 경고창 띄우고, 
     홈으로 다 이동되도록 B서비스에 구현해주세요
     ---
   
   라는 요구사항을 받았는데, 
   "A서비스는 소켓으로 구현되어 있는데 B서비스는 소켓이 없어서 바로는 안됩니다."
   라고 소통하면 모르는 사람이 들었을때 당연히 정보가 없으니까 물어봐야되는데,
   뭘 물어봐야 될지 모르는 경우가 생길수도 있을거고, 여러가지 문제가 생길 수 있다고 생각한다.
   
   그래서 나는 이런식으로 설명을 했던거 같다(근데 이때는 몰랐지만 기획자분이 개발을 해보셨던 분이라 투머치 설명이긴 했다)
   
     ---
     A서비스는 소켓으로 긴급점검을 구현했는데, B서비스는 소켓이 없습니다.
     소켓은 서버에서 신호를 주면 클라이언트단에서 바로 신호를 받을 수 있는데,
     지금 B서비스는 클라이언트에서 요청을 해야만 서버에서 답을 줄 수 있는 구조로 되어 있습니다.
     일단 지금 당장 소켓을 추가하는데는 무리가 있다고 하는데,
     지금 떠오르는 방법은 클라이언트에서 일정시간마다 한번 요청을 보내서
     서버 점검 상태를 캐치하는 방법이 있을거 같습니다.
     일정시간이 짧으면 짧을수록 통신 비용이 늘거 같아서, 적당한 시간이 필요하고,
     다른 방법이 있는지 개발팀에서 회의를 한번 진행해봐야 될거 같습니다.
     ---
   
   라고 소통을 했고 10분마다 확인하는 방식으로 조치를 했다
   
   이렇게 소통을 할때 내가 아는 지식을 함께 맞추는 과정을 통해서 더 소통이 편해지도록 한것 같다.
   
   ------
   10분으로 정한 이유는 람다 함수를 이용해서 확인하는 방식으로 구현했는데,
   요청 1백만 건당 0.20 USD
   5000(명) * 6(1시간) * 24(하루) * 30(한달) / 1000000(백만건) * 0.2(0.2달러)로
   동시접속자가 5천명으로 꾸준히 유지될때 5달러 미만으로 예상하고 정했다.

6. 목적 중심적으로 설득한다.

   목적을 설득하기 위한 근거를 말하기 때문에 소통을 리딩하게 된다고 한다.
   3번과 마찬가지로 내가 이 이야기를 왜 하고 있는지를 생각하면서 소통하면 될것 같다.

7. 소통과 소통을 이어주는 기록을 남긴다.

   - 소통을 하면서 나만의 기록을 남기고
   - 다음 소통때는 어떤걸 준비해서 어떤 이야기를 할거고, 어떤 결론을 지어야 겠다 라고 생각하고
   - 이번에 만난 이유와 다음에 만난 이유를 잘 관리하는 사람이 되야 된다
   라고 말씀을 해주셨다.
   
   소통을 할때 모든 이야기들을 회의록에 작성하시는 분도 있는데,
   나는 오늘 협의한게 틀어지면 안되는 내용들(어떻게 개발하기로 결정되었는지)만 
   내가 알아보기 쉽게 적어놨던것 같다.
   
   중요한 내용만 적으면 된다고 생각했지만, 저번 회의와 이번 회의를 이어주려면
   여러가지 내용들을 자세히 적으면 좋을거 같다는 생각을 했다.
   
   이전에 회의록을 항상 적으시는 분들을 보면 대단하다고만 생각을 했었는데,
   이제는 뭔가 적으시는 이유를 공감하게 된것 같다.

8. 소통의 결과를 약속하고 성과로 책임진다.

   개발을 처음 시작할때 부터 아주 중요하다고 생각하고 있다.
   나로 인해서 여러 사람들 일정이 연쇄적으로 틀어진다고 생각하고 항상 일정을 생각했고,
   실제로 소통의 결과가 성과로 나오지 않는 일들이 반복되면 그사람을 못믿게 되는것 같다.
   
   그래서 일정이 촉박할 때는 몇일동안 막차를 타고 가기도 하며, 일정을 중요하게 생각했기에
   공감이 많이 됐다.
   
   자신감은 중요하지만, 내가 할 수 있는 기준을 잘 파악해 조절 할 수 있도록 연습해야겠다.(막차안타도록;;)

소통을 잘하는 특징과
개발자가 소통을 더 잘해야 하는 이유를 설명해주셨는데,
너무 긴것 같아서 두개로 나누어 정리를 해야겠다.