서론

안녕하세요, 크로스텍 매니지먼트(Crosstech Management) Foundation Dept. 소속 미즈모토입니다.

Foundation Dept.에서는 가이드라인에 따라 작성된 요구 사양서를 전달하면, 설계부터 구현, 테스트, PR 생성까지 인간의 개입 없이 완수하고, 요구 사양서 작성자가 최종적인 품질 체크만 수행하는 개발 에이전트 기반을 개발하고 있습니다.

이러한 형태의 개발에는 기존의 팀 개발과 결정적으로 다른 점이 하나 있습니다. 인간이 코드를 읽는 공정이 존재하지 않는다는 점입니다.

지금까지 보안의 상당 부분은 인간의 코드 리뷰가 잡아내고 있었습니다. SQL이 문자열 결합으로 구성되어 있다면 누군가 알아챌 것입니다. 인증 토큰이 localStorage에 놓여 있다면 누군가 제지할 것입니다. 그 '누군가'가 사라졌을 때, 보안 리뷰는 언제, 어디서, 누가 수행할 것인가.

이 기사에서는 이 질문에 답하기 위해 수행한 두 가지 작업을 기술합니다. 전반부는 조사입니다. 코드 보안 규격과 AI 에이전트용으로 공개된 보안 리뷰 기법(Claude Code의 Skill 및 플러그인)을 일일이 살펴보았습니다. 후반부는 설계입니다. 조사 결과를 바탕으로, 검사를 3개 층으로 나누어 파이프라인에 통합하는 안을 만들었습니다.

먼저 조사 결론의 절반만 미리 말씀드리겠습니다. 가치가 있었던 것은 규격 그 자체가 아니라, 보안 전문 도구가 만들어 놓은 '대상을 좁히는 방법'과 '오탐(False Positive)을 제거하는 방법'이었습니다.

전제: 어떤 파이프라인인가

파이프라인은 직렬 스테이지로 구성되어 있습니다. 요구 사양서를 수신하여 설계, 백엔드 구현, 프론트엔드 구현, E2E 검증 순으로 진행하며, 마지막에 PR을 생성합니다. 각 스테이지의 출구에는 빌드, lint, 테스트, 설계 산출물과의 대조와 같은 체크가 있으며, 통과하지 못하면 다음으로 진행할 수 없습니다.

인간이 확인하는 것은 코드의 diff가 아닙니다. 산출물을 staging 환경에 배포하고, 요구 사양서 작성자가 동작하는 애플리케이션을 실제로 조작하며 요구사항대로 동작하는지, UI나 UX가 사용 가능한지를 확인합니다. 인간의 주의력을 '코드가 올바른가'가 아니라 '프로덕트로서 좋은가'에 사용하는 것이 이 형태의 목적이며, PR은 산출물과 검증 결과의 보관 장소이지 인간이 코드 리뷰를 하는 장소가 아닙니다.

생성 대상은 업무용 Web 애플리케이션입니다.

조사: 규격과 전문 도구의 현주소

규격은 5개 층으로 정리할 수 있다

보안 규격은 수가 많아 보이지만, 레이어로 정리하면 관계는 단순했습니다.

공통 어휘는 CWE이며, 거의 모든 규격이 CWE를 참조함으로써 상호 연결되어 있습니다. AI 고유의 리스크에는 OWASP의 LLM 애플리케이션용 Top 10과, 에이전트 고유의 Agentic Applications용 Top 10(2026년판, ASI01~ASI10)이 별도로 존재합니다.

참고로, 이후에 나오는 Web 애플리케이션의 Top 10은 '2025년판'으로, Agentic과는 버전의 연도가 다릅니다. 이는 OWASP의 프로젝트마다 버전 명명 방식이 다르기 때문입니다. Web의 Top 10은 출시 연도(2025년 11월 발표)를, Agentic은 대상 연도(2025년 12월 발표인 'for 2026')를 표기하고 있으며, 둘 다 집필 시점 기준 최신 버전입니다.

