2017.07.05

Node.js 앱 구조 설계를 위한 7가지 핵심 사항

Rahul Mhatre | InfoWorld
Node.js가 새로운 웹 애플리케이션 개발을 위한 언어로 자바, 루비, 파이썬, 닷넷을 빠른 속도로 따라잡는 중이다. Node.js 팀은 하루가 다르게 자바스크립트 런타임을 더 빠르게, 더 견고하게 만들고 있다. 사용자 커뮤니티도 하루가 다르게 성장 중이다.

도입이 늘어남에 따라 점점 더 많은 개발자들이 Node.js를 배우면서 비슷한 문제에 직면하고 비슷한 기능을 코딩한다. 좋은 점은 Node.js 커뮤니티를 통해 일반적인 문제 해결뿐만 아니라 애플리케이션 설계에도 도움이 되는 프레임워크와 설계 패턴을 구할 수 있다는 것이다.

프레임워크는 일반적으로 MVC(모델-뷰-컨트롤러), MVVM(모델-뷰-뷰모델), MVP(모델-뷰-프리젠터) 또는 단순히 MV와 같은 MV 패턴을 구현한다. 또한 프레임워크는 모델, 뷰, 컨트롤러를 위한 코드가 있어야 할 위치, route가 있어야 할 위치, 구성을 추가해야 할 위치도 알려준다. 하지만 많은 수의 경험이 부족한 개발자와 Node.js 애호가가 설계 패턴 또는 OOP(객체 지향 프로그래밍) 다이어그램이 애플리케이션의 코드 라인과 구조에 어떻게 매핑되는지 제대로 이해하지 못하는 경우가 많다.

Express.js, Sails.js와 같은 Node.js 프레임워크의 용도가 바로 거기에 있다. 이 두 가지를 비롯해 신속하게 웹 애플리케이션 개발을 시작하는 데 도움이 되는 여러 가지 프레임워크가 있다. 어느 프레임워크를 사용하든 앱을 설계할 때는 몇 가지 사항을 염두에 두어야 한다.

Node.js 애플리케이션 개발에 착수하기 전에 생각해야 할 7가지 핵심 사항은 다음과 같다.

1. 애플리케이션에 적합한 디렉토리 구조
앱의 디렉토리 구조를 결정할 때는 자신이 선택한 설계 패턴을 고려해야 한다. 그러면 코드를 찾고 온보딩하고 신속하게 문제를 격리하는 데 도움이 된다. 개인적으로는 Node.js 앱을 설계할 때 MVC 패턴을 선호한다. 장점은 많지만 몇 가지만 나열하자면 개발 속도를 높이는 데 도움이 되고 동일한 데이터에 대해 여러 가지 뷰를 생성하는 유연성을 제공하며 MVC 컴포넌트 간 비동기 통신과 격리를 지원한다.

필자는 왼쪽 화면처럼 루비 온 레일즈(Ruby on Rails)와 Express.js의 조합을 바탕으로 하는 디렉토리 구조를 즐겨 사용한다.

2. ER 다이어그램을 모델에 매핑
테코피디아(Techopedia)에 정의된 바와 같이 “엔티티 관계 다이어그램(ERD)은 정보 시스템의 엔티티와 이러한 엔티티 간 관계를 그래픽으로 표현하는 데이터 모델링 기법”이다. ER 다이어그램은 시스템에 참여하는 다양한 엔티티를 기술하고 이러한 엔티티 간의 다음과 같은 모든 상호작용을 정의한다.

• 추상적 또는 물리적 “요소”에서 모델의 엔티티가 됨
• 모델이 데이터베이스 내의 테이블에 매핑됨
• 엔티티의 특성 또는 속성이 모델의 특성으로 해석되고, 이는 다시 테이블 내의 열로 변환됨

예를 들어 엔티티가 사용자라면 그에 상응하는 모델은 데이터베이스 내에 first_name, last_name, address 등의 특성과 해당 테이블 및 열이 있는 “User”가 될 것이다.

단순한 데이터 설계를 사용하면 새 스키마가 생성될 때마다 커지는 데이터페이스와 파일을 쉽게 추적할 수 있다.

