Dropbox가 MCP와 Dash를 활용해 디자인‑코드 보안 격차를 해소하는 방법

출처: Dropbox Tech Blog

모든 보안 팀은 절차를 잘 알고 있습니다. 새로운 기능은 설계 검토를 거치고, 위협 모델이 작성되며, 완화 방안에 합의한 뒤 개발이 시작됩니다. 많은 경우 구현이 코드 리뷰 단계에 도달했을 때—엔지니어가 코드를 실제 배포 전에 검토하는 과정—원래의 보안 요구사항은 워크플로우에서 사라져 버립니다. 기능이 포함해야 할 잠재적 보안 위험과 보호 조치를 개요한 위협 모델은 종종 코드와 별개의 문서나 시스템에 존재합니다.

이러한 분리는 문제를 일으킵니다. 구현은 원래 보안 검토가 이루어진 지 몇 주 혹은 몇 달 뒤에 이루어지는 경우가 많아, 리뷰어가 합의된 보안 요구사항이 실제로 구현됐는지 확인하기 어렵게 됩니다. Dropbox에서는 이 격차가 실제로 얼마나 자주 발생하는지 파악하고 싶었습니다.

그래서 우리는 세 가지 기술을 결합한 시스템을 구축했습니다: Model Context Protocol, 기본 대형 언어 모델(이하 “기본 모델”), 그리고 Dropbox 내에서 팀의 콘텐츠를 쉽게 찾고 이해할 수 있게 해주는 AI 기능인 Dash. 이 기술들은 코드 리뷰 중에 관련 위협 모델을 자동으로 검색하고, 코드 변경 사항이 해당 모델에 정의된 요구사항과 일치하는지 평가합니다. Dash가 이미 Dropbox와 연결된 애플리케이션에 저장된 콘텐츠를 색인하고 연결해 두었기 때문에, 시스템은 수년간 축적된 보안 검토와 엔지니어링 문서를 별도의 수작업 없이 활용할 수 있습니다.

이 글에서는 해당 시스템의 아키텍처를 살펴보고, 수개월에 걸친 위협 모델 분석을 통해 얻은 인사이트와 이 패턴을 다른 설계·컴플라이언스 검토에 적용할 수 있는 방법을 논의합니다.

설계‑코드 격차

조직은 제품이 출시되기 훨씬 전부터 위협 방어와 같은 중요한 결정을 내립니다. 하지만 보안 검토가 만든 가치가 지속되려면, 그 검토에서 도출된 요구사항이 개발 전 과정에 걸쳐 가시적으로 유지돼야 합니다. 엔지니어들은 이러한 요구사항이 개발 진행 중에도 지켜지는지 확인하고, 혹시 발생할 수 있는 격차를 찾아내고자 합니다.

보안 검토 과정에서 엔지니어들은 잠재적 위험을 식별하고, 기능이 어떻게 악용될 수 있는지 논의한 뒤, 포함해야 할 보호 조치에 합의합니다. 이러한 결정은 위협 모델에 기록됩니다. 그러나 개발이 시작되면 이 결정들은 종종 코드와 분리됩니다. 위협 모델은 위키나 문서 시스템에 존재하고, 코드는 풀 리퀘스트(PR)라는 작업 단위로 구현됩니다. 누군가 명시적으로 두 요소를 연결하지 않으면, 리뷰어는 이전에 합의된 보안 요구사항을 전혀 보지 못할 수 있습니다.

Dropbox에서는 수년간의 제품 개발에 걸친 위협 모델 문서를 보관하고 있습니다. 각 문서는 수많은 보안 엔지니어링 작업 시간을 담고 있지만, 구현 단계에서 리뷰어가 해당 문서를 접근할 수 있어야만 지속적인 가치를 제공합니다. 이 연결이 얼마나 유지되는지 파악하기 위해, 우리는 위협 모델과 해당 모델이 설명하는 기능을 구현한 PR 사이의 관계를 조사했습니다. 그 결과, 구현 PR 중 단 12%만이 원래 설계 검토와 위협 모델에 링크되어 있었습니다.

이 격차는 검토와 구현 사이에 시간이 많이 흐른다는 점에서도 심화됩니다. 79개의 검증된 쌍을 대상으로 설계 검토 제출 시점과 PR 생성 시점 사이의 간격을 측정했을 때, 54% 이상의 구현 PR이 검토 제출 후 한 달 이상 지나서야 열렸음을 발견했습니다. 중앙값 지연 시간은 약 5주였으며, 11개월을 초과하는 경우도 있었습니다. 보안 검토 후 첫 2주 이내에 열린 구현 PR은 29%에 불과했습니다.

