CURVC DevOps Confluence


브에서 운영하는 DevOps 지식 기반 공간에 오신것을 환영합니다. DevOps, ALM, Agile과 관련된 Atlassian,
SonarQube, Open Source, CURVC 솔루션에 대한 다양한 정보를 확인할 수 있습니다.



 

Products Guide -




Jira 가이드

Atlassian Jira Guide

Atlassian Jira 설치, 사용자, 관리자 가이드를 제공합니다.

Confluence 가이드

Atlassian Confluence Guide

Atlassian Confluence 설치, 사용자, 관리자 가이드를 제공합니다.

Bitbucket 가이드

Atlassian Bitbucket Guide

Atlassian Bitbucket 설치, 사용자, 관리자 가이드를 제공합니다.



Bamboo 가이드

Atlassian Bamboo Guide

Atlassian Bamboo 설치, 사용자, 관리자 가이드를 제공합니다. 



Crowd 가이드

Atlassian Crowd Guide

Atlassian Crowd 설치, 사용자 관리자 가이드를 제공합니다.




SonarQube Guide

SonarQube 설치, 사용자, 관리자 가이드를 제공합니다.




- CURVC News -




main.png
2026/02/26

AI 사용자 경험(UX) 패턴

출처 : AI User Experience Patterns - Work Life by Atlassian https://www.atlassian.com/blog/developer/ai-user-experience-patterns 작성자 :  Dugald Morrow 발행일: 2026년 02월 23일 AI와 상호작용할 때 가장 널리 쓰이는 방식은 채팅형 사용자 인터페이스지만, 많은 경우 이것이 최적의 방법은 아닙니다.  소프트웨어 실무자들은 AI 시대에 맞춰 사용자 경험을 새롭게 구상할 필요가 있습니다. AI를 자연스럽게 활용할 수 있는 다양한 사용자 경험 시나리오가 존재하며, 사용자 컨텍스트 전환, 복사 및 붙여넣기, 프롬프트 작성과 같이 채팅에 지나치게 의존할 때 발생하는 몇 가지 문제를 극복할 수 있습니다. 최근 Atlassian Workplace Events 팀을 위해 Forge 앱 https://go.atlassian.com/about-forge-en을 개발했습니다. 이 앱에는 Workplace Events 팀이 competition을 설정할 수 있는 관리자 UI가 포함되어 있습니다. 각 competition에는 제목, 설명, 시작 및 종료 날짜·시간 등 여러 입력 필드가 있으며, 이러한 정보는 자연스럽게 양식을 통해 수집됩니다. image-5.png 앱에 실제로 포함된 양식에는 더 많은 입력 필드가 있어 작성에 시간이 오래 걸립니다. 이를 보완하기 위해 AI가 양식 작성을 도와주는 기능이 추가되었습니다. 양식 상단에는 AI 양식 작성 컨트롤을 표시할 수 있는 토글이 제공됩니다. 이 컨트롤을 통해 사용자는 AI가 양식을 작성하는 데 필요한 몇 가지 기본 매개변수를 지정할 수 있으며, 기본 양식을 사용하는 것보다 훨씬 빠르게 작성할 수 있습니다. image-6.png 사용자가 “Fill with AI” 버튼을 클릭하면 Forge LLM API https://developer.atlassian.com/platform/forge/runtime-reference/forge-llms-api/를 통해 LLM으로 쿼리가 전송됩니다. 이 쿼리에는 기존 양식 데이터와 AI 안내 위젯의 데이터가 포함되며, 경우에 따라 양식의 목적을 설명하기 위한 추가 컨텍스트도 함께 전달됩니다. 쿼리는 LLM이 양식의 각 필드에 대응하는 JSON 객체로 응답하도록 요청하며, 이를 통해 코드가 반환된 값으로 양식을 쉽게 업데이트할 수 있습니다. 다음은 실제 동작 예시입니다: ai-ux-form-completion-1.gif AI 양식 작성 방식은 AI 사용 여부를 명확하게 보여주고, 양식 제출 전에 사용자가 AI 응답을 검토하고 수정할 수 있도록 설계되어 있어 책임 있는 기술 원칙 https://twitter.com/intent/tweet?source=webclient&via=atlassian&text=our%20responsible%20technology%20principles&url=https://www.atlassian.com/blog/developer/ai-user-experience-patterns에도 부합합니다. 양식 작성은 흔히 사용되는 방식이지만, AI를 활용할 수 있는 다른 유형의 사용자 경험도 확인해볼 필요가 있습니다. 아래에서는 사용자 경험을 개선하기 위해 AI를 활용한 네 가지 패턴을 소개하며, 먼저 양식 작성 패턴부터 살펴보겠습니다. AI 양식 자동 완성 개요(Overview): 양식 작성은 번거로운 작업이 될 수 있습니다. 이 패턴은 AI를 활용해 양식 작성을 자동화하는 데 도움을 줍니다. 패턴(The Pattern): 사용자에게 양식이 표시됩니다. 사용자는 양식을 직접 작성하거나 “Fill form with AI” 옵션을 클릭할 수 있습니다. 현재 양식 데이터는 양식을 설명하고 LLM이 필드를 완성할 수 있도록 돕는 일부 컨텍스트와 함께 LLM으로 전송됩니다. LLM에 전달되는 프롬프트는 완성된 양식 값이 JSON 형태로 반환되도록 요청하며 각 구성 요소는 양식 컴포넌트의 고유 ID로 식별됩니다. 이를 통해 UI는 값을 쉽게 업데이트할 수 있습니다. UI에는 사용자가 LLM에 추가적인 안내를 제공할 수 있도록 텍스트 필드나 토글과 같은 위젯을 선택적으로 포함할 수 있습니다. 사용 가능한 컨텍스트의 양에 따라 AI가 양식을 충분히 작성하기 전에 추가적인 수동 컨텍스트(추가 AI 안내 위젯 또는 일부 양식 직접 작성)가 필요한 정도를 결정합니다. 충분한 컨텍스트가 있는 경우 선택 단계로 두기보다는 양식을 자동으로 작성하고 사용자가 수정하도록 하는 방식도 가능합니다. UX 영향(UX Impact): 양식 작성 속도를 높이면서도 제출 전 검토할 수 있는 기능을 제공합니다. 사용 예시(Example usage): 코드 변경 사항을 커밋할 때 커밋 메시지는 변경 내용을 요약해야 합니다. 또한 커밋 메시지 앞에 Jira 작업 항목 키를 붙이는 것이 일반적인 관행인 경우가 많습니다. 이 패턴을 적용하면 AI를 활용해 커밋 메시지 초안을 작성할 수 있습니다. 예측 입력(고스트 텍스트) 완성 개요(Overview): 텍스트 편집 중에 LLM(문법 언어 관리자)의 기능을 활용하여 문장과 단락을 완성합니다. 패턴(The Pattern): AI 기반 IDE는 개발자가 편집하는 위치 근처에서 코드를 생성하여 개발자가 탭 키를 눌러 제안된 코드를 수락할 수 있도록 합니다. 동일한 패턴을 Atlassian 편집기에도 적용할 수 있습니다. Google Docs와 Gmail은 이미 이러한 기능을 제공하고 있으며, 이를 스마트 작성(Smart Compose) 이라고 부릅니다 . UX 영향(UX Impact): 이 패턴은 “low-friction” 상호작용을 가능하게 한다는 점에서 강력한 UX 패턴입니다. AI가 사용자의 다음 행동을 미리 예측하고 사용자는 이를 즉시 수용하거나 계속 입력해 무시할 수 있으며 이후 편집으로 통하여 추가 컨텍스트를 제공할 수도 있습니다. 사용 예시(Example usage): 작업 항목에 댓글을 작성할 때 에디터에는 작업 상세 정보와 이전 댓글이 포함된 컨텍스트가 제공됩니다. 사용자가 새 댓글 작성을 시작하면 AI는 해당 컨텍스트를 기반으로 사용자가 작성하려는 내용을 예측하고 고스트 텍스트 형태로 제안합니다. 선제적 예측 트리거 개요(Overview): 사용자가 프롬프트를 입력할 때까지 기다리는 대신 시스템이 LLM을 활용해 사용자 행동을 분석하고 요청이 있기 전에 도움을 제공합니다. 패턴(The Pattern): LLM은 신호가 약한 사용자 행동을 모니터링하고 사용자가 정보를 이해하고 행동할 수 있도록 비침투적인 제안을 트리거합니다. UX 영향(UX Impact): AI를 반응형 도구에서 능동적인 파트너로 변화시켜, 사용자가 새로운 기능을 어떻게 사용해야 할지 몰라 불안해하는 것과 같은 인지적 부담을 덜어줍니다. 사용 예시(Example usage): 사용자가 복잡한 차트 위에 마우스를 올리면 AI가 자동으로 반응해 “이 데이터를 해석하려는 것 같은데, 요약해 드릴까요?”라는 자연스러운 제안을 표시합니다. 메모리 모듈화 & 워크스페이스 컨텍스트 개요(Overview): LLM이 이전 세션에서 설정된 선호도나 규칙을 자주 ‘잊는’ 문제를 해결하기 위한 패턴입니다. 패턴(The Pattern): UI는 규칙과 스킬로 구성된 계층적 구조를 통해 사용자가 지속 메모리를 관리할 수 있도록 합니다. 하위 레벨은 상위 레벨의 규칙과 스킬을 상속합니다. 규칙은 일관성을 유지하기 위한 수동적 가드레일 역할을 하며 스킬은 AI 에이전트가 특정 스크립트와 도구를 실행할 수 있도록 권한을 부여하는 모듈형 기능입니다. 이러한 규칙과 스킬은 해당 아티팩트 계층과 관련된 모든 AI 쿼리의 컨텍스트에 포함됩니다. UX 영향(UX Impact): 매번 새로운 설명이 필요한 낯선 도구가 아니라, 사용자의 표현 방식과 스타일, 히스토리를 이해하는 장기적인 동료와 함께 일하는 듯한 개인화된 경험을 제공합니다. 사용 예시(Example usage): Jira 스페이스, 에픽, 기능/버그/작업 및 서브태스크로 이어지는 계층 구조는 각 레벨별 규칙과 스킬로 확장될 수 있습니다. 예를 들어 스페이스 레벨 규칙에서는 스프린트가 2주 단위라는 팀 운영 방식을 정의할 수 있습니다. 에픽 레벨 규칙은 프로젝트의 주요 마일스톤을 정의할 수 있으며 에픽 레벨 스킬은 정기적인 회고 생성을 지원할 수 있습니다. 이 패턴들은 아직 더 많은 검증과 보완이 필요하지만, AI를 활용해 사용자 경험을 어떻게 새롭게 설계할 수 있을지에 대한 아이디어를 제공합니다.

