CURVC DevOps Confluence

안녕하세요, 커브입니다. 현대 소프트웨어 개발 환경에서는 다양한 아티팩트와 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 AI가 바꾸는 서비스 관리의 미래 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38d8dbb3b541982cacacaa1d9b495b0dd6f SonarQube AI 기능 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38de559d5c1a8eeaf23caa1d9b495b0dd6f Atlassian Cloud 계정 관리자 접근 권한 부여하기 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38d2ae17731db032492caa1d9b495b0dd6f SonarQube Windows 설치 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38d7df65d90e0f9541dcaa1d9b495b0dd6f Atlassian Intelligence(AI) 안내 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38dad4e06900bc85931caa1d9b495b0dd6f Sonar: 2026 Gartner® Magic Quadrant™ 기술 부채 관리 도구 부문 Leader 선정 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38d35648f76e826ad66caa1d9b495b0dd6f Content Assistant가 디자인 품질 기준을 높인 방법 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38df724544dcd2ffa3ccaa1d9b495b0dd6f AI에게 디자인 언어를 학습시키기 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38d6270a1f8c614a95ecaa1d9b495b0dd6f AI 에이전트와 Jira로 엔지니어링 "반복 업무"줄인 방법 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38d6889c4b8eca9c2d3caa1d9b495b0dd6f SonarQube Cloud Team Plan에 SAS 제공 발표 https://link.email.unifyr.com/c/103/10c39e4daa17d28df1d9a04f9d91d0b5e1dc953a3daae38d79dfbdd11d8600bccaa1d9b495b0dd6f 2026.06 2.png https://confluence.curvc.com/spaces/ASD/blog/2026/06/19/333152257/JFrog+Artifactory%EB%9E%80+%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94 2026.06 3.png https://confluence.curvc.com/spaces/ASD/blog/2026/06/26/335413317/Sonar+%EB%B3%B4%EA%B3%A0%EC%84%9C%EB%A1%9C+%EB%B3%B4%EB%8A%94+%EC%A3%BC%EC%9A%94+LLM%EC%9D%98+%EC%BD%94%EB%94%A9+%EC%84%B1%ED%96%A5%EA%B3%BC+%EC%88%A8%EC%9D%80+%EB%A6%AC%EC%8A%A4%ED%81%AC

2026/06/26

SonarQube Cloud Team Plan에 Advanced Security 제공 발표

SonarQube 블로그에 따르면 2026년 6월 24일 SonarQube Cloud Team Plan에 Advanced Security가 제공된다고 안내되었습니다. https://www.sonarsource.com/blog/announcing-advanced-security-for-sonarqube-cloud-team-plan/ https://www.sonarsource.com/blog/announcing-advanced-security-for-sonarqube-cloud-team-plan/ 요약 SonarQube Advanced Security가 이제 SonarQube Cloud Team 플랜에서 사용 가능해졌으며, 내장된 종속성 위험 분석, 소프트웨어 구성 분석(SCA) 및 맬웨어 탐지 기능을 제공합니다. 이 기능은 최근 Axios와 Trivy 같은 주요 도구들이 단 몇 분 만에 해킹당한 사례와 같이 증가하는 소프트웨어 공급망 위협으로부터 보호해 줍니다. 이 솔루션은 별도의 파편화된 보안 도구 없이 기존 개발자 워크플로, 코드 품질 검사 및 IDE에 직접 통합됩니다. 팀은 저장소 분기를 병합하기 전에 취약한 공개 패키지를 즉시 식별하고, 라이선스 가시성을 추적하고, 안전한 코드 표준을 적용할 수 있습니다. SonarQube Cloud Team 플랜 고객은 이제 종속성 위험 분석(SCA, 종속성 인식 오염 분석 및 맬웨어 탐지)을 이용할 수 있습니다. 공급망이 새로운 최전선이다 블로그 글을 보셨다면 이미 아시겠지만, 이제 소프트웨어 공급망은 단순한 공격 대상이 아닙니다. 바로 핵심 공격 대상이 되었습니다. 3월 31일, 불과 39분 동안 공격자들은 JavaScript 생태계에서 가장 많이 다운로드되는 HTTP 클라이언트 중 하나인 Axios https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all의 메인테이너 계정을 탈취했습니다. Axios는 주간 다운로드 수가 약 8천만 건에 달하는 패키지입니다. 공격자들은 백도어가 심어진 두 개의 버전, 1.14.1과 0.30.4를 각각 latest 및 legacy 태그로 배포했습니다. 그 결과 npm install axios 명령 한 번만으로도 macOS, Windows, Linux 개발자 장비와 CI 러너에 크로스 플랫폼 RAT(Remote Access Trojan)가 설치될 수 있는 상황이 발생했습니다. 불과 12일 전에는 Trivy 공급망 침해 사건 https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/으로 인해 보안 스캐너 자체가 공격 도구로 변했습니다. TeamPCP 그룹은 aquasecurity/trivy-action의 77개 버전 태그 중 76개를 강제로 변경해 악성 커밋을 가리키도록 만들었고, 백도어가 삽입된 trivy v0.69.4 바이너리를 배포했습니다. 또한 이들은 스스로 확산되는 npm 웜인 CanisterWorm을 발생시켰고, 그 결과 66개 이상의 패키지가 침해되었습니다. 이 중 28개는 60초도 되지 않아 감염되었습니다. 같은 캠페인은 이후 Bitwarden CLI, Checkmarx KICS, LiteLLM으로도 확산되었습니다. Axios, Trivy, tj-actions/changed-files, ua-parser-js, Codecov, 그리고 그 이전의 SolarWinds 사례가 반복해서 보여주는 교훈은 동일합니다. 다만 그 메시지는 사건이 반복될수록 더 크게 들리고 있습니다. 이제 더 이상 의존성을 “다른 사람의 문제”로 취급할 수 없습니다. 모든 전이적 패키지, 모든 고정된 버전, 모든 postinstall 스크립트는 여러분의 공격 표면의 일부입니다. 그리고 “악성 버전이 배포되는 순간”부터 “그 악성 코드가 CI에서 실행되는 순간”까지의 간격은 이제 분 단위로 측정됩니다. SonarQube Cloud Team 플랜에서 Advanced Security 제공 SonarQube Advanced Security https://www.sonarsource.com/products/sonarqube/advanced-security/는 출시 이후 Enterprise 플랜의 일부로 제공되어 왔습니다. 이제 SonarQube Cloud Team 플랜 고객도 동일한 기능을 사용할 수 있게 되었습니다. 이미 사용 중인 Team 플랜에서, 검증된 Advanced Security 기능을 그대로 활용할 수 있습니다. Advanced Security는 개발자가 이미 사용하고 있는 워크플로우 안에 자연스럽게 통합됩니다. 새 도구를 도입할 필요도, 별도 대시보드를 관리할 필요도, 새로운 프로세스를 설득할 필요도 없습니다. SonarQube Team이 제공하는 코드 품질 및 코드 보안 기능에 더해, 현대 개발팀이 반드시 확인해야 하는 오픈소스 가시성을 제공합니다. Software Composition Analysis(SCA): 실제로 사용하고 배포하는 모든 의존성을 분석하고 목록화합니다. 악성 패키지 탐지: 코드가 어떤 공개 패키지로 연결되는지 정확히 확인할 수 있습니다. 라이선스 가시성: 의존성 정보와 함께 라이선스 세부 정보를 확인할 수 있습니다. 취약점 검사: 의존성에 공개적으로 보고된 취약점이 있는지 탐지합니다. Quality Gates + IDE 통합: 병합 전 기준을 적용하고, SonarQube for IDE 안에서 바로 수정할 수 있도록 지원합니다. Team 플랜 고객에게 중요한 이유 지금까지 SonarQube Cloud Team 플랜 고객 중 공급망 리스크에 가장 많이 노출된 팀, 즉 빠르게 제품을 배포하지만 전담 AppSec 조직을 갖추기 어려운 중소 규모 팀은 별도의 SCA 도구를 추가로 도입하거나, 충분한 가시성 없이 개발을 진행해야 했습니다. 도구가 분산되면 맥락도 분산됩니다. 알림은 한 곳에 있고, 코드는 다른 곳에 있으며, 개발자는 계속 도구를 오가야 합니다. 그 결과 수정은 늦어지고, 리스크는 남게 됩니다. Advanced Security가 포함된 Team 플랜은 이 문제를 해결합니다. 기존에 코드 스멜로 인해 병합을 차단하던 동일한 Quality Gate가 이제는 취약한 의존성으로 인한 병합도 차단할 수 있습니다. 기존에 개발자에게 버그 수정 가이드를 보여주던 SonarQube for IDE 플러그인은 이제 가져오면 안 되는 의존성까지 알려줄 수 있습니다. 동일한 워크플로우, 하나의 기준점에서 관리할 수 있습니다. Team 플랜 고객이 얻을 수 있는 효과 리스크 감소 항상 활성화된 의존성 가시성을 통해 실제로 무엇을 배포하는지 파악할 수 있습니다. 취약한 의존성이 CI 러너에 도달하기 전에, 개발 라이프사이클의 더 이른 단계에서 발견할 수 있습니다. 더 빠른 개발 코드 품질, 코드 보안, 의존성 인텔리전스를 한곳에서 관리할 수 있습니다. 사고 발생 후가 아니라 병합 전에 Quality Gate를 통해 기준을 적용할 수 있습니다. SonarQube for IDE 안에서 개발자에게 바로 실행 가능한 가이드를 제공할 수 있습니다. 더 많은 기능이 필요하다면 SonarQube Enterprise Team 플랜의 Advanced Security는 탐지 기능을 제공합니다. 만약 팀에 컴플라이언스 요구사항이 있거나, 조직 전체 수준의 리포팅과 가시성이 필요하다면 SonarQube Enterprise가 그 위에 거버넌스 계층을 추가로 제공합니다. SonarQube Enterprise에서는 다음과 같은 기능을 활용할 수 있습니다. 여러 프로젝트를 통합 관리할 수 있는 포트폴리오 리스크를 한눈에 확인할 수 있는 리포팅 컴플라이언스 대응을 위한 SBOM 내보내기 Enterprise 요구사항에 맞춘 라이선스 정책 및 라이선스 리스크 추적 현재 단계에서 이러한 수준의 거버넌스가 필요하지 않다면, Team 플랜의 Advanced Security가 적절한 시작점이 될 수 있습니다. 더 안심하고 배포하세요 SonarQube Advanced Security는 이제 모든 SonarQube Cloud Team 플랜 고객에게 제공됩니다. 기능을 활성화하고, 저장소를 연결한 뒤, 여러분의 소프트웨어 안에 실제로 무엇이 포함되어 있는지 확인해 보세요.

