Copilot 글을 세 번 돌리고서야 발표일을 본 날

Copilot 발표를 새 소식으로 전하려고 AI가 글을 쓰는 작업을 세 번 실행했어요. 첫 실행에 10.3분과 Claude 최종 검수 비용 US$0.93이 들었지만, 세 번 모두 공개에 이르지 못했어요.

무슨 상황이었냐면요. 이 블로그에서는 Codex가 공식 출처의 새 글을 후보로 모아 원고·조사 기록·이미지를 준비해요. Claude가 원문과 대조해 최종 검수하고, 사이트 검사는 글의 문장과 링크 등을 확인해요. 이미지 업로드까지 마치면 실행기가 공개해요. 사람도 발행 기준에 맞지 않는 후보를 멈출 수 있어요. 이번에는 출처에서 글을 처음 발견한 날짜와 발표 자체의 날짜가 어긋난 채 원고 작성부터 시작됐어요.

처음 두 번은 서로 다른 곳에서 실제로 멈췄어요. 그래서 문장 검사와 이미지 업로드를 고치면 끝날 문제처럼 보였죠. 그런데 세 번째에는 글의 출발점인 발표일과 한국 제공 범위를 사람이 확인하고 발행을 멈췄어요. 그제야 앞의 두 오류와 별개로, 왜 나흘 지난 발표가 새 소식 후보에 들어왔는지를 되짚게 됐어요.

먼저 의심한 것은 문장 검사였어요

9월 29일 오후 4시, AI 소식 작업은 Microsoft Copilot의 Home·Code·Autopilot 발표를 새 글감으로 골랐어요. Codex가 원고와 대표 이미지·작은 썸네일·공유 이미지를 준비했고 Claude 최종 검수도 거쳤어요. 이 첫 실행은 10.3분 동안 진행됐지만 사이트 검사에서 멈췄어요. 실행 요약은 “사이트 검사를 통과하지 못해 공개하지 않았습니다”라고 적었고, 검사 출력에는 “3번 이하로 줄이고 독자가 할 일이나 알게 된 사실로 바꾸세요”라는 지시가 남았어요. 반복된 단서·경고 표현을 줄이라는 뜻이에요. 남은 요약만으로 어떤 문장들이 모두 걸렸는지까지는 확정하기 어려워요.

첫 멈춤은 문장 검사 문제로 읽혔고, 오후 4시 15분 13초 수동 재실행 계획에도 “3번 이하로 줄일 것”이라고 적었어요. 두 번째 실행에서는 원고 작성과 오프라인 사이트 검사를 마쳤지만 미디어 업로드에서 멈췄어요. 실행 기록의 분류는 “미디어 업로드 실패”이고 소요 시간은 4.7분이에요. 오프라인 검사를 통과한 글도 이미지를 올리는 단계에서 멈출 수 있다는 걸 보여 주는 기록이에요.

그사이 오후 4시 16분 운영 점검은 진행 중이던 두 번째 실행을 “끝나지 않음” 문제로 읽었어요. 점검 시각인 16:16:54에도 실행 기록 파일이 갱신되고 있었어요. 점검 기록은 이를 진행 중 실행을 실패로 본 오탐으로 판단하고 개입하지 않았어요. 잠금 파일에 남은 실행 번호는 두 번째 실행과 같았지만, 잠금에 적힌 프로세스가 살아 있는지까지는 확인하지 못했다고 적었어요. 이 오탐은 두 번째 실행의 최종 업로드 실패와도, Copilot 발표의 발행 적합성과도 다른 문제예요.

이후 업로드 실패 이유는 16:20:44 KST 커밋 26700ec의 메시지에 남았어요. 아직 공개되지 않은 글의 표지를 올릴 때, 이전 실행이 같은 이름으로 올린 이미지가 남아 있으면 --no-clobber 옵션이 덮어쓰기를 막았어요. 이름이 같은 파일을 보존하는 옵션인데, 이 경우에는 새 표지가 올라가지 않아 확인 단계에서 실패했다는 설명이에요. 수정은 미공개 글의 이미지만 다시 올릴 수 있도록 했어요. 문장 검사와 업로드는 각각 실제 중단 지점이었지만, 낡은 발표가 새 후보로 들어온 경로까지 설명해 주지는 않았어요.

