저장 버튼을 눌렀는데 아무 표시도 바뀌지 않는다고 해 보자. 조금 기다리다가 다시 누르게 된다. 그래도 조용하면 내가 쓴 내용부터 걱정된다. 만드는 쪽에서는 요청을 처리하고 있는 중이어도, 쓰는 사람에게는 아무 일도 일어나지 않는 화면이다.
나는 기술을 고를 때 이런 순간을 기준으로 삼고 싶다. 어떤 도구를 쓰는지도 중요하지만, 그 도구들로 사용자의 불안을 어디까지 줄일 수 있는지가 더 궁금하다. 첫 화면을 빠르게 만드는 일과 그 화면을 믿고 계속 쓰게 만드는 일 사이에는 아직 결정할 것이 많다.
기다리는 동안에도 알 수 있는 것
이 블로그 편집기의 저장 흐름을 보면 작은 선택들이 이어져 있다. 저장을 시작하면 ‘저장 중…’으로 상태가 바뀌고 저장 버튼은 잠시 비활성화된다. 요청이 실패하면 입력한 내용은 유지한 채 오류를 알려 준다. 사용자가 지금 기다려야 하는지, 내용을 고쳐야 하는지 판단할 단서다.
버튼을 잠시 막는 것으로 끝나지는 않는다. 응답을 받지 못해 같은 내용을 재시도할 수도 있기 때문이다. 편집기는 같은 저장 내용의 재시도에 같은 요청 식별자를 사용하고, 서버는 이미 성공한 요청이면 그 결과를 돌려준다. 같은 식별자로 다른 내용을 보내면 거부한다. 여기서 중요한 것은 서버가 재시도와 새로운 저장을 구분할 수 있도록 화면과 약속을 맞췄다는 점이다.
나는 이런 연결에 효율의 의미가 있다고 본다. 버튼을 다시 누른 사람에게 조심하라고 요구하기 전에, 그렇게 누를 수밖에 없었던 화면을 살펴보는 것이다. 질문이 구체적이면 필요한 도구의 역할도 분명해진다. 화면은 상태를 전하고, 서버는 저장의 규칙을 지킨다.
이 역할 구분을 더 살펴보고 싶다면 Next.js의 서버·클라이언트 안내에서 각 환경을 사용하는 기준을 읽어 볼 만하다. 공개 데모 저장소는 완성 화면과 파일 구성을 함께 살펴보는 참고가 된다. 다만 이 블로그의 재시도 처리는 별도로 구현된 저장 규칙이다.
AI에게 맡기기 전에 정할 문장
이 상황을 AI에게 설명한다면 “저장 기능을 만들어 줘”에서 조금 더 나아가고 싶다. 저장하는 동안 상태가 보여야 하고, 실패해도 본문이 남아 있어야 하며, 같은 요청을 다시 보내도 새 글이 중복으로 생기지 않아야 한다고 말하는 것이다. 원하는 결과를 이렇게 적으면 제안된 코드를 검토할 기준이 생긴다.
다른 창에서 같은 글을 편집하는 경우도 따로 생각해야 한다. 이 편집기는 저장할 때 글의 버전을 함께 보내고, 서버는 현재 버전과 맞지 않으면 저장을 거부한다. 먼저 저장된 글을 오래된 화면의 내용으로 덮어쓰지 않도록 하는 장치다. 입력을 그대로 남겨 두는 일과 충돌을 알리는 일이 함께 있어야, 작성자가 두 내용을 비교할 수 있다.
이 글에서 설명한 동작은 이 블로그 저장소의 편집기와 저장 코드를 확인한 내용이다. 같은 요청의 성공 결과를 다시 돌려주는 동작, 다른 내용에 같은 식별자를 쓰면 거부하는 동작, 오래된 버전의 저장을 막는 동작은 로컬의 기존 테스트에서도 확인했다. 그림은 그 구조를 이해하기 위한 연출이며 실제 화면을 촬영한 자료는 아니다.
새 라이브러리가 필요한지는 그 다음에 판단할 수 있다. 이미 있는 상태 표시와 저장 규칙으로 해결할 수 있다면 그 흐름부터 다듬는다. 반복해서 손대는 부분이 남는다면, 어떤 수고를 줄이려는지 적어 보고 도구를 검토한다. 도입 이유가 선명해야 나중에 유지할지 바꿀지도 결정하기 쉽다.
