이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
효율적인 데이터 구조 설계에서 제가 가장 중요하게 생각하는 요소는 접근 패턴입니다. 어떤 데이터를 어떤 방식으로, 얼마나 자주 읽고 쓰는지를 먼저 파악해야 적합한 구조가 보입니다. 구조를 먼저 선택하고 나중에 사용 패턴을 맞추려 하면 불필요한 변환이 늘어납니다.
게임 서버 구조를 학습할 때, 읽기가 압도적으로 많은 데이터와 쓰기가 잦은 데이터를 같은 테이블에 넣으면 어느 쪽이든 성능이 나빠진다는 것을 배웠습니다. 읽기 최적화와 쓰기 최적화는 방향이 다르기 때문에, 그 둘을 나누는 것이 설계의 출발점이었습니다.
다만 모든 최적화에는 트레이드오프가 있습니다. 조회 속도를 위해 데이터를 분산하면 일관성 유지가 복잡해집니다. 한 결을 살리면 다른 결이 줄어든다는 것을 의식하면서 설계하는 것이 중요하고, 어느 쪽 비용이 더 큰지를 기준으로 구조를 선택하는 방식을 씁니다.
데이터 구조 설계에서 이론보다 직접 개선해본 경험이 판단 기준을 만들어줍니다. 학교 프로젝트에서 인벤토리 시스템을 처음 만들 때 아이템 정보를 Dictionary<string, Item>으로 설계했습니다. 초기에는 잘 작동했는데, 아이템 종류가 늘어나면서 특정 카테고리 아이템만 필터링할 때마다 전체 순회가 발생해 처리 속도가 떨어졌습니다. 읽기 패턴을 먼저 분석하지 않고 구조를 잡았던 것이 문제였습니다.
카테고리별 `List`와 전체 `Dictionary`를 병렬로 유지하는 구조로 바꾼 뒤 필터링 속도가 개선됐습니다. 메모리는 조금 더 썼지만 읽기 빈도가 높은 경로를 최적화하는 것이 더 중요하다는 판단이었습니다. 그 경험에서 접근 패턴을 먼저 분석하는 것이 구조 설계의 출발이라는 기준이 생겼습니다.
직접 고친 경험이 추상적인 원칙보다 더 오래 남는 기준이 됩니다.
효율적인 데이터 구조를 고를 때 그 데이터가 읽히는 빈도와 쓰여지는 빈도를 먼저 파악하는 것이 중요합니다. 학교 프로젝트에서 적 스폰 데이터를 어떤 구조로 저장할지 고민할 때, 읽기가 압도적으로 많고 쓰기는 게임 로드 시에만 발생한다는 걸 먼저 확인했습니다. 그 패턴이라면 읽기 속도에 최적화된 구조가 맞고, 쓰기 유연성은 덜 중요합니다.
읽기 위주 데이터는 배열이나 정렬된 구조가 유리하다는 판단으로 ScriptableObject 배열로 설계했습니다. 구조를 먼저 정하는 게 아니라 사용 패턴을 먼저 파악하는 것이 올바른 순서라고 생각합니다. 사용 패턴 없이 구조를 고르면 나중에 리팩토링 비용이 생깁니다.
어떻게 쓰일 것인가가 무엇으로 저장할 것인가를 결정합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 에이메드 게임 기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.