사용자의 일에서 기능과 설계 정하기

01 · 문제에서 시작

기능은 있는데 신청이 끝났는지 알 수 없다

작은 행사 참가 신청 도구를 만든다고 생각해 보세요. 로그인과 게시판은 있지만, 신청 버튼을 누른 뒤 화면이 그대로입니다. 신청자는 기다리다가 한 번 더 누르고 담당자에게 문의합니다.

이 도구의 문제는 기능이 적다는 데 있지 않습니다. 신청자가 하려던 일, 즉 원하는 날짜에 신청하고 접수 결과를 확인하는 일이 끝나지 않았습니다. 여기서 무엇을 만들지 판단할 기준이 생깁니다.

기능 중심 설계는 로그인·게시판 같은 기능 목록에서 출발합니다. 사용자 중심 설계는 누가 어떤 상황에서 무엇을 끝내려는지 살피고 필요한 기능을 찾습니다. 로그인도 필요한 기능일 수 있지만, 그 이유는 실제 사용하는 상황에서 확인해야 합니다.

이 자료의 행사 조건은 설명을 위한 가정입니다. 자기 프로젝트에 적용할 때는 실제 사용자와 운영 담당자에게 확인하세요. ‘명세’는 만들 것과 범위·완료 기준을 적은 문서입니다. 기존 명세가 없다면 이 사례로 연습하거나 본인이 반복하는 일 하나를 골라도 됩니다.

02 · 요청의 이유

“문자 알림을 주세요”는 어떤 뜻일까?

신청자에게 물었더니 “신청하면 문자 알림이 있었으면 좋겠어요”라고 합니다. 이제 바로 문자 발송을 만들면 될까요?

조금 더 물어보니 ‘접수됐는지 몰라서 불안하다’고 답합니다. 하지만 신청 직후만 확인하면 되는지, 며칠 뒤에도 다시 확인하려는지는 아직 모릅니다. 즉시 확인에는 완료 화면이, 재확인에는 접수 내역이, 화면을 떠난 뒤 안내에는 문자가 도움이 될 수 있습니다.

따라서 다음 질문은 ‘어떤 문자 서비스를 쓸까?’가 아니라 ‘언제 접수 여부를 다시 확인하고 싶나요?’입니다. 사용자 요청을 무시하는 것이 아니라 그 요청이 해결하려는 상황을 알아보는 과정입니다.

AI에게는 ‘요청의 목적, 확인된 사실, 아직 모르는 내용, 다른 해결 방법을 구분해 줘’라고 부탁할 수 있습니다. AI가 ‘로그인하면 문의가 줄어든다’고 답해도 효과가 확인된 것은 아닙니다. 문의가 생긴 이유와 대안을 비교해야 합니다.

03 · 행동에서 기능 찾기

신청자가 시작하는 순간부터 따라가 보기

이제 ‘날짜를 고르고 정보를 넣어 접수 결과를 확인한다’는 일을 순서대로 펼쳐 봅니다.

신청자는 참가 가능한 날짜를 봅니다. 여기서 날짜와 마감 여부 표시가 필요합니다. 이름과 연락처를 적고 제출 전에 확인합니다. 입력과 수정 기능이 필요합니다. 마지막에는 실제로 접수된 내용을 확인합니다. 접수 기록과 결과 표시가 필요합니다.

담당자는 다른 일을 합니다. 날짜별 신청 목록을 보고 인원을 확인해야 합니다. 신청자 화면에 완료가 보여도 담당자 목록에 기록이 없다면 두 결과가 맞지 않습니다. 완료라고 표시할 조건은 실제 기록까지 포함해야 합니다.

• 날짜 선택 → 날짜·마감 여부 표시
• 내용 입력·확인 → 입력·수정
• 접수 확인 → 신청 기록·결과 표시·담당자 목록 반영

04 · 빠진 규칙 찾기

마지막 한 자리에 두 사람이 신청한다면

정상적인 신청 순서만 그려서는 결정할 수 없는 일이 남습니다. 마지막 한 자리에 두 요청이 동시에 들어왔습니다.

