기획이 바뀔 때마다 터지는 코드 – 유연한 구조 설계란?

 

“이거 하나만 고쳤을 뿐인데, 신나게 와르르 무너지는 하울의 움직이는 성”

가장 자주 터지는 사고 유형 중 하나다.
처음 기획대로만 작동하도록 코드를 짜면, 기획이 바뀌는 순간부터 코드가 무너진다.
그래서 유연한 구조 설계는 필수다.
실제 프로젝트에서 자주 쓰이는 대응 방식들을 정리해본다.

---

1. 하드코딩 vs 데이터 드라이븐

• if(skillType == 1) 같이 숫자 박아놓은 코드는 기획이 바뀌면 전부 찾아 고쳐야 한다
• 실무에선 enum이나 string key를 쓰더라도 별도 데이터 테이블에서 조절 가능하게 만드는 게 기본
• 기획 변경 가능성이 있는 항목은 코드가 아니라 데이터에서 제어하게 한다

---

2. 조건식이 늘어나면 상태 머신으로 빼야 한다

• 상태가 많아지는 시스템(예: 보스 AI, 튜토리얼 조건, 퀘스트 트리거)은
  if 문 늘릴수록 관리가 어려워진다
• 유지보수가 필요한 조건 분기는 대부분 FSM, ScriptableObject, DSL 등 구조화한다

---

3. UI/인게임 연동은 이벤트 기반이 안전하다

• 실무에서 흔히 발생하는 문제: "체력이 줄었는데 HP바가 안 줄어요"
• 직접 호출 방식 대신 Observer/Event 시스템으로 데이터 변화에 반응하게 만들면
  구조가 유연해지고 문제 발생 지점을 좁힐 수 있다

---

4. 이펙트, 사운드, 리소스는 '연결 정보'만 코드에 둔다

• 코드에 PlaySound("LaserFire")를 직접 넣는 건 나중에 이름 바뀌면 다 깨진다는 뜻
• 데이터로 이름 연결하고, 코드에선 key만 넘기는 구조로 설계해야 리소스 변경에 강해진다

---

정리하며

유연한 구조는 개발자를 위한 게 아니라, 게임 전체가 무너지지 않기 위한 안전장치다. (+ 야근방지)
기획이 바뀔 수밖에 없는 구조라면 (어떤 상황이든 기획은 반드시 바뀌긴 하지만..), 코드도 바뀌지 않도록 짜야 한다.
실무에서 버그 안 나는 코드는 대개 '안정성'이 아니라 '분리'에서 나온다.