CURVC DevOps Confluence

출처: How we catch and mitigate performance regressions at scale in Jira Cloud https://www.atlassian.com/blog/how-we-build/catching-and-mitigating-performance-regressions-at-scale-in-jira-cloud 작성자: James Parkyn (Software Engineer) Jira Cloud처럼 규모가 크고 멀티 테넌트(Multi-tenant) 구조를 가진 제품에서는, 시스템 어디에서든 발생한 “작은” 변경이 전체 지표에 이상으로 나타나기 전에 일부 주요 고객에게 먼저 불편을 줄 수 있습니다. / 고객의 사용 경험을 조용히 악화시킬 수 있습니다. → 선택 Feature flag(기능 플래그), 점진적 롤아웃, 테넌트별 데이터와 트래픽 형태로 인해 이러한 성능 저하는 Jira의 일부 영역에만 영향을 미치는 경우가 많습니다. (예: 3개 테넌트에서 관리자 사용자에게만 영향을 주는 특정 엔드포인트에서 발생하는 성능 저하) / (예: 3개 테넌트에서 관리자 사용자에게만 해당되는 특정 엔드포인트) → 선택 (“성능저하”라는 말은 원문에 없음) 이처럼 영향 범위가 매우 제한적이기 때문에 문제를 발견하기도 어렵고, 원인을 파악하는 것은 더 까다롭습니다. 이번 글에서는 Jira에서 테넌트별·엔드포인트별로 성능 저하를 감지하는 시스템을 어떻게 구축했는지, 그리고 이를 Rovo Dev CLI https://support.atlassian.com/rovo/docs/use-rovo-dev-cli/와 연동해 단순히 특정 부분이 느려졌다는 것뿐 아니라 왜 느려졌는지까지 빠르게 파악할 수 있는 방법을 살펴봅니다. 최근 몇 달 사이에만 이 시스템은 8건 이상의 서로 다른 운영 환경에서 발생한 성능 저하 문제("문제" 뺄지말지) 를 탐지하고 대응하는 데 도움을 주었으며, 성능이 더 나빠지는 것을 막는 동시에 개선을 이어가고 있습니다. / 성능 개선을 위한 투자를 이어가는 과정에서도 추가적인 성능 악화를 방지하는 데 기여하고 있습니다. → 선택 Regression(성능 회귀)이란? 먼저 정의를 살펴보겠습니다: / 먼저 개념을 정리해보겠습니다: → 선택 성능 회귀는 성능(예: 엔드포인트 지연 시간)이 기존 기준선보다 성능이 저하되는 경우를 의미합니다. 기준선은 성능 회귀가 발생하기 전에 측정된 "문제가 발생하기 전 성능"을 의미합니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260112-032732-720x286.png 테넌트에 따라 크게 달라지는 Jira 성능 Jira Cloud는 수백만 개의 테넌트를 지원하며, 각 테넌트는 매우 다양한 특성을 가질 수 있습니다: / Jira Cloud는 수백만 개의 테넌트를 지원하며, 각 테넌트는 서로 큰 차이를 보입니다: / Jira Cloud는 수백만 개의 테넌트를 지원하며, 각 테넌트는 다양한 형태를 보입니다: → (선택) 데이터 특성(이슈 수, 필드 설정, 변경 이력 등) 트래픽 패턴(변동이 큰 트래픽 vs 안정적인 트래픽, 글로벌 팀 vs 로컬 팀) 애드온 및 구성 네트워크 환경 및 클라이언트 하드웨어 이러한 차이들로 인해 성능은 테넌트별뿐만 아니라 프로젝트별로도 크게 달라집니다. 대부분의 테넌트(99.99%)에서는 문제가 되지 않는 변경이라도, 규모나 사용 패턴이 극단적인 일부 테넌트(0.01%)에는 크게 영향을 줄 수 있습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260115-062440-720x291.png 상위 1만 개 고객에서 백엔드 엔드포인트 하나의 지연 시간 변동 끊임없는 변경 Jira에서는 매일 많은 변경이 발생합니다: 수십에서 수백 건의 PR이 머지됩니다. Feature flag 변경이 수천 건 이루어집니다. 인프라와 의존성도 지속적으로 변화합니다. 고객은 사용량을 늘리거나 줄이고, 자동화를 추가하며, 서드파티 도구를 설치합니다. 이러한 변경 하나하나는 성능을 악화시킬 수 있는 작은 위험을 가지고 있으며, 그중 일부는 소수의 테넌트에만 영향을 미칩니다: 예를 들어, 일부 대규모 엔터프라이즈 고객이나 특정 구성과 데이터 조합을 가진 테넌트가 여기에 해당합니다. 이러한 상황이 발생할 때마다, 문제가 누적되지 않도록 반드시 이를 감지하고 성능 회귀를 해결해야 합니다. “글로벌” 모니터링만으로는 충분하지 않은 이유 대부분의 성능 모니터링 시스템은 집계 지표를 기반으로 구성됩니다: 환경, 샤드(shard) 또는 대규모 고객 집단(XL customer cohort) 단위의 SLO 수백 개 테넌트에서 한 번에 계산된 퍼센타일(예: p90) 환경 또는 고객 집단 단위로 집계된 프론트엔드 지표(예: 페이지 로딩 성능을 나타내는 TTVC, time to visually complete) 이러한 지표들은 전체적인 상태를 파악하는 데는 유용하지만, 중요한 문제가 드러나지 않고 묻힐 수 있습니다: 많은 성능 회귀는 소수의 매우 큰 테넌트에만 영향을 미치기 때문에, 고객 집단 단위로 집계된 지표에서는 완전히 드러나지 않는 경우가 많습니다. 고정 임계값만으로는 충분하지 않은 이유 그렇다면 왜 각 테넌트마다 SLO를 설정하고 이를 초과하는 경우를 감지하기보다, “성능 회귀(regression)”를 찾아야 할까요? 테넌트 간 편차가 크다는 점을 고려하면, 이렇게 접근했을 때 어떤 일이 발생하는지 아래 예시를 통해 다음과 같은 상황이 발생합니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260112-032824-720x310.png 두 가지 큰 문제: → 볼드 처리 할지 말지 (선택) 임계값보다 성능이 지속적으로(또는 항상) 낮은 테넌트는 계속해서 알림이 발생합니다. 성능이 “매우 좋은 상태”(임계값보다 훨씬 낮은 수준)에서 “좋은 상태”(임계값보다 약간 낮은 수준)로 떨어진 테넌트는 알림이 전혀 발생하지 않습니다. 임계값을 매우 높게 설정하거나(성능이 가장 낮은 테넌트보다 높게), 또는 매우 낮게 설정하면(가장 빠른 테넌트보다 높게), 이 문제들 중 하나는 해결할 수 있지만, 고정 임계값만으로는 두 가지를 동시에 해결할 수는 없습니다. 설정한 기준 따라서 이번 프로젝트의 목표는 다음과 같습니다: 전체 지표에는 문제가 없어 보이더라도, 특정 백엔드 엔드포인트에서 개별 테넌트나 소규모 테넌트 그룹의 성능 저하를 감지하는 것 이를 위해 다음 세 가지가 필요합니다: 대규모 환경에서 수집되는 테넌트별·엔드포인트별 지표 각 테넌트의 과거 데이터와 비교하는 감지 파이프라인 “무언가 느려졌다”는 사실을 바탕으로 “유력한 원인”을 빠르게 파악하는 방법 탐지부터 대응까지: 하나의 성능 회귀 사례 전 과정 구체적인 사례를 통해, 실제 운영 환경에서 발생한 성능 회귀를 살펴보겠습니다: 집계된 지표로는 감지되지 않았던 백엔드 성능 저하를 탐지 담당 팀에 알림 전달 문제의 원인이 된 feature flag를 정확히 식별하는 자동화된 원인 분석(RCA) 고객 불만이 제기되기 전에 대응이 이루어지도록 지원 2025년 10월 말경, Jira 백엔드의 한 feature flag가 운영 환경 전반에 걸쳐 점진적으로 적용되기 시작했습니다. 일부 테넌트에서는 이 영향으로 이슈 뷰와 보드에서 사용되는 두 개의 백엔드 동작에서 지연 시간이 크게 증가했습니다. 반면, 나머지 테넌트에는 거의 영향을 주지 않았기 때문에, 다른 많은 성능 회귀와 마찬가지로 집계된 지표에서는 거의 드러나지 않았습니다. 이 문제는 상위 20개 테넌트에서 감지되었고, 해당 백엔드 엔드포인트를 담당하는 내부 팀에 JSM(Jira Service Management) 알림이 전달되었습니다. 각 (테넌트, 엔드포인트) 조합에서 전체 트래픽의 10% 이상을 차지하는 이상 사용자(outlier users)를 식별 → 이 단계는 알림 품질을 높이는 데 매우 중요하며, 이를 제외하지 않으면 단일 소스에서 발생한 일시적인 트래픽 급증으로 인해(다른 사용자들의 지연 시간에는 영향을 주지 않더라도) 성능 저하 신호가 다수 발생할 수 있음 각 (테넌트, 엔드포인트) 조합에서 이상 사용자(outlier)를 제외한 뒤, 메트릭 데이터 레이크를 기반으로 일별 p90 지연 시간을 계산 동일한 엔드포인트에서의 각 테넌트 과거 데이터를 기반으로 구성된 기준선(중앙값 및 표준편차)과 현재 p90을 비교해, 성능 저하가 발생한 (테넌트, 엔드포인트) 조합을 식별 유사한 성능 저하를 테넌트 및/또는 엔드포인트 기준으로 그룹화하고, JSM(Jira Service Management) Operations에 알림을 전달 Rovo Dev CLI를 활용한 자동화된 원인 분석(RCA) 알림을 통해 문제를 인지할 수 있지만, 여전히 해결해야 할 큰 문제가 하나 있습니다: 성능 회귀의 원인을 진단하고 규명하는 일은 생각보다 훨씬 어렵습니다. 하나의 성능 회귀를 조사하는 데 며칠이 걸리기도 하며, 데이터 부족이나 도메인 지식의 한계로 인해 많은 경우 끝내 원인을 찾지 못하기도 합니다. 이러한 어려움은 Jira의 규모와 매일 이루어지는 수많은 변경에서 비롯됩니다. Jira는 여러 복잡한 레포지토리와 서비스 전반에 걸쳐 수천 명의 엔지니어가 개발에 참여하고 있습니다. 매일 수십에서 수백 건의 PR과 수천 건의 커밋, 그리고 수천 건의 feature flag 변경이 운영 환경에 반영됩니다. 또한 수백만 개에 달하는 Jira 테넌트는 각각 고유한 데이터 특성, 트래픽 패턴, 성능 특성을 가지며 이 역시 지속적으로 변화합니다. 여기에 더해 성능 데이터 자체에 노이즈가 많아 문제를 더 복잡하게 만듭니다. 이로 인해 성능 회귀가 정확히 언제 시작됐는지 특정하기 어렵고, 이 시점은 테넌트마다 다를 수 있습니다. 이러한 요인들이 겹치면서 성능 회귀의 근본 원인을 추적하기는 매우 어려운 작업입니다. 이를 AI로 해결할 수 있는 방법을 실험했습니다. 알림이 생성되면 시스템은 Rovo Dev CLI https://support.atlassian.com/rovo/docs/use-rovo-dev-cli/ 기반의 근본 원인 분석 에이전트를 실행합니다. 이 에이전트는 다음과 같은 작업을 수행합니다: 다단계 계획에 따라 동작하며, 각 성능 회귀 이후 새로운 도메인 지식과 조사 패턴을 반영해 계획을 지속적으로 조정합니다. 이를 통해 기존 수동 조사 과정에서 축적된 상세한 맥락과 구체적인 패턴을 활용합니다. 데이터 레이크에 저장된 high-cardinality 운영 환경 메트릭을 대상으로 SQL 쿼리를 작성합니다. Jira를 구동하는 소스 코드와 최근 Git 이력에 대해 읽기 전용 접근 권한을 가집니다. 동작 방식을 자세히 살펴보기 전에, 해당 성능 회귀에 대해 에이전트가 생성한 원인 분석 요약은 다음과 같습니다: Feature flag replace-metrics-check-ff는 2025-10-30 23:42 UTC에 배포되었습니다. 이 변경으로 인해 모든 데이터베이스 쿼리의 핵심 경로에서 Tenant Context Service(TCS)에 대한 호출이 추가되었습니다. 이 호출은 동기식으로 수행되며 캐싱이 적용되지 않습니다. 해당 코드 변경(커밋 07d429ba99)은 feature flag 체크를 EditionService.getProductEdition() 호출로 대체했습니다. 이 과정에서 TcsHttpClient.get()을 통해 TCS API에 대한 블로킹 호출이 발생합니다. 이로 인해 TCS 클라이언트 실행 시간이 1016% 증가했으며(프로파일러 기준 1.37시간 → 15.30시간), 이는 관측된 지연 시간 증가와 직접적으로 연관됩니다. 또한 이 호출은 모든 데이터베이스 연결과 쿼리마다 수행되며, 그 영향이 요청 전체 라이프사이클 전반으로 증폭됩니다. 해당 성능 회귀에 대해 에이전트가 어떤 경로로 분석을 진행했는지 살펴보겠습니다: / 에이전트가 이 성능 회귀를 분석하면서 어떤 과정을 거쳤는지 살펴보겠습니다: → 선택 1. 영향 범위 요약 및 타임라인 수집 에이전트는 알림에 포함된 모든 테넌트의 지연 시간 데이터를 확인하고, 이를 바탕으로 영향이 시작된 시점을 파악하기 위해 타임라인을 구성합니다. 이 정보는 이후 다른 신호와의 상관관계를 분석하는 데 활용됩니다. 2. 샘플링 프로파일러 데이터 분석 Jira에는 백엔드에서 시간이 어디에 소비되는지(클래스, 메서드, 테넌트, 엔드포인트 등 기준) 측정하고, 그 데이터를 데이터 레이크로 전송하는 자체 샘플링 프로파일러가 있습니다. 다른 데이터와 마찬가지로, 에이전트는 데이터 레이크에 저장된 데이터를 SQL로 조회할 수 있습니다. 이를 통해 성능 회귀 전후의 프로파일을 비교하고, 실행 시간이 증가한 특정 메서드로 범위를 좁혀갈 수 있습니다. 이번 사례에서는 프로파일러 데이터를 통해 특정 메서드(TcsHttpClient.get())가 영향을 받은 테넌트에서 하루 기준 1.37시간에서 15.3시간으로 증가했으며, 성능 회귀가 발생한 시점과 동일한 시각부터 시작된 것으로 확인되었습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260118-234518-720x306.png 조사 대시보드 중 하나에서 가져온 차트로, 특정 테넌트에서 발생한 성능 회귀와 상관관계를 보여주며 TcsHttpClient.get()에서 소요 시간이 시간 단위로 증가하는 양상(하단의 빨간색/마룬 영역)을 나타냅니다. 3. Feature flags 다음으로 에이전트는 feature flag 평가 데이터를 살펴봅니다: 데이터 레이크에는 요청 단위의 flag 평가 결과가 성능 메트릭과 함께 기록됩니다. 이를 통해 특정 테넌트와 백엔드 엔드포인트에서 flag 변경 시점을 정확히 파악할 수 있습니다. (프로덕션 환경에서는 flag가 점진적이고 무작위로 롤아웃되기 때문입니다) 에이전트는 성능 회귀와 강한 상관관계를 보이는 flag 변경을 찾기 위해 SQL 쿼리를 작성하고, 여러 영향을 받은 테넌트의 시점을 교차 검증합니다. 세 개의 후보 flag가 도출되었으며, 그중 replace-metrics-check-ff가 여러 영향을 받은 테넌트에서 시간 단위까지 강한 상관관계를 보이며 가장 두드러졌습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260118-233932-768x485.png 조사 대시보드 중 하나에서 가져온 차트로, 영향을 받은 테넌트 중 하나에서 해당 flag의 지연 시간 데이터를 보여줍니다. 에이전트는 이 차트를 생성하는 데 사용된 요청 단위의 원시 데이터에 접근할 수 있습니다. 4. 소스 코드 분석 이 단계에서 전통적인 하드코딩 기반 흐름과 비교해 에이전트의 장점이 드러납니다. 이미 의심되는 feature flag를 식별한 상태에서 에이전트는 각 feature flag의 사용처를 검색하며 실제 변경 내용을 분석하기 시작합니다. replace-metrics-check-ff의 경우, 다음과 같은 변경이 이루어졌습니다. // pseudocode of the old path boolean shouldEmitMetrics(String rds) { return queryStatsig(SLO_METRICS_ENABLED, Map.of("rds", rds)); } 다음과 같이 변경되었습니다: // pseudocode of the new path boolean shouldEmitMetrics(String tenantId) { Edition edition = editionService.getProductEdition(tenantId); return edition == ENTERPRISE; } 에이전트는 editionService.getProductEdition(tenantId)의 호출 트리를 분석한 결과, 어느 단계에서도 캐싱 없이 7개의 메서드 호출 체인을 거쳐 프로파일러 데이터에서 확인된 TcsHttpClient.get() 메서드로 직접 연결됨을 확인했습니다. 5. 전체 흐름 정리 에이전트는 근본 원인에 대한 충분히 강한 근거를 확보했으며, 남은 작업은 요약 보고서를 작성해 Confluence에 저장하는 것이었습니다. 엔지니어들은 이를 검토한 뒤, 영향을 받은 고객이 문제를 인지하기 전에 몇 시간 내로 해당 flag를 다시 비활성화했습니다. 조사 계획에는 일반적으로 몇 가지 단계(코드 배포, 데이터베이스 메트릭 등)가 더 포함되지만, 이번 사례에서는 필요하지 않았습니다. What we learnt / 배운 점 → 선택 1. 성능 회귀 감지는 절반에 불과합니다 프로젝트 초기에는 이를 주로 데이터 엔지니어링 문제로 접근했습니다. 이처럼 대규모 데이터를 어떻게 안정적이고 효율적으로 처리할 수 있을지에 초점을 맞췄습니다. 이 부분도 여전히 어려웠지만, 이 프로젝트의 가장 큰 과제는 아니었습니다. 핵심은 알림에서 대응까지 이어지는 과정이었습니다. 이 시스템에서 실질적인 가치를 얻기 위해서는 단순히 알림을 생성하는 것만으로는 충분하지 않습니다. 알림이 적절한 팀에 전달되고, 실제로 조사가 이루어지며, 최종적으로 대응까지 이어지도록 해야 합니다. 이는 엔지니어링 문제이면서 동시에 비즈니스 협업 문제이기도 합니다. 엔지니어링 측면: 성능 회귀의 근본 원인을 빠르게 파악하기 위해서는 적절한 데이터와 도구를 갖추는 것이 중요하며, 이 때문에 자동화된 RCA가 초기 예상보다 훨씬 더 중요해졌습니다. 성능 회귀를 조사하기 어렵다면 팀은 이를 진행하지 않게 되고, 결과적으로 성능 회귀는 해결되지 않습니다. 자동화된 RCA와 함께, feature flag 변경을 찾기 위한 Databricks 대시보드와 같은 다양한 “수동” 도구도 구축했으며, 이 중 많은 도구가 이후 자동화된 RCA 단계로 발전했습니다. 이 전체 과정은 성능 회귀를 발견하고, 조사하고, 도구를 개선하는 반복적인 순환 구조로 이루어졌으며, 조사 과정에 깊이 관여하지 않았다면 적절한 도구를 구축하기 어려웠을 것입니다. 비즈니스 협업 측면: 성능 회귀 알림을 하나의 중앙 팀이 모두 처리하는 방식은 장기적으로 확장하기 어렵기 때문에, 알림을 관련 Jira 팀에 자동으로 할당할 수 있는 방법이 필요했습니다. 이를 위해 모든 Jira 엔드포인트와 소스 파일에 대해 특정 팀에 소유권을 지정한 최근 작업이 큰 도움이 되었으며, 이를 통해 각 알림을 항상 적절한 팀에 할당할 수 있게 되었습니다. 또한 성능 회귀를 방지하는 것과 개발 속도를 지나치게 저해하지 않는 것 사이에서 적절한 균형을 찾는 것도 필요했습니다. 때로는 소규모 성능 회귀가 발생하더라도 중요한 버그를 먼저 수정해 배포하고, 이후에 성능을 개선하는 것이 더 나은 선택일 수 있습니다. 2. 좋은 평가 데이터셋은 복잡한 에이전트를 구축하는 데 매우 중요합니다 근본 원인 분석 에이전트를 처음 개발할 때는 이를 단기적인 실험으로 보고, 일회성 수동 실행과 결과를 확인하는 방식으로 테스트했습니다. 하지만 이 방식이 큰 제약이 된다는 점을 곧 깨달았습니다. 변경이 실제로 개선으로 이어지는지 판단하기 어려웠고, 당시 개발 중이던 특정 시나리오에 맞춰 과적합되기 쉬웠습니다. 이로 인해 에이전트를 보다 일관되게 테스트하기 위한 평가 프레임워크를 구축하게 되었으며, 이는 에이전트 개발 과정에서 가장 중요한 작업이었습니다. 에이전트를 보다 현실적으로 평가하기 위해, 합성 데이터가 아닌 실제 운영 환경에서 발생한 성능 회귀를 기반으로 시나리오를 구성했습니다. 이를 통해 실제 조사에서 중요한 다양한 요소들을 반영할 수 있습니다. 예를 들어 노이즈가 많은 메트릭, 계절성 및 트래픽 변화, 상관관계를 가지는 신호, 그리고 겹치는 코드 변경 등이 있습니다. 에이전트는 메트릭에 대해 임의의 SQL을 실행하고 코드도 자유롭게 분석할 수 있기 때문에, 이 부분에서 타협할 수 없습니다. 평가 시나리오는 알림부터 타임라인, 코드, 배포에 이르기까지 전체 흐름을 모두 다루어야 합니다. 각 시나리오에 기록되는 내용은 다음과 같습니다: 알림 시스템 입력 정보: 성능 회귀 발생 시점, 영향을 받은 엔드포인트, 그리고 테넌트 성능 회귀 발생 며칠 후 시점의 커밋 해시: 에이전트가 안정적인 코드베이스 상태를 기준으로 분석할 수 있도록 합니다. 사람이 검증한 기준 정보: 실제 근본 원인에 대한 간결한 설명과 상세한 평가 노트이며, 에이전트에는 제공되지 않고 오직 평가에만 사용됩니다. 초기에는 생성된 RCA 보고서를 키워드 검색(예: 실제 근본 원인에 해당하는 feature flag 키)으로 평가했습니다. 하지만 이 방식은 곧 한계에 부딪혔습니다. 에이전트가 발견한 모든 신호를 보고서에 나열하는 것만으로도 높은 점수를 받게 되었고, 실제 근본 원인에 대한 이해나 판단은 제대로 평가되지 않았습니다. 이를 해결하기 위해, 각 시나리오에 대해 기록된 실제 근본 원인과 평가 노트를 기준으로 각 실행 결과를 평가하는 LLM-as-a-judge https://arxiv.org/abs/2411.15594 방식을 도입했으며, 그 결과 평가 품질이 크게 향상되었습니다. 생성된 요약 보고서를 바탕으로 평가를 진행하고, 다음 두 가지 기준으로 점수를 부여합니다: 재현율(Recall): 요약이 성능 회귀의 근본 원인과 핵심 신호를 정확히 찾아냈는가? 정확도(Precision): 요약이 잘못되었거나 관련 없는 근본 원인을 포함하지 않았는가? 다음은 평가 하네스(evaluation harness)에서 전체적으로 어떻게 구성하는지입니다: https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/screenshot-2026-02-20-at-1.11.18-pm-720x149.png 다이어그램: 에이전트의 벤치마킹/평가 흐름을 보여줍니다 각 시나리오는 병렬로 실행되며, 일관성을 검증하기 위해 필요에 따라 여러 번 실행되기도 합니다. 실행 전에 해당 시점의 올바른 커밋 기준으로 코드 저장소를 체크아웃합니다. 이후 에이전트를 실행하고, 그 결과를 평가자(judge)로 검증한 뒤, 모든 결과를 하나의 보고서로 통합합니다. 향후 계획 테넌트별 통계 기반 탐지와 AI 기반 원인 분석(RCA) 에이전트를 결합함으로써, 성능 회귀 대응을 즉흥적인 대응(firefighting)에서 반복 가능하고 자동화된 워크플로로 전환했으며, Jira 전반으로 확장 가능한 구조를 만들었습니다. 이 시스템은 이제 전사적 지표로는 포착되지 않는 성능 회귀를 지속적으로 탐지하고, 가장 가능성 높은 근본 원인을 팀에 제시하며, 고객이 문제를 체감하기 전에 대응을 배포할 수 있도록 돕습니다. 다음 단계에서는 이 시스템을 더 넓고 깊게 확장할 예정입니다. 모든 Jira 엔드포인트로 적용 범위를 확대하고, 인프라 신호부터 제품 수준의 컨텍스트까지 더 풍부한 데이터를 RCA에 통합하며, 탐지–조사–대응 간 피드백 루프를 더욱 강화할 것입니다. Jira 팀들이 전반적인 성능 개선을 지속적으로 추진하는 만큼, 이 시스템 역시 이에 발맞춰 성능 회귀를 조기에 탐지하고, 이를 명확하게 설명하며, 팀이 이를 해결할 수 있는 직접적인 경로를 제공하는 것을 목표로 합니다. 이 시스템을 함께 구축해 준 모든 팀원들에게 깊이 감사드립니다. 특히 Elad Shultz, Behrooz Nobakht, Alexander Yurinski, James Choi, Manu Masson, Rahul Mamgain, James Parkyn에게 감사드립니다. → 감사인사라 지우는게 맞겠죠?

