AI 코딩에서 마지막 확인은 생각보다 사람 일이다

코드가 바뀌었다고 끝난 건 아니었다

AI 코딩 도구를 쓰면 변경 속도가 빨라진다. 파일을 찾고, 패턴을 맞추고, 비슷한 컴포넌트를 복사해서 새 화면을 만드는 일은 확실히 편하다. 그런데 코드가 바뀌었다고 작업이 끝나는 건 아니었다. 진짜 확인은 그 뒤에 온다. 빌드가 되는지, 라우트가 생성되는지, sitemap과 feed에 들어가는지, 화면에서 문장이 너무 이상하지 않은지 봐야 한다.

특히 콘텐츠 사이트는 더 그렇다. 글 파일 하나를 추가해도 목록, 카테고리, 검색, sitemap, feed가 같이 움직인다. AI가 파일만 추가하고 끝내면 겉으로는 된 것 같지만 실제 발견 경로가 비어 있을 수 있다. 반대로 하네스가 통과해도 글이 너무 딱딱하면 사람은 금방 느낀다. 이 두 가지를 같이 봐야 한다.

한눈에 보는 마지막 확인

AI가 만든 결과를 볼 때 이제는 "괜찮아 보인다"로 끝내지 않고 다섯 칸으로 나눠 본다. 말이 자연스러운지보다, 실제 운영 표면에 남는 흔적이 있는지가 먼저다.

이 표는 거창한 검수 체계가 아니다. 실제로는 작업을 마치기 전에 내가 자주 놓치는 다섯 가지다. AI는 파일을 잘 바꾸지만, Search Console이 언제 새 sitemap을 다시 읽는지 알지 못한다. AI는 문장을 매끈하게 만들 수 있지만, 그 문장이 내가 실제로 한 운영 판단인지 알지 못한다. 그래서 마지막 한 번은 사람이 페이지를 열어 읽어야 한다.

AI가 잘하는 일과 사람이 끊어야 하는 일

AI가 잘하는 일은 분명하다. 기존 파일 구조를 찾고, 비슷한 frontmatter를 맞추고, 반복되는 표 형태를 만들고, 하네스 이름을 기억하고, 누락된 링크 후보를 찾아준다. 이런 일은 사람이 손으로 하면 금방 지친다. 그래서 AI를 쓰는 이유는 충분하다.

그런데 사람이 끊어야 하는 지점도 분명하다. 어떤 글을 대표 글로 남기고 어떤 글을 archive/noindex로 보낼지, 짧은 제작 메모를 새 글로 둘지 기존 제작 로그에 흡수할지, 정보 글이 기준일과 비교표를 갖췄는지, Play 링크가 자연스러운지 같은 판단은 AI가 대신 끝낼 수 없다. AI는 "비슷해 보이는" 결정을 잘 만든다. 사이트 운영에서는 그 비슷함이 위험할 때가 있다.

이 구분을 해두면 AI 코딩이 불안해서 못 쓰는 상태도 아니고, 아무 결과나 믿고 공개하는 상태도 아니다. 속도는 AI가 만들고, 경계는 사람이 잡는다. 지금 Bobob에서 필요한 것도 이 균형이다.

내가 마지막에 직접 보는 장면

AI가 만든 변경을 받을 때 가장 먼저 보는 것은 diff가 아니라 실제 페이지다. 파일이 예쁘게 바뀌어도 목록에서 제목이 어색하면 실패이고, route가 살아 있어도 검색 결과에서 설명이 비슷하면 실패다. 그래서 Blog 글은 `/blog`, category hub, 개별 글, sitemap, feed를 같이 본다. Play 글이면 관련 Play 링크가 왕복으로 이어지는지도 본다. 이 확인을 빼면 글 하나가 아니라 발견 경로 전체가 얇아진다.

특히 대표 글은 더 엄격하게 본다. 짧은 제작 메모처럼 하루치 감상만 남아 있으면 공개 목록에서 빼고, 제작 로그나 archive 후보로 보낸다. 대표 글로 남기려면 내가 실제로 바꾼 기준, 실패했던 화면, 다시 확인할 명령이 들어 있어야 한다. AI가 초안을 빠르게 만들 수는 있지만, 어떤 글을 sitemap에 남길지는 결국 운영자가 직접 정해야 한다.

이번 Blog + Play 정리에서도 이 차이가 컸다. 글이 많다는 사실은 장점처럼 보이지만, 짧은 메모가 공개 목록과 검색 결과에 너무 많이 보이면 오히려 사이트가 얇아 보인다. 그래서 작업은 "더 많이 만들기"가 아니라 "대표 글만 남기고, 짧은 메모는 제작 로그나 archive 후보로 흡수하기"가 됐다. 이 판단은 자동 생성으로 끝낼 수 없다. 실제 목록을 열어 보고, 처음 들어온 사람이 무엇을 먼저 보게 되는지 읽어야 한다.