2026/06/26

Sonar 보고서로 보는 주요 LLM의 코딩 성향과 숨은 리스크

AI 코딩 도구는 이제 개발 현장에서 빠르게 확산되고 있습니다. GitHub Copilot, Cursor, Claude Code와 같은 도구는 개발자가 더 빠르게 코드를 작성하고, 반복적인 작업을 줄이며, 복잡한 문제 해결을 지원하는 데 활용되고 있습니다. SonarSource가 발표한 The Coding Personalities of Leading LLMs 보고서는 중요한 시사점을 제공합니다. 이 보고서는 주요 LLM이 생성한 코드를 분석해, 각 모델이 단순히 문제를 얼마나 잘 푸는지를 넘어 실제 엔터프라이즈 개발 환경에서 얼마나 안전하고 유지보수 가능한 코드를 생성하는지 살펴봅니다. 핵심 메시지는 명확합니다. AI 코딩 모델은 기능적으로 동작하는 코드를 빠르게 만들어낼 수 있지만, 그 코드가 반드시 안전하고 유지보수하기 쉬운 좋은 코드라는 의미는 아닙니다. Sonar는 어떻게 LLM 생성 코드를 평가했을까? Sonar는 기존의 성능 벤치마크를 넘어, LLM이 생성한 코드를 평가하기 위한 자체 분석 프레임워크를 개발했습니다. 이 분석에는 SonarQube Enterprise의 정적 분석 엔진이 활용되었습니다. SonarQube Enterprise는 엔터프라이즈급 소프트웨어에서 복잡한 버그, 보안 취약점, 코드 스멜을 탐지해 온 경험을 바탕으로 코드 품질을 분석합니다. 이번 보고서에서는 두 가지 유형의 모델을 평가했습니다. 첫 번째는 Anthropic의 Claude Sonnet 4 및 Claude 3.7 Sonnet, OpenAI의 GPT-4o, Meta의 Llama 3.2 90B, 오픈소스 모델인 OpenCoder-8B 등 5개의 비추론형(non-reasoning) LLM입니다. 두 번째는 새로운 추론형(reasoning) 모델인 GPT-5입니다. 직접적인 비교를 위해 GPT-5는 다른 비추론형 모델들과 유사하게 비교할 수 있는 minimal reasoning mode에서 평가되었습니다. 각 모델은 MultiPL-E-mbpp-java, MultiPL-E-humaneval-java, ComplexCodeEval 등에서 가져온 4,442개 이상의 Java 프로그래밍 과제를 수행했습니다. 이 분석의 목적은 단순히 “어떤 모델이 가장 성능이 좋은가”를 보여주는 것이 아닙니다. 각 모델이 어떤 방식으로 코드를 작성하고, 어떤 유형의 리스크를 만들어내며, 실제 개발 조직에서 어떻게 활용되어야 하는지에 대한 보다 현실적인 기준을 제시하는 데 있습니다. 공통 강점: LLM은 코드를 잘 만든다 LLM이 개발 현장에서 빠르게 활용되는 이유는 분명합니다. 대부분의 모델은 문법적으로 유효한 코드를 생성하고, 알고리즘 문제를 해결하며, 추상적인 로직을 다양한 프로그래밍 언어 환경에 맞게 변환하는 데 강점을 보입니다. image-2026-6-25_16-39-44.png HumanEval, MBPP, Weighted test Pass@1 평균을 모델별로 비교한 표 Claude Sonnet 4와 GPT-5-minimal은 높은 기능 통과율을 보였지만, 이 수치만으로 코드 품질 전체를 판단하기는 어렵습니다. 예를 들어 HumanEval 기준으로 Claude Sonnet 4는 95.57%, GPT-5-minimal은 약 92%의 성공률을 기록했습니다. 이는 두 모델이 실행 가능한 코드를 생성하는 데 높은 역량을 가지고 있음을 보여줍니다. 또한 “Weighted test Pass@1” 기준에서도 Claude Sonnet 4는 77.04%, GPT-5-minimal은 75.37%를 기록했습니다. 즉, 주요 LLM들은 단순한 문법 생성기를 넘어 실제 문제 해결 능력을 갖춘 코딩 도구로 볼 수 있습니다. 하지만 이 지점에서 중요한 질문이 남습니다. 기능 테스트를 통과한 코드는 정말 좋은 코드일까요? 공통 약점 1: 보안 의식의 부족 보고서에 따르면 모든 모델은 보안 측면에서 공통적인 약점을 보였습니다. 특히 비추론형 모델들은 ‘BLOCKER’ 심각도에 해당하는 취약점을 높은 비율로 생성하는 경향이 있었습니다. https://confluence.curvc.com/download/attachments/335413282/image-2026-6-26_8-48-5.png?version=1&modificationDate=1782431286127&api=v2 https://confluence.curvc.com/download/attachments/335413282/image-2026-6-26_8-48-55.png?version=1&modificationDate=1782431335974&api=v2 GPT-5-minimal은 다른 모델에 비해 취약점 밀도가 3~6배 낮은 코드를 생성했습니다. 그러나 이것이 곧 “안전한 코드”를 의미하지는 않습니다. GPT-5-minimal은 일반적이고 잘 알려진 취약점을 줄이는 대신, 더 미묘하고 구현 방식에 특화된 취약점을 만들어내는 경향을 보였습니다. 예를 들어 GPT-5-minimal은 여전히 “Path-traversal & Injection(경로 탐색 및 인젝션)” 취약점을 20% 수준으로 생성했으며, 다른 모델보다 “Inadequate I/O error-handling(부적절한 I/O 오류처리)” 관련 취약점 비율이 높게 나타났습니다. 이는 LLM의 보안 문제가 단순히 가끔 발생하는 환각의 문제가 아니라, 모델의 학습 방식과 구조적 한계에서 비롯될 수 있음을 보여줍니다. 인젝션 취약점을 방지하려면 신뢰할 수 없는 입력 지점에서 민감한 처리 지점까지 데이터 흐름을 추적하는 taint-tracking이 필요합니다. 이는 일반적인 LLM의 문맥 처리 범위를 넘어서는 비국소적 데이터 흐름 분석에 가깝습니다. 공통 약점 2: 엔지니어링 원칙 적용의 어려움 보안 취약점 외에도 LLM은 소프트웨어 엔지니어링 원칙이 필요한 영역에서 한계를 보였습니다. 예를 들어 리소스 누수, 예외 처리 미흡, API 계약 위반, 타입 안정성 문제, 동시성/스레딩 문제 등이 발생할 수 있습니다. 이러한 문제는 단순히 테스트를 통과하는지만으로는 충분히 확인하기 어렵습니다. 특히 추론형 모델은 흥미로운 트레이드오프를 보입니다. GPT-5처럼 더 높은 추론 능력을 가진 모델은 “Control-flow mistakes”와 같은 기본적인 논리 오류를 줄일 수 있습니다. 하지만 모델이 더 복잡한 해결책을 시도하면서 “Concurrency / Threading” 버그와 같은 고급 결함은 오히려 증가할 수 있습니다. 즉, 더 뛰어난 모델이 항상 더 안전한 코드를 만든다고 단정하기는 어렵습니다. 리스크가 줄어드는 것이 아니라, 더 복잡하고 발견하기 어려운 형태로 이동할 수 있기 때문입니다. image-2026-6-26_8-59-9.png 제어 흐름 오류, API 계약 위반, 예외 처리, 리소스 누수, 동시성/스레딩 문제 등 버그 유형 비교 LLM은 기능 구현에는 강점을 보이지만, 실제 운영 코드에서 중요한 엔지니어링 품질을 일관되게 보장하지는 못합니다 공통 약점 3: 코드 스멜과 기술부채 보고서에서 가장 주목할 부분 중 하나는 LLM이 생성한 이슈 중 대부분이 코드 스멜이라는 점입니다. 코드 스멜은 당장 프로그램 실행을 막는 오류는 아닙니다. 하지만 코드 구조가 복잡하거나, 중복이 많거나, 불필요한 코드가 포함되어 있거나, 유지보수하기 어려운 형태로 작성되었다는 신호입니다. image-2026-6-26_9-5-7.png 모델별 버그, 취약점, 코드 스멜 비중 모든 모델에서 코드 스멜이 전체 이슈의 대부분을 차지했습니다. 보고서에 따르면 모든 모델에서 코드 스멜은 전체 이슈의 대부분을 차지했습니다. 특히 GPT-5 계열은 다른 모델보다 ‘CRITICAL’ 등급의 코드 스멜 비중이 높게 나타났습니다. 이는 높은 기능 성능에 따르는 비용, 즉 심각한 기술부채의 증가로 볼 수 있습니다. 아래표는 유지보수성 측면의 상충 관계를 가장 직접적으로 보여주는 근거입니다. AI를 활용하면 초기 개발 속도는 빨라질 수 있습니다. 하지만 코드 스멜이 누적되면 이후 코드 리뷰, 기능 추가, 버그 수정, 신규 개발자 온보딩, 리팩토링에 더 많은 시간이 필요해집니다. 결국 AI로 얻은 초기 생산성 향상이 장기적인 유지보수 비용으로 상쇄될 수 있습니다. image-2026-6-26_9-7-27.png 사용되지 않는 코드, 설계/프레임워크 모범 사례 위반, 복잡도, 네이밍/문서화 등 코드 스멜 유형 비교 코드 스멜도 단일 문제가 아니라, 모델별로 서로 다른 방식으로 나타납니다. LLM마다 다른 “코딩 성향”이 있다 그렇다면 모든 LLM이 공통적인 강점과 약점을 가진다면, 왜 실제 개발 환경에서 각 모델이 작성한 코드는 서로 다르게 느껴질까요? Sonar 보고서는 각 LLM이 고유하고 측정 가능한 “코딩 성향”을 가지고 있다고 설명합니다. 이러한 성향은 단순한 인상이 아니라, 생성된 코드의 구조적 지표를 통해 정량적으로 확인할 수 있습니다. image-2026-6-25_16-41-1.png X축: 기능 성능 Y축: 인지 복잡도 버블 크기: 코드량 보고서는 모델의 코딩 스타일을 세 가지 주요 특성으로 분류했습니다. 첫째, 장황성(Verbosity)입니다. 이는 주어진 작업을 해결하기 위해 모델이 생성하는 코드의 전체 분량을 의미합니다. 둘째, 복잡도(Complexity)입니다. 생성된 코드의 구조적·논리적 복잡성을 의미하며, 순환 복잡도와 인지 복잡도 같은 지표로 측정됩니다. 셋째, 커뮤니케이션 및 문서화(Communication and documentation)입니다. 코드 내 주석의 밀도를 통해 모델이 자신의 작업을 얼마나 설명하려는 경향이 있는지를 보여줍니다. 예를 들어 GPT-5-minimal은 490,010 LOC를 생성하며 매우 장황한 성향을 보였습니다. 반면 OpenCoder-8B는 동일한 문제를 해결하기 위해 120,288 LOC만 생성했습니다. 이는 단순히 코드 길이의 차이가 아니라, 문제 해결 방식의 차이를 보여줍니다. GPT-5-minimal은 인지 복잡도에서도 111,133을 기록하며 가장 복잡한 솔루션을 생성했습니다. 이는 OpenCoder-8B의 13,965보다 12배 이상 높은 수치입니다. 문서화 성향에서도 차이가 나타났습니다. Claude 3.7 Sonnet은 16.4%의 높은 주석 밀도를 보였지만, GPT-5-minimal은 2.1%에 그쳤습니다. 이는 모델마다 협업과 유지보수성에 영향을 줄 수 있는 서로 다른 커뮤니케이션 스타일을 가지고 있음을 의미합니다. image-2026-6-26_9-12-28.png 모델별 LOC, 주석 비율, 순환 복잡도, 인지 복잡도 비교 LLM마다 단순히 성능 차이만 있는 것이 아니라, 코드 작성 방식 자체가 다르게 나타납니다. 주요 LLM의 코딩 아키타입 Sonar 보고서는 각 모델의 코딩 성향을 바탕으로 여섯 가지 아키타입을 정의했습니다. LLM 코딩 아키타입 기능 역량 (통과율 %) 이슈 밀도 (Issues/KLOC) 장황성 (LOC) 인지 복잡도 주요 결함 유형 (전체 이슈 중 비중) GPT-5-minimal 기준 성능형 75.37% 26.65 490,010 111,133 코드 스멜 94.87% Claude Sonnet 4 시니어 아키텍트형 77.04% 19.48 370,816 47,649 코드 스멜 92.2% Claude 3.7 Sonnet 균형 잡힌 이전 세대형 72.46% 22.82 288,126 42,220 코드 스멜 92.9% GPT-4o 효율적인 범용형 69.67% 26.08 209,994 26,450 코드 스멜 90.5% Llama 3.2 90B 기대에 못 미친 잠재형 61.47% 26.2 196,927 20,811 코드 스멜 89.9% OpenCoder-8B 빠른 프로토타입형 60.43% 32.45 120,288 13,965 코드 스멜 92.0% 기준 성능형 [GPT-5-minimal] 이는 GPT-5의 기본적인 추론 모드에 해당합니다. 대부분의 비추론형 모델보다 우수한 강력한 성능을 제공합니다. 이 모델의 성향은 더 고도화된 모델들과 비교했을 때 상대적으로 “전통적인” 리스크 프로필을 가진다는 점으로 정의할 수 있습니다. 예를 들어 “경로 탐색 및 인젝션(Path-traversal & Injection)” 취약점이 상당한 비율인 20%로 나타나며, “제어 흐름 오류(Control-flow mistake)”와 같은 기본적인 버그도 생성합니다. 동시에 높은 장황성과 복잡도로 인해 새로운 유형의 리스크도 만들어냅니다. 그 결과, 평가된 모든 모델 중 ‘CRITICAL’ 등급 코드 스멜의 비중이 가장 높게 나타났습니다. 시니어 아키텍트형 [Claude Sonnet 4] 이 LLM은 엔터프라이즈급 시스템 구축을 맡은 숙련되고 야심 있는 아키텍트처럼 코드를 작성합니다. 벤치마크 테스트의 77.04%를 통과하며 가장 높은 기능 역량을 보였습니다. 이 모델의 스타일은 장황하고 매우 복잡합니다. 정교한 안전장치, 오류 처리, 고급 기능을 지속적으로 구현하려고 하며, 이는 시니어 엔지니어의 행동 방식과 유사합니다. 하지만 바로 이 정교함이 함정이 될 수 있습니다. 코드는 고급스럽고 안전해 보일 수 있지만, 실제로는 리소스 누수와 같은 더 복잡하고 심각도 높은 버그를 만들어낼 가능성이 있습니다. 모델의 정교함은 복잡하고 상태를 관리하는 시스템에서 자주 발생하는 고위험 버그가 생길 여지를 많이 만듭니다. 이 모델의 고유한 버그 프로필을 보면, 동시성 및 스레딩 버그가 전체 버그의 9.81%로 비교적 높게 나타났고, 리소스 관리 누수도 전체 버그의 15.07%를 차지했습니다. 즉, 이 모델의 강점인 정교한 코드 생성 능력이 동시에 약점과 연결되어 있습니다. 균형 잡힌 이전 세대형 [Claude 3.7 Sonnet] 이 모델은 이전 세대의 유능하고 균형 잡힌 개발자에 가깝습니다. 벤치마크 통과율 72.46%로 강력한 기능 역량을 보입니다. 이 모델을 가장 잘 정의하는 성향은 커뮤니케이션 방식입니다. Claude 3.7 Sonnet은 뛰어난 문서화 성향을 보이며, 16.4%라는 높은 주석 밀도의 코드를 생성했습니다. 이는 후속 모델보다 거의 세 배 높고, 평가된 모든 모델 중 가장 높은 수치입니다. 덕분에 이 모델이 작성한 코드는 사람이 읽고 이해하기에 상대적으로 쉽습니다. 하지만 균형 잡힌 이전 세대형에도 한계는 있습니다. 더 야심적인 후속 모델보다 안정적이고 덜 무모해 보일 수는 있지만, 결코 “안전한” 모델이라고 보기는 어렵습니다. 여전히 높은 비율의 ‘BLOCKER’ 취약점, 즉 56.03%를 생성하며, 다른 모델들과 동일한 근본적 결함을 가지고 있습니다. 효율적인 범용형 [GPT-4o] 이 LLM은 신뢰할 수 있는 중간 지점의 개발자에 가깝습니다. “시니어 아키텍트형”만큼 장황하지도 않고, “빠른 프로토타입형”만큼 간결하지도 않습니다. 여러 작업에 두루 활용할 수 있는 범용형 모델이며, 일반적인 코딩 지원 용도로 자주 선택될 수 있는 유형입니다. 이 모델의 코드는 적당한 수준의 복잡도를 가지며, 기능 성능도 안정적입니다. 다만 이 모델의 독특한 성향은 실수의 유형에서 드러납니다. 일반적으로 가장 심각한 ‘BLOCKER’ 또는 ‘CRITICAL’ 버그는 비교적 잘 피하는 편이지만, 논리적 정밀성에서는 눈에 띄는 부주의함을 보입니다. 이를 잘 보여주는 것이 가장 흔한 버그 유형입니다. GPT-4o의 전체 버그 중 “제어 흐름 오류(Control-flow mistakes)”가 48.15%를 차지합니다. 이는 전체 목표는 올바르게 파악하지만, 코드를 견고하게 만들기 위해 필요한 세부 사항에서 자주 실수하는 개발자의 모습과 유사합니다. 의도한 시나리오에서는 코드가 동작할 가능성이 높지만, 시간이 지날수록 품질과 신뢰성을 저해하는 지속적인 문제가 나타날 수 있습니다. 기대에 못 미친 잠재형 [Llama 3.2 90B] 모델의 규모와 배경을 고려하면, 이 모델은 최상위권 경쟁자가 되어야 할 것처럼 보입니다. 하지만 이번 분석에서 나타난 성능은 그 잠재력이 충분히 실현되지 않았음을 보여줍니다. 기능 역량은 보통 수준으로, 벤치마크 통과율은 61.47%였습니다. 이는 테스트한 훨씬 작은 오픈소스 모델보다 약간 나은 수준에 그쳤습니다. 그러나 이 모델에서 가장 우려되는 특징은 매우 취약한 보안 상태입니다. Llama 3.2 90B는 심각한 보안 사각지대를 보였으며, 생성한 취약점 중 70.73%가 ‘BLOCKER’ 심각도에 해당했습니다. 이는 평가된 모든 모델 중 가장 높은 비율입니다. 이러한 보안 프로필은 강력한 외부 검증 체계 없이 이 모델을 운영 환경에 배포할 경우 상당한 리스크가 따를 수 있음을 시사합니다. 빠른 프로토타입형 [OpenCoder-8B] 이 LLM은 뛰어나지만 규율이 부족한 주니어 개발자에 가깝습니다. 최대한 빠르게 아이디어를 구현하는 데 적합한 모델입니다. 이 모델의 스타일은 간결함으로 정의됩니다. 기능적 결과를 만들기 위해 가장 적은 양의 코드인 120,288 LOC를 생성했습니다. 따라서 첫 결과물을 빠르게 얻는 것이 가장 중요한 해커톤, 개념 검증, 빠른 프로토타이핑에 적합한 선택지가 될 수 있습니다. 하지만 즉각적인 생산성 향상은 분명한 반면, 그 대가로 가장 높은 이슈 밀도를 보입니다. 이는 프로젝트 안에 기술부채를 쌓아 장기적인 생산성과 유지보수성을 저해할 수 있습니다. 이 모델은 사실상 기술부채 생성기에 가깝습니다. 평가된 모든 모델 중 가장 높은 이슈 밀도인 KLOC당 32.45개의 이슈를 보였습니다. 가장 두드러지는 성향상 결함은 죽은 코드, 사용되지 않는 코드, 중복 코드 등을 남기는 경향입니다. 이러한 항목은 전체 코드 스멜의 42.74%를 차지했습니다. 이는 정리와 정제 과정 없이 급하게 반복 개발을 진행했을 때 나타나는 전형적인 신호입니다. 프로토타입에는 적합할 수 있지만, 운영 환경에 적용하려면 시니어 개발자의 상당한 리팩토링 노력이나 강력한 거버넌스 도구를 통한 검증이 필요합니다. 왜 “더 뛰어난” 모델이 더 위험할 수 있을까? 이번 보고서의 가장 흥미로운 발견 중 하나는 모델 업그레이드가 실제 환경에서의 리스크 증가를 가릴 수 있다는 점입니다. 최신 모델은 기능 성능이 향상될 수 있습니다. 하지만 그 과정에서 리스크의 양상이 일반적이고 잘 알려진 결함에서, 더 미묘하고 발견하기 어려운 구현상의 문제로 이동할 수 있습니다. 예를 들어 Claude Sonnet 4는 Claude 3.7 Sonnet보다 성능 벤치마크에서 개선을 보였지만, 생성하는 버그와 보안 취약점은 BLOCKER 심각도에 해당할 가능성이 더 높았습니다. GPT-5는 더 복잡한 트레이드오프를 보여줍니다. GPT-5는 대부분의 비교 모델보다 기능적으로 정확하고, BLOCKER 취약점 비중을 크게 낮췄습니다. 그러나 동시에 동시성/스레딩 버그와 같은 더 복잡한 유형의 리스크를 높은 비율로 생성했습니다. 즉, 더 뛰어난 모델은 단순한 실수를 줄일 수 있지만, 그 대신 더 복잡하고 발견하기 어려운 문제를 만들어낼 수 있습니다. image-2026-6-25_16-48-18.png Claude 3.7 Sonnet, Claude Sonnet 4, GPT-5-minimal 비교 벤치마크 통과율, BLOCKER 취약점 비중, 동시성/스레딩 버그 비중 비교 모델 업그레이드는 기능 성능 향상과 동시에 새로운 유형의 리스크를 동반할 수 있습니다. 마무리 AI 코딩 시대의 핵심 전략: Trust, but Verify AI 코딩 도구는 개발 생산성을 높이는 강력한 수단입니다. 하지만 AI가 생성한 코드를 그대로 신뢰하는 것은 위험할 수 있습니다. 코드를 개발자가 작성했든 LLM이 작성했든, “신뢰하되 검증하라(Trust, but Verify)”는 접근 방식은 그 어느 때보다 중요해졌습니다. 특히 새로운 세대의 모델에서는 검증이 더욱 엄격해야 합니다. 개발자는 겉으로 보기에는 더 깔끔해 보이는 코드가 주는 잘못된 안도감에 빠져서는 안 됩니다. 그 아래에는 동시성 버그, 보안 취약점, 심각한 기술부채와 같은 구조적 문제가 숨어 있을 수 있기 때문입니다. SonarQube는 이러한 검증 체계를 구축하는 데 중요한 역할을 할 수 있습니다. 개발자가 직접 작성한 코드뿐만 아니라 AI가 생성한 코드 역시 동일한 품질 기준으로 분석하고, 보안·신뢰성·유지보수성 측면에서 문제를 조기에 발견할 수 있도록 지원합니다. AI 코딩 도구 사용이 확대될수록 조직에는 다음과 같은 체계가 필요합니다. AI 생성 코드에 대한 일관된 품질 기준 보안 취약점과 버그의 조기 탐지 코드 스멜과 복잡도 기반의 기술부채 관리 품질 게이트를 통한 배포 전 검증 개발자 워크플로우 안에서의 지속적인 코드 품질 피드백 출처: https://www.sonarsource.com/the-coding-personalities-of-leading-llms/ https://www.sonarsource.com/the-coding-personalities-of-leading-llms/ The Coding Personalities of Leading LLMs Report by SonarSource

