예시 답변 1
약 100초
스키마 유연성 필요로 MongoDB 선택 + RDBMS 대비 비교 중심으로 푸는 결
졸업 프로젝트에서 사용자 행동 로그를 저장하는 모듈을 만들 때 를 선택했습니다. 처음에는 로 시작했는데, 사용자마다 행동 이벤트의 속성이 달라서 스키마를 미리 확정하기 어려운 상황이었습니다. 페이지 뷰는 url·머문 시간·디바이스 정보가 들어오고, 클릭 이벤트는 요소 id와 좌표가 따라붙는 식이었습니다. 매번 컬럼을 추가하거나 null을 허용하는 방식으로는 스키마가 금방 지저분해질 것 같았고, 이벤트 타입마다 구조가 다른 문서를 그대로 저장하는 게 낫다고 판단해 로 전환했습니다. 처리량은 하루 약 50만 건 수준이었는데, 인덱스를 user_id와 timestamp 복합 인덱스로 걸었더니 조회 속도에서 문제가 없었습니다. 아쉬운 점은, 나중에 이벤트 간 연관 분석이 필요해졌을 때 JOIN이 없어서 애플리케이션 레이어에서 처리해야 했다는 점이었습니다. 가 유연성에서는 좋았지만, 관계형 쿼리가 필요한 분석에는 맞지 않는 트레이드오프가 있다는 걸 직접 경험했습니다. 지금은 그 두 가지가 공존하는 구조를 초기 설계 단계에서 고려해야 한다고 봅니다.
이 결의 특징
이벤트 속성마다 스키마가 달라 컬럼이 지저분해지는 문제를 문서 저장 구조로 전환해 풀고, 하루 약 50만 건 처리량에서 JOIN 부재라는 트레이드오프까지 인정한 흔적이 있습니다.
이 결이 통하는 자리
유연성과 관계형 쿼리 제약을 둘 다 솔직하게 짚을 때 통합니다. 이벤트 간 연관 분석이 필요해졌을 때 애플리케이션 레이어에서 처리해야 했던 아쉬움이 보이면 균형 잡힌 시각이 읽히는 자리가 됩니다.