커뮤니티 글에서 최근 꾸준글로 보이는 한 친구가 있다. 자신을 컴퓨터공학과 학생으로 소개하면서, 알고리즘 문제를 풀다보니 너무 어려워서 전공을 바꿀까, 자신은 보잘것 없는 개발자가 될 것이라며 자학을 꾸준히 하고 있었다. 무슨 문제를 못 풀어서 저러는 건지는 모르겠지만, 갑자기 내 대학원 때 생각이 나서, 주저리 적어본다.

슈퍼 개발자의 존재

개발조직 사이에서, ‘100명의 개발자 중 1-2명의 슈퍼 개발자들이 나머지 개발자들보다 일을 잘 한다’ 라는 말을 흔히들 한다. 이런 슈퍼 개발자를 모셔 와야 조직의 퍼포먼스가 올라간다는 것이다. 그러면 이 ‘나머지 개발자’ 들의 운명은 어떻게 되는 것인가? 조직의 입장에서, 슈퍼 개발자를 모셔 왔으면, 나머지 중 하위 10명 정도는 잘라내도 괜찮을가? 개인의 입장에서, 내가 슈퍼 개발자가 아니면, 모가지를 내놓고 회사를 다녀야 할까?

내 생각엔, 이런 뛰어난 개발자는 축구로 치면 스타 플레이어의 크랙 (crack) 이다. 대치 상태를 뒤집고 돌파할 수 있는 천재적인 능력이나 역량을 지닌 선수를 말한다. 프로그래머는 문제를 해결하는 사람들이므로, 어떤 문제에 부딪혔을 때, 누구보다도 문제를 빠르게 해결하거나 그 방법을 제시할 수 있는 사람들이 슈퍼 개발자라면, 괜찮은 비유인 듯 하다. (어렵지만) 축구에서도 스타 플레이어 혼자 끝까지 달려 수비수를 제끼고 골을 넣을 수 있다. 프로그래머도 혼자 끝까지 코딩해서 문제를 풀 수 있다. 이 부분도 어느 정도 맞다.

하지만 한 골이 아니라 경기 전체, 한 문제가 아니라 조직 비즈니스 전체에서는 실패할 확률을 줄이면서 성공으로 이끌어야 하는 책임이 있다. 한 두번이면 몰라도, 축구선수가 크래킹을 시도 때도 없이 한다던지 독단적으로 볼키핑을 하거나 요구한다면, 상대방이 수비 전술을 바꿔 꽁꽁 묶어버릴 수도 있고, 다른 선수의 사기를 떨어뜨릴 수 있다. 감독은, 그 선수의 뒤에서 볼을 주고 받아 줄 다른 선수들과 긴밀한 유대를 가지도록 독려해야 하며, 스타 플레이어의 역량과 조직 운용에 균형을 맞춰야 한다.

혼자 하는 프로그래밍도 마찬가지인데, 뒤에서 따라가며 이해하고 테스트를 하거나 리뷰를 해 줄 다른 개발자가 필요하다. 그렇지 않으면, 문제 해결에 혈안이 된 나머지 다른 버그를 놓치거나 코드 품질의 저하, 조직 문화 저하를 가져올 수 있다. ‘혼자 가면 빨리 가고, 함께 가면 멀리 간다’ 라는 말이 괜히 있는 게 아니다.

결국 시스템만 남는다

하지만 현실적으로, 슈퍼 개발자, 스타 플레이어가 물론 경기를, 비즈니스를 성공적으로 이끄는 모습은 그렇게 놀랄만한 일이 아니다. 그들은 비단 한 골이 아니라, 아예 제품을 일신시켜줄 그런 멋진 도약을 해내곤 한다. 인정한다. 하지만 조직 입장에서는 이럴 때 일 수록 경계해야 한다. 매니저는 항상 “저 선수/개발자가 떠나면 우린 어떡하지?” 라는 고민을 해야 한다.

조직은 그 자리에 머문다. 스타 플레이어 뿐만 아니라 일반 개발자, 매니저까지 모조리 떠날 수 ‘있다’. 남는 건 바로 제품(코드)와 시스템이다. 이것들이 스타 플레이어에 의존한다면, 떠나고 나서도 제대로 작동할 가능성은 제로에 가깝다. 조직 입장에서는, 이 부분이 핵심이다. 그래서 잘 하는 개발자를 모셔오는 것도 좋지만, 이렇게 영입하고서도 조직 시스템을 해치진 않는지 고민해야 한다.

개발자의 역할

이제 개발자 개인의 관점에서 생각해보자. 사실 ‘나는 슈퍼 개발자가 아니구나’ 라는 생각을 늘 하고 있었는데, 이런 고민을 이렇게 글로 풀어보고 싶었다.

앞서 말했듯이 조직은 슈퍼 개발자에 의존하지 않아도 작동할 시스템과 제품 코드를 유지하고자 한다. 내 결론은, 이 시스템을 잘 이해하고 따르기만 해도, 내부 코드를 잘 이해하고 있기만 해도 조직에서의 가치는 올라갈 수 있다. 더 나아가면, 조직을 너무 잘 이해한 나머지, 문제 해결을 할 수 있는 슈퍼 플레이어에게 패스를 잘 할 수 있는, 플레이메이킹을 할 수 있다. 이런 개발자를, 사일로 (silo) 를 연결해 주는 브릿지 (bridge) 역할을 한다고 한다. 조직에서는 정말 보배같은 존재다.

그런데 이 부분에서도 경쟁력이 필요하다. 시스템을 잘 이해한다는 것은, 시스템 안에서 정보를 누구보다 빨리 찾아낼 줄 알아야 하고 다른 팀과 소통을 빠르게 할 수 있어야 한다는 뜻이다. 내부 코드를 잘 이해하고 있다는 것은, 자기가 담당하거나 담당했던 부분에 대해서는 누구보다 자신있게 대답할 준비가 되어 있어야 한다는 것이다. 그냥 이해하면 그냥 임금노동자일 뿐이다.

만약 시스템이 정말 안 맞는다, 코드가 정말 어렵다면 방법은 두 가지다. (야근을 강요하는 것으로 들렸다면 미안하지만) 자투리 시간에 공부를 더 해서 경쟁력을 올리거나, 그렇게 해도 안 되겠으면 자기에게 더 잘 맞을 것 같은 조직으로 이직해야 한다.

개발도 사람이 한다

결론은, 개발도 결국 사람이 하는 것이다. (물론 기본은 해야겠지만) 개발 능력이 슈퍼 개발자에 비해 부족하다고 좌절할 필요는 없다. 나도 그런 벽은 꽤나 많이 경험해 봤고, 좌절도 해 보고 노력도 해 봤지만 큰 소용이 없다. 그보다는, 다른 방면으로 조직에 기여할 수 있는 부분이 있는지 찾아보는 편이 훨씬 빠르다.

나는 개인적으로 문서화하는 걸 즐겨해서 보고 들은 것, 경험한 것을 사내 위키에 정리해 둔다. 한 가지 원칙은 ‘이 문서는 반드시 남들이 볼 것이다’ 라는 생각으로 탈고해야 한다. 그렇게 하지 않으면 미래의 나 조차 문서를 이해하지 못하기 때문이다. 이런 습관이 커리어에 많은 도움이 되었다.

회사에 취직하지 않았다고 하더라도, 똑같은 공식을 오픈소스 프로젝트나 동아리, 하다못해 개인 토이 프로젝트에 적용하면 어떨까. 개발조직 세상에는, 코딩 외에 할 일이 너무나도 많다.