2026/06/24

AI 에이전트와 Jira로 엔지니어링 "반복 업무"를 최대 80% 줄인 방법

출처: How We Cut up to 80% of Engineering “Chores” Using AI Agents in Jira https://www.atlassian.com/blog/development/ai-agents-jira-engineering-maintenance 작성자: Arnaud Moret, Principal Engineer, Jira Waiyee Loo, Senior Engineer, Jira 발행일: 2026년 06월 01일 Jira 엔지니어링 팀은 KTLO(Keeping the Lights On) 업무에 예상보다 많은 시간을 할애하고 있었습니다. 이는 누구도 많은 시간을 들이고 싶어 하지는 않지만 반드시 수행해야 하는 작고 중요한 유지보수 작업을 의미합니다. 예를 들어 오래된 기능 플래그 정리, 불안정한 테스트(flaky tests) 추적, 발견된 취약점 수정, 접근성 이슈 해결, 그리고 장기간 누적된 버그를 처리하는 작업 등이 포함됩니다. 팀은 단순히 기술 부채를 관리하는 데 그치지 않고, 최고의 도구를 활용해 엔지니어링 조직이 더 빠르게 움직일 수 있도록 지원하는 데 시간을 집중하고자 했습니다. 이를 위해 에이전트, Jira, 그리고 워크플로를 활용해 핵심적인 반복 업무에 소요되는 시간을 최대 80%까지 줄일 수 있는 방식을 마련했습니다. Jira는 이러한 전략의 중심에 있습니다. 각 작업 항목(work item)은 수행해야 할 업무를 기록하는 역할을 할 뿐만 아니라, 에이전트에게 제공되는 프롬프트 역할도 합니다. 에이전트가 필요로 하는 모든 컨텍스트는 작업 항목, Atlassian’s Teamwork Graph https://www.atlassian.com/platform/teamwork-graph, 그리고 워크플로 자동화에 포함된 명시적인 지침을 통해 제공됩니다. 팀은 수년 동안 이러한 유형의 문제를 직접 해결해 왔습니다. 이러한 패턴에 대한 이해가 있었기에 에이전트에 업무를 위임할 수 있었습니다. 효과적인 정리가 어떤 모습인지 알고 있기 때문에 명확한 기준을 정의하고, 검토 단계를 마련하며, 팀의 품질 기준을 충족하는 코드를 생성할 수 있도록 인간이 개입하는(human-in-the-loop) 시스템을 설계할 수 있었습니다. 팀에게 Jira는 단순히 업무를 추적하는 도구가 아닙니다. Jira는 에이전트에 필요한 컨텍스트를 제공하고, 업무를 할당하며, 에이전트가 수행한 작업 중 실제로 코드베이스에 반영할 내용을 팀이 통제하는 공간입니다. 다음은 이러한 프레임워크를 활용해 엔지니어링 반복 업무 일부를 자동화한 두 가지 사례입니다: Jira에서 AI 에이전트를 활용해 불안정한 테스트(flaky tests)를 더 빠르게 해결하는 방법 불안정한 테스트(flaky tests)는 개별적으로 보면 작은 유지보수 이슈처럼 보이지만, 시간이 지날수록 개발 생산성에 실질적인 부담을 줍니다. 이는 빌드를 중단시키고, CI에 대한 신뢰를 떨어뜨리며, 배포 속도를 늦추고, 엔지니어가 제품 개발 대신 문제 해결에 시간을 쓰도록 만듭니다. 기존에는 불안정한 테스트 하나를 해결하는 데 약 2시간이 소요되었습니다. 이러한 문제는 하루에 평균 한 건, 많을 때는 그 이상 발생했습니다. 엔지니어는 CI 실패 원인을 분석하고, 로컬 환경 또는 CI와 유사한 환경에서 문제를 재현한 뒤, 원인이 테스트 코드인지 제품 코드인지 판단하고 수정 작업을 수행해야 했습니다. Jira 기반의 에이전트 워크플로를 도입한 이후, 매월 약 1주일 분량의 엔지니어링 시간을 절약하고 있습니다. 이를 통해 불안정한 테스트 해결에 투입되는 엔지니어링 시간을 최대 80%까지 줄일 수 있었습니다. 에이전트에 적절한 맥락을 제공하는 방법 수작업을 줄이기 위해, 팀은 그동안 처리해 온 불안정한 테스트 문제를 분석했습니다. 비동기 처리 시점 이슈, 경쟁 상태(race conditions), 불안정한 테스트 환경 설정, 신뢰할 수 없는 목(mock) 객체, 페이지 상태 문제, 시각적 렌더링 차이 등 반복적으로 나타나는 공통적인 근본 원인과 해결 패턴을 파악했습니다. 이러한 학습 내용을 재사용 가능한 에이전트 스킬로 전환했습니다. 모든 불안정한 테스트에 하나의 범용 워크플로를 적용하는 대신, 테스트 유형에 따라 적절한 에이전트 스킬이 해당 범주에 특화된 지침을 적용할 수 있도록 설계했습니다. 예를 들어 다음과 같은 스킬을 구성할 수 있습니다: 단위 테스트(Unit test) 전문 스킬: 비동기 처리 시점 이슈, 목(mock) 객체, 가짜 타이머(fake timers), 테스트 격리에 중점을 둡니다. 통합 테스트(Integration test) 전문 스킬: 브라우저 자동화 이슈, 네트워크 경쟁 상태(network races), 페이지 안정성, 테스트 환경 설정에 중점을 둡니다. 시각적 회귀 테스트(Visual regression) 전문 스킬: 결정론적 렌더링(deterministic rendering), 스냅샷 업데이트, 이미지 차이(image diffs), 시각적 테스트 안정성에 중점을 둡니다. 에이전트가 올바른 문제를 진단할 수 있도록, 각 스킬에는 재현(reproduction) 절차도 함께 포함되어 있습니다. 예를 들어 에이전트는 CI 환경을 최대한 유사하게 재현하기 위해 속도를 낮추거나 CPU를 제한(throttled)한 조건에서 실패한 테스트를 반복 실행할 수 있습니다. 이를 통해 단일 로컬 테스트 실행에서는 드러나지 않는 간헐적 실패(intermittent failures)까지 재현할 수 있습니다. Jira 워크플로를 활용한 이슈 자동 분류 티켓이 생성되면 워크플로는 먼저 사용자 정의 프롬프트를 기반으로 에이전트에게 트리아지(triage)를 위임하며, 해당 이슈가 실제 문제인지 검증하는 단계부터 시작합니다. 만약 해당 이슈가 오탐(false positive)으로 판단되면, 에이전트는 작업을 중단하고 그 결과를 요약해 원본 Jira 작업 항목에 코멘트로 남깁니다. 이를 통해 해당 티켓을 검토하는 엔지니어는 에이전트가 수행한 작업과 발견 내용을 별도로 탐색하지 않고도 빠르게 파악할 수 있습니다. 문제가 재현 가능한 경우에는 에이전트가 관련된 수정 패턴을 적용하고 코드 변경을 준비합니다. 이후 엔지니어링 팀을 위해 코멘트를 남기고, 엔지니어가 검토할 수 있도록 드래프트 풀 리퀘스트를 생성합니다. 핵심은 에이전트가 반복적인 1차 작업을 담당한다는 점입니다. 즉, 조사, 진단, 그리고 잠재적 수정 제안까지의 초기 과정을 수행합니다. 엔지니어는 최종적으로 변경 사항을 검증한 후 병합합니다. 이러한 방식으로 과거에는 몇 시간씩 걸리던 수동 조사 작업이 이제는 몇 분 단위의 리뷰 작업으로 줄어들었습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/06/workflow-td-1-462x1400.png AI 에이전트로 오래된 기능 플래그 정리를 자동화하는 방법 기능 플래그(feature flags)는 점진적 롤아웃과 안전한 실험에 매우 유용합니다. 하지만 기능 플래그로 제어되는 코드가 정기적으로 최신 상태로 관리되지 않으면 사용되지 않는 코드(dead code)가 누적되고, 이는 성능, 안정성, 개발자 생산성에 영향을 미칠 수 있습니다. 대규모 멀티 제품 코드베이스에서 정리 작업은 단순히 “코드를 제거하는 것”보다 훨씬 복잡합니다. 특정 플래그는 일부 고객에게는 완전히 롤아웃되었지만, 컴플라이언스 요구사항, 릴리스 트랙, 실험 유지 대상 등의 이유로 다른 고객에게는 여전히 활성 상태일 수 있습니다. 여러 시스템에 흩어진 정보를 조합해 플래그의 실제 상태를 파악하는 작업은 수작업에 의존해야 했고, 오류가 발생하기 쉬웠습니다. 지루하고 시간이 많이 걸리며 반복적인 작업이었고, 에이전트에 맡기기에 적합한 영역이었습니다. 이러한 작업의 상당 부분을 자동화하기 위해 Jira에 시스템을 구축했습니다. 현재까지 이 시스템을 통해 최근 70일 동안 500건 이상의 PR이 병합되었습니다. Jira 작업 항목을 프롬프트로 활용하는 방법 그동안의 경험을 바탕으로 코드베이스에서 오래된 기능 플래그를 식별하고, 에이전트가 작업을 시작하는 데 필요한 컨텍스트를 수집할 수 있는 휴리스틱을 만들었습니다. 매일 실행되는 cron 작업을 통해 오래된 각 플래그에 대한 Jira 작업 항목을 생성하고 업데이트하며, 여기에는 다음 정보가 포함됩니다: 플래그 이름 및 유형: 플래그의 고유 식별자와 플래그 유형을 포함합니다. 예를 들어 롤아웃 게이트(rollout gate), 실험(experiment) 등이 해당됩니다. 저장소 및 코드 참조 정보: 플래그가 사용된 정확한 레포지토리, 파일 경로, 줄 번호를 포함합니다. 원하는 최종 상태: 플래그가 제거된 후 코드가 어떤 모습이어야 하는지를 정의합니다. 예를 들어 롤아웃 게이트의 경우 일반적으로 유지해야 하는 “on” 또는 “off” 분기를 의미합니다. 실험의 경우 선정된 코호트, 특정 변형(variant)의 동작 방식, 또는 실험 소유자가 정의한 사용자 지정 경로가 될 수 있습니다. Jira에서 작업 항목을 에이전트에게 위임하기 책임성과 코드 품질을 보장하기 위해 인간이 개입하는(human-in-the-loop) 시스템을 설계했습니다. 엔지니어는 생성된 작업 항목을 검토한 후 상태를 변경해 작업을 에이전트에게 위임할 수 있습니다. 이 과정에서 정리 작업 지침이 포함된 사용자 지정 시스템 프롬프트를 에이전트에 전달하는 워크플로가 실행됩니다. https://support.atlassian.com/jira-software-cloud/docs/collaborate-on-work-items-with-ai-agents/#Add-an-agent-to-workflow-transitions Atlassian에는 수백 개의 팀이 소유한 수천 개의 레포지토리가 존재하며, 각 팀은 서로 다른 코드베이스와 개발 관행을 가지고 있습니다. 따라서 모든 상황에 동일하게 적용되는 획일적인 접근 방식은 효과적이지 않습니다. 이에 팀은 그동안 축적한 정리 작업 경험과 노하우를 레포지토리별 에이전트 스킬에 반영했으며, 시스템 프롬프트를 통해 각 에이전트가 명확한 대체 경로(fallback path)를 따를 수 있도록 했습니다. 가능한 경우, 해당 코드베이스에 특화된 지침을 제공하는 레포지토리의 기존 정리 절차를 활용합니다. 전용 스킬이 도움이 될 수 있는 레포지토리를 식별하고, 레포지토리 소유자에게 정리 절차 생성을 위한 지침을 제공합니다. 별도의 정리 절차가 없는 경우, 대부분의 코드베이스에서 활용할 수 있는 범용 정리 스킬을 적용합니다. 이제 모든 정리 작업은 일관되게 높은 품질의 PR로 이어지며, 그 과정에서 축적되는 지침은 에이전트의 의사결정을 지속적으로 개선하는 데 활용됩니다. 배운 점 두 사례에서 공통적으로 확인한 패턴은 명확합니다. 팀이 이미 잘 수행하고 있는 업무를 기반으로, 그 지식과 경험을 구조화된 Jira 작업 항목, 에이전트 지침, 그리고 에이전트 스킬에 반영한 뒤, 에이전트가 1차 작업을 담당하도록 하되 최종 결과물에 대한 통제권은 엔지니어가 유지하는 방식입니다. 만약 팀이 반복 가능한 패턴을 가진 업무에 지속적으로 엔지니어링 시간을 투입하고 있다면, 이는 에이전트 기반 자동화를 도입할 수 있는 기회가 있다는 신호일 수 있습니다.

