가입부터 프로필 수정까지

화면을 통과하는 것과 목적을 달성하는 것

QA가 가입 화면의 버튼을 눌러 보았다는 말만으로 회원 기능을 검증했다고 할 수는 없습니다. 가입 완료 안내는 나왔지만 실제 회원이 저장되지 않았다면 다음 로그인은 실패합니다. 반대로 저장은 되었는데 안내가 사라지면 사용자는 다시 가입을 시도할 수 있습니다. 신입에게 먼저 요구하는 것은 클릭 횟수가 아니라 사용자의 목적, 그 목적을 이루는 상태 변화, 상태를 확인할 증거를 연결하는 능력입니다.

이번 프로젝트의 사용자는 동아리 회원입니다. 방문자는 계정을 만들고, 회원은 로그인한 뒤 자기 닉네임을 수정하려 합니다. ‘가입부터 프로필 수정까지’라는 이름은 화면 세 장을 그리라는 뜻이 아닙니다. 처음에는 계정이 없고 마지막에는 자신의 변경된 정보가 재조회된다는 출발점과 도착점을 설명하라는 뜻입니다. 이 두 상태 사이에 어떤 조건이 필요한지 적으면 실패 지점도 함께 드러납니다.

이번 모듈에서 사용할 작업 공간

네 레슨은 문서를 작성하고 판단하는 실습입니다. 미션의 starter 압축을 풀고 그 폴더에서 작업합니다. 텍스트 편집기, Python 3, bash가 필요하며 네트워크와 실제 회원 계정은 사용하지 않습니다. 예시 이메일은 합성 주소인 new@example.test입니다. 레슨의 짧은 Python 예시는 코드 블록을 별도 파일에 저장하고 python3 파일명.py로 실행합니다. Python 자체를 배우는 과정은 뒤 모듈에서 다루므로 지금은 입력 문서와 출력 문장이 무엇을 뜻하는지 확인합니다.

산출물은 spec/flow.json, spec/requirements.json, spec/questions.json, spec/traceability.json입니다. JSON은 큰따옴표로 키와 글자를 감싸고 배열은 대괄호로 묶습니다. 마지막 항목 뒤에는 쉼표를 붙이지 않습니다. 파일은 UTF-8로 저장합니다. bash check.sh는 이 문서들의 형식과 연결을 확인합니다. 현재 starter는 보충할 부분이 있어 실패하도록 되어 있으며 레슨을 진행하며 채웁니다. 상세 필드는 압축 안 README.md에서 찾습니다.

역할을 세 층으로 나누어 적습니다

화면(ui)은 사용자가 입력하고 결과를 읽는 층입니다. API(api)는 화면이나 다른 클라이언트에서 보낸 요청을 받아 규칙에 따라 처리하는 접점입니다. 저장 상태(state)는 처리 뒤 다시 읽을 수 있는 회원과 세션의 상태입니다. 이 모듈에서는 DB 테이블이나 세션 저장 기술을 확정하지 않고 관찰할 결과만 씁니다. 예를 들어 ‘회원 수가 1 증가한다’는 저장 결과이고 ‘새 회원 목록에 이메일이 보인다’는 그 결과를 확인할 방법입니다.

행동	화면 관찰	API 관찰 계획	상태 관찰
가입	가입 완료와 로그인 화면	새 계정 생성 요청의 결과	회원 1명 증가
로그인	본인 프로필 진입	인증 요청과 본인 조회 결과	유효한 세션으로 조회 가능
닉네임 수정	새 닉네임 표시	본인 수정 요청의 결과	재조회 값 일치

API 성공 응답의 구체적인 코드와 주소는 아직 정하지 않았습니다. 문서에 임의로 200이나 특정 URL을 붙이면 개발 계약으로 오해될 수 있습니다. 지금은 ‘무슨 요청의 어떤 의미를 확인할 것인가’를 적고 세부 계약은 API 모듈에서 확인합니다. 관찰 위치를 구분하는 것은 구현을 지시하려는 일이 아니라 같은 현상을 서로 다른 근거로 확인할 준비입니다.

화살표에는 사전 조건이 있습니다

방문자→가입→로그인→본인 프로필→수정→재조회 순서로 기본 흐름을 씁니다. 가입에서 로그인으로 가는 화살표에는 ‘사용할 계정이 만들어졌다’는 조건이 필요합니다. 로그인에서 프로필 수정으로 가는 화살표에는 ‘유효한 세션과 본인 대상’이라는 조건이 필요합니다. 조건을 생략하면 이미 로그인된 계정으로만 검증하고 새 회원의 첫 로그인을 놓칠 수 있습니다. 각 칸에 행동을, 칸 사이에 다음 행동이 가능한 이유를 적습니다.

