CURVC DevOps Confluence

출처: Four warning signs your AI and collaboration investments aren’t paying off https://www.atlassian.com/blog/ai-at-work/four-warning-signs-your-ai-and-collaboration-investments-arent-paying-off 작성자: kdelara 발행일: 2026년 04월 13일 96%의 기업이 AI로부터 의미 있는 비즈니스 가치를 아직 얻지 못하고 있습니다. 그리고 여러분의 조직 역시 그중 하나일 수 있습니다. 그럼에도 IT 리더들은 계속해서 큰 규모의 투자를 이어가고 있으며, 프로젝트 지연과 서비스 지표 개선 부진의 원인을 고민하고 있습니다. Atlassian의 AI Collaboration Index https://www.atlassian.com/blog/cxo-ai-collaboration-report-2025에 따르면, 광범위한 투자에도 불구하고 96%의 기업이 아직 AI에서 의미 있는 비즈니스 가치를 확인하지 못했습니다. AI는 업무 수행을 더 쉽게 만들었지만, 협업을 더 쉽게 만들지는 못했습니다. 이 내용이 불편하게 느껴진다면, 이미 여러분은 다음의 네 가지 경고 신호 중 하나(또는 그 이상)에 해당하고 있을 가능성이 있습니다. 이 네 가지 경고 신호는 독립적인 문제가 아니라 하나의 흐름을 이루는 단계입니다. 하나를 경험하고 있는 대부분의 IT 조직은 이미 다음 단계로 이동하고 있습니다. 그리고 그 단계가 깊어질수록 AI 투자와 실제 ROI 사이의 격차는 더욱 커집니다. 1. 개인은 더 빨라지고, 팀은 더 느려진다 이론적으로 AI는 IT에 있어 게임 체인저가 되어야 합니다. 더 빠른 장애 분류, 더 나은 근본 원인 분석, 더 정리된 문서화, 그리고 더 효율적인 변경 관리까지 가능해야 합니다. 하지만 실제로는 많은 IT 리더들이 전혀 다른 현실을 경험하고 있습니다: 개별 구성원은 더 많은 티켓과 문서, 그리고 다양한 “업무 산출물(work artifacts)”을 만들어냅니다. 로컬 수준의 작업은 더 빠르게 처리됩니다. 하지만 엔드투엔드 프로젝트 일정과 서비스 지표는 거의 변화가 없습니다. 이것이 IT에서 나타나는 AI 효율성의 역설입니다: AI는 분절된 시스템 안에서 개별 작업의 속도를 높이지만, 연결된 업무 방식이 없다면 이러한 개선은 조직 전체의 의미 있는 성과로 이어지지 않습니다. AI 도입이 단순히 코드 추천이나 문서 요약 같은 “개인 생산성” 중심의 사용 사례에만 집중되어 있고, 팀 간 업무 흐름을 바꾸지 않는다면, 실제로는 잘못된 대상을 최적화하고 있을 가능성이 높습니다. 팀에서는 다음과 같은 모습으로 나타날 수 있습니다: AI는 깔끔한 PIR(사후 사고 보고서)을 초안으로 작성하지만, incident commander는 이를 읽기 전에 4개의 도구를 오가며 컨텍스트를 찾는 데 40분을 소비합니다. 에이전트는 단순한 티켓 처리량을 두 배로 늘렸지만, 주요 장애의 MTTR은 거의 변하지 않았는데, 그 이유는 핸드오프와 책임 소유가 여전히 불명확했기 때문입니다. 이 지점에 있다면, 잘 되고 있는 것을 단순히 확장하면 해결될 것이라고 생각할 수 있습니다. 하지만 바로 그 접근이 다음 경고 신호를 촉발합니다. 해결책: AI에 목표 맥락 제공 평균 해결 시간(MTTR), 서비스 수준 계약(SLA) 준수율, 고객 만족도(CSAT)와 같은 측정 가능한 성과 지표에서 시작해 이를 AI 도구에 컨텍스트와 기준으로 제공합니다. 조직의 목표를 중앙 컨텍스트 그래프에 통합하면, 각 AI의 동작과 응답은 더 정확해지고 이후 상황을 더 잘 예측할 수 있게 됩니다. 2. 병목은 해결되지 않은 채 옮겨졌다 아마 팀의 작업 속도는 더 빨라졌을 것입니다. 하지만 처리량은 이후 리뷰, 승인, 또는 팀 간 조율 단계에서 다시 병목이 발생하며, 실제 제약이 실행에서 거버넌스와 의사결정으로 이동했음을 보여줍니다. AI는 더 많은 RFC, 변경 요청, PIR, 서비스 요청을 생성하지만, 검토와 승인 워크플로가 여전히 수동적이고 분절되어 있다면 결국 병목은 해결되지 않은 채 옮겨졌을 뿐입니다. 변경 자문 위원회는 AI가 생성한 기록에 파묻히고, 보안 및 리스크 팀은 쏟아지는 요청에 압도되며, 리더십의 인박스에는 AI로 정리된 비즈니스 케이스가 쌓이지만 여전히 실질적인 정합성은 부족한 상태입니다. 팀에서는 다음과 같은 모습으로 나타날 수 있습니다: 변경 요청은 하룻밤 사이 두 배로 늘어나지만, CAB는 여전히 주간 단위로 운영됩니다. 리스크와 영향도가 한 곳에서 보이지 않기 때문에 승인 작업이 며칠씩 쌓이고, 그 사이 출시 일정은 지연되며, 리더들은 AI가 ‘다음번에는 더 빨라질 것’이라고 기대하게 됩니다. 이 시점에서 많은 리더들은 새로운 병목을 해결하기 위해 AI 투자를 더 강화하게 됩니다. 하지만 그 아래에 의도적으로 설계된 워크플로 시스템이 없다면, 이러한 가속은 오히려 더 큰 문제를 만들어냅니다. 해결책: AI로 인한 병목을 고려한 사전 작업 설계 서비스, 소프트웨어, 인프라 전반을 아우르는 하나의 연결된 관점을 정의합니다. 또한 새로운 용량 제약을 고려하기 위해, AI가 생성한 작업(코드, PIR, 지식 베이스 콘텐츠 등)에 대해 사람의 검토가 필요한 지점을 식별합니다. 3. AI는 혼란을 더 키우고 있다 이미 작업이 여러 도구와 팀에 걸쳐 파편화되어 있는 상태에서 AI를 도입하면, 오히려 이러한 파편화가 더 심화될 수 있습니다. 연결되지 않은 시스템 사이를 오가는 콘텐츠와 추천의 양이 증가하면서, 사람들이 올바른 맥락을 찾고 확신을 가지고 행동하기가 더 어려워집니다. 즉, 맥락 없는 AI는 노이즈를 증폭시킵니다. 팀에서는 다음과 같은 모습으로 나타날 수 있습니다: 가상 에이전트는 ‘관련 있어 보이는’ 문서 3개를 제안하지만, 모두 오래된 정보입니다. 엔지니어들은 어떤 런북을 신뢰해야 할지 논쟁하는 동안에도 인시던트 시간은 계속 흘러갑니다. AI가 실패한 것이 아니라, 신뢰해야 할 정보의 기준(source of truth)이 문제였습니다. 조직 내에서 업무가 어떻게 흐르는지, 어떤 시스템이 현재의 단일 정보원(source of truth)을 담고 있는지, 그리고 목표·정책·표준이 어떻게 관리되고 최신 상태로 유지되는지에 대한 명확함 없이 운영된다면, AI는 이미 혼란스러운 워크플로 위에 또 하나의 잡음을 더하는 요소에 불과하게 됩니다. 여기까지 도달했다면, 아마도 불편한 사실 하나를 깨닫기 시작했을 것입니다. 해결책: 조직 맥락을 기반으로 AI 작업 시스템 구성 위키, 파일 공유, 엔터프라이즈 채팅 전반에 걸쳐 조직의 지식을 통합하는 컨텍스트 그래프에 투자하세요. 이를 단일 정보원으로 활용해 런북, PIR, 표준을 최신 상태로 유지하고, KB 문서 및 자산과 연결합니다. 4. AI 이전과 다르지 않은 방식으로 일하는 팀 여기에는 불편한 진실이 있습니다. 앞선 세 가지 경고 신호는 사실 AI 자체의 문제가 아니라 조직의 시스템 문제였습니다. 조직 구조, 승인 체계, 그리고 파편화된 런북(runbook)과 암묵적 지식의 문제입니다. AI가 무언가를 망가뜨린 것이 아니라, 이미 존재하던 균열을 더 이상 무시할 수 없게 만들었을 뿐입니다. 이제 AI는 잘못된 인계, 불명확한 소유권, 그리고 사일로화된 의사결정을 기계의 속도로 그대로 재현하고 있습니다. 더 냉정한 현실은, AI는 맥락이 없는 상태에서는 IT 조직의 기존 파편화를 해결할 수 없다는 것입니다. 서비스, 소프트웨어, 인프라 팀이 서로 단절된 워크플로와 데이터 모델 위에서 운영될 때, AI는 그 단절을 그대로 반영할 뿐 아니라 인시던트, 변경, 프로젝트 업무 전반에서 오히려 이를 증폭시키는 경우가 많습니다. 결과를 바꾸려면 리더들이 먼저 소유권, 거버넌스, 그리고 크로스 툴 통합 구조를 재설계해야 하며, 그래야만 AI가 단순히 파편화를 가속하는 시스템이 아니라, 일관된 시스템을 강화하는 방향으로 작동할 수 있습니다. 팀에서는 다음과 같은 모습으로 나타날 수 있습니다: 여러 도구에 AI를 도입했지만, 목표는 여전히 슬라이드 자료에 머물러 있고 승인 과정은 이메일 인박스에 남아 있습니다. 사람들은 여전히 작년과 같은 플레이북을 따르고 있을 뿐이며, 단지 더 빠르게 움직일 뿐이기 때문에 결과는 달라지지 않습니다. 해결책: AI와 함께 일하는 팀의 업무 방식 재설계 AI의 출력 품질이 향상됨에 따라, 워크플로에서 더 장기적으로 수행되는 작업의 책임자로 AI를 도입하는 방안을 고려해야 합니다. 먼저 팀이 달성하고자 하는 원칙을 정의해야 하며, 여기에는 목표, 결과물의 품질, 그리고 성공 기준이 포함됩니다. 이후 반복적인 실험과 테스트를 통해 AI가 어떤 영역의 작업을 수행할 수 있는지 확인하고, 사람은 검토와 판단을 담당하는 구조로 점진적으로 확장해 나갑니다. 왜 AI만으로는 이러한 문제를 해결할 수 없는가 이 단계에서 자신의 팀이 해당된다고 느낀다면, 이미 그 궤적을 직접 확인한 것입니다. 패턴은 분명합니다. AI는 조직 설계와 워크플로의 파편화를 해결할 수 없습니다. 깨진 시스템 위에 AI를 더 많이 쌓아도 제약 조건은 단지 다른 곳으로 이동할 뿐입니다. 진정한 ROI를 얻기 위해서는 먼저 일하는 방식을 바로잡아야 합니다. 이 지점에서 연결된 시스템 오브 워크(System of Work)를 구축하는 것이 핵심이 됩니다. Atlassian의 System of Work는 기술 팀과 비즈니스 팀을 연결해 업무 속도를 높이고 임팩트를 극대화하도록 돕는 데이터 기반 철학입니다. 이는 네 가지 원칙을 기반으로 합니다. 목표에 맞춰 업무를 정렬 함께 업무를 계획하고 추적 집단 지식 활용 AI를 팀의 일부로 포함 IT 리더들이 이러한 원칙을 적용하면, AI와 협업 도구는 더 이상 개별적인 포인트 솔루션에 머무르지 않고, 성과 중심으로 조정된 통합된 시스템의 일부가 됩니다. 경고 신호를 로드맵으로 전환하기 이 원칙들이 함께 적용되면 이러한 경고 신호는 실행 계획으로 전환됩니다. 실질적인 AI 투자 성과를 내고 있는 조직들은 더 좋은 도구를 구매하는 것에서 시작하지 않았습니다. 대신 팀 간 업무 흐름을 재설계하는 것에서 출발했습니다. 무엇이 이들을 다르게 만드는지 알고 싶으신가요? AI Collaboration Index https://www.atlassian.com/blog/ai-collaboration-report-2025는 상위 4% 조직이 무엇을 다르게 하는지, 그리고 AI 투자와 실제 영향 사이의 격차를 어떻게 줄일 수 있는지를 설명합니다.

