23, 19주차

18~19주차

두 주간 node.js 백엔드 API를 만들기 위해 필요한 지식을 쌓고, 강의를 들으며 과제를 하는 시간을 보냈다.

과정 중에서 배우고 경험한 내용을 몇가지 정리해 본다면...

 

 

1. ORM

ORM(Object-Relational Mapper)과 ODM(Object-Document Mapper)의 차이에 대해서는 이 글에서 정리했다. 둘 다 데이터베이스를 더 쉽게 사용하기 위한 프로그래밍 방법인데, 이번엔 ORM을 위해 Sequelize를 사용했고, ODM을 위해서 Mongoose를 사용했다. 

 

ORM이 없다면, DB에서 원하는 값을 얻기 위해, SQL문을 직접 작성해서 보내야 하는데, Document 방식의 NoSQL에서는 그나마 가능할 수 있겠다. 그러나 관계형 데이터베이스에서는 테이블을 조인하고, 찾고 하는 등의 SQL문을 다 직접 써줘야하는데 복잡한 경우나 새로운 상황을 생각했을 때 그때마다 SQL문을 작성해야 하는데 전문적인 지식이 필요할 수 있거나, 여러 상황에 맞게 대처하기 어려울 수도 있을 것이다.

 

그렇지만 ORM을 사용해서 개발을 하는 이유는 이런 쿼리문을 대신 써주기 위한 기능이 아니라는 것을 이번주차에 경험했다. 바로 ORM을 통해 만들어진 SQL문을 읽을 때 해석하기 난해한 수준이 아닌데, 그걸 만들기 위한 Sequelize 사용 시 오히려 간단한 쿼리를 복잡하게 구현해야 하는 상황을 겪었기 때문이다. 

 

이게 맞나... 싶은 생각에 검색해보고 물어보니, 실제로 날 쿼리로 작업을 하는 경우도 있고, ORM에 대한 호불호 또는 찬반에 대한 의견도 있다고 한다.

(Do we really need an ORM?, DB 쿼리 어떻게 하시나요?, ORM이냐 날쿼리냐 그것이 문제로다, Why do we need object relational mapping)

 

ORM을 사용하는 이유는 layered architecture에서, Persistent Layer를 추상화 하기 위해 사용한다. 즉, 애플리케이션에서 데이터베이스에 대한 의존성을 제거하거나 분리할 수 있다는 것. 추상화...는 자주 듣지만 추상적인 단어라 와닿지 않을 수 있지만 다시 정리하면, RDBMS가 바뀌더라도 원하는 도메인 모델이 잘 작동할 수 있게, 영향을 주지 않기 위함이라고 이해했다.

 

덧붙여 보안 관점에서도 맵핑 형태로 작성되있으면 SQL 주입 공격을 막을 수 있다. 왠만한 곳에서는 에 대한 대비가 당연히 되어 있겠지만...

 

2. noSQL

SQL이 싫어서 no SQL은 아니고, not only SQL이라고 한다. 그런데 설명을 보면 하나같이 RDBMS가 아닌 것으로 설명하니... noRDBMS라고 해야하는거 아닌가 싶다.

 

아무튼, 관계형 DB 특성 뿐만 아니라 다른 기능이 있다는 건데, Key Value DB, Document DB, Graph DB 같은 것들이 있다. 각각 장단점과 특성이 있고, 개략적으로 알아두고 도메인에 따라 속도와 적합성이 설명되고, 리소스가 허락한다면 사용할 수 있겠다. (잘 정리된 글)

 

 

3. SQL

SQL(Structured Query Language)는 언어다. 구조화된 조회 언어.

언어가 엄청 어렵지는 않아 보이는데 데이터베이스라는 한정된 영역이라 그런 것 같다.

 

키워드는 크게 세가지로 나눌 수 있다. 데이터를 정의하는 키워드(CREATE, ALTER, DROP 등), 그리고 데이터를 조작하는 키워드(SELECT, INSERT, UPDATE 등), 데이터를 제어하는 키워드(GRANT, REVOKE 등)가 있다. 

 

사용할 때에 유의사항으로는, 대소문자 무관, 세미콜론으로 명령이 끝나고, 고유값은 따옴표로 감싸주고, 객체는 백틱으로, 주석은 더블대쉬 -- 로, 여러줄 주석은 /* */로 처리하면 된다.

 

4. n-Tier, n-Layered Architecture

대체로 일은 전체 그림을 우선 소화하고, 그 다음 분할 정복(Divide and Conquer)해야 한다. 어떤 애플리케이션을 만든다고 하면, 기획된 애플리케이션을 구현할 때는 예상하는 상황에 따라 물리적인 Tier를 나누고, 논리적인 Laye를 나눠 개발해야 한다는 점을 배웠다. 

정답은 없으나, 효율적이고 스케일 변화와 리소스 한계를 감안해서 어느 선에서 결정해야 하고, 불확실한 상황이라면 리소스가 적게 들지만 나중에 개선할 수 있는 여지를 남겨주는 식의 결정을 해야 할 것.... 같은 당연한 소리를 구현하기 위한 개발 방법 또는 패턴에 대한 이야기다. 자세한 내용은 이 글에서 정리했다. 

 

5. Refresh, Access Token

사용자 인증과 인가는 잘 다뤄야 한다. 아무리 작은 서비스라도 소중할 수 있기 때문에. 토큰 방식의 사용자 인증 및 인가 방식이 유용한 지점이 많다. 보안은 결과적으로 사용자 경험과 반비례할 가능성이 높다고 생각한다. 둘 다 높이기 위해 사용하는 것이 결과적으로 Access Token과 Refresh Token인 것으로 이해했고, 해당 내용을 이 글에서 정리했다.