고독한 코드 미식가
자칭 슈퍼 개발자는 어떻게 회사를 망치는가
'내가 이 회사에서 코딩 제일 잘 하는 것 같다.'
어느날 내가 팀장으로 있는 팀의 부하직원이 연봉협상을 하면서 꺼낸말이라고 한다.
어떤 문맥에서 나온 이야기인지는 알 수 없지만, 제3자 입장에서 전해들었을때는 황당한 이야기였다.
분명 자신의 몸값을 생각하는 수준까지 올리기 위한 베팅이었을것이다.
하지만 그 바램은 이루어지지 않았고 머지않아 그 직원은 퇴사를 했다.
실력은 제법 있었고, 몇가지 시스템 개발이나 유지보수 등 실무도 그럭저럭 쳐내던 직원이었다.
그는 혼자서 많은 일을 했다고 생각할것이다. 회사의 여건을 생각하면 일정부분 그 생각에 동의한다.
하지만 당시 해당 직원에 대한 주위의 평판 및 인사권자의 평가는 그 기대와는 정반대였다.
사실 혼자서 일을 하게끔 한것은 업무상의 배려였다. 그는 협업이 아예 불가능한 사람이었다.
업무영역이 다른사람과 조금이라도 걸쳐있으면 항상 사고가 났다.
오죽했으면 그 직원을 담당했던 팀장이 3번이나 바뀌어서 결국 입사한지 얼마 안되는 나한테까지 왔을까.
나도 업무보고도 제대로 하지 않고, 근태가 불성실한 그를 관리하는것은 쉽지 않았다.
이 직원을 쓰기 위해서는 부단한 노력이 필요했다.
특정한 언어 및 도구의 전문가가 되는것을 희망했기에 일을 가려서 받으려고 했다.
그래서 회사에서 팀으로 내려오는 다양한 일이 있었지만, 그 직원에 역량에 맞는 일 밖에 줄 수 없었다.
협업도 할 수 없으니 주위와 소통을 할 필요가 없는 독립된 일을 골라내서 줘야했다.
이런일은 필연적으로 혼자서 하기에는 일이 많거나, 시간이 촉박한 일들이다.
그래서 아무하고도 소통하지 않은채 주위와 담을 쌓고 코딩만을 하고 있는 시간이 많았다.
업무가 계속 지연되어서 사람을 붙이려고 해도, 인수인계 및 업무공유가 불가능해서 혼자서 일을 끝내게 해야했다.
문제는 그러한 일들 조차 일정내에 끝내는 경우는 한번도 없었고, 결국 내가 투입해서 마무리해야했다.
협업이 안되고, 일정 준수도 안되며, 지시도 따르지 않는 직원의 평가가 좋을리가 없었다.
특정 도구의 전문가가 되고자 하는 그 생각을 이해하지 못하는것은 아니다. 나 또한 그랬기 때문이다.
코드 생산성이 높은것이 '슈퍼 개발자', '소프트웨어 장인'이라고 생각했고, 그렇게 되기 위해 부단히 노력했다.
프로그래밍에 관심이 많아서 이것저것 다양한 도구를 능숙하게 사용하기 위해 공부도 많이 했다.
정규직 경력으로만 합쳐도 10년이 넘는 개발자 생활동안 나는 그저 살기 위해 발버둥 쳤다.
내 손으로 일구고, 만들고 창조하는것이 내 생업이겠구나 하고 더욱 많은것을 만들 수 있는 기술 습득에 몰두했다.
어떤 소프트웨어 개발 현장을가든 해야할 일은 많고 어려웠다.
거기다 C++, MFC, Delphi 등 기존의 기술장벽을 넘기 힘들고 못마땅했다.
그래서 습득도 어렵고 레거시도 난장판인 기존것을 버리고, 생산성이 뛰어나다는 새로운 기술을 기웃거렸다.
나는 실용주의 프로그래머, 폴리글랏(Ployglot) 프로그래머라고 자위하며 다양한 도구와 기법을 익혔다.
Javascript, JAVA, C, C++, Go, Kotlin, C#, Delphi, Flutter, Ruby, PHP, Common Lisp, Clojure 등...
심지어 Common Lisp과 유사한 문법의 프로그래밍 언어를 만들어서 업무에 도입해보려는 시도도 했었다.
내가 원하는대로 소프트웨어 현장에서 도구를 선택할 수 없는 경우도 많아 아쉬운 기억도 있다.
물론 여러가지 여건상 실무에서 사용했을때 그렇다할 성과를 내지 못한 도구들도 많았다.
이러한 노력과는 달리 현실은 쉽게 바뀌지 않았다.
세월이 흐르고 어느 회사를 가도 마찬가지, 나는 어디를 가던 그곳의 대들보를 자처했다.
하지만 생산성 향상을 통한 목표달성, 문제해결은 현실과 동떨어져 있는것으로 보였다.
현실의 소프트웨어 업무환경과 동료들의 관심사 및 수준들이 나의 인식과 상당한 거리가 있었던것이다.
그렇게 지나고 보니 나 말고 주위사람은 모두 한심한 인간으로 밖에 보이지 않는 병에 걸렸다.
'주위 사람들이 능력없고 아는게 없으니, 힘들고 어려운 일은 모두 내 차지다'라고 체념해버렸다.
생각과 맞지 않거나 따라오지 못하면 무능하다고 치부해버린것이다.
이제와서 생각해보면 아주 부끄러운 일이다.
과거에 내가 불필요한 기술 장벽이라고 생각했던것들을 다른 방식으로 만들고 있었다.
젊은 혈기로 새로운 것을 학습하는 능력을 기술 장벽으로 활용해서 내 자리를 지키고자 했던것이다.
단지 다양한 도구를 사용할 줄 아는것이 유능한것인가? 지금은 단언코 '아니다'라고 할 수 있다.
건설, 인테리어, 청소 등 다양한 현장 업무에서도 다양한 기계로 수공구를 쓰는것보다 효율적으로 일을 한다.
효율적인 도구를 쓰는것과 그렇지 않은것은 일반적으로 생산성이 몇배이상 차이가 난다.
하지만 어떠한 일을 하던 그러한 도구들이 생산성을 높일 수 있어도 최종적인 일의 품질을 크게 좌우하지 않는다.
결국 그 일을 하는 사람이 얼마나 꼼꼼하느냐, 경험이 있느냐에 일의 품질이 좌우된다.
기술이 발전해도 모든 업무가 자동화 되지 못하고 사람이 꼭 필요한 이유가 이것이다.
소프트웨어 개발도 여기서 크게 벗어나지 않는다.
개발자는 제품 생산자이기도 하면서 문제를 해결하는 역할을 한다.
특정한 도구가 단위 업무를 빠르고 편하게 해결하는데 도움이 될 수는 있다.
하지만 전체 소프트웨어 개발 목표에서 일을 끝내는데는 아주 작은 영향을 미칠 뿐이다.
해당 도구를 사용함으로 인해서 고려해야할 점이 늘어나서 일의 총량이 변화하기 때문이다.
예를들어 ChatGPT등 생성형 AI를 이용해서 코드를 생성해서 빠른 개발을 하기로 했다고 하자.
이를 위해서는 AI에게 목표와 진행상황을 이해시키기 위한 정교한 프롬프트를 작성하는데 드는 시간이 추가된다.
그리고 상업적 가치가 있는 수준의 소프트웨어는 종종 대형화 되기 때문에 AI가 한번에 모든 논리적 문맥을 기억하고, 요구사항의 변경을 대처하는것은 아직까지는 힘들다.
결국 일의 품질을 높이고, 끝내는것은 사람이 할 일이다.
사람이 AI가 만든 코드를 이해하고, 구성하고, 디버깅해야하는데 오히려 직접 짜는것보다 많은 시간이 걸리기도 한다.
이러한점은 AI 기술이 발달됨에 따라 점차 많은 부분에서 사람이 필요없는 수준까지 편리해지겠지만, 결국 AI는 사람이 사용하기 위한 도구의 수준에 머무를것이라고 생각한다.
일을 끝낸다는것은 목표를 설정하고 해당 목표에 근접해가는 과정을 말한다.
처음 잡은 목표를 달성했다해서 전체 일은 끝나지 않을 수 있다.
그렇기에 계속된 목표 설정과 달성을 반복해나간다. 그 과정에서 다양한 업무가 파생된다.
이러한 업무들을 완수해 나가는것으로 사람들에게 의미가 있는 가치를 만들어 나간다.
사람은 대부분 혼자서 그 많은 일을 할 수 없다.
그래서 팀을 만들고, 회사를 만들어 다양한 사람들과 만나고 협업하며 일을 해 나간다.
제 아무리 뛰어난 축구선수라도 혼자서 90분 경기를 치를 수 없는 일이다.
대부분 사람들이 '슈퍼 개발자'에 대해 잘못된 개념을 가지고 있다.
슈퍼 개발자는 혼자서 빠르게 많은 코드를 생산하는 사람이 아니라, 다른 사람들의 실수에서 오는 시간낭비를 줄여서 전체 조직의 생산성을 높이는 사람이다.
코딩 능력도 중요하지만 기본적으로 협업을 잘 하는 사람인것이다.
많은 회사나 개발자들이 일정 규모 이상의 소프트웨어 개발을 혼자서 할 수 없다는것을 종종 간과한다.
그래서 다른 사람들과 협업을 하는 방법에 대해서 크게 고민하지않는다.
그 결과 프로젝트에 얼마나 개발자를 많이 투입시키든 제대로된 협업이 되지않고 오히려 서로를 방해한다.
협업을 위한 방법이나 도구들도 그저 프로젝트를 수행하는데 꼭 필요할때만 건성으로 따를 뿐이다.
생각없이 프레임워크화 되어있는 구조를 따라 MVC를 맞춰서 코딩할뿐 그게 무슨 의미인지 고민하지 않는다.
소프트웨어를 설명하기 위한 설계 문서를 쓰지만 조금만 지나면 현행화 되지 않은 쓸모없는 정보가 된다.
코드에 주석을 쓰지만 전체 구조를 파악할만한 클래스, 메서드에 대한 주석을 현행화 하는것을 게을리 한다.
코드 가독성을 중시한다면서 코드와 주석에 탭과 스페이스를 오가며 오와 열을 맞추는데 시간을 쓰고 있다.
svn이나 git 등 버전관리 도구의 사용법과 운용 방법을 몰라 동료가 작업한 코드를 종종 날려먹는다.
코드 한줄 쓰는것 보다 이러한 문화를 개선하는것이 가장 시급하다.
이해관계자간에 손발이 안맞아서는 성공할 일도 실패하게 된다.
촉박한 일정에 빠르게 일을 진행하기 위해 업무 영역을 나눠서 일을 진행하지만 서로를 방해하다가 자멸할것이다.
프로젝트에서 개발자의 역할은 전체 프로젝트가 끝날때까지 기여할 수 있는 모든것을 하는것이다.
그렇기에 업무영역을 나누는것 보다는 교집합처럼 일정 부분 공유하는것이 더 나을 수 있다.
축구에서도 각자의 포지션이 있지만, 일단 뛰기 시작하면 그 자리에만 있어서는 경기에 대응할 수 없는것과 같다.
이를 위해 당장 페어프로그래밍을 도입하지는 못하더라도 관심사를 공유하고 서로 논의하는 문화가 필요하다.
귀찮더라도 주기적인 코드리뷰를 통해 동료가 무슨일을 어떤 생각으로 하는지 들어보는 시간을 가져보자.
그 과정에서 소프트웨어를 어느 수준까지 문서화를 하는게 커뮤니케이션에 좋을지 도출해낼 수 있을것이다.
개발자에게 있어 커뮤니케이션 능력이란 무엇인가?
그것은 '배움과 문제해결에 닫혀있지 않은 자세'이다.
남의 일이라고 생각하지 말고 다양한 어려움을 함께해야하며, 생소한 지식과 관심사라도 필요하다면 시간을 들여 배워서라도 동료와 함께 할 수 있는 능력을 배양하는것이다.
다양한 사람과 함께할 수 있게 되었을때, 비로소 당신도 진정한 '슈퍼개발자'가 되어있을것이다.
