좋은 개발자 / 유명한 개발자
개발자의 대외적인 인지도와 실제 역량에 상관관계에 대해서 생각해본적이 있는가? 나는 사실 둘 사이에 특별한 관계성이 없다고 생각한다. 역량이 뛰어난 개발자가 유명할 수도 있지만 그렇지 않을수도 있다. 반대로 유명한 개발자의 역량이 뛰어날 수도 있지만, 그렇지 않을수도 있다. 둘 사이에 교집합은 있지만 집단간의 관계성을 설명해 주진 않는 것으로 보인다.
설명을 간단히 하기 위해 실제 역량이 뛰어난 개발자를 ‘좋은 개발자'라고 부르겠다. 나는 현업에서 ‘좋은 개발자’의 덕목은 기술로서 비즈니스의 성공을 돕는 것이라고 생각한다. 많은 기술적 지식을 가지고 있다고 할 지라도 그것이 궁극적으로 비즈니스적인 성취에 도움이 되지 않는다면 적어도 이 관점에선 좋은 개발자라 볼 수 없다.
기술 기업들의 블로그나 유튜브, 컨퍼런스(Google I/O, Amazon re:invent, Facebook F8등)들을 보면 자신들의 기술적 성취들을 많이 공개하고 있다. 글을 쓰고 발표를 사람들의 면면을 살펴보면 업계의 유명인들도 있지만, 그렇지 않은 사람들도 많다. 처음 보는 이름의 개발자들이더라도, 그들은 각자의 회사에서, 조직에서 성공 경험들을 만들어 낸 사람들이다. 그들이 일하고 있는 수 조에서 수 천억 가치의 회사를 직접 만들어 직접 내진 않았을지 몰라도, 회사에 크게는 수억원 가치의 이익을 가져다 주는 무언가를 달성했을 것이다.
성능을 개선하여 더 적은 장비로 더 많은 서비스를 제공하게 했을 수도 있고, 새로운 기술을 개발 또는 적용하여 전환율(Conversion Rate)을 올렸을 수도 있다. 이들은 이 성취로서 유명해질 기회를 얻었을 수는 있다. 하지만 그들이 유명했기 때문에 성취를 얻은 것은 아니다.
모든 회사와 개발자들이 이렇게 자신들의 성취를 공개적으로 발표할 수 있는 것은 아니다. 때문에 블로그와 같은 개인 활동이나 대외 활동에 시간을 투자하지 않고 회사 일에만 몰두하고 기여하는데 집중하다보면, 회사에서 좋은 성취를 이루어 냈다 하더라도 본인의 가치를 대외적으로 보여 줄 기회가 많지 않다. 회사 동료들에게는 이런 개발자들이 더 ‘좋은’ 개발자로 여겨질 수 있다.
그러나 시장에서는 이렇게 회사에 헌신하는 좋은 개발자들이 대외적인 인지도가 떨어진다는 이유로 저평가받고, 블로그, SNS나 대외 활동을 통해 인지도를 높인 개발자들이 오히려 더 대단하게 여겨지는 경우가 많다. 이런 상황에 박탈감을 느끼는 개발자들도 있을 것이다.
대부분의 회사에서 일반 개발자들이 기술 외적으로 바꿀 수 있는 것은 많지 않다. 심지어 기술적인 선택조차 그렇게 자유롭지 못한 경우가 많다. 그렇기 때문에 보통은 주어진 환경에서 최선의 결과를 만들어내는데 집중할 수 밖에 없다. 환경을 불평할 시간에 회사와 사용자에게 필요한 기능 하나라도 더 배포하려고 노력하는 개발자들도 많다. 나는 그런 개발자들이 좋은 개발자일 가능성이 크다고 생각한다. 회사를 위한, 곧 사용자를 위한 개발을 하는 것, 그것이 결국에는 비즈니스에 대한 기여로 이어질 것이기 때문이다.
그런데 이렇게 제품에 더 집중하다보면 그 외적인 것들에 대해 잘 신경 쓰지 못하는 경우도 많다. 이런 분들이 블로그나 대외활동 등을 통해 셀프 브랜딩에도 신경을 쓴다면 그 경험과 역량을 바탕으로 ‘유명한 개발자’가 될 수도 있다. 그렇게만 된다면 금상첨화겠지만 모두에게 그런 에너지나 욕망이 있는것은 아니다. 그저 묵묵히 개발하는 것만으로 만족하고 오히려 눈에 띄는것을 싫어하는 개발자분들도 많다는 것이 현실이다. 보통 이런 성향을 가진 분들이 좋은 개발자임에도 불구하고 유명하지 않아 제대로된 평가를 받지 못하는 경우가 있다.
유명한 개발자의 경우를 보자. 그들은 그들의 강점인 셀프 브랜딩 능력을 통해 기회를 쉽게 잡을 수 있는 편이다. 서두에서도 언급한 것 처럼 유명세와 역량간의 상관관계는 크지 않거나 거의 없음에도 불구하고, 기술적 역량 판단이 쉽지 않은 조직, 또는 채용 마케팅적인 측면으로 그들의 유명세가 필요한 조직에서는 그들이 선호될 수 있다. 이 유명한 개발자들이 만약 역량도 탁월하여 조직에서 원하는 역할을 잘 해낼 경우에는 아무런 문제가 없다. 하지만 그렇지 않을 경우엔 트러블이 생길 수 밖에 없다.
초기 스타트업과 같은 조직의 경우 기술 인력이 없거나 기존 구성원들의 경력 또는 역량이 부족해 채용과정에서 역량에 대한 체크를 면밀하게 하기 어렵다. 그러다보니 외적으로 보이는 부분들에 혹하기 쉽다. (사실 채용 과정에서 역량 판단이 정확히 되는 경우가 드물다. 다만 큰 회사들은 프로세스가 길다보니 그 사이 뭐라도 발견할 가능성이 있지만.) 이런 경우 역량이나 산출물의 수준을 판단할 수 있는 환경도 아닐 경우가 대부분이기에, 비싼 비용을 들여서 데려온 개발자가 일을 제대로 하고 있는지 알기도 어렵다. 모든 것이 잘 돌아간다면 문제가 없겠지만, 새로 들어온 개발자가 기존 코드에 대한 불평, 지금 사용중인 기술에 대한 불평, 문화와 동료들에 대한 불평을 쏟아내기 시작한다면? 뭘 하고 있는지도 모르겠는데 이 기술을 써야됩니다, 이 언어를 써야됩니다라는 말만 주구장창 하고 있다면? 🔴 빨간불이다.
그 회사에 모든 걸 걸고 있는 임원들이나 기존 구성원들은 선택의 여지가 없다. 현실이 암담해도 당장은 레거시를 안고 가야할 경우가 많다. 하지만 언제 어디로라도 튈 수 있는 개발자들이라면? 마음에 안드는 것이 있으면 내부 총질만 하다가 날라버리면 그만이다. 그들에겐 오라는 곳들이 줄을 서 있을 태니까.
문제는 그렇게 회사를 옮겨다니며 본인의 경험들을 과대 포장하는 것이다. 보통 이런식으로 회사를 옮기게 되는 경우 회사에 특별한 산출물을 남기지 않았을 가능성이 더 크다. 남기지 않았으면 오히려 다행이다. 기존 시스템을 뒤집어 엎어놓고 갔다면 남은 사람들이 수습을 해야하는 경우도 많다. 그렇게 뒷 수습을 하는 사람들은 주로 회사와 서비스에 헌신하는, 동료들에게 ‘좋은 개발자’로 여겨지는 분들인 경우가 많다. 누군가의 뒷 수습을 한다는 것은 책임감과 실력 둘 다 뒷받침이 되어야 하기 때문이다.
여기서 유명 개발자들에 대한 안좋은 경험들이 생기기 시작한다. 실제로 업계에서 직간접적으로 비슷한 경험을 하고 유명한 개발자들에 대한 편견을 가지고 있는 개발자 분들을 많이 보았다. 새로운 플랫폼, 프레임워크, 언어 적용한다고 뒤집어 엎다가 나가놓고서는 자신의 블로그나 유튜브, 또는 밋업 등에서 그것을 커리어로 포장한다. 그리고 그걸로 그들은 새로운 기회를 다시 잡는다. 남아서 뒷처리를 했을 개발자들에겐 울분이 터지고 박탈감 느껴지는 일일 것이다.
이런 일은 업계에 개발자에 대한 인식에도 영향을 준다. 회사를 운영하는 입장에선 ‘유명하고 비싼 개발자 써봤는데 별거 없더라.’ ‘새로운 기술이 좋다 그래서 적용 해봤는데 문제만 많고 별로더라.’라는 편견을 가지게 될 수도 있다. 이것은 개발자와 기술에 자체에 대한 불신으로 이어지게 된다. 누군가의 커리어 한 줄, 블로그 글 하나를 위한 땔감이, 개발자라는 직군 전체에 대한 평판을 깎아 내리는 결과로 이어질 수도 있는 것이다.
흔히 ‘네임드’라고 불리는 이런 유명인들은 스터디, 밋업, 커뮤니티 등을 통해 형성된 그룹에 속해있는 경우가 많다. 간혹 온,오프라인에서 친분을 과시하기도 한다. 유명인이 포함되어있다보니 그 그룹을 보는 다른 개발자들은 저 그룹의 개발자들은 역량이 뛰어나거나 특별한 사람들인가 하는 생각도 들게 한다. 하지만 개개인의 역량은 그 개인에게 달려 있는 것이지 어떤 그룹에 속해있는 것 만으로 그 사람의 역량을 판단 할 수 있는 것은 아니다.
인맥 형성이나 과시 그 자체가 문제는 아니다. 단순 친목만이 목적이라면 괜찮겠지만, 서로가 서로는 포장하고 본인들과 의견이 다른 사람이나 집단은 폄하하여 여론을 좌우하게 된다면 그것은 위험한 일이다. 실제로 페이스북이나 트위터와 같은 소셜 미디어에서 특정 글이나 인물에 대해 자기들끼리 ‘조리돌림’성 발언들을 하는 경우들이 보인다. 이런 집단은 앞서 말했던, 남은 사람들이 뒷처리를 해야만 했던 사례들도 좋은 것으로 포장한다. 실제로는 개인에게도 회사에게도 실패였던 경험이 실패가 아닌 것으로 포장되며 발전할 수 있는 기회를 줄여나간다. 그리고 변명하기도 한다. ‘오너, 문화, 시스템, 기존 구성원들이 별로인데 일개 개발자가 할 수 있는것이 무엇이 있느냐?’
하지만 어떠한 환경에서도 맡은바 역할을 다하고 심지어 성과도 만들어 내는 개발자들은 있다. 모든 환경과 여건이 갖추어져야 역량을 발휘할 수 있는 개발자를 과연 좋은 개발자라고 할 수 있을까?
결론적으로 하고 싶은 이야기는, 개발자에 대한 평가 역시 궁극적으로 그가 회사의 비즈니스적인 성과에 얼마나 기여를 했는지로서 이루어져야한다는 것이다. 얼마나 많은 기술이나 언어를 사용할 줄 알고, 얼마나 많은 블로그 글이나 책을 썼으며, 얼마나 많은 발표를 했는지가 아니라. 그리고 그런 사람들을 치켜세워주고 서로 포장해주는 풍토 역시 개선되어야한다고 생각한다.
물론 이런 사람들도 훌륭한 능력을 가지고 있는 사람들이다. 다만 그 역량으로 회사와 사용자, 동료들을 도울 것이 아니라면 개발자보단 학자나 저자, 강사나 에반젤리스트를 추천하고싶다. 오픈소스 프로젝트나 연구기관을 위해 일하는 방법도 있겠다. 이런 방법들로도 충분히 다른 개발자들에게 도움을 줄 수 있다.
직업인으로서 개발자라면 기술적 욕심보다는 서비스의 성공에 모든 역량을 투자하자. 그것이 당신과 다른 모든 개발자의 평판을 높이는 길이다. 물론 역량이 된다면 둘 다 이루면 되는 것이고. 실제로 원하는 기술을 마음껏 시도하며 비즈니스도 성공시키는 개발자들도 많다. 이런데서 진짜 기술적인 역량이 드러나는 법이다. 이런 사람들은 자연스럽게 유명해지기까지 한다. 긍정적인 방향으로. 첫 문단에서 둘이 관계가 거의 없다고 했었는데 조금 정정해야겠다. 진짜로 좋은 개발자는 본인 의사와 관계 없이 유명해질 수도 있다고.
- 2022. 09. 12, 전체적으로 고쳐 씀.
