이 글은 플렉스웍 블로그에서 발행되었습니다. 뉴스레터 구독 시 AI 워크플로우 실무 가이드도 함께 받을 수 있습니다.

플렉스웍 뉴스레터 무료 구독하기

3줄 요약 

• AI 도구를 도입하는 것과 AI 중심으로 업무 프로세스를 다시 설계하는 것은 전혀 다른 일입니다.

• 영국의 한 메드테크 스타트업은 도입 시작부터 안정기까지 10개월이 걸렸고, 그 사이 세 직군의 협업 구조가 순차에서 동시 진행으로 바뀌었습니다.

• 결국 조직에 필요한 건 AI를 잘 쓰는 사람이 아니라, AI와 함께 일하는 방식을 설계할 수 있는 사람입니다.

"AI 도구는 도입했는데, 왜 일하는 방식은 그대로일까요?"

플렉스웍 x 기고만장 웨비나에서 황소흠 프로덕트 디자이너가 던진 질문입니다.

요즘 안 써본 조직이 없습니다. ChatGPT, Gemini, Copilot. 그런데 대부분 여기서 멈춥니다. 도구만 배포하고, 일하는 방식은 그대로 두는 겁니다.

진짜 변화는 그다음부터입니다. 이 도구가 있다는 전제로 업무 프로세스를 어떻게 다시 짤 것인가.

황소흠 님은 이 질문에 답을 찾아가는 과정을 사례 하나로 풀어냈습니다. 의료기기 AI 인증 솔루션을 만드는 영국 메드테크 스타트업입니다. Flok Health, Lucida Medical, Floy 같은 회사가 고객사입니다. 병원과 의료기기 제조사가 규제 인증을 빠르게 통과하도록 돕는 게 이 회사 사업입니다.

그런데 발표에서 진짜 흥미로웠던 건 이 회사가 뭘 만드는지가 아니었습니다. 이 회사 안에서 사람들이 어떻게 일하는지, 그게 AI 도입 전후로 어떻게 달라졌는지였습니다.

순서대로 넘기던 일이, 동시에 진행하는 일로 바뀌었습니다

원래는 이랬습니다.

아이디어가 나오면 엔지니어링, 디자인, 프로덕트가 순서대로 일했습니다. 한 직군이 끝나야 다음 직군에 바통을 넘겼습니다. 세 직군의 작업 구간은 시간 축 위에서 하나도 겹치지 않았습니다.

그러다 보니 어느 한 단계만 늦어져도 전체 리드타임이 그대로 늘어났습니다.

지금은 다릅니다.

같은 세 직군이 작업 구간을 겹쳐가며 동시에 움직입니다. 기능 하나 출시하는 데 걸리는 시간이 눈에 띄게 줄었습니다.

핵심은 사람을 더 뽑은 게 아니라는 점입니다.

순서대로 넘기던 협업 구조 자체를 동시에 진행하는 방식으로 바꾼 것입니다.

AI 덕분에 각 직군이 다른 직군 영역까지 어느 정도 커버할 수 있게 되면서 생긴 변화입니다.

10개월이 걸렸습니다

이 변화는 하루아침에 일어나지 않았습니다. 발표는 이 과정을 세 단계로 나눕니다.

2025년 10월, 도입 시작. 디자인, 프로덕트, 의료 심사원, 기술 운영팀이 각자 ChatGPT, Gemini, Copilot을 따로따로 써봤습니다.

2026년 1월, 과도기. 직군별로 나름의 활용법이 생기기 시작했습니다. 그런데 팀마다 격차가 뚜렷하게 벌어졌습니다.

2026년 8월, 안정기. 범용 도구 수준을 넘어 팀 고유의 워크플로우, 표준 프로세스로 자리 잡았습니다.

즉 AI 도입은 한 번의 결정이 아니라 최소 6개월에서 10개월짜리 학습 과정이라는 뜻입니다.

도입 초기와 안정기의 활용 수준 차이가 이렇게 크기 때문에, 단기간에 성과를 판단하면 안 됩니다. 단계별로 다른 목표를 잡아야 합니다.

디자이너가 코드를 짰습니다

