/ 우리는 이렇게 합니다 / 운영 담당자의 노트
운영·QA · 런칭을 맡은 사람

오픈 버튼을 누르기 전에, 한 번 더 봅니다.

개발이 끝나고 디자인이 예뻐도, 저는 마지막에 한 번 더 묻습니다. “이거 지금 오픈하면, 정말 안 깨질까?” 화면에 안 보이는 것들 — 깨진 링크, 막아둔 robots, 빠진 분석 코드 — 이 사고를 냅니다. 그래서 이 글은 제가 오픈 전에 실제로 돌리는 점검표입니다. 아래 체크리스트, 직접 체크하면 진행률이 올라갑니다.

한 줄 직답

안전한 오픈은 운이 아니라 점검표입니다. Findable은 브라우저·링크·폼·메타·404·robots·sitemap·검색등록·분석·HTTPS·접근성·속도를 오픈 전에 모두 확인하고, 오픈 뒤에는 색인·유입·오류를 모니터링하며 측정→개선 루프를 돕니다. 문제가 생기면 직전 버전으로 롤백할 준비도 미리 해 둡니다.

요약

  • 오픈 전 점검은 ‘느낌’이 아니라 체크리스트로 — 빠짐없이 항목을 닫는다.
  • 가장 흔한 사고는 막아둔 robots 미해제, 깨진 링크, 빠진 분석 코드다.
  • 오픈 후 첫 48시간은 색인·유입·오류 로그를 모니터링하고 측정→개선을 반복한다.
  • 직전 버전을 보관하고 롤백 절차를 미리 적어 둬서 사고 시 피해를 먼저 끊는다.

몇 해 전, 밤늦게 오픈한 사이트가 다음 날 검색에서 통째로 안 보인 적이 있습니다. 코드는 멀쩡했죠. 원인은 한 줄, 개발 중에 막아둔 Disallow: /를 robots.txt에서 안 푼 것이었습니다. 그날 이후로 저는 ‘오픈은 끝이 아니라 점검의 시작’이라고 생각합니다. 보이는 화면만 보고 오픈하면 꼭 안 보이는 곳에서 사고가 납니다. 그래서 저는 머릿속이 아니라 종이(정확히는 체크리스트)로 일합니다.

왜 ‘느낌으로 오픈’이 위험할까요?

사람의 기억은 새벽 2시에 가장 약합니다. 오픈은 보통 그 시간에 합니다. “아까 확인했지” 하는 항목이 사실은 다른 페이지였거나, 스테이징에서만 됐거나, 내 브라우저에서만 됐던 경우가 많습니다. 체크리스트는 그 ‘아마 했을 것’을 ‘방금 눈으로 닫았다’로 바꿔 줍니다.

오픈 전에 실제로 무엇을 보나요?

아래는 제가 매번 돌리는 8가지입니다. 설명만 읽지 말고, 직접 체크해 보세요. 진행률이 차오르는 걸 보면 어떤 항목이 비어 있는지 한눈에 보입니다. 이게 제가 오픈 직전에 보는 화면과 거의 같습니다.

Live · 런칭 체크리스트

오픈 전, 빠짐없이

항목을 체크해 보세요. 진행률이 실시간으로 올라갑니다.

0 / 8 완료

제가 항목마다 실제로 하는 일

크로스 브라우저·기기 — 내 크롬에서만 보지 않습니다. 사파리·엣지·모바일 사파리·안드로이드 크롬에서 헤더, 폼, 폰트 깨짐을 봅니다. 아이폰 SE처럼 좁은 화면이 제일 잘 깨집니다.

링크·폼 — 메뉴, 푸터, 본문 링크를 전부 눌러 봅니다. 문의 폼은 실제로 한 번 보내서 알림 메일이 오는지 확인합니다. 접수가 안 되는 폼은 새는 수도꼭지와 같습니다.

메타·OG·favicon — 카톡·슬랙에 URL을 붙여 미리보기 카드가 제대로 뜨는지 봅니다. 제목·설명·이미지가 비면 공유될 때 휑하게 나갑니다.

