열두 살쯤, 나는 프로페셔널 프로그래머가 되겠다는 목표를 세웠다.
확실히 기억하는 이유는 그때 왼손잡이임에도 의식적으로 오른손으로 마우스를 쓰기로 결심했기 때문이다.

내 생각은 이랬다. 언젠가 동료의 컴퓨터 문제를 도와줘야 할 때 굳이 마우스를 반대쪽으로 옮기고 시작하고 싶지 않다는 것. 꽤 어색한 일 아닌가. (물론 무선 마우스의 등장을 예상하지는 못했다… 사실 지금도 습관 때문에 오른손으로 마우스를 쓴다.)

내가 항상 궁금했던 것 중 하나는 프로그래머의 평범한 하루가 어떻게 생겼는가 하는 점이었다. 이 직업을 쫓으며 시간을 낭비하고 있는 건 아닐까? 답은 한참 뒤에야 찾을 수 있었다. 직접 프로페셔널 프로그래머가 되어서야 말이다. 이 글은 여러분이 몇 년간의 불확실함을 겪지 않도록 돕기 위해 쓰였다.

본격적으로 읽기 전에, 이 시리즈의 첫 번째 글인 “Why I love Programming”을 꼭 읽어보길 바란다.

“프로”와 “취미” 프로그래밍의 차이는 무엇일까?

한 단어로 말하자면, 책임감이다.
책임을 져야 한다는 기대를 받는다.

여가 시간에 하는 프로그래밍은 뒷정리할 필요 없는 파티를 여는 것과 같다. 오로지 재미뿐이다. 지루해지면 언제든 그만두고 다른 걸 하면 된다. 하지만 프로의 프로그래밍은 다르다. 일을 끝까지 해내야 한다는 기대를 받는다.

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

주니어 개발자로 산다는 것

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

프로페셔널 소프트웨어 개발은 긴 과정이다. 읽기 쉽고, 테스트가 잘 되어 있으며, 문서화가 잘 된 코드를 작성하는 일은 상당한 노력이 든다. 인내심이 필요하다. 그것도 아주 많이. 자신에 대해서도, 타인에 대해서도 그렇다.

주니어 때는 세상을 흑백 논리로만 본다. 코드를 보면 모든 게 잘못된 것처럼 보인다. 제정신인 사람이 어떻게 이런 끔찍한 괴물을 만들었지?! 하지만 경험이 쌓일수록 회색의 음영을 보게 된다.

결국에는 그 고참 개발자들이 당신보다 느려서가 아니라 더 신중했음을 이해하게 된다. 코드를 어떻게 테스트하고 문서화해야 하는지 배우게 된다. 심지어 UML 다이어그램의 가치를 인정하게 될지도 모른다.

도태된다는 것

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

쓸모없어지는 것이라면 애초에 스킬이라고 할 수 없다. 커리어 내내 “Jenkins 담당자”로 기억되고 싶지는 않을 것이다. “소프트웨어 품질” 전문가로 기억되고 싶을 것이다. 힌트: Jenkins가 뭔지 모른다면, 바로 그게 핵심이다. 자신의 영역을 너무 좁게 한정해서는 안 된다. 제대로 된 스킬은 절대 쓸모없어지지 않는다.

때로는 회사의 새로운 방침 때문에 당신이 공들여 만든 멋진 결과물이 쓸모없어지기도 한다. 우울하게 들리겠지만, 이는 소프트웨어 업계에서 흔히 있는 일이다. 적응해야 한다. 하나 조언을 하자면, 너무 심각하게 받아들이지 말라는 것이다. 프로젝트는 내려놓고, 거기서 얻은 지혜는 간직하라. 변화를 받아들여라.

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

프로페셔널 프로그래머는 항상 부족한 것들과 씨름해야 한다. 이 게임의 이름은 “제약 사이의 균형 잡기”다. 마감 기한, 예산, 코드 품질은 우리가 고려해야 할 서로 충돌하는 제약 중 일부에 불과하다. 현실 앞에서는 우아한 설계도 빛이 바랜다. 결국 소프트웨어로 돈을 벌어야 하니, 제품을 출시해야 한다!

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

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

경험이 적은 프로그래머 멘토링하기

프로그래밍을 잘하게 될수록, 코드는 덜 쓰게 된다.

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

비즈니스의 속속들이를 알게 되면, 당신은 회사에 없어서는 안 될 자산이 된다. 관리자가 되어 달라는 제안을 받을 수도 있고, 적어도 프로젝트 관리는 자연스럽게 책임 범위의 연장처럼 느껴지기 시작할 것이다. 하지만 조심하라! 이 느리고 점진적인 과정은 위험하다. 다시 전업 프로그래머로 돌아가는 것은 쉽지 않다. 당신이 프로젝트 관리로 바쁜 동안, 다른 이들은 코딩 실력을 갈고닦고 있기 때문이다. 여가 시간에 최신 흐름을 따라가려 노력할 수는 있지만, 쉽지 않다.

나는 뛰어난 개발자들이 훌륭한 관리자가 되는 모습을 봐 왔다. 커리어의 어느 시점에서는 스스로 결정을 내려야 한다.

어떤 길을 선택하든, 소통하는 법을 배우는 데 시간을 투자할 가치는 있다. 거기서 공감 능력은 중요한 역할을 한다. 팀으로 소프트웨어를 개발하는 일은 매우 복잡해서 목표를 조율하고 문제를 소통하는 데 많은 시간이 든다. 사실 당신이 돈을 받는 것은 바로 소통 때문이다. 여기에는 문서, 테스트, 그리고 코드 자체도 포함된다.

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

돈에 대한 한마디

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

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

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

마지막으로

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