어떤 개발자가 개발자들 사이에서 인정 받을까?
슈퍼개발자가 되고싶은 보통개발자
개발자들 사이에서 인정받는 슈퍼 개발자들의 모습은 우리 개발자들이 어떻게 성장하고 싶은지를 잘 보여준다. 개발자들이 선호하는 개발자는 넓고 깊은 지식을 기반으로 기술적 능력이 뛰어나며 이를 잘 표현하고 심지어는 가만히있어도 그런 느낌이 새어나오는 사람이다.
프로젝트를 함께하는 동료들과 팀원들에게 인정받고 싶은것이 기본이다. 개발자들이 맡은 역할은 기술적인 이해를 기반으로 기획자들이 그려온 것들을 구현하는 일이다. 내 능력밖의 일이라 할 수 없거나 여건상 이 일은 불가능하다고 말할때 개발자들의 마음은 불편하다. 그래서 능력이 되는 최대한모든걸 해주고 싶은 마음이 있는데, 여기서 말하는 ’능력’이 하루아침에 생기는 것이 아니니 역량이 뛰어난 개발자들이 더 멋지게 보인다. 이 능력을 키우기 위해 선배 개발자들에게 물어보고 어떻게 하면 일을 가능하게 할지 기술을 공부한다. 그리고 이를 통해 얻은 기술적 통찰을 블로그에 정리하거나 기술적 문서로 쌓아가며 성장을 축적한다.
또 커뮤니케이션 능력이 특히 좋은 개발자들이 있다. 이 일정에는 절대 불가능하고, 이 스펙은 절대 구현이 불가능해서 안 된다는 불편한 이야기를 해야하는데, 이런 환경에서도 동료들에게 고맙다는 말 까지 들으며 잘 소통하는 개발자들이 간혹 있다. 심지어 본인 기술 블로그나 깃허브에 공부한 내용을 올려서 사람들의 칭송을 받고 컨퍼런스같은 행사에 나가서 발표까지 잘 하는 사람들도 있다. 매일 쏟아지는 업무 속에서 열심히 버티는 보통 개발자들에게는 그들이 신처럼 보이기도 한다.
기획자의 입장에서 개발자들을 생각하면 그들은 모든 것들을 개발할 수 있고, 우리 소프트웨어를 어떻게든 만들어 줄 것이라는 기대감을 갖게 된다. 하지만 당연하게도 개발자들은 만능일 수 없다. 새로운 기술들은 매 해 소화할 수 없을 만큼 많이 생산되며, 기획자들이 요청하는 내용은 대게 업계 최고의 최신 기술을 지향한다. 우리가 주변에서 원하는 멋진 기획자가 되고싶은 것 처럼 개발자들도 협업부서와 주변 동료들에게 인정받고 싶은 마음이 있다. 이번 장에서는 특히 개발자들 가운데서 이사람은 정말 멋지다고 인정받는 사례와 그 특징들을 알아보려고 한다.
내가 만든 에러나 장애를 의연하게 대처하는 선배 개발자를 보며 멋있고 심지어 경이롭다고 생각한 적이 많다. 나 뿐만 아니라 많은 개발자들이 대부분 그런 경험이 있을 것이다. 짧게는 몇시간 길게는 며칠동안 머리싸매고 있던 문제를 보자마자 순식간에 해결해 내는 모습은 마치 영웅처럼 멋지다. 경험한 일 중에 특히 기억에 남는 이야기가 있다.
게임사에서 일할 때 5년간 수백억을 들인 대규모 신작 게임이 런칭하는 중요한 날이 있었다. 수백명이 몇년간 준비한 작품이 세상에 나오는 날, 전 직원의 시선은 서비스 오픈에 집중됐다. CBT를 수 차례 진행하고 내부 테스트도 여러 차례 진행했지만 많은 사람들은 긴장하고 오픈을 준비했다. 준비를 철저히 했음에도 언제든 사고가 터질수 있기 때문이다. 오픈 전 점검을 하며 여러 파트에서 문제가 발생한 것을 감지했다. 대부분의 문제들은 새벽부터 즉각 수정했기 때문에 전체 오픈 일정에 영향을 주지 않고 신속하게 처리됐다. 하지만 안타깝게도 치명적인 문제가 발생했다. 알 수 없는 이유로 여러 서버들의 데이터를 중계해주는 역할을 하는 미들웨어가 일정 규모 이상의 트래픽이 되면 이를 견디지 못하고 죽어버리는 문제였다.
상황은 심각했다. 제일 비싸고 효과가 좋은 홍보수단인 네이버 메인베너광고를 송출하는 시점에 광고를 보고 새로 진입한 유저들이 게임을 실행하지 못하고 있었다. 해결이 되지 않고 시간이 흐르자 상위 의사결정자들이 하나둘 개발팀 자리로 모였다. 오래 걸리지 않아 대표이사도 내려와 언제 해결되냐고 보채기 시작했다. 아찔한 상황이었다. 많은 사람들이 보고있는 상황이면 더 긴장하기 마련이다. 특히 회사 최고 의사결정권자가 바로 뒤에서 지켜보고 있으니 담당 개발자의 긴장감은 더 커졌다.
해결이 안되자 몇 달 전 버전으로 프로그램을 롤백도 해보고 이미 퇴사한 옛 담당자까지 급하게 호출해서 해결해보려 했지만 수확이 없었다. 이때 이미 실무에서 손을 뗀 기술센터장님이 갑자기 등장했다. CTO역할을 겸임하던 그는 한동안 화이트보드에 무언가를 적으며 질문을 하더니 게임서버와 소켓통신을 하는 코어 로직을 손봤다. 그가 등장하고 30분이 채 되지 않아 조직 전체가 해결하지 못하고 멘붕에 빠져있던 일이 해결됐다. 예전에 비슷한 문제를 해결한 적이 있었다는 심플한 피드백을 남기고 그는 돌아갔다. 남은 개발자들은 그의 신묘함에 감탄했고 내 눈엔 그의 뒷모습에 후광도 비치는 것 같았다. 이 일은 이후 전설의 슈퍼개발자 CTO 이야기로 남았고, 인상깊었던 나는 오래 기억하기 위해 블로그에 기록을 해 뒀다.
이날 CTO의 놀라운 문제 해결력은 단순한 기술적 능력이 아니라 풍부한 경험과 실행력이 만들어 낸 결과라고 생각한다. 그는 서버간 통신에서 중요한 부분이 어디인지 정확한 지식을 갖고있었다. 게다가 비슷한 문제를 해결해본 경험도 있었다. 그리고 본인의 경험과 실력으로 망설이지 않고 실행에 옮겨 중요한 순간에 문제를 해결했다.
이처럼 경험과 실행력을 갖춘 개발자들은 개발자 사이에서 존경을 받는다. 경험이 많으면 예상치 못한 일이 닥쳤을때 대처하는데 유리하다. 소프트웨어 개발은 많은 경우 전에 발생했던 문제들의 반복이거나 그 파생일 가능성이 높기 때문이다.
기획자가 새롭게 개발 요청을 하는 경우 개발자의 입장에선 구현이 가능한지 먼저 검토하게 된다. 이 건이 구현가능한지 여부를 판단하기 위해 이를 구현해놓은 다른 레퍼런스가 있는지 확인한다. 우리 서비스에 없던 기능이라면 외부에서 해냈던 사례를 검색해 어떻게 만들면 좋을지 생각한다. 경험이 많은 개발자들은 이때 가치를 드러낸다. 해 본 적 있는 일이라면 빠르게 이 일에 접근할 수 있다. 어떻게 하면 될지 머리속으로 그림이 그려지고, 어떤 부분에서 문제가 생길지 감지해 낼 수 있다. 기획자가 미처 생각지 못한 예외 상황들을 이야기 해주면 기획자 입장에서는 너무 고맙다.
게다가 경험이 많은 개발자는 주변에 문제해결에 어려움을 겪는 동료들에게도 큰 힘이 된다. 이 문제가 구현 가능한지 불가능한지를 아는 것은 개발할때 사기를 크게 좌우한다. 문제를 듣고 이건 이렇게 하면 될거야 라던가, 내가 해봤는데 어렵긴한데 되더라고 라는 이야기를 해주는 것은 매우 큰 도움이 된다. 이렇게 경험 많은 개발자들은 여러모로 주변에서 환영받는다.
실행력은 단순한 의지 이상의 능력이다. 개발자가 구현이 가능한지 여부를 판단하고 설계를 했다면, 그 다음은 실제 동작하는 소프트웨어를 만들어 내야 한다. 이는 마치 중고등 수학에서 근의공식을 아는것과 이를 적용해서 주어진 문제를 풀어내는것은 다른것과 비슷하다. 소프트웨어는 그 규모가 수학문제와는 비교할 수 없이 크다. 머리로 이렇게 만들면 되겠다고 생각하는 것과 실제로 실행해 프로그램을 만들어내는 것은 다른 수준의 이야기이다.
컴퓨터공학과 프로그래밍 수업을 들을 때 매 수업이 끝나고 그날 배운 내용을 기반으로 짧은 퀴즈를 풀어내는건 수업을 성실하게 들은 학생이라면 대부분 잘 해내곤 한다. 하지만 학기가 끝날무렵 제출하는 소프트웨어 제출 과제는 수업을 성실하게 들은 친구들도 해내지 못하는 경우가 많다. 이처럼 아는 바를 적용해 무언가를 만들어낼 수 있는 실행력은 모두가 갖고있는것이 아니다. 함께 업무를 하며 매번 결과물을 만들어내야 하는 회사라면 이 능력은 훨씬 많이 중요해진다.
요즘은 소프트웨어 개발 주기가 빨라져 동작하는 최소단위의 소프트웨어인 MVP(Minimum Viable Product)를 만들어 기획방향이 맞는지 자주 확인하는게 유행이다. 짧은 주기로 돌아오는 프로그램 납기를 맞추는건 쉬운 일이 아니며 실행력은 이를 위해 필수적인 능력이라고 생각한다.
말로만 떠드는 사람과 실제로 해본사람은 많이 다르다. 이 차이는 개발자 세계에서도 특히 두드러진다. 단순히 라이브러리를 조합해 기능을 가져다 쓰는 개발자와, 그 기능의 바탕이 되는 라이브러리를 직접 만들 줄 아는 개발자는 완전히 다르다. 이 차이를 이해하려면, 기획자를 예로 들어보면 도움이 된다. 기존의 문서를 업데이트해 자료를 만드는 것과 백지에서 시작해 보고서를 처음부터 완성하는 것은 큰 차이가 있다.
기획자가 요청하는 새로운 기능들에는 기존의 레퍼런스가 어느 정도 있지만, 기능이든 디자인이든 기존과는 다른 부분이 많다. 창의적 발상이 더해진 덕분이겠지만, 개발자 입장에서는 이런 변화가 새롭게 만들어야 할 기능으로 연결된다. 이런 상황에서 직접 라이브러리나 코드를 만들 줄 아는 개발자라면 문제 해결이 가능하지만, 단순히 가져다 쓸 줄만 아는 개발자라면 어려움을 겪는다. 할 줄 알지만 여건상 하지 못하는 사람과 못 하는 사람의 차이는 크다.
나 역시 초급 개발자 시절, 사수에게 직접 프레임워크를 만들어 보라는 지시를 받은 적이 있다. 그 의미는 분명했다. 기존의 재료를 조합하기만 하는 사람에서 벗어나 직접 창의적으로 구현하는 개발자로 성장하라는 뜻이었다. 그때 나를 지도해 준 황** 사수에게 감사한다.
이렇듯 실력을 쌓아나간 개발자들은 발표나 기술 공유에서도 차이를 보여준다. 빅테크와 기술 선도 기업들이 매년 개최하는 개발자 컨퍼런스에서 발표하는 개발자들은 단순히 개인의 성취에 그치지 않고, 다른 사람들에게도 도움이 되는 지식을 나누려는 의도를 갖고 있다. 바쁜 시간 속에서 발표까지 준비하는 이유는, 다른 개발자들이 쉽게 사용하고 이해할 수 있도록 지식의 완성도를 높이기 위해서다.
직접 만든 지식을 공유하는 개발자와, 그렇지 않은 개발자. 이 차이가 곧 그들이 존경받는 이유이기도 하다.
개발자들은 남들은 쉽게 해결하지 못하는 일을 해결해 내는것을 멋지다고 생각한다. 되도록 다른 사람들보다 정확하고 빠르게 해결하고싶은 의지가 가득하다. 그렇지만 이런 개발자가 되는것은 의지만으로 가능한 것이 아니다. 어떤이들은 본인이 해결하지 못하는 일이 자기의 책임이 아닌것으로 돌리기 위해 잔머리를 쓰기도 한다. 본인보다 기술적 이해가 부족한 협업부서와 소통할때 온갖 전문용어를 구사하며 못 알아듣게 설명하고 본인만이 이 일을 해결할 수 있다고 거짓말하는 개발자 들이 있다. 이런 개발자를 만났다면 대응을 하기 앞서 이 사람이 코너에 몰려 자기가 살기 위해 몸부림치는구나 생각을 해보는 것도 도움이 될것이라고 생각한다.
개발자들이 멋지게 생각하고 인정받는 개발자들의 특징에 대해 알아봤다. 마치 최신 과학기술을 연구하는 과학자들처럼 장인정신을 발휘해 소프트웨어를 만들어 내는 것이 개발자의 삶이다. 기술적 능력이 뛰어나며 실행력있는 슈퍼 개발자들이 되고자 노력하는 우리 개발자들이 그들이 바라는 대로 성장하도록 환경을 만들어준다면 그들은 행복해할것이라고 생각한다. 더 멋지게 성장하도록 그들의 발전해 나갈 때마다 발전을 응원하고 지지해 준다면 그들은 독자여러분들을 좋아할 수 밖에 없을것이라고 생각한다.
