서론

Anthropic이 /plugin install 한 줄로 설치할 수 있는 공식 security plugin을 release했습니다.

security-guidance ── Claude Code에 install하면, Claude가 작성한 코드를 다른 Claude가 백그라운드에서 리뷰해 주는 구조입니다.

무엇이 좋은지 먼저 요약하자면 다음과 같습니다.

AI가 코드를 작성하는 속도를 인간의 리뷰가 따라가지 못한다는 현장의 고민에 대해, Anthropic 스스로가 공식 plugin으로 정면 대응했다 -
3단계 리뷰 타이밍 (편집 시 / 턴 종료 시 / commit 시)을 통해 비용과 커버리지(Coverage)가 깔끔하게 트레이드오프(Trade-off)되어 있다 -
코드를 작성한 Claude 본인에게 리뷰를 맡기지 않는다 (별도의 context를 가진 Claude가 확인)는, 인간의 코드 리뷰와 동일한 독립성 설계 - 어느 계층도 쓰기나 commit을
물리적으로 차단하지 않고, 작성자의 자유와 책임을 마지막까지 남겨두는 설계 -
.claude/security-patterns.yaml을 통해, 자사 고유의 금칙 규칙을 결정론적(deterministic)으로 추가할 수 있다 -
모든 플랜에서 사용 가능 (per-edit 계층은 비용 0, end-of-turn / commit 계층은 usage 과금), 게다가 OSS 구현으로 내부를 들여다볼 수 있다

이 정도가 공식 doc을 한 번 다 읽고 난 뒤 제 머릿속에 남은 '장점' 리스트입니다.

시계열로 조금 정리하자면, 저는 바로 오늘 아침 Anthropic Managed Agents의 리뷰 기사를 막 다 쓴 참이었습니다. 그때 중심에 두었던 것이 Isabella He 님의 *

여기서 느낀 점: 아침의 하네스(Harness) 기사와 저녁의 security-guidance plugin 뉴스가, 동일한 「agent loop의 진화」라는 서로 다른 음색이라는 것을 깨달은 순간, Anthropic이 어디를 향해 움직이고 있는지 그 윤곽이 한 단계 더 선명해진 기분이 들었습니다. 반나절 차이로 내려온 두 가지 소재는 제 안에서 아름답게 같은 화음으로 울려 퍼지며, 한동안 머릿속에서 계속 맴돌 것 같습니다.

2. 같은 날 움직이고 있었던, 다른 레이어의 「하네스」

여기서는 이 plugin과 같은 날에 일어났던, 조금 더 다른 레이어의 「하네스」 움직임을 나열해 보겠습니다. 오늘(2026년 5월 27일)은 되돌아보면, 기술·조직·인재라는 세 가지 레이어에서 동시에 하네스가 진화한, 한동안 기억해 두어야 할 하루가 될 것 같습니다.

사실 이 security-guidance plugin 뉴스가 흘러나온 것과 거의 같은 타이밍에, 또 다른 큰 발표가 있었습니다. 일본 국내에서는 Fujitsu와 Anthropic의 전략적 파트너십 체결 뉴스입니다.

당사 그룹 전 사원(약 10만 명)이 Anthropic의 「Claude」를 스스로 활용하여 업무의 고도화, 고속화를 실시하면서, AI를 안심하고 안전하게 사용할 수 있는 형태를 실천적으로 검증해 나갑니다.

── Fujitsu 보도자료 (2026년 5월 27일)

10만 명 규모의 조직이 Anthropic의 Claude를 업무에 편입시켜 나간다. 이는 모델 그 자체를 구동하는 「기술 하네스 (Technical Harness)」가 아니라, **조직이 AI를 어떻게 움직일 것인가라는 「조직의 하네스 (Organizational Harness)」**에 관한 이야기로 보였습니다.

그리고 사람의 흐름 또한 같은 레이어를 움직이고 있다는 느낌이 듭니다.

• OpenAI 공동 창업자인 Andrej Karpathy가 Anthropic으로 (2026년 5월 19일, pre-training team에 합류)
• 「OpenClaw」의 개발자인 Peter Steinberger가 OpenAI로 (2026년 2월 15일, "next generation of personal agents" 담당)

