이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
MongoDB를 사용한 경험에서 가장 중요하게 생각한 것은 도큐먼트 구조 설계였습니다. 자주 함께 조회되는 데이터는 같은 도큐먼트에 포함시키고, 조인이 많이 발생하는 패턴은 관계형 DB를 검토하는 기준을 팀과 함께 정했습니다.
Elasticsearch는 전문 검색 기능이 필요한 경우에 도입했습니다. 역인덱스 구조 덕분에 수십만 개의 텍스트 도큐먼트에서도 밀리초 단위로 키워드 검색이 가능했고, 한국어 형태소 분석기를 추가해 조사가 포함된 검색어도 처리할 수 있었습니다.
NoSQL을 선택할 때 스키마 유연성이 장점이자 위험 요소라는 것을 경험했습니다. 필드가 자유롭게 추가되다 보니 어느 순간 동일한 의미의 필드가 여러 이름으로 존재하는 문제가 생겼고, 초기에 네이밍 규칙을 팀과 합의해두는 것이 중요하다는 것을 배웠습니다.
MongoDB를 사용한 프로젝트에서 데이터가 쌓이면서 특정 필터 조건 쿼리가 느려지는 문제를 경험했습니다. 실행 계획을 확인하니 인덱스가 없어 컬렉션 전체를 순차 조회하고 있었는데, 데이터가 늘어날수록 선형적으로 느려진다는 것을 직접 확인했습니다. 자주 사용하는 필터 조건에 인덱스를 추가하니 응답 시간이 줄었습니다. 이 과정에서 인덱스를 여러 필드에 추가하면 쓰기 성능이 낮아지는 트레이드오프가 있다는 것을 알게 됐습니다. 실제 사용 패턴을 분석해서 가장 자주 사용되는 쿼리에만 인덱스를 적용하는 방식으로 정리했습니다. MongoDB에서 성능 최적화는 인덱스를 많이 추가하는 것이 아니라 쿼리 패턴을 먼저 파악하고 그에 맞게 설계하는 것이라는 것을 이 경험에서 배웠습니다. 이후 새로운 쿼리 패턴이 생길 때마다 인덱스 영향도를 먼저 검토하는 습관을 갖게 됐습니다.
Elasticsearch를 도입하면서 한국어 텍스트 검색에서 예상과 다른 결과가 나오는 경험을 했습니다. 기본 분석기를 사용하면 한국어는 형태소로 분리되지 않아서 검색어와 유사한 표현이 포함된 문서가 나오지 않는 경우가 생겼습니다. 한국어 형태소 분석기를 적용하니 단어가 어간으로 분리돼서 유사한 표현도 검색이 가능해졌습니다. 한계는 텍스트 처리 방식을 변경하려면 기존 인덱스를 다시 생성해야 한다는 점이었습니다. 데이터가 쌓인 이후에 분석기를 교체하면 전체 재인덱싱 비용이 발생했고, 이를 사전에 고려하지 못했던 것이 아쉬웠습니다. Elasticsearch는 강력한 검색 기능을 제공하지만, 사용하는 언어와 검색 패턴에 맞는 분석기를 초기에 설계하지 않으면 나중에 변경 비용이 크다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.