이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
NoSQL 데이터베이스를 사용한 경험은 팀 프로젝트에서 사용자 활동 로그를 저장하는 데 MongoDB를 쓴 것입니다. 로그 데이터는 필드 구조가 자주 바뀌었는데, 스키마를 미리 정의해야 하는 관계형 DB에서는 유연하게 대응하기 어려웠습니다. MongoDB는 문서 단위로 저장해 필드를 자유롭게 추가할 수 있어 이 상황에 적합했습니다. 다만 JOIN이 없어서 여러 컬렉션 데이터를 합칠 때 복잡해지는 경우도 경험했습니다. 그때 데이터 모델링 방식이 RDB와 다르다는 것을 느꼈고, NoSQL에서는 쿼리 패턴에 맞게 데이터를 저장하는 것이 더 중요하다는 것을 배웠습니다. 인덱스 설정도 중요했는데, 자주 쿼리하는 필드에 인덱스를 안 걸면 데이터가 늘어날수록 속도가 급격히 느려졌습니다. 도구는 목적에 맞게 선택하는 것이 맞고, NoSQL이 항상 좋은 것은 아니라는 것도 배웠습니다.
NoSQL 활용에서 막힌 자리를 도움 받아 해결한 경험을 말씀드리겠습니다. MongoDB에서 여러 컬렉션의 데이터를 합쳐야 하는 자리가 생겼을 때 어떻게 해야 할지 몰라 막힌 자리가 있었습니다. JOIN이 없어서 기존 SQL 방식으로 접근하면 코드가 복잡해지는 자리가 됩니다. 팀원에게 물어봤더니 $lookup 연산자를 써서 두 컬렉션을 연결할 수 있다는 것을 알려줬습니다. 직접 써보니 데이터 양이 많을 때 $lookup이 느려지는 자리가 있었고, 이때 자주 같이 쓰는 데이터를 한 문서에 같이 저장하는 비정규화 방식이 NoSQL의 설계 철학이라는 걸 그때 이해했습니다.
RDB 방식으로 NoSQL을 쓰면 오히려 더 복잡해지는 자리가 생깁니다. 아직 부족한 건 대용량 데이터에서 인덱스 전략을 최적화하는 경험인데, 이 부분은 더 많은 실습이 필요한 자리입니다. 도움 받아 배운 $lookup과 비정규화가 NoSQL 설계 이해의 자리라는 걸 생각하고 있습니다.
NoSQL 활용 경험에서 배운 것을 다음에도 쓸 수 있게 정리한 자리가 있습니다. MongoDB를 처음 쓸 때 어떤 경우에 NoSQL이 적합하고 어떤 경우에 RDB가 더 나은지를 정리해뒀습니다. 스키마가 자주 바뀌거나 필드가 가변적인 데이터는 MongoDB, 관계가 복잡하고 데이터 정합성이 중요한 경우는 RDB가 적합한 자리라고 정리했습니다.
컬렉션 설계 원칙 — 자주 같이 조회하는 데이터는 한 문서에, 독립적으로 접근하는 데이터는 분리도 메모해뒀습니다. 이 기준 없이 새 프로젝트에서 NoSQL을 쓰면 초기 설계를 잘못 잡아 나중에 고치기 어려운 자리가 생깁니다. 아직 부족한 건 Redis나 Cassandra 같은 다른 NoSQL 유형을 직접 써보며 목적에 맞는 선택 기준을 넓히는 경험인데, 이 부분은 더 많은 실습이 필요한 자리입니다.
NoSQL 적합 기준 정리가 다음 설계의 출발 자리라는 걸 생각하고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 111퍼센트 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.