[RBF] 2025-03-14

[Yumi-Park996]

Java 웹 애플리케이션 배포 교안 - 1장: 전체적인 흐름 개요

1. Java 웹 애플리케이션 배포란?

---

Java 웹 애플리케이션 배포는 개발자가 만든 애플리케이션을 서버에 올려 사용자가 접근할 수 있도록 만드는 과정이다.

배포 과정은 여러 단계로 이루어지며, Servlet → Tomcat → Docker → Render 순으로 진행된다.

각 단계가 역할을 분담하면서 안정적이고 효율적인 실행 환경을 제공한다.

💡 예제 상황:

예를 들어, 사용자가 웹사이트에서 "로그인" 버튼을 클릭했다고 하자. 이 요청이 어떻게 처리되어 화면에 결과가 나타나는지 살펴보겠다.

---

2. Java 웹 애플리케이션 배포 전체 흐름

📌 사용자가 웹사이트에 접속하면 요청이 아래 단계를 거친다.

1️⃣ 클라이언트 (웹 브라우저)에서 요청 발생

• 사용자가 www.example.com/login 페이지에 접속하면 브라우저는 HTTP 요청을 보낸다.
• 이 요청은 서버에서 특정 데이터를 요청하거나, 새로운 정보를 저장하려는 목적을 가진다.

2️⃣ Servlet (Java 애플리케이션의 핵심 역할)

• 웹 브라우저의 요청이 Java 애플리케이션의 Servlet으로 전달된다.
• Servlet은 비즈니스 로직을 실행한다. 예를 들어:
  • 로그인 요청이면 사용자가 입력한 아이디와 비밀번호를 검증한다.
  • 데이터베이스에서 정보를 가져와 사용자의 로그인 여부를 판단한다.
• 결과에 따라 응답 데이터를 생성한다. (예: 로그인 성공 시 사용자 프로필 페이지 반환)

3️⃣ Tomcat (WAS, 애플리케이션 실행 및 관리)

• Servlet을 실행하는 서버 역할을 하는 것이 Tomcat이다.
• Tomcat은 HTTP 요청을 처리하고, Servlet을 실행하며, 웹 애플리케이션을 관리한다.
• 즉, 사용자가 보낸 요청이 올바르게 애플리케이션 내부에서 처리될 수 있도록 돕는 역할을 한다.

4️⃣ Docker (운영 환경을 컨테이너화하여 배포 안정성 보장)

• Tomcat이 애플리케이션을 실행하고 나면, 이를 Docker 컨테이너로 패키징한다.
• Docker는 애플리케이션이 실행되는 환경을 하나의 컨테이너에 포함시켜,
  • 개발 환경과 운영 환경을 동일하게 만들고,
  • 배포 오류를 방지한다.

✅ 왜 Docker가 필요할까?

• 개발 환경에서는 Java 17, Tomcat 10을 사용했는데, 운영 서버에는 Java 8, Tomcat 9이 있다면?
  → 버전 차이로 인해 애플리케이션이 정상적으로 실행되지 않을 수 있음
• Docker를 사용하면, 애플리케이션 실행에 필요한 모든 환경을 포함한 패키지를 만들 수 있다.
  → 어디서든 같은 환경에서 실행 가능

5️⃣ Render (최종 배포 및 실행, URL 제공)

• Docker로 패키징된 애플리케이션을 클라우드 서버에서 실행할 수 있도록 돕는 것이 Render이다.
• Render는 컨테이너를 실행하고, 외부에서 접속할 수 있도록 URL을 제공한다.
  • 즉, 사용자가 www.example.com에 접속하면,
  • Render가 애플리케이션을 실행하고,
  • 최종적으로 웹사이트 화면을 브라우저에 출력한다.

✅ 왜 Render를 사용하나?

• 직접 서버를 구축하지 않고 손쉽게 배포 가능
• 자동으로 SSL 인증서 제공 → https:// 보안 접속 가능
• 무료 플랜이 있어 스타트업에서도 쉽게 사용 가능

---

마무리 요약

1. Java 웹 애플리케이션 배포란?
   • 개발자가 만든 애플리케이션을 서버에 올려, 사용자가 접속할 수 있도록 만드는 과정.
2. 배포 과정은?
   • 클라이언트 요청 → Servlet (비즈니스 로직) → Tomcat (실행 및 관리) → Docker (환경 일관성 유지) → Render (최종 배포 및 실행).