높은 Star를 보유한 Skill 모음집에 보안 전용 Skill은 없었다

조사 전의 예상은 이러했습니다. GitHub에서 높은 Star를 보유한 Claude Code Skill 모음집을 뒤져보면 보안 리뷰의 정석도 한차례 갖춰져 있을 것이 분명하다.

실상은 반대였습니다. Star 수가 최대급인 범용 Skill 모음집 2개(obra/superpowers와 anthropics/skills)에는 보안 전용 Skill이 단 하나도 없었습니다 (2026년 7월 시점, 모든 SKILL.md를 열거하여 확인했습니다). 제가 조사한 범위 내에서 실질적인 내용은 그보다 규모가 훨씬 작은 전문 리포지토리 2곳에 집중되어 있었습니다.

anthropics/claude-code-security-review: Claude Code 내장형 /security-review

명령어와 동일한 분석 로직. LLM이 PR의 차이점(diff)을 분석합니다. -
trailofbits/skills: 보안 감사 기업인 Trail of Bits가 제공하는 플러그인 모음. 감사 워크플로우에 특화되어 있습니다.

스타(Star) 수와 내장 보안의 충실도는 오히려 역상관 관계에 가깝습니다. 개발 흐름 전체를 아우르는 대형 프레임워크군도 일일이 확인해 보았으나, 대부분은 "OWASP 체크리스트를 개발 흐름의 한 공정으로 돌리는" 넓고 얕은 구조였으며, 이제부터 설명할 오탐(False Positive) 억제 기제는 모두 갖추고 있지 않았습니다.

이러한 역상관 관계의 이유는 추측건대, 현재 에이전트 개발 커뮤니티의 관심이 어디에 집중되어 있는지와 관련이 있다고 생각합니다. 높은 스타 수를 기록하는 Skill 모음이나 프레임워크들이 경쟁하는 지점은 "머릿속에 그린 것을 AI가 어디까지 만들어낼 수 있는가"라는 구현 능력 측면이며, 스타 수는 그러한 기대가 모이는 곳을 투영합니다. 보안은 만드는 속도에 직접적으로 기여하지 않기 때문에, 체크리스트를 하나의 공정으로 두는 정도의 취급에 머물기 쉽습니다. 반면, 전문 리포지토리는 감사라는 본업의 필요성에 의해 정교하게 만들어져 있습니다. 스타 수가 측정하는 것은 주목도이지, 보안의 성숙도가 아닐 것입니다.

전문 도구가 투자한 것은 탐지력이 아니었다

전문 도구 두 곳의 내용을 읽으며 가장 의외였던 점이 바로 여기입니다. 양측이 공들여 만든 것은 "얼마나 많이 찾아내는가"가 아니라, 오탐(False Positive)을 어떻게 제거하느냐였습니다.

Anthropic 공식 리뷰는 감사 프롬프트의 서두에 다음과 같이 적고 있습니다.

1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability
2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings

실제 악용 가능성(exploitability)에 대해 80% 이상의 확신이 있는 경우에만 보고하라는 지시입니다. 나아가 DoS, 속도 제한(rate limiting) 부재, 이론적인 레이스 컨디션(race condition) 등 "보고해서는 안 되는 것"을 17개 항목으로 나열하였으며, 탐지 후에는 정규 표현식을 통한 하드 필터링과 별도의 LLM을 통한 건별 재판정을 거칩니다. 대상 또한 PR이 새로 도입한 차이점에만 한정하여, 기존 코드에 대한 지적은 금지하고 있습니다.

Trail of Bits 측은 더욱 직접적입니다. fp-check라는 검증 전용 Skill에 "LLM은 버그를 보고 싶어 하며, 심각도를 과대평가하는 편향(bias)이 있다"라고 명시한 뒤, 의심스러운 지적을 6개의 게이트(프로세스, 도달 가능성, 실질적 피해, PoC, 수학적 경계, 환경 전제)에 통과시켜, 모두 통과한 것만을 참 양성(True Positive)으로 인정합니다.

