De Novo Orthopedics
AI 시대의 디자인 씽킹: 병목에서 증폭기로
Blog/
||||||

AI 시대의 디자인 씽킹: 병목에서 증폭기로

최근 한 지역 병원 조회 시간에 시니어 주치의가 우리에게 물었습니다. '디자인 씽킹은 이제 한물 간 것 아닙니까?' 의료 기술 영역에서 우리는 이 질문을 일 년에 몇 번씩 듣습니다. 우리의 답은 이렇습니다. 디자인 씽킹은 지난 십 년 동안 실패한 것이 아니라, 단지 너무 느리게 돌았을 뿐입니다. AI는 prototype 제작과 피드백 합성 단계를 몇 달에서 며칠로 압축합니다. 이것이 디자인 씽킹이 조용히 기다려 온 변화입니다.

aidesign-thinkingirehabproduct-designmedical-ai

최근 한 지역 병원 조회 시간에 시니어 주치의가 우리에게 이렇게 물었습니다. "디자인 씽킹은 이제 한물 간 것 아닙니까?"

용어가 모두에게 익숙하지는 않으니 짧게 정리하고 가겠습니다. 디자인 씽킹(design thinking)은 1990년대 IDEO와 인접 디자인 컨설팅 회사들이 대중화한 다섯 단계 루프입니다. empathize(사용자 이해), define(문제 정의), ideate(해결안 발산), prototype(거친 시제품 제작), test(사용자 앞에 올려놓기)로 구성됩니다. 핵심 전제는 단순합니다. 무엇을 만들기 전에 어떤 문제를 풀고 있는지부터 파악하라, 그리고 거친 버전을 실제 사용자에게 만지게 한 뒤 문제 정의를 다시 들여다보라는 것입니다. 상식처럼 들리지만 현실에서는 대부분의 팀이 단 한 번의 완전한 루프조차 끝내지 못합니다.

지난 십 년 사이 이 방법론이 낡았다는 인상이 굳어졌습니다. 흔히 따라붙는 행간은 다음과 같습니다.

  • 2010년대의 산물이고, 세상은 lean startup과 AI의 직접 생성으로 넘어갔다
  • 워크숍 산업으로 변질되었다. Post-it은 잔뜩, 후속 실행은 없음
  • 대기업들이 의식으로 만들어 버렸다. 일주일 sprint 한 번으로 끝
  • LLM이 즉시 해결안을 합성하는데 굳이 empathize나 사용자 리서치가 필요한가

우리의 해석은 다릅니다. 지난 십 년간 디자인 씽킹을 낡아 보이게 만든 것은 논리가 아니라 속도였습니다. AI는 루프를 늦추던 단계 — prototype 제작과 피드백 합성 — 를 몇 달에서 며칠로 압축합니다. 이제야 비로소 전체 루프가 처음으로 끝에서 끝까지 돌 수 있게 되었습니다.

이 글은 우리 팀의 최근 내부 pivot을 따라갑니다. 단일 진료과를 대상으로 한 침상 옆 도구에서, 어떤 전문의든 스스로 정의해서 배포할 수 있는 cross-specialty schema composer로 옮겨 간 과정입니다. 이 흐름은 우연찮게 디자인 씽킹의 한 사이클과 정확히 겹칩니다. 우리는 이 사례를 통해 AI가 디자인 씽킹의 대체재가 아니라, 디자인 씽킹이 이십 년 동안 기다려 온 도구라는 점을 보여 드리려 합니다.

왜 사람들이 한물 갔다고 여겼는가

디자인 씽킹의 다섯 단계 핵심 — empathize, define, ideate, prototype, test — 는 1990년대 IDEO와 인접 디자인 컨설팅 회사들이 대중화했고, Tim Brown이 2008년 Harvard Business Review에 발표한 선언문이 이를 주류 방법론으로 끌어올렸습니다.

진짜 병목은 한 번도 논리에 있지 않았습니다. 시간이었습니다.

