운영·QA는 이렇게 합니다 — 검증·배포·사후 관리

왜 '운영·QA'를 따로 부르나요?

제작이 끝나면 사이트가 완성되는 것처럼 보이지만, 실제로는 거기서부터 운영 파트의 일이 시작됩니다. 디자인과 개발이 '만드는 일'이라면, 운영·QA는 만든 것이 정말 작동하는지 검증하고, 안전하게 세상에 내보내고, 오픈 뒤에도 살아 있게 지키는 일입니다. 새로 만든 페이지는 내 컴퓨터의 한 브라우저에서는 멀쩡해 보여도, 다른 기기·다른 브라우저·느린 회선에서는 깨지는 경우가 흔합니다. 그 차이를 오픈 전에 잡아내는 것이 QA의 역할입니다.

그래서 우리는 '제작팀이 알아서 확인했겠지'에 기대지 않고, 운영·QA 파트가 같은 체크리스트로 처음부터 다시 점검합니다. 만든 사람과 검증하는 사람의 시선을 분리해야 빠진 부분이 보이기 때문입니다.

런칭 전 QA에서는 무엇을 점검하나요?

감으로 보지 않고, 항목을 적어 두고 한 줄씩 통과시킵니다. 크게 다섯 묶음입니다. 첫째 브라우저 — 크롬·사파리·엣지에서 레이아웃이 같은지. 둘째 기기 — 안드로이드폰·아이폰 실기기와 작은 화면부터 큰 화면까지 화면 크기별로 글자와 버튼이 무너지지 않는지. 셋째 링크 — 메뉴·버튼·푸터의 모든 링크를 눌러 엉뚱한 곳이나 없는 페이지(404)로 가지 않는지. 넷째 폼 — 문의 폼이 실제로 전송되는지, 필수값 비우면 막히는지, 보낸 뒤 완료 안내가 뜨는지. 다섯째 접근성 — 마우스 없이 키보드 탭만으로 이동되는지, 이미지에 대체 텍스트가 있는지, 글자 대비가 충분한지.

통과 못 한 항목은 그 자리에서 표시하고, 고친 다음 같은 항목을 다시 확인합니다. '한 번 봤으니 됐다'가 아니라, 수정한 부분이 다른 곳을 망가뜨리지 않았는지까지 다시 도는 것이 QA입니다.

배포할 때 보안과 HTTPS는 어떻게 챙기나요?

검증을 통과한 사이트를 실제 주소로 내보내는 단계에서 보안 기본기를 확인합니다. 먼저 HTTPS — SSL 인증서를 적용해 주소창에 자물쇠가 뜨게 합니다. HTTPS가 없으면 브라우저가 '안전하지 않음'을 띄워, 방문자가 이름·연락처를 폼에 넣기를 망설입니다. 그다음 HTTP로 들어온 접속을 HTTPS로 자동 전환하고, HSTS로 브라우저가 처음부터 보안 연결만 쓰도록 합니다.

여기에 응답 헤더 몇 가지를 더합니다. X-Content-Type-Options로 파일 형식 오인을 막고, 기본 CSP(콘텐츠 보안 정책)로 허용한 출처의 리소스만 불러오게 해 변조와 혼합 콘텐츠를 줄입니다. 마지막으로 도메인 연결이 올바른지, 그리고 인증서가 만료 전에 자동 갱신되는지를 확인합니다. 인증서 갱신을 놓치면 어느 날 갑자기 사이트 전체가 경고 화면이 되기 때문에, 이 부분은 운영 파트가 캘린더가 아니라 자동화로 관리합니다. 이런 보안·기술 항목은 사후 관리에서도 계속 점검하며, 자세한 운영 범위는 유지·운영 안내에 정리했습니다.

저는 배포 직전에 아래 항목을 하나도 빠뜨리지 않았는지 칩 단위로 다시 훑은 뒤에야 '내보내기' 버튼을 누릅니다.

이 다섯 칩이 모두 초록일 때만 통과로 보고, 하나라도 걸리면 그 자리에서 멈추고 고친 다음 다시 처음부터 확인합니다.

