보안에 대한 소유권을 조직 전체로 확대

Clarke: (00:05)
나와 주셔서 감사합니다.

Megan: (00:07)
당연히 나와야죠.

Clarke: (00:08)
이전 경력에 대한 내용과 AWS로 오게 된 과정을 말씀해 주시겠습니까?

Megan: (00:13)
15년이 넘는 기간 동안 다양한 보안 역할을 맡아왔습니다. 처음에는 한 병원에서 네트워크 보안 전문가로 일했습니다. 그 다음에는 시애틀 소재 글로벌 소매업체에서 다양한 보안 엔지니어링과 아키텍처 업무를 지원하는 일을 했습니다. 이 업체는 2014년에 AWS 고객이 되었는데, 그때 클라우드 보안 전략을 수립하고 보안 제어를 구현하는 일을 했습니다. 이후 Slalom에 입사했고 DevSecOps 팀에서 북미 전역의 고객을 도와 같은 일을 했습니다. 클라우드 보안 전략을 수립하고 보안 제어를 구현하는 일을 했지요. 그 후에 태평양 연안 북서부 지역의 엔터프라이즈 솔루션 아키텍트로 AWS에 들어와서 보안 전문가 팀에 합류했습니다.

Clarke: (01:02)
대단하군요.

Megan: (01:03)
이제 4년쯤 되었네요. 예.

Clarke: (01:04)
좋습니다.

Megan: (01:04)
감사합니다.

Clarke: (01:05)
처음에는 컴퓨터 공학과 관련된 일을 하신 것 같은데 보안에 끌린 이유는 무엇인가요?

Megan: (01:12)
흥미를 느꼈어요. 처음에는 기계공학 관련 진로를 선택했습니다. Boeing에서 여름 3개월간 인턴십에 참여하면서 767-400 라인의 툴링 엔지니어들과 함께 일하게 되었어요. 그때 엔지니어들에게 지금 학교를 간다면 무엇을 전공하겠느냐고 물었더니 컴퓨터 공학이라고 말하더군요 “괜찮네”라는 생각을 했는데, 다들 같은 대답을 했습니다. 그래서 제가 말했죠. “좋아요. 컴퓨터 보안이나 컴퓨터 공학 수업을 들어야겠어요.” 그런데 아주 좋아하게 되었어요. 정말 재미가 있었거든요. 퍼즐을 푸는 것 같더라고요.

Clarke: (01:47)
맞습니다.

Megan: (01:47)
학생 중 절반은 떨어져 나갔는데, 적성에 맞지 않았던 거죠. 그런데 저는 계속했어요. 선택 과정 중 하나가 디지털 보안이었는데 이름부터 너무 흥미롭게 들렸습니다. 이 과정을 듣고 나서 완전히 빠졌죠. 정말 흥미로웠거든요. 퍼즐을 푸는 것은 같은데 이 퍼즐이 계속해서 변하는 것이에요. 컴퓨터 공학을 전공하면서 4학년 때는 실제로 IDS를 구축하는 프로젝트를 진행했습니다. 네트워크 패킷 캡처를 분석하고 불법 네트워크 동작을 결정하는 작은 프로그램을 구축했어요. 정말 재미있었습니다.

Clarke: (02:21)
대단하군요. 그것이 멋진 직업으로 이어진 게 확실하네요.

Megan: (02:23)
예.

Clarke: (02:24)
AWS에서 수석 보안 솔루션스 아키텍처로 일하고 계신데, 어떤 의미가 있습니까? 이 역할에서 주로 어떤 책임을 맡고 계신가요?

Megan: (02:33)
AWS의 보안과 관련된 지원을 고객에게 제공합니다. 기반을 구축하고 가드레일을 설정하고 보안 제어를 구현하는 방법에 대한 지침을 제공하고 클라우드 운영 모델과 그 형태를 이해할 수 있도록 돕습니다. 이벤트에서 고객 교육을 지원하는 일도 합니다. 워크숍, 빌더 세션과 내부 현장 직원용 교육 프로그램을 만드는 일을 하는데, 내부 현장 에세이를 통해 보안의 다양한 측면을 교육하는 내부 프로그램을 제공하고 있습니다. 100 레벨 보안부터 300 레벨까지 프로그램을 이수하여 고객과 효과적으로 대화하는 방법을 배울 수 있습니다.

