서론

안녕하세요, Canly에서 SRE를 맡고 있는 요시무라입니다.

이번 글에서는 각 프로덕트에서 사용 중인 컴포넌트의 취약점 정보를 GitHub Projects 대시보드에서 일원화하여 관리하고, 개발자에게는 각 레포지토리의 이슈 형태로 전달하는 시스템을 구축한 경험에 대해 이야기하고자 합니다.

※ 여기서 말하는 컴포넌트는 npm 등의 언어 라이브러리뿐만 아니라 OS 패키지(deb 등)나 미들웨어까지 포함하여 의존 소프트웨어 전반을 의미합니다.

간단히 요약하면,

• 취약점 대응이 '누군가 우연히 발견하는' 상태에서 Notion 리포트 × Enabling MTG를 통한 동기적인 공유로 발전했지만, 태스크화된 이후의 추적(즉, 상황을 일일이 물어보는) 비용이 남아있었습니다.
• 회사 내부적으로는 모든 레포지토리의 SBOM을 취합하여 grype / xeol로 취약점 및 EOL(End of Life)을 탐지하는 기반이 팀에 의해 이미 갖춰져 있었습니다. 다만, 탐지는 할 수 있어도 '대응되는 상태'까지는 도달하지 못했습니다.
• 그래서 그 탐지 결과를 SRE와 개발자 각각에게 전달되는 형태로 바꾸는 작업에 착수했습니다. 구체적으로는 Claude Code를 이용한 각 레포지토리로의 이슈 자동 생성과 GitHub Projects 대시보드로의 취합입니다.
• 결과적으로, 대응해야 할 레포지토리에 이슈 형태로 취약점이 나타나고, 동기적인 공유 자원에 의존하지 않는 비동기적인 취약점 대응이 가능해졌습니다.

즉, '탐지하는 시스템'을 '대응되는 시스템'으로 바꾼 이야기라고도 할 수 있습니다.

취약점 관리의 시스템화를 검토하고 계신 분이나, SRE로서 개발팀에 Enabling(역량 강화)를 진행하고 계신 분들께 도움이 되기를 바랍니다.

🤔 배경: 취약점 관리의 3가지 페이즈

Canly는 여러 프로덕트를 제공하고 있어 레포지토리의 수도 그만큼 많습니다. 프로덕트마다 언어와 프레임워크가 다르기 때문에, 의존하는 컴포넌트의 취약점은 레포지토리별로 산발적으로 발생합니다.

이런 환경에서의 취약점 관리는 한 번에 지금의 형태로 된 것이 아니라, 3가지 페이즈를 거쳐왔습니다.

페이즈 1: 알림이 없고, 사람이 우연히 발견하는 경우

처음에는 시스템이라 할 만한 것이 없었고, 취약점은 '누군가 우연히 발견함'으로써 알려지는 경우가 대다수였습니다.

• 누가 언제 확인할지 정해져 있지 않아, 탐지 자체가 운에 맡겨졌습니다.
• 발견한 사람의 선의로 대응되거나, 기능 개발 태스크에 묻혀 방치되는 식이었습니다.
• SRE가 전체 그림을 파악하려고 하면, 레포지토리를 하나하나 순회할 수밖에 없었습니다.

탐지조차 제대로 되지 않는 단계에서는 관리 자체를 시작할 수 없었습니다.

페이즈 2: Notion 리포트 × Enabling MTG를 통한 동기 공유

그래서 다음 단계로, SBOM을 기반으로 한 취약점 탐지 기반을 갖추고, 탐지 결과를 주기적으로 Notion 보고서로 정리하여 개발팀과의 Enabling MTG에서 공유하며 대응을 요청하는 운영을 시작했습니다.

탐지는 정기화되었고, 공유할 장소도 생겼습니다. 하지만 실제로 운영해보니 새로운 과제가 눈에 띄었습니다.

