개발자로서의 성장은 기술적 역량만큼이나, 혹은 그 이상으로 의사소통 능력에 의존합니다. 다른 개발자들과 아이디어를 나누고 협력하는 과정이 혼자서 학습하는 것보다 높은 퍼포먼스를 보여줄 수 있으니까요. 그러나 의사소통은 쉬운 일이 아닙니다. 서로 다른 배경과 지식을 갖는 사람들 간에 효과적으로 소통하기 위해서는 많은 노력이 필요합니다.
여기서는 제 의사소통 경험에서 느낀점을 이야기 해보려고 합니다.
내가 말하는 것을 이해할 수 있을까?
친구들과 잡담을 하거나 편안한 자리에서 이야기 할 때는 뇌를 거치지 않고 자연스럽게 말이 잘 나오죠. 그렇지만 면접, 발표, 회의와 같은 자리 혹은 무언가를 설명하려 할 때는 곧잘 나오지 않는 편입니다.
저는 상대방을 너무 지나치게 많이 신경쓰는 타입인것 같아요. 발표같은 경우에는 미리 스크립트를 만들 수 있지만 면접, 회의는 내가 이해하고 있는 것을 즉석해서 상대에게 명확히 전달해야하죠. 저는 혹시라도 상대방이 이해가 되지 않을까 A부터 Z까지 전~부 이야기하려고 합니다. 그러다보니 오히려 말이 장황해지고 핵심을 이야기하지 못하는 경우가 많았습니다.
부트캠프 기간동안 피어세션을 진행했어요. 자신들이 구현한 것을 동료와 공유하는 시간이었습니다. 그때 당시 Javascript로 Store 시스템을 만들고 있었습니다. 처음 구현해보는 부분이라 진행중이던 미션에 도움이 될 만한 블로그를 참고했어요. 처음보는 생소한 코드라서 제가 직접 실행시켜서 동작을 바탕으로 이해를 했었습니다. 코드를 이해하고 팀원들에게 설명을 시작했어요.
제가 직접 실행시켜보면서 이해했는데요. 먼저 observable이라는 객체는 관측가능한 객체로... 어쩌고 저쩌고
부끄럽지만 팀원분들 대부분이 제 설명을 이해 못하셨습니다. 설명하는데도 핵심은 쏙 빼놓고 주절주절 말만 길어졌죠. 되돌아보면서 머리로 이해하고 사용하는 것과 설명하는 것에는 큰 차이가 있다는 것을 제대로 느꼈습니다.
설명을 어떻게 해야하지?
저는 일단 너무 구체적으로 설명하려는 습관을 버려야 할 것 같아요. 만약 정말로 구체적인 설명이 필요한 상대였다면 지금과 같은 방식이 맞을 수 있겠지만 대부분은 아니었죠.
부트캠프에서 같은 수업을 들었으니 어느 정도 이해하고 있는 내용이 비슷할 것이라고 예상할 수 있습니다. 그렇다면 내가 이해한 것에서 핵심을 추려내 전달하는게 좋다고 생각됩니다. 만약 제 앞에 있는 사람이 개발을 전혀 모르는 사람이라면 이야기는 달라지겠죠.
결론은!
핵심을 파악하고 설명을 받아들이는 사람과 상황에 맞추자!
협업적으로 어려웠던 부분
서로 다른 분야의 개발자들이 자신이 익숙한 단어들을 사용해 소통이 어려웠던 경험도 있습니다. 제가 진행했던 프로젝트는 프론트엔드 2명, IOS 2명, 백엔드 2명 이렇게 6명이서 진행했습니다. 매일매일 스크럼을 진행했는데 서로의 진행상황을 공유했어요.
프론트 : 오늘 Context API 연동할거에요.
IOS : ViewModel 마저 만들고 Usecase 할 것 같아요.
백엔드: Docker compose 파일에 build 문제에 의한 nginx 배포문제 해결해야 할 것 같아요.
저는 Context API말고 무슨 말인지 몰랐습니다. 마찬가지로 팀원 분들은 Context API가 뭔지 몰랐죠. 그러다보니 팀원들의 진행상황을 정확하게 파악하기 어려웠어요. 웹 풀스택, 모바일까지 섭렵한 슈퍼 개발자라면 무슨 말하는지 쉽게 알 수 있겠죠. 하지만 프로젝트를 진행한 팀원들은 모두 대학생이었습니다.
다행히 팀원 모두 저와 비슷한 생각을 가지고 있었고, 모든 개발 용어를 대체할 수는 없었지만 어느정도 이해할 수 있는 언어로 바꿔서 진행하기도 했습니다.
프론트 : 오늘 어디어디 부분 구현할 겁니다.
IOS : 어제 이쪽 뷰 만들었고 테스트 해볼 것 같아요.
백엔드: 서버 CPU 부하문제 해결해보려고 합니다.
앞으로도 다른 사람과 말을 할 때는 상대방의 상황을 파악을 해야 할 것 같습니다.
안된다고만 하지 말자
프로젝트 팀원 구성의 특성상 백엔드 개발자들은 웹과 모바일이 모두 사용할 수 있는 API를 구현했어야 했습니다. API의 데이터 형식을 정할 때, '아 이거는 힘들 것 같은데..' 라는 부분이 있었습니다. 그렇다면 이런 상황에 우리는 어떤식으로 의사소통을 해야할까요?
오우.. 그렇게 요청받으면 구현하기 힘들겠는데요....
그럼 어떻게 해야하지? ...
생각해보면 무작정 안된다고 하는 것은 더 이상의 소통을 힘겹게 만드는 것 같습니다. 중요한 건 안되는 사실자체보다 안되는 이유같아요. 문제를 해결하려면 원인을 알아야 하듯이 다른 방법을 찾으려면 곤란한 이유를 알아야 하겠죠.
따라서 그냥 안되는데요 끝내지 말고 어떤 이유에서 힘든지, 정말 불가능한건지 따져보고 새로운 대안을 제시하는 것이 의사소통 측면에서 중요할 것이라고 생각합니다.
질문은 어떻게?
저는 처음에 혼자서 어떤 문제를 해결해내는 것에 프라이드가 있었어요. 0점 비율이 87%가 되는 난이도 높은 과제에서 만점을 받아보기도 하고, 남들이 어려워 하는 학부 과제를 해결했을 때 상당한 성취감을 얻었거든요. 혼자서도 충분히 많은 성장을 해낼 수 있다고 생각했습니다.
그런데 생각이 바뀌는 시점이 있었습니다. 제가 같은 강의를 듣는 학생에게 과제를 도와주었던 때였는데요. 상대 학생의 질문방식이 정말 좋다고 느꼈습니다.
제가 이런 결과를 얻으려고 코드를 짰는데, 실제 결과는 이렇게 나오네요?
저는 이 부분이 문제인거 같은데, 혹시 어떻게 생각하세요?
짧지만 명확한 상황설명, 상대방의 생각이 담겨 있어서 답변하기 수월했습니다.
질문을 받고 정성스럽게 디버깅을 하면서 어떤 부분에서 데이터 연산이 제대로 되지 않는지 알려줬습니다. 저는 여기서 끝내지 않고 디버깅을 하는 방법, 검색하는 방법을 추가적으로 알려줬어요. 구현에 대해 감을 잡았던 때가 이 두가지를 해봤을 때였거든요. 어느 정도 시간이 지난 후 놀라운 일이 있었습니다. 제가 알려주는 입장임에도 불구하고, 상대 학생이 더 좋은 해결방법을 구현해낸 것이었습니다.
이 때, 혼자서도 할 수 있겠다라는 생각이 전환되었던 것 같아요.
와, 같이하면 혼자일 때 보다 몇 배는 좋은 퍼포먼스가 나오는구나. 나도 저렇게 좋은 질문을 할 수 있도록 노력해야겠다.
라는 다짐을 하게 되었답니다.
공유하자 공유!
페어프로그래밍은 개발 과정에서 가장 인상 깊은 경험 중 하나였습니다. 프론트엔드 미션을 시작한 첫 주차부터 함께한 동료와 페어 프로그래밍을 통해 화면을 구현했습니다. 이 기간 동안 함께 논의하고 문제를 해결하며 프로젝트를 진행하는 과정은 정말 활기차고 의미 있었습니다. 가장 인상 깊었던 순간은, 우리가 피그마와 거의 동일한 레이아웃을 화면에 구현했을 때입니다. "이걸 우리가 만들었어요!!" 라는 뿌듯함을 공유하며 큰 성취감을 느꼈습니다.
당시 구현한 화면
만약 혼자서 토이 프로젝트를 진행했다면, 이런 성취감을 느끼기는 힘들었을 것입니다. 하지만 페어프로그래밍을 통해 성취를 공유하고 공감할 수 있었던 것은 정말 행복한 경험이었습니다. 함께 노력하고 성장하는 과정에서 동료와의 협업은 개발자로서 가치있는 순간 중 하나였습니다.
마치며
그동안 이렇다 할 의사소통, 특히 개발적인 부분에서 부족하다고 느끼고 있었습니다. 2달간의 부트캠프 기간동안 의미있는 경험을 많이 했지만 개인적으로 특히 인상깊었던 부분은 동료들과 함께했던 시간이었습니다. 이 때 느꼈던 행복한 감정을 다시한번 느끼고 싶기에 앞으로도 동료들과 함께 고민하고 좋은 고민을 하기위해 깨달은 부분을 잊지 않고 살아야겠습니다. 😊
