브리핑을 한 번 보내는 데 성공했으니 예약만 걸면 될 줄 알았습니다. 그런데 다음에는 오지 않았습니다. 어떤 때는 실행 화면에 성공이라고 떠도 받아 볼 결과가 없었습니다. “성공”이라는 표시와 제가 원한 결과는 같은 것이 아니었습니다.
문제를 세 군데로 나누니 살펴볼 순서가 보였습니다. 예약이 시작됐는지, 필요한 자료가 모였는지, AI가 자료에 맞는 답을 썼는지입니다.
이 글은 당시 구축 과정의 문제와 개선 방법을 정리했습니다.
1. 안 왔다면 예약 실행 기록부터 봅니다
2026년 6월 1일의 기존 기록에서는 예약 실행 이력이 없고, 이전의 수동 실행 이력만 확인됐습니다. 설정이 켜져 있다는 표시만 보고 자동화까지 끝났다고 생각한 것이 문제였습니다.
시험 중에는 노드 이름을 바꿨는데 연결 정보에 옛 이름이 남아 시작 부분만 움직인 경우도 있었습니다. 뒤의 브리핑 생성과 발송은 실행되지 않았습니다.
전체 상태만 보기보다 어떤 단계가 실제로 실행됐는지 살펴봐야 했습니다.
다시 확인할 때는 시작 시각, 실행된 노드, 생성한 결과, 발송 응답을 순서대로 봤습니다. 예약 시각과 시간대 설정을 확인하고, 그 시각에 시작된 실행 기록에서 마지막 결과까지 따라가는 방식입니다.
2. AI보다 먼저 자료가 들어왔는지 봅니다
AI가 정리할 원자료가 없으면 그럴듯한 문장을 받아도 도움이 되지 않습니다. 날씨가 수집됐는지, 기사의 링크가 유효한지, 숫자에 기준 시각이 있는지를 먼저 확인해야 했습니다.
자료마다 갱신 시각도 다릅니다. 오후에 만든 브리핑이라고 안의 자료가 모두 그 순간 최신인 것은 아닙니다.
받지 못한 항목은 “자료 없음”이나 “확인 필요”로 남겨 두어야, 독자가 오래된 자료를 새 소식으로 오해하지 않습니다.

3. 외부 AI는 정리할 자료를 함께 받습니다
이 브리핑에서는 NAS가 모은 자료를 클라우드 AI에 보내 문장을 정리하게 했습니다. 큰 AI 모델을 NAS 안에서 직접 실행하는 방식과는 다릅니다.
따라서 NAS에 설치했다고 자료가 모두 NAS 안에만 남는 것도 아닙니다.
구축 당시에는 제공사에서 시험할 수 있는 모델을 연결했습니다. 모델 목록에 보인다고 내 계정에서 호출까지 가능한 것은 아니었고, 실제 요청이 실패한 경우도 있었습니다.
먼저 작은 요청으로 응답을 확인하고 결과 형식을 확인하는 과정이 필요했습니다.
당시 무료 제공 범위를 활용했다는 경험을 현재의 무제한 무료 운영 방법으로 받아들이면 안 됩니다. NVIDIA API Catalog 같은 평가 서비스는 계정·모델별 제한과 평가·운영 이용 조건이 적용됩니다.
계속 운영할 때는 현재 약관과 이용 범위를 별도로 확인해야 합니다.
4. 유창한 문장보다 숫자와 근거를 봅니다
요약은 잘 읽히지만 원문에 없는 이유를 덧붙일 수 있습니다. 예를 들어 지수가 올랐다는 숫자만 받았는데 “정책 기대감 때문”이라고 설명하면, 그 이유를 뒷받침하는 자료가 더 필요합니다.
그래서 수집된 자료에 있는 사실과 연결되는지 확인하고, 근거가 없는 설명은 빼거나 기본 요약으로 바꾸도록 구성했습니다. 모델에게 “정확하게 써 줘”라고 부탁하는 것만으로 검사가 끝나는 것은 아닙니다.
같은 기준을 영상 추천에도 적용했습니다. 그럴듯한 제목이나 주소를 만들어 내는 대신 수집한 후보 안에서 골라야 했습니다.
사람이 실제 링크를 열어 보는 확인도 필요했습니다.
5. AI가 실패했을 때의 결과도 준비했습니다
외부 모델은 연결이 끊기거나 응답이 늦거나 정해 둔 형식과 다른 답을 줄 수 있습니다. 당시에는 첫 모델과 예비 모델을 시도하고, 사용할 수 없으면 수집 자료와 정해진 규칙으로 만든 기본 요약을 쓰는 흐름을 마련했습니다.
여기서 기본 요약은 없는 사실을 대신 지어내는 기능이 아닙니다. 받은 자료 안에서만 만든 결과입니다.
자료 자체가 부족하면 그 상태를 표시하거나 발행을 멈추는 조건이 따로 필요합니다.
또 실제 프로그램은 실패했는데 실행 관리 화면에는 성공으로 남는 문제가 있었습니다. 작업과 발송이 끝난 뒤 실패 상태를 확인하는 처리를 더했습니다.
오류를 감추지 않고 어느 단계에서 멈췄는지 남기는 일이, 겉으로 성공처럼 보이게 하는 것보다 중요했습니다.
6. 다음에 같은 일이 생기면 이 순서로 봅니다
- 시작: 예약 시각과 실행 기록이 맞는지 봅니다.
- 입력: 자료 수와 기준 시각, 누락 항목을 봅니다.
- 출력: 답변이 원자료와 맞고 링크가 열리는지 봅니다.
- 전달: 마지막 발송 응답과 실제 도착을 확인합니다.
한 번 고쳤다고 영원히 끝나지는 않았습니다. 그래도 이 순서를 정해 두니 “왜 안 됐지?”라는 큰 질문을 작은 확인으로 나눌 수 있었습니다.
다음 편에서는 이렇게 다듬은 브리핑을 오전과 오후에 어떻게 읽었는지 보여 드립니다.
1부: PC를 꺼도 소식 받기 · 3부: 오전·오후 브리핑을 읽는 방법
공식 참고: n8n 오류 처리 · NVIDIA API Catalog 시작 안내 · NVIDIA API 평가 이용 조건
최초 작성 2026년 9월 7일 · 재정리 2026년 10월 16일. 당시 공개한 구축 사례이며 현재 모든 예약 실행의 정상 동작을 보장하는 글은 아닙니다.
표지·도식은 설명용 생성 이미지입니다.