• 리포트로 공유하고 대응을 태스크화한 후, 그 추적(Tracking)이 매우 힘들었습니다. 진행 상황을 알기 위해서는 결국 팀원들에게

이 두 가지 관점을 하나의 메커니즘 안에서 양립시키는 것을 이번 목표로 삼았습니다.

📐 설계 사상: 4가지 방침

메커니즘을 만들기 전에, 팀에서 합의한 4가지 방침이 있습니다.

1. 진척도는 "묻는 것"이 아니라 "보이는 것"으로 만든다

페이즈 2의 가장 큰 과제는 태스크화한 이후의 진척도가 대화 속에만 존재했다는 점이었습니다. 그래서 대응 상황은 issue와 대시보드의 "상태(State)"로 표현하기로 했습니다. 대시보드를 보면 누구에게 묻지 않아도 전체 진척도를 알 수 있습니다. SRE가 "그건 어떻게 되었나요?"라고 물으러 다니는 시간도, 개발자가 질문을 받고 대답하는 시간도 모두 없앱니다. 진척 관리에서 동기식 커뮤니케이션(Synchronous Communication)을 없애는 것이 이 메커니즘의 출발점입니다.

2. 취약점 대응을 "특별한 이벤트"로 만들지 않는다

취약점 대응만을 위한 회의체나 전용 관리 도구를 늘리지 않았습니다. 새로운 도구를 늘릴수록 "그곳을 확인하러 가야 한다"는 행동 비용이 대응의 장벽이 되기 때문입니다.

개발자에게 있어 대응의 입구는 평소 업무에서 매일 보고 있는 GitHub의 issue입니다. 이렇게 하면 스프린트의 백로그(Backlog)에 취약점 대응을 올리는 것도 일반적인 태스크와 완전히 동일한 동작으로 수행할 수 있습니다.

3. 노이즈를 전달하지 않는다. 전달되는 것은 "대응해야 할 것"뿐이어야 한다

취약점 스캔을 모든 리포지토리에 돌리면 검출 건수는 간단히 수백 건 규모가 됩니다. 이것을 전부 issue로 만들면 개발자는 확실히 알림을 무시하게 됩니다. "전부 전달하는 것"은 "아무것도 전달되지 않는 것"과 같습니다.

따라서 issue로 생성하는 것은 중요도가 높고(Critical / High), 실제 악용될 가능성이 있는 것으로 압축했습니다. EPSS 등의 지표를 사용한 구체적인 필터링 방법은 후술하겠습니다.

4. SRE는 게이트(Gate)가 아니라 이네이블러(Enabler)가 된다

SRE가 취약점을 트리아지(Triage)하여 각 팀에 "의뢰"하는 형태가 되면, SRE가 병목(Gate)이 됩니다. 그렇게 하는 대신, SRE의 역할은 다음과 같이 압축했습니다.

• 전체를 가시화하여, 대응 우선순위와 진척도를 조직으로서 판단할 수 있는 상태를 만드는 것
• 개발자가 망설임 없이 대응할 수 있도록, issue에 필요한 정보를 갖추어 전달하는 것

대응의 주체는 어디까지나 각 프로덕트의 개발 팀입니다. SRE는 "메커니즘과 정보"를 제공하는 측에 서는 것입니다. 이는 취약점 관리에 국한되지 않고, 저희가 SRE Enabling에서 일관되게 취하고 있는 스탠스입니다.

🛠️ 전체상: SBOM을 기점으로 출구를 두 개로 나눈다

전체상은 다음과 같습니다. 왼쪽 그룹(SBOM 생성 ~ 취약점 검출)은 팀이 정비해 두었던 기존 기반이며, 오른쪽이 이번에 연결한 부분입니다.

이번에 수행한 작업은 이 검출 결과를 SRE와 개발자 각각에게 전달되는 두 개의 출구로 연결하는 것이었습니다. 포인트는 정보의 흐름은 하나지만, 출구가 두 개라는 점입니다.

