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

<hr><p>
                    개인 광고 영역
</p>

                    <hr>
                    <p>포트폴리오와 이력서는 어떻게 관리하는 것이 좋을까?</p>

<p>그냥 많은 프로젝트를 진행하고, 많은 활동을 하는 것이 좋을까?</p>

<p>이 글은 지극히 개인적인 생각을 담아 정리하기에 편하게 읽어주시길</p>



<h3>이 글에서 알아볼 내용</h3>

<ul>
  <li>지극히 개인적인 내용을 담았습니다.</li>
</ul>





<h2>포트폴리오</h2>

<p>포트폴리오는 개인 프로젝트, 팀 프로젝트, 블로그 등이 포트폴리오로 활용이 가능하다.</p>



<h3>블로그</h3>

<p>매우 많은 사람들이 블로그를 정리하고 있다.</p>

<p>필자도 2017년부터 GitHub을 이용해 현재 블로그를 활용하고 있다.(이 전 블로그는 Tistory인데 첫 시작 기준 10년을 넘게 블로그 활동을 하고 있다.)</p>

<p>블로그 글 정리하는 건 쉬운 일이 아닌데, 여기에 소모하는 시간은 적게는 1시간 최대는 글로 작성할 샘플 프로젝트를 함께 해야 하니 몇 주가 걸리기도 한다.</p>

<p>블로그를 작성하는 건 시간을 소비하는 일이지만 그에 비해 많은 학습을 요하니 상대적으로 이득일 수 있다.</p>

<ul>
  <li>머릿속에 복잡하게 굴러다니는 키워드를 한 번에 정리한다.</li>
  <li>남들이 볼 수 있으니 더 많은 자료를 찾아본다.</li>
  <li>내가 다시 봤을 때 쉽게 이해할 수 있도록 더 많은 자료를 찾아 정리한다.</li>
</ul>

<p>와 같은 개념으로 접근하고 있다. AI가 좋아지고 ChaptGPT를 활용해 검색이 쉽다. 하지만 그 내용들 역시 머리에 떠다니게 된다.</p>

<p>결국 키워드를 얼마나 잘 알고 학습하는지에 따라 학습 방식의 차이가 발생한다.</p>

<p>키워드는 있지만 나머지 내용이 머리에 없다면 어딘가 표현해둔 글을 찾거나, 글을 적는 행위를 하는 건 자연스럽다.</p>

<p>그러니 블로그 작성에 시간이 많이 걸린다고 하더라도, 그 개념 자체는 머리에 남게 되니 매우 유용하다.</p>

<p>더구나 꾸준히 작성한 글은 이력으로도 손색이 없다.</p>



<h3>프로젝트</h3>

<p>개인 프로젝트와 팀 프로젝트가 있다. 개인 프로젝트야 혼자 생각하고 혼자서 할 수 있다. 하지만 팀 프로젝트는 보통 같은 목적을 만들어 개발한다.</p>

<p>서비스를 하기 위함일 수도 있고, 포트폴리오 용일 수도 있다.</p>

<p>당연히 서비스로 이어진다면 가장 좋겠지만 그렇지 못한 케이스도 많을 것이다.</p>

<p>결국 이렇게 작성한 코드들은 이력서에 프로젝트 내역에 추가할 것이다.</p>

<p>여기서부터 중요한 부분이 있다.</p>

<ul>
  <li>개인 프로젝트라면 README.md를 잘 정리하라</li>
  <li>팀 프로젝트라면 내가 작업한 내용을 잘 명시하라. 중요 한건 아이디 기준으로 GitHub 커밋 내역도 확인하게 된다. 그 내용과 매칭이 안된다면 사유를 적어두어야 한다.
    <ul>
      <li>결국 내가 하지도 않은 내용을 이력서나 README.md에 적는다고 해도 모두가 알고 있다. 당신이 거짓말했다는 것을</li>
    </ul>
  </li>
  <li>많은 프로젝트는 필요하지 않다. 관리 잘한 1-2개의 프로젝트가 10개보다 더 좋다.
    <ul>
      <li>프로젝트 수가 중요하지 않다. 하나라도 내가 얼마나 공부해서 적용해 보려고 노력했는지가 더 중요하다.</li>
    </ul>
  </li>
</ul>