main.png
2026/02/26

Rovo로 팀이 업무를 30% 더 빠르게 시작하는 방법

출처 : How Rovo helps teams start work 30% faster - Work Life by Atlassian https://www.atlassian.com/blog/atlassian-engineering/jira-ai-productivity-how-rovo-helps-teams-start-work-30-percent-faster 작성자 :  Michael Siers Sr. Data Scientist, Jira AI 발행일: 2026년 02월 19일 Rovo의 AI 기능을 Jira에 https://www.atlassian.com/software/jira/ai?tab= 활용한 사용자들의 생산성 변화를 파악하기 위해 1년간의 사용 데이터를 분석했습니다.  그 결과 Rovo의 AI 기능을 도입한 사용자들은 업무 시작 속도가 30% 더 빨라졌고, 매달 하루의 생산성 향상을 경험했습니다. 이 추가적인 시간은 회고 진행 https://www.atlassian.com/team-playbook/plays/retrospective, 팀 건강 상태 점검 https://www.atlassian.com/team-playbook/health-monitor 등 다양한 활동 https://www.atlassian.com/team-playbook/plays에 활용할 수 있습니다. 이 글에서는 이러한 결과에 도달하기까지 어떤 분석 단계를 거쳤는지 자세히 소개합니다! image-20260121-025601 (1).png Jira에서 Rovo란 무엇인가요? Rovo https://www.atlassian.com/software/rovo는 300만 명 이상의 사용자가 사용하는 Atlassian의 AI 앱입니다. Rovo는 Atlassian 제품군 전반에서 동작하며 .Jira를 위한 다양한 기능을 제공합니다. 자세한 내용은 아래 데모 영상을 통해 확인해 보세요. <iframe width="640" height="360" src="https://www.youtube.com/embed/0tkL5R8kAJE" title="How to create work items from anywhere using Jira + Rovo AI" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen]]> <iframe width="640" height="360" src="https://www.youtube.com/embed/FjwGvfl6sNk" title="How to build automations in Jira using Rovo AI" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen]]> <iframe width="640" height="360" src="https://www.youtube.com/embed/cBsmFJIqcAE" title="How to add context to Jira work items with Rovo AI" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen]]> <iframe width="640" height="360" src="https://www.youtube.com/embed/7hsoFU2kmxk" title="How to break down large projects in Jira using Rovo AI" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen]]> Jira에서 ‘생산성’을 정의하는 방법과 어려움 Jira는 계획부터 유지관리까지 작업 항목의 전체 라이프사이클과 그 사이의 모든 과정 https://www.atlassian.com/agile/software-development/sdlc을 추적하는 데 사용됩니다. Jira 작업 항목 생성부터 완료까지 걸린 시간, 동료에게 피드백을 요청한 시점부터 해당 피드백을 반영하는 시점까지의 시간 등 각 단계 간 진행에 소요된 시간을 측정하는 다양한 지표가 존재합니다. 업무 항목 라이프사이클에서 두 개의 특정 단계 간 전환을 기준으로 측정했을 때 많은 잠재적 노이즈를 줄일 수 있었습니다. 그래서 생산성을 다음과 같이 정의했습니다: Lead Time to Start - Jira 작업 항목이 생성된 시점부터 “In Progress” 상태로 전환될 때까지 걸린 시간 Rovo가 Jira에 제공하는 AI 기능들이 고객의 이러한 지표를 크게 개선한다는 가설을 세웠습니다. 또한 다음과 같은 보조 지표를 사용해 동일한 분석을 반복했습니다: Number of work items moved into In Progress - “In Progress” 상태로 이동한 Jira 작업 항목의 수 이 두 가지 지표를 정확히 정의하려면 Jira에서 Status와 Status category의 차이를 이해하는 것이 중요합니다. Jira 보드에는 다양한 Status가 있으며 이는 보드 화면에서 컬럼으로 표시됩니다. 각 상태는 “To Do”, “In Progress”, “Done”이라는 세 가지 카테고리 중 하나에 매핑됩니다. 위 두 지표는 Jira 작업 항목이 Status category “To Do”에서 “In Progress”로 처음 이동한 시점을 기준으로 측정합니다. 작업 항목을 “In Progress”에서 다시 “To Do”로 이동시키는 것도 가능하기 때문에 “To Do”에서 “In Progress”로 이동하는 첫 이동 시점을 측정 대상으로 선택했습니다. image-20260210-000924-768x676.png <status category를 활용해 Lead Time to Start를 측정하는 방식을 시각적으로 보여주는 예시> 연구 설계 대조군과 실험군 두 그룹을 비교하기 위해 준실험(quasi-experiment) 접근 방식을 사용했습니다. 대조군(Control): Jira에서 Rovo AI 기능을 전혀 사용하지 않은 사용자 실험군(Test): Jira에서 Rovo AI 기능을 정기적으로 사용하게 되었으며 45일 동안 그 상태를 유지한 사용자 준실험(Quasi-experiments https://en.wikipedia.org/wiki/Quasi-experiment)은 전통적인 통계 실험과 중요한 차이가 있습니다. 바로 실험군과 대조군에 무작위 배정이 이루어지지 않는다는 점입니다. 전통적인 실험에서는 이러한 무작위성이 공정한 표본을 만들어 주지만 준실험에서는 표본을 공정하게 만들기 위해 여러 변수를 통제해야 합니다. 이러한 이유로 대조군과 실험군 모두에 다음과 같은 필터를 적용했습니다: Jira에서 최소 180일 이상의 사용 이력이 있는 사용자가 생성한 작업 항목만 포함했습니다. Jira Premium 또는 Enterprise의 유료 라이선스를 사용하는 사용자만 포함했습니다. 좌석 수(seat size)에서 발생할 수 있는 이상치를 줄이기 위해 50석에서 1,000석 사이의 유료 라이선스만 포함했습니다. 이상치를 줄이기 위해 윈저화(winsorization https://en.wikipedia.org/wiki/Winsorizing) 기법을 적용했습니다. 이는 Lead Time to Start 값의 하위 10%와 상위 10% 구간을 제외하는 간단한 방법입니다. Atlassian에서는 사용자가 Jira를 창의적인 방식으로 활용하는 경우가 많아 매우 극단적인 이상치가 발생하는 경우가 있어 이러한 처리가 자주 필요합니다. 그다음 정규화된 타임라인을 정의했습니다. “Day 0”는 사용자가 Rovo Jira AI 사용자가 된 날을 의미하며 “Day 45”는 그로부터 45일 후를 의미합니다. 여기서 한 가지 의문이 생길 수 있습니다. Rovo Jira AI를 한 번도 사용하지 않은 대조군의 경우 Day 0를 어떻게 정의했는지가 궁금할 수 있습니다. 두 그룹을 공정하게 비교하기 위해 대조군 사용자에게도 Day 0를 부여할 필요가 있었습니다. 대조군과 실험군의 샘플 수가 동일했기 때문에 실험군의 모든 “Day 0” 날짜를 가져와 랜덤으로 섞은 뒤 이를 대조군 사용자에게 할당했습니다. 이렇게 함으로써 비교되는 날짜가 동일한 분포에서 무작위로 선택되도록 했습니다. 대조군 사용자는 Rovo Jira AI 사용자가 된 적이 없기 때문에 실험군 사용자의 날짜를 랜덤으로 섞어 대조군 사용자에게 할당했습니다. image-20260121-044856-768x396.png <가설을 보여주는 개념도> 방법론의 마지막 단계에서는 Day 0부터 Day 45까지의 상대적 변화를 두 그룹 간에 비교했습니다. 유의수준 0.05와 검정력 0.8을 적용한 양측 t-검정을 사용해 두 그룹을 비교했습니다. 분석 결과 Rovo AI를 Jira에 도입한 사용자는 45일 후 "진행 중" 상태로 이동한 작업 항목 수가 평균 30% 증가한 것으로 나타났습니다. 이는 통계적으로 유의미한 결과(p<0.01)입니다. 반면, Rovo AI를 전혀 사용하지 않은 사용자는 이러한 차이를 경험하지 못했습니다. 또한 Jira에서 Rovo AI를 45일 동안 사용한 사용자들은 Rovo AI를 전혀 도입하지 않은 사용자들과 비교했을 때 Lead Time to Start의 상대적 변화에서 통계적으로 유의미한 차이를 보였습니다. 두 그룹 모두 Lead Time to Start가 감소했지만 Rovo AI 도입 사용자들은 대조군 대비 약 1.4배 더 큰 감소 효를 보였습니다. 다시 말해, Jira에서 Rovo AI를 도입한 사용자들은 Lead Time to Start가 35% 단축되는 효과를 경험했습니다. 일반적인 사용자 기준으로 보면, 이는 28일마다 약 하루 정도의 시간을 절약하는 효과에 해당합니다. 앞으로의 계획 이는 Jira AI가 실제 환경에 미치는 영향을 측정하는 첫 번째 단계일 뿐입니다. 앞으로는 작업 항목 작성이 더 잘되고 있는지, 보드 관리가 더 쉬워졌는지, 스프린트가 더 원활하게 운영되고 있는지와 같은 질문들을 살펴볼 예정입니다. 신중한 실험과 실제 고객 사용 데이터를 결합해 단순한 기대를 넘어 모든 새로운 AI 기능이 팀에 실질적인 가치를 제공하도록 하는 것이 목표입니다. 이 과정을 계속 지켜보거나 직접 기능을 사용해 보고 싶다면 Jira에서 Rovo에 대해 더 알아보세요 https://www.atlassian.com/software/jira/ai.

