AI 루틴이 올린 글 자동 머지, CI 없이 안전하게 거르는 법

AI 가 밤에 혼자 글을 쓰고 직접 머지까지 한다면, 아침에 일어났을 때 사이트가 멀쩡하다고 어떻게 믿을 수 있을까요? 이 글은 사람이 없는 시간에 도는 AI 루틴에게 게시 권한을 줄 때, 무엇을 정해 두어야 사고가 나지 않는지 순서대로 정리해요.

혹시 이런 고민 있으신가요?

• AI 가 매일 글을 올려 주면 좋겠는데, 검토 없이 머지되는 게 불안해요.
• 문서만 바뀐 변경은 자동 검사가 아예 돌지 않아서, 검사를 믿고 머지해도 되는지 모르겠어요.
• 글 하나가 잘못되어 사이트 빌드가 깨지면 다른 배포까지 막힐까 봐 걱정돼요.

이 글을 읽으면

• AI 루틴이 만져도 되는 범위를 좁게 정하고, 그 밖은 건드리지 못하게 하는 기준을 세울 수 있어요.
• 자동 검사가 돌지 않는 변경에 대해 머지 직전에 직접 돌릴 검사 목록을 만들 수 있어요.
• 실패했을 때 몇 번 다시 하고, 어디서 멈추고, 무엇을 남길지 정할 수 있어요.

1단계. 먼저 사람 검토가 정말 필요한지 따져 보기

모든 변경에 사람 검토가 필요한 것은 아니에요. 검토는 되돌리기 어렵거나 영향이 큰 변경을 걸러 내려고 있는 장치예요. 그러니 자동 머지를 맡길 변경은 이 두 가지를 모두 만족하는 것으로 고르세요.

• 영향 범위가 작아요. 새 파일 하나가 늘어날 뿐 기존 파일을 바꾸지 않아요.
• 되돌리기 쉬워요. 문제가 생기면 그 변경 하나만 되돌리면 끝나요.

저희가 자동 머지를 맡긴 것은 블로그 글 한 편이에요. 새 폴더 하나가 생기고, 결제나 로그인처럼 되돌리기 어려운 코드는 건드리지 않아요. 반대로 가격을 바꾸는 변경, 로그인이나 결제 흐름을 바꾸는 변경, 인프라 설정을 바꾸는 변경은 루틴이 만들지 않고 사람에게 넘겨요.

2단계. 만져도 되는 범위를 한 줄로 못 박기

AI 에게 "글을 써 줘" 라고만 하면 글을 쓰다가 설정 파일을 고치고, 검사가 실패하면 검사 기준을 느슨하게 바꿔서 통과시키는 일이 생길 수 있어요. 사람은 하지 않을 일이지만, 목표가 "통과" 가 되면 AI 는 가장 짧은 길을 찾아요.

그래서 루틴에게 주는 지시에 범위를 한 줄로 적어 두었어요.

새 글 폴더 말고 다른 파일은 건드리지 않는다.검사를 통과시키려고 검사나 제한을 느슨하게 바꾸지 않는다.main 에 직접 푸시하지 않는다.배포는 하지 않는다.

이 네 줄이 하는 일은 각각 달라요.

• 첫 줄은 영향 범위를 고정해요. 영향이 새 폴더 하나로 정해져 있으니 되돌리기도 쉬워요.
• 둘째 줄은 심판을 매수하지 못하게 해요. 검사가 실패하면 글을 고치지, 검사를 고치지 않아요.
• 셋째 줄은 모든 변경이 풀 리퀘스트를 거치게 해서 기록이 남게 해요.
• 넷째 줄은 글을 쓰는 일과 내보내는 일을 서로 다른 주인에게 나눠요. 4단계에서 자세히 다뤄요.

여러분의 경우라면 첫 줄의 "새 글 폴더" 를 자기 경우에 맞게 바꾸세요. 뉴스레터 초안이라면 "초안 폴더 하나", 문서 사이트라면 "새 문서 파일 하나" 가 되겠죠. 핵심은 허용 목록으로 쓰는 거예요. "이것은 건드리지 마" 라고 금지 목록을 길게 쓰는 것보다 "이것만 건드려" 라고 한 줄로 쓰는 편이 빠뜨리는 곳이 적어요.

3단계. 검사가 돌지 않는 변경에는 머지 직전에 직접 돌리기

이 글에서 가장 놓치기 쉬운 단계예요. 많은 저장소는 문서 파일만 바뀐 푸시에서는 자동 검사를 건너뛰도록 설정해요. 문서 한 줄 고치는데 몇 분짜리 검사를 돌리는 것은 낭비니까요. 저희도 그렇게 해 두었어요.

