AI 코드·스니펫 검사 글에 판단 매트릭스와 유입 경로 도식 추가

content/ko/blog/2026/20260608_ai_snippet_scan/index.md

@@ -80,13 +80,15 @@ AI 코드 스니펫이 라이선스 위반 분쟁으로 이어진 사례부터 
 
 ## 회사 조건별로 본다면
 
-| 회사 유형 | 스니펫 검사의 비중 | 이유 |
-|---|---|---|
-| 코드를 외부에 전달하지 않음 (순수 SaaS, AGPL 구성요소 미사용) | 낮음 | 배포가 아니라 카피레프트 의무가 잘 생기지 않음 |
-| 코드나 바이너리를 고객에 전달, 단 외부 감사 없음 | 상황에 따라 | 라이선스 의무가 생길 수 있으나 외부에서 들여다볼 일이 없음 |
-| 코드 전달 + 인수합병 실사, 고객 감사, 규제 | 높음 | 외부에서 출처를 실제로 확인하는 지점 |
+앞의 두 조건을 두 축으로 놓으면 네 갈래가 나옵니다.
+
+![코드를 외부에 전달하는지와 외부 검증을 받는지를 두 축으로 놓은 사분면. 둘 다 해당하는 경우에만 스니펫 검사의 비중이 높고, 코드를 전달하지 않으면 검증 여부와 무관하게 낮다](./snippet-decision-matrix.png)
+
+**그림 1.** 두 조건에 따른 스니펫 검사의 비중
+
+오른쪽 위 칸이 부담이 가장 큰 자리입니다. 코드가 회사 밖으로 나가 라이선스 의무가 생기는데, 인수합병 실사나 고객 감사처럼 그 의무를 실제로 들여다보는 계기까지 있는 경우입니다. 왼쪽 위는 의무가 생기더라도 확인할 사람이 없어 잠재 상태에 머뭅니다. 아래 두 칸은 배포 자체가 없어 따질 의무가 잘 생기지 않습니다.
 
-표는 판단의 출발점이지 정답이 아닙니다. 같은 칸에 있더라도 다루는 코드의 성격, 사용하는 라이선스의 종류, 회사의 위험 감수 수준에 따라 선택은 달라질 수 있습니다.
+이 그림은 판단의 출발점이지 정답이 아닙니다. 같은 칸에 있더라도 다루는 코드의 성격, 사용하는 라이선스의 종류, 회사의 위험 감수 수준에 따라 선택은 달라질 수 있습니다.
 
 ## 임베디드는 사정이 다릅니다
 
@@ -102,6 +104,14 @@ AI 코드 스니펫이 라이선스 위반 분쟁으로 이어진 사례부터 
 
 이 설정은 사후 스니펫 스캔과 목적이 겹치는 부분이 있습니다. 한쪽은 들어온 뒤에 찾아내고, 다른 한쪽은 들어오기 전에 막습니다. 둘 중 무엇을, 어느 정도로 둘지는 위의 조건과 비용을 함께 보고 정할 문제입니다.
 
+지금까지 나온 유입 경로와 검사 수단을 한자리에 놓으면 이렇습니다.
+
+![코드가 들어오는 경로 세 가지와 각각을 잡아내는 수단. 패키지 매니저로 선언된 것은 의존성 단위 SCA가 보지만, 복사·붙여넣기나 AI 생성으로 들어온 조각과 매니페스트 없이 소스째 복사한 임베디드 코드는 스니펫 매칭만 잡는다](./code-inflow-coverage.png)
+
+**그림 2.** 코드 유입 경로와 이를 잡아내는 수단
+
+의존성 단위 SCA가 보지 못하는 영역이 어디인지, 그 자리를 스니펫 매칭이 어떻게 메우는지가 이 판단의 출발점입니다.
+
 ## 판단을 위한 기준
 
 이 판단이 간단하지 않은 데는 이유가 있습니다. 패키지로 선언되지 않은 채 복사되거나 AI가 만들어 넣은 코드 조각을 찾아내는 방법은 사실상 스니펫 매칭뿐입니다. 의존성 단위 SCA도, 코드를 거르는 설정도 그 조각까지 다 잡아내지는 못합니다. 그래서 스니펫 매칭만이 채워 주는 부분이 작게나마 남습니다. 그런데 많은 회사에서 그 작은 부분이 실제 손실로 이어지는 경우는 드물고, 스니펫 검사에는 도구 비용과 검토 노력이 듭니다. 결국 이 작은 위험을 막으려고 그만한 비용을 들일지 말지를 정하는 일입니다.