3. MVP 패턴 사용
MVC를 구현한다는 것은 단순히 컨트롤러, 뷰, 모델을 위한 폴더를 생성한다는 뜻이 아니다. MVC에 따라 코드와 논리도 분할해야 한다. 모델 내의 코드는 데이터베이스 스키마 정의에 따라 엄격하게 제한되어야 한다. 개발자는 모델에 CRUD 작업을 수행하는 코드도 들어간다는 사실을 잊곤 한다. 또한 그 모델에 한정된 함수 또는 작업은 이 파일 내에 있어야 한다. 모델과 관련된 대부분의 비즈니스 논리가 이 파일에 있어야 한다.

흔히 저지르는 실수 중 하나는 모든 비즈니스 논리를 컨트롤러에 집어넣는 것이다. 컨트롤러는 모델 또는 다른 컴포넌트에서 함수를 호출하고, 컴포넌트 간에 데이터를 전송하고, 요청의 흐름을 제어하는 역할만 해야 하며, 뷰 폴더에는 객체를 사람이 읽을 수 있는 형태로 변환하기 위한 코드만 있어야 한다. 데이터 포맷 또는 정렬, 필터링과 같은 논리가 뷰 안에서 수행되면 안 된다. 뷰를 깔끔하게 유지하면 사용자 경험도 향상되고, 뷰를 바꿀 때 다른 컴포넌트를 변경하지 않아도 된다.

4. 논리를 모듈로 나누기
개발자들이 항상 듣는 말은 코드를 파일과 모듈로 정리해야 한다는 것이다. 이 말은 앱 전체를 하나의 파일에 집어넣기 위해 노력하라는 뜻이 아니다. 최선의 방법은 논리와 기능에 따라 코드를 분할하는 것이다. 하나의 엔티티 또는 객체와 관련된 함수를 하나의 파일로 묶고 논리를 기준으로 디렉토리 구조를 설계하면 여러 이점이 따른다.
첫째, 버그를 수정해야 할 때 어느 함수를 건드려야 할지 확인하는 데 소요되는 시간이 대폭 줄어든다. 둘째, 아키텍처의 모든 컴포넌트를 분리(decouple)하는 데 도움이 된다. 따라서 다른 코드 라인을 수정할 필요 없이 개별 기능을 대체할 수 있다. 셋째, 테스트 케이스를 작성하는 데도 유용하다.

5. 테스트 케이스의 중요성
테스트 케이스를 구축할 때는 편법으로 지름길을 택하지 않는 것이 중요하다. 테스트는 코드 베이스를 지키는 수호자다. 애플리케이션의 규모가 커질수록 대처해야 할 모든 시나리오를 코딩 중에 기억하기는 더 어려워진다. 테스트 케이스는 코드 베이스의 안정성을 유지하는 데 도움이 된다.

테스트를 통해 회귀를 방지하고 소중한 개발 시간과 노동을 아낄 수 있다. 적용할 새로운 기능에 오류가 없는지 확인할 수 있다. 또한 프로덕션 단계로 가기 전에 버그를 잡을 수 있으므로 코드 품질 개선에도 도움이 된다. 가장 중요한 점은 테스트를 하면 코드가 충돌하지 않는다는 확신을 가질 수 있다는 것이다.

6. 로그의 중요함
로그는 애플리케이션을 디버그하고 상태를 파악하는 데 유용하다. 로그를 통해 앱의 동작에 관한 유용한 시야를 얻을 수 있다. 로그를 활용할 때 유의해야 할 점은 다음과 같다.

• 로깅의 경우 적절한 균형을 찾아야 한다. “정보가 너무 많아서” 해가 될 일은 없지만 과도한 로깅은 일을 더 힘들게 할 뿐이다. 건초더미가 작을수록 바늘을 찾기도 쉬워진다. 반면 로깅을 빈약하게 하면 디버그나 진단에 사용할 정보가 너무 적어진다.

• 오프라인 로그와 온라인 로그를 분할한다. 가장 최근 로그는 빠른 검색과 처리를 위해 두고, 오래된 로그는 아카이브하거나 파일로 덤프한다.

• 필요한 저장 공간의 양에 영향을 미치는 로그의 빈도와 기간을 감안해야 한다. 대부분의 경우 필요한 저장 공간과 보관하는 로그의 수는 정비례한다.