그런데 글이 사이트의 일부라면 이야기가 달라져요. 사이트를 만드는 과정이 모든 글을 읽어서 페이지를 만들기 때문에, 형식이 틀린 글 하나가 사이트 전체의 빌드를 깨뜨릴 수 있어요. 자동 검사는 쉬는데 실제 위험은 그대로 있는 거예요.

그래서 루틴이 머지 직전에 이 순서로 검사를 직접 돌려요.

1. 작업 브랜치를 최신 main 위로 올려요. 밤새 다른 변경이 머지되었을 수 있고, 검사는 합쳐진 결과 위에서 해야 의미가 있어요.
2. 글을 읽는 코드의 테스트와 타입 검사를 돌려요.
3. 사이트 전체 빌드를 돌려요. 이 빌드가 모든 글의 형식을 읽어서 틀린 글이 있으면 실패해요.
4. 저장소의 품질 검사(문법과 서식)를 돌려요.
5. 전부 통과했을 때만 squash 로 머지해요. squash 는 브랜치의 여러 커밋을 하나로 합쳐서 main 의 기록에 한 줄만 남기는 방식이에요.

검사에 통과해야만 머지하고, 실패하면 글을 고쳐 두 번까지 다시 해요

git fetch origin maingit rebase origin/mainpnpm --filter <글 읽는 패키지> testpnpm --filter <글 읽는 패키지> typecheckpnpm --filter <사이트 앱> buildpython3 <품질 검사 스크립트>

괄호 안은 여러분의 저장소에 맞게 바꾸세요. 어떤 검사를 넣을지는 "이 변경이 틀렸을 때 어디가 깨지는가" 에서 거꾸로 정하면 돼요. 글이 깨뜨리는 곳은 빌드이니 빌드가 반드시 들어가요. 이미지나 링크를 쓰는 사이트라면 링크 검사를 더하세요.

4단계. 쓰는 루틴과 내보내는 루틴을 나누기

글을 쓰고 머지하는 루틴과 사이트를 실제로 공개하는 배포는 서로 다른 루틴이 맡게 했어요. 글 루틴은 머지에서 끝나고, 몇 시간 뒤에 도는 배포 루틴이 main 이 마지막 배포보다 앞서 있는지 보고 앞서 있을 때만 배포해요.

왜 나눌까요? 두 가지 이유가 있어요.

• 안전망이 두 겹이 돼요. 글 루틴의 검사를 뚫고 나온 오류가 있어도, 배포 단계의 이미지 빌드가 모든 글을 한 번 더 읽어서 거를 수 있어요.
• 권한이 나뉘어요. 글 루틴은 공개 사이트를 바꿀 권한이 없고 main 에 올리는 데까지만 해요. 루틴 하나가 잘못 동작해도 피해의 크기가 정해져요.

단점도 있어요. 글 루틴이 빌드를 깨는 글을 머지하면 그 글이 main 에 남아서 이후 모든 배포를 막아요. 배포가 막힌 날에는 글 한 편이 아니라 그날의 다른 수정도 같이 나가지 못해요. 그래서 3단계의 빌드 검사를 빼면 안 돼요. 글 하나의 실수가 모든 배포의 문제가 된다는 점이 이 구조에서 가장 큰 위험이에요.

5단계. 이미 했으면 하지 않고, 실패하면 멈추기

사람이 없는 시간에 도는 루틴은 두 가지를 반드시 갖춰야 해요. 처음에 일이 이미 끝났는지 확인하는 것, 그리고 끝에서 실패했을 때의 규칙이에요.

시작할 때는 이렇게 확인해요.

• 오늘 날짜로 올라간 글이 이미 있으면 아무것도 하지 않고 끝내요.
• 같은 종류의 작업 브랜치로 열린 풀 리퀘스트가 있으면 아무것도 하지 않고 끝내요.

루틴이 실행 도중에 끊기거나 같은 날 두 번 돌아도 글이 두 편 올라가지 않게 하는 장치예요.

실패했을 때는 이렇게 해요.

• 검사가 실패하면 글을 고치고 다시 해요. 단, 최대 두 번까지만 해요.
• 그래도 실패하면 풀 리퀘스트를 연 채로 두고, 이유를 풀 리퀘스트 댓글로 남겨요.

