재취업 시기를 겪으면서 다시 내 이력서를 보는 기회가 많아졌고 실제로 제출하는 경우가 생기고 있다. 그런데 나만 그런건지 이력서를 볼 때마다 어딘가 부족해보이고, 뭔가 잘못 작성한듯한 느낌이 든다. ㅜㅜ

한참 취업 준비한다고 이력서를 여러번 고치던 때는 2024년 말까지였고, 이후로 이력서를 방치했다시피 했다. 그래서 다시 이력서 쓰는 법을 상기시킬 겸 큰돌님의 <포트폴리오 어나더레벨> 강의를 수강을 보고 정리한 다음, 내 이력서를 점검하는 시간을 가지려고 한다.

개요

요즘 같이 개발자의 수요 대비 과잉 공급인 시기에, 실력은 기본이요. 포장 능력도 매우 중요하다.
따라서 본 강의에서는 어떻게 최고의 포트폴리오를 만들어내는지에 대해 안내한다.

1. 면접관의 눈으로 본 당신의 포트폴리오

요즘 같이 경쟁이 매우 치열한 상황에서, 단순히 "나는 코딩을 좋아한다.", "오픈소스에 관심있다.", "요구사항을 명확히 이해하는 개발자" 수준의 포트폴리오로는 합격하기 어렵다.

면접관은 증거있는 성과를 원한다.

1.2. 첫 1장에 임팩트를 준다.

면접관은 하루에도 수십 장의 포트폴리오를 본다.
평균 검토 시간은 30s ~ 1m 이다.
그러니까 앞 1장만 보고 넘길 확률이 높고 이는 즉, 1장에 임팩트를 내야 한다.

1.3. 자주하는 실수

• 전화번호, 주소 X -> 메일만 작성한다.
• '신입 개발자'라는 표현은 쓰지 않는다. 어차피 하지 않아도 다 안다.
• 10장 이상의 장문 포트폴리오를 지양하자. 1~3장이 적절하다.
• 3.8 미만인 경우 학점은 쓰지 말자.
• 특목고가 아닌 경우 고등학교 학력 적지 말자.
• 개발철학 같은 추상적 서술 X
• React 17.0.2 처럼 버전 쓰지 않아도 된다.
• 문장을 줄이지 않고 장문으로 쓰지 말자.

1.4. 집중해야 할 것은 2개

1. 문제 해결 능력

• 디테일하게 설명해야 한다.
• 예: API 서버 부하 테스트 구현 (X) -> API 서버 부하 테스트 (JMeter) 결과, tps 200 -> 1,200 개선 (O)

2. 수치화된 결과

• 추상적인 표현보다 숫자로 표현한다.
• 예: API 응답속도 개선 (X) -> 1.2s에서 320ms로 73% 단축 (O)

2. 무엇을 보여줄 것인가

2.1. 주제

다음과 같은 소개는 이제 그만하자.

• "오픈소스를 좋아하는 개발자입니다."
• "빠르게 배우는 개발자입니다."
• "성실하고 책임감있는 개발자입니다."

대신, 성과와 기여 중심으로 작성하자.

• AWS 비용 최적화 프로젝트 담당하면서 비용 30% 절감
• Redis 캐시 도입하면서 서버 응답속도 1.2에서 320ms로 개선
• GitHub Actions CI/CD 구축하면서 배포 시간 40분에서 5분으로 단축

