<div id="readability-page-1" class="page"><article>
    <div>

                
                <div>
                    <details open="">
                        <summary accesskey="c" title="(Alt + C)">
                            <p>Table of Contents</p>
                        </summary>
                        <nav id="TableOfContents">
  <ul>
    <li><a href="#멘토링에서-자주-이야기-하는-이력서-피드백">멘토링에서 자주 이야기 하는 이력서 피드백</a>
      <ul>
        <li><a href="#생각해-볼-것">생각해 볼 것</a></li>
        <li><a href="#문제점-요약---읽는-사람-입장에서-읽기-쉬운-이력서">문제점 요약 - 읽는 사람 입장에서 읽기 쉬운 이력서</a></li>
        <li><a href="#주요-점검-사항">주요 점검 사항</a></li>
        <li><a href="#마무리하며">마무리하며</a></li>
      </ul>
    </li>
  </ul>
</nav>
                    </details>
                </div>
                
                <h2 id="멘토링에서-자주-이야기-하는-이력서-피드백">멘토링에서 자주 이야기 하는 이력서 피드백</h2>
<p>일년에 몇 차례 멘토링을 진행할 때가 있다. 대학교 후배들 부터 직장 또는 커뮤니티에서 만나는 다양한 개발자 분들과 이야기를 나누게 되는데, 종종 이력서 피드백을 요청받고는 한다. 현업 면접관으로 참여한 경험도 있고 해서, 그 순간 ‘<strong>우리팀에 함께 했으면 하는 분은 누구일까</strong>?’ 라는 컨셉으로 이력서를 살펴보고 피드백을 드렸다.</p>
<p>그러다가 경험이 쌓이다 보니, 자주 이야기 하게 되는 내용들이 있어 이를 정리해보았다.</p>
<h2 id="생각해-볼-것">생각해 볼 것</h2>
<p>이력서에 대한 피드백을 정리해보면, 결국 글을 어떻게 작성해야하는 가에 대한 질문으로 정리된다. 다음과 같은 주제를 고려해보자.</p>
<h3 id="생각해-볼-것-1---이력서는-누가-읽을까">생각해 볼 것 1 - 이력서는 누가 읽을까?</h3>
<p>이력서를 작성하는 순서는 대략 다음과 같다.</p>
<ol>
<li>지원자는 자기 소개, 개발 스킬셋, 프로젝트 경험에 대한 내용을 이력서에 작성한다.</li>
<li>자신이 생각하는 어필할 수 있는 내용들을 채워넣기 시작한다.</li>
<li>여러차례 반복하며 이력서의 형태를 다듬는다.</li>
<li>마지막으로 빠진 부분이 없는지 체크하고 오타가 없는지 확인한다.</li>
</ol>
<p>여기서 생각해볼 것은 “<strong>이력서도 하나의 글</strong>” 이라는 점이다.</p>
<p>따라서 독자가 있으며, 그 독자는 일차적으로 서류검토자, 나아가서 <strong>내가 일하게 될 팀의 리더</strong>가 될 확률이 높다.</p>
<figure>
    <img src="https://findstar.pe.kr/images/posts/career/please.jpg" alt="이력서 검토">
    
</figure>
<h3 id="생각해-볼-것-2---나는-누구인가">생각해 볼 것 2 - 나는 누구인가?</h3>
<p>이력서를 작성할 때 결국 <strong>나</strong>라는 사람이 드러나야 한다. 왜냐하면 결국 최종적으로 이력서를 통해서 결정하고자 하는 것은 <strong>나의 동료가 될 사람을 찾는 것</strong> 이기 때문이다.</p>
<p>따라서 자신이 문제 상황에서 어떤 점을 고려했고, 어떤 점을 중요하게 생각했는지 드러내는 것이 좋다. 자신의 가치관을 표현하는 것이다.</p>
<p>단순히 내가 수행한 이력들을 나열하는 것은 정보의 목록에 그칠 뿐이다. <strong>이력서를 통해서 그 사람을 궁금하게 만드는 것이 필요하지 않을까?</strong></p>
<figure>
    <img src="https://findstar.pe.kr/images/posts/career/one.jpeg" alt="동료가 될 사람을 찾는 팀장">
    
