업무에 AI를 사용하지 않는 회사는 뒤처진다고 해서, 우리 팀도 업무에 AI를 꽤 오래 써왔습니다.

AI를 사용하여 회의록을 요약하고, 기획서 초안을 만들고, 자료를 조사하고, 고객 피드백을 정리하고.. 
AI를 업무에 도입하니, 업무가 빨라진 것처럼 느껴졌습니다. 
빈 문서 앞에서 고민하던 시간이 줄었고, 회의 내용을 파악하기 위해 녹취록을 다시 듣는 일도 사라졌으니까요.

"이 정도면 AI를 잘 쓰고 있는 거지!"

한동안은 그렇게 믿었습니다. 적어도 이 질문을 받기 전까지는요.

“AI를 이렇게 계속 쓰고 있는데, 왜 우리는 할 일이 늘어나는 것처럼 느껴질까요..?”

맞는 말이었습니다.

AI가 작성한 회의록은 생겼지만, 회의에서 결정한 사항은 직접 다시 찾아야 했습니다. 
ChatGPT가 기획서 초안을 써주었지만, 개발자는 그 기획서를 바로 이해할 수 없었습니다. 
고객 피드백은 정리됐지만, 무엇을 먼저 제품에 반영해야 할지는 직접 사람이 판단하고 정리해야 했죠.

AI는 분명 결과물을 만들고 있었고, 우리는 그것을 보고 업무를 빠르게 해왔다고 믿었습니다.
하지만 그 결과물이 다음 업무로 자연스럽게 이어지지는 않았기에, 우리의 업무 시간은 변하지 않았죠.

회의록은 회의록으로 남았고, 초안은 초안으로 남았으며,
정리된 피드백은 누군가의 해석을 기다렸습니다.

결국 우리는 AI가 만든 결과물을 다시 읽고, 다시 고치고, 다시 다른 문서로 옮기고 있었습니다.

AI를 써도 인간의 정리는 끝이 없다. <이미지: ChatGPT 생성>

BCG의 2025년 9월 보고서 ‘The Widening AI Value Gap' (Build for the Future 2025 Global Study)에 따르면 1,250개 이상의 글로벌 기업 중 AI에서 실질적 가치를 만들어낼 역량을 갖춘 기업은 5% 수준밖에 되지 않았고, 60%는 거의 효과를 보지 못한 것으로 보도했습니다. 

5%밖에 되지 않는 기업 안에 드는 일, 즉 성과의 핵심은 AI도입이 아닌 AI전환을 이루어내야 한다는 점입니다. 

AI도입과 AX의 차이, 이제부터 알아보겠습니다.

AX란?

👉AX ( AI Transformation ): 단순히 AI 기술을 도입하는 것을 넘어, 
조직의 일하는 방식과 의사결정 구조, 비즈니스 운영 방식을 AI가 있는 환경에 맞게 다시 설계하는 것

AX를 이해하려면 이전에 자주 쓰였던 DX, 즉 Digital Transformation과 비교해보는 것이 좋은데요,

DX는 디지털 기술을 조직 전반에 적용해 프로세스, 제품, 운영 방식, 기술 구조를 현대화하는 전략적 변화로 설명됩니다. 
쉽게 말하면 종이, 엑셀, 수기, 오프라인 중심으로 돌아가던 업무를 디지털 시스템 위로 올리는 일이었습니다.

일상생활에서 접할 수 있는 예를 들면
전자 결재를 도입하고, 고객 정보를 CRM에 쌓거나 업무 협업을 메신저와 프로젝트 관리 툴로 옮기고,
팀의 데이터를 협업 툴 안에 저장하고 어디서든 볼 수 있게 바뀐 이 변화가 DX에 가깝습니다.

그렇다면 AX는 무엇이 다를까요?

IBM의 설명을 참고하자면, AI Transformation, 즉 AX는 기업이 AI를 운영, 제품, 서비스에 통합해 
혁신과 효율, 성장을 만드는 전략적 활동입니다.
뿐만 아니라 단순한 AI기술 도입을 넘어 업무 흐름, 조직 문화의 변화까지 필요하다고 말했습니다. 
<원문 : What is AI transformation? : IBM>

조금 더 쉽게 말해볼게요.