2026/05/20

Rovo로 만드는 협업형 AI 캔버스 구축기

출처: Creating with Rovo: How We Built a Collaborative AI Canvas https://www.atlassian.com/blog/how-we-build/rovo-creation-canvas 작성자: Alex Knight (Sr. Principal Engineer) Abhi Kishore 발행일: 2026년 04월 06일 Rovo는 플랫폼의 핵심에 있는 핵심 AI 솔루션입니다. Teamwork Graph https://www.atlassian.com/platform/teamwork-graph를 통해 Confluence, Jira 및 연결된 앱과 같은 도구 전반에서 내부 및 외부 지식을 검색하고, 필요한 정보를 적절히 찾아 제공합니다. 또한 Jira 이슈부터 Confluence 페이지까지 생태계 전반의 객체를 생성하고 상호작용할 수도 있습니다. 하지만 Rovo에는 아직 완전한 기능을 갖춘 생성 캔버스가 없었습니다: 사람과 AI가 함께 실시간으로 콘텐츠를 공동 생성하고, 반복적으로 개선하며, 정교하게 다듬을 수 있는 협업 공간이 부족했던 것입니다. 이러한 공백이 “Creating content with Rovo https://support.atlassian.com/confluence-cloud/docs/create-new-content-items-with-rovo/”의 출발점이 되었습니다. Rovo로 창작한다는 핵심 아이디어는 단순합니다: 콘텐츠 생성은 AI와 사용자의 협업이어야 하며, 한쪽이 다른 쪽에 작업을 넘기는 방식이어서는 안 된다는 것입니다. 이 글에서는 Rovo를 활용한 콘텐츠 생성의 내부 과정을 살펴보고, 다음 내용을 다룹니다: 이를 왜 협업형 AI 캔버스로 설계했는지, 그리고 왜 단발성 작성 도구(one-shot writer)가 아닌지를 설명합니다. 페이지, 화이트보드, 데이터베이스 등 다양한 콘텐츠 유형을 안정적으로 처리하는 방법을 다룹니다. ADF, SVG, CSV 기반 스키마에 대한 기술적 설계 선택을 설명합니다. Rovo가 풍부한 콘텐츠를 안전하게 생성하고 실시간으로 편집할 수 있도록 하는 스트리밍 인프라 구조를 소개합니다. 핵심 원칙 우리는 단일 제품 안에 고립된 독립형 AI 작성 도구를 만들고자 하지 않았습니다. Rovo로 콘텐츠를 만드는 기능은 Confluence에서 시작할 수 있지만, 본질적으로 Rovo 위에서 네이티브하게 구축되어 있으며 모든 Rovo 환경에서 접근할 수 있습니다. 콘텐츠 생성은 채팅 경험의 자연스러운 확장처럼 느껴져야 합니다. 사용자는 하나의 대화 안에서 질문하고, 페이지를 공동 작성하고, 화이트보드를 반복적으로 개선하며, 데이터베이스를 정교하게 다듬을 수 있습니다. 이 모든 과정은 동일한 컨텍스트를 이해하는 동일한 AI와 함께 이루어집니다. 그 결과 몇 가지 핵심 설계 원칙이 도출되었습니다: 생성은 채팅 안에서 이루어집니다. 콘텐츠는 Rovo 채팅 내 캔버스에서 시작되며, 원하는 상태가 되면 적절한 공간이나 제품 영역으로 이동할 수 있습니다. 이는 기능이 아니라 플랫폼입니다. 처음부터 이 캔버스는 페이지, 화이트보드, 데이터베이스 등 다양한 콘텐츠 유형을 지원하도록 설계되었으며, 다른 제품으로 확장될 수 있도록 만들어졌습니다. Jira 작업 항목을 위한 Create with Rovo 기능은 최근 EAP로 출시되었으며 동일한 패턴을 따릅니다. 실시간 스트리밍 사용자는 콘텐츠가 생성되고 편집되는 과정을 실시간으로 확인할 수 있습니다. 이를 통해 협업은 단순한 “생성 후 붙여넣기”가 아니라 살아 있고 반복적으로 발전하는 경험이 됩니다. 기술 구현 https://atlassianblog.wpengine.com/wp-content/uploads/2026/04/cwr-architecture_-high-level-overview--768x656.jpg 상위 수준에서 보면, Rovo의 백엔드는 상위 오케스트레이터(Orchestrator) 에이전트를 중심으로 구성되어 있으며, 이 에이전트는 여러 전문 스킬에 접근할 수 있습니다. 여기에는 크로스 프로덕트 검색(서드파티 제품 포함), Teamwork Graph 검색, Jira 조회 에이전트 등이 포함됩니다. 오케스트레이터는 사용자의 의도에 따라 이러한 스킬들을 호출합니다. Rovo 기반 콘텐츠 생성을 지원하기 위해, Confluence 전용 생성 및 편집 스킬을 도입했습니다. 이는 다음 역할을 수행하도록 설계된 목적 특화 에이전트입니다: 사용자의 의도를 이해하고, 적절한 콘텐츠 유형과 템플릿을 선택하며, 다운스트림 시스템이 신뢰할 수 있는 구조화된 콘텐츠를 생성합니다. 이 에이전트는 독립적으로 동작하지 않습니다. Rovo의 전체 컨텍스트를 그대로 상속하며, 여기에는 대화 기록, 연결된 지식 소스, 관련 작업 항목이 포함됩니다. 사용자는 Rovo에게 다음과 같이 요청할 수 있습니다: “Q3 목표를 기반으로 프로젝트 계획을 생성해줘” 그러면 에이전트는 문서를 생성하기 전에 Teamwork Graph에서 적절한 컨텍스트를 먼저 가져옵니다. LLM을 활용한 Confluence 콘텐츠 생성 Confluence 콘텐츠 유형은 각각 서로 다른 내부 표현 방식과 제약 조건을 가지고 있습니다: 페이지는 깊은 중첩을 가진 리치 노드 기반 구조를 사용합니다. 화이트보드는 공간 기반 레이아웃과 시각 요소에 의존합니다. 데이터베이스는 스키마와 뷰를 갖춘 테이블 중심 구조입니다. 품질을 극대화하기 위해 우리는 각 콘텐츠 유형에 맞는 적절한 모델과 출력 형식을 찾아야 했습니다. 이를 위해 다양한 LLM과 포맷에 대해 평가를 수행했고, 결국 각 유형에 따라 서로 다른 접근 방식을 적용하게 되었습니다. 이 과정에서는 최신 프론티어 LLM의 역량에 대한 예상치 못한 인사이트도 얻을 수 있었습니다. 페이지 / 라이브 문서 페이지의 경우, 다음과 같은 요구사항이 있었습니다: 패널, 상태, 복잡한 테이블, 매크로 등 다양한 리치 텍스트 요소를 지원하고 편집 과정에서 서식이 손실되지 않도록 합니다 페이지 생성의 경우, LLM이 ADF(중첩 JSON)를 직접 생성하도록 하고, 이를 전용 ADF 복구 라이브러리를 통해 처리합니다. 이 라이브러리는 다음과 같은 역할을 합니다: 일반적인 LLM 출력 문제(유효하지 않거나 스키마를 준수하지 않는 JSON)를 처리하고 에디터에 도달하기 전에 ADF 스키마 준수를 보장합니다 페이지 편집의 경우, LLM이 ADF를 조작할 수 있도록 에디터 스타일의 소규모 명령 집합을 정의했습니다. 예를 들어 다음과 같습니다: replaceNode (노드 교체) insertNodeAfter (특정 노드 뒤에 노드 삽입) removeNode (노드 삭제) 각 도구 호출 내에서 LLM은 ADF를 값으로 생성합니다. 편집은 반성(reflection)을 포함한 에이전틱 루프(agentic loop)로 실행되며, 이는 Atlassian 문서에 특화된 코딩 에이전트와 유사하게 동작합니다. 화이트보드 화이트보드는 공간 기반 레이아웃과 시각적 의미 구조로 인해 또 다른 수준의 복잡성을 가집니다. 다음과 같은 여러 출력 형식을 평가했습니다: HTML + CSS WDF (화이트보드 문서 형식 – 내부 JSON 저장 표현 방식) WDF 위에 구축된 DSL 직접적인 도구 호출 콘텐츠 생성 평가를 위해 대규모 데이터셋을 구축했으며, 사람과 LLM이(출력 스크린샷을 기반으로) 결과를 평가하도록 했습니다. 평가는 시각적 요소, 연결 구조 및 그룹화, 레이아웃 품질을 중심으로 이루어졌습니다. 또한 데이터를 파싱하고 스트리밍할 수 있는 능력도 의사결정에 영향을 주었습니다. 최종적으로 SVG가 가장 우수한 선택으로 결정되었습니다. LLM은 방대한 데이터로 학습됩니다. SVG가 사람들이 무한 캔버스 보드를 사고하는 방식(도형, 텍스트, 위치)과 가장 밀접하게 대응되며, LLM이 안정적으로 생성하고 이해할 수 있는 표현 방식이라는 점을 확인했습니다. 화이트보드의 경우, 다음과 같은 요구가 있었습니다: 새로운 보드를 생성할 때 SVG 문서를 생성한 다음, 이를 네이티브 화이트보드 요소로 변환합니다. 이는 거의 SVG를 가져오는(import) 것과 같은 방식입니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/04/image-20251218-065756-1-300x244.png <svg viewBox="0 0 1200 800" xmlns="http://www.w3.org/2000/svg" Haiku Cherry blossoms fall Soft petals dance on the breeze Spring whispers goodbye 5 - 7 - 5 syllables ]]> LLM이 생성한 청크를 실시간으로 처리하는 과정은 스트리밍 SVG 파서와 제약 조건 해결 알고리즘을 함께 사용해 이루어지며, 요소의 포함 관계를 보장하고 레이아웃 겹침을 해결합니다. 이를 통해 사용자는 화이트보드가 실시간으로 “조립되는” 과정을 볼 수 있습니다. 편집의 경우, 다음과 같은 작업을 수행합니다: 현재 보드의 SVG 표현을 LLM에 제공하며, 라인 번호가 포함됩니다. 또한 다음과 같은 도구들을 제공합니다: delete_svg insert_svg replace_svg (라인 기반) update_elements_svg (ID 기반) LLM이 변경 작업을 수행하기 전에 계획을 먼저 정리할 수 있도록 특별한 todo_list 도구를 도입했습니다. 이 단순한 패턴은 복잡한 다단계 편집 작업의 품질을 크게 향상시켰습니다. <todo_list> 모든 스티키 노트를 빨간색으로 변경 모든 스티키 노트를 왼쪽으로 이동 아래에 빨간 스티키를 더 생성 </todo_list> 편집 예시 출력 – TODO 리스트가 항상 먼저 나옵니다. 데이터베이스 데이터베이스는 LLM이 스키마, 뷰, 데이터의 세 개의 CSV로 생성하며, 이를 XML 태그로 감싸 구성됩니다. 이를 통해 스키마, 프레젠테이션(표현), 데이터가 명확하게 분리되고, 스트리밍되는 과정에서도 파싱 가능한 상태로 유지됩니다. 생성 과정에서는 모델이 항상 XML 태그로 감싸진 세 개의 CSV 섹션을 생성합니다: <fields> – 스키마 정의: field_name, type, depends_on, configuration <views> – 뷰 설정: view_name, layout, filters, sorts, hidden_fields <data> – 정의된 필드에 맞는 샘플 행 편집 시에는 모델이 이 표현 방식의 데이터베이스와 사용자의 선택을 함께 입력으로 받고, 그 결과로 두 개의 CSV를 출력합니다: 메타데이터 변경 – 스키마, 뷰, 필터, 정렬 데이터 변경 – 행 추가/수정/삭제 이러한 CSV의 각 행은 하나의 선언적 변경을 나타내며, 이를 다운스트림 코드가 안정적으로 파싱하고 적용할 수 있습니다. 생성된 콘텐츠를 클라이언트로 스트리밍하기 LLM이 무엇을 생성해야 하는지를 결정하는 것은 문제의 절반에 불과했습니다. 나머지 절반은 해당 출력을 프론트엔드로 전달하는 것이었으며, 이는 점진적으로, 실시간으로, 그리고 여러 렌더링 표면에 걸쳐 이루어져야 했습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/04/image-20260331-103036-720x382.png Rovo 채팅 / Rovo 캔버스 내 콘텐츠 iFrame 통신 Canvas는 전사적으로 공통으로 사용되는 Rovo Chat 플랫폼 컴포넌트를 활용합니다. 단순한 미리보기(preview)를 따로 구현하는 대신, Confluence 메인 경험에서 사용하는 것과 동일한 컴포넌트를 사용해 콘텐츠를 렌더링하며, 이를 iframe에 임베딩합니다. 이를 통해 Canvas는 Confluence의 콘텐츠 객체와 동일한 수준의 기능적 동등성(feature parity)을 갖게 됩니다. 이를 지원하기 위해 LLM 액션을 위한 새로운 스트리밍 API 계약을 정의했습니다: LLM API는 생성되는 동안 부분 결과를 스트리밍으로 전송합니다. 프론트엔드는 이러한 부분 청크를 수집합니다. 그리고 렌더링이 필요한 콘텐츠 객체에 업데이트를 반영합니다. 프론트엔드 컴포넌트는 이를 통해 스트리밍 형태의 사용자 경험을 제공합니다. 이 기능은 Rovo가 지원하는 모든 환경에서 동작해야 합니다. Rovo Canvas 내의 생성/편집에서도, Rovo를 통해 Confluence 콘텐츠를 직접 편집할 때와 동일한 명령을 사용했습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/04/image-20260331-110119-720x394.png Rovo Chat을 통한 Confluence 일반 콘텐츠 편집 iFrame 내부에서 사용자는 텍스트를 선택하고 편집을 요청할 수 있으며, 해당 요청은 iFrame 외부에 있는 Rovo Chat 컴포넌트를 통해 실행되어야 합니다. 따라서 채팅과 콘텐츠 객체 간 양방향 통신 채널(bidirectional communication channel)이 필요하다는 점이 명확해졌습니다: 동일 origin 및 cross-origin 환경에서 서로 다른 JavaScript 컨텍스트 간에도 전송 계층 세부 사항이 애플리케이션 코드로 노출되지 않도록 그 결과 Rovo Bridge API가 탄생했습니다. 이는 로컬 함수 호출을 통해 서로 다른 애플리케이션이 통신할 수 있도록 하는 라이브러리이며, 그 과정에서 하위 전송 계층은 추상화됩니다. 내부 동작 구조: 전송 계층 추상화(Transport abstraction)는 데이터가 실제로 어떻게 전달될지를 결정합니다: BrowserTransport (postMessage 기반) DesktopTransport (Electron IPC 기반) 그리고 향후 더 추가될 다양한 방식들 명령은 강한 타입 시스템을 갖춘 Command 패턴을 따르며, 안전성을 보장합니다. 각 명령에는 추적성과 보안을 위해 sender 및 receiver 메타데이터가 포함됩니다. 데이터는 선택된 전송 계층 위에서 JSON-RPC 스펙(JSON-RPC 2.0 Specification https://www.jsonrpc.org/specification )을 기반으로 교환됩니다. 평가 및 모니터링 오프라인 평가(offline eval)는 모든 콘텐츠 유형에 걸친 대규모 데이터셋을 활용해 매일 수행되었습니다. 이 과정에서는 스크린샷 기반의 새로운 평가 방식을 사용했으며, LLM 평가자가 작업 완료 여부뿐 아니라 시각적 품질, 톤, 지식 정확성까지 평가하도록 했습니다. 또한 결과는 항상 사람의 피드백을 기준선으로 삼아 비교되었습니다. 온라인 평가는 실제 고객 및 내부 트래픽에서 성공률과 작업 완료 지표를 추적하여, 고정된 데이터셋과 분리된 현실 세계의 신호를 제공합니다. 실시간 안정성과 품질 모니터링을 위해 자동화된 헬스 체크가 구축되었으며, 에이전틱 플로우(agentic flows)가 올바르게 동작하는지를 검증했습니다. 단순히 상위 API 호출 성공 여부가 아니라, 적절한 서브 에이전트, 도구, 콘텐츠 액션이 정확히 호출되는지를 확인합니다. 이와 더불어 광범위한 신뢰성 모니터링 대시보드와 SLO가 운영되며, 급격한 에러 스파이크와 성능 저하를 감지하는 탐지 시스템도 포함되어 있습니다. 결론 AI를 위한 시스템을 구축하려면 사고방식의 전환이 필요합니다. 업계는 매우 빠르게 변화하고 있으며, 코드·프롬프트·모델 역시 지속적으로 빠르게 진화할 것입니다. 그러나 견고한 평가(evaluation) 체계, 온라인 실험을 위한 정교한 메트릭, 그리고 포괄적인 신뢰성 모니터링이 있어야만 빠른 반복을 안정적으로 수행할 수 있습니다. Rovo를 활용한 콘텐츠 생성은 새로운 기반 경험이며, 향후 Confluence AI 기능의 핵심 구성 요소로 확장될 것입니다. 이는 시작에 불과합니다.

