디자인 씽킹 5단계, AI 전환에서 순서보다 중요한 반복과 검증

디자인 씽킹 5단계는 공감, 문제 정의, 아이디어 발상, 프로토타입, 테스트로 이뤄집니다. 다만 순서대로 한 번 밟고 끝나는 절차라기보다, 그때그때 필요한 이해와 검증에 따라 오가는 활동으로 보는 편이 실제에 가까워요. 테스트 결과가 예상과 어긋나면 사용자 이해나 문제 정의로 되돌아갈 수 있습니다. 업무에 적용할 때도 도구부터 고르지 말고 사용자의 문제를 먼저 살펴보세요. 검증 결과에 따라 처음 세운 문제까지 고칠 수 있다는 전제로 접근하길 권합니다.

먼저 볼 것은 '지금 몇 단계인가'가 아닙니다. 다음 결정을 내리려면 무엇을 더 알아야 하는지예요.

사용자의 어려움이 아직 흐릿하다면 관찰과 대화가 먼저입니다. 해결 방향이 여러 갈래라면 아이디어를 나란히 놓고 비교해 볼 필요가 있고요. 시제품이 이미 준비됐다면 이제 그게 실제 업무에 도움이 되는지 살펴볼 차례입니다. 다섯 단계는 이렇게 불확실성을 줄일 활동을 고르는 기준으로 쓸 수 있어요.

다섯 단계는 각각 무엇을 하고, 어떻게 되돌아가나

Stanford d.school의 Design Thinking Bootleg은 다섯 활동을 '모드'로 소개하면서, 도구 카드를 원하는 곳에서 시작해도 된다고 안내합니다. 모드는 '지금 필요한 작업 방식' 정도로 이해하면 쉬워요. 활동마다 역할은 구분하되, 앞 활동을 완전히 끝내야 다음으로 넘어갈 수 있다는 뜻으로 읽을 필요는 없습니다.

• 공감: 사용자를 관찰하고 대화하며 경험을 이해합니다.
• 문제 정의: 조사 내용을 종합해 누구의 어떤 어려움을 해결할지 구체화합니다.
• 아이디어 발상: 가능한 해결책을 넓게 탐색합니다.
• 프로토타입: 아이디어를 사용자가 경험할 수 있는 형태로 만듭니다.
• 테스트: 사용자의 반응을 통해 시제품과 그 바탕에 놓인 가정을 함께 살펴봅니다.

헷갈리기 쉬운 지점은 테스트 뒤에 무엇을 고치느냐입니다. 화면이나 기능만 바뀌는 게 아니에요. 사용자에 대한 이해도, 처음 정한 문제도 바뀔 수 있습니다. 사용자가 시제품을 잘 다루더라도 정작 업무에 필요하지 않다면, 조작 방식을 다듬는 것만으로는 풀리지 않아요.

디자인 씽킹을 프로세스라고 불러도 틀린 말은 아닙니다. IDEO도 프로세스라는 표현을 쓰면서, 실제 작업은 직선으로 흘러가지 않는다고 설명하거든요. 단계 구분은 분명 쓸모가 있지만, 정해진 순서대로 한 번씩 하면 끝난다고 해석하지 않도록 조심해야 합니다.

AI 답변 보조 도구에 대입해 보면

가상의 고객지원 도구를 설계한다고 해 볼게요. 출발점은 상담 담당자가 정확히 어디서 막히는지 확인하는 일입니다. 관련 정보를 찾는 데 시간이 걸리는 건지, 답변을 쓰는 일 자체가 부담인 건지에 따라 필요한 해결책이 달라지니까요. Google PAIR의 사용자 요구 가이드도 기존 업무 흐름을 살피고, 규칙 기반 해결책과 견줘서 AI가 더할 가치를 판단하라고 권합니다.

문제가 구체화됐다면 이제 범위를 정할 차례예요. 자동 발송까지 맡길지, 사람이 검토할 답변 초안만 줄지를 결정합니다. 정보 검색이 핵심 문제라면 필요한 자료를 찾도록 돕는 기능부터 검토해 볼 수 있어요. 자동화 수준은 사용자가 맡기려는 업무와 검토 방식에 맞춰 정하는 편이 타당합니다.

초안 보조 도구를 테스트했더니 정보가 빠진다면, 필요한 정보가 데이터에 들어 있는지와 그게 출력에 반영되는지를 먼저 살펴볼 수 있습니다. 이때 누락 원인을 곧바로 데이터 부족으로 단정하기 쉬운데, 그보다 앞서 답변에 어떤 정보가 들어가야 하는지 기준부터 확인해야 해요. 사용자 요구와 모델 출력을 연결해 평가하라는 Google PAIR의 데이터·평가 가이드와도 맞닿는 이야기입니다.

초안을 검토하는 부담이 커졌다면 실제 업무 흐름을 다시 조사할 이유가 생긴 겁니다. 자동 발송에 거부감이 보였다면, 사용자가 직접 통제하고 싶어 하는 지점이 어디인지 살피고 자동화 범위를 다시 설계해야 하고요. 같은 테스트에서 나온 문제라도 돌아갈 곳은 저마다 다릅니다.

그래서 무언가를 고치기 전에, 어떤 가정이 어긋났는지부터 짚어 보길 권합니다.

시제품마다 무엇을 확인할지 먼저 정하기

빠르게 만든 결과물은 가정을 일찍 확인할 기회를 줍니다. 그 기회를 살리려면 시제품마다 무엇을 알아보려는 건지 분명해야 해요. 기능이 작동하는지 보는 테스트와 사용자의 업무 부담이 줄었는지 보는 테스트는 서로 다른 질문에 답합니다. AI로 만드는 속도가 빨라졌다는 사실만으로는 사용자 조사나 검증을 줄일 근거가 부족해요.

업무에 적용한다면 사용자 부담이 실제로 줄었는지, 출력이 업무 목적에 맞는지부터 확인해 보세요. 답이 흐릿하다면 관찰이나 문제 정의로 돌아갈 근거가 생긴 셈입니다. 반복의 가치는 검증 결과를 다음 결정에 반영하는 데 있어요.