Jira 대체 ITSM, 금융권은 무엇을 기준으로 선택해야 할까?

Jira와 Confluence를 오랫동안 자체 서버에서 운영해 온 기업이라면 최근 몇 년간의 Atlassian 정책 변화가 단순한 라이선스 변경 이상의 문제로 다가왔을 것입니다.

Atlassian은 2024년 2월 15일 Server 제품에 대한 기술지원, 버그 수정, 보안 업데이트를 종료했습니다.

당시 Server 고객에게 제시된 주요 선택지는 Cloud 또는 Data Center로의 전환이었습니다.

그런데 상황은 다시 달라지고 있습니다. Atlassian은 주요 Data Center 제품에 대해서도 단계적 종료 계획을 발표했으며, 신규 고객의 Data Center 구매는 2026년 3월 30일부터 중단되고 영향 대상 제품의 Data Center End of Life는 2029년 3월 28일로 예정돼 있습니다.

따라서 지금의 문제는 단순히 “Server를 Cloud로 옮길 것인가?”가 아닙니다.

앞으로의 IT 서비스 관리 환경을 특정 벤더의 제품 정책과 라이선스 체계에 계속 맞춰갈 것인지, 아니면 이번 기회에 우리 기업의 운영 방식에 맞는 ITSM 체계 자체를 다시 설계할 것인지를 판단해야 하는 시점입니다.

Server 환경에서는 기업이 자체 인프라를 운영하면서 보유한 라이선스를 중심으로 시스템을 유지하는 방식이 일반적이었습니다.

하지만 Cloud와 Data Center는 모두 구독 기반 구조입니다. Atlassian Cloud의 연간 구독은 활성 사용자에 따른 사용자 티어를 기준으로 과금되며, Data Center 역시 사용자 티어를 기준으로 하는 연간 구독 방식입니다.

따라서 전환 비용을 평가할 때는 단순히 Jira 한 제품의 라이선스 가격만 비교해서는 안 됩니다.

기업이 실제로 부담하는 비용은 다음과 같이 봐야 합니다.

즉 ITSM의 TCO(Total Cost of Ownership) 관점에서 현재 비용과 향후 3~5년의 비용 구조를 함께 비교해야 합니다.

특히 기존 Server를 그대로 사용하던 기업일수록 “제품을 바꾸지 않는 것이 가장 안전하다”는 판단을 하기 쉽습니다. 하지만 벤더 정책에 따라 라이선스 모델과 플랫폼 자체가 변경된다면, 유지하는 것 역시 하나의 마이그레이션 전략이 됩니다.

금융회사의 ITSM 전환이 일반 기업보다 복잡한 이유는 시스템 안에서 처리하는 정보와 접근 구조 때문입니다.

ITSM에는 장애 및 변경 요청, 시스템 정보, 계정 및 권한 요청, 담당 조직, 처리 이력, 개발·배포 관련 정보 등 다양한 IT 운영 데이터가 축적될 수 있습니다. 따라서 단순히 “SaaS를 사용할 수 있는가?”보다 어떤 데이터를 어떤 환경에서 처리하고 누가 접근하는지를 먼저 설계해야 합니다.

국내 금융권의 SaaS 활용 환경도 변화하고 있습니다. 금융위원회와 금융감독원은 2026년 4월 20일부터 일정한 보안규율을 준수하는 경우 금융회사가 내부 업무망에서 SaaS를 활용할 수 있도록 망분리 규제를 완화했습니다.

그렇다고 모든 ITSM을 별도 검토 없이 SaaS로 전환할 수 있다는 의미는 아닙니다.

금융사가 ITSM을 검토할 때는 적어도 다음을 함께 살펴볼 필요가 있습니다.

결국 금융권에서 중요한 것은 Cloud와 On-Premise 중 하나를 단순 선택하는 것이 아니라, 기업이 통제 가능한 IT 운영 구조를 설계할 수 있느냐입니다.

특정 제품을 장기간 사용하면 업무 프로세스가 제품 구조에 맞춰지는 경우가 많습니다.

서비스 요청은 특정 Workflow에 맞춰지고, 개발팀과 운영팀의 협업 방식은 제품 기능과 Marketplace App에 의존하며, 각종 시스템 연계 역시 해당 플랫폼을 중심으로 구축됩니다.

이 상태에서 벤더 정책이 변경되면 기업이 선택할 수 있는 범위가 좁아집니다.

이번 Atlassian 정책 변화가 보여주는 핵심도 여기에 있습니다. Server 종료 이후 Cloud 또는 Data Center 전환을 고민했던 기업이 이제는 다시 Data Center 종료까지 고려해야 하기 때문입니다.