2026/06/24

AI에게 디자인 언어를 학습시키기

출처: Teaching AI to speak our design language https://www.atlassian.com/blog/ai-at-work/teaching-ai-to-speak-our-design-language 작성자: Eleni Misthos, Senior Developer Content Designer Kylor Hall, Principal Prompt Engineer Farid Sabitov, Lead Design Technologist Julian Fleetwood, Lead Content Designer 발행일: 2026년 06월 02일 AI는 이제 디자인과 개발 과정 전반에서 자연스럽게 활용되고 있습니다. 하지만 AI 도구의 성능은 어떤 정보를, 어떤 방식으로 제공받느냐에 크게 좌우됩니다. Atlassian 규모의 환경에서는 디자인 언어와 관련된 정보가 문서 사이트, Confluence 페이지, Figma 파일, Loom 영상, 그리고 수백 개의 코드 패키지에 분산되어 있습니다. 일부 자료는 충분한 정보를 제공하지만, 중요한 세부 내용이 누락되어 있거나 최신 상태가 아니며, 이미지와 같은 시각적 정보에 의존해 코드가 이해하기 어려운 경우도 많습니다. 대부분의 자료가 사람이 읽고 활용하는 데 초점을 맞추고 있어, 기계가 효과적으로 읽고 활용하기에는 적합하지 않습니다. AI 도구가 이렇게 흩어져 있는 정보를 기반으로 Atlassian UI를 생성하면 결과를 예측하기 어려워지고 비용도 불필요하게 증가합니다. 에이전트는 오래된 패턴을 참조하거나 접근성 요구사항을 놓치고, 실제 디자인 시스템에 존재하지 않는 컴포넌트를 만들어내기도 합니다. 이 문제를 해결할 방법을 찾기 위해 다양한 사례를 검토했지만, 대규모 환경에서 이를 효과적으로 해결한 사례를 찾기는 어려웠습니다. 이에 디자인 시스템 콘텐츠를 일관된 스키마로 재구성하고, AI가 Atlassian UI를 생성하는 데 필요한 수준의 컨텍스트를 제공하는 방식을 마련했습니다. 이러한 접근 방식을 "Structured Content"라고 부릅니다. 디자인 시스템에서의 Structured Content 구성 방식 구조화된 콘텐츠(Structured Content)란 넓은 의미에서, 자유로운 서술형 텍스트 대신 일관된 구조를 갖춘 기계가 읽을 수 있는 단위로 콘텐츠를 구성하는 방식을 의미합니다. 예를 들어, 아이콘에 대한 설명은 디자인 시스템 웹사이트, 코드, Figma 라이브러리 등 여러 곳에서 사용됩니다. 이때 동일한 메타데이터를 여러 도구와 위치에서 재사용함으로써, 정보를 중복 관리하다가 시간이 지나면서 서로 다른 내용으로 불일치가 발생하는 문제를 방지할 수 있습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/05/sc_chart-955x531.jpg AI의 활용이 확대되면서 이러한 접근 방식을 더욱 발전시킬 필요가 있었습니다. 모든 컴포넌트, 토큰 및 기타 요소의 세부 정보는 일관되고 가벼우며, 기계가 읽을 수 있는 형식으로 관리되어야 합니다. 이를 위해 Atlassian Design System의 컴포넌트, 아이콘, 토큰, lint 규칙, 그리고 기본 가이드라인을 위한 새로운 콘텐츠 스키마를 개발했습니다. 이 스키마는 사용 방법, 코드 예제, props, 콘텐츠 표준, 접근성 요구사항 등을 포괄하는 일관된 형식을 제공합니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/05/piping-model-v4-926x537.png 스키마는 코드와 함께 TypeScript 파일로 관리됩니다. 이 단일 소스를 기반으로 ADS MCP 서버용 콘텐츠, 디자인 시스템 스킬, DESIGN.md 파일 등 에이전트에 필요한 다양한 산출물을 생성할 수 있으며, 향후 필요한 다른 형식으로도 확장할 수 있습니다. 더 정확하고 빠른 UI 생성의 초기 성과 MCP 서버 도입 이전(에이전트가 코드베이스와 비정형 문서를 직접 탐색하던 방식), MCP 서버 도입 이후, 그리고 Structured Content 기반 MCP 서버를 적용한 이후의 AI 출력 결과를 비교하여 그 효과를 측정했습니다. Structured Content 기반 MCP 적용 결과 특정 질의 기준 정확도 최대 52% 향상 AI 에이전트의 ADS 관련 작업 속도 평균 34% 향상 AI 도구 호출 횟수 26% 감소 및 토큰 사용량 16% 감소 MCP 없이 작업하는 에이전트와 비교했을 때, Structured Content 기반 ADS MCP를 사용한 경우 코드 정확도는 4.9% 향상되었고, 오류 발생은 11% 감소했습니다. 또한 작업 완료 속도는 34% 빨라졌으며, 토큰 사용량은 16%, 도구 호출 횟수는 26% 감소했습니다. 더 정확하게, 더 빠르게, 더 효율적으로 작업할 수 있게 된 것입니다. Structured Content를 적용한 경우, 생성된 코드에서 lint 오류가 더 적게 발생했습니다. 이는 AI 에이전트가 회사 전체의 모노레포와 길고 비정형적인 문서를 탐색하는 대신, 처음부터 정확한 컨텍스트를 제공받았기 때문으로 보입니다. 또한 필요한 컨텍스트를 즉시 제공함으로써, 작업은 더 빠르게 완료되었고 토큰 사용량도 줄어들었습니다. 실제 워크플로에서 Structured Content가 활용되는 방식 이러한 수치적 성과 뒤에는 Structured Content가 사람과 AI 에이전트의 작업 방식에 실질적인 영향을 미친 사례들이 있습니다. 한 워크플로에서는 제품 개발자가 Cursor에서 ADS MCP를 사용해 카드 컴포넌트에 주요 액션(primary action)을 추가했습니다. 높은 수준의 프롬프트만 제공했음에도, AI는 오류 없이 카드 푸터에 적절한 버튼 변형(button variant)를 추가했습니다. 또 다른 사례에서는 MCP를 디자인 시스템의 Slack 지원 채널에 통합했습니다. 누군가 폼에서 버튼을 비활성화해야 하는지 질문하자, Structured Content는 올바른 가이드라인인 "검증 과정에서도 버튼은 활성화 상태를 유지해야 한다"는 내용을 제공했습니다.