<p>보통 이력서에 GitHub 링크를 작성한다. 하지만 모든 사람이 GitHub 코드를 열어보는 것은 아니다. 이 프로젝트가 뭔지도 모르고 열어보기도 한다.</p>

<p>그리고 코드가 별로이면 다른 프로젝트는 열어보지 않을 수 있다. 결국 내가 꾸준히 공부하고 흔적을 잘 남긴 GitHub 프로젝트 링크 하나만 있어도 좋단 소리다.</p>

<p>최근에 공부하고, 지속 관리한 프로젝트를 열수 있도록 링크를 만드는 것이 좋다.</p>



<h4>참고</h4>

<p>보통 이력서에 적힌 GitHub 링크를 타고 들어가면 최근 관리한 내용이 없거나, 내가 하고 싶은 직업과 관련한 코드가 없는 경우도 있다.</p>

<p>이런 경우라면 그냥 이력서에 적지 않는 게 더 좋다.</p>



<h2>추천하는 GitHub은?</h2>

<p>꾸준히 관리하고 학습하는 프로젝트로 개인적으론 pluu 님의 프로젝트를 추천한다.</p>

<ul>
  <li><a href="https://github.com/Pluu/WebToon">https://github.com/Pluu/WebToon</a></li>
</ul>

<p>README.md를 잘 정리하는 것 역시 중요하다.</p>

<ul>
  <li><a href="https://github.com/f-lab-edu/wak-plus">https://github.com/f-lab-edu/wak-plus</a></li>
</ul>

<p>재웅 님은 이미 너무 유명하니</p>

<ul>
  <li><a href="https://github.com/skydoves">https://github.com/skydoves</a></li>
</ul>



<h2>이력서</h2>

<p>이력서는 누군가는 딱 한 페이지만 보고 끝나기도 한다. 결국 포트폴리오 링크들도 중요하겠지만 이력서에 이력을 잘 정리해둘 필요가 있다.</p>

<p>요즘 노션을 통해 정리된 가장 흔한 이력서 형태는</p>

<ul>
  <li>소개(내가 잘하는 것?)</li>
  <li>주요 스킬을 적는다.(간혹 점수도 있다)</li>
  <li>이력</li>
  <li>진행한 프로젝트를 링크 형태로 담는다.</li>
  <li>내가 다룰 수 있는 모든 스킬을 차트 형태로 담는다.</li>
</ul>

<p>이런 형태의 이력서가 매우 유행하는 듯하다.</p>



<h3>이력서를 살펴보는 입장에선</h3>

<h3>주요 스킬</h3>

<p>주요 스킬을 포함하여 내가 장점으로 치부할 수 있는 능력을 적게 되는데, 이런 내용이라면 괜찮다.</p>

<p>안드로이드 개발자라면 당연하게도 자바(옵션), 코틀린, 안드로이드는 알아야 한다.</p>

<p>당연히 다룰 수 있어야 할 기술을 설명을 포함해 적어야 할 이유는 없다.</p>

<p>딱히 이력서적인 매력이 없다고 개인적으론 생각한다.</p>



<h3>주요 스킬별 점수 노출</h3>

<p>간혹 이력서에 주요 스킬별 점수 노출하는 경우가 있다.</p>

<p>이 점수는 지극히 주관적인 점수라고 생각한다.</p>

<p>별 3개 기준 이 스킬의 점수는? 별 5개 기준 이 스킬의 점수는?</p>

<p>뭘 보여주고 싶은 것일까?</p>

<p>이력서를 보는 사람 입장에선 이 점수를 토대로 뭘 기대해야 할 것인가?</p>

<p>보통은 이렇게 생각한다.</p>

<p>내 기준 코틀린 다루는 기술은 별 1개를 겨우 줄 수 있는데, 별 4개라니 엄청난 분이군.</p>

<p>매우 기대하고 면접 볼 수 있겠다.</p>

<p>이걸 기대한 것이라면 이 별점은 매우 유용할 것 같다.</p>



<h3>이력</h3>

<p>기존 회사에 다니면서 진행한 프로젝트 이력은 매우 중요하다. 이 이력은 거짓말을 포함하더라도, 나중에 국민연금 문서와 비교 후 탈락의 대상이 되기도 한다.</p>