따라서 새로운 ITSM을 검토할 때는 현재 제공되는 기능뿐 아니라 다음 질문을 해야 합니다.

“향후 우리 회사의 프로세스가 바뀌었을 때 제품에 맞춰 업무를 변경해야 하는가, 아니면 시스템을 우리 업무에 맞게 변경할 수 있는가?” 이 질문이 벤더 종속성을 판단하는 중요한 기준입니다.

먼저 현재 사용하고 있는 Jira의 역할을 분리해야 합니다.

Jira Software를 중심으로 개발 프로젝트의 Backlog, Sprint, Issue를 관리하는 것이 핵심인지, Jira Service Management를 중심으로 IT 서비스 요청·장애·문제·변경·릴리스 프로세스를 운영하는 것이 핵심인지 구분해야 합니다.

ITSM이 중심이라면 대체 솔루션을 평가할 때 필요한 기준도 보다 명확해집니다.

가격만 저렴한 제품을 찾는 것이 아니라, 지금 Jira를 통해 수행하는 핵심 업무를 다른 환경에서도 지속할 수 있는 구조를 찾는 것이 중요합니다.

이러한 관점에서 유스트라 ITSM은 Jira Service Management를 포함한 기존 ITSM 환경의 대안을 검토하는 기업에게 적합한 방향을 제공합니다.

유스트라 ITSM은 표준화된 프로세스를 기반으로 서비스 요청·결재·장애 등의 IT 업무를 관리하고, ITIL 기반의 서비스 데스크, 장애관리, 문제관리, 변경관리, 릴리즈관리, 구성관리 등의 프로세스를 제공합니다. 요청 유형별 액티비티와 프로세스 버전을 관리할 수 있는 Workflow 기능도 제공됩니다.

여기에서 중요한 강점은 기능의 개수보다 기업의 운영 환경에 맞춰 ITSM을 구성할 수 있다는 점입니다.

공식 제품 기준으로 유스트라 ITSM은 구축형과 구독형을 모두 제공합니다. 특히 구축형은 패키지 기반에 커스터마이징 개발을 결합할 수 있으며, 단순·변경·문제·장애·릴리즈 등의 프로세스 변경과 필요한 시스템 연계 개발, 기존 데이터 이관을 지원하는 구조입니다.

이는 기업의 보안정책이나 IT 운영 프로세스를 SaaS 표준 구조에 일방적으로 맞추는 것이 아니라, 기존 업무 환경과 필요한 통제 구조를 유지하면서 ITSM 체계를 재구성해야 하는 기업에게 중요한 장점입니다.

또 하나의 핵심은 IT 운영에서 개발·배포까지 이어지는 통제 구조입니다.

유스트라 ITSM 구축형의 프리미엄 영역에서는 SVN·GitLab과 같은 형상관리 도구, Jenkins와 같은 배포 도구, Sparrow 보안·품질 점검 도구와의 연계 기능을 제공하고 있습니다. 또한 요청부터 배포까지 증적자료를 보관·관리하여 ITGC 대응을 지원합니다.

따라서 단순히 “Jira 화면과 비슷한 제품”을 찾는 것이 아니라 서비스 요청 → 승인 → 변경 → 개발·배포 → 이력 및 증적 관리까지 기업의 IT 운영 프로세스를 연결하는 것이 목적이라면 유스트라 ITSM의 강점이 더욱 분명해집니다.

Atlassian Server 지원 종료는 이미 완료됐고, 주요 Data Center 제품 역시 종료 로드맵에 들어갔습니다.

이 시점에서 또 다른 특정 제품으로 단순 이전하는 것만으로는 벤더 종속성 문제를 해결하기 어렵습니다.

중요한 것은 현재 Jira와 Confluence에서 사용하고 있는 업무를 분석해 반드시 유지해야 하는 프로세스와 불필요하게 제품에 종속된 영역을 구분하는 것입니다.

그리고 서비스 요청, 장애, 문제, 변경, 릴리스, 내부통제처럼 기업의 핵심 IT 운영 프로세스를 자체 업무 기준으로 다시 설계해야 합니다.

기존 ITSM 환경을 훼손하지 않으면서도 기업의 보안정책과 운영 프로세스에 맞는 구축 방식을 확보하고, 필요한 시스템 연계와 Workflow를 구성해야 한다면 유스트라 ITSM이 Jira 중심 ITSM 환경을 재설계하기 위한 실질적인 해답이 될 수 있습니다.