Clarke: (03:20)
AWS에는 강력한 보안 문화가 있고 이 문화를 강화하는 데 도움이 되는 다수의 메커니즘이 있는 것으로 알고 있는데요. 특별히 좋아하는 메커니즘이 있습니까?

Megan: (03:29)
물론입니다. Sev Two 제출 프로세스가 있습니다. 직위와 관계없이 보안 문제가 있다고 생각되면 티켓을 제출해야 하는데, 이 프로세스를 Sev Two라고 부릅니다. 티켓이 제출되면 이 프로세스의 반대편에 있는 보안 엔지니어가 해당 사안이 문제인지 여부를 평가하고 접수를 받습니다. 보안 문제가 아니어도 문제가 되지 않습니다. 좋지요. 비난을 받을 일이 없고요. 누구도 보안 문제를 걱정하지 않고 보안 문제로 인해 겁을 내지 않는 환경을 만드는 것이 핵심입니다. 보안 문제를 인지하고 올바르고 긍정적인 방법으로 보안 문제에 대응해야 합니다. 그리고 경영진 수준에서 이 프로세스를 지원합니다. 이렇게 하면 보안 교육을 하거나 경영진과 대화할 때 모두가 긍정적으로 생각하게 됩니다. 이러한 종류의 사고는 투명한 보안과 개방성이라는 독자적인 문화를 배양합니다. 저는 이 프로세스를 아주 높게 평가합니다.

Clarke: (04:44)
맞습니다. 고객 조직에서 다양한 직무를 맡은 여러 고객과 대화할 때 자체적인 보안 문화의 조성을 위해 특별히 장려하는 영역이 있습니까? 비난 없는 보안 문화처럼요?

Megan: (05:01)
물론입니다. 몇 가지 영역이 있는데요. 보안 팀을 비즈니스 지원 팀, 개발자 지원 팀처럼 운영할 것을 장려합니다. 일을 쉽게 할 수 있고 보안 관점에서 옳은 일을 할 수 있도록 돕는 것입니다. 올바른 모델 안에서 보안 요구 사항을 투명하게 파악하고 장애물에 부딪히는 일 없이 속도를 낼 수 있도록 길을 닦아주는 것과 같아요. 이러한 지원이 있으면 보안과 개발이 적절한 균형을 이루게 되고 그 균형 안에서 서로 협력할 수 있습니다. 고객 회사에서 그 이점을 실현하는 것을 보면 아주 기쁩니다. 여러 건의 고객 사례에서 분명히 확인했고요. 이렇게 하면 보안 측면에서 운영 방식이 개선되고 개발 측면에서는 협력 하에 서로를 도울 수 있습니다.

Clarke: (06:00)
“안돼요”라고 말하는 부서가 아니라 실제로 도움을 주고 성공을 지원하는 부서가 되라는 말씀이군요.

Megan: (06:05)
예. 맞습니다.

Clarke: (06:07)
고객 경영진 관점에서 이러한 보안 문화를 조성하고 고객 관계를 구축하기 위해 고위 경영진이 할 수 있는 일은 무엇일까요?

Megan: (06:20)
지금은 예전과는 많이 다릅니다. 보안은 이제 보안 팀만의 책임이 아닙니다. 개발자도 많은 부분을 책임져야 해요. 고객에게 “AWS에는 AWS와 고객이 보안을 공동으로 책임진다”는 점을 자주 알려주는데, 다양한 보안 제어와 클라우드의 보안 측면에 대한 공동 책임 모델을 나머지 조직으로 확장하고 모두의 책임을 투명하게 알려주어야 합니다.

Clarke: (06:53)
맞습니다.

Megan: (06:53)
그리고 이러한 일을 쉽게 할 수 있고 올바르게 할 수 있도록 지원해야 하죠. 공동 책임 모델을 자체 조직 내에서 확장하면 모두가 효과적인 방법을 알 수 있게 됩니다.

Clarke: (07:05)
대단하군요. 충분한 수의 보안 전문가를 두지 못한 고객이 많을 것 같은데요. 보안 팀에서 고객 조직의 나머지 부분으로 주력 영역을 확장하고 영향력을 확대하기 위해 할 수 있는 일은 무엇일까요?