디자인 팀은 Figma 기반 워크플로우를 버리고 AI 기반 코드 생성 도구로 넘어갔습니다.

원래는 화면 단위로 디자인 파일을 여러 개 만들어 관리했습니다. 디자이너가 화면을 설계해서 개발자에게 넘기면, 개발자가 그걸 다시 코드로 옮겼습니다.

지금은 버튼, 인풋, 셀렉트 같은 요소를 디자이너가 곧바로 "실제 작동하는 코드"로 만듭니다. "View code" 버튼 하나로 개발팀이 바로 갖다 쓸 수 있는, 재사용 가능한 UI 컴포넌트 라이브러리가 됐습니다.

디자이너와 개발자 사이 "전달"이라는 단계가 통째로 사라진 겁니다.

디자이너가 설계만 하는 게 아니라 검증까지 같이 하는 쪽으로 역할이 넓어졌습니다.

반복 업무는 에이전트에게 넘겼습니다

기술 운영팀 이야기입니다. 개발 환경 구축, 코드 리뷰, PR 관리처럼 반복적이고 규칙이 정해진 업무를 AI 에이전트에게 위임했습니다.

/automate, /review, /split-to-prs 같은 명령어를 팀 전체가 표준으로 씁니다. 한 사람 한 사람이 "이럴 땐 이렇게 물어보면 되더라" 하고 쌓아온 노하우를, 팀 전체가 재사용할 수 있는 시스템으로 만든 것입니다.

QMS(품질경영시스템) 문서나 감사 증빙 자료를 올리고 검토하고 승인하는 과정에도 상태 기반 워크플로우가 들어갔습니다. 담당자가 자료를 올리면 "검토 중 → 승인" 단계를 시스템에서 그대로 추적할 수 있습니다.

규제 산업이라 사람이 최종 승인해야 하는 지점은 남겨뒀습니다. 대신 그 앞뒤 업로드, 정리, 상태 추적은 다 자동화했습니다.

대부분 여기서 멈춥니다

발표에서 가장 강조된 대목입니다. "AI 툴만 도입"과 "업무 프로세스 재정의"는 다릅니다.

대다수 조직은 ChatGPT, Gemini, Copilot을 배포하는 단계에서 멈춥니다. 진짜 변화를 만드는 조직은 여기서 한 걸음 더 갑니다. 작은 단위라도 업무 프로세스 자체를 다시 정의합니다.

도구를 얹는 건 개인의 작업 속도를 조금 높여줍니다. 일하는 방식을 바꾸는 건 팀의 협업 구조와 산출물의 질 자체를 바꿉니다.

황소흠 님은 이 차이를 이렇게 정리했습니다. "도구를 얹는 것"과 "일하는 방식을 바꾸는 것"은 다릅니다.

그래서 남는 세 가지

이 사례가 모든 조직의 정답은 아닙니다. 그런데 AI를 도구가 아니라 업무 시스템의 일부로 쓸 때 뭐가 달라지는지는, 개인·팀·조직 세 층위로 정리해볼 수 있습니다.

개인. AI는 생산성 도구에서 팀의 인프라로 자리를 옮깁니다. ChatGPT를 잘 쓰는 사람 한 명이 생기는 것과, 팀 전체가 /review, /automate로 활용법을 표준화하는 건 다른 이야기입니다.

팀. 직군의 경계보다 업무의 흐름이 중요해집니다. 디자이너가 코드를 이해하고, 기술 운영팀이 반복 업무를 AI에게 넘기면서, 순서대로 넘기던 협업이 동시에 진행하는 협업으로 바뀝니다.

조직. 결국 필요한 건 'AI를 잘 쓰는 사람'이 아니라 'AI와 함께 일하는 방식을 설계할 수 있는 사람'입니다.

도구를 얹는 것과 일하는 방식을 바꾸는 것, 그 차이는 결국 이 설계를 누가 할 수 있느냐에서 갈립니다.

본 정리본은 Flexwork x 기고만장 웨비나 1부, 황소흠 Product Designer 발표 자료를 바탕으로 작성됐습니다. 사례로 소개된 영국 메드테크 기업은 발표에 인용된 해외 기업 사례이며, 저작권은 원 발표자 및 해당 기업에 있습니다.