CURVC DevOps Confluence

출처: Atlassian’s guidelines for writing with AI https://www.atlassian.com/blog/ai-at-work/atlassians-guidelines-for-writing-with-ai 작성자: Liz Fosslien (Thought Leadership) 발행일: 2026년 06월 25일 AI를 활용한 글쓰기, 어떻게 해야 할까요? AI는 유용한 도구이지만, 적절한 가이드라인이 없다면 작성된 글의 완성도가 기대에 미치지 못할 수 있습니다. 과도한 긴 대시(—) 사용이나 "X가 아니라 Y입니다"와 같은 AI 표현 습관에 대하여 농담 삼고는 하지만, 실제로 AI 작성에 지나치게 의존하는 문제는 더 심해지고 있습니다: 외부적으로는, AI가 생성한 텍스트가 이미 넘쳐나고 있습니다. AI가 작성한 것이 확실한 이메일을 받아본 적이 있다면, 발신자에 대한 신뢰가 떨어지는 경험도 해본 적이 있을 것입니다. 내부적으로는, AI가 생성한 콘텐츠가 지식 그래프(knowledge graph http://teamworkgraph.com/)의 일부가 됩니다. 이는 사진을 계속 복사하는 것과 비슷합니다. 복사본을 다시 복사할수록 품질이 떨어지는 것처럼, 일반적이고 검증되지 않은 콘텐츠는 누구에게도 실질적인 도움이 되지 않습니다. Atlassian 브랜드 팀은 이러한 문제를 중요하게 바라보고 있습니다. AI를 적극적으로 활용해 빠르게 작업하면서도, 유익하고 읽는 재미가 있으며 신뢰할 수 있는 콘텐츠를 만드는 것이 목표입니다. 또한 팀의 잠재력을 끌어내는 것은 언제나 Atlassian의 핵심 목표였으며, 이를 위해서는 실질적인 도움이 되고, Atlassian만의 관점이 담긴 최고의 콘텐츠를 제공하는 것이 중요하다고 생각합니다. 지난 4월에는 Atlassian의 여러 작가들이 모여 글쓰기 과정에서 AI를 사용할지, 사용한다면 어디에, 어떻게 활용해야 할지를 논의했습니다. 이후 이러한 가이드라인을 마케팅 조직 전체에 적용해 검증하는 과정을 거쳤습니다. Atlassian의 "Open company, no bullshit https://www.atlassian.com/company/values" 철학에 따라, 이 가이드라인을 공개하기로 결정했습니다. 이 가이드라인은 아직 완성된 것이 아니라 계속 발전해 나가는 과정에 있습니다. 따라서 엄격한 규칙이라기보다 지향하는 방향을 담은 원칙에 가깝습니다. 이 내용이 여러분의 팀에도 도움이 되기를 바랍니다. AI 기술은 계속 발전하고 있으며, 이에 따라 이 가이드라인도 함께 업데이트될 예정입니다. Atlassian은 AI 기술의 변화에 맞춰 3개월마다, 또는 필요 시 그보다 더 이른 시점에 가이드라인을 다시 검토하고 업데이트할 예정입니다. 이를 통해 미래를 대비하는 사고방식과 엄격한 품질 기준 사이의 균형을 유지하고자 합니다. 최초 작성일: 2026년 4월 1일 최종 업데이트: 2026년 6월 24일 핵심 원칙 1. 글쓰기와 아이디어 발상은 사람이 주도해야 합니다. AI는 검토, 편집, 개선을 도울 수 있지만, 초안 작성과 최종 원고 작성은 반드시 사람이 자신의 목소리로 직접 수행해야 합니다. 2. 모든 콘텐츠에는 사람의 이름이 작성자로 표시되어야 합니다. 게시하는 모든 콘텐츠에는 사람 작성자의 이름이 포함되어야 합니다. 해당 작성자는 AI의 도움을 받은 부분을 포함해 콘텐츠 전체에 대한 책임을 집니다. 3. AI에 충분한 맥락을 제공합니다. AI로 글을 편집하거나 다듬을 때는 대상 독자, 작성 목적, 원하는 톤을 명확하게 전달해야 합니다. 그래야 일반적이고 추상적인 피드백을 줄일 수 있습니다. 4. 사실 확인은 반드시 직접 확인합니다. AI가 제안하거나 생성한 모든 내용은 실제 적용하기 전에 반드시 담당자가 검증해야 합니다. 여기에는 사실 정보, 데이터, 인용문도 모두 포함됩니다. 5. 읽고 싶지 않은 글은 공개하지 않습니다. 자신이 읽어도 도움이 되거나 공감되지 않는 글이라면, 독자도 그렇게 느낄 가능성이 높습니다. 6. AI로 인해 다양한 관점이 사라지지 않도록 주의합니다. AI는 학습 데이터에서 가장 많이 나타난 대상과 관점을 기준으로 응답을 생성하는 경향이 있습니다. 그 결과 일부 관점은 과도하게 반영되고, 다른 관점은 희석되거나 사라질 수 있습니다. AI의 글쓰기 제안을 검토할 때는 무엇이 추가되었는지만큼 무엇이 빠졌는지도 함께 살펴봐야 합니다. Atlassian에서 이러한 원칙을 적용하는 방법 AI를 효과적으로 활용하는 방법 신중하게 활용해야 하는 경우 AI를 사용하지 말아야 하는 경우 권장되는 활용 사례: (최종 책임은 사람이 집니다.) 신중한 검토와 판단이 필요한 활용 사례: 금지되는 활용 사례: 초안의 부족한 부분이나 보완이 필요한 부분 식별 (“어느 부분의 논리가 불명확하거나 근거가 부족한가?”) 메시지 검증 및 반론 가능성 점검 (“회의적인 독자는 어떤 이의를 제기할 수 있을까?”) 검증된 고객 조사 결과를 핵심 인사이트로 구조화 사람이 작성한 상세한 메모, 조사 결과 또는 잘 구성된 개요를 바탕으로 구조화된 초안 작성 여러 아이디어를 가장 적합한 하나의 안으로 구체화 추가 콘텐츠 초안 작성 (소셜 게시물, 뉴스레터 소개 문구, 인용 문구 등) 브랜드 보이스와 톤에 맞게 문장 다듬기 SEO 지원 (키워드, 메타 설명, 헤더 구조 제안 등) 경쟁 포지셔닝 검토 콘텐츠를 핵심 메시지(Narrative Pillars)에 맞게 구성 통계(정량·정성 데이터), 고객 추천사 또는 고객 사례(Case Study) 생성 제품 관련 주장이나 성능 결과 생성 Atlassian의 맥락이나 관점(POV) 없이 콘텐츠 초안 작성 핵심 주장이나 차별화된 논지 결정 핵심 주장이나 차별화된 논지 결정 사실 확인의 최종 판단을 AI에 맡기기