empathize에서 test, 그리고 다시 redefine까지 한 사이클을 한 번 도는 데에는 전통적인 제품 팀 기준 보통 3개월에서 6개월이 걸렸습니다.

  • empathize: 5–15명 사용자 인터뷰 일정 잡기, 녹취, 패턴 클러스터링
  • define / ideate: 모든 이해관계자를 며칠짜리 워크숍에 모아 Post-it 더미 생성
  • prototype: 디자이너가 화면을 짜고, 엔지니어가 실제 동작하는 버전 빌드
  • test: 또 한 차례 사용자 세션, 피드백 수집

각 단계가 느렸고, 한 차례를 끝내고 사용자 반응을 보았을 즈음에는 이미 거기에 대응할 시간도 예산도 남아 있지 않았습니다.

그 결과 지난 십 년 동안 세 가지 일이 벌어졌습니다.

  • empathize와 define은 의식이 되었습니다. 워크숍 한 번 돌리고 끝
  • prototype과 test는 디자인 에이전시에 외주로 넘어갔습니다. 보기 좋은 결과물, 그러나 실제 운영과는 거리가 먼 것
  • 방법론 전체가 "이틀짜리 sprint"로 짜부라들었습니다. 이름은 디자인 씽킹이지만, 정작 의미를 만드는 동작인 실제로 방향을 트는 것이 빠져 있었습니다

2020년대 초가 되자 합의는 이미 옮겨 가 있었습니다. 디자인 씽킹은 "옛날 방식"이고, 새로운 방식은 lean startup, growth hacking, data-driven product라는 분위기 말입니다.

이 "한물 갔다"는 평가는 업계 잡담이 전부가 아닙니다. Rebecca Ackermann의 2023년 MIT Technology Review 회고문이 지난 십 년의 비판을 종합했습니다. 실행 없는 아이디어, 혁신을 가장한 연극, 공동체 전문성이 빠진 empathy 같은 지적입니다. NYU의 Natasha Iskander 교수는 그보다 5년 앞서 2018년 HBR 기고문에서 더 날카롭게 짚었습니다. "근본적으로 보수적이다." 두 비판 모두 디자인 씽킹이 사회·정책 영역 — 학교 급식 프로그램, 빈곤 대책, 공공 서비스 — 에서 실패했음을 겨냥합니다. 다섯 단계 루프가 아니라 장기적 정치·제도 작업이 필요한 영역들입니다.

우리는 이 비판들과 다투려는 게 아닙니다. 그들의 지적은 정확합니다. 이 글이 다루는 질문은 더 좁습니다. 왜 디자인 씽킹이 제품 워크플로 안에서 멈춰 버렸는가입니다.

AI가 실제로 바꾼 것

AI가 등장했을 때 가장 시끄러웠던 서사는 "이제 사용자 리서치는 필요 없다, LLM이 직접 답을 합성한다"였습니다. 이 서사는 디자인 씽킹과 정면으로 충돌하고, 그래서 사람들이 디자인 씽킹이 한물 갔는지 묻는 것입니다.

그러나 제품 팀 안에서 우리가 보는 풍경은 그 반대에 가깝습니다.

LLM은 empathize 단계를 가속하지 않습니다. prototype 제작과 피드백 처리를 가속할 뿐입니다.

단계AI 이전AI 도입 후
spec 초안1–2주 (다중 라운드 이해관계자 검토)1–2일 (병렬 multi-AI review)
UI mock1주 (디자이너 + 도구)반나절 (LLM + Figma 플러그인)
동작 prototype2–4주 (프론트 + 백엔드 엔지니어링)3–5일 (mocked API + AI 생성 UI 로직)
피드백 합성1주 (수작업 클러스터링)반나절 (LLM 주제 추출 + 클러스터링)
규제 / 법무 초안2–4주 (변호사 + 내부 검토)3–5일 (AI 초안 + 변호사 검토)

