다음을 통해 공유

API 게이트웨이 패턴과 직접 클라이언트-마이크로 서비스 통신 비교

팁 (조언)

이 콘텐츠는 .NET Docs 또는 오프라인으로 읽을 수 있는 다운로드 가능한 무료 PDF로 제공되는 컨테이너화된 .NET 애플리케이션용 .NET 마이크로 서비스 아키텍처인 eBook에서 발췌한 내용입니다.

PDF 다운로드

컨테이너화된 .NET 애플리케이션을 위한 .NET 마이크로서비스 아키텍처 eBook의 표지 썸네일.

마이크로 서비스 아키텍처에서 각 마이크로 서비스는 (일반적으로) 세분화된 엔드포인트 집합을 노출합니다. 이 사실은 이 섹션에 설명된 대로 클라이언트-마이크로 서비스 통신에 영향을 미칠 수 있습니다.

직접적인 클라이언트-마이크로서비스 통신

가능한 방법은 직접 클라이언트-마이크로 서비스 통신 아키텍처를 사용하는 것입니다. 이 방법에서 클라이언트 앱은 그림 4-12와 같이 일부 마이크로 서비스에 직접 요청할 수 있습니다.

클라이언트-마이크로 서비스 통신 아키텍처를 보여 주는 다이어그램

그림 4-12. 직접 클라이언트-마이크로 서비스 통신 아키텍처 사용

이 방법에서 각 마이크로 서비스에는 퍼블릭 엔드포인트가 있으며, 때로는 각 마이크로 서비스에 대해 다른 TCP 포트가 있는 경우도 있습니다. 특정 서비스에 대한 URL의 예는 Azure에서 다음 URL일 수 있습니다.

http://eshoponcontainers.westus.cloudapp.azure.com:88/

클러스터를 기반으로 하는 프로덕션 환경에서 해당 URL은 클러스터에서 사용되는 부하 분산 장치에 매핑되어 마이크로 서비스에 요청을 분산합니다. 프로덕션 환경에서는 마이크로 서비스와 인터넷 사이에 Azure Application Gateway 와 같은 ADC(애플리케이션 배달 컨트롤러)가 있을 수 있습니다. 이 계층은 부하 분산을 수행할 뿐만 아니라 SSL 종료를 제공하여 서비스를 보호하는 투명한 계층 역할을 합니다. 이 방법은 CPU 집약적 SSL 종료 및 기타 라우팅 업무를 Azure Application Gateway로 오프로드하여 호스트의 부하를 향상시킵니다. 어쨌든 부하 분산 장치 및 ADC는 논리적 애플리케이션 아키텍처 관점에서 투명합니다.

특히 클라이언트 앱이 ASP.NET MVC 앱과 같은 서버 쪽 웹 애플리케이션인 경우, 직접 클라이언트-마이크로 서비스 통신 아키텍처는 작은 마이크로 서비스 기반 애플리케이션에 충분할 수 있습니다. 그러나 크고 복잡한 마이크로 서비스 기반 애플리케이션(예: 수십 개의 마이크로 서비스 유형을 처리할 때)을 빌드하는 경우, 특히 클라이언트 앱이 원격 모바일 앱 또는 SPA 웹 애플리케이션인 경우 이러한 접근 방식은 몇 가지 문제에 직면합니다.

마이크로 서비스를 기반으로 대규모 애플리케이션을 개발할 때 다음 질문을 고려합니다.

  • 클라이언트 앱은 백 엔드에 대한 요청 수를 최소화하고 여러 마이크로 서비스에 대한 번잡한 통신을 줄이려면 어떻게 해야 하나요?

여러 마이크로 서비스와 상호 작용하여 단일 UI 화면을 빌드하면 인터넷을 통해 왕복 횟수가 증가합니다. 이 방법은 UI 쪽에서 대기 시간 및 복잡성을 증가합니다. 이상적으로 응답은 서버 쪽에서 효율적으로 집계되어야 합니다. 이 방법은 여러 데이터 조각이 병렬로 돌아오고 일부 UI가 준비되는 즉시 데이터를 표시할 수 있으므로 대기 시간을 줄입니다.

  • 권한 부여, 데이터 변환 및 동적 요청 디스패치와 같은 횡단 관심사를 어떻게 처리할 수 있나요?

