개발자가 되기 전에는 예상하지 못한 어려움
개발자로 일하기 전에는 내 실력이 가장 큰 걸림돌이라고 생각했다. 하지만 개발자로 일할수록 내 개발 실력이 부족해서 생기는 어려움은 가장 심플하고 간단한 것임을 깨달았다. 정말 힘들고 어려운 것은 외부에 있다. 모든 회사생활이 그렇지만 조직 구성원이 가장 중요하다. 특히 나와 업무적으로 긴밀한 관계일수록 그 사람과 호흡이 중요하다.
내가 처음 만난 사람은 같은 팀 동료였다. 성실하고 선한 성격을 가지고 있었지만 사회 경험과 센스가 다소 부족한 편이었다. 회의를 통해 암묵적으로 합의된 코드 컨벤션을 공식적으로 문서화하자는 안건이 나왔었다. 그런데 그 문서를 워드나 한글, PPT도 아니고 README.md 파일로 작성한 것이다. 잘못한 것은 아니지만, 개발자가 아니면 이 문서를 볼 수 있을까? 물론 개발자가 아닌 사람이 이 문서가 필요할 일은 없겠지만 그래도 뭔가 이상했다. 조금만 더 생각해보면 한번에 처리할 수 있던 일을 근시안적으로 해결하여 꼭 손이 한번씩 더 가도록 만들었다.
두번째로 만난 사람은 같은 팀 상사이다. 실력도 매우 좋고, 일도 열심히 하는 사람이었으나 일정을 뒤늦게 알려주었다. 예를들어 시작 전에는 3개월동안 하나의 서비스만 만들면 된다고 했다가 갑자기 마감기간이 다음달로 변경되었다는 식이다. 일정이 변경된 만큼 우선순위가 낮은 기능은 다음 업데이트 때 추가되는 것으로 미뤄졌으나 그럼에도 불구하고 야근은 불가피했다.
세번째로 만난 사람은 사이드프로젝트 PL이다. 서비스 기획을 하고 싶던 현직 디자이너였는데 개발에 대해서는 하나도 모르는 분이었다. 사이트프로젝트의 구성원은 PL 1명, 기획자7명, 백엔드 개발자1명, 프론트엔드 개발자1명으로 총 10명이었다. 제시한 아이디어들은 너무 훌륭하고 창의적이었다. PL이 '그럼 기획자가 많으니 팀을 나눠서 아이디어를 구체화하고 개발자가 각 팀에 투입되어 구현하는 방향으로 할까요?'라고 말하기 전까지 말이다. 웹개발자 2명을 모아두고 앱개발을 논하는 이 기획자들을 보고 있으니 막막해졌다. 앱개발과 웹개발, 백엔드와 프론트엔드, 심지어 본인이 말하는 핵심기능이 어떤 개발이 필요한지조차 모르는 PL을 바라보며 나는 탈퇴를 선언했다.
이 사람들의 공통점은 커뮤니케이션에 있어 매끄럽지 못했다는 것이다. 업무 처리 방식에 있어서, 일정 관리에 있어서, 그리고 업무 스킬에 있어서 호흡이 맞지 않았다. 반대로 말하면 나도 그들에게 좋은 협력자는 아니었을 것이다. 면접에서 왜 이렇게 협업, 커뮤니케이션을 중요하게 생각하고 물어보나 했는데 내가 경험해보니 알 것 같다. 단순하게 의사소통에 안되는 것에서 끝나는 일이 아니었다. 나는 첫번째 상대 때문에 퇴사를 했다. 이를 보아 호흡이 안맞다는 것은 상대에 대한 감정에 영향을 미치고, 팀워크에 영향을 미쳐 결국 일의 효율성 저하로 이어진다.