2026/06/24

Content Assistant가 작업 속도를 유지하면서 디자인 품질 기준을 높인 방법

출처: How Content Assistant raised the design quality bar without slowing us down https://www.atlassian.com/blog/how-we-build/how-content-assistant-raised-the-design-quality-bar-without-slowing-us-down 작성자: Tim Pike, Lead Content Designer Ann Henley, Content Design Manager Aaron Ruby, Lead Content Designer 발행일: 2026년 06월 01일 콘텐츠는 제품 경험을 좌우하는 최전선에 있습니다. 잘 만들어진 콘텐츠는 존재감 없이 자연스럽게 녹아들지만, 그렇지 못한 콘텐츠는 고객이 정면으로 마주치는 장벽이 됩니다. 소프트웨어를 확장하는 모든 기업은 콘텐츠와 관련해 비슷한 문제에 직면합니다. 관리해야 할 접점은 계속 늘어나지만 이를 뒷받침할 거버넌스는 충분하지 않고, 규모가 커질수록 콘텐츠 품질은 점차 저하됩니다. 약 6개월 전, 이러한 문제를 해결하기 위해 Content Assistant라는 에이전트를 개발했습니다. Atlassian의 AI 플랫폼인 Rovo를 기반으로 구축된 Content Assistant는 짧은 UX 문구 초안을 작성하고, 콘텐츠 작성 표준을 제공하며, Slack과 Confluence 등 사람들이 이미 업무를 수행하는 환경에서 자연스럽게 활용될 수 있도록 설계되었습니다. 이 과정에서 디자인 역량과 콘텐츠 도메인 지식, 그리고 Atlassian AI 기술을 결합했습니다 결과는 기대 이상이었습니다. Content Assistant는 Atlassian에서 가장 높은 도입률을 보인 에이전트 중 하나로 자리 잡았습니다. 이제 매달 수백 명의 Atlassian 구성원이 이를 활용하고 있으며, 사용자층도 디자이너에 국한되지 않고 엔지니어, PM, 마케팅 팀 등으로 확대되었습니다. 여러 팀은 콘텐츠 초안 작성에 걸리던 시간이 몇 시간에서 15분 수준으로 단축되었다고 평가했습니다. 또한 Content Assistant를 릴리스 노트와 지원 문서 등 다른 유형의 콘텐츠 작성에도 확장 적용한 결과, 유사한 수준의 생산성 향상을 확인할 수 있었습니다. Ariana Tran !content 이 메시지를 검토해 주세요: "인증이 성공적으로 완료되었지만, 인증 요청의 요청자를 확인할 수 없습니다. 대기 중인 작업을 계속 진행해 주세요." AI를 활용해 제작 시간과 비용을 줄이는 것은 이제 기본적인 기대 수준이 되었습니다. 하지만 가장 놀라웠던 점은 다른 데 있었습니다: Content Assistant는 품질과 거버넌스를 확산시키는 예상 밖의 역할을 해냈습니다. 모든 기능 팀은 콘텐츠 기준, 브랜드 보이스, 그리고 그동안 축적해 온 콘텐츠 전문성을 손쉽게 활용할 수 있게 되었습니다. 누구도 열어보지 않는 문서 속 스타일 가이드가 아니라, 실제로 필요한 순간에 바로 활용할 수 있는 에이전트를 통해서 말입니다. 전담 콘텐츠 디자이너가 없는 팀도 이제 표준을 준수하는 문구를 작성할 수 있게 되었습니다. Content Assistant가 제공한 가치는 단순한 속도 향상에 그치지 않았습니다. 더 넓은 범위로 확장할 수 있는 역량을 제공했습니다. AI 없이는 일관되게 관리하기 어려웠던 다양한 접점에서 사용자 친화적이고 일관된 언어를 적용할 수 있게 된 것입니다. Content Assistant는 팀의 업무 속도를 늦추지 않으면서도 모든 앱과 기능 릴리스 전반에 걸쳐 일관된 Atlassian의 목소리를 전달하고 있습니다. 내부 동작 들여다보기 사용자가 Content Assistant를 이용하면, 에이전트는 초안을 생성하는 과정에서 어떤 출처를 참조했는지, 그리고 어떤 가이드라인을 적용했는지를 설명하는 근거를 함께 제공합니다. 실제로 응답을 생성하기 전에 먼저 근거를 제시하도록 지시했을 때, 응답 품질이 향상되는 것을 확인했습니다. 예를 들어, 아래 프롬프트는 고객에게 Studio 앱 사양 초안이 작성되었음을 알리는 알림 메시지 초안을 요청하는 사례입니다: Monica Tsui !content 다음 알림 메시지를 개선해 주세요. "앱 사양이 준비되었습니다! 앱 사양이 생성되었습니다. 계속하려면 앱 빌드(Build app)를 클릭하세요." 이 알림은 사용자가 Studio를 통해 앱을 구축하는 과정에서 표시됩니다. Atlassian 콘텐츠 가이드라인에 따라 이 문구를 개선해 주세요. 이에 대해 Content Assistant는 다음과 같이 동작했습니다: 사용자의 요청 의도를 분석하고, 요청을 충족하기 위해 어떤 기준을 적용해야 하는지 판단합니다. 예를 들어 Monica의 요청에는 성공 메시지에 대한 구조 및 작성 가이드라인과 Rovo 용어집이 필요합니다. 관련 가이드라인을 확인하고 이를 요청 내용에 적용하여 필요한 문구 초안을 작성합니다. 초안과 함께, 해당 결과가 도출된 근거를 포함한 응답을 준비합니다. 생성된 결과물에 대해 품질 검사를 수행합니다. 최종 응답을 제공합니다. 에이전트 친화적 설계에서 AI 네이티브로 Content Assistant는 Rovo를 기반으로 구축되었으며, Jira, Confluence, Slack을 비롯해 Atlassian의 업무 시스템(System of Work)을 구성하는 다양한 애플리케이션과 기본 통합 기능을 활용했습니다. 이를 통해 단순한 챗봇이 아니라 실제 팀원처럼 자연스럽게 협업할 수 있는 경험을 제공할 수 있었습니다. 또한 에이전트를 다양한 워크플로와 활용 사례로 확장하는 과정에서, 훌륭한 에이전트의 가치는 결국 그것이 속한 시스템의 완성도에 달려 있다는 점을 빠르게 깨달았습니다. 콘텐츠 표준이 2023년 이후 아무도 업데이트하지 않은 오래된 문서에 머물러 있다면, 팀은 절약한 시간보다 생성된 콘텐츠를 수정하는 데 더 많은 시간을 쓰게 될 것입니다. 신뢰할 수 있는 단일 정보 출처(source of truth)가 Slack 스레드 어딘가에 묻혀 있다면, AI는 환각(hallucination)을 일으킬 수 있습니다. 또한 피드백 루프가 없다면 품질은 서서히 저하되며, 그 영향이 결국 고객에게 미칠 때까지 이를 인지하지 못할 수도 있습니다. 실질적인 변화와 영향력을 만들어내고자 한다면, Content Assistant를 독립적인 도구로 바라보는 데서 벗어나 더 큰 무언가를 구축해야 했습니다. 바로 AI 네이티브 콘텐츠 시스템(AI-native content system)입니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/05/4-layers-768x652.png 모든 팀이 구축할 수 있는 4가지 레이어 그렇다면 실제로 AI 네이티브 콘텐츠 시스템은 어떤 모습일까요? 컨텍스트 저장소(Context stores) 콘텐츠 기준, 가이드라인, 제품 지식을 LLM이 읽고 적절히 적용할 수 있도록 구조화합니다. 이는 또 다른 스타일 가이드 PDF를 만드는 것을 의미하지 않습니다. 대신, AI 네이티브 형식으로 구성된, 체계적으로 관리되는 기계 판독 가능한 지식 레이어를 구축하는 것을 의미합니다. 에이전트와 워크플로(Agents and workflows) 특정 목적에 맞게 설계된 에이전트를 사람들이 이미 업무를 수행하는 환경에 통합합니다. 예를 들어, Slack에는 Content Assistant를, Jira Service Management에는 릴리스 노트 에이전트를, 그리고 PM이 지원 문서를 요청할 때 콘텐츠 초안이 자연스럽게 작성될 수 있도록 돕는 Brief Builder를 도입했습니다. 신뢰 수준 기반 운영 모델(An operating model with trust tiers) 모든 작업에 시니어 작성자가 필요한 것은 아니며, 모든 콘텐츠 유형을 AI로 작성해야 하는 것도 아닙니다. 사소한 변경 사항에 대한 릴리스 노트와 가격 정책 관련 콘텐츠는 근본적으로 다른 수준의 위험을 수반합니다. 이에 따라 사람의 판단이 얼마나 필요한지에 따라 작업을 낮음(Low), 중간(Medium), 높음(High) 수준으로 구분해 운영하는 신뢰 수준 기반 운영 모델을 구축했습니다. 거버넌스와 피드백 루프(Governance and feedback loops) 효율성과 품질 지표를 대시보드에서 문서화하고 지속적으로 추적합니다. 자동화된 피드백 루프를 통해 콘텐츠를 최신 상태로 유지하고 관련성을 높입니다. 사람이 수정한 모든 AI 생성 초안은 중요한 신호로 활용됩니다. 이러한 신호를 시스템에 다시 반영해 단순히 더 빠른 시스템이 아니라, 더 똑똑한 시스템으로 발전시킵니다. 또한 모든 에이전트 기반 워크플로에는 인간의 거버넌스가 설계 단계부터 내재되어 있습니다. Drew Sposeep !content 데이터 인사이트 카드를 클릭했을 때 표시될 정보성 토스트 메시지 문구가 필요합니다. 사용자가 카드를 클릭하면 Asks 테이블이 "Last updated" 열을 기준으로 오름차순 정렬되며, 해당 열이 숨겨져 있는 경우 표시됩니다. 제안하는 메시지 문구는 다음과 같습니다. "'Last updated' 열이 표시되었으며, 오름차순으로 정렬되었습니다." 도입 효과 성과는 수치로도 명확하게 드러납니다. 시스템 위에 구축한 서비스 레이어인 Content Review Desk는 9개월이 채 되지 않는 기간 동안 1,500건 이상의 요청을 처리했습니다. 릴리스 노트 작성 시간은 88% 단축되었으며, 콘텐츠 디자이너들은 Figma에서 여러 차례 플레이스홀더 콘텐츠 초안을 작성하는 대신 전략 수립과 콘텐츠 완성도 향상에 집중할 수 있게 되었습니다. 이를 통해 700시간 이상의 업무 시간을 확보했습니다. 또한 이것은 단순한 도구가 아닌 시스템이기 때문에, 누적 효과는 분명하게 나타났습니다. 표준을 체계화할 때마다 에이전트는 더 똑똑해졌고, 워크플로를 자동화할 때마다 사람은 보다 전략적인 업무에 집중할 수 있게 되었습니다. 또한 모든 피드백 루프는 다음 초안을 이전보다 더 나은 결과물로 발전시키는 역할을 했습니다. Rebecca Li !content 사용자에게 "Headcount used"가 무엇을 의미하는지 설명하는 툴팁 문구를 작성해 주세요. 전략 계획(Strategic plan)에서 "Headcount used"는 총 할당된 인력 용량(capacity)을 전체 인력 예산(capacity budget)으로 나눈 값을 나타내는 푸터 항목입니다. 5142bf26-3eae-4cfa-8bae-6ce304388e96.png 어디서부터 시작해야 할까요? 만약 이 글을 읽으며 "우리에게도 이런 시스템이 필요하다"고 생각하고 있다면, 지금부터 다음과 같이 시작할 수 있습니다. 반복 가능한 하나의 콘텐츠 유형부터 시작하세요. Atlassian의 경우 UI 문구와 릴리스 노트가 그 시작점이었습니다. 작성에 많은 시간이 소요되고, 반복 가능한 패턴을 가지며, 명확한 품질 기준이 있는 콘텐츠를 선택하세요. 그리고 그 영역에서 먼저 접근 방식의 효과를 입증해 보세요. 컨텍스트 레이어를 소홀히 하지 마세요. 이는 응답 품질을 결정하는 핵심 요소 중 하나이며, 어쩌면 가장 중요한 요소일 수도 있습니다. 이를 위해 콘텐츠 표준을 체계적으로 정비하고, 개별 파일에 흩어져 있는 중요한 지식을 LLM이 활용하기 쉬운 구조화된 문서로 전환해야 합니다. 이러한 작업은 많은 노력이 필요했지만, Content Assistant의 신뢰성과 일관성을 높이는 데 큰 도움이 되었습니다. 자동화가 아닌 위험 수준과 신뢰를 중심으로 운영 모델을 설계하세요. 작업 특성에 맞는 운영 체계를 구축하고, 사람의 판단이 실제로 필요한 영역에 집중할 수 있도록 하세요. 첫날부터 피드백 루프를 구축하세요. 선택 사항으로 두지 말고, 기본적으로 내재된 요소로 설계해야 합니다. Devin Clancy !content "double-click"과 "right-click"을 접근성을 고려해 어떻게 표현할 수 있을지 알려주세요. 이는 사용자 대상 문서에 사용될 예정이며, 해당 문서에서는 "click" 대신 "select"를 사용합니다. AI 네이티브 시스템으로의 전환 AI 네이티브 콘텐츠 시스템으로의 여정은 이제 막 시작되었습니다. 이 여정을 통해 콘텐츠 제작 과정에서 축적해 온 전문성을 체계화하고, 고객이 가장 필요로 하는 순간에 이를 제공할 수 있는 기회를 만들어가고 있습니다. Atlassian의 모든 팀은 여전히 이 시스템을 함께 구축해 나가고 있으며, 그 과정 또한 열린 방식으로 공유하고 있습니다. Jira와 Confluence 같은 Atlassian 애플리케이션을 활용해 시스템을 구축하는 방법부터, 새로운 AI 활용 패턴을 적극적으로 탐색하며 가능성의 범위를 넓혀가는 과정까지, 배운 내용을 지속적으로 공유해 나갈 예정입니다. 아직 해결해야 할 미지의 영역이 많지만, 한 가지는 분명합니다. 도구 중심이 아닌 시스템 중심으로 사고방식을 전환함으로써, 불과 1년 전만 해도 상상하기 어려웠던 방식으로 업무 방식을 혁신하고 품질 기준을 한 단계 끌어올릴 수 있게 되었다는 점입니다.

- Others -

Contributor

사용자	수정	댓글	레이블
설진호 이사	1268	39	414
황희연 대표	680	12	13
이지혜 선임	677	0	30
이수정 선임	629	0	69
윤준호 책임	628	7	18
박주현 책임	326	4	15
Anonymous	242	10	46
김나우 선임	223	0	11
성윤주 선임	170	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
신민수 선임	24	0	2
최보근 선임	23	0	0
김수영 선임	22	0	0
나종진 부장	17	0	1
정성훈 선임	14	0	0
김상범 선임	9	0	0
강수재 선임	6	0	0
황현우 선임	6	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 -**