웹 개발자 포트폴리오, 뭘 넣어야 취업이 될까?
최종 업데이트: September 21, 2026읽는 데 4분 소요
신입 웹 개발자 서류에서 채용 담당자가 가장 먼저 여는 링크는 이력서가 아니라 포트폴리오입니다. 그런데 여기서 열에 아홉은 비슷한 실수를 합니다. 강의를 따라 만든 투두 리스트 앱 세 개를 나란히 올려두는 거죠.
문제는 그 세 개가 서로 구분이 안 된다는 점입니다. 채용 담당자 입장에서는 "이 사람이 스스로 무엇을 만들 수 있는가"가 궁금한데, 튜토리얼 복제본만 보이면 그 질문에 답이 안 됩니다. 이 글에서는 웹 개발자 포트폴리오에 무엇을 넣어야 서류가 통과되는지, 한국 채용 현실에 맞춰 구체적으로 정리했습니다.
포트폴리오에 반드시 들어가야 하는 것
포트폴리오는 프로젝트 갤러리가 아니라 "이 사람과 일하면 어떤 결과가 나올까"를 보여주는 증거 자료입니다. 그래서 프로젝트 개수보다 각 프로젝트가 무엇을 증명하느냐가 훨씬 중요합니다.
최소한 이 세 가지는 확인할 수 있어야 합니다. 실제로 배포되어 접속되는 링크, 코드를 볼 수 있는 GitHub 저장소, 그리고 무엇을 왜 그렇게 만들었는지 설명하는 README입니다. 링크만 있고 코드가 없으면 검증이 안 되고, 코드만 있고 배포가 안 되어 있으면 "이게 돌아가긴 하나"라는 의심이 남습니다.
한 가지 구체적인 예를 들어볼게요. "동네 카페 대기 인원 공유 앱"을 만들었다고 해봅시다. 로그인, 실시간 대기 등록, 지도 표시 기능이 있고 Vercel에 배포되어 있으며 README에는 "왜 이 문제를 골랐는지, 어떤 기술을 썼는지, 개발 중 막혔던 지점과 해결 방법"이 적혀 있습니다. 이런 프로젝트 하나가 튜토리얼 복제본 다섯 개보다 강합니다. 채용 담당자가 클릭 몇 번으로 "아, 이 사람은 문제를 정의하고 끝까지 만든다"를 확인할 수 있으니까요.
프로젝트를 고르는 기준
무엇을 넣을지 고민된다면 이 질문을 던져보세요. "이 프로젝트를 면접에서 5분 동안 설명할 수 있는가?" 설명할 거리가 없다면 포트폴리오에 넣을 이유도 없습니다.
강의 과제를 그대로 올리는 대신, 거기서 기능 하나를 더 붙이거나 UI를 처음부터 다시 짜보세요. 원본과 달라진 지점이 곧 당신의 실력을 보여주는 부분입니다. 프론트엔드 지원자라면 반응형 처리와 접근성을, 백엔드 지원자라면 API 설계와 데이터베이스 구조를 드러내는 프로젝트가 유리합니다. 이 두 방향이 헷갈린다면 프론트엔드와 백엔드를 비교해 시작점을 정하는 가이드를 먼저 읽고 방향을 잡는 편이 낫습니다.
신입이 자주 하는 실수
가장 흔한 건 "완성도 낮은 프로젝트를 많이 올리는 것"입니다. 개수로 승부하려는 심리인데, 오히려 역효과입니다. 미완성 프로젝트 다섯 개는 "이 사람은 시작만 하고 끝을 못 낸다"는 인상을 줍니다.
두 번째는 README를 비워두는 것입니다. GitHub 저장소에 코드만 덜렁 있고 설명이 없으면, 바쁜 채용 담당자는 코드를 한 줄씩 읽어줄 여유가 없습니다. 프로젝트 스크린샷, 실행 방법, 사용 기술, 담당한 부분을 세 문단이면 충분히 정리할 수 있습니다.
세 번째는 배포를 안 하는 것입니다. 로컬에서만 돌아가는 프로젝트는 존재하지 않는 것과 비슷하게 취급됩니다. Vercel, Netlify, GitHub Pages 같은 무료 호스팅으로 5분이면 배포되니, 이건 반드시 해두세요.
좋은 포트폴리오 vs 아쉬운 포트폴리오
같은 실력이어도 정리 방식에 따라 결과가 갈립니다. 아래 표로 차이를 비교해봤습니다.
| 항목 | 아쉬운 포트폴리오 | 서류가 통과되는 포트폴리오 |
|---|---|---|
| 프로젝트 수 | 미완성 5~6개 | 완성·배포된 2~3개 |
| 주제 | 튜토리얼 복제본 | 스스로 정의한 문제 |
| 배포 | 로컬 실행만 가능 | 접속되는 URL 제공 |
| README | 비어 있거나 한 줄 | 문제·기술·담당 역할 설명 |
| 코드 | 커밋 1개에 몰아넣음 | 의미 단위로 나눈 커밋 이력 |
표에서 보듯 핵심은 화려한 기술 스택이 아니라 "검증 가능성"입니다. 서울이든 부산이든, 스타트업이든 SI 업체든, 채용 담당자가 확인하고 싶은 건 결국 같습니다. 이 사람이 실제로 만들 수 있는가.
어디에 올려야 할까
한국에서 신입 웹 개발자 포트폴리오를 정리하는 방법은 크게 두 가지입니다. GitHub 저장소를 정리하고 README를 포트폴리오 허브처럼 쓰는 방식, 그리고 개인 웹사이트를 직접 만들어 프로젝트를 소개하는 방식입니다.
개인 웹사이트를 만들면 그 자체가 프론트엔드 실력을 보여주는 프로젝트가 됩니다. Next.js로 간단한 소개 페이지를 만들어 배포하면, 별도 프로젝트 하나를 추가한 효과가 납니다. 다만 시간이 부족하면 무리해서 웹사이트를 만들기보다 GitHub 정리부터 끝내는 게 현실적입니다. 완성되지 않은 개인 사이트는 오히려 마이너스입니다.
이력서에는 GitHub 링크와 배포 URL을 상단에 명확히 적어두세요. 채용 담당자가 스크롤을 내리지 않아도 클릭할 수 있어야 합니다.
혼자 만들기 막막하다면
포트폴리오의 진짜 어려움은 코드가 아니라 "무엇을 만들지 정하는 것"에 있습니다. 실무에서 다루는 문제를 경험해본 적이 없으면 주제 자체가 안 떠오르죠. 이럴 때는 팀 프로젝트나 협업 과제를 거치면서 실제 개발 흐름을 겪어보는 게 도움이 됩니다.
정규 과정으로 기초부터 프로젝트까지 이어서 쌓고 싶다면 실무 프로젝트 중심의 웹 개발 부트캠프 과정을 살펴보고, 직장을 다니면서 자기 속도로 배우려면 자기주도형 웹 개발 학습 코스가 더 잘 맞습니다. 어떤 방식이든 결과물로 남는 프로젝트가 있어야 포트폴리오가 채워집니다.
포트폴리오는 프로젝트를 모아둔 창고가 아니라, 완성하고 배포하고 설명까지 끝낸 결과물 두세 개면 충분합니다. 오늘 만든 프로젝트 중 하나를 골라 README부터 채우고 배포 링크를 붙여보세요. 어디서부터 시작할지 감이 잡히지 않는다면 수강 방식별 비용과 과정 구성을 비교해보며 자신에게 맞는 학습 경로를 정해보시길 권합니다.
