[AWSKRUG 보안 소모임 발표] Prowler MCP 개발 및 AWS 취약점 점검 및 조치 자동화 아키텍처 구성기

발표자료: AWSKRUG 보안 소모임 8월 발표자료
Prowler MCP 코드: https://github.com/comprowler/project_compler

좋은 기회를 얻어 AWSKRUG 보안 소모임에서 발표를 진행하게 되었다.
오픈소스 CSPM 도구인 Prowler를 주제로, 그동안 개발해온 Prowler MCP를 공개할 수 있었다. 진행하던 프로젝트를 외부 커뮤니티, 그것도 학생이 아닌 현직자를 대상으로 발표까지 이어간 것은 이번이 처음이었기에 더욱 의미 있는 경험이었다.

왜 만들었나? (WHY?)

배경은 단순하다. 2024년부터 금융 산업 내 클라우드 사용 규제가 완화되면서 금융권의 AWS 전환 속도가 빠르게 증가했다. 실제로 하나은행, 토스증권과 같은 금융사들도 AWS를 적극적으로 도입하기 시작했다.

문제는 여기서 발생한다. 클라우드를 도입하면 자산이 빠르게 늘어나고, 그에 따라 보안 점검을 수작업으로 유지하는 것이 사실상 불가능해진다는 점이다.

이 지점에서 CSPM(Cloud Security Posture Management) 도구의 필요성이 나온다. CSPM은 클라우드 구성 평가, 지속적 모니터링, 규정 준수 점검을 자동화하는 역할을 한다. 그중에서도 오픈소스 기반에서 가장 널리 사용되는 도구가 Prowler다. 실제로 클라우드와 CLI 버전을 모두 써보았는데, 내장 컴플라이언스가 매우 많아 형상 관리에 편했다.

다만 Prowler는 CLI 기반 도구이기 때문에 비개발자가 사용하기 어렵고, 클라우드 버전은 유료다. 또한 CSPM 특성상 점검 결과 확인까지만을 지원하기 때문에 해석, 대응 조치까지의 과정이 각각 분리되어 있어 흐름이 끊긴다. 자연스럽게 “이 과정을 자연어 인터페이스 하나로 묶을 수 없을까?” 라는 질문이 들었고, MCP를 이용하면 이 문제를 해결할 수 있겠다는 결론이 나왔다.

문제: 공식 팀이 먼저 같은 내용을 발표했다

개발 과정에서 예상하지 못한 변수가 발생했다. Prowler V5 발표에서 Prowler Lighthouse와 Prowler Cloud MCP가 공개된 것이다. 방향성이 내가 만들고 있던 것과 거의 동일했다. 공식 벤더에서 만든 MCP가 있다면 굳이 이 프로젝트를 진행하는 이유가 있을까? 만든다고 하더라도, 공식 MCP를 베끼는 방향으로 프로젝트가 진행되지 않을까? 하는 고민들이 앞섰다.

처음에는 개발을 중단하고 새로운 주제를 선정할까 고민했지만, 대신 방향을 조정하기로 했다. 공식 MCP는 Google API Key나 OpenAI API Key가 필수이며, IDE 연동 중심으로 설계되어 있었다.

우리는 다음과 같이 차별화했다:

Claude Desktop 기반으로 동작
IaC 도구와의 연동을 중심으로 설계

특히 v5에서 함께 발표된 Prowler의 내장 remediation 코드 스니펫인 Fixer를 적극적으로 연동하여, 공식 팀의 로드맵과 같은 방향으로 발전하고 있음을 보여주고자 했다. 이 결론을 내리기 위해 Prowler 기술 블로그와 공식 유튜브를 이틀 동안 밤새가며 정리했다...

만든 것

핵심 아이디어는 점검 → 대응 → 알림을 한 사이클로 묶는 것이었다.

점검 쪽은 Prowler CLI로 로컬 스캔한 결과 파일(JSON, CSV, HTML)을 MCP가 읽어서 파싱하고 요약해준다. 출력 경로만 설정해두면 Claude가 알아서 파일을 읽고 "지금 가장 심각한 문제가 뭔지", "어떤 항목이 fail인지"를 자연어로 설명해준다.

