나는 12살 무렵 프로페셔널 프로그래머가 되겠다는 목표를 세웠다.
그걸 아는 이유는 그때 왼손잡이임에도 의식적으로 오른손으로 마우스를 쓰기로 결심했기 때문이다.

혹시 동료의 컴퓨터 문제를 도와줘야 할 때 시작하기도 전에 마우스를 반대편으로 옮겨야 한다면 얼마나 어색할까 싶었다. 그건 피하고 싶었다. (물론 무선 마우스의 등장은 예상하지 못했다… 사실 지금도 습관 때문에 오른손으로 마우스를 쓴다.)

늘 궁금했던 게 하나 있다. 프로그래머의 평범한 하루는 어떤 모습일까. 이 진로를 좇는 게 시간 낭비는 아닐까. 답은 훨씬 뒤에야 찾았다. 직접 프로페셔널 프로그래머가 되고 나서였다. 이 글이 여러분의 몇 년 치 불확실성을 덜어주었으면 한다.

본문을 읽기 전에 이 시리즈의 첫 번째 글인 “왜 나는 프로그래밍을 사랑하는가”를 먼저 읽어보길 권한다.

‘프로’와 ‘취미’ 프로그래밍은 무엇이 다른가

한 단어로 말하면 책임이다.
책임을 져야 한다.

여가 시간에 하는 프로그래밍은 뒷정리할 필요 없는 파티와 같다. 그저 즐겁기만 하다. 지루해지면 언제든 다른 일을 하면 된다. 프로의 프로그래밍은 그렇지 않다. 맡은 일을 끝까지 해내야 한다.

모든 애플리케이션은 끊임없는 버그 수정과 리팩터링, 때로는 몽키 패치까지 요구한다. 코드를 유지보수하는 일은 놀이공원이 아니다. 특히 내 코드가 아닐 때는 더 그렇다.

주니어 개발자로 산다는 것

학교를 갓 졸업했을 때는 자신이 꽤 잘나가는 프로그래머라고 생각할지도 모른다. 말해주겠다. 그렇지 않다. 재능 있는 사람들이 저 깜빡이는 기계로 무엇을 해낼 수 있는지 상상도 못 할 것이다. 첫 몇 년 동안 배워야 할 것이 산더미처럼 쏟아진다.

프로페셔널 소프트웨어 개발은 긴 호흡의 과정이다. 읽기 쉽고, 테스트가 잘 되어 있으며, 문서화가 잘 된 코드를 작성하는 일은 상당한 노력을 필요로 한다. 인내심이 필요하다. 정말 많은 인내심이. 자신에게도, 남에게도.

주니어 때는 세상을 흑백으로만 본다. 코드를 보면 전부 잘못된 것처럼 보인다. 도대체 제정신인 사람이 어떻게 이런 끔찍한 괴물을 만들었을까 싶다. 경험이 쌓이면 회색 지대가 보이기 시작한다.

결국 그 수염 덥수룩한 고수들이 나보다 느려서가 아니라 더 신중했음을 이해하게 된다. 코드를 테스트하는 법, 문서화하는 법을 배우게 된다. 심지어 UML 다이어그램이 고마워 보이기 시작한다.

쓸모없어진다는 것

“세상은 너무 빨리 변한다. 오늘 배운 것이 내일이면 쓸모없어진다. 뭣 하러 애쓰나?” 커리어 내내 이 말을 수없이 들었다. 흔한 말이지만 틀렸다.

쓸모없어지는 것이라면 애초에 스킬이 아니다. 커리어 내내 ‘Jenkins 담당자’로 기억되고 싶지는 않을 것이다. ‘소프트웨어 품질 전문가’로 기억되고 싶을 것이다. 힌트: Jenkins가 뭔지 모른다면, 그게 바로 핵심이다. 활동 범위를 너무 좁히지 마라. 제대로 된 스킬은 절대 쓸모없어지지 않는다.

때로는 회사의 새로운 방침 때문에 정성껏 만든 결과물이 쓸모없어지는 일이 생긴다. 우울하게 들리겠지만 소프트웨어 업계에서는 흔한 일이다. 적응해야 한다. 해줄 수 있는 조언 하나는 너무 심각하게 받아들이지 말라는 것이다. 프로젝트는 내려놓고 지혜는 간직하라. 변화를 받아들여라.

완벽하지 않은 세상에서 소프트웨어 만들기

