글: Kristijan Sekereš

2027년 1월 31일 Atlassian Connect 지원 종료: 자체 개발한 Jira와 Confluence 앱을 Forge로 옮기기

초록색 퍼즐 조각들 사이에 놓인 빨간 퍼즐 조각 하나

2027년 1월 31일 Atlassian은 오래된 Jira와 Confluence Cloud 앱 대부분이 기반으로 삼은 프레임워크인 Connect의 지원을 종료합니다. Atlassian은 그날부터 "Connect의 중대한 보안 취약점만 처리하며", 여전히 Connect에서 돌아가는 비공개 앱은 "더 이상 지원되지 않고 제대로 작동하지 않을 수 있다"고 밝혔습니다.

사이트의 모든 앱이 Atlassian Marketplace에서 온 것이라면 이 일은 벤더들의 몫이고, 대부분은 이미 해냈습니다. Atlassian은 2026년 8월 "유료 앱 시트의 95% 이상이 Forge로 마이그레이션되었다"고 보고했습니다.

이 글은 그 반대의 경우를 위한 것입니다. 사내 개발자, 외주 업체, 파트너 등 누군가 귀사를 위해 만든 Jira나 Confluence 앱이 있는 경우입니다. 구매한 것이 아니라 링크로 설치한 앱입니다. 회사 밖의 누구도 이 앱을 옮겨 주지 않으며, 그것을 작성한 사람은 이미 없을 수도 있습니다.

지원 종료가 뜻하는 것과 뜻하지 않는 것

공개된 차단 날짜는 없습니다. Atlassian은 2027년 2월 1일에 Connect 앱이 실행을 멈춘다고 말하지 않았고, 처음 일정 발표에서는 "Connect 앱을 설치한 고객이 앱에 대한 접근을 잃지는 않는다"고 했습니다.

이것을 안전하다는 뜻으로 읽지 마십시오. 바뀌는 것은 Atlassian에서 더 이상 아무도 Connect를 돌보지 않는다는 점입니다.

  • 중대한 보안 취약점만 수정됩니다. 중대하지 않은 버그는 남습니다.
  • "Connect 기능의 지원 중단은 사전 공지가 거의 없이 이루어질 것입니다."
  • Atlassian 지원팀은 "그 레거시 기술로 인한 문제를 해결할 수 없습니다".
  • Atlassian 자신의 표현으로는 이렇습니다. "Connect는 지원 종료 후 안정된 상태로 유지되지 않습니다. 장애는 늘어나고 호환성 격차는 벌어질 것입니다."

그러니 위험은 절벽이 아니라 점진적으로 옵니다. 있을 법한 실패는 이렇습니다. Jira가 페이지 하나를 바꾸고, Connect 패널이 렌더링을 멈추고, 티켓을 올릴 곳이 아무 데도 없습니다. 그 앱이 재무 승인이나 고객 대상 서비스 데스크 안에 있다면, 소식은 그것에 의존하는 사람들에게서 듣게 됩니다.

이미 일어난 일

1월 날짜는 2025년에 시작된 일련의 단계 중 마지막입니다.

  • 2025년 9월: Marketplace가 새 Connect 앱을 더 이상 받지 않았습니다.
  • 2026년 3월 31일: 업데이트가 동결되었습니다. Atlassian의 자체 개발 앱 안내는 그 날짜 이후 "Connect 앱에 업데이트를 배포할 수 없게 된다"고 분명히 밝혔습니다. 자체 서버의 코드는 여전히 바꿀 수 있지만, 앱이 Jira나 Confluence에 선언하는 내용(모듈, 스코프, 웹훅)은 고정됩니다.
  • 2026년 3월: 일정 발표는 "Connected Apps를 통해 새 Connect 비공개 앱을 설치하는 기능이 사라진다"고도 했습니다. 제거는 되돌릴 수 없는 것으로 취급하십시오. 무엇이 깨지는지 보려고 비공개 Connect 앱을 제거하지 마십시오.
  • 2026년 8월: Atlassian은 지원 종료일을 2026년 12월에서 2027년 1월 31일로 옮겼습니다. 한 달이 늘었을 뿐입니다. 또 한 번의 연기를 전제로 계획하지 마십시오.
  • 지금: Atlassian은 Atlassian Administration에 경고를 띄우고 있으며, 아직 Connect에 있는 비공개 앱은 "LEGACY 상태로 표시"됩니다.

비공개 앱 찾기

