17강. 팀 프로젝트 기여도 정리: 맡은 역할과 협업 범위를 정확히 작성하기

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

팀 결과 전체를 “제가 만들었습니다”라고 쓰면 실제 역량과 협업 태도를 왜곡합니다. 본인 주도, 공동 작업과 다른 구성원의 작업을 정직하게 구분합니다.

✓2. 학습 목표

✓이번 강의를 마치면

• 역할명이 아니라 구체적인 책임과 결과를 씁니다.
• 본인 주도·공동·타인 작업을 표로 구분합니다.
• 기여 주장에 코드·문서·테스트 등 확인 가능한 근거를 연결합니다.

◇3. 핵심 개념

“프로그래머”는 역할명일 뿐 기여 범위가 아닙니다. 어떤 기능의 요구사항을 정하고, 어떤 코드를 작성·수정했으며, 누구와 어떤 경계를 맞췄는지 구체적으로 씁니다. 기여율을 임의의 퍼센트로 표현하기보다 책임 단위로 구분합니다.

✎4. 단계별 실습

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

docs/contribution.md

# 기여 범위

## 프로젝트 형태
- 개인 / 팀 프로젝트 중 실제 유형
- 기간과 인원: 공개 가능한 범위만 기록

## 책임별 기여
| 영역 | 본인 역할 | 협업 범위 | 결과·근거 |
| --- | --- | --- | --- |
| 핵심 규칙 | 설계·구현·테스트 주도 | 기획자와 완료 기준 합의 | 관련 파일·T-01 |
| UI 연결 | 이벤트 인터페이스 공동 설계 | UI 구현은 팀원 담당 | 인터페이스·통합 기록 |
| 아트 | 구현하지 않음 | 외부/팀 에셋 연결만 담당 | 출처 문서 |

## 협업 중 해결한 문제
- 상황:
- 내 행동:
- 함께 결정한 내용:
- 결과와 검증:

## 명확한 제외
- 팀원이 만든 모델·이미지·핵심 코드를 내 작업으로 표시하지 않는다.

코드 작업: 실제 커밋·파일·이슈 중 공개 가능한 근거만 상대 링크로 연결합니다. 비공개 저장소 주소나 내부 대화, 개인정보를 복사하지 않습니다.

완료 기준: 팀 프로젝트는 책임 3개 이상을 주도·공동·타인으로 구분합니다. 개인 프로젝트는 개인 프로젝트라고 쓰고 외부 코드·에셋의 기여를 출처 문서로 분리합니다.

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

정확한 기여 범위는 무엇을 혼자 할 수 있고 어떤 협업을 경험했는지 동시에 보여 줍니다. 공로를 과장하지 않아 팀원과 독자 모두에게 검증 가능한 설명이 됩니다.

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

!자주 하는 실수

• 팀 작업을 혼자 한 것처럼 씀: 책임별로 주도·공동·타인 작업을 구분합니다.
• 임의의 기여율만 제시: 구체적인 산출물과 결정으로 설명합니다.
• 커밋 수를 기여 품질로 단정: 문제, 책임과 결과를 함께 봅니다.
• 비공개 링크·대화를 증거로 공개: 공개 가능한 요약과 허용된 자료만 사용합니다.

✎7. 직접 실습

✎직접 실습

docs/contribution.md를 작성하세요. 완료 기준은 핵심 책임마다 본인 행동, 협업 경계, 결과와 공개 가능한 근거가 있고 타인의 작업을 명시적으로 구분한 것입니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 기여율 퍼센트보다 책임 단위가 더 유용한 이유는 무엇인가요?
2. 공동 설계와 직접 구현은 어떻게 구분해 쓸 수 있나요?
3. 비공개 저장소의 기여를 설명할 때 무엇을 공개하면 안 되나요?

■9. 핵심 요약

■핵심 요약

팀 포트폴리오는 본인 주도, 공동 작업과 타인의 기여를 책임 단위로 구분합니다. 구체적인 행동과 공개 가능한 근거로 설명하며 공로를 과장하지 않습니다.