Layered Architecture

서버 코드가 커질수록 화면 처리, 규칙 계산, 저장소 접근, 외부 API 연결이 한 함수와 한 파일 안에 섞이기 쉽습니다. 이런 상태에서는 수정 한 번이 예상보다 넓게 번지고, 테스트도 어디서 끊어야 할지 애매해집니다. 새 기능을 넣을수록 기존 코드 구조가 더 빨리 탁해집니다. Layered Architecture는 바로 이 내부 혼잡을 줄이기 위한 정리 방식입니다.

초기 업무 시스템은 기능 수가 적을 때는 하나의 코드베이스로도 충분했습니다. 하지만 도메인 규칙이 늘고 외부 연동이 붙으면서 코드가 서로 다른 이유로 자주 함께 바뀌기 시작했습니다. 이때 가장 먼저 필요한 것은 배포 단위를 쪼개기보다, 한 애플리케이션 안에서 책임 경계를 읽을 수 있게 만드는 일이었습니다. Layered Architecture는 그 요구에 대한 가장 보편적인 응답 중 하나였습니다.

가장 바깥 층은 입력과 출력, 그 안쪽은 유스케이스 조정, 더 안쪽은 핵심 도메인 규칙, 그리고 가장 바깥 기술 연결은 인프라 층이 맡는 식으로 나눕니다. 중요한 점은 파일을 폴더로만 나누는 것이 아니라, 어떤 층이 어떤 질문에 답하는지를 고정하는 데 있습니다. 그러면 변경이 들어왔을 때 화면 문제인지, 흐름 문제인지, 규칙 문제인지, 기술 연결 문제인지 판단이 쉬워집니다.

Layered Architecture와 Microservices는 모두 복잡도를 나누려는 시도입니다. 하지만 Layered Architecture는 하나의 애플리케이션 내부를 책임별로 정리하는 방식이고, Microservices는 배포 단위 자체를 여러 서비스로 쪼개는 방식입니다. 즉 전자는 '한 앱 안을 어떻게 나눌까'에 가깝고, 후자는 '앱 경계를 어디서 끊을까'에 가깝습니다.

하나의 서버 애플리케이션을 운영하면서도 업무 규칙을 오래 유지하고 테스트하고 확장해야 할 때 Layered Architecture는 기본 정리 도구가 됩니다. 특히 데이터 접근 코드가 도메인 판단을 침범하거나, 프레젠테이션 코드가 규칙을 직접 품기 시작할 때 유용합니다. 다만 모든 층이 항상 같은 속도로 커지는 것은 아니어서, 나중에는 배포 단위 자체를 다시 생각하게 될 수 있습니다.

다음에 볼 개념

함께 보면 좋은 개념