2026/05/04

Claude Code Security에 대한 생각: AI는 기존 보안 분석을 대체할 수 있을까?

Claude Code Security와 SonarQube의 역할 구분 AI 코딩 도구의 활용이 빠르게 확산되면서, 이제는 “AI가 코드를 얼마나 잘 작성하는가”뿐 아니라 “AI가 만든 코드를 얼마나 신뢰할 수 있는가”가 중요한 질문이 되고 있습니다. 최근 Anthropic은 Claude Code Security를 발표했습니다. Claude Code Security는 AI 모델을 활용해 코드베이스를 스캔하고, 메모리 손상, 인젝션 결함, 인증 우회와 같은 고위험 취약점을 식별하며, 발견된 이슈에 대한 패치까지 생성하는 research preview 형태의 도구입니다. SonarSource는 이 도구를 기존 보안 도구를 대체하는 솔루션이라기보다, AI 기반 보안 연구자에 가까운 개념으로 설명합니다. 즉, 모든 코드를 체계적으로 검증하는 도구가 아니라, 기존 도구가 놓칠 수 있는 복잡하고 중요한 취약점을 탐색하는 보완적 역할에 가깝다는 것입니다. Claude Code Security는 무엇인가요? Claude Code Security는 Anthropic https://www.anthropic.com/ 에서 개발한 연구용 프리뷰 버전 으로, AI 모델을 사용하여 코드베이스를 스캔하고 메모리 손상, 인젝션 결함, 인증 우회와 같은 심각도가 높은 특정 취약점을 식별하고 발견된 문제를 패치합니다. SonarSource는 Anthropic이 발표한 내용은 에이전트형 보안 연구원과 유사하다고 말합니다. 보안 연구팀이나 윤리적 해커를 고용하거나 애플리케이션의 취약점을 찾는 버그 바운티 프로그램을 운영하는 등 다양한 기법을 활용하는 것이 오랫동안 최선의 방법으로 여겨져 왔습니다. 이러한 접근 방식은 SAST 및 DAST를 포함한 다른 사이버 방어 체계를 보완하여 일반적으로 간과되는 문제를 찾아냅니다. Claude Code Security는 메모리 손상, 인젝션 취약점, 인증 우회, 복잡한 논리 오류 등 패턴 매칭 도구가 일반적으로 놓치는 심각도가 높은 취약점에 집중합니다. 일단 문제를 발견하면, 적대적 검증이라는 기술을 사용하여 문제가 실제로 존재하는지 확인한 다음, 식별된 문제를 해결하기 위한 패치를 생성합니다. 에이전트 기반 보안 연구는 코드베이스 및 애플리케이션 보안을 전반적으로 개선하는 데 큰 가능성을 보여줍니다. 보안 연구원들의 노력을 증폭시키고 ( 현재 베타 버전으로 제공되는 SonarQube Remediation Agent https://www.sonarsource.com/blog/join-the-sonarqube-remediation-agent-beta 와 유사하게 ) 문제 해결의 마지막 단계를 해결함으로써 시너지 효과를 창출합니다. 기존 기술과 함께 사용하면 더욱 건전하고 안전한 코드베이스를 구축할 수 있을 것으로 기대합니다. Anthropic은 제품 설명에서 "Claude Code Security는 기존 도구가 놓칠 수 있는 부분을 찾아내고 문제 해결의 고리를 완성함으로써 기존 도구를 보완합니다."라고 설명합니다. SonarQube와 Claude Code Security의 역할은 무엇가요? SonarQube는 모든 코드를 체계적으로 평가합니다. 반면, Claude Code Security는 샘플링 기반의 부분 검사 방식을 사용합니다. SonarQube는 정의된 문제 세트를 일관되고 반복적으로 평가하여 검토가 완료되었음을 보장합니다. 반면, Claude Code Security는 전체 코드에 대한 일관된 검증보다는, 발견 가능성이 있는 고위험 취약점을 찾아내는 탐색형 접근에 가깝습니다. SonarQube는 단순한 패턴 매칭을 넘어 데이터 흐름과 같은 복잡한 문제를 평가하는 정교한 수학적 추론 기법을 사용합니다. 이 모든 것을 업계 최저 수준의 오탐률(false positive rate)을 유지하면서 구현합니다. 반면 Claude Code Security는 오류에 취약한 확률적 추론 기법을 사용하고, 토큰 소모가 심하고 편향적이며 신뢰도가 낮은 LLM 기반 검증 기법을 사용합니다. 즉, 두 도구는 매우 다르지만 상호 보완적인 역할을 합니다. SonarQube: 엄격하고 일관성 있으며 빠르고 저렴한 코드 검토 및 검증 Claude Code Security: 드물지만 가치가 높은 취약점을 찾아내는 기회주의적 접근 방식. SonarQube의 접근 방식은 모든 코드 라인이 신뢰성과 유지 관리성에 대한 정의된 표준을 충족하도록 보장하는 동시에 오픈 소스 종속성에 대한 알려진 취약점 및 라이선스 위험을 모니터링합니다. 이 방법론은 결정론적이고 일관성이 있습니다. 동일한 코드를 입력하면 매번 동일한 결과가 나옵니다. 또한 포괄적입니다. 코드베이스 전체를 검사하며, 특정 부분만 선별적으로 검사하는 것이 아닙니다. 마지막으로, 설명이 가능합니다. 문제가 발생하면 어떤 규칙이 어떤 이유로 적용되었는지 정확하게 확인할 수 있습니다. 이는 몇 가지 실질적인 이유로 중요합니다. 감사자와 규정 준수 체계는 코드 점검이 이루어졌다는 일관되고 반복 가능한 증거를 요구합니다. 개발팀은 코드 병합 전에 IDE 내에서, CI/CD 파이프라인의 일부로, 일반적인 워크플로에서 바로 활용할 수 있는 결과를 필요로 합니다. 보안 범위는 자체 코드뿐만 아니라 오픈 소스 종속성, 인프라 구성, 그리고 실수로 커밋되었을 수 있는 기밀 정보까지 포함해야 합니다. 두 도구의 차이 구분 SonarQube Claude Code Security 주요 목적 체계적인 코드 검증 및 리뷰 스팟 체크와 취약점 발견 분석 범위 전체 코드베이스, 모든 코드 라인, 매 스캔 기회주의적 접근, 포괄적 검증 보장 아님 일관성 결정론적. 같은 코드에 같은 결과 확률적. 실행마다 결과가 달라질 수 있음 오탐률 약 3%로 제시 알려지지 않음. LLM은 오탐을 낼 수 있음 설명 가능성 각 발견 사항에 명확한 룰 참조 제공 AI 추론 기반으로 감사가 어려울 수 있음 컴플라이언스 활용 감사자와 규제기관에 수용 가능한 근거 제공 현재 단독 컴플라이언스 근거로는 적합하지 않음 속도와 비용 빠르고 예측 가능한 비용 느리고 토큰 소비가 큼 도입 현황 700만 명 이상 사용자, CI/CD 워크플로우 및 주요 AI 코딩 도구와 통합 현재 research preview, Claude Code에서만 사용 가능 보안 체계는 하나의 도구만으로 완성되지 않는다 보안에 가장 민감한 조직들은 다양한 도구 포트폴리오에 의존합니다. 일반적인 성숙한 보안 관행은 이미 여러 계층의 방어 체계를 결합하고 있는데, 단 하나의 방법으로는 모든 것을 차단할 수 없기 때문입니다 대표적인 계층은 다음과 같습니다. 개발 워크플로우에 통합된 자동화 코드 분석 SAST, SCA, secrets, IaC 분석 등이 여기에 포함됩니다. 특정 취약점 유형을 위한 전용 보안 테스트 도구 아키텍처와 설계를 검토하는 내부 보안팀 기존 체계가 놓친 문제를 찾는 외부 보안 연구자 또는 버그 바운티 프로그램 SonarSource는 Claude Code Security가 이 중 네 번째 범주에 자연스럽게 들어간다고 설명합니다. 즉, AI 기반 보안 연구자로서 코드베이스를 대상으로 잠재적인 취약점을 선제적으로 탐색하는 역할입니다. 따라서 중요한 질문은 “어떤 도구를 사용할 것인가”가 아니라, “각 보안 계층이 무엇을 커버하고 있으며, 어디에 공백이 있는가”입니다. 애플리케이션 보안의 다음 진화 단계 AI 기반 보안 리서치 도구의 등장은 업계에 긍정적인 변화입니다. 맥락적 추론이 필요한 취약점, 즉 특정 코드가 원래 어떤 동작을 해야 하는지 이해하고, 그 의도가 어디에서 깨지는지를 찾아내는 작업은 그동안 숙련된 보안 연구자의 영역에 가까웠습니다. 이러한 역량을 더 쉽게 활용하고, 더 넓은 범위로 확장할 수 있게 만드는 것은 분명 가치 있는 일입니다. 다만. AI 리서치 도구를 흥미롭게 만드는 특징은 동시에, 이 도구들이 체계적인 코드베이스 분석을 대체하기에는 적합하지 않은 이유이기도 합니다. AI 리서치 도구는 모든 것을 빠짐없이 검사하지 않습니다. 실행할 때마다 항상 같은 결과를 보장하지도 않습니다. 또한 컴플라이언스 프레임워크가 요구하는 구조화되고 감사 가능한 증거를 제공하지도 못합니다. 앞으로의 애플리케이션 보안은 이 두 계층이 함께 강화되는 방향으로 발전할 가능성이 높습니다. 결정론적이고 포괄적인 스캐닝은 검증 계층을 담당합니다. 즉, 알려진 모든 유형의 취약점이 전체 코드에 걸쳐 지속적으로 확인되었는지를 보장하는 역할입니다. 반면 AI 보조 리서치는 탐색 계층을 담당합니다. 규칙만으로는 미리 예측하기 어려운 문제를 찾아내는 역할입니다. 이 두 접근 방식은 함께 사용될 때, 어느 한쪽만 사용할 때보다 더 넓은 보안 범위를 다룰 수 있습니다. Claude Code Security는 스팟 체크 도구입니다. SonarQube는 포괄적인 감사 및 검증 플랫폼입니다. 각 도구에는 각자의 역할이 있습니다. 요약: SonarQube의 체계적인 코드베이스 분석은 SAST, SCA, 시크릿, IaC를 포함하며, 수학적 추론을 활용해 전체 코드베이스에 대해 포괄적이고 일관되며 감사 가능한 커버리지를 제공합니다. 이는 보안 실무 기반이 됩니다. AI 보조 보안 리서치는 규칙만으로는 예측하기 어려운, 특정 맥락에 따라 발생하는 취약점을 찾아냅니다. 이는 지금까지 인간 보안 연구자와 버그 바운티 프로그램이 수행해 온 역할과 같습니다. 따라서 이 두 역량은 경쟁 관계가 아니라 상호 보완 관계입니다. 가장 강력한 보안 체계는 두 가지를 함께 활용하는 것입니다. 컴플라이언스 요구사항, 규제 의무, 또는 일관된 보안 커버리지를 입증해야 하는 팀에게는 체계적인 코드 분석이 여전히 필수적입니다. 그리고 이는 research preview 단계의 도구로 대체될 수 없습니다. Anthropic은 실제로 유용한 도구를 만들었습니다. 다만 이 도구의 효과를 가장 크게 얻을 수 있는 팀은 이미 탄탄한 체계적 코드 분석 기반을 갖춘 팀이라고 볼 수 있습니다. 바로 그 기반이 있어야 AI 보조 리서치가 가장 효과적으로 작동하는 데 필요한 맥락을 제공할 수 있기 때문입니다. 출처: SonarSource, “Thoughts on Claude Code Security” by Manish Kapur https://www.sonarsource.com/blog/thoughts-on-claude-code-security/ https://www.sonarsource.com/blog/thoughts-on-claude-code-security/?utm_source=chatgpt.com

