설계 판단과 면접 설명

선택의 이유를 실패 사례와 함께 설명합니다

면접에서 프레임워크 이름을 말하는 것만으로 행사 검색 사이트를 이해했다고 판단하기 어렵습니다. 어떤 사용자 문제를 해결했고, 어느 코드가 책임지며, 잘못 구현했을 때 무엇이 깨지고, 이를 어떻게 확인했는지 설명해야 합니다. 이번 레슨은 트랙의 여섯 질문에 코드 위치·판단·실패 사례·대안의 비용·검증을 연결해 DECISIONS.md를 완성합니다.

설명은 문제에서 시작합니다. “request-session을 만들었습니다”보다 “이전 검색이 늦게 도착해 최신 결과를 덮는 문제를 막았습니다”가 이유를 드러냅니다. 이어 선택한 경계를 말하고 실제 함수 위치와 검사 이름을 연결합니다. 한 문장에 모든 구현 세부를 넣지 않습니다. 듣는 사람이 원하면 해당 코드와 반례를 열어 확인할 수 있도록 파일 이름과 함수 이름을 정확히 적습니다.

첫 질문은 시맨틱 HTML을 선택한 이유입니다. results.html의 검색 폼과 레이블, 목록·상세의 문서 구조를 보여 줍니다. 요소 이름을 외워 나열하는 대신 검색 입력이 어떤 이름으로 인식되고 키보드 사용자가 어떤 동작을 할 수 있는지 설명합니다. div에 click만 연결한 대안은 추가 키보드 처리와 의미 제공이 필요하므로 native 폼·링크 사용의 비용 차이를 사용자 흐름과 연결합니다.

두 번째 질문은 좁은 화면 문제의 확인 방법입니다. assets/site.css에서 실제 줄바꿈과 레이아웃 규칙을 찾아 긴 연속 제목을 넣은 이유를 말합니다. 화면 너비만 줄이고 짧은 제목으로 검사하면 콘텐츠 경계 문제를 놓칠 수 있습니다. 320·390·1280px 검사와 확대 관찰의 범위를 나누고 overflow를 숨기는 수정이 정보를 잘라 버릴 위험도 설명합니다. 미실행 폭은 결과로 쓰지 않습니다.

세 번째 질문은 키보드만으로 폼을 사용하는 흐름입니다. Tab·Enter 순서, 검색 제출, 카드 상세 진입, 복귀 후 초점 위치를 행동으로 말합니다. assets/results.mjs의 포커스 이동 위치와 접근성 테스트를 연결합니다. 키 이벤트를 많이 등록하는 것이 목표가 아닙니다. native 동작을 보존하고 화면 전환에서 추가 책임이 필요한 지점을 설명해야 의미와 실제 사용을 함께 보여 줄 수 있습니다.

네 번째 질문은 검색 요청의 역전입니다. A 검색을 시작하고 B 검색을 시작했는데 A가 늦게 끝나는 반례를 설명합니다. 취소 요청만으로 이미 완료된 후속 처리를 모두 막는다고 단정하지 않고 세대 검사가 최신 요청만 발행하는 이유를 말합니다. request-session.mjs와 order-test.cjs를 열어 취소·늦은 성공·종료 뒤 발행 폐기의 계약을 찾습니다. 동기 검색과 비동기 응답의 책임도 구분합니다.

다섯 번째 질문은 로딩·오류·빈 결과를 나눈 이유입니다. loading은 기다리는 중이고 empty는 정상 응답이지만 결과가 없으며 error는 요청이나 응답 처리 실패입니다. 사용자의 다음 행동이 기다리기·조건 바꾸기·재시도로 달라집니다. api.mjs의 상태 발행과 StatusPanel의 문구를 연결하고 잘못된 레코드를 빈 배열로 바꿨을 때 사용자가 장애를 놓치는 반례를 설명합니다.

여섯 번째 질문은 상태 위치를 정한 사례입니다. 검색 조건·선택 id·요청 상태의 소유자를 results.mjs와 request-session.mjs에서 확인합니다. 컴포넌트가 각자 검색어를 저장하면 URL·폼·결과가 따로 바뀔 수 있습니다. EventCard는 주어진 데이터를 표시하고 SearchForm은 조건을 읽어 상위로 전달합니다. 상위 상태 변경에서 화면까지의 한 경로를 추적해 중복 상태를 줄인 이유를 설명합니다.

