🎬 한 장의 그림으로 이해하는 모놀리식 3-Tier 웹 서비스 구조

🖼️ 4컷 인포그래픽

💡 한 줄 결론

웹 서비스의 경쟁력은 UI·비즈니스 로직·상태 저장을 얼마나 느슨하게 분리하느냐에 달려 있고, 모놀리틱 3-Tier의 한계를 이해해야 왜 현대 웹이 API 중심·클라이언트 렌더링·수평 확장 구조로 이동했는지 판단할 수 있다.

📌 핵심 요점

HTTP 1.0 기반 초기 웹은 상태를 기억하지 않는 문서 열람 체계였고, 로그인·세션·쿠키·DB는 이 빈자리를 메우기 위해 뒤늦게 붙은 장치들이다.
모놀리틱 웹은 화면 생성, 서버 로직, 데이터 접근, 배포 단위가 한 몸이라 일부 기능 수정도 전체 영향과 재배포 부담으로 이어지기 쉽다.
CGI에서 WAS·서블릿·JSP·톰캣·스프링으로 이어진 흐름은 동적 HTML 생성 비용과 URL 매핑 복잡도를 줄이기 위한 서버 측 생산성 개선의 역사다.
REST API와 JSON 중심 구조는 서버의 책임을 데이터 제공으로 줄이고, 브라우저가 화면 조립을 맡게 해 디바이스 대응과 계층 분리를 유리하게 만들었다.
모놀리틱 구조의 확장 한계는 단순 성능 부족이 아니라 세션이 서버 메모리에 묶여 스케일아웃·분산 운영·보안 대응까지 함께 복잡하게 만든다는 데 있다.

🧠 상세 요약

1) 배경과 문제 정의

웹은 처음부터 애플리케이션 플랫폼이 아니라 원격 문서 전달 시스템으로 출발했다. 하지만 로그인, 폼 입력, 사용자별 화면, 데이터 저장이 필요해지면서 단순한 문서 서버는 상태를 관리하는 서비스 구조로 바뀌었다. 이 영상의 관찰 포인트는 바로 그 변화 과정에서 어떤 기술이 왜 등장했고, 어느 지점에서 현대 웹 구조로의 전환이 불가피해졌는가다.

2) 섹션별 상세 정리

1. 문서 전달 웹에서 서비스 아키텍처 웹으로 시야가 이동한다 [00:01]

초반부는 HTTP, REST 같은 개념 공부를 넘어 실제 웹 서비스가 어떤 구조로 구현되는지 봐야 한다는 문제의식을 깐다.
과거 구조를 알아야 현재의 용어와 계층이 왜 존재하는지 이해할 수 있다는 점을 먼저 못 박는다.

2. 웹은 모놀리틱과 현대적 분리 구조의 대비로 이해할 수 있다 [00:59]

설명의 큰 틀은 과거형 모놀리틱 웹과 현대적 웹 아키텍처의 대비다.
핵심은 “예전 방식이 왜 생겼고, 무엇이 한계였으며, 그래서 어떤 방향으로 이동했는가”를 하나의 진화 흐름으로 보는 것이다.

3. 모놀리틱 웹은 화면·로직·데이터가 하나의 덩어리로 묶여 있다 [02:59]

과거 웹은 프론트엔드, 백엔드, DB 처리, 비즈니스 로직이 사실상 한 코드베이스와 한 배포 단위 안에 있었다.
서버가 HTML을 직접 만들어 보내는 서버 사이드 렌더링 중심 구조라서 브라우저 차이, 장치 차이, 변경 영향 범위가 모두 서버 쪽 부담으로 몰렸다.

4. 초기 웹의 본질은 상태 없는 HTML 문서 뷰어였다 [06:56]

HTTP 1.0 시기의 웹은 사용자가 요청한 문서를 전달받아 읽는 체계였고, 서비스가 사용자의 이전 행동을 기억하지 않았다.
브라우저는 원격 HTML을 받아 파싱하고 렌더링하는 뷰어 성격이 강했고, 경쟁력도 렌더링 엔진 성능에 크게 좌우됐다.

5. UI 분리 요구가 CSS와 자바스크립트의 등장을 밀어 올렸다 [12:38]

좋은 소프트웨어 설계는 UI, 데이터, 로직을 분리하는 데서 출발하지만, 초기 HTML은 내용과 표현이 강하게 섞여 있었다.
이후 CSS가 표현을 분리했고, 자바스크립트가 상호작용을 담당하면서 브라우저는 단순 뷰어에서 실행 플랫폼으로 진화했다.

6. CGI는 웹에 서버 로직을 넣었지만 운영 비용이 너무 컸다 [19:53]

단순 정적 리소스 제공을 넘어 서버 안에서 프로그램을 실행하려는 시도로 CGI가 도입됐다.
하지만 요청마다 프로세스가 늘어나는 구조, 보안 취약성, 운영체제 종속성 때문에 대규모 서비스에 비효율적이었고 점차 한계를 드러냈다.

7. 로그인·폼·검증·DB가 들어오며 웹은 상태 기반 상호작용 시스템이 된다 [24:04]

로그인과 폼은 사용자의 입력을 서버로 보내는 본격적인 상호작용의 출발점이 됐다.
입력값 검증, 인증, 상태 전이 관리가 필요해지면서 서버는 더 이상 문서만 주는 존재가 아니라 데이터를 기억하고 판정하는 시스템이 되었다.
이 과정에서 쿠키와 데이터베이스가 사용자 상태를 이어 붙이는 기억 장치로 자리 잡는다.