<p>없는 이력을 만들고 합격하더라도, 국민연금 문서와 맞지 않다면 탈락될 수 있단 소리다.</p>

<p>여기서 적어야 할 내용이 있다면 다음일 수 있다.</p>

<ul>
  <li>이직이 잦았다면 이직한 이유를 짧게 적는 것도 좋다.</li>
  <li>전직을 해야 한다면 소개 부분에 잘 적고, 여기에도 짧게 적을 필요가 있다.</li>
</ul>



<h3>진행한 프로젝트</h3>

<p>진행한 프로젝트는 노션에서 갤러리 뷰로 보통 정리한다. 이 방식을 개인적으로 좋아하지 않는다.</p>

<p>뭘 봐야 할까?</p>

<p>보통 열면 엄청난 설명글과 함께 플로우 차트도 포함되어 있다.</p>

<p>잘 정리되어 있다면 이 내용이 매우 유용하겠지만 이력서를 하루에도 수십 개 봐야 한다면 이 내용을 다 보기 쉽지 않고, 대충 보고 넘어갈 수 있다.</p>

<p>그래서 갤러리 형태가 아니라 표현 형태로 정리하는 걸 추천한다.</p>

<p>내가 이 프로젝트 디테일을 눌렀을 때, 코드를 열었을 때 얻을 수 있는 정보가 무엇일지 말이다.</p>

<p>개인적으로 작성한다면 아래와 같이 적을 것 같다.</p>

<ul>
  <li><a href="https://github.com/taehwandev/ComposeKeyboardState">https://github.com/taehwandev/ComposeKeyboardState</a></li>
  <li>프로젝트 개요 : Compose에서 키보드 처리를 쉽게 하려고 만듦</li>
  <li>다룬 기술</li>
  <li>View 상태를 측정해 keyboard state를 처리</li>
  <li>Compose에서 이를 쉽게 활용하기 위해 CompositionLocalProvider을 활용</li>
</ul>



<h3>스킬을 테이블로</h3>

<p>스킬들을 테이블로 정리하는 경우도 많다.</p>

<p>이 역시 뭘 보여주려 하는지 알기 어렵다. 여기 있는 모든 기술은 이미 회사 이전 이력과 내 프로젝트에 담겨있다.</p>

<p>그렇다면 이 테이블로 한눈에 표기한 내용에선 뭘 알 수 있을까?</p>

<p>보통 면접을 보면 여기에 있는 기술들을 몽땅 다 물어보게 될 수 있다.</p>

<p>최근에 지속적으로 관리한 프로젝트가 그래서 중요하다고 생각한다.</p>



<h3>오픈 소스 활동</h3>

<p>오픈 소스 활동을 했다면 분명 장점이다.</p>

<p>기여 활동은 다양하다 이슈를 찾아서 이슈를 올릴 수도 있고,</p>

<p>해당 프로젝트에 실제 기술적 오류를 해결할 수도 있다.</p>

<p>단순히 문서 내용을 수정하기도 한다.</p>

<p>문서 내용만 잔뜩 찾아서 오픈소스 활동했다는 건 그다지 큰 장점은 아닌 것 같다.</p>

<p>진짜 코드 수정했다면 코드 리뷰도 배웠고, 기여도 해보았으니 이것만큼 좋은 경험은 없다. 다만 문서 내용만 잔뜩 수정했다는 이력은 매의 눈을 가진 건 틀림없지만 이력에는 좋을까?는 개인적으론 딱히 쓸모없는 지문 낭비로 보인다.</p>

<p>간혹 소스 사용법이 틀릴 수도 있으니 말이다.</p>

<p>그러니 잘 정리해두고, 하나라도 오픈소스에 기여했다면 매우 좋은 경험일 것이다.</p>



<h2>정리하면</h2>

<p>포트폴리오는 당연하게도 잘 관리한 것 1-2개면 충분하다.</p>

<p>1년에 한 번이라도 좋다. 하다 보면 1년에 한 번으론 관리하기 어렵겠지만.</p>

<p>GitHub 잔디 심기도 좋다. 잔디를 심었다면 어떠한 학습을 했는지가 더 중요하겠지만 꾸준히 공부함을 나타낼 수도 있으니 말이다.</p>

<p>이력서 또한 그렇다.</p>

<p>양이 많은 것보단 간단 명료하게 꼭 필요한 내용을 잘 다루는 편이 더 좋다.</p>

