아티클 카타) 상위 1% 개발자들의 포트폴리오, 경력 기술서 작성법

• 프리랜서는 어떻게 포트폴리오를 써야 할까...에 대해 고민이 많았던 차에 발견한 아티클!
• 인사이트를 얻을 수 있을 것 같아 이번 아티클 카타로 선정하게 되었다.
• 출처 : https://yozm.wishket.com/magazine/detail/3391/

상위 1% 개발자들의 포트폴리오, 경력 기술서 작성법 | 요즘IT

 

 

1. 아티클 정보

• 제목 : 상위 1% 개발자들의 포트폴리오, 경력 기술서 작성법
• 작성자(저자) : 위시켓

 

2. 핵심 내용 요약

◾아티클의 주요 메시지

• 포트폴리오와 경력기술서는 그냥 내가 했던 일을 정리해 두는 문서가 아니다.
• 클라이언트 입장에서는 이 사람이 우리 프로젝트를 맡길 만한 사람인지 판단하는 자료에 가깝다.
  (그걸 제가 어떻게 압니꺼... 궁예도 아니고)
• 도급 프로젝트에서는 결과물을 보여주는 포트폴리오가 중요하고,
  기간제나 상주 프로젝트에서는 기술 경험을 정리한 경력기술서가 더 중요하다.
  (자잘한 기간제가 너무 많아서 다 하기엔 메챠 무리데스ㅠㅠ)
• 그래서 어떤 프로젝트에 지원하느냐에 따라 보여줘야 하는 내용도 달라진다.
  (하... 산 넘어 산이로구나)
• 포트폴리오를 쓸 때는 사용한 기술이나 구현한 기능을 많이 나열하는 것보다,
  어떤 문제가 있었고 그 문제를 어떻게 해결했는지 보여주는 게 더 중요하다.
  (이러면 팍 줄긴 함... 근데 너무 팍 줄어버림/기억력 이슈... 10년 전 일까지 다 기억하기엔...8ㅅ8)
• 기술을 설명할 때도 단순히 어려운 기술명을 쓰는 것보다,
  왜 그 기술을 썼고 어떤 효과가 있었는지까지 적어야 클라이언트가 이해하기 쉽다.
  (이것도 하드스킬/소프트스킬 분류해서 작성해야 하는 걸꽈... 홀리몰리 갓떼이욤)
• 경력기술서도 지원하려는 시장에 따라 달라진다.(ㅠㅠ)
• 대기업 SI 시장에서는 프로젝트명, 기간, 고객사, 역할, 사용 기술처럼 정리된 정보가 중요하고,
  스타트업이나 중소기업에서는 문제 해결 과정과 기여도, 성과가 더 중요하게 보인다.ㅌ
  (흩날려라 이력서 하려면 일단 둘 다 적당히 잘 작성하는 수밖에...껄)
  또, 경력이 쌓일수록 단순 개발 경험보다 DB 설계, 인프라 설계 같은 설계 경험이 중요해진다.
  (나의 경우에는 PM 지원할 때 이해관계자 정렬에 포커싱하는 게 좋을 둡... 디자인적인 역량보다는..)
• 특정 산업 도메인 경험도 경력기술서에서 중요한 요소가 될 수 있다.
  (나의 경우는 디자인, 강사 관련해서 경험했던 툴+SaaS/에듀테크 쪽 지식이라고 어필하면 좋을 듯?)

◾핵심 키워드

• 포트폴리오, 경력기술서, 도급 프로젝트, 상주 프로젝트, 문제 해결, 클라이언트 관점, 비즈니스 맥락, SI, SM, 도메인 경험, 설계 경험

 

3. 흥미로운 점 / 새롭게 알게 된 점

◾읽으면서 가장 흥미로웠던 부분

• 포트폴리오와 경력기술서를 프로젝트 유형에 따라 다르게 봐야 한다는 점이 기억에 남았다.
  (언제 하냐 ← 이게 제일 큰 문제임)
• 그동안 포트폴리오는 결과물을 보여주는 자료, 경력기술서는 경력을 정리하는 자료 정도로만 생각했는데,
  이 글에서는 두 문서가 쓰이는 상황 자체가 다르다고 설명한다.
  (그리고 디자인 포폴이랑은 성격이 많이 다른 듯)
• 도급 프로젝트에서는 비슷한 결과물을 만들어본 경험이 중요하고,
  기간제나 상주 프로젝트에서는 특정 기술과 도메인을 얼마나 오래 다뤄봤는지가 중요하다.
• 이렇게 보니 포트폴리오를 만들 때도 무조건 많이 보여주는 게 아니라,
  상대가 어떤 기준으로 나를 판단할지 먼저 생각해야 한다는 점이 보였다.
  결국 읽는 사람은 내 전체 이력이 궁금한 게 아니라, 자기 프로젝트에 맞는 경험이 있는지를 보고 있는 것 같다.
  (그니까 그걸 어케 압니꺼 제가...!!!)

◾이전에는 알지 못했거나 새롭게 배운 내용

• 유명한 프로젝트 경험이 무조건 좋은 포트폴리오가 되는 건 아니라는 점을 새롭게 알게 됐다.
  (딱히 유명한 프로젝트는 없긴 함....ㅋㅋㅋ 도 or 시에서 주관하는 행사를 하청에 하청으로 받아서 처리한 정도...?)
• 대기업 프로젝트를 했거나 어려운 기술을 썼다는 사실보다,
  (사기업이랑 일 해 본 경험 자체가 별로 없음...)
  지금 지원하는 프로젝트와 얼마나 비슷한 문제를 해결했는지가 더 중요하다.
• 기술 설명도 다시 생각하게 됐다.
  아티클 기준 ex. 분산 처리, CI/CD, MSA 같은 단어를 적는 것만으로는 충분하지 않다.
  트래픽이 몰려도 서비스가 안정적으로 돌아가게 하기 위해 적용했다거나,(대용량 트래픽 유지보수 어필... OK)
  배포 과정의 실수를 줄이기 위해 CI/CD를 적용했다는 식으로 써야 기술이 실제 문제 해결과 연결된다.
  (구체적인 예시를 작성하고 싶어서 아티클 발췌에 가깝게 정리했다)
• 이미지 구성도 단순히 예쁜 화면을 보여주는 게 아니라, 서비스 흐름을 이해시키는 역할을 해야 한다는 점이 인상적이었다.
  (개발자도 UI/UX를 어필해야 하는 시대... 혼란하다 혼란해)
• 메인 화면 하나만 보여주는 것보다 사용자 흐름, 관리자 화면, 주요 기능 작동 모습,
  개선 전후를 함께 보여주는 게 훨씬 설득력 있다.
  (이건 PM도 적용 가능한 내용인 둡)

 

4. 나의 한 문장 요약

• 포트폴리오와 경력기술서는 내가 얼마나 많은 일을 했는지 보여주는 문서가 아니라,
  상대방의 문제를 내가 해결할 수 있다는 확신을 주는 문서다.
  (하쥐만... 다다익선인 부분도 있지 않을까나)