39장. 실제 사용자처럼 전체 흐름 점검하기

기능이 다 되는데도, 서비스는 이상할 수 있다

지금까지 우리는 회원가입도 붙였고, 로그인도 만들었고, 글 작성과 수정, 삭제, 검색까지 하나씩 구현해 왔다. 그러다 보면 어느 순간 이런 생각이 든다.

"이제 다 된 것 같은데?"

실제로 초보자가 가장 많이 하는 확인 방식은 기능별 확인이다. 회원가입 버튼 눌러 보기, 로그인 한 번 해 보기, 글 하나 써 보기, 검색창에 단어 넣어 보기. 이 확인은 물론 필요하다. 다만 여기에는 큰 함정이 있다. 각 기능이 따로는 되는데, 실제 사용 흐름으로 이어지면 어딘가 삐걱거리는 경우가 아주 많다는 점이다.

예를 들어 회원가입은 된다. 로그인도 된다. 글 작성도 된다. 그런데 회원가입 직후 자동으로 로그인되지 않아 사용자가 길을 잃을 수 있다. 글 작성도 저장은 되지만 저장 후 목록으로 돌아갔을 때 방금 쓴 글이 안 보일 수도 있다. 검색도 동작은 하지만, 막 작성한 글은 검색 결과에 빠질 수도 있다.

이런 문제는 기능 하나만 눌러 봐서는 잘 안 보인다. 실제 사용자처럼 처음부터 끝까지 한 번 걸어 봐야 드러난다. 마치 집 안의 전등, 수도, 문은 각각 멀쩡한데 막상 하루 살아 보니 동선이 불편한 것과 비슷하다. 부품 점검과 생활 점검은 다르다.

이번 장에서는 바로 그 생활 점검을 한다. 회원가입부터 로그인, 글 작성, 목록 확인, 상세 보기, 검색까지, 한 명의 사용자가 서비스를 실제로 쓰듯 따라가며 전체 흐름을 확인해 볼 것이다.

사용자 흐름 점검은 서비스의 '여행 테스트'다

기능 테스트가 물건 하나하나를 검사하는 일이라면, 사용자 흐름 점검은 여행 가방을 싸서 집을 나서고, 버스를 타고, 목적지에 도착하고, 다시 돌아오는 전 과정을 실제로 해 보는 일에 가깝다.

이 테스트가 중요한 이유는 사용자는 기능을 따로 쓰지 않기 때문이다. 사용자는 "API 호출 성공 여부"를 경험하지 않는다. 사용자는 "가입하고 들어가서 글 쓰고 찾아보는 경험"을 한다. 즉, 사용자는 언제나 흐름 단위로 서비스를 만난다.

그래서 이 장에서 여러분이 익혀야 할 감각은 간단하다.

기능이 되는지 묻는 데서 멈추지 말고, 사용자가 다음 행동으로 자연스럽게 넘어갈 수 있는지를 보라는 것이다.

서비스 점검에서 정말 자주 발견되는 문제는 대개 이런 종류다.

• 이전 화면에서는 성공했는데 다음 화면으로 연결이 어색한 경우

• 데이터는 저장됐는데 사용자 눈에는 반영되지 않는 경우

• 로그인 상태가 이어지지 않아 중간에 다시 막히는 경우

• 검색이나 목록 정렬이 방금 만든 데이터와 어긋나는 경우

• 에러는 아니지만 사용자가 무엇을 해야 할지 헷갈리는 경우

이 다섯 가지는 각각 작은 문제처럼 보여도, 실제 사용자 입장에서는 "이 서비스 뭔가 불안하다"라는 감각으로 합쳐진다.

먼저 한 명의 가상 사용자를 정하자

전체 흐름을 점검할 때는 머릿속에 사용자를 한 명 세워 두는 편이 좋다. 이름이 있으면 더 쉽다. 예를 들어 이런 사람을 상상해 보자.