또한 기억해야 할 점은 이메일 ID, 암호, 신용카드 정보, 전화번호와 같은 민감한 데이터를 로깅하지 않는 것이다. 보안 측면에서 크게 위험할 뿐만 아니라 많은 경우 불법이기도 하다.

7. 애플리케이션이 확장되는가?
애플리케이션 개발에서 최악의 접근 방법은 트래픽이 늘어난 이후에야 확장할 방법을 고민하는 것이다. 시간을 절약하고 생산성을 높이라면 처음부터 확장 가능한 아키텍처를 구축해야 한다.

확장(scaling)은 서버 스핀업이 아니라 부하를 여러 리소스에 걸쳐 분산시키는 것이다. 부하가 증가할 때 새 서버를 가동해서는 안 된다는 뜻이 아니다. 우선 현재 리소스 내에서 부하 분산을 설정해 늘어난 부하를 처리해야 한다. 부하 분산으로 워크로드를 효율적으로 관리할 수 없을 때가 비로소 수평 확장을 시작해 새 서버를 투입할 시점이다. 이는 독립적인 무상태(stateless) 프로세스 또는 모듈을 통해 가능하다. 각 프로세스 또는 모듈은 격리되어 독립적으로 작동한다. 이는 애플리케이션의 효율적인 확장에 도움이 될 뿐만 아니라 시스템에 내장애성을 부여하고 쉽게 복구할 수 있게 해준다.

웹 애플리케이션의 구조 설계는 적절한 기술을 선택하는 것만큼 중요하다. 기반에 결함이 있다면 그 위에 쌓은 애플리케이션은 결국 무너지거나 확장을 거부하거나 때로는 아예 시작조차 못하게 된다. 적절한 계획과 설계 없이 서둘러 새로운 기능이나 새로운 아이디어를 구현해서는 안 된다. 나쁜 구조 또는 아키텍처는 터질 때만 기다리는 시한 폭탄과 같다.
Rahul Mhatre는 Built.io의 기술 아키텍트이다.
 editor@itworld.co.kr

2017.07.05

Node.js 앱 구조 설계를 위한 7가지 핵심 사항

Rahul Mhatre | InfoWorld
Node.js가 새로운 웹 애플리케이션 개발을 위한 언어로 자바, 루비, 파이썬, 닷넷을 빠른 속도로 따라잡는 중이다. Node.js 팀은 하루가 다르게 자바스크립트 런타임을 더 빠르게, 더 견고하게 만들고 있다. 사용자 커뮤니티도 하루가 다르게 성장 중이다.

도입이 늘어남에 따라 점점 더 많은 개발자들이 Node.js를 배우면서 비슷한 문제에 직면하고 비슷한 기능을 코딩한다. 좋은 점은 Node.js 커뮤니티를 통해 일반적인 문제 해결뿐만 아니라 애플리케이션 설계에도 도움이 되는 프레임워크와 설계 패턴을 구할 수 있다는 것이다.

프레임워크는 일반적으로 MVC(모델-뷰-컨트롤러), MVVM(모델-뷰-뷰모델), MVP(모델-뷰-프리젠터) 또는 단순히 MV와 같은 MV 패턴을 구현한다. 또한 프레임워크는 모델, 뷰, 컨트롤러를 위한 코드가 있어야 할 위치, route가 있어야 할 위치, 구성을 추가해야 할 위치도 알려준다. 하지만 많은 수의 경험이 부족한 개발자와 Node.js 애호가가 설계 패턴 또는 OOP(객체 지향 프로그래밍) 다이어그램이 애플리케이션의 코드 라인과 구조에 어떻게 매핑되는지 제대로 이해하지 못하는 경우가 많다.

Express.js, Sails.js와 같은 Node.js 프레임워크의 용도가 바로 거기에 있다. 이 두 가지를 비롯해 신속하게 웹 애플리케이션 개발을 시작하는 데 도움이 되는 여러 가지 프레임워크가 있다. 어느 프레임워크를 사용하든 앱을 설계할 때는 몇 가지 사항을 염두에 두어야 한다.

Node.js 애플리케이션 개발에 착수하기 전에 생각해야 할 7가지 핵심 사항은 다음과 같다.

