주니어 개발자 이력서 작성 2 - (내용 채우기와 첨삭)

개요

---

 열심히 기능 개발하고, 버그 잡고, 배포도 했는데 막상 글로 적으려니 XX 기능 개발, YY 페이지 구현 같은 밋밋한 문장밖에 떠오르지 않았다. 솔직히 그런 것들은 기본적으로 해야하는 것들이다. 정말 특수한 기능, 알고리즘이 들어간다거나 혹은 완전히 새로운 로직이 들어가는 기능이 아니고서 구현이나 개발 이라는 것을 쓰는건 작성하는 사람이나 읽는 사람이나 모두 시간낭비가 될거라고 생각했다.

 

 일단 기억나는 대로 적어서 주변의 현업 개발자 지인들에게 피드백을 요청했다. 돌아온 답변은 이랬다.

 

 

"너무 겸손하게 작성하면 안돼."

"이건 자랑인 거랑 자랑 아닌 게 섞여 있어서 평균이 깎여 보여."

"자기소개에 대한 증거가 없어. 임팩트를 끼쳤다는 증거가 될 만한 내용이 하나도 없잖아."

 

 

 이력서는 겸손을 떠는 곳이 아니라 나를 세일즈하는 문서라는 것을 머리로는 알았지만, 실제로는 실천하지 못하고 있었다. 지인들에게 받은 피드백을 바탕으로 이력서를 어떻게 뜯어고쳤는지, 그 과정을 기록해보기로 했다.

 

들어가기 전에 미리 보는 대략적인 이력서

전체적인 모습은 이런식으로 작성했다. 전체 2페이지로 정리했다. ▼

 

 

일단 다 적고 줄여라

---

 우선 무엇을 적어야 할 지 모르겠다면 다 적고 시작하라는 말을 들었다. 쌩신입도 아니고, 모바일에서 웹으로 전직하는 상황에서 어떤 것들을 적어야할 지 모르겠는 상황이었다. 신입의 관점이 아닌 경력직의 관점에서 이런 문구를 적어도 되나? 하는 생각이 많았다. 그렇게 너무 사소한가 싶어서 적지 않은 것들이 많아지면서 이력서가 듬성듬성해 보였다. 이런 상황에서는 피드백이고 뭐고 받을 수도 없었다.

 

 

"일단 생각나는 거 다 쓰고, 10장이든 20장이든 쓴 다음에 줄여라."

"쓰고 나서 줄이셈"

 

 

 이 조언은 굉장히 유효했다. 일단 필터링 없이 내가 했던 모든 업무와 트러블 슈팅 경험을 쏟아냈다. 그러고 나서 다시 읽어보니 '아, 이건 진짜 별거 아니네', '어? 이건 생각보다 임팩트가 있었는데?' 하는 것들이 구분되기 시작했다.

 

자랑거리와 수치화

 가장 뼈아픈 피드백은 자기소개에 대한 증거를 찾기 어렵다는 것이었다. 나는 자기소개에 비즈니스 임팩트를 창출했다고 적어놓고, 정작 프로젝트 설명에는 동아리 운영을 위한 사이트 개발정도로만 적어놨었다.

 

 내 입장에서는 100명이 넘는 인원을 보유한 동아리 운영을 전면 디지털화 하고, 흩어져있던 자료들을 한 군데로 모으는 일을 했기에 충분히 비즈니스 임팩트가 있었다고 생각했다. 하지만 읽는 사람 입장에서는 동아리 운영에 대한 비하인드를 모르기에 '그래서 무슨 임팩트를 줬는데?' 라는 의문이 생길 수밖에 없다.

 

수정 전 : 행위 위주의 설명

기존에는 단순히 무엇을 했는지 행위 위주로 적었다. ▼

민둥한 행위 위주의 이력서

 

이것만 봐서는 내가 기술적으로 어떤 고민을 했는지, 얼마나 기여했는지 알 수가 없다.

 