누구를 먼저 접수할지, 다른 사람을 대기자로 받을지 정해야 합니다. 취소가 생기면 자리를 다시 열지 대기자에게 먼저 안내할지도 정해야 합니다. 같은 연락처가 두 번 들어온 경우에는 중복인지 가족 대리 신청인지 확인해야 합니다.

이런 기준을 ‘업무 규칙’이라고 합니다. AI는 가능한 규칙과 영향을 비교할 수 있지만 행사의 운영 방침을 알고 있는 것은 아닙니다. ‘미결정 규칙을 찾아 선택지와 영향을 설명하고, 확인할 질문으로 남겨 줘’라고 요청하세요.

처음부터 모든 예외를 모으기보다 내 일에 중요한 두 가지를 고릅니다. 규칙을 다르게 정했을 때 기능이나 사용자가 받는 결과가 어떻게 달라지는지 설명해 보세요.

05 · 처리 방법 고르기

기능을 미뤄도 그 일은 남는다

첫 버전에서는 취소 화면을 만들지 않고 담당자가 연락을 받아 처리하기로 했습니다.

화면을 제외하는 선택은 가능합니다. 다만 취소 연락 방법, 처리할 사람, 목록과 인원을 바꾸는 절차는 남아야 합니다. 담당자가 감당할 처리량과 반영 지연도 확인해야 합니다. 기능을 줄였는데 사용자의 일이 끊기거나 담당자가 처리할 수 없다면 범위를 다시 봐야 합니다.

다른 서비스 연결도 같은 방식으로 결정합니다. 하루 몇 건을 한 사람이 확인한다면 직접 처리할 수 있습니다. 여러 사람이 자주 함께 수정한다면 최신 상태를 공유할 방법이 필요할 수 있습니다. 도구 이름보다 실제 조건을 먼저 적습니다.

문자를 자동으로 보내기로 했다면 접수와 발송은 따로 봅니다. 접수는 됐지만 발송이 실패한 경우 접수를 또 만들면 중복됩니다. 접수 기록을 유지하고 발송 상태를 확인한 뒤 필요한 단계만 다시 처리하도록 정합니다.

06 · 변경 영향 살피기

날짜 변경은 화면의 날짜만 바꾸는 일이 아니다

신청자가 토요일에서 일요일로 참가 날짜를 바꾸려고 합니다. 무엇까지 함께 바뀌어야 할까요?

성공하면 토요일의 자리가 비워지고 일요일 인원에 반영되어야 합니다. 신청 내역과 담당자 목록에도 같은 날짜가 보여야 합니다. 일요일이 마감됐다면 기존 토요일 신청은 유지하고, 변경하지 못한 이유와 다음 선택을 알려줘야 합니다.

AI에게 ‘성공 후 함께 맞아야 할 정보와 실패 후 유지할 정보를 찾아 줘’라고 요청하면 변경의 영향을 검토할 수 있습니다. 실행 검증이 통과한 뒤에도 다른 사람에게 날짜 변경을 맡겨 보세요. 완료됐다는 뜻을 이해하는지 관찰하면 화면 안내와 실제 처리의 어긋남을 찾을 수 있습니다.

07 · 내 일에 적용

같은 순서로 내 프로젝트를 보완하기

앞의 사례를 이해했다면 본인이 반복하는 일 하나에 적용합니다. 기존 문서가 있으면 보완하고, 없으면 아래 기본형에서 시작하세요.

먼저 사용자가 시작해서 결과를 확인하기까지 하는 행동을 적습니다. 각 행동 옆에 필요한 기능과 사람이 처리할 일을 씁니다. 다음으로 중요한 예외 두 가지의 규칙을 정하고, 확인되지 않은 내용은 담당자에게 물을 질문으로 남깁니다.

AI가 제안한 기능 하나를 골라 해결하려는 문제, 근거, 다른 방법을 비교합니다. 처리 방법과 실패 후 행동을 정한 뒤 동료에게 보여줍니다. ‘이 규칙을 바꾸면 무엇도 바뀌나요?’라는 질문에 답해 보면 설계가 얼마나 구체적인지 알 수 있습니다.