• 개발자용 출구: 대응할 리포지토리로의 issue 생성
• SRE용 출구: GitHub Projects 대시보드로의 집약

동일한 취약점 정보가 각자의 입장에 최적화된 형태로 전달됩니다.

취약점 검출 기반: SBOM으로 "조직의 취약점 정보"를 한곳에 보유

이번 메커니즘의 토대가 되고 있는 것은 사내에 이미 존재하던 취약점 검출 기반입니다. 사내 리포지토리의 SBOM (Software Bill of Materials)과 취약점·EOL 정보를 일원 관리하기 위한 장소로, 다음과 같은 구조를 가지고 있습니다.

repos/
└── [repo-name]/
├── properties.json # 메타데이터 (Owner, Product, 스캔 대상 플래그)
...

툴체인(Toolchain)은 aqua로 통합 관리하며, SBOM 생성에는 syft, 취약점 스캔에는 grype, EOL 검출에는 xeol을 사용하고 있습니다. 취약점 검출 기반에서는 SBOM을 정기적으로 재생성하여 집약하고 있기 때문에, 스캔은 항상 최신에 가까운 SBOM을 대상으로 실행됩니다.

이 기반에서 효과적이라고 느끼는 점은 리포지토리 레벨과 컨테이너 레벨의 SBOM을 나누어 보유하고 있다는 점입니다.

• 리포지토리 SBOM: 개발 시 도구를 포함한 의존성 전체량
• 컨테이너 SBOM: 프로덕션 이미지에 포함된 것 (시스템 라이브러리 포함)

분석 시에는 컨테이너 SBOM을 우선합니다. 리포지토리에는 포함되지만 컨테이너에는 포함되지 않는 컴포넌트는 '개발 환경 전용'이라고 판단할 수 있어, "devDependencies의 취약성 때문에 운영 환경 대응 공수를 사용하는" 낭비를 피할 수 있기 때문입니다. 탐지 결과를 개발자에게 전달하는 측면에서도, 이러한 필터링 덕분에 '전달해야 할 것'이 상당히 압축된 상태에서 시작할 수 있습니다.

또한, properties.json의 enable-vuln-fix 플래그를 통해 리포지토리 단위로 이 메커니즘의 On/Off를 제어할 수 있습니다. 이를 통해 모든 리포지토리에 일제히 적용하는 것이 아니라, 팀의 준비가 된 곳부터 단계적으로 확대해 나갈 수 있습니다.

스캔은 GitHub Actions로, 프로덕트/오너 단위로 실행 가능

스캔과 이슈 생성(Issue creation) 워크플로우는 GitHub Actions (workflow_dispatch)로 실행합니다. 이때 리포지토리 이름을 직접 지정하는 것뿐만 아니라, 프로덕트 단위·오너 단위로 실행할 수 있습니다.

# 프로덕트 단위로 스캔
gh workflow run vuln-scan.yaml \
-f custom_property_name=product \
...

조직의 대화 단위는 '리포지토리'가 아니라 '프로덕트'나 '팀'입니다. "이 프로덕트, 지금 상황이 어때?"라는 질문에, 그 단위 그대로 메커니즘이 답할 수 있도록 구성했습니다.

🔍 트리아지(Triage): 4가지 관점을 가이드로 언어화하기

탐지된 취약점을 어떻게 우선순위화할 것인가. 이 부분이 이 메커니즘의 핵심입니다.

취약점 탐지 기반에는 우선순위화를 정한 **트리아지 가이드 (Triage Guide)**가 있습니다. 판단은 다음 4가지 관점에서 수행합니다.

