개발자에게 물어봤습니다: ① 함께 일하고 싶은 개발자

우리가 알고 있는 대부분의 기업이나 서비스는 한 명의 힘으로 운영되지 않습니다. 스티브 잡스 하면 가장 먼저 떠오르는 애플의 아이폰조차 스티브 잡스 혼자만의 힘으로 만들어진 것이 아닙니다. 지금 이 시각에도 다양한 직무의 사람들이 서로 협력하며 서비스를 발전시켜나가고 있으며, 특히 IT 기업의 경우 PM(혹은 기획자), 디자이너, 그리고 개발자가 함께 일하는 경우가 많습니다. 그렇다면 각 직무의 인재들이 원활하게 협력하기 위해서는 어떠한 역량이 필요할까요?

이번 시리즈에서는 다양한 직무와 협업하는 IT 기업 직장인 중에서 개발자가 함께 일하고 싶어 하는 동료에 대해 다루고자 합니다. 오늘은 그중에서 개발자가 생각하는 ‘함께 일하고 싶은 개발자'에 대해 살펴볼 예정입니다. 여러 의견을 듣기 위해 2년 차 개발자부터 10년 차 개발자까지 총 8명의 개발자와 인터뷰를 진행해 보았습니다. 과연 개발자는 어떤 개발자와 함께 일하고 싶어 할까요?

개발자 사이의 협업

프로그래밍의 범위가 넓은 만큼, 개발자의 종류도 매우 다양합니다. 흔히 생각하는 웹이나 앱 분야의 개발자를 비롯해서 서버, 게임, 인프라, AI, 머신 러닝, 블록체인 등 다양한 분야의 개발자가 존재합니다. 그래서 개발자 간에 협업하는 상황도 각양각색인데, 대표적으로 서버 개발자가 작성한 API 코드를 앱이나 웹 개발자가 사용하는 경우가 있습니다. 예를 들어 회원가입 요청 코드를 서버 개발자가 완성하면, 웹 개발자가 이를 활용하여 아이디와 비밀번호 등을 받아서 회원가입 절차를 수행할 수 있도록 웹페이지를 구성하는 것입니다.

사실 다른 분야보다 같은 분야의 개발자 간에 협업하는 경우가 더 많습니다. 하나의 기능을 나눠서 작업하거나, 같은 코드 베이스 내에서 서로 다른 기능을 개발하는 것처럼 말이죠. 코드를 작성하는 것 외에 라이브러리와 아키텍처를 결정하거나 규칙(컨벤션)을 설정하는 과정에서도 개발자 사이에 협업이 활발하게 이루어집니다.

가령 자바스크립트 개발자 중에서 어떤 사람은 세미콜론(;)을 붙이는 것을 선호하고, 어떤 사람은 아예 붙이지 않는 것을 선호합니다. 몇몇 개발자는 ‘서로 다른 방식이 섞여 있으면 작업하기 어려우니 하나를 결정해서 컨벤션으로 정하자’고 하고, 또 다른 개발자는 ‘컨벤션을 정하고 지키는 것도 리소스가 소비되니 개인이 편한 방식으로 작성하자’고 합니다. 단순한 예시를 들었지만, 이처럼 개발자는 수많은 결정 사항과 작업에 대해 다른 개발자들과 소통하고 협업합니다.

협업이 잦은 만큼 ‘함께 일하고 싶은 개발자'가 되는 것은 매우 중요한데, 개발자 사이에 소통의 어려움이 발생하는 상황은 다음과 같습니다.

1) 잘 모르는데 아는 척 넘어가는 사람

“다양한 캐릭터의 개발자가 있는데 보통 커뮤니케이션이 원활하지 않을 때 함께 일하기 어려운 것 같아요. 커뮤니케이션이 어려운 상황에는 여러 가지가 있는데, 제가 가장 크리티컬 하다고 생각하는 것은 ‘잘 모르는 데 아는 척 넘어가는 것’이에요. 몰라도 아는 척 어물쩍 넘어가는 동료와는 일을 분배할 수 없겠다는 생각이 들더라고요. 그런 분을 믿고 일을 부탁하거나 그분의 작업을 믿기 어렵게 되는 것이죠.”

함께 일하는 데 있어서 신뢰는 매우 중요한 것 같습니다. 모르는데 아는 척 넘어가는 동료가 있으면 그의 솔직함과 역량에 대해 신뢰할 수 없게 되고, 한 번 신뢰가 깨지면 어떤 일이든 함께 하기 어려워지게 됩니다. 결국 그 순간의 부끄러움을 벗어나기 위해 아는 척을 하는 것이 자신의 성장과 자신에 대한 동료의 신뢰를 모두 저버리는 행동이 될 수 있습니다.

