끊임없이 변하는 세상에서 가장 중요한 기술은 안목이다.
누구에게나 옳은 말은 아닐 것이다. 하지만 새로운 것을 알아보는 능력, 다른 이의 작업을 알아보는 능력 또는 어떤 일을 할 수 있는 여러 방법을 비교하고 당신, 팀, 프로젝트, 조직에 가장 적합한 것을 고를 수 있는 능력은 어마어마하게 소중하다. 내가 아는 이 대부분은 이에 능하지 못했고, 내가 아는 대부분의 리더는 이 부분에선 정말 엉망이었다.
누군가 당신에게 이걸 해야 한다고 말하는 일이나 블로그에서 읽은 것 또는 모두가 하는 걸 그대로 해내는 건 쉽다. 목적과 모든 면을 고려하여 살펴보고 자신에게 가장 잘 맞는 최적의 선택을 하는 게 훨씬 어렵다. 누구나 선택을 해야 하지만, 어떤 이들은 평가 자체를 두려워하여 아무거나 골라버리거나 남들이 하는 대로 따라가는 일도 흔하다.
목적을 달성하는 방법엔 여러 가지가 있지만, 고객 입장에선 뭐든 상관없다.
고객은 개발자가 겪는 문제가 뭔지 관심 없다. 그저 결과물인 소프트웨어가 자신이 원하는 작업을 해결해주길 바랄 뿐이다.
시스템에 문제가 생기고 예외가 발생하든 개발 장비에 문제가 생겼든 다른 개발자가 진상이거나 해커가 침입했든, 사용자에게는 별로 중요한 문제가 아니다. 문제가 생겼을 때 정직해지는 건 좋다. 그게 가끔이라면 말이다. 하지만 고객이 보기 전에 문제가 오래가지 않도록 해두는 편이 더 좋다.
목적을 달성하는 방법엔 여러 가지가 있지만, 고객 입장에선 뭐든 상관없다.
고객은 개발자가 겪는 문제가 뭔지 관심 없다. 그저 결과물인 소프트웨어가 자신이 원하는 작업을 해결해주길 바랄 뿐이다.
시스템에 문제가 생기고 예외가 발생하든 개발 장비에 문제가 생겼든 다른 개발자가 진상이거나 해커가 침입했든, 사용자에게는 별로 중요한 문제가 아니다. 문제가 생겼을 때 정직해지는 건 좋다. 그게 가끔이라면 말이다. 하지만 고객이 보기 전에 문제가 오래가지 않도록 해두는 편이 더 좋다.
로그를 남기지 않아 몰랐던 것이 큰 문제가 될 수 있다.
오늘날에도 소프트웨어가 어떻게 동작하는지 알기 위해 로그나 크래시 리포트, 사용 정보를 충분히 수집하지 않는 걸 보면서 놀라곤 한다. 이러한 정보를 수집하지 않는 사람들은 품질을 과신한다.
측정하고 기록하지 않으면 고객은 당연히 알게 될 문제를 개발자는 알 수 없다. 어떤 문제든 발생하는 즉시 알 수 있도록 나는 늘 세밀하고 유용한 로그, 크래시 추적, 리뷰와 코멘트 등 수집할 수 있는 건 모조리 해야 한다고 주장해왔다. 물론 아직도 이런 것들이 개발자가 되는데 전혀 필요 없다고 생각하는 사람들도 있지만 말이다.
포트폴리오
· 가능하면 GitHub이나 BitBucket 같은 Git 호스팅 서비스에 올려두자. 요즘은 SVN이든 Git이든 VCS를 사용하지 않는 업체를 찾기 어려울 정도다. 혹시 VCS를 전혀 사용하지 않는 개발 업체가 있다면 입사를 다시 한번 고민해보라고 진지하게 말하고 싶다. 입사 지원자에게 GitHub 계정 링크를 알려달라는 곳이 해외는 물론 국내에도 꽤 있다. 가능하면 포트폴리오를 앞서 말한 두 서비스 중 하나를 택해서 올려두는 게 좋다. 개인적으로는 GitHub을 추천하는데, 사용자가 더 많아서 문제가 생겼을 때 도움을 구하기 쉽기 때문이다.
· .gitignore 파일에 .idea 폴더나 npm-debug.log 같은 불필요한 파일은 포함되지 않게 설정해두자. 코딩 능력과 상관없는 거지만 기본적인 사용법을 모르는 것처럼 보일 수 있다.
· 커밋 메시지는 의외로 많은 것을 말해준다. 신경 써서 좋은 커밋 메시지를 작성하는 게 좋다.
· 혹여 포트폴리오 소개서를 쓴다면 사용한 기술은 나열은 하되 강조하지는 않는 걸 추천한다. 신입에게는 대단한 기술 스택일지 몰라도 (아마) 면접관들에게는 그리 대단하지 않을 공산이 큰데, 그런 걸 강조하면 오히려 더 없어 보이기 때문. 반면 만에 하나라도 면접관의 관심을 끌 만한 기술이라면 굳이 강조하지 않아도 눈에 띌 것이다.
· 개인 프로젝트라 하더라도 테스트 케이스는 성의껏 작성해두자. 코딩 전에 하든 후에 하든, 어쨌든 작성해 두는 게 좋은 인상을 줄 수 있다.