포인트는 Severity만으로 판단하지 않는 것입니다. CVSS가 Critical이라도 개발 환경 전용 컴포넌트라면 리스크를 수용(Risk Acceptance)할 수 있습니다. 반대로 High라도 인터넷에 노출되어 있고 EPSS가 높다면 즉시 대응해야 합니다. "대응 비용 < 피해 비용 × 악용 가능성"이라면 대응한다는 사고방식이 가이드에 명문화되어 있습니다.

이 사고방식은 이슈 생성 기준에도 그대로 반영되어 있습니다.

• 중대도가 높고 (Critical / High), 동시에 EPSS 등의 지표를 통해 악용될 현실성이 있는 것

즉, 중대도와 악용 가능성 양면(AND)에서 필터링하여, 악용될 현실성이 없는 취약성은 Critical이라 하더라도 이슈로 만들지 않습니다 (대시보드 측의 판단 자료로는 남겨둡니다). 구체적인 임계값은 운영하면서 튜닝한다는 전제하에 본 글에서는 다루지 않겠지만, 이러한 필터링이 있기에 개발자에게 전달된 이슈는 '그냥 온 알림'이 아니라 '대응할 가치가 있다고 판단된 것'이 됩니다.

이슈 생성 시에는 이 트리아지 가이드를 활용했습니다. 가이드는 사람이 읽는 운영 문서인 동시에, Claude Code가 읽고 실행하는 지시서로서도 기능합니다. CVE Program이나 NVD, GitHub Advisories의 URL 패턴까지 가이드에 적혀 있기 때문에, Claude Code는 기반 시스템의 트리아지 결과에 대해 웹에서 정보를 보완하며 조사·정리·이슈 생성까지 실행할 수 있습니다. 이 '가이드를 그대로 Claude Code의 절차서로 사용하는' 연결 방식이 이슈 생성을 자동화하는 데 있어 핵심이었습니다.

여기서 경계선으로서 의식한 점은, Claude Code에게 맡기는 것은 '수집·조사·정리·이슈 생성'까지이며, '대응할 것인가/리스크를 수용할 것인가'의 최종 판단은 인간이 갖는다는 것입니다. 트리아지 기준을 충족하는지에 대한 1차 판정은 기계적으로 돌릴 수 있지만, "이 프로덕트에서 이 취약점을 어떻게 다룰 것인가"는 프로덕트의 맥락을 가진 인간이 결정해야 할 영역입니다. AI에게 넘기는 범위를 판단 직전 단계에서 멈추는 것이, 이 메커니즘을 안심하고 운영할 수 있는 전제가 됩니다.

운영해 보니 효과를 보고 있는 점은, 이 기준이 guide라는 하나의 파일로 집약되어 있다는 것입니다. "티켓 생성 시 이 정보도 포함해 주었으면 좋겠다", "이 조건은 스킵하고 싶다"와 같은 개선 요구사항이 가이드(guide)에 대한 PR(Pull Request)로서 제안 및 리뷰되고, 그대로 다음 동작에 반영됩니다. 운영 규칙의 변경이 대화나 부탁 기반이 아니라, 리뷰 가능한 변경 사항으로서 이력에 남는다는 점은 AI에게 업무를 맡기는 설계만의 특징이라고 느끼고 있습니다.

📊 SRE 관점: 대시보드로 "전사의 취약점 현황"을 파악하기

SRE 측의 결과물은 GitHub Projects에 만든 취약점 관리 대시보드입니다.

GitHub Projects에서 모든 프로덕트의 취약점을 목록으로 관리. 대응 상태(Status)로 그룹화하고, Product 슬라이스로 필터링 가능

뷰(View)는 대응 상태로 그룹화하고, 사이드바의 Product 슬라이스를 통해 프로덕트 단위로 필터링할 수 있도록 구성했습니다. "미대응 그룹에 몇 건이 남아 있는가", "이 프로덕트는 어떤가"를 한눈에 알 수 있는 구조입니다. Severity(심각도) 정렬을 조합하면, "미대응 Critical부터 순차적으로 해결한다"라는 SRE의 트리아지(Triage) 동선이 이 화면 하나로 완결됩니다.

