포트폴리오 프로젝트는 무엇을 만들어야 하나 — 개수보다 완결성

개수를 늘리면 생기는 문제

포트폴리오에 프로젝트를 여러 개 넣으면 강해 보일 것 같지만, 실제로는 반대 효과가 나기 쉽다.

• 하나당 들인 시간이 짧아 깊이가 없다
• 비슷한 구성이 반복되어 차별점이 안 보인다
• 미완성 상태가 섞이면 관리 능력에 의문이 생긴다

검토하는 쪽은 저장소를 전부 열어보지 않는다. 대개 상단 한두 개를 보고 판단한다. 그렇다면 그 한두 개가 완결돼 있는 편이 유리하다.

'완결'의 기준

무엇을 완결로 볼지가 모호하면 계속 미완성이 된다. 판정 가능한 기준:

| 항목 | 확인 방법 |

|---|---|

| 실행 가능 | 새 환경에서 README대로 따라 하면 뜬다 |

| 배포됨 | 접속 가능한 주소가 있다 |

| 문서화 | 무엇을 왜 만들었는지 읽힌다 |

| 관리 흔적 | 이슈·커밋에 개선 이력이 있다 |

| 마감 처리 | 에러 화면, 빈 상태, 로딩 처리가 있다 |

마지막 항목이 의외로 변별력이 크다. 정상 경로만 동작하는 프로젝트와 예외 상황까지 처리한 프로젝트는 완성도 차이가 뚜렷하다.

주제를 고르는 방법

1. 자기가 실제로 쓰는 것

사용자가 자신이면 요구사항이 명확하고, 계속 개선할 동기가 생긴다. 개선 이력이 쌓이는 프로젝트가 되기 쉽다.

2. 데이터가 있는 것

공공 데이터, API가 열린 서비스 등을 쓰면 화면만 있는 프로젝트에서 벗어난다. 데이터 처리·저장·조회의 실제 문제를 만나게 된다.

3. 완결 가능한 범위

"OO 같은 서비스"는 대개 완결되지 않는다. 기능을 하나로 좁힌 뒤, 그 하나를 끝까지 만드는 편이 낫다.

클론 코딩의 위치

학습 수단으로는 유효하다. 다만 포트폴리오 항목으로는 변별력이 낮다 — 같은 결과물이 많고, 설계 판단이 원본에서 온 것이라 판단 근거를 보여주지 못한다.

클론에서 시작하더라도 다음 중 하나를 붙이면 성격이 달라진다.

• 원본에 없는 기능을 추가하고 그 이유를 문서화
• 다른 기술 선택을 하고 비교 결과를 정리
• 성능·접근성 등 측정 가능한 개선을 수행하고 수치 제시

무엇을 문서로 남길 것인가

코드만으로는 판단 과정이 안 보인다. 남겨야 할 것:

```markdown

문제

어떤 불편에서 시작했는가

선택

어떤 방식을 골랐고, 무엇을 버렸는가

결과

무엇이 달라졌는가 (가능하면 수치)

한계

알고 있지만 처리하지 않은 것

```

마지막 '한계' 항목이 신뢰를 만든다. 문제를 인지하고 있다는 것 자체가 판단력의 근거가 된다.

정리할 때

오래된 미완성 저장소가 여러 개 있다면 다음 중 하나를 택한다.

• 완결시킨다 (위 기준 5개 충족)
• 비공개로 돌린다
• 아카이브 처리하고 README에 상태를 명시한다

방치된 저장소가 프로필 상단에 있으면, 완결된 프로젝트가 있어도 그쪽이 먼저 보인다.

최종 수정 2026-08-28