가입 성공을 곧바로 로그인 완료로 취급하는 실수도 자주 봅니다. 이번 교육용 합의 v1은 가입 후 로그인 화면으로 이동하는 규칙입니다. 회원이 저장되었다는 것과 인증된 세션이 생겼다는 것은 별개입니다. 다른 제품은 자동 로그인할 수 있지만 그 동작을 이 실습의 기대값으로 가져오지 않습니다. 흐름도의 사전 조건에 로그아웃 상태를 적으면 이 혼동을 줄일 수 있습니다.

실패 분기에서 남은 상태를 묻습니다

가입 단계의 빈 이메일과 중복 이메일은 입력 또는 정책 거절 분기입니다. 로그인 단계에는 틀린 비밀번호가 있습니다. 프로필 단계에는 타인 정보 수정 요청이 있습니다. 이 분기를 ‘에러’ 한 칸에 모으면 어느 단계에서 어떤 상태를 유지해야 하는지 알 수 없습니다. 가입 거절은 새 회원이 생기지 않아야 하고 로그인 거절은 인증된 세션이 생기지 않아야 합니다. 타인 수정 거절은 대상 회원의 닉네임을 바꾸지 않아야 합니다.

통신 중단은 정책 거절과도 다릅니다. 서버가 저장했지만 화면이 응답을 못 받았을 수 있습니다. 이 모듈에서 재시도 정책을 임의로 설계하지 말고 ‘성공 여부를 재조회할 수 있는가’라는 질문으로 남깁니다. 실패 화면이 보였다는 사실만으로 저장이 취소되었다고 단정하지 않습니다. 실패 위치와 남은 상태를 나란히 적는 습관은 뒤의 결함 재현과 데이터 검증에서도 그대로 필요합니다.

흐름도를 읽어 검토합니다

flow.json의 nodes에는 actor, action, precondition, success, failure, layers를 적습니다. edges는 앞 단계 ID와 다음 단계 ID의 쌍입니다. F-01이라는 이름은 단계 식별자이며 화면 주소가 아닙니다. 회원 A와 회원 B처럼 행위자와 대상을 나누면 본인 수정과 타인 수정의 차이를 설명하기 쉽습니다. arrows가 있다는 사실보다 그 사이의 조건과 거절 뒤 상태가 충분한지가 리뷰의 핵심입니다.

검사 결과에 ‘화살표 참조 오류’가 나오면 edges의 이름이 nodes의 id와 정확히 일치하는지 확인합니다. ‘사용자 목적 공백’은 goal이 빈 문자열이거나 스페이스뿐이라는 뜻입니다. 코드 오류를 고치듯 검사기를 수정하는 대신 해당 문서의 빠진 값을 보충합니다. 검사가 통과해도 실제 화면·API를 실행한 증거는 없습니다. 제출 설명에는 ‘흐름 문서 작성, 앱 실행 전’이라고 범위를 밝힙니다.

완성한 그림을 동료에게 보여 주고 ‘중복 가입을 했을 때 무엇이 남나요?’와 ‘A가 B를 수정하면 어디서 막히나요?’를 물어봅니다. 그림만 보고 행위자·사전 조건·거절 뒤 상태를 설명할 수 있으면 이번 목표에 도달한 것입니다. 설명하지 못하는 칸은 문장을 더 길게 쓰기보다 조건과 관찰 지점을 보충합니다. 시스템 전체를 보는 일반 원리는 더 읽기의 서재 장으로 이어서 읽습니다.

동아리 회원이 가입하고 로그인한 뒤 자신의 닉네임을 수정하여 재조회합니다.

{"id":"F-01","actor":"방문자","action":"가입","precondition":"같은 이메일이 없고 로그아웃 상태","success":"회원 1명 증가 후 로그인 화면","failure":"중복·빈 입력 안내와 회원 무변경","layers":["ui","api","state"]}

checks = [("ui", "가입 완료 안내가 보이는가?"), ("api", "가입 요청이 정책에 따라 처리되는가?"), ("state", "새 회원을 다시 조회할 수 있는가?")]
for layer, question in checks:
    print(layer + ": " + question)

ui: 가입 완료 안내가 보이는가?
api: 가입 요청이 정책에 따라 처리되는가?
state: 새 회원을 다시 조회할 수 있는가?