전부 더하면, 예전에 12–16주(혹은 그 이상)이 걸리던 디자인 씽킹 한 사이클이 이제 2–3주(혹은 그 미만)에 돕니다.

여담 하나. IDEO 본가도 같은 결론에 도달해 있습니다. 2024년부터 IDEO는 Bring AI to the Design Thinking Process라는 온라인 코스를 운영하며, 위 표와 거의 일대일로 대응되는 다섯 단계에 대해 AI 가속 기법을 가르칩니다. 이 신호는 뒤에서 다시 다루겠습니다.

병목이 옮겨 갔습니다. 예전에 느렸던 "사용자가 실제로 만질 수 있는 것을 만든다"가 이제 빠릅니다. 지금 느린 것은 "무엇을 만들지 결정한다"입니다.

다시 말해, empathize / define 단계의 상대적 중요도는 떨어진 것이 아니라 오히려 올라갔습니다.

진짜 변화

LLM은 증폭기입니다. 문제를 잘못 잡으면 아무도 원하지 않는 것을 전례 없는 효율로 찍어 냅니다. 제대로 잡으면 옳은 방향을 열 배로 키웁니다.

따라서 디자인 씽킹의 가장 고전적인 동작 — "먼저 왜인지 묻는다" — 은 AI 시대에도 여전히 유효한 정도가 아니라, 그 자체가 가드레일입니다.

과거에는 empathize가 느렸기 때문에 팀들이 건너뛰고 싶어 했습니다. 오늘날에는 prototype이 빠르기 때문에 empathize를 건너뛰는 것이 오히려 더 위험합니다. 잘못된 길을 매우 효율적으로 한참 달려간 뒤에야 알아차리게 되기 때문입니다.

우리 팀의 내부 규칙은 이렇습니다. spec sign-off 없이는 작업을 시작하지 않습니다. AI가 빨라질수록 sign-off 단계는 더 결정적입니다. 우리는 모든 spec에 대해 세 개의 AI reviewer(Codex, Gemini, ChatGPT)를 병렬로 돌립니다. 이들은 contract 위반, IDOR, PHI 노출, cross-version 호환성 문제를 잡아냅니다. 전통적인 디자인 씽킹 워크숍은 이런 항목을 한 번도 다룬 적이 없습니다. AI 시대에는 이 관심사들이 "사용자가 무엇을 원하는가"와 나란히 empathize / define에 들어가야지, 그 이후에 붙어서는 안 됩니다.

"spec 우선"은 디자인 씽킹과 반대되는 것이 아닙니다. AI 시대에 맞춰 다시 짠 디자인 씽킹입니다.

사례: SOAP.S overflow에서 cross-specialty composer까지

이 흐름은 시장 조사나 focus group에서 시작되지 않았습니다. 한 시니어 의사와의 대화에서 시작되었습니다. 그 의사는 자신의 팀이 본 현상을 이렇게 묘사했습니다. patient copilot 도구가 환자에게 진료 전 주소(chief complaint)를 입력받는데, LLM이 생성한 텍스트가 SOAP의 Subjective란을 일상적으로 넘쳐흐르게 만든다는 것이었습니다. 의사가 임상 추론에 쓰던 시간이, 이제 AI가 써 놓은 글을 정리하는 데로 옮겨 가 있었습니다.

처음 떠오른 본능은 단순했습니다. 압축기를 하나 끼우자 — 환자 입력을 의사가 실제 쓸 수 있는 형태로 줄여 주자.

팀은 그렇게 하지 않았습니다. 문제와 좀 더 같이 앉아 있어 보니, 빠진 것은 압축 레이어 하나가 아니라 가치 흐름 전체의 재배치라는 게 분명해졌습니다. 그래서 팀은 문제를 디자인 씽킹의 다섯 단계로 끌고 갔습니다. 대화에서 pivot 결정까지 약 2주. 같은 작업을 AI 이전에 했더라면 6–9개월이 걸렸을 것입니다.