<p>A4 기준 10장을 작성해도 요약이 없는 이력서라면 뭘 봤는지 기억하지 못한다.</p>

<p>열심히 한 만큼 좋은 이력을 남기고 싶다면 핵심만 잘 정리해 난 이런 걸 해봤다만 잘 표현하더라도 좋은 이력서가 될 수 있다.</p>

<p>모호한 내용은 상세 페이지에 담고, 이 프로젝트의 핵심은 한 장만 보아도 알 수 있다면 좋은 이력서 일 수 있다.</p>



<h2>마무리</h2>

<p>긴 이력서보단 짧은 이력서 의미 없는 개인적인 점수보단 글로 표현하는 것이 더 좋다.</p>

<p>당연히 알아야 할 기술적 내용은 굳이 이력서 지면을 채울 필요는 없다. 이미 프로젝트를 진행해 보았다면 당연히 거기에서 활용하고 있을 것이니 말이다.</p>

<p>그렇다고 필자가 이력서를 잘 쓰는 것도, 면접을 잘 보는 것도 아니니 참고만 하시길</p>

                    <hr>
                    

<hr>
                </div></div>

꿈 많은 개발자가 되자 - Taehwan

포트폴리오와 이력서는 어떻게 관리하는 것이 좋을까?
그냥 많은 프로젝트를 진행하고, 많은 활동을 하는 것이 좋을까?
이 글은 지극히 개인적인 생각을 담아 정리하기에 편하게 읽어주시길
이 글에서 알아볼 내용
지극히 개인적인 내용을 담았습니다.
포트폴리오
포트폴리오는 개인 프로젝트, 팀 프로젝트, 블로그 등이 포트폴리오로 활용이 가능하다.
블로그
매우 많은 사람들이 블로그를 정리하고 있다.
필자도 2017년부터 GitHub을 이용해 현재 블로그를 활용하고 있다.(이 전 블로그는 Tistory인데 첫 시작 기준 10년을 넘게 블로그 활동을 하고 있다.)
블로그 글 정리하는 건 쉬운 일이 아닌데, 여기에 소모하는 시간은 적게는 1시간 최대는 글로 작성할 샘플 프로젝트를 함께 해야 하니 몇 주가 걸리기도 한다.
블로그를 작성하는 건 시간을 소비하는 일이지만 그에 비해 많은 학습을 요하니 상대적으로 이득일 수 있다.
머릿속에 복잡하게 굴러다니는 키워드를 한 번에 정리한다.
남들이 볼 수 있으니 더 많은 자료를 찾아본다.
내가 다시 봤을 때 쉽게 이해할 수 있도록 더 많은 자료를 찾아 정리한다.
와 같은 개념으로 접근하고 있다. AI가 좋아지고 ChaptGPT를 활용해 검색이 쉽다. 하지만 그 내용들 역시 머리에 떠다니게 된다.
결국 키워드를 얼마나 잘 알고 학습하는지에 따라 학습 방식의 차이가 발생한다.
키워드는 있지만 나머지 내용이 머리에 없다면 어딘가 표현해둔 글을 찾거나, 글을 적는 행위를 하는 건 자연스럽다.
그러니 블로그 작성에 시간이 많이 걸린다고 하더라도, 그 개념 자체는 머리에 남게 되니 매우 유용하다.
더구나 꾸준히 작성한 글은 이력으로도 손색이 없다.
프로젝트
개인 프로젝트와 팀 프로젝트가 있다. 개인 프로젝트야 혼자 생각하고 혼자서 할 수 있다. 하지만 팀 프로젝트는 보통 같은 목적을 만들어 개발한다.
서비스를 하기 위함일 수도 있고, 포트폴리오 용일 수도 있다.
당연히 서비스로 이어진다면 가장 좋겠지만 그렇지 못한 케이스도 많을 것이다.
결국 이렇게 작성한 코드들은 이력서에 프로젝트 내역에 추가할 것이다.
여기서부터 중요한 부분이 있다.
개인 프로젝트라면 README.md를 잘 정리하라
팀 프로젝트라면 내가 작업한 내용을 잘 명시하라. 중요 한건 아이디 기준으로 GitHub 커밋 내역도 확인하게 된다. 그 내용과 매칭이 안된다면 사유를 적어두어야 한다.
    