Megan: (07:22)
몇 가지가 있습니다. 우선, 업무에 적합한 실무자를 항상 찾을 수 있는 것은 아닙니다. 그래서 때로는 시야를 조금 넓혀서 생각해봐야 해요. “클라우드를 모르지만 관심이 있는 보안 직원이 있다면 일을 시켜보세요”라고 말하죠. 개발자나 DevOps 직원 중에 보안에 관심이 있지만 해당 배경이 없는 직원이 있다면 일을 한 번 시켜보는 것입니다. 필요한 교육을 제공하고요. 도구를 사용할 수도 있습니다. 제가 즐겨 사용하는 방법 중 하나는 이전 re:Invent 동영상인 re:Inforce를 보는 것인데요. 보안 기초 모범 사례에 대한 30분~45분짜리 세션이 있습니다. 고객 사례를 구체적으로 보여주는 동영상도 많이 있어요. 이러한 동영상은 고정된 틀을 벗어나서 생각하는 데 도움이 됩니다. 또한 AWS Solutions Architect Associate 또는 Professional 자격증은 기초 개념을 다지기에 아주 좋은 방법입니다. 물론 Security Specialist 자격증도 좋고요.

Clarke: (08:39)
지난 18개월은 모두에게 힘든 시기였죠. 팬데믹을 겪으면서 많은 분들이 재택 근무로 전환했는데, 팬데믹으로 인해 클라우드 도입이 늘거나 줄었습니까? 고객을 만나보면 어떻습니까?

Megan: (08:54)
물론입니다. 몇몇 큰 고객은 변화에 대응하기 위해 클라우드 도입을 늘려야 했습니다. 온라인 소매 비즈니스의 경우 상점들이 문을 닫아야 했기 때문에 폭발적으로 성장했습니다. 여기서 흥미로운 패턴을 찾았고 다른 고객에게 적용할 수 있는 교훈을 얻었습니다. 기초적인 초기 보안과 다중 계정을 구축할 때 사용할 수 있는 방법과 관련해서요. 자동화를 활용하면 아주 효과적이라는 것입니다. 더 많은 계정을 구축하고 자동화를 구현할 수 있거든요. 이러한 업체는 이미 자동화를 통해 보안 기초와 제어를 구축했었습니다. 반면, 자동화되지 않았다면 물론 자동화 없이 구축을 지원하고 최대한 빨리 운영을 늘릴 수 있도록 도울 수도 있지만 수동으로 작업할 경우 힘들고 느립니다. 또한 모든 가드레일과 다중 계정을 자동화하는 것이 아주 중요합니다. 이는 실제 방식을 보여주는 아주 좋은 예였습니다. 고객으로 AWS 사용을 시작했을 당시 회사에 2개의 개발 팀이 있었는데 6개월 후에 20개로 늘어났습니다. 시스템이 프로덕션으로 전환되었고 모든 직원을 플랫폼에 온보딩해야 했죠. 제가 초기에 배운 것처럼 많은 고객이 이 교훈을 얻어야 한다고 생각합니다.

Clarke: (10:31)
원하는 보안 기준을 충족하기 위해 일을 다시 해야 했겠군요.

Megan: (10:35)
맞습니다.

Clarke: (10:37)
같은 맥락에서 보안 팀이 고객 계정 내에서 클라우드 전환을 주도할 수 있는 방법이 있습니까?

Megan: (10:50)
보안을 가장 마지막으로 미루는 경우를 많이 봤습니다. 하지만 그렇게 하지 않아도 됩니다. 온프레미스에 도입한 보안 프레임워크를 클라우드용으로 업데이트하고 제어할 수 있거든요. 매핑 작업을 수행하고 가드레일을 미리 설정하기만 하면 일이 훨씬 쉬워집니다. 배포 담당자를 위한 준비를 할 수 있거든요. 주위의 압박이 없다면 더 좋습니다. 지표와 같은 것들을 정의할 수 있으니까요. 문 앞에서 “어서 가자”고 서두르는 사람 없이 자동화를 설정할 수 있죠. 이렇게 하면 보안 팀에서 보안 요구 사항을 투명하게 파악하고 개발자는 구축해야 하는 것과 보안 팀에서 기대하는 사양을 더 잘 이해할 수 있습니다. 다시 말하지만 개발 팀과 보안 팀 사이의 관계가 더 효과적으로 효율적이 되죠. 그러면 개발자가 원하는 비즈니스 기능을 구현하는 데 도움이 됩니다.

