✅ 역할에 따른 코드 분리

역할에 따라 코드를 분리하여 구조화를 진행한다. 여기서 말하는 ‘구조'란 꼭 파일로서 분리하는 것은 아닐 수 있다. 프로그램 자체의 구조를 뜻하기도 한다. 편의상 파일로 분리하는 과정을 진행한 후, 점진적으로 소프트웨어 아키텍처 자체를 이해하는 것으로 폭을 넓혀가는 것이 좋다.

HTTP 통신을 처리하는 서버의 상황은 레스토랑과 별반 다르지 않다. 고객(손님)의 요청(주문)이 들어오면 서버는 데이터(재료)를 가공하여 요청에 알맞은 응답(요리)를 반환한다.

[사진1] 역할 분리 모식도

서버가 하는 역할을 자세히 뜯어보면 굉장히 다양한 기능이 혼재되어 있다. 회원가입하는 로직을 생각해보면 아래와 같다.

• 클라이언트로부터 요청을 받는다.
• Request에 누락된 Key가 없는지 확인 하여 Key Error를 캐치한다.
• 비밀번호의 길이를 확인하고, 유저의 존재 유무를 확인한다.
• 비밀번호를 암호화한다.
• Database에 INSERT INTO 문을 전송하여 데이터를 저장한다.
• 제대로 데이터가 저장되었음을 응답으로 알려준다.

이렇게 많은 기능이 app.js 파일 하나에서 일어나고 있을 것이다.

[사진2] 회원가입시 서버의 역할 모식도

이러한 코드는 스파게티 코드로, 하나의 기능을 수정하거나 교체하려고 할 때 파일 내부의 모든 다른 코드들이 지장받을 가능성이 높다. 뿐만 아니라, 특정 파일에서 오류가 발생하면 해당 파일 내부에 있는 다른 코드들 또한 오류에 영향을 받을 수 있다. 코드가 조금만 많아져도 파일이 복잡해져 가독성이 떨어지는 문제도 발생한다.

따라서 코드의 역할에 따라 파일을 분리할 수 있습니다. 크게 다음과 같은 기준으로 분리합니다.

• [파일 1] HTTP Request/Response 처리
• [파일 2] Business Logic 처리
• [파일 3] Database 통신 처리
  

[사진3] 회원가입시 서버의 layered architecture 모식도

• 파일 1은 Client로부터 받은 요청 자체에 관련된 일만 처리한다. 예시
  • Request body 에서 데이터를 꺼낸다.
  • JSON Response로 제품 정보를 전달한다.
• 파일 2는 우리 서비스가 결정한 규칙에 따른 일들만 처리한다. 예시
  • 비밀번호의 길이는 8자리 이상으로 규정한다.
  • 이미 가입한 이메일로는 중복으로 가입할 수 없도록 한다.
  • 비밀번호는 암호화해서 저장한다.
• 파일 3은 데이터베이스와의 통신만 처리한다. 예시
  • 데이터를 INSERT INTO로 저장한다.
  • SELECT로 데이터를 가져온다.

분리된 구조로 코드를 구현하면 코드의 확장성이 높아진다. 각 파일에 포함되어 있는 코드의 목적이 명확하고 범위도 확실하기 때문에 코드의 구조를 파악하기도 쉽다. 또한, 각 파일이 서로 독립적이고 역할이 분명하므로 서로에게 끼치는 영향을 최소화하면서 확장하거나 수정할 수 있다.

이렇게 주된 역할과 집중해야할 기능을 분리하여 서로 다른 기능을 하는 파일은 신경을 쓰지 않도록 하는 것을 ‘Seperation Of Concern, 관심사의 분리’하고 한다.

✅ 정리

---

• 코드의 구조를 더 체계적으로 그리고 효율적으로 구현하는 것을 코드의 아키텍처(architecture)라고 한다.
• 이러한 아키텍쳐를 적용하는 것은 확장성, 재사용성, 유지 보수 가능성, 가독성, 테스트 가능성의 사유로 매우 중요하다.
• 또한 관심사 분리의 개념을 적용하여, 각 코드의 역할을 독립적으로 분리할 필요가 있다.