왜 억제 측면에 이토록 투자하는 것일까요? 노이즈가 섞인 지적이 매번 PR에 흘러 들어오면, 읽는 사람은 지적을 무시하게 되고 리뷰 메커니즘 자체가 형해화되기 때문입니다. 탐지 카테고리를 늘리는 것은 쉽지만, 늘어난 만큼의 노이즈를 제거하는 것은 훨씬 어렵습니다. 전문 도구 두 곳의 구조는 그렇게 읽혔습니다.

규격은 어휘의 공급원으로 사용한다

또 하나, 설계 방침을 바꾼 관찰 결과가 있습니다. Anthropic 공식 리뷰는 OWASP나 CWE를 전혀 명시하지 않고도 성립되었습니다(리포지토리 전체를 코드 검색했을 때 모두 zero-hit). 규격 준수를 선언하는 것과 탐지가 제대로 기능하는 것은 별개의 문제입니다.

그래서 규격은 게이트의 근거가 아니라, 어휘와 체크 항목의 공급원으로 사용하기로 했습니다. 예외는 두 가지입니다. ASVS 5.0은 웹 애플리케이션의 요구사항을 "검증 가능한 문장" 단위로 나열한 규격이므로, 수용 기준의 어휘로서 그대로 사용할 수 있습니다. Agentic Top 10은 생성물이 아니라 파이프라인 자체의 위협 모델(threat model)에 대응하므로, 도구 실행의 거버넌스(실행 시 정책으로 허용과 거부를 판정하는 메커니즘)를 검증하는 데 사용합니다.

설계: 검사를 세 개의 층으로 분리하기

조사 내용을 바탕으로, 파이프라인에의 통합은 다음 세 개의 층으로 구성했습니다.

표에서 알 수 있듯이, 기계인지 LLM인지는 층을 나누는 기준이 아닙니다 (② 안에도 기계 검사가 있습니다). 층을 나누는 기준은 사건의 원인입니다. 코드의 차분에 기인하는 것은 ①, 전체가 조립된 후에야 판정할 수 있거나 이력·의존성에 기인하는 것은 ②, 결정적인 패턴으로 작성할 수 있는 것은 ③에 해당합니다.

왜 「스테이지별」과 「종료 후」 모두를 사용하는가

실행 타이밍의 선택지는 「스테이지별」, 「전부 끝난 후」, 「그 둘 모두」의 세 가지가 있었습니다. 둘 다를 채택한 이유는 각각의 방식에서만 보이는 것이 있기 때문입니다.

스테이지별로 확인하는 이유는 재작업 비용(rework cost) 때문입니다. 백엔드의 인가 결함이 프론트엔드와 E2E를 통과한 후에 발견되면, 수정은 3개 스테이지 분량의 결과물에 파급됩니다. 차분이 작을 때 확인하면 수정은 동일한 스테이지 내에서 완결되며, 원인 귀속도 차분 단위로 확실해집니다.

반면, IDOR (타인의 리소스에 대한 접근)는 API와 클라이언트가 모두 갖춰지지 않으면 확정할 수 없습니다. CORS나 CSP 설정과 인가 설계의 정합성 또한 전체가 조립된 후에야 판정할 수 있습니다. 스테이지 단위의 리뷰를 아무리 반복하더라도, 이러한 종류의 결함은 원리적으로 검출할 수 없습니다. 따라서 종료 후의 횡단 게이트가 별도로 필요합니다.

참고로 스테이지별로 확인한다고 해도, 대상은 해당 스테이지가 변경한 차분으로 한정합니다. 「매 스테이지마다 코드베이스 전체를 스캔한다」는 안은 채택하지 않았습니다. 동일한 지적이 반복되어 노이즈가 되기 때문입니다. Anthropic 공식 문서가 대상을 차분으로 좁히고 있는 이유는, 범위를 좁히는 것 자체가 노이즈 원인을 구조적으로 줄여주기 때문이며, 이 사상을 스테이지 단위에 투영했습니다.

