프론트엔드 설계
구현 전에 화면의 요구사항 정리하기
설계는 사용자의 목표와 실패 조건을 먼저 구분하는 데서 시작합니다.
이럴 때 필요해요
도구 이름보다 어떤 경험을 보장해야 하는지 먼저 적습니다.
어떻게 동작하나요?
예매 버튼을 만든다는 요구만으로는 충분하지 않습니다. 언제 누를 수 있고, 요청 중에는 어떻게 보이며, 실패하면 무엇을 할 수 있는지 정해야 합니다.
정상·로딩·오류처럼 화면이 가질 상태를 적고 어떤 사건으로 바뀌는지 확인합니다. 아래 배열은 화면 상태를 나열한 설명용 데이터이며 실제 상태 머신을 구현하지 않습니다.
버튼을 한 번만 누르게 하는 일과 서버 중복 처리를 막는 일은 책임이 다릅니다. 화면과 서버가 각각 무엇을 보장하는지 적어 두면 이후 API·보안·결제 상황을 판단하기 쉽습니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
const screens = ["선택 전", "요청 중", "확인 완료", "결과 확인 필요"];
console.log(screens[1]); // 요청 중상태 이름을 기록한 예제이며 전환이나 서버 보장을 자동 구현하지 않습니다.
자주 헷갈리는 포인트
- 기술 선택만 나열하고 사용자 요구사항을 생략하지 않습니다.
- UI 잠금과 서버의 중복 처리 보장을 혼동하지 않습니다.
내 말로 설명해 보기
응답이 늦을 때 보여줄 화면도 설계에 포함될까요?
생각할 단서 예제의 값을 하나 바꿔 보고, 바뀌는 부분과 그대로인 부분을 구분해 보세요.
예시 답변 확인
설명에 들어갈 핵심
- 설계는 사용자의 목표와 실패 조건을 먼저 구분하는 데서 시작합니다.
- 상태 이름을 기록한 예제이며 전환이나 서버 보장을 자동 구현하지 않습니다.
예시 답변
네. 요청 중 안내, 재클릭 허용 여부와 결과를 모를 때의 확인 경로까지 요구사항으로 정리합니다.
문장을 그대로 외우기보다 예제의 값과 실행 흐름을 떠올리며 설명해 보세요.