보안 설계와 코드 리뷰의 간극을 좁히는 구조적 접근
대규모 조직에서 코드 리뷰는 단순히 구현 품질을 검증하는 단계를 넘어, 보안 설계 의도가 실제 코드에 반영되었는지 확인하는 중요한 검문소 역할을 해야 한다. 그러나 현실에서는 위협 모델(Threat Model)이나 보안 요구사항 문서가 별도 시스템에 분산되어 있어, 리뷰어가 PR을 열었을 때 관련 설계 맥락을 찾아 대조하기가 쉽지 않다. Dropbox는 이 문제를 내부 지식 플랫폼인 Dash와 MCP(Model Context Protocol)를 연계하는 방식으로 구조적으로 해결했다.
핵심 아이디어는 PR 단위로 관련 위협 모델과 보안 요구사항을 자동으로 조회하여, 리뷰어 화면에 함께 제공하는 것이다. 리뷰어는 구현 코드를 보면서 설계 단계에서 정의한 보안 의도와 실제 구현 사이의 불일치를 즉각적으로 감지할 수 있다.
MCP를 활용한 컨텍스트 연동 아키텍처
MCP는 다양한 외부 시스템으로부터 컨텍스트를 가져와 통합 인터페이스로 노출하는 프로토콜이다. Dropbox의 구조에서 Dash는 내부 문서와 지식을 보관하는 플랫폼으로, MCP 서버 역할을 수행한다. 코드 리뷰 시점에 PR 메타데이터(변경된 파일, 서비스명, 태그 등)를 기반으로 관련 위협 모델과 보안 요구사항을 Dash에서 질의하고, 그 결과를 리뷰 인터페이스에 연계하는 방식이다.
PR 오픈
└─▶ MCP 클라이언트가 PR 메타데이터 추출
└─▶ Dash(MCP 서버)에 관련 문서 질의
└─▶ 위협 모델 / 보안 요구사항 반환
└─▶ 리뷰 화면에 컨텍스트로 제공
이 구조의 핵심은 기존 문서 시스템을 교체하지 않고도 리뷰 워크플로우에 자연스럽게 연동할 수 있다는 점이다. MCP라는 표준 인터페이스를 중간에 두기 때문에, Dash가 아닌 다른 내부 위키나 문서 시스템으로 교체하더라도 클라이언트 쪽 변경을 최소화할 수 있다.
실무 적용 시 고려할 점
이 아키텍처를 실무에 도입할 때는 몇 가지 선결 조건이 있다.
- 문서와 코드의 연결 메타데이터 정비: PR과 위협 모델을 매핑하려면 서비스명, 컴포넌트 태그, 기능 분류 등이 코드 저장소와 문서 시스템 양쪽에 일관되게 정의되어 있어야 한다.
- 문서 최신성 유지: 연동된 위협 모델이 오래된 정보라면 오히려 리뷰어를 혼란에 빠뜨릴 수 있다. 설계 변경 시 문서 갱신을 프로세스로 강제하는 장치가 필요하다.
- 리뷰어 경험 설계: 컨텍스트가 너무 많으면 오히려 노이즈가 된다. 관련성 높은 문서를 정확하게 추출하는 질의 전략이 시스템의 실질적 유용성을 좌우한다.
Java 백엔드 서비스 기준으로 유사한 구조를 도입한다면, 서비스별 위협 모델을 Confluence나 사내 위키에 구조화하고, PR 훅에서 서비스 식별자를 추출하여 문서 API를 호출하는 형태로 구현할 수 있다.
// PR 훅에서 서비스 식별자 추출 후 문서 질의 예시
String serviceName = prMetadata.getChangedModules().stream()
.map(ModuleResolver::toServiceName)
.distinct()
.collect(Collectors.joining(","));
List<SecurityDocument> docs = dashClient.queryByService(serviceName);
정리
- 보안 설계 문서와 코드 리뷰를 MCP 기반으로 연동하면, 리뷰 시점에 위협 모델과 보안 요구사항을 자동으로 제공할 수 있다.
- 이 구조의 실효성은 PR 메타데이터와 설계 문서 간의 매핑 품질, 그리고 문서 최신성 유지에 달려 있다.
- 표준 인터페이스(MCP)를 중간 계층으로 두면 문서 시스템이 교체되더라도 리뷰 워크플로우 연동을 최소한의 변경으로 유지할 수 있다.