2) 동료와 프로덕트를 고려하지 않는 사람

“개발하는 것을 좋아하고 잘하시는 분과 함께하면 좋은 영향을 많이 받는 것 같아요. 그러나 개발에만 너무 집중해서 다른 동료들은 안중에 없거나 프로덕트의 성공과 멀어지는 개발을 하는 분이면 함께 일하고 싶지 않더라고요. 개발을 통해 고객 가치를 만드는 것을 중요시하는 분과 함께하고 싶어요.”

아무리 개발을 잘해도 그 방향이 동료와 프로덕트에 맞지 않으면 함께하고 싶지 않다는 의미입니다. 개인적으로 저 역시 개발은 좋은 가치를 만들기 위한 수단이라고 생각합니다. 수단을 잘 활용하는 것은 매우 중요한 역량이지만, 수단을 목적보다 중요시하면 안 된다고 생각합니다.

함께 일하고 싶은 개발자

그렇다면 개발자들이 함께 일하고 싶어 하는 개발자는 어떤 유형이 있을까요? 이 질문에 개발자들은 아래와 같이 답변했습니다.

1) 병목을 줄일 수 있는 사람

“우선 대부분 제품 조직의 아웃풋에서 가장 시간이 오래 걸리는 직무는 개발자라고 생각해요. 기능 요구사항을 가장 마지막에 전달받으면서도 기술 구현 과정에서 맞닥뜨리는 문제에 따라서 구현이나 설계가 달라질 수 있기 때문이에요. 또 개발자는 기술 구현 상황에 따라 기획이나 디자인 변경을 역으로 요청해야 할 때도 많은데요. 이렇게 변경이 필요한 사항을 최대한 이전 단계에서 알아보고 커뮤니케이션을 시작하는 것이 아웃풋을 극대화할 수 있는 부분인 것 같아요. 결국 전달받을 내용이 도달하기 전에 미리 할 수 있는 작업을 쪼개서 준비해두고, 기획과 디자인에 대해 빠르게 피드백하는 것이 개발자의 중요한 역량이라고 생각해요.”

대부분의 제품 조직에서는 기획자, 디자이너, 개발자 순서로 작업이 이루어집니다. 기획자가 기획 문서를 작성하면 디자이너가 디자인 파일을 만들고, 마지막으로 개발자가 기획 문서와 디자인 파일을 보고 구현하는 방식입니다. 결국 프로세스의 마지막에 위치한 개발자가 제품 개발 타임라인에서 중요한 위치를 차지하게 됩니다. 이때 프로세스의 이전 단계들이 끝나는 것만 기다리지 않고 미리 준비해서 커뮤니케이션하면 팀의 생산성을 높이는 개발자가 될 수 있을 것입니다.

2) 팀플레이가 가능한 사람

“팀플레이가 가능한 사람과 함께 일하고 싶어요. 할 줄 아는 게 개발이고 잘하는 게 개발이라서 그냥 관성적으로 개발하는 사람이 아니라, 같은 목표를 갖고 그 목표에 공감하고 같이 즐기면서 성장하는 사람이면 좋을 것 같아요.”

결국 핵심은 함께한다는 사실입니다. 개발을 좋아하고 잘하는 것도 물론 중요하지만, 함께 소통하고 성장하며 공동의 목표를 위해 나아가는 사람이 팀에게 있어서 필요한 개발자라고 생각합니다.

3) 함께 성장하기 위해 노력하는 사람

“개발자라면 대부분 개인의 성장은 신경 쓴다고 생각해요. 그러나 팀과 팀원 모두의 성장까지 신경 쓰는 개발자는 상대적으로 적은 것 같아요. 좋은 팀원들과 이야기하고 논의하다 보면 나도 발전하게 되는데, 이런 선순환을 생각하며 팀 전체의 성장을 위해 노력하는 개발자와 함께하고 싶어요.”

함께 성장한다고 하면 거창하게 들리지만, 사실 함께 성장하는 방법은 매우 다양합니다. 내가 읽었던 좋은 개발 아티클을 팀원들에게 공유하고, 코드 리뷰를 하고, 열린 자세로 논의하는 등 이 모든 것이 나와 팀원의 성장에 도움이 되는 과정입니다. 어떻게 하면 이런 과정을 활성화하고 발전할 수 있는지 고민하는 동료가 있다면, 그 팀은 시너지를 내어 빠르게 성장할 것입니다.

4) 근거와 함께 의견을 설득하는 사람

