웹 개발의 발전과 현대적 아키텍처

예를 들어 1990년대의 회사 소개 페이지는 모든 방문자에게 같은 파일을 보내면 충분했습니다. 그러나 장바구니, 게시판, 인터넷 뱅킹처럼 사용자마다 다른 상태가 필요해지자 서버는 요청의 cookie와 session을 읽고 database 결과를 HTML에 끼워 넣어야 했습니다. 이때 화면은 여전히 완성된 문서였지만, 문서를 만드는 과정이 파일 복사에서 프로그램 실행으로 바뀌었습니다.

이 역사를 알면 정적 페이지와 동적 애플리케이션을 낡음과 새로움으로 나누지 않게 됩니다. 변경이 드문 도움말은 미리 만든 HTML이 더 빠르고 고장 지점도 적습니다. 반대로 실시간 재고나 개인 권한은 요청 시점의 계산이 필요합니다. 설계자는 페이지마다 누가 내용을 만들고, 언제 다시 만들며, 실패했을 때 어떤 오래된 결과까지 허용할지를 먼저 결정해야 합니다.

초기의 server application에서는 URL 처리, SQL, 업무 규칙과 HTML 조립이 한 요청 함수에 모이기 쉬웠습니다. 화면을 조금 바꾸려다 database query까지 건드리고, 모바일 앱을 추가하려면 같은 규칙을 다시 구현하는 문제가 반복됐습니다. Frontend와 backend의 분리는 이 변경 이유가 다른 코드를 API라는 검토 가능한 경계로 나누려는 시도였습니다.

온라인 주문을 예로 들면 frontend는 금액을 보기 좋게 표시하고 입력 오류를 빨리 알려줄 수 있지만 최종 할인과 재고 차감은 backend가 다시 판단해야 합니다. 브라우저의 값은 사용자가 바꿀 수 있기 때문입니다. 따라서 경계의 핵심은 어느 팀이 어느 언어를 쓰는지가 아니라, 신뢰할 수 없는 입력을 어디서 검증하고 어떤 상태 변경을 한 번만 허용하는지에 있습니다.

상품 카드 component가 `price: number`를 요구하는데 API adapter가 문자열을 넘기면 TypeScript는 두 경계가 합의하지 않았음을 build 전에 드러낼 수 있습니다. 그러나 서버가 실제로 `"무료"`를 보내도 개발자가 응답을 강제로 type assertion했다면 검사는 통과합니다. 정적 타입은 이미 알고 있는 계약의 연결을 검사할 뿐, network 밖의 사실을 관찰하지는 못합니다.

실무에서는 외부 입력을 runtime schema로 확인하고, 확인을 통과한 값을 domain type으로 바꾼 뒤 component에 전달합니다. Component test는 loading, empty, error와 정상 상태가 어떻게 보이는지 확인합니다. 이 세 층을 나누면 type error, 잘못된 외부 data, 화면 행동 오류를 서로 다른 위치에서 더 짧은 feedback으로 찾을 수 있습니다.

렌더링 전략은 페이지 이름이 아니라 사용자에게 언제 어떤 byte를 보낼지에 대한 결정입니다. 공개 문서라면 build 시 HTML을 만들고 CDN에서 오래 cache할 수 있습니다. 로그인 후 주문 내역은 요청마다 권한을 확인해야 하고, 필터를 빠르게 바꾸는 표는 초기 골격 뒤 browser에서 일부 data를 다시 가져오는 편이 자연스러울 수 있습니다.

혼합 전략에서는 cache key와 무효화가 가장 중요한 운영 계약이 됩니다. 사용자 A의 응답이 공유 cache에 들어가면 보안 사고가 되고, 상품 가격이 갱신됐는데 정적 page가 남아 있으면 업무 오류가 됩니다. 각 route에 개인화 여부, 갱신 허용 시간, JavaScript 없이 필요한 기능, 오류 시 보여줄 fallback을 적으면 framework 용어보다 먼저 올바른 경계를 고를 수 있습니다.

사용자가 결제 버튼을 누르면 browser의 event만 성공해서는 안 됩니다. DNS와 TLS를 거친 요청이 gateway에서 인증되고, API가 idempotency key를 확인하며, database transaction이 주문과 재고를 함께 갱신하고, 응답이 끊겨도 같은 주문 상태를 다시 조회할 수 있어야 합니다. 어느 한 계층의 200 응답만으로 전체 결과를 판정할 수 없는 이유입니다.

요청 지도를 만들 때는 component 이름보다 경계마다 남는 증거를 적습니다. Browser에는 사용자에게 보인 결과, gateway에는 request ID와 인증 주체, API에는 revision과 업무 오류, database에는 transaction 결과, 배포 계층에는 image digest가 남아야 합니다. 이 식별자가 연결되어야 장애가 frontend인지 cache인지 query인지 추측이 아니라 증거로 좁혀집니다.

교육용 fixture에서 A 응답을 800ms, B 응답을 100ms 지연시켜 순서를 강제로 바꿉니다. 이 수치는 실제 서비스 성능이 아니라 순서 오류를 재현하기 위한 입력 조건입니다. 타이머가 우연히 원하는 순서로 끝나기를 기다리지 말고 각 응답을 독립적으로 해제할 수 있는 mock을 둡니다. 그래야 느린 시험 장비에서도 같은 인과관계를 재현할 수 있습니다.