3. 각 단계가 필요한 이유?
   • Servlet: 사용자의 요청을 받아 처리하고 응답 반환
   • Tomcat: 애플리케이션을 실행하고 관리
   • Docker: 개발 환경과 운영 환경을 동일하게 유지
   • Render: 쉽게 배포하고 URL을 제공하여 최종 서비스 실행

✅ 결론:

이 과정을 거치면 안정적으로 애플리케이션을 실행하고, 어디서든 동일한 환경에서 배포할 수 있다.

[Yumi-Park996]

Java 웹 애플리케이션 배포 교안 - 2장: Servlet

1. Servlet이란?

Servlet은 Java에서 클라이언트(웹 브라우저)의 요청을 처리하고 응답을 생성하는 핵심 기술이다.

• Java EE 표준 기술이며, 웹 애플리케이션에서 클라이언트 요청을 처리하는 역할을 담당한다.
• 웹 서버(Tomcat 등)에서 실행되며, HTTP 요청을 받아서 비즈니스 로직을 수행한 후 응답을 반환한다.
• Java 기반의 웹 애플리케이션에서 필수적인 요소이며, 동적인 웹 페이지를 구현하는 데 사용된다.

2. Servlet의 역할

역할	설명
HTTP 요청 처리	클라이언트(브라우저)가 보낸 GET, POST 요청을 수신
비즈니스 로직 수행	요청을 분석하고 필요한 데이터를 가공
응답 생성 및 반환	HTML, JSON 등의 응답을 생성하여 클라이언트에 반환

3. Servlet의 동작 과정

1. 클라이언트(브라우저)가 특정 URL로 HTTP 요청을 보낸다.
2. 요청이 Servlet 컨테이너(Tomcat) 로 전달된다.
3. Servlet 컨테이너는 요청된 URL과 매핑된 Servlet을 찾아 실행한다.
4. Servlet이 요청을 분석하고 필요한 비즈니스 로직을 수행한다.
5. 처리된 결과를 HTML, JSON 등으로 변환하여 클라이언트에게 응답한다.

4. Servlet 컨테이너가 요청을 처리할 Servlet을 찾는 방법

1. URL 매핑 확인

   • web.xml 설정 파일에서 <servlet-mapping> 태그를 사용하여 URL과 Servlet을 연결할 수 있다.
   • 또는 @WebServlet("/경로") 어노테이션을 사용하여 URL과 특정 Servlet을 매핑할 수 있다.
   • 예시:

     <servlet>
         <servlet-name>ExampleServlet</servlet-name>
         <servlet-class>com.example.ExampleServlet</servlet-class>
     </servlet>
     <servlet-mapping>
         <servlet-name>ExampleServlet</servlet-name>
         <url-pattern>/example</url-pattern>
     </servlet-mapping>

     또는

     @WebServlet("/example")
     public class ExampleServlet extends HttpServlet {
         ...
     }

2. 매칭된 Servlet 검색

   • Servlet 컨테이너는 요청된 URL과 등록된 Servlet 목록을 비교한다.
   • 위 예제에서 /example 경로로 요청이 들어오면 ExampleServlet이 실행된다.

3. Servlet 실행

   • 매칭된 Servlet이 있으면, Servlet 컨테이너가 해당 Servlet의 service() 메서드를 호출한다.
   • HTTP 요청 방식(GET, POST 등)에 따라 doGet() 또는 doPost() 메서드를 실행하여 요청을 처리한다.

4. Servlet이 응답 생성 후 반환

   • Servlet은 클라이언트 요청을 처리한 후 응답을 생성한다.
   • 응답은 HTML, JSON, XML 등으로 생성할 수 있으며, response.getWriter().write(...)를 통해 출력된다.

Servlet 동작 흐름도

+------------------+        +------------------+        +-----------------+
|  클라이언트     | -----> |  Servlet 컨테이너 | -----> |   Servlet 실행  |
|  (브라우저)     |        |  (Tomcat)        |        | (비즈니스 로직)  |
+------------------+        +------------------+        +-----------------+
         |                           |
         |                           V
         |                 +----------------+
         |                 |   응답 생성     |
         |                 | (HTML, JSON 등) |
         |                 +----------------+
         V
   브라우저에서 결과 확인

