번역글입니다.

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

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

💭 기억할만한 문장 모음💭

• 우리 업계는 빠르게 변화합니다. 다시 말하면, 우리는 아직 기본적인 것들을 제대로 다룰 만큼 능숙하지 않다는 뜻입니다. 다른 분야에서 배울 수 있는 것이 많습니다. 예술과 음악은 역사가 오래된 분야입니다. (...) 따라서 어떤 문제를 해결하기 위해 프로그래머들이 사용한 최고의 방법만 배우겠다고 하면, 스스로의 선택지를 크게 제한하는 셈이 됩니다.
• 만약 그들의 능력이 "아무것도 아니고, 전혀 중요하지 않다"고 생각한다면, 그들이 잘하는 무언가를 당신도 그만큼 잘하게 될 가능성은 없습니다.
• 바퀴를 다시 발명할 수도 있는거죠. 같은 것을 반복해서 작성할 수도 있습니다. “나쁜” 방식으로 코드를 작성하고 어떤 일이 일어나는지 관찰할 수도 있습니다.
  “최고의 관행”에 주의하십시오. 이것은 다른 누군가가 이에 대해 생각하고 똑똑한 방법으로 만든 다음, 당신에게 가장 단순한 것을 제공한 결과입니다.

🧐 생각

원문을 3개로 나눈 파트 중, 이번 파트에서 내 생각을 바꾼 문장이 가장 많았다. 위에 적은 문장들이다. IT업계는 아직 젊다. 우리나라 IT는 특히 더더욱 그렇다. 아직 40년차 프로그래머가 생길만큼 성숙한 업계가 아니다. 그만큼 이 분야에만 갇히지 않고 다른 시선을 가지는게 중요하다. 글쓴이가 말하는대로, 나의 선택지를 스스로 제한하고 싶지 않기 때문이다.
'최고의 관행' 역시 경계해야겠다. 항상 그렇지만 무언가 최고의 관행이라고 해서 무조건적으로 수용하지 말자. 항상 의심해보자.

다른 분야를 살펴보고 배우세요

우리 업계가 아직 젊다는 것은 무엇을 의미할까요? 바로, 우리가 아직도 기본적인 것들을 알아가는 중이라는 뜻입니다.

1993년부터 1998년까지 제가 대학을 다닐 때, 테스트 우선 개발이나 테스트 주도 개발 같은 것은 대중적이지도 않았고 널리 알려지지도 않았습니다. 애자일 방법론도 마찬가지였습니다. 버전 관리 시스템은 존재했지만 좋지 않았고, 널리 사용되지 않았습니다. 오픈 소스도 존재했지만 당시에는 오픈 소스 소프트웨어가 형편없다는 인식이 많았습니다. 리눅스가 최고의 서버 운영체제가 될 수 있다는 생각은 소수의 광신도들만 믿는 이상한 아이디어처럼 보였습니다. C 언어가 어셈블리 언어를 대체할 만큼 빠르다고 여기는 것도 보편적이지 않았습니다. “GOTO” 문이 나쁘고 피해야 한다는 것이 막 이해되던 시기였습니다. 웹은 이제 막 시작되었고, 제가 학교에 다니던 중에 웹 페이지에 그림을 넣는 기능이 지원되기 시작했습니다.

우리 업계는 빠르게 변화합니다. 다시 말하면, 우리는 아직 기본적인 것들을 제대로 다룰 만큼 능숙하지 않다는 뜻입니다.

다른 분야에서 배울 수 있는 것이 많습니다. 저는 예술가들의 연습 방법을 참고해 어떻게 배울 수 있는지에 대한 책을 쓴 적이 있습니다. 여기서도 음악가들에 대해 자주 언급합니다. 예술과 음악은 역사가 오래된 분야입니다. 우리는 이러한 분야를 오랫동안 가르쳐왔고, 예술과 음악을 가르치는 사람들은 컴퓨터 과학 교수들보다 훨씬 앞서 있습니다.

