이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
DBMS 사용 경험은 수업 웹 개발 과목에서 MySQL로 게임 유저 데이터와 랭킹 테이블을 설계한 것이 시작이었습니다. 정규화된 테이블 구조로 유저, 캐릭터, 아이템 데이터를 분리해 외래키로 연결하는 방식을 배웠습니다. JOIN 쿼리로 복잡한 데이터를 조합할 때 인덱스 유무가 성능에 큰 차이를 만든다는 것을 경험했습니다. MongoDB는 스키마 유연성이 높아 게임 로그처럼 구조가 다양한 데이터를 저장할 때 적합하다고 배웠습니다.
관계형 DB는 데이터 정합성이 중요할 때, 문서형 DB는 빠른 조회와 구조 변화가 잦을 때 선택하는 것이 일반적입니다. 두 방식의 특성을 이해하고 상황에 맞게 선택하는 것이 중요하다고 생각합니다.
초반에 MongoDB를 선택했다가 중반에 구조를 바꿔야 했던 경험이 있습니다.
빠르게 프로토타이핑하려고 스키마 없이 문서를 쌓았는데, 조회 조건이 복잡해질수록 쿼리가 길어지고 인덱스 설계가 애매해졌습니다. 여러 컬렉션을 조인해야 하는 상황이 생기자 코드가 급격히 복잡해졌고, 결국 관계형으로 전환하면서 초반 선택이 얼마나 뒤에 부담이 되는지 몸으로 알게 됐습니다. 전환 작업만 이틀을 쓴 경험이었습니다.
지금은 데이터 접근 패턴을 먼저 그려보고 저장소를 고릅니다. 쓰기가 많고 구조가 자주 바뀌면 문서형, 복잡한 조회와 정합성이 중요하면 관계형이 맞더라고요. 처음부터 완벽한 선택보다 전환 비용을 낮게 유지하는 구조가 더 중요하다는 걸 그때 배웠습니다.
MySQL과 MongoDB를 같은 프로젝트 안에서 함께 쓰는 구성을 처음 접했을 때는 어색했습니다.
사용자 계정처럼 정합성이 중요한 데이터는 MySQL로, 행동 로그나 이벤트 데이터는 MongoDB로 쪼개져 있었습니다. 처음엔 왜 두 개를 쓰는지 이해가 잘 안 됐는데, 각각의 접근 빈도와 수정 패턴이 다르다는 걸 파악하고 나서야 납득이 됐습니다. 로그는 항상 쓰고 드물게 읽고, 계정 데이터는 자주 읽고 드물게 바뀌는 방식이었습니다.
그 경험을 통해 저장소 선택이 기술 선호도보다 데이터 특성에 맞춰야 한다는 걸 배웠습니다. 어떤 데이터가 얼마나 자주 읽히고 어떻게 변하는가를 먼저 보면 도구 선택이 훨씬 자연스럽게 따라온다는 감각을 그때 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 게임 서버 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.