Disclaimer

1. A급이 최고 수준인 것으로 설정하겠다.
2. 생각해보니 개발자 말고 모든 분야에 해당될 것으로 믿는다.

이유

만약 어떤 사유로든 A급 인재가 아닌 개발자를 채용했다고 치자.

팀에 피해가 간다. 이렇게 말이다:

1. PR review 시간이 길어지고 소모적이게 된다. 이미 A급이면 알고 있을 걸 모르니까, 보통은 본인보다 실력이 좋은 (그 사람이 A급일 수도 있다) 구태여 시간을 들여 증명하고 이해시켜줘야 한다. 이렇게 하면 A급 개발자는 본인 일도 할 시간을 더 뺏긴다. 이렇게 되면 A급 개발자가 의미있는 코드를 쓸 수 있는 시간은 줄어든다. 그 시간에 리뷰해야 하니까.

2. 우여곡절 끝에 PR이 리뷰되고 머지가 돼도 사실은 코드를 +500 -500줄 바꿨다면 모든 줄을 다 보기는 어렵다. 핵심적인 로직이나 기능 위주로 보게 되기 마련이다. 구태여 CSS나 세세한 문법까지 봐 줄 필요는 없지 않은가. 기본이니까. 그렇지만 A급 개발자가 아닌 사람은 그곳에서 문제를 발생시킨다. 버그나 문제가 생기고 그 곳을 다시 고쳐야 하는 상황에 빠진다. 그러면 팀의 누군가가 투입되서 그것을 시간을 사용하여 고칠 것이다. 그러면 또 그 사람의 시간을 낭비하게 된다. 그러면 처음 그 코드를 적은 사람이 사용한 시간은 결국 0의 가치를 생산한 것이니 시간을 낭비했고, 그것을 고치는 사람의 시간도 원래 존재할 시간이 아니었으니 낭비한 게 된다.

3. 반대로 A급 개발자의 PR에 달리는 리뷰의 수준도 떨어지게 된다.

4. 품질 나쁜 코드를 생산하여 다른 개발자가 좋은 코드를 보지 못하게 만든다. 코드만 좋다면 서로의 코드를 보면서 많이 배울 수 있다. 그래서 오픈 소스를 많이 하라는 말이 여기저기서 있긴 하지 않은가. 그런데 좋은 코드를 생산하지 않는다면 그의 코드가 팀에게 주는 이익은 단지 그 코드 자체가 유지하고 있는 그 기능 뿐이다. 그 이상도 그 이하도 아니다.

5. 평상시 많은 도움을 필요로 한다. ‘언제든지 도와드릴게요’는 맞는 말이다. 그렇지만 언제든지 도와드리면 그를 도와주는 A급 개발자의 효율은 떨어진다. 본인 개발을 할 시간이 없으니까. 물론 팀 전체의 효율이 높아지면 좋은 일이다. 하지만 그렇지 않을 때는.. 팀에 피해가 간다.

6. 기술적으로 용납되지 않는 이상한 주장을 해서 팀의 에너지와 시간을 소비시킨다. 많은 기술 회사들은 평등함을 중요시한다. 그런데 문제가 있다. ‘이 상황에는 이렇게 해야 한다’라는 기술적인 주장이 있다고 치자. 그러면 그 주장이 객관적으로 검사해 봤을 때 다른 주장에 비해 옳다고 하더라도 기술적인 역량이 따라오지 못하는 개발자는 그 주장을 완전하고 올바르게 평가할 수 있는 능력이 부족하다. 왜냐하면 충분한 이해가 따라오지 않는데 그 주장을 타당한 근거로 옹호하거나 반대할 수는 없기 때문이다. 그러면 또 옳은 주장을 하는 쪽에서 이 사람을 이해시켜줘야만 팀이 한 발짝 앞으로 갈 수 있다. 물론 반대 의견이 좋지 않다는 말은 아니다. 단지 반대 의견이 나왔을 때 그것은 타당해야 한다. 근데 타당하지 않은 반대 의견이 나왔을 때 묵살시켜버릴 수도 없고… 왜냐하면 우리 팀은 ‘평등’하니까 이 사람을 이해를 시키고 동의까진 아니더라도 반대에서 벗어나게 해야만 앞으로 갈 수 있다. 이럴 때는 두 가지 방법이 있다. 이 사람의 기분은 나쁘지만 그 사람의 의견을 묵살하고 결정을 내리는 것. 다른 방법은 이 사람을 처음부터 끝까지 이해시키는 것이다. 알겠지만 후자는 시간을 또 투자해야 한다.

   그러니까, 정확한 예시가 없어서 다시 예시만 하나 들어서 설명하겠다. 본인 나이대의 평균적인 지능을 가진 초등학생 아이가 있다고 하자. 부모님은 음식을 골고루 먹으라고 한다. 부모님의 주장의 이유는 다음과 같을 것이다:

   1. 건강할 확률이 높아진다
   2. 건강하게 성장하는 게 중요하다
   3. 건강하면 대체적으로 행복하다
   4. … 등등, 살아온 세월에서 나오는 수도 없이 많은 이유를 댈 수 있을 것이다.

   초등학생 아이도 반대를 한다. 아이의 이유는 다음과 같다:

   1. 시금치가 맛이 없다.

   물론 사실이지만 타당하진 않다. 주장이 타당할 수 있으려면 가장 먼저 그 음식을 먹지 않아도 충분히 건강할 수 있다는 조건을 충족해야 할 것이다. 예를 들면 시금치가 맛이 없어서 먹지 않을 것이지만, 시금치로부터 얻어지는 영양분을 시금치 맛이 하나도 나지 않는 시금치로 만든 특제 소스가 들어간 파스타로 대체한다는 주장 같은 것이다. 그렇지만 이 아이는 그런 주장을 formulate 할 ‘실력’과 ‘지식’이 부족하다. 그럼에도 불구하고 아이는 본인의 주장이 인정되기를 원한다. 그러면 골치가 아파오기 시작한다. 그것이 스타트업에서 좋은 개발자가 겪는 고통일 것이다.

   현실

   알겠지만, 현실은 그렇지 않다. 가장 좋은 시나리오는 사실 초기에 투자를 왕창 받게 되어 좋은 개발자만 높은 연봉을 주고 데려오는 것이다. 슬프게도 그렇지 않은 케이스가 대부분이다. 그렇다면 뭘 할 수 있을까.

   1. 폭발적인 성장 가능성이 뚜렷한 개발자를 데려온다. 주식으로 치면 undervalued 된 개발자를 뜻한다. 싼 가격에 좋은 투자를 할 수 있다. 이런 개발자는 앞에서 언급한 4가지의 특성을 처음에는 가지고 있을 수도 있으나 비교적 빠른 시간 안에 탈바꿈 할 수 있을 것이다.
   2. A급 개발자가 아닌 개발자를 육성하는 것을 즐기거나 적어도 용납할 수 있는 A급 개발자를 데려온다. 이 사람의 역할은 ‘선생님’이다. 이런 일을 즐겨 하는 사람이 있을 수도 있다.

Written by Joel Mun. Joel likes Rust, GoLang, Typescript, Wasm and more. He also loves to enlarge the boundaries of his knowledge, mainly by reading books and watching lectures on Youtube. Guitar and piano are necessities at his home.