그동안의 이야기

어느덧 네번째 회고록이다. Node.js 와 Express, Mongoose 를 사용해 만들었던 블로그에, 회원가입, 로그인, 코멘트 남기기, 회원/비회원 여부 비교 등을 수행하는 블로그로 업그레이드 시켰다. 앞서 만들었던 과제들보다, 슬슬 여유가 생기기 시작해서 이전에 배웠던 개념들을 다시 복습하고 다져나가는 시간을 가지고 있다.
배열을 다루는 데 쓰는 map과 reduce, filter는 본격적으로 사용할 일이 많이 나오는데 왜이리도 헷갈리는지. 계속해서 검색하고, 내 방식대로 정리해서 기록하고, 다시 코드에 작성해보는 작업을 반복하고 있다. 어느 순간 팟 하고 쓸 수 있겠거니, 하고 있다.

• 블로그 기능 업데이트
• 내가 한 주 동안 배운 것
• 느낀 것
• 내게 아쉬웠던 것

블로그 기능 업데이트

기존에는 사용자가 하나라고 가정하고 작성되었지만, 이제 여러 사용자가 접속해서 글을 쓸 수 있는 블로그 서비스 형태가 되었다. 따라서 기존에는 사용자id 같은 것을 고려하지 않았지만, 이제는 구분이 필요했다. 글 외에도 댓글 기능이 추가되어, 이제 관리해야하는 Collection은 세개가 되었다. article, user, comment 이렇게 세 개이다.

구성한 스키마는 아래와 같다.

// article Schema
const BlogSchema = mongoose.Schema(
    {
        title: String,
        content: String,
        authorId: String,
        articlePassword: String,
    },
);

// user Schema
const UserSchema = mongoose.Schema(
    {
        authorName: String,
        password: String,
    },
);

// comment Schema
const CommentSchema = mongoose.Schema(
    {
        articleId: String,
        authorId: String,
        commentContent: String,
    },
);

BlogSchema 구성 요소에 authorId를 두어, 게시글 목록을 조회할 때는 이 글을 누가썼는지를 UserSchema 에서 조회한다. CommentSchema에서도 동일한 방식으로, 이 댓글이 "어느 게시글에서 쓰였는지" 와 "누가 썼는지"의 정보를 갖고 있는다.

게시글이 삭제되면, 부모 잃은 댓글들은 어디로 가나요?

이 부분에서 가장 고민했던 지점은 그것이었다. 게시글이 지워지면 그 게시글에 연결되어 있던 댓글 정보도 모두 쓸모없는 값이 되어서 지워야 하나?

그런데 이건 가만 생각해보니, 네이버 카페에서의 사용자별 댓글 모아보기를 할 경우의 방식을 생각해보았다.

위는 내가 실제로 네이버 카페 중고나라에서, 내가 쓴 댓글보기 페이지로 접근했을 때 보이는 페이지이다. 삭제된 게시글의 경우 (삭제된 게시글)로 표기되지만, 원본 글이 날아가도 내가 작성한 댓글 내용은 확인할 수 있다. 경우에 따라 원본 글이 날아가도 댓글은 확인해야할 필요가 있을 때 쓸모가 있을거라 생각하여, 글이 삭제되더라도 하위에 연결되어있는 댓글은 삭제하지 않도록 설정했다.

현재는 그런 지점을 잘 고민하여 잘 동작하고 있고, jwt 를 사용해 로그인 한 사용자만 접근할 수 있는 부분을 걸러내어 비회원이 권한 밖의 동작을 수행할 수 없게 잘 막아두었다. 이전 회사에서 일할 때 사용자별 권한 설정에 대한 부분을 정말 지독하게 파고들었던 부분이 떠오르기도 했다..

내가 한 주 동안 배운 것

ORM/ODM 이란?

지난주 부터 사용하고 있는 Mongoose 의 경우 ODM(Object Document Mapping) 이다.

