TL;DR

  • 자격증·GitHub 프로젝트·포트폴리오·오픈소스 기여로 구성된 체크리스트는 이제 주니어 엔지니어의 차별화 요소가 아니라 최소 기준이 됐으며, 호기심·적응력·학습 능력을 행동으로 보여주는 방식이 중요함.
  • 직접 만들지 않은 오픈소스 코드베이스를 이해하고 기여하는 경험이 실제 업무 환경에 가까운 학습·협업 역량을 보여줌.
  • 해결된 지식이 아니라 혼란을 겪고 이해하게 된 과정을 구체적으로 공개하면 고유한 관점과 기억에 남는 사고방식을 드러냄.
  • 비엔지니어에게 기술적 결정을 전달하는 번역 능력은 나중에 개발할 기술이 아니라 일찍부터 갖춰야 할 기반 역량임.
  • 자원봉사 기술 업무는 실제 이해관계와 결과를 수반하며, 아무도 요구하지 않은 일을 선택하는 호기심과 주도성을 보여주는 방식임.

체크리스트의 한계

  • 기술 업계 진입을 준비하는 사람들에게는 자격증 취득, GitHub용 프로젝트 제작, 포트폴리오 구성, 오픈소스 기여를 권하는 조언이 반복적으로 제시됨. 이를 ‘체크리스트’로 부를 수 있음.
  • 이 조언 자체가 나쁜 것은 아니지만, 충분히 많은 사람이 따르면서 조언이 아니라 최소 기준이 됨.
  • 대형 언어 모델(LLM)의 등장으로 채용 공고의 조건을 모두 충족하는 정교하고 맞춤화된 이력서를 작성하거나 포트폴리오 프로젝트를 빠르게 만드는 일이 훨씬 쉬워짐.
  • 체크리스트는 그 어느 때보다 덜 독특해졌으며, 차별화 요소가 아니라 최소 요구사항이 됨.
  • 무료 기술 교육과 커리어 지원을 제공하는 자선단체 CodeYourFuture와의 멘토링 경험에서도 이런 상황이 확인됨.
  • 멘토링 대상자들은 현재 위치에 오기까지 열심히 노력했으며, 일부는 첫 직장을 구하기 위해 학습 중이고 일부는 이미 업계에 진입해 다음 단계로 나아갈 방법을 찾는 중임.
  • 이들에게 부족한 것은 대체로 체크리스트 항목이 아님. 자격증과 GitHub 저장소를 갖추고 지시받은 일을 모두 수행하지만, 여전히 돋보이기 어려워함.
  • 돋보이기 위해 필요한 것은 LinkedIn에 자격증을 하나 더 추가하는 일이 아님.

채용에서 중요한 역량

  • 올해 London Tech Week에서 업계 주요 기업의 연사들이 반복해서 제시한 채용 희망 역량은 호기심, 적응력, 학습 능력임.
  • 채용 담당자들은 익숙하지 않은 코드베이스를 파악하고, 다른 맥락에서 일하며, 무너지지 않고 문제 영역을 전환할 수 있다는 증거를 원함.
  • 이런 특성은 특정 기술 자격증보다 더 중요하게 평가됨.
  • 다만 모든 연사가 인정했듯이 호기심·적응력·학습 능력은 이력서, 자기소개서, 심지어 기술 면접만으로 평가하기 어려움.
  • 자격증 목록은 누군가 무엇을 배웠는지는 보여주지만, 어떻게 사고하는지, 낯선 상황에 어떻게 대응하는지, 일상 업무 밖에서도 지적 호기심을 보이는지는 보여주지 않음.
  • 채용 담당자가 원하는 것과 전통적인 채용 방식이 드러낼 수 있는 것 사이의 간극이 실제 문제이며, 체크리스트는 애초에 이 문제를 해결하도록 설계되지 않음.

직접 작성하지 않은 코드에 기여하기

  • 이 간극을 좁히는 출발점은 직접 구축하지 않은 오픈소스 프로젝트에 기여하는 일임.
  • 직접 시작한 프로젝트나 모든 맥락을 알고 있는 프로젝트가 아니라, 낯선 프로젝트를 찾아 코드를 읽고, 의사결정 당시 현장에 없었더라도 그 결정이 어떻게 이뤄졌는지 이해한 뒤 유용한 작업을 수행해야 함.
  • 이는 실제 고용 환경과 훨씬 가까운 상황을 제공함.
  • 다른 사람이 설계한 아키텍처를 탐색함.
  • 자신을 알지 못하는 사람들의 코드 리뷰를 받으며 작업함.
  • 서로 모순되는 코딩 스타일과 패턴이 공존하는 레거시 코드베이스를 다룸.
  • 자신이 설계하지 않은 시스템을 학습할 수 있다는 점을 구체적으로 보여주며, 이는 실제 업무의 대부분을 차지하는 역량임.