각 issue에는 Project의 커스텀 필드(Custom Field)로서 다음 정보가 연결됩니다.

은근히 효과를 보고 있는 것이 "대응 방침"과 "Fixed In" 필드입니다.

취약점 대응은 "업데이트한다"만이 정답이 아니라, WAF로 방어하거나 리스크를 수용(Risk Acceptance)한다는 판단이 있을 수 있습니다. 그 판단 결과를 구조화하여 남김으로써, "왜 이것은 대응하지 않는가"를 나중에 감사(Audit)할 수 있게 됩니다. 리스크 수용은 "무시"가 아니라 "문서화된 의사결정"이라는 것이 트리아지 가이드의 사고방식입니다.

Fixed In에는 won't fix나 1.2.0 (일부 won't fix)와 같은 값도 들어갑니다. 즉, 업데이트로는 해결할 수 없는 취약성이 목록 중에서 솔직하게 보입니다. won't fix된 컴포넌트는 "버전만 올리면 끝"이 아니라, 대체 컴포넌트로의 이관이나 리스크 수용과 같은 무거운 판단이 필요하므로, 그것이 다른 항목과 섞이지 않고 식별될 수 있다는 점이 우선순위 논의의 질을 높여줍니다.

이를 통해 SRE는 다음과 같은 상태가 되었습니다.

• 미대응 Critical / High가 몇 건, 어느 프로덕트에 남아 있는지를 한눈에 파악할 수 있음 - 진행 상황 확인을 위해 각 팀에 상황을 문의하는 번거로움이 사라짐
• 대응이 지연되고 있는 프로덕트나 팀을 조기에 감지하여 팔로업(Follow-up)할 수 있음
• 보안 감사나 경영진 보고도 이 뷰를 그대로 사용할 수 있음

"전사의 취약점, 지금 상황이 어떠한가?"라는 질문에, 리포지토리를 순회하거나 누구에게 묻지 않고도 즉시 답변할 수 있게 된 것이 큰 변화입니다.

🧑💻 개발자 관점: 취약점은 "평소와 같은 issue"로 전달된다

반면, 개발자 측에는 대응해야 할 취약점이 자신의 리포지토리의 issue로 전달됩니다.

Notion 리포트 시절에는 미팅에서 리포트를 열지 않으면 취약점 정보를 접할 기회가 없었습니다. issue로서 자신의 리포지토리에 생성되는 지금의 방식에서는, 평소의 issue 트리아지나 스프린트 플래닝(Sprint Planning) 과정에서 다른 태스크와 동일한 선상에서 자연스럽게 확인할 수 있습니다. 취약점 대응만을 위해 따로 보러 가야 할 장소가 없다는 점이 개발자에게 있어 가장 큰 변화입니다.

Claude Code가 생성한 취약점 대응 issue 예시

issue의 입도는 "컴포넌트 × 리포지토리"

티켓 생성의 입도는 "컴포넌트 × 리포지토리"의 조합을 1개의 issue로 설정했습니다. 타이틀은 [High] hogehoge-pkg (product-1-front)와 같은 형식입니다.

CVE 단위로 티켓을 생성하면, 동일한 컴포넌트의 업데이트 1회로 해결되는 여러 개의 CVE가 별개의 issue로 나뉘어 개발자의 태스크 관리 입도와 맞지 않게 됩니다. 개발자의 액션 단위는 "이 컴포넌트를 올린다"이므로, issue의 입도도 액션 단위에 맞춥니다. 동일 컴포넌트에 여러 개의 CVE가 있는 경우에는 1개의 issue 안에 취약점 목록으로 나열합니다. 실제로 1개의 컴포넌트에 수십 개의 CVE가 딸려 있는 경우도 있는데, 그럴 때일수록 이 설계의 효과가 커집니다.

issue 본문은 「조사 완료」 상태로 전달됩니다