파일 위치가 존재한다고 해당 주장이 검증된 것은 아닙니다. 선택한 함수의 입력과 출력, 실패를 방지하는 조건문, 그 조건을 겨냥한 테스트를 함께 읽습니다. 줄 번호는 편집 후 바뀔 수 있으므로 파일·함수·검사 이름을 기본 식별자로 씁니다. 설명에 “최신 요청은 항상 정상”처럼 검사가 보장하지 않는 단정을 넣지 않습니다. 네트워크 실패와 오래된 결과 폐기는 서로 다른 결과입니다.

대안은 채택하지 않은 이유까지 말합니다. 모든 응답을 표시하는 대안은 단순하지만 역전 위험이 있고, API 오류를 조용히 빈 목록으로 바꾸는 대안은 구현이 짧지만 장애를 숨깁니다. 중앙 상태는 일관성을 주지만 책임이 커지므로 컴포넌트 계약으로 경계를 분리합니다. 실제 프로젝트의 조건에 맞춰 비교하며 다른 팀과 모든 제품에도 같은 설계가 최선이라고 일반화하지 않습니다.

검증 결과를 말할 때 수행한 범위를 제한합니다. npm test가 통과했다면 Node 계약과 회귀가 통과했다고 설명합니다. 실제 브라우저 검사와 수동 키보드 확인은 따로 수행해야 화면 연결을 주장할 수 있습니다. EVIDENCE.md의 PENDING 항목을 면접 설명에서 성공으로 바꾸지 않습니다. 남은 검증을 인정하고 재현 가능한 절차를 제시하는 것이 근거 없는 확신보다 검토에 도움이 됩니다.

성능 판단은 앞 모듈의 performance.json과 REVIEW.md를 참고합니다. 중앙값과 원자료·데이터 크기·측정 구간을 말하고 Node DOM 모델의 결과를 모바일 체감 속도로 바꾸지 않습니다. 동일 조건에서 개선되지 않았다면 이유와 다음 관찰을 씁니다. 이 레슨은 성능 설명을 다시 복사하는 과제가 아니라 상태·문서·출력 경계의 선택과 테스트 연결을 자신이 이해하는지 확인하는 과제입니다.

AI를 사용했다면 제공 권한이 있는 fixture만 입력하고 제안을 검증한 방법을 설명합니다. 생성 코드가 사용하는 API가 실제 있는지 확인하고 정상·경계·실패 테스트로 검토합니다. “AI가 맞다고 했다”는 근거 대신 어떤 제안을 채택했고 어떤 제안을 기각했는지 씁니다. 미실행 브라우저 검사를 통과로 요약한 제안은 기각합니다. 핵심 상태 전이는 도움 없이도 직접 추적할 수 있어야 합니다.

설명 연습은 90초 안팎의 초안으로 시작합니다. 사용자 문제, 코드 선택, 실패 반례, 검사 결과와 제한 순서로 말하고 상대가 다음에 무엇을 질문할지 적습니다. 반례를 손으로 추적할 때 A·B 요청의 시작과 완료 순서를 표로 써 봅니다. 암기한 문장을 읽기보다 왜 조건을 제거하면 테스트가 실패하는지 설명하면 코드의 책임을 이해했는지 확인하기 쉽습니다.

동료 검토에서는 코드 파일을 닫고 설명을 먼저 들려줍니다. 동료가 어느 행동을 재현해야 하는지 말할 수 없으면 문제와 실패 사례가 추상적입니다. “안전하게 만들었다”는 문장을 “일반 h2의 textContent로 제목을 넣고 중복 id 응답은 오류로 처리한다”로 좁힙니다. 보안 전체 보장처럼 범위를 넓힌 문장은 해당하지 않는 URL·권한·실제 날짜 검증의 제한도 함께 적습니다.

DECISIONS.md의 여섯 항목을 채우고 EVIDENCE.md와 테스트 로그로 연결하면 제출 설명을 검토할 수 있습니다. 샘플의 대안과 브라우저 결과는 사람이 검토하고 실제 관찰로 완성해야 합니다. 문서 구조 검사 통과는 설명의 설득력이나 사실성을 자동 보장하지 않습니다. 최종 미션에서는 다른 사람이 실행부터 다섯 흐름·여섯 판단까지 따라갈 수 있도록 자료의 경로와 대상 버전을 맞춥니다.