main.png
2026/01/16

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

안녕하세요, 커브입니다. 새해가 밝았습니다. 2026년에도 고객 여러분의 업무에 도움이 되는 소식과 정보를 꾸준히 전해드리겠습니다.  이번 1월 뉴스레터에서는 Atlassian 제품과 관련해 주요 업데이트를 정리했습니다. Atlassian Data Center 제품군 가격 인상 및 신규 고객 대상 판매 종료 일정, 그리고 Confluence Cloud 레거시 편집기(Legacy Editor) 지원 종료 일정을 함께 안내드리니, 적용 시점과 영향 범위를 미리 확인해보시기 바랍니다. 인기 컨텐츠 신규 컨텐츠 Jira Cloud 스페이스 만들기 https://confluence.curvc.com/spaces/ASD/pages/109642041/Jira+Cloud+%EC%8A%A4%ED%8E%98%EC%9D%B4%EC%8A%A4+%EB%A7%8C%EB%93%A4%EA%B8%B0 Jira Cloud 전체/삭제/보관 스페이스 확인하기 https://confluence.curvc.com/spaces/ASD/pages/137594528/Jira+Cloud+%EC%A0%84%EC%B2%B4+%EC%82%AD%EC%A0%9C+%EB%B3%B4%EA%B4%80+%EC%8A%A4%ED%8E%98%EC%9D%B4%EC%8A%A4+%ED%99%95%EC%9D%B8%ED%95%98%EA%B8%B0 Jira Cloud 자동화 (Automation) 작업자(Actor) 변경하기 https://confluence.curvc.com/spaces/ASD/pages/81664465/Jira+Cloud+%EC%9E%90%EB%8F%99%ED%99%94+Automation+%EC%9E%91%EC%97%85%EC%9E%90+Actor+%EB%B3%80%EA%B2%BD%ED%95%98%EA%B8%B0 Atlassian Cloud 계정 관리자 접근 권한 부여하기 https://confluence.curvc.com/spaces/ASD/pages/81664170/Atlassian+Cloud+%EA%B3%84%EC%A0%95+%EA%B4%80%EB%A6%AC%EC%9E%90+%EC%A0%91%EA%B7%BC+%EA%B6%8C%ED%95%9C+%EB%B6%80%EC%97%AC%ED%95%98%EA%B8%B0 Atlassian Guard - 도메인 확인하기 https://confluence.curvc.com/spaces/ASD/pages/81664950/Atlassian+Guard+-+%EB%8F%84%EB%A9%94%EC%9D%B8+%ED%99%95%EC%9D%B8%ED%95%98%EA%B8%B0 JSM Virtual Agent로 고객 지원 자동화하기 https://confluence.curvc.com/spaces/ASD/blog/2026/01/08/300351625/JSM+Virtual+Agent%EB%A1%9C+%EA%B3%A0%EA%B0%9D+%EC%A7%80%EC%9B%90+%EC%9E%90%EB%8F%99%ED%99%94%ED%95%98%EA%B8%B0 Deep Research v2: Atlassian의 차세대 AI 리서치 엔진 https://confluence.curvc.com/spaces/ASD/blog/2026/01/08/300351630/Deep+Research+v2+Atlassian%EC%9D%98+%EC%B0%A8%EC%84%B8%EB%8C%80+AI+%EB%A6%AC%EC%84%9C%EC%B9%98+%EC%97%94%EC%A7%84 SonarQube Advanced Security 개요 https://confluence.curvc.com/spaces/ASD/pages/300351654/SonarQube+Adavanced+Security+%EA%B0%9C%EC%9A%94 JFrog AI-Native Enterprise, AI 소프트웨어 공급망의 새로운 패러다임 https://confluence.curvc.com/spaces/ASD/pages/300351662/JFrog+AI-Native+Enterprise+AI+%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4+%EA%B3%B5%EA%B8%89%EB%A7%9D%EC%9D%98+%EC%83%88%EB%A1%9C%EC%9A%B4+%ED%8C%A8%EB%9F%AC%EB%8B%A4%EC%9E%84 JFrog 5단계로 섀도우 AI를 탐지하고 제거하는 방법 https://confluence.curvc.com/spaces/ASD/pages/300351667/5%EB%8B%A8%EA%B3%84%EB%A1%9C+%EC%84%80%EB%8F%84%EC%9A%B0+AI%EB%A5%BC+%ED%83%90%EC%A7%80%ED%95%98%EA%B3%A0+%EC%A0%9C%EA%B1%B0%ED%95%98%EB%8A%94+%EB%B0%A9%EB%B2%95 2026년 01월 1.png https://confluence.curvc.com/spaces/ASD/blog/2026/01/16/300351670/2026%EB%85%84+Atlassian+Data+Center+%EA%B0%80%EA%B2%A9+%EC%9D%B8%EC%83%81+%EC%95%88%EB%82%B4 2026년 01월 2.png https://confluence.curvc.com/spaces/ASD/blog/2025/12/29/295862439/%EA%B3%B5%EC%A7%80+Confluence+Legacy+Editor+%EC%A2%85%EB%A3%8C+%EC%95%88%EB%82%B4