오후 4시 20분 세 번째 실행을 걸었다가 공개 전에 사람이 멈췄어요. 실행은 1.2분 걸렸고, 기록의 이유는 그대로 이렇습니다.

발행 기준(4일 지난 발표·한국 미제공 프리뷰)에 맞지 않아 공개 전에 사람이 멈춤

Copilot 새 소식 원고는 이때도 공개되지 않았어요. “프리뷰”는 정식 제공 전에 일부 이용자에게 먼저 여는 기능이에요. 당시 한국에서 제공되지 않는 프리뷰라는 판단이 중단 기록에 남았어요. 첫 실행의 문장 검사나 두 번째 실행의 이미지 오류를 고쳐도, 9월 25일 발표를 9월 29일의 새 발표처럼 소개하는 문제는 남아 있었어요. 앞의 두 실패를 해결하는 일과 이 글을 발행해도 되는지 판단하는 일은 서로 달랐어요.

진범은 처음 수집한 날짜 범위였어요

시간을 첫 실행보다 앞선 때로 돌려 봐야 해요. 그날 14:20:20 KST 커밋 39f7a18에서 공식 소식 출처를 10곳에서 18곳으로 늘렸어요. 새 출처를 처음 읽을 때 날짜가 있는 글 중 최근 7일 안의 항목을 후보로 넘기는 설정이 있었어요. Microsoft 출처의 목록에는 9월 25일 발표가 있었고, 9월 29일에 이 목록을 처음 읽은 작업은 이를 새 후보로 받았어요. 첫 실행 계획의 출처 주소에는 2026/09/25가, 재실행 계획에는 “9월 25일”이 적혀 있었어요. 날짜가 숨어 있던 것은 아니에요. 수집기에 처음 잡혔다는 뜻의 “새 후보”와 독자에게 오늘 전할 “새 발표”를 같은 말처럼 다룬 게 문제였어요.

9월 29일 16:25:36 KST 커밋 86d88ba는 수집 범위를 7일에서 3일로 바꿨어요. 당시 위험한 기본값과 수정된 한 줄은 다음과 같아요.

