개발자 포트폴리오 구성법: 신입 프로젝트 2~3개 고르기와 README 작성 예시 (2026)

소개, 대표 프로젝트, 기술 스택, 링크를 기본 골격으로 잡으면 돼요. 아래 표는 프리터뷰가 정리한 편집 양식이고 정해진 규격은 아닙니다.

형식은 웹 페이지, 노션, PDF 어느 쪽이어도 내용은 같고, 채용 공고가 형식을 정해 두었다면 그대로 따르세요.

GitHub를 쓴다면 두 가지를 손볼 만해요. GitHub 문서에 따르면 사용자 이름과 같은 이름의 퍼블릭 저장소를 만들고 루트에 README.md를 두면 그 내용이 프로필 페이지에 표시돼요. 프로필에는 저장소를 고정할 수 있는데 저장소와 gist를 합쳐 최대 6개까지입니다. 6개를 다 채울 필요는 없고, 이 글이 권하는 대표 프로젝트 2~3개를 맨 앞에 고정하면 프로필을 연 사람이 먼저 보는 곳이 정리돼요.

신입이라면 2~3개를 제안해요. 고르는 기준은 직무 관련성, 내가 구현한 범위, 실행 결과를 보여 줄 수 있는지입니다. 개수는 편집 제안이고, 기준은 아래처럼 확인 질문으로 바꿔 쓸 수 있어요.

세 기준을 모두 넘은 프로젝트가 한 개뿐이면 한 개를 깊게 쓰는 편이 나아요. 기준에 못 미치는 프로젝트로 개수를 채우면, 그 프로젝트마다 면접에서 답하기 어려운 질문이 생깁니다.

가상 예시로 후보가 다섯 개 있다고 해 볼게요. 강의를 따라 만든 쇼핑몰, 직접 설계한 동아리 일정 앱, 팀으로 만든 중고 거래 서비스, 알고리즘 문제 풀이 저장소, 공공 데이터로 만든 지도 앱입니다. 백엔드 공고라면 동아리 일정 앱과 중고 거래 서비스의 서버 쪽을 대표로 두고, 지도 앱은 보조로 한 줄만 적어요. 강의 쇼핑몰과 풀이 저장소는 GitHub에는 남기되 포트폴리오 본문에서는 뺍니다.

대표 프로젝트 중 하나는 직무와 가장 가까운 것으로 설명을 길게 쓰고, 나머지는 다른 면을 보여 주는 것으로 고르면 균형이 잡혀요. 예를 들어 하나는 서버 설계를, 하나는 팀 협업과 배포를 보여 주는 식입니다.

문제, 내가 한 일, 결과 순서로 쓰세요. MIT 진로개발센터의 이력서 안내는 경험을 쓸 때 무엇을 했고, 왜 했고, 결과가 어땠는지를 답하게 하고, 결과의 규모를 확인 가능한 수치로 보이라고 안내해요. 이력서용 안내이지만 프로젝트 설명에도 그대로 맞습니다.

결과 칸에 쓸 숫자가 없다면 만들어 넣지 말고, 실제로 확인한 사실로 대신하세요. 어떤 값을 어떻게 쟀는지(측정 방법과 전후 조건)를 함께 적으면 숫자의 신뢰가 올라갑니다. 아래 두 전후 비교는 모두 가상 예시이고 ○에는 내가 잰 값만 들어가야 해요.

프론트엔드도 같은 방식으로 고쳐 볼게요.

프로젝트마다 이 세 줄을 먼저 쓰고 그 아래에 화면 캡처와 링크를 붙이세요. 판단 이유(왜 이 도구와 구조를 골랐는지)는 한 줄이라도 있어야 면접 질문에 연결돼요. 질문이 어디서 나오는지는 포트폴리오 면접 질문 예시에 있어요.

한 줄 소개, 화면 캡처, 실행 방법, 배포 링크가 기본이고, 포트폴리오용이라면 내가 맡은 부분과 막혔던 문제를 더하세요. GitHub 문서는 README에 프로젝트가 하는 일, 유용한 이유, 시작하는 방법, 도움을 받을 곳, 유지·기여하는 사람을 담는 것이 일반적이라고 설명하고, 긴 설명서는 위키에 두라고 안내해요. GitHub 문서도 방문자가 저장소를 열면 가장 먼저 보는 항목이 README인 경우가 많다고 설명해요.

