아티클: https://yozm.wishket.com/magazine/detail/1702/
협업이란?
협업, 영어론 collaboration, 스페인어로는 colaboración이라고 한다. 뜻은 공동 출연, 경연, 합작, 공동 작업, 모두 일하는, 협력하는 것 모두를 뜻한다.
개발자는 협업이 필수불가결하다. 개인 개발 및 서비스가 있긴 하겠지만 대부분의 서비스는 PM, 디자이너, 개발자가 팀으로 이루어져 만들어 진다 생각하기 때문이다. 팀 구성이 이렇지 않더라도 개발자가 둘 이상이라면 협업이 이루어 질 수 밖에 없기 떄문이다.
이 아티클에선 2년 차 개발자부터 10년차 개발자까지 총 8명에게 함께 일하고 싶은 개발자와 같이 일하고 싶지 않은 개발자에 대해 인터뷰한 내용을 다루고 있다.
피하고 싶은 개발자
잘 모르는데 아는척 넘어가는 개발자
"다양한 캐릭터의 개발자가 있는데 보통 커뮤니케이션이 원활하지 않을 때 함께 일하기 어려운 것 같아요. 커뮤니케이션이 어려운 상황에는 여러 가지가 있는데, 제가 가장 크리티컬하다고 생각하는 것은 '잘 모르는데 아는 척 넘어가는 것'이에요. 몰라도 아는 척 어물쩍 넘어가는 동료와는 일을 분배할 수 없겠다는 생각이 들더라고요. 그런 분을 믿고 일을 부탁하거나 그분의 작업을 믿기 어렵게 되는 것이죠."
보통 협업에는 커뮤니케이션이 중요하다. 대부분 일할 때 생기는 에러중 하나가 커뮤니케이션이 원활하게 되지 않는 것이라 생각하는데 인터뷰에 따르면 그 중 크리티컬하다는게 잘 모르는데 아는 척 넘어가는 것이라고 한다. 그 이유는 신뢰성의 문제가 생겨 협업이 어렵다고 한다. 나같아도 잘 아는 것 같아 일을 맡겼는데 잘 알지 못해 기간안에 제품이 나오지 않는 다던지 퀄리티가 떨어지는 일이 벌어진다면 신뢰가 뚝 떨어져 같이 일하고 싶진 않을 것 같다.
나도 가끔 헷갈리던지 가물가물한 기억을 대충 아는 척 하고 넘기던 습관이 있는데 최근들어 고치고 있다. 어딘가에 이 애매한 지식이나 기억들을 자세히 알아보고 기록하는 것이 좋은 것 같다. 다시 찾아보기도 쉽고 기억에 오래남는다.
동료와 프로덕트 고려하지 않는 사람
"개발하는 것을 좋아하고 잘하시는 분과 함께하면 좋은 영향을 많이 받는 것 같아요. 그러나 개발에만 너무 집중해서 다른 동료들은 안중에 없거나 프로덕트의 성공과 멀어지는 개발을 하는 분이면 함께 일하고 싶지 않더라고요. 개발을 통해 고객 가치를 만드는 것을 중요시하는 분과 함께하고 싶어요."
개발을 아무리 잘해도 방향이 동료나 프로덕트에 맞지 않다면 함께하고 싶지 않다고 한다. 개발도 결국은 최종 목적이 사용자들을 위한 서비스를 만들기 위한 수단에 불과하다 생각한다. 아무리 개발하는 것이 좋아도 같이 일하는 동료를 생각하면서 동시에 프로젝트의 성공을 목표로 해야 협업을 하는 것에 의미가 있지 않을까 생각한다.
함께 일하고 싶은 개발자
병목을 줄일 수 있는 사람
"우선 대부분 제품 조직의 아웃풋에서 가장 시간이 오래걸리는 직무는 개발자라고 생각해요. 기능 요구 사항을 가장 마지막에 전달받으면서도 기술 구현 과정에서 맞닥뜨리는 문제에 따라서 구현이나 설계가 달라질 수 있기 때문이에요. 또 개발자는 기술 구현 상황에 따라 기획이나 디자인 변경을 역으로 요청해야 할 때도 많은데요. 이렇게 변경이 필요한 사항을 최대한 이전 단계에서 알아보고 커뮤니케이션을 시작하는 것이 아웃풋을 극대화할 수 있는 부분인 것 같아요. 결국 전달받을 내용이 도달하기 전에 미리 할 수 있는 작업을 쪼개서 준비해두고, 기획과 디자인에 대해 빠르게 피드백하는 것이 개발자의 중요한 역량이라고 생각해요."
대부분의 실무에서는 기획자 -> 디자이너 -> 개발자 순서로 작업이 이루어진다. 기획자가 기획 문서를 만들면 디자이너가 그것을 토대로 디자인 파일을 만들고 이후 그걸 바탕으로 개발자가 기획 문서와 디자인 파일을 보고 기능과 디자인을 구현하는 방식이다. 작업의 마지막을 개발자가 맞게 되는데 시간 안에 프로젝트를 성공적으로 마감하기 위해서는 이전 단계들이 끝나길 기다리기만 하는게 아니라 미리미리 필요한 내용을 준비한다면 생산성을 높일 수 있게 된다.
팀플레이가 가능한 사람
"팀플레이가 가능한 사람과 함께 일하고 싶어요. 할 줄 아는 게 개발이고 잘하는게 개발이라서 그냥 관성적으로 개발하는 사람이 아니라, 같은 목표를 갖고 그 목표에 공감하고 같이 즐기면서 성장하는 사람이면 좋을 것 같아요."
개발뿐 만 아니라 협업과 실무의 기본이라 생각한다. 개인 플레이를 추구하는 사람과의 협업은 참 어렵다. 개발만 잘하는 것이 아니라 팀원과의 소통을 통해 함께 성장하고 같은 목표를 위해 나가는 것이 팀원으로서의 역할이 아닌가 싶다.
함께 성장하기 위해 노력하는 사람
"개발자라면 대부분 개인의 성장은 신경 쓴다고 생각해요. 그러나 팀과 팀원 모두의 성장까지 신경 쓰는 개발자는 상대적으로 적은 것 같아요. 좋은 팀원들과 이야기하고 논의하다 보면 나도 발전하게 되는데, 이런 선순환을 생각하며 팀 전체의 성장을 위해 노력하는 개발자와 함께 하고 싶어요."
개인적으로 다른 직업들 보다 개발자라는 직업이 커뮤니티나 같은 직군끼리의 커뮤니케이션이 활발하다고 생각한다. 인턴을 경험 했을 때에 다른 팀의 프론트엔드 선임 분들 께서 많은 도움을 주셨다. 어떤 책이 요즘 좋다던지 코드 리뷰를 요청하면 항상 같이 봐주신다던지, 변수명 생성기 같은 사소한 것 까지도 공유했던 것이 나에겐 아주 소중한 경험이자 조금이라도 성장할 수 있었던 경험이었다.
근거와 함께 의견을 설득하는 사람
"똑똑한 사람이면 좋겠어요. 사실 똑똑하다는 것이 많은 것을 담고 있는데, 문제 해결을 잘하는 것도 똑똑함이고 다른 사람의 제안을 열린 마음으로 받아들이는 것도 똑똑함이고, 자신의 의견을 근거와 함께 명확하게 설명하는 것도 똑똑함이라고 생각해요. 특히 근거와 함께 의견을 설득하는 것이 중요하다고 생각하는데, 가끔 보면 신기술을 무작정 좋아하는 개발자가 있는 것 같아요. 예를 들어 타입스크립트가 이제 막 나왔을 때 큰 이유를 설명해주지 않고 신기술이라는 이유만으로 도입했던 적이 있었어요. 당시에 멀쩡한 코드가 에러로 표시되는 등의 버그가 많아서 불편했는데, 제대로 된 설득 과정이 없이 이러한 불편함을 겪게 되니 더욱 결정에 공감을 하지 못했던 것 같아요. 다행히 지금은 타입스크립트가 편하고 좋지만, 왜 도입하는지 저를 비롯한 다른 동료들에게 설명이 되었으면 좋았을 것 같다는 생각이 들어요."
실무에서 가장 중요하다고 생각하는 점이다. 짧지만 3개월간의 인턴을 경험해보면서 스프린트를 몇번 진행해 보았는데 간단한 라이브러리 하나 조차 사용 가능한지, 간단하게라도 왜 써야하는지에 대해 회의 때 설명했어야 했다. 그리고 취업 준비를 하면서도 사이드 프로젝트들에 사용하는 라이브러리들의 사용 이유를 따로 생각해 냈어야만 했다. 실무에 들어간다면 프로젝트를 시작하기 전에 사용할 기술들을 미리 정리해야 할텐데 어떤 기술을 어떤 버전을 사용할 것인지 그리고 그에 대한 이유는 무엇인지 설명해야 팀원들이 이해하고 의견을 나누어야 좋은 방향성을 가진 프로젝트를 시작할 수 있게 된다 생각한다.
본인의 생각이 있는 사람
"본인의 생각이 있는 개발자와 일하고 싶어요. 저는 면접에 들어갈 때 마다 정답이 없는 질문을 준비해서 본인의 생각을 갖고 있는지 테스트를 해보는 편이에요. 인터넷이나 책에서 공부할 수 있는 것들은 사실 자기 생각이 아니더라도 얼마든지 말할 수 있어요. 그러나 정답이 없는 것들은 생각해보지 않으면 말하기 어려울 거예요. 가령 새로운 서비스를 시작할 때 MySQL이랑 NoSQL 중에서 어떤 선택이 좋을지 물어보는 것이죠. 이런 질문에는 정답이 없다고 생각하는데, 정답이 없는 질문에 납득이 가는 답변을 할 수 있는 개발자와 함께 하고 싶어요."
인터뷰 질문 내용들을 보니 첫 질문을 시작으로 점차 꼬리에 꼬리를 물어가는 질문인듯 하다. 개발자뿐만이 아니라 누군가를 설득하기 위해서는 본인의 생각이나 주관이 뚜렷해야한다 생각한다. 남들을 설득하기 위해서는 본인 생각이 어떠하고 그 생각을 뒷받침 해주는 근거가 있어야 하기 때문에 타당한 이유를 생각 해내야 한다.
말 잘하고 글 잘 쓰는 사람
"말 잘하고 글 잘 쓰는 개발자와 일하고 싶어요. 개발 실력이 좋은 것을 전제했을 때 이 사람이 얼마나 다른 사람에게 자신의 생각을 표현하고 설득할 수 있는지가 중요하다고 생각해요. 그런 능력을 갖추고 있는 사람과 함께 일하면 의견을 주고받기도 편하고 시너지도 잘 나는 것 같아요."
내가 가장 부러워 하는 부류 이다. 나는 평소 생각의 정리가 잘 되지 않아 말을 더듬거나 생각을 오래하고 말하는 편이다. 근거와 함께 의견을 설득한다면 좋기야 하겠지만 말도 잘하고 글도 잘쓰며 정리 잘해서 설득한다면 더욱 배로 시너지가 되지 않을까? 이게 정말 쉽지 않다. 나도 말 잘하고 글도 잘 쓰고 싶다.
정리
좋은 개발자가 되기 위해서는 뛰어난 개발 능력이 우선이라고 생각 했지만 이 아티클에서는 팀원과의 협업을 중시하는 사람이 우선이라고 말하고 있다.
정리하자면
1. 프로젝트를 원활하고 빠르게 진행하기 위해 병목을 줄이고,
2. 팀플레이를 우선시 하며,
3. 팀원과 함께 성장하기 위해 노력하고,
4. 팀원들에게 자신의 의견을
5. 타당한 근거와 함께
6. 말과 글을 잘 써서 설득하는 사람을 개발자들은 원하고 있다는 것이다.
좋은 개발자되기 너무 어렵다. 처음부터 하나씩 노력해보는 개발자가 되자.
그래도 개발 능력은 좋아야 하는게 디폴트값이 아닌가 생각해본다.
