번역글입니다.

원 저작자의 허락을 받고, Noah Gibbs의 블로그 글 "The Forty-Year Programmer" 를 번역한 글입니다.

• 글이 꽤 긴 관계로 제가 임의로 3 파트로 나누어 글을 올릴 예정입니다.
• 원문 링크: https://codefol.io/posts/the-forty-year-programmer/
• 번역하면서 이런 생각이 들었습니다. 여러분은 어떤 생각이 드나요?

💭 기억할만한 문장 모음💭

• 음악을 만들고 연주하면서 돈을 버는 사람들도 있지만, 대다수의 음악가는 돈을 받지 못해도 여전히 음악을 합니다.
• 하지만 대부분은 결국 배우게 됩니다.
  “저는 15년 경력의 소프트웨어 엔지니어인데, 이 프로젝트를 이끌기에 적합한 사람인가요?”라는 질문에도 같은 대답이 돌아옵니다. “아마도요.” 그러면 이어지는 질문은 “그 15년 동안 당신은 뭘 했나요?”겠죠.

🧐 생각

40년차 프로그래머의 통찰은 뭔가 다른걸까? 이전에 개발자 커리어 단계별 역량 차이 라는 번역글을 올린 적이 있다. 커리어 단계별로 뭔가 정해진 역량이 있고 그걸 따라가야 할 것처럼 적힌 글이다. 하지만 이번 글의 저자는 사뭇 다른 이야기를 하고 있다. 정해진 단계 같은건 없다. 그저 내가 시간을 얼마나 밀도있게 썼는지가 중요하다는 입장이다. 나는 이 중 어떤 생각을 취하면 좋을까?

일과 커리어를 혼동하지 마세요

언젠가 은퇴하고 싶지 않냐고요? 물론 좋겠죠. 하지만 일을 완전히 그만두지는 않을 겁니다. 다만, 오직 돈을 벌기 위해 배울 게 전혀 없는 일을 하지 않을 겁니다. 현재 제가 참여하고 있는 YJIT 프로젝트에는 무보수로도 적을법한 코드로 가득한데요... 하지만 진짜로 돈을 받지 않는다면 비용 보고서 같은 건 손도 안 댈 거고, 상태 업데이트 같은 것도 거의 안 쓸 겁니다. 시스템 관리 작업이나 Git 기록 정리 같은 것도 훨씬 줄어들겠죠.

일(work)과 커리어(career)를 혼동하지 마세요. 이 둘은 같은 게 아닙니다. 사실 별로 관련도 없습니다. 소프트웨어 개발은 정말 멋진 "일"입니다. 하지만 커리어로는 그냥 그럭저럭 괜찮거나 조금 더 나을 뿐이죠.

그래서 제가 음악가 이야기를 자주 꺼내는 겁니다. 음악을 만들고 연주하면서 돈을 버는 사람들도 있지만, 대다수의 음악가는 돈을 받지 못해도 여전히 음악을 합니다. 그 일이 흥미롭고, 강력하며, 만족감을 주기 때문이죠. 물론 돈을 벌 수 있다면, 그만큼 더 많은 시간을 그 일에 투자할 수 있겠죠. 하지만 "일"은 그 자체로 가치를 지니고 있고, "직업(job)"은 그 일을 하기 위해 길을 닦는 도구일 뿐입니다. 저에게 소프트웨어 개발은 그런 존재입니다. 혹시 당신에게도 그렇지 않나요?

가장 중요한 건, 누군가 당신에게 조언을 할 때 그게 "일"에 대한 조언인지, "직업"에 대한 조언인지 구별할 줄 아는 겁니다. 만약 이 둘을 혼동하면 그 조언이 무슨 말인지 이해가 안 될 겁니다. 짜증나게도, 사람들은 "일", "직업", "커리어" 같은 단어를 뒤섞어 사용하기도 하죠. 따라서 단어만 듣고 구별하려 해서는 안 됩니다.

명확한 단계(level)는 없습니다

배우는 순서가 중요하지 않다면, 사실 "1단계", "2단계" 같은 건 존재하지 않습니다. 혹은 어떤 다른 단계도요. 어떤 언어나 기술부터 배워야 한다는 추천을 여러번 받을 겁니다. 그건 괜찮습니다. 하지만 자신만의 길을 개척한다고 해서 기본기를 건너뛰었다거나, 부족하다고 생각할 필요는 없습니다. 중요한 것은 시간이 지나면서 필요한 것들을 스스로 깨닫고 배우게 된다는 사실입니다.

혹은 그렇지 않을 수도 있죠. 하지만 대부분은 결국 배우게 됩니다.