ORM은, Object Relational Mapping 으로, 관계형 데이터베이스의 데이터를 자동으로 객체에 매핑해주는 역할을 한다. ORM의 R은 사실상 RDBMS를 의미한다면, ODM 의 D 는 결국 Document로 noSQL 계열의 데이터베이스를 의미한다고 할 수 있겠다. 실제로도 그렇게 동작한다.

사설이지만, 1주차때 파이썬으로 프로젝트를 수행할 때 MongoDB에 직접 쿼리를 날려가며 작성하다가 Mongoose를 처음 썼을때 매우 충격이었다. 이렇게도 불러와서 쓸 수 있어? NoSQL인데 RDBMS처럼 입력받는 자료형을 정할수도 있네? 사실은, 쿼리를 날려도 동일하게 수행할 수 있지만 좀 더 읽기 편하게 해준다는 장점에 근 3주간 편리하게 코드를 작성할 수 있게 되었다.

두 개의 장/단점은 아래와 같다.

• 장점
  • 객체 지향형 코드를 사용하여 직관적으로 이해할 수 있음
  • ORM/ODM 을 통해 작성한 객체를 재활용할 수 있어, 재사용 및 유지보수 편의성 증대
• 단점
  • 구현을 잘못할 경우 성능 저하 발생
  • 복잡한 쿼리를 수행해야 하는 경우, 각 데이터베이스의 Query 형태로 사용하는 것이 좀 더 효율적이고 속도가 빠를 수 있음.

noSQL vs. SQL

noSQL과 SQL 의 비교에 앞서 데이터베이스가 무엇인지 알아보아야 한다.

Databse란?

대량의 정보를 컴퓨터가 효율적으로 접근할 수 있도록 가공하고, 저장한 것.

DBMS란?
다수의 사용자들이 데이터베이스 내의 데이터를 접근할 수 있도록 하는 소프트웨어 도구의 집합

RDBMS란? (SQL)

Relational Database Management System의 약자로, 데이터를 테이블에 나누어 담고 테이블 간 관계를 정의하여 사용하는 형식의 데이터베이스.
테이블 간 관계를 정의하는 부분에서, 불필요한 테이블 생성과 관계 정의 과정이 발생할 수 있고, 데이터 저장 형태를 자주 바꿀 필요가 있을 경우 유연하게 대처하기 어렵다.

noSQL이란?

non-SQL, 또는 non-relational SQL을 의미한다. RDBMS와 달리, noSQL은 데이터를 테이블에 쪼개 담지 않고 도큐먼트 안에 JSON 형식으로 다루어 수평적인 데이터 구조를 지향한다.

관계형 데이터베이스에서는 수평 확장이 어렵다는 단점을 극복할 수 있는 데이터베이스이기도 하여서 '더 유연한' 구조를 가지고 있다고 본다.

빠르게 개발 환경을 바꿔야 하는 스타트업이나, 대용량 데이터를 다루는 문서, 키-밸류, 그래프, 인-메모리, 검색 등에 용이하다.

느낀 것

구현을 거의 생각한대로 모두 구현해낼 수 있어서 기뻤다. 다만, 깃헙쪽에 제약사항으로 분류해둔 사항이 몇 개 있어서, 다음 주차를 진행하며 시간이 남으면 코드의 주석을 정리하고 에러 처리부분을 일원화 하며 처리해볼 수 있을 경우 추가해볼 예정이다.

내게 아쉬웠던 것

내가 어렴풋이 아는 내용을 다른 분들에게 설명하려 할 때 여전히 많이 막히는 것을 느낀다. 완전히 내 것으로 소화한 것이 아니기 때문일테니, 계속해서 블로그나 깃헙에 읽고 쓰고, 코드 레벨에서 사용해보며 꾸준히 익혀야 할 것 같다.

참고 URL

Database - RDBMS & noSQL, ORM & ODM
SQL - DBMS와 SQL이란