DX가 업무를 디지털 시스템 위로 올리는 과정이었다면,
AX는 AI가 일할 수 있는 방식으로 업무를 다시 설계하는 과정에 가깝습니다.

그래서 AX를 한 문장으로 말하면 이렇게 정리할 수 있습니다.

'AX는 업무를 할 때 AI를 많이 사용하는 것이 아니라, AI가 일할 수 있는 방식으로 업무를 다시 설계하는 일이다.'

AI를 써도 일이 그대로인 이유

앞서 말한 우리 팀처럼, 많은 조직은 왜 AI를 쓰고도 일이 크게 바뀌었다고 느끼지 못할까요?

이유는 간단합니다. 
AI를 업무에 “붙이기”는 했지만, 업무의 흐름은 그대로인 경우가 많기 때문입니다.

특히 제품을 만드는 팀에서는 이 차이가 더 분명하게 드러나게 됩니다.

제품 기획은 단순히 문서를 쓰는 일이 아니기 때문이죠.
고객의 요구와 회의에서 나온 아이디어를 기능 범위, 정책 조건, 화면 흐름, 개발 이슈 등 
수많은 다음 액션으로 이어지게 만드는 일이기에 차이는 더 크게 나타납니다.

예를 들어볼게요.
한 팀이 AI 회의록 요약 도구를 도입했다고 가정해본다면

• 회의가 끝나자마자 AI가 꽤 그럴듯한 요약본을 만들어준다.
• 참석자, 주요 논의 내용, 결정사항, 다음 액션까지 정리된다.
• 문서 하나에 간단하게 정리되니 편하며 효율적이라고 느낀다.
   

이전에는 누군가 회의 내용을 다시 듣고, 메모를 정리하고, 참석자들에게 공유해야 했기에
이 작업만 놓고 보면 AI의 도입은 굉장히 효율적입니다.

그런데 다음 날, 슬랙에 이런 메시지가 올라옵니다.

“어제 이 기능 하기로 한 거 맞나요?”
“그건 이번 주에 들어가는 건가요, 다음으로 미룬 건가요?”
"디자인은 A안으로 가는 건가요, B안으로 가는 건가요?”
“이거 개발 이슈는 누가 만들기로 했죠?”
“결정된 내용 기준으로 PRD는 누가 업데이트하나요?”

회의록은 생겼는데, 제품 기획은 여전히 다음 단계로 넘어가지 못하고 있는 상황이 펼쳐집니다.

AI가 요약을 못한 것은 아닙니다. 
요약된 정보가 제품 기획의 다음 산출물로 이어지도록 정리되지 않았던 것이 문제죠.

회의에서 나온 내용은 단순 기록으로 끝나면 안 됩니다.

어떤 요구사항으로 반영할지, 기능 범위는 어디까지인지, 
보류된 내용은 무엇인지, 개발자가 확인해야 할 조건은 무엇인지로 나뉘어야 합니다.

그래야 회의록이 단순한 요약본이 아니라
PRD와 기능명세서, 유저플로우, 개발 이슈로 이어지는 출발점이 될 수 있습니다.

이렇듯 제품 기획에서 중요한 것은 그럴듯한 문장을 빨리 만들어내는 것이 아닙니다.

팀이 같은 기준으로 이해하고, 디자이너가 화면 흐름을 잡고, 개발자가 구현 범위와 예외 조건을 판단할 수 있는 구조가 중요한 것이죠.

AI는 분명 일을 빠르게 해줬음에도 팀의 일하는 방식은 크게 달라지지 않은 이유는
AI의 결과물이 제품 기획의 다음 업무로 자연스럽게 이어지지 않았기 때문입니다.

이제 AI 활용과 AX의 차이가 보이시나요?

AI 활용이 ‘작업 하나를 AI로 빠르게 처리하는 것’이라면, 
AX는 “어떤 작업이 앞뒤 업무와 연결되는 방식을 바꾸는 것”입니다.

AI는 잘못된 흐름을 좋은 흐름으로 바꿔주지 않습니다.
오히려 잘못된 흐름에 AI를 붙이면, 비효율이 더 빠르게 반복될 뿐이죠.

결국 AX의 핵심은 ‘AI가 무엇을 만들어줬는가’가 아닙니다.