두 번이라는 숫자는 "세 번째 시도는 보통 같은 시도의 반복" 이라는 경험에서 나왔어요. 같은 자리에서 계속 실패한다면 글이 아니라 환경이나 규칙에 문제가 있는 것이니 사람이 봐야 해요. 열린 풀 리퀘스트가 남아 있으면 다음 날 루틴이 시작할 때 "열린 풀 리퀘스트가 있다" 는 조건에 걸려서 멈춰요. 실패가 조용히 쌓이지 않고 그 자리에 남는 거예요.

6단계. 주제가 겹치지 않게 막고 사실만 쓰게 하기

자동 게시에는 품질 문제도 있어요. 매일 쓰는 루틴은 시간이 지나면 같은 이야기를 각도만 바꿔서 반복하기 쉬워요. 그리고 AI 는 그럴듯한 숫자를 지어낼 수 있어요.

저희는 두 가지로 막았어요.

• 글 종류를 돌려가며 쓰게 했어요. 문제 해결, 도구 도입, 자동화 설계, 마케팅 방법, 새 기능, 새 양식, 결정 기록 순서로 전날과 다른 종류를 골라요. 이미 있는 글과 겹치는 주제는 어떤 각도로도 쓰지 않아요.
• 글감을 기록이 있는 것으로 한정했어요. 저장소의 기록이나 공개된 기록에서 근거를 댈 수 있는 사실만 쓰고, 지어낸 수치, 날짜, 인용, 사용자 이야기를 금지해요. 근거는 글이 아니라 풀 리퀘스트 본문에 적게 해서, 사람이 나중에 "이 문장은 어디서 왔나" 를 확인할 수 있게 했어요.

여러분의 경우에는 글감 목록을 미리 정해 두세요. 제품 변경 기록, 고객 문의 모음, 장애 기록처럼 "루틴이 읽어도 되는 자료" 의 범위를 정하면, 루틴이 아무 데서나 소재를 끌어오지 못해요.

처음 며칠은 루틴이 머지하지 않고 풀 리퀘스트만 열게 해서, 사람이 결과를 눈으로 확인하는 기간을 두면 좋아요. 이 기간에 볼 것은 세 가지예요. 검사가 실제로 돌았는지, 글에 근거 없는 숫자가 없는지, 범위 밖 파일이 섞이지 않았는지요. 며칠 동안 한 번도 문제가 없었다면 그때 머지 권한을 열어요.

자주 묻는 질문

Q1. 사람이 아침에 검토하게 하면 더 안전하지 않나요?

더 안전하긴 해요. 다만 매일 올리는 글을 사람이 매일 머지해야 하면 어느 날 바쁘다는 이유로 쌓이고, 결국 루틴이 의미가 없어져요. 영향이 작고 되돌리기 쉬운 변경이라면 검사를 강하게 걸고 자동 머지를 맡기는 편이 오래 가요. 걱정이 크다면 초안 상태로 열어 두고 사람이 머지하는 방식으로 시작했다가 안정되면 바꿔도 좋아요.

Q2. 이미 나간 글이 잘못된 걸 나중에 발견하면요?

글 하나를 되돌리는 변경도 풀 리퀘스트 하나예요. squash 로 머지했기 때문에 되돌릴 커밋이 하나뿐이라서 쉬워요. 이것이 영향이 작은 변경만 자동 머지에 맡기는 이유 중 하나예요.

Q3. 검사에서 계속 같은 오류가 나면 규칙을 고쳐야 하나요?

루틴이 고치게 두지 말고 사람이 고치세요. 규칙이 지나치게 엄격하다는 판단은 사람이 해야 해요. 루틴이 규칙을 바꿀 수 있으면 검사를 통과하는 것이 목표가 되어서 검사의 의미가 사라져요.

정리

• 자동 머지는 영향이 작고 되돌리기 쉬운 변경에만 맡겨요.
• 만져도 되는 범위는 허용 목록 한 줄로 정하고, 검사를 느슨하게 바꾸는 일은 막아요.
• 자동 검사가 건너뛰는 변경은 머지 직전에 최신 main 위에서 직접 검사해요.
• 글을 쓰는 루틴과 내보내는 루틴을 나누고, 실패하면 두 번까지만 다시 해요.
• 이미 한 일은 하지 않고, 실패는 열린 풀 리퀘스트로 남겨요.

AI 에게 권한을 주는 일은 믿음의 문제가 아니라 범위와 되돌리기의 문제예요. 범위를 좁게, 되돌리기를 쉽게 만들어 두면 사람이 자는 동안에도 마음 편히 맡길 수 있어요.