저도 처음엔 보여줄 게 없는데 어떻게 포트폴리오를 만들지?라는 생각만 했습니다.
큰 팀 프로젝트도 없고, 완성된 서비스도 없는 상태에서 포트폴리오라는 단어 자체가 부담이었습니다. 그런데 직접 부딪혀보니, 포트폴리오는 이미 대단한 경험이 있는 사람만 만드는 문서가 아니었습니다. 작은 경험이라도 어떻게 정리하느냐에 따라 완전히 다른 결과가 나온다는 걸 알게 됐습니다.
작은 결과물도 포트폴리오가 된다
처음 포트폴리오를 준비할 때, 저는 클론 코딩(clone coding)으로 시작했습니다. 클론 코딩이란 기존에 있는 서비스나 화면을 보고 그대로 따라 만들어보는 학습 방식입니다. 처음엔 이게 포트폴리오에 넣을 수 있는 경험이 맞는지조차 확신이 없었습니다. 그냥 따라 만든 건데 의미가 있을까 싶었습니다.
그런데 생각을 바꾼 계기가 있었습니다. 로그인 화면을 만들다가 입력값 유효성 검사(validation)에서 막힌 적이 있었는데, 유효성 검사란 사용자가 입력한 데이터가 올바른 형식인지 확인하는 로직을 말합니다. 이 부분을 콘솔로 하나씩 찍어가며 직접 해결했을 때, 그게 단순한 실습과는 다른 경험이라는 걸 느꼈습니다. 그리고 그 과정을 GitHub README에 기록하면서 생각이 완전히 달라졌습니다.
일반적으로 신입 포트폴리오는 규모가 커야 한다고들 말하지만, 제 경험상 이건 좀 다릅니다. 기업 채용 담당자들이 신입에게 기대하는 건 완성된 서비스가 아니라 학습 태도와 성장 가능성에 가깝습니다. 고용노동부 취업 지원 지침에서도 신입 구직자의 직무 역량 기록과 성장 과정 정리를 포트폴리오의 핵심 요소로 안내하고 있습니다.
실제로 작은 결과물을 포트폴리오로 정리할 때 효과적인 방법은 다음과 같습니다.
- 자기소개 페이지, 할 일 목록(To-do List), 날씨 API 연결처럼 기능 단위로 나눠서 각각 저장소를 만든다
- 각 저장소마다 README에 제작 목적, 사용 기술, 어려웠던 점, 해결 방법을 기록한다
- 작은 기능들을 HTML/CSS 기초 → JavaScript 이벤트 처리 → API 연동처럼 학습 흐름으로 묶어 보여준다
이렇게 정리하면 단편적인 조각처럼 보이는 실습들이 하나의 성장 스토리로 읽힙니다. 제가 직접 해봤을 때, GitHub 프로필 상단에 대표 저장소를 정리하고 README를 채워 넣자 확연히 다른 인상이 됐습니다. 코드만 올려둔 빈 저장소와, 왜 만들었고 무엇을 배웠는지 적힌 저장소는 읽는 사람 입장에서 완전히 다르게 느껴집니다.
문제 해결 기록이 포트폴리오의 진짜 핵심이다
직접 겪어보니 가장 강한 포트폴리오는 트러블슈팅(troubleshooting) 기록이었습니다. 트러블슈팅이란 문제가 발생했을 때 원인을 찾고 해결하는 과정을 체계적으로 정리한 기록을 말합니다. 결과물이 완성도 높은 서비스가 아니더라도, 어떤 오류를 만났고 어떻게 해결했는지를 쓴 포트폴리오는 그냥 만들었다는 포트폴리오와 완전히 다른 무게를 가집니다.
제가 경험한 대표적인 트러블슈팅 상황을 예로 들면, API 응답 데이터를 화면에 출력하다가 undefined가 반복 출력되는 문제가 있었습니다. 비동기 처리(asynchronous processing)를 제대로 이해하지 못한 게 원인이었는데, 비동기 처리란 데이터를 요청한 뒤 응답을 기다리는 동안 다른 코드가 먼저 실행되는 방식을 말합니다. 이 개념을 이해하고 Promise와 async/await 구조로 수정했을 때의 성취감은 지금도 기억에 남습니다. 그리고 그 경험을 README에 문제 상황 → 원인 파악 → 해결 방법 → 배운 점 순서로 기록해 뒀습니다.
솔직히 이건 예상 밖이었습니다. 면접 준비를 하면서 어떤 문제를 해결해 봤나요?라는 질문에 막혔던 기억이 있는데, 이 트러블슈팅 기록 덕분에 구체적인 답변이 가능해졌습니다. 한국직업능력연구원 자료에 따르면 IT 직무 신입 채용에서 실무 문제 해결 경험과 논리적 사고 과정을 제시하는 지원자를 더 선호하는 경향이 있다고 분석합니다.
포트폴리오에서 문제 해결 기록을 효과적으로 정리하려면 다음 구조를 추천합니다.
- 문제 상황: 어떤 오류나 막힘이 있었는지 구체적으로 서술
- 원인 파악: 어떻게 원인을 찾았는지 (콘솔 확인, 공식 문서 참조 등)
- 해결 방법: 실제로 어떻게 고쳤는지
- 배운 점: 이 경험을 통해 어떤 개념을 더 이해하게 됐는지
이 구조로 기록하면 작은 실습 하나도 면접용 경험 서술이 됩니다. 특히 버전 관리 시스템인 Git에서 충돌(conflict)이 발생했을 때 해결한 경험처럼, 겉으로 보기엔 사소해 보이는 경험도 이 구조로 쓰면 전혀 다르게 읽힙니다. 입문자나 비전공자일수록 이런 기록 습관이 나중에 팀 프로젝트 경험이 생겼을 때 포트폴리오를 확장하는 데에도 훨씬 자연스럽게 이어집니다.
결국 지금 가진 가장 작은 결과물부터 기록하는 것이 맞는 방향이라고 생각합니다. 포트폴리오는 완성된 실력을 증명하는 문서가 아니라, 배우고 성장하는 과정을 보여주는 기록입니다. 경험이 없어서 시작 못 하는 게 아니라, 작은 경험을 기록하지 않았기 때문에 비어 보이는 경우가 훨씬 많습니다. 지금 만든 가장 작은 기능 하나, 오늘 해결한 오류 하나부터 README에 적어두는 것부터 시작하면 충분합니다.
프로젝트 경험이 없는 사람은 포트폴리오를 만들면서 동시에 경험을 쌓아야 한다
포트폴리오가 없는 상태에서 가장 좋은 방법은 포트폴리오를 완성한 뒤에 경험을 쌓으려고 하는 것이 아니라, 포트폴리오를 만들면서 경험을 쌓는 것이 중요합니다.
예를 들어 다음과 같은 흐름으로 준비할 수 있다.
- 희망 직무를 정한다
- 그 직무에 맞는 작은 기능을 하나 만든다
- GitHub에 올리고 README를 작성한다
- 문제 해결 과정을 짧게 정리한다
- 다시 작은 기능 하나를 더 만든다
- 이를 반복하면서 포트폴리오를 채운다
이 방식의 장점은 명확합니다. 포트폴리오를 미루지 않게 되고, 작은 경험도 기록으로 남기게 되며, 시간이 지날수록 성장한 과정이 자연스럽게 경험을 하게 됩니다.
특히 비전공자나 입문자들이 많이 생각하는 부분이, 완벽한 프로젝트를 하고 나서 포트폴리오를 만들어야 한다라고 생각하기 때문에 시작을 늦추는 경우들이 많습니다. 그렇지만 실제로는 작은 실습, 간단한 클론 코딩, 기능 구현, 오류 해결 경험도 모두 충분한 포트폴리오가 될 수 있습니다.
중요한 것은 완벽한 결과물이 아니라 지금 할 수 있는 것을 직접 경험해 보고, 그것을 이해하고, 정리해 두는 습관입니다. 이 습관이 쌓이면 나중에는 프로젝트 경험이 생겼을 때도 자연스럽게 포트폴리오를 확장할 수 있습니다.
결국 경험이 없는 사람에게 포트폴리오는 없는 상태를 숨기는 문서가 아니라, 지금부터 경험을 만들어가는 과정을 보여주는 문서에 가깝습니다.