[Node.js] 1. 모듈로 앱 구조 짜기 (번역)

E-ρ(rho) 이로·2022년 6월 6일
1

✅ [번역] Tao of Node

목록 보기
1/3
post-thumbnail
이 블로그 글은 제시된 원문을 직접 번역한 것입니다. (오역이 있을 수 있으니 꼭 원문을 참고하시길 바라요!)

This article will give you a translated version of Original Article.

서론

자바스크립트의 가장 큰 이점은 바로 브라우저와 서버에서 모두 동작한다는 것이다. 엔지니어로서 하나의 언어를 마스터할 필요가 있다. 그러면 우리는 갈고 닦은 기술을 다양하게 적용해볼 수 있을 것이다. 필자 또한 이런 이유로 2015년 노드에 입문했다.
Node는 프론트엔드와 백엔드 어플리케이션 사이에서 라이브러리, 로직, 타입을 재사용할 수 있다. 풀스택 개발자의 전형적인 예시가 될 수 있는 것이다!
Node 생태계는 처음 구축된 당시의 무거운 프레임워크에서 탈피하여 자유로움과 유연함에 초점을 맞추고 있다. 엄격한 코딩 기준이나 어플리케이션 구조를 따지지 않아도 된다! 대신.. 유연함엔 대가가 따르긴 한다.
JS를 처음 접했다면 Node 앱을 작성하는데 있어서 규칙과 원리를 찾기 어려울 것이다. OOP(객체지향프로그래밍)를 다뤄봤던 개발자들은 이전에 사용했던 언어에서 빠르게 관습들을 차용해올 수는 있다.

필자가 Node app을 개발하며 세웠던 몇 가지 규칙들을 간략히 보여주려고 한다.

Structure & Coding Practices

앱 구조를 짜는 것은 전략적이고 전술적인 결정을 합친 것이다. 개발자들은 폴더 정렬, 층, 그 사이의 연결(communication)뿐만 아니라 낮은 수준의 디테일까지 생각해야한다. 하나라도 무시하면 디자인에 흠이 발생하게 된다.

Structure the applicaion in modules

모듈로 앱 구조 짜기

백엔드 개발에서 가장 유명한 구조 디자인 패턴(structural design pattern)은 MVC이다. MVC는 대부분의 상황에 적용할 수 있고, 사용하기로 했다면 일이 잘못되는 일은 없다. MVC가 중점으로 다루고자 하는 것은 app의 기술적인 책임감들을 중점으로 구조화하는 것이다. HTTP 요청과 응답을 다루는 컨트롤러(controllers), 데이터베이스에서 데이터를 가져오는 모델(models), 응답을 시각화하는 (views)로 구성된다.

이러한 접근법의 이점은 아직 크지 않다. 요즘에 대부분의 Node app은 JSON으로 통신해서 view 층이 필요하지 않은 REST한 서비스이다. 모델과 ORM을 사용하는 것도 항상 바람직한 것은 아니다. 데이터의 일부를 가지고있는 마이크로 서비스에 접근하는데 복잡한 도구들이 필요하지는 않기 때문이다. 그리고 컨트롤러 층은 종종 개발자들이 모든 종류의 로직을 컨트롤러에 쏟아내면서 복잡함 그 자체가 되기도 한다.

걱정을 나누는건 기술적 책임(역할)을 나누는 것과는 다른 얘기다.

MVC 구조의 장점은 MVC를 사용하는 각각의 app이 같은 방식으로 구성되어있다는 점이다. 하지만 나는 이것을 '결점'으로 보았다. app의 구조는 이것이 무엇을 하는 건지 보여줄 수 있어야하고, 도메인에 대한 정보를 제공해야한다. 컨트롤러로 가득찬 폴더를 열어보는 것은 서비스 내의 로직이 어떻게 구분되는 것인지 그 어떤 맥락도 제공하지 않는다. 모델의 긴 목록으로도 모델 간의 관계를 나타내지는 않는다.

노드 앱을 더 잘짜는 방식은 도메인의 한 부분을 대표하는 모듈들(modules)에 있다. 각각은 핸들러, 모델, 테스트, 비즈니스 로직을 포함한 구분된 폴더이다. 이러한 구조는 서비스가 하는 일을 한 눈에 들여다보기 편하게 하고 개발자로서 각 모듈의 모든 것에 대해 자신감을 갖게 한다. 놓친 것이 없는지 확인하기 위해 코드단에서 깊게 파볼 일이 없게 되는 것이다!

// 👎 Don't structure by technical responsibilities
├── src
|   ├── controllers
|   |   ├── user.js
|   |   ├── catalog.js
|   |   ├── order.js
|   ├── models
|   |   ├── user.js
|   |   ├── product.js
|   |   ├── order.js
|   ├── utils
|   |   ├── order.js
|   ├── tests
|   |   ├── user.test.js
|   |   ├── product.test.js

// 👍 Structure by domain modules
├── src
|   ├── user
|   |   ├── user-handlers.js
|   |   ├── user-service.js
|   |   ├── user-queries.js
|   |   ├── user-handlers.test.js
|   |   ├── index.js
|   ├── order
|   |   ├── order-handlers.js
|   |   ├── order-service.js
|   |   ├── order-queries.js
|   |   ├── order-handlers.test.js
|   |   ├── calculate-shipping.js
|   |   ├── calculate-shipping.test.js
|   |   ├── index.js
|   ├── catalog
|   |   ├── catalog-handlers.js
|   |   ├── product-queries.js
|   |   ├── catalog-handlers.test.js
|   |   ├── index.js

모듈 구조에 대해서는 따라야 할 특정한 패턴은 없다. 도메인 파트에 따라서 다른 내용들이 있을 수 있다. 예를 들어 핸들러, 모델 수가 다를 수도 있고, 비즈니스 로직의 크기가 다를 수 있다.

금융업계와 의학계에서 운영되는 app은 다른 방식으로 구조를 짜야한다. 도메인이 작동하는 방식의 차이점이 코드단에서 보여야한다. 즉, 우리의 소프트웨어가 해결하고자하는 실제 문제에 따라서 다르게 구조를 짜야할 필요가 있다. 모든 비즈니스 도메인은 다른 어려움에 직면하므로 우리는 어플리케이션을 모두 같게 디자인해서는 안된다.

My comment
실제로 나는 controller, model 등을 따로 구분해서 그 안에 user, function1, function2가 계속 반복된 형태의 스트럭쳐를 사용했었다. 그냥 파일을 여는 것 자체가 좀 귀찮..고 어려웠는데 이렇게 모듈로 만들면 관리가 편할 것 같다!

0개의 댓글