NoSQL 데이터 모델링, 쿼리문, 서비스..

라용·2022년 10월 29일

위코드 - 스터디로그

목록 보기

93/100

위코드 기업 협업에 참여하며 배운 내용을 정리 & 회고 한 내용입니다.

기업협업 2주차 미션은 NoSQL 모델링이었다. how 가 아닌 what 의 관점으로 데이터베이스와 SQL, NoSQL 에 대한 공부를 했으니, 이제 how 를 해볼 차례였다. 이번 과제도 처음엔 자유롭게 how 에 대한 접근을 해보는 것이었는데, 여기서 또 나도 모르게 how 로 how 를 해버렸다. 이게 무슨 말인가 하면 데이터를 모델링할 생각을 하지 않고 인프런 파이어베이스 강의를 보고 따라 만들기만 해본 것이다. 강의 자체는 리액트와 파이어베이스를 다 해볼 수 있어서 너무 유용했지만, 한번 따라해본 것으로는 이해되지 않는 것이 많았고(이후 복습을 하겠지만..), 데이터 모델링에 대한 고민도 하지 않았다.
나는 NoSQL 데이터 모델링을 해볼 사이트로 '뭐하러 할까'라는 사이트를 골랐는데, 이 과정은 따로 포스팅하고 여기에는 NoSQL 데이터 모델링에 대해 멘토님께 들은 얘기들을 정리해볼까 한다. (정리하면서 조금 이상해졌을 수 있음)

SQL, NoSQL

이 두가지를 다시 정리해보면, SQL 은 S, 구조에 포커싱을 맞추고 있고, NoSQL 은 Q 에 포커싱을 맞춘다. 데이터 모델링의 기준은 결국 서비스라서 서비스 목적에 따라 어떤 식으로 데이터를 활용해야 하는지 보고 거기에 맞는 데이터 베이스를 구축해야 한다. 안정적인 구조가 먼저일지, 쿼리를 통한 사용성 테스트가 우선인지.. NoSQL 은 쿼리가 우선이다. 서비스를 분석하고 DB 구조를 짜는 게 아니라 쿼리문을 먼저 짠다. 그리고 나서 쿼리문에 최적화된 구조를 짠다. 아무튼 서비스를 파악하고 어떤 데이터베이스가 적합할지 선택하는 것은 회사차원에서도 매우 중요한 문제다. 그 선택에 따라 인력 구성이 달라질 수 있다. 그렇기 때문에 그 선택의 기준, 논리, 근거가 중요하다. 우리의 서비스와 그 상황과 전체 맥락에서 어떤 데이터베이스를 선택할 것인지..

NoSQL, 파이어베이스, 몽고디비..

보드마카를 정의하고 어떻게 쓸지 고민하는 게 SQL 이라면 쓸게 필요하다고 생각하고 보드마카, 펜등을 생각하는 게 NoSQL 이다. NoSQL 은 어떤게 필요해.. 라는 질문이나 요청등을 다 짜고 거기에 맞는 구조를 구성한다. 그래서 스키마가 필요 없다. 구조에서도 중복을 허용한다. 저장 효율보다 사용성을 먼저 증명해야 한다면 구조보다 쿼리를 먼저 생각하는 게 좋을 수 있다. 구조 설계를 다 했는데 시장의 반응이 없다면, 더 애매할 수 있으니까... 파이어베이스와 몽고디비 둘 다 NoSQL 이지만 문제의 해석이 다르다. 둘다 쿼리에 집중하지만 몽고디비는 그 중에서도 더 쿼리에 집중해서 구조 자체를 거의 없앴다. 컬렉션 데이터베이스의 뎁스가 하나다. 파이어베이스는 이와 다르게 어느정도 구조는 필요하다고 생각해 트리구조로 데이터를 구조화할 수 있다. 몽고디비를 사용하면 당장 사용성 찾기는 더 쉬울 수 있지만 이후 구조화까지 고민한다면 파이어베이스를 선택할 수 있는 것이다.