issue 본문에는 개발자가 그 자리에서 대응 여부를 판단할 수 있는 정보를 갖추고 있습니다. 실제 issue([High] hogehoge-pkg (product-1-front))의 이미지는 다음과 같은 형태입니다.

## 대응 권장
- **권장 대응 기한**: 1주일 이내 (P2)
- **검출원**: product-1-front
...

여기서 의식한 점은, 「조사하는 작업」을 issue 안에서 완결시켜 두는 것입니다.

취약점 대응이 뒤로 밀리는 이유의 상당수는 대응 그 자체가 무거워서가 아니라, "이게 뭐지? 영향이 있나? 어떤 버전으로 올려야 하지?"와 같은 조사의 초동 비용 (Initial Cost)이 높기 때문이라고 생각합니다. 그 초동 부분을 Claude Code가 대신 수행하여 issue에 적어둠으로써, 개발자는 바로 "판단과 실행" 단계로 들어갈 수 있습니다. 이것이 이 메커니즘에서 Enabling의 본질이라고 생각합니다.

다만, issue 내용은 AI가 생성한 것이므로, 무조건 믿는 것을 전제로 만들지는 않았습니다. 권장 버전이나 영향 범위는 어디까지나 "조사의 초안 (Draft)"이며, 최종적인 업데이트 여부나 호환성은 대응하는 개발자가 판단합니다. 오검출 (실제로는 영향이 없는 검출)인 경우에는 대시보드의 대응 상태를 "대응 불필요"로 변경하고, 대응 방침에 이유를 남깁니다. AI가 초안을 준비하고 사람이 확정하는 역할 분담을 issue 레벨에서도 철저히 하고 있습니다.

대응이 끝나면, issue를 닫습니다

대응 클로즈 (Close) 플로우는 심플합니다. 개발자가 컴포넌트를 업데이트하고 issue를 클로즈하면 해당 리포지토리에서의 대응은 완료됩니다. 다음 스캔에서 동일한 취약점이 검출되지 않는다면, 해당 issue가 다시 오픈되는 일도 없습니다. 대시보드상의 대응 상태는 트리아지 (Triage) 담당자가 업데이트하지만, "실제로 고쳐졌는가"에 대한 최종적인 답은 다음 스캔의 검출 결과가 쥐고 있는 설계입니다. 상태를 수동으로 "대응 완료"로 변경하더라도, 스캔에서 재검출되면 미대응 상태로 돌아옵니다. 사람의 신고가 아닌 스캔 결과를 정답으로 삼음으로써, 자산 조사 (Inventory)의 정밀도를 유지하고 있습니다.

재검출·재발도 issue의 라이프사이클로 표현합니다

정기 스캔에서 동일한 취약점이 재검출되었을 때의 처리 방식도 설계되어 있습니다.

• OPEN 상태인 issue가 이미 있는 경우 $\rightarrow$ 중복 issue를 만들지 않고, 재검출 코멘트를 추가하여 대시보드의 Scan Date만 업데이트
• CLOSED 된 issue만 있는 경우 $\rightarrow$ "한 번 고쳤는데 재발한" 케이스이므로, 신규 issue로서 별도 관리

"고쳤을 터인 취약점이 돌아왔다"는 것은 의존성 (Dependency) 롤백 등 다른 문제의 신호이므로, 과거의 issue를 다시 오픈하는 것이 아니라 새로운 현상으로 취급하도록 했습니다.

💭 운영해 보니: 가시화는 「대응되는 상태」로 가기 위한 첫걸음

운영을 시작하며 느끼는 점은, "보이는 것"과 "대응되는 것" 사이에는 거리가 있지만, "보이지 않는 것"은 절대 대응되지 않는다는 것입니다.