"민지는 처음 방문한 사용자다. 서비스를 처음 보고 회원가입을 한다. 로그인에 성공한 뒤 첫 글을 쓴다. 자신이 쓴 글이 목록에 보이는지 확인한다. 상세 페이지로 들어가 내용을 다시 본다. 나중에 검색창에서 방금 쓴 글을 검색해 찾는다."

이렇게 한 사람의 행동으로 흐름을 만들면 점검이 훨씬 현실적이 된다. 단순히 버튼을 누르는 것이 아니라, 사용자의 의도와 기대를 함께 떠올릴 수 있기 때문이다.

민지는 회원가입 후 어디로 가길 기대할까? 글 저장 후 무엇을 보고 싶어 할까? 검색 결과가 없으면 어떤 기분일까? 이런 질문이 붙는 순간 테스트는 단순 확인이 아니라 사용자 경험 점검이 된다.

점검 전에 준비해야 할 것들

실제 흐름 점검은 준비를 조금만 해 두면 훨씬 정확해진다. 아무 상태에서나 마구 눌러 보면 오히려 무엇이 정상이고 무엇이 이상한지 헷갈릴 수 있다.

가장 먼저 할 일은 깨끗한 출발점을 만드는 것이다. 로그아웃 상태에서 시작할 것인지, 새 계정을 만들 것인지, 기존 테스트 데이터는 남겨 둘 것인지 정해 두자. 브라우저에 예전 로그인 정보가 남아 있으면 처음 방문자 흐름을 제대로 볼 수 없다.

그다음에는 이번 점검의 목표를 짧게 써 두면 좋다. 예를 들면 이런 식이다.

• 새 사용자가 가입부터 첫 글 작성까지 막힘 없이 끝낼 수 있는가

• 작성한 글이 목록과 상세에 올바르게 반영되는가

• 검색으로 방금 작성한 글을 다시 찾을 수 있는가

이렇게 목표를 적어 두면, 중간에 자잘한 디자인 수정을 하느라 본래 목적을 잊어버리는 일을 줄일 수 있다.

그리고 가능하다면 점검 결과를 메모할 간단한 표도 만들어 두자. 꼭 거창할 필요는 없다. "단계", "기대한 결과", "실제 결과", "수정 필요" 정도만 있어도 충분하다. 이 습관은 다음 장의 버그 수정 단계에서 엄청난 힘을 발휘한다.

시나리오 1: 첫 방문자는 길을 잃지 않는가

이제 진짜로 사용자가 되어 보자. 브라우저를 열고 서비스 첫 화면에 들어간다. 이때 첫 질문은 아주 단순하다.

"처음 온 사람이 이 서비스에서 무엇을 할 수 있는지 바로 알 수 있는가?"

초보자는 기능이 동작하는지에 집중하느라 첫 화면의 안내를 자주 놓친다. 하지만 사용자는 첫 화면에서 방향을 잡는다. 서비스 이름이 보이는지, 주요 행동 버튼이 눈에 띄는지, 로그인하지 않은 상태에서 어디로 가야 하는지가 분명한지 확인해 보자.

회원가입 버튼을 눌렀을 때도 그냥 페이지가 열리면 끝이 아니다. 제목과 입력칸이 헷갈리지 않는지, 이메일과 비밀번호 입력 흐름이 자연스러운지, 제출 버튼이 눈에 잘 들어오는지 살펴봐야 한다. 이미 38장에서 로딩과 실패 처리를 배웠다면, 여기서는 그것이 실제 흐름 안에서 자연스럽게 작동하는지를 보는 것이다.

회원가입을 마친 뒤에는 더 중요하다. 가입 성공 후 사용자가 어디로 이동하는가? 자동 로그인되는가, 아니면 로그인 페이지로 보내는가? 성공 메시지가 뜨는가? 아무 설명 없이 같은 화면에 멈춰 있지는 않은가?

여기서 많은 문제가 잡힌다. 회원가입 자체는 성공했는데 사용자는 성공했는지 모를 수 있다. 계정은 만들어졌지만 화면이 바뀌지 않아 같은 정보를 한 번 더 제출할 수도 있다. 또는 가입 후 홈으로 돌아갔는데 여전히 로그아웃 상태처럼 보일 수도 있다.

