<div id="readability-page-1" class="page"><div><div><h2 id="c523" data-testid="storyTitle">이력서 요모조모</h2><div><a rel="noopener follow" href="/?source=post_page-----393c60e6b4f8--------------------------------"><div aria-hidden="false"><p><img alt="John" src="https://miro.medium.com/v2/resize:fill:88:88/1*F439q5jgt53AtQMDiCAjQg.png" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a></div></div><figure></figure><p id="959d">(나를 포함하여) 이력서를 쓰는 데 어려움을 겪는 사람들이 많다고 생각한다. 신년을 맞이하여 이력서를 업데이트하였는데, 이력서를 작성하면서 고려했던 내용들을 나열해본다.</p><figure></figure><h2 id="09ee">어떤 내용을 추가할 것인가?</h2><p id="0f34">이력서를 작성할 때 먼저 내가 무슨 일을 했는 지를 쭉 나열해본다. 이 때 나는 포스트잇을 사용하는 편이지만 올 해는 포스트잇이 없는 상태에서 급하게 써야 해서 우선 워드를 사용했다.</p><ul><li id="7724">XX 프로젝트</li><li id="0a5c">YY 프로젝트</li><li id="db0a">ZZ 프로젝트</li></ul><p id="c869">프론트엔드 개발자이기 때문에 구태여 작성하지 않는다면 프론트엔드 개발이 기본이라는 것을 모두가 알겠지만, 그럼에도 내 분야가 아닌 곳에서 했던 일이 있다면 추가로 작성하는 것이 좋다. 예를 들어, 직접 참여한 프로젝트는 아니지만 간접적으로 이런 일을 했었다.</p><ul><li id="5b91">모바일 개발 환경 연구 및 설계, 구축</li><li id="9112">프론트엔드 표준 문서 작성</li></ul><p id="28e4">이런 일들을 특별히 프로젝트성이라고 보기에는 어렵지만 기술적으로 이루어낸 일들, 그리고 중장기적으로 생산성에 도움을 주는 일이기 때문에 작성해두면 좋다.</p><p id="a367">그렇게 나열하고 나서는 P0 ~ P2 로 프로젝트별 우선순위를 추가해준다. 여기서 우선순위는 ‘이 프로젝트가 비즈니스에 미친 영향이 많다’ 인 순서가 좋다고 생각한다. 신입으로 지원한다면 프로젝트별이 아니라 Feature별로 나열할 때 우선순위를 생각해보면 좋다. 경력직이더라도 기능을 나열해두는 건 유의미하다고 생각한다.</p><p id="e1a7">[P0] XX 프로젝트</p><ul><li id="d4aa">[P0] OIDC 기반의 Single Sign On 구축</li><li id="a147">[P1] GitHub Actions 를 활용한 배포 파이프라인 구축</li></ul><p id="1ff6">[P0] YY 프로젝트</p><p id="f324">[P1] ZZ 프로젝트</p><p id="e0db">시간이 지나서 당장 어떤 내용을 추가할 지 기억에 나지 않는 경우가 굉장히 많기 때문에, 그럴 때는 나는 PR을 다시 돌려보는 편이다.</p><h2 id="a130">어떤 내용을 어필할 것인가?</h2><p id="35b8">나는 개인적으로 “OO하는 개발자” 류의 스타트를 별로 좋아하지는 않는다. 여러 이유가 있지만 우선 고정 관념을 가진 상태로 이력서를 보게 되는 경향을 주고, 만약 OO 하는 개발자라고 썼는데 불구하고 이력서에 그런 내용이 보이지 않으면 아쉽기 때문이다.</p><p id="1e06">이력서 내용을 어필할 때에는 상대방이 궁금하게 만들어야 한다. 적어도 이력서를 보고 ‘이런 일을 했다고? 한 번 상세한 내용을 들어보고 싶은데?’ 라고 만들어서 면접 (또는 과제)까지 가게 만드는 게 중요하다. 이력서에는 늘 잘한 일들을 중점적으로 쓰면 좋다. 아쉬웠던 점, 약한 점을 구태여 어필할 필요는 없다고 생각한다.</p><p id="e291">셀프 리뷰를 쓴다고 생각해보는 것도 좋다. 직장 상사나 동료가 나를 평가해야한다고 생각했을 때 셀프 리뷰 문서에 어떤 내용을 포함해야 상대방이 나를 평가할 수 있을까?</p><p id="de7a">객관성을 높일 수 있는 모든 것들은 있으면 좋다.</p><ul><li id="e788">수치화 가능한 건 모두 수치화한다.</li><li id="77d3">벤치마크가 있다면 벤치마크를 반드시 활용한다.</li></ul><p id="d519">내가 남들에 비해 뛰어나다고 생각하는 점이 있다면 어필한다.</p><p id="4e81">SBI 피드백을 쑬 수 있다면 활용한다.</p><p id="a4ce">예를 들어,</p><p id="0e52"><strong>OO 프로젝트</strong></p><ul><li id="9f51">OO 기능을 구현할 때, iOS Safari 및 Android Chrome 사이에 지원 범위가 명확하지 않은 이슈가 있었는데 사전에 프로토타입을 구현하여 빠르게 가능 여부를 파악했습니다. 이로 인해 추후 발생할 수 있는 <strong>이슈를 사전에 파악</strong>할 수 있었습니다. [관련 블로그 글]</li><li id="f92b">OO 기능을 구현할 때, 비즈니스 로직과 UI 로직 사이의 결합도가 높아 상태 관리가 어려운 이슈가 생겼습니다. 그 때 비즈니스 로직을 Store로 따로 분리하고 UI 로직은 컴포넌트별로 두어 비즈니스 로직 변경이 UI 로직에 직접 영향을 주지 않도록 하였습니다. 이로 인해 비즈니스 로직 변경이 용이해지고 테스트 코드를 작성하기 수월해져, <strong>비즈니스 로직 코드 커버리지를 90%</strong>까지 끌어올릴 수 있었습니다. [관련 블로그 글]</li><li id="6868">특정 데이터 조회를 위한 API속도가 호출당 2 sec 정도가 걸리는 이슈가 있어, Elastic Search를 연동하여 API 속도를 호출당 0.5 sec 으로 줄인 뒤, Interface 에 페이징을 추가하여 데이터를 15개씩 호출할 때 호출당 0.1 sec 으로 최적화하였습니다.</li></ul><p id="4f9a">같은 식으로 작성해볼 수 있다.</p><h2 id="5c7c">이력서도 꾸준히 개선해야한다.</h2><p id="d9e2">프로젝트를 진행할 때에는 바쁘니 당연히 이력서를 업데이트하기 힘들지만, 그럼에도 불구하고 시간이 날 때마다 틈틈히 이력서를 개선할 필요가 있다고 생각한다. 이직 시기가 아니더라도, 시간이 지날수록 기억 속에서 휘발되기 때문이다. (이렇게 말한 나도 사실 2023년에 한 번도 업데이트하지 않았다..)</p><p id="abf1">한 달에 한 번정도는 한 일을 돌아보면서 이력서를 업데이트 해보면 좋겠다.</p></div></div>