Atlassian Administration의 Connected Apps 페이지에서 시작하십시오. LEGACY 표시가 붙은 것은 모두 Connect에서 돌아가고 있습니다. 비공개 앱을 알아보는 Atlassian의 점검 목록은 다음과 같습니다. 대부분 해당한다면 귀사가 옮겨야 할 앱입니다.

  • Marketplace가 아니라 직접 링크나 개발자 모드로 설치되었다.
  • Marketplace 검색에 나오지 않는다.
  • 귀사 조직이 소스 코드를 관리한다.
  • 라이선스 정보가 없고, 설치 목록에 귀사 조직만 올라 있다.
  • Connected Apps 페이지에 관련 링크 사이드바가 없다(Marketplace 앱에는 있다).

Atlassian은 경험칙도 덧붙입니다. 5년도 더 전에 만든 자체 클라우드 앱은 Connect 앱일 가능성이 크며, Connect 앱은 Atlassian 밖에서 호스팅되고 "대개 Heroku, AWS, Azure, Google Cloud Platform 같은 서비스에서" 돌아갑니다. 앱의 View app details 링크는 Atlassian이 아는 범위에서 개발자가 누구인지 보여 줍니다.

누구든 코드를 건드리기 전에 앱마다 다섯 가지를 적어 두십시오.

  1. 무엇을 하는지와 누가 쓰는지를 업무 담당자가 알아볼 수 있는 한 문장으로.
  2. 소스 코드가 어디에 있는지. 귀사가 관리하는 저장소인지, 외주 개발자의 노트북인지, 아무 데도 없는지.
  3. 어디서 실행되는지, 그리고 호스팅 비용을 누구 계정이 내는지. 서버가 예전 외주 업체의 클라우드 계정에 있다면 그것은 1월이 아니라 지금의 위험입니다.
  4. 디스크립터. 모든 Connect 앱은 어떤 URL에서 atlassian-connect.json 파일을 제공합니다. 앱이 쓰는 모든 모듈, 스코프, 웹훅이 나열되어 있어 얻을 수 있는 가장 믿을 만한 현황 목록입니다.
  5. 어떤 데이터를 어디에 보관하는지. 자체 데이터베이스인지, 아니면 Jira 이슈와 Confluence 페이지에 저장된 속성인지.

만들기 전에 결정하기

모든 비공개 앱이 마이그레이션할 가치가 있는 것은 아닙니다. Atlassian 자신의 조언은 Jira나 Confluence의 기본 기능이 이제 그 일을 하는지 확인하고, 조직에 여전히 필요한 것만 마이그레이션하라는 것입니다. 오래된 앱은 제품이 그 뒤에 메운 빈틈을 채우던 경우가 많습니다.

앱마다 세 가지 답 중 하나를 받습니다. 마이그레이션, 지원되는 다른 것으로 대체, 폐기입니다. 폐기도 정당한 결과입니다. Atlassian은 앱을 없앤다면 저절로 고장 나게 내버려 두지 말고 사용자에게 알리고 2027년 1월 31일 전에 제거 일정을 잡으라고 권합니다.

Forge로 옮기는 데 필요한 것

Forge는 이름만 바꾼 Connect가 아닙니다. 호스팅 모델, 보안 모델, UI 모델이 모두 다르기 때문에 Atlassian은 단순한 앱의 소유자에게도 개념 증명을 일찍 시작하라고 말합니다.

호스팅

Connect 앱은 귀사가 운영하는 웹 서비스입니다. Forge 앱은 Atlassian의 인프라에서 엄격한 제한이 있는 함수로 실행됩니다. 사용자가 트리거하는 함수는 25초, 비동기 이벤트와 예약 트리거는 최대 900초입니다. 사용자가 기다리는 동안 10분짜리 동기화를 돌리는 Connect 앱은 그 작업을 비동기 이벤트로 옮겨야 하고, 15분보다 긴 작업은 단계로 나눠야 합니다. 외부 호출도 제한됩니다. 앱 매니페스트에 선언하지 않은 도메인은 모두 거부됩니다.

지금의 백엔드 유지하기

Forge Remote를 쓰면 Forge 앱이 다른 곳에 호스팅한 서비스를 호출할 수 있고, 귀사의 서버가 요청이 정말 Forge에서 왔는지 확인할 수 있으며, 백엔드가 Atlassian API를 호출할 토큰을 받습니다. 몇 년 치 비즈니스 로직이 서버에 쌓인 비공개 앱이라면 대개 이쪽이 더 짧은 길입니다. UI와 연동 지점은 Forge로 옮기고 로직은 그 자리에 둡니다.