main.png
2026/01/16

2026년 Atlassian Data Center 가격 인상 안내

2025년 2월 17일부터 Atlassian Data Center 제품 군의 가격이 인상될 예정입니다. 인상되는 제품군 정보는 다음과 같습니다. Jira Software Confluence Jira Service Management 가격 인상 외에도 무제한 사용자 요금제 적용 기준(데이터 센터 제품별로 상이함)을 상향 조정하고 새로운 User/Agent 티어를 도입할 예정입니다.  자세한 내용은 아래 표를 참조하세요. 가격 인상 제품 목록 Advantage Jira Software 0~1,000명 사용자: 15% 인상 1,001~5,000명 사용자: 20% 인상 5,001명 이상의 사용자: 25% 인상 Jira Software 모든 사용자 등급:  30% 인상 Confluence 0~1,000명 사용자: 15% 인상 1,001~5,000명 사용자: 20% 인상 5,001명 이상의 사용자: 25% 인상 Confluence 이미 정가에 판매 중입니다. JSM 0~1,000명의 에이전트: 15% 인상 1,001~5,000명의 에이전트: 20% 인상 5,001명 이상의 에이전트: 25% 인상 JSM 이미 정가에 판매 중입니다.  사용자 티어 변경 데이터센터 사용자 티어 변경 제품 현재 사용자 등급 구조 새로운 사용자 등급 구조 Jira Software 사용자 등급별 최대 한도는 50,000석 Unlimited tier: 50,001석부터 시작 60,000석 ~ 150,000석 신규 티어 추가 새로운 등급은 각각 다음과 같습니다.10,000좌석 증분 Unlimited tier: 150,001석부터 시작 Confluence 사용자 등급별 최대 한도는 40,000석 Unlimited tier: 40,001석부터 시작 45,000석~150,000석까지 신규 티어 추가 새로운 등급은 각각 다음과 같습니다.10,000좌석 증분 Unlimited tier: 150,001석부터 시작 JSM 사용자(에이전트) 등급의 최대 한도는 14,000석 Unlimited tier: 14,001석부터 시작 15,000석~20,000석 규모의 User(Agent) 신규 티어 추가 새로운 등급은 1,000석 단위로 증분됩니다. Unlimited tier: 20,001석부터 시작됩니다. Atlassian 공지는 다음 링크에서 확인하실 수 있습니다. https://www.atlassian.com/ko/licensing/future-list-pricing/data-center-pricing/faqs#general-questions https://www.atlassian.com/ko/licensing/future-list-pricing/data-center-pricing/faqs#general-questions 더불어 2026년 3월 30일부터 Atlassian Data Center 신규 판매가 중지됩니다. 종료 일정 및 정보는 다음 페이지에서 확인하시기 바랍니다. Atlassian Data Center 종료 안내 https://confluence.curvc.com/spaces/ASD/blog/2025/09/10/278036482/Atlassian+Data+Center+%EC%A2%85%EB%A3%8C+%EC%95%88%EB%82%B4