2026/04/23

20분 만에 홈페이지 재설계하기: Figma MCP + Atlassian Design System MCP + Rovo Dev CLI

출처 Redesigning a Homepage in 20 Minutes: Figma MCP + Atlassian Design System MCP + Rovo Dev CLI https://www.atlassian.com/blog/developer/redesigning-homepage-20-minutes-with-rovo-dev 작성자: Anuj Shah (Software Engineer) 발행일: 2026년 02월 23일 Before vs after (이전 vs 이후) 개발자가 4일 동안 작업해야 했던 것이 Rovo Dev CLI와 MCP 서버를 사용해 20분 만에 완료됩니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260219-043133-477x206.pnghttps://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260219-043127-468x268.png TL;DR (요약) 애플리케이션 홈페이지 전체를 새롭게 리디자인했습니다. Figma 목업부터 프로덕션에 바로 투입할 수 있는 React 코드까지, 20분도 채 걸리지 않았습니다. 디자인 토큰을 일일이 복붙할 필요도 없었고, 컴포넌트 API를 추측할 필요도, DevTools에서 픽셀 단위로 미세 조정할 필요도 없었습니다. 재설계의 핵심 핵심은 무엇일까요? Figma MCP https://developers.figma.com/docs/figma-mcp-server/, Atlassian Design System (ADS) MCP https://www.npmjs.com/package/%40atlaskit/ads-mcp, 그리고 Rovo Dev CLI https://support.atlassian.com/rovo/docs/use-rovo-dev-cli/를 하나의 AI 기반 워크플로로 연결하는 것입니다. 이 글에서는 이를 어떻게 구현했는지 자세히 살펴보고, 내부적으로 어떤 MCP 도구들이 사용되었는지, 그리고 그 결과 어떤 코드가 만들어졌는지 정확히 소개합니다. The Problem (문제) 기존 홈페이지의 시각적 디자인을 완전히 개편해야 했습니다. 보통 이런 종류의 재설계에는 프런트엔드 엔지니어가 최소 3~4일, 그 이상의 시간을 들여야 합니다. 디자인을 해석하고, 토큰을 찾아보고, 적절한 컴포넌트를 찾고, 스타일을 연결하고, 테스트를 해야 합니다. AI를 활용하면 이 과정을 몇 분으로 줄일 수 있을지 확인해 보고자 했습니다. 구성: RD CLI와 두 개의 MCP 서버가 연동되는 구조 개발 환경에서 두 개의 MCP (Model Context Protocol) https://modelcontextprotocol.io/introduction 서버를 구성했습니다. Figma Desktop MCP Figma 데스크톱 앱에 연결해 Figma 파일에서 디자인 데이터를 직접 추출합니다. { "figma-desktop": { "url": "http://127.0.0.1:3845/mcp", "transport": "http" } } Atlassian Design System MCP ADS의 모든 컴포넌트, 토큰, 아이콘 및 접근성 가이드라인에 대한 접근 권한을 제공합니다. { "atlassian-design-system-mcp": { "command": "npx", "args": ["-y", "@atlaskit/ads-mcp"] } } Rovo Dev CLI 워크플로를 총괄하는 AI 코딩 에이전트로, 디자인을 읽고, 디자인 시스템 가이드를 조회하고, 코드를 생성하며, 테스트까지 수행합니다. 이 세 가지가 모두 연결되면 다음과 같은 파이프라인이 구성됩니다: Figma 디자인 → AI 해석 → ADS 준수 코드 → 테스트 완료된 결과물 Step-by-Step (단계별 설명): 20분 동안 진행된 과정 Step 1: Figma에서 디자인 추출하기 Rovo Dev https://www.atlassian.com/software/rovo-dev에게 새로운 홈페이지 디자인의 Figma 노드 URL을 전달했습니다. 내부적으로 두 개의 Figma MCP 도구가 동시에 사용되었습니다: get_design_context 전체 디자인 트리(레이아웃 구조, 색상, 타이포그래피, 여백, 컴포넌트 계층, 콘텐츠)를 추출했습니다. 이를 통해 프레임 내 모든 요소의 구조화된 표현을 얻을 수 있었습니다. 여기에는 다음이 포함됩니다: 프레임 크기와 자 레이아웃 속성 색상 채우기 (the amber #F5CD47 hero, the #0C66E4 video card) 텍스트 내용, 글자 크기, 굵기, 줄 간격 테두리 반경, 패딩, 간격 값 중첩된 컴포넌트 구조 get_screenshot 시각적 참고를 위해 디자인의 픽셀 단위까지 정확한 스크린샷을 캡처했습니다. 이를 통해 AI는 검증 기준이 되는 이미지를 얻게 됩니다. 구조화된 데이터와 시각적 스크린샷의 조합 덕분에 AI는 추측할 필요 없이 의미 구조와 시각적 목표물을 모두 확보할 수 있었습니다. Step 2: Atlassian Design System 조회 Rovo Dev는 https://www.atlassian.com/software/rovo-dev 단 한 줄의 코드를 작성하기 전에 ads_plan 도구를 사용하여 ADS MCP에 쿼리를 보냈습니다 이것이 단순히 "이미지에서 코드를 생성하는 것"과 차별화되는 핵심 요소였습니다. 쿼리에는 다음 항목이 포함되었습니다: 요청된 토큰: color.background.warning (앰버 히어로 배너용) color.background.brand.bold (파란색 비디오 카드용) color.text, color.text.subtle, color.text.inverse elevation.shadow.overflow, elevation.surface.raised space.200, space.300, space.400, space.500 border.radius.200 요청된 컴포넌트: Box, Inline, Stack, Flex, Grid (레이아웃 기본 요소) Heading, Button, Lozenge, ProgressBar, Checkbox, Badge 요청된 아이콘: play, chevron-left, chevron-right, more, clock, video ADS MCP에서는 다음과 같은 결과가 나왔습니다: 각 컴포넌트의 정확한 import 경로 사용 방법과 API 문서 토큰 값과 사용 시점 아이콘 컴포넌트 이름과 해당 패키지 각 컴포넌트의 접근성 요구사항 이렇게 생성된 코드는 하드코딩된 hex 값 대신 실제 디자인 시스템 토큰을 사용하고, 일반적인 HTML이 아닌 실제 ADS 컴포넌트를 사용하며, 처음부터 올바른 접근성 패턴을 따릅니다. Step 3: 기존 코드 패턴 파악 Rovo Dev https://www.atlassian.com/software/rovo-dev는 프로젝트의 코드 패턴 문서(rovodev/code-patterns.md 파일)를 참고해 다음 내용을 파악했습니다: 프로젝트에서 컴포넌트를 구성하는 방법 스타일링 규칙(xcss 사용, raw CSS 대신) 별칭 패턴 가져오기(~src/...) 테스트 규칙 기존 페이지에서 레이아웃을 구성하는 방식 이렇게 하면 생성된 코드가 보기에도 좋을 뿐만 아니라 코드베이스에도 잘 맞아 떨어졌습니다. Step 4: 컴포넌트 생성 디자인 데이터, ADS 가이드, 그리고 코드베이스 패턴을 바탕으로 Rovo Dev https://www.atlassian.com/software/rovo-dev는 새로운 컴포넌트 여섯 개를 생성하고 기존 파일 두 개를 업데이트했습니다. 컴포넌트 기능 WelcomeHeroBanner.tsx 환영 메시지, 주차 라벨, 설명, 일러스트가 포함된 앰버 색상의 히어로 배너 WeeklyVideoCard.tsx 비디오 썸네일, 재생 버튼 오버레이, 재생 시간 배지가 포함된 파란색 카드 WeeklySchedulePanel.tsx 이벤트 목록, 시간 배지, Join/Details 버튼이 포함된 일정 패널 TopTasksSection.tsx 카테고리별로 그룹화된 작업과 진행률 바, 인터랙티브 체크박스가 포함된 섹션 ChangeWeekFab.tsx 주차 선택을 위한 플로팅 액션 버튼 CamperHomeSidebar.tsx 네비게이션 항목, 아이콘, 완료 개수 배지가 포함된 왼쪽 사이드바 각 컴포넌트에는 다음 요소가 사용되었습니다: 레이아웃에는 CSS로 직접 스타일링한 div 대신 ADS Box, Flex, Stack, Grid 사용 적절한 헤딩 레벨을 적용한 ADS Heading 상태 배지를 위한 ADS Lozenge 액션을 위한 ADS Button(기본 API와 새로운 API 모두 사용) 작업 완료 상태를 표시하는 ADS ProgressBar 접근성을 위해 적절한 aria-label을 적용한 ADS Checkbox xcss를 통한 디자인 토큰 적용(예: 앰버 배너에는 color.background.warning.bold, 비디오 카드에는 color.background.brand.bold) @atlaskit/icon/core/* 및 @atlaskit/icon/utility/*의 ADS 아이콘 Step 5: 레이아웃 구성 메인 HomePage.tsx 파일을 업데이트해 Figma와 동일한 레이아웃으로 모든 새 섹션을 구성했습니다. 이미지 (8).png 사이드바는 코드 분할 로딩을 위해 프로젝트의 lazyWithSidebar 유틸리티를 사용해 라우팅 구조에 연결되었습니다. Step 6: 문제 수정 및 테스트 실행 AI는 코드를 생성하는 데서 끝나지 않고 기존 테스트 스위트(test suite)를 실행해 세 가지 문제를 차례로 수정했습니다. Double React.lazy wrapping 사이드바에 React.lazy가 두 번 적용되었습니다. (한 번은 수동으로 적용되었고, 한 번은 lazyWithSidebar를 통해 적용되었습니다) 이로 인해 “Element type is invalid” 오류가 발생했습니다. 이에 따라 사이드바를 named export로 변경해 해결했습니다. Duplicate welcome text 기존 HomeBanner와 새 WelcomeHeroBanner에서 동일한 문구가 렌더링되어 getByText가 여러 요소를 찾게 되는 문제가 발생했습니다. 이를 해결하기 위해 기존 HomeBanner를 제거하고 그 안에 있던 액션 버튼을 인라인으로 옮겼습니다. Accessibility violation TopTasksSection의 체크박스에 라벨이 없어 axe-core 접근성 검사에 실패했습니다. 이를 해결하기 위해 설명이 포함된 aria-label 속성을 추가했습니다. 최종 결과: 접근성 검사를 포함해 3개의 테스트가 모두 통과했습니다. 최종 결과 10개 파일이 변경되었으며, 1,381줄이 추가됐고 70줄이 삭제됐습니다. 홈페이지 전면 개편 - 새로운 히어로 배너, 비디오 섹션, 일정 패널, 작업 트래커, 사이드바 내비게이션이 추가되었습니다. 모든 구성은 ADS(Atlassian Design System) 컴포넌트와 토큰을 기반으로 구성되었으며, 접근성을 준수하고 기존 코드베이스 패턴을 따릅니다. Branch: feature/camper-homepage-redesign / 브랜치: feature/camper-homepage-redesign → (선택) 최종 결과: 접근성 검사를 포함해 3개의 테스트가 모두 통과했습니다. 왜 중요한가 Speed 개발자 기준으로 4~5일이 걸리던 작업을 약 20분 만에 처리할 수 있습니다. AI가 기계적인 변환 과정(design → tokens → components → layout)을 담당하고, 개발자는 의도 파악과 결과 검토에 집중할 수 있습니다. Consistency 코드 생성 전에 ADS MCP를 조회했기 때문에 모든 컴포넌트가 올바른 디자인 토큰과 컴포넌트 API를 사용합니다. 하드코딩된 색상도 없고, 잘못된 간격 값도 없으며 더 이상 사용되지 않는 컴포넌트도 없습니다. Accessibility ADS MCP는 컴포넌트 API와 함께 접근성 가이드를 제공합니다. 생성된 코드는 처음부터 올바른 heading 계층 구조, ARIA 라벨, 그리고 키보드로 탐색 가능한 패턴을 포함하며, 테스트 스위트가 axe-core를 통해 이를 검증합니다. Code Quality Rovo Dev https://www.atlassian.com/software/rovo-dev가 먼저 코드베이스의 규칙을 확인했기 때문에 생성된 코드는 프로젝트의 기존 패턴을 따릅니다. 결과물은 코드베이스를 잘 아는 팀원이 작성한 것처럼 보이며, 단순히 스크린샷만 보고 만든 AI 코드처럼 보이지 않습니다. The MCP Tool Chain: A Summary Step MCP Server Tool Purpose 1 Figma Desktop get_design_context 디자인 구조, 색상, 타이포그래피, 간격 정보 추출 2 Figma Desktop get_screenshot 대상 디자인의 시각적 참조 이미지 캡처 3 ADS MCP ads_plan 컴포넌트 API, 토큰 값, 아이콘 import, 접근성(a11y) 가이드 확인 4 Rovo Dev Code reading 기존 코드 패턴, 테스트 규칙, 라우트 설정 확인 5 Rovo Dev Code generation 신규 컴포넌트 6개 생성 및 기존 파일 4개 업데이트 6 Rovo Dev Test runner 테스트 실행 후 모든 테스트가 통과할 때까지 문제 반복 수정 직접 사용해 보기 Figma MCP https://developers.figma.com/docs/figma-mcp-server/ 설치 - Figma 데스크톱 앱 연동 활성화 ADS MCP https://www.npmjs.com/package/%40atlaskit/ads-mcp 설치 - Atlassian Design System 서버 연결 Rovo Dev CLI https://support.atlassian.com/rovo/docs/use-rovo-dev-cli/에 Figma 노드 전달 - 노드 URL을 공유하고 원하는 작업 설명 결과 검토 - AI가 코드 생성, 테스트, 수정까지 수행하고 사용자가 최종 검토 및 보완 Front-end 개발의 미래는 개발자를 대체하는 것이 아니라, 디자인과 코드 사이의 번거로운 변환 과정을 줄여 개발자가 실제로 중요한 판단에 집중할 수 있도록 하는 것입니다.