AI가 만들어준 결과물이 다음 업무로 자연스럽게 이어졌는가? 
AI가 만들어준 결과물을 사람이 다시 처음부터 해석하지 않아도 되는가? 
그 업무의 흐름이 반복 가능하게 시스템화되었는가?

이 질문에 답할 수 있을 때, AI는 단순히 결과물을 만드는 도구를 넘어 실제 업무 흐름 안으로 들어오는, 진정한 AX가 시작됩니다.

AI를 쓰는 것과 일하는 방식이 바뀌는 것은 다른 문제다. <이미지: ChatGPT 생성>

AX, 그래서 하면 뭐가 좋은데?

어렵게 작동하기 시작한 AX의 성과를 단순히 "업무가 빨라진다" 정도로 설명하면 안 됩니다.
AI는 이미 많은 작업을 빠르게 만들고 있기에, AX에게 가장 중요한 것은 그 속도가 실제 성과로 이어지는가입니다.

서론에서 소개했던 5%에 불과한 기업들, 즉 AI에서 실질적 가치를 만들어낼 역량을 갖춘 기업들의 공통점은 AI를 핵심 업무에 통합하고 워크플로우를 다시 설계하며 데이터 기반과 인재 역량을 함께 갖추었다는 점이었습니다.

<참고 문헌 : The Widening AI Value Gap (Build for the Future 2025 Global Study)>

이처럼 AI를 단순히 사용할때가 아니라 AI를 업무 흐름 안에 제대로 넣는 AX가 시작될 때 성과가 납니다.

그렇다면 AX가 잘 됐을 때 실제로 무엇이 달라질까요?

가장 먼저 바뀌는 것은 판단의 선명함입니다.

AI를 쓴 문서 덕분에, 필요한 정보는 더 빠르게 만들어집니다. 
하지만 정보가 많아진다고 판단이 쉬워지는 것은 아니죠. 
회의록이 요약되어도 결정 사항이 분리되어 있지 않으면 다시 읽어야 하고
고객 피드백이 수십 개 정리되어 있어도 우선순위가 없으면 무엇부터 해야 할지 알기 어려워 다시 읽고 정리를 반복할 뿐입니다.

AX는 바로 이 지점을 바꾸는 일입니다.

AI가 만든 결과물이 단순한 텍스트가 아니라 결정 사항, 보류 사항, 담당자, 다음 할 일처럼 업무에 필요한 형태로 정리되면
사람은 자신이 무엇을 판단해야 하는지 선명하게 파악하고 AI에게 명령할 수 있게 됩니다.

이렇게 판단해야 하는 것이 선명해지면, 다음 업무로 넘어가는 속도 역시 달라집니다. 
AI가 빠르게 만든 결과물이 다음 업무의 출발점이 되기에, 빠르게 다음 작업을 진행할 수 있기 때문입니다.

회의록은 단순 기록이 아니라 할 일이 되고,
고객 피드백은 단순 의견이 아니라 요구 사항이 되고,
아이디어는 단순 메모가 아니라 실행 가능한 작업 단위로 이어집니다.
 

결국 AI도입에서 AI전환으로 도약하기 위해서는 아래와 같은 방향으로 AI 활용을 바꾸어야합니다.

"회의록을 더 빨리 요약하자"❌ → "회의에서 결정된 내용이 PRD와 다음 액션으로 이어지게 하자" ✅
"기획서를 더 빨리 쓰자" ❌ → "고객 요구가 기능명세와 정책 조건으로 정리되게 하자" ✅
"고객 피드백을 더 빨리 정리하자"❌ → "고객 요구가 요구사항과 기능 우선순위로 이어지게 하자"✅
"아이디어를 더 빨리 정리하자" ❌ → "아이디어가 기능명세서와 유저플로우로 이어지게 하자" ✅

결국 AX가 줄이는 것은 단순히 작업 시간만이 아닙니다.

사람이 같은 내용을 다시 설명하고, 다시 이해하고, 다시 수정하는 수많은 반복 작업의 비용을 줄이는 것입니다.

AI를 업무 흐름 안에 제대로 넣어야 업무의 속도가 달라진다. <이미지: ChatGPT 생성>