쿼리문

NoSQL에서 쿼리문을 짜는 것은 서비스를 분석하는 것과 비슷하 맥락이다. 우리 서비스에 필요한 기능을 보고 거기에 어떤 쿼리가 필요한지, 어떤 변수들을 쓰는지를 정의한다. NoSQL 를 선택했다면 쿼리문에 9를 쓰고 구조화에 마지막 1을 쓰는 느낌이다. 효율은 쿼리에 있다. 서비스의 사용성이 중요하다. 연습을 하더라도 무엇부터 만들지 어떤 조건들이 필요할지 쿼리문을 다 짜두고, 최적화하는 작업을 진행한다. 이후 구조를 잡을 때도 효율이나 중복 제거에 포커스를 맞추기 보다는 최대한 빨리 열람할 수 있게 하는 것이 포인트다. 쿼리문을 짠다는 것이 딥한 기술적 개념은 아니다. 넷플릭스의 개인화된 리스트업이 필요해.. 하고 개인화를 어떻게 만들지 까지 들어가면 너무 딥하고.. 관심사를 열람할 때 어떤 기준으로 저장하니까. 이렇게 가져오겠다.. 정도를 짜는 것이 쿼리문을 짜는 것이다.

도메인 이해

도메인에 대한 정리를 따로 포스팅했지만 여기에도 간단히 남겨보면 , NoSQL 에서 도메인 지식을 이해한다는 건, 우리 서비스가 어떤 서비스인지 이해하는 것과 비슷하다. 이 서비스가 시장에서 어떤 역할을 하는지.. 타켓팅이 분명하지 않다면 도메인이 얕다고 볼 수 있다. 문제점을 발견했지만 시장성을 갖추지 않았을 수도 있다. 시장성을 찾았다면 거기에 맞게 기능이 달라질 것이다. 그런 확장성을 다 고려해 흔들림 없이 안전하게 가는 방식이 SQL 방식이라면, 그 시장이 아닐 수 있으니 후단을 너무 고민하지 않고 일단 가보는 것이 NoSQL 느낌이다. 아무튼 쿼리문을 짜려면 도메인 모델을 먼저 파악해야 한다.

개발 방식

코드는 어떤 일을 하던 전체 일의 20%를 넘기면 안된다고 한다. 모든 계획을 다 하고 마지막에 코드를 치는 게 좋다. 과정을 계속 생각하며 코드를 치는 것은 비효율적이다. 지금까지는 코드를 치는 행위, how 를 연습하기 위해 코드를 치는 행위를 많이 연습했을 수 있지만 현업에서 빠르게 개발을 하기 위해서는 문서상으로 계획을 상세하게 짠 후 코딩을 하는 게 좋다. 전체 흐름을 생각하며 사용할 쿼리와 이펙트, 대략적인 코드와 호출 타이밍등.. 그렇게 계획을 세워두고 코드를 그대로 짜면 되는 것이다. 이렇게 진행하면 나중에 왜 안되지 하는 경우가 별로 없다. 코딩은 구현하는 도구, 동작하는 도구로 쓰고 모든 동작의 생각은 나에게서 나오고, 그것을 문서화한다고 생각하면 된다. 개발자라면 더 세밀한 계획을 짜야 한다. 이런 계획으로 이런 시장 상황에서 이 기능으로 어떤 효과를 내고 어떤 것을 목표로 이런 기능을 구현하고 어떤 결과를 만들 것인지.. 그런 플로우가 중요하다. (기능명 / 기능의 정의 / 목표 / 타겟 / 문제 / 예시 / 시장 / as-is / to-be 등..)

서비스, 기능, 쿼리