2026/04/16

공급망 공격의 새로운 타깃: 당신의 '에이전트'는 안전합니까?

2026년 3월 24일 발생한 LiteLLM 공급망 침해는 고립된 사건이 아닙니다. 이는 JFrog Security Research가 수년간 추적해 온, 진화하는 공격자 플레이북의 가장 최근 사례이자 어쩌면 가장 위험한 사일 수 있습니다. 이제 공격 대상은 개발자에서, 개발자가 소프트웨어를 구축하기 위해 의존하는 AI 에이전트로 옮겨갔습니다. 개발자는 늘 공격의 표적이었습니다 공급망 공격은 단순한 공식을 따릅니다. 신뢰받는 오픈소스 패키지를 찾고, 그것을 오염시킨 뒤, 생태계가 그 배포를 대신하게 만드는 것입니다. 2025년 9월 처음 보고되었고 JFrog Security Research 팀이 광범위하게 분석한 Shai-Hulud는 그 좋은 사례였습니다. npm 패키지에 삽입된 자기복제 웜을 기반으로, 이 공격은 개발자 토큰을 탈취하고 해당 개발자들이 유지 관리하던 다른 패키지들까지 자동으로 다시 감염시키도록 설계되었습니다. 공격자의 직접적인 개입 없이 기하급수적으로 확산되었기 때문에, 이는 기록상 가장 심각한 자바스크립트 공급망 공격 중 하나로 평가되었습니다. 조직이 이러한 유형의 위협으로부터 스스로를 보호할 수 있도록, JFrog Curation은 악성 및 취약한 오픈소스 패키지가 개발자 환경에 도달하기 전에 차단하는 자동화된 게이트키핑 계층을 제공합니다. SDLC는 변화하고 있으며, 공격 표면도 함께 바뀌고 있습니다. 개발자 자체뿐 아니라, 악의적인 행위자들은 AI가 생성한 코드에서도 취약점을 찾아내고 있습니다. 이제 소프트웨어 개발자는 더 이상 자신의 코딩 역량에만 의존하지 않습니다. 대신 코드 생성, 테스트, 리서치, 배포를 위해 여러 AI 에이전트를 동시에 운영하고 있습니다. 개발 수명주기는 인간이 주도하는 선형적인 흐름에서, 분산된 멀티 에이전트 파이프라인으로 진화했습니다. AI 생성 코드 이전 image-2026-4-16_14-55-56.png AI 생성 코드 이후 image-2026-4-16_14-55-1.png 이제 각 개발자는 여러 에이전트를 병렬로 실행할 수 있으며, 각 에이전트는 AI 패키지, MCP 서버, 모델, 스킬과 상호작용합니다. 그 결과 공격 표면은 빠르게 확장되고 있습니다. 에이전트가 어떻게 작동하는지 이해하는 것은 이러한 새로운 공격 표면을 이해하는 데 중요합니다. AI 에이전트는 단일 모델이 아니라 여러 AI 구성요소가 결합된 구조입니다. 그 중심에 있는 LLM 그 동작 방식을 형성하는 룰과 메모리 에이전트가 실행할 수 있는 스킬 외부 시스템 및 데이터와 연결해 주는 MCP 서버 이 구성요소 각각은 모두 잠재적인 공격 경로이자 위험 요소입니다. AI 에이전트의 구조 image-2026-4-16_15-10-0.png 에이전트가 이제 새로운 표적이 되었습니다 공급망 통제로 개발자 환경을 오염시키는 것이 더 어려워지나, 공격자들은 방향을 틀었습니다. 개발자를 뚫을 수 없다면, 그들이 사용하는 도구를 노리면 되기 때문입니다. 2025년 9월, postmark-mcp: 실제 환경에서 발견된 최초의 악성 MCP 서버 공격자는 정상적인 Postmark MCP 저장소를 복제한 뒤, 거의 동일한 npm 패키지를 배포했습니다. 15개 버전 동안 이 패키지는 아무 문제 없이 작동했고, 수백 개의 워크플로우에서 개발자들의 신뢰를 받았습니다. 그러다 버전 1.0.16에서 단 한 줄의 코드가 추가됐습니다. 숨겨진 BCC 기능이 삽입된 것입니다. 이 코드는 MCP 서버를 통해 전송되는 모든 이메일을 공격자가 제어하는 도메인으로 조용히 전달했습니다. 비밀번호 재설정 메일, 청구서, 내부 메모까지, 커넥터를 전적으로 신뢰하고 있던 AI 에이전트 워크플로우 내부에서 은밀하게 유출되었습니다. 이 공격이 특히 위험했던 이유는 MCP 서버가 에이전트 툴체인 안에서 높은 수준의 신뢰와 광범위한 권한을 가지고 실행되기 때문입니다. 악성 MCP 서버는 단순히 하나의 코드베이스를 오염시키는 데 그치지 않습니다. 그것은 전체 AI 기반 워크플로우와 연결된 모든 시스템을 조작할 수 있는, 지속적인 상위 제어 지점이 됩니다. postmark-mcp 공격은 경고탄이었습니다. LiteLLM 침해는 그보다 한 단계 더 격화된 사건이었습니다. LiteLLM 공격: 한층 더 정교해진 수준 LiteLLM은 AI 생태계에서 가장 중요한 패키지 중 하나로, OpenAI, Anthropic, AWS Bedrock, Google VertexAI를 포함한 100개 이상의 LLM API로 연결되는 범용 게이트웨이 역할을 합니다. 이 패키지는 하루 약 340만 건의 다운로드를 기록하고 있으며, 클라우드 환경의 36%에 존재합니다. 또한 MCP 플러그인과 AI 에이전트 프레임워크에서 흔히 사용되는 필수 종속석 패키지이기 때문에 공격 대상이 되었습니다. 자세한 내용은 JFrog Security Research의 전체 기술 분석 보고서 https://research.jfrog.com/post/litellm-compromised-teampcp/?_gl=1%2areqtrj%2a_gcl_au%2aMjA3ODI1NTEwMy4xNzc1NjI1Mjk5%2aFPAU%2aMjA3ODI1NTEwMy4xNzc1NjI1Mjk5%2a_ga%2aMTk3NTQ0Nzk4LjE3NjYzODU3MDM.%2a_ga_SQ1NR9VTFJ%2aczE3NzYzMTc1MzkkbzIwJGcxJHQxNzc2MzE3OTgyJGoyNyRsMCRoNjg5NTg0NzI0%2a_fplc%2aVnI2cUNEdTJwaSUyRkdQRWtUYUw5WXduaEhERml3QTRFcCUyQk5MMGRWbFhKZXIxVDg1UExzVWpSb3g3OFZ4ajVtdjlKZ3Z1R1FnMzNpTXVibGZ1YzlFTkJFVWpSdTBOYXMxMUZWR3lQMFY0YWZtMElPJTJCMWhHcnVmJTJGSUpVb205R0ElM0QlM0Q.를 참고하시기 바랍니다. 이번 공격은 Aqua Security의 Trivy 스캐너와 Checkmarx의 KICS GitHub Action을 해킹한 TeamPCP에 의해 수행되었습니다. 이는 우발적인 공격이 아니라, 조직적이고 연쇄적인 공격 캠페인이었습니다. 어떻게 발생했는가 LiteLLM의 CI/CD 파이프라인은 빌드 과정의 일부로 Trivy를 실행하고 있었으며, 버전은 고정되어 있지 않았습니다. 3월 19일, TeamPCP는 이미 Trivy의 GitHub Action을 침해한 상태였습니다. 이후 LiteLLM의 빌드가 실행되자, 손상된 Trivy 액션은 GitHub Actions 러너에서 프로젝트의 PyPI 게시 토큰을 유출했습니다. 이 자격 증명을 손에 넣은 공격자들은 3월 24일 아침, LiteLLM의 정상적인 릴리스 워크플로우를 완전히 우회하는 악성 페이로드가 포함된 litellm 1.82.7 및 1.82.8 버전을 게시했습니다. 악성코드는 무엇을 했는가 실행이 시작되면, 이 페이로드는 3단계 공격을 수행했습니다. SSH 키, AWS, GCP 및 Azure 클라우드 토큰, Kubernetes 시크릿, 암호화폐 지갑, .env파일 등의 자격 증명을 수집 Kubernetes 클러스터 전체에 걸쳐 권한 있는 Pod를 모든 노드에 배포하여 클러스터 간 수평 이동을 시도 공격자가 제어하는 인프라에서 추가 바이너리를 주기적으로 수집하는 영구적인 systemd 백도어를 설치. 수집된 모든 데이터는 암호화되어 models.litellm.cloud합법적인 LiteLLM 인프라를 사칭하는 도메인(공격 당일 등록된 도메인)으로 유출되었습니다. 특히 1.82.8 버전은 Python의 .pth 파일 메커니즘을 악용했기 때문에 더욱 공격적이었습니다. 이 메커니즘은 LiteLLM이 명시적으로 import되지 않더라도, Python 인터프리터가 시작될 때마다 실행됩니다. 또한 이 페이로드는 정적 분석을 피하기 위해 이중 base64 인코딩 처리되어 있었습니다. 어떻게 발견되었는가 – 에이전트 내부에서 이 공격은 Cursor 내부에서 실행 중이던 MCP 플러그인이 전이 의존성으로 해당 패키지를 가져오면서 처음 발견되었습니다. 한 연구원의 머신이 RAM 고갈로 인해 응답하지 않게 되었는데, 이는 악성코드 자체의 포크밤(Fork bom) 버그로 인한 부작용이었습니다. 즉, 사람이 의식적으로 설치하기도 전에 악성 패키지가 AI 에이전트의 런타임까지 도달한 상태였습니다. 조직에 미치는 영향 LiteLLM은 일반적으로 애플리케이션과 여러 AI 서비스 제공자 사이에 직접 위치하기 때문에, 조직의 전체 AI 스택에 대한 API 키, 환경 변수, 민감한 구성 데이터를 보유하게 됩니다. 따라서 단 한 번의 손상된 설치만으로도, 조직이 사용하는 모든 AI 서비스의 자격 증명이 노출될 수 있습니다. 그리고 그 범위는 LiteLLM이 실행되는 모든 환경, 즉 개발자 머신, CI/CD 파이프라인, 스테이징, 운영 환경 전체에 걸칩니다. 해당 악성 버전은 약 3시간 동안 PyPI에 게시된 상태로 존재했습니다. 패키지의 다운로드 규모를 고려하면, 그 시간 동안의 잠재적 노출 범위는 상당했습니다. 명확한 패턴 공격 벡터 목표 Shai-Hulud(npm) 오픈소스 패키지에서 발견된 자가 복제 웜 개발자 환경 postmark-mcp(npm) 악성 MCP 서버 AI 에이전트 워크플로 LiteLLM(PyPI) 손상된 CI 도구를 통해 악성 AI 인프라 패키지가 배포 에이전트 런타임 + CI/CD 공격 대상 범위가 넓어졌을 뿐만 아니라, 각 개발자가 실행하는 에이전트 수만큼 증가했습니다. 단 하나의 AI 종속성이 손상되면 에이전트가 동시에 작동하는 모든 환경으로 파급 효과가 발생할 수 있습니다. 오픈소스 AI 게이트웨이의 문제 생태계 안에서 LiteLLM이 맡고 있는 역할은 면밀히 살펴볼 필요가 있습니다. LiteLLM은 본질적으로 애플리케이션과 모든 LLM API 사이에 위치하는 단일 라우팅 계층을 사용하는 오픈 소스 AI 게이트웨이입니다. 이러한 아키텍처적 위치는 매우 강력하지만, 동시에 매우 매력적이고 파괴적인 공격 경로가 될 수 있는 요인이기도 합니다. 모든 AI 트래픽을 단일 오픈소스 패키지를 통해 라우팅한다는 것은, 그 패키지의 무결성, 그 패키지를 유지 관리하는 사람들의 보안 관행, 그리고 그것을 배포하는 파이프라인에 지대한 신뢰를 두는 일입니다. LiteLLM 침해 사건은 그 신뢰가 얼마나 취약할 수 있는지를 보여주었습니다. CI 워크플로우 안에서 버전이 고정되지 않은 단 하나의 의존성만으로도, 공격자에게 조직 전체 AI 인프라의 열쇠가 넘어갈 수 있었습니다. 여기에는 모든 모델 API 키, 모든 클라우드 자격 증명, 그리고 해당 환경 내 모든 비밀정보가 포함됩니다. 물론 이것이 AI 게이트웨이의 강점을 활용하지 말라고 주장하는 것은 아닙니다. 다만 우리는 그것을 올바른 보안 기반 위에서 구축해야 한다는 점을 강조하고 싶습니다. 여러분의 에이전트형 공급망 중심에 위치하는 AI 게이트웨이라면, 공용 레지스트리에서 가져와 잘 되기만을 바라는 방식이 아니라, 엔터프라이즈급 통제를 바탕으로 관리되어야 합니다. 신뢰할 수 있는 에이전트형 공급망 구축 해답은 AI 도입 속도를 늦추거나 금지하는 것이 아닙니다. 해답은 AI 계층을 맹목적으로 신뢰하는 일을 멈추고, 나머지 소프트웨어 공급망에 적용해 온 것과 동일한 수준의 엄격함으로 이를 관리하기 시작하는 것입니다. 바로 이런 이유로, JFrog는 에이전트의 신뢰성은 에이전트가 소비하고, 구축하고, 배포하는 데이터만큼만 중요하다는 원칙을 기반으로 처음부터 설계된 JFrog AI Catalog https://jfrog.com/ai-catalog/ 와 AI Gateway를 출시했습니다. AI Gateway: 설계 단계부터 신뢰를 내장하다 단순히 트래픽을 라우팅하고 결과를 기다리는 오픈 소스 게이트웨이와 달리, JFrog AI 게이트웨이는 보안 정책이 적용된 연결 계층으로 설계되었습니다. 이 게이트웨이는 모델, MCP 서버, 에이전트 스킬 등 모든 AI 소비 대상을 하나의 중앙 통제 지점을 통해 라우팅함으로써, 전체 AI 사용 범위를 통합 거버넌스 아래에 둡니다. 또한 모든 요청이 인증되도록 보장하고, 하위 자산에 대한 접근이 허용되기 전에 각각이 충분히 검증되도록 합니다. 핵심적인 아키텍처적 차이점은 바로 이것입니다. JFrog AI 게이트웨이는 단순히 트래픽을 프록시하는 데 그치지 않고, 에이전트가 검증되지 않은 모델이나 MCP 서버에 접근하기 전에 연결 지점에서 신뢰를 구축합니다. JFrog MCP Registry: 더 이상 맹목적인 신뢰는 없다 JFrog MCP Registry는 postmark-mcp와 LiteLLM이 보여준 바로 그 유형의 공격에 대한 직접적인 대응입니다. JFrog는 오래전부터 소프트웨어 패키지를 관리하고 보호해 온 방식 그대로, MCP 서버 역시 스캐닝, 정책 강제, 버전 관리 기능이 내장된 완전히 통제 가능한 아티팩트로 다룹니다. MCP Registry가 제공하는 핵심 기능은 다음과 같습니다. 설계 단계부터 보안을 강화하여, 침해 후 탐지하는 대신 에이전트가 악성 또는 규정을 준수하지 않는 MCP 서버를 다운로드하거나 실행하기 전에 사전에 차단합니다. 중앙 집중식 거버넌스 개발자는 공개 레지스트리에서 가져올 필요 없이 IDE(Cursor, Claude Code, VS Code)에서 사전 승인된 MCP 서버 레지스트리에 직접 액세스할 수 있습니다. 엔터프라이즈급 정책 시행으로 "맹목적인 신뢰"를 프로젝트 수준의 세부적인 권한 설정으로 대체하여 에이전트가 연결할 수 있는 MCP 서버를 정확하게 제어합니다. 로컬 MCP 게이트웨이는 개발자 컴퓨터에서 인증 및 권한 확인을 투명하게 처리하는 경량 프록시로, 코딩 에이전트가 사전 검증된 서버에만 연결되도록 보장합니다. postmark-mcp 공격이 성공한 이유는 개발자가 공용 레지스트리에서 MCP 서버를 가져와 전적인 신뢰를 부여했기 때문입니다. LiteLLM 공격이 성공한 이유는 빌드 파이프라인이 버전 고정되지 않은 오픈소스 패키지를 암묵적으로 신뢰했기 때문입니다. JFrog MCP Registry는 모든 MCP 서버를 통제되는 아티팩트로 다루고, 승인되지 않은 것은 입구에서 차단하기 때문에, 이런 상황이 개발자에게 경고 없이 발생할 수 없도록 설계되었습니다. 에이전트 기반 공급망 전체를 위한 단일 기록 시스템 더 큰 비전은 에이전트가 소비하고 생성하는 모든 계층을 통제하는 통합 기록 시스템를 구축하는 것입니다. 모델, MCP 서버, 에이전트 스킬, AI 생성 코드, 조립된 아티팩트까지 모두 한곳에서 관리하며, 더 넓은 소프트웨어 공급망에 적용되는 것과 동일한 보안 및 컴플라이언스 통제 아래 두는 것입니다. JFrog는 이를 신뢰할 수 있는 에이전트형 공급망, 즉 Trusted Agentic Supply Chain이라고 부릅니다. 이는 불변성, 출처 추적, 정책 강제, 지속적인 스캐닝과 같이 수십 년간 소프트웨어 공급망을 지배해 온 원칙을, 에이전트가 의존하는 새로운 AI 자산군 전체로 확장한 개념입니다. 또한 이는 NVIDIA 같은 파트너와의 통합을 통해 검증되고 있으며, NVIDIA의 OpenShell 런타임은 엔터프라이즈 규모에서 검증된 AI 스킬을 배포하기 위한 관리형 엔드포인트로 JFrog Platform을 사용하고 있습니다. JFrog가 에이전트형 공급망 보호를 지원하는 방법 JFrog와 협력하면, 다음과 같은 조치를 통해 최신 공급망 공격으로부터 조직을 보호하기 시작할 수 있습니다. 에이전트와 MCP 플러그인이 가져오는 전이적 의존성을 포함해 AI 의존성 체인을 감사하세요. 버전을 반드시 고정하세요. LiteLLM 공격은 공급망 여러 지점에서 버전이 고정되지 않은 의존성을 악용했습니다. 오픈소스 AI 게이트웨이를 본질적으로 신뢰할 수 있는 인프라로 취급하지 마세요. 정책 강제가 가능한 엔터프라이즈급 거버넌스 게이트웨이를 통해 AI 트래픽을 라우팅하세요. MCP 서버를 통제하세요. JFrog MCP Registry https://jfrog.com/ai-catalog/mcp-registry/를 사용해 에이전트가 검증되고 승인된 서버에만 연결할 수 있도록 하세요. 침해가 의심되는 경우에는 패키지 제거에 그치지 말고, 시스템 전체가 침해되었을 가능성을 전제로 자격 증명을 적극적으로 교체하세요. 신뢰할 수 있는 AI 카탈로그를 구축하세요. JFrog AI Catalog https://jfrog.com/ai-catalog/를 모델, MCP, 스킬, AI 패키지를 위한 단일 기록 시스템으로 활용하세요. 핵심 요약 SDLC(소프트웨어 개발 수명주기)가 변화했습니다. 개발자는 더 이상 파이프라인의 유일한 주체가 아니라, 기계 속도로 AI 자산을 소비하는 에이전트 플릿을 지휘하는 역할을 합니다. 공격자들은 개발자들이 활동하는 모든 새로운 환경, 심지어 에이전트 워크플로까지 추적합니다. LiteLLM은 경종을 울리는 사건이었습니다. 이 사건은 AI 인프라의 중심에 있는 오픈 소스 AI 게이트웨이가 중립적인 인프라가 아니라 매우 가치 있는 공격 대상이라는 사실을 보여주었습니다. 문제는 여러분의 트러스트 모델이 이러한 현실에 대비되어 있느냐는 것입니다. JFrog는 신뢰가 플랫폼에 내장되어야 하며, 당연한 것으로 전제되거나 사후에 덧붙여져서는 안 된다고 믿습니다. 이는 오픈소스 패키지를 큐레이션하고, AI 모델을 통제하며, 실행 전에 정책을 강제하는 레지스트리를 통해 MCP 서버를 보호하고, 신뢰를 최우선으로 두는 게이트웨이를 통해 모든 AI 트래픽을 라우팅하는 것을 의미합니다. AI로 가속되는 세상에서, 속도는 그 기반이 신뢰할 수 있을 때에만 진정한 이점이 되기 때문입니다. JFrog 솔루션에 대해 더 알고싶다면 커브에 문의하세요. 제품 소개 및 평가판 지원 또한 JFrog AI Catalog, JFrog MCP Registry, JFrog Curation에 대해서도 더 자세히 알아보실 수 있습니다. 출처 : From Shai-Hulud to LiteLLM: Supply Chain Attackers Are Coming for Your Agents by Yuval Fernbach, CTO, JFrog ML https://jfrog.com/blog-author/yuval-fernbach/