결국 내가 하지도 않은 내용을 이력서나 README.md에 적는다고 해도 모두가 알고 있다. 당신이 거짓말했다는 것을
많은 프로젝트는 필요하지 않다. 관리 잘한 1-2개의 프로젝트가 10개보다 더 좋다.
    
프로젝트 수가 중요하지 않다. 하나라도 내가 얼마나 공부해서 적용해 보려고 노력했는지가 더 중요하다.
보통 이력서에 GitHub 링크를 작성한다. 하지만 모든 사람이 GitHub 코드를 열어보는 것은 아니다. 이 프로젝트가 뭔지도 모르고 열어보기도 한다.
그리고 코드가 별로이면 다른 프로젝트는 열어보지 않을 수 있다. 결국 내가 꾸준히 공부하고 흔적을 잘 남긴 GitHub 프로젝트 링크 하나만 있어도 좋단 소리다.
최근에 공부하고, 지속 관리한 프로젝트를 열수 있도록 링크를 만드는 것이 좋다.
참고
보통 이력서에 적힌 GitHub 링크를 타고 들어가면 최근 관리한 내용이 없거나, 내가 하고 싶은 직업과 관련한 코드가 없는 경우도 있다.
이런 경우라면 그냥 이력서에 적지 않는 게 더 좋다.
추천하는 GitHub은?
꾸준히 관리하고 학습하는 프로젝트로 개인적으론 pluu 님의 프로젝트를 추천한다.
https://github.com/Pluu/WebToon
README.md를 잘 정리하는 것 역시 중요하다.
https://github.com/f-lab-edu/wak-plus
재웅 님은 이미 너무 유명하니
https://github.com/skydoves
이력서
이력서는 누군가는 딱 한 페이지만 보고 끝나기도 한다. 결국 포트폴리오 링크들도 중요하겠지만 이력서에 이력을 잘 정리해둘 필요가 있다.
요즘 노션을 통해 정리된 가장 흔한 이력서 형태는
소개(내가 잘하는 것?)
주요 스킬을 적는다.(간혹 점수도 있다)
이력
진행한 프로젝트를 링크 형태로 담는다.
내가 다룰 수 있는 모든 스킬을 차트 형태로 담는다.
이런 형태의 이력서가 매우 유행하는 듯하다.
이력서를 살펴보는 입장에선
주요 스킬
주요 스킬을 포함하여 내가 장점으로 치부할 수 있는 능력을 적게 되는데, 이런 내용이라면 괜찮다.
안드로이드 개발자라면 당연하게도 자바(옵션), 코틀린, 안드로이드는 알아야 한다.
당연히 다룰 수 있어야 할 기술을 설명을 포함해 적어야 할 이유는 없다.
딱히 이력서적인 매력이 없다고 개인적으론 생각한다.
주요 스킬별 점수 노출
간혹 이력서에 주요 스킬별 점수 노출하는 경우가 있다.
이 점수는 지극히 주관적인 점수라고 생각한다.
별 3개 기준 이 스킬의 점수는? 별 5개 기준 이 스킬의 점수는?
뭘 보여주고 싶은 것일까?
이력서를 보는 사람 입장에선 이 점수를 토대로 뭘 기대해야 할 것인가?
보통은 이렇게 생각한다.
내 기준 코틀린 다루는 기술은 별 1개를 겨우 줄 수 있는데, 별 4개라니 엄청난 분이군.
매우 기대하고 면접 볼 수 있겠다.
이걸 기대한 것이라면 이 별점은 매우 유용할 것 같다.
이력
기존 회사에 다니면서 진행한 프로젝트 이력은 매우 중요하다. 이 이력은 거짓말을 포함하더라도, 나중에 국민연금 문서와 비교 후 탈락의 대상이 되기도 한다.
없는 이력을 만들고 합격하더라도, 국민연금 문서와 맞지 않다면 탈락될 수 있단 소리다.
여기서 적어야 할 내용이 있다면 다음일 수 있다.
이직이 잦았다면 이직한 이유를 짧게 적는 것도 좋다.
전직을 해야 한다면 소개 부분에 잘 적고, 여기에도 짧게 적을 필요가 있다.
진행한 프로젝트
진행한 프로젝트는 노션에서 갤러리 뷰로 보통 정리한다. 이 방식을 개인적으로 좋아하지 않는다.
뭘 봐야 할까?
보통 열면 엄청난 설명글과 함께 플로우 차트도 포함되어 있다.
잘 정리되어 있다면 이 내용이 매우 유용하겠지만 이력서를 하루에도 수십 개 봐야 한다면 이 내용을 다 보기 쉽지 않고, 대충 보고 넘어갈 수 있다.
그래서 갤러리 형태가 아니라 표현 형태로 정리하는 걸 추천한다.
내가 이 프로젝트 디테일을 눌렀을 때, 코드를 열었을 때 얻을 수 있는 정보가 무엇일지 말이다.
개인적으로 작성한다면 아래와 같이 적을 것 같다.
https://github.com/taehwandev/ComposeKeyboardState
프로젝트 개요 : Compose에서 키보드 처리를 쉽게 하려고 만듦
다룬 기술
View 상태를 측정해 keyboard state를 처리
Compose에서 이를 쉽게 활용하기 위해 CompositionLocalProvider을 활용
스킬을 테이블로
스킬들을 테이블로 정리하는 경우도 많다.
이 역시 뭘 보여주려 하는지 알기 어렵다. 여기 있는 모든 기술은 이미 회사 이전 이력과 내 프로젝트에 담겨있다.
그렇다면 이 테이블로 한눈에 표기한 내용에선 뭘 알 수 있을까?
보통 면접을 보면 여기에 있는 기술들을 몽땅 다 물어보게 될 수 있다.
최근에 지속적으로 관리한 프로젝트가 그래서 중요하다고 생각한다.
오픈 소스 활동
오픈 소스 활동을 했다면 분명 장점이다.
기여 활동은 다양하다 이슈를 찾아서 이슈를 올릴 수도 있고,
해당 프로젝트에 실제 기술적 오류를 해결할 수도 있다.
단순히 문서 내용을 수정하기도 한다.
문서 내용만 잔뜩 찾아서 오픈소스 활동했다는 건 그다지 큰 장점은 아닌 것 같다.
진짜 코드 수정했다면 코드 리뷰도 배웠고, 기여도 해보았으니 이것만큼 좋은 경험은 없다. 다만 문서 내용만 잔뜩 수정했다는 이력은 매의 눈을 가진 건 틀림없지만 이력에는 좋을까?는 개인적으론 딱히 쓸모없는 지문 낭비로 보인다.
간혹 소스 사용법이 틀릴 수도 있으니 말이다.
그러니 잘 정리해두고, 하나라도 오픈소스에 기여했다면 매우 좋은 경험일 것이다.
정리하면
포트폴리오는 당연하게도 잘 관리한 것 1-2개면 충분하다.
1년에 한 번이라도 좋다. 하다 보면 1년에 한 번으론 관리하기 어렵겠지만.
GitHub 잔디 심기도 좋다. 잔디를 심었다면 어떠한 학습을 했는지가 더 중요하겠지만 꾸준히 공부함을 나타낼 수도 있으니 말이다.
이력서 또한 그렇다.
양이 많은 것보단 간단 명료하게 꼭 필요한 내용을 잘 다루는 편이 더 좋다.
A4 기준 10장을 작성해도 요약이 없는 이력서라면 뭘 봤는지 기억하지 못한다.
열심히 한 만큼 좋은 이력을 남기고 싶다면 핵심만 잘 정리해 난 이런 걸 해봤다만 잘 표현하더라도 좋은 이력서가 될 수 있다.
모호한 내용은 상세 페이지에 담고, 이 프로젝트의 핵심은 한 장만 보아도 알 수 있다면 좋은 이력서 일 수 있다.
마무리
긴 이력서보단 짧은 이력서 의미 없는 개인적인 점수보단 글로 표현하는 것이 더 좋다.
당연히 알아야 할 기술적 내용은 굳이 이력서 지면을 채울 필요는 없다. 이미 프로젝트를 진행해 보았다면 당연히 거기에서 활용하고 있을 것이니 말이다.
그렇다고 필자가 이력서를 잘 쓰는 것도, 면접을 잘 보는 것도 아니니 참고만 하시길

이력서를 위한 이력 관리는 어떻게 하는 것이 좋을까?

댓글