Web 서비스를 운영할 때, 알맞은 아키텍처는 무엇일까?

세상엔, 다양한 종류의 웹 서비스가 있고, 각 웹 서비스에는 자기만의 구조가 있을 수도 있고, 보편적인 구조를 사용할 수도 있다. 아니면, 그냥 작동하는 것에 의의를 두고, 만들어진 웹 서비스도 있을 것이다.(물론 개인적으로 이 구조는 피하고 싶다.)

이번 문서에서는 가장 보편적일 수 있는 구조에 대해 이야기해 볼 예정이다.

Web 서비스 아키텍처

REST API

웹 API 설계를 위한 표준(강제되는 구조는 아니다.)으로 Java, Python, Go 등 다양한 언어로 참고할 수 있는 레퍼런스가 많다.(즉, 구현하기 쉽다.)

• Rest API는 서비스 개발을 위해선 가장 일반적인 접근 방법이 될 수 있다.
• HTTP 프로토콜 기반만 따르면 응용이 용이하다.(주로 JSON, 개인적으론 선호하진 않지만, 정말 가끔 XML)
• STATELESS 기반 수평 확장이 용이하다.
• Self-descriptveness를 실현시킬 수 있다.

3-Tier 아키텍처

서비스를 이루는 아키텍처는 매우 다양하지만, 가장 보편적인 구초로는 3-Tier 아키텍처가 있다.

각 계층을 간단하게 설명하자면...

• Presentation Layer
  • 사용자가 실질적으로 맞닥뜨리는 계층(UI/UX 관련 서비스를 제공받는다.)
• Application Layer
  • 트랜잭션 처리에 필요한 비즈니스 로직 제공
• Data Layer
  • 데이터를 저장하고 조회하는 기능 제공

보편적인 이유는? 계층간의 고립성

• 각 계층을 모듈화 함으로서 다른 계층에 미치는 영향을 최소화할 수 있다.
• 따라서, 프론트엔드, 백엔드 엔지니어간의 역할 분리가 용이하다.
• 따라서, 확장이 용이하다.

마무리

현재 진행하고있는 프로젝트는 HTTP api(Restful을 지향하지만, 아쉽게도 아직 갈길이 멀다.)를 진행하고 있다. 디자이너도 없고, 기획자도 없고, 프론트엔드 엔지니어도 없이, 오직 백엔드 개발 지망생끼리 진행하고 있는 프로젝트지만, 현재, 백/프론트 엔지니어간의 역할의 분리를 명확히 하는 업계 분위기에 맞게, 준비하는 것이 바람직할 거라 판단하였다. 또한, 이번에 언급했던 3-Tier 아키텍쳐와는 다른 이야기일 수도 있지만, 서비스가 거대해질수록, micro service 아키텍쳐로 진화하고 있는 몇몇 애플리케이션(대표적으로 배달의 민족)을 보면, 영역별로, 계층별로, 분리를 명확하게 하는 것이 더 나은 방향일 듯 하다.