B 결과가 나타난 뒤 A 응답을 풀어도 화면의 검색어와 결과 식별자가 B로 유지되는지 확인합니다. 요청 횟수만 맞는 테스트는 잘못된 결과가 마지막에 덮어쓰는 결함을 놓칠 수 있습니다. 검사 대상에는 화면에 보이는 첫 항목과 링크의 대상 ID를 함께 넣습니다. 제목만 B로 남고 클릭 대상이 A로 되돌아가면 겉보기 성공과 실제 사용자 행동이 어긋난 것입니다.

같은 fixture에 실패 응답을 섞어 오류 메시지도 현재 요청에 속하는지 봅니다. A의 늦은 오류가 B의 성공 화면을 오류 화면으로 바꾸면 성공 경로만 고친 것입니다. 오류가 속한 요청 ID를 화면 state에 저장하는지도 살펴봅니다. 일반 error boolean 하나만 공유하면 과거 요청의 실패를 현재 요청의 실패와 구분할 수 없습니다.

검토 기록에는 요청 조건, 적용한 응답 ID, 버린 응답 ID와 화면 결과를 함께 남깁니다. 다음 담당자는 재현 순서를 보고 수정 전에는 실패하고 수정 후에는 통과하는지 같은 조건으로 확인합니다. 버린 응답을 성공 처리량으로 중복 집계하지 않는지도 관찰합니다. 네트워크 응답 수와 사용자가 실제로 본 결과 수는 서로 다른 지표이며 한 숫자로 합치면 재현 해석이 달라집니다.

교육용 완료 버튼은 저장소에 완료 상태를 넣은 뒤 페이지를 열어 검증합니다. 본문 DOM이 유지되면서 버튼 상태가 복원되는지 기다리고, 고정된 짧은 시간 대신 기대 조건이 성립하는지를 한도 안에서 확인합니다. 대기 한도를 넘기면 임의로 통과시키지 않고 초기 저장값과 최종 버튼 상태를 실패 증거로 남깁니다. 이렇게 해야 단순 지연과 실제 복원 기능의 부재를 구분할 수 있습니다.

복원 뒤 버튼을 눌러 완료를 해제하고 다시 완료로 바꿉니다. 두 번 모두 화면의 접근성 상태와 저장소 값이 함께 바뀌어야 이벤트 연결과 저장 동작을 확인한 것입니다. 화면 상태만 바뀌고 저장값이 그대로면 새로고침 뒤 이전 상태가 돌아옵니다. 따라서 마지막 클릭 후 페이지를 다시 열 때 필요한 값이 실제로 기록됐는지 확인합니다.

Native details의 펼침만 확인하면 JavaScript가 실행되지 않아도 테스트가 통과할 수 있습니다. React state를 실제로 바꾸는 조작과 JavaScript 없이 읽을 수 있는 본문 검사를 서로 다른 증거로 둡니다. 자바스크립트 요청을 차단한 fixture에서는 완료 버튼의 성공을 요구하지 않습니다. 대신 제목과 본문 링크를 읽을 수 있는지 보아 두 검사의 책임을 섞지 않습니다.

실패 보고는 초기 HTML 부재, 자산 경로 오류, state 복원 실패와 클릭 후 저장 실패를 구분합니다. 같은 “화면 오류”로 합치지 않아야 SSR 생성과 client effect 중 어디를 고칠지 결정할 수 있습니다. 오류를 고친 뒤 첫 방문과 재방문을 모두 실행합니다. 저장소가 비어 있는 첫 방문만 확인하면 개인 상태를 복원하는 경로의 불일치는 계속 숨을 수 있습니다.

가상의 상품 목록에서 category=books, page=3을 주소로 연 뒤 항목을 선택합니다. 새 탭에 복사한 주소와 뒤로 돌아온 화면이 같은 필터를 복원하는지 비교합니다. 상세 링크에는 원래 목록으로 돌아가는 조건이 보존되어야 합니다. 화면의 뒤로 버튼만 따로 구현하지 말고 브라우저 기록의 이동에서도 같은 결과가 나오는지 살펴봅니다.

page=-1과 지원하지 않는 sort 값을 별도 fixture로 만듭니다. 오류를 보일지 기본값으로 바꿀지 먼저 정하고 결과 URL, 요청 조건과 화면 표시가 합의한 규칙에 맞는지 검사합니다. 같은 잘못된 값을 server 진입과 client 필터 변경 양쪽에 넣습니다. 한쪽은 오류이고 다른 쪽은 조용한 기본값이면 공유한 URL이 사용자마다 다른 행동을 만들 수 있습니다.

네트워크가 느릴 때 이전 결과를 표시한다면 그 결과가 어느 조건에 속하는지도 알려야 합니다. 주소만 새 조건이고 결과는 이전 조건인데 최신이라고 말하면 사용자는 다른 항목을 잘못 선택할 수 있습니다. 로딩 표시가 사라지는 시점도 요청한 조건의 성공에 연결합니다. 먼저 끝난 무관한 요청이 로딩 상태를 해제하면 아직 새 결과가 없는데 선택 가능한 화면으로 오해할 수 있습니다.

완료 증거는 링크 클릭 한 번이 아니라 직접 진입, 새로고침, 뒤로 가기와 잘못된 주소 입력을 포함합니다. 네 경로가 같은 조건 해석을 사용하면 화면 상태가 일회성 메모리를 넘어 공유 가능한 작업이 됩니다. 주소 계약을 바꿀 때는 이전에 공유한 링크 fixture를 보관합니다. 새 화면에서만 맞는 상태 설계는 저장된 북마크와 외부 링크의 사용자를 정상 경로에서 밀어낼 수 있습니다.