수정 루프에는 반드시 상한을 둘 것

① (스테이지 리뷰)의 지적 사항은 동일한 run 내의 수정 루프로 돌려보내지만, 수정하는 주체는 리뷰를 담당하는 LLM 자신이 아닙니다. 리뷰 측은 읽기 전용으로 두고, 지적 사항은 해당 코드를 작성한 구현 에이전트에게 전달하여 수정하게 합니다. 수정한 본인이 「수정되었다」고 판정하는 자기 채점을 피하기 위한 역할 분리이며, ②의 검증 레인에서도 마찬가지입니다.

그리고 루프에는 횟수 상한(2~3회)을 둡니다. 이는 단순한 사상이 아니라 실측을 통한 교훈으로, 상한 없는 자기 검증 루프가 백여 회 이상 헛도는 사례를 실제 run에서 관찰했습니다. 상한에 도달하면 남은 지적 사항을 결과물에 기록하여 진행하며, 나중에 언급할 검증 레인을 통과한 후 PR을 생성합니다.

무거운 검증은 돌이킬 수 없는 판정 직전에만 배치한다

① (스테이지 리뷰)와 ② (횡단 게이트) 모두 수정 루프를 돌리는데, 검출과 검증의 분리를 ②에만 두는 이유는 무엇일까요? 지적이 전달되는 대상에 따라 검증의 강도를 단계별로 나누었기 때문입니다.

①의 지적은 자동 수정 루프에 들어갑니다. 오검출(false positive)의 피해는 무의미한 수정 시도이지만, 상한을 통해 제어하고 있습니다. 반면 ②의 지적은 게이트의 block 판정과 수락 여부를 판단하는 사람에게 전달됩니다. 잘못된 block은 납품 중단이며, 잘못된 보고는 인간의 신뢰를 훼손하여 레인이 형해화되는 입구가 됩니다. 돌이킬 수 없는 판정과 인간 대상 보고 직전에만, 무거운 독립 검증을 배치합니다. 이 비대칭성은 의도된 설계입니다.

순서 또한 ①과 ②를 반대로 구성했습니다. ①은 검출하면 우선 수정하고 나머지를 나중에 검증합니다. ②는 검증으로 확정한 후에 수정합니다. 후반부의 수정은 이미 통과한 검사를 망가뜨릴 수 있는 고비용 작업이므로, 오검출에 대해 실행하게 둘 수 없기 때문입니다.

②에서 확정한 지적 사항은 수정 가능성에 따라 분류합니다. run 내에서 수정 가능한 것(통합 테스트 실패, 설정 모순, 의존성 버전 업데이트)은 수정 루프(correction loop)로 돌려보내며, 수정 후에는 해당 검사의 재실행과 E2E 회귀 확인을 거칩니다. run 내에서 완결되지 않는 것(git 이력에 혼입된 시크릿. 이력 재작성 및 무효화에 인간의 권한이 필요함)은 수정 루프에 넣지 않고 즉시 에스컬레이션(escalation)합니다.

기계 계층은 LLM 앞에서 패턴을 제거한다

하드코딩된 시크릿이나 알려진 위험 패턴은 결정적으로 판정할 수 있습니다. 여기에 LLM을 사용할 이유는 없으므로, ③(기계 계층)은 커밋마다의 pre-commit hook과 스테이지의 check 태스크에 semgrep(CWE Top 25에서 생성물 스택에 맞춘 서브셋)과 secrets 스캐너를 배치합니다. 위치는 앞서 언급한 스테이지 출구의 체크(빌드나 lint)와 동일한 열입니다. 전자가 기능의 품질을 확인하는 기존의 체크라면, ③은 그 열에 보안의 결정적 패턴 판정을 추가하는 계층입니다. 히트(hit) 시에는 빌드 실패와 동일하게 취급하여 즉시 수정으로 돌려보내며, 검증 레인(verification lane)은 통과시키지 않습니다. 결정적인 판정에는 오검출에 대한 논쟁의 여지가 없으며, 오검출은 규칙 선정 측에서 해결해야 할 문제이기 때문입니다.