“똑똑한 사람이면 좋겠어요. 사실 똑똑하다는 것이 많은 것을 담고 있는데, 문제 해결을 잘하는 것도 똑똑함이고 다른 사람의 제안을 열린 마음으로 받아들이는 것도 똑똑함이고, 자신의 의견을 근거와 함께 명확하게 설명하는 것도 똑똑함이라고 생각해요. 특히 근거와 함께 의견을 설득하는 것이 중요하다고 생각하는데, 가끔 보면 신기술을 무작정 좋아하는 개발자가 있는 것 같아요. 예를 들어 타입스크립트(Typescript)가 이제 막 나왔을 때 큰 이유를 설명해주지 않고 신기술이라는 이유만으로 도입했던 적이 있었어요. 당시에는 멀쩡한 코드가 에러로 표시되는 등의 버그가 많아서 불편했는데, 제대로 된 설득 과정이 없이 이러한 불편함을 겪게 되니 더욱 결정에 공감을 하지 못했던 것 같아요. 다행히 지금은 타입스크립트가 편하고 좋지만, 왜 도입하는지 저를 비롯한 다른 동료들에게 설명이 되었으면 좋았을 것 같다는 생각이 들어요.”

서로 다른 의견이 있을 때는 설득하는 과정이 필요합니다. 만약 설득의 과정 없이 결정을 통보받기만 하면, 실제로 작업을 하는 개발자는 금세 일에 의욕과 열정을 잃어버릴 수 있습니다. 반대로 적절한 근거와 함께 설득하는 과정을 거친다면, 설령 자신의 의견이 받아들여지지 않더라도 결과를 납득할 수 있게 됩니다. 최종 선택은 의사 결정권자가 하더라도, 결국 팀원들과 동일한 방향성을 유지하기 위해서 적절한 설득의 과정이 필요한 것입니다.

5) 본인의 생각이 있는 사람

“본인의 생각이 있는 개발자와 일하고 싶어요. 저는 면접에 들어갈 때마다 정답이 없는 질문을 준비해서 본인의 생각을 갖고 있는지 테스트를 해보는 편이에요. 인터넷이나 책에서 공부할 수 있는 것들은 사실 자기 생각이 아니더라도 얼마든지 말할 수 있어요. 그러나 정답이 없는 것들은 생각해보지 않으면 말하기 어려울 거예요. 가령 새로운 서비스를 시작할 때 MySQL이랑 NoSQL 중에서 어떤 선택이 좋을지 물어보는 것이죠. 이런 질문에는 정답이 없다고 생각하는데, 정답이 없는 질문에 납득이 가는 답변을 할 수 있는 개발자와 함께하고 싶어요.”

스택이 어느 정도 갖춰진 기업이나 환경에서 개발하다 보면 큰 고민 없이 개발하는 경우가 종종 있습니다. 그러나 본인의 생각 없이 단순히 개발만 하다 보면 급변하는 기술 생태계를 쫓아가지 못할 수 있습니다. 평소에 여러 기술과 스택에 대해 고민하지 않았던 사람은 새로운 기술을 어떻게 받아들여야 하는지 모르기 때문입니다. 당연하고 익숙한 기술이라도 가끔은 한 발짝 뒤에서 고민하고 판단한다면 더 깊은 생각을 가진 개발자로 성장하게 될 것입니다.

6) 말 잘하고 글 잘 쓰는 사람

“말 잘하고 글 잘 쓰는 개발자와 일하고 싶어요. 개발 실력이 좋은 것을 전제했을 때 이 사람이 얼마나 다른 사람에게 자신의 생각을 표현하고 설득할 수 있는지가 중요하다고 생각해요. 그런 능력을 갖추고 있는 사람과 함께 일하면 의견을 주고받기도 편하고 시너지도 잘 나는 것 같아요.”

위에서도 설득의 중요성에 대해서 언급한 적이 있습니다. 그러나 설득하겠다는 의지만 있고, 생각을 잘 전달할 수 없다면 설득의 과정이 매끄럽지 않을 것입니다. 원활하게 소통하고 싶다면 이야기를 듣는 다른 개발자가 얼마나 제대로 이해할 수 있는지 고려하는 자세가 필요합니다.

협업하는 동료를 원한다

개발자가 함께 일하고 싶어 하는 개발자에 대한 이야기를 쭉 들어봤는데, 사실 대부분의 이야기가 개발자에만 국한되는 내용은 아닌 것 같습니다. 개발적인 역량은 기본적이라고 생각해서인지 모르겠지만, 대부분의 개발자는 개발적인 역량보다는 함께 협업하는 측면을 더욱 고려하는 것으로 보입니다. 그런데 과연 다른 직군에 대해서도 개발자의 생각이 비슷할까요? 다음 편에는 개발자가 ‘함께 일하고 싶은 디자이너'에 대해 알아보도록 하겠습니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.