8. WAS와 DB 결합은 동적 HTML 생성을 산업화한 단계였다 [30:49]

사용자 상황에 따라 다른 HTML을 내려주려면 웹서버만으로는 부족했고, 별도의 애플리케이션 로직 서버가 필요해졌다.
WAS는 입력 검증과 비즈니스 로직을 자바 기반으로 처리하고, JDBC·JPA 등을 통해 관계형 DB와 연결되며 동적 화면 생성의 핵심 계층이 된다.

9. JSP·서블릿·톰캣·스프링은 서버 생산성과 구조 분리를 위한 해법이었다 [37:21]

자바 코드로 HTML을 직접 조립하는 고통을 줄이기 위해 JSP가 등장했고, 이는 내부적으로 서블릿 클래스로 변환되어 실행된다.
톰캣 같은 서블릿 컨테이너는 URL 요청, 코드 생성, 컴파일, 실행, 인스턴스 관리를 통합했다.
이후 URL과 매핑이 폭증하자 디스패처 서블릿과 스프링 같은 프레임워크가 필요해졌고, 반복 설정을 줄이며 UI·컨트롤러·로직 분리를 더 체계화했다.

10. 현대 웹은 HTML 생성보다 데이터 전달과 렌더링 분리로 중심축이 이동했다 [46:33]

서버가 HTML 전체를 조립하는 대신 JSON 형태의 데이터를 주고받는 REST API 중심 구조가 널리 퍼졌다.
브라우저는 이 데이터를 받아 직접 화면을 구성하는 클라이언트 사이드 렌더링을 수행하며, React·Angular·Vue 같은 프레임워크가 이 흐름을 대표한다.
이 구조에서는 웹서버, 애플리케이션 서버, 데이터베이스가 더 분리된 n-Tier 구조를 이루기 쉬워진다.

11. 운영과 보안은 아키텍처 이해와 함께 봐야 한다 [50:01]

구조가 복잡해질수록 WAS의 JVM 상태, SQL 응답 시간, 병목 지점을 APM으로 추적해야 서비스 품질을 유지할 수 있다.
앞단에는 IPS, SSL 처리 구간, WAF 같은 보안 계층이 붙으며, 기능 구조와 운영 구조는 분리해서 볼 수 없는 관계가 된다.

12. 모놀리틱의 결정적 한계는 세션 공유와 수평 확장 문제다 [52:19]

로그인 후 사용자를 식별하는 세션 아이디는 대개 쿠키를 통해 전달되지만, 실제 상태는 서버 측 메모리나 저장소와 연결된다.
WAS를 여러 대로 늘리면 세션 정보가 서버마다 분산돼 사용자 상태를 일관되게 유지하기 어려워지고, 이 지점이 스케일아웃의 큰 장애물이 된다.
결국 현대 웹으로의 전환은 단순 유행이 아니라 상태 관리, 배포 분리, 확장성, 보안 대응을 동시에 풀기 위한 구조적 선택이라는 메시지로 마무리된다.

✅ 액션 아이템

현재 운영 중인 서비스 하나를 골라 웹서버, WAS, DB, 세션 저장 위치를 한 장의 다이어그램으로 나누고, “화면 문구 수정”, “로그인 정책 변경”, “DB 스키마 변경” 각각이 어느 배포 단위에 영향을 주는지 표시한다.
로그인 기능이 있는 샘플 애플리케이션에서 브라우저의 폼 POST 요청, 서버 검증, 사용자 조회 SQL, 세션 생성, Set-Cookie 응답까지를 순서대로 캡처해 요청/응답 추적 문서를 만든다.
서버 사이드 렌더링 페이지 하나를 골라 동일 기능을 “서버 HTML 생성”과 “JSON API + 클라이언트 렌더링” 두 방식으로 나눴을 때 캐시 지점, 프론트 배포 독립성, 장애 전파 범위를 비교한다.
WAS 2대와 로드밸런서를 가정한 뒤 세션이 각 인스턴스 메모리에만 있을 때 발생하는 로그인 끊김 시나리오를 정리하고, Redis 세션 저장소 또는 무상태 토큰 방식 중 무엇이 더 맞는지 비교안을 작성한다.
현재 서비스의 운영 대시보드 초안에 JVM 메모리, GC 시간, p95 응답 시간, 주요 인증 SQL latency, SSL 종료 지점, WAF 배치 위치를 함께 넣어 아키텍처와 관측 지표를 연결한다.

❓ 열린 질문

세션을 외부 저장소로 빼면 수평 확장 문제는 완화되는데, 그 이후에도 모놀리틱을 계속 유지하기 어렵게 만드는 가장 큰 비용은 배포 결합인가, 데이터 스키마 결합인가, 조직 협업 병목인가?
JSP 기반 SSR이 지금도 살아남는 환경에서는 사용자 경험 열세보다 운영 단순성과 낮은 변경 비용이 더 중요하다는 뜻인데, 그 임계점은 트래픽 규모보다 제품 변경 빈도에서 갈리는가?
JSON API와 클라이언트 렌더링이 기본값처럼 보이지만, SEO·초기 로딩·권한 처리·복잡한 상태 동기화까지 합치면 어느 조건에서 다시 SSR 또는 하이브리드 구조가 더 경제적인가?
입력 검증, 세션 처리, WAF, APM까지 모두 보강해도 모놀리틱의 본질적 리스크가 남는다면, 실제 전환 판단의 신호는 성능 저하보다 “변경 속도 저하”에서 먼저 나타나는가?

한 장의 그림으로 이해하는 모놀리식 3-Tier 웹 서비스 구조