AI가 다음 업무로 이어지기 위한 4가지 조건

여기까지 보면 AX는 “AI를 어떻게 잘 쓰느냐”의 문제처럼 보일 수 있습니다.

하지만 AI를 잘 쓰는 것과, AI가 만든 결과물이 다음 업무로 이어지는 것은 전혀 다른 문제입니다.

회의록을 '잘' 요약하는 것 만으로 회의 이후의 작업이 끝나는 것이 아닙니다.
고객 피드백을 '잘' 정리하는 것만으로 요구사항을 완성시킬 수 없습니다.
기획서 초안을 '잘' 만드는 것 만으로 개발자가 바로 일할 수 있는 명확한 기준이 생기지 않습니다.

결국 AI가 업무 흐름 안에서 제대로 작동하려면(=AX로 도약하려면) 맥락, 구조, 판단, 반복 이 네 가지 조건이 필요합니다.

이 요소들이 갖춰질 때, AI는 단순한 결과물 생성 도구를 넘어 우리의 업무 흐름 안으로 들어와 반복 작업 비용을 줄여줄 수 있습니다.

AI가 다음 업무로 이어지기 위한 4가지 조건

여기까지 보면 AX는 "AI를 어떻게 잘 쓰느냐"의 문제처럼 보일 수 있습니다.
하지만 AI를 잘 쓰는 것과, AI가 만든 결과물이 다음 업무로 이어지는 것은 전혀 다른 문제입니다.

앞에서 봤던 그 팀, 회의록은 생겼는데 다음 날 슬랙에 "이거 하기로 한 거 맞나요?"가 올라오던 팀을 다시 떠올려볼게요. 

이 팀이 회의록 도구를 버렸을까요? 

아닙니다. 도구는 그대로 두고, 네 가지를 바꿨습니다. 
그리고 이 네 가지가 바로 AI가 업무 흐름 안에서 작동하기 위한 조건, 맥락, 구조, 판단, 반복입니다.

1) 맥락 : AI가 참고할 기준이 있어야 합니다

이 팀의 첫 번째 문제는 AI가 회의 내용"만" 알고 있었다는 점입니다.

지난 회의에서 보류된 기능이 무엇인지, 이번 분기 목표가 무엇인지, 어떤 고객 요구에서 이 논의가 시작됐는지 AI는 모릅니다. 그러니 회의에서 "그건 지난번에 얘기한 대로 가시죠"라는 발언이 나오면, AI 요약본에도 딱 그만큼만 적힙니다. 

'지난번에 얘기한 대로 진행하기로 함.' 

결국 읽는 사람은 결국 지난 회의록을 다시 뒤지게 되죠.

그래서 이 팀은 회의록 도구에 요약을 시키기 전에, 지난 회의의 결정사항과 보류사항, 진행 중인 기획 문서를 함께 참조하게 했습니다. 그러자 같은 발언이 이렇게 요약되기 시작했습니다.

 '결제 수단 추가는 지난 회의에서 합의한 대로 카드 우선, 간편결제는 2차로 보류.'

중요한 것은 자료를 많이 넣는 것이 아니라, AI가 참고할 맥락을 남기고 그 맥락이 흩어지지 않게 관리하는 것입니다. 회의록, 고객 피드백, 정책 조건이 각각 따로 존재할 때보다 하나의 흐름 안에서 연결될 때, AI는 비로소 팀의 상황을 바탕으로 결과물을 만들 수 있습니다.

2) 구조 : 다음 사람이 쓸 수 있는 형태여야 합니다

맥락을 넣어도 문제가 하나 남았습니다. 요약본이 잘 쓰인 '글'이었다는 점입니다.

문단으로 흘러가는 요약은 읽기에는 자연스럽지만, 개발자가 "그래서 내가 만들 게 뭔데?"를 찾으려면 처음부터 끝까지 읽어야 합니다. 그래서 이 팀은 회의록의 형식을 정해버렸습니다. 
어떤 회의든 결과물은 반드시 결정사항 / 보류사항 / 담당자 / 다음 할 일 네 칸으로 나뉘게요.