기능의 피처의 개념이고 피쳐는 쿼리들을 조합해서 만든다. 어떤 기능은 퀴리가 아닐 수 있고, 쿼리에 어떤 부가 기능을 붙일 수 있다. 보통 서비스 - 기능 - 정리 - 데이터 .. 순으로 생각한다면, 서비스 - 기능 - 쿼리라고 할 수 있는 것들 - 데이터. .. 순으로 생각해야 쿼리문이 보인다. 미디엄이라는 블로그 사이트는 블로그를 어떻게 열람할까를 고민한 서비스다. 추천을 통해 보여주거나, 검색해서 찾은 것을 보여주거나, 북마크로 체크업한 것들을 보여주거나.. 이렇게 보면 세가지 방식의 쿼리가 있는 것이다. 추천 쿼리, 찾기 쿼리, 체크업 쿼리. 이런 식으로 도메인 모델을 파악하면 큰 쿼리 맥락을 생각해볼 수 있다. 쿼리 기준으로 살을 더 붙보면 이른 느낌이다. 추천은 조건, 관심사 클랩으로. 찾기는 검색 로직, 풀 텍스트 서치. 북마크는 내 정보 기준으로 북마크한 포스터이 데이터를 가지거나, 포스팅 글마다 북마크한 유저정보를 담거나.. 이런 식으로 쿼리를 짠다. 큰 쿼리 맥락은 서비스의 기둥 느낌이다. 인스타 같은 각종 sns 서비스도 비슷한 맥락이다. 친구 기준, 추천 기준, 검색 기반.. 단일 텀텐츠를 가지고 어떻게 즐길까를 고민한 결과로 쿼리를 만든다. 페북이나 인스타, 유튜브 등이 그렇다. (sns 전략) 네이버, 구글 검색엔진들은 어떻게 하면 최적화된 정보를 줄 것인가를 고민힌다. 최적화된 것을 어떤 쿼리문을 통해 만들 것인지. (로봇들이 www 의 모든 도메인을 돌며 크롤링하면 그렇게 취합한 모든 정보를 디비화한 것이 검색엔진, www 의 모든 콘텐츠를 검색으로 즐기라는 것) 잘하는 개발자들은 이런 맥락을 보고 무엇이 핵심인지 메인인지 중요한 쿼리인지 파악한다. 그것을 우선적으로 만든다.

이외에 찾아본 것들

NoSQL 데이터 모델링

NoSQL 을 이용한 구현은 데이터 모델링을 얼마나 잘했냐가 개발 성공 여부의 90% 차지. SQL 이 개체 기반으로 시작해 정규화를 통해 테이블을 설계하고 쿼리를 이용해 결과를 뽑는다면, NoSQL 은 쿼리 결과를 먼저 설계한 후 중복을 허용해 데이터를 저장하는 테이블 구조를 정의.
ㄴ데이터 모델링?
데이터 흐름을 도식화하는 과정. 조직의 정보 수집과 시스템을 정의하는 시각적 표현, 청사진을 생성하는 프로세스. 데이터 모델을 만들어 두면, 다양한 이해관계자들이 조직의 데이터에 대한 통일된 개념을 생성할 수 있음. 데이터 모델링을 통해 만든 데이터 모델은, 해당 비즈니스가 수집하는 데이터, 각 데이터 간의 관계, 데이터를 저장하고 분석하는 데 사용하는 방식등을 설명. 데이터 모델링은 데이터를 이해하고, 이 데이터를 저장 및 관리하기 위한 올바른 기술을 선택할 기회를 제공

도메인 모델 파악

쿼리문을 작성하기 전에 도메인 모델에 대한 이해를 먼저 해야 함. 어떤 데이터가 있는지, 데이터 개체 간의 관계는 어떻게 되는지를 파악해야 한다. 데이터 분석을 해야 한다. 해당 관점없이 바로 어플리케이션 관점으로 접근하면 저장할 데이터에 대한 명확한 이해 없이 모데링을 하므로 문제가 생길 수 있다. 간단한 블로그 시스템의 도메인 모델은, 사용자 ID 를 기반으로 블로그의 분류를 가진다. 분류별로 글을 작성할 수 있다. 글에 파일을 첨부할 수 있다. 댓글을 달 수 있다 등등