# 디자인 프로세스는 죽지 않았다, 압축되었을 뿐

> Clean Markdown view of GeekNews topic #27724. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27724](https://news.hada.io/topic?id=27724)
- GeekNews Markdown: [https://news.hada.io/topic/27724.md](https://news.hada.io/topic/27724.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-22T09:47:01+09:00
- Updated: 2026-03-22T09:47:01+09:00
- Original source: [nngroup.com](https://www.nngroup.com/articles/design-process-isnt-dead/)
- Points: 8
- Comments: 0

## Summary

AI가 디자인 루프를 단축시키자 “프로세스를 버려라”는 구호가 유행하지만, 실제로는 숙련자의 **내면화된 프로세스가 압축 실행**되는 현상에 가깝습니다. 경험이 쌓인 디자이너의 직관은 수년간의 리서치와 실패를 통해 형성된 데이터베이스이며, 이를 단순한 감각으로 오해하면 리스크 관리 장치를 잃게 됩니다. 개발자에게 중요한 지점은 프로세스 자체가 아니라, 문제의 성격에 따라 어떤 단계를 생략하거나 강화할지를 판단하는 ‘프로세스 리터러시’입니다. AI가 속도를 높여도 이 판단력만큼은 자동화되지 않습니다.

## Topic Body

- AI가 디자인 작업 속도를 높이면서 "프로세스를 버려라"는 주장이 확산되고 있지만, 이는 숙련된 디자이너의 작업 방식을 **오해한 결과**  
- 숙련된 디자이너가 "그냥 만들기 시작했다"고 말할 때, 실제로는 수년간 축적된 경험을 통해 **프로세스를 내면화하고 압축**하여 실행하는 것  
- 직관에 의존하는 방식은 경험이 부족한 주니어 실무자에게는 적용이 어려우며, 규제 산업에서는 **프로세스가 피해 방지를 위한 안전장치** 역할  
- 솔루션 우선 디자인은 제품 패턴이 잘 확립된 좁은 맥락에서만 유효하며, 성공 사례만 부각하는 **생존자 편향**의 위험 존재  
- 현대 디자인의 핵심 역량은 프로세스를 버리는 것이 아니라, 문제에 맞는 접근법을 의도적으로 선택하는 **프로세스 리터러시(process literacy)**  
  
---  
  
### "프로세스를 버려라" 주장의 내용  
  
- 전통적 디자인 프로세스가 구식이며, 좋은 결과물이 만들어지는 실제 방식과 동떨어져 있다는 주장  
- 반복, 직관, 단계 건너뛰기가 약점이 아니라 **강점**이며, 강한 직관을 쌓고 디테일에 집착하며 상황에 맞게 프로세스를 리믹스해야 한다는 입장  
- 훌륭한 작업은 문제 정의가 아닌 **솔루션에서 시작**되는 경우가 많으며, 설득력 있는 프로토타입을 본 후에야 그것이 실제로 해결하는 문제를 이해하게 됨  
- Anthropic의 디자인 리드 Jenny Wen이 이 주장의 대표적 목소리 중 하나  
  
### 주장이 무너지는 지점  
  
- 위 관찰들이 틀린 것은 아니지만, 프로세스가 불필요하다는 증거가 되지는 않음  
- 숙련된 디자이너들이 이미 하고 있는 일, 즉 프로세스를 내면화하고 탐색·아이디에이션·평가 단계를 **유동적으로 이동**하는 방식을 묘사한 것에 불과  
- "프로세스를 건너뛴다"고 보이는 것은 실제로는 **프로세스를 압축**하는 것 — 경험을 가이드로 삼아 각 단계를 더 빠르게 통과  
- **더블 다이아몬드**와 **디자인 씽킹** 프로세스는 문자 그대로의 체크리스트나 템플릿이 아님  
  - 목적은 **리스크 관리**: 팀이 문제를 이해하고, 솔루션을 탐색하며, 잘못된 것을 만들 확률을 줄이는 것  
- 솔루션 우선 접근이 효과적인 경우는 문제 공간이 **성숙**하고, 내재된 지식이 풍부하며, 새로운 것을 발명하는 것이 아니라 확립된 패턴 위에 구축할 때로 한정  
  
### 프로세스 압축, 포기가 아님  
  
- "디자인 프로세스"를 하나의 거대한 덩어리로 취급하는 것 자체가 문제  
- 더블 다이아몬드나 디자인 씽킹 사이클은 "그 프로세스"가 아니라, **창의적 문제 해결 과정의 단계를 단순화한 표현**  
  - 무엇이 잘못인지 파악 → 무엇을 만들지 결정 → 만들기 → 배우기의 고수준 설명  
- "프로세스를 버려라"는 주장은 **인간 중심 디자인의 실무 방식을 오도**한 것에 크게 의존  
  - 숙련된 실무자는 비선형적이고 맥락적으로 프로세스를 운용  
  - 공식적 프레임워크는 사고를 접근 가능하고 전달 가능하게 만들기 위해 존재  
- 성숙한 소비자 제품을 다루는 숙련된 디자이너가 "그냥 만들기 시작했다"고 할 때, 프로세스를 포기한 것이 아니라 **내면화된 버전을 압축 실행**하는 것  
  - 사용자 행동 연구, 경쟁사 트렌드 분석, 숙련된 팀과의 리서치 수행을 통해 축적된 지식이 기반  
- **"직관"이라 불리는 것은 실제로는 수년간의 작업을 통해 압축되고 내면화된 프로세스**  
  - 디자이너가 신뢰하는 직관은 자신이 무시하는 바로 그 프로세스에 의해 형성된 것  
- AI 도구가 이 압축을 더욱 가속하고 **민주화**  
  - **바이브코딩(Vibecoding)** 이 아이디어와 테스트 가능한 결과물 사이의 간극을 축소  
  - 탐색, 제작, 학습, 개선이 하루 오후 안에 가능  
  - 숙련된 디자이너가 항상 공식 프레임워크보다 빠르게 디자인 루프를 돌려왔다면, AI는 이제 경험이 적은 실무자도 동일하게 할 수 있게 해줌  
  
### 직관은 프로세스를 대체하지 못함  
  
- 디자인 프로세스에서 직관을 포용하라는 조언은 해방적으로 들리지만, **복잡한 현실을 지나치게 단순화**  
  
#### 모든 사람이 직관으로 작업할 수 있는 것은 아님  
- Jenny Wen 같은 숙련된 디자이너는 강한 디자인 문화와 수준 높은 팀을 갖춘 기업에서 수년간 실무를 통해 직관을 구축  
  - 직관 주도 의사결정을 이끌 수 있는 기술, 권한, 실적, 팀 수준을 보유  
- 직관을 신뢰할 수 있게 만드는 지식이 축적되지 않은 **주니어 실무자**에게는 직관 의존이 훨씬 덜 유효  
  - 숙련된 디자이너가 빠르고 정보에 기반한 판단을 내리는 것과, 조직 지식·사용자 행동 패턴·비즈니스 제약에 노출되지 않은 신입에게 "자신을 믿으라"고 말하는 것은 전혀 다른 문제  
  
#### 직관에는 책임성이 부족  
- 많은 환경에서 의사결정에는 **문서화와 정당화**가 필요  
  - 리서치 결과, 사용성 테스트 결과, 분석 데이터 같은 프로세스 산출물이 이해관계자 정렬과 승인에 필수  
- 대부분의 기업 환경에서 "직관을 따랐다"는 설명은 VP가 "어떤 증거가 이것을 뒷받침하는가?"라고 물었을 때 살아남지 못함  
  
#### 고도로 규제된 산업에서 직관은 통하지 않음  
- 의료, 금융, 정부, 접근성이 중요한 시스템 등 **고위험 또는 규제 산업**에서 프로세스는 관료적 의례가 아니라 피해 방지를 위한 안전장치  
- 의료 기기 UI에서 리서치를 건너뛰는 것과 화이트보드 기능에서 리서치를 건너뛰는 것은 전혀 다른 차원의 문제  
  
#### 직관에는 편향이 내재  
- 잘 쌓인 직관에도 **사각지대** 존재  
  - 숙련된 디자이너가 무의식적으로 익숙한 패턴에 고착되거나, 자신의 멘탈 모델에 맞지 않는 엣지 케이스를 무시할 수 있음  
- 직관이 깊을수록 편향을 감지하기가 더 어려움  
- 프로세스는 가정이 비용이 큰 실수로 굳어지기 전에 **이를 공개적으로 드러나게 강제**  
  
### 솔루션 우선 디자인은 좁은 맥락에서만 유효  
  
- AI 시대에 많은 전문가가 **솔루션 우선 디자인**을 옹호 — 새로운 기술적 역량에서 시작하여 역으로 그것이 해결할 수 있는 문제를 파악하는 접근  
  - 문제를 먼저 파악한 후 솔루션을 찾는 전통적 모델의 역전  
- Jenny Wen이 솔루션 우선 디자인을 주장하며 사용한 사례 — 자원이 풍부한 기업이 만든 AI 제품의 성공적이고 널리 채택된 기능들 — 는 **생존자 편향**을 반영  
  - 보이지 않는 것은 실패한 수많은 솔루션 우선 실험들: 내부 팀을 흥분시켰지만 사용자에게는 공감을 얻지 못한 프로토타입, 또는 의미 있는 필요를 충족하지 못해 출시 후 채택률이 낮았던 기능들  
  - 성공 사례만 보여주면 어떤 접근이든 훌륭해 보임  
- 신흥 기술을 설계할 때 빠른 구현은 필수적이지만, **실행 속도가 적절한 문제 프레이밍의 중요성을 감소시키지는 않음**  
  - 공식적인 문제 정의서나 디스커버리 스프린트가 필요하지 않더라도, 무엇을 고치려는 것인지는 알아야 함  
- 솔루션 우선 디자인은 리스크를 완화하지 못하며, 산업의 **좁은 범위**에만 적합  
  - 제품 패턴이 이미 잘 이해되어 있고, 사용자가 정교하며, 디자인 과제가 차별화에 국한된 환경에서 성공 가능  
  - 높은 수준의 조직적·**UX 성숙도**를 전제 — 강한 도메인 지식과 유망한 방향을 빠르게 인식하는 경험을 갖춘 팀  
- 대부분의 팀은 이런 조건에서 운영되지 않음  
  - **저성숙도 환경**, 조직 지식이 제한된 환경, 또는 새롭고 위험도가 높은 맥락에서 솔루션으로 시작하면 잘못된 가정의 비용이 증폭  
  - 이런 경우 최소한의 사전 문제 프레이밍이 여전히 필수  
  
### 프로세스 리터러시: 문제에 맞는 프로세스 선택  
  
- 현대 디자인의 진정한 역량은 프로세스를 버리는 능력이 아니라 **프로세스 리터러시** — 문제에 맞는 올바른 접근법과 도구를 선택하는 능력  
  - 어떤 프로세스가 해당 작업에 적합한지 알고, 따르지 않았을 때의 리스크를 이해해야 함  
  - 단지 프로세스를 다르게 적용하는 것이라면, 프로세스를 사용하지 않는다고 주장하지 말아야 함  
- 모든 프로젝트에 6주간의 디스커버리 단계가 필요하다는 뜻이 아니며, 모든 디자인 문제를 의료 기기 개발처럼 다뤄야 한다는 뜻도 아님  
  - **문제에 맞는 프로세스 매칭**이 핵심: 일부 문제는 깊은 조사가 필요하고, 다른 문제는 빠른 실험과 반복이 효과적  
  - 누군가가 "프로세스는 죽었다"고 선언했기 때문이 아니라, **의도적으로** 선택해야 함  
- AI 도구가 이전에 볼 수 없었던 속도로 빠른 프로토타이핑과 반복을 가능하게 하지만, 디자인 프로세스가 완화하는 **불확실성과 리스크를 제거하지는 않음**  
  - 디자이너는 여전히 문제를 이해하고 아이디어를 평가해야 함  
- 더블 다이아몬드, 디자인 씽킹, Jobs-to-be-Done 같은 프로세스 프레임워크는 엄격한 절차가 아니라 **스캐폴딩(scaffolding)**  
  - 내면화되면 숙련된 실무자의 작업 방식에 암묵적으로 녹아드는 사고 방식을 가르치는 것  
- 진짜 질문은 프로세스를 따를 것인가가 아니라, **우리가 하는 작업이 해결하려는 문제에 어떻게 매핑되는가**  
  - AI가 더 많은 워크플로를 압축하고, 에이전트 시스템이 행동하고 맥락을 기억하며 대신 결정을 내리기 시작하면, 이 질문을 건너뛰는 비용은 줄어드는 것이 아니라 **더 커짐**

## Comments



_No public comments on this page._