404·리다이렉트 — 일부러 없는 주소를 쳐서 404 페이지가 홈으로 가는 길을 주는지 봅니다. 도메인 변경이 있었다면 옛 주소가 새 주소로 301로 넘어가는지 확인합니다.

robots·sitemap·검색등록 — 그날 사고의 주인공입니다. 막아둔 robots를 풀고, sitemap.xml이 열리는지 보고, 서치콘솔과 네이버 서치어드바이저에 사이트와 sitemap을 등록합니다.

분석 연결 — GA4 측정 ID가 모든 페이지에 들어갔는지, 실시간 보고서에 내 방문이 잡히는지 확인합니다. 첫날부터 숫자가 쌓여야 나중에 개선할 근거가 생깁니다.

HTTPS·보안 헤더 — 자물쇠가 떠 있는지, http로 들어와도 https로 넘어가는지, 혼합 콘텐츠 경고가 없는지 봅니다. 기본 보안 헤더도 함께 점검합니다.

접근성·속도 — 마우스를 치우고 Tab만으로 끝까지 이동되는지, 이미지 대체 텍스트와 명도 대비가 충분한지 봅니다. 속도는 모바일 기준 Lighthouse로 마지막에 한 번 더 측정합니다.

오픈하고 나면 끝일까요?

오픈은 시작점입니다. 첫 24~48시간이 제일 바쁩니다. 서치콘솔의 색인 상태와 오류, GA4의 실시간 유입과 이탈, 폼 접수 알림, 서버 에러 로그를 번갈아 봅니다. 404가 갑자기 늘면 깨진 내부 링크나 잘못된 리다이렉트라는 신호라, 바로 추적합니다.

오픈 직후 무엇을 언제 보고 ‘어떤 숫자가 뜨면 손대는지’를, 저는 표로 고정해 두고 그대로 봅니다.

오픈 후 모니터링 — 항목 × 시점 × 위험 신호
볼 것언제이러면 손댄다
서치콘솔 색인·오류첫 24~48시간색인 0·커버리지 오류 급증
GA4 실시간 유입·이탈오픈 당일실시간 0 → 측정 코드 누락
폼 접수 알림오픈 직후 1건 실제 발송알림 메일 안 옴 → 폼 단절
서버 에러·404 로그첫 주 매일404 급증 → 깨진 링크·리다이렉트

이 표의 ‘이러면 손댄다’ 칸이 켜지기 전에 보는 게 핵심입니다.

그다음은 어떻게 더 좋아지나요?

저는 측정한 숫자로만 다음 할 일을 정합니다. 어떤 페이지에서 사람들이 많이 빠져나가는지, 어떤 검색어로 들어오는데 정작 그 내용이 약한지를 보고 한 번에 한두 개씩 고칩니다. 추측으로 다 갈아엎지 않고, 측정→가설→수정→재측정 루프를 천천히 돕니다. 작은 개선이 쌓이는 게 큰 리뉴얼보다 안전합니다.

일이 잘못되면, 되돌릴 수 있나요?

네, 미리 준비하면요. 저는 오픈 전에 항상 직전 버전을 따로 보관하고, ‘이럴 땐 이렇게 되돌린다’는 롤백 절차를 한 장으로 적어 둡니다. 큰 문제가 보이면 현장에서 고치려고 매달리기 전에 안정된 버전으로 먼저 되돌립니다. 사용자 피해를 끊는 게 1순위, 원인 수정은 그다음입니다. 이 한 장이 있어서 새벽에도 침착할 수 있습니다.

그 ‘한 장’에 반드시 들어가야 새벽에 흔들리지 않는 항목은 이것들입니다.

롤백 준비 — 한 장에 담는 것
직전 버전 보관되돌리기 절차판단 기준선담당·연락복구 후 재배포

이 칩이 비어 있으면, 문제가 터진 그 순간에 절차를 만들게 됩니다.

