AI와 함께 일하며 체감한 업무 프로세스의 변화

속도는 빨라졌고, 판단은 더 중요해졌다.

Jan 28. 2026

최근들어 개인 작업에서 AI를 활용하는 일이 많아졌습니다.

앱도 몇개 만들어보고, 함께하는 사이드 프로젝트도 진행하면서 AI가 실제 제 업무 프로세스에 어떤 변화를 주었는지 정리 겸 적어보려 합니다. 이 글은 제 개인적인 경험을 바탕으로 정리한 내용이어서 모든 분들께 동일하게 와닿지는 않을 수도 있다는 점 이해해주시면 감사하겠습니다.

프로세스는 편의상 더블다이아몬드 기준으로 나눠서 정리했습니다.

Discover

Before
- 데스크 리서치 + 인터뷰를 모두 거쳐야 공감이 완성되는 느낌

After
- 데스크 리서치 단계에서 공감의 대부분이 형성됨
- 인터뷰는 검증과 디테일 보완에 집중
- 인터뷰 전·후 과정 전반이 크게 단축

그동안 사용자에 대한 공감을 끌어올리는 수단으로 데스크 리서치와 인터뷰를 활용해왔습니다. 전체적인 틀은 크게 달라지지 않았지만, 데스크 리서치의 퀄리티는 확실히 많이 올라갔다고 느꼈어요. AI와 대화를 통해 인터뷰를 하지 않아도 도메인 지식을 쌓는 속도가 이전과 비교해 훨씬 빨라졌거든요.

어느 정도로 체감되냐면, 예전에는 인터뷰를 통해서야 비로소 새로운 정보를 얻게 되는 경우가 많았다면, 지금은 AI를 통해 충분한 정보를 확보한 상태에서 인터뷰를 진행해도 될 정도가 되었어요. 그래서 인터뷰의 역할도 데스크 리서치에서 얻은 가설이나 이해를 검증하고 디테일을 보완하는 도구에 더 가까워진 게 아닐까라는 생각이 들었습니다.

인터뷰 전후 과정도 굉장히 단축되었어요. 맥락에 맞는 인터뷰 질문지 작성도 AI가 도와주고, 질문 자체도 충분한 네러티브와 의도를 담고 있다고 느꼈습니다.

예전에는 인터뷰를 다녀오면 녹취본을 받아 적고 정리하는 데 하루를 다 쓰곤 했는데, 이제는 녹취부터 정리까지 한 번에 진행되다 보니 인터뷰 이후 작업이 훨씬 가벼워졌어요. 개인적으로는 이 과정이 노동에서 검토로 바뀌었다는 점이 가장 크게 느껴졌습니다.

Define

Before
- Discover에서 발산된 데이터를 긁어 모아 정리하는데 많은 시간을 소비

After
- AI에게 리서치 데이터를 제공하면, 결과물이 한번에 도출됨 (정리와 초안 작성을 보조하는 역할)
- 문제 정의의 최종 판단은 여전히 디자이너의 몫
- AI 개입이 체감되긴 하지만, Discover만큼 극적이진 않음

앞단계만 탄탄하게 정리해놓았다면 문제 정의 단계에서 사용자의 페인포인트와 니즈, 목적을 만드는 것은 리서치 데이터에 기반하여 빠르게 도출할 수 있게 되었습니다.

완성본은 아니더라도, 문제 정의의 초안 정도는 AI의 도움을 받아 빠르게 만들어볼 수 있겠다는 생각이 들었어요. 특히 PRD, 유저스토리처럼 문제 정의의 내러티브를 구성하는 과정에서 꽤 유용하게 느껴졌습니다.

하나 깨달은 건, 문제 정의 단계에서는 여전히 ‘좋은 문제를 고르는 감각’이 중요하다는 점이었어요. AI는 맥락을 정리하고 그럴듯한 문제 정의의 형태를 만들어주는 데는 능숙하지만, 그 정의가 지금 이 프로덕트에서 정말 중요한 문제인지까지 판단해주지는 않더라고요.

결국 어떤 문제를 선택하고 어디까지를 문제로 볼 것인지는 디자이너의 경험과 감각에 가까운 영역이라는 생각이 들었습니다.

Develop & Deliver

Before
- 시안: 혼자서 생각해내기에는 충분치 않았던 아이디어
- 산출물: 보통 피그마를 통해 그려진 정적인 디자인, 최대 메인 시나리오에 대한 프로토타입까지

After
- 시안: 베스트 프렉티스, 레퍼런스 등을 종합하여 본인의 아이디어와 최종 합작.
- 특히 레퍼런스는 구현 단계에서 매번 새롭게 탐색하고 언제든 차용할 수 있게됨.
- 산출물: 개발로 구현(피그마로 직접 그리지 않아도 되어 시간 효율이 크게 올라감)