2026/04/03

사이버 복원력 법안(CRA)과 JFrog 플랫폼

main.png CRA란? 입법 프레임워크 (정의) EU가 디지털 제품 및 서비스의 사이버보안을 강화하기 위해 도입한 포괄적인 입법 프레임워크입니다. 수명주기 전반의 보안 (대상) 하드웨어와 소프트웨어를 포함한 디지털 요소가 탑재된 제품이 전체 수명주기 동안 강력한 보안을 유지하며 설계, 개발, 관리되도록 보장합니다. 신뢰 제고 및 의무화 (목적) 제품의 취약성을 감소시키고 디지털 시장의 신뢰를 제고하는 것이 핵심입니다. 이를 위해 보안 설계, 정기적인 업데이트, 그리고 능동적인 취약점 관리를 법적으로 의무화합니다. CRA 적용 범위 대상 제품 (디지털 요소) 직접 또는 간접적으로 데이터 네트워크에 연결될 수 있는 모든 하드웨어 및 소프트웨어 제품을 포함합니다. 경제 주체 (책임 대상) 해당 디지털 제품을 EU 시장에 공급하는 제조사, 수입업체, 유통업체 모두에게 보안 준수 의무가 부여됩니다. 포함 자산 범위 소스 코드부터 컨테이너, 바이너리, 아티팩트, 메타데이터, 그리고 시스템 구성(Configuration)에 이르기까지 소프트웨어 공급망 전체 자산을 다룹니다. CRA 핵심 요구사항(4가지) Security by Design 설계 단계부터 보안을 핵심 요소로 고려하여 내재화합니다. Risk Management 제품 수명주기 전반에 걸친 지속적인 위험 식별, 평가 및 완화를 수행합니다. Vulnerability Handling 취약점 식별, 우선순위 지정, 조치 및 적시 공개를 위한 필수 메커니즘을 구축합니다. Regular Updates & Patches 새로운 취약점 대응을 위한 정기적인 보안 업데이트와 패치를 제공합니다. JFrog 보안 소프트웨어 공급망 관리 플랫폼 JFrog 플랫폼은 소스 코드부터 런타임까지 소프트웨어 개발 전 과정을 안전하고 통제된 방식으로 운영할 수 있도록 지원하는 통합 소프트웨어 공급망 관리 솔루션입니다. 이 플랫폼은 소프트웨어 개발을 위한 단일한 신뢰 기반을 제공하며, 개발자, 운영팀, 보안팀 간의 간극을 해소해 전체 소프트웨어 공급망을 보호할 수 있도록 지원합니다. JFrog Security 솔루션은 CRA 준수를 지원하며, 클라우드, 멀티클라우드, 셀프호스팅, 에어갭, 하이브리드 방식으로 제공됩니다. image-2026-4-3_13-28-55.png JFrog 플랫폼 구성 및 보안 기능 JFrog Curation & Catalog 안전하지 않은 오픈소스 소프트웨어(OSS) 구성요소가 소프트웨어 공급망에 유입되지 않도록 자동화된 보안 정책을 적용하여, 신뢰할 수 있는 구성요소만 사용되도록 보장합니다. JFrog Essential & Advanced Security 취약점을 쉽게 식별, 우선순위화, 조치할 수 있으며, 안전한 자동 업데이트를 제공하고 SBOM을 통해 적시에 보고할 수 있도록 지원합니다. 문맥 기반 분석, SAST, 보안 노출 스캔을 포함한 고급 애플리케이션 보안 테스트 및 강력한 취약점 관리를 통해 안전한 코딩 관행을 구현할 수 있습니다. JFrog Release Lifecycle Management SDLC 초기 단계에서 변경 불가능한 릴리스 번들을 생성하여 안전한 개발 관행을 수립하고, 적시 업데이트와 보안 패치를 보다 효율적으로 수행할 수 있도록 합니다. 리스크 평가와 감사 추적을 포함한 포괄적인 문서화를 통해 릴리스 프로세스 전반에 대한 가시성을 확보할 수 있습니다. JFrog Connect 배포 수명주기 전반에 걸쳐 CVE 심각도를 능동적으로 모니터링하고, 임베디드 디바이스에 영향을 미치는 취약점에 대한 깊이 있는 인사이트를 제공합니다. JFrog의 통합 보안 솔루션은 포괄적인 리스크 평가와 상세한 감사 추적 및 문서화를 제공하여, 기업이 CRA 규정을 준수하고 책임성을 확보할 수 있도록 지원합니다. JFrog 플랫폼과 Security Suite를 활용하면 개발 워크플로우 전반에 보안을 자연스럽게 통합할 수 있으며, 이를 통해 Cyber Resilience Act 준수는 물론 소프트웨어 공급망 전반의 보안 수준까지 향상시킬 수 있습니다. JFrog 플랫폼이 요구사항 충족에 어떻게 도움이 되는지 더 알아보려면 데모를 요청해 보시기 바랍니다.