Stories by 조은, Eun Cho on Medium

choeun

(나를 포함하여) 이력서를 쓰는 데 어려움을 겪는 사람들이 많다고 생각한다. 신년을 맞이하여 이력서를 업데이트하였는데, 이력서를 작성하면서 고려했던 내용들을 나열해본다.
어떤 내용을 추가할 것인가?
이력서를 작성할 때 먼저 내가 무슨 일을 했는 지를 쭉 나열해본다. 이 때 나는 포스트잇을 사용하는 편이지만 올 해는 포스트잇이 없는 상태에서 급하게 써야 해서 우선 워드를 사용했다.
XX 프로젝트
YY 프로젝트
ZZ 프로젝트
프론트엔드 개발자이기 때문에 구태여 작성하지 않는다면 프론트엔드 개발이 기본이라는 것을 모두가 알겠지만, 그럼에도 내 분야가 아닌 곳에서 했던 일이 있다면 추가로 작성하는 것이 좋다. 예를 들어, 직접 참여한 프로젝트는 아니지만 간접적으로 이런 일을 했었다.
모바일 개발 환경 연구 및 설계, 구축
프론트엔드 표준 문서 작성
이런 일들을 특별히 프로젝트성이라고 보기에는 어렵지만 기술적으로 이루어낸 일들, 그리고 중장기적으로 생산성에 도움을 주는 일이기 때문에 작성해두면 좋다.
그렇게 나열하고 나서는 P0 ~ P2 로 프로젝트별 우선순위를 추가해준다. 여기서 우선순위는 ‘이 프로젝트가 비즈니스에 미친 영향이 많다’ 인 순서가 좋다고 생각한다. 신입으로 지원한다면 프로젝트별이 아니라 Feature별로 나열할 때 우선순위를 생각해보면 좋다. 경력직이더라도 기능을 나열해두는 건 유의미하다고 생각한다.
[P0] XX 프로젝트
[P0] OIDC 기반의 Single Sign On 구축
[P1] GitHub Actions 를 활용한 배포 파이프라인 구축
[P0] YY 프로젝트
[P1] ZZ 프로젝트
시간이 지나서 당장 어떤 내용을 추가할 지 기억에 나지 않는 경우가 굉장히 많기 때문에, 그럴 때는 나는 PR을 다시 돌려보는 편이다.
어떤 내용을 어필할 것인가?
나는 개인적으로 “OO하는 개발자” 류의 스타트를 별로 좋아하지는 않는다. 여러 이유가 있지만 우선 고정 관념을 가진 상태로 이력서를 보게 되는 경향을 주고, 만약 OO 하는 개발자라고 썼는데 불구하고 이력서에 그런 내용이 보이지 않으면 아쉽기 때문이다.
이력서 내용을 어필할 때에는 상대방이 궁금하게 만들어야 한다. 적어도 이력서를 보고 ‘이런 일을 했다고? 한 번 상세한 내용을 들어보고 싶은데?’ 라고 만들어서 면접 (또는 과제)까지 가게 만드는 게 중요하다. 이력서에는 늘 잘한 일들을 중점적으로 쓰면 좋다. 아쉬웠던 점, 약한 점을 구태여 어필할 필요는 없다고 생각한다.
셀프 리뷰를 쓴다고 생각해보는 것도 좋다. 직장 상사나 동료가 나를 평가해야한다고 생각했을 때 셀프 리뷰 문서에 어떤 내용을 포함해야 상대방이 나를 평가할 수 있을까?
객관성을 높일 수 있는 모든 것들은 있으면 좋다.
수치화 가능한 건 모두 수치화한다.
벤치마크가 있다면 벤치마크를 반드시 활용한다.
내가 남들에 비해 뛰어나다고 생각하는 점이 있다면 어필한다.
SBI 피드백을 쑬 수 있다면 활용한다.
예를 들어,
OO 프로젝트
OO 기능을 구현할 때, iOS Safari 및 Android Chrome 사이에 지원 범위가 명확하지 않은 이슈가 있었는데 사전에 프로토타입을 구현하여 빠르게 가능 여부를 파악했습니다. 이로 인해 추후 발생할 수 있는 이슈를 사전에 파악할 수 있었습니다. [관련 블로그 글]
OO 기능을 구현할 때, 비즈니스 로직과 UI 로직 사이의 결합도가 높아 상태 관리가 어려운 이슈가 생겼습니다. 그 때 비즈니스 로직을 Store로 따로 분리하고 UI 로직은 컴포넌트별로 두어 비즈니스 로직 변경이 UI 로직에 직접 영향을 주지 않도록 하였습니다. 이로 인해 비즈니스 로직 변경이 용이해지고 테스트 코드를 작성하기 수월해져, 비즈니스 로직 코드 커버리지를 90%까지 끌어올릴 수 있었습니다. [관련 블로그 글]
특정 데이터 조회를 위한 API속도가 호출당 2 sec 정도가 걸리는 이슈가 있어, Elastic Search를 연동하여 API 속도를 호출당 0.5 sec 으로 줄인 뒤, Interface 에 페이징을 추가하여 데이터를 15개씩 호출할 때 호출당 0.1 sec 으로 최적화하였습니다.
같은 식으로 작성해볼 수 있다.
이력서도 꾸준히 개선해야한다.
프로젝트를 진행할 때에는 바쁘니 당연히 이력서를 업데이트하기 힘들지만, 그럼에도 불구하고 시간이 날 때마다 틈틈히 이력서를 개선할 필요가 있다고 생각한다. 이직 시기가 아니더라도, 시간이 지날수록 기억 속에서 휘발되기 때문이다. (이렇게 말한 나도 사실 2023년에 한 번도 업데이트하지 않았다..)
한 달에 한 번정도는 한 일을 돌아보면서 이력서를 업데이트 해보면 좋겠다.

이력서 요모조모

댓글