6강. 기술 선택 기록: Unity·웹·Python·Java 도구를 선택한 이유 쓰기

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

기술 스택 로고만 나열하면 왜 그 기술이 필요했고 어떤 대가가 있었는지 알 수 없습니다. 실제 문제와 제약을 기준으로 핵심 선택 두세 개를 기록합니다.

✓2. 학습 목표

✓이번 강의를 마치면

• 기술과 기술을 선택한 이유를 구분합니다.
• 선택 당시의 대안과 트레이드오프를 기록합니다.
• 프로젝트별 핵심 선택을 검증 결과와 연결합니다.

◇3. 핵심 개념

좋은 기술 결정 기록은 상황 → 선택 기준 → 대안 → 결정 → 결과와 한계 순서입니다. 지금은 더 좋은 도구가 있어 보여도 당시 목표와 시간, 팀 경험을 기준으로 평가해야 합니다.

✎4. 단계별 실습

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

docs/decisions.md

# 기술 결정 기록

## D-01 정적 배포 방식
- 상황: 로그인·서버 없이 프로젝트 소개를 공개해야 했다.
- 기준: 무료 정적 배포, 간단한 유지보수, 모바일 대응
- 대안: 직접 서버 운영, 정적 HTML/CSS/JavaScript
- 결정: 정적 파일과 GitHub Pages 사용
- 결과: 서버 관리 없이 공개 가능했다.
- 한계: 문의 폼의 실제 전송은 제공하지 않는다.

## D-02 데이터 분리
- 상황: 규칙 수치를 코드 수정 없이 조정해야 했다.
- 결정: Unity는 ScriptableObject, 웹은 별도 데이터 배열을 사용했다.
- 결과와 증거: 설정 변경 테스트 T-06 통과

프로젝트에 없는 도구를 억지로 추가하지 않습니다. Python이라면 표준 라이브러리와 외부 패키지 선택, Java라면 JDK·빌드 도구, Unity라면 ScriptableObject·이벤트 선택을 기록할 수 있습니다.

완료 기준: 결정 2개 이상에 상황, 대안, 선택, 결과와 한계가 모두 있습니다.

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

결정 기록은 기술 유행을 따라 쓴 목록이 아니라 제약 속에서 판단한 능력을 보여 줍니다. 한계까지 적으면 선택의 범위를 이해했다는 근거가 됩니다.

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

!자주 하는 실수

• “유명해서 선택”으로 끝냄: 프로젝트 제약과 연결된 기준을 씁니다.
• 대안을 뒤늦게 꾸며냄: 실제 검토했거나 현실적인 대안만 기록합니다.
• 모든 라이브러리를 나열: 결과에 영향을 준 선택 2~3개만 다룹니다.
• 한계를 숨김: 구현하지 않은 서버·저장·배포 기능을 명시합니다.

✎7. 직접 실습

✎직접 실습

docs/decisions.md에 핵심 결정 2개를 작성하세요. 완료 기준은 각 결정에 대안 하나, 선택 기준 두 개, 실제 결과와 한계가 있으며 프로젝트 코드 또는 테스트 위치를 가리키는 것입니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 기술 이름만 나열하면 판단 능력을 알기 어려운 이유는 무엇인가요?
2. 기술 결정에서 대안을 기록하는 목적은 무엇인가요?
3. 결과와 한계를 함께 쓰면 어떤 오해를 줄일 수 있나요?

■9. 핵심 요약

■핵심 요약

기술 선택은 상황, 기준, 대안, 결정, 결과와 한계로 설명합니다. 실제 프로젝트에 없던 기술을 추가하지 않고 핵심 판단만 증거와 연결합니다.