이 부분이 조금 흥미로운 지점인데, OpenClaw는 원래 "Clawdbot"이라는 이름으로 Claude 위에 만들어진, 말하자면 오픈 소스 버전의 「에이전트 하네스 (Agent Harness)」입니다 (Anthropic 측의 법무 지적으로 인해 개명된 경위가 있음).

그 오픈 소스 하네스를 설계한 당사자가 OpenAI로 옮겨가고, Anthropic은 Anthropic대로 자사제 일급 시민 하네스로서 Managed Agents를 퍼블릭 베타(Public Beta)로 내놓고 있습니다.

같은 「에이전트 하네스」라는 레이어에서, 누가 어디에서 어디로 움직이는가. AI의 「다음 몇 년」이 어디에서 형성되어 가는가, 그 지형이 재편되는 중이라고 느낍니다. 솔직히 말해, 이러한 흐름 속에 몸을 담고 있다는 것 자체만으로도 설렙니다.

여기서 느낀 점: 아침에 읽은 Isabella He 님의 *"Harnesses should evolve alongside your agents."*라는 문장은, 어쩌면 기술적 하네스만을 가리키는 것이 아니었을지도 모릅니다. 조직의 하네스(운용 기반·인재·지견)도, 인재의 하네스(누가 어느 팀에서 어느 레이어를 움직이고 있는가)도 같은 속도로 진화시켜 나가야 하는 시대에 접어들었다 ── 다시 말해, 조직의 의사결정도, 인재 배치도 기술적 하네스와 같은 속도로 움직여 나가야 하는 시대가 되었다는 뜻일지도 모르겠습니다. 반나절 차이로 내려온 일련의 뉴스들을 나열해 보며 다시 한번 그렇게 느끼고 있습니다.

3. plugin이 해결하려는 문제

여기서는 이 plugin이 애초에 어떤 현장 과제에 손을 대고 있는지를 정리해 보겠습니다.

공식 문서(doc)는 plugin의 역할을 상당히 담담하게 설명하고 있습니다. 의역하자면, "Claude가 작성한 코드를 Claude 스스로가 (다른 context에서) 동일한 session 내에서 리뷰하고, 발견한 문제를 동일한 session 내에서 수정한다"는 것입니다. Pull Request까지 도달하기 전, 편집 중인 단계에서 보안 리뷰(Security Review)를 끼워 넣는다고 바꾸어 말할 수도 있을 것입니다.

저 자신도 AI Solutions Architect로서 고객과 함께 AI를 이용한 코드 생성 워크플로우를 설계하는 장면이 늘어나고 있습니다. 생성된 코드의 보안(Security)을 어떻게 담보할 것인가라는 질문은 이제 「언젠가 생각할 일」이 아니라 「매 프로젝트의 전제 조건」이 되어가고 있습니다.

「injection(인젝션)이 섞여 있지 않은가」, 「pickle로 위험한 deserialization(역직렬화)을 하고 있지 않은가」, 「.innerHTML에 외부 입력을 그대로 전달하고 있지 않은가」

이러한 관점을 매 파일, 매 차분(diff)마다 수동으로 확인하는 것은, AI가 고속으로 코드를 생성해내는 현실과 솔직히 말해 시간축이 맞지 않습니다.

여기서 느낀 점: 이 plugin의 발상은 「보안 리뷰를 후공정에 두는 것」이 아니라 「작성하는 도중에 끼워 넣는 것」이었습니다. 제 머릿속에서는 이것이 **「인간 리뷰어의 한정된 시간과 AI의 생성 속도 사이의 미스매치(mismatch)」**를, 별도의 AI를 관찰자로서 사이에 끼워 넣음으로써 메우려는 설계로 보였습니다. AI로 AI를 본다는 말을 듣는 순간 조금 경계하게 되는 부분도 있지만, 후술할 독립성 설계에 관한 내용을 읽고 나면 그 위화감은 상당히 해소됩니다.

4. 삼층 구조를 읽어내다

여기서는 plugin이 준비한 세 가지 검사 계층을, 각각이 「이전 계층으로부터 무엇을 해방하고, 무엇을 여전히 남겨두고 있는가」라는 관점에서 읽어보겠습니다.

공식 doc에는 리뷰 타이밍이 세 가지로 나누어 적혀 있습니다.