</figure>
<h2 id="문제점-요약---읽는-사람-입장에서-읽기-쉬운-이력서">문제점 요약 - 읽는 사람 입장에서 읽기 쉬운 이력서</h2>
<p>결국 내가 공통으로 피드백하는 내용은 다음과 같다.</p>
<blockquote>
<p><strong>읽는 사람 입장에서 읽기 쉬운 이력서를 작성하자</strong></p>
</blockquote>
<p>내가 피드백한 대부분의 경우 이력서가 담고 있는 내용이 지원자의 관점에서만 고려되어 “<strong>나는 무엇무엇을 해보았다.</strong>“의 나열인 경우가 많아, 읽는 사람 입장에서 궁금증이 해소되기 어려운 경우가 많았다.</p>
<p>작성한 이력서를 지원자 입장이 아니라, 글을 읽는 독자의 관점에서 바라보자면, 결국 최종적으로 ‘<strong>나와 같이 일하게 될 팀의 리더</strong>’ 가 이 이력서를 바탕으로 나의 면접 통과 여부를 결정하게 된다.</p>
<p>그렇다면, 이력서라는 글은 독자의 입장에서 읽기 쉽게 작성되어야 하는 것이 좋지 않을까? 따라서 <strong>동료가 될 사람을 찾고 있는 팀의 리더</strong> 입장에서 궁금한 것들을 잘 정리해놓고, 지원자가 어떤 사람인지 무엇을 중요하게 생각하는지 생각이 잘 드러나는 내용이 있으면 좋겠다고 생각한다.</p>
<h2 id="주요-점검-사항">주요 점검 사항</h2>
<p>문제점을 해결하기 위해서 다음과 같은 점검 사항을 요약해보았다.</p>
<h3 id="읽는-사람을-위해-작성시-고려할-부분들">읽는 사람을 위해 작성시 고려할 부분들</h3>
<ol>
<li>지원 포지션과 관련있는 내용으로 통일하기
<ul>
<li>이력서 전반에 걸쳐 경력 기간, 업무 내용, 경험해본 기술 스펙등이 일관되기를 기대한다. 종종 <strong>지원 포지션과는 무관한 경험</strong>이 분량을 위해서 채워져 있는 인상을 받을 때가 있는데 불필요한 내용을 읽는 느낌을 줄 수 있다.</li>
</ul>
</li>
<li>불필요한 정보 제거하기
<ul>
<li>포지션과 무관한 학력정보(<del>고등학교</del>), 자격증(<del>정보처리기사</del>, <del>운전면허증</del>), 연관성이 낮은 정보(<del>다른 계통의 인턴경험</del>)는 생략해서 핵심 내용을 부각시키는게 좋다.</li>
</ul>
</li>
<li>스킬셋은 나열형식 보다는 조금 더 구체적으로
<ul>
<li>단순히 기술을 다룰 수 있다는 나열 대신에 사용한 최신 버전이나 실제 활용 경험, 본인이 다룰 수 있는 숙련도를 구체적으로 언급하는 것이 좋다.</li>
</ul>
</li>
<li>프로젝트 경험
<ul>
<li>프로젝트 경험을 작성할 때는 팀의 규모, 본인의 위치와 역할을 추가하면 좋다. 실제 면접에서 주로 질문하는 내용들을 이력서 단계에서 파악할 수 있도록 작성하기</li>
<li>꼬리 질문을 생각해보고, 이 내용들을 이력서에 담아보자.
<ul>
<li>‘이 프로젝트는 몇명이 진행한 프로젝트인가요?(이력서에는 기간만 있고 인원이 잘 표시되지 않아 질문하게 됨)’</li>
<li>‘이 중에서 어떤 역할을 주로 담당하셨나요?(프로젝트의 전체 내용 위주로 작성되어 있고 어떤 역할을 중점적으로 수행했는지 잘 드러나지 않아 질문하게 됨)’</li>
<li>‘프로젝트 진행중에 어떤 점이 가장 어려웠었나요?(트러블 슈팅 경험이 궁금함, 어떤 부분을 힘들어 하는지 알고 싶음)’</li>
<li>‘그 과정에서 새롭게 알게 되었거나 배운점은 무엇이었나요?(경험을 통해서 어떤 부분을 성장시켜나갔는지 알고 싶음)’</li>
</ul>
</li>
<li>정성적인 내용과 함께 정량적인 내용을 함께 작성하자.
<ul>
<li>“무엇무엇을 통해서 성능을 개선했습니다.” 보다, “무엇무엇을 통해서 성능을 30% 개선했습니다.” 라는 문장이 더 매력적이다.</li>
<li>정량적인 내용이 어렵다면, 주위의 정성적인 의견 취합도 좋다. (ex) 이 작업 이후 동료들이 모두 긍정적인 효과를 체험했다고 이야기 해주었습니다.)</li>
</ul>
</li>
</ul>
</li>
</ol>
<h3 id="자신의-정체성을-드러내기-위해서">자신의 정체성을 드러내기 위해서</h3>
<ul>
<li>
<p>경험을 작성할 때 이야기를 쓰듯이 작성해보자. 내가 추천하는 방식은 <strong>S.T.A.R. 스토리텔링</strong> 기법이다.</p>
<ul>
<li>S : 상황(Situation) - 경험의 배경을 소개한다.</li>
<li>T : 과제(Task) - 해결하고자 했던 문제를 구체적으로 작성한다.</li>
<li>A : 행동(Action) - 문제 해결을 위해 구체적으로 어떤 행동을 했었는지 상세하기 작성한다.</li>
<li>R : 결과(Result) - 도출된 결과를 정량적 데이터(예: 매출 20% 증가, 사용자 만족도 15% 상승 등)나 동료의 피드백을 통해 표현하면, 기여도를 효과적으로 어필할 수 있다.</li>
</ul>
</li>
<li>
<p>소개에서 자신이 중요하게 생각하는 것들을 작성하자.</p>
<ul>
<li>‘공유’, ‘생산성’, ‘커뮤니케이션’, ‘협업’, ‘UI/UX’ 무수히 많은 키워드 중에서 내가 핵심적으로 관심있고 중요하게 생각하는 가치를 뽑아서 드러내보자. 그러한 내용들을 실제 업무에서 어떻게 적용했는지 사례가 있으면 좋다.</li>
<li>경험에서 배운 점 강조 : 단순히 ‘무엇을 했다’가 아니라, ‘어떤 교훈을 얻었고 어떻게 성장했는지’를 작성해보면 좋다. 결국 이러한 내용들은 나중에 조직에서 어떤 시너지를 발휘할 수 있는지를 명확하게 보여주게 된다.</li>
</ul>
</li>
</ul>
<h2 id="마무리하며">마무리하며</h2>
<p>내가 피드백 하는 내용들이 항상 상황에 딱 들어 내용이라고 생각하지는 않는다. 다만, 여러번 경험하면서 <strong>검토자 입장에서 읽기 쉽도록 정리되어 있는 이력서</strong>가 좋은 이력서가 아닐까 생각한다.</p>
<p>결국 팀의 동료가 될 누군가를 찾고 있는 수많은 팀장들에게 ‘나 자신의 경험과 그 안에서 성장한 내용, 그리고 중요하게 생각하는 가치들’에 대해서 잘 설명할 수 있다면 초고속으로 합격통보를 보내지 않을까 한다.</p>


                

                <hr>
                

                





<p><a href="https://disqus.com/">comments powered by </a>



            </p></div>
</article></div>

Soo Story

Jung-Soo Ahn

일년에 몇 차례 멘토링을 진행할 때가 있다. 주로 주니어 개발자 분들과 이야기를 나누게 되는데, 종종 요청받는 내용이 이력서에 대한 피드백이다. 그 중에서 자주 이야기 하게 되는 피드백에 대해서 정리해보았다.

멘토링에서 자주 이야기 하는 이력서 피드백

댓글