모든 마이크로 서비스에서 보안 및 권한 부여와 같은 보안 및 교차 절단 문제를 구현하려면 상당한 개발 노력이 필요할 수 있습니다. 가능한 방법은 Docker 호스트 또는 내부 클러스터 내에서 이러한 서비스를 사용하여 외부에서 직접 액세스를 제한하고 API 게이트웨이와 같은 중앙 집중식 위치에서 이러한 교차 절단 문제를 구현하는 것입니다.

  • 클라이언트 앱은 인터넷이 아닌 프로토콜을 사용하는 서비스와 어떻게 통신할 수 있나요?

서버 쪽에서 사용되는 프로토콜(예: AMQP 또는 이진 프로토콜)은 클라이언트 앱에서 지원되지 않습니다. 따라서 요청은 HTTP/HTTPS와 같은 프로토콜을 통해 수행되고 나중에 다른 프로토콜로 변환되어야 합니다. 맨 인 더 미들 접근 방식은 이 상황에서 도움이 될 수 있습니다.

  • 모바일 앱에 대해 특별히 만들어진 외관을 어떻게 형성할 수 있나요?

여러 마이크로 서비스의 API는 다른 클라이언트 애플리케이션의 요구 사항에 맞게 잘 설계되지 않을 수 있습니다. 예를 들어 모바일 앱의 요구 사항이 웹앱의 요구 사항과 다를 수 있습니다. 모바일 앱의 경우 데이터 응답이 더 효율적일 수 있도록 더욱 최적화해야 할 수 있습니다. 여러 마이크로 서비스에서 데이터를 집계하고 단일 데이터 집합을 반환하고 경우에 따라 모바일 앱에서 필요하지 않은 응답의 데이터를 제거하여 이 기능을 수행할 수 있습니다. 물론 해당 데이터를 압축할 수도 있습니다. 모바일 앱과 마이크로 서비스 간의 외관 또는 API는 이 시나리오에 편리할 수 있습니다.

직접 클라이언트-마이크로 서비스 통신 대신 API 게이트웨이를 고려하는 이유

마이크로 서비스 아키텍처에서 클라이언트 앱은 일반적으로 둘 이상의 마이크로 서비스에서 기능을 사용해야 합니다. 해당 사용이 직접 수행되는 경우 클라이언트는 마이크로 서비스 엔드포인트에 대한 여러 호출을 처리해야 합니다. 애플리케이션이 발전하고 새 마이크로 서비스가 도입되거나 기존 마이크로 서비스가 업데이트되면 어떻게 되나요? 애플리케이션에 마이크로 서비스가 많은 경우 클라이언트 앱에서 너무 많은 엔드포인트를 처리하는 것은 악몽일 수 있습니다. 클라이언트 앱은 이러한 내부 엔드포인트와 결합되므로 나중에 마이크로 서비스가 발전하면 클라이언트 앱에 큰 영향을 줄 수 있습니다.

따라서 중간 수준 또는 간접 참조 계층(게이트웨이)을 갖는 것은 마이크로 서비스 기반 애플리케이션에 편리할 수 있습니다. API 게이트웨이가 없는 경우 클라이언트 앱은 마이크로 서비스에 직접 요청을 보내야 하며 다음과 같은 문제가 발생합니다.

  • 결합: API 게이트웨이 패턴이 없으면 클라이언트 앱이 내부 마이크로 서비스에 결합됩니다. 클라이언트 앱은 애플리케이션의 여러 영역이 마이크로 서비스에서 어떻게 분해되는지 알아야 합니다. 내부 마이크로 서비스를 발전시키고 리팩터링할 때 이러한 작업은 클라이언트 앱의 내부 마이크로 서비스에 대한 직접 참조로 인해 클라이언트 앱에 호환성이 손상되는 변경이 발생하므로 유지 관리에 영향을 줍니다. 클라이언트 앱을 자주 업데이트해야 하므로 솔루션의 발전이 더 어려워집니다.

  • 너무 많은 왕복: 클라이언트 앱의 단일 페이지/화면에 여러 서비스에 대한 여러 호출이 필요할 수 있습니다. 이러한 접근 방식으로 인해 클라이언트와 서버 간에 여러 네트워크 왕복이 발생하여 대기 시간이 상당히 늘어나게 될 수 있습니다. 중간 수준에서 처리되는 집계는 클라이언트 앱의 성능 및 사용자 환경을 향상시킬 수 있습니다.

  • 보안 문제: 게이트웨이가 없으면 모든 마이크로 서비스가 "외부 세계"에 노출되어야 하므로 클라이언트 앱에서 직접 사용하지 않는 내부 마이크로 서비스를 숨기는 경우보다 공격 표면이 커집니다. 공격 표면이 작을수록 애플리케이션의 보안이 더 안전해질 수 있습니다.

  • 횡단적 관심사: 공개적으로 게시된 각 마이크로 서비스는 권한 관리와 SSL과 같은 사항을 처리해야 합니다. 대부분의 경우 이러한 문제를 단일 계층에서 처리하여 내부 마이크로 서비스가 간소화될 수 있습니다.