대가도 있습니다. Forge Remote를 쓰면 앱이 Atlassian의 Runs on Atlassian 프로그램 대상에서 빠질 수 있습니다. 사내 도구라면 그다지 중요하지 않지만, 보안팀이 알고서 받아들여야 합니다.

인증과 권한

Connect 앱은 공유 비밀로 서명한 JWT로 인증합니다. Forge는 이를 매니페스트에 선언한 OAuth 2.0 스코프로 대체하고, 원격 백엔드에는 JWT 대신 서버가 검증하는 Forge Invocation Token을 줍니다.

그다음 Jira나 Confluence API에 대한 인증된 호출은 각각 앱을 쓰는 사람의 권한으로 실행되는 asUser, 또는 Atlassian의 표현으로 "누가 앱을 쓰든 관계없이" 작동하는 asApp 중 하나로 이루어집니다. 호출 하나하나를 살펴보며 의도적으로 고르는 것이 마이그레이션 전체에서 가장 중요한 보안 검토입니다.

팀들을 당황하게 하는 차이가 하나 있습니다. Connect 모듈은 기본적으로 라이선스가 없는 사용자와 익명 사용자에게도 렌더링됩니다. Forge 모듈은 매니페스트에서 unlicensedAccess로 명시하지 않으면 렌더링되지 않습니다. 앱이 서비스 데스크 고객이나 익명의 Confluence 독자에게 무엇이든 보여 준다면 그 경로를 따로 테스트하십시오.

사용자 인터페이스

Connect 페이지는 Atlassian의 JavaScript API로 Jira나 Confluence와 통신하는 iframe입니다. Forge는 두 가지 선택지를 줍니다.

  • UI Kit: 네이티브 Atlassian 컴포넌트를 렌더링하는 React 기반 프레임워크입니다. 빠르고 일관되지만 Atlassian의 컴포넌트로만 만들어야 합니다. 커스텀 HTML은 작동하지 않을 수 있고, 받아들이는 정적 리소스는 이미지뿐입니다.
  • Custom UI: iframe 안에서 @forge/bridge로 제품과 통신하는 귀사 자체의 HTML, CSS, JavaScript입니다.

기존 iframe 프런트엔드는 대개 Custom UI로 옮기는 것이 변경이 가장 적습니다. 작은 패널과 설정 화면은 UI Kit으로 다시 만드는 편이 더 빠른 경우가 많습니다.

데이터

마이그레이션이 잘못되는 곳이 여기입니다. Forge에는 자체 호스팅 스토리지가 있습니다. 키-값 저장소, 커스텀 엔티티 저장소, Forge SQL, 그리고 미리 보기 단계의 객체 저장소입니다. 데이터는 설치별로 범위가 정해지고 호스트 Jira나 Confluence 사이트와 같은 위치에 보관되므로, 추가 설정 없이 데이터 상주(data residency)가 보장됩니다.

비공개 앱에게는 다음을 뜻합니다.

  • Connect 앱 자체 데이터베이스의 데이터는 일회성 마이그레이션 작업으로 Forge 스토리지에 옮기거나, 그 자리에 두고 Forge Remote로 접근합니다.
  • Connect 앱이 자기 앱 키로 Atlassian 쪽에 저장한 것은 무엇이든 옛 앱이 아직 돌아갈 때 내보내 두어야 합니다. 새 앱이 그것을 읽을 수 있는지 일찍 테스트하십시오. 가정하지 마십시오.
  • Forge는 제거 후 28일 동안 호스팅 데이터를 보관하지만, 다시 설치해도 자동으로 복원되지는 않습니다.

마이그레이션은 확인 가능한 건수를 남기는 반복 실행 가능한 스크립트로 작성하고, 테스트 사이트에서 리허설하고, 내보낸 데이터는 보관하십시오.

점진적 경로, 그리고 그것이 아마 귀사의 길이 아닌 이유

Atlassian은 Connect 앱을 위해 더 완만한 경로를 만들었습니다. Forge를 점진적으로 도입하면서 기존 설치를 유지하고, 디스크립터를 Forge 매니페스트로 변환하고, 모듈 계열을 하나씩 옮기는 방식이며, 매크로, 커스텀 필드, 워크플로 검증기 같은 일부 모듈은 데이터 마이그레이션이 기본 제공됩니다.

