2강. 프로젝트 선택과 범위 정리: 지금 공개할 수 있는 작업 하나 고르기

?1. 이번 강의에서 해결할 문제

여러 미완성 프로젝트를 동시에 다듬으면 어느 것도 공개 가능한 상태가 되기 어렵습니다. 지금 실행할 수 있고 본인 역할을 증명할 수 있는 프로젝트 하나를 선택합니다.

✓2. 학습 목표

✓이번 강의를 마치면

• 후보를 실행 가능성·기여도·증거·범위로 비교합니다.
• 공개할 기능과 이번에 제외할 기능을 구분합니다.
• 한 프로젝트의 마감 범위를 한 문장으로 고정합니다.

◇3. 핵심 개념

좋은 첫 포트폴리오는 가장 큰 프로젝트보다 다른 환경에서 재현 가능하고 설명 가능한 프로젝트입니다. 기존 Unity 게임, 정적 웹, Python·Java 프로그램 중 핵심 흐름이 닫힌 결과물을 고릅니다.

선택은 취향 투표가 아니라 현재 증거를 비교하는 결정입니다. 후보마다 실행 가능, 내 기여를 파일·기능으로 설명 가능, 테스트·화면 증거 존재, 정리 기간 안에 완료 가능을 같은 기준으로 확인합니다.

최소 사례로, 기능은 많지만 실행되지 않는 팀 웹보다 시작→핵심 행동→결과→재시작이 검증되는 작은 게임이 첫 공개 후보에 더 적합할 수 있습니다. 목표는 새 기능 수가 아니라 현재 결과를 제3자가 확인하게 만드는 것입니다.

✎4. 단계별 실습

문서 작업 · 산출물: <PROJECT_ROOT>/docs/project-selection.md

시작 전 상태: 후보 2~3개의 실제 저장 위치, 마지막 실행 결과, 본인 담당 범위를 준비합니다. 실행하지 않은 기능을 추측해 가능으로 표시하지 않습니다.

docs/project-selection.md

# 프로젝트 선택 기록

| 후보 | 현재 실행 | 본인 기여 설명 | 테스트 증거 | 일주일 내 정리 | 선택 |
| --- | --- | --- | --- | --- | --- |
| 2D 택배 게임 | 가능 | 명확 | 일부 있음 | 가능 | O |
| 예전 팀 웹 | 불확실 | 일부만 | 없음 | 어려움 | X |

## 공개 범위
- 핵심 루프, 점수·실패, 재시작, 테스트 결과

## 이번에 제외
- 새 스테이지, 온라인 순위표, 광고, 대규모 리팩터링

## 범위 문장
기존 2D 택배 게임을 새 기능 없이 실행·검증·설명 가능한 포트폴리오로 정리한다.

Unity Editor 작업: 게임 후보라면 메인 Scene을 열어 시작부터 재시작까지 한 번 플레이합니다.

웹 브라우저 작업: 웹 후보라면 로컬에서 홈, 핵심 상호작용과 모바일 폭을 확인합니다.

코드 작업: Python·Java 후보라면 문서에 적힌 명령으로 대표 입력 한 건을 실행합니다. 이 단계에서 기능 코드는 고치지 않습니다.

완료 기준: 후보 2개 이상을 비교했으며 선택 프로젝트 하나, 공개 범위, 제외 범위와 마감 문장이 있습니다.

변경 전의 “게임을 더 완성한다”는 문장은 끝이 없습니다. 변경 후 범위 문장은 대상, 하지 않을 일, 검증 결과가 드러나므로 새로운 아이디어가 생겨도 제외 목록으로 보낼 수 있습니다. 선택한 뒤에는 대표 흐름을 한 번 더 실행해 표의 현재 실행 근거를 확인합니다.

§5. 작성 방식이 필요한 이유

선택표는 “조금만 더 만들자”는 범위 팽창을 막습니다. 공개 가능성이 낮은 이유도 남기므로 다음 포트폴리오 후보를 고칠 때 출발점이 됩니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 가장 큰 프로젝트를 자동 선택: 현재 재현 가능성을 먼저 평가합니다.
• 기능을 많이 추가함: 새 기능은 제외 목록에 옮기고 기존 흐름을 검증합니다.
• 팀 결과 전체를 본인 결과로 선택: 실제 맡은 부분을 독립적으로 설명할 수 있는지 확인합니다.
• 문제를 숨긴 채 선택: 실행 불가나 누락 참조를 표에 그대로 기록합니다.

✎7. 직접 실습

✎직접 실습

실습 목표

후보 2~3개를 같은 증거 기준으로 비교하고 한 프로젝트의 공개·제외 범위를 고정합니다.

시작 전 상태

각 후보의 저장소·프로젝트를 열 수 있는지 확인하고 현재 Git 상태를 기록합니다. 새 기능 구현은 아직 시작하지 않습니다.

1단계: 따라 하기

예시 표의 다섯 기준을 채웁니다. 가능만 쓰지 말고 실행 명령, 화면, 테스트 파일처럼 근거 위치를 한 줄 덧붙입니다.

2단계: 기준 바꿔 보기

처음 고른 후보에서 “일주일 내 정리”가 불가능하다고 가정해 제외 기능을 늘립니다. 그래도 핵심 흐름이 닫히는지 다시 판단합니다.

3단계: 직접 적용

후보 하나를 선택해 공개 범위 3개, 제외 범위 3개, 마감 문장 한 줄을 작성합니다. 팀 프로젝트라면 본인 담당 파일·기능도 별도로 적습니다.

4단계: 스스로 확인

• 선택 이유 2개와 제외 이유 2개에 근거가 있나요?
• 시작부터 결과까지 실제로 한 번 실행했나요?
• 새 기능 없이 공개 가능한 범위인가요?

막혔을 때

증상	확인·해결
모든 후보가 실행 불가	가장 복구 범위가 작은 후보를 고르고 복구 자체를 첫 완료 기준으로 둡니다.
범위가 계속 늘어남	핵심 사용자 흐름에 필요 없는 항목을 제외 목록으로 옮깁니다.
팀 기여가 모호함	커밋·담당 문서·구현 파일로 설명 가능한 부분만 본인 범위로 씁니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 기능이 20개지만 실행되지 않는 프로젝트와 기능 3개가 반복 검증되는 프로젝트 중 첫 포트폴리오로 무엇을 선택하며 왜인가요?
2. 새 온라인 순위표 아이디어가 생겼을 때 현재 마감 범위를 지키기 위해 어느 목록에 두고 무엇을 먼저 검증하나요?
3. 팀 프로젝트 전체를 자신의 결과처럼 보이지 않게 하려면 어떤 증거와 범위를 별도로 기록해야 하나요?

■9. 핵심 요약

■핵심 요약

지금 실행하고 본인 책임을 설명할 수 있는 프로젝트 하나를 고릅니다. 공개 범위와 제외 범위를 함께 고정해야 마무리에 집중할 수 있습니다.

§10. 다음 강의 연결

공개할 프로젝트와 하지 않을 일을 정했습니다. 다음 강의에서는 선택한 범위를 검증 가능한 요구사항과 완료 기준으로 바꿉니다.