"오래 남는 저장이 손을 열고, 장식은 뒤따라와."
먼저 지킬 것
손이 옮겨 쓸 원문이 의미 있는 결과야. 원문과 출처가 commit되면 요청은 돌아와도 돼. 번역과 뒤이은 리뷰는 페이지를 인질로 잡을 권리가 없고 따라 읽기 음성은 필요할 때만 형제에게 요청해.
상태로 약속해
엔트리와 첫 작업 행을 한 transaction에서 만들고, 장식 상태가 pending이라고 보이는 응답을 돌려줘. 오래 남을 원문이 이미 있으니 빠른 응답은 낙관적인 허풍이 아니야.
조용한 실패
모든 하류 서비스를 기다리면 필사가 가장 느린 형제에게 묶이고 음성 장애가 글쓰기 장애가 돼. 반대로 엔트리 commit 전에 응답하면 화면에는 보였는데 재시작 뒤 찾을 수 없는 문장이 생겨.
다섯 순간을 따라가
이 원칙이 진짜인지 알려면 생성 직전, 저장 직후, worker가 집어 든 순간, 결과가 돌아온 순간, 다음 날 다시 읽는 순간을 차례로 봐. 각 순간에 엔트리와 작업의 상태, 작업이 읽은 원문, 사용자가 보는 문구를 적어. 성공한 요청만 맞고 재시도나 취소에서 달라지면 원문 주권은 조건부였던 거야.
수행해
뽑기 요청의 시간선을 그리고 가장 이르게 정직하게 응답할 수 있는 지점을 표시해. 정상 완료 하나만 그리지 말고 원문 수정, 엔트리 삭제, worker 재시작, 외부 서비스 실패도 같은 표에 넣어. 결과를 버리는 일이 데이터 손실이 아니라 무결성 보존이 되는 순간을 분명히 표시해.
마지막 질문
화면이 원문을 계속 보여주고 작업 상태를 솔직히 말하는가? 그렇다면 장식은 원문을 돕고 있어. spinner나 빈칸으로 실패를 숨기거나 늦은 결과가 최신 글을 덮으면 장식이 왕좌를 훔친 거야.
이 레슨의 착지 조건
commit 전 응답과 commit 뒤 응답을 일부러 갈라서 시험해. 첫 번째는 화면에만 있고 복구할 수 없는 문장을 만들고, 두 번째는 번역이 늦어도 원문을 다시 찾을 수 있어. 빠름의 기준은 모든 작업 종료가 아니라 의미 있는 결과가 오래 남기 시작한 순간이야.
응답 속도와 정확성은 서로 반대편에 있지 않아. 오래 남을 원문을 먼저 확정하고, 나중 결과에는 현재 상태를 다시 묻게 하면 둘 다 지킬 수 있어.