2026/07/08

Jira Service Management에서 Rovo와 자동화를 활용해 문제 해결 속도를 높이는 3가지 방법

출처: 3 ways teams use Rovo and automation in Jira Service Management to speed up resolution https://www.atlassian.com/blog/jira-service-management/rovo-automation-customer-stories 작성자: Bimal Jayadev (Senior Product Manager, Atlassian) 발행일: 2026년 06월 17일 자동 분류, 번역, 사고 대응 후속 조치에 대한 실제 고객 사례 Jira Service Management에서 에이전트 기반 자동화는 기존 자동화보다 3.4배 빠른 속도로 확산되고 있습니다.] 그 이유는 간단합니다: 팀은 더 이상 개별 작업의 처리 속도를 높이는 데 그치지 않고, 분류, 번역, 조사, 후속 조치까지 포함한 전체 워크플로를 AI 에이전트에 맡기고 있기 때문입니다. https://atlassianblog.wpengine.com/wp-content/uploads/2026/06/screenshot-2026-06-05-at-3.39.49-pm-768x739.png Atlassian 고객사인 Axpo, SpotOn, Vodeno의 사례는 이러한 방식이 실제 운영 환경에서 어떻게 활용되고 있는지 보여줍니다. 세 팀. 세 가지 워크플로. 업무를 넘길 필요가 없습니다. Axpo: 다국어 지원을 위한 엔드투엔드 자동 번역 문제: 스위스의 주요 에너지 기업인 Axpo는 독일어 사용 고객을 지원하지만, 2차 지원팀은 독일어를 사용하지 않는 스페인 마드리드에 위치해 있었습니다. 담당자는 티켓이 접수될 때마다 번역 도구에 내용을 복사해 붙여 넣고, 번역 결과를 기다린 뒤, 추가 확인이 필요한 내용을 다시 주고받아야 했습니다. 해결 방법: Axpo는 Jira Service Management에 Rovo를 통합해 번역 과정을 완전히 자동화했습니다. 독일어 티켓이 접수되면 Rovo가 언어를 자동으로 감지하고, 요약과 설명을 영어로 번역해 전용 필드에 저장합니다. 또한 독일어로 작성된 모든 댓글은 자동으로 영어로 번역되어 내부 전용 메모로 등록되며, 원본 작성자와 작성 시간도 그대로 유지됩니다. 주요 성과: 이제 마드리드의 지원팀은 독일어 티켓도 Jira Service Management 안에서 바로 처리할 수 있습니다. 별도의 번역 도구를 사용할 필요가 없고, 문맥이 끊기지 않으며, 번역을 위한 업무 전달 과정도 사라졌습니다. 동작 방식 https://atlassianblog.wpengine.com/wp-content/uploads/2026/06/screenshot-2026-05-14-at-12.13.42-pm.png 트리거 에이전트 작업 새 독일어 티켓 생성 Rovo가 언어를 감지 → 요약과 설명 번역 → 커스텀 필드에 입력 새 독일어 댓글 추가 Rovo가 댓글을 영어로 번역 → 원본 작성자와 작성 시각을 포함한 내부 전용 영어 댓글로 등록 SpotOn: 단일 화면에서 제공하는 프로덕션 티켓 인텔리전스 문제: SpotOn은 미국 샌프란시스코에 본사를 둔 레스토랑 기술 및 금융 서비스 기업으로, 내부 IT 지원에 Jira Service Management를 사용하고 있습니다. 모든 요청에는 과거 티켓, 관련 문서, 이전 해결 사례 등 풍부한 조직 내 정보가 담겨 있었지만, 담당자는 티켓이 접수될 때마다 여러 도구를 오가며 필요한 정보를 직접 찾아야 했습니다. 해결 방법: SpotOn은 Rovo 기반 에이전트를 구축해, 새 티켓이 생성될 때마다 여러 서브 에이전트가 병렬로 작업하도록 했습니다. 티켓이 생성되는 즉시 Rovo는 간결한 요약, 유사한 과거 티켓, 권장되는 다음 조치, 추천 담당자, 관련 문서 링크를 담은 하나의 댓글을 추가합니다. 주요 성과: 담당자는 티켓을 열자마자 필요한 정보를 바로 확인할 수 있게 되었습니다. 그 결과 초기 응답 속도가 빨라지고, 처리 일관성이 향상되었으며, 필요한 순간 AI가 관련 지식을 즉시 제공합니다. 동작 방식 https://atlassianblog.wpengine.com/wp-content/uploads/2026/06/screenshot-2026-05-14-at-12.12.59-pm.png 트리거 에이전트 작업 SpotOn 직원이 지원 티켓 제출 Rovo 서브 에이전트가 병렬로 작업 → 요약, 유사한 티켓, 권장되는 다음 조치, 추천 담당자, 관련 문서 링크를 포함한 하나의 댓글 추가 Vodeno: 장애 진단부터 PIR 자동화까지 문제: Vodeno는 유럽의 Banking-as-a-Service(BaaS) 플랫폼으로, 근본 원인 진단부터 사고 후 학습 내용 정리와 후속 조치 수행까지 이어지는 전체 장애 대응 라이프사이클을 단축해야 했습니다. 수작업으로 진행되는 조사와 장애 후 문서화는 시간이 오래 걸렸고, 일관성이 부족했으며, 장애가 해결된 이후에는 후속 작업의 우선순위가 쉽게 밀리곤 했습니다. 해결 방법: Vodeno는 Jira Service Management 자동화와 Rovo Ops 에이전트를 활용해 장애 대응 전 과정을 하나의 에이전트 기반 워크플로로 운영하고 있습니다. 장애가 생성되면 Rovo Ops가 관련 정보를 분석해 가장 가능성이 높은 원인을 제안합니다. 장애가 해결되면 Rovo는 Confluence에 PIR을 생성하고 이를 장애 티켓과 연결한 뒤, 후속 조치를 추출해 이를 추적할 Jira 작업을 생성합니다. 주요 성과: 근본 원인을 더 빠르게 진단하고, 일관된 장애 사후 분석을 수행하며, 후속 작업 누락을 방지할 수 있게 되었습니다. 이제 모든 장애는 단순히 티켓을 종료하는 데 그치지 않고, 시스템을 지속적으로 개선하는 계기가 됩니다. 동작 방식 https://atlassianblog.wpengine.com/wp-content/uploads/2026/06/screenshot-2026-03-27-at-2.56.09-pm-1.png 트리거 에이전트 작업 장애 생성 Rovo Ops가 관련 정보를 분석 → 가능한 원인을 추려 제안 → 가장 가능성이 높은 원인을 장애 티켓에 업데이트 장애 해결 Rovo가 Confluence에 PIR 생성 → 장애 티켓과 연결 → 후속 조치 추출 → Jira 작업 생성 패턴: 사람 간 업무 전달에서 에이전트 간 업무 전달로 세 사례 모두에서 AI는 사람을 대체하는 것이 아니라, 사람 간 업무 전달 과정과 비효율을 없애고 있습니다. Axpo는 번역 과정의 비효율을 제거했고, SpotOn은 필요한 정보를 수집하는 과정을 간소화했으며, Vodeno는 장애 후 문서화와 후속 조치에 필요한 업무 전달 과정을 없앴습니다. 그 결과, 사람은 사람의 판단이 필요한 업무에 더욱 집중할 수 있게 되었습니다. 이것이 에이전트 기반 자동화가 기존 자동화보다 3.4배 빠르게 확산되는 이유입니다. 기존 자동화는 작업 시간을 몇 초 단축하는 데 그치지만, 에이전트 기반 자동화는 워크플로의 단계를 아예 없애기 때문입니다. 팀의 다음 혁신은 자동화 하나에서 시작될 수 있습니다. Rovo를 활용한 새로운 Jira Service Management 자동화 템플릿 https://community.atlassian.com/forums/Jira-Service-Management-articles/New-in-Jira-Service-Management-6-Rovo-automation-templates-to/ba-p/3249154을 살펴보세요. 티켓 분류, 번역, 장애 대응, PIR 생성을 위한 미리 구성된 자동화 템플릿으로 손쉽게 시작해 보세요.

2026/06/26

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

안녕하세요, 커브입니다. 현대 소프트웨어 개발 환경에서는 다양한 아티팩트와 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차 작업을 담당하도록 하되 최종 결과물에 대한 통제권은 엔지니어가 유지하는 방식입니다. 만약 팀이 반복 가능한 패턴을 가진 업무에 지속적으로 엔지니어링 시간을 투입하고 있다면, 이는 에이전트 기반 자동화를 도입할 수 있는 기회가 있다는 신호일 수 있습니다.

- Others -

Contributor

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