즉, 첫 방문자 점검은 단순히 "가입 성공"을 보는 것이 아니라, 가입 직후 사용자가 다음 행동을 이해할 수 있는지를 확인하는 단계다.

시나리오 2: 로그인은 단순 통과 의식이 아니다

이제 민지가 로그인한다고 생각해 보자. 이메일과 비밀번호를 넣고 로그인 버튼을 누른다. 이때는 로그인 성공 여부만 보지 말고 그 뒤의 연결을 봐야 한다.

로그인 후 상단 메뉴나 버튼이 바뀌는가? 예를 들어 로그인 전에는 "로그인 / 회원가입"이 보였는데 로그인 후에는 "내 글 쓰기 / 로그아웃"처럼 바뀌어야 할 수 있다. 사용자 이름이나 이메일 일부가 표시되면 더 좋다. 이런 변화는 "내가 지금 로그인된 상태구나"라는 확신을 준다.

또 로그인한 사용자만 볼 수 있는 페이지로 이동했을 때 권한이 제대로 반영되는지도 중요하다. 글 작성 페이지에 들어갈 수 있는지, 로그아웃 상태였다면 막히던 기능이 지금은 열리는지 확인해 보자.

반대로 로그인 후 브라우저를 새로고침했을 때 상태가 유지되는지도 살펴봐야 한다. 로그인은 성공했는데 새로고침하자마자 풀려 버리면 실제 서비스에서는 상당히 불편하다. 이 문제는 버튼 한 번 눌러 보는 테스트로는 놓치기 쉽고, 흐름 점검에서는 꽤 잘 드러난다.

시나리오 3: 첫 글 작성은 가장 중요한 분기점이다

이제 사용자가 서비스 안에서 실제 가치를 만드는 순간으로 들어가 보자. 바로 글 작성이다.

민지가 "글 작성" 버튼을 누른다. 글 작성 페이지는 열리는가? 제목과 내용 입력칸이 분명한가? 저장 버튼을 눌렀을 때 저장 중 상태가 보여지는가? 저장이 끝난 뒤에는 어디로 가는가?

이 흐름은 겉보기보다 훨씬 많은 걸 점검한다. 인증 상태, 폼 입력, 서버 요청, 데이터 저장, 저장 후 이동, 목록 갱신까지 한 번에 이어지기 때문이다.

특히 저장 직후를 유심히 보자. 초보 프로젝트에서 가장 흔한 문제 중 하나는 "저장은 됐는데 사용자는 저장된 걸 체감하지 못하는 상황"이다. 예를 들어 이런 경우가 있다.

• 저장은 성공했는데 여전히 작성 페이지에 남아 있어서 성공 여부를 알기 어려운 경우

• 상세 페이지로 이동했지만 방금 입력한 내용이 일부 비어 있는 경우

• 목록 페이지로 돌아왔는데 최신 글이 바로 보이지 않는 경우

• 저장 후 중복 클릭 때문에 글이 두 번 생성된 경우

이 문제들은 각각 따로 보면 작아 보이지만, 실제 사용자에게는 꽤 큰 불신을 만든다. "내가 잘못한 건가?", "다시 눌러야 하나?", "글이 날아간 건가?" 같은 불안이 생기기 때문이다.

그래서 글 작성 흐름을 점검할 때는 꼭 이렇게 물어보자.

"저장되었다는 사실이 사용자에게 분명하게 전달되는가?"

이 질문은 단순하지만 아주 강력하다.

목록 화면은 방금 일어난 일을 잘 반영하는가

글 작성이 끝났다면, 이제 사용자는 보통 목록으로 돌아가거나 홈으로 이동해 방금 쓴 글을 다시 보게 된다. 이 순간은 서비스가 살아 있는지 확인하는 장면이다.

목록에서 먼저 볼 것은 단순히 글이 있는지가 아니다. 방금 작성한 글이 기대한 위치에 보이는지를 봐야 한다. 최신순이라면 맨 위에 보이는가? 제목은 제대로 나오나? 작성자 정보는 맞는가? 내용 일부 미리보기가 깨지지는 않았나?