Bobob에서 실제로 멈추는 다섯 곳

이 다섯 곳 중 하나라도 비면 "코드가 바뀐 것"과 "사이트 품질이 올라간 것"이 달라진다. 예를 들어 `publicationTier: representative`를 붙였다고 대표 글이 되는 것이 아니다. `/blog`에서 봤을 때 같은 말이 반복되면 대표 글이 아니다. `indexPolicy: noindex`를 붙였다고 약한 글이 사라지는 것도 아니다. 검색 결과나 category hub에 계속 나오면 사용자는 여전히 그 글을 먼저 본다.

그래서 마지막 확인은 파일 속성보다 공개 흐름을 우선한다. 사용자가 보는 목록, 크롤러가 보는 sitemap, feed 독자가 보는 item, Play에서 이어지는 결과 링크가 같은 방향을 가리켜야 한다.

AI 답변 근거 도장판으로 옮긴 이유

이 생각을 Play로 옮긴 것이 AI 답변 근거 도장판이다. 그 Play에서는 매끈한 답변을 그대로 믿지 않고, 경로 열림, 명령 출력, 원문 출처, 한계 표시가 비어 있는지 도장으로 가른다. 블로그에서 쓰는 마지막 확인과 같은 루틴을 30-60초짜리 작은 판으로 만든 셈이다.

중요한 것은 AI를 불신하는 게임이 아니라는 점이다. 근거가 남아 있으면 근거 남음 도장을 찍고, 없는 파일 경로, 실행 없는 완료 단정, 출처 없는 최신 정보, 새 의존성, 비밀값 노출처럼 다시 열어봐야 하는 신호가 있으면 다시 열어볼 도장을 찍는다. 실제 작업에서도 이 구분이 필요하다. 모든 답을 의심하면 일이 멈추고, 모든 답을 믿으면 사이트가 얇아진다.

그래서 이 글과 Play는 같은 기준을 공유한다. 빠른 초안은 환영한다. 다만 공개 페이지로 남기기 전에는 실제 경로와 명령 출력과 화면과 한계를 다시 본다.

이 Play가 필요한 이유도 "AI를 쓰지 말자"가 아니다. 오히려 AI를 더 많이 쓸수록 작은 확인 루틴이 필요하다. AI가 만든 답이 틀릴 때는 보통 아주 크게 무너지지 않는다. 파일명이 하나 틀리고, 최신 정보 기준일이 빠지고, 실행하지 않은 명령을 실행한 것처럼 쓰고, 관련 없는 내부 링크를 붙이는 식으로 작게 어긋난다. 작은 어긋남이 쌓이면 사이트는 금방 얇아 보인다.

그래서 근거 도장판에서는 답변을 통째로 맞다/틀리다로 보지 않는다. 경로가 있으면 경로 도장, 명령 출력이 있으면 출력 도장, 한계를 적었으면 한계 도장을 찍는다. 실제 작업에서도 같은 방식이 편하다. 모든 것을 다시 만들 필요는 없고, 공개 전에 빠진 도장만 채우면 된다.

다음 작업에 남기는 기준

다음에 AI 코딩으로 글이나 Play를 추가하면, 먼저 “이 페이지가 혼자 열려도 설명이 되는가”를 본다. 두 번째로 “다른 글과 같은 말을 반복하지 않는가”를 본다. 세 번째로 “검증 명령이 하나라도 남아 있는가”를 본다. 이 세 가지가 없으면 새 글을 만들지 않고 기존 대표 글에 흡수하는 편이 낫다.

이 기준은 귀찮지만 사이트를 얇게 보이지 않게 만드는 최소선이다. 빠르게 만든 페이지일수록 마지막에 사람이 한 번 더 줄이고, 연결하고, 실제 URL로 열어봐야 한다.

실제 마감에서는 아래 순서로 멈춘다.

이 순서를 다 지켜도 외부 색인은 바로 따라오지 않는다. 그래서 마지막 줄이 중요하다. 로컬에서 품질을 올린 것, production에 배포된 것, Search Console이 발견한 것, 사람이 다시 신청할 준비가 된 것은 서로 다른 단계다. AI가 만든 결과를 사람 일이 되게 만드는 지점은 바로 이 구분이다.

내 기준으로 좋은 AI 코딩 마감은 "전부 자동으로 끝났다"가 아니다. 무엇을 자동으로 처리했고, 어디서 사람이 멈췄고, 어떤 명령과 화면으로 확인했는지가 남아 있는 상태다. Bobob이 지금 보여줘야 하는 것도 그쪽이다. 많이 만든 사이트가 아니라, 만든 사람이 계속 보고 고치는 사이트.