프로젝트 설계

이번 주 읽기: 상담 플랫폼, 어떻게 설계할까?

상담에서 가장 결과를 좌우하는 건 어떤 기법을 쓰느냐가 아니라, 내담자와 상담사 사이의 “관계의 질”이다. 이 관계를 학술적으로 “치료적 동맹(therapeutic alliance)”이라 부른다. 쉽게 말하면 “이 사람과 함께라면 내 문제를 해결할 수 있겠다”는 느낌이다. 수십 년간의 연구가 일관되게 보여주는 결론이 있다. 어떤 기법을 쓰든, 치료적 동맹이 강한 상담이 결과가 좋다. CBT를 하든 정신역동을 하든 인본주의를 하든, 내담자가 상담사를 신뢰하고 협력하는 관계가 형성되어야 변화가 일어난다.

Gainer(2025)는 이 개념을 온라인 환경으로 확장해서 “디지털 치료적 동맹(Digital Therapeutic Alliance, DTA)”이라 이름 붙였다. DTA는 세 가지 요소로 이루어진다. 첫째, 목표 합의 — 내담자와 상담사가 “뭘 해결할 건지” 같은 방향을 보는 것이다. 앱에서는 접수 과정에서 “불안을 줄이고 싶다”를 “주 3회 이상 숙면하기”처럼 구체적 목표로 바꿔주는 것이 이에 해당한다. 막연한 “나아지고 싶다”를 측정 가능한 목표로 전환하는 과정 자체가 치료적이다.

둘째, 과업 합의 — “어떤 방법으로 해결할 건지”에 대한 상호 이해다. “매일 감정 일기 쓰기”, “주 1회 CBT 모듈 완료” 같은 구체적 활동을 설정하고, 진행 상황을 대시보드로 보여주는 것이다. 오프라인 상담에서는 “이번 주에 이것을 해보세요”라고 말하면 끝이지만, 디지털 환경에서는 진행률 바(progress bar)와 알림으로 과업을 함께 추적할 수 있다.

셋째, 정서적 유대 — “이해받고 있다”는 느낌이다. 이게 디지털에서 가장 어려운 부분이다. Gainer는 AI가 내담자의 이름을 기억하고, 지난 대화 맥락을 이어가고, 일관된 톤을 유지하는 것이 정서적 유대의 디지털 버전이 될 수 있다고 본다. 예를 들어, 지난주에 내담자가 “어머니와 다퉜다”고 했으면, 이번 주에 “지난번에 어머니와의 일 이후 어떠세요?”라고 먼저 물어보는 것이다. 사소해 보이지만, “내 이야기를 기억하고 있구나”라는 경험은 관계 형성에 큰 영향을 미친다.

세네카 R. 게이너

디지털 치료적 동맹은 오프라인 상담을 온라인으로 단순히 옮기는 게 아니다. 기술이 매개하는 새로운 유형의 관계이며, 이 관계의 품질은 인터페이스 설계, 반응 시간, 개인화 수준, 그리고 안전감의 함수다.

— Gainer (2025, p. 189)

사용자 중심 설계: 누구를 위한 앱인가?

Alan Cooper(2014)는 ‘About Face’라는 책에서 “페르소나(persona)” 기법을 체계화했다. 페르소나란, 실제 사용자 조사를 바탕으로 만든 가상의 대표 사용자다. 예를 들어 “김지수, 24세, 대학원생, 밤 11시에 침대에서 스마트폰으로 접속” 같은 구체적인 인물 프로필이다. 페르소나는 단순한 인구통계학적 정보가 아니다. 이 사람의 하루 일과, 기술에 대한 태도, 상담에 대한 기대와 두려움까지 포함하는 입체적인 인물상이다.

Cooper가 강조한 핵심은 “모든 사용자를 만족시키려 하면 아무도 만족시키지 못한다”는 것이다. 이것을 “탄력적 사용자(elastic user)의 함정”이라 부른다. “20대부터 60대까지 누구나 쓸 수 있는 앱”을 만들려 하면, 결국 어느 연령대에게도 맞지 않는 앱이 된다. 상담 플랫폼이라면 최소 두 명의 페르소나가 필요하다. 내담자 페르소나와 상담사 페르소나다. 내담자의 목표는 “판단받지 않고 편하게 이야기하고 싶다”이고, 상담사의 목표는 “내담자 정보를 빠르게 파악하고 상담에 집중하고 싶다”이다. 이 두 목표가 충돌하는 지점을 찾아 균형을 잡는 게 설계의 핵심이다.