이때 의외로 자주 발견되는 문제가 있다. 데이터베이스에는 들어갔지만 목록을 가져오는 기준과 맞지 않아 안 보이는 경우다. 예를 들어 공개 글만 보여주는 목록인데 새 글이 비공개로 저장됐거나, 정렬 기준이 달라 예상한 위치에 나타나지 않을 수 있다. 검색 기능도 비슷하다. 저장은 됐는데 목록과 검색이 다른 기준으로 움직이면 사용자는 "글이 사라졌다"고 느낄 수 있다.

여기서 여러분은 중요한 감각을 얻게 된다. 서비스는 기능 하나의 성공으로 완성되지 않는다. 한 기능의 결과가 다음 화면에 자연스럽게 이어져야 비로소 완성에 가까워진다.

상세 페이지는 '보인다'를 넘어 '믿을 수 있다'까지 가야 한다

목록에서 방금 작성한 글을 눌러 상세 페이지로 들어가 보자. 상세 페이지에서는 다음을 확인하면 좋다.

제목이 정확히 보이는지, 본문 줄바꿈이 이상하지 않은지, 작성 시간이 말이 되는지, 작성자 정보가 맞는지, 수정이나 삭제 버튼이 권한에 맞게 보이는지 살펴본다.

이 단계는 단순히 정보 표시만 확인하는 곳이 아니다. 사용자가 "아, 내가 방금 만든 결과물이 제대로 남았구나"라고 느끼는 자리다. 그래서 작은 어긋남도 생각보다 크게 느껴진다. 목록에서는 제목이 보였는데 상세 페이지에 본문이 비어 있다면 사용자는 저장을 불신하게 된다.

가능하다면 브라우저를 새로고침해 보는 것도 좋다. 새로고침 후에도 글이 그대로 보이는지 확인하면, 클라이언트 상태에만 의존하는 문제를 잡는 데 도움이 된다. 화면에 잠깐 보였다가 새로고침하니 사라진다면, 실제 저장이 아니라 화면에만 임시 반영되었을 가능성도 있다.

시나리오 4: 검색은 마지막 확인이 아니라 진짜 사용 행동이다

이제 검색으로 넘어가 보자. 많은 초보자가 검색을 "있으면 좋은 기능" 정도로 생각하지만, 실제로 검색은 데이터 흐름과 화면 반영이 맞물리는 훌륭한 점검 도구다.

민지는 방금 쓴 글 제목의 일부를 검색창에 입력한다. 이때 확인할 것은 의외로 많다. 입력 즉시 반응하는지, 검색 버튼을 눌러야 하는지, 결과가 너무 늦지 않은지, 검색 결과에 방금 작성한 글이 포함되는지, 검색어를 지우면 전체 목록으로 자연스럽게 돌아오는지 봐야 한다.

검색은 특히 방금 만든 데이터가 다른 기능과 같은 세계를 보고 있는지 확인해 준다. 글 작성은 성공했는데 검색에서는 안 나온다면, 둘이 같은 데이터를 같은 규칙으로 다루지 않는다는 뜻일 수 있다. 이건 기능별 테스트만으로는 놓치기 쉬운 문제다.

검색 결과가 0개일 때의 경험도 함께 보자. 여기서도 중요한 것은 단지 빈 화면 여부가 아니다. 사용자가 "검색이 실패한 건가, 결과가 없는 건가"를 구분할 수 있어야 한다. 그리고 검색어를 바꾸거나 초기화할 길이 보여야 한다.

즉, 검색 점검은 기능 하나를 보는 일이 아니라, 서비스 전체의 데이터 일관성을 점검하는 일이기도 하다.

기능별 점검과 흐름 점검은 무엇이 다를까

둘의 차이를 아주 짧게 정리하면 이렇다.

기능별 점검은 "이 버튼이 동작하는가"를 본다. 흐름 점검은 "이 버튼을 누른 뒤 사용자가 다음 단계로 자연스럽게 갈 수 있는가"를 본다.

