Oh My OpenCode v4.4.0: /security-research — 5인 적대적 보안팀을 한 명령으로 띄우는 스킬

Oh My OpenCode v4.4.0: /security-research — 5인 적대적 보안팀을 한 명령으로 띄우는 스킬

7분 읽기원문 보기

안녕하세요, Tom입니다.

Oh My OpenCode v4.4.0이 공개됐어요. 이번 릴리스의 핵심은 단 하나, /security-research 스킬이에요. 한 명령으로 5명의 보안 전문가 에이전트를 띄워서 코드베이스를 적대적으로 분석하게 만드는 기능인데, [[2026-05-11-oh-my-opencode-v400]]에서 다룬 팀 모드를 본격적으로 활용한 첫 사례라 정리할 가치가 있어요.

/security-research가 뭐길래

한 줄로 설명하면, 5명의 보안 전문가 에이전트가 동시에 코드베이스를 공격자 관점에서 분석하는 스킬이에요. 명령은 단순해요.

/security-research

이 한 줄을 입력하면 5명 팀이 가동돼요. 구성은 이렇게 짜여 있어요.

  • 3명의 취약점 헌터 (Vulnerability Hunters)- Surface 헌터 — 표면적 취약점(XSS, CSRF, 잘못된 검증 등) - Auth/Data 헌터 — 인증·인가·데이터 보안 이슈 - Runtime/Supply Chain 헌터 — 런타임 및 공급망 취약점
  • 2명의 PoC 엔지니어 (PoC Engineers) — 발견된 취약점의 실제 공격 코드 작성

각 헌터가 자기 전문 영역만 깊게 파고, 발견한 게 있으면 PoC 엔지니어가 실제 공격 시나리오를 만들어 검증하는 구조예요. 역할 분담이 뚜렷한 보안 팀을 그대로 에이전트로 옮긴 형태죠.

핵심 원칙 — "실제 익스플로잇 경로가 없으면 보고하지 않는다"

이 스킬에서 가장 인상적인 부분이에요. 릴리스 노트에 명시된 원칙이 있어요.

"Every finding is calibrated by actual exploitability — no severity without an attack path."

번역하면 "모든 발견은 실제 익스플로잇 가능성으로 보정한다 — 공격 경로 없는 심각도는 없다"예요. 무슨 뜻이냐면, 이론적으로는 위험해 보이지만 실제로 공격이 가능한 경로가 없는 경우는 보고에서 빼버린다는 거예요.

이게 왜 중요하냐면, 보안 스캐너의 가장 큰 골칫거리가 false positive(오탐)이거든요. 자동화 도구들이 "이 코드에 SQL 인젝션 가능성이 있다"고 경고를 마구 띄우는데, 실제로 가보면 입력값이 미리 검증되거나 외부에서 접근할 수 없는 경로라서 무해한 경우가 대부분이에요. 이런 오탐이 쌓이면 개발자가 보안 보고서 자체를 무시하게 돼요.

/security-research는 PoC 엔지니어를 팀에 둠으로써 이 문제를 풉니다. "공격 코드를 실제로 짜봐서, 코드가 돌아가는 익스플로잇만 인정한다"는 원칙이에요. 결과적으로 보고서가 짧아지지만, 보고된 항목은 진짜 위험한 것들이에요.

산업 표준 프레임워크 채택

이 스킬은 보안 업계의 표준 프레임워크를 그대로 따라요.

  • CWE (Common Weakness Enumeration) — 취약점 분류 체계
  • OWASP WSTG/ASVS — 웹 보안 테스트 가이드와 검증 표준
  • CVSS v4.0 — 표준화된 심각도 점수

이 부분이 진지해 보여요. 그냥 LLM이 "위험해 보여"라고 말하는 게 아니라, 업계 표준 분류 코드를 붙이고 표준 점수 체계로 점수를 매긴다는 거예요. 보안 보고서를 사내 보안 팀이나 외부 감사인에게 제출할 때 호환되는 포맷이에요.

어떻게 활성화하나

기능이 강력한 만큼 기본 설정에서 꺼져 있어요. 사용하려면 설정 파일에서 팀 모드를 활성화해야 해요.

// oh-my-opencode.jsonc
{
  "team_mode": {
    "enabled": true,
  },
}

이 한 줄을 추가하면 /security-research를 비롯한 팀 모드 스킬을 쓸 수 있어요. 팀 모드 자체는 v4.0.0에서 도입된 기능이고, v4.4.0에서 보안에 특화된 스킬이 추가된 거예요.

Oh My OpenCode의 팀 모드 진화

작년부터 Oh My OpenCode 시리즈를 꾸준히 추적해 봤어요. [[2026-01-25-oh-my-opencode-v3]]에서 Atlas 오케스트레이터가 처음 등장했고, [[2026-02-12-oh-my-opencode-v350]]에서 "Atlas Trusts No One"이라는 서브에이전트 검증 구조가 들어왔어요. 그리고 v4.0.0에서 정식 팀 모드가 도입됐고, 이번 v4.4.0이 그 팀 모드를 활용한 첫 번째 도메인 특화 스킬이에요.

이 흐름이 흥미로운 게, 일반적인 멀티 에이전트 시스템과 다른 점이에요. 보통은 "에이전트를 여러 개 띄울 수 있다"까지가 끝인데, 이 프로젝트는 역할별 전문성과 산업 표준 프레임워크까지 결합한 사용 케이스를 만들어내고 있어요. 보안이 첫 도메인이라면, 다음에는 어떤 도메인 특화 스킬이 나올지 기대돼요.

어떻게 쓰면 좋을까

제 생각엔 이 스킬은 다음 시나리오에서 특히 가치가 있어요.

  • 출시 전 보안 점검 — 코드 동결 직전에 한 번 돌려서 P1급 취약점 찾기
  • PR 리뷰 보조 — 보안 민감 코드(인증, 결제, 권한 관리 등)에 대한 PR을 머지하기 전에 추가 검토
  • 레거시 코드베이스 감사 — 오래된 코드의 보안 부채를 한 번에 훑어보기

다만 한계도 명확해요. AI 기반이라 학습 데이터에 없는 새로운 공격 기법은 발견하지 못할 수 있어요. 그리고 실제 침투 테스트(red team) 수준의 깊이는 아직 못 따라가요. 어디까지나 "1차 자동 점검"이라는 위치로 보는 게 맞아요.

총평

/security-research"에이전트 팀 모드의 첫 실용적 도메인 적용 사례"예요. 5명 팀 구성, 실제 익스플로잇 검증, 산업 표준 프레임워크 — 세 가지가 결합되면서 "AI로 보안 점검"이 그럴듯한 단계에서 실용적인 단계로 한 발 진보했어요. [[2026-04-06-roach-pi]]에서 다룬 Worker-Validator 분리와도 같은 결의 디자인이에요.

참고: 보안은 영역 특성상 오탐을 줄이고 진짜 위험만 잡는 것이 가장 어려워요. 이 스킬이 그 부분에서 어떻게 작동하는지 실전에서 검증되는 사례가 더 쌓이면 좋겠어요. 일단 자기 프로젝트에 한 번 돌려보고 보고 결과의 질을 직접 평가해 보는 걸 추천해요.


원문: oh-my-opencode v4.4.0 Release Notes

관련 글