28. GitHub의 파일 보관과 Vercel의 사이트 공개

커밋 설명이 다음 작업을 돕습니다

‘수정’이라는 설명만 여러 번 남기면 어떤 변화인지 찾기 어렵습니다. ‘소개 첫 문장 수정’, ‘링크 주소 교체’, ‘빈 입력 안내 추가’처럼 바뀐 내용을 적으면 기록을 읽기 쉽습니다. 긴 기술 설명을 쓸 필요는 없습니다. 나중에 어떤 상태로 돌아가려는지 구분할 수 있으면 됩니다.

커밋을 남겼다는 사실은 파일의 특정 상태가 기록되었다는 뜻입니다. 그 상태의 기능을 모두 시험했다는 뜻까지 포함하지는 않습니다. 변경 기록과 확인 기록을 구분하고 필요한 경우 함께 적습니다. 파일이 보관된 상태와 사용 가능한 상태를 같은 말로 넘기지 않습니다.

브랜치가 도움이 되는 장면

공개 중인 소개 문장은 유지하고 새로운 배치를 시험하고 싶다고 해 봅시다. 별도의 브랜치에서 수정하면 운영 기준과 검토 중인 변경을 나누어 볼 수 있습니다. Vercel의 연결 설정에 따라 검토용 주소로 결과를 볼 수 있습니다. 이름만 새로 붙이는 것이 아니라 어느 흐름의 변경을 어디에 반영하는지 구분하는 것입니다.

처음 파일 하나를 올리는 실습에서는 새 연습용 프로젝트로 시작해 기존 운영 사이트와 섞이지 않게 합니다. 이후 실제 운영에 수정할 때는 브랜치와 배포 대상의 관계를 확인합니다. main이라는 이름을 외우는 것보다 이 프로젝트에서 어떤 브랜치를 운영 기준으로 쓰는지 아는 것이 중요합니다.

빌드가 실패했다는 안내를 읽기

빌드 실패는 사이트를 준비하는 과정이 끝나지 않았다는 뜻일 수 있습니다. 필요한 파일이 없거나 설정이 맞지 않거나 코드에 문제가 있을 수 있습니다. 화면의 색을 바꾸는 요청으로 해결할 문제가 아닐 수도 있습니다. 어떤 단계에서 어떤 안내가 나왔는지 확인합니다.

이번 실습은 별도 변환이 필요 없는 HTML 파일을 기준으로 하므로 복잡한 빌드 명령을 넣지 않습니다. 다른 도구가 여러 파일과 설치가 필요한 프로젝트를 만들었다면 이 설정을 그대로 쓰지 않아야 합니다. 실제 결과물의 구조와 공개 설정을 맞추는 것이 먼저입니다.

배포 기록에서 확인할 세 가지

어느 프로젝트인지, 어떤 변경 기록을 사용했는지, 어느 주소로 제공되는지를 봅니다. 프로젝트 이름이 비슷하면 다른 작업을 확인할 수 있고, 이전 배포를 열면 새 문장이 보이지 않을 수 있습니다. 상태가 성공이어도 내가 확인하려던 버전인지 알 수 있어야 합니다.

방문자에게 안내할 주소와 관리 주소도 구분합니다. 관리 화면의 성공 표시를 캡처하는 것보다 방문자용 주소를 실제로 열어 읽고 눌러 보는 확인이 필요합니다. 파일 관리와 사이트 공개가 이어지지만 서로 다른 역할이라는 설명이 여기에서 실제 판단에 쓰입니다.

“GitHub에 올렸는데 사이트가 안 바뀌면 무엇을 보나요?”

먼저 올바른 저장소와 브랜치에 파일이 기록되었는지 봅니다. 그다음 Vercel이 그 저장소와 연결되어 있는지, 새로운 배포가 시작되어 끝났는지 확인합니다. 마지막으로 현재 열고 있는 사이트 주소가 확인하려는 배포인지 봅니다. 파일 반영에서 방문자 화면까지의 흐름을 따라가는 방법입니다.

일부 단계가 아직 끝나지 않았거나 다른 대상을 보고 있을 수 있습니다. 파일 이름과 위치가 달라졌다면 공개 설정과 맞지 않을 수도 있습니다. 원인을 확인하지 않고 같은 파일을 여러 번 올리거나 프로젝트를 계속 새로 만드는 방식은 기록을 더 복잡하게 만들 수 있습니다.

도움을 요청할 때는 저장소 이름과 브랜치, 배포 상태, 실제 보이는 결과를 함께 설명합니다. 비밀 정보는 제외합니다. 어느 단계까지 확인했는지 알면 다음 확인을 좁히기 쉽습니다. 두 서비스의 역할을 구분하는 지식이 실제 문제 해결에 쓰이는 장면입니다.