수정 후 : 수치와 기술적 의사결정

피드백을 수용하여 수치와 구체적인 기술셋을 명시했다. ▼

수치로 환산해서 적었다

 

TurboRepo를 이용한 모노레포 아키텍처 설계로 빌드 시간 70% 단축

• 4개의 개별 레포지토리를 모노레포로 통합하여 코드베이스 효율성 및 개발 워크플로우 개선
• 증분 빌드 및 캐싱 적용으로 빌드 시간 약 70% 단축 (평균 1분 50초 → 평균 30초)

하이브리드 SSG 적용과 이미지 최적화를 통한 성능 29% 개선

• (Vercel Speed Insight 75점 → 97점, Lighthouse 74점 → 83점)

 이렇게 바꾸니 그냥 사이트 만들었네가 아니라, 모노레포를 도입해서 빌드 효율을 높였고, 구체적인 성능 최적화를 할 줄 아는 개발자라는 증거가 확실해졌다.

 

 

배치의 심리학

---

이력서에 적은 내용들의 퀄리티가 들쭉날쭉하다는 피드백도 있었다.

 

"20점짜리, 90점짜리, 70점짜리 경험을 다 보여주면 합쳐서 180점만큼의 매력이 보일 것 같지만,

사실은 가장 먼저 본 20점만큼 보이게 된다."

 

 사람은 본능적으로 위에서부터 읽는다. 그리고 처음에 읽은 내용으로 그 사람의 수준을 판별해버린다. 그런데 맨 위에 20점짜리(누구나 할 수 있는 단순 구현 등) 경험이 있다면? 뒤에 90점짜리 경험이 있어도 아, 이 정도 수준의 개발자구나라고 판단을 내리게 된다.

 

그래서 아래의 작업들을 했다. ▼

• 과감하게 20점짜리 경험은 삭제하거나 맨 뒤로 뺐다.
• 가장 자신 있는 프로젝트, 가장 기술적 챌린지가 컸던 경험을 최상단으로 올렸다.

자랑거리만 적기에도 지면은 부족하다. 굳이 시간 순서대로 적겠다고 내 점수를 깎아먹는 방어적인 내용은 적을 필요가 없다.

 

 

주니어에게 기대하는 것

---

 이력서 작성을 할 때 '기술적으로 엄청 뛰어남을 보여줘야하지 않나 ?'하는 생각이 있었다. 그래서 로직적인 부분을 많이 보여야 하나 하던 찰나 지인의 조언이 들어왔다.

 

 

"주니어가 기술적으로 잘한다가 그렇게 중요한 건 아닌 듯.

'돈 받고 일해봤고, 뭐라도 해보려고 했다'를 보여주는 게 중요함."

 

 

 단순히 코딩을 잘한다는 것보다, 주어진 환경에서 문제를 해결하기 위해 어떤 시도를 했는지, 그리고 그게 비즈니스(돈, 시간)적으로 어떤 이득을 가져다주었는지를 보여주는 것이 일 잘하는 주니어의 증명서가 된다.

 

 대학생과 현업자의 차이점은 돈을 받고 프로덕트를 만들어봤냐이다. 물론 체계적인 아키텍쳐의 경험 유무도 크지만, 돈을 받고 안받고의 차이는 크다. 토이 프로젝트나 사이드 프로젝트들은 그 프로젝트가 지지부진해도 큰 문제도 없고, 그와 동시에 책임감도 사라진다. 그렇기에 그 책임감의 차이를 보게 된다.

 

 그래서 나는 프로젝트 설명에 단순히 React 사용이라고 적는 대신, 인트라와 어드민 도메인 간 공유되는 UI 컴포넌트 패키지화로 코드 중복 제거 와 같이 효율성을 고민한 흔적을 담으려 노력했다. 해당 부분이 기술적으로 엄청나게 잘 했다는 아니지만 뭐라도 해보려고 했다를 강조할 수 있다고 생각했다.

 

 어차피 기술적으로 정말 뛰어난지를 판가름 하는 부분은 기술면접에서 보여진다. 회사에서 요구하는 최소치의 기술과 내가 할 줄 안다고 적어놨던 기술들에 대한 판별은 면접에서 이루어지기에, 내가 엄청나게 잘 한다의 어필은 크게 소용이 없는 거 같았다. 실제로도 면접에 갔을 때, 내 프로젝트의 기술들 위주로 질문이 들어왔다.

 

 

