이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
자료구조와 알고리즘을 활용한 경험은 수업 프로젝트에서 게임 내 NPC 길 찾기를 A 알고리즘으로 구현한 것입니다. 그리드 맵에서 장애물을 피해 목적지에 도달하는 경로를 Priority Queue를 활용해 최적화했습니다. 처음에는 BFS로 구현했지만 휴리스틱 비용 추가 없이 모든 방향을 탐색해 성능이 낮아서 A로 전환했습니다. 이 경험에서 같은 문제도 어떤 자료구조를 선택하느냐에 따라 성능 차이가 크다는 것을 실감했습니다.
정렬 알고리즘은 랭킹 보드 구현에서, 해시맵은 퀘스트 상태 저장에서 자주 활용했습니다. 알고리즘은 게임에서 직접 성능 차이를 체감하며 배우는 것이 가장 기억에 남습니다.
게임 내 인벤토리 시스템을 만들면서 아이템 검색에 List를 쓰다가 성능 문제를 겪은 경험이 있습니다. 아이템이 수십 개일 때는 괜찮았는데, 수백 개로 늘어나자 특정 아이템을 찾는 작업이 눈에 띄게 느려졌습니다. List에서 조건으로 찾는 것이 O(n) 탐색이라는 걸 그때야 의식했습니다. 아이템 ID를 키로 하는 Dictionary로 교체하자 탐색이 O(1)에 가까워졌고, 인벤토리 상호작용 응답이 빨라졌습니다. 처음부터 사용 패턴을 생각하지 않고 편한 자료구조를 선택한 것이 원인이었습니다.
자료구조는 어떤 연산이 얼마나 자주 일어나는지를 기준으로 골라야 나중에 교체 비용을 줄일 수 있다는 걸 그 경험이 알려줬습니다. 지금은 컬렉션을 선택할 때 조회·삽입·삭제 중 어떤 연산이 주된 사용 패턴인지를 먼저 생각합니다. 사용 패턴을 먼저 생각하면 자료구조 선택이 설계가 된다는 걸 그 경험이 알려줬습니다.
게임 개발 외에 웹 서비스 API를 만들 때도 자료구조 선택이 중요하다는 걸 경험한 적이 있습니다. 서버에서 게임 랭킹 상위 100명을 반환하는 API를 만들었는데, 처음엔 매 요청마다 정렬하는 방식이었습니다. 요청이 많아지자 정렬 비용이 쌓이는 문제가 생겼고, Redis의 Sorted Set을 써서 점수 업데이트마다 자동 정렬 상태를 유지하는 구조로 바꿨습니다. 자료구조 교재에서 봤던 우선순위 큐 개념이 실제 시스템에서 다른 이름으로 사용되고 있다는 걸 그때 연결해서 봤습니다. 같은 원리의 자료구조가 언어나 플랫폼마다 다른 이름과 API로 제공된다는 것도 배웠습니다.
개념을 알면 낯선 도구도 어떤 역할을 하는지 빠르게 파악된다는 걸 그 경험이 알려줬습니다. 지금은 새 도구나 라이브러리를 볼 때 어떤 자료구조 개념을 구현한 것인지를 먼저 생각하는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.