혼란에서 출발해 글쓰기

  • 다음 단계는 관점을 개발하고 이를 공개된 공간에 남기는 일임.
  • 튜토리얼을 작성하라는 뜻은 아님. 튜토리얼은 체크리스트의 또 다른 형태이며, 많은 사람이 작성해 내용이 서로 비슷해지는 경향이 있음.
  • 더 드물고 유용한 것은 혼란을 솔직하게 기록하는 일임.
  • 문제를 해결한 뒤의 버전이 아니라, 혼란을 겪은 경험을 씀.
  • 무엇이 구체적으로 이해되지 않았는지, 무엇이 어떻게 이해되기 시작했는지, 그 이유가 무엇인지 정확히 설명함.
  • 이런 구체성이 글을 기억에 남게 함.
  • 혼란에 가까이 있을 때 글을 써야 할 실용적인 이유도 있음. 일부 시니어 엔지니어는 무언가를 진정으로 이해하지 못했던 감각을 잊었을 수 있기 때문임.
  • 아직 남아 있는 그 기억은 자산이며, 희미해지기 전에 활용해야 함.

비엔지니어도 따라올 수 있게 말하기

  • 가장 위조하기 어렵고 가장 쉽게 소홀히 하는 역량은, 기술적 결정을 내리지 않았고 같은 기준틀을 공유하지 않는 사람에게 그 결정을 전달하는 능력임.
  • 이를 기술 내용을 쉽게 만드는 일로 오해해서는 안 됨. 그런 관점은 상대를 낮춰 보는 태도이며 정확하지도 않음.
  • 번역은 별개의 기술임. 전달하려는 내용을 충분히 이해해야 다른 경로를 찾아 설명할 수 있음.
  • 많은 초기 경력 엔지니어는 더 많은 경험을 쌓고 기술적 기반을 다진 뒤에 이 역량을 개발하려 함.
  • 그러나 이는 나중에 익히는 기술이 아니라 기반 기술이며, 아직 편안하지 않은 시기에 일찍 구축하는 편이 나중에 덧붙이는 것보다 상당히 쉬움.
  • 주니어 엔지니어는 다른 기술 인력과 함께 있을 때 자연스럽게 기술 용어로 말하는 경향이 있으며, 이 기본값이 오래 문제 제기 없이 유지될수록 바꾸기 어려워짐.

실제 이해관계가 있는 일 찾기

  • 초기 경력 엔지니어에게 가장 과소평가된 또 하나의 경로는 무료로 기술 업무를 수행하는 일임.
  • 영국에는 이를 위해 만들어진 플랫폼이 있으며, 예시는 reachvolunteering.org.uk, doit.life, CodeYourFuture임.
  • 다른 지역에도 유사한 플랫폼과 단체가 존재할 수 있으며, 많은 자선단체가 원격으로 일하는 사람들의 도움을 받을 의향이 있을 수 있음.
  • 사이드 프로젝트와 다른 점은 기술적 난이도가 아니라 이해관계가 자신이 아닌 다른 사람에게 있다는 점임.
  • 제약 조건이 실제로 존재함.
  • 부실한 작업의 결과가 GitHub 프로필 바깥의 어딘가에 영향을 미침.
  • 그 일을 하기로 한 결정은 전적으로 자신의 선택임.
  • 동시에 사회에 좋은 일을 하므로, 그 자체만으로도 충분한 이유가 됨.
  • 채용 담당자는 자원봉사 활동을 긍정적으로 평가하는 경향이 있음.
  • 아무도 요구하지 않은 이런 일을 선택하는 것은 체크리스트가 보여줄 수 없는 방식으로 채용 담당자가 찾는 호기심과 주도성을 정확히 나타냄.

자격증보다 행동

  • 이 모든 것이 체크리스트를 대체하는 것은 아님.
  • 체크리스트는 면접실에 들어가게 해주며, 애초에 그 이상의 역할을 하도록 만들어진 것이 아님.
  • 그 밖의 모든 요소는 자격증이 아니라 행동이며, 주장하는 것이 아니라 직접 보여주는 것임.
  • 이제 자격증은 생성할 수 있지만, 행동은 실제로 살아내야 함.
  • 이것이 AI가 위조할 수 없는 요소이며, 누군가를 계속 함께 일할 가치가 있는 사람으로 만드는 요소임.