5. Servlet의 한계점

1. HTML과 Java 코드가 혼합될 경우 유지보수가 어려움

   • Servlet 내부에서 직접 HTML을 생성할 경우, 코드가 복잡해지고 유지보수가 어렵다.
   • 해결 방법: JSP(Java Server Pages)와 같은 기술을 활용하여 View(화면) 부분을 분리하는 것이 일반적이다.

2. 매 요청마다 Servlet 객체를 생성하는 것은 비효율적

   • Servlet은 기본적으로 싱글톤 패턴으로 동작한다. 즉, 한 개의 Servlet 객체가 여러 요청을 처리한다.
   • 요청마다 새로운 Servlet 인스턴스를 생성하지 않고, 기존 인스턴스를 재사용하여 성능을 최적화한다.

6. 정리

• Servlet은 Java 웹 애플리케이션에서 클라이언트 요청을 처리하는 핵심 기술이다.
• Tomcat과 같은 웹 애플리케이션 서버에서 실행되며, 클라이언트의 요청을 받아 응답을 생성하는 역할을 수행한다.
• Servlet 컨테이너는 URL과 매핑된 Servlet을 찾아 요청을 처리한다.
• Servlet은 기본적으로 싱글톤 방식으로 동작하며, 멀티스레드 환경에서 주의해야 한다.
• HTML과 Java가 혼합될 경우 유지보수가 어려우므로, JSP와 같은 View 기술과 함께 사용하는 것이 일반적이다.

[Yumi-Park996]

Java 웹 애플리케이션 배포 교안 - 3장: Tomcat

1. Tomcat이란?

Tomcat은 Java 웹 애플리케이션을 실행하기 위한 웹 애플리케이션 서버(WAS, Web Application Server) 이다.

• Servlet과 JSP(Java Server Pages)를 실행할 수 있도록 지원하는 오픈 소스 서버이다.
• 클라이언트(브라우저)로부터 HTTP 요청을 받아 Servlet을 실행하고, 응답을 반환하는 역할을 한다.
• Java 웹 애플리케이션을 개발할 때 필수적인 서버 환경이다.

2. Servlet과 Tomcat의 관계 및 차이점

Servlet과 Tomcat은 밀접한 관계가 있지만, 각자의 역할이 다르다.

구분	Servlet	Tomcat
역할	클라이언트 요청을 처리하고 응답을 반환하는 Java 프로그램	Servlet을 실행할 수 있는 환경을 제공하는 서버
실행 위치	Tomcat과 같은 WAS 내에서 실행됨	웹 애플리케이션을 구동하고 Servlet을 실행함
개발 방식	개발자가 직접 구현해야 함	Servlet을 실행할 수 있도록 관리함
동작 방식	HTTP 요청을 받아 Java 코드로 처리 후 응답 반환	HTTP 요청을 받아 Servlet에 전달하고 실행

Servlet과 Tomcat의 관계

1. 클라이언트가 http://localhost:8080/example과 같은 URL로 요청을 보냄.
2. Tomcat이 HTTP 요청을 받아서 내부 Servlet 컨테이너로 전달.
3. Servlet 컨테이너는 URL 매핑을 확인하고 적절한 Servlet을 실행.
4. Servlet이 비즈니스 로직을 수행하고 응답을 생성.
5. Tomcat이 응답을 클라이언트(브라우저)에게 반환.

Servlet과 Tomcat의 관계 흐름도

+------------------+        +---------------+        +-----------------+
|  클라이언트     | -----> |   Tomcat      | -----> |   Servlet 실행  |
|  (브라우저)     |        |  (요청 수신)  |        | (비즈니스 로직)  |
+------------------+        +---------------+        +-----------------+
         |                           |
         |                           V
         |                 +----------------+
         |                 |   응답 생성     |
         |                 | (HTML, JSON 등) |
         |                 +----------------+
         V
   브라우저에서 결과 확인

3. Tomcat의 한계점

1. 대용량 트래픽 처리에 한계

   • 기본적으로 싱글 프로세스 기반이므로, 많은 요청이 들어오면 성능 저하가 발생할 수 있음.
   • 해결 방법: Apache HTTP Server 또는 Nginx와 연동하여 로드 밸런싱 수행.

