반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
스토리지 관리
예방 점검
APM Solution
애플리케이션 관리
URL 관리
브라우저 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
AI 인공지능
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
브레인즈컴퍼니 ‘2023 소프트웨어대전’ 참가
클라우드(Cloud) 관리와 AWS가 뭔가요?
이운형
2023.11.16
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[행사] 브레인즈컴퍼니 전략사업본부 ‘happy 호프데이’
오늘날 IT 인프라 운영환경은 매우 복잡해졌어요. 갑작스러운 환경 변화에 따라 신속한 대응도 필요한 시점이죠. 이러한 현상으로 많은 기업들이
온프레미스(On-premise) 환경에서 클라우드(Cloud) 환경으로 전환하는 추세
이기도 해요.
클라우드 컴퓨팅 서비스 중에는 여러 벤더가 있는데요. 대표적으론 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)가 있어요.
그중 ‘AWS’는 국내 클라우드 시장에서 3년 간 70% 내외의 시장점유율로, 1위를 차지했는데요
(*클라우드 서비스 분야 실태조사(2022), 공정거래위원회)
이처럼 높은 점유율을 가진
1) AWS의 주요 서비스를 살펴보고 2) 하이브리드 클라우드 모니터링이 필요한 이유는 무엇인지 3) AWS의 각종 서비스를 모니터링할 수 있는 제니우스(Zenius)
도 함께 소개해 드릴게요!
AWS(Amazon Web Services)란?
AWS는 ‘Amazon Web Services’의 약어로, 아마존 닷컴이 제공하는 클라우드 컴퓨팅 플랫폼 및 서비스의 집합이에요. AWS에서 제공하는 여러 가지 서비스를 이용하면, 기업 및 개인이 필요한 컴퓨팅 리소스를 유연하게 확장하고 관리할 수 있죠. AWS 주요 서비스는 다음과 같아요!
AWS 주요 서비스
▪
Amazon VPC
(Amazon Virtual Private Cloud)
격리된 네트워크 환경을 구성하게 해주는 서비스예요. AWS의 동일 계정이나, 서로 다른 계정 간에 격리된 네트워크를 연결할 수 있도록 다양한 옵션들을 제공해 줘요.
▪
Amazon EC2
(Amazon Elastic Compute Cloud)
AWS에서 가장 많이 사용되는 컴퓨팅 서비스예요. 가상 서버를 호스팅 할 때 사용하죠. 리눅스나 윈도우 환경 등 다양한 인스턴스 유형을 지원하고, 필요에 따라 성능을 조정할 수 있어요. 생성 가능한 인스턴스 타입은 리전 별 차이가 있으나, 100개~300개에 이를 정도로 방대하답니다.
▪AWS Lambda
AWS에서 제공하는 서버리스 컴퓨팅 플랫폼이에요. 여기서 ‘서버리스’란 개발자가 서버의 존재를 신경 쓸 필요가 없다는 뜻이에요. AWS에서는 서버 인프라에 대한 프로비저닝, 유지관리 등을 대신 처리해 주죠. 이처럼 개발자가 비즈니스 로직에 집중하여 코드를 실행하게 해줘요.
▪Amazon S3
AWS에서 제공하는 스토리지 서비스예요. S3는 파일시스템이 아닌 오브젝트 스토리지 서비스로, 모든 파일에 API를 통해 접근 가능해요. 무제한적인 확장성, 높은 가용성과 내구성을 제공하며 단일 파일을 최대 5TB까지 업로드할 수 있어요.
▪Amazon EBS
(Amazon Elastic Block Store)
EC2 인스턴스에 장착하여 사용할 수 있는 가상 저장 장치에요. EBS를 연결하여 파일을 저장하면, EC2 인스턴스와 관계없이 데이터를 영구적으로 보관 가능해요. 이 밖에도 AWS에서 제공하는 서비스는 매우 방대한대요. 아래 URL로 접속 시, 필요한 서비스 목록 확인이 가능하답니다!
?
더 많은 AWS 서비스가 궁금하다면?
온프레미스와 AWS의 차이
온프레미스 방식은, 클라우드 컴퓨팅 서비스가 나오기 전까지 기업에서 전통적으로 사용한 ‘일반적인 인프라 구축 방식’이에요. 온프레미스 환경에서 서버를 운영하면, 호스팅 서비스를 이용하거나 서버를 직접 구매 또는 임대하죠. 그다음 데이터 센터(IDC, Internet Data Center) 또는 기업 전산실에 설치하여 운영해요.
하지만 물리적인 서버를 직접 설치할 경우, 많은 시간과 비용이 소모되어 이를 위한 운영 공간과 인력이 필요할 수 있어요.
예시를 들어 볼게요. 대형 콘서트 예매, 대학교 수강신청, 입시 원서 접수 등 단기간에 트래픽이 급증했다가 감소되는 경우를 생각해 볼까요? 이때 ‘온프레미스 방식’으로 시스템을 구축한다면, 매우 많은 비용 낭비가 발생하게 될 거예요.
반면 AWS의 경우는 어떨까요? 인터넷이 연결된 어디에서든 쉽게 인프라를 구축하고, 사용한 만큼 비용을 지불할 수 있어요. 큰 이벤트를 처리한 후 생성된 리소스를 간편하게 삭제할 수 있죠. 이처럼 온프레미스 방식과 대비한다면, 남는 자원에 대한 비용 고민이 없어지겠죠?
하이브리드 클라우드 모니터링이 필요한 이유
이처럼 AWS는 매우 유연하고 확장성 있는 클라우드 서비스예요. 하지만 모든 서비스를 AWS를 이용해서 서비스하는 것은 한계가 있는데요. 이유는 다음과 같아요.
▪보안 및 규정 준수
민감한 데이터나 규정 준수가 필요한 업무의 경우, 사설 클라우드나 온프레미스 환경의 자체 데이터 센터를 통해 운영하려는 경향이 있어요.
▪비용 효율
AWS는 사용한 만큼 비용을 지불하기 때문에, 예측할 수 없는 트래픽 증가 등에 대응하기에 좋아요. 하지만 서비스에 따라 온프레미스 환경에서 운영하는 것이 비용 측면에서 더 효율적인 경우가 있죠.
이처럼 많은 기업이 AWS를 이용한 클라우드 서비스로 전환하는 추세지만, 당분간 온프레미스 방식과 결합한 하이브리드 클라우드 운영환경이 많은 편이에요.
그렇다면 이러한 하이브리드 클라우드 운영 환경을 모니터링할 수 있는 방법이 없을까요? 바로
‘제니우스’를 활용한다면
가능해요!
제니우스를 이용한 하이브리드 클라우드 모니터링 구성도
제니우스 하이브리드 클라우드 모니터링 프로세스를 간략히 소개할게요!
우선
클라우드 환경
단계에서는 AWS 서비스를 이용하여 구축된 클라우드 환경 정보를 RestAPI 방식으로 수집해요.
CMS Manager
는 AWS 클라우드 환경에서 수집한 정보를 취합 후 스토리지에 저장해 주죠.
EMS Manager
는 온프레미스 환경에서 수집한 정보를 취합 후 스토리지에 저장해 줘요.
Web UI
에서는 스토리지에 저장된 데이터를 이용하여, 사용자에게 모니터링 정보를 제공한답니다!
제니우스에서 AWS 모니터링하기
제니우스를 이용한 ‘하이브리드 클라우드 모니터링 구성’을 좀 더 자세히 살펴볼까요?
▪CMS > 모니터링 > 요약 :
위 그림은
AWS 통합 요약
페이지인데요. EC2, RDS, VPC 등 과금 현황까지 통합 모니터링할 수 있어요.
▪EMS > 토폴로지 > 클라우드 맵 :
리전 별 자동 구성형 클라우드 맵 페이지에서는, AWS 리전 별 이용하는 서비스와 연관관계를 클라우드 맵이 자동으로 구성해 줘요.
▪
CMS > 클라우드서비스 > EC2 > 주요 성능 지표 :
주요 성능지표 모니터링
페이지에서는 AWS 콘솔에 접속하지 않고, AWS 주요 성능 지표에 대한 모니터링 추이를 확인할 수 있어요.
▪EMS > 오버뷰 :
오버뷰를 통한 온프레미스 + AWS 통합 모니터링
페이지에서는, AWS 모니터링 항목과 온프레미스 환경 모니터링 항목의 통합 현황판을 확인할 수 있어요.
이처럼 AWS와 온프레미스 환경은 물론, 더 다양한 환경의 인프라 모니터링을 위해 제니우스를 사용을 해보는 건 어떨까요?
#클라우드
#AWS
#Cloud
#브레인즈컴퍼니
#클라우드컴퓨팅
#제니우스
#AWS클라우드
#하이브리드클라우드
이운형
Technical Consulting팀
Technical Consulting팀에서 제품구축과 유지보수 업무를 수행하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
IT 인프라 모니터링 시스템의 컨트롤러 개선기, ArgumentResolver를 통한 중복 제거
IT 인프라 모니터링 시스템의 컨트롤러 개선기, ArgumentResolver를 통한 중복 제거
대규모 IT 인프라를 모니터링하는 도메인에서는 서버나 네트워크 장비와 같은 관리 대상을 통칭하여 타겟(Target)이라고 부릅니다. 이에 따라 대다수의 API는 리소스 식별을 위해 URL 경로(Path Variable)나 쿼리 스트링(Query Parameter)을 통해 targetId를 필수적으로 전달받는 구조를 가지고 있습니다. 이 targetId는 단순한 문자열 식별자가 아니라, 실제 비즈니스 로직이 수행되기 전 반드시 선행되어야 하는 일련의 검증 절차를 요구합니다. 구체적으로는 클라이언트 입력값에 대한 유효성 검사, 해당 ID를 기반으로 한 DB 조회 및 도메인 객체(TargetInfoRecord)로의 매핑, 그리고 해당 타겟에 대한 사용자 접근 권한(Authorization) 확인 과정이 포함됩니다. 프로젝트 초기 구현 단계에서는 이러한 전처리 로직을 각 컨트롤러 메서드 바디 상단에 직접 구현하는 방식을 취했습니다. 하지만 API 엔드포인트가 수십 개로 늘어남에 따라, 동일한 검증 코드가 여러 컨트롤러에 산재하게 되는 구조적 문제가 발생했습니다. 이는 단순한 코드 중복(Boilerplate Code)을 넘어, 타겟 검증 정책이 변경될 때마다 관련된 모든 API를 수정해야 하는 유지보수의 취약점으로 이어졌습니다. 또한 비즈니스 로직과 검증 로직이 한 곳에 혼재됨에 따라 코드의 가독성이 저하되고, 수정 과정에서 누락이 발생할 경우 장애로 직결될 위험이 높습니다. 반복되는 검증 로직과 분산된 수정 포인트(N개의 지점) 문제를 근본적으로 해결하기 위해, 다음과 같은 명확한 엔지니어링 목표를 수립했습니다. “타겟 검증, 변환을 메서드 파라미터 주입 시점에 끝낸다.” Spring MVC는 이미 @PathVariable, @RequestParam, @AuthenticationPrincipal과 같이 요청 데이터를 가공하여 컨트롤러 메서드 파라미터에 바인딩하는 표준화된 메커니즘을 제공하고 있습니다. 이 아키텍처 패턴에 착안하여, [ URL에서 타겟 ID 추출 → 유효성 검증 → 도메인 객체 변환 ]으로 이어지는 일련의 과정을 비즈니스 로직 진입 전인 '파라미터 주입 단계'에서 완결짓도록 HandlerMethodArgumentResolver를 적용했습니다. 이 아키텍처를 실제 코드로 구현하기 위해, 프로세스를 크게 세 가지 단계로 나누어 진행했습니다. 메타데이터 정의 (Annotation): 어떤 파라미터를 검증할지 식별하고 정책을 부여 로직 구현 (Resolver & Helper): 실제 값을 추출하고 도메인 객체로 변환하는 바인딩 로직 작성 설정 등록 (Configuration): Spring MVC가 해당 리졸버를 인식하도록 설정 가장 먼저, 컨트롤러 파라미터에 검증 요구사항을 명시할 커스텀 어노테이션을 정의합니다. 1. 커스텀 어노테이션 정의 - @ToTargetInfoRecords 구현의 첫 단계로, 파라미터에 메타데이터를 부여할 커스텀 어노테이션을 정의합니다. 타겟에 대한 모든 정보를 TargetInfoRecord라는 도메인 객체로 캡슐화하여 관리하고 있습니다. 따라서 '해당 파라미터를 TargetInfoRecord 객체로 변환하라'는 명시적인 의미를 담아 @ToTargetInfoRecords라는 어노테이션을 설계했습니다. 이 어노테이션은 런타임 시점에 Resolver가 식별할 수 있어야 하므로 RUNTIME 정책을 사용하며, 파라미터 레벨에 적용되도록 타겟을 한정했습니다. - VALUE_PARAMETER로 메서드 파라미터에서만 사용하도록 제한합니다. - RUNTIME 보존으로 요청 처리 시점에 리졸버가 어노테이션 값을 읽습니다. 2. ArgumentResolver 구현 다음으로 Spring MVC의 HandlerMethodArgumentResolver 인터페이스를 구현하여 실질적인 바인딩 로직을 처리하는 ToTargetInfoRecordResolver를 작성합니다. HandlerMethodArgumentResolver를 상속한 ToTargetInfoRecordsResolver를 생성합니다. 3. 리졸버 등록 방법 구현한 리졸버가 실제로 동작하기 위해서는 Spring MVC의 Argument Resolver 체인에 등록해야 합니다. WebMvcConfigurer를 구현하여 우리가 만든 리졸버를 추가해주면, 이후 들어오는 요청에 대해 Spring이 자동으로 개입하게 됩니다. 이 리졸버를 등록한 후에 클라이언트로부터 요청이 들어오면, 컨트롤러 메서드 호출 직전에 파라미터 단위로 다음 순서가 진행됩니다. 1. Spring이 컨트롤러 메서드의 각 파라미터에 대해 등록된 리졸버 리스트를 순서대로 확인합니다. 2. supportsParameter(...)가 true인 첫 번째 리졸버를 선택합니다. 3. 선택된 리졸버의 resolveArgument(...)를 호출하여 값을 만들고, 그 반환값을 해당 파라미터에 주입합니다. 자세한 구현은 다음과 같습니다. 1) 어떤 파라미터를 내가 담당하는가 — supportsParameter 파라미터에 @ToTargetInfoRecords가 붙어 있으면 자신의 책임으로 판단합니다. 2) 값을 어떻게 만들고 주입하는가 — resolveArgument 3) URL에서 값은 어떻게 추출하는가 — 쿼리 vs 경로 - 쿼리스트링은 webRequest.getParameterValues()로, 경로 변수 HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE로 추출합니다. - 메서드 파라미터 타입이 List인지도 구분하고 검증합니다. 이렇게 헬퍼 클래스를 통해 요청 위치나 데이터 타입에 구애받지 않고 무결성이 검증된 데이터가 준비되면, 변환된 객체가 마침내 컨트롤러 메소드의 파라미터에 주입됩니다. 결과적으로 컨트롤러는 HTTP 요청의 복잡한 세부 사항을 전혀 모른 채, 안전하게 가공된 도메인 객체를 즉시 사용할 수 있게 됩니다. 실제 적용 사례 가장 눈에 띄는 변화는 컨트롤러의 간결함입니다. 기존에는 비즈니스 로직과 섞여 있던 '타겟 ID 추출', '유효성 검사', '도메인 변환', '권한 체크' 등의 횡단 관심사(Cross-cutting Concerns)가 완벽하게 분리되었습니다. 덕분에 개발자는 신규 API를 작성할 때 불필요한 반복 코드(Boilerplate)를 작성하는 수고를 덜고, 핵심 비즈니스 로직 구현에만 온전히 집중할 수 있게 되었습니다. 또한, 유지보수 측면에서도 강력한 이점을 가집니다. 만약 타겟 검증 정책이 변경되더라도 수십 개의 컨트롤러를 일일이 수정할 필요 없이, ArgumentResolver의 로직 한 곳만 수정하면 전사적으로 변경 사항이 반영됩니다. 다수의 API에서 [URL로부터 값 추출 → 검증 → 도메인 객체 변환]의 패턴이 반복되는 프로젝트라면, HandlerMethodArgumentResolver를 적극적으로 도입하여 코드의 품질과 생산성을 높여보시는 것을 권장합니다.
2026.02.06
Spring MVC: 반복되는 검증 로직 한 번에 끝내기
Spring MVC: 반복되는 검증 로직 한 번에 끝내기
인프라 관리 도메인에서 API 설계 시 가장 빈번하게 등장하는 파라미터는 단연 targetId입니다. 하지만 이 식별자는 비즈니스 로직이 실행되기 전, 반드시 통과해야 하는 '삼중 관문'을 가지고 있습니다. 유효성 검사, 도메인 객체 변환, 그리고 권한 확인이 그것입니다. 초기 구현 단계에서는 이 관문들을 각 컨트롤러 메서드 내부에서 직접 제어하는 방식을 택했습니다. 하지만 인프라 규모가 커지고 API 엔드포인트가 늘어날수록, 이 직관적인 방식은 코드 중복과 유지보수 효율성 저하라는 아키텍처적 부채로 돌아오기 시작했습니다. API 엔드포인트가 수십 개로 늘어남에 따라, 동일한 검증 코드가 여러 컨트롤러에 산재하게 되는 구조적 문제가 발생했습니다. 이는 단순한 코드 중복(Boilerplate Code)을 넘어, 타겟 검증 정책이 변경될 때마다 관련된 모든 API를 수정해야 하는 유지보수의 취약점으로 이어졌습니다. 또한 비즈니스 로직과 검증 로직이 한 곳에 혼재됨에 따라 코드의 가독성이 저하되고, 수정 과정에서 누락이 발생할 경우 장애로 직결될 위험이 높습니다. 반복되는 검증 로직과 분산된 수정 포인트(N개의 지점) 문제를 근본적으로 해결하기 위해, 다음과 같은 명확한 엔지니어링 목표를 수립했습니다. “타겟 검증, 변환을 메서드 파라미터 주입 시점에 끝낸다” Spring MVC는 이미 @PathVariable, @RequestParam, @AuthenticationPrincipal과 같이 요청 데이터를 가공하여 컨트롤러 메서드 파라미터에 바인딩하는 표준화된 메커니즘을 제공하고 있습니다. 이 아키텍처 패턴에 착안하여, [ URL에서 타겟 ID 추출 → 유효성 검증 → 도메인 객체 변환 ]으로 이어지는 일련의 과정을 비즈니스 로직 진입 전인 '파라미터 주입 단계'에서 완결짓도록 HandlerMethodArgumentResolver를 적용했습니다. 이 아키텍처를 실제 코드로 구현하기 위해, 프로세스를 크게 세 가지 단계로 나누어 진행했습니다. 1. 메타데이터 정의 (Annotation): 어떤 파라미터를 검증할지 식별하고 정책을 부여 2. 로직 구현 (Resolver & Helper): 실제 값을 추출하고 도메인 객체로 변환하는 바인딩 로직 작성 3. 설정 등록 (Configuration): Spring MVC가 해당 리졸버를 인식하도록 설정 가장 먼저, 컨트롤러 파라미터에 검증 요구사항을 명시할 커스텀 어노테이션을 정의합니다. 1. 커스텀 어노테이션 정의 - @ToTargetInfoRecords 구현의 첫 단계로, 파라미터에 메타데이터를 부여할 커스텀 어노테이션을 정의합니다. 타겟에 대한 모든 정보를 TargetInfoRecord라는 도메인 객체로 캡슐화하여 관리하고 있습니다. 따라서 '해당 파라미터를 TargetInfoRecord 객체로 변환하라'는 명시적인 의미를 담아 @ToTargetInfoRecords라는 어노테이션을 설계했습니다. 이 어노테이션은 런타임 시점에 Resolver가 식별할 수 있어야 하므로 RUNTIME 정책을 사용하며, 파라미터 레벨에 적용되도록 타겟을 한정했습니다. - VALUE_PARAMETER로 메서드 파라미터에서만 사용하도록 제한합니다. - RUNTIME 보존으로 요청 처리 시점에 리졸버가 어노테이션 값을 읽습니다. 2. ArgumentResolver 구현 다음으로 Spring MVC의 HandlerMethodArgumentResolver 인터페이스를 구현하여 실질적인 바인딩 로직을 처리하는 ToTargetInfoRecordResolver를 작성합니다. HandlerMethodArgumentResolver를 상속한 ToTargetInfoRecordsResolver를 생성합니다. 3. 리졸버 등록 방법 구현한 리졸버가 실제로 동작하기 위해서는 Spring MVC의 Argument Resolver 체인에 등록해야 합니다. WebMvcConfigurer를 구현하여 우리가 만든 리졸버를 추가해주면, 이후 들어오는 요청에 대해 Spring이 자동으로 개입하게 됩니다. 이 리졸버를 등록한 후에 클라이언트로부터 요청이 들어오면, 컨트롤러 메서드 호출 직전에 파라미터 단위로 다음 순서가 진행됩니다. 1. Spring이 컨트롤러 메서드의 각 파라미터에 대해 등록된 리졸버 리스트를 순서대로 확인합니다. 2. supportsParameter(...)가 true인 첫 번째 리졸버를 선택합니다. 3. 선택된 리졸버의 resolveArgument(...)를 호출하여 값을 만들고, 그 반환값을 해당 파라미터에 주입합니다. 자세한 구현은 다음과 같습니다. 1) 어떤 파라미터를 내가 담당하는가 — supportsParameter 파라미터에 @ToTargetInfoRecords가 붙어 있으면 자신의 책임으로 판단합니다. 2) 값을 어떻게 만들고 주입하는가 — resolveArgument 3) URL에서 값은 어떻게 추출하는가 — 쿼리 vs 경로 - 쿼리스트링은 webRequest.getParameterValues()로, 경로 변수는HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE로 추출합니다. - 메서드 파라미터 타입이 List인지도 구분하고 검증합니다. 이렇게 헬퍼 클래스를 통해 요청 위치나 데이터 타입에 구애받지 않고 무결성이 검증된 데이터가 준비되면, 변환된 객체가 마침내 컨트롤러 메소드의 파라미터에 주입됩니다. 결과적으로 컨트롤러는 HTTP 요청의 복잡한 세부 사항을 전혀 모른 채, 안전하게 가공된 도메인 객체를 즉시 사용할 수 있게 됩니다. 실제 적용 사례 가장 눈에 띄는 변화는 컨트롤러의 간결함입니다. 기존에는 비즈니스 로직과 섞여 있던 '타겟 ID 추출', '유효성 검사', '도메인 변환', '권한 체크' 등의 횡단 관심사(Cross-cutting Concerns)가 완벽하게 분리되었습니다. 덕분에 개발자는 신규 API를 작성할 때 불필요한 반복 코드(Boilerplate)를 작성하는 수고를 덜고, 핵심 비즈니스 로직 구현에만 온전히 집중할 수 있게 되었습니다. 또한, 유지보수 측면에서도 강력한 이점을 가집니다. 만약 타겟 검증 정책이 변경되더라도 수십 개의 컨트롤러를 일일이 수정할 필요 없이, ArgumentResolver의 로직 한 곳만 수정하면 전사적으로 변경 사항이 반영됩니다. 다수의 API에서 [URL로부터 값 추출 → 검증 → 도메인 객체 변환]의 패턴이 반복되는 프로젝트라면, HandlerMethodArgumentResolver를 적극적으로 도입하여 코드의 품질과 생산성을 높여보시는 것을 권장합니다.
2026.03.06
다음 슬라이드 보기