함정은 가이드의 첫 문단에 있습니다. "Forge의 점진적 도입은 이미 Marketplace에 등록된 Confluence와 Jira Connect 앱에만 제공됩니다."

비공개 앱이라면 새 Forge 앱을 계획하십시오. 운영 환경에 배포하고, 개발자 콘솔의 설치 링크로 귀사 사이트에 공유하고, 데이터를 마이그레이션하고 사용자가 테스트하는 동안 옛 Connect 앱과 나란히 돌린 뒤, Connect 앱을 제거합니다.

도입 가이드는 모듈 대응표 때문에 여전히 쓸모가 있고, Forge에서 제공되지 않는 Connect 기능 목록도 마찬가지입니다. Jira Service Management 모듈 여러 개와 모바일 앱 지원은 계획 없음으로 표시되어 있고, jiraReports는 아직 검토 중입니다. 첫 주에 디스크립터를 그 목록과 대조하십시오. 거기서 빈틈이 나오면 설계가 바뀝니다.

2027년 1월 31일부터 거꾸로 짠 계획

2026년 10월 초부터 계산하면 약 17주가 남았고, 12월은 누구에게나 짧습니다. 지킬 수 있는 계획은 다음과 같습니다.

  1. 이번 주: 위의 다섯 가지 사실과 함께 모든 LEGACY 앱을 나열합니다. 소스 코드와 호스팅 계정을 누가 관리하는지 확인합니다.
  2. 10월 중순까지: 앱마다 마이그레이션, 대체, 폐기를 결정합니다. 폐기할 앱의 사용자에게 알립니다.
  3. 10월 말까지: 가장 어려운 앱의 가장 어려운 부분에 대한 Forge 개념 증명. 대개 Forge에 직접 대응하는 것이 없는 모듈이거나, 데이터를 가장 많이 가진 모듈입니다.
  4. 11월: 구축하고, 테스트 사이트를 대상으로 데이터 마이그레이션을 두 번 이상 실행합니다.
  5. 12월 초: Connect 앱 옆에 Forge 앱을 설치하고, 데이터 사본을 마이그레이션하고, 매일 그것을 쓰는 사람들에게 확인하게 합니다.
  6. 2027년 1월: 최종 마이그레이션, 사용자 전환, 그리고 새 앱이 한동안 문제없이 돌아간 뒤에만 Connect 앱을 제거합니다.

Jira 데이터를 읽기만 하고 아무것도 저장하지 않는 패널 하나라면 작은 일입니다. 자체 데이터베이스, 워크플로 규칙, 다른 시스템과의 연결이 있는 앱이라면 그 몇 주가 모두 필요합니다.

날짜를 놓치더라도 Atlassian이 공개한 어떤 자료도 그날 앱이 멈춘다고 말하지는 않습니다. 하지만 그때부터 귀사는 소유자가 고치기를 멈춘 플랫폼 위에서 업무 프로세스를 돌리게 됩니다. 그 시간은 빌린 시간으로 여기고 이전을 끝내십시오.

원래 개발자가 떠났다면

Atlassian은 이 경우를 직접 다룹니다. 원래 앱 소유자를 확인하거나 연락할 수 없거나 더 이상 개발 역량이 없다면, Solution Partner와 계약할 것을 권합니다. 소스 코드가 없다면 "Forge에서 처음부터 다시 만들어야 할 수도 있다"는 점도 분명히 합니다.

소스 코드가 없더라도 아무것도 모르는 상태에서 시작하는 것은 아닙니다. 디스크립터는 앱이 연결되는 모든 곳을 나열하고, 동작은 테스트 사이트에서 관찰할 수 있으며, 서버 비용을 귀사가 내고 있다면 실제로 무엇이 배포되어 있는지 볼 수 있습니다. 이런 조각들로 다시 만드는 것은 이식보다 느리지만, 규모를 가늠할 수 있는 일입니다.

도움이 필요하시면

저희는 현재 팀의 누구도 작성하지 않은 코드를 넘겨받아 그것이 실제로 무엇을 하는지 파악하고 옮깁니다. Connect 앱이라면 디스크립터와 서버를 읽고, Forge 앱을 만들고, 데이터 마이그레이션을 작성하고 리허설하는 일입니다. 이 일은 대개 레거시 시스템 유지보수 작업에서 시작하며, 개발자는 있지만 인원이 부족하다면 인력 증강으로 기간 동안 귀사 팀에 사람을 더합니다. 앱이 무엇을 하고 어디서 돌아가는지 office@c9group.dev로 알려 주십시오.