여기서 느낀 점: 삼층 구조의 구성이 저에게는 솔직히 깔끔하게 보였습니다. 제1층은 속도와 확실성을 위해 model을 포기하고, 제2층은 문맥을 포착하기 위해 model을 호출하며, 제3층은 주변 코드까지 읽으러 가기 위해 agentic하게 동작합니다. 모든 것을 한 단계에서 완벽하게 해내려 하지 않는다는 절제미가 각 단계의 역할을 명확하게 해주고 있습니다.

이는 제가 평소 접하는 Cloud / SRE 세계에서 말하는 「defense in depth(다층 방어)」와 거의 같은 발상으로 느껴졌습니다.

제1층은 비용 0인 대신, 문자열 매칭으로 보이는 범위만 포착할 수 있습니다. eval(을 작성하면 반드시 걸러내는 확실성을 대가로, 비즈니스 로직의 취약성은 당연히 찾아낼 수 없다는 절제입니다. 그럼에도 불구하고, deterministic하게 포착할 수 있는 종류의 리스크를 deterministic하게 확실히 포착한다는 설계는, 첫 번째 단계의 역할로서 충분히 기능하고 있다고 느꼈습니다.

제2층에서는 turn의 종료 시점에 해당 turn 중에 변경된 파일 diff를 별도의 context를 가진 Claude에게 리뷰하게 하는 구조로 되어 있습니다. 여기서 doc에 단 한 문장이지만 매우 강한 어조로 적혀 있는 부분이 있습니다.

The plugin does not ask the same Claude instance that wrote the code to grade itself.

「코드를 작성한 Claude 본인에게, 그 Claude 스스로를 grade(평가)하게 하지 않는다」. 이에 대해서는 다음 장에서 자세히 다루겠습니다.

5. 「별도의 Claude」가 본다는 설계

여기서는 이 plugin이 가장 중요하게 여기며 만든 설계 판단인, 리뷰어의 독립성에 대해 정리해 보겠습니다.

공식 doc에는 다음과 같이 적혀 있습니다.

The per-edit check is a deterministic string match with no model involved. The end-of-turn and commit reviews run as a separate Claude call with a fresh context and a security-focused prompt: the reviewer starts from the diff, has no investment in the original approach, and is instructed only to find problems.

의역하자면, 제1층은 모델(model)이 없는 결정론적 체크(deterministic check)이며, 제2층과 제3층은 새로운 컨텍스트(fresh context)를 가진 별도의 Claude가 보안 전용 프롬프트(security prompt)를 사용하여 차이점(diff)만을 검토합니다. 리뷰어는 원래의 접근 방식(approach)에 대한 투자 없이, 오직 문제점을 찾는 것만을 지시받는 구조로 되어 있습니다.

여기서 느낀 점: 이 문장이 오늘 가장 기억에 남습니다. 인간의 코드 리뷰(code review) 업계에서 수십 년간 사용되어 온 "작자와 다른 사람이 리뷰한다"라는 대원칙을, Anthropic은 AI 레이어(layer)에서 정성스럽게 재현해냈다고 느꼈기 때문입니다. 언뜻 보면 당연한 원칙처럼 보이지만, "AI가 AI를 리뷰한다"라는 말을 듣는 순간 경계심을 갖는 사람이 많다는 점을 고려하면, 이 부분을 정면으로 설계해 왔다는 점은 저에게 매우 큰 판단으로 다가왔습니다.

AI가 고속으로 코드를 생성하는 시대가 되어도, "자신이 작성한 것에 점을 찍지 마라"라는 리뷰의 대원칙은 인간과 동일한 방식으로 적용됩니다.

기술이 변해도 리뷰의 철학은 변하지 않습니다. 오히려 AI가 빠르기 때문에 리뷰어의 독립성을 여러 겹으로 보장하고 싶어 합니다. 이는 저 자신이 고객과의 대화 속에서 반복해서 설명해야 할 테마라고 다시 한번 느꼈습니다.

그리고 한 가지 더, 제가 개인적으로 좋아하는 설계가 있습니다. 이 플러그인(plugin)은 어떤 층에서도 쓰기(write)나 커밋(commit)을 물리적으로 차단하지 않는다는 점입니다.

None of the layers block writes or commits. Findings reach the writing Claude as instructions, Claude addresses them in the conversation

의역하자면, 어떤 층도 쓰기나 커밋을 물리적으로는 막지 않습니다. 발견된 사항(findings)은 작성 측 Claude에게 지시 사항(instruction)으로 전달되며, Claude가 이를 수정할지 여부를 판단(judge)하는 설계입니다.

여기서 느낀 점: 보안 가드(security guard)가 엄격해질수록 작성자의 자유가 억제되고, 결과적으로 우회(bypass)되는 경향이 생긴다 ── 이는 보안 현장에서 수없이 반복되어 온 실패라고 생각합니다. Anthropic이 차단하지 않는 설계를 선택한 것은, 자유와 책임의 경계선을 움직이지 않기 위한 현명한 판단이라고 저는 받아들였습니다. 작성자는 마지막까지 자유롭되, 그 대신 마지막까지 책임을 집니다. AI가 작성하는 시대에도 이 경계선은 인간이 작성하던 시대와 같은 위치에 있다는 것을 다시 한번 느낍니다.

마치며

지금까지 공식 문서(doc) 한 편을 읽고 정리한 내용을 적어보았습니다. 아직 설치(install)하지도 않았고, 직접 만져보지도 않았습니다. 그럼에도 이 타이밍에 글을 쓰고 싶었던 이유는, 오늘 이 플러그인을 읽은 엔지니어의 머릿속에 그려진 지도를 잊기 전에 남겨두고 싶었기 때문입니다.

오늘 아침에 쓴 Managed Agents 관련 기사에서, 저는 Isabella He 씨의 *"Harnesses should evolve alongside your agents."*라는 문장을 중심으로 "하네스(harness)가 에이전트와 함께 진화한다면, 자신의 머릿속 프레임워크(framework) 또한 똑같이 계속 진화시켜 나가야 한다"라고 썼습니다.

그리고 저녁이 되어 security-guidance plugin 뉴스가 흘러나왔고, Anthropic이 바로 하네스를 진화시키고 있는 순간에 저는 기사를 쓰며 제 머릿속의 지도를 업데이트하고 있었습니다.

그와 동시에 Fujitsu와 Anthropic의 전략적 파트너십이 발표되었고, Karpathy나 Steinberger 같은 간판 엔지니어들이 대형 AI 연구소 사이를 이동하고 있다는 뉴스도 들려왔습니다.

기술 하네스, 조직 하네스, 인재의 하네스 — 세 가지 레이어가 같은 날 움직이고 있었습니다.

그런 날로서, 저는 앞으로 당분간 이 날을 기억할 것 같습니다.

하네스가 진화한다면, 그것을 해석하는 엔지니어의 언어 또한 계속해서 진화시켜 나가야 합니다.

그런 생각을 다시 한번 하게 됩니다.

내일부터는 Phase B 작업과 병행하여, 이 플러그인을 실제로 설치하여 구동해 볼 예정입니다. 첫 독해를 통한 정리와 실제 경험 사이에 어느 정도의 차이가 발생하는지, 그것을 또 하나의 기사로 남길 수 있다면 좋겠습니다. 이번 정리는 그것을 위한 발판으로서 우선 이대로 이곳에 두겠습니다.

기술이 변해도 리뷰의 철학은 변하지 않습니다.

오히려 AI가 빨라지는 시대이기 때문에, 독립성과 책임의 라인을 몇 번이고 정성스럽게 다시 구축할 가치가 있다고 생각합니다.

그리고 동시에, 일본의 중요 인프라 영역에 AI를 구현해 나가는 업무에 더욱 깊이 관여하고 싶다

오늘의 일련의 발표를 보며 다시 한번 그렇게 느끼고 있습니다.

참고 링크

• 공식 doc: Catch security issues as Claude writes code
• 공식 marketplace: Security Guidance plugin
• OSS source: anthropics/claude-plugins-official
• Anthropic 공식 announcement: Making frontier cybersecurity capabilities available to defenders
• 오늘 아침 공개한 Managed Agents 리뷰 기사: 신등장 Claude Managed Agents란 무엇인가
• 같은 날 발표된 Fujitsu × Anthropic 전략적 파트너십: Fujitsu 보도자료
• Andrej Karpathy → Anthropic: TechCrunch (2026-05-19)
• Peter Steinberger → OpenAI: TechCrunch (2026-02-15)

Discussion