30. 공개한 페이지의 수정과 문제 해결

작동하는 상태를 먼저 남깁니다

공개한 뒤에도 오타를 고치거나 링크를 바꿀 수 있습니다. 수정 전에 현재 잘 작동하는 파일과 변경 기록을 확인하면 돌아갈 기준이 생깁니다. 어떤 문장을 고칠지, 어떤 부분은 그대로 둘지 정하고 작은 변경부터 시작합니다.

운영 브랜치에 파일을 기록하면 연결 설정에 따라 바로 배포될 수 있습니다. 검토용 브랜치에서 먼저 확인하는 흐름이라면 그 결과를 본 뒤 운영에 반영합니다. 이 차이를 모르고 파일을 저장하면 생각보다 빨리 방문자에게 바뀐 화면이 보일 수 있습니다.

수정한 곳과 주변을 함께 확인합니다

소개 문장을 바꿨다면 문장이 맞는지 보고, 길어지면서 링크가 가려지지는 않았는지도 봅니다. 검색 기능을 고쳤다면 검색어를 지웠을 때의 목록과 새 항목 추가도 확인합니다. 수정한 부분만 따로 존재하는 것이 아니기 때문입니다.

공개 주소에서 이전 내용이 보이면 먼저 배포가 끝났는지, 맞는 주소인지, 최신 결과인지 확인합니다. 브라우저가 이전 자료를 재사용하는 경우도 있지만, 확인 없이 계속 새로 배포하지 않습니다. 어느 버전이 어디에 공개되었는지 알아야 문제의 위치를 찾을 수 있습니다.

문제를 세 층으로 나누기

1. 내용과 기능링크 주소가 틀리거나 버튼이 기대와 다르게 움직이는 경우입니다.
2. 공개 과정파일이 없거나 설정이 맞지 않아 사이트가 준비되지 않을 수 있습니다.
3. 접속 환경로그인 보호나 네트워크 문제로 특정 사람에게만 열리지 않을 수 있습니다.

‘사이트가 안 돼요’라는 말만으로 셋을 구분할 수는 없습니다. 어느 주소에서, 어떤 기기로, 무엇을 했을 때, 어떤 문장이 보였는지를 기록합니다. 이 정보가 있으면 코드를 고쳐야 하는지, 공개 설정을 봐야 하는지 판단하기 쉬워집니다.

되돌리기의 범위를 이해하기

이전 파일을 다시 올리거나 서비스의 복구 기능으로 이전 배포를 사용하게 할 수 있습니다. 어떤 방식을 쓰든 현재 공개 주소에서 원하는 버전이 보이는지 확인합니다. 사이트 화면이 돌아왔다고 사용자가 입력한 자료까지 과거로 돌아오는 것은 아닙니다.

링크 목록처럼 브라우저에 있는 자료와 코드의 변경은 별개입니다. 저장 방식을 바꾸는 큰 수정은 예전 자료를 읽을 수 있는지 확인해야 합니다. 첫 프로젝트에서는 자료 구조를 급하게 바꾸기보다, 현재 자료를 내보내고 작은 예시로 시험하는 방식이 낫습니다.

공개 후 첫 수정의 사례

지수가 공개한 페이지에서 소개글의 오타를 발견했습니다. 먼저 현재 파일과 마지막 배포 상태를 확인하고, 오타 한 곳만 고친 새 파일을 준비했습니다. 새 파일을 열어 문장이 맞는지 본 뒤 같은 연습용 저장소에 반영했습니다. 연결된 배포가 끝난 뒤 방문자용 주소에서 바뀐 문장을 확인했습니다.

이 흐름에서는 변경의 이유와 범위가 작아서 문제를 찾기 쉽습니다. 만약 같은 순간에 배치와 링크 주소, 저장 기능까지 함께 바꾸었다면 결과가 이상할 때 어느 변화 때문인지 구분하기 어려웠을 수 있습니다. 공개된 페이지에서도 작은 변경과 확인의 원칙이 유지됩니다.

새로고침해도 예전 문장이 보일 때

먼저 내가 고친 파일이 실제 저장소에 반영되었는지 봅니다. 그다음 새 배포가 끝났는지와 현재 열고 있는 주소가 맞는지 확인합니다. 이전 배포의 고정 주소를 열고 있다면 새 결과가 보이지 않을 수 있습니다. 브라우저가 이전 자료를 재사용하는 경우도 확인할 수 있지만, 처음부터 그 원인으로 단정하지 않습니다.

여러 가능성을 동시에 바꾸기보다 반영 흐름을 따라갑니다. 내 파일, 저장소 기록, 배포 결과, 현재 주소 순서로 보면 어디까지 바뀌었는지 알 수 있습니다. 이 과정을 이해하면 ‘계속 새로 만들기’보다 필요한 지점을 확인하는 질문을 할 수 있습니다.

꼭 기억하세요

공개 후 수정도 작은 범위로 진행하고, 배포된 주소에서 확인하며, 되돌릴 기준을 남깁니다.