예를 들어 생각해보자. 내담자 입장에서는 질문이 적을수록 부담이 없다. 하지만 상담사 입장에서는 정보가 많을수록 초기 면접이 효율적이다. 이 충돌을 해결하려면 “꼭 필요한 질문만 먼저 하고, 나머지는 상담 과정에서 자연스럽게 수집한다”는 전략이 나온다. 기술적으로는 조건부 분기(답에 따라 다음 질문이 바뀌는 구조)로 구현할 수 있다.

앨런 쿠퍼

소프트웨어 설계에서 가장 비용이 큰 실수는 구현 단계가 아니라 설계 단계에서 발생한다. 잘못된 기능을 완벽하게 구현하는 것보다, 올바른 기능을 불완전하게 구현하는 것이 낫다.

— Cooper (2014), About Face

Gainer(2025)는 여기에 한 가지를 더한다. 상담 앱은 은행 앱이 아니다. 사용자가 가장 힘들고 취약한 순간에 접속하는 도구다. 에러 메시지 하나가 “여기서도 실패했다”는 자기비난을 불러올 수 있다. 그래서 상담 플랫폼의 설계에는 “이 사용자가 울고 있을 때도 이것을 사용할 수 있는가?”라는 질문이 항상 따라다녀야 한다. 에러 메시지조차 “문제가 발생했습니다”가 아니라 “잠시 연결이 어려워요. 괜찮습니다. 잠시 후 다시 시도해주세요”처럼 따뜻하고 안심을 주는 톤으로 써야 한다.

앨리슨 다시

정신건강 앱에서 가장 큰 실패는 기술적 오류가 아니다. 사용자가 도움을 요청하는 순간에 실망을 주는 것이다. 그 순간이 바로 사용자가 가장 취약할 때다.

— Darcy (2017)

와이어프레임: 코딩 전에 그려보는 설계도

집을 지을 때 설계도 없이 벽돌부터 쌓지 않듯, 앱을 만들 때도 코딩 전에 화면 구조를 먼저 그려본다. 이것을 와이어프레임(wireframe)이라 한다. 예쁜 디자인이 아니라 “어디에 뭐가 놓이는지”만 보여주는 뼈대 그림이다. 색상도 이미지도 없고, 회색 상자와 텍스트만으로 구성된다.

와이어프레임을 그리는 이유는 세 가지다. 첫째, 팀원과 설계 의도를 공유할 수 있다. “접수 폼 오른쪽에 진행률 바를 넣자”라고 말로만 하면 사람마다 다르게 상상한다. 그림으로 보여주면 오해가 줄어든다. 둘째, 코딩 전에 문제를 미리 발견할 수 있다. “이 버튼을 누르면 어디로 가지?”라는 질문에 답할 수 없다면, 설계가 불완전한 것이다. 셋째, 개발자에게 화면 구조를 전달할 수 있다. 상담 전문가가 “이런 느낌의 접수 폼이 필요해요”라고 하면, 개발자는 구체적으로 뭘 만들어야 할지 알 수 없다. 와이어프레임은 그 간극을 메운다.

상담 플랫폼의 와이어프레임에서 특별히 신경 써야 할 부분이 있다. 위기 스크리닝 결과가 나왔을 때의 화면 분기다. PHQ-9 9번 문항에서 높은 점수가 나오면, 일반적인 결과 화면이 아니라 위기 지원 안내 화면으로 전환되어야 한다. 이 분기를 와이어프레임 단계에서 미리 설계해두지 않으면, 개발 과정에서 빠뜨릴 수 있다.

MVP: 작게 만들어서 빨리 확인하기

소프트웨어를 만들 때 모든 기능을 한꺼번에 구현하면 시간도 오래 걸리고, 사용자가 원하지 않는 기능에 공을 들이게 될 수 있다. 그래서 MVP(Minimum Viable Product, 최소 기능 제품)라는 전략을 쓴다. 핵심 가설을 검증할 수 있는 최소한의 기능만 먼저 만들어보는 것이다. 스타트업에서 흔히 쓰는 전략인데, 상담 플랫폼에도 똑같이 적용된다.