API 게이트웨이 패턴이란?

여러 클라이언트 앱을 사용하여 크거나 복잡한 마이크로 서비스 기반 애플리케이션을 디자인하고 빌드할 때는 API 게이트웨이를 고려하는 것이 좋습니다. 이 패턴은 특정 마이크로 서비스 그룹에 대한 단일 진입점을 제공하는 서비스입니다. 개체 지향 디자인의 외관 패턴 과 유사하지만 이 경우 분산 시스템의 일부입니다. API 게이트웨이 패턴은 클라이언트 앱의 요구 사항을 고려하면서 빌드하기 때문에 "프런트 엔드 백 엔드"(BFF)라고도 합니다.

따라서 API 게이트웨이는 클라이언트 앱과 마이크로 서비스 사이에 있습니다. 클라이언트에서 서비스로 요청을 라우팅하는 역방향 프록시로 사용됩니다. 인증, SSL 종료 처리, 캐시와 같은 범용 기능도 제공할 수 있습니다.

그림 4-13에서는 사용자 지정 API 게이트웨이가 몇 개의 마이크로 서비스만으로 간소화된 마이크로 서비스 기반 아키텍처에 어떻게 부합하는지 보여 줍니다.

사용자 지정 서비스로 구현된 API 게이트웨이를 보여 주는 다이어그램

그림 4-13. 사용자 지정 서비스로 구현된 API 게이트웨이 사용

앱은 개별 마이크로 서비스에 요청을 전달하도록 구성된 단일 엔드포인트인 API 게이트웨이에 연결합니다. 이 예제에서 API 게이트웨이는 컨테이너로 실행되는 사용자 지정 ASP.NET Core WebHost 서비스로 구현됩니다.

이 다이어그램에서는 여러 클라이언트 앱에 연결된 단일 사용자 지정 API 게이트웨이 서비스를 사용한다는 점을 강조해야 합니다. API 게이트웨이 서비스는 클라이언트 앱의 다양한 요구 사항에 따라 성장하고 발전할 것이기 때문에 이러한 사실은 중요한 위험이 될 수 있습니다. 결국, 이러한 다양한 요구 사항으로 인해 부풀어 오르고 효과적으로 모놀리식 애플리케이션 또는 모놀리식 서비스와 유사할 수 있습니다. 따라서 클라이언트 앱 폼 팩터 유형당 하나씩 여러 서비스 또는 여러 개의 작은 API 게이트웨이에서 API 게이트웨이를 분할하는 것이 매우 좋습니다.

API 게이트웨이 패턴을 구현할 때는 주의해야 합니다. 일반적으로 애플리케이션의 모든 내부 마이크로 서비스를 집계하는 단일 API 게이트웨이를 사용하는 것은 좋지 않습니다. 이 경우 모놀리식 집계 또는 오케스트레이터 역할을 하며 모든 마이크로 서비스를 결합하여 마이크로 서비스 자율성을 위반합니다.

따라서 API 게이트웨이는 비즈니스 경계 및 클라이언트 앱에 따라 분리되어야 하며 모든 내부 마이크로 서비스에 대한 단일 집계 역할을 하지 않아야 합니다.