1. 애플리케이션에 적합한 디렉토리 구조
앱의 디렉토리 구조를 결정할 때는 자신이 선택한 설계 패턴을 고려해야 한다. 그러면 코드를 찾고 온보딩하고 신속하게 문제를 격리하는 데 도움이 된다. 개인적으로는 Node.js 앱을 설계할 때 MVC 패턴을 선호한다. 장점은 많지만 몇 가지만 나열하자면 개발 속도를 높이는 데 도움이 되고 동일한 데이터에 대해 여러 가지 뷰를 생성하는 유연성을 제공하며 MVC 컴포넌트 간 비동기 통신과 격리를 지원한다.

필자는 왼쪽 화면처럼 루비 온 레일즈(Ruby on Rails)와 Express.js의 조합을 바탕으로 하는 디렉토리 구조를 즐겨 사용한다.

2. ER 다이어그램을 모델에 매핑
테코피디아(Techopedia)에 정의된 바와 같이 “엔티티 관계 다이어그램(ERD)은 정보 시스템의 엔티티와 이러한 엔티티 간 관계를 그래픽으로 표현하는 데이터 모델링 기법”이다. ER 다이어그램은 시스템에 참여하는 다양한 엔티티를 기술하고 이러한 엔티티 간의 다음과 같은 모든 상호작용을 정의한다.

• 추상적 또는 물리적 “요소”에서 모델의 엔티티가 됨
• 모델이 데이터베이스 내의 테이블에 매핑됨
• 엔티티의 특성 또는 속성이 모델의 특성으로 해석되고, 이는 다시 테이블 내의 열로 변환됨

예를 들어 엔티티가 사용자라면 그에 상응하는 모델은 데이터베이스 내에 first_name, last_name, address 등의 특성과 해당 테이블 및 열이 있는 “User”가 될 것이다.

단순한 데이터 설계를 사용하면 새 스키마가 생성될 때마다 커지는 데이터페이스와 파일을 쉽게 추적할 수 있다.

3. MVP 패턴 사용
MVC를 구현한다는 것은 단순히 컨트롤러, 뷰, 모델을 위한 폴더를 생성한다는 뜻이 아니다. MVC에 따라 코드와 논리도 분할해야 한다. 모델 내의 코드는 데이터베이스 스키마 정의에 따라 엄격하게 제한되어야 한다. 개발자는 모델에 CRUD 작업을 수행하는 코드도 들어간다는 사실을 잊곤 한다. 또한 그 모델에 한정된 함수 또는 작업은 이 파일 내에 있어야 한다. 모델과 관련된 대부분의 비즈니스 논리가 이 파일에 있어야 한다.

흔히 저지르는 실수 중 하나는 모든 비즈니스 논리를 컨트롤러에 집어넣는 것이다. 컨트롤러는 모델 또는 다른 컴포넌트에서 함수를 호출하고, 컴포넌트 간에 데이터를 전송하고, 요청의 흐름을 제어하는 역할만 해야 하며, 뷰 폴더에는 객체를 사람이 읽을 수 있는 형태로 변환하기 위한 코드만 있어야 한다. 데이터 포맷 또는 정렬, 필터링과 같은 논리가 뷰 안에서 수행되면 안 된다. 뷰를 깔끔하게 유지하면 사용자 경험도 향상되고, 뷰를 바꿀 때 다른 컴포넌트를 변경하지 않아도 된다.

4. 논리를 모듈로 나누기
개발자들이 항상 듣는 말은 코드를 파일과 모듈로 정리해야 한다는 것이다. 이 말은 앱 전체를 하나의 파일에 집어넣기 위해 노력하라는 뜻이 아니다. 최선의 방법은 논리와 기능에 따라 코드를 분할하는 것이다. 하나의 엔티티 또는 객체와 관련된 함수를 하나의 파일로 묶고 논리를 기준으로 디렉토리 구조를 설계하면 여러 이점이 따른다.
첫째, 버그를 수정해야 할 때 어느 함수를 건드려야 할지 확인하는 데 소요되는 시간이 대폭 줄어든다. 둘째, 아키텍처의 모든 컴포넌트를 분리(decouple)하는 데 도움이 된다. 따라서 다른 코드 라인을 수정할 필요 없이 개별 기능을 대체할 수 있다. 셋째, 테스트 케이스를 작성하는 데도 유용하다.

