AI 코딩에서 위험한 순간은 코드가 만들어지는 순간보다 배포 직후입니다. 로컬 테스트와 빌드가 모두 통과해도, 실제 도메인에서는 데이터 연결, 캐시, 라우팅, 브라우저 실행 환경, 공개 문구 같은 이유로 다른 결과가 나올 수 있습니다. 그래서 AI에게 구현을 맡겼다면 배포 후에도 사람이 읽을 수 있는 검증 증거를 남겨야 합니다.

이 글은 한 가지 실전 문제를 다룹니다. 'AI가 만든 변경을 서비스에 올린 뒤 무엇을 확인해야 배포를 끝냈다고 말할 수 있는가'입니다. 답은 거창한 모니터링 체계를 새로 만드는 것이 아니라, 배포 상태, 대표 경로, 콘솔 오류, 공개 금지어, 롤백 기준을 짧고 반복 가능한 라이브 스모크 루프로 묶는 것입니다.

핵심 결론

AI 코딩 작업은 배포 성공 알림이 아니라 라이브 검증 증거로 끝나야 합니다. 최소 루프는 다음 다섯 문장으로 정리할 수 있습니다.

1. 배포 상태가 성공인지 확인한다.
2. 사용자가 실제로 들어가는 대표 경로가 정상 응답하는지 확인한다.
3. 새로 만든 상세 페이지나 수정한 화면에서 핵심 문구가 보이는지 확인한다.
4. 브라우저 콘솔 오류와 공개 금지어 노출이 없는지 확인한다.
5. 실패하면 어떤 조건에서 되돌릴지 롤백 기준을 미리 적용한다.

초보자에게 라이브 스모크는 '배포된 진짜 사이트를 짧게 눌러 보는 확인'입니다. 실무자에게는 '배포가 끝났다는 주장에 붙는 최소 증거'입니다. AI가 빠르게 고칠수록 이 루프는 더 중요해집니다.

왜 중요한가

로컬 통과와 실제 서비스 성공은 다르다

로컬 환경은 개발자 컴퓨터 안의 조건입니다. 실제 서비스는 도메인, 배포 캐시, 서버 환경, 브라우저, 네트워크가 함께 작동합니다. 로컬에서 보이지 않던 404, 빈 목록, 깨진 링크, 자바스크립트 실행 오류가 라이브에서만 나타날 수 있습니다.

특히 AI 코딩은 변경 속도가 빠릅니다. 작은 수정처럼 시작했는데 라우팅, 메타데이터, 데이터 로딩, 렌더링 구조가 함께 바뀌기도 합니다. 이때 배포 직후 확인이 없다면 사용자가 먼저 문제를 발견합니다.

AI 보고서는 증거가 아니라 주장일 수 있다

에이전트가 '검증 완료'라고 말해도 실제 도메인을 열어 보지 않았다면 아직 주장에 가깝습니다. 좋은 배포 보고는 구체적인 증거를 포함합니다. 예를 들어 어떤 대표 경로를 확인했는지, 어떤 상세 페이지에서 핵심 문구를 봤는지, 콘솔 오류가 있었는지, 공개 금지어 스캔 결과가 어땠는지 적어야 합니다.

실제 작업 순서

1단계: 배포 상태를 먼저 확인한다

배포 직후에는 새 커밋이 실제 서비스에 반영됐는지 확인합니다. 단순히 푸시가 성공했다는 사실만으로는 부족합니다. 배포 플랫폼이 빌드를 실패했거나, 아직 이전 배포가 서비스 중일 수 있기 때문입니다.

확인할 것은 세 가지입니다.

• 방금 올린 변경의 커밋이 배포 대상인지
• 배포 상태가 성공인지
• 라이브 페이지에서 새 글 제목이나 수정한 문구처럼 이번 변경의 표시가 보이는지