항목점검 없이 오픈체크리스트 오픈
오류·사고막아둔 robots·깨진 폼이 그대로 노출오픈 전에 항목별로 닫아 사고 차단
방문자 신뢰깨진 화면·접수 실패로 이탈링크·폼·미리보기까지 정상 동작
검색 노출색인 누락·sitemap 미제출robots 해제·sitemap 제출·색인 요청
사고 대응되돌릴 방법 없이 현장 수습직전 버전 보관·롤백 절차로 즉시 복구

다른 담당자와의 연결

운영은 사이트 제작의 마무리이자, 동시에 모든 작업을 잇는 매듭입니다. 제가 오픈 전에 닫는 항목 하나하나는 다른 담당자들의 일과 맞물려 있습니다. 점검을 어떤 절차로 돌리는지는 운영은 이렇게 합니다에서 더 자세히 풀었습니다. HTTPS·보안 헤더 같은 기본은 보안 담당자의 노트에 정리돼 있고, 마지막 접근성 점검의 기준은 접근성 담당자의 노트와 그대로 이어집니다. 저는 이 세 사람의 일을 한 장의 체크리스트로 모아 오픈 버튼 앞에 둡니다.

오픈 전에 가장 먼저 점검해야 할 건 뭔가요?
링크와 폼이 실제로 동작하는지 먼저 봅니다. 깨진 링크와 접수 안 되는 폼은 방문자를 곧장 잃습니다. 그다음 크로스 브라우저·기기 확인, 메타·OG·favicon, 404·리다이렉트, robots·sitemap·검색엔진 등록, GA4·서치콘솔, HTTPS·보안 헤더, 접근성·속도 순으로 빠짐없이 봅니다.
robots.txt와 sitemap.xml은 꼭 있어야 하나요?
있어야 합니다. robots.txt로 검색엔진이 무엇을 읽어도 되는지 알려주고, sitemap.xml로 페이지 목록을 전달합니다. 개발 중 막아둔 ‘Disallow: /’를 오픈 때 풀지 않으면 사이트 전체가 검색에서 빠집니다. 오픈 직후 서치콘솔에 sitemap을 제출하고 색인을 요청합니다.
오픈한 뒤에는 무엇을 봐야 하나요?
첫 24~48시간은 서치콘솔의 색인·오류 리포트, GA4의 실시간 유입과 이탈, 폼 접수 알림, 서버 에러 로그를 봅니다. 404가 갑자기 늘면 깨진 내부 링크나 잘못된 리다이렉트 신호입니다. 측정한 숫자로 다음 개선 항목을 정하는 루프를 돕니다.
오픈 직후 문제가 생기면 어떻게 하나요?
미리 직전 버전을 보관해 두고 롤백 절차를 적어 둡니다. 큰 문제가 보이면 고치는 데 매달리기 전에 안정된 버전으로 되돌려 사용자 피해를 먼저 끊습니다. 그다음 원인을 재현·수정하고 다시 배포합니다.
속도와 접근성은 오픈 전에 어떻게 확인하나요?
속도는 Lighthouse나 PageSpeed로 모바일 기준을 봅니다. 이미지 용량·압축, 폰트 로딩, 불필요한 스크립트를 먼저 줄입니다. 접근성은 키보드만으로 끝까지 이동되는지, 이미지 대체 텍스트와 명도 대비가 충분한지, 폼 라벨이 붙어 있는지 마지막에 한 번 더 점검합니다.

이 점검표로 당신의 오픈을 지킵니다

오픈 전 빠짐없는 점검과 오픈 후 모니터링까지, 같은 태도로 당신의 사이트를 운영합니다. 무료 진단으로 시작하세요.

무료 진단 받기

이 글의 체크리스트는 이 페이지에서 실제로 동작하는 코드입니다(체크하면 진행률이 올라갑니다, 외부 라이브러리 0). 검색 노출·전환 관련 설명은 일반 원칙이며 특정 순위·성과를 보장하지 않습니다. 날조된 사례·수치는 사용하지 않았습니다.