2. 고급 기능 부족

   • Tomcat은 WAS이지만, JBoss, WebLogic, WebSphere 같은 풀 기능 WAS에 비해 기능이 제한적임.
   • 트랜잭션 관리, EJB(Enterprise Java Beans) 같은 고급 기능이 필요하다면 추가적인 설정이 필요함.

4. 정리

• Tomcat은 Java 웹 애플리케이션을 실행하는 웹 애플리케이션 서버(WAS)이다.
• HTTP 요청을 받아 Servlet을 실행하고, 처리된 결과를 클라이언트에게 응답으로 반환한다.
• 대량의 트래픽을 감당하기 어려우므로, 고성능 서비스에서는 Nginx와 같은 웹 서버와 함께 사용된다.

[Yumi-Park996]

Java 웹 애플리케이션 배포 교안 - 4장: Docker

1. Docker란?

Docker는 애플리케이션 실행 환경을 컨테이너(Container)라는 단위로 패키징하여 어디서든 동일한 환경에서 실행할 수 있도록 해주는 기술이다.

• 애플리케이션과 실행에 필요한 모든 환경(OS, 라이브러리, 의존성 등)을 하나의 패키지로 묶어 제공한다.
• 개발 환경과 운영 환경을 일관되게 유지할 수 있어, 배포 및 운영 안정성이 증가한다.
• 가상 머신(VM)보다 가볍고 빠르며, 리소스를 효율적으로 사용할 수 있다.

2. Docker의 역할

역할	설명
애플리케이션 컨테이너화	애플리케이션과 필요한 환경을 컨테이너로 패키징하여 실행
개발 및 운영 환경 일관성 유지	개발 환경, 테스트 환경, 운영 환경을 동일하게 유지하여 배포 오류 방지
리소스 효율성 증대	가상 머신보다 가벼운 컨테이너 기술로 서버 자원을 절약
빠른 배포 및 확장성	컨테이너 이미지를 기반으로 빠르게 배포 및 확장이 가능

3. Docker의 동작 과정 (End-to-End 흐름 포함)

사용자의 요청
      ↓
  [클라이언트 (브라우저)]
      ↓ HTTP 요청
  [Servlet (Java)]
      ↓ 비즈니스 로직 실행
  [Tomcat (WAS)]
      ↓ 애플리케이션 실행 및 관리
  [Docker 컨테이너화]
      ↓ 환경 일관성 유지
  [Render 배포]
      ↓ URL 제공 및 서비스 실행
  사용자 응답

1단계: 애플리케이션 개발 및 Servlet 실행

• 클라이언트(브라우저)가 특정 URL을 통해 서버에 HTTP 요청을 보낸다.
• Java 기반 웹 애플리케이션에서 Servlet이 요청을 받아 비즈니스 로직을 처리한다.
• Servlet은 필요한 데이터를 처리하고 클라이언트에 응답을 반환한다.
• 이 모든 과정이 Tomcat(웹 애플리케이션 서버) 내에서 실행된다.

2단계: Dockerfile 작성

• 개발된 Java 애플리케이션과 실행에 필요한 환경을 정의하는 Dockerfile을 작성한다.
• Dockerfile에는 다음과 같은 요소가 포함된다:
  • 운영체제: 컨테이너 내부에서 사용할 OS 지정 (예: Ubuntu, Alpine Linux).
  • 필수 패키지 설치: Tomcat, Java, 애플리케이션이 실행되는 데 필요한 패키지 포함.
  • 애플리케이션 코드 추가: Java 코드, 빌드된 .war 또는 .jar 파일을 컨테이너 내부로 복사.
  • 포트 설정: 클라이언트가 접근할 수 있도록 Tomcat의 포트를 오픈(예: 8080).
  • 실행 명령어: 컨테이너가 시작되면 Tomcat이 실행되도록 설정.

3단계: Docker 이미지 빌드

• 작성된 Dockerfile을 기반으로 실행 환경을 패키징한 Docker 이미지를 생성한다.
• 이미지에는 운영체제, Java 환경, Tomcat, 애플리케이션 코드가 포함되어 있다.
• 생성된 이미지는 Docker Hub 또는 내부 저장소에 업로드할 수 있다.
• 이 이미지를 통해 개발 환경, 테스트 환경, 운영 환경이 일관되게 유지된다.

4단계: Docker 컨테이너 실행 (이 단계에서는 사용자 응답이 반환되지 않음)