2026/04/29

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

안녕하세요, 커브입니다. 따뜻한 봄기운이 완연한 4월입니다. 이번 뉴스레터에서는 AI 에이전트 확산에 따라 커지고 있는 공급망 보안 이슈와 SonarQube 운영 고도화 포인트를 간단히 정리해 전해드립니다. 빠르게 변하는 개발 환경 속에서 어떤 부분을 더 살펴봐야 할지 함께 확인해보시기 바랍니다. 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 Jira Cloud 전체/삭제/보관 스페이스 확인하기 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893cf3bf92388b361f54caa1d9b495b0dd6f JFrog로 엔터프라이즈 소프트웨어 운영 효율화 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893ca0eac6041f8427b2caa1d9b495b0dd6f SonarQube Rules 심각도(Severities) 기준 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893c6def55f8c4f0ba15caa1d9b495b0dd6f SonarQube / SonarScanner Memory 설정하기 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893c5c72ecd0cdd49560caa1d9b495b0dd6f Rovo Chat 사용 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893c03e81b051bb318efcaa1d9b495b0dd6f SonarQube Server 2026.2 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893c43572ccde1ab5287caa1d9b495b0dd6f SonarQube Server 온라인 라이선스 관리 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893c6751f1c7b609d24ecaa1d9b495b0dd6f 사이버 복원력 법안(CRA)과 JFrog 플랫폼 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893ca9201a3a9967ca08caa1d9b495b0dd6f CURVC JSM Cloud 고객 가이드 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893c858df15698088f5fcaa1d9b495b0dd6f Jira Cloud에서 성능 저하 감지하고 대응하는 방법 https://link.email.unifyr.com/c/103/10c39e4daa17d28d48eecb0bedacee5d88e1d5a985d7893c614dfc58b428ffb1caa1d9b495b0dd6f 04 2.png https://confluence.curvc.com/spaces/ASD/blog/2026/04/16/317227164/%EA%B3%B5%EA%B8%89%EB%A7%9D+%EA%B3%B5%EA%B2%A9%EC%9D%98+%EC%83%88%EB%A1%9C%EC%9A%B4+%ED%83%80%EA%B9%83+%EB%8B%B9%EC%8B%A0%EC%9D%98+%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8+%EB%8A%94+%EC%95%88%EC%A0%84%ED%95%A9%EB%8B%88%EA%B9%8C 04 3.png https://confluence.curvc.com/spaces/ASD/pages/287244899/SonarQube+Community+Build%EB%A5%BC+%EC%97%85%EA%B7%B8%EB%A0%88%EC%9D%B4%EB%93%9C%ED%95%B4%EC%95%BC+%ED%95%98%EB%8A%94+%EC%9D%B4%EC%9C%A0

