20강. 최종 실습: 개인 프로젝트 생산성 워크플로 완성하기

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

각 도구를 따로 알아도 실제 작업 순서가 없으면 필요할 때 빠뜨립니다. 프로젝트 시작부터 기능 완료, 오류 조사, 커밋 전 확인까지 반복 가능한 최소 워크플로를 완성합니다.

✓2. 학습 목표

✓최종 실습을 마치면

• 한 프로젝트의 실행·검증·작업 기록을 다른 사람이 따라 할 수 있게 정리합니다.
• Formatter 또는 Linter, 디버거 또는 구조화 로그를 실제 문제에 적용합니다.
• 작은 작업, 테스트, 커밋 전 검사와 AI 검증을 하나의 흐름으로 연결합니다.

◇3. 핵심 개념

최소 워크플로는 도구 개수가 아니라 반복 가능한 입구와 완료 기준으로 평가합니다.

1. README로 환경과 실행법을 확인합니다.
2. 작업을 작은 결과로 나누고 하나만 진행합니다.
3. Formatter·Linter로 기계적인 실수 후보를 줄입니다.
4. Debugger·로그로 원인을 좁히고 재현 기록을 남깁니다.
5. 자동 테스트와 수동 체크리스트로 결과를 확인합니다.
6. diff, 민감 정보, 불필요 파일, 문서를 확인한 뒤 완료합니다.

✎4. 단계별 실습

4-1. 적용할 프로젝트와 기준 기록

웹, Python, Java, Unity, Unreal 중 실제로 실행 가능한 프로젝트 하나를 고릅니다.

Markdown · 파일 경로: docs/workflow/environment.md

docs/workflow/environment.md

# 개발 환경 기록
- 기록일:
- 프로젝트 절대 경로:
- OS:
- 필요한 도구와 `--version` 결과:
- 프로젝트 실행 명령과 실행 위치:
- 기본 빌드·테스트 명령:
- 버전 확인에 사용한 공식 문서와 확인일:

4-2. Formatter 또는 Linter 적용

프로젝트에 이미 맞는 도구 하나를 고릅니다. 웹이라면 기존 Prettier·ESLint, Python이라면 기존 Ruff·Black, Java라면 기존 빌드 도구 플러그인처럼 현재 저장소에 있는 설정을 우선합니다. 새 도구가 필요하다면 별도 작업으로 검토하고 무조건 설치하지 않습니다.

Markdown · 파일 경로: docs/workflow/tool-result.md

docs/workflow/tool-result.md

# Formatter 또는 Linter 적용 결과
- 선택한 도구와 이유:
- 사용한 기존 설정 파일:
- 실행 명령과 위치:
- 적용 전 문제 1개:
- 적용 후 차이:
- 자동 수정하지 않고 사람이 판단한 항목:

4-3. 오류 재현과 원인 좁히기

실제 오류 하나를 고르거나 안전하게 잘못된 경로·설정 값을 만들어 실패시킵니다. Debugger의 중단점 또는 10강의 구조화 로그를 사용합니다.

Markdown · 파일 경로: docs/workflow/debug-record.md

docs/workflow/debug-record.md

# 오류 조사 기록
- 기대 결과 / 실제 결과:
- 최소 재현 절차:
- 첫 오류 메시지:
- 중단점 또는 로그로 확인한 값:
- 원인:
- 수정:
- 수정 후 검증:
- 제거하거나 마스킹한 민감 정보:

4-4. 기능과 테스트 계획

Markdown · 파일 경로: docs/workflow/final-checklist.md

docs/workflow/final-checklist.md

# 최종 워크플로 체크리스트

## 작은 기능
- [ ] 기능 1 — 완료 기준:
- [ ] 기능 2 — 완료 기준:
- [ ] 기능 3 — 완료 기준:

## 동작 테스트
- [ ] 일반 상황
- [ ] 잘못된 프로젝트 경로
- [ ] 누락된 파일·Inspector·모듈 참조
- [ ] 잘못된 설정 값
- [ ] 빠른 반복 실행 또는 연속 입력