LLM 계층은 그 앞에서 다 제거하지 못한 의미론적 판정(인가(authorization) 플로우가 설계 의도대로인지, 데이터 플로우가 민감한 조작에 닿지 않는지 등)에 전념하게 합니다.

OWASP Top 10에 비추어 빈틈을 명시한다

검사 대상 모집단은 OWASP Top 10:2025(집필 시점의 최신 버전)를 기준으로 삼았습니다. 자의적인 나열을 피하기 위해서이며, 10개 카테고리 전체가 어느 계층(또는 검사 레인 외부의 어떤 수용처)에 속하는지 표로 나타내고, 수용처가 없는 것은 '갭(gap)'이라고 명시합니다.

DoS나 속도 제한(rate limiting) 같은 가용성 관련 사안은 의도적으로 검사 레인에서 제외했습니다. 방치하는 것이 아니라, 설계 측의 가용성 요구사항이라는 별도의 수용처로 보내는 것입니다 (Anthropic 공식 입장도 같은 이유로 제외하고 있습니다). 파이프라인 자체의 폭주나 도구 오용(Agentic Top 10의 영역) 또한 실행 시 거버넌스(runtime governance)라는 별도 트랙의 담당입니다.

빈틈을 포함하여 표로 만드는 것은 격식을 차리기 위함이 아닙니다. '어디를 보고 있지 않은지'를 명문화해 두지 않으면, 검사를 통과했다는 사실의 의미를 나중에 아무도 설명할 수 없게 되기 때문입니다.

자율 파이프라인만의 논점

인간의 리뷰를 AI로 교체하는 것뿐이라면, 여기까지의 이야기는 기존 CI 설계의 연장선입니다. 자율 파이프라인에 고유한 논점이 두 가지 남습니다.

AI의 '자기 면제'를 차단한다

기계 계층의 오검출을 통과시키는 정규 경로는 allowlist(nosemgrep 코멘트나 secrets 스캐너의 제외 설정)입니다. 여기에 함정이 있습니다. 코드를 작성하는 AI 스스로가 검사에 걸리는 순간 '검사를 침묵시키는' 자기 면제를 해버릴 수 있다는 점입니다.

상정하고 있는 동작은 예를 들어 다음과 같습니다. semgrep의 지적에 대해 코드를 고치는 대신 해당 라인에 // nosemgrep 코멘트를 추가하여 재커밋합니다. secrets 스캔에 걸리면 스캐너의 제외 설정에 대상 파일의 경로를 추가합니다. 두 가지 모두 '검사를 통과한다'는 목표에 대해서는 합리적인 최단 경로이므로, 금지하지 않는 한 선택될 수 있습니다. 이는 가상의 걱정이 아닙니다. '테스트가 통과하는 것처럼 보이는 구현'은 실제 run에서 관측되고 있으며, 검사를 침묵시키는 행동은 그와 같은 계통의 실패 모드입니다.

대책은 두 가지입니다. 첫째, AI는 자신의 판단으로 allowlist를 추가하지 않는다고 리뷰용 Skill의 원칙에 명시하는 것입니다. 둘째, allowlist의 변경이 반드시 PR 차분에 나타나는 곳에 위치시켜 인간 리뷰의 대상으로 만드는 것입니다. 커밋 전 hook을 --no-verify로 건너뛰는 경로 또한 실행 스크립트 측에서 차단합니다.

리뷰하는 AI 자신도 속는다

리뷰를 담당하는 LLM은 리뷰 대상 코드에 섞여 들어간 지시를 따라버릴 가능성이 있습니다 (Prompt Injection). Anthropic 공식 README에도 "이 액션은 Prompt Injection에 대한 내성이 없으며, 신뢰할 수 있는 PR 리뷰 전용입니다"라고 명시되어 있습니다.

