렌더링 계약

이 문서의 중심

UI 일관성은 데이터 정확성보다, 그 데이터를 언제·어디까지·어떤 우선순위로 공개할지에 대한 합의에서 생깁니다.

그리고 그 합의를 구조화한 것이 “렌더링 계약”입니다.

• 시점 (When)
• 범위 (Where / How much)
• 우선순위 (Priority)

이건 기능보다 관계의 문제입니다.

• 데이터와 상태가 화면에서 만나는 방식,
• 사용자 입력이 받아들여지는 방식,
• “지금 보이는 것”과 “방금 계산한 것”의 순서를 맞추는 방식.

렌더링 계약이 드러나는 지점

렌더링 계약이 중요해지는 장면은 두 종류입니다.

• 화면 시작점: 어떤 정보가 먼저 사용자를 만나느냐를 정할 때
• 화면 갱신 중간: 여러 변화가 겹칠 때 무엇이 최종으로 보일지를 정할 때

SSR/CSR/SSG/SPA는 기술 용어가 아니라 이런 질문에 대한 서로 다른 답입니다.

• 처음 만나는 화면의 책임이 어디에 있는가
• 그 이후 갱신이 어느 주기로 이어지는가
• 갱신 실패를 누가 받아들이고 어떻게 수습할 것인가

백엔드 전환자가 잡아야 할 철학적 기준

백엔드 사고의 장점은 보존하면서, 프론트의 관점을 하나 추가하면 됩니다.

• 응답의 정확성 외에 관측의 정확성을 추가한다.
• 값의 정합성 외에 사용자에게 보이는 정합성을 분리해 본다.
• 성공/실패만이 아니라 언제 보이고 언제 지연되는가를 상태와 함께 설계한다.

Web 트랙으로 이어지는 포인트

이 문서가 말하는 계약은 다음에서 실제 전략으로 이어집니다.

• 렌더링 전략(CSR/SSR/SSG)
• Next.js(App Router)로의 연결

체크 질문

• 화면 갱신의 “시점/범위/우선순위” 중 어디가 팀에서 덜 공유되어 있었는가?
• 같은 갱신이 겹칠 때, 팀은 같은 기준으로 설명할 수 있는가?
• 전략 선택(SSR/CSR/SSG)이 제품의 실제 사용자 체감 지연과 어떻게 맞물려 있는가?