Empathize

이 팀에는 진료 중인 정형외과 전문의이자 창업자인 멤버가 있습니다. 그의 시점에서 가장 고전적인 디자인 씽킹 질문을 던졌습니다.

"매 진료에서 나는 환자의 두서없는 호소를 어떻게 SOAP.S 내용으로 번역하는가?"

답은 "전부 받아 적는다"가 아닙니다. "네 개의 필드와 각 필드의 추론 근거로 압축한다"입니다. 어느 쪽인가, 중증도, 외상성인가 퇴행성인가, 지속 기간. 이 네 가지가 채워지면 감별 진단 가설 트리가 알아서 조립됩니다.

다시 말해, 의사가 쓰는 SOAP.S는 환자의 서술을 그대로 옮긴 transcript가 아닙니다. 그 서술에 대한 의사의 구조화된 해석입니다. SOAP.S overflow의 원인은 환자가 너무 많이 쓴 것이 아닙니다. AI 출력을 의사가 먼저 검토할 수 있도록 압축하지 않고, 차트로 직접 쏟아 넣도록 설계된 도구의 문제입니다.

(이 "AI는 초안, 의사가 확정"이라는 디자인 규칙은 iRehab Doctor AI: Draft-Only 원칙에서 더 깊이 다뤘습니다. AI 번역과 의사의 확정은 합쳐서는 안 되는 두 개의 행위입니다.)

Define

문제를 다시 진술했습니다.

"환자가 진료실에 들어오기 전 2분 동안, 지난 2주간의 환자 입력 — VAS 추이, 상처 사진, 운동 기록, PROM 점수 — 을 의사가 5초 안에 읽을 수 있는 specialty 맞춤 요약으로 압축한다."

핵심 단어는 "압축"과 "5초 가독"입니다. 기존의 "transcript를 EMR에 넣는다"는 발상을 유지하는 한, AI 정확도가 아무리 올라가도 SOAP.S overflow는 멈추지 않습니다.

이 define 단계는 의도적으로 좁게 잡았습니다. 정형외과만, 이 한 조각만, 그 외에는 아무것도 다루지 않는다.

Ideate

이전의 모든 접근은 동작이 진료실 안에서 일어난다는 것을 전제로 깔고 있었습니다. 의사가 앉고, 환자가 앞에 있고, EMR이 열려 있고, 들으면서 타이핑한다.

핵심 ideate 동작은 번역 단계 자체를 진료실 밖으로 옮기는 것이었습니다. 환자는 진료 외 시간(집에서, 휴대폰으로, 지난 2주에 걸쳐) 입력합니다. AI는 진료 2분 전에 압축합니다. 의사는 진료실에 들어가기 전 5초 안에 읽습니다.

이건 도구 업그레이드가 아닙니다. 워크플로 자체의 재배치입니다. (Brief에 입력을 공급하는 환자 측 흐름이 우리가 따로 글로 다룬 30초 데일리 체크인입니다. 하루 30초이지만 2주의 누적이 진료 직전 요약의 원재료가 됩니다.)

Prototype

며칠간의 spec 작성, multi-AI review, prototype 빌드 끝에 iRehab Brief Wave 1이 정형외과 전용으로 출시되었습니다.

예전에는 이 작업에 4–8주, 종종 그 이상이 들었습니다. AI는 spec 초안, UI mock, 백엔드 API 골격, 데이터 모델 검토, 규제 문서 초안을 모두 압축했습니다.

Test

Brief가 원내 시범 운영에 들어가자 예상하지 못한 일 두 가지가 벌어졌습니다.

첫째, 한 사이트에서 물리적 배포가 막혔습니다. 코드 문제가 아니었습니다. 병원 정책상 QR 코드가 들어간 포스터에는 모두 홍보부 승인이 필요했고, 외과 과장은 이를 "또 한 명의 의사가 자기 Facebook 페이지를 밀고 있다"는 프레임으로 해석했습니다. 코드 리뷰의 커버리지와 institutional governance는 결국 서로 다른 두 세계임이 드러났습니다.

