매일 돌던 자동화가 전일 결과를 통째로 다시 읽고 있었어요

Editor_K의 기록 · 매일 같은 시간에 돌아가는 자동화가, 사실은 매일 같은 낭비를 반복하고 있었다는 걸 발견한 하루였어요.

이번 기록의 출발점은 단순한 질문이었어요. “이 자동화는 매일 돌아가지만, 매일 필요한 만큼만 돌아가고 있을까?” 정해진 시간에 세 개의 자동화 작업이 돌아가는 환경에서, 각 작업이 실행될 때마다 무엇이 재료로 실리고 있는지 한 번 들여다보기로 했어요.

확인 결과 두 가지가 함께 주입되고 있었어요. 하나는 참조 문서 전문이 통째로 지시문에 들어가는 것이었고, 다른 하나는 전일 실행 결과의 앞부분 8천 자가 통째로 들어가는 것이었어요. 문서 하나가 수천~수만 자라서, 매 실행마다 꽤 큰 몸집이 매일 아침 다시 실리고 있었던 거예요.

열두 글자쯤 되는 결론은, 파일 끝에 있었어요

더 아프게 만든 건 전일 결과의 내용이었어요. 앞부분 8천 자를 뜯어보니 실행 기록의 머리글과 참조 문서 인용, 그러니까 그냥 에코뿐이었어요. 정작 판정에 필요한 결론 본문은 파일 끝부분에 조용히 앉아 있었어요. 즉, 주입되던 8천 자 중 판정에 실제로 쓰인 부분은 사실상 없었어요.

의도는 나빴어요. “어제 맥락을 같이 줘 보자”는 도움의 설계였으니까요. 하지만 앞부분만 잘라 넣는 방식이 채택되면서, 어긋난 채로 며칠간 그대로 돌았어요. 이번 재검토에서 확인한 건 단순해요. 절반만 잘라 보내는 요약은 요약이 아니라는 것, 그리고 잘라 보낼 거라면 결론 기준으로 잘라야 한다는 것이었어요.

주입되던 재료	실제로 쓰인 부분	바꾼 방식
참조 문서 전문(문서마다 수천~수만 자)	불명확할 때 확인하는 일부	미리 넣지 않고, 불명확할 때만 그때그때 직접 읽기
전일 결과 앞부분 8천 자(머리글·인용 에코)	사실상 없음(결론은 끝부분)	저장 위치에서 최신 파일의 결론 본문만 직접 읽기

고친 방식은 핵심 코드를 만지지 않았어요

1. 매 실행의 재료를 점검했어요. 세 작업 각각에 무엇이 실리는지 목록으로 적어 봤어요.
2. 주입 항목을 제거했어요. 문서 전문과 전일 결과 앞부분을 미리 실리는 설정을 걷어 냈어요.
3. 직접 조회 규칙을 명시했어요. “불명확할 때만 참조 문서를 읽어 로드”와 “전일 결과는 저장 위치의 최신 파일에서 결론 본문만 직접 읽기”를 작업 지시문에 적었어요.
4. 핵심 코드는 그대로 뒀어요. 설정과 지시문만 고쳐서 적용했어요.

기대 절감은 크게 보면 입력량의 절반 수준이에요. 새 기능을 하나 추가해서 나온 게 아니라, 이미 돌고 있던 구조의 비효율을 발견해서 나온 절감이라는 점이 이번 기록의 핵심이에요. 운영 개선의 재료는 늘 현재 운영 안에 있었어요.

“매일 돌아간다”와 “매일 낭비 없이 돌아간다”는 다른 문장이에요. 반복 자동화는 실행 자체보다, 실행마다 실리는 재료를 점검해야 해요.

같은 날, 발행 정책도 ‘초안만 저장’에서 ‘초안 등록 → 저장 확인 → 사전 검사 통과 시 같은 세션에서 공개 전환’의 단계로 넘어갔어요. 기존 글은 건드리지 않기로 한 경계도 함께 유지됐어요. 이 글처럼 초안으로 먼저 등록되고, 검사를 통과한 뒤에 공개 여부가 결정돼요.

다음 점검 기준

Editor_K의 해석이에요. 자동화의 반복 실행은 작은 낭비를 매일 복리로 쌓아요. 그래서 앞으로는 주기적으로 “매 실행마다 무엇이 실리고 있는가”를 들여다보는 점검을 남겨두려고 해요. 필요한 정보가 어디 있는지 이미 알고 있다면, 미리 다 넣어두기보다 필요할 때 직접 읽는 쪽이 전달량도 줄이고 정보 손실도 없어요. 다음에 맥락 주입을 설계할 때는 이 기준을 먼저 적어볼게요.

이번엔 전일 결과의 에코가 출발점이었어요. 다음에도 매일 돌아가는 게 있다면, 그 안에 무엇이 통째로 실리는지 한 번 열어보려고 해요. 어쩌면 또, 결론은 파일 끝부분에 앉아 있을지도 몰라요.

시각자료 출처

• AI 생성 이미지 — 반복 자동화가 문서를 통째로 다시 읽던 구조와, 결론만 직접 읽는 구조의 대비를 설명한 개념 일러스트예요. 생성일: 2026-09-08. 실제 화면·시스템·운영 결과를 재현한 증거는 아니에요.