따라서 어떤 문제를 해결하기 위해 프로그래머들이 사용한 최고의 방법만 배우겠다고 하면, 스스로의 선택지를 크게 제한하는 셈이 됩니다. 어떤 문제를 해결하는 방법을 찾을 때는 프로그래머가 아니라 다른 모두가 문제를 어떻게 다루는지 생각하는 것이 더 좋습니다. 아툴 가완데(Atul Gawande)의 체크리스트 매니페스토(The Checklist Manifesto)에서는 파일럿, 고층 건물 건설자, 의사들이 체크리스트를 다루는 아주 다양한 방법들을 설명합니다. 모두 훌륭한 접근 방식입니다. 소프트웨어 분야에서는 그들의 방법 중 극히 일부만 겨우 차용하기 시작했을 뿐입니다. 따라서 프로그래머한테서만 배우는 순간, 대부분의 체크리스트 문제에 대한 최선의 접근법을 놓쳤다고 볼 수 있습니다.

체크리스트만이 유일한 사례는 아닙니다. 재즈 음악가들은 프로그래머들이 부러워할 만큼 높은 수준으로 협업합니다. 전문적인 비주얼 디자이너들이 만들어내는 결과물은 데이터 과학자들이 모방하려고 시도할 만큼 뛰어납니다. 요리학교에서 훈련받은 팀들이 작업 공간을 조직하는 방식을 보면 입이 떡 벌어질 정도입니다. 도서관 사서가 조직한 데이터 공간에서 몇 년만 일해보면 우리의 문서화 방식이 얼마나 엉망인지 알게 될 것입니다.

최고의 프로그래머만큼 잘하려고 한다면 스스로를 과소평가하는 셈입니다.

프로그래머들이 비(非)프로그래머의 조언을 무시하는 경향이 있다는 것을 분명 느껴보셨을 겁니다. QA나 운영 담당자는 종종 2등 시민처럼 취급되고, 그들에게서 배울 것이 없다고 생각하기도 합니다. 이는 정말로 바보 같은 행동입니다. 똑똑하다면 그들이 잘하는 것이 무엇이고 그것이 왜 중요한지 파악하려고 노력할 것입니다.

만약 그들의 능력이 "아무것도 아니고, 전혀 중요하지 않다"고 생각한다면, 그들이 잘하는 무언가를 당신도 그만큼 잘하게 될 가능성은 없습니다.

완전히 다른 분야에서 기술을 습득하는 것은 어렵습니다. 예술에서 배울 만큼 충분히 익히는 데도 몇 년이 걸릴 수 있습니다. 하지만 데이터베이스 관리나 DevOps처럼 프로그래밍과 비슷한 분야는 충분히 가까우니 이해하려고 노력할 가치가 있습니다.

또한, 목공, 춤, 또는 가라테 같은 취미가 있다면 그 취미가 당신에게 어떤 기술을 제공했는지 생각해보는 것도 좋습니다. 다른 프로그래머라면 몇 년을 배워야 하는 기술을 이미 가지고 있을 가능성이 높습니다. 저는 목공이나 춤, 또는 가라테를 하지 않기 때문에 어떤 기술인지 알 수 없지만, 제가 조금은 아는 예술과 음악에서 배운 점을 이야기하는 이유도 그 때문입니다.

프로그래머는 반항적이다

다른 분야를 배우다보면 뭔가 낯선 느낌이 들 수 있습니다. 대체로 좋은 일이지만, 때로는 충돌을 일으키기도 합니다.

미술가, 음악가, 작가들은 모두 같은 활동을 반복적으로 하면 실력이 늘어난다는 것을 알고 있습니다. 재작성은 당연한 일이고, 같은 곡을 반복해서 연습하는 것도 당연합니다. 인체를 그리거나 정물을 반복해서 그리는 것도 흔한 일입니다.

소프트웨어에서도 이런 개념이 있습니다. “바퀴를 다시 발명하다”는 말이죠. 이는 부끄러운 일로 취급되고, 몰래 해야만 하는 행동으로 여겨집니다. 우리는 반복적인 작업을 컴퓨터가 처리하게 하고, 스스로는 새로운 작업만 하려고 합니다.

반복적으로 같은 작업을 한다고 말하면 공개적으로 비난받기 쉽습니다. 평판을 잃게 됩니다. 평판은 직책이나 수입과도 연결되기 때문에 중요한 요소입니다.