Clarke: (12:10)
맞습니다. 보안 팀이 개발자나 제품 책임자보다 먼저 클라우드를 도입하면 특정 수준의 확신과 신뢰가 쌓인다는 말씀인가요? “보안 팀이 하고 있으니 핑계가 없네요”라고 말할 수 있겠군요.

Megan: (12:25)
바로 그것입니다. 고객과 일할 때 아주 효과적이었던 것 중 하나는 보안 요구 사항과 사례를 제시해 줄 때였습니다. 예를 들어 “보안 ID 및 액세스 정책은 어떤 형태입니까?”, “안전한 보안 그룹과 안전하지 않은 보안 그룹의 차이는 무엇입니까?”에 대한 답변과 유형의 예제를 제공하는 내부 Wiki처럼요. 우리가 말하고 있는 것이 바로 이것입니다. 액세스 정책에 있어서는 작업보다 중요한 것이 리소스입니다. 어떤 이유로 개발 팀의 작업이 막혔을 때, 예를 들어 고객이 특정 보안 요구 사항으로 곤란을 겪는 경우 보안 팀이 일주일에 한 번 업무 시간에 서비스를 제공하거나 slack 채널을 통해 서비스를 제공하면 개발자가 전체 프로세스를 수행하기가 훨씬 더 쉬워집니다. 보안 팀은 필수적인 팀이 되어야 합니다. 많은 경우 작업이 막혀서 24시간 동안 기다리는 일을 방지하기 위해 이들과 친밀한 관계를 쌓습니다. 또한 보안 팀은 피드백 루프를 가속화할 수 있습니다. 예를 들어 “문서화가 너무 복잡합니다”라거나 “이것을 지정해야 합니다”라는 피드백을 제공해 줄 수 있습니다. 또는 호스트의 보안 에이전트를 부트스트래핑해야 하는 경우 이를 요청하는 대신 직접 스크립트를 작성해서 코드 리포지토리에 스크립트를 저장하여 제공할 수 있어요.

Clarke: (14:02)
그런데 평균적인 보안 팀에는 없을 수도 있는 기술에 대한 이야기가 나온 것 같은데요. 전통적인 보안 팀에서는 IDS와 다양한 네트워크 서비스, 패치 적용 시스템 등을 실행하지 않았습니까? 제가 잘못 이해했다면 교정해 주시기 바랍니다. 그런데 Megan 씨의 이야기를 들으니, 이제는 보안 팀에서 개발 주기가 어떻게 작동하는지 알아야 하고 심지어 직접 코딩하는 방법도 알아야 하나요?

Megan: (14:33)
물론입니다. 제 생각에... 보안 실무자의 배경에 따라 개발자 배경이나 CS 학위가 없을 수 있습니다. 필수는 아닙니다. 하지만 Python 프로그래밍을 조금 할 줄 알면 좋지요. CloudFormation은 쉽게 배울 수 있어요. Ansible은 YAML 구성 파일이고요. 백로그가 있는 애자일 방식으로 개발 팀과 비슷하게 운영하면, 보안 관점에서 우선 순위를 관리하는 제품 책임자의 도움을 받을 수 있습니다. 첫째, 개발자의 작업 방식을 이해해야 합니다. 실제로 아주 효율적인 작업 방식을 이해해야 해요. 제가 실무자였을 때는 이런 방식으로 일을 했는데, 특히 보안 관점에서는 일이 아주 빠르게 변하고 비즈니스 요구 사항이 아주 빠르게 변합니다. 갑자기 스케일 업해야 하고 기존의 운영 방식을 바꿔야 하죠. 따라서 이렇게 하면 정기적인 간격으로 우선 순위를 적절하고 효율적으로 다시 지정하는 데 도움이 됩니다.

Clarke: (15:39)
조직 내부에서 서비스 형태로 보안을 실행하는 것과 같군요?

Megan: (15:44)
예. 그렇습니다.

Clarke: (15:46)
좋습니다. 주제를 조금 바꿔서 최근 뉴스에 나오는 내용에 관해 이야기를 해볼까 합니다. 랜섬웨어 기사는 어렵게 찾아보지 않아도 자주 듣게 되는데요. 랜섬웨어 완화 기법과 관련하여 고객의 현재 상태는 어떤지, 그리고 고객에게 해줄 수 있는 조언은 무엇인지요?