• 빌드된 이미지를 실행하면 새로운 컨테이너가 생성된다.
• 컨테이너는 실행 중인 프로세스로, 격리된 환경에서 Java 애플리케이션이 실행된다.
• 컨테이너 내부에서는 Tomcat이 실행되며, 클라이언트의 HTTP 요청을 처리할 준비가 된다.
• 동일한 이미지를 기반으로 여러 개의 컨테이너를 실행하여 부하 분산이 가능하다.
• 이 단계에서는 컨테이너가 로컬에서 실행될 뿐, 클라이언트가 직접 접근할 수 없다.

5단계: 컨테이너 배포 (이후 사용자 응답이 반환됨)

• 실행 중인 컨테이너를 클라우드 플랫폼(Render, AWS, GCP 등)에 배포하여 운영 환경에서 실행할 수 있도록 한다.
• 배포된 컨테이너는 클라우드에서 지속적으로 실행되며, 사용자의 요청을 처리한다.
• 필요할 경우 자동 확장(스케일링) 이 가능하며, 장애 발생 시 새로운 컨테이너를 생성하여 교체할 수 있다.
• 이 단계에서 클라이언트는 브라우저를 통해 URL을 입력하고 애플리케이션에 접근할 수 있다.
• 사용자의 요청이 들어오면, 클라우드 서버에서 실행 중인 컨테이너가 요청을 받아 Servlet이 응답을 반환한다.

Docker의 파일, 이미지, 컨테이너의 차이

개념	설명
Dockerfile (파일)	컨테이너를 생성하기 위한 설정 파일. 운영체제, 패키지, 실행 명령어 등을 정의.
Docker Image (이미지)	Dockerfile을 기반으로 생성된 실행 환경의 패키지. 실행할 준비가 된 상태.
Docker Container (컨테이너)	Docker 이미지를 실행한 인스턴스. 애플리케이션이 실제로 동작하는 환경.

• Dockerfile → 실행 환경을 정의하는 텍스트 파일.
• Docker 이미지 → Dockerfile을 빌드하여 생성된, 실행 가능한 패키지.
• Docker 컨테이너 → Docker 이미지를 실행한 상태. 실제로 애플리케이션이 동작하는 환경.

Docker 기반 End-to-End 배포 흐름도

1. 개발자가 애플리케이션을 개발하고 Servlet을 구현한다.
2. Tomcat 환경에서 실행되도록 애플리케이션을 빌드한다.
3. Dockerfile을 작성하여 실행 환경을 정의한다.
4. Docker 이미지로 패키징하여 저장소에 업로드한다.
5. Docker 이미지를 실행하여 컨테이너를 생성한다.
6. 클라우드(Render, AWS, GCP)로 배포하여 운영 환경에서 실행한다.
7. 사용자가 웹을 통해 애플리케이션에 접근한다.
8. 컨테이너가 요청을 받아 Servlet이 처리하고 응답을 반환한다.

4. 정리

• Docker 컨테이너가 실행된다고 해서 즉시 사용자가 접근할 수 있는 것은 아니다.
• 5단계에서 클라우드에 배포되어야 클라이언트가 URL을 통해 접근할 수 있다.
• Dockerfile은 실행 환경을 정의하는 파일, Docker 이미지는 실행 가능한 패키지, 컨테이너는 실제 실행 환경이다.
• 컨테이너 기반 배포 방식은 운영 환경과 개발 환경을 일관되게 유지하는 데 필수적이다.

[Yumi-Park996]

Java 웹 애플리케이션 배포 교안 - 6장: Render와 Kubernetes의 차이

1. Render와 Kubernetes란?

Render와 Kubernetes는 모두 컨테이너 기반의 애플리케이션 배포를 지원하는 기술이지만, 사용 목적과 대상이 다르다.

• Render는 스타트업, 개인 개발자, 소규모 프로젝트를 위한 간편한 배포 플랫폼이다. 사용자가 복잡한 서버 설정을 하지 않아도 쉽게 애플리케이션을 배포할 수 있도록 돕는다.
• Kubernetes는 대규모 애플리케이션을 위한 컨테이너 오케스트레이션 시스템이다. 복잡한 네트워크 환경에서 다수의 컨테이너를 관리하고 확장할 수 있도록 설계되었다.

