게임 개발 초반 단계에서 직렬화나 서버 연동이 없고, 데이터 형식이 바뀔 가능성이 높기 때문에 Dictionary 대신 List를 쓴다.

1. 데이터 스키마가 안정되지 않은 상태

• 프리프로덕션 단계에서는 스프레드시트 구조가 자주 바뀜.

  (예: 열 이름, 순서, 키 필드 추가/삭제 등)

• Dictionary<TKey, TValue>를 쓰려면 고정된 키가 필요함.

  하지만 데이터가 실험적으로 바뀌면 Dictionary 키 설계가 계속 깨짐.

• 반면 List<T>는 단순히 순서대로 담는 형태라 구조 변경에 유연함.

• 즉, “데이터 모델이 굳기 전까지는 List로 유연하게 가져가는 게 낫다”는 판단.

2. 직렬화 및 로딩 로직이 단순해야 함

• 지금은 서버/DB 직렬화가 없는 상태니까,

  런타임에만 사용되는 단순 데이터 컨테이너로 충분함.

• List<T>는 Unity의 JsonUtility, ScriptableObject, Addressable 등에서

  직렬화 호환성이 가장 높고 단순하게 동작함.

• 반면 Dictionary는 기본 JsonUtility로 직렬화되지 않기 때문에,

  나중에 세이브/로드나 원격 캐싱 시스템을 붙이려면

  별도 변환 로직을 짜야 함. (→ 지금은 굳이 복잡하게 만들 이유 없음)

3. 현재 로직이 “데이터 테이블” 중심으로 동작하기 때문

• 구글 시트에서 데이터를 불러와서 리스트 형태로 보관하고,

  필요한 순간에 LINQ나 foreach로 검색하는 구조라면

  Dictionary보다 List가 더 직관적임.

• 예를 들어 다음 구조라면 자연스러움

  [Serializable]
  public class EnemyData {
      public int Id;
      public string Name;
      public float HP;
  }
  
  [Serializable]
  public class EnemyDataTable {
      public List<EnemyData> Enemies;
  }
  
  

• 추후 ID 기반 검색이 잦아지고, 데이터 구조가 고정되면

  그때 Dictionary<int, EnemyData>로 전환하면 됨.

  (이 시점에는 “정식 데이터 파이프라인”이 도입될 가능성이 높음)