형식 하나 바꿨을 뿐인데 변화는 컸습니다.
 디자이너는 결정사항 칸만 보고 A안으로 시안 작업을 시작했고, 개발자는 다음 할 일 칸에서 자기 이름이 붙은 항목만 골라 이슈를 만들었습니다. 회의록을 "읽는" 사람이 사라지고, "쓰는" 사람만 남은 거죠.

AX 관점에서 중요한 것은 결과물의 양이 아니라 구조입니다. 기획서도 마찬가지입니다. 

아무리 자연스럽게 쓰인 초안이라도 기능 범위, 정책 조건, 예외 케이스가 구분되어 있지 않으면 개발자는 다시 질문하게 될 뿐이거든요.

3) 판단 : 팀에게 맞는 좋은 판단은 결국 사람이 해야 합니다

그런데 형식을 갖춘 회의록에도 함정이 있었습니다. 

AI가 '결정사항' 칸에 넣은 내용이 사실은 회의에서 결정되지 않은 것일 때가 있었거든요. 
누군가 강하게 주장한 의견을 AI가 합의로 오해한 겁니다. 이걸 그대로 믿고 개발이 시작됐다면, 슬랙 질문 정도가 아니라 일주일치 작업이 날아갔을 겁니다.

그래서 이 팀은 규칙을 하나 더 만들었습니다. 회의록이 생성되면 회의 주재자가 5분 안에 결정사항 칸만 검토해서 확정하는 것. AI의 산출물은 그 확정 전까지는 '초안'이고, 확정 후에야 팀이 움직이는 '기준'이 됩니다.

판단에서 필요한 것은 프롬프트를 잘 쓰는 능력이 아닙니다. 

AI가 만든 결과물이 왜 그렇게 나왔는지 이해하고, 어느 수준까지 믿을 수 있는지 해석해서, 실제 업무의 기준으로 확정하는 능력이죠. AI에게는 빠르고 잘하는 일을 맡기되, 그 결과물을 팀의 기준으로 만드는 역할은 사람에게 남습니다.

4) 반복 : 한 번의 결과가 팀의 방식으로 쌓여야 합니다

마지막 변화는 가장 조용했지만 가장 컸습니다.

몇 주가 지나자 이 팀에는 데이터가 쌓이기 시작했습니다. 

어떤 맥락을 넣었을 때 요약 품질이 좋아졌는지, 결정사항 칸에서 자주 틀리는 패턴이 무엇인지, 개발자가 회의록을 보고도 다시 묻는 조건이 무엇인지. 개발자가 세 번 연속으로 "예외 케이스는요?"라고 물었다면, 그건 다음 회의록 형식에 '예외 케이스' 칸을 추가하라는 신호입니다.

이 팀은 그 신호들을 그때그때 회의록 템플릿과 검토 체크리스트에 반영했습니다. 
좋은 결과가 우연이 아니라 형식이 되도록요.

AI를 통해 성과를 한 번 냈다고 업무 방식이 바뀌지는 않습니다. 
좋은 결과가 나왔을 때 그 이유를 팀 안에 축적해야, AI는 일회성 도구가 아니라 팀의 일하는 방식 안으로 들어오기 시작합니다.

AI를 업무 흐름 안에 넣기 위한 4가지 조건 <이미지: ChatGPT 생성>

AI가 참고할 맥락을 남기고

결과물을 쓸 수 있는 구조로 만들고

사람이 그것을 판단해 다음 업무로 연결하고

그 방식을 팀 안에서 반복하는 것

이 네 가지가 함께 움직일 때, AI는 단순히 결과물을 만드는 도구를 넘어 일하는 방식의 일부가 됩니다.

AX는 작은 ‘업무 흐름’에서 시작된다

여기까지 읽으면 AX가 아주 거대한 조직 혁신처럼 느껴질 수도 있겠지만
너무 거창하게 생각할 필요는 없습니다.

실무에서는 오히려 아주 작은 업무 흐름에서 시작될 수 있거든요.

“이 회의 내용에서 다음 할 일로 정리가 잘되었나?” 
“고객 피드백이 요구사항으로 잘 정리되고 있나?” 
“AI가 만든 초안을 보고 팀원이 사용할 수 있는 상태인가?”

특히 제품을 만드는 팀이라면 이 질문이 더 익숙할 겁니다.