예를 들어 기능별 점검에서는 회원가입 성공, 로그인 성공, 글 작성 성공, 검색 성공이 각각 따로 기록될 수 있다. 하지만 흐름 점검에서는 이런 질문이 추가된다.

• 회원가입 직후 사용자는 어디로 가는가

• 로그인한 뒤 화면은 그 사실을 어떻게 보여 주는가

• 글 저장 후 사용자는 무엇을 보게 되는가

• 방금 만든 글을 다시 찾는 과정이 자연스러운가

• 중간에 길을 잃거나 불안해지는 순간은 없는가

이 차이가 중요하다. 서비스는 결국 이어진 경험이기 때문이다. 퍼즐 조각이 모두 예쁘다고 해서 그림이 완성되는 것은 아니다.

흐름 점검 중에는 '개발자 눈'을 잠깐 내려놓자

전체 흐름을 점검할 때 가장 어려운 점은, 내가 이미 내부 구조를 너무 잘 안다는 것이다. 어느 버튼을 눌러야 하는지, 어느 페이지로 가야 하는지, 어떤 에러가 왜 났는지 개발자는 어느 정도 짐작한다. 하지만 실제 사용자는 그렇지 않다.

그래서 일부러라도 모르는 척해 보는 태도가 필요하다. 첫 화면만 보고도 행동을 정할 수 있는지, 문구만 읽고도 다음 단계를 이해할 수 있는지, 성공했는지 실패했는지 화면만 보고 알 수 있는지 살펴보자.

가능하다면 친구나 동료에게 5분만 써 보게 하는 것도 큰 도움이 된다. 개발자는 전혀 이상하다고 느끼지 못한 부분에서 다른 사람은 바로 멈출 수 있다. 버튼 문구가 애매하다거나, 저장 후 어디로 가야 할지 모르겠다거나, 검색창이 눈에 띄지 않는다는 식이다.

이런 반응은 코드보다 더 값진 힌트를 준다. 왜냐하면 서비스는 결국 사람이 쓰는 것이기 때문이다.

한 번의 흐름 점검으로 끝내지 말자

실제 서비스 점검은 한 번 하고 끝나는 의식이 아니다. 수정하면 다시 걷고, 다시 걷다가 또 고치고, 다시 확인하는 반복에 가깝다.

특히 다음 같은 변화가 생겼을 때는 핵심 흐름을 다시 한 번 점검하는 것이 좋다.

• 로그인 방식이나 권한 처리를 수정했을 때

• 글 작성 폼이나 저장 로직을 바꿨을 때

• 목록 정렬이나 검색 조건을 건드렸을 때

• 배포 환경이나 데이터베이스 설정을 바꿨을 때

이런 수정은 겉보기에는 일부 기능만 바꾼 것 같아도, 실제로는 전체 흐름에 영향을 줄 수 있다. 예를 들어 검색 조건 하나 바꿨을 뿐인데 방금 작성한 글이 검색에서 빠질 수도 있고, 로그인 처리 방식을 바꿨더니 저장 직후 권한 체크에 걸릴 수도 있다.

그래서 핵심 사용자 흐름 하나쯤은 늘 다시 걸어 볼 준비가 되어 있어야 한다. 여러분 서비스의 기본 산책로 같은 것이다.

흐름 점검 기록은 버그 수정의 지도다

점검하면서 발견한 문제를 머릿속에만 두면 금방 섞인다. 그래서 간단하게라도 기록해 두는 것이 좋다.

좋은 기록은 길지 않아도 된다. 예를 들어 이런 식이면 충분하다.

"회원가입 성공 후 같은 화면에 머무름. 성공 여부를 알기 어려움."

"글 저장은 되지만 목록으로 돌아왔을 때 최신 글이 바로 안 보임. 새로고침하면 보임."

"검색어 입력 후 결과 없음 메시지는 뜨지만 검색 초기화 버튼이 없음."

이런 기록의 장점은 두 가지다. 첫째, 수정 우선순위를 정하기 쉬워진다. 둘째, AI에게도 훨씬 정확하게 요청할 수 있다. 막연히 "뭔가 이상해요"라고 말하는 대신, 어느 흐름의 어느 순간이 어색한지 바로 전달할 수 있기 때문이다.