MVP의 핵심은 “완벽한 제품을 만드는 것”이 아니라 “핵심 가설을 검증하는 것”이다. 상담 플랫폼의 MVP 가설은 이런 거다 — “온라인 접수 시스템이 내담자의 심리적 안전감을 해치지 않으면서 상담사의 초기 평가 효율을 높일 수 있는가?” 이걸 검증하려면 접수 폼, 기본 선별 검사, 결과 요약 화면이면 된다. 화상 상담, AI 보고서 생성, 다국어 지원은 나중 일이다. 먼저 가장 기본적인 것이 작동하는지 확인하고, 사용자 피드백을 받아서 다음 버전을 만든다.

기능의 우선순위를 정할 때는 MoSCoW라는 분류법을 쓴다. Must have(이것 없으면 안 됨) — 접수 폼, 위기 스크리닝, 기본 점수 산출.Should have(있으면 훨씬 좋음) — 불안 검사 통합, 결과 시각화. Could have(시간 되면 추가) — AI 주호소 분석.Won't have this time(이번엔 안 함) — 화상 상담, 보험 연동. 우리 프로젝트도 이 프레임으로 범위를 정하게 된다.

MoSCoW에서 가장 어려운 판단은 “Must”와 “Should”의 경계다. 위기 스크리닝은 당연히 Must다. 사람의 안전과 직결되니까. 하지만 “결과 시각화”는 어떨까? 숫자만 보여줘도 기능은 하지만, 그래프로 보여주면 상담사의 이해가 훨씬 빨라진다. 이런 판단을 내릴 때 페르소나가 기준이 된다. 상담사 페르소나가 “15명의 내담자를 빠르게 파악해야 한다”면, 시각화는 Must에 가깝다. 이처럼 기능 우선순위는 추상적 원칙이 아니라 구체적 사용자의 목표에서 출발해야 한다.

스티브 크루그

사용자가 생각하게 만들지 마라. 좋은 인터페이스는 설명이 필요 없다. 사용자가 '이게 뭐지?'라고 생각하는 순간, 설계자는 실패한 것이다.

— Krug (2014), Don't Make Me Think

Steve Krug의 이 원칙은 상담 플랫폼에서 더욱 중요하다. 일반 앱의 사용자가 혼란을 느끼면 짜증을 내고 다른 앱을 찾는다. 하지만 상담 앱의 사용자가 혼란을 느끼면 “나도 여기서조차 제대로 못하는구나”라는 자기비난으로 이어질 수 있다. 인터페이스가 직관적이어야 하는 이유가 편의성뿐만 아니라 치료적 안전 때문이기도 한 것이다. 이것이 상담 플랫폼 설계가 일반 소프트웨어 설계와 다른 결정적 지점이다.

상담 과정, 무엇을 자동화하고 무엇을 지켜야 하나

상담은 보통 여섯 단계를 거친다. 접수(intake) → 심리평가(assessment) → 목표 설정 → 개입(intervention) → 모니터링 → 종결이다. 이 단계들을 잘 들여다보면, “정해진 양식에 정보를 채우는 일”과 “상담사가 머리를 써서 판단하는 일”이 섞여 있다. 마치 요리에서 “재료를 씻고 다지는 일”과 “간을 보고 불 세기를 조절하는 일”이 다른 것처럼, 상담에서도 기계적으로 처리할 수 있는 부분과 인간의 판단이 꼭 필요한 부분이 구분된다.

예를 들어 접수 단계에서 이름, 연락처, 보험 정보를 받는 건 누가 해도 같다. 이런 건 컴퓨터가 더 정확하고 빠르다. 하지만 내담자의 표정을 읽고, 말투에서 불안을 감지하고, 첫 만남에서 신뢰를 쌓는 건 상담사만 할 수 있다.Gainer(2025)는 이걸 “자동화 적합성 스펙트럼”이라 불렀다. 한쪽 끝에는 완전 자동화(데이터 입력, 점수 계산), 반대쪽 끝에는 반드시 인간이 해야 하는 일(위기 개입의 최종 결정, 상담 관계의 회복)이 있다. 그 가운데에 AI가 보조하되 상담사가 감독하는 “증강(augmentation)” 영역이 있다.