2. Render와 Kubernetes의 차이점

Render의 특징 (간편한 배포 플랫폼)

Render는 사용자가 직접 서버를 설정하지 않아도 컨테이너 기반 애플리케이션을 손쉽게 배포할 수 있도록 해준다. 웹 대시보드나 간단한 설정만으로 애플리케이션을 실행할 수 있으며, 운영 및 유지보수를 자동으로 처리해준다.

• 설정이 간단함 → 몇 번의 클릭만으로 배포 가능.
• 자동 HTTPS 제공 → 별도 설정 없이 보안 인증서 적용.
• 서버 유지보수 필요 없음 → Render가 인프라를 자동으로 관리.
• CI/CD 내장 → GitHub와 연동하여 코드 변경 사항이 자동으로 배포됨.
• 비용 효율적 → 사용한 만큼 비용이 부과되며, 무료 플랜도 제공됨.
• 스타트업과 개인 개발자에게 적합 → 빠른 배포가 필요한 경우 유용.

Kubernetes의 특징 (대규모 컨테이너 관리 시스템)

Kubernetes는 수천 개 이상의 컨테이너를 효과적으로 운영하기 위한 시스템이다. 다양한 환경에서 컨테이너 기반 애플리케이션을 확장하고 자동으로 조정할 수 있다.

• 대규모 서비스 운영 가능 → 다수의 컨테이너를 동시에 실행하고 관리 가능.
• 고급 네트워크 및 보안 설정 가능 → 역할 기반 접근 제어(RBAC), 네트워크 정책 등을 통해 세부적인 보안 설정 가능.
• 수동 설정 필요 → 클러스터 구성, 네트워크 설정, 노드 추가 등 복잡한 운영이 요구됨.
• CI/CD 연동 필요 → GitHub Actions 같은 내장 기능이 없으며, Jenkins, ArgoCD 등의 외부 도구와 연동해야 함.
• 기업용 서비스 운영에 적합 → 엔터프라이즈 환경에서 트래픽이 많고 높은 가용성이 요구되는 경우 유용.

3. Render와 Kubernetes의 장단점 비교

✅ Render의 장점

• 배포가 쉽고 빠름 → 초보자도 쉽게 사용할 수 있음.
• 별도의 서버 유지보수 불필요 → Render가 모든 인프라를 관리.
• 자동 HTTPS 적용 → 기본적으로 보안이 설정됨.
• CI/CD 기본 제공 → 코드 변경 사항이 자동으로 배포됨.
• 비용 절감 가능 → 사용량에 따라 비용이 부과되며, 작은 규모에서는 경제적임.

⚠️ Render의 단점

• 대규모 트래픽 처리 어려움 → 확장성에 한계가 있음.
• 사용자가 인프라를 직접 제어할 수 없음 → 세부적인 설정이 불가능함.
• 기업 환경에서 사용하기 어려움 → 특정 네트워크 및 보안 요구 사항을 충족하기 어려움.

✅ Kubernetes의 장점

• 수천 개 이상의 컨테이너 관리 가능 → 대규모 서비스 운영에 적합.
• 유연한 설정 가능 → 다양한 인프라 환경에 맞게 조정할 수 있음.
• 고급 보안 설정 가능 → RBAC, 네트워크 정책 등을 세부적으로 조정할 수 있음.
• 멀티 클러스터 지원 → 여러 개의 데이터 센터에서 서비스를 분산 운영 가능.

⚠️ Kubernetes의 단점

• 설정이 복잡함 → 클러스터 관리, 네트워크 설정, CI/CD 연동 등이 필요.
• 운영 및 유지보수 비용이 발생함 → 클라우드 비용 및 관리 인력이 필요함.
• 초기 구축이 어려움 → 구축 단계에서 많은 리소스와 시간이 요구됨.

4. Render와 Kubernetes의 선택 기준

조건	Render 선택	Kubernetes 선택
설정이 쉬운 배포 환경이 필요함	✅	❌
인프라 운영을 직접 관리하고 싶지 않음	✅	❌
수천 개 이상의 컨테이너를 운영해야 함	❌	✅
고급 네트워크 및 보안 설정이 필요함	❌	✅
CI/CD 자동화가 기본 제공되는 환경이 필요함	✅	❌
엔터프라이즈급 확장성이 필요함	❌	✅