이 파이프라인에서 이 문제가 억제되고 있는 이유는, 리뷰로 흘러 들어가는 것이 파이프라인 자체가 생성한 코드뿐이기 때문입니다. Anthropic이 "신뢰할 수 있는 PR 전용"이라고 단정한 것과 동일한 전제 위에서 이 리뷰는 성립합니다.

도입 순서는 "취소할 수 있는가"로 결정한다

세 개의 층을 한꺼번에 도입하지 않고, 도입을 두 단계로 나누었습니다. 분기 기준은 피해의 불가역성입니다.

기능 버그는 나중에 고칠 수 있습니다. 하지만 시크릿(Secret)이 PR에 포함되어 외부로 유출되면 취소할 수 없습니다. 게다가 실험 단계의 run이야말로 토큰 취급이 소홀해지기 쉬우며, 리스크는 메커니즘이 미성숙한 지금이 더 높습니다. 따라서 ③(기계 계층)의 Secrets 스캔만은 LLM을 사용하지 않고 비용도 거의 들지 않으므로, 선행하여 즉시 도입합니다.

LLM을 사용하는 ①(스테이지 리뷰)와 ②(횡단 게이트)는 기능 측면의 결과물이 안정된 후에 활성화합니다. 앱이 기본적으로 작동하지 않는 동안에는 인가(Authorization)의 의미론적 리뷰 지적이 기능 결함과 섞여 원인 귀속이 모호해지며, Confidence 임계값이나 루프 상한의 교정(Calibration) 또한 베이스라인 품질이 불안정한 동안에는 측정이 불가능하기 때문입니다.

활성화 타이밍은 주관적으로 결정하지 않기로 했습니다. "최근 N run 연속으로 E2E가 통과하여 PR에 도달"과 같은 안정 지표를 먼저 합의하여 고정합니다. 이와 함께, 알려진 취약점을 의도적으로 심어놓은 교정용 케이스를 준비합니다. 미검출(False Negative)은 그대로 두면 관측할 수 없으므로, 검출할 수 있어야 할 것을 검출할 수 있는지에 대한 정점 관측(定点観測)이 필요합니다.

요약

인간이 코드를 읽지 않는 파이프라인의 보안 리뷰 설계로서, 이 글에서는 다음 3가지를 작성했습니다.

• 조사 결론: 전문 도구가 투자해 온 것은 검출력이 아니라 오탐(False Positive)의 억제이며, 규격은 게이트의 근거가 아니라 어휘의 공급원으로 사용한다.
• 설계 골자: 차분(Diff) 한정 스테이지 리뷰, 검증 레인이 포함된 횡단 게이트, LLM을 사용하지 않는 기계 계층의 3층 구조로 나누고, 무거운 검증은 돌이킬 수 없는 판정 직전에만 배치한다.
• 운영 원칙: 수정 루프에 상한을 두고, AI의 자기 면제(Self-exemption)를 차단하며, 도입 순서는 피해의 불가역성으로 결정한다.

Confidence 임계값의 초기값, 루프 상한의 구체적인 값, Block 기준 등 미결정된 파라미터는 아직 남아 있습니다. 이것들은 교정용 케이스와 실제 run의 측정을 통해 결정할 예정이며, 작동을 시작하면 속편으로 작성할 계획입니다.

마찬가지로 "AI에게 구현을 맡기는 메커니즘"을 만들고 계신 분이 있다면, 검출 카테고리를 늘리기 전에 제외 규칙과 검증의 위치부터 설계해 보시기 바랍니다. 저의 조사에 따르면, 그곳이 전문 도구와 그 외를 나누는 경계선이었습니다.

마치며

크로스텍 매니지먼트(Crosstech Management)사는 "교육 × AI"를 통해 차세대 학습을 창조하기 위해 탄생한 예술 대학 발 스타트업입니다.

관심이 있으신 분은 언제든 편하게 문의해 주시면 감사하겠습니다!

참고 링크

Discussion