main.png
2026/01/08

Deep Research v2: Atlassian의 차세대 AI 리서치 엔진

출처: Deep Research v2: Inside Atlassian’s Next-Gen AI Research Engine - Work Life by Atlassian https://www.atlassian.com/blog/artificial-intelligence/rovo-deep-research-v2 작성자: Xincheng You 외 Atlassian Machine Learning & Engineering Team 발행일: 2025년 12월 17일 AI로 재정의하는 자동화 리서치 2024년 6월 Atlassian은 Rovo Deep Research를 처음 선보이며 하나의 방향성을 제시했습니다. SaaS와 Atlassian 전반에 흩어진 정보를 연결해, 인용 가능한 임원급 리포트를 몇 분 안에 생성하는 AI 리서처를 제공하겠다는 것이었습니다. 이후 Deep Research는 단순 요약을 넘어 전략 수립 리스크 분석 프로세스 개선처럼 의사결정 난도가 높은 질문에 활용되기 시작했습니다. 사용 사례가 확대되면서, 기존 접근 방식에서 개선이 필요한 지점 또한 점차 분명해졌습니다. Deep Research v2는 이러한 관찰을 바탕으로 사람이 실제로 조사하는 방식에 더 가까운 리서치 엔진으로 설계되었습니다. What’s New? 실제 업무 환경에서 Deep Research를 평가한 결과, 몇 가지 공통적인 패턴이 확인되었습니다. 리포트는 기술적으로 정확했지만, 깊이가 충분하지 않거나 맥락과 다른 관점을 충분히 반영하지 못한 경우가 있었습니다. 또한 단 한 번의 실행으로 끝나는 fire-and-forget(실행 후 무시) 방식의 워크플로우는, 초기 리서치 계획이 적절하지 않을 경우 과정 중 이를 조정하기 어렵다는 한계를 드러냈습니다. Deep Research v2에서는 이러한 문제를 해결하기 위해 워크플로우가 재설계되었습니다. 새로운 증거가 나타날 때마다 반복적으로 탐색·종합·수정하는 흐름이 반영되었으며, 다중 턴 인터랙션을 통해 사용자가 리서치 과정에 보다 적극적으로 개입할 수 있도록 개선되었습니다. 질문 한번으로는 부족한 리서치 “우리 AI 전략의 리스크는 무엇인가요?” “사고 대응 프로세스의 가장 큰 공백은 무엇인가요?” 이와 같은 질문은 범위가 넓어, 실제 리서치에서는 추가적인 확인이 필요합니다. 어떤 제품을 대상으로 하는지, 어떤 기간을 의미하는지, 누구를 위한 결과물인지를 명확히 해야 합니다. Deep Research v2에서는 이 단계를 워크플로우에 명시적으로 포함했습니다. 리서치 시작 전 범위, 제약 조건, 성공 기준을 명확히 하는 질문을 먼저 제시함으로써 결과가 사용자의 실제 관심사에 보다 정확히 맞춰지도록 했습니다. V1 워크플로우의 구조적 한계  기존 v1 워크플로우는 사실상 fire-and-forget 구조였습니다. 초기 계획이 잘못 설정될 경우 결과를 끝까지 기다린 뒤 처음부터 다시 시작해야 하는 상황이 발생했습니다. v2에서는 리서치 계획 자체가 공유 가능한 산출물로 다뤄집니다. 구조화된 리서치 플랜 제안 섹션, 우선순위, 관점 수정 승인 이후 본격적인 리서치 실행 이를 통해 리서치 초기 단계에서 방향을 조정할 수 있게 되었고, 불필요한 재작업이 크게 줄어들었습니다. 통찰력 및 심층성이 부족한 리포트 기존 리포트는 사실 전달에는 충실했지만, 비교, 맥락, 리스크, 의사결정 포인트가 충분히 드러나지 않은 경우가 있었습니다. Deep Research v2는 단순한 정보 요약을 목표로 하지 않습니다. 질문에 답하는 것을 넘어 다음에 무엇을 해야 하는지를 고민하게 만드는 리포트를 지향합니다. 이를 위해 더 깊은 탐색, 관점 비교, 패턴 분석, 그리고 실행 가능한 권고안 도출에 초점을 맞추도록 설계되었습니다. 내부 지식 활용의 한계 전략 수립, 시장 분석, 기술 평가는 내부 문서만으로는 충분하지 않은 경우가 많습니다. 공개 리서치, 벤더 문서, 업계 뉴스와 같은 외부 정보가 함께 고려되어야 합니다. Deep Research v2는 Atlassian 데이터와 연결된 SaaS 정보뿐 아니라, 필요에 따라 퍼블릭 웹 정보까지 함께 활용할 수 있도록 확장되었습니다. 이를 통해 내부 맥락과 외부 시그널이 결합된 엔드투엔드 리서치가 가능해졌습니다. 새로운 아키텍처 Deep Research v2의 핵심에는 대규모 언어 모델(LLM)의 추론 능력을 활용하는 중앙 오케스트레이터 에이전트가 있습니다. 기존 세대의 획일적이고 경직된 파이프라인을 넘어, 상황에 따라 유연하게 대응하는 적응형 지능(Adaptive Intelligence) 기반 구조가 도입되었습니다. 오케스트레이터는 전체 대화 맥락 속에서 각 질문을 분석한 뒤, 복잡도에 따라 즉각적인 응답 또는 다단계·반복적 리서치 프로세스를 실행합니다.  https://atlassianblog.wpengine.com/wp-content/uploads/2025/12/image-20251212-214101-768x938.png Adaptive Orchestration: 쿼리에서 리포트까지 시스템의 중심에는 오케스트레이터 에이전트가 위치합니다. 오케스트레이터는 사용자 맥락, 대화 이력, 전문 에이전트의 역량을 포함한 동적 프롬프트를 구성합니다. 이를 바탕으로 직접 답변할지, 전문 에이전트에게 위임할지를 판단하는 구조화된 판단 결과가 생성됩니다. 이러한 맥락 기반 라우팅을 통해 단순한 질문에는 빠른 응답이 제공되고 복잡한 요청에는 깊이 있는 분석과 다각적 관점이 적용됩니다. 전문 에이전트와 반복적 리서치 복잡한 리서치 작업은 세 가지 전문 에이전트로 분리됩니다. Grounding Agent 사용자 환경과 맥락을 파악하고 명확화 질문을 생성 Planning Agent 리서치 목표를 구조화된 계획으로 변환 Execution Agent 실제 리서치 수행과 반복 개선 담당 특히 Execution Agent에는 v2의 핵심 기술이 집약되어 있습니다. Execution Agent의 주요 혁신 Self-Evolution Engine: 발견된 정보에 따라 쿼리를 진화시키고 종료 시점을 판단 Dynamic Outline Optimization: 새로운 증거에 맞춰 리포트 구조를 재정렬 Memory Bank Writing: 모든 주장과 섹션별 출처를 저장해 추적성 확보 Test-Time Diffusion: 초안을 노이즈로 간주하고 집중 리서치를 통해 정제 그 결과 모든 문장이 출처로 연결되는 감사 가능한 리포트가 생성됩니다. 성능, 확장성, 안정성 Deep Research v2는 병렬 쿼리 실행을 통해 처리 속도를 향상시키는 동시에 모든 주장에 대한 출처 추적을 가능하게 해 투명성과 신뢰성을 확보합니다. 구성 가능성과 관측성 모델 선택, 실행 파라미터, 기능 플래그를 코드 변경 없이 조정할 수 있어 A/B 테스트, 단계적 롤아웃, 사용 맥락에 따른 최적화를 효과적으로 지원합니다. 또한 구조화된 로그, 지연 시간 지표, 토큰 사용량 모니터링을 통해 시스템 동작을 세밀하게 추적할 수 있도록 설계되었습니다. 비동기 실행과 복구 가능한 스트리밍 Deep Research 작업은 실행 시간이 길고 연산량이 큰 경우가 많습니다. 이에 따라 v2에서는 메인 웹 요청 경로에서 분리된 비동기 실행 구조가 도입되었습니다. 웹 서버는 작업을 백그라운드 워커 풀로 전달하고 진행 상황만 스트리밍 형태로 전달합니다. 이를 통해 사용자 경험은 실시간처럼 유지되며 리서치 엔진은 백그라운드에서 모든 과정을 수행합니다. 전용 워커 플릿을 통해 웹 서버 자원 점유를 방지하고 요청 급증 상황에서도 전체 시스템 안정성을 유지할 수 있도록 설계되었습니다. 또한 재연결 가능한 스트리밍을 지원해 네트워크 오류나 기기 전환 상황에서도 동일한 리서치 세션을 이어갈 수 있습니다. 평가 전략과 결과 I.  Reference 기반 평가 전략 RACE 프레임워크 기반 평가(details https://arxiv.org/abs/2506.11763) Deep Research의 실제 활용 성능을 평가하기 위해, 장문 리서치 평가에 특화된 RACE 프레임워크를 주요 기준으로 활용하고 있습니다. RACE는 각 리포트를 다음 네 가지 관점에서 평가합니다. Comprehensiveness 리포트가 주제의 핵심 영역을 충분히 다루고 있는지, 주요 내용이 누락되지 않았는지를 평가합니다. Insight 단순한 사실 나열을 넘어 원인, 영향, 트렌드를 분석하고 의미 있는 시사점을 제공하는지를 평가합니다. Instruction Following 리서치 브리프를 얼마나 충실히 따르고, 사용자의 질문에 직접적으로 답하고 있는지를 측정합니다. Readability 구조가 명확하고 논리 흐름이 자연스러워 이해관계자가 쉽게 내용을 소화할 수 있는지를 평가합니다. RACE의 핵심적인 특징은 단일한 고정 평가 기준을 적용하지 않는다는 점입니다. 질의의 성격에 따라 과제별 가중치와 세부 평가 기준을 동적으로 생성해, 해당 작업에서 “좋은 결과”가 무엇인지를 상황에 맞게 정의합니다. 질의별 가중치 및 평가 기준 예시 다음과 같은 질의 https://github.com/Ayanami0730/deep_research_bench/tree/main/data를 예로 들 수 있습니다. “AI와의 상호작용이 인간의 대인관계에 어떤 영향을 미치는지를 논의하시오. 특히 AI가 개인들이 서로 관계를 맺는 방식과 그 이유를 근본적으로 어떻게 변화시킬 수 있는지를 고려하시오. 이 과제에 대해 RACE는 평가 항목별로 서로 다른 가중치를 부여합니다. https://atlassianblog.wpengine.com/wp-content/uploads/2025/12/screenshot-2025-12-18-at-10.21.30-am-760x228.png 아래는 Insight(40%) 항목에 대해 RACE가 생성한 세부 평가 기준(rubric)의 예시입니다.   https://atlassianblog.wpengine.com/wp-content/uploads/2025/12/screenshot-2025-12-18-at-10.21.56-am-600x321.png 벤치마크 구성 Deep Research는 공개 벤치마크와 내부 벤치마크를 함께 활용해 평가됩니다. 이를 통해 개방적이고 경쟁적인 환경에서의 성능과, 실제 엔터프라이즈 업무 흐름에서의 활용성을 동시에 검증합니다. 공개 벤치마크 – DeepResearch Bench DeepResearch Bench는 딥 리서치 시스템 평가를 위해 설계된 공개 벤치마크입니다. 도메인 전문가가 작성한 100개의 박사급 연구 과제로 구성되어 있으며, 딥 리서치 제품 간의 공정한 비교를 목표로 합니다. 현재 Deep Research의 점수는 50.74점으로, 리더보드 기준 4위에 해당합니다. https://huggingface.co/spaces/muset-ai/DeepResearch-Bench-Leaderboard https://huggingface.co/spaces/muset-ai/DeepResearch-Bench-Leaderboard https://atlassianblog.wpengine.com/wp-content/uploads/2025/12/image-20251212-235527-600x348.png\ 내부 벤치마크 – 엔터프라이즈 리포트 엔터프라이즈 환경에서 Deep Research가 실제로 어떻게 사용되는지를 평가하기 위해, 사내 Confluence에 축적된 고품질 리포트 기반 내부 벤치마크를 운영하고 있습니다. 이 리포트들에 역 프롬프트 엔지니어링(reverse prompt engineering)을 적용해, 실제 기업 업무 흐름을 반영한 리서치 질문으로 변환합니다. 이를 통해 Deep Research가 일상적인 엔터프라이즈 의사결정 과정에서 요구되는 리서치 과제를 얼마나 잘 수행하는지를 평가합니다. 대표적인 활용 사례 시장 및 경쟁 분석 예: “FY25 Q4 기준, 주목해야 할 시장 및 인재 트렌드는 무엇이며 이러한 변화가 채용 및 비즈니스 전략에 어떤 영향을 미칠 수 있는가?” 분기 및 임원 보고용 요약 예: “FY26 Q1 ‘State of Atlassian’을 종합적으로 요약·분석하고, 창업자 관점, 회사 차원의 OKR, 주요 고객 성과, 핵심 전환 과제의 진행 상황과 도전 과제를 포함해 AI 및 클라우드 전략 관점에서 향후 방향성을 설명하시오.” 실제 이해관계자에게 전달되는 결과물과 동일한 수준의 기타 임원 보고용 리포트 이 데이터셋에 대해 RACE 프레임워크를 적용해 모델이 생성한 리포트를 평가한 결과, Deep Research의 RACE 점수는 62.72점으로 나타났습니다. RACE 기준에서 50점 이상은 인간이 작성한 기준 리포트보다 높은 품질을 의미하며, 이는 생성된 리포트가 해당 벤치마크에서 기존 인간 작성 리포트를 이미 상회하고 있음을 시사합니다. 공개 벤치마크와 엔터프라이즈 중심의 내부 벤치마크를 함께 활용함으로써, Deep Research의 평가 전략은 산업 표준 성능과 실제 업무 활용 품질을 동시에 검증하도록 설계되었습니다. 참조 기반 벤치마크 요약 https://atlassianblog.wpengine.com/wp-content/uploads/2025/12/screenshot-2025-12-18-at-10.23.19-am-600x517.png II. Reference-Free 평가 전략 Side-by-Side 비교 평가 참조 기반 벤치마크 외에도, 경쟁사의 Deep Research 제품과 참조 없이(reference-free) 결과를 직접 비교하는 병렬 평가(side-by-side evaluation)를 함께 수행합니다. 각 리서치 과제에 대해 다음과 같은 방식으로 평가가 진행됩니다. Deep Research를 사용해 리포트 생성 경쟁 제품(예: ChatGPT Deep Research)으로 동일 과제 리포트 생성 두 결과물을 LLM 판정자 기반 승 / 무 / 패(win / tie / lose) 프레임워크로 비교 이 방식은 사용자가 실제로 두 결과물을 나란히 비교해 선택하는 상황을 모사합니다. 이를 통해 단순 점수 비교가 아닌, 실제 선호도 관점에서의 품질 차이를 측정합니다. DeepConsult 평가 DeepConsult https://github.com/youdotcom-oss/ydc-deep-research-evals/tree/main/datasets/DeepConsult는 시장 분석, 투자 기회 평가, 산업 분석, 재무 모델링 및 평가, 기술 트렌드 분석, 전략적 비즈니스 기획 등 실제 컨설팅 업무에 가까운 과제를 폭넓게 포함한 데이터셋입니다. 주요 과제 유형 시장 분석 투자 기회 평가 산업 분석 재무 모델링 및 평가 기술 트렌드 분석 전략적 비즈니스 기획 이 데이터셋을 활용해 Deep Research와 ChatGPT Deep Research를 side-by-side 환경에서 직접 비교하고, LLM 판정자가 각 과제별로 더 우수한 결과물을 선택합니다. 품질 비교 요약 https://atlassianblog.wpengine.com/wp-content/uploads/2025/12/screenshot-2025-12-18-at-10.23.48-am-600x138.png DeepConsult 기준 side-by-side 평가에서, Deep Research 리포트는 ChatGPT Deep Research 대비 77%의 승률을 기록했습니다. 이는 다수의 비교 상황에서 LLM 기반 판정자가 Deep Research의 결과물을 더 우수하다고 판단했음을 의미하며, 실제 의사결정 환경에서도 일관되게 높은 품질의 리포트가 제공되었음을 보여줍니다. https://atlassianblog.wpengine.com/wp-content/uploads/2025/12/image-20251212-235606-600x348.png 앞으로의 Deep Research Deep Research v2는 완성이 아니라 새로운 기준선으로 제시됩니다. 실행 가능한 전문가 수준의 권고안 강화 단순한 정보 제공을 넘어, 트레이드오프를 명확히 제시하고 구체적인 선택지와 다음 단계를 드러내는 리포트를 지향합니다. 사실 정확성과 인용 품질을 검증하는 가드레일 강화 핵심 주장과 출처 간의 연결성을 체계적으로 검증해, 근거가 부족한 응답보다 검증되고 인용이 명확한 결과를 우선합니다. ADF 기반 시각적 구조와 데이터 시각화 확대 Atlassian Document Format(ADF)과의 통합을 통해 시각적 구조를 강화하고, 데이터 분석 결과를 차트와 그래프로 표현해 인사이트를 더 쉽게 전달하도록 개선이 이어지고 있습니다. Deep Research는 단순한 AI 기능을 넘어 팀의 사고와 의사결정을 확장하는 연구 파트너로 발전하고 있습니다. 참고 링크 How Rovo Deep Research works – Work Life by Atlassian How Rovo Deep Research works https://www.atlassian.com/blog/atlassian-engineering/how-rovo-deep-research-works Introducing Rovo Deep Research, grounded on your data – Work Life by Atlassian https://twitter.com/intent/tweet?source=webclient&via=atlassian&text=Introducing%20Rovo%20Deep%20Research,%20grounded%20on%20your%20data%20%E2%80%93%20Work%20Life%20by%20Atlassian&url=https://www.atlassian.com/blog/artificial-intelligence/rovo-deep-research-v2