누군가 기본기를 소홀히 해서 몇 년씩 끔찍한 코드를 작성했다는 무서운 이야기를 들었을 겁니다. 실제로 그런 일이 일어나기도 하죠. 예를 들어, 어떤 사람이 모듈 간의 경계를 무시하고 서로의 변수를 직접 설정하는 스파게티 코드를 15년간 작성했다고 해봅시다. 하지만 계속 시도하다 보면 왜 그런 방식이 문제인지 알게 되거나, 새로운 스타일과 해결책을 발명해 괴짜 같은 전문가가 될 수도 있습니다. 한 프로그래머에게 "새로운 패러다임"은 다른 프로그래머에게 "괴짜 같은 뭔가"로 보이기 마련이니까요.

문제는 나아지려는 시도를 멈출 때 발생합니다. 새로운 실수를 계속 저지르다 보면, 결국 유용하거나 아름답거나 기이한 무언가를 배우게 될 겁니다. 하지만 동일한 실수를 계속 반복하면서 발전하려는 시도를 하지 않는다면 그땐 정말 답이 없습니다.

사실 누군가 미리 설계한 단계를 차례대로 밟아가도 같은 결과를 볼 수는 있습니다.

브루스 리는 이렇게 말했죠.

"한 번씩만 열 번의 킥을 연습한 사람은 두렵지 않다. 하지만 하나의 킥을 만 번 연습한 사람은 두렵다."

핵심은 신경 쓰고 나아지는 겁니다. 하나의 일에 집중하는 것도 좋고, 열 가지 혹은 백 가지 일에 집중해도 충분히 가능합니다. 만 가지는 좀 무리일 수도 있겠지만요. 그래도 진짜 노력한다면 제 말을 증명해보일 수도 있을 겁니다. 물론, 꽤 독특한 방식으로요.

그건 좋은 일입니다. 새로운 패러다임 – 흔히 "뭔가 괴상한 것"이라고 불리는 – 을 통해 우리는 집단적으로 새로운 기술을 익히게 됩니다. 만약 "매주 화요일마다 완전히 새로운 것을 시도하기"가 당신의 "하나의 킥"이라면 계속 해보세요. 잘못됐다는 걸 깨닫거나 정말 뛰어나게 잘하게 되거나, 둘 중 하나일 테니까요.

실력이 좋아질수록 다른 사람과 달라지게 됩니다

초기 경력 단계의 훈련(코드 스쿨, 블로그 글, 대학 수업, 책)은 공장 라인처럼 느껴질 수 있습니다. 함수 작성, 디버깅, 작업량 추정, 팀과의 커뮤니케이션 등 기본적인 스킬들을 일정 수준으로 갖추게 하기 위한 과정이죠.

하지만 이것이 예를 들어, 수석 엔지니어(Principal Engineer)라면 더 많은 스킬 리스트가 있고 더 높은 수준의 능력을 가져야 한다는 의미는 아닙니다. 절대 그렇지 않습니다.

이건 단순히 직급만의 문제가 아닙니다. 오픈 소스에서의 레벨, 사람들의 인식에서도 마찬가지입니다.

단순한 코드 조각을 자세히 문서화하고 사람들에게 설명하는 것만으로도 크게 존경받을 수 있습니다. 예를 들어 Patrick McKenzie의 Bingo Card Creator처럼요. 혹은 수익성이 좋은 무언가를 만들거나, 깊고 복잡한 무언가를 작성해서 인정을 받을 수도 있죠. 이 경로들은 기본적인 역량 외에는 서로 거의 공통점이 없습니다.

어느 한 분야에서 뛰어난 실력을 가지는 것이 중요합니다. 그 분야가 대중적이든, 수익성이 있든, 아니면 어떤 방식으로든 인정받을 수 있는 분야라면요. 이 설명이 굉장히 모호하게 들릴 수도 있지만 사실입니다.

예를 들어, 빌 게이츠급의 소프트웨어 수익을 내겠다고 시작했는데 결국 비평가들로부터 인정받은 하스켈 같은 언어를 개발했다면(복잡하고 깊이 있는 언어지만 큰 돈은 안 되는), 그건 실패한 것이고 그 반대도 마찬가지입니다. 그리고 필요한 기술도 완전히 다르죠.

이 때문에 “저는 소프트웨어 엔지니어로 15년의 경력이 있습니다. 보통 이런 경우 연봉이 얼마인가요?” 같은 질문은 어리석은 겁니다. 15년은 너무나 긴 시간입니다. 당신은 같은 15년 경력의 엔지니어와 전혀 다른 사람이 되어야 합니다. 그 15년 동안 무엇을 했나요? 책을 썼나요? 돈을 벌어준 대규모 프로젝트에 참여했나요? 흥미로운 오픈 소스 프로젝트를 만들었나요?

이 질문은 단순히 연봉에만 국한되지 않습니다.

“저는 15년 경력의 소프트웨어 엔지니어인데 이 프로젝트를 이끌기에 적합한 사람일까요?”라는 질문에도 같은 대답이 돌아옵니다. “아마도요.” 그러면 이어지는 질문은 “그 15년 동안 당신은 뭘 했나요?”겠죠.