둘째, FB 반응이 예상보다 훨씬 뜨거웠습니다. 정신건강의학과, 신경과, 비뇨부인과, 산부인과 의사들로부터 같은 질문을 담은 다이렉트 메시지가 들어왔습니다. "우리 진료과용으로도 만들어 줄 수 있나요?"

두 갈래 피드백은 하나의 메시지로 수렴했습니다. 우리가 처음 정의한 문제는 더 큰 문제의 한 조각이었습니다.

Redefine

모든 진료과는 번역기가 필요하지만, 각 과가 번역해 들어가야 할 네 개의 필드는 완전히 다릅니다.

  • 정신건강의학과는 수면, 기분 변동, 복약 순응도가 필요합니다
  • 비뇨부인과는 배뇨 일지, Kegel 운동 완수도가 필요합니다
  • 신경과는 증상 변동성, 부작용, 발작 빈도가 필요합니다
  • 산부인과는 임신 관련 호소, 태동, 분기별 경고 신호가 필요합니다

같은 아키텍처. 완전히 다른 네 개의 schema.

정형외과 Brief를 그대로 밀고 갔다면 한 줌의 정형외과 사용자에게 부드럽게 굴렀을 것입니다. 동시에 진짜 통찰을 놓쳤을 것입니다. 이 도구의 가치는 "정형외과 의사의 시간을 절약한다"가 아닙니다. "어떤 의사든 자신의 번역 규칙을 몇 분 안에 직접 정의할 수 있게 한다"입니다.

우리는 정형외과 Brief 배포를 멈췄습니다. 그리고 새 spec을 열었습니다. 어느 전문의든 자신의 네 개 필드를 직접 정의하고, attestation에 서명하고, 자신의 specialty pack을 출시할 수 있게 하는 cross-specialty Schema Composer입니다.

이 redefine 결정이 디자인 씽킹 다섯 번째 단계의 진짜 산출물입니다. "prototype이 잘 동작한다"가 아니라 "원래 잡았던 문제 프레임이 너무 좁았다"입니다.

두 개의 AI 증폭기

지난 2주를 돌이켜보면, AI는 두 군데에서 작업을 가속했습니다.

첫 번째 증폭기: spec → prototype 시간.

sign-off 가능한 수준의 spec을 쓰고, 동작하는 prototype을 빌드하고, 내부 review를 돌리는 데 예전에는 4–8주가 걸렸습니다. 우리 팀은 이를 7–10일로 압축합니다. LLM이 spec 초안을 쓰고, 세 개의 AI reviewer가 병렬로 돌고, 인간 architect가 결론을 모읍니다. prototype은 mocked API와 AI가 생성한 UI stub에서 출발하고, 엔지니어가 비즈니스 로직을 채웁니다.

두 번째 증폭기: 피드백 → redefine 시간.

"파일럿 가동"에서 "방향을 틀어야 한다"까지 가는 데 예전에는 3–6개월의 사용 데이터, 여러 차례의 인터뷰, 합성 작업이 필요했습니다. 우리의 루프는 이렇게 돕니다. FB 1주, DM 3일, 내부 팀 토론 1일. 외부 신호에서 "원래 프레임은 하위 문제였다"를 담은 새 spec까지 5일.

두 증폭기를 합치면, 디자인 씽킹 한 사이클 — 사고, spec, prototype, 피드백, redefine — 이 6–9개월에서 약 2주로 압축됩니다. 이것은 디자인 씽킹이 대체된 것이 아닙니다. 디자인 씽킹이 처음으로 끝에서 끝까지 돌아간 것입니다.

디자인 씽킹의 진짜 정체

디자인 씽킹은 워크숍이 아닙니다. Post-it도 아닙니다. empathy map도 아닙니다.

