내가 보고 싶었던 이력서

_지난 편에서는 8년간의 채용 경험을 통해 깨달은 채용의 본질과 철학에 대해 이야기했습니다. 이번 편에서는 100명이상의 많은 개발자와 만나면서 발견한 구체적인 패턴들과 실용적인 조언을 나누겠습니다._ ## 안타까움 멘토링을 하면서 가장 안타까웠던 점은, 대부분의 지원자들이 충분히 좋은 경험을 가지고 있음에도 불구하고 이를 이력서에 제대로 표현하지 못한다는 것이었습니다. 예를 들어, "이 프로젝트를 3개월간 진행했습니다"라고 단순하게 적어놓은 지원자에게 저는 이런 질문들을 던져봤습니다. - "그 프로젝트를 진행하면서 예상치 못한 문제는 없었나요?" - "팀원들과 의견이 달랐던 적은 없었나요?" - "처음 계획했던 것과 달라진 부분이 있나요?" 그러면 훨씬 더 구체적이고 흥미로운 이야기들이 나왔습니다. 어떤 개발자는 이렇게 말했습니다. > "사실 중간에 기술 스택을 바꿔야 했어요. 처음에는 A 기술을 쓰려고 했는데, 성능 이슈가 있어서 B로 전환했거든요. 그 과정에서 팀 전체가 새로운 기술을 배워야 했고, 일정이 지연될 위험이 있었지만..." 이런 내용이야말로 이력서에 들어가야 할 가치 있는 경험인데, 정작 이력서에는 "○○ 프로젝트 개발 참여"라고만 적혀 있었습니다. 이런 경험이 반복되면서 사람들이 자신의 경험을 과소평가하는 경향이 있다는 것을 깨달았습니다. '이 정도는 누구나 겪는 일이겠지', '이런 걸 굳이 써야 하나?' 같은 의구심 때문일 것입니다. 하지만 채용 담당자 입장에서는 바로 그런 구체적인 경험과 문제 해결 과정에서의 사고방식이 궁금한 것입니다. ### 의미 없는 수치들 먼저 '기여도'라는 표현에 대해 이야기해보겠습니다. "이 프로젝트에 40% 기여했습니다"라고 적힌 이력서를 자주 봅니다. 하지만 이 40%라는 숫자가 정확히 무엇을 의미하는지 알기 어렵습니다. 예를 들어 3명이서 한 프로젝트라면, 수학적으로는 각각 33.3%씩 기여해야 합니다. 그런데 실제로는 한 명은 40%를 했다고 하고, 다른 한 명은 50%를 했다고 합니다. 그렇다면 나머지 한 명은 10%만 한 건가요? 아니면 모든 사람이 자신의 기여도를 높게 평가하는 건가요? 기여도의 기준도 애매합니다. 코딩한 줄 수로 계산하는 건가요? 그렇다면 같은 기능을 100줄로 구현한 사람과 50줄로 구현한 사람 중 누가 더 기여한 건가요? 아니면 참여한 시간으로 계산하는 건가요? 그렇다면 10시간 만에 핵심 기능을 구현한 사람과 30시간에 걸쳐 부가 기능을 만든 사람 중 누가 더 기여한 건가요? 실제 프로젝트에서는 각자 다른 역할을 합니다. 누군가는 초기 설계를, 누군가는 핵심 로직 구현을, 누군가는 테스트와 디버깅을 담당합니다. 이처럼 서로 다른 역할들을 하나의 퍼센트로 표현하는 것은 무의미하다고 생각합니다. 차라리 "프로젝트에서 제가 담당한 역할은 ○○였고, 그 과정에서 ××한 문제를 △△한 방식으로 해결했습니다"라고 구체적으로 설명하는 것이 훨씬 의미 있습니다. 매출 기여도도 비슷한 문제가 있습니다. "이 기능을 개발해서 매출이 20% 증가했습니다"라는 표현을 가끔 봅니다. 하지만 매출 증가에는 정말 많은 요인들이 작용합니다. 새로운 기능의 효과일 수도 있지만, 마케팅 캠페인, 시장 상황의 변화, 경쟁사의 실수 등 다양한 변수가 있습니다. 특히 개발자나 디자이너처럼 직접적으로 비즈니스에 관여하지 않는 직군에서는 이런 표현이 설득력이 떨어질 수 있습니다. 물론 경력이 많거나 비즈니스에 직접 관여하는 역할이라면 이런 지표들이 의미가 있을 수 있습니다. 하지만 대부분의 개발자들에게는 "어떤 기능을 어떻게 구현했는지", "그 과정에서 어떤 고민과 선택이 있었는지"가 더 중요한 정보라고 생각합니다. ### 빈 링크 GitHub 링크나 블로그 링크를 이력서에 넣는 경우가 많습니다. 이런 링크를 넣는 이유는 대개 두 가지인 것 같습니다. 하나는 개발 실력을 보여주기 위해서이고, 다른 하나는 성실함을 어필하기 위해서입니다. 하지만 여기에는 큰 함정이 있습니다. 링크를 넣어놓고 막상 들어가 보면 아무것도 없거나 거의 비어있는 경우가 있습니다. 이런 경우에는 오히려 마이너스가 됩니다. 차라리 링크를 넣지 않는 것이 나을 수도 있습니다. GitHub의 경우를 예로 들어보겠습니다. 채용 담당자가 GitHub 링크를 클릭했을 때, 만약 저장소가 거의 비어있다면 솔직히 말해서 짜증이 납니다. "아무것도 없는데 왜 링크를 넣은 거지? 왜 내 시간을 빼앗는 거지?"라는 생각부터 듭니다. 그 다음에야 "아, 이 사람은 평소에 개발에 대한 관심이 그렇게 높지 않은가?" 같은 판단이 따라옵니다. 물론 회사 업무가 바쁘거나 개인적인 사정으로 개인 프로젝트를 할 시간이 없을 수도 있지만, 첫인상에서는 그런 사정을 알기 어렵습니다. 성실성 측면에서도 고려할 점이 있습니다. GitHub 활동이나 블로그 포스팅은 이직 시즌에만 하는 것이 아니라 평상시에도 꾸준히 해야 하는 것입니다. 만약 입사 후에 "사실 저는 개인 시간에는 개발을 잘 안 해요"라고 한다면 조금 어색할 수 있습니다. 물론 회사 업무와 개인 프로젝트는 다르지만, 어느 정도의 일관성은 필요할 것 같습니다. 만약 GitHub 링크를 넣기로 했다면, 저는 보통 이런 것들을 봅니다. 먼저 저장소 목록을 보면서 어떤 종류의 프로젝트들을 했는지 파악합니다. 그 다음 몇 개의 저장소에 들어가서 커밋 히스토리를 봅니다. 커밋 메시지가 의미 있게 작성되어 있는지, 적절한 단위로 커밋이 나뉘어져 있는지 확인합니다. 그리고 실제 커밋 내용을 보면서 메시지와 변경 사항이 일치하는지도 봅니다. 여기서 몇 가지 아쉬운 부분들이 있습니다. 예를 들어 "fix bug"라는 메시지와 함께 전혀 관련 없는 기능이 추가되어 있다면, 커밋 관리에 신경을 쓰지 않는다고 판단할 수 있습니다. 코드에 린팅이 제대로 되어 있지 않거나, 명백히 불필요한 console.log 같은 디버깅 코드가 그대로 남아있다면 아쉽습니다. 또한 Git으로 형상관리를 하고 있는데도 사용하지 않는 코드나 임시로 막아둔 코드들을 주석 처리해서 그대로 남겨둔 것들도 아쉽습니다. 버전 관리 시스템이 있는데 왜 주석으로 코드를 보관하는 건지 이해하기 어렵습니다. 물론 이런 것들이 치명적인 감점 요소는 아닙니다. 하지만 여러 명의 지원자 중에서 선택해야 하는 상황이라면, 이런 세부적인 것들도 판단 요소가 될 수 있습니다. 블로그도 비슷합니다. 블로그 링크를 넣는 이유는 대개 성실성을 보여주거나 글쓰기 능력, 더 나아가서는 논리적 사고 능력을 어필하기 위해서인 것 같습니다. 여기서 말하는 글쓰기 능력은 문장력이나 문학적 표현력을 의미하는 것이 아닙니다. 전반적인 논리 구조를 가지고 있는지, 생각의 흐름을 체계적으로 정리할 수 있는지를 보는 것입니다. 하지만 막상 블로그에 들어가 보면 의미 있는 글이 별로 없는 경우가 있습니다. 예를 들어 "오늘 배운 것" 형태의 TIL(Today I Learned) 글들만 몇 개 있거나, 인터넷에서 찾을 수 있는 일반적인 기술 설명들만 정리해놓은 경우입니다. 물론 이런 글들도 나름의 의미가 있지만, 채용 담당자 입장에서는 "이 사람만의 특별한 관점이나 경험"을 찾기 어렵습니다. 차라리 "이런 문제가 있어서 이렇게 해결했다", "이 기술을 써보면서 이런 점이 좋았고 이런 점은 아쉬웠다", "이런 상황에서 이런 선택을 했는데 그 이유는 이것이다" 같은 개인적인 경험과 생각이 담긴 글이 몇 개라도 있으면 훨씬 의미 있다고 생각합니다. ### 모든 경험을 다 넣는 함정 이력서에 자신이 했던 모든 경험을 다 넣으려는 경우도 자주 봅니다. 아마도 "많이 써놓으면 그 중에 하나라도 채용 담당자의 눈에 띌 것이다"라는 생각 때문일 것입니다. 하지만 양이 많다고 해서 합격 확률이 높아지는 것은 아닙니다. 오히려 정말 중요한 경험들이 묻힐 수 있습니다. 예를 들어보겠습니다. A 지원자가 10개의 프로젝트 경험을 나열했는데 그 중 8개는 평범하고 2개만 정말 인상적이라고 하겠습니다. B 지원자가 3개의 프로젝트만 적었는데 모두 흥미롭다고 하겠습니다. 채용 담당자는 한 사람의 이력서를 보는 데 많은 시간을 할애할 수 없기 때문에, A의 이력서에서는 인상적인 2개를 놓칠 가능성이 있습니다. 반면 B의 이력서는 모든 내용을 꼼꼼히 읽을 가능성이 높습니다. 물론 "목구멍이 포도청"이라고, 급하게 취업을 해야 하는 상황에서는 조금이라도 가능성을 높이고 싶은 마음이 이해됩니다. 하지만 여기서 중요한 것은 내가 지원하려는 회사나 팀이 어떤 곳인가 하는 점입니다. 만약 단순히 특정 기술을 다뤄본 경험이 있는 사람을 찾는 회사라면, 관련된 모든 경험을 나열하는 것이 도움이 될 수 있습니다. 하지만 그런 회사는 보통 장기적으로 함께 성장하기보다는 당장 필요한 기능을 구현할 수 있는 사람을 찾는 경우가 많습니다. 기술은 계속 변화하고 새로운 것이 나오는데, 그런 환경에서는 지속적인 성장이 어려울 수 있습니다. 반면에 함께 성장하고 싶어하는 회사라면, 지원자의 사고방식이나 문제 해결 능력, 학습 태도 같은 것들을 더 중요하게 볼 것입니다. 이런 회사에서는 10개의 평범한 경험보다 3개의 깊이 있는 경험이 더 의미 있게 받아들여질 수 있습니다. ### 제가 직접 개발한 게 아닌데 넣어도 되나요? 이 질문을 정말 자주 받습니다. 특히 주니어 개발자들이나 팀에서 주로 보조 역할을 했던 분들이 많이 하는 질문입니다. 제 생각에는 **내가 완벽하게 설명할 수 있다면 넣어도 된다**고 봅니다. 여기서 중요한 것은 "완벽하게 설명할 수 있다"는 부분입니다. 단순히 "제가 그 프로젝트에 참여했어요"가 아니라, "그 프로젝트에서 이런 문제가 있었고, 우리는 이런 방식으로 해결했으며, 제가 비록 직접 코딩하지는 않았지만 이 과정을 완전히 이해하고 있고, 만약 비슷한 상황이 생긴다면 같은 방식으로 해결할 수 있어요"라고 말할 수 있어야 한다는 뜻입니다. 실제로 실무에서도 그렇습니다. 매니저들의 이력서를 생각해보면, 매니저가 직접 코딩한 것은 거의 없습니다. 하지만 프로젝트 전체를 설계하고, 문제가 생겼을 때 해결 방향을 제시하고, 팀원들에게 기술적 가이드를 제공하는 것은 매니저의 몫입니다. 어떻게 보면 매니저가 더 많은 '기여'를 했다고 볼 수도 있습니다. 반대로 내가 직접 타이핑한 코드라고 해도, 정작 "왜 그렇게 구현했는지", "다른 방법은 고려해보지 않았는지", "그 기술을 선택한 이유가 무엇인지" 같은 질문에 제대로 답변하지 못한다면, 그것이 정말 '내 것'이라고 할 수 있을까요? 면접에서 중요한 것은 코드를 누가 타이핑했느냐가 아니라, 그 과정에서 어떤 사고를 했는지, 어떤 판단을 내렸는지, 그리고 그 경험을 통해 무엇을 배웠는지입니다. 만약 내가 직접 개발하지 않았더라도 그 모든 과정을 이해하고 설명할 수 있다면, 그것만으로도 충분히 의미 있는 경험이라고 생각합니다. ## 마치며: 채용은 서로를 찾아가는 과정 이런 긴 이야기를 하고 나면 항상 마지막에 하는 말이 있습니다. 제가 하는 이야기가 절대적인 기준은 아니라는 것입니다. 채용 담당자마다 중요하게 생각하는 포인트가 다르고, 회사마다 추구하는 방향이 다르며, 팀마다 필요로 하는 역할이 다릅니다. 제 기준에서는 좋아 보이지 않는 이력서라도 다른 회사에서는 매우 매력적으로 받아들여질 수 있습니다. 그래서 저는 항상 "이런 관점도 있다"는 식으로 이야기하려고 합니다. "무조건 이렇게 해야 한다"가 아니라 "이런 시각에서 보는 사람도 있으니 참고해보세요"라는 의미입니다. 최근 1년간 100명과 만나면서 가장 아쉬웠던 점은, 정말 좋은 경험과 역량을 가진 사람들이 그것을 제대로 표현하지 못하고 있다는 것이었습니다. 조금만 더 구체적으로, 조금만 더 자신 있게 표현한다면 훨씬 매력적인 지원자가 될 수 있을 텐데 하는 안타까움이 있었습니다. 채용이라는 것은 결국 서로를 찾아가는 과정입니다. 회사는 자신들과 잘 맞는 사람을 찾고, 지원자는 자신이 성장할 수 있고 만족할 수 있는 회사를 찾습니다. 이력서와 면접은 그 과정에서 서로를 이해하기 위한 도구일 뿐입니다. 그런 관점에서 이력서를 작성할 때는 "어떻게 하면 나를 좋게 포장할 수 있을까"보다는 "어떻게 하면 나의 진짜 모습을 제대로 전달할 수 있을까"를 고민하는 것이 더 중요할지도 모릅니다. 그래야 서로에게 맞는 조합을 찾을 수 있고, 결과적으로는 모두에게 도움이 되는 결과를 만들 수 있을 것입니다. 강의실에서 마주하는 학생들의 진지한 눈빛을 보면, 이들이 단순히 '취업'이라는 목표를 넘어서 자신만의 길을 찾아가길 바라게 됩니다. 이 글이 이력서를 고민하고 있는 분들에게 조금이나마 도움이 되기를 바랍니다. 그리고 무엇보다, 여러분이 가진 좋은 경험들을 더 자신 있게 표현하는 계기가 되었으면 합니다.