신입 개발자를 위한 포트폴리오 작성법 5가지

 포트폴리오는 지원자의 첫인상을 결정합니다. 특히 개발자에게 포트폴리오는 작업물을 공유하고 기업에게 어필하기 위한 가장 좋은 수단입니다. 반대로 기업은 지원자의 기술 역량을 파악하고 성향과 코드 스타일까지 확인할 수 있기에 협업에 유리한 인재인지 아닌지를 알게 됩니다. 그렇기에 지원자는 포트폴리오 관리에 신경 쓸 수밖에 없습니다. 이번 포스트에서는 신입 개발자(프론트엔드 and 백엔드)를 위한 포트폴리오 작성법을 소개합니다. 

 

1. 팀 프로젝트와 개인 프로젝트를 적절하게

 팀 프로젝트는 협업 능력을 측정하기 위한 중요한 포트폴리오입니다. 평생 개인 프로젝트만 해온 사람 즉, 독학러들은 상대적으로 깃허브 브랜치 전략이나 실무 협업을 경험해보지 못해 입사 초기부터 버벅거릴 수 있습니다. 기업 입장에서 이런 사람을 좋아하지는 않겠죠. 따라서 해커톤, 공모전, 국비지원(팀프로젝트) 같은 곳에서 다른 개발자들과 협업한 프로젝트를 기입하는게 좋습니다. 

 

 만약 팀 프로젝트가 없다면 해커톤을 준비해보시는 것도 도움이 됩니다. 굳이 해커톤이 아니더라도 개발자 행사(컨퍼런스, 세미나)에 주기적으로 참석해 보며 정보를 얻는 것도 도움이 됩니다. 아예 특정 컨퍼런스에서 강연자로 참석해 발표하는 경험도 좋고요. 아래 깃허브 레포에 개발자 행사 리스트가 잘 정리되어 있으니 참고하시면 됩니다.

 

https://github.com/brave-people/Dev-Event

 

 그럼 팀 프로젝트만 적으면 되는건가? 그건 아닙니다. 팀 프로젝트만 기입되어 있으면 개인 성장 측면에서 소홀하다고 느껴지기 때문에 개인 프로젝트를 한 두 개 정도 기입해 놓는 것도 중요합니다. 특히 프론트엔드 개발자라면 프론트엔드 중심 프로젝트 하나, 백엔드 서버를 구축한 풀 스택 프로젝트 하나 이렇게 구성하는 것도 좋습니다.

 

 회사일을 하다보면 그동안 쓰지 않았던 기술을 다루게 되는데 이때 개인 프로젝트로 학습 경험이 있다면 지원자로 하여금 꾸준하게 공부하는 사람이라는 인상을 줄 수 있습니다. 동시에 팀 프로젝트 기여에 있어서도 무임승차하지 않는다는 마음가짐도 주게 됩니다. 

 

사실상 본업에 도움되라고 하는ㄱ ㅓ https://www.shinailbo.co.kr/news/articleView.html?idxno=1623875

 

2. 이슈, 문제 상황, 해결 방법, 배운점

 포트폴리오 작성법입니다. 맨 처음 어떤 이슈가 있었는지, 그게 왜 문제인지를 한 문장으로 적습니다. 그리고 어떤 기술을 써서 어떻게 해결했는지, 마지막으로 무엇을 배웠는지 까지 하면 지원자로 하여금 적절한 상황에 적절한 기술스택을 활용했다는 점이 보입니다. 즉, 문제해결을 할 때 막무가내로 처리하는 게 아닌, 적절한 과정을 거치고 합리적인 방법으로 문제정의와 해결을 할 수 있는 인재라는 점을 어필하는 것이죠.

 

 예를 들어 프론트엔드에서 d3.js로 그래프를 그리는데, React와 D3.js모두 DOM에 접근할 수 있다 보니 성능 저하 문제가 생기는 상황을 마주했다고 가정해 봅시다. 그리고 서로다른 두 기술을 React는 단순 UI에 D3.js는 복잡한 연산으로 기능을 분리하여 1000개의 Data 범위에서 프레임율을 80%끌어올렸다고 가정해봅시다. 이 문제해결 과정을 다음과 같이 기술할 수 있습니다.

 

React와 D3.js를 동시에 사용하다 보니 프레임 저하 현상이 생겨 유저가 불편함을 겪었음. React는 UI파트, D3.js는 그래프 연산 파트로 DOM 업데이트 범위 분리해서 해결함. 기존대비 프레임율을 80% 개선함.

 

 이렇게 되면 기업 면접관 입장에서 문제의 원인과 해결과정을 쉽게 해석할 수 있습니다. 대부분 시니어분들이기 때문에 자세하게 묘사하지 않아도 충분히 이해하시니 굳이 길게 적지 마시고 최대한 압축해서 두괄식으로 작성하시면 됩니다.

 

 