2026/04/23

Jira Cloud에서 성능 저하를 대규모로 감지하고 대응하는 방법

출처: 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개 테넌트에서 관리자 사용자에게만 해당되는 특정 엔드포인트)에만 영향을 미치는 경우가 많습니다. 이처럼 영향 범위가 매우 제한적이기 때문에 문제를 발견하기도 어렵고, 원인을 파악하는 것은 더 까다롭습니다. 이번 글에서는 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는 수백만 개의 테넌트를 지원하며, 각 테넌트는 다양한 형태를 가질 수 있습니다: 데이터 형태(이슈 수, 필드 설정, 변경 이력 등) 트래픽 패턴(변동이 큰 트래픽 vs 안정적인 트래픽, 글로벌 팀 vs 로컬 팀) 애드온 및 구성 네트워크 환경 및 클라이언트 하드웨어 이러한 차이들로 인해 성능은 테넌트별뿐만 아니라 프로젝트별로도 크게 달라집니다. 대부분의 테넌트(99.99%)에서는 문제가 되지 않는 변경이라도, 규모나 사용 패턴이 극단적인 일부 테넌트(0.01%)에는 크게 영향을 줄 수 있습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/02/image-20260115-062440-720x291.png 상위 10,000 개 고객에서 하나의 백엔드 엔드포인트 지연 시간 변동 끊임없는 변경 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 문제 2가지: 임계값보다 성능이 지속적으로(또는 항상) 낮은 테넌트는 계속해서 알림이 발생합니다. 성능이 “매우 좋은 상태”(임계값보다 훨씬 낮은 수준)에서 “좋은 상태”(임계값보다 약간 낮은 수준)로 떨어진 테넌트는 알림이 전혀 발생하지 않습니다. 임계값을 매우 높게 설정하거나(성능이 가장 낮은 테넌트보다 높게), 또는 매우 낮게 설정하면(가장 빠른 테넌트보다 높게), 이 문제들 중 하나는 해결할 수 있지만, 고정 임계값만으로는 두 가지를 동시에 해결할 수는 없습니다. 설정한 기준 따라서 이번 프로젝트의 목표는 다음과 같습니다: 전체 지표에는 문제가 없어 보이더라도, 특정 백엔드 엔드포인트에서 개별 테넌트나 소규모 테넌트 그룹의 성능 저하를 감지하는 것 이를 위해 다음 세 가지가 필요합니다: 대규모 환경에서 수집되는 테넌트별·엔드포인트별 지표 각 테넌트의 과거 데이터와 비교하는 감지 파이프라인 “무언가 느려졌다”는 사실을 바탕으로 “유력한 원인”을 빠르게 파악하는 방법 탐지부터 대응까지: 하나의 성능 회귀 사례 전 과정 구체적인 사례를 통해, 실제 운영 환경에서 발생한 성능 회귀를 살펴보겠습니다: 집계된 지표로는 감지되지 않았던 백엔드 성능 저하를 탐지 담당 팀에 알림 전달 문제의 원인이 된 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를 다시 비활성화했습니다. 조사 계획에는 일반적으로 몇 가지 단계(코드 배포, 데이터베이스 메트릭 등)가 더 포함되지만, 이번 사례에서는 필요하지 않았습니다. 이를 통해 배운 점 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 팀들이 전반적인 성능 개선을 지속적으로 추진하는 만큼, 이 시스템 역시 이에 발맞춰 성능 회귀를 조기에 탐지하고, 이를 명확하게 설명하며, 팀이 이를 해결할 수 있는 직접적인 경로를 제공하는 것을 목표로 합니다.

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) 컴포넌트와 토큰을 기반으로 구성되었으며, 접근성을 준수하고 기존 코드베이스 패턴을 따릅니다. 브랜치: 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 개발의 미래는 개발자를 대체하는 것이 아니라, 디자인과 코드 사이의 번거로운 변환 과정을 줄여 개발자가 실제로 중요한 판단에 집중할 수 있도록 하는 것입니다.

- Others -

Contributor

사용자	수정	댓글	레이블
설진호 이사	1269	39	414
황희연 대표	682	12	13
이지혜 선임	680	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 -**