그리고 면접관에게 "어? 이런 것도 했어?" 하면서 상세 링크로 가게 하는 것이 포인트이다.
ex) ~~ 오픈소스에 기여 (https://github.com/~~~~~)

직군에 따라 보여줘야 하는 강점도 다르다.

- 백엔드: 비용, 안정성, 트래픽 개선 등

• 프론트엔드: UX 개선 (로딩 속도)

2.2. 배치 순서

1. 나의 역량을 꾹꾹 담아 쓴 3줄 이내 소개글
2. 프로젝트, 경력, 학력, 커뮤니티 활동 순으로 나열한다. 이때, 내가 가진 강점을 잘 보여줄 수 있는 활동 순으로 적절히 배치한다. 대신, 기본적으로 프로젝트는 최신순 내림차순으로 한다. 대신, 과거에 했던 프로젝트 중에서 성과를 잘 보여줄 수 있는 프로젝트라면 상위로 올린다.

3. 면접관을 사로잡는 문장의 힘

3.1. 합격하는 문장 템플릿

• 문제: ~~한 상황에서
• 해결: ~~기술/방법을 사용하여 해결
• 결과: ~~만큼 개선/성과 달성

말 끝에는, '함.' 또는 '했다.'로 요약해서 표현한다.

아래는 예시다.

• 문제: API 응답 지연으로 사용자 이틀 발생 (평균 1.8s)
• 해결: DB 인덱싱과 Redis 캐시 도입
• 결과: 응답 속도 1.8s -> 0.4s (78% 개선), 서버 비용 30% 절감

-> "API 응답 지연(avg 1.8s)으로 사용자 이탈 발생했으며 이를 DB 인덱싱과 Redis 캐시(Query Caching)으로 응답속도를 78% 개선, 서버 비용을 30% 절감함."

각 주제별 써야하는 워딩

• 성능: 응답속도 ns -> n`s, 처리량 n배 증가
• 비용: 서버 비용 n% 절감
• 사용자: DAU/MAU n% 증가
• 안정성: 에러율 n% -> n`%
• 협업: 배포 주기 n일 -> n`일

4. 기술에는 근거가 있어야 한다.

각 프로젝트에서 사용한 기술 스택에 대해서 "왜 그 기술을 사용했는 지?"를 준비해야 한다.
실제로 면접관이 "그 기술을 왜 사용했나요?"라고 물어보면, 해당 기술에 대한 특징이 바로 나와야한다.

또한, 트레이드오프를 생각하는 개발자가 되어야 한다.
예를 들어, "더 성능이 좋은 모듈 A가 아닌 모듈 B를 사용한 이유는, 설계가 쉽고 팀 내 빠른 개발과 협업에 적합하다. 또한 자료도 많아서 트러블 슈팅에 용이하다."고 답할 수 있어야 한다.
기술 선택에는 항상 Trade-off가 있고, 그 고민은 높게 평가받는다.

4.1. 기술의 분류

• Strong: 전문성 보유
  • 6개월 이상 사용하거나, 블로그 글에 깊이 있는 내용으로 정리해서 올린 경우
  • 관련 오픈소스에 PR을 날린 경우
• Knowledgeable: 보조 지식
  • Strong 외 기술로, 단순 학습이 아닌 한 번 정도 예제를 해본 경우

예시)
Strong: Java, Spring Boot, MySQL, Redis, AWS EC2/S3
Knowledgeable: Node.js, Vue.js, Docker, Linux, Git

이렇게 분류 했을 때 좋은 점은, 면접관의 질문을 Strong 쪽으로 유도할 수 있다.

5. 합격을 결정짓는 악마의 디테일

5.1. 디테일의 중요성

채용 시장은 점점 상향평준화되고 있다. 기술 역량이 비슷한 지원자가 많기에, 디테일이 합격 여부를 가른다.
포트폴리오의 사진, 레이아웃, 맞춤법 같은 작은 부분들이 꼼꼼함과 전문성을 보여준다.

5.2. 사진에 신경쓰자

강아지와 함께 찍은 사진, 여행지에서 찍은 사진, 과도한 포즈나 셀카 등.. 이런 사진은 비전문적인 인상을 준다.
전문적인 인상을 줄 수 있는 사진을 쓰자.

5.3. 원칙을 지킨다.

• 1~3장 안에 요약하는 것이 원칙이다.
• 컬러는 흑백, 파란색 계열 등 차분한 톤을 사용한다.
• 이모티콘은 자제한다.
• 프로젝트마다 같은 포맷(문제 -> 해결 -> 결과)을 반복한다. 이는 가독성을 증가시킨다.
• 맞춤법을 관리한다.
• "떄문에, 릏" 같은 오타는 치명적인 감점 요소다.

6. GitHub 하나로 합격률 끌어올리는 법

아주 잘 작성된 GitHub README를 참고하자. 링크

만약, 팀 프로젝트를 진행했을 때 README에 각자의 역할을 나열 할 가능성이 높다.
이때는 개인 레포지토리로 fork를 떠서, 내가 맡은 역할만을 작성하자.

7. 실제 합격 사례로 배우는 포트폴리오 전략

7.1. 대회우승사례

대회우승사례가 있다면 소개글에 작성한다.

예시

• "~~에서 프로젝트 우수상(1위)를 2번 타는 등의 성과를 낸 경험이 ..."
• "애플 아카데미와 소프트웨어 마에스트로 활동을 통해 iOS 개발의 매력에 빠졌고, 총 3개의 iOS 앱을 출시하였습니다. 또한 애플이 주관한 WWDC SSC에 참가하여 전 세계 약 300명의 수상자 중 한 명으로 선정되었습니다."
• "비즈니스 목표 달성을 위해 속도감과 퀄리티를 지킬 수 있는 개발 문화를 지향합니다. 최근에는 ATDD를 적용하여 운영 중인 앱의 퀄리티를 높였습니다. 정션 아시아 해커톤에서 28개 팀 중 1위로 우승하며 속도와 퀄리티를 모두 지켜 개발한 경험이 있습니다."
• 경험과 소통을 즐기는 개발자 김xx입니다. 저는 여러 경험을 통해 자극을 받고, 이를 바탕으로 끊임없이 성장하기 위해 도전하고 노력하고 있습니다. 그리고 소통과 협업을 중요하게 생각하며, 대화를 통해 더 나은 결과를 만들 수 있다고 믿고 있습니다. (X) -> 한양대 컴퓨터 공학과 김xx입니다. 학점 4.3일정도로 매번 과탑을 놓치지 않을 정도의 탄탄한 전공 지식을 가지고 있는.. (O) (명문대가 아니더라도 학점이 높은것=가산점)

7.2. 개발과 관련없는 TMI는 제거한다.

"대학교 2학년 시절, ** 소프트웨어 경진대회에 출전한 팀에서 기획자 역할을 맡았습니다. 평소 가장 해결하고 싶었던 환경 문제를 해결할 수 있는 솔루션을 기획 및 디자인했습니다" (X)

7.3. 이력서 최상단에 있는 소개글은 정말정말정말 중요하다.

내 강점을 3줄로 요약해서 꾹꾹 눌러 담아야 한다.

8. Q&A

8.1. 오픈소스 기여 이력이나 수상 이력이 없다면?

프로젝트 하나라도 탄탄하게 한다.

• 어떤 문제를 해결하고자 이 프로젝트를 진행했으며, 어떠한 기술을 왜 썼고? 아키텍처도 설명 가능해야 한다.
• 배포 또는 docker-compose 등을 통해 배포 가능성이라도 보여줘야 한다.
• 예외 케이스나 실패 케이스에 대한 테스트 코드를 작성하고, 테스트 커버리지를 신경쓴다.
• README에 프로젝트의 전부를 보여준다.
• 특정 API 응답시간을 개선한다.

사실 프로젝트 하나면 합격하기 쉽지 않다. 하지만, 하나라도 정말 잘 만들면 기본은 갖춘 개발자가 된다.

8.2. 부족한 점을 서서히 채워나가기만 하면 된다.

마치며

강의를 기반으로 이력서를 다시 작성해봤다. 사실 강의를 듣는 내내 불안함이 생겼는데, 오픈소스 PR이나 대회 수상 이력이 없다는 점 때문이다.
부족한 점은 서서히 채워나가면 된다..! 그런데 지금은 외연을 넓히기보다는 내실을 다지기 위한 적절한 시기라고 생각한다.

대학교에서 기본적인 CS 과목을 수강하긴 했지만, 시간이 오래 지나기도 했고 졸업 이후로 교육이랑 프로젝트만 진행했지, CS에 대한 공부를 등한시 했다.
그리고 내 이력서에서 자신있게 적은 내용들을 면접관들이 "왜 했냐"고 물어보면 대답할 자신이 없다.
프로젝트를 했던 것도 시간이 꽤 지나기도 했고, 그때 당시에는 "하나하나 깊게 해야 하는데..!" 라는 생각만 가득했지 실제로 깊게 하지는 않았다.

지금 내실을 다져놓지 않으면 앞으로 개발자를 준비하고, 일하는 시간 내내 "깊게 해야 하는데" 라는 미련만 가지고 있을 것 같기 때문이다.

일단 지금까지 했던 것들을 기반으로 CS 레벨까지 연관지어 깊게 학습하고 다시 한번 정리한 다음, 오픈소스 컨트리뷰터나 대회에 적극적으로 참여해서 성과를 내는 식으로 부족한 이력서를 채워나가도록 해야겠다.