즉, 보안 요구사항이 정의된 시점과 해당 코드가 리뷰되는 시점 사이에 긴 지연이 발생할 수 있습니다. 리뷰어가 구현을 살펴볼 때, 보안 검토 중에 이루어진 결정은 그들이 열어보지 않을 문서 속에 파묻혀 있을 가능성이 높습니다.

기존 도구가 해결하지 못하는 이유

격차 규모를 파악한 뒤 다음 질문은 기존 보안 도구가 이를 메울 수 있는가였습니다. 예를 들어 정적 분석 도구는 알려진 패턴과 잠재적 문제를 검사하지만, 보안 제어가 존재한다는 사실만 알려줄 수 있습니다. 설계 검토 중 합의된 요구사항에 따라 구현됐는지는 판단하지 못합니다. 이 도구들은 코드 자체만을 분석하고, 그 맥락이나 의도를 파악하지 못합니다.

많은 조직이 엔지니어에게 코드 변경을 설계 검토와 연결하도록 요구하거나, 리뷰 절차를 상기시켜 주는 봇을 배포하는 방식으로 이 문제에 접근합니다. 그러나 이러한 접근법은 엔지니어가 추가 단계를 기억해야 한다는 전제에 의존하며, 시간이 지나면서 준수율이 떨어지는 경향이 있습니다. 부족했던 점은 이미 존재하는 보안 가이드를 코드 변경과 연결하는 방법이 없다는 것이었습니다. 문제는 보안 지식이 부족한 것이 아니라, 그 지식을 코드 리뷰 시점에 활용할 수 없다는 것이었습니다.

우리 데이터는 또 다른 기회를 보여줍니다. 설계 검토의 약 15%가 사후에 제출되었는데, 이는 코드를 먼저 작성하고 나중에 보안 검토가 이루어진 경우를 의미합니다. 이러한 경우는 보안 민감 작업이 구현 단계에서 바로 검토가 필요하다는 인식이 부족했음을 시사합니다. 개발 중에 관련 보안 컨텍스트를 제공하고, 사후가 아니라 개발 중에 필요한 검토를 촉구할 수 있는 시스템이 양방향으로 도움이 될 수 있습니다: 코드를 기존 검토와 연결하고, 추가 검토가 필요할 때 조기에 신호를 제공하는 것입니다.

Dash와 MCP를 컨텍스트 브리지로 활용하기

우리는 리뷰 중인 코드를 조직 내 다른 곳에 존재하는 보안 가이드와 연결할 방법이 필요했습니다. Dash는 자연스러운 출발점이었습니다. 연결된 애플리케이션 전반에 걸친 콘텐츠를 색인하기 때문에, 위협 모델 컬렉션은 이미 다른 엔지니어링 문서와 함께 검색이 가능했습니다. 리뷰어가 직접 적절한 보안 문서를 찾는 대신, 우리는 코드가 리뷰에 제출될 때 자동으로 관련 위협 모델을 가져오는 시스템을 구축했습니다.

Model Context Protocol (MCP)은 에이전트가 필요한 정보를 접근하도록 해줍니다. Dash에는 MCP 서버가 있어, 색인된 콘텐츠를 다른 AI 도구에 제공할 수 있습니다. 우리의 경우, 보안 검토 에이전트가 Dash의 MCP 서버를 이용해 Dash 검색을 구동하는 동일한 연결된 콘텐츠(위협 모델 및 관련 문서)를 검색하고 읽습니다. 이를 통해 각 소스 시스템마다 맞춤형 통합을 만들 필요 없이 에이전트가 필요한 컨텍스트를 확보할 수 있습니다.

MCP는 여러 컨텍스트 소스를 하나의 에이전트 세션으로 결합합니다. 모델은 이를 기반으로 보안 요구사항과 구현 사이의 격차를 식별합니다.

코드 변경이 리뷰를 위해 열리면, 에이전트는 MCP를 통해 관련 위협 모델 및 기타 지원 컨텍스트를 가져옵니다. 기본 모델은 문서화된 요구사항과 제안된 코드 변경을 동시에 검토할 수 있습니다. 예를 들어, 위협 모델이 특정 엔드포인트에 인증이 필요하다고 명시했을 때, 도입되는 코드가 실제로 해당 요구사항을 구현했는지를 판단할 수 있습니다.

다양한 정보원을 종합해 추론할 수 있는 능력은 전통적인 정적 분석과 차별화되는 핵심 요소입니다. 이 시스템은 단순히 코드를 검사하는 것이 아니라, … (이하 내용은 원문이 끊긴 부분이므로 여기서 마칩니다).