## 커밋 전 확인
- [ ] 프로젝트 빌드 또는 실행 성공
- [ ] 자동 테스트와 수동 체크 통과
- [ ] 실제 토큰·비밀번호·개인정보 없음
- [ ] 로그·빌드 결과물·불필요 파일 없음
- [ ] README와 작업 기록이 현재 동작과 일치

## AI 도구 사용 시 검증
- [ ] 요청 밖 변경과 삭제가 없는지 diff 확인
- [ ] 패키지·API·버전을 공식 문서로 확인
- [ ] 생성 코드를 직접 읽고 오류·보안 경계 확인
- [ ] 빌드·테스트·수동 확인을 개발자가 실행

4-5. 전체 검사 실행

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

Get-Location
git status --short
git diff --check
git diff --stat
npm.cmd run check

예상 결과: 현재 위치와 변경 범위를 확인하고 공백 오류가 없으며 프로젝트 검사가 성공합니다. npm 프로젝트가 아니라면 README에 기록한 실제 Python·Java·Unity·Unreal 검증 명령으로 마지막 줄을 바꿉니다. 관리자 권한은 필요하지 않습니다.

4-6. 다음 프로젝트에 적용

Markdown · 파일 경로: docs/workflow/next-projects.md

docs/workflow/next-projects.md

# 다음 적용 계획

## 웹 프로젝트
- Formatter·Linter·빌드 명령을 `check`로 묶고 반응형 수동 검사를 추가한다.

## 게임 프로젝트
- 에디터 참조 누락과 빠른 반복 생성 상황을 체크리스트에 넣고 로그를 상태 전환 중심으로 남긴다.

## 포트폴리오
- 실행·배포 URL, 사용 기술, 핵심 결정과 검증 결과를 README에 요약한다.

→5. 도구와 설정이 동작하는 이유

문서는 실행 조건을 고정하고, 작은 작업은 변경 범위를 줄이며, 포맷·정적 분석은 실행 전 후보를 찾습니다. 디버거와 로그는 원인을 관찰하고, 테스트는 수정 결과를 반복 확인합니다. 마지막 diff와 보안 점검은 저장소에 들어갈 실제 변경을 기준으로 실수를 한 번 더 막습니다.

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

!자주 하는 실수

• 도구를 많이 설치하면 생산적이라고 생각: 현재 문제를 줄이는 최소 도구만 선택합니다.
• 설정 파일을 통째로 복사: 기존 파일과 병합하고 프로젝트 버전을 확인합니다.
• 완료 기준 없이 기능을 계속 추가: 작은 기능 3개를 먼저 끝내고 후속 아이디어는 준비 목록으로 옮깁니다.
• 빌드 성공을 실제 사용 성공으로 착각: 정상·실패·경계·반복 상황을 수동으로도 확인합니다.
• AI가 만들었으니 검토를 생략: 생성 코드의 실행·검토·테스트 책임은 개발자에게 있습니다.

✎7. 직접 실습

✎직접 실습

위 여섯 단계를 실제 개인 프로젝트 하나에 적용하세요. docs/workflow/의 네 기록과 README를 완성하고, Formatter 또는 Linter 전후 차이, Debugger 또는 구조화 로그를 사용한 오류 조사, 5가지 테스트 상황, 3개 이상의 작은 기능, 커밋 전·AI 검증표를 모두 증거와 함께 제출합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 생산성 워크플로의 품질을 설치한 도구 수로 판단하면 안 되는 이유는 무엇인가요?
2. Formatter·Linter, Debugger·로그, 테스트는 각각 어떤 단계의 위험을 줄이나요?
3. 웹·게임·포트폴리오에 같은 워크플로를 적용할 때 달라져야 하는 검증 항목은 무엇인가요?

■9. 핵심 요약

■핵심 요약

완성된 워크플로는 환경 기록, 작은 작업, 자동 규칙, 원인 조사, 테스트, 커밋 전 검증을 하나로 연결합니다. 도구는 실수와 반복, 문맥 전환을 줄이지만 최종 판단과 검증 책임은 개발자에게 있습니다.