5. 테스트 케이스의 중요성
테스트 케이스를 구축할 때는 편법으로 지름길을 택하지 않는 것이 중요하다. 테스트는 코드 베이스를 지키는 수호자다. 애플리케이션의 규모가 커질수록 대처해야 할 모든 시나리오를 코딩 중에 기억하기는 더 어려워진다. 테스트 케이스는 코드 베이스의 안정성을 유지하는 데 도움이 된다.

테스트를 통해 회귀를 방지하고 소중한 개발 시간과 노동을 아낄 수 있다. 적용할 새로운 기능에 오류가 없는지 확인할 수 있다. 또한 프로덕션 단계로 가기 전에 버그를 잡을 수 있으므로 코드 품질 개선에도 도움이 된다. 가장 중요한 점은 테스트를 하면 코드가 충돌하지 않는다는 확신을 가질 수 있다는 것이다.

6. 로그의 중요함
로그는 애플리케이션을 디버그하고 상태를 파악하는 데 유용하다. 로그를 통해 앱의 동작에 관한 유용한 시야를 얻을 수 있다. 로그를 활용할 때 유의해야 할 점은 다음과 같다.

• 로깅의 경우 적절한 균형을 찾아야 한다. “정보가 너무 많아서” 해가 될 일은 없지만 과도한 로깅은 일을 더 힘들게 할 뿐이다. 건초더미가 작을수록 바늘을 찾기도 쉬워진다. 반면 로깅을 빈약하게 하면 디버그나 진단에 사용할 정보가 너무 적어진다.

• 오프라인 로그와 온라인 로그를 분할한다. 가장 최근 로그는 빠른 검색과 처리를 위해 두고, 오래된 로그는 아카이브하거나 파일로 덤프한다.

• 필요한 저장 공간의 양에 영향을 미치는 로그의 빈도와 기간을 감안해야 한다. 대부분의 경우 필요한 저장 공간과 보관하는 로그의 수는 정비례한다.

또한 기억해야 할 점은 이메일 ID, 암호, 신용카드 정보, 전화번호와 같은 민감한 데이터를 로깅하지 않는 것이다. 보안 측면에서 크게 위험할 뿐만 아니라 많은 경우 불법이기도 하다.

7. 애플리케이션이 확장되는가?
애플리케이션 개발에서 최악의 접근 방법은 트래픽이 늘어난 이후에야 확장할 방법을 고민하는 것이다. 시간을 절약하고 생산성을 높이라면 처음부터 확장 가능한 아키텍처를 구축해야 한다.

확장(scaling)은 서버 스핀업이 아니라 부하를 여러 리소스에 걸쳐 분산시키는 것이다. 부하가 증가할 때 새 서버를 가동해서는 안 된다는 뜻이 아니다. 우선 현재 리소스 내에서 부하 분산을 설정해 늘어난 부하를 처리해야 한다. 부하 분산으로 워크로드를 효율적으로 관리할 수 없을 때가 비로소 수평 확장을 시작해 새 서버를 투입할 시점이다. 이는 독립적인 무상태(stateless) 프로세스 또는 모듈을 통해 가능하다. 각 프로세스 또는 모듈은 격리되어 독립적으로 작동한다. 이는 애플리케이션의 효율적인 확장에 도움이 될 뿐만 아니라 시스템에 내장애성을 부여하고 쉽게 복구할 수 있게 해준다.

웹 애플리케이션의 구조 설계는 적절한 기술을 선택하는 것만큼 중요하다. 기반에 결함이 있다면 그 위에 쌓은 애플리케이션은 결국 무너지거나 확장을 거부하거나 때로는 아예 시작조차 못하게 된다. 적절한 계획과 설계 없이 서둘러 새로운 기능이나 새로운 아이디어를 구현해서는 안 된다. 나쁜 구조 또는 아키텍처는 터질 때만 기다리는 시한 폭탄과 같다.
Rahul Mhatre는 Built.io의 기술 아키텍트이다.
 editor@itworld.co.kr

X