오픈하면 분석 도구는 어떻게 세팅하나요?

사이트를 켜는 것과 동시에, '잘 되고 있는지 볼 수 있는 눈'을 붙입니다. 두 가지가 기본입니다. 구글 서치콘솔은 검색 쪽 눈입니다. 사이트맵을 제출해 페이지가 색인에 들어갔는지, 어떤 검색어로 노출되는지, 색인 오류는 없는지를 봅니다. GA4는 방문 쪽 눈입니다. 사람들이 어떤 경로로 들어와 어느 페이지에 머물고 어디서 나가는지, 그리고 문의 폼 제출 같은 전환 이벤트가 얼마나 일어나는지를 봅니다.

중요한 건 두 도구를 그냥 설치만 하는 게 아니라, '문의 폼 제출'을 전환 이벤트로 지정해 두는 일입니다. 그래야 방문 수가 아니라 실제 문의로 이어진 수를 셀 수 있고, 어떤 유입이 진짜 고객을 데려오는지 판단할 수 있습니다. 방문자를 문의로 바꾸는 설계 자체는 제작 단계에서 시작되며, 그 관점은 제작 단계에서 최적화를 심는 이유에서 다룹니다.

'오픈하고 끝'과 '운영 루프'는 무엇이 다른가요?

가장 큰 차이는 사이트를 한 번의 결과물로 보느냐, 계속 손보는 살아 있는 도구로 보느냐입니다. 만들고 방치한 사이트는 시간이 지나면 깨진 링크가 늘고, 검색 색인이 빠지고, 보안 패치가 밀리면서 발견성과 신뢰가 함께 떨어집니다. 반대로 운영 루프를 도는 사이트는 숫자를 보며 약한 페이지를 고치고, 장애를 사용자보다 먼저 잡습니다.

오픈 후 모니터링은 무엇을, 얼마나 자주 보나요?

사람이 매번 들여다보는 대신, 자동으로 도는 점검을 둡니다. 가동 모니터링은 일정 주기로 사이트에 접속해 응답이 없거나 느리면 운영 파트에 알림을 보냅니다. 폼 전송 실패나 화면이 멈추는 자바스크립트 오류도 로그로 모아, 방문자가 신고하기 전에 우리가 먼저 봅니다. 핵심은 사용자가 불편을 겪고 떠나기 전에 우리가 먼저 아는 구조를 만드는 것입니다.

여기에 더해 정기적으로 깨진 링크를 다시 훑고, 검색·AI 노출과 GA4 전환 숫자를 모아 보고합니다. 보안 패치와 백업도 주기적으로 돌려, 문제가 생겨도 빠르게 되돌릴 수 있게 해 둡니다.

제가 매주·매월 어떤 일을 어떤 도구로 도는지는 운영 루틴 표로 고정해 두고 그대로 실행합니다(주기·수치는 운영 기준 예시입니다).

표로 주기를 박아 두면 '바빠서 건너뛰는' 항목이 없어지고, 빠진 칸이 보이는 순간 바로 메우게 됩니다.

측정해서 알아낸 걸로 무엇을 고치나요?

숫자는 보는 게 아니라 고치는 데 씁니다. 예를 들어 GA4에서 특정 페이지의 이탈이 유독 높으면, 그 페이지의 첫 화면·버튼 위치·문구를 손봅니다. 서치콘솔에서 노출은 되는데 클릭이 안 되는 검색어가 보이면, 그 페이지의 제목과 설명을 다시 씁니다. 이렇게 측정 → 가설 → 수정 → 다시 측정을 한 바퀴로 돌립니다. 검색·AI 노출을 키우는 작업은 이 루프 안에서 이어지며, 그 방법은 검색·AI 노출은 이렇게 만듭니다에서 정리했습니다.

Findable은 제작·디자인·운영·QA를 한 팀에서 이어 가는 중소기업 전문 웹 에이전시입니다. 일하는 방식과 사람은 회사 소개에서 볼 수 있고, 지금 사이트의 검증·보안·운영 상태가 궁금하다면 무료 진단으로 시작하시면 됩니다.