main.png
2026/01/08

JSM Virtual Agent로 고객 지원 자동화하기

출처 Automating Customer Support with JSM Virtual Agent - Work Life by Atlassian https://www.atlassian.com/blog/atlassian-engineering/automating-customer-support-with-jsm-virtual-agent 작성자: Abhishek Rana (Senior Software Engineer), Rajat Gupta (Senior Machine Learning Engineer) 발행일: 2025년 11월 24일 Atlassian의 Jira Service Management(JSM) Virtual Agent가 AI를 활용해 고객 지원을 자동화하고, 채팅 워크플로우를 간소화하며, 전 세계 팀에 더 빠르고 정확한 문제 해결 경험을 제공합니다. Introduction 고객 지원은 빠르게 진화하고 있으며, 그 중심에는 자동화가 있습니다. Jira Service Management(JSM) 팀은 AI를 활용해 지원 프로세스를 간소화하고, 사용자에게 더 빠르고 정확한 응답을 제공하기 위해 지속적으로 노력해 왔습니다. 이 글에서는 JSM Virtual Agent를 구축해 온 과정과 아키텍처, 그리고 실제로 만들어내고 있는 성과에 대해 소개합니다. JSM이란? Jira Service Management(JSM)는 Atlassian의 AI 기반 서비스 관리 솔루션입니다. JSM을 통해 팀은 고객 요청을 손쉽게 접수하고, 추적하며, 관리하고, 해결할 수 있습니다. 고객은 다음과 같은 다양한 채널을 통해 요청을 제출할 수 있습니다. 이메일 헬프 센터 임베디드 위젯 Slack, Microsoft Teams와 같은 서드파티 앱 https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/082012c9-10fd-41bf-a708-5dcb3eaa5149-1536x918.png JSM 활용 사례 IT 지원 팀 기술 문제 해결 요청 신규 소프트웨어 접근 권한 요청 처리 인사(HR) 팀 복지, 급여, 사내 정책 관련 문의 대응 JSM Chat 개요 JSM Chat의 간단한 데모를 살펴보겠습니다. 아래 예시처럼 고객이 JSM 헬프 센터를 통해 요청을 등록하면, Virtual Agent(VA) 봇이 먼저 문제 해결을 시도합니다. 봇이 해결하지 못할 경우, 사용자는 사람 상담원에게 이관할 수 있으며, 이 과정에서 JSM 티켓이 자동으로 생성됩니다. 이 데모는 가상 에이전트와 실제 상담원 간의 매끄러운 전환을 보여주며, 고객이 항상 필요한 도움을 받을 수 있도록 보장합니다. https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/c65d938d-d7dd-4e0e-9b5b-54a06d96f9f8.gif 채팅 아키텍처의 진화 Before 이전의 채팅 백엔드는 여러 한계를 가지고 있었습니다. 가장 큰 문제 중 하나는 채널별로 봇 응답이 일관되지 않았다는 점입니다. 예를 들어 웹 기반 인터페이스인 Portal과 Help Center는 서로 다른 백엔드를 사용하고 있었습니다. Portal: Intent Flow만 지원 Help Center: AI 답변만 지원 AI 답변은 Atlassian 자체 LLM 모델 또는 OpenAI와 같은 서드파티 LLM을 활용해 생성되었습니다. Intent Flow는 문자열 벡터화를 통한 유사도 매칭 방식으로 동작하며, 관리자가 트리 구조의 흐름을 사전에 설정할 수 있었습니다. 모든 채널에서 AI 답변을 제공하려면 총 6개의 서로 다른 백엔드를 수정해야 했고, 이는 10명 규모의 개발팀에게 매우 큰 부담이었습니다.    https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/6aa8050c-9852-4128-a5c2-7e846430f1dd.png <이전의 JSM Chat 아키텍처> Now 이러한 문제를 해결하기 위해 채팅 아키텍처를 전면 재설계했습니다. 채널 분류 (Channel Categorization) 고객 채널을 스트리밍 채널과 비스트리밍 채널로 구분했습니다. 스트리밍 채널 (Help Center, Portal 등) → AI 응답을 실시간으로, 한 글자씩 스트리밍하여 사용자에게 즉시 전달 비스트리밍 채널 (Slack, MS Teams 등) → AI 응답을 모두 생성한 뒤 한 번에 전송 → 실시간 스트리밍을 지원하지 않는 채널 특성에 최적화 통합 오케스트레이터 (Unified Orchestrator) 모든 채널에 대해 단일 오케스트레이터 서비스를 도입했습니다. Slack, Help Center, Portal 등 어떤 채널에서 요청이 들어오든, 오케스트레이터가 이를 일관된 로직으로 처리하고 동일한 품질의 응답을 생성합니다. 이를 통해 채널별 구현 복잡도를 줄이고, 응답 생성 방식을 표준화했습니다. 데이터 저장 (Data Storage) 다음과 같은 대화 관련 데이터는 DynamoDB에 안전하게 저장됩니다. 사용자 메시지 AI 응답 핸들러 정보 티켓 연결 정보 모든 데이터는 데이터 레지던시 정책을 준수하도록 설계되었습니다. https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/67df1cf7-aa0e-445f-9cea-70bc960f1e65-600x401.png  <현재 JSM Chat 아키텍처> 이 다이어그램은 스크립트 기반 응답에서 고도화된 AI 기반 시스템으로 발전한 과정을 보여줍니다. 각 단계는 고객 요청을 더 정확하고 효율적으로 이해하고 해결하기 위한 도약을 의미합니다. AI 심층 분석: Virtual Agent의 동작 방식 심층 분석: 라우팅 전략 https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/31ec345c-deb0-445f-8c41-5ed28e199206-600x651.png 라우팅 전략 VA(가상 에이전트)가 활성화된 고객의 경우, (현재는 Atlassian Premium 고객 대상), 먼저 Intent 매칭 여부를 확인합니다. VA가 비활성화된 경우, 즉시 사람 상담원으로 이관하고 JSM 티켓을 생성합니다. VA가 활성화되어 있고 신뢰도가 높은 Intent가 감지되면, Intent 메시지(Intent Message)를 바로 제공합니다. 그렇지 않은 경우, AI 생성 답변으로 전환합니다. 대화가 이어질 경우, 이전에 사용된 핸들러 정보를 DB에서 불러와 흐름을 유지합니다. 신뢰도 점수가 낮아지면 AI 답변으로 전환되며, 한 번 AI 생성 답변으로 전환된 경우, Intent Flow로 다시 돌아가지 않습니다. 심층 분석: 질의 흐름 및 구성 사용자 질의(Query)가 처리되는 전체 흐름 개인화(Personalisation) 사용자 위치, 프로필 등 정보를 활용해 응답을 더 적절하게 구성 RAG (Retrieval-Augmented Generation) Jira 티켓, 지식 베이스(KB) 등 다양한 검색 소스를 활용 환각 방지(No Hallucinations) 부정확하거나 오해를 일으킬 수 있는 답변을 생성하지 않도록 안전 장치 적용 이 다이어그램은 사용자 입력부터 개인화, 검색, 최종 AI 응답 생성까지의 전체 여정을 보여줍니다. https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/d7a68628-0408-44fe-8eee-151a1f00a47f-600x264.png   심층 분석: 검색 및 랭킹 여러 개의 질의 변형을 생성한 뒤, 지식 베이스(KB)에서 관련 정보를 검색합니다. 각 질의는 서로 다른 결과를 반환할 수 있기 때문에, 가장 유용한 결과를 선별하는 과정이 필요합니다. 왜 상위 N개의 문서 구간을 추출해야 할까요? 검색 결과가 너무 많을 경우, 사용자가 혼란스러워질 수 있습니다. 반대로 결과가 너무 적으면, 최적의 답변을 놓칠 가능성이 있습니다. 이를 해결하기 위해 재랭킹(Reranking) 과정을 적용합니다. https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/d6fd9075-1300-4f63-99a3-3bf4e472420b-600x344.png 랭킹 메커니즘 상위 N개의 문서 구간을 선정하기 위해 다음 점수들을 조합합니다. Similarity Score 질의와 문서 구간을 임베딩으로 변환한 뒤, 코사인 유사도 기반 점수를 산출합니다. Cross Encoder Score BERT 기반 Cross Encoder를 사용해 질의와 문서 구간을 함께 인코딩하고, 정교한 관련성을 평가합니다. Reciprocal Rank Fusion (RRF) 각 랭킹 결과의 순위를 기반으로 점수를 부여한 뒤 이를 합산해 최종 랭킹을 생성합니다. 단순하면서도 확장성이 뛰어나며, 여러 랭킹 방식의 장점을 효과적으로 결합합니다. https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/26941d74-07fa-4867-b164-1e9b61a8c581-600x324.png 성과 및 결과 https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/aaeac38a-b424-4dbb-aaf9-2672e6abfafd-600x480.png JSM Virtual Agent의 성과 자동화를 통해 해결률이 50% 증가했으며, JSM 채팅 요청의 약 50%를 AI로 처리 CSAT(고객 만족도) 40% 개선 20개 이상 언어 지원, 글로벌 고객 지원 환경 제공 추가 개선 사항 https://atlassianblog.wpengine.com/wp-content/uploads/2025/11/52671a63-fb80-4345-b943-f6f0369a4e52-600x305.png 개선하기 위한 기능 추가 질의 변형(Query Variation) 여러 질의 변형을 생성해, 표현 방식이 달라도 적절한 KB 문서를 찾을 수 있도록 지원 모호한 질의 감지(Vague Query Detection) 질문이 모호할 경우, 사용자에게 추가 정보를 요청 COT 기반 환각 감지기 AI의 추론 과정을 분석해 신뢰할 수 없는 답변을 감지·차단 Conclusion AI 기반 가상 에이전트는 고객 지원을 더 빠르고, 정확하며, 확장 가능하게 변화시키고 있습니다. JSM은 지금까지의 성과를 자랑스럽게 생각하며, 자동화된 고객 지원의 미래를 기대하고 있습니다.



- Others -





  • 레이블 없음