아래는 가상의 동아리 일정 앱을 기준으로 한 README 골격입니다. 순서와 칸 이름은 프리터뷰의 편집 제안이에요.

실행 방법은 새 컴퓨터에서 그대로 따라 해 돌아가는지 직접 확인하세요. 실행 명령이 한 줄만 틀려도 읽는 사람은 프로젝트를 돌려 보지 못해요. 환경 변수는 이름만 적고 값은 비워 둔 예시 설정 파일로 안내하는 방식이 안전해요.

프리터뷰 포트폴리오 점검에 GitHub 주소를 넣었는데 README가 없거나 몇 줄뿐이어서, 첨부 파일 없이 읽어 낸 실질 본문을 모두 합쳐도 500자가 안 되면 채점하지 않고 읽을 내용이 거의 없다고 안내해요. 이 경우에는 점검권이 차감되지 않아요(2026-10-28 기준 서비스 동작). 점검을 받기 전에 README부터 채워 두면 같은 안내를 받지 않고 바로 평가를 확인해요.

열었을 때 바로 확인되는 것이 다르니, 먼저 보여 줄 자료도 달라져요. 아래 표는 편집 정리이고 직무별 공식 기준은 아닙니다.

무료 배포 서버는 일정 시간 요청이 없으면 멈추는 경우가 있어서, 제출 직전에 직접 열어 응답이 오는지 보세요. 직무별 면접 질문은 백엔드 개발자 면접 가이드와 프론트엔드 개발자 면접 가이드에 정리했어요.

내가 한 부분과 아닌 부분을 나눠 적으면 내 프로젝트로 쓸 수 있어요. 팀 프로젝트와 커리큘럼 과제는 전체 기능을 모두 내 것처럼 쓰면 면접에서 바로 막히니, 역할을 아래처럼 갈라 표기하세요.

커밋 기록과 PR이 남아 있다면 링크로 걸어 두는 방법이 있어요. 읽는 사람이 내 기여를 직접 확인할 수 있게 하자는 편집 제안입니다. 커리큘럼 과제를 내 프로젝트로 바꾸는 재료는 부트캠프 수료 후 취업 준비에서 더 다뤘어요.

팀 프로젝트라면 전체 구조는 그림 한 장으로 요약하고, 설명 분량은 내가 맡은 구간에 쓰세요. 맡지 않은 부분을 자세히 적으면 그 부분을 묻는 질문에 답하기 어려워져요.

링크, 비밀 정보, 분량을 확인하세요. 아래는 프리터뷰가 제안하는 제출 전 점검표예요.

• 로그아웃한 브라우저나 시크릿 창에서 GitHub, 배포, 문서 링크가 모두 열리는가
• 대표 저장소가 퍼블릭이고 README 첫 화면에 한 줄 소개와 실행 화면이 보이는가
• README, 설정 파일, 커밋 기록에 비밀번호, API 키, 개인정보가 없는가
• 비밀 정보가 한 번이라도 올라갔다면 파일에서 지운 것과 별개로 그 키를 새로 발급받았는가
• 배포 서버가 꺼지지 않았고, 다른 기기에서 실행 방법이 그대로 따라지는가
• 대표 프로젝트 개수와 형식이 공고 조건에 맞는가(조건이 없으면 2~3개를 기준으로)
• 팀 프로젝트마다 내가 맡은 부분이 표시돼 있는가

PDF로 낼 때는 파일 용량도 봐야 해요. 채용 사이트 중에는 첨부를 파일당 5MB로 받는 곳이 있어서, 프리터뷰 포트폴리오 점검 결과 아래의 제출 전 점검은 주소 응답, PDF 쪽수, 원본 용량 세 줄을 보여 주고 5MB를 넘으면 주의로 표시해요.

혼자 보면 설명이 비어 있는 자리가 잘 안 보입니다. 프리터뷰 포트폴리오 점검은 가입하면 자소서 첨삭과 합쳐 하루 1회 무료이고, PDF·이미지·링크·텍스트 중 편한 방식으로 넣으면 점수와 보완할 곳을 알려 줘요. 무료 결과에서는 개선안 1개를 자세히 볼 수 있고 나머지는 제목만 보입니다. 이용 조건은 요금·이용 조건에서 확인하세요. 사람에게 첨삭받는 경로는 포트폴리오 첨삭·피드백 받는 법에 정리했어요.