2026/03/27

2026년 03월 커브 소식지(뉴스레터)

안녕하세요, 커브입니다. 최근 AI 어시스턴트 덕분에 코드가 생성되는 속도는 비약적으로 빨라졌고, 업무 자동화는 이제 선택이 아닌 필수가 되었습니다. 하지만 속도가 빨라진 만큼, 우리가 놓치고 있는 '빈틈'은 없을까요? 단순히 양적으로 늘어난 결과물이 오히려 조직의 기술 부채를 키우고 있지는 않은지 점검이 필요한 시점입니다. 이번 뉴스레터에서는 AI가 만든 코드의 안전성을 확보하는 기술적 방안과, AI 도입 후 자칫 빠지기 쉬운 '생산성의 함정'을 극복하는 전략을 준비했습니다. https://d15k2d11r6t6rl.cloudfront.net/public/users/Integrators/208d7955-33b5-4ad5-b739-82f8ce94ecac/8a9982cf7639e85d01764536575024c3/%EC%BB%A8%ED%85%90%EC%B8%A0%20%EB%B0%B0%EB%84%88/BEST%26NEW%20CONTENTS%20TITLE-09.png https://d15k2d11r6t6rl.cloudfront.net/public/users/Integrators/208d7955-33b5-4ad5-b739-82f8ce94ecac/8a9982cf7639e85d01764536575024c3/%EC%BB%A8%ED%85%90%EC%B8%A0%20%EB%B0%B0%EB%84%88/BEST%26NEW%20CONTENTS%20TITLE-10_1.png Loom과 Rovo로 쉽고 효과적으로 경쟁사 분석 하기 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235a101d33e2cf729292caa1d9b495b0dd6f Jira Cloud 스페이스 (Space) 구성 가이드 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235ab71432349a910396caa1d9b495b0dd6f Jira Cloud 필드의 필수 값 설정하기 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235a0aeebb3a4c9cca7fcaa1d9b495b0dd6f Jira Cloud 자동화 (Automation) 사용 가이드 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235a52f34d5a2fb9d790caa1d9b495b0dd6f Jira Cloud 파일 저장 데이터 사용량 확인하기 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235a099bc69d1c39feb5caa1d9b495b0dd6f SonarSource : AC/DC 개발 사이클의 등장 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235a57aa239fdcdd253acaa1d9b495b0dd6f SonarQube 소스코드 라인 계산기 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235aeef549356bd7b813caa1d9b495b0dd6f AI 사용자 경험(UX) 패턴 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235ac884071ff5a9f275caa1d9b495b0dd6f Rovo로 팀이 업무를 30% 더 빠르게 시작하는 방법 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235a347f291e54a4ceb5caa1d9b495b0dd6f EU CRA 준수를 위한 8단계 체크리스트 https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235addd6fce11af9ae47caa1d9b495b0dd6f 202603 2.png https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235af81c6e03cf9e2146caa1d9b495b0dd6f 202603 3.png https://link.zift123.com/c/103/10c39e4daa17d28da9c725501ecec34210a9c43acd69235a64672f0bb25c8349caa1d9b495b0dd6f

