실습 과제와 포트폴리오 기초집LESSON 20

최종 실습: 제출·공개 가능한 프로젝트 포트폴리오 패키지 완성하기

난이도초급 프로젝트

예상 시간90분

선수지식1~19강 산출물

20강. 최종 실습: 제출·공개 가능한 프로젝트 포트폴리오 패키지 완성하기

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

문서와 화면 자료를 각각 만들었어도 링크가 끊기거나 실행 절차, 기여 범위와 보안 검사가 빠지면 공개 후보가 아닙니다. 기존 웹·Unity·Python·Java 프로젝트 하나의 자료를 최종 패키지로 통합하고 새 환경 관점에서 검증합니다.

2. 학습 목표

3. 핵심 개념

최종 패키지는 파일 수가 아니라 처음 보는 사람이 이해 → 실행 → 검증 → 기여 확인을 끊김 없이 수행하는 상태입니다. 공개는 “문제가 없음” 선언이 아니라 검증 범위와 알려진 한계를 명확히 제시하는 일입니다.

4. 단계별 실습

4-1. 패키지 구조 확정

문서 작업 · 산출물 위치: 선택 프로젝트 루트

최종 포트폴리오 패키지
project/
├─ README.md
├─ docs/
│  ├─ project-brief.md
│  ├─ requirements.md
│  ├─ architecture.md
│  ├─ decisions.md
│  ├─ run-guide.md
│  ├─ test-checklist.md
│  ├─ known-issues.md
│  ├─ contribution.md
│  ├─ third-party-assets.md
│  ├─ security-review.md
│  ├─ retrospective.md
│  └─ bugs/001-example.md
└─ media/
   ├─ 01-main-flow.png
   ├─ 02-feature.png 또는 .gif
   └─ 03-result.png

프로젝트 유형에 따라 game-portfolio.md, web-portfolio.md, code-tour.md 중 해당 문서를 README에서 연결합니다.

4-2. 소개와 요구사항 검토

문서 작업 · 산출물: docs/final-review.md

docs/final-review.md
# 최종 공개 검토

## 프로젝트 요약
- 한 줄 소개:
- 목표 사용자:
- 해결하려는 문제:
- 핵심 기능 3개:

## 요구사항
- [ ] 요구사항과 완료 기준이 최소 5개다.
- [ ] 각 기준에 테스트 또는 미디어 증거가 있다.
- [ ] 미완성 기능을 현재 기능처럼 표현하지 않았다.

## 패키지
- [ ] README에 환경·구조·설치·실행·테스트·알려진 문제가 있다.
- [ ] 핵심 미디어 3개 이상과 설명이 있다.
- [ ] 문제 하나의 재현·가설·수정·검증 기록이 있다.
- [ ] 회고에 배운 점·현재 한계·다음 개선이 있다.

4-3. 프로젝트 유형별 최종 검증

Unity Editor 작업: 게임을 선택했다면 시작, 플레이, 일시정지, 게임 오버와 재시작을 확인합니다. 핵심 루프·조작법·규칙·검증한 빌드 환경을 docs/game-portfolio.md에 기록합니다. Unity 버전과 플랫폼 정책은 실제 공개 전 공식 문서를 다시 확인합니다.

웹 브라우저 작업: 웹을 선택했다면 모바일 폭, 키보드 조작·접근성, 핵심 상호작용과 배포 링크를 새 창에서 확인합니다. 정적 사이트가 서버·로그인 없이 핵심 내용을 제공하는지 검사합니다.

코드 작업: Python·Java 프로그램을 선택했다면 핵심 클래스·모듈 책임과 입력 → 처리 → 출력 데이터 흐름을 docs/code-tour.md에 기록하고 정상·잘못된 입력을 실행합니다.

4-4. 최종 테스트

테스트 작업 · docs/test-checklist.md 필수 범주

docs/test-checklist.md 최종 항목
- [ ] 일반 사용에서 핵심 흐름이 완료된다.
- [ ] 빈 값·경계값 또는 빈 상태가 안전하게 처리된다.
- [ ] 잘못된 입력 또는 설정의 원인을 알 수 있다.
- [ ] 핵심 동작을 빠르게 반복해도 중복·멈춤이 없다.
- [ ] 프로젝트에 맞는 긴 실행 시간 동안 진행 불가 오류가 없다.
- [ ] 새 실행 또는 재시작 뒤 초기 상태가 정상이다.

모든 항목에 실제 조건과 결과를 적습니다. 실패 항목은 버그 또는 알려진 문제로 연결합니다.

4-5. 공개 안전과 링크 검사

PowerShell · 실행 위치: 프로젝트 루트

git status --short
git ls-files
rg -n -i "api[_-]?key|password|secret|token|private[_-]?key" .
rg -n "[A-Z]:\\\\Users\\\\|C:/Users/" README.md docs media

검색 결과의 문맥을 직접 검토합니다. 실제 비밀을 발견하면 공개하지 말고 먼저 폐기·재발급합니다. 스크린샷의 사용자명·절대 경로·알림도 눈으로 확인합니다.

문서 작업 · docs/final-review.md에 추가

docs/final-review.md 공개 전 점검
## 공개 전 점검
- [ ] 개인·팀 기여를 구분했다.
- [ ] 외부 코드·에셋·폰트·이미지의 출처와 조건을 기록했다.
- [ ] 민감 정보, 실제 사용자 데이터와 비공개 경로가 없다.
- [ ] 불필요한 빌드 파일과 깨진 상대 링크가 없다.
- [ ] 공개 URL은 로그인하지 않은 새 창에서도 열린다.
- [ ] 알려진 문제와 우회 방법을 숨기지 않았다.

## 공개 판단
- 상태: 공개 가능 / 수정 후 공개 / 비공개 유지
- 검증한 범위:
- 남은 한계:
- 다음 개선 3개:

4-6. 포트폴리오 소개 완성

문서 작업 · README에 넣을 요약

README.md 포트폴리오 요약
## 프로젝트에서 맡은 일
- 핵심 책임과 실제 결과를 2~4개로 설명합니다.

## 기술적으로 해결한 문제
- 증상: 실제 관찰
- 원인 가설과 확인: 어떤 근거로 좁혔는지
- 수정: 최소 변경 내용
- 검증: 같은 재현 절차의 결과

## 현재 한계와 다음 단계
- 알려진 문제 링크와 우선순위 높은 개선 3개

팀 프로젝트라면 다른 구성원의 작업을 분리하고, 개인 프로젝트라도 외부 코드·에셋은 본인 작업으로 표시하지 않습니다. 취업 보장이나 검증하지 않은 사용자·성능 수치를 쓰지 않습니다.

최종 완료 기준: README, 프로젝트 소개, 요구사항 5개 이상, 실행 방법, 구조, 테스트, 알려진 문제, 문제 해결 기록, 미디어 3개 이상, 유형별 설명, 기여도, 출처·보안 점검과 회고가 모두 실제 파일·결과와 일치합니다.

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

최종 검토 문서는 개별 자료가 존재하는지만 보지 않고 서로 모순 없이 연결되는지 확인합니다. 실행·검증·기여·안전이 한 경로에 모여야 독자가 결과를 신뢰하고 작성자도 다음 개선을 판단할 수 있습니다.

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

7. 직접 실습

8. 이해 점검 질문 3개

9. 핵심 요약

MINI QUIZ