"우리가 실무에서 맨날 쓰는 이 서버 아키텍처, 대체 이름이 뭡니까?"

요약 교과서적인 웹 서비스 아키텍처는 보통 클라이언트(Presentation), 서버(Logic), 데이터베이스(Data)로 구성되는 '3티어(Three-Tier) 아키텍처'로 소개되곤 합니다. 하지만 한 개발자가 실무 현장에서 실제로 마주하는 구조는 이와 전혀 다르며, 업계에서 널리 쓰이는데도 정작 마땅한 이름이 붙어있지 않다며 의문을 제기했습니다. 작성자가 설명하는 현실적인 구조는 기존의 비즈니스 로직(Logic) 계층이 클라이언트 요청을 실시간으로 처리하는 '애플리케이션 티어(Application Tier)'와 비동기 작업을 도맡는 '워커 티어(Worker Tier)'로 완전히 양분되어 있습니다. 즉 클라이언트, 애플리케이션(요청), 워커(태스크), 데이터베이스의 4단계 형태입니다. 두 계층이 분리되는 이유는 명확합니다. 클라이언트 요청에 즉각 응답하는 것과 작업을 안정적으로 완수하는 것은 기능적 책임이 다르고, CPU/메모리/네트워크 등 물리적 자원 관리와 확장 방식도 제각각이기 때문입니다. 또한 동기 vs 비동기라는 프로그래밍 모델 차이뿐 아니라 프론트엔드와 백엔드 담당 조직의 분리라는 현실적인 이유도 작용합니다. 간단한 웹 요청은 상태를 즉시 해제하므로 트래픽 급증 시 인스턴스를 늘려 수평 확장을 하기 쉽습니다. 반면 이메일 대량 발송 같은 백그라운드 태스크는 고유한 수명 주기와 상태를 지니며, 실패 시 재시도 로직이 필수적입니다. 이 때문에 개발 현장에서는 메시지 큐, 분산 스케줄러, 사가(Saga) 패턴, 내구성 실행 프레임워크 등을 계속해서 재발명하게 됩니다. 작성자는 이러한 구조가 마치 과거 화제가 되었던 '스타벅스 주문 방식(비동기 처리)' 비유나 레스토랑의 홀(Front of House)과 주방(Back of House)의 철저한 업무 분담과 닮아있다며, 실무를 가장 잘 반영한 이 아키텍처를 과연 무엇이라 불러야 할지 화두를 던졌습니다.