이것이 대부분의 프로그래머가 새로운 프로젝트를 시작하는 데 서툰 이유입니다. 특정 문법 구조를 언제 사용하는지 논의하지 못하고, 들여쓰기 규칙 같은 것은 단순하고 명확한 정답이 있는 문제처럼 행동합니다. 왜냐하면 이런 기술을 쌓는 방법은 반복과 점진적 향상, 그리고 표현력에 대한 믿음, 그리고 다른 사람들과의 소통에 있기 때문입니다. 그러나 우리 업계에서는 이런 것들이 낙인 찍히는 경향이 있습니다.

그렇다고 해서 당신이 반드시 이런 것들에 서툴러야 한다는 것은 아닙니다.

당신은 프로그래머들에게 다른 사고방식을 설득할 필요가 없습니다. 몇몇 사람들에게는 가능할 수 있지만, 모두를 더 나은 방향으로 이끌려 한다면 몇십 년 이상 걸릴 것입니다. 그럴 시간은 없을 겁니다. 당신은 더 빠르게 더 나아지고 싶을 것입니다.

하지만 개인적으로 “나쁜 관행”이라 불리는 일을 하더라도 그것이 실제로 당신을 더 나아지게 한다면 해보는게 좋습니다.

바퀴를 다시 발명할 수도 있는거죠. 같은 것을 반복해서 작성할 수도 있습니다. “나쁜” 방식으로 코드를 작성하고 어떤 일이 일어나는지 관찰할 수도 있습니다.

“최고의 관행”에 주의하십시오. 이것은 다른 누군가가 이에 대해 생각하고 똑똑한 방법으로 만든 다음, 당신에게 가장 단순한 것을 제공한 결과입니다.

시작하기에는 좋은 출발점이 될 수 있습니다. 하지만 더 나아지기 위한 방법으로는 좋지 않습니다.

미술가, 사서, 수셰프에게 배운다고 해서 소프트웨어 업계 전체를 쉽게 끌고 갈 수는 없습니다. 당신이 옳다고 해서 다른 사람을 설득할 수 있는 것도 아닙니다. 당신의 기준에서는 올바르게 작업하는 방식이, 다른 사람들이 가지고 있지 않은 기술을 요구할 수도 있습니다.

하지만 주변 사람들이 당신에 대해 어떻게 생각하는지 너무 신경 쓰지 않는다면 더 나아질 수 있습니다. 그리고 자신이 어떻게 그렇게 되었는지 굳이 다른 사람들에게 말할 필요도 없습니다.

실력이 늘어날수록 다른 사람들과는 점점 더 달라 보이게 됩니다. 특히, 자기 분야에서 정말 뛰어난 사람들과도 다르게 보이게 됩니다.

이와 같은 이유로 도구와 규칙의 강제성에 주의해야 합니다. 이런 것들은 최소한의 역량을 유지하기 위해 설계된 것이지, 독특한 방식으로 뛰어나게 만드는 데 설계된 것이 아닙니다.

하지만 당신은 남다른 분야에서 매우 뛰어난 사람이 되고 싶을 겁니다.

생산성 팁에 주의하세요

많은 사람들이 "잘하는 비결은 꾸준히 일하는 것이다"라고 말할 겁니다. 사실, 저도 이미 여기서 네다섯 번은 그런 이야기를 했습니다. 그들은 매일 조금씩 나아지고, 그것이 곱해지도록 하는 것이 비결이라고 말할 것입니다.

그런 조언에는 함정이 있습니다. 대부분의 경우, 연습한다고 해서 즉각적으로 눈에 띄게 나아지지는 않습니다. 때로는 큰 도약을 이루기도 하지만, 그 도약이 다른 몇 가지 능력을 더 나쁘게 만들 수도 있습니다.

만약 매달 복리로 계산해 매년 20%씩 꾸준히 성장할 것을 기대한다면, 큰 실망을 하게 될 것입니다.

효율성에는 한계가 있습니다. 이런 과정들 중 상당수는 매우 비효율적이고 전혀 믿을 수 없는 경우가 많습니다. 때로는 엄청난 성과를 내기도 하지만, 종종 아무런 성과도 없거나 오히려 해를 끼치기도 합니다.

성공은 바로 그런 모습을 하고 있을겁니다.

깔끔하고 정돈된 생산성과 효율성에 대한 조언은 대개 명확하게 구조화된 작업에 적합합니다. 그러나 40년에 걸친 프로그래밍 경력은 그런 종류의 작업이 아닙니다. 다시 말하지만, 마라톤이나 스프린트가 아니라 일기를 쓰는 것처럼 생각하세요. 스스로를 위한 진행 상태 표시줄을 유지하려고 하면 실패할 가능성이 높습니다.