3. 토글 제외, 링크는 최대한 적게, 가독성 신경 써서

 노션으로 이력서를 작성하신다면 토글에 디테일한 부분을 적게 됩니다. 그러나 실제 기업 면접관 분들은 하루에도 수십 건 많게는 수백 건가량의 이력서를 마주하시기 때문에 토글을 하나하나 열어볼 시간이 없습니다. 우리 회사에 가장 알맞은 지원자를 뽑기 위해서는 쓱 읽어보는 게 중요한데 토글을 여느라 시간이 낭비된다면 상당히 불편해집니다. 이 같은 점 때문에 면접관 입장에서는 상대에 대한 배려를 하지 않는다고 잘 못 비칠 수 있습니다. 불편하기도 하고요.

 

 이력서는 깔끔하고 임팩트 있어야 합니다. 단 몇 장에 기술 스택, 이력, 신뢰도, 협업능력, 직무 능력등을 함축해서 보여줘야 하기 때문에 면접관 입장에서 거슬리는 요소가 있으면 안 됩니다.

 

 링크도 마찬가지입니다. 링크드인, 깃허브 주소와 포트폴리오 접속 주소만 링크해 두고, 유튜브, 스크린샷등은 첨부하지 않는 게 좋습니다. 오픈소스의 경우 깃허브 레포를 링크해 두시고 레포 내의 리드미를 최대한 신경 써서 작성하시는 편이 좋습니다. 이 경우 지원자의 문서화 능력을 직접적으로 볼 수 있기 때문에 협업 차원에서 긍정적인 인상을 줄 수 있습니다.

 가독성을 신경써서 작성하면 “배려하는 사람”이라는 인상을 쉽게 줄 수 있습니다. 하루에도 여러 이력서를 검토하는 사람 입장에서 가독성이 떨어지는 이력서를 많이 읽게 되는데 그때 가독성이 좋은 이력서는 단연 눈에 띌 수밖에 없습니다. 말을 길게 풀어쓰지 마시고 두괄식으로 작성하셔야 합니다. 행은 최대 3~4줄이 적당합니다.

 

4. 기업에 맞는 스택 중심으로 구성

 소개할 프로젝트가 많은 경우(5~6개) 지원할 기업에서 요구하는 스택에 가장 부합하는 프로젝트를 우선적으로 선별하셔야 합니다. 아무리 주니어라도 회사 입장에서는 바로 투입해서 성과를 내는 게 중요하게 작용하기에 기업이 현재 사용 중인 스택을 중심으로 이력서를 수정하는 건 취업등락에 중요한 작용을 할 수밖에 없습니다. 언제나 팔은 안으로 굽는 법이니까요. 당연 회사에서 사용하는 스택을 주로 사용하는 지원자를 봤을 때 같은 능력이라도 좋게 보이는 건 회사 입장에서 당연한 일입니다.

 

 회사가 사용하는 스택은 채용공고를 보면 나와 있습니다. 프론트엔드의 경우 대게 React/TypeScript 스택을 기조로 NextJS나 다른 스타일/상태관리 라이브러리들을 사용하고 있습니다. 사이드 프로젝트를 통해 하나 둘 익히시다 보면 회사의 스택과 사이드프로젝트의 스택이 동일한 경우가 있는데, 이런 프로젝트를 선별해서 지원해 보는 것도 도움이 됩니다.

 

https://yozm.wishket.com/magazine/detail/1402/

 

 참고로 위 이미지에서 jQuery는 배우지 않는 게 좋습니다. 

 

5. 주변 사람들 이력서 검토

 면접관 입장에서 생각해 볼 수 있어야 합니다. 가장 좋은 방법은 나를 제외한 다른 이력서를 검토해 보는 방법입니다. 개발 직군 특성상 플랫폼에 포트폴리오를 공개하는 경우가 많은데, 플랫폼에서 다른 개발자분들 이력서를 열람해 볼 수 있습니다. 제가 추천하는 플랫폼으로는 렐릿, 서핏이 있습니다. 각 플랫폼 모두 다른 개발자분들이 올려두신 이력서를 볼 수 있는데, 이러한 경험이 내 스택을 객관적으로 바라보는데 도움이 됩니다. 게다가 이력서를 잘 만들어서 올려두면 취업 이직 제안도 들어오는 편이니 해당 플랫폼에 올려두면 일석이조겠죠. 

 

---

 

 이렇게 신입 개발자를 위한 포트폴리오 작성법을 알아봤습니다. 도움이 되셨다면 좋겠습니다.