핵심은 두 가지 의지입니다.

  • 나의 첫 번째 답이 틀렸음을 인정할 의지
  • 빠르게 시험해 옳은 답을 찾을 의지

지난 십 년간 두 의지 모두 지키기 어려웠습니다. 첫 번째는 매몰 비용이 막았습니다("이 spec에 석 달을 썼는데 어떻게 틀렸다고 말하나"). 두 번째는 시간이 막았습니다("한 사이클을 더 돌리면 또 6개월이다").

AI가 두 번째를 바꿨습니다. 빠른 반복이 마침내 저렴해졌습니다. 그래서 첫 번째 의지가 처음으로 의미를 갖습니다. 틀렸다고 인정하는 것이 곧바로 다음 시도를 의미하게 되었기 때문입니다.

그래서 우리 팀은 spec 우선, 왜인지 묻기, "이것이 어떤 문을 열었는가"를 내부 규율로 다룹니다. AI는 도구일 뿐입니다. 그 위에 얹히는 방법론에는 이름이 있습니다. 그것이 디자인 씽킹입니다.

우리 혼자가 아닙니다

한 팀의 사례만 보면 일화로 들릴 수 있습니다. 그러나 이 방법론의 원조 진영도 더 직접적인 신호를 보내고 있습니다.

2024년부터 IDEO는 정직하게도 Bring AI to the Design Thinking Process라는 제목의 온라인 코스를 운영합니다. 커리큘럼은 다섯 단계 전반에 걸쳐 AI 가속을 가르칩니다.

  • Inspiration / Research: AI로 창의적 input 확장하기
  • Synthesis: "리서치와 합성을 가속하고, 인사이트를 더 빠르게 얻기"
  • Brainstorming: 더 빠르게 ideate하고 더 많은 옵션을 탐색하기
  • Prototyping: 컨셉을 빠르게 살아 있는 형태로 만들기
  • Responsible use: AI의 한계와 윤리 이해하기

이 다섯 단계를 앞서 본 AI 가속 표 위에 겹쳐 놓으면 거의 일대일로 들어맞습니다.

디자인 씽킹의 원조 보급자들은 AI를 라이벌로 다루지 않습니다. 그들은 자신의 커뮤니티를 직접 다음 세대 버전으로 옮겨 태우고 있습니다. 다섯 번째 단계 — responsible use — 에 주목하시기 바랍니다. AI가 빨라질수록 "왜인지 먼저 묻기"가 가드레일이 된다는 우리 주장과 같은 메아리입니다.

디자인 씽킹은 한물 간 게 아닙니다. 그 창시자들이 직접 손으로 AI에 연결하고 있습니다.

마무리

다시 시니어 주치의의 질문으로 돌아갑니다. "디자인 씽킹은 한물 간 것 아닙니까?"

우리의 답은 이렇습니다. 한물 가지 않았습니다. 지난 십 년 동안 한물 가 보였던 이유는 반복 루프가 너무 길었기 때문입니다. AI는 디자인 씽킹의 라이벌이 아닙니다. AI는 디자인 씽킹이 이십 년 동안 기다려 온 도구입니다.

iRehab Brief가 단일 진료과 파일럿에서 cross-specialty composer로 변신한 그 2주는, 우리 팀이 디자인 씽킹이 처음으로 끝에서 끝까지 도는 모습을 본 시간이었습니다. 이번이 마지막은 아닐 것이라고 봅니다.

더 읽을거리

De Novo 블로그에서

  • iRehab Doctor AI: Draft-Only 원칙 — Brief의 디자인 규칙을 다룬 자매 글. AI는 번역하고, 의사가 확정하며, 두 행위는 합칠 수 없습니다.
  • 30초 데일리 체크인 — Brief에 입력을 공급하는 환자 측 흐름. 하루 30초, 2주 누적이 진료 직전 요약의 원재료가 됩니다.
  • Recovery Loop — iRehab의 기능들이 그 안에서 출시되는 더 넓은 임상 방법론.