API 게이트웨이 계층을 여러 API 게이트웨이로 분할하는 경우 애플리케이션에 여러 클라이언트 앱이 있는 경우 여러 API 게이트웨이 유형을 식별할 때 기본 피벗이 될 수 있으므로 각 클라이언트 앱의 요구 사항에 대해 다른 외관을 가질 수 있습니다. 이 사례는 'Backend for Frontend'(BFF)라 불리는 패턴으로, 다음 이미지에서 보여지듯이, 각 API 게이트웨이는 각각의 클라이언트 앱 유형 또는 장치 유형에 맞춰 조정된 다른 API를 제공할 수 있습니다. 이는, 특정 어댑터 코드를 구현함으로써 가능하며, 이러한 코드가 여러 내부 마이크로서비스 호출을 수행합니다.

여러 사용자 지정 API 게이트웨이를 보여 주는 다이어그램

그림 4-13.1. 여러 사용자 지정 API 게이트웨이 사용

그림 4-13.1은 클라이언트 유형별로 분리된 API 게이트웨이를 보여 줍니다. 하나는 모바일 클라이언트용이고 다른 하나는 웹 클라이언트용입니다. 기존 웹앱은 웹 API 게이트웨이를 사용하는 MVC 마이크로 서비스에 연결합니다. 이 예제에서는 세분화된 여러 API 게이트웨이가 있는 간소화된 아키텍처를 보여 줍니다. 이 경우 각 API 게이트웨이에 대해 식별되는 경계는 전적으로 "BFF(백 엔드 for Frontend) 패턴"을 기반으로 하므로 클라이언트 앱당 필요한 API를 기반으로 합니다. 그러나 더 큰 애플리케이션에서는 더 나아가 비즈니스 경계를 기반으로 다른 API 게이트웨이를 두 번째 디자인 피벗으로 만들어야 합니다.

API 게이트웨이 패턴의 주요 기능

API 게이트웨이는 여러 기능을 제공할 수 있습니다. 제품에 따라 더 풍부하거나 간단한 기능을 제공할 수 있지만 API 게이트웨이에 대한 가장 중요하고 기본적인 기능은 다음과 같은 디자인 패턴입니다.

역방향 프록시 또는 게이트웨이 라우팅. API 게이트웨이는 내부 마이크로 서비스의 엔드포인트로 요청을 리디렉션하거나 라우팅하는 역방향 프록시(계층 7 라우팅, 일반적으로 HTTP 요청)를 제공합니다. 게이트웨이는 클라이언트 앱에 대한 단일 엔드포인트 또는 URL을 제공하고 내부적으로 요청을 내부 마이크로 서비스 그룹에 매핑합니다. 이 라우팅 기능은 마이크로 서비스에서 클라이언트 앱을 분리하는 데 도움이 되지만, 모놀리식 API와 클라이언트 앱 사이에 API 게이트웨이를 설치하여 모놀리식 API를 현대화할 때도 편리합니다. 그런 다음 나중에 여러 마이크로 서비스로 분할될 때까지 레거시 모놀리식 API를 계속 사용하는 동안 새 API를 새 마이크로 서비스로 추가할 수 있습니다. API 게이트웨이로 인해 클라이언트 앱은 사용되는 API가 내부 마이크로 서비스 또는 모놀리식 API로 구현되는지 여부를 알지 못하며, 더 중요한 것은 모놀리식 API를 마이크로 서비스로 발전시키고 리팩터링할 때 API 게이트웨이 라우팅 덕분에 클라이언트 앱은 URI 변경에 영향을 받지 않습니다.

자세한 내용은 게이트웨이 라우팅 패턴을 참조하세요.

집계를 요청합니다. 게이트웨이 패턴의 일부로 여러 내부 마이크로 서비스를 대상으로 하는 여러 클라이언트 요청(일반적으로 HTTP 요청)을 단일 클라이언트 요청으로 집계할 수 있습니다. 이 패턴은 클라이언트 페이지/화면에 여러 마이크로 서비스의 정보가 필요한 경우에 특히 편리합니다. 이 방법을 사용하면 클라이언트 앱은 내부 마이크로 서비스에 여러 요청을 디스패치한 다음 결과를 집계하고 모든 것을 클라이언트 앱으로 다시 보내는 단일 요청을 API 게이트웨이에 보냅니다. 이 디자인 패턴의 주요 이점과 목표는 클라이언트 앱과 백 엔드 API 간의 수다를 줄이는 것입니다. 이는 모바일 앱 또는 클라이언트 원격 브라우저의 JavaScript에서 제공되는 SPA 앱에서 들어오는 요청과 같이 마이크로 서비스가 상주하는 데이터 센터의 원격 앱에 특히 중요합니다. 서버 환경(예: ASP.NET Core MVC 웹앱)에서 요청을 수행하는 일반 웹앱의 경우 대기 시간이 원격 클라이언트 앱보다 훨씬 작기 때문에 이 패턴은 중요하지 않습니다.

