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

▶️ 유튜브

• 원본 링크: https://youtu.be/2cWEh4xSXL0?si=s1NOCSxWT5ZVCswZ

🖼️ 4컷 인포그래픽

💡 한 줄 결론

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

📌 핵심 요점

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

🧠 상세 요약

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까지 모두 보강해도 모놀리틱의 본질적 리스크가 남는다면, 실제 전환 판단의 신호는 성능 저하보다 “변경 속도 저하”에서 먼저 나타나는가?