최근 이직을 위해 이력서를 열심히 작성했습니다. 제 나름대로 열심히 쓰고 퇴고도 열심히 한 뒤 처음으로 피드백을 받고 싶어서 대학교 친한 형에게 피드백을 요청했습니다. 형이 제 이력서를 쭉 보더니 몇 가지 피드백을 주셨습니다. 이 피드백들을 기반으로 수정하는 과정을 소개해드리려 합니다.
주요 피드백 내용
- 프로젝트에 있는 문장들 다른 개발자 이름 넣어도 쓸 수 있을거 같아. 너무 잘보이려고 쓴 이상적인 글인 느낌이다.
- 회사는 네가 궁금한 거지 프로젝트가 궁금한 것이 아니다.
- 개발자로서 겪었던 경험들, 기술적으로 챌린지한게 무엇이 있는지, 어떤 역할이었는지가 궁금하다. 그걸 통해서 어떤 걸 느꼈는지가 궁금한거다.
- 모호한 언어가 많아 뭘 질문해야될지 모르겠다. 구체적인 언어로 쓰면 좋겠다.
- 연차가 신경쓰인다면 네가 한 1년동안의 모든 압축된 시간과 농도들이 한 문장에 들어가야한다.
- 프로젝트는 이해할 수 있는 정보만 축약하고 너에 대한 얘기를 많이 해주면 좋겠다. 질문이 나오도록 주요 키워드들을 넣으면 좋겠다.
엄청 노력을 들인 이력서였기 때문에 피드백이 저에게 큰 충격으로 다가왔고 바로 깨달음이 생겼습니다. “아하 이렇게 써야겠구나 그래야 회사에서 나란 사람에 대해 알 수 있겠구나.” 이렇게 정확하고 필요한 피드백을 해줄 수 있는 사람이 제 곁에 있다는 것에 감사함을 느꼈습니다.
수정 전 이력서
그러면 수정 전 이력서를 같이 보시죠. 보면서 문제가 되는 부분들을 하나씩 수정해봅시다. 제 이력서는 총 2장인데 1장씩 보겠습니다.
어떠신가요? 지금 보니 굉장히 모호하고 회사에 잘보이고 싶은 프론트엔드 개발자가 보이네요.
경력, 주요 성과 부분의 피드백을 많이 받아 이 부분 부터 수정해야합니다.
먼저 프로젝트에 대한 설명이 너무 길고 나열식으로 되어 있습니다. 하루에 엄청 많은 이력서를 보는 분들은 긴 문장은 읽고 싶지 않겠죠? 이력서는 자기 자신을 소개하는 것이지 프로젝트에 대한 설명을 하는게 아니기 때문에 프로젝트에 대한 설명은 간결하고 임팩트있게 정리를 해야합니다.
어떤 프론트엔드 개발자의 이력서에도 사용할 수 있는 모호한 말이 많습니다.
- 프론트엔드 전문성을 키울 수 있었습니다.
- 프로젝트에 참여했습니다.
- 적극적인 커뮤니케이션을 했습니다.
- 프로젝트에서 편리하게 사용했습니다.
저도 이런 모호한 단어들을 인지하고 있었으나 면접 때 질문이 나올거라 생각하고 그냥 넘겼었습니다. 예를들어 효율적인 커뮤니케이션 이라는 단어가 있을 때 면접에서 효율적인 커뮤니케이션이란게 어떤 커뮤니케이션을 말씀하시는 건가요? 와 같은 질문을 하시지 않을까 생각했습니다. 그리고 그에 대한 답변을 준비하려고 했습니다.
하지만 회사 입장에서 생각해보면 이력서에 본인에 대한 모든 궁금한 내용들이 다 들어있어야 구체적인 질문을 할 수 있고 저에 대해서 관심이 생기게 만들 수 있도록 구체적인 단어를 사용하는 것이 중요하다는 것을 피드백에서 얻게 됐습니다.
모호한 단어가 아닌 제가 인사 담당자에게 보여주고 싶은 제 모습들을 기술적 챌린지와 경험, 역할 과 참여한 것을 간략하게 핵심만 뽑아서 구체적인 단어로 만드는 것이죠.
자 2번째 이력서 페이지입니다. 문제점들을 정리해보면 다음과 같습니다.
- 나열된 프로젝트 설명
- 구체적이지 않은 모호한 말들
- 쭉 나열식으로 작성한 교육 프로그램
나열된 프로젝트 설명을 핵심만 적자
1페이지와 동일하게 프로젝트에서 진행한 경험들을 쭉 나열식으로 프로젝트를 설명해뒀습니다. 어떤 페이지 개발 이런식으로만 적어놨는데 이렇게 작성하면 인사담당자는 그렇구나 하고 넘어가게 될 것 같습니다. 그 페이지를 개발하면서 어떤 경험이 있고 어떤 문제점이 있었고 그걸 개선하기 위해 뭘 했는지 핵심을 적도록 수정해야 합니다.
구체적이지 않은 모호한 말들을 구체적으로 바꾸자
“여러 경험을 쌓을 수 있었습니다”라는 문구가 있는데 인사 담당자가 원하는 건 이 여러 경험에 대한 구체적인 것임을 알았습니다. 제가 보여주고 싶은 모습들 중 경험을 토대로 어떤 것을 얻었는지를 작성하도록 수정해야합니다.
쭉 나열식으로 작성한 교육 프로그램을 간결하게 작성하자
지금 잠깐 봤는데 글이 되게 길고 한눈에 들어오지 않습니다. Bullet Point로 한눈에 들어오도록 간결하게 작성해야합니다.
이력서에 작성하고 싶은 내용 정리
이력서를 수정할 내용이 정말 많네요. 먼저 문장들 자체가 너무 잘보이려고, 어떤 개발자 이력서에 들어가도 될 것 같다는 조언에 따라서 누구에게나 들어가도 좋은 말들은 지우고 솔직하게 본연의 제 모습을 보여주는 것을 목표로 수정했습니다.
제 경력 중 각각의 프로젝트에서 저에 대해서 보여줄 수 있는 부분이 있었으면 좋겠다고 생각했습니다. 사진을 첨부하면 좋겠지만 보안상의 이유로 첨부하지는 못해서 아쉽네요. 기능이 전부 배포가 되면 추후 블로그에 포스팅하겠습니다.
Orange
먼저 Orange 프로젝트에서 보여주고 싶은 제 모습은 문서에 대한 전반적인 기능 즉 생성하고 확인하고 수정하고 삭제하는 모든 기능과 시험 데이터를 연동하는 기능, 카카오 전자서명을 활용하여 외부 API를 연동하는 기능을 중점적으로 보여주고 싶었습니다.
이 경험들 중 데이터를 연동하는 기능이 제가 개발하면서 겪은 가장 기술적으로 챌린지한 내용이므로 해당 내용에 대해 작성하여 면접 때 질문을 받고 싶었습니다. 예를 들어 왜 데이터 변환을 프론트에서 했나요? 와 같은 질문이 들어오면 그 이유에 대해서 말씀드리는거죠.
- 백엔드 개발자 분과 상의한 결과 너무 많은 데이터들이 파편화되어 있었습니다. 해당 데이터를 백엔드에서 변환하여 API로 만들게 되면 엔드포인트가 엄청나게 많이 생기고 자원 자체에 대한 정보가 존재하는데 중복된 정보를 포함한 무언가를 데이터가 추가되는 기획이 나올 때마다 다시 만들어야 하는 문제점이 있었습니다.
이런 식으로 구체적인 질문을 할 수 있는 문구를 많이 넣고 싶었습니다.
주요기능의 2번째 문구로 “Folder와 Item 2개의 컴포넌트로 재귀를 사용하여 디렉토리 형태의 구조 렌더링”이란 문장을 추가했습니다. 정말 많은 시행착오를 거쳐서 개발한 것이기 때문에 면접 때 기술적으로 겪은 챌린지가 있냐고 질문이 있을 때 아래와 같이 답변을 하고 싶어 넣었습니다.
- 처음엔 구조부터 엉망으로 만들어 실시간으로 데이터를 연동하는 방식으로 잘못 구현한 경험이 있습니다. 그렇게 되면 데이터 검색을 프론트에서 처리하기가 어렵고 백엔드에서 처리해야하는데 다음 스프린트에 포함된 기능인 검색 기능을 고려하지 않고 구현 설계를 하여 어려움을 겪었습니다.
- 또한 데이터를 가지고 올 때마다 깜빡거리는 현상이 발생하는 문제점도 발생했습니다. 따라서 현재 구현한 방식처럼 데이터를 전부 가지고 와서 변환을 한뒤 변환한 데이터를 가지고 Folder와 Item 2개의 컴포넌트를 재귀를 돌리는 방식으로 구현했습니다.
이제 꼬리 질문으로 재귀와 관련된 질문이 나오겠죠? 그러면 데이터의 구조 설명과 함께 왜 2개로 재귀를 사용했는지 말씀을 드릴 수 있을 것 같습니다. 이런 식으로 제가 구현할 때 고민을 많이한 부분을 질문으로 나올 수 있게 이력서를 수정했습니다.
템플릿 기능과 전자서명 기능도 마찬가지로 프론트엔드 전문성을 높일 수 있었습니다라는 문구에서 조금 더 구체적인 표현으로 그리고 무엇을 어떻게 구현했는지 문장을 수정했습니다.
Labnote-UI
Labnote-UI 프로젝트에서는 디자인 시스템을 개발하면서 재사용성과 유연성을 강조하고 싶어 2개의 문구를 추가했습니다.
- 필요한 곳에 재사용할 수 있도록 variants에 따라 style이 다르게 적용되도록 구현
- 컴포넌트를 사용하는 프로젝트에서 색상을 얼마든지 바꿀 수 있도록 유연하게 구현
그러면 제가 개발한 것 중 Chip 컴포넌트를 구현할 때 PrefixIcon, SuffixIcon 유무에 따라 gap, padding을 따로 스타일 처리한 부분에 대해서 말씀드릴 수 있습니다. 그리고 Input, Label, HelperText를 구분하여 개발한 이유 등 말씀드릴 수 있는게 정말 많아지게 됩니다.
컴포넌트를 사용하는 프로젝트에서 색상을 바꿀 수 있도록 구현하는 것은 하나의 예시일 뿐이지만 보다 구체적으로 유연성이란 단어를 설명하고 싶어 추가했습니다.
유연성을 고려한 여러가지 요소들 예를 들어 Modal을 구현할 때 다른 형태의 모달이 나오게 되면 구현할 수 있도록 Modal.Header, Modal.Content, Modal.Footer와 같이 구분한 것에 대해서 말씀드릴 수 있을 것 같습니다.
Mint
Mint 프로젝트에서는 입사 후 얼마되지 않아 바로 투입된 것이기 때문에 많은 기능을 구현하지 못했습니다. 따라서 빠르게 회사에 적응한 모습이나 사용자의 요청을 대응하여 사용자 경험을 향상시킨 것을 강조하고 싶었습니다.
DRMS
DRMS 프로젝트에서는 차트와 테이블을 구현하여 사용자 경험을 향상시킨 것을 강조하고 싶었습니다. 인턴 때 한 프로젝트라 데이터를 가지고와서 렌더링하기 위해 원하는 형태로 변환하고 외부 라이브러리 문서를 보는 것도 어려웠는데 문서를 통해 학습하고 사수님께 여쭤보면서 성장한 경험을 말씀드리고 싶었습니다.
그리고 제가 메시지 오발송을 해서 엄청나게 곤욕을 치룬 경험이 있는데, 이렇게 개발적으로 실수를 했을 때 어떻게 대처를 했는지에 대해서도 보여드리고 싶었습니다.
기타 수료한 프로그램
기타 프로그램에서 나열식으로 된 문장을 전부 bullet으로 바꾸고 간단하고 명확하게 프로젝트와 연관된 것만 남기고 삭제했습니다.
수정한 결과
어떠신가요? 다시 한번 이력서를 수정하면서 회사가 저에 대해 궁금한게 무엇이 있을까 고민을 많이 하게 됐습니다. 앞으로도 계속 수정할 생각이니 조언이나 조금 더 개선했으면 하는 부분이 눈에 들어오시면 하단에 있는 이메일로 피드백 주시면 정말 감사드립니다. 반영하여 수정하도록 하겠습니다.
포트폴리오에 대한 작은 생각
이렇게 이력서를 잘 작성해두면 포트폴리오에서 구구절절 쓸 필요가 없겠다는 생각이 들었습니다. 프로젝트 캡쳐본과 함께 증명하려고 어떤 기술스택으로 이렇게 저렇게 개발했습니다라는 얘기를 할 필요가 없겠다는 생각도 들어서 포트폴리오도 6장짜리를 3장으로 핵심만 담아 줄여두려고 합니다. 여기서도 위에 있는 피드백을 반영해서 이상적인 프로젝트 진행을 보여주는 것이 아닌 제가 그 프로젝트에서 맡은 역할과 겪었던 챌린지, 경험을 녹여보려고 합니다. 포트폴리오는 링크를 참고해주세요!
끝으로
이 글을 보실지 모르겠지만 피드백을 해주신 형에게 감사하다는 말씀 다시한번 드리고 싶습니다.
작은 부분을 조금씩 개선해나가다 보면 제가 원하는 모습으로 한 걸음씩 나아갈 수 있다고 생각합니다. 이렇게 이력서와 포트폴리오도 조금씩 개선하면서 제가 원하는 모습을 보여줄 수 있도록 꾸준히 성장하려고 다시 한번 다짐합니다.
글 읽어주셔서 감사합니다.
