[2025_12_01]기획 문서의 해석

기획 문서 해석과 커뮤니케이션

1. 배경

이번에 처음으로 기획자와 기획 문서를 가지고 협업하게 되었다.

우선 기획 문서를 보면서 내가 맡은 부분(유닛/전투/유닛 UI)에 대해 데이터 관리 방법과 설계를 고민하였고, 그걸 기반으로 코드를 작성하기 시작했다.

처음에는 "이 정도면 충분하겠지"라고 생각했지만, 막상 설계 및 코딩을 하면서 자의적으로 해석할 수 있는 부분과 기획자와 반드시 상의해야 하는 부분이 생겼다.

2. 상황 정리

1. 기획서에 명시되지 않은 데이터 - 감지 범위

상황: 기획 문서에는 유닛의 공격 범위(사거리)만 데이터 테이블에 있었고, 감지(탐지) 범위는 명시되어 있지 않았다.

 

고민

• 적을 탐지하는 범위가 사거리와 같아야 하나?
• 더 넓어야 하나?
• 임의로 정해도 될까?

결정: 이건 게임 밸런스와 직결되는 부분이라고 판단했다. 자의적으로 판단하기보단 당연히 기획자와 상의해야 한다고 생각해서 기획자와 상의하여 감지 범위를 10으로 정했다.

csharp

Collider2D[] hits = Physics2D.OverlapCircleAll(
    transform.position,
    10f,  // 감지 범위
    enemyLayer
);

배운 점:

• 기획서에 없는 수치 = 기획자의 의도를 물어봐야 함
• 특히 밸런스 관련 수치는 함부로 정하면 안 됨

---

2. 발견한 문제점 → 적극적인 제안

상황: 처음에 유닛 사거리를 유닛의 크기를 고려해 +1을 했다. 그런데 실제 배치 상 유닛의 크기는 0.5f였다.

 

고민

• 이미 구현했는데 바꿔야 하나?
• 기획자가 의도한 게 맞을 수도?
• 그냥 넘어가도 될까?

결정: 문제를 발견했으면 적극적으로 제안해야 한다고 생각했다. 기획자분께 "실제 사거리를 0.5로 하여 구현하는 게 어떨까요?"라는 의견을 제시했고, 기획자분께서 수락하셨다.

 

 

csharp

// Before
float effectiveRange = unit.Data.AttackRange + 1f;

// After  
float effectiveRange = unit.Data.AttackRange + 0.5f;

배운 점:

• 구현 중 발견한 실제 수치 불일치는 빠르게 공유
• "이미 구현했으니 그냥 둬야지" X
• "더 나은 방법을 제안하자" O
• 기획자도 모든 걸 예측할 수는 없음 - 상호 보완적 관계

---

3. UX 개선 아이디어 - 자의적 구현 후 확인

상황:유닛 생성 방식은 기획서에 명시되지 않았다. 스폰 포인트 정 중앙에서 생성되는 것보다 스폰 포인트의 일정 범위 안에서 랜덤하게 생성되는 게 더 자연스러울 것 같다고 생각했다.

 

고민:

• 이건 기획 의도를 바꾸는 건가?
• 먼저 물어봐야 하나?
• 일단 만들어보고 보여드릴까?

결정:시각적 UX 개선은 말로 설명하는 것보다 보여주는 게 빠르다고 판단했다. 자의적으로 판단 후 구현한 뒤 기획자분께 보여드리고 확인을 받았다.

 

 

csharp

Vector3 offset = new Vector3(
    Random.Range(-0.5f, 0.5f),
    Random.Range(-0.3f, 0.3f),
    0
);
Vector3 finalPosition = spawnPosition + offset;

 

배운 점:

• 시각적/UX 개선은 말보다 프로토타입이 효과적
• "이렇게 하면 어떨까요?" < "이렇게 해봤는데 어떤가요?"
• 빠른 프로토타이핑 → 피드백 → 반영 사이클

---

 판단 기준 

이번 협업에서 세운 나만의 기준:

기획자와  상의

1. 기획서에 명시되지 않은 수치
   • 감지 범위, 쿨타임 등
   • 밸런스에 영향을 주는 값
2. 기획 의도가 불명확한 부분
   • "시간차를 두고" → 구체적으로 몇 초?
   • "일정 범위" → 얼마나?
3. 게임 플레이 변화를 주는 로직
   • 유닛 생성 방식 변경
   • 전투 시스템의 핵심 로직

1.  

 능동적 제안 가능

1. 구현 중 발견한 수치 문제
   • 사거리 +1 → +0.5 제안
2. 더 나은 UX 개선안
   • 스폰 위치 랜덤화
3. 확장성/유지보수 고려
   • Inspector 설정값 추가
   • 데이터 테이블 구조 개선

---

배운 점

1. 기획서는 "완벽한 설명서"가 아니다

• 기획서에 모든 게 명시될 수 없음
• 구현하면서 빈 공간을 메우는 게 프로그래머의 역할
• 단, 혼자 판단하지 말고 소통하자

2. 질문하는 것도 능력이다

나쁜 질문: "이거 어떻게 해요?"
좋은 질문: "A와 B 중 어떤 게 의도에 맞나요?"

3. 프로토타입의 힘

• 말로 설명 < 실제로 보여주기
• "이렇게 하면 어떨까요?" < "이렇게 해봤어요"
• 빠르게 만들어서 빠르게 피드백받기

4. 기획자도 개발자의 의견이 필요할 수 도 있다.

• 기획자가 모든 기술적 세부사항을 알 수 없음
• "유닛 크기 0.5f라서 사거리 조정이 필요해요" 같은 정보
• 상호 보완적 관계

5. 애매하면 일단 물어보자

• 혼자 고민하는 시간 > 물어보고 확인받는 시간
• 잘못 구현해서 다시 만드는 것보다 미리 확인하는 게 빠름
• 소통 비용 < 재작업 비용

 

---

협업 프로세스

1. 기획서 분석

• 데이터 구조 설계
• 애매한 부분 리스트업

2. 1차 질문 (명세되지 않은 수치)

• 기획자와 논의
• 답변 반영

3. 프로토타입 구현

• 구현 중 발견한 문제점 정리

4. 2차 소통 (개선 제안)

• 수치 조정 제안
• UX 개선안 시연
• 피드백 반영

5. 기획자 확인

• 최종 승인
• 다음 기능으로

---

 앞으로의 다짐

Do

• 애매한 부분은 빠르게 질문
• 구현 중 발견한 문제는 적극 제안
• 프로토타입으로 빠르게 검증
• 기획 의도를 존중하되, 더 나은 방법 제시

Don't

•  혼자 추측해서 구현
• 기획서에 없으니까 대충
• 발견한 문제를 혼자 안고 가기
• 이미 만들었으니까 그냥 두자

---

마무리

처음 기획자와 협업하면서 가장 크게 느낀 점은: 기획서는 완성본이 아니다

 

기획자의 의도를 이해하고, 기술적으로 구현 가능한 최선의 방법을 찾고, 더 나은 UX를 제안하는 것. 이게 프로그래머로서 협업하는 방식이구나 싶었다.

그리고 소통이 정말 중요하다는 것.

• 모르면 물어보기
• 문제 발견하면 공유하기
• 더 나은 방법 있으면 제안하기

이 세 가지만 잘 지켜도 협업이 훨씬 수월해진다는 걸 배웠다.

다음 기능 구현할 때는 이번 경험을 바탕으로 더 적극적으로 소통하면서 작업해봐야겠다!