포트폴리오를 처음 만들 때, 저도 프로젝트를 많이 넣으면 유리하다고 생각했습니다.
기술 스택 목록을 길게 쌓고, 화면 캡처를 잔뜩 붙여두면 그게 실력처럼 보일 거라고 착각했습니다.
막상 정리를 끝내고 나서 들었던 생각은 딱 하나였습니다. 이게 나를 보여주는 게 맞나? 이 글은 그 고민에서 출발합니다.
개발자 프로젝트 개요: 포트폴리오, 결과물보다 왜 만들었는가 가 먼저입니다
처음 포트폴리오를 만들 때 가장 흔히 빠지는 함정이 있습니다.
완성된 화면을 보여주는 것에만 집중하는 겁니다. 결과물은 있는데 맥락이 없는 포트폴리오는 읽는 사람 입장에서 맥이 빠집니다.
프로젝트 개요(Project Overview)란 단순한 소개 문장이 아닙니다.
여기서 프로젝트 개요란, 이 프로젝트가 어떤 문제를 해결하기 위해 만들어졌는지, 사용자가 누구인지, 어떤 상황에서 필요한 도구인지를 압축해서 보여주는 첫 문장입니다.
사용자 일정 관리를 돕는 웹 서비스처럼 짧고 분명한 한 줄이, 스크린숏 열 장보다 훨씬 빠르게 읽히는 이유가 여기 있습니다.
GitHub 공식 문서에서도 저장소의 README가 방문자가 가장 먼저 마주하는 공간이며, 프로젝트의 목적과 유용성이 담겨야 한다고 안내하고 있습니다.
저도 README를 처음 제대로 써봤을 때, 오히려 제 프로젝트를 스스로 더 잘 이해하게 됐습니다. 목적을 한 문장으로 정리하려니 내가 뭘 만들었는지 명확하지 않은 부분이 드러났거든요.
개요와 목적이 분명하게 잡혀 있으면, 그 뒤에 나오는 기술 설명도 힘을 받습니다.
반대로 이 부분이 흐릿하면 아무리 코드가 잘 짜여 있어도 읽는 사람은 방향을 잃습니다. 프로젝트 규모가 작아도 목적이 분명한 포트폴리오가 훨씬 정돈된 인상을 주는 이유가 바로 여기 있습니다.
개발자 포트폴리오 역할 분리 : 기술 스택 나열보다 내가 한 일 이 훨씬 중요합니다
React, Spring Boot, MySQL, AWS EC2 사용. 이런 기술 스택(Tech Stack) 목록을 보면 뭔가 있어 보입니다.
여기서 기술 스택이란 프로젝트를 만드는 데 사용한 언어, 프레임워크, 데이터베이스, 인프라 도구의 조합을 의미합니다.
그런데 저는 직접 경험해 보니 이 목록만으로는 실제 역량이 거의 드러나지 않는다는 걸 알게 됐습니다.
채용 담당자가 보고 싶은 건 기술 이름이 아니라, 그 기술로 뭘 만들었느냐이기 때문입니다.
특히 팀 프로젝트에서 역할 분리(Role Separation)가 빠진 경우가 많습니다.
역할 분리란 팀원 각자가 어떤 기능을 직접 구현했는지, 어느 영역을 담당했는지를 명확히 구분해 기록하는 것입니다.
전체 프로젝트 소개만 쭉 나열해 두면 이 팀에서 이 사람이 실제로 뭘 했는지를 파악하기 어렵습니다.
제가 팀 프로젝트를 정리할 때 이 부분을 뭉개고 넘어갔다가 나중에 면접에서 이 기능은 직접 구현하셨나요?라는 질문을 받고 멈칫했던 기억이 있습니다. 그 이후로는 반드시 본인 역할을 분리해서 적도록 바꿨습니다.
포트폴리오에서 본인 역할을 정리할 때 참고할 수 있는 항목은 다음과 같습니다.
- 프런트엔드: 화면 구성, 상태 관리(State Management), 반응형 레이아웃(Responsive Layout), API 연결
- 백엔드: 회원 인증(Authentication), 데이터베이스 설계(DB Schema), 예외 처리(Exception Handling), REST API 설계
- 공통: 배포 환경 구성, 코드 리뷰, 문서화
React로 사용자 입력 상태를 관리하고, 검색 결과를 조건별로 필터링하는 화면을 구현했다 처럼 작업 단위로 적는 것이 훨씬 읽히기 좋습니다. 기술 이름 한 줄과, 그 기술로 실제 만든 것을 설명한 두 줄은 완전히 다른 무게를 가집니다.
문제 해결 과정이 있어야 포트폴리오가 살아납니다
결과물 모음집으로 끝나는 포트폴리오가 아쉬운 이유는 딱 하나입니다.
어떻게 생각했는지가 안 보이기 때문입니다. 신입 채용에서 특히 이 부분이 중요하게 읽힌다는 것을 저는 뒤늦게 알았습니다.
트러블슈팅(Troubleshooting) 경험을 포트폴리오에 담는 것이 효과적입니다.
트러블슈팅이란 개발 과정에서 발생한 오류나 성능 문제를 분석하고 해결하는 과정 전체를 뜻합니다.
로그인 토큰 만료 오류를 해결한 경험이든, API 응답 속도를 줄인 경험이든, 레이아웃이 특정 기기에서 무너지는 문제를 잡은 경험이든 상관없습니다. 중요한 건 그 문제가 얼마나 어려웠냐가 아니라, 어떻게 분석하고 어떤 방식으로 해결했는지입니다.
고용노동부 국가직무능력표준(NCS)에서도 문제해결능력을 핵심 직업기초능력 중 하나로 제시하고 있으며, 의사소통능력과 함께 거의 모든 직무에서 공통으로 요구되는 역량으로 분류하고 있습니다.
결국 개발자 포트폴리오는 코드를 보여주는 문서이면서 동시에, 내가 어떻게 사고하고 소통할 수 있는 사람인지를 보여주는 문서이기도 합니다.
저는 각 프로젝트에 어려웠던 점, 해결 방법, 다시 만든다면 바꿀 부분을 짧게라도 적는 습관을 들였습니다.
이 항목들은 면접 답변으로도 그대로 이어졌고, 준비가 덜 된 상태에서 떠듬거리던 때와는 확실히 달랐습니다.
특히 다시 만든다면이라는 항목은 스스로도 생각을 정리하는 데 꽤 도움이 됐습니다. 부족한 점을 인정하면서도 그걸 어떻게 개선할 수 있는지 방향을 보여줄 수 있으니까요.
GitHub README 상태도 함께 점검하는 게 좋습니다.
저장소 이름이 뒤섞여 있거나 README가 비어 있으면, 코드 완성도와 무관하게 정돈되지 않은 인상을 줍니다.
README에 프로젝트 목적, 주요 기능, 실행 방법, 예시 화면이 정리되어 있으면 읽는 사람이 훨씬 빠르게 파악할 수 있습니다.
포트폴리오는 PDF 한 장이 아니라, GitHub 전체 구조와 README, 배포 링크까지 포함한 전체 인상에 가깝습니다.
포트폴리오를 화려하게 꾸미려는 마음은 이해합니다.
저도 처음엔 그랬으니까요. 하지만 실제로 읽히는 포트폴리오는 많이 넣은 것이 아니라 잘 정리된 것입니다.
프로젝트 하나를 제대로 설명할 수 있는 사람이, 열 개를 나열해 두고 설명 못 하는 사람보다 훨씬 강한 인상을 줍니다.
포트폴리오를 마지막에 급하게 만드는 자료라고 생각하지 말고, 공부와 프로젝트를 진행하면서 차곡차곡 기록해 두는 과정 자체로 접근해 보시길 권합니다.