2026/03/26

EU CRA 준수를 위한 8단계 체크리스트

유럽 연합(EU)의 사이버 복원력 법안(CRA)은 소프트웨어 제조사가 '설계 단계부터 보안(Secure-by-design)'을 실현하도록 의무화하며, 제품의 취약점에 대해 법적 책임을 지도록 규정하고 있습니다. 특히 CRA는 사람이 작성한 코드와 AI가 제안한 코드를 구분하지 않으므로, 기업은 AI의 개발 속도에 맞춰 보안 검증 역량을 확장해야만 하는 과제에 직면해 있습니다. EU CRA란? EU Cyber Resilience Act로, 소프트웨어·IoT 등 디지털 요소가 있는 제품에 기본적인 사이버보안 요건을 의무화한 규정입니다. 제품을 설계할 때부터 보안을 반영하고, 출시 후에도 취약점 관리와 보안 업데이트를 해야 하며, 심각한 사고나 실제 악용된 취약점은 정해진 절차에 따라 신고해야 합니다. 2024년 12월 10일 발효됐고 주요 의무는 2027년 12월 11일부터 적용됩니다. 이러한 규제 환경에 효과적으로 대응하기 위한 8단계 체크리스트는 다음과 같습니다. CRA 준수를 위한 8단계 체크리스트 1. SAST를 통한 취약점 최소화 정적 애플리케이션 보안 테스트(SAST)를 활용하여 개발 초기 단계에서 악용 가능한 코딩 약점을 식별합니다. 이는 제품 출시 전 취약점을 최소화해야 한다는 CRA 제13조 의무 사항을 충족하는 핵심 방법입니다. 2. 시스템 접근 보호 코드베이스 전체를 스캔하여 하드코딩된 API 키, 비밀번호, 민감한 토큰을 탐지하고 차단합니다. 이는 무단 접근으로부터 시스템을 보호해야 한다는 Annex I(부속서 I) 요건을 실현합니다. 3. 서드파티 리스크 관리 소프트웨어 구성 분석(SCA)을 통해 보안 취약점이 있는 외부 종속성을 식별하고 지속적으로 모니터링합니다. 이는 CRA의 투명성 및 수명 주기 리스크 관리 의무를 지원합니다. 4. 알려진 취약점(Exploits) 부재 검증 NVD, EPSS, KEV, OSV 등의 데이터베이스를 활용하여 사용 중인 구성 요소에 알려진 위험이 없는지 검증합니다. 알려진 취약점 없이 제품을 출하해야 한다는 Annex I의 명령을 직접적으로 이행하는 단계입니다. 5. 공급망 투명성 확보 기계 판독이 가능한 소프트웨어 자재 명세서(SBOM)를 자동으로 생성합니다. 이를 통해 소프트웨어 수명 주기 전반에 걸쳐 추적 가능한 인벤토리 관리 프로세스를 구축하고 명확한 CRA 요건을 충족할 수 있습니다. 6. 감사 추적 및 증빙 생성 수명 주기 변경, 구성 업데이트, 보안 이벤트 등을 기록하는 안전하고 변경 불가능한 감사 로그를 유지합니다. 이는 CRA 리스크 평가에 필요한 문서화 과정을 획기적으로 간소화해 줍니다. 7. 생성 시점에서 표준 적 IDE에서 개발자에게 실시간 피드백을 제공하고, CI/CD 파이프라인에 '품질 게이트(Quality Gates)'를 설정합니다. 이를 통해 규정을 준수하지 않은 코드가 운영 환경으로 넘어가는 것을 원천 차단합니다. 8. 전략적 거버넌스를 통한 리스크 평가 프로젝트 대시보드와 포트폴리오 관리를 통해 코드베이스의 건강 상태를 가시화합니다. 보이지 않던 '기술 부채'를 데이터로 변환하여 경영진과 리스크 관리자가 명확한 의사결정을 내릴 수 있도록 돕습니다. SonarQube는 위와 같은 엄격한 표준을 충족할 수 있는 자동화된 검증 인프라를 제공하여, 모든 코드가 보안성을 갖추고 운영에 적합한 상태임을 보장합니다. 참고: CRA 관련 보안 보고서 및 요건은 엔터프라이즈 에디션 이상에서 지원되며, SCA 및 SBOM 생성은 Advanced Security 기능이 필요합니다.