결과물까지 만들어내는 시간이 짧아졌다.

Develop & Deliver 단계에서 가장 크게 느낀 변화는 아이디어를 생각하는 시간보다 실제 결과물로 옮기는 속도가 확실히 달라졌다는 점이었어요. 이 변화를 가장 잘 보여주는 두 가지 프로젝트 사례를 아래에서 이야기해볼게요.

실험 1: 기존 프로덕트 확장(Web)

이 실험에서는 AI를 활용해 기존에 잘 만들어진 프로덕트를 얼마나 빠르게 코드로 재현하고, 그 위에 새로운 기능을 얹을 수 있는지를 확인해보고 싶었어요.

적어도 기존에 잘 만들어진 웹이라면, 실제 돌아가는 프로토타입 수준에서는 이제 꽤 높은 완성도로 재현해볼 수 있는 환경이 된 것 같아요. 저는 기존 서비스를 재구현한 뒤 그 위에 새로운 기능을 얹어 프로토타입을 완성해봤는데요. 흥미로운 점은 이 과정 전체에서 피그마로 직접 작업한 시간이 30분도 채 되지 않았다는 거였어요.

접근 방식

전체 과정을 아주 단순하게 정리하면, 크게 3단계로 나눌 수 있었어요.

기존 프로덕트 해체 분석하기

기존 프로덕트 똑같이 구현하기

새로운 기능을 추가하여 프로토타입 만들기

리서치 & 해체 분석

AI를 활용해보며 느낀 점은 앞단에서 얼마나 양질의 데이터를 제공하느냐에 따라 결과물의 차이가 꽤 크게 난다는 거였어요. 특히 기존 프로덕트를 해체 분석하는 과정에서는 몇 번의 경험을 거치며 어떤 정보를 어떻게 전달해야 완성도가 높아지는지도 스스로 많이 학습하게 되더라고요.

‘기존 프로덕트 해체 분석’을 위해 제가 AI에게 제공했던 정보는 세 가지입니다.

웹사이트 풀페이지 스크린샷

html.to.design을 통해 피그마로 레이어 정보를 가져온 뒤, Figma MCP를 활용해 코드로 옮기기

Playwright라는 프론트엔드 도구를 활용해 실제 동작하는 웹페이지의 구조와 정보를 추출하기

위 세 가지 정보를 전달하고 후보정을 해주니, 프로토타입 수준만큼은 실제 깃헙 프로젝트를 포크뜨지 않아도 기존 프로덕트를 거의 복붙에 가까운 수준으로 재현할 수 있었어요.

구현 팁

구현하면서 느낀 팁을 몇 가지 정리해보면, 한 번에 많은 정보를 전달하기보다는 정보를 쪼개서 단계별로 제공하는 편이 결과물의 완성도를 높이는 데 도움이 되더라고요. 그리고 분석한 내용을 바탕으로 디자인 시스템을 함께 구축해두면 훨씬 일관성 있게 구현할 수 있었어요.

아이데이션 & 구현

기존 기능을 재현하는 데 어느 정도 익숙해지고 나니, 그 다음부터는 새로운 기능을 붙이는 쪽도 흥미로워졌어요. 이 과정을 거치면서 어떤 프로젝트는 피그마에서 직접 그리는 시간이 거의 필요 없을 수도 있겠다는 생각이 들 정도로, 아이디어를 발산하고 구현하는 단계가 대폭 단축되었다는 걸 느꼈거든요.

저는 기본적으로 PRD를 학습시켜두고, 레퍼런스나 벤치마크 소재를 개발 중간중간 AI와 대화하면서 찾아가며 활용했습니다. 개인적으로 이 부분이 가장 시사점이 컸어요. 과거에는 레퍼런스 리서치를 데스크 리서치 단계에서 한 번에 진행했다면, 이제는 프로덕트 개발 과정 속에서 아이디어가 생길 때마다 계속 탐색하게 되더라고요.

PRD 맥락을 바탕으로 떠오른 여러 아이디어 옵션들은 구현된 프로토타입에서 브랜치를 나눠 비교해볼 수 있었어요. 이 과정에서 AI가 방향을 대신 결정해주지는 않았습니다. 다만 여러 선택지를 빠르게 만들어볼 수 있었고, 그중 어떤 방향이 지금 상황에 맞는지는 제가 판단해야 했어요.

결국 이 단계를 통해서 ‘만들어내는 속도’보다 여러 결과물 중 ‘무엇을 선택할지’에 대한 디자이너의 판단이 더 중요해졌다는 느낌을 받았습니다.

이런 프로세스가 어떻게 가능했을까?

이 모든 과정이 가능했던 이유를 굳이 하나 꼽자면, 디자인 시스템이 어느 정도 받쳐주고 있었던 덕분인 것 같아요. 시스템에 기반해 구현하다 보니 결과물의 톤이 쉽게 흐트러지지 않았고, 그래서 더 빠르게 반복할 수 있었습니다. 만들면서도 몇 번이나 “이게 되네…” 싶더라고요.

