디자인 싱킹 회고

프로젝트 기획심의가 5월 말에 예정되어 있어, 최근 여러 멘토님들을 만나며 프로젝트 기획에 대한 피드백을 받았다. 결과는 예상보다 더 냉정했다. “도메인 자체가 이미 레드오션이다”라는 이야기도 있었지만, 그중 가장 크게 남았던 말은 프로젝트 담당 멘토님의 한마디였다.

“지금 기능에 너무 매몰되어 있어요.”

처음에는 솔직히 이해하기 어려웠다. 문제를 해결하려면 결국 기능이 필요하고, 그렇다면 기능 중심으로 설계하는 것이 당연하다고 생각했기 때문이다. 그래서 속으로는 조금 반박하고 싶은 마음도 있었다.

하지만 여러 멘토님들의 이야기를 듣다 보니, 내가 놓치고 있던 부분이 무엇인지 조금씩 보이기 시작했다. 사용자는 “이 기능이 얼마나 기술적으로 뛰어난가?”를 기준으로 제품을 사용하는 것이 아니라, 결국 “내 불편함이 실제로 해결됐는가?”를 기준으로 제품을 사용한다는 점이었다.

즉, 아무리 기능을 잘 만들어도 그 기능이 해결하려는 문제가 진짜 사용자의 문제와 연결되지 않는다면, 사용자는 굳이 그 제품을 사용할 이유가 없다.

(수많은 기능들의 향연...)

그렇다면 우리는 어떻게 기획해야 할까?

문제 해결 자체만 바라보며 개발을 해왔던 나에게는 꽤 어려운 질문이었다. 그때 한 멘토님께서 추천해주신 것이 바로 ‘디자인 싱킹(Design Thinking)’ 프로세스였다.

처음에는 이름 때문에 조금 오해가 있었다. 뭔가 손으로 직접 만질 수 있는 제품을 설계할 때만 사용하는 방법론처럼 느껴졌기 때문이다. 실제로 디자인 싱킹은 칫솔, 쇼핑카트처럼 사람들이 실제 사용하는 제품을 더 편하게 만들기 위한 과정에서 많이 활용되었다고 한다.

그런데 흥미로웠던 점은, 이 프로세스가 서비스나 개발 기획에도 충분히 적용될 수 있다는 것이었다.

디자인 싱킹은 단순히 아이디어를 내는 방식이 아니었다. 오히려 “이 문제가 정말 해결할 가치가 있는 문제인가?”를 집요하게 검증하는 과정에 가까웠다.

디자인 싱킹은 다음 단계들로 이루어져있다.

• Empathize

  • 사용자를 관찰하고 인터뷰하며 불편함에 공감하는 단계

• Define

  • 관찰한 내용을 바탕으로 문제를 정의하는 단계

• Ideate

  • 정의한 문제를 해결하기 위한 아이디어를 자유롭게 브레인스토밍하는 단계

• Prototype

  • 아이디어를 실제 형태로 만들어보는 단계

• Test

  • 사용자에게 직접 사용하게 하며 검증하는 단계

• Assess

  • 피드백을 기반으로 다시 개선하는 단계

이 과정에서 필요하다면 언제든 이전 단계로 돌아갈 수 있고, 아닌 것 같다면 가능한 빨리 돌아가는게 더 좋은 방향으로 수정할 수 있었던 것 같다.

이 여러 단계 중 가장 어려웠던 건 Empathize와 Define 단계였다.

한 기획 멘토님께서 이런 질문을 해주셨다.

“그래서 이 프로젝트는 어떤 본질적인 문제를 해결하려는 건가요?”

그 순간 머리가 멍해졌다. 우리는 분명 열심히 기능을 고민하고 있었지만, 정작 “왜 이걸 만들어야 하는가?”에 대해서는 제대로 답하지 못하고 있었기 때문이다.

돌이켜보면 우리는 불편함 자체에는 집중했지만, 그것이 정말 반복되고 지속되는 문제인지까지는 깊게 고민하지 않았던 것 같다.

그래서 초심으로 돌아가 보기로 했다. 개발자의 시선이 아니라, 그냥 한 명의 사용자로서 생각해보기 시작했다.

우리는 문서와 관련된 문제를 해결하고 싶었다. 여기서 문서란 단순히 계약서나 이력서만 의미하는 것이 아니다. 회고 글, 일기, 메모, 이미지처럼 데이터를 담고 있는 거의 모든 기록들을 포함한다.

나는 문서를 자주 작성하는 편은 아니지만, 저장하거나 수정하는 일은 꽤 많았다. 그리고 그 과정에서 반복적으로 겪는 불편함이 있었다.

“분명 어디선가 봤던 내용인데, 그게 어떤 파일에 있었는지 기억이 안 난다.”

비슷한 문서들이 계속 쌓이다 보니, 정작 필요한 정보를 찾지 못하는 순간들이 자주 있었다.

이런 경험들을 팀원들과 공유해보니 의외로 비슷한 불편함을 겪고 있었다. 그렇게 우리는 각자의 경험을 모아 공통된 문제를 정의하기 시작했다.

그 과정에서 처음으로 팀원 모두가 납득할 수 있는 How Might We(HMW)를 도출할 수 있었다.

How Might We는 정의한 문제를 바탕으로 해결 방향을 열어두는 질문이다.

예를 들어, “욕실 바닥이 미끄럽다”라는 문제가 있다면,

• “욕실 바닥이 젖어 있어도 미끄럽지 않게 하려면 어떻게 해야 할까?”
• “욕실 바닥의 물을 빠르게 마르게 하려면 어떻게 해야 할까?”

처럼 해결 방향 자체를 질문 형태로 바꾸는 방식이다.

아무튼, 이 질문이 만들어지고 나서야 비로소 “무엇을 만들 것인가”가 아니라, “왜 이것을 만들어야 하는가”를 중심으로 아이디어를 이야기할 수 있게 되었다.

현재는 이러한 과정들을 거쳐 기획서까지 작성한 상태다. 프로세스로 보면 아직 Ideate 단계에 가까운 것 같다. 이제 기획심의를 통과하게 된다면, Claude Code와 Codex 등을 활용해 빠르게 MVP를 만들어보려고 한다.

예전에는 “무엇을 만들 수 있는가”를 먼저 고민했다면, 지금은 “왜 이걸 만들어야 하는가”를 먼저 고민하게 된 것 같다.

아직 완성된 기획은 아니지만, 적어도 이전보다 조금 더 사용자 가까이에서 문제를 바라보게 된 것은 분명한 변화라고 느끼고 있다.