- Others -

Contributor

사용자	수정	댓글	레이블
설진호 이사	1269	39	414
황희연 대표	682	12	13
이지혜 선임	679	0	30
이수정 선임	631	0	69
윤준호 책임	629	7	18
박주현 책임	326	4	15
Anonymous	242	10	46
김나우 선임	223	0	11
성윤주 선임	176	1	14
박상민 선임	161	0	29
이형근 책임	130	1	6
김광일 선임	119	1	1
한은우 선임	86	0	0
이상훈 선임	60	0	3
박재국 선임	55	1	1
김미현 선임	53	0	15
Anonymous	39	1	15
Anonymous	31	7	0
김태연 선임	26	0	1
신민수 선임	26	0	2
최보근 선임	23	0	0
김수영 선임	22	0	0
나종진 부장	17	0	1
정성훈 선임	14	0	0
강수재 선임	6	0	0
황현우 선임	6	0	0
김상범 선임	5	0	0
송선택 선임	5	1	1
이학준 부장	5	0	0
문소정 선임	4	0	0
이준석 사원	4	1	0
Anonymous	3	0	4
강다빈 선임	1	0	0
박건우 선임	1	0	2
Anonymous	0	0	1
강돈영 선임	0	0	1
김동윤 선임	0	0	2
김희범 책임	0	0	1
정재훈 책임	0	0	1

페이지 트리

CURVC DevOps Confluence

**- Products Guide -**