세네카 R. 게이너

기술이 증강하되 대체하지 않는다(Augment, don't replace). 이 원칙은 상담 프로세스의 모든 단계에서 설계의 나침반이 되어야 한다. 자동화는 상담사에게 시간을 돌려주기 위한 것이지, 상담사를 제거하기 위한 것이 아니다.

— Gainer (2025, p. 156)

구체적으로 보면, 접수 단계가 디지털화에 가장 적합하다. 인적 사항, 상담 이력, 주호소를 온라인 폼으로 받으면 상담사가 행정 질문에 쓰는 시간(보통 15~20분)을 절약할 수 있다. 내담자 입장에서도 집에서 편하게, 자기 속도로 적을 수 있어서 오히려 더 솔직해진다는 연구 결과도 있다. 대면에서는 상담사의 눈치를 보며 축소해서 말하던 것을, 혼자 폼을 작성할 때는 더 솔직하게 적는다는 것이다.

심리평가 단계에서는 PHQ-9, GAD-7 같은 표준 검사의 실시와 채점을 완전 자동화할 수 있다. 종이에 답을 적고, 상담사가 수작업으로 점수를 계산하고, 해석표를 찾아보는 과정이 클릭 한 번으로 끝난다. 하지만 검사 결과가 “이 사람한테 어떤 의미인지” 해석하는 건 상담사의 몫이다. PHQ-9 점수가 15점이라도, 원래 25점이었다가 15점으로 내려온 사람과 원래 5점이었다가 15점으로 올라간 사람은 상황이 완전히 다르다.

목표 설정과 개입 단계는 AI가 보조하되 인간이 주도하는 영역이다. AI가 “이 내담자에게 CBT 기법이 적합할 수 있다”고 제안할 수는 있지만, 실제로 그 기법을 적용할지, 언제 적용할지, 어떻게 내담자의 속도에 맞출지는 상담사가 결정한다. 모니터링 단계에서는 AI의 역할이 다시 커진다. 매 회기 진행 상황을 추적하고, 변화 패턴을 시각화하고, “3회기 연속 호전 없음” 같은 알림을 보내는 것은 AI가 인간보다 정확하고 일관되게 할 수 있다.

마이클 램버트

상담 성과를 추적하고 피드백을 제공하는 시스템은 그 자체로 치료 결과를 개선한다. 상담사가 내담자의 진행 상황을 객관적으로 파악할 수 있을 때, 더 나은 임상적 결정을 내린다.

— Lambert (2013)

종결 단계에서도 기술이 도울 수 있다. 상담이 끝날 때 전체 진행 과정을 요약하는 보고서를 AI가 자동으로 생성할 수 있다. “첫 회기 PHQ-9 점수 18점에서 마지막 회기 7점으로 감소”, “주요 작업 주제: 가족 갈등, 완벽주의” 같은 내용을 정리하면, 향후 상담이 필요할 때 참고 자료가 된다. 하지만 종결의 핵심은 기록이 아니라 “이별”이다. 내담자와 상담사가 함께 온 여정을 되돌아보고, 감정을 정리하고, 이별을 건강하게 경험하는 과정은 인간만이 할 수 있는 치료적 작업이다.

칼 로저스

상담사의 역할은 문제를 해결해주는 것이 아니다. 내담자가 자기 안에서 답을 찾을 수 있도록 안전한 관계를 제공하는 것이다.

— Rogers (1961)

와이어프레임: 앱의 설계도 그리기

와이어프레임(wireframe)은 앱이나 웹사이트의 “뼈대 그림”이다. 색상이나 예쁜 디자인 없이, 어디에 뭐가 놓이는지만 보여주는 간단한 스케치다. 건축으로 치면 평면도와 같다. 와이어프레임을 그리는 이유는 세 가지다. 팀원과 설계 의도를 공유하고, 코딩하기 전에 문제를 미리 발견하고, 개발자에게 화면 구조를 전달하기 위해서다.

와이어프레임에는 세 가지 수준이 있다. 저충실도(low-fidelity)는 종이에 손으로 그린 스케치다. 5분이면 되고, 아이디어를 빠르게 탐색할 때 쓴다. 중충실도(mid-fidelity)는 디지털 도구로 그린 깔끔한 뼈대다. Miro나 Figma 같은 도구를 쓰고, 팀원과 공유하기 좋다.고충실도(high-fidelity)는 실제 앱처럼 보이는 프로토타입이다. 이번 수업에서는 중충실도 수준을 목표로 한다.

상담 플랫폼의 사용자 동선(user flow)은 크게 두 가지로 나뉜다.내담자 동선은 첫 화면 → 회원가입 → 접수 폼 작성 → 선별 검사(PHQ-9, GAD-7) → 결과 확인 → 상담 예약 순서다.상담사 동선은 로그인 → 대시보드(새 접수 알림 확인) → 내담자 프로필 조회 → 검사 결과 확인 → 상담 기록 작성 순서다. 이 두 동선이 만나는 지점이 핵심이다 — 내담자가 접수를 완료하면 상담사에게 알림이 가는 것처럼.

사용자 동선을 설계할 때 특별히 주의할 점이 있다. “이탈 지점(drop-off point)”을 예측하는 것이다. 내담자가 접수 폼을 작성하다 중간에 포기하는 경우가 생각보다 많다. 질문이 너무 많거나, 민감한 질문이 갑자기 나오거나, 진행률을 알 수 없을 때 이탈률이 높아진다. 이런 이탈 지점마다 “지금까지 잘 하고 계세요. 거의 다 왔습니다” 같은 격려 메시지를 넣는 것도 상담적 배려의 일환이다.

앨런 쿠퍼

'탄력적 사용자'의 함정을 피하라. 모든 사용자를 만족시키려는 설계는 결국 누구의 요구도 만족시키지 못한다. 구체적인 페르소나를 정의하고, 그 페르소나의 목표를 중심으로 설계하라.

— Cooper (2014)

AI 설계 도구: Miro AI와 v0.dev

과거에는 와이어프레임을 그리려면 Figma 같은 전문 도구를 배워야 했다. 이제는 AI 도구로 훨씬 쉽게 시작할 수 있다. Miro AI에 “상담 접수부터 종결까지 사용자 플로우를 다이어그램으로 만들어줘”라고 한국어로 입력하면, 주요 단계와 분기점이 포함된 플로우차트가 자동으로 나온다. 이걸 상담 맥락에 맞게 수정하면 된다. 예를 들어, AI가 만든 플로우차트에 위기 분기점이 빠져 있으면 직접 추가해야 한다.

v0.dev는 Vercel이라는 회사가 만든 AI UI 생성 도구다. “심리상담 접수 페이지를 만들어줘. 이름, 연락처, 주호소 자유 서술란, PHQ-9 설문 포함”이라고 입력하면, 실제 작동하는 웹 폼 코드가 나온다. 코딩을 할 줄 모르는 상담 전공 학생도 30분 만에 작동하는 프로토타입을 만들 수 있다는 것이 이 도구의 장점이다. 과거에는 개발자 없이는 불가능했던 일이 지금은 한국어 설명만으로 가능하다.

하지만 AI가 만든 UI를 그대로 쓰면 안 된다. 위기 스크리닝 로직, 정서적 안전 문구, 상담 맥락에 맞는 표현 수정은 상담 전문가가 직접 해야 한다. 예를 들어, AI가 생성한 폼에 “자살에 대한 생각이 있습니까?”라고 적혀 있다면, 실제 PHQ-9의 표준 한국어 번역 문항으로 교체해야 한다. AI가 제공한 뼈대 위에 상담학적 판단을 입히는 것이 핵심이다. 기술은 도구이고, 전문성은 그 도구를 어떻게 쓰느냐에 있다.

스티브 크루그

사용자 테스트의 핵심은 우아함이 아니라 명료함이다. 사용자가 3초 안에 '이 페이지에서 나는 무엇을 할 수 있는가'를 파악할 수 있어야 한다.

— Krug (2014)

Krug의 “3초 규칙”을 상담 접수 폼에 적용하면 이렇다. 내담자가 접수 폼의 첫 화면을 열었을 때, 3초 안에 “여기서 나는 내 정보를 입력하면 되는구나”를 파악할 수 있어야 한다. “환영합니다. 아래 정보를 편하게 입력해주세요”라는 안내 문구, 깔끔한 입력 필드 배치, 진행률 바가 보이면 사용자는 즉시 뭘 해야 할지 안다. 반면 메뉴바, 공지사항, 로고, 광고가 뒤섞여 있으면 사용자는 혼란에 빠진다. 특히 심리적으로 힘든 상태의 내담자에게 이런 혼란은 치명적이다. 설계의 첫 번째 원칙은 “군더더기를 빼는 것”이다.

이번 주 강의의 핵심 메시지를 정리하면 이렇다. 상담 과정의 각 단계에는 자동화에 적합한 부분과 인간이 반드시 해야 하는 부분이 있다. 이 구분을 명확히 하는 것이 상담 플랫폼 설계의 출발점이다. 와이어프레임은 그 설계를 눈에 보이는 형태로 만드는 도구이고, AI 도구는 와이어프레임 제작의 진입 장벽을 낮춰준다. 하지만 최종적으로 “이 인터페이스가 내담자에게 안전한가?”를 판단하는 것은 상담 전문가의 역할이다.

페르소나 만들기: 내 앱은 누구를 위한 건가?

Alan Cooper(2014)의 페르소나 기법을 실제로 적용해보자. 상담 플랫폼을 만들려면 최소 두 명의 페르소나가 필요하다 — 내담자와 상담사다. 페르소나에 들어가야 하는 정보는 이렇다. 이름(가상), 나이, 직업, 디지털 기기 사용 수준, 상담 경험, 목표(감정적 목표·실질적 목표·인생 목표), 불편한 점(frustrations), 사용 환경(언제, 어디서, 어떤 기기로 접속하는가).

페르소나를 만들 때 가장 흔한 실수는 “너무 일반적으로 쓰는 것”이다. “20대 대학생”은 페르소나가 아니다. 구체적이어야 한다. “김지수, 24세, 서울 소재 대학원 석사 2학기, 밤 11시 이후 침대에서 스마트폰으로 접속하는 사람”이 페르소나다. 이 정도로 구체적이어야 설계할 때 “김지수라면 이 버튼을 찾을 수 있을까?”라는 질문을 던질 수 있다.

예를 들어 내담자 페르소나 “김지수(24세, 대학원생)”는 이렇다. 스마트폰 위주 사용자이고, 대학 상담센터를 1번 가봤지만 대기가 길어서 포기했다. 감정적 목표는 “판단받지 않고 내 이야기를 하고 싶다”, 실질적 목표는 “논문 스트레스와 수면 문제를 해결하고 싶다”이다. 불편한 점은 “예약이 2주 넘게 걸린다”, “첫 방문에서 같은 이야기를 여러 번 반복해야 했다”이다. 주로 밤 11시 이후에 침대에서 스마트폰으로 접속한다. 이 마지막 정보가 설계에 미치는 영향을 생각해보자. 밤 11시, 침대, 스마트폰이면 화면은 어두운 배경이 좋고, 글씨는 커야 하고, 한 손으로 조작할 수 있어야 한다.

세네카 R. 게이너

상담 플랫폼을 설계하는 것은 은행 앱을 설계하는 것과 다르다. 사용자가 가장 취약한 순간에 접근하는 도구이기 때문이다. 모든 인터페이스 요소는 '이 사용자가 울고 있을 때도 이것을 사용할 수 있는가?'라는 질문을 통과해야 한다.

— Gainer (2025, p. 201)

상담사 페르소나 “이현우(38세, 임상심리전문가)”는 PC 위주 사용자이고, 엑셀과 한글을 주로 쓴다. 실질적 목표는 “주 15사례를 효율적으로 관리하고 싶다”이다. 불편한 점은 “접수 면접에서 행정 질문에 15분을 쓰고 나면 정작 호소 문제를 탐색할 시간이 부족하다”, “검사 채점에 시간이 너무 많이 걸린다”이다. 이 페르소나에서 알 수 있는 설계 시사점이 있다. 상담사 화면은 PC 기준으로 설계해야 하고, 여러 내담자의 정보를 한눈에 볼 수 있는 대시보드가 핵심이다. 엑셀과 한글에 익숙한 사용자이므로, 인터페이스가 너무 생소하면 안 된다.

MoSCoW로 기능 우선순위 정하기

페르소나를 만들었으면, 각 페르소나의 목표를 달성하려면 어떤 기능이 필요한지 리스트를 뽑는다. 이때 “기능”이 아니라 “사용자 스토리” 형식으로 쓰는 게 좋다. 사용자 스토리의 형식은 “[누구]로서, [목적]을 위해, [기능]이 필요하다”이다. 예를 들어 “김지수(내담자)로서, 상담 전에 내 상태를 전달하기 위해, 접수 면접 폼이 필요하다” 이런 식이다. 기능 자체가 아니라 “누가 왜 필요한가”에 초점을 맞추면, 정말 필요한 기능과 있으면 좋은 기능을 구분하기 쉬워진다.

사용자 스토리 목록이 나오면 MoSCoW에 배치한다. 판단 기준은 세 가지다. 첫째, 안전(safety) — 위기 감지 관련 기능은 무조건 Must다. 이것은 협상의 대상이 아니다. 둘째, 핵심 가치 — 이 플랫폼이 존재하는 이유와 직결되는 기능은 Must 또는 Should다. 접수 폼 없이 상담 플랫폼을 쓸 수 없으므로 접수 폼은 Must다. 셋째, 구현 가능성 — 학기 안에 만들 수 있는가? 8주 안에 AI 통합까지 하기는 어려우니, 기본 폼과 채점 로직에 집중하는 게 현실적이다.

앨런 쿠퍼

'탄력적 사용자(elastic user)'의 함정을 피하라. 모든 사용자를 만족시키려는 설계는 결국 누구의 요구도 만족시키지 못한다.

— Cooper (2014)

사용자 스토리를 잘 쓰는 팁이 있다. “접수 폼이 필요하다”라고만 쓰면, 그 폼이 왜 필요한지, 어떤 맥락에서 쓰이는지가 빠진다. “김지수(내담자)로서, 첫 상담 전에 내 상태를 미리 전달하기 위해, 편안한 분위기의 접수 폼이 필요하다. 이를 통해 대면 상담에서 같은 이야기를 반복하지 않아도 된다”라고 쓰면 설계 의도가 명확해진다. “편안한 분위기”라는 표현이 들어가면, 폼의 색상·문구·레이아웃 결정에도 영향을 미친다.

스티브 크루그

좋은 설계의 비밀은 단순함이 아니라 명료함이다. 사용자가 무엇을 해야 하는지 즉시 파악할 수 있는 인터페이스가 좋은 인터페이스다.

— Krug (2014)

MoSCoW 분류를 할 때 팀 내에서 의견이 갈리는 경우가 많다. 예를 들어, AI 기반 주호소 분석은 Must인가 Could인가? 상담사 페르소나의 목표가 “내담자 정보를 빠르게 파악하는 것”이라면, AI가 주호소에서 키워드를 뽑아주는 기능은 상당히 유용하다. 하지만 학기 안에 구현할 수 있는가를 고려하면 Could로 내려갈 수 있다. 이런 판단은 정답이 없다. 팀원들이 페르소나를 공유하고 있으면, 적어도 같은 기준으로 논의할 수 있다.

와이어프레임에서 확인해야 할 상담적 체크리스트

v0.dev로 와이어프레임을 만든 후, 상담 전문가 관점에서 반드시 검토해야 할 항목이 있다. 첫째, 위기 분기 동선이 있는가? PHQ-9 9번 문항에서 높은 점수가 나왔을 때, 일반 결과 화면이 아닌 위기 지원 화면으로 전환되는가? 둘째, 안전 문구가 적절한가? 민감한 질문 앞에 “이 질문은 당신의 안전을 위해 묻는 것입니다” 같은 안내가 있는가? 셋째, 자동 저장이 되는가? 내담자가 중간에 나갔다 돌아올 수 있는가? 이 세 가지가 빠져 있으면 기술적으로는 완벽해도 상담 도구로서는 부족하다.