대시보드와 issue를 정비했다고 해서 모든 것이 해결되는 것은 아닙니다. 기한이 지난 issue에 대한 팔로업(Follow-up)이나, 기표 기준의 튜닝 등 운영으로 계속 돌려야 하는 부분은 남아 있습니다.

다만, 이전처럼 "어디에 무엇이 있는지 모른다", "진척 상황은 물어봐야만 알 수 있다"는 상태와 비교하면 논의의 출발선이 완전히 다릅니다. "대응할 것인가, 리스크를 수용(Risk Acceptance)할 것인가"를 조직으로서 판단할 수 있는 재료가 항상 갖춰져 있습니다. 이것이 취약점 관리 메커니즘으로서 우선 도달해야 할 상태라고 생각합니다.

정량적인 효과 (대응 리드 타임 단축이나 미대응 Critical 취약점의 추이)는 도입한 지 얼마 되지 않아 아직 논할 단계는 아닙니다. 이 부분은 지속적으로 측정하여 조만간 수치로 되돌아보고 싶습니다.

Enabling MTG의 역할도 변했습니다. 이전에는 리포트를 함께 읽으며 대응을 "의뢰하는 자리"였지만, 일상적인 대응이 비동기(Asynchronous)로 진행되게 된 지금은 판단이 갈리는 케이스나 우선순위 상담 등, 동기(Synchronous)로만 해결할 수 있는 논의에 시간을 쓸 수 있는 자리가 되었습니다. 동기적인 자리는 없애는 것이 아니라, 본래 해야 할 일에 사용하는 것. 이것 또한 비동기화의 효과라고 생각합니다.

✍️ 요약

"사람이 우연히 발견하는 것"에서 "리포트와 MTG를 통한 동기 공유"로, 그리고 이번에는 "대시보드와 issue를 통해 비동기로 추적할 수 있는" 상태로. 검출하는 기반은 이미 있었기에, 이번에 한 일은 그 한 발 앞선 단계 —— 검출된 것을 실제로 대응되는 상태까지 운반하는 것 —— 이었습니다. 되돌아보면 포인트는 다음 4가지입니다.

• 검출에서 멈춰있던 것을 SRE와 개발자 각각의 출구로 연결했다

입장에 따라 보고 싶은 것이 다르기 때문에, 출구는 분리한다. SRE에게는 "대시보드(Dashboard)", 개발자에게는 "이슈(Issue)"를 제공한다. -
진척도를 "대화"에서 "상태"로 옮겨, 취약점 대응을 비동기화했다

대응해야 할 리포지토리(Repository)에 이슈(Issue)로 기재함으로써, 묻지 않아도, 혹은 묻지 않아도 진척 상황을 알 수 있게 했다. -
"전부 전달하기"를 그만두고, 중요도가 높고 악용될 현실성이 있는 것만 이슈화했다

노이즈를 줄이는 것이 알림이 계속 기능하기 위한 전제 조건이다. 이슈(Issue)의 입도(Granularity) 또한 "개발자의 액션 단위(컴포넌트 × 리포지토리)"에 맞춘다. -
수집·조사·기재는 Claude Code에 맡기고, "대응할지 여부"의 판단은 인간이 담당하도록 선을 그었다

기존 가이드(기준)에 따라 Claude Code가 이슈를 기재하며, SRE는 순회나 전기가 아닌 판단과 팔로업(Follow-up)에 시간을 쓸 수 있다.

SRE가 전부 하는 것도, 개발 팀에 통째로 떠넘기는 것도 아닌, "대응하기 쉬운 상태"를 시스템으로 만들어 조직 전체의 대응력을 높인다. 이것이 우리가 생각하는 SRE Enabling이며, 취약점 관리는 그 좋은 사례가 되었다고 생각합니다.

이 시스템도 아직 진화하는 과정에 있습니다. EOL(End of Life) 관리 측면의 노력이나, 수정 대응 자체의 자동화 등, 뒷이야기는 다시 기사로 이어가겠습니다.

Discussion