시간이 지나면, 너무 깔끔하고 정돈된 것을 경계하게 될 것입니다. 다시 한 번 강조하자면, 조언은 중요한 부분을 모두 제거한 상태의 전문 지식입니다. 제가 지금 하는 말도 그에 포함됩니다.

효율성은 항상 특정 유형의 효율성만을 의미합니다. 시간 효율적인 접근법이 비용적으로 비효율적일 수도 있습니다. 어느 한 쪽이든 지금 당신이 가진 자원, 예를 들어 아이가 적거나 조용한 환경이 필요할 수도 있습니다. 효율성은 이미 어느 정도 작동하고 있는 전략을 다듬는 방법일 뿐입니다.

저는 효율성 팁에 대해 많이 이야기하지 않습니다. 저는 여기서 이러한 일을 가장 빠르게 하는 방법을 이야기하고 있는 것이 아닙니다. 가장 신중하게 최적화된 접근법은 기본적으로 항상 취약합니다. 효율성은 좋습니다. 최적화도 좋습니다. 그러나 기본적인 것들이 작동하고 난 이후에야 약간의 추가 도움을 줄 수 있을 뿐입니다.

어려운 것은 기본을 다지는 것입니다. 그래서 제가 말하는 대부분은 기본을 다지는 방법에 관한 것입니다. 그 이후에 효율성을 추구하는 것은 덜 중요하고 더 쉬운 일입니다.

하지만 진지하게, 그냥 하세요

여기서 한 말들은 모두 꽤 괜찮은 이야기입니다. 대부분은 여러분의 접근 방식을 바꾸기보다는 안심시키기 위한 것입니다. 제가 비기술적인 분야의 조언을 자꾸 추천하는 게 우연이 아닙니다. 이미 알고 있는 것들에 대해 말하는 것이, 최근에 프로그래밍에 빠져든 열성적인 사람들로 가득한 포럼에서 듣는 조언보다 낫기 때문입니다.

프로그램을 작성한다면 당신은 프로그래머입니다. 혹은 코더, 소프트웨어 엔지니어, 당신이 부르고 싶은 대로 부르면 됩니다.

계속해서 프로그램을 작성한다면, 몇 년 경력의 프로그래머든 뭐든 될 수 있습니다. 이걸 감시하는 사람은 아무도 없습니다. 최소한, 누군가 감시한다고 해도 무시해도 됩니다. 예를 들어 누군가는 이런 댓글을 달지도 모릅니다. “저 사람은 40년 경력의 프로그래머가 아니야. 전업으로 일한 지 25년도 안 됐잖아!” 멍청한 말이죠. 하지만 여기는 인터넷입니다. 그런 말을 하는 사람은 반드시 있습니다.

때로는 타이틀이 자기 설명을 위한 것조차 아닐 때도 있습니다. 그런 의미를 이해하려면 첫 문장을, 심지어 두 문장 정도는 읽어야 전체 맥락을 이해할 수 있습니다. 하지만 JoeRandom_420 같은 사람은 그렇게 신경 써주지 않습니다.

어쨌든 꾸준히 노력한다면 그 자격을 얻게 됩니다. 이건 누구든 당신을 쫓아낼 수 있는 공식적인 클럽이 아닙니다. 일정 시간 동안 작업을 해냈다면 그 시간 동안 작업했다고 말할 자격이 있는 겁니다.

어떻게 일정 시간 동안 작업을 지속할 수 있을까요? 계속 해야 합니다. 스스로의 기대치를 조정해야 합니다. 실수를 알아차리고 고쳐야 합니다. 너무 경직되지 않도록 조심하며, 일을 계속 즐기려고 노력하면 됩니다.

방금 말한 게 전부입니다.

나머지는 시간이 해결해주거나 조금 더 여유롭게 받아들이는 자세가 필요할지도 모릅니다.

40년이라는 시간은 생각보다 빨리 지나갈 겁니다. 참나무 옆에 있는 아버지의 범퍼 스티커에 적힌 문구처럼 말이죠. “너도 곧 나이가 들게 될 거야.”