만약 개인 포폴이나 사이드 프로젝트 만들기를 목적으로 한다면 한번 시도해보셨으면 좋겠어요 ㅎㅎ

실험 2: 새로운 프로덕트 구축(Native App)

사이드 프로젝트로 영어 공부 앱을 하나 만들어보고 있어요. 스픽, 듀오링고, 케이크, 말해보카, 컬컴까지 이것저것 써보면서 느낀 점이 있었는데, ‘내가 원하는 콘텐츠로 영어 공부를 하려면 생각보다 제약이 많다’는 거였어요. 콘텐츠가 제 취향이 아니면 학습이 지속되지 않는 게 제일 큰 문제였거든요.

TED 강연이나 프렌즈 같은 유명한 콘텐츠는 많지만, 그걸로 공부하는 건 저한테는 좀 지루해서 손이 잘 안 가더라고요. 저는 해외 아티스트를 좋아해서 테일러 스위프트나 타일러 더 크리에이터 같은 셀럽 인터뷰를 듣고, 이해하고, 쉐도잉까지 할 수 있으면 좋겠다는 생각으로 시작하게 됐어요.

리서치 앱은 웹과 비교하면 실제 UI 구조를 데이터로 가져오기가 어려워서, 스크린샷 중심으로 접근하게 됐어요. 그래서 처음에는 AI에게 앱 레퍼런스를 리서치시키고, Mobbin 스크린샷과 플로우 정보를 함께 제공하는 방식으로 시작했습니다.

프로토타입에다가 차용하고 싶은 앱의 디자인 시스템을 참고 자료로 학습시키면, 제가 만들고 싶은 브랜드나 프로덕트의 분위기가 훨씬 빨리 잡히더라고요.

로파이 프로토타입 + 디자인 시스템

이렇게 만들어낸 로파이 프로토타입과 디자인 시스템 두 가지 조합은 생각보다 조합이 잘맞았어요. 프로토타입이 전체 흐름과 구조를 잡아주고, 디자인 시스템이 그 위를 채워주면서 결과물의 퀄리티를 어느 정도 고정해줬거든요.

주요 시나리오

만든 프로젝트의 주요 시나리오는 아래와 같아요.

사용자가 원하는 유튜브 링크를 삽입한다.

서비스가 영상을 분석해 학습용 스크립트/퀴즈 형태로 변환한다.

사용자는 생성된 학습 자료로 반복 학습한다.

이 시나리오 중에서도 저는 2번, ‘학습 형태로 변환하는 단계’를 중심으로 AI를 활용했어요. 이 단계를 얼마나 구조화하느냐가 전체 경험을 좌우한다고 느꼈거든요.

아이데이션

위 웹 프로젝트와 다른 점이 하나 있었어요. 새로 구축하는 프로덕트라 화면 구성 단계부터 Figma Make를 적극 활용해봤다는 점이에요. 프로젝트에서 제일 중요한 건 ‘영어 학습 페이지’였는데, 그에 대한 아이디어를 Figma Make와 합작으로 만들어봤습니다.

제가 Figma Make에 썼던 프롬프트는 딱 두 개였네요.

“듀오링고 앱의 영어 단어 조합 퀴즈 화면 만들어줄 수 있어?”

“(스크린샷 첨부) 케이크라는 앱의 학습 화면인데, 영상에 나오는 문장 단위의 스크립트를 방금 만든 듀오링고 스타일의 단어 조합 퀴즈 UX로 만들고 싶어.”

구현으로 연결

이렇게 만든 첫 결과물은 썩 맘에 들지는 않았어요. 대신 핵심 의도는 참고할 만해서 몇 번만 손보면 바로 구현 단계로 넘어갈 수 있겠더라고요. 그것도 진짜 러프하게, 대충 손봐도 말이죠.

대충 손봐준 화면은 Figma MCP를 통해서 내보내고, 미리 구현해둔 디자인 시스템을 적용해달라고 하면 거의 끝이었어요. 결국 아이데이션과 시안 제작 단계에서는 Figma Make의 도움을 받고, 그 다음 단계부터는 디자인 시스템을 통해 빠르게 구현으로 연결할 수 있었던 셈이에요.

아이데이션 → 디자인 보정 → 코드로 구현까지의 과정

결론

AI 덕분에 만드는 속도는 확실히 빨라졌지만 그만큼 무엇을 선택할지 판단해야 하는 순간이 더 자주 찾아온 것 같아요. 이 글에서 정리한 ‘변화’는 AI가 일을 대신해준 이야기라기보다는 디자이너의 판단이 어느 지점에서 얼마나 더 중요해졌는지를 제 경험 안에서 정리해본 기록에 가깝습니다.