Megan: (16:11)
지난 2개월간 랜섬웨어에 대해 고객과 직접 스무 차례 넘게 대화를 나눴습니다. 저는 이런 대화를 나누는 것을 좋아하는데, 고객들이 ”AWS의 메시지가 무엇인지 알고 싶다”고 말하기 때문입니다. 이 말은 고객이 AWS를 파트너로 생각하고 있음을 나타냅니다. 랜섬웨어에는 만능약이 없기 때문에 저는 10가지 모범 사례를 알려줍니다. 강력한 보안 프로그램, 강력한 보안 제어가 있어야 하고 효율적으로 작동해야 하죠. 몇 가지 핵심 영역은 확실히 다룰 필요가 있어요. 다중 계정 전략이나 최소 권한 액세스와 같은 것들이요. 제가 반복적으로 묻는 질문은 장기 유지되는 정적 IM 보안 인증 정보가 있는지 여부에 대한 것입니다. 있다면 이를 자세히 살펴보고 여전히 필요한지 여부를 결정해야 합니다. 아키텍처를 바꿀 수 있는지 확인해야 하죠. 하지만 하이브리드 액세스의 경우처럼 정말 필요하다면 이 보안 인증 정보에 연결된 액세스 권한을 최소화해야 합니다. 환경에서 수행할 수 있는 작업을 최소화하는 것이죠. 그런 다음 그 사용을 모니터링하고 위험으로 분류해야 합니다. 위험 레지스터에 등록하고 시야를 벗어나는 일이 없도록 해야 해요. 향후에 제거할 기회가 생기면 제거합니다. 이것이 근래의 가장 큰 위험 중 하나이므로 저희는 고객이 선제적으로 이를 차단할 수 있도록 돕고 있습니다.

Clarke: (17:44)
랜섬웨어를 완화하려면 기초적인 보안을 제대로 해야 한다는 말씀이군요. 제가 제대로 이해했나요?

Megan: (17:52)
예. 맞습니다. 패치 적용은 새로운 개념이 아니죠. AWS에서도 다양한 방식으로 이를 수행할 수 있습니다. 오토 스케일링 그룹을 바꾸고 CICD 파이프라인의 시스템을 다시 시작하면 됩니다. Systems Manager를 사용할 수도 있죠. Systems Manager는 절반은 운영 도구이고 절반은 보안 도구와 같습니다. 아주 놀라운 기능을 제공합니다. 따라서 많은 옵션이 있어요. 이러한 옵션에 대해서도 이야기하죠. “온프레미스에서 Air-Gapped 백업을 수행했었다. 말 그대로 테이프 백업을 만들고 Iron Mountain 트럭에 넣어 아무도 건드리지 못하도록 했는데 AWS에서는 어떻게 하느냐?”고 묻는 고객이 있었습니다. 모든 것이 API이고 연결되어 있지만 보안을 살펴보면 AWS 계정이 보안 경계 역할을 합니다. 개별 계정을 만들고 백업을 해당 계정으로 전송할 수 있어요. 누르고 당기는 유형의 메커니즘으로 자동화를 수행하면 백업용 랜딩 계정을 만들 수 있습니다. 그런 다음 개별 계정에서 양호한 것으로 알려진 소스를 가져오고 S3 버킷의 WORM인 S3 객체 블록과 일부 강력한 보안과 제어를 사용해서 계정 관리자의 액세스 권한도 최소화할 수 있습니다. 약 2주 전에 발표된 AWS Backup의 AWS Backup Vault Lock을 사용하면 저장소에도 WORM을 적용할 수 있죠. 기본적으로 이 기능은 백업이 생성된 후 해당 백업을 변경할 수 없도록 합니다. 따라서 어떤 것도 삭제할 수 없어요. AWS Backup Vault Lock을 사용하면 액세스 정책을 설정해서 백업을 변경하지 못하게 할 수 있습니다. 기본적으로 S3 객체 잠금과 유사한데, 데이터가 이 위치에 저장되지만 특정 시간 동안 접근을 제한하는 것입니다.

Clarke: (20:05)
그렇군요. 언급하신 도구와 모범 사례 중에서 인시던트 대응 준비에 관한 것을 듣지 못했는데요. 이것은 얼마나 중요하고 고객은 이 영역에서 무엇을 해야 합니까?

