Project iQ: Qantas가 1,000개 넘는 레거시 앱의 데이터를 이어 AI를 넓히려 Accenture와 맺은 계약
Qantas가 Accenture와 다년 계약(Project iQ)을 맺고 서로 연결되지 않는 1,000개 넘는 레거시 앱과 데이터 플랫폼, 재무·구매·인사·마케팅 업무를 다시 짭니다. 약 850개 직무가 영향을 받고 첫 변화는 2027년 중반입니다.
Qantas는 AI를 넓히기 전에 서로 말이 통하지 않는 1,000개 넘는 레거시 앱의 데이터부터 잇기로 했고, 그 일을 Accenture에 맡기며 본사 후선 업무까지 함께 다시 짭니다. 이런 계약을 따라 하려면 앱 목록과 데이터 연결 순서, 이관할 업무의 지식 인수 계획, 직무별 영향표를 계약 전에 먼저 갖춰야 합니다.
요약
호주 항공사 Qantas가 2026년 11월 10일 Accenture와 다년 계약을 맺었다고 직원들에게 알렸습니다. 내부 이름은 Project iQ입니다. iTnews 보도에 따르면 Accenture는 Qantas의 백엔드(back-end, 고객 눈에 보이지 않는 뒷단) 시스템과 프로세스, 데이터를 현대화하고, 본사 기능 일부의 일하는 방식을 단순하게 다시 설계합니다. 일부 서비스는 Accenture로 넘어가 주로 인도 팀이, 일부는 호주 팀이 맡습니다. 넘어간 업무는 시간을 두고 자동화와 AI로 다시 바뀝니다. Accenture는 데이터 플랫폼 현대화를 앞당기려 먼저 투자합니다.
Qantas가 든 이유는 수십 년 쌓인 기술 부채입니다. 처음부터 함께 돌아가도록 설계되지 않은 레거시 애플리케이션이 1,000개가 넘고, 이 시스템을 현대화해 데이터를 잇는 일이 복잡성을 덜고 AI 활용을 앞당기는 다음 단계라고 설명했습니다. 영향을 받는 직무는 앞으로 몇 년에 걸쳐 약 850개이고, 첫 변화는 2027년 중반으로 잡혔습니다. 노조(Australian Services Union)는 첫 대상이 재무, 구매, 인사, 마케팅이라고 밝히며 해외 이전에 해명을 요구했습니다. Vanessa Hudson CEO는 직원 메일에서 “Standing still is not an option for us”라고 썼습니다. 아래에서는 이 계약을 움직이는 네 가지 메커니즘과, 비슷한 계약을 준비하는 회사가 실제로 챙길 기술·현업 디테일을 정리합니다.
핵심 메커니즘
아래 메커니즘 이름은 이해를 돕기 위해 붙인 것이고 원문 용어가 아닙니다.
Integration Debt: 따로 노는 앱 1,000개가 AI를 막는 이유
무엇인가. 시스템을 하나씩 따로 들여오면서 쌓인 연결 부채입니다. 앱마다 고객, 공급사, 직원, 비용 같은 같은 대상을 제각각 정의하고 저장해서, 여러 앱의 데이터를 한 번에 묻기 어렵습니다.
어떻게 작동하나. 입력은 업무 질문 하나입니다. 예를 들어 “이 공급사에 올해 얼마를 썼고 계약 조건은 무엇인가”를 AI에 묻는다고 해 봅시다. 답에 필요한 데이터가 구매, 재무, 계약 관리 시스템에 흩어져 있고 공급사 코드가 서로 다르면, AI는 앱마다 따로 붙여야 하고 결과를 맞춰 보는 일은 사람이 합니다. 앱을 정리하고 데이터를 한 플랫폼에 이으면 같은 질문을 한 번에 처리할 수 있습니다. 출력은 사람 손을 덜 거치는 답과 자동화할 수 있는 업무 흐름입니다.
언제 쓰고 언제 안 쓰나. AI 시범은 잘 됐는데 다른 부서로 넓히지 못할 때 이 부채부터 의심합니다. 반대로 한 시스템 안에서 끝나는 업무(문서 한 장 요약, 단일 앱 내 분류)는 연결을 기다릴 필요가 없습니다.
원문의 예. Qantas는 1,000개가 넘는 레거시 앱을 들며, 시스템 현대화와 데이터 연결을 AI 활용을 앞당길 다음 단계로 꼽았습니다.
작은 예시(가상). 한 제조사가 협력사 리스크를 AI로 점검하려는데 협력사 코드가 ERP, 품질 시스템, 구매 포털에서 제각각이라면, AI 모델을 고르기 전에 협력사 마스터 하나를 만드는 일이 먼저입니다.
Data Platform First: 벤더가 먼저 투자해 데이터 기반부터 바꾼다
무엇인가. 업무 이관과 AI 적용보다 데이터 플랫폼 현대화를 앞에 두는 순서입니다. Qantas 계약에서는 Accenture가 이 부분에 선투자합니다.
어떻게 작동하나. 입력은 흩어진 원천 시스템입니다. 데이터를 공통 플랫폼으로 모으고 주요 대상(공급사, 직원, 비용 항목)의 정의를 맞춥니다. 그 위에서 재설계된 업무가 같은 데이터를 쓰고, 나중에 자동화와 AI가 그 데이터를 읽습니다. 벤더가 앞단 비용을 먼저 내면 회사는 초기 부담을 줄이고 속도를 얻는 대신, 이후 운영 계약으로 그 투자를 나눠 갚는 구조가 됩니다(일반적인 구조 설명이며 Qantas 계약 금액과 조건은 공개되지 않았습니다).
언제 쓰고 언제 안 쓰나. 내부 인력만으로는 속도와 규모가 모자랄 때 맞습니다. Qantas도 혼자 할 때보다 빠르고 크게 움직이려고 다년 파트너십을 택했다고 설명했습니다. 데이터 정의를 누가 갖느냐(소유권)를 계약에 못 박지 않으면 나중에 벤더를 바꾸기 어렵습니다.
원문의 예. Accenture가 그룹 데이터 플랫폼 현대화를 앞당기려 선투자합니다. Mediaweek에 따르면 Qantas는 해마다 기술에 10억 달러 이상을 씁니다.
Transfer-Redesign-Automate: 이관하고, 단순화하고, AI를 얹는 순서
무엇인가. 본사 후선 업무를 세 단계로 바꾸는 방식입니다. 업무를 외부 팀으로 넘기고, 넘기는 과정에서 중복을 걷어 단순하게 다시 짜고, 시간을 두고 자동화와 AI를 넣습니다.
어떻게 작동하나. 입력은 재무, 구매, 인사, 마케팅의 현재 업무입니다. 처리 단계에서 일부는 Accenture 인도 팀으로, 일부는 호주 팀으로 옮기고, 중복된 단계를 줄입니다. Hudson CEO는 재설계할 때 자동화와 AI를 처음부터 넣겠다고 했고, 회사 발표는 넘어간 서비스가 시간이 지나며 자동화와 AI로 더 바뀐다고 했습니다. 출력은 더 단순하고 서로 연결된 업무 흐름입니다.
언제 쓰고 언제 안 쓰나. 규칙이 정해진 대량 업무(전표 처리, 구매 발주, 인사 행정)에 맞습니다. 안전과 운항 규정에 묶인 업무는 이 계약의 대상으로 발표되지 않았습니다.
원문의 예. 첫 대상은 재무, 구매, 인사, 마케팅이고(노조 발표), 약 850개 직무가 몇 년에 걸쳐 영향을 받습니다. 개별 직무는 아직 정해지지 않았습니다.
Onshore AI Core: AI 역량은 안에 두고 운영은 밖으로
무엇인가. 업무 운영은 외부로 넘기되, AI와 제품 혁신 역량은 회사 안에 두는 배치입니다.
어떻게 작동하나. Qantas는 애들레이드에 제품 혁신 센터를 두고 약 400명 규모로 키웁니다(iTnews는 약 400명, Mediaweek는 400명 이상). 반복 운영은 Accenture가 맡고, AI 활용 방향과 제품은 회사 안에서 정합니다. 수천 명의 직원이 이미 일상 업무에 AI 도구를 쓰고 있다고 회사는 밝혔습니다.
언제 쓰고 언제 안 쓰나. 운영을 외부에 넘겨도 무엇을 자동화할지 판단하는 사람은 안에 있어야 합니다. 판단까지 넘기면 회사 데이터와 업무 지식이 벤더 쪽에만 쌓입니다.
원문의 예. Hudson CEO는 1월에 AI를 회사 전반으로 넓힐 기반을 다져 왔다고 밝히며 예지 정비, 비행 계획, 인사 업무를 기회로 꼽았습니다(Cyber Daily).
통념과 다른 주장
흔히 이렇게 봅니다AI 확대는 좋은 모델과 도구를 고르고 부서마다 시범을 늘리면 된다고 봅니다.
Qantas는 이렇게 봅니다서로 연결되지 않은 시스템의 데이터를 잇는 일이 AI를 앞당기는 다음 단계입니다. 그래서 가장 큰 계약을 데이터 플랫폼과 백엔드 현대화에 걸었습니다.
근거함께 돌아가도록 설계되지 않은 레거시 앱이 1,000개를 넘고, 이 복잡성을 줄이지 않으면 AI를 넓히기 어렵다고 회사가 직접 설명했습니다.
저자가 든 사례
Qantas: 레거시 앱과 본사 업무를 Accenture와 함께 다시 짠다
| 구분 | 내용 |
|---|---|
| 상황 | 수십 년 동안 쌓인 기술 부채. 함께 돌아가도록 설계되지 않은 레거시 앱이 1,000개를 넘습니다. 8월에 Australian Financial Review가 Accenture와의 아웃소싱 계획을 먼저 보도했습니다. |
| 한 일 | Accenture와 다년 계약(Project iQ). 백엔드 시스템·프로세스·데이터 현대화, 본사 기능 일부 재설계, 일부 서비스를 Accenture 인도·호주 팀으로 이관, Accenture의 데이터 플랫폼 선투자. |
| 결과 | 약 850개 직무가 몇 년에 걸쳐 영향을 받고 첫 변화는 2027년 중반입니다. 개별 직무는 직원·노조 협의 뒤 정합니다. 회사는 재배치, 재교육, 지원을 약속했습니다. 계약 금액과 절감 효과는 원문에서 밝히지 않았습니다. |
| 이 노트와의 연결 | Integration Debt가 출발점이고, Data Platform First가 순서를, Transfer-Redesign-Automate가 업무 변화를, Onshore AI Core가 역량 배치를 보여 줍니다. |
기술 디테일: 데이터를 이으면서 업무를 넘기려면
아래 필드명, 설정값, 기준은 원문에 없는 실행 제안이자 가상 예시입니다.
앱 목록을 데이터 대상 기준으로 다시 씁니다(Integration Debt). 1,000개 규모의 앱을 한 번에 다룰 수는 없으니, 먼저 앱마다 어떤 핵심 데이터 대상을 만들고 읽는지 적습니다. 대상은 공급사, 직원, 비용 항목, 고객, 자산처럼 10~15개로 시작합니다. 같은 대상을 만드는 앱이 둘 이상이면 그 대상이 연결 부채의 중심입니다. 앱 목록은 CMDB(구성 관리 데이터베이스)와 결제 계정, SSO 로그인 기록을 합쳐 만들면 빠진 앱을 줄일 수 있습니다.
{
"app_id": "FIN-0412",
"name": "공급사 지급 관리",
"owner_function": "재무",
"creates": ["supplier", "invoice"],
"reads": ["cost_centre", "contract"],
"supplier_key": "VENDOR_NO",
"interfaces": {"batch_files": 6, "api": 1},
"monthly_users": 140,
"decision": "migrate",
"target_wave": 1
}decision은 유지(retain), 이전(migrate), 교체(replace), 폐기(retire) 넷 가운데 하나로 둡니다. 같은 대상을 만드는 앱이 여럿이면 하나만 원천으로 남기고 나머지는 읽기 전용으로 돌립니다.
연결은 마스터 데이터와 키 매핑부터 합니다(Data Platform First). 공급사 코드가 시스템마다 다르면 데이터 플랫폼에 모아도 AI는 같은 공급사를 셋으로 봅니다. 이름, 사업자번호, 계좌로 후보 짝을 만들고, 짝짓기 규칙으로 맞추지 못한 건만 LLM에 넘겨 같은 대상인지 판정하게 합니다. 이때 출력은 {"match": true, "confidence": 0.0~1.0, "evidence": [...]} 같은 고정 스키마로 받고 temperature는 0으로 둡니다. 신뢰도 0.9 미만은 데이터 담당자가 확인합니다. 맞춘 결과는 키 매핑 표로 남겨, 업무를 넘긴 뒤에도 Accenture 팀과 사내 팀이 같은 표를 씁니다.
이관 전에 업무 지식을 기록으로 남깁니다(Transfer-Redesign-Automate). 업무가 다른 나라 팀으로 넘어가면 담당자 머릿속 예외 처리가 빠지기 쉽습니다. 이관 대상 업무마다 시스템 로그로 실제 흐름을 뽑고(프로세스 마이닝), 담당자 인터뷰와 기존 매뉴얼을 LLM으로 묶어 표준 작업서(SOP) 초안을 만듭니다. 초안은 업무 단계, 쓰는 시스템, 예외 유형, 판단 기준, 승인자로 나누고, 원래 담당자가 검토해 서명합니다. 이 작업서가 나중에 AI 자동화의 설계도가 됩니다.
AI는 재설계된 흐름의 정해진 지점에만 넣습니다(Transfer-Redesign-Automate). 전표 증빙 추출, 구매 요청 분류, 인사 문의 응답처럼 입력과 정답이 분명한 지점부터 넣습니다. 같은 문서를 3번 처리해 결과가 다르면 사람 검토로 넘기고, 사람 검토율과 오류율을 주간으로 봅니다. 승인과 지급처럼 돈이 나가는 단계는 AI가 제안만 하고 사람이 확정합니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 같은 대상이 여러 앱에서 만들어짐 | 플랫폼에 모아도 숫자가 맞지 않음 | 대상별 원천 앱 하나 지정, 나머지 읽기 전용 |
| 이관 뒤 예외 처리가 끊김 | 처리 지연, 되묻기 증가 | 이관 전 SOP와 예외 목록 서명, 병행 운영 기간 확보 |
| 데이터 정의가 벤더 쪽에만 쌓임 | 벤더 교체나 내재화가 어려움 | 데이터 모델과 키 매핑 표 소유권을 계약에 명시 |
| AI 자동화가 계속 뒤로 밀림 | 이관만 끝나고 효과가 안 보임 | 이관 단계부터 자동화 후보와 목표 시점을 SOP에 적음 |
현업 실행 디테일: 누가, 언제, 무엇을
원문은 계약 발표와 일정의 큰 틀까지를 전합니다. 아래 역할, 일정, 기준은 비슷한 계약을 준비하는 회사를 가정해 새로 짠 가상 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| CEO | 왜 지금인지 설명, 인력 영향 메시지, 노조 소통의 책임자 |
| CIO·CTO | 앱 목록과 연결 순서, 데이터 플랫폼 설계 승인, 데이터 소유권 조항 |
| CFO·구매 | 계약 구조(선투자와 운영 대가), 성과 지표와 지급 조건 |
| CHRO | 직무별 영향표, 재배치·재교육 계획, 노조 협의 일정 |
| 기능 리더(재무·구매·인사·마케팅) | 이관 대상 업무 선정, SOP 검토와 서명, 병행 운영 |
| 사내 AI 조직 | 자동화 후보 선정과 우선순위, 벤더 산출물 검토 |
준비물. 앱 목록(소유 부서, 사용자 수, 인터페이스 수), 핵심 데이터 대상 정의서, 기능별 업무 목록과 월 처리량, 직무별 인원과 업무 비중, 기존 아웃소싱 계약과 만기, 노사 협약 일정이 필요합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~4주 | 앱 목록 정리, 데이터 대상 10~15개 정의, 기능별 업무 목록 | 앱·데이터 대상 매트릭스 |
| 5~8주 | 앱별 결정(유지·이전·교체·폐기), 이관 후보 업무 선정, 직무별 영향 초안 | 연결 순서(1차 묶음), 영향표 초안 |
| 9~12주 | 벤더 제안 비교, 데이터 소유권·성과 조항 협상, 노조 사전 설명 | 계약 조건표, 소통 계획 |
| 13~24주 | 1차 묶음 이관 준비, SOP 작성과 서명, 병행 운영 | 서명된 SOP, 병행 운영 결과 |
현장에 물을 것.
- 이 업무에 쓰는 앱은 몇 개이고, 같은 데이터를 두 번 입력하는 곳은 어디인가요?
- 담당자가 매뉴얼에 없이 판단하는 예외는 무엇이고, 한 달에 몇 건인가요?
- 이 업무를 넘기면 회사 안에 남아야 할 결정 권한은 무엇인가요?
- 자동화가 들어오면 이 직무의 사람은 어떤 일로 옮겨 갈 수 있나요?
- 데이터 정의를 바꾸면 영향을 받는 보고서와 시스템은 무엇인가요?
진행 판정 기준(예시). 1차 묶음의 핵심 데이터 대상 가운데 80% 이상이 원천 앱 하나로 정리되고, 이관 업무의 SOP가 모두 서명되며, 병행 운영에서 처리 지연이 기존보다 10% 이상 늘지 않으면 다음 묶음으로 넘어갑니다. 데이터 정리가 50%에 못 미치면 이관보다 연결 작업을 먼저 끝냅니다.
AX 적용 제언. 국내 대기업과 중견기업 상당수가 그룹사 ERP, 부서별 패키지, 자체 개발 시스템을 겹겹이 쌓아 왔습니다. AI 시범이 부서 밖으로 퍼지지 않는다면 Qantas처럼 앱 목록과 데이터 연결 순서를 먼저 그리는 편이 낫습니다. 외부 파트너와 손잡을 때는 세 가지를 계약 전에 정합니다. 데이터 모델과 키 매핑 표는 회사 소유로 두고, 자동화 목표 시점을 이관 단계 성과 지표에 넣고, AI 판단 역량은 사내 조직에 남깁니다. 인력 영향은 CHRO가 처음부터 함께 설계해야 노조 협의와 이관 일정이 엇갈리지 않습니다. 첫 대상으로는 재무 전표와 구매 발주처럼 데이터 대상이 분명하고 처리량이 많은 업무가 좋습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | iTnews, Ry Crozier, 2026.11.10 |
| 보조 자료 | Cyber Daily(Hannah Dowling, 2026.11.10, Australian Aviation 원 게재), Mediaweek(2026.11.10) |
| 회사·상대 | Qantas Group, Accenture |
| 계약 | 다년 파트너십, 내부 이름 Project iQ |
| 범위 | 백엔드 시스템·프로세스·데이터 현대화, 본사 기능 일부 재설계·단순화 |
| 기술 부채 | 함께 돌아가도록 설계되지 않은 레거시 앱 1,000개 이상 |
| 투자 | Accenture가 데이터 플랫폼 현대화에 선투자 |
| 인력 영향 | 약 850개 직무, 앞으로 몇 년에 걸쳐. 첫 대상 재무·구매·인사·마케팅(노조 발표) |
| 업무 위치 | 주로 Accenture 인도 팀, 일부 호주 팀. 이후 자동화와 AI로 추가 전환 |
| 일정 | 첫 변화 2027년 중반 |
| 사내 AI 역량 | 애들레이드 제품 혁신 센터 약 400명 규모로 확대 |
| 기술 지출 | 연간 10억 달러 이상(Mediaweek) |
| 앞선 보도 | 8월 Australian Financial Review가 아웃소싱 계획 첫 보도 |
| 미공개 | 계약 금액, 해외 이관과 자동화로 나뉘는 직무 수, 절감 효과 |
핵심 개념
- Technical debt
- 빨리 만들거나 따로 들여온 시스템 때문에 나중에 치러야 할 정리 비용. 여기서는 서로 연결되지 않는 앱 묶음
- Legacy application
- 오래전에 만들어 지금도 쓰지만 새 시스템과 잇기 어려운 업무용 프로그램
- Back-end
- 고객이 직접 보지 않는 시스템과 업무. 재무, 구매, 인사 처리와 그 데이터
- Offshoring
- 업무를 다른 나라의 팀이나 외부 회사로 옮겨 처리하게 하는 것
- Redeployment
- 업무가 사라진 직원을 회사 안의 다른 자리로 옮기는 것
내 메모
TODO: 내 생각 추가
원문은 iTnews의 「Qantas taps Accenture for major IT and data modernisation」(Ry Crozier, 2026.11.10)입니다. 같은 날 같은 발표를 다룬 Cyber Daily(Hannah Dowling)와 Mediaweek 기사를 함께 읽고, 그 기사에만 있는 내용(CEO 직원 메일 인용, 연간 기술 지출, 1월 발언, 본사 위치)은 출처를 따로 적었습니다. 요약, 핵심 메커니즘의 원문 예, 사례, 원문 사례 표는 보도된 사실을 AX Review가 다시 정리했습니다. 핵심 메커니즘 이름(Integration Debt, Data Platform First, Transfer-Redesign-Automate, Onshore AI Core)은 이해를 돕기 위해 붙인 것이고 원문 용어가 아닙니다. JSON 예시, 키 매핑과 SOP 방식, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 업무명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.