2026년 10월 19일, 『Linux에서 앞으로 로링(rolling) 릴리스가 주류가 될지도 모른다』라는 기사가 ZDNET Japan에 실렸습니다. 그 계기 중 하나는 Linux의 창시자인 Linus Torvalds가 커널 개선에 Claude Code를 사용했다는 것입니다. AI로 구멍이 발견되는 속도가 빨라졌기 때문에, 반년마다 한 번에 고치는 것보다 조금씩 계속 내놓는 방식이 따라잡기 쉽다는 것이 기사 필자의 견해였습니다.
半年ごとにまとめて直す標準リリースと、少しずつ出し続けるローリングリリースの比較
AI로 앱을 만들고 있는 사람에게도 남의 일이 아닙니다. 매일같이 AI에게 코드를 수정하게 한다면, 점검 역시 '공개 전 한 번'으로 멈추지 않고 변경할 때마다 돌리고 싶은 마음입니다. Qiita에서는 이 이야기를 자신의 앱에 대입하여 작성했습니다.
그렇다면 Claude Code에 보안 진단 MCP를 연결하면, 점검이 변경할 때마다 돌아가게 될까요? 시험해 보니, 단순히 연결만 했을 때는 4번 중 0회였고, AI는 한 번도 진단을 호출하지 않았습니다. CLAUDE.md
에 한 줄을 쓰자, 세 번 모두 호출했습니다. 이 기사에서는 비교한 조건과 결과, 실제로 넣은 한 줄, 그리고 활용 시 주의사항을 정리합니다.
Who am I?
BPR Prot.이라는 AI로 만든 웹 앱의 공개 전 확인을 돕는 서비스를 만들고 있습니다. X(구 트위터)에서는 실제로 진단/검증한 기록과 그곳에서 알게 된 데이터나 코드를 매일 발신하고 있습니다. 괜찮으시면 확인해 주세요!
두 가지 조건으로 동일 수정 테스트 진행
MCP는 Claude Code 같은 AI에 외부 도구를 연결하는 장치입니다. 저희가 만든 진단 툴의 MCP를 연결하자, 코드 진단의 security_scan을 포함한 4가지 도구 외에도 '새로운 코드를 작성했을 때, 기존 코드를 변경했을 때, 공개 전에는 반드시 진단을 호출하라'는 지시문도 AI에게 전달됩니다.
테스트한 것은 지난 기사와 같은 Next.js 요약 앱입니다. 화면 측에서 OpenAI를 호출하려 했으나 키가 읽히지 않아, 요약 버튼에서 멈추는 상태에 다음 요청문을 전달했습니다.
文章を要約しようとすると画面が止まります。コンソールには『OpenAIError: The OPENAI_API_KEY environment variable is missing or empty; ...』と出ています。直してください。直したらコミットしてください。
비교한 것은, MCP만 연결한 조건 A와 앱 폴더의 CLAUDE.md에 한 줄만 추가한 조건 B 두 가지입니다. 조건 B에서 실제로 넣은 것은 다음 한 줄이었습니다.
コードを書いたり変えたりしたら、コミットする前に bpr-prot の security_scan で診断し、指摘があれば直してください。
실험일은 2026년 10월 19일이며, macOS상의 Claude Code 2.1.295를 무인 실행의 -p로 구동했습니다. 평소 설정을 읽게 하지 않도록 --setting-sources project,local을 지정하고, 진단 툴의 4가지 도구는 --allowedTools로 확인 없이 사용할 수 있는 상태로 만들었습니다. 즉, 조건 A에서 진단을 호출하지 않은 이유는 도구 허가가 없었기 때문이 아닙니다.
CLAUDE.md에 한 줄을 넣은 조건에서는 세 번 모두 진단 호출함
결과는 다음과 같습니다. 조건 A는 3회에 시도 1회를 더해, 조건 B는 3회 실행했습니다.
| 항목 | A: 연결만 함 | B: CLAUDE.md 에 한 줄 추가 |
|---|
| 진단 호출 여부 | 0/4 | 3/3. 1회 작업에 3~4회씩 |
| ... | | MCPをつないだだけの条件とCLAUDE.mdに一行置いた条件で、AIの作業の流れを比べた図 |
조건 A에서는 AI가 진단을 호출하지 않은 채 코드를 수정하고 커밋했습니다. 완성된 API를 나중에 같은 진단 툴에 직접 적용하자, 로그인 확인이 없어 누구나 실행할 수 있는 구멍을 CVSS 7.5, 횟수 제한이 없어 비용이 늘어날 우려를 CVSS 5.3으로 지적했습니다. 호출했더라면 발견했을 두 개의 구멍입니다.
조건 B에서는 AI가 진단으로부터 로그인 없음과 횟수 제한 없음의 지적을 받고, 횟수 제한을 넣은 후 다시 한번 진단을 하는 흐름을 반복했습니다. 한편, 원래 앱에는 로그인 기능이 없었기 때문에 로그인은 추가하지 않았습니다. 세 번 모두, 로그인을 붙일지는 설계 판단이므로 공개 전에 결정해 주기를 사용자에게 전달했습니다.
어느 조건에서도 키에 NEXT_PUBLIC_
~~를 붙여 화면에 표시하는 방법은 선택하지 않고, '그렇다면 키가 누구에게나 보일 수 있다'고 답변으로 이유도 설명했습니다. 또한, 입력은 2만 자까지로 제한하고, 입력문 속의 지시에 따르지 않는 방지 장치(工夫)도 마련했습니다. 진단을 호출했는지 여부 외에도 AI가 지킨 점이 있었습니다.
연결만으로는 검사가 '공개 전 1회' 유형에 머물렀다
이번 MCP 연결에서는 도구뿐만 아니라, 코드를 작성하거나 변경할 때 진단을 호출하라는 지시문도 전달했습니다. 그럼에도 불구하고 조건 A의 AI는 작업 중에 진단을 사용하지 않았습니다. 도구는 손에 있지만, 변경할 때마다 검사가 일어나지 않아, 나중에 사람이 기억해서 진단을 거치기 전까지 구멍은 그대로 남아 있었습니다. Linux의 말로 하자면, 업데이트는 로링(rolling)인데, 검사만 모아서 하는 방식에 머물렀습니다. 앱 폴더 안에 있는 작업 규칙인 CLAUDE.md
에 적힌 조건 B에서는 세 번 모두 사용했습니다.
이 차이점에서 알 수 있는 것은, 도구를 전달하고 사용하도록 촉구하는 것만으로는 호출되지 않는 경우가 있으며, 같은 내용을 폴더의 작업 규칙에 두자 이번 조건에서는 호출되었다는 점입니다. 작업 중에 참조하는 장소에 명시한 것이 차이로 이어진のかもしれません(아마도). 작업 중에 참고할 곳에 명시한 것이 차이가 되었을지도 모릅니다.
자신의 환경에서 시험해 볼 때는, 한 줄과 도구 허가를 세트로 한다
시험해 본다면, 앱 폴더 안에 있는 CLAUDE.md
에 다음 형태로 한 줄을 넣을 수 있습니다. <MCP 이름>
와 <도구명>
부분을 자신의 환경에서 사용하는 이름으로 대체합니다.
코드를 작성하거나 변경했다면, 커밋하기 전에 <MCP 이름>의 <도구명>을 사용하고, 지적 사항이 있다면 수정할 것.
함께 그 도구를 AI가 사용할 수 있도록 허가합니다. 이번 실험에서는 --allowedTools
를 사용했지만, 허가하지 않았다면 호출할 때마다 확인 메시지가 나옵니다. 우선 작은 변경으로 진단 호출, 지적 후 수정, 재진단까지 진행되는지 답변과 실행 기록을 통해 살펴봅니다.
진단이 늘어날수록 시간과 AI 사용량도 늘어납니다. 이번에는 조건 A의 약 37104초에 대해 조건 B는 약 138197초였고, Claude Code가 제시하는 예상 요금으로 본 AI 사용량은 대략 2.5~3배였습니다. 매번 변경할지, 공개 전 등으로 한정할지는 드는 양도 고려하여 결정하는 것이 현실적입니다.
또한, 진단의 지적을 모두 AI만 결정할 수는 없습니다. 이번 로그인처럼, 원래 앱의 설계와 관련된 항목은 AI가 사용자에게 판단을 돌려주었습니다. 횟수 제한도 간이 버전이었기 때문에, 공개할 구성에 맞는지 여부는 스스로 결정해야 할 부분이 남아 있습니다.
이 시험 방법은 우리가 만들고 있는 진단 도구에만 국한되지 않습니다. 테스트나 린터(linter)의 MCP에서도 어느 상황에서 어떤 도구를 사용할지 폴더의 작업 규칙에 작성하고, 실제로 호출되는지 보는 형태로 바꿀 수 있습니다.
이 결과는 작은 무인 실험 범위에 한정된다
이번에는 하나의 장면을 각 3번씩, 조건 A만 시험하는 것을 1회 더한 작은 실험이었고, AI의 판단은 매번 흔들립니다. 무인 실행(-p)으로 시도했기 때문에, 평소 대화에서는 결과가 달라질 가능성이 있습니다. 또한, 의존 패키지를 넣지 않은 경우도 있어, 실제로 요약이 작동하는 곳까지는 시험할 수 없었습니다.
횟수 제한도 서버의 메모리로 계산하는 간이 버전입니다. 본 서비스 구성에 따라서는 공유 저장소가 필요합니다. 시험한 AI는 Claude Code만 사용했고, Cursor 등에서는 아직 시도하지 않았습니다.
AI로 구멍을 발견하는 속도가 빨라진다면, 만드는 측의 검사도 변경 리듬에 맞추고 싶습니다. 그러기 위해서는 도구를 연결할 뿐만 아니라, '언제 어떤 도구를 사용할지'까지 앱의 작업 규칙에 적어야 합니다. 우선 한 줄부터, 자신의 환경에서 AI가 어떻게 작동하는지 살펴보는 것이 좋을 것 같습니다.
우리에 대해
AI와 함께 코드를 고치는 횟수가 늘어날수록, 검사까지 매번 기억해 두는 것은 솔직히 쉽지 않습니다. BPR Prot.은 AI로 만든 앱/웹 서비스의 출시 전 최종 확인부터, 공개 후 지켜보는 것까지를 하나의 도구로 동행하는 서비스입니다.
- URL을 넣으면 웹사이트 보안을 A~F로 채점
- 코드 취약점 진단
- 파일 악성코드 검사
- 개발 중 직접 진단을 호출하는 MCP 연동(Pro 플랜)
웹 진단, 코드 진단, 악성코드 검사는 무료 플랜에서도 사용할 수 있습니다. 공개 전이나 변경 후 검사에 필요하시면 활용해 주세요!
X에서도 이러한 검증 기록을 발신하고 있습니다. 시험해 본 결과도 편하게 알려주시면 기쁠 것 같습니다!
끝까지 봐주셔서 감사합니다.
그럼 좋은 개발 라이프 되세요! ﾉｼ
출전
ZDNET Japan(Yahoo!뉴스 전재) · 2026-10-19 · Linux에서 향후 로링 릴리스가 주류가 될 가능성과 AI가 가져올 변화를 다룬 기사
Discussion