대외활동

---

 경력 기술서만큼이나 고민이 많았던 곳이 바로 대외활동란이었다. 대학 졸업한 지 1년 정도밖에 안지났기에 대학 시절 활동도 적어도 된다고 생각했다. 대학 생활동안 나름대로 열심히 살았다고 자부했기에, 스터디, 동아리, 블로그 운영 등 내가 했던 모든 것을 다 적어내고 싶었다.

 

 

"이것저것 많이 했으니 성실해 보이겠지?"

 

 

하지만 피드백을 받아본 결과, 이것 역시 문제가 많았다.

 

수정 전 : 백화점식 나열과 평범한 서술

 처음 작성한 이력서를 보면 'OO 스터디', '테크 블로그 운영', '알고리즘 동아리1', '알고리즘 동아리2', '개발 동아리' 등 굵직한 활동과 사소한 활동이 뒤섞여 있었다.

 

아래의 문제들이 있었다. ▼

1. 임팩트 희석: 단순히 스터디에 참여해서 TIL을 썼다는 내용(20점짜리 경험)이 창립 멤버로 활동한 경험(90점짜리 경험) 옆에 있으니, 전체적인 활동의 무게감이 떨어져 보였다.
2. 모호한 설명: "알고리즘 커뮤니티를 더 개방적으로 개선" 같은 문장은 구체적으로 뭘 했는지 알 수가 없다.
3. 카테고리 오류: "테크 블로그 운영은 활동 경험(Extra-curriculum)으로 치기 어렵다"는 피드백도 있었다.
4. 축소된 설명: 동아리에서 한 일이 꽤나 임팩트 있는 일인데, 그걸 별 거 아닌 듯 너무 축소해서 적었다. 

 

수정 후 : 과감한 삭제와 수치적 증명

피드백을 수용하여 '단순 참여' 수준의 활동(스터디 등)은 과감히 삭제했다. 대신 내가 주도적으로 **'리딩'**했거나 **'변화'**를 만들어낸 활동에 집중해서 살을 붙였다. ▼

수정 전 / 수정 후

 

알고리즘 동아리 1

• 수정 전 - 알고리즘 커뮤니티를 더 개방적으로 개선
• 수정 후 - 기존 활동에 커뮤니티 행사를 추가하여 80명에서 200명으로 학회원 증가

개발 동아리

• 수정 전 - 모든 운영진이 업무에 혼선이 없게끔 워크 플로우를 파악해 노션 설계
• 수정 후 - 27명으로 시작하여 현재 매년 300명 이상의 학회원 유지
• 수정 후 - Notion 기반의 워크플로우를 설계 및 구축하여 운영진의 업무 효율성과 협업 프로세스 개선

 단순히 열심히 운영했다가 아니라, 80명 → 200명 성장, 워크플로우 시스템 구축과 같이 조직에 기여한 성과를 숫자로 명시했다. 읽는 사람에게 '이 사람은 조직을 성장시킬 줄 아는 사람이구나'라는 인상은 훨씬 강하게 남길 수 있었다.

 

 

마치며

---

 이력서 수정 전에는 "나름 열심히 했는데 적을 게 없네"라고 생각했다. 하지만 문제는 경험의 부재가 아니라 표현의 부재였다.

내가 한 일을 숫자로 증명하고, 가장 잘한 것을 맨 위에 배치하고, 비즈니스 관점에서 서술하는 것. 이 세 가지만 지켜도 이력서의 퀄리티는 확실히 달라지는거 같다.