매일 수많은 정보가 생기는 제품 개발 과정에서 나오는
고객 피드백, 회의에서 나온 아이디어, 기능 요구사항, 화면 흐름, 
정책 조건, 개발자가 확인해야 할 예외 케이스…

이 정보들이 한 번에 정리되지 않죠.

아이디어는 회의록에 있고, 
고객 요구는 CS에 남아 있으며, 
기능 범위는 별도 문서에 적혀 있고, 
세부 조건은 슬랙이나 메모 어딘가에 흩어져 있는 답답한 상황을 많이 마주해 보셨을 겁니다.

이 상태에서 AI에게 “다 읽고 기획서 하나 써줘”라고 말하면 어떻게 될까요?

그럴듯한 초안은 나올 수 있겠지만, 
실무자는 결국 아래와 같은 질문을 하게 됩니다.

“이 내용은 어떤 고객 요구에서 나온 거지?” 
“이전 회의에서 보류한 내용은 반영됐나?” 
“개발자가 구현하려면 어떤 조건까지 적어야 하지?”

결국 다시 사람이 맥락을 파악하고, 연결하고, 정리하는 반복 작업이 생기게 되는 거죠.

이런 비효율을 피해, AI로 다음 업무에 쓸 수 있는 결과물을 만들려면
AI가 참고할 맥락과 프로젝트의 흐름이 정리되어 있어야만 합니다.

결국 중요한 것은 AI에게 글을 쓰게 하는 것이 아니라, AI가 일할 수 있는 흐름을 만들어주는 것이죠.

매니패스트가 집중하는 지점도 바로 이 흐름입니다.

제품 기획 과정에서 흩어진 아이디어와 고객 피드백, 회의 내용을 단순히 정리하는 데서 끝내지 않고
요구사항과 기능명세서, 유저플로우로 이어지게 만드는 것입니다.

IT 제품의 기획 과정에서 매니패스트는

흩어진 아이디어와 기획 내용을 맥락에 맞게 파악하고

그 맥락을 바탕으로 요구사항을 구조적으로 정리하고

사람에게 필요한 질문을 던지며 판단 기준을 세워가고

다음 업무에 바로 쓸 수 있는 형태의 결과물로 만듭니다.

즉, 기획서가 단순한 아이디어 정리나 기능 나열, 화면 아이디어에서 끝나지 않도록 도와줍니다.
기획자가 판단할 수 있는 기준이자, 팀이 다음 업무를 시작할 수 있는,
출발점이 되는 기획 흐름으로 만드는 것입니다.

물론, 매니패스트 하나로 조직 전체의 AX를 기획하고 완성시킬 수는 없습니다.

하지만 제품을 만드는 팀이 “AI가 만든 결과물이 다음 업무로 이어지지 않는 문제”를 느끼고 있다면, 
기획 흐름을 바꾸는 좋은 시작점이 될 수 있으리라 믿습니다.

마무리하며

결국 AX는 AI가 만든 결과물이 사람의 재정리 없이 다음 업무로 이어지도록, 일의 흐름을 다시 설계하는 일에 가깝습니다.

그 출발점은 거창한 전환이 아니어도 됩니다.

회의록이 다음 할 일로 이어지고 있는지
고객 피드백이 요구사항으로 정리되고 있는지
AI가 만든 초안이 팀원이 바로 사용할 수 있는 기준이 되고 있는지

이런 작은 질문에서 시작할 수 있습니다.

결국 중요한 것은 하나입니다.

"AI가 만든 결과물을 통해 다음 업무를 빠르게 진행할 수 있는가?"

이 질문에 답하기 위해서는 AI에게 맡길 맥락을 남기고, 
결과물을 쓸 수 있는 구조로 만들고, 
사람이 판단해 기준을 세우고, 
그 방식을 팀 안에 반복해서 쌓아야 합니다.

그때 AI는 단순히 결과물을 만들어주는 도구를 넘어, 팀의 일하는 방식 안으로 들어오기 시작합니다.

흩어진 아이디어와 요구사항이 다음 업무로 잘 이어지지 않는다면, 
매니패스트에서 기획 흐름을 먼저 정리해보세요.

 

PRD와 기능명세서, 유저플로우와 와이어프레임까지 이어지는 기획 흐름 정리하기 👉manyfast.io