[TIL] 레이어드 아키텍처 (10장)

책은 이걸 기본값 아키텍처라고 부른다. 고른 적이 없는데 그냥 그렇게 되어 있는 구조라는 뜻이다. 아키텍처를 딱히 정하지 않으면 자연스럽게 여기로 흘러간다.

어떻게 생겼나

위에서 아래로 쌓여 있다.

화면        사용자 요청 받고 보여주기
로직        비즈니스 규칙
데이터 접근  DB에 읽고 쓰기
DB          저장

가운데 둘을 합쳐서 3층으로 쓰기도 한다. 어느 쪽이든 나누는 기준은 하는 일의 종류다.

덕분에 비슷한 코드끼리 잘 모인다. 대신 주문 기능 하나 고치려면 세 층을 동시에 열어야 한다.

층이 막아주는 것

이 구조의 핵심은 어떤 층을 고쳐도 그 여파가 바로 옆 층까지만 간다는 데 있다.

화면 코드는 로직 층이 뭘 해주는지만 알면 되고, 그 밑에 어떤 DB가 있는지는 몰라도 된다. 그래서 DB를 통째로 갈아치워도 화면은 안 건드린다.

이게 성립하려면 층을 건너뛰면 안 된다. 화면이 데이터 접근 층을 직접 부르는 순간 이 방벽이 사라지고, DB 테이블 하나 바뀌었는데 화면 코드가 깨지기 시작한다.

물론 예외는 필요하다. 공통 기능을 모아둔 층 같은 건 건너뛸 수 있게 열어두기도 한다. 중요한 건 어디가 열려 있고 어디가 막혀 있는지 적어두는 것이다. 안 적어두면 시간이 지나면서 전부 열린다.

아무 일도 안 하는 층

레이어드에서 제일 자주 나오는 문제다. 요청이 층을 지나가는데 중간이 아무것도 안 하고 그대로 아래로 넘기기만 한다.

화면        getUser()
로직        getUser()             ← 하는 일 없음
데이터 접근  getUser()             ← 하는 일 없음
DB          SELECT * FROM users

지나가는 값만 치르고 얻는 게 없다. 책은 이걸 싱크홀이라고 부른다.

기준도 알려준다. 이렇게 그냥 통과만 하는 요청이 20% 정도면 괜찮고, 80%까지 가면 레이어드가 잘못된 선택이라는 신호다. 전부 통과만 시키는 층이라면 있을 이유가 없으니까.

데이터와 클라우드, 그리고 배포

데이터 쪽은 단순하다. DB 하나를 다 같이 쓴다. 테이블 조인이 자유롭고, 중간에 실패하면 알아서 되돌려준다. 이게 레이어드의 가장 큰 실무적 장점이고, 동시에 여기가 막히면 전부 막히는 지점이기도 하다.

클라우드에서는 별로다. 배포 덩어리가 하나라 필요한 부분만 늘릴 수가 없다. 결제 트래픽만 열 배로 뛰어도 앱 전체를 복제해야 하는데, DB는 여전히 하나라서 그쪽이 먼저 무너진다.

대신 싸다. 인프라가 단순하고 관리할 게 적다. 그래서 기존 서버에 있던 걸 클라우드로 있는 그대로 옮기는 작업에는 오히려 잘 맞는다.

배포 부담도 꽤 크다. 한 줄 고쳐도 전체를 다시 배포해야 하니 테스트 범위가 전체다. 그러다 보니 배포 주기가 길어지고, 길어지니 한 번에 많이 묶어서 내보내고, 그러면 더 무서워진다. 이 고리가 레이어드의 진짜 비용인 것 같다.

규칙을 지키게 만들기

층 건너뛰지 말자는 약속은 문서로는 안 지켜진다. 6장에서 나왔던 방법이 여기서 쓰인다. 화면 코드가 데이터 접근 코드를 가져다 쓰면 CI가 실패하게 만드는 식이다. 자바라면 ArchUnit 같은 도구가 이 검사를 해준다.

이런 장치가 없으면 층 구조는 프로젝트 초반 몇 달만 버틴다.

팀 구조도 딱 들어맞는다. 프론트엔드 팀은 화면, 백엔드 팀은 로직과 데이터 접근, DBA 팀은 DB. 콘웨이의 법칙 그대로다. 문제는 기능 하나 만드는 데 세 팀 일정이 맞아야 한다는 것. 기능 단위와 팀 단위가 어긋나 있다.

이 스타일의 장단점

좋은 쪽   싸다, 단순하다
보통      전체 안정성
약한 쪽   따로 배포하기, 필요한 만큼 늘리기, 일부 장애 버티기, 나중에 바꾸기

좋은 게 두 개뿐이고 나머지는 대체로 약하다. 그런데 프로젝트 초반에 제일 중요한 게 딱 그 두 개인 경우도 꽤 많다.

작고 단순한 앱, 예산과 일정이 빡빡한 프로젝트, 도메인이 아직 안 보이는 초기 단계라면 합리적인 선택이다. 반대로 기능마다 필요한 서버 규모가 다르거나 자주 따로 배포해야 한다면 여기 있으면 안 된다.

정리

레이어드는 제일 싸고 제일 단순하다. 그 둘 말고는 거의 다 약하다.

결국 이 장에서 남은 건 층을 만들라는 말이 아니라, 만든 층이 실제로 뭔가를 막아주고 있는지 확인하라는 쪽이었다.

지금 우리에게 가장 중요한 게 그 둘이 맞다면 좋은 선택이고, 아니라면 배포 덩어리는 그대로 두고 쪼개는 기준만 바꾸는 길이 있다. 11장의 모듈러 모놀리스다.

레퍼런스

• Mark Richards, Neal Ford, Fundamentals of Software Architecture, 2nd Edition — Chapter 10, Layered Architecture Style