배포 전에 확인할 웹 접근성

혼자 개발할수록 확인한 값과 바꾼 값을 따로 남기는 습관이 필요하다. 특히 배포 전에는 접근성까지 확인해야 한다.

배포 문제를 크게 잡지 말고 단계별로 확인하자. 한 단어만 붙잡지 말고 문제 해결 전체 흐름에서 원인을 좁혀야 한다.

핵심 질문

배포하기 전에 로컬과 운영의 차이까지 같이 적어두면 원인 추적이 쉬워진다.

제외할 원인들

배포 자체보다 재현 가능한 단서를 남기는 게 중요하다. 재현 조건을 확인하면 다음으로 볼 범위가 확 줄어든다.

• 먼저 볼 것: 재현 조건
• 비교할 값: 정상일 때의 상태
• 남길 기록: 명령어 출력, 응답 상태코드, 수정한 설정

설정 확인

배포 전에 로그부터 확인하면 불필요한 변경을 줄일 수 있다. 작은 확인이 쌓이면 원인 후보가 자연스럽게 줄어든다.

npm run build

정상 상태 정의

배포 자체보다 재현 가능한 단서를 남기자. 설정을 확인하면 범위가 줄어든다.

사용자 영향 확인

문제 해결의 흐름을 먼저 끊어서 봐야 한다. 빌드 결과가 애매하면 다른 부분을 고쳐도 결과가 바뀌지 않을 수 있다.

확인 순서:

1. 같은 조건에서 증상이 다시 나오는지 테스트한다
2. 로그나 응답에서 달라진 부분을 설명한다
3. 공개 화면, 빌드 결과, 실제 요청으로 최종 확인한다

마무리

마지막에는 실제 화면이나 공개 URL까지 확인해야 작업이 끝난다. 관련 기록을 남겨두면 다음 확인이 훨씬 빨라진다.