이 단계에서 실패하면 더 깊은 브라우저 확인으로 넘어가지 않습니다. 먼저 배포 실패 원인을 확인하거나, 사용자가 보는 화면이 이전 버전인지 판단해야 합니다.

2단계: 대표 경로를 작게 고른다

모든 페이지를 다 열어 보려 하면 루프가 무거워져서 결국 생략됩니다. 대신 이번 변경과 관계있는 대표 경로를 3개에서 5개 정도 고릅니다. 예를 들어 VIBE 코딩 글을 추가했다면 홈, VIBE 코딩 목록, 새 상세 페이지가 기본입니다. Q&A나 Hermes처럼 공통 내비게이션 영향을 받을 수 있는 주요 경로도 함께 확인하면 좋습니다.

대표 경로는 '많이 쓰는 페이지'와 '이번 변경이 직접 닿는 페이지'를 섞어야 합니다. 목록만 확인하면 상세 페이지 404를 놓치고, 상세만 확인하면 섹션 카드나 링크 오류를 놓칩니다.

3단계: 콘텐츠 마커를 확인한다

상태 코드가 200이어도 내용이 맞다는 뜻은 아닙니다. 새 글이라면 제목, 섹션 이름, 핵심 문구처럼 실제 화면에 보여야 하는 콘텐츠 마커를 확인합니다. 수정 글이라면 바뀌어야 할 문장과 사라져야 할 문장을 함께 봅니다.

좋은 콘텐츠 마커는 화면에 안정적으로 렌더링되는 짧은 문구입니다. 너무 긴 본문 문장이나 접힌 영역의 텍스트만 기준으로 삼으면 확인이 불안정해집니다.

4단계: 브라우저 콘솔 오류를 본다

라이브 스모크에서 가장 자주 빠지는 항목이 브라우저 콘솔입니다. 서버 응답은 정상인데 클라이언트 코드가 실행 중 오류를 내면 사용자는 버튼, 펼침 패널, 링크 이동에서 문제를 만납니다. 자동 HTML 스캔만으로는 이런 오류를 충분히 확인하기 어렵습니다.

최소한 새 상세 페이지 하나는 실제 브라우저로 열고 콘솔 오류를 확인합니다. 오류가 있다면 단순 경고인지, 기능 실패로 이어지는 오류인지 구분해 보고에 남깁니다.

5단계: 공개 금지어와 롤백 기준을 함께 본다

AI 코딩 작업은 내부 설명을 공개 문구로 옮겨 버리는 실수가 생길 수 있습니다. 그래서 공개 금지어 스캔은 보안 담당자만의 일이 아니라 콘텐츠 배포 루프의 일부입니다. 내부 시스템 이름, 비밀값을 떠올리게 하는 표현, 관리자 조작 라벨, 로컬 파일 경로처럼 사용자가 볼 필요 없는 단어를 확인합니다.

롤백 기준도 이때 같이 적용합니다. 예를 들어 대표 경로가 500을 반환하거나, 새 상세 페이지가 404이거나, 공개 금지어가 실제 페이지에 노출되거나, 콘솔 오류가 핵심 기능을 막으면 배포 완료가 아니라 복구 작업으로 전환합니다.

상황별 예시

새 VIBE 코딩 글을 배포한 경우

새 글을 추가했다면 목록과 상세를 같이 확인합니다. 목록에서는 카드 제목과 요약이 보이는지 봅니다. 상세에서는 본문 섹션, FAQ, 공유 메타데이터, 관련 링크가 정상인지 확인합니다. 이때 대표 경로는 홈, VIBE 코딩 목록, 새 상세 페이지가 됩니다.

실무 팁은 새 글의 제목 하나만 보지 않는 것입니다. 목록에 글이 보이지만 상세가 404일 수 있고, 상세는 열리지만 목록 정렬이 오래된 순서일 수 있습니다. 두 화면을 같이 봐야 합니다.

기존 기능을 고친 경우