대응 쪽은 IaC 도구 연동이다. 분석된 취약점을 기반으로 Cloud Custodian YAML 정책 파일을 자동 생성한다. 예를 들어 퍼블릭 S3 버킷이 발견되면, 해당 버킷 접근을 차단하는 Custodian 정책 파일을 만들어준다. Terraform 대신 Custodian을 선택한 이유는 단일 리소스 단위 빠른 수정에 최적화되어 있기 때문이다. Terraform은 인프라 전체를 선언적으로 관리하는 데 강점이 있는데, "이 버킷 하나 지금 당장 막아야 함" 같은 시나리오에는 Custodian이 더 맞다.

알림은 Slack이다. MCP의 파일 읽기/쓰기 작업, IaC dry-run 결과, 생성된 YAML 파일의 주요 내용을 Slack으로 전달한다.

한 가지 설계 결정이 있었다. 처음에는 대화 안에서 Custodian run까지 자동으로 되게 만들려 했다. 그냥 물어보면 취약점 찾고 바로 조치까지 되는 구조. 그런데 팀 내부에서 보안상 안전하지 않다고 판단했다. MCP는 Custodian YAML 파일 생성까지만 하고, 실제 실행은 별도 웹 대시보드에서 사용자가 credentials를 직접 입력하고 dry-run을 확인한 후 진행하도록 분리했다. AI가 만든 정책을 사람이 검토하고 실행하는 흐름이다.

MCP에 구현된 tool 목록은 대략 이렇다:

get_latest_file
analyze_html_file / analyze_csv_file / analyze_json_file
analyze_prowler_results
get_prowler_reports_list
get_security_summary
get_cloud_custodian_aws_resource_reference_html
write_yaml_file / create_yaml_directory / list_iac_files / get_iac_file_content

Custodian 문법 RAG도 붙였다. YAML 정책 파일을 생성할 때 문법 오류를 줄이기 위해서다.

발표 후 계획

커뮤니티에서 피드백을 받았고, 이후 작업 방향은 세 가지다.

비슷한 기능의 MCP tool들을 통합해서 Claude에 노출되는 도구 수를 줄이려 한다. 도구가 많으면 Claude가 어떤 도구를 선택할지 판단이 흔들리고, hallucination 가능성도 올라간다.

QA도 강화해야 한다. 그리고 망분리 환경에서 쓸 수 있는 로컬 MCP 버전도 고려 중이다. 현재는 Claude Desktop을 통해 동작하는 구조라 외부 API 호출이 있는데, 금융권처럼 망분리 환경에서는 이 구조 자체가 제약이 되기 때문이다.

그리고 아쉬웠던 점도 있었다. 비용 제약과 학생 프로젝트라는 한계로 인해, 우리가 테스트한 Prowler MCP의 형상 데이터 규모는 수백 개 수준에 머물러 있었다. 반면 실제 현업에서는 수만 개 단위의 리소스를 다룬다는 피드백을 받았다. 현재 구조와 처리 속도를 기준으로 보면, 수만 개의 리소스를 한 번 점검하는 데 10분 이상이 소요될 것으로 예상된다. 이는 실무 환경에서 사용하기에는 부담이 있는 수준이다.

MCP 속도도 단순히 좋은 하드웨어에서 작동시키는 것 이외의 방법으로 개선해야겠다고 생각했다. 파싱 구조 최적화, 병렬 처리, 데이터 처리 방식 개선 등 아키텍처 레벨에서의 성능 개선이 필요하다는 점을 인식하게 되었다...

느낀 점

처음 만든 오픈소스 프로젝트가 외부 커뮤니티 발표까지 이어졌다는 점에서 의미가 컸다. 만드는 과정에서 공식 팀이 유사 기능을 먼저 공개하는 변수도 있었고, 자동화의 범위를 어디까지로 할지, 개발과 컴플라이언스 중 어떤 것에 더 집중할지 하는 팀 내 논쟁도 있었다.

이번 프로젝트를 통해 방대하게 느껴졌던 클라우드 보안 설정을 하나의 흐름으로 연결해 이해할 수 있었고, 그 구조를 보다 명확하게 정리할 수 있었다.

개인적으로는 자동화와 자동화를 시스템으로 만드는 과정 자체에 흥미를 느끼는 편이라, 보안 정책을 IaC코드로 개발화하고 실제 인프라에 적용하는 과정도 굉장히 재미있었다.

오픈소스로 공개해뒀으니, 관심 있는 분들은 사용해 보시고 이슈를 남겨주시면 감사합니다. (내용이 재밌으셨다면 깃헙 스타도 부탁드립니다)

Github Repo

Pitch Slides

발표자료는 https://www.awskr.org/groups/security/sessions/2025-08-prowler-mcp.html 에서 더 볼 수 있다.