Megan: (20:19)
랜섬웨어와 관련된 이야기를 할 때마다 고객에게 이렇게 묻습니다. “랜섬웨어 보안 이벤트에 대한 모의 훈련을 실제로 해보셨습니까?” 모의 훈련은 아주 중요하거든요. 인시던트 대응 관련 작업을 해본 적이 없다면 스트레스가 심할 수 있습니다. 모의 훈련을 하면 많은 문제를 경험할 기회가 생깁니다. 그러면 실제 이벤트 중에 이 문제를 처리하지 않고 문제 없이 집중하고 조사를 진행할 수 있습니다. 모의 훈련에서는 기본적으로 이벤트가 일어난 것을 확인하는 방법, 모든 AWS 계정에 액세스하여 필요한 조사를 수행할 수 있는지 여부, 이벤트를 확인하는 위치, 보안 운영 센터로 들어오는지 여부, 일관된 대응을 위한 모든 활동을 명시해 놓은 플레이북이 있고 의사 결정에 필요한 데이터가 있는지 여부, 해당하는 이해 관계자가 참여하고 있는지 여부를 확인합니다. 보안 이벤트가 발생하면 우리 고객과, 고객의 고객과 의사 소통할 방법을 알아야 하니까요. 그 과정에서 복잡한 일이 많이 발생하는데, 고객은 AWS의 ProServe 팀을 통해 도움을 받을 수 있습니다. AWS는 이 연습을 여러 번 수행합니다. 연습은 완벽을 만들죠. 특정 시나리오에 대해 두려움이 있다면 “그럼, 연습합시다”라고 합니다. 그러면 두려움이 사라져요. 연습을 통해 실력을 쌓는 것처럼 간단합니다.

Clarke: (21:55)
다른 이해 관계자라는 말을 하셨는데요. 보안 팀만 참여하는 연습이 아닌가요?

Megan: (22:00)
전혀 아닙니다.

Clarke: (22:01)
이 모의 훈련에 참여해야 하는 다른 이해 관계자들은 누구입니까?

Megan: (22:06)
예. 법무 팀, 개인 정보 보호 팀, 보안 관리 팀에서 주로 참여하고, 연습의 유형과 연습하는 인시던트의 유형에 따라 헬프 데스크가 참여할 수도 있는데, 예를 들어 완화 유형을 연습하는 경우에는 애플리케이션 및 개발 팀에서 참여해서 이 연습의 다운스트림 영향을 이해하는 데 도움을 줄 수 있습니다.

Clarke: (22:36)
고객 계층 구조의 모든 직급에서 참여합니까? 다시 말해 CEO가 이 모의 훈련에 참여할까요? 아니면 다른 직급의 관리자가 참여합니까? 어디에서 끝나는지요?

Megan: (22:50)
예. 프로세스를 이해하고자 하는 사람들도 참여합니다. 보안 이벤트가 실제로 발생하면 일반적으로 기밀로 유지되니까요. 해당 이벤트를 알아야 하는 사람에게만 알려야 합니다. 계산된 방식으로 커뮤니케이션이 수행될 수 있도록 해야 하죠. 그러나 연습의 경우 참여를 원하는 사람을 막을 이유가 없습니다. CEO가 관심을 보인다면 물론 모셔와야 하죠.

Clarke: (23:21)
훌륭합니다.

Megan: (23:22)
모두가 배울 것이 있습니다.

Clarke: (23:24)
최근 뉴스에 자주 나오는 또 다른 주제이자 고객이 항상 묻는 것이 제로 트러스트 개념입니다. 제로 트러스트는 어떤 의미가 있습니까?

Megan: (23:34)
예. 전통적으로는 환경의 액세스와 보안 제어에서 네트워크 경계에 크게 의존했었습니다. 반면 오늘날에는 API 계층에서 호출을 인증하고 권한을 부여하죠. 즉, 사용자가 환경에 액세스하거나 API로 API를 호출할 때 이 네트워크 통신에 대한 경로의 각 단계에서 인증과 권한 부여를 확인하는 것입니다.

Clarke: (24:10)
오늘 나와 주셔서 감사합니다.

Megan: (24:12)
예. 감사합니다. 아주 즐거웠습니다.