기존 기능 수정은 '고친 화면'과 '영향받을 수 있는 주변 화면'을 같이 봅니다. 예를 들어 카드 컴포넌트를 고쳤다면 해당 섹션의 목록뿐 아니라 같은 카드를 재사용하는 다른 섹션도 한두 개 확인합니다. AI가 공통 컴포넌트를 바꿨을 때 한 화면만 좋아지고 다른 화면이 깨지는 일을 막을 수 있습니다.

운영 문구를 바꾼 경우

운영 문구나 공개 안내를 바꿨다면 공개 금지어 스캔이 더 중요합니다. 작업 중에는 내부적으로 편한 말을 쓰더라도, 공개 화면에는 방문자가 이해할 수 있는 말만 남아야 합니다. '사용자가 이 문장을 보면 무엇을 하라는 뜻인지 알 수 있는가'를 기준으로 읽으면 좋습니다.

실수와 주의점

푸시 성공을 배포 성공으로 착각한다

푸시는 저장소에 변경을 올리는 일이고, 배포 성공은 실제 서비스가 새 버전으로 열리는 일입니다. 둘은 다릅니다. 푸시 뒤 배포 상태를 확인하지 않으면 실패한 빌드나 지연된 배포를 놓칩니다.

상태 코드만 보고 끝낸다

200 응답은 페이지가 열렸다는 뜻이지 내용이 맞다는 뜻은 아닙니다. 콘텐츠 마커, 콘솔 오류, 공개 금지어를 같이 봐야 합니다. 특히 AI가 만든 글이나 UI는 문구 품질과 내부 표현 노출까지 확인해야 합니다.

롤백 기준을 장애가 난 뒤 정한다

문제가 보인 뒤에 되돌릴지 말지 논의하면 시간이 늘어납니다. 배포 전에 어떤 실패를 롤백 조건으로 볼지 정해 두면 판단이 빨라집니다. 대표 경로 실패, 핵심 상세 404, 내부 표현 노출, 기능 차단 콘솔 오류는 강한 롤백 후보입니다.

루프를 너무 크게 만든다

처음부터 모든 것을 자동화하려고 하면 실행이 느려지고 유지가 어렵습니다. 먼저 작은 수동 루프를 안정적으로 반복하세요. 이후 자주 보는 대표 경로와 금지어 스캔만 자동화해도 효과가 큽니다.

검증 체크리스트

• 배포 상태가 성공이고 새 커밋의 변경이 라이브에서 확인된다.
• 홈, 섹션 목록, 변경 상세처럼 대표 경로가 정상 응답한다.
• 새 글이나 수정 화면의 콘텐츠 마커가 실제 HTML 또는 브라우저 화면에 보인다.
• 브라우저 콘솔 오류가 없거나, 기능에 영향 없는 경고로 분류됐다.
• 공개 금지어, 내부 경로, 비밀값을 떠올리게 하는 문자열이 공개 HTML에 없다.
• 문제가 생겼을 때 적용할 롤백 기준과 담당 액션이 분명하다.
• 최종 보고에는 확인한 경로, 발견한 위험, 다음 조치가 짧게 남아 있다.

다음 단계

처음에는 배포마다 같은 표를 복사해 쓰는 것만으로 충분합니다. 경로, 기대 마커, 실제 결과, 콘솔 오류, 금지어 스캔, 롤백 판단을 한 줄씩 남기세요. 같은 확인을 세 번 이상 반복하게 되면 그때 자동 스크립트나 테스트로 옮기면 됩니다.

AI 코딩의 장점은 빠른 구현입니다. 하지만 빠른 구현은 빠른 검증과 같이 있을 때만 운영 품질이 됩니다. 다음 작업에서는 에이전트에게 '코드를 고쳐라'만 요청하지 말고, 배포 후 라이브 스모크 증거까지 남기라고 요구해 보세요. 그러면 AI의 속도와 사람의 책임 있는 판단을 같은 루프로 묶을 수 있습니다.