프로페셔널 프로그래머는 늘 결핍과 씨름해야 한다. 이 게임의 이름은 ‘제약 조건의 균형 맞추기’다. 마감, 예산, 코드 품질은 우리가 저울질해야 할 수많은 상충하는 제약 중 일부일 뿐이다. 현실 앞에서는 우아한 설계도 바랜다. 결국 소프트웨어로 돈을 벌어야 하니 출시해야 한다!

내가 아는 최고의 개발자들은 실용성과 우아함 사이의 균형을 유지한다. 무엇이 중요하고 무엇이 중요하지 않은지 안다. 그 균형을 모르는 사람은 필요할 때 교체된다.

나는 늘 우아함 쪽으로 기울어져 있었다. 다르게 말하면 완벽주의자였다는 뜻이다. 실용적인 부분은 힘든 노력을 통해 배워야 했다.

경험이 적은 프로그래머를 멘토링한다는 것

프로그래밍을 잘할수록 코드를 덜 쓰게 된다.

대신 소프트웨어 아키텍처와 높은 수준의 설계를 고민하고, 작업을 더 작은 단위로 쪼개 다른 개발자들이 맡을 수 있게 나누는 데 더 많은 시간을 쓰게 된다. 주니어 개발자를 멘토링하기 시작하고, 채용에도 많은 신경을 쓰게 된다. 비즈니스 담당자들과 프로젝트 목표를 논의하는 회의에서 시간을 보내게 된다. 어떤 사람은 이를 중재자 역할이라고 하고, 다른 사람은 관리자라고 부른다.

비즈니스의 안팎을 속속들이 알게 되면 회사에 꼭 필요한 인재가 된다. 관리자 역할을 제안받거나, 적어도 프로젝트 관리를 맡는 일이 책임의 자연스러운 연장처럼 느껴지기 시작할 것이다. 하지만 조심하라. 이 느리고 점진적인 과정은 위험하다. 전업 프로그래머로 돌아가는 일은 쉽지 않다. 당신이 프로젝트 관리로 바쁜 동안 다른 사람들은 코딩 실력을 갈고닦고 있기 때문이다. 여가 시간에 따라가 보려 해도 쉽지 않다.

뛰어난 개발자가 훌륭한 관리자가 되는 경우를 많이 봤다. 커리어의 어느 시점에서는 스스로 결정해야 할 문제다.

어떻게 결정하든, 소통하는 법을 배우는 데 시간을 투자할 가치는 있다. 거기서 공감 능력이 중요한 역할을 한다. 팀으로 소프트웨어를 개발하는 일은 너무 복잡해서 목표를 조율하고 문제를 공유하는 데 많은 시간을 쓰게 된다. 사실 당신이 돈을 받는 이유가 바로 소통이다. 문서도, 테스트도, 코드 자체도 모두 소통에 포함된다.

다른 사람들과 대화하고 그들의 고민을 들어라. 직접 관리자가 되고 싶지 않더라도 소프트웨어 프로젝트 관리에 관한 책을 읽어라. 상사의 역할을 이해하는 데 도움이 될 것이다.

돈에 관하여

IT에서 일할 이유는 많지만, 돈은 그중 하나가 아니다.

예상 연봉을 기준으로 커리어 결정을 내리고 싶은 유혹이 들겠지만, 그러지 마라. 매우 불행해질 것이다. 하루에 여덟 시간 넘게 깜빡이는 커서 앞에 앉아 있어야 한다. 그건 엄청나게 긴 시간이며, 시간은 돈보다 훨씬 가치 있다.

오해하지 마라. 보수가 괜찮은 일자리는 많다. 다만 부자가 되기는 어렵다. 크게 성공하고 싶다면 도와줄 방법이 없다. 부동산 같은 쪽을 알아보는 게 낫겠다… 개발자로서 부자가 되는 유일한 방법은 정말 어려운 일에 매달려 엄청나게 많은 시간을 쏟아붓고 운까지 따라주는 것이다. 결국 스타트업이라는 얘기다. 명심하라. 빌 게이츠 한 명 뒤에는 천 번의 실패가 있다. 다른 방법은 프로그래머를 그만두고 관리자가 되는 것이다. 그에 대한 내 생각은 앞 섹션에서 이미 밝혔다.

마지막으로

코드를 읽는 법(그리고 어쩌면 쓰는 법)을 배워야 하는 건 맞지만, 프로페셔널 프로그래머로 일하는 것이 모두에게 맞는 길은 아니다. “그만한 가치가 있을까?”라고 물을지도 모른다. 나에게는 올바른 결정이었다. 이 글이 여러분이 스스로 결정하는 데 도움이 되었기를 바란다.