AI에게는 '장면 단위'로 설명하자

이 장의 핵심은 AI와 협업할 때도 그대로 통한다. 전체 흐름 점검에서 발견한 문제를 AI에게 맡길 때는 기능 이름만 말하지 말고, 사용자 장면으로 설명하는 것이 훨씬 좋다.

예를 들어 이렇게 말할 수 있다.

"로그아웃 상태에서 회원가입을 완료하면 계정은 생성되지만 화면 변화가 없어 사용자가 성공 여부를 알기 어렵습니다. 가입 성공 후 로그인 페이지로 이동하고 상단에 성공 메시지를 보여 주도록 수정해 주세요."

또는 이렇게 말할 수도 있다.

"로그인 후 글 작성은 성공하지만 목록 페이지에서 방금 작성한 글이 바로 보이지 않습니다. 새로고침하면 보입니다. 저장 후 목록 재조회 또는 캐시 갱신 흐름을 점검해 주세요."

이런 요청은 아주 강하다. 왜냐하면 개발자 관점의 추상적인 문제가 아니라, 사용자 경험 안에서 벌어지는 구체적인 장면을 전달하기 때문이다.

우리 서비스에서 꼭 걸어봐야 할 핵심 산책로

이 책에서 만드는 작은 풀스택 웹 서비스라면, 최소한 다음 흐름은 직접 걸어봐야 한다.

• 로그아웃 상태로 접속한다.

• 회원가입을 완료한다.

• 로그인한다.

• 글 작성 페이지로 이동한다.

• 글을 작성하고 저장한다.

• 목록에서 방금 쓴 글을 확인한다.

• 상세 페이지에서 내용을 다시 확인한다.

• 검색으로 그 글을 찾아본다.

• 가능하다면 수정 또는 삭제까지 이어서 확인한다.

이 순서는 단순한 체크리스트가 아니다. 여러분 서비스의 뼈대를 통과하는 길이다. 이 길이 매끄러우면 서비스는 훨씬 안정적으로 느껴진다. 반대로 이 길 어딘가가 자꾸 끊기면, 사용자는 다른 기능을 만나기도 전에 떠날 수 있다.

실제 사용자처럼 본다는 것은 결국 신뢰를 보는 일이다

이 장에서 우리가 확인한 것은 단순히 "되나 안 되나"가 아니다. 사용자가 서비스를 믿을 수 있는지를 본 것이다.

회원가입 후 성공했는지 알 수 있는가. 로그인 후 내가 들어와 있다는 확신이 드는가. 글을 저장했을 때 정말 남았다는 느낌을 받는가. 방금 만든 글을 목록과 검색에서 다시 찾을 수 있는가. 이런 경험이 쌓여야 사용자는 서비스에 마음을 놓는다.

초보자가 만든 첫 서비스가 여기까지 오면 이미 대단한 단계다. 화면 하나를 띄우는 수준을 넘어, 실제 사용자의 여정을 생각하기 시작했기 때문이다. 바로 이 지점에서 여러분은 "기능을 만든 사람"에서 "서비스를 만드는 사람"으로 넘어간다.

이 장의 핵심 정리

기능별 확인은 필요하지만, 그것만으로는 실제 서비스 품질을 보장할 수 없다. 사용자는 기능을 따로 쓰지 않고, 회원가입부터 로그인, 글 작성, 목록 확인, 검색까지 이어진 흐름으로 서비스를 경험한다.

그래서 전체 흐름 점검은 반드시 필요하다. 이 점검은 가입 직후의 이동, 로그인 상태 유지, 저장 후 반영, 목록과 상세의 일관성, 검색 결과 연결처럼 기능 사이의 틈에서 생기는 문제를 잘 잡아낸다.

기억하자. 작은 기능의 성공보다 더 중요한 것은, 사용자가 처음 들어와 원하는 일을 끝까지 마칠 수 있는지다. 서비스는 버튼이 아니라 여정으로 평가된다.