전문가의 지식을 서비스로: 상담·검사와 캐릭터챗 개발
심리 전문가와 상담·검사 서비스를 만들고, 검사 결과 기반 캐릭터챗을 개발하는 협업 과정을 소개합니다.

전문가의 설명을 화면으로 옮길 때 생기는 질문
심리상담 분야 박사님과 함께 심리상담·검사 서비스를 만들고 있습니다. 중심은 상담과 검사이고, 검사 결과를 바탕으로 캐릭터와 대화하는 기능도 개발 중입니다. 이 일을 하며 다루는 질문은 “AI가 무엇을 말할 수 있는가”에만 머물지 않습니다. 이용자가 어떤 정보를 보고, 다음에 무엇을 할 수 있으며, 누가 내용을 검토해야 하는지가 제품의 흐름을 결정합니다.
이 글에서 가져갈 것은 전문가의 요구를 검토 가능한 화면과 상태로 나누는 방법입니다. 고객사의 검사 문항이나 대화 설계 대신, 가상 도서관의 프로그램 신청 예제로 그 과정을 따라가겠습니다. 이 실습은 심리 검사나 상담 기능을 재현하지 않습니다.
요구 한 줄을 질문과 예외로 나눕니다
가상 도서관 담당자가 “프로그램 안내를 읽은 사람이 신청 현황을 알 수 있게 해주세요”라고 요청했다고 해봅시다. 바로 신청 버튼부터 만들면, 클릭 직후 어떤 문구가 나와야 하는지 결정되지 않은 채로 화면이 완성될 수 있습니다.
먼저 세 가지를 정합니다. 신청을 보냈다는 것과 자리가 확정됐다는 것이 같은가? 확인은 누가 하는가? 신청자가 취소하면 어떤 상태가 되는가? 이 실습에서는 담당자가 확인 후 확정하고, 신청자는 확정 전후 모두 취소할 수 있다고 정합니다.
| 질문 | 실습에서 정한 규칙 | 화면에 미치는 영향 |
|---|---|---|
| 신청하면 바로 확정인가? | 아니요, 담당자 확인 필요 | 제출 직후 “신청 접수” 표시 |
| 확정은 누가 하나? | 담당자 | 이용자 화면에는 확정 버튼 없음 |
| 취소 뒤 되돌릴 수 있나? | 기존 신청 복구 대신 새 신청 | 취소 건은 기록으로 남김 |
| 프로그램을 못 찾으면? | 신청을 만들지 않음 | 안내 화면으로 돌아갈 경로 제공 |
이 표는 개발 명세이면서 담당자에게 보여줄 질문 목록입니다. “신청 기능 개발 완료”보다 “접수 직후 확정으로 안내하지 않는지 확인해 주세요”가 검토하기 쉽습니다.
가상 데이터 세 건으로 상태를 움직여 봅니다
프로그램은 글쓰기 모임 P-01, 사진 산책 P-02, 책 정리 워크숍 P-03입니다. 이용자는 실명과 연락처 대신 U-01 같은 가상 ID만 사용합니다. 프로그램 안내에는 제목·일정·장소를 표시하고, 신청 기록에는 신청 ID·프로그램 ID·이용자 ID·상태만 둡니다.
| 신청 ID | 프로그램 | 이용자 | 현재 상태 | 가능한 다음 행동 |
|---|---|---|---|---|
| R-01 | P-01 | U-01 | 접수 | 담당자 확인 / 이용자 취소 |
| R-02 | P-02 | U-02 | 확인 중 | 담당자 확정 / 이용자 취소 |
| R-03 | P-03 | U-03 | 확정 | 이용자 취소 |
기대하는 정상 흐름은 접수 → 확인 중 → 확정입니다. 각 단계에서 취소할 수 있지만 취소 → 확정 이동은 허용하지 않습니다. 예를 들어 R-01을 확인 중으로 옮기면 이용자 화면에도 “담당자가 확인하고 있어요”가 보여야 합니다. 담당자 화면만 바뀌고 이용자 화면이 그대로라면 두 화면이 같은 신청 기록을 읽는지 확인합니다.
화면 검토와 내용 검토를 따로 기록합니다
전문가 협업에서는 버튼이 작동한다는 사실만으로 문구 검토까지 끝났다고 볼 수 없습니다. 그래서 실습에서도 두 개의 확인 칸을 둡니다. 하나는 기능 확인, 다른 하나는 문구·운영 규칙 확인입니다.
| 항목 | 개발에서 확인할 것 | 담당자에게 확인할 것 |
|---|---|---|
| 접수 직후 화면 | 상태가 접수로 저장됨 | “접수”라는 안내가 실제 운영과 맞음 |
| 확인 중 화면 | 같은 신청 ID를 보여줌 | 대기 중 무엇을 해야 하는지 충분함 |
| 취소 화면 | 취소 후 확정 이동을 막음 | 재신청 방법과 안내 문장이 정확함 |
검토 기록에는 항목·결과·검토자·확인일을 남깁니다. 아직 답을 못 받은 문장은 “검토 필요”로 둡니다. 문장이 자연스러워 보인다는 이유만으로 승인 상태를 채우지 않습니다. 실제 심리상담·검사 서비스에서는 전문 내용과 해석을 전문가와 검토하고, 개발에서는 화면과 정보 연결을 확인하는 식으로 역할을 나눕니다.
Claude Code·Codex에 부탁할 범위
가상 도서관 프로그램 신청 프로토타입을 만들어줘.
프로그램 P-01~03, 가상 이용자 U-01~03, 신청 R-01~03 표를 사용해.
이용자 화면은 안내/신청 현황/취소, 담당자 화면은 신청 목록/확인/확정이야.
상태는 접수→확인 중→확정, 세 상태 모두 취소로 이동 가능해.
취소에서 확정으로 되돌리는 동작은 막아줘.
기능 확인과 담당자 문구 검토를 별도 필드로 관리해.
실명, 연락처, 실제 계정, 외부 전송은 넣지 마.
역할 전환은 데모용 선택기로만 만들고 실제 권한 제어와 구분해.
각 화면을 어떻게 검토하면 되는지 안내해줘.
역할 선택기만으로 이용자와 담당자 화면을 나누는 것은 시연 방법입니다. 실제 서비스에서는 주소를 직접 열거나 요청을 보냈을 때도 다른 사람의 정보를 받지 못하도록 서버의 접근 제어가 필요합니다. 가상 데이터로 화면을 검토하는 단계와 실제 계정을 붙여 운영하는 단계를 나눠 진행하세요.
검토 회의에 가져갈 것은 기능 목록보다 장면입니다
“신청 기능이 있습니다” 대신 세 장면을 준비합니다. 신청자가 막 제출한 장면, 담당자가 확인 중으로 바꾼 장면, 이용자가 취소한 뒤 다시 들어온 장면입니다. 각 장면에서 화면 문구와 가능한 행동을 함께 보여줍니다.
여기에 실패 장면 하나를 더합니다. 존재하지 않는 신청 ID를 열면 빈 화면이 아니라 “신청을 찾을 수 없어요”와 목록으로 돌아가는 링크가 보여야 합니다. 이런 장면을 만들면 전문 지식을 모두 이해하기 전에도 구체적인 피드백을 받을 수 있습니다.
지금 개발 중인 검사 결과 기반 캐릭터챗에서도 결과 맥락을 다음 경험으로 어떻게 전달할지 검토하는 일이 남아 있습니다. 이 글의 실습에서 얻을 수 있는 연습은 명확합니다. 요구를 상태로 나누고, 같은 기록이 여러 화면에서 일관되게 보이는지 확인한 뒤, 담당자에게 검토할 장면을 보여주는 것입니다.
이 사례의 바탕 · 심리 전문가와 상담·검사 서비스를 만드는 협업 경험입니다. 검사 결과 기반 캐릭터챗은 개발 중입니다. 고객사 자료와 이용자 기록을 제외했으며, 위 도서관 예제는 별도로 만든 비의료 실습입니다.