사용하는 API 게이트웨이 제품에 따라 이 집계를 수행할 수 있습니다. 그러나 대부분의 경우 API 게이트웨이 범위에서 집계 마이크로 서비스를 만드는 것이 더 유연하므로 코드(즉, C# 코드)에서 집계를 정의합니다.

자세한 내용은 게이트웨이 집계 패턴을 참조하세요.

교차적 관심사 또는 게이트웨이 부하 분산. 각 API 게이트웨이 제품에서 제공하는 기능에 따라 개별 마이크로 서비스에서 게이트웨이로 기능을 오프로드할 수 있으며, 이를 통해 교차 절단 문제를 하나의 계층으로 통합하여 각 마이크로 서비스의 구현을 간소화할 수 있습니다. 이 방법은 다음 기능과 같은 모든 내부 마이크로 서비스에서 제대로 구현하기 위해 복잡할 수 있는 특수한 기능에 특히 편리합니다.

  • 인증 및 권한 부여
  • 서비스 검색 통합
  • 응답 캐싱
  • 재시도 정책, 회로 차단기 및 QoS
  • 속도 제한 및 트래픽 제어
  • 부하 분산
  • 로깅, 추적, 상관 관계
  • 헤더, 쿼리 문자열 및 클레임 변환
  • IP 허용 목록화

자세한 내용은 게이트웨이 오프로드 패턴을 참조하세요.

API 게이트웨이 기능과 함께 제품 사용

각 구현에 따라 API 게이트웨이 제품에서 제공하는 더 많은 횡단 관심사가 있을 수 있습니다. 여기서는 다음을 살펴보겠습니다.

Azure API Management

Azure API Management (그림 4-14 참조)는 API 게이트웨이 요구 사항을 해결할 뿐만 아니라 API에서 인사이트 수집과 같은 기능을 제공합니다. API Management 솔루션을 사용하는 경우 API 게이트웨이는 전체 API 관리 솔루션 내의 구성 요소일 뿐입니다.

Azure API Management를 API 게이트웨이로 사용하는 방법을 보여 주는 다이어그램

그림 4-14. API 게이트웨이에 Azure API Management 사용

Azure API Management는 로깅, 보안, 계량 등과 같은 API 게이트웨이 및 관리 요구 사항을 모두 해결합니다. 이 경우 Azure API Management와 같은 제품을 사용하는 경우 이러한 종류의 API 게이트웨이가 "더 얇기"때문에 단일 API 게이트웨이가 있을 수 있다는 사실은 위험하지 않습니다. 즉, 모놀리식 구성 요소로 발전할 수 있는 사용자 지정 C# 코드를 구현하지 않습니다.

API 게이트웨이 제품은 일반적으로 수신 통신을 위한 역방향 프록시처럼 작동하며, 내부 마이크로 서비스에서 API를 필터링하고 이 단일 계층의 게시된 API에 권한 부여를 적용할 수도 있습니다.

API Management 시스템에서 사용할 수 있는 인사이트를 통해 API가 사용되는 방식과 API의 성능을 파악할 수 있습니다. 근 실시간 분석 보고서를 보고 비즈니스에 영향을 미칠 수 있는 추세를 식별하여 이 작업을 수행합니다. 또한 추가 온라인 및 오프라인 분석을 위해 요청 및 응답 활동에 대한 로그를 가질 수 있습니다.

Azure API Management를 사용하면 키, 토큰 및 IP 필터링을 사용하여 API를 보호할 수 있습니다. 이러한 기능을 사용하면 유연하고 세분화된 할당량 및 속도 제한을 적용하고, 정책을 사용하여 API의 모양과 동작을 수정하고, 응답 캐싱을 사용하여 성능을 향상시킬 수 있습니다.

이 가이드 및 참조 샘플 애플리케이션(eShopOnContainers)에서 아키텍처는 Azure API Management와 같은 PaaS 제품을 사용하지 않고 일반 컨테이너에 집중하기 위해 더 간단하고 사용자 지정으로 만든 컨테이너화된 아키텍처로 제한됩니다. 그러나 Microsoft Azure에 배포되는 대규모 마이크로 서비스 기반 애플리케이션의 경우 프로덕션 환경에서 API 게이트웨이의 기반으로 Azure API Management를 평가하는 것이 좋습니다.

오실롯

Ocelot 은 간단한 접근 방식에 권장되는 간단한 API 게이트웨이입니다. Ocelot은 시스템에 통합된 진입점이 필요한 마이크로 서비스 아키텍처용으로 특별히 만들어진 오픈 소스 .NET Core 기반 API 게이트웨이입니다. 가볍고 빠르며 확장성이 뛰어난 이 기능은 다른 많은 기능들 사이에서 라우팅 및 인증을 제공합니다.

eShopOnContainers 참조 애플리케이션 2.0에 Ocelot을 선택하는 주된 이유는 Ocelot이 Docker 호스트, Kubernetes 등과 같은 마이크로 서비스/컨테이너를 배포하는 동일한 애플리케이션 배포 환경에 배포할 수 있는 .NET Core 경량 API 게이트웨이이기 때문입니다. .NET Core를 기반으로 하므로 플랫폼 간을 통해 Linux 또는 Windows에 배포할 수 있습니다.

컨테이너에서 실행되는 사용자 지정 API 게이트웨이를 보여 주는 이전 다이어그램은 컨테이너 및 마이크로 서비스 기반 애플리케이션에서 Ocelot을 실행할 수 있는 방법을 정확하게 보여 줍니다.

또한 Apigee, Kong, MuleSoft, WSO2 및 서비스 메시 수신 컨트롤러 기능을 위한 링커드 및 Istio와 같은 다른 제품과 같은 API 게이트웨이 기능을 제공하는 다른 많은 제품이 시장에 있습니다.

초기 아키텍처 및 패턴 설명 섹션 후 다음 섹션에서는 Ocelot을 사용하여 API 게이트웨이를 구현하는 방법을 설명합니다.

API 게이트웨이 패턴의 단점

  • 가장 중요한 단점은 API 게이트웨이를 구현할 때 해당 계층을 내부 마이크로 서비스와 결합한다는 것입니다. 이와 같이 결합하면 애플리케이션에 심각한 문제가 발생할 수 있습니다. Azure Service Bus 팀의 설계자 인 Clemens Vaster는 GOTO 2016의 "메시징 및 마이크로 서비스" 세션에서 이러한 잠재적 어려움을 "새로운 ESB"라고 부릅니다.

  • 마이크로 서비스 API 게이트웨이를 사용하면 가능한 단일 실패 지점이 추가로 생성됩니다.

  • API 게이트웨이는 추가 네트워크 호출로 인해 응답 시간이 증가할 수 있습니다. 하지만 이 추가 호출은 일반적으로 내부 마이크로서비스를 직접 너무 자주 호출하는 수다스러운 클라이언트 인터페이스로 인한 영향보다 적습니다.

  • 제대로 확장되지 않으면 API 게이트웨이가 병목 상태가 될 수 있습니다.

  • API 게이트웨이에는 사용자 지정 논리 및 데이터 집계가 포함된 경우 추가 개발 비용 및 향후 유지 관리가 필요합니다. 개발자는 각 마이크로 서비스의 엔드포인트를 노출하기 위해 API 게이트웨이를 업데이트해야 합니다. 또한 내부 마이크로 서비스의 구현 변경으로 인해 API 게이트웨이 수준에서 코드가 변경될 수 있습니다. 그러나 API 게이트웨이가 보안, 로깅 및 버전 관리만 적용하는 경우(Azure API Management를 사용하는 경우와 같이) 이 추가 개발 비용이 적용되지 않을 수 있습니다.

  • 단일 팀에서 API 게이트웨이를 개발하는 경우 개발 병목 현상이 발생할 수 있습니다. 이 측면은 다른 클라이언트 요구 사항에 대응하는 몇 가지 세분화된 API 게이트웨이를 사용하는 것이 더 나은 또 다른 이유입니다. 내부 마이크로 서비스에서 작업하는 다른 팀이 소유한 여러 영역 또는 계층으로 API 게이트웨이를 내부적으로 분리할 수도 있습니다.

추가 리소스

이전다음