// 이전: export async function collectFeeds(repo, stateDir, { recentDays = 7 } = {}) {
export async function collectFeeds(repo, stateDir, { recentDays = 3 } = {}) {

collectFeeds는 공식 출처의 글을 모으는 함수이고, recentDays는 새 출처를 처음 읽을 때 며칠 전 항목까지 후보로 넘길지를 정하는 값이에요. 커밋 메시지는 “새 출처의 과거 글은 최근 3일치만 후보로(7일이면 4일 지난 Copilot 발표가 새 소식으로 올라옴)”라고 이유를 남겼어요. 같은 커밋은 발표 3일 초과 소식이나 한국에서 지금 쓸 수 없는 프리뷰·한정 프로그램 발표를 새 글 대신 보류하는 지침도 더했어요. 16:54:05 KST 커밋 074029f는 사람이 멈춘 세 번째 실행을 ‘중단’ 상태로 마무리하고, 의도한 중단을 운영 문제가 아닌 것으로 다루도록 정리했어요.

여기서 확인된 원인은 나흘 지난 발표가 후보로 들어온 경로예요. 첫 두 실행에서 누가 어떤 순서로 날짜 판단을 뒤로 미뤘는지는 실행 요약만으로 확정할 수 없어요. 3일 제한은 후보를 줄이는 장치이지 발표일과 제공 범위를 판정하는 장치는 아니에요. 이 사건에서 필요한 마지막 판단은 “목록에 언제 들어왔나”와 “발표가 언제였고 지금 한국에서 쓸 수 있나”를 따로 보는 일이었어요.

남은 흔적의 숫자를 읽어 보면

10곳 → 18곳 출처 → 첫 수집 7일 범위 → 9월 25일 발표를 29일에 발견 → 16:00 문장 검사 정지 → 16:15 이미지 업로드 실패 → 16:20 사람의 중단 → 16:25 수집 범위 3일 → 16:54 중단 상태 정리 순서였어요. 10곳과 18곳은 확인하는 출처 수예요. 7일과 3일은 출처를 처음 읽을 때 항목을 후보로 넘기는 기간이고, 발행을 허락하는 기간은 아니에요. 출처가 늘자 새로 발견할 수 있는 과거 글도 늘었고, 그중 하나가 이번 발표였어요.

첫 실행의 10.3분은 원고 준비부터 검수와 검사까지 걸린 전체 시간이에요. US$0.93은 그 실행의 Claude 최종 검수 비용으로 기록된 금액이고, 세 실행의 총비용을 뜻하지 않아요. 두 번째 실행은 4.7분 뒤 미디어 업로드 실패로 끝났고, 세 번째는 1.2분 뒤 사람이 중단했어요. 세 번은 공개 횟수가 아니라 실행 횟수예요. 공개된 Copilot 새 소식 글은 0편이에요. 16:16 운영 점검의 “끝나지 않음”은 그 시점의 실패 확정이 아니라 진행 중인 작업을 잘못 읽은 표시였어요.

그 뒤 이 사건을 복기한 이 에피소드는 9월 30일 08:00 발행 실행에 기록됐고 11:21, 12:07 수정 실행에서 경과와 근거를 보강했어요. 멈췄던 Copilot 새 소식 원고가 뒤늦게 공개됐다는 뜻은 아니에요. 08:00은 발행 작업의 시작 시각이고 실제 공개 완료 시각은 기록에서 확인되지 않았어요.

발견한 날과 발표한 날을 나눠야 해요

출처를 처음 등록한 날은 수집 시스템에 항목이 들어온 날이에요. 독자에게 새 소식인지 판단할 때 필요한 날짜는 발표 자체가 일어난 날이에요. 이번에는 “우리가 오늘 처음 봤다”가 “오늘 발표됐다”로 넘어갔어요. 새 출처를 더한 직후라면 과거 글이 한꺼번에 들어올 수 있다는 점을 먼저 의심해야 해요. 여기에 한국 제공 범위까지 분리해 봐야 지금 독자가 할 수 있는 일이 있는지도 판단할 수 있어요.

자동 검사는 문장이나 링크 같은 결함을 잡고, 미디어 업로드는 이미지를 보내요. 둘 다 통과해도 발표 시점과 제공 범위의 판단은 따로 남아요. 앞 단계에서 멈췄다는 사실만으로 글감이 적합한지 알 수는 없어요. 이 사건에서는 문장 검사 수정 계획, 업로드 오류 수정, 진행 중 실행을 읽는 운영 점검까지 각각 다른 문제를 다뤘어요. 해결해야 할 층이 달라서 어느 한 오류를 고쳤다는 기록을 발행 가능하다는 증거로 읽으면 다시 같은 글에 시간을 쓰게 돼요.

그래서 하지 말아야 할 것

첫째, 새 출처에서 가져온 글을 곧바로 “오늘의 발표”로 쓰지 않으려 해요. 후보마다 발표일과 처음 발견한 날을 따로 적으면 나흘 전 발표가 오늘의 소식처럼 올라오는지 볼 수 있어요. 출처를 늘린 직후라면 이 날짜 대조를 원고 작성 전에 해야 해요.

둘째, 검사 오류를 고쳤다는 기록을 글감까지 검증했다는 신호로 읽지 않으려 해요. 문장 검사, 업로드, 날짜·제공 범위 판단 중 어디서 멈췄는지 실행 기록에서 먼저 확인하면, 재실행으로 해결할 문제인지 글감부터 다시 볼 문제인지 구분할 수 있어요.

셋째, 프리뷰의 한국 제공 여부를 원고 작성 전에 확인하려 해요. 발표가 최근이어도 한국 독자가 지금 쓸 수 없는 기능이라면 새 소식으로 쓰는 이유가 약해져요. 이 사건의 중단 기록처럼, 제공 범위를 확인한 뒤 보류할 수 있어요.

넷째, 수집 기간을 줄인 뒤에도 날짜와 제공 범위를 발행 전에 다시 보려 해요. 7일을 3일로 바꾼 것은 후보가 들어오는 폭을 좁힌 것이지 검수를 대신한 것이 아니에요. 여러분의 수집기에서도 기간 설정을 바꾼 커밋과 그 뒤 첫 실행의 후보 목록을 나란히 놓고, 바뀐 기간 밖의 발표가 여전히 들어오는지 확인해 보세요.

마치며

이번에 가장 늦게 본 것은 날짜 자체가 아니라, 이미 적혀 있던 날짜의 뜻이었어요. 여러분의 소식 수집에서도 “처음 본 날”과 “발표한 날”을 따로 기록하고 있나요?