협업이 힘들었던 개발자의 특성

개발자는 기계와 일하지 않는다. 개발자는 사람과 함께 일한다.

물론 컴퓨터랑 싸워서 이겨야 하는(?) 상황도 가끔 있지만,

기존의 관습을 놓쳤거나 이해하지 못했을 때 발생하는 에러도 상당하다.

 

그리고 '기존의 관습'은 사람이 만든다.

하물며 로우 레벨의 칩셋이라도 입출력과 인터페이스는 사람이 정의했으니까.

 

ALU

 

그래서 개발자는 사람과 함께 일할 수 있는지가 개인의 기술 수준만큼이나 중요하다고 생각한다.

특히 비즈니스를 향해 한 배를 타고 있는 개발자들이라면 더더욱.

개개인의 다양성을 해치지 않는 수준에서 협업하기 어렵다고 생각하는 개발자의 특성을 뽑아봤다.

 

무접점 개발자

 

우직하게 개발만 하는 개발자.

같이 어울릴 수 있는 모든 기회를 차단한 채 자신의 코드에만 몰입한다.

항상 일하는 모습만 보는데 정작 무슨 일을 하는지 잘 모르겠는 사람들.

 

 

개발자들이 코드 밖에서 대화하는 이유가 따로 있겠는가.

어떤 도메인 보고 있는지, 어떤 부분에서 막혔는지 서로 얘기해가며,

이전에 했던 방법 있으면 알려주고, 대안도 제시하고,

작게나마 합의하고, 그 와중에 컨디션은 괜찮은지,

고민거리는 없는지 서로 관심 가져주면서 코드도 발전하고 일할 힘을 얻는다.

 

이분들과는 접점이 없으므로 그럴 계기도 없다.

코드 스타일, 기술 수준이 3개월 후도, 6개월 후도 그대로 유지가 된다.

 

리더에게는 어쨌든 우직하게 일을 처리해서 프로덕트를 보여줄 수 있다는 면이 장점이지만,

동료 개발자들이 볼 때는 종종 아쉬운 코드를 만들어 내는 사람이 된다.

"코드 봤는데요..." 하고 말 한마디 붙이기 어려운 그런 사람들.

 

자신의 코드를 사랑하는 개발자

 

자신의 코드를 너무 사랑해서 대규모 변경도 테스트&리뷰 없이 작업 브랜치에 내보내는 개발자.

전체 코드 수정 등 Side Effect를 불러 올 수 있는 수정도 거침없다.

 

그리고 이런 분들이 실수하면...

 

물론 나름의 전략일 수도 있다. 커뮤니케이션 비용을 줄이고 일을 빨리빨리 할 수 있고,

항상 PR을 보는 입장이 되니 코드 베이스를 자신의 컨벤션에 맞추기 유리하다.

하지만 그 결과로 다른 개발자들의 업무 시간이 희생될 수밖에 없다.

 

간혹 이런 분들이 직접 만든 컨벤션을 매우 강조하는 경우도 있다.

새로 온 개발자라면 물론 컨벤션을 눈여겨볼 필요가 있겠지만,

논의 과정을 거쳐서 만든 컨벤션이라면 그렇게 강조하지 않아도 팀원들의 머릿속에 남는다.

팀 컨벤션에 대한 무한 강조는 곧, 논의 과정이 부족한 컨벤션이었다는 반증이 된다.

 

주방장 개발자

 

주요 기능 개발은 자신, 혹은 신용이 있는 사람에게만 맡기고,

연차가 낮은 개발자에게는 마지못해 테스트 짜기나 문서화 등을 맡긴다.

 

물론 중요한 일이지만, 상대적으로 배울 수 있는 부분이 적은 일들.

특히 하나의 도메인을 맡아서 개발하게 시키는 일이 거의 없고,

신기능은 주로 직접 만드는 경우가 많다.

 

 

신입 개발자로서는 이런 개발자 밑에서 성장하기 어렵겠다는 느낌이 든다.

하물며 앙파 까기, 바지락 씻기, 청소하기, 설거지하기는 요리하는 사람의 기본기가 될 수 있겠지만

테스트는 코드 짜는 사람이 테스트를 염두에 두지 않으면 짤 수 없다.

기능 개발한 사람이 짜야 하고 기능 개발하는 도중에 짜야 한다.

다른 사람에게 테스트 코드 작성을 넘기면 버그나 좀 잡아 줄 수야 있겠지만

테스트의 장점은 아무것도 살릴 수가 없다.

 

그런 코드를 테스트하겠다고 고생은 고생대로 다 할 것이다. 크크

 

공유하지 않는 개발자

 

컨텍스트 없이 일을 넘기고 완벽한 처리를 기대하는 개발자.

제목만 있고 내용이 없는 업무를 쓰레기 뿌요처럼 다른 개발자에게 안겨준다.

 

바요엔!

컨텍스트를 공유하는 것은 일을 주는 사람이 나의 실수를 반복하지 않기 위함이다.

어떤 환경에서 어떤 요청을 날렸을 때 어떤 문제가 발생했는지,

그리고 어떤 방법을 시도했는지 정도를 공유해 주어야 타인의 리소스를 효율적으로 쓸 수가 있다.

내가 했던 실수를 타인이 반복하고 있다면 그것은 팀 전체로 봤을 때 리소스의 낭비이기 때문이다.

 

물론 컨텍스트 없이 오류가 뜨는 것만 보아서 단순히 귀띔해 주는 것도 충분히 도움이 된다.

개발자들 나름의 자존심이 있어서 엄청 파고들기 시작할 것이므로...

 

하지만 컨텍스트가 있는 업무인데, 그걸 파악하는 것까지 일을 준 사람의 몫으로 본다면,

크로스 체크조차 하지 않고 일을 준 사람에게 모든 책임을 지어준다면,

 

협업이라는 업무 스타일과는 거리가 있는 것 같다.

 

정리

 

문서화되지 않은 컨벤션 강요, 기존 코드에 대한 집착, 감정 싣기 등등...

나머지 생각나는 것들은 다 이 네 가지의 부산물 아닌가 싶다.

 

궁극적으로는 그런 생각이 든다.

협업을 잘 하냐, 못 하냐는 어쩔 수 없이 사람 대 사람의 문제가 된다.

 

내가 개발자로 계속 일한다면 기술 전문가의 트랙이나, 관리자의 트랙을 탈 텐데,

어느 쪽이든 새로 오는 사람들을 포용하고 따르게 하는 능력이 필요하지 않을까?

 

꽥꽥

 

그런 면에서 무한한 주의가 필요하겠다는 생각을 한다. 혹여나 닮지 않도록.

지금처럼 같이 일하는 사람들에게 쉽게 다가갈 수 있도록. 나도 노력 많이 해야 할 것 같다.