CURVC DevOps Confluence

AI와 머신러닝은 소프트웨어 애플리케이션 개발 전반에 빠르게 통합되고 있습니다. AI 에이전트 역시 개발자에게 선택 사항이 아닌 필수 요소로 자리 잡고 있으며, 기업은 경쟁력을 유지하기 위해 AI 지원 개발과 AI 자산을 적극적으로 활용하고 있습니다. 그러나 검증되지 않은 AI 구성 요소가 개발 파이프라인에 유입되면 거버넌스와 보안 위험도 함께 증가합니다. AI를 안전하게 도입하려면 위험 관리, 거버넌스, 추적성을 고려해 생산 파이프라인의 도구와 프로세스, 운영 방식을 재정비해야 합니다. 빠른 AI 도입과 보안 사이의 균형 기업은 AI를 빠르게 도입해 혁신과 생산성을 높여야 하는 동시에, 소프트웨어 공급망의 보안과 통제력을 유지해야 합니다. AI는 기존 소프트웨어 공급망을 대체하기보다 개발 속도를 크게 높입니다. 하지만 더 많은 외부 자산이 유입되고 에이전틱 개발을 통해 생성되는 바이너리가 증가하면서, 애플리케이션이 노출되는 위협도 함께 확대됩니다. 또한 AI 모델뿐 아니라 다음과 같은 새로운 유형의 아티팩트도 관리 대상에 포함됩니다. AI 모델 MCP 서버 Agent Skills 플러그인 외부 AI 서비스 이에 따라 아티팩트 계보, 모델 출처, 과도한 AI 에이전트 권한, 개발 단계 전반의 가시성 부족과 같은 새로운 보안 사각지대가 발생할 수 있습니다. 관리되지 않은 AI 도입의 마찰 요인 Shadow AI의 확산 내부 팀이 빠른 혁신을 위해 새로운 AI 도구를 개별적으로 도입하면, 기업의 관리 범위를 벗어난 사용이 늘어날 수 있습니다. 이러한 Shadow AI는 AI 공급망에 대한 중앙 통제와 가시성을 약화시킵니다. 중앙화된 관리가 부족하면 다음과 같은 문제가 발생할 수 있습니다. 보안 위협과 컴플라이언스 위험에 대한 대응력 저하 연구개발 조직 외부에서 사용되는 AI 자산에 대한 가시성 상실 AI 생태계에 대한 조직의 통제력 약화 거버넌스 정책 집행의 어려움 새로운 기술을 확장하기 위한 도구와 프로세스 부족 접근 권한 관리의 복잡성 증가 이를 해결하려면 관리되지 않는 모델과 AI 자산을 자동으로 탐지하고 통제할 수 있는 Shadow AI 탐지 기능이 필요합니다. 이를 통해 보안팀은 개발 속도를 방해하지 않으면서도 AI 사용 현황을 파악하고 컴플라이언스를 적용할 수 있습니다. AI 자산의 ‘블랙박스’ 문제 기존 소프트웨어는 소스 코드를 검토하고 검증할 수 있지만, AI 모델은 복잡한 가중치와 바이너리로 구성된 블랙박스에 가깝습니다. 일반적인 보안 도구로는 이러한 AI 자산을 충분히 분석하기 어렵습니다. 이러한 가시성 부족은 공격자가 오염된 자산, 백도어, 손상된 종속성을 소프트웨어 개발 수명주기에 유입할 수 있는 기회를 제공합니다. AI 에이전트를 안전하게 배포하려면 보안팀과 개발팀이 복잡한 바이너리를 분석하고 다음 질문에 답할 수 있어야 합니다. 사용 중인 AI 자산의 정확한 출처는 어디인가? 모델의 구조와 종속성 내부에는 무엇이 포함되어 있는가? 알려진 취약점이나 악성 페이로드가 포함된 외부 자산은 무엇인가? 모델의 안전성을 입증할 수 있는 감사 자료가 있는가? 어떤 MCP 서버를 SDLC에 안전하게 통합할 수 있는가? 이를 위해서는 AI 자산의 출처와 변경 이력을 확인하는 Traceability, 생성·학습·수정 주체를 확인하는 Chain of Custody, 보안 및 컴플라이언스 준수 여부를 입증하는 Audit-Ready Evidence, 그리고 AI 자산에 대한 지속적인 자동 스캔이 필요합니다. 확장되는 AI 공격 표면 AI 공급망의 공격 표면은 더 이상 모델에만 한정되지 않습니다. MCP 서버, Agent Skills, 도구 호출 기능, 데이터, 알고리즘, 배포 환경, 소스 코드, 외부 라이브러리까지 관리 범위가 확대되고 있습니다. AI 공격 표면에는 다음과 같은 위험이 포함됩니다. 구분 주요 위험 모델 및 아티팩트 모델 탈취, 역추론공격(Inversion Attack), 오염된 모델 바이너리 데이터 및 학습 학습 데이터 오염, 민감정보 및 개인정보 노출, 손상된 데이터셋 공급망 및 종속성 외부 자산의 상속된 취약점, 손상된 외부 API, 신뢰할 수 없는 공개 레지스트리 에이전트 및 실행 과도한 권한을 가진 AI 에이전트, Tool·Skill Hijacking, 검증되지 않은 AI 출력 실행, MCP 서버 공격 입력 및 프롬프트 직접·간접 프롬프트 인젝션, AI 탈옥(Jailbreak), Guardrail 우회, 악성 콘텍스트 페이로드 이러한 위험에 대응하려면 지속적인 모니터링과 검증, 선제적인 정책기반의 통제 계층(Policy Gate), 모든 아티팩트 유형에 대한 통제를 포함하는 보안 프레임워크가 필요합니다. 신뢰를 위한 세 가지 기반 AI 애플리케이션 개발에서 신뢰는 단순한 권장 사항이 아니라 엔지니어링 체계로 관리되어야 합니다. 코딩 단계부터 운영 환경까지 소프트웨어 공급망 전체를 확인하고, AI 아티팩트의 이동 과정과 무결성을 검증할 수 있어야 합니다. JFrog는 AI 공급망의 신뢰를 다음 세 가지 요소로 설명합니다. AI Management: System of Record AI 모델, Agent Skills, MCP 서버를 일반 소프트웨어 바이너리와 동일하게 단일 시스템에서 관리합니다. 각 AI 구성 요소를 누가 만들었는지, 어디에서 가져왔는지, 어떤 종속성을 사용하는지 확인할 수 있어야 합니다. AI Security: Continuous Inspection AI 패키지를 배포 전과 배포 과정에서 지속적으로 스캔합니다. 복잡한 바이너리를 분석해 백도어, 오염된 페이로드, 악성 코드, 라이선스 컴플라이언스 문제를 운영 환경에 도달하기 전에 확인합니다. AI Governance: Control Plane 어떤 AI 자산을 사용할 수 있는지, 누가 사용할 수 있는지, 어떤 방식으로 배포할 수 있는지를 정의합니다. 개발자뿐 아니라 AI 에이전트와 에이전트를 구성하는 자산에도 접근 권한과 정책을 적용해야 합니다. 신뢰할 수 있는 AI 공급망을 위한 네 가지 핵심 요소 Shadow AI Detection 관리되지 않는 모델, 신뢰할 수 없는 외부 API, 검증되지 않은 AI 자산을 지속적으로 자동 탐지합니다. 모든 AI 자산을 가시화하면서도 개발 속도는 유지할 수 있습니다. Centralized AI Registry 내부 및 외부 모델, MCP 서버, Agent Skills, 관련 패키지를 일반 소프트웨어 바이너리와 동일하게 관리하는 중앙 레지스트리를 구축합니다. 이를 통해 자산 검색, 버전 관리, 승인 과정과 증거관리 연속성(Chain of Custody)를 일관되게 유지할 수 있습니다. Automated Policy Enforcement 수동 보안 승인 대신 소프트웨어 공급망에 자동화된 정책 기반의 통제 계층을 적용합니다. AI 모델과 패키지, 종속성을 악성 페이로드, 라이선스 위반, 알려진 취약점 기준으로 지속적으로 스캔하고, 정책을 준수하지 않는 자산은 운영 환경에 도달하기 전에 차단합니다. Secure AI Gateway 내부 애플리케이션과 AI 에이전트, 외부 LLM 제공업체 사이에 보안 통제 지점을 구성합니다. 모든 요청과 MCP 서버, AI Agent Skills의 연결을 관리하고, 사용자 또는 에이전트에 명시적인 권한이 없는 작업을 차단합니다. 이를 통해 민감정보 유출과 프롬프트 인젝션을 방지하고, 에이전틱 워크플로와 도구 호출을 통제할 수 있습니다. JFrog Platform을 통한 통합 AI 관리 AI 기반 개발을 실험 단계에서 실제 운영 환경으로 확장하려면 소프트웨어와 AI의 관리, 보안, 거버넌스를 하나의 플랫폼으로 통합해야 합니다. JFrog Platform에서는 AI를 전체 개발 수명주기의 일부로 관리합니다. 이를 통해 분리된 팀과 프로세스를 연결하고 부서 간 협업을 지원합니다. JFrog AI Catalog는 기업의 AI 공급망을 위한 단일 System of Record입니다. 내부 및 외부 모델부터 Agent Skills와 MCP 서버까지 AI 워크로드를 중앙에서 관리하고, 거버넌스와 보안을 적용할 수 있도록 지원합니다. 이를 통해 Shadow AI를 줄이고, 속도와 통제력을 유지하면서 신뢰할 수 있는 애플리케이션을 제공할 수 있습니다. 에이전틱 공급망의 미래 대응은 소프트웨어 공급망 전체에서 신뢰를 구축하고 입증하는 것에서 시작됩니다. 이를 위해서는 기업 환경에서 확장할 수 있는 End-to-End 신뢰 계층이 필요합니다. 출처: JFrog, When AI Outpaces Security: A Guide to Regaining Control of Your Agentic Supply Chain https://jfrog.com/ebook/regaining-control-of-your-agentic-supply-chain/ https://jfrog.com/ebook/regaining-control-of-your-agentic-supply-chain/

2026/07/08

Atlassian의 AI 글쓰기 가이드라인

출처: 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

- Others -

Contributor

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