한 번 됐으니 이제 되겠지 싶었는데, 다음에 또 막혔습니다. 그래도 고칠 때마다 조금씩 나아졌어요.
1부에서 필요한 정보를 모아 카카오톡으로 보내는 데까지 연결했습니다. 이제 예약만 걸어 두면 되겠구나 싶었어요. 하지만 실제로 쓰기 시작하니 예상하지 못한 곳에서 자꾸 걸렸습니다. 올 시간이 지났는데 브리핑은 없고, 실행 화면에는 성공이라고 적혀 있는데 받아 볼 결과가 없기도 했죠.
도착했다고 끝도 아니었습니다. 정보가 잔뜩 있어도 무엇부터 읽어야 할지 모르겠다면 제가 원한 브리핑과는 거리가 있었어요. AI가 문장을 매끄럽게 정리해 주는 건 좋았지만, 숫자와 설명을 그대로 믿어도 되는지도 마음에 걸렸습니다.
제가 AI에게 설명할 수 있는 건 눈앞의 불편함이었습니다. 오늘은 왜 안 왔는지, 이 숫자는 어디서 가져왔는지, 관심 없는 영상은 왜 들어 있는지요. 전문적인 질문은 못 해도 이상한 부분은 짚을 수 있었어요. 그 질문을 들고 실행 기록과 코드를 하나씩 살펴봤습니다.
첫 월요일, 브리핑이 오지 않았다
2026년 6월 1일에 확인한 첫 문제는 예약 실행이었습니다. 이전 성공 기록은 수동 실행이나 CLI 실행이었고, n8n의 예약 시간에 따라 시작한 기록은 없었습니다. 활성화되어 있다는 표시만으로 예약 자동화까지 완료됐다고 받아들인 것이 문제였습니다.
당시 일지의 문장입니다.
“월요일은 장애가 맞았다. 최근 실행 이력에는 2026-05-29의 manual/cli 실행만 있었고, 예약 실행(mode=trigger)은 없었다.”
— 2026년 6월 1일 예약 실행 복구 작업일지
예약을 복구하는 시험에서도 한 번 더 막혔습니다. 시험용으로 노드 이름을 바꿨는데 연결 정보에는 옛 이름이 남아 있었어요. 그래서 시작 노드만 움직이고 뒤의 작업은 이어지지 않았습니다. 성공 표시를 봤는데 브리핑도 카카오 발송도 없었던 이유가 여기 있었습니다. 이름 하나가 이렇게 영향을 주는구나 싶었죠.
이름과 연결을 맞춘 뒤 다시 시험했습니다. 6월 1일 오전 11시 32분에는 실제 예약 트리거가 브리핑 생성과 카카오 전송까지 실행했고, 이후 당시 운영 설정인 평일 오전 7시로 되돌렸습니다.
저는 브리핑이 안 왔다고 했을 뿐인데, 들여다볼 곳은 여럿이었습니다. 예약이 시작됐는지부터 보고, 어떤 노드가 움직였는지, 결과가 만들어졌는지, 발송 응답은 무엇인지 차례로 확인했어요. 그 뒤로는 성공이라는 글자만 보고 안심하기 어려워졌습니다. 어디까지 된 건지 끝까지 봐야 했어요.
무료 클라우드 AI를 붙이는 아이디어
전달 문제가 풀리고 나니 내용에 욕심이 났습니다. 시세와 뉴스 제목을 줄줄이 보여 주는 데서 한 걸음 더 가고 싶었어요. 중요한 것부터 읽게 해 주고, 왜 눈여겨볼 만한지 근거 안에서 짧게 정리해 주면 좋겠다고 생각했습니다. 브리핑에 편집자가 필요한 셈이었죠.
그 편집 역할에 무료 클라우드 LLM을 붙였습니다. 자료를 모으고 정해진 시간에 실행하는 일은 NAS가 하고, 문장을 정리하는 일은 외부 AI에 부탁하는 방식이에요. NAS에서 큰 모델을 직접 돌리지 않아도 되니, GPU부터 마련해야 한다는 부담 없이 시험해 볼 수 있었습니다.
그림 2. 구현에서 확인한 역할 분담. NAS는 자료 수집과 검증·전달을 맡고, 클라우드 LLM은 제공된 자료를 편집한다. 설명을 위해 재구성한 도식이다.
2026년 7월 14일에는 전체 AI 자동화 프로젝트에서 NVIDIA Build의 여러 모델을 실제로 호출했습니다. GLM·Nemotron·DeepSeek의 hosted 호출은 성공했지만, Free Endpoint로 보이던 다른 후보는 계정에서 사용할 수 없어 404가 나왔습니다. 화면의 모델 목록만 보고 연결 완료라고 할 수 없었습니다.
“모델 등록 전에는 페이지 배지만 믿지 말고
/v1/models와 최소 실호출을 함께 검증해야 한다.”— 2026년 7월 14일 NVIDIA API 연동 작업일지
이후 8월 21일 운영 확인 기록에서는 브리핑이 NVIDIA API를 직접 호출하며 Nemotron을 먼저, GLM을 예비 모델로 쓰는 경로가 확인됩니다. 전체 프로젝트에 등록한 모든 모델을 브리핑에 넣었다는 뜻은 아닙니다.
저에게 이 조합이 특히 반가웠던 이유는 비용의 문턱을 낮춰 줬기 때문입니다. 비싼 AI API부터 계약하지 않고도 제가 필요한 요약과 정리를 만들어 볼 수 있었어요. 다만 유료 최상위 모델과 성능을 비교해 이겼다는 실험이나 실제 청구서의 절감 금액이 있는 건 아닙니다. 이 브리핑에 필요한 편집 역할을 무료 제공 모델과 검증 코드로 맡겨 본 경험이에요.
무료 이용의 조건도 확인할 부분입니다. NVIDIA는 무료 API 접근을 프로토타이핑 용도로 설명하고 운영용 경로를 별도로 안내합니다. 여기서의 무료 활용은 당시 제공된 개발·평가 접근을 이용한 경험이며, 무제한 무료 운영을 뜻하지 않습니다. 당시 일지에도 운영 사용 권한 확인이 후속으로 남아 있습니다. NVIDIA 공식 안내
정확한 정보는 어디에서 가져올까
AI가 글을 잘 써 주니 오히려 신경 쓰이는 부분이 생겼습니다. 문장이 매끄러우면 저도 모르게 더 믿고 읽게 되잖아요. 그런데 말이 자연스럽다는 이유로 날씨와 시세까지 맞는 건 아닙니다. 그래서 설명을 맡기기 전에 믿고 참고할 자료부터 준비하기로 했어요.
확인한 프로그램에는 다음 출처들이 연결돼 있습니다. 수집 성공 여부는 매번 따로 기록하며, 필요한 자료가 없는 경우도 구분합니다.
| 정보 | 연결한 출처 | 맡긴 역할 |
|---|---|---|
| 날씨 | 기상청 APIHub | 지역별 예보·관측, 기온·습도·바람·강수확률 |
| 국내 시장 | 네이버 금융 | 화면에 사용할 지수·종목·테마 시세 수집 |
| 공식 주식 자료 | 금융위원회 주식시세정보 API | 기준일이 있는 공식 참고자료 첨부 |
| 기업 공시 | OpenDART | 종목에 최근 공시 제목과 원문 링크 연결 |
| 가상자산 | Upbit 공개 API | 가격·제공 등락률·거래대금 수집 |
| 뉴스 | NewsData.io, Google 뉴스 보완 | 분야별 제목과 링크 수집·중복 정리 |
| 나들이 | 한국관광공사 API·검색 보완 | 생활에 활용할 방문 후보와 정보 연결 |
모든 항목이 공식 기관 API만으로 들어오는 것은 아닙니다. 웹에서 수집하는 운영 시세, 공식 참고자료, 뉴스 출처를 구분했습니다. API가 데이터를 준다는 사실만으로 기사 내용이나 분석까지 사실검증되는 것도 아닙니다.
제가 모든 분야를 잘 알 수는 없으니, 해당 자료를 제공하는 곳으로 연결했습니다. 날씨는 기상청의 예보·관측 자료를, 기업 소식은 OpenDART의 공시 원문을 확인할 수 있게요. AI에게 기억만으로 대답하게 하기보다, 읽을 자료를 손에 쥐여 주고 정리를 부탁하는 방식이었습니다. 기상청 APIHub, OpenDART 소개
공식 자료라도 지금의 값은 아닐 수 있다
출처를 붙이면 한숨 돌릴 줄 알았는데, 다음으로 볼 게 있었습니다. 같은 종목의 숫자라도 언제의 값이냐에 따라 다르더라고요. 공식 자료인지 확인하는 일에 기준 시각을 보는 일까지 더해졌습니다.
금융위원회 주식시세정보는 공식 자료이지만 실시간 시세처럼 사용할 수 없습니다. 공식 제공 페이지는 일 1회 갱신, 기준일 다음 영업일 오후 1시 이후 업데이트를 안내합니다. 지금 수집한 가격과 이를 구분 없이 섞으면 서로 다른 시점을 비교하게 됩니다. 금융위원회 주식시세정보
그래서 코드에서는 수집한 운영 시세를 공식 자료로 덮어쓰지 않고, 종목코드로 찾은 공식 참고값을 별도 항목으로 붙였습니다. 참고자료를 연결하는 기능이지 모든 가격을 동일 시점에 대조해 일치 보증하는 기능은 아닙니다.
뉴스에도 조건이 있습니다. NewsData.io 무료 플랜에는 12시간 지연이 있습니다. 프로그램에 지연 안내를 넣고, 부족한 항목은 Google 뉴스로 보완하는 경로를 마련했습니다. 무료 정보를 활용할수록 한계를 알고 읽을 수 있게 해야 했습니다. NewsData.io 요금제 설명
날씨 역시 발행 시각과 자료의 발표·관측 시각은 다릅니다. 확인한 코드에는 오전 기준 시각을 쓰는 부분이 있어, 오후판이라고 날씨까지 모두 오후 실황으로 바뀌었다고 할 수는 없습니다. 정보가 많이 들어오는 것에 더해, 기준 시각을 함께 봐야 하는 이유입니다.
AI가 쓴 문장에 근거를 붙였다
자료를 제대로 가져왔다고 AI가 늘 그대로 설명해 주는 것도 아니었습니다. 요약하면서 숫자를 바꾸거나 원문에 없는 이유를 붙일 수 있으니까요. 읽기 좋은 답을 만드는 일과, 그 답을 믿고 보여 주는 일은 따로 챙겨야 했습니다.
AI가 정리한 답에도 다시 확인할 근거가 필요했습니다. 자료를 대조하는 과정을 표현한 생성 이미지이며 실제 작업 화면은 아닙니다.
실제 브리핑 편집 지시에는 이런 문장이 들어 있습니다.
“시장 문장은 seed.market.evidence에 있는 사실만 사용하고 각 문장에 근거 source_ids를 넣으세요.”
— 보관된 브리핑 편집 프롬프트 원문
용어를 풀면, 모아 둔 근거 목록 안에서만 시장 설명을 쓰고 문장마다 어떤 자료를 사용했는지 표시하라는 뜻입니다. 가격과 등락률을 새로 만들지 않고, 근거 제목에 없는 원인이나 전망도 덧붙이지 않게 했습니다.
어떤 종목의 상승률과 공시가 함께 있다고 해서 그 공시 때문에 올랐다고 단정할 수는 없습니다. 공시는 독자가 확인할 자료로 연결하되 원인까지 자동으로 입증한 것처럼 설명하지 않도록 했습니다.
프로그램은 실제 근거 ID인지, 요약 항목에 맞는 종류의 자료인지, 숫자가 연결한 근거에 있는지 검사합니다. 어긋난 부분은 수집 자료로 만든 기본 요약으로 교체합니다. 화면에서는 원문으로 넘어갈 수 있게 근거 링크를 붙입니다.
저는 설명 옆에 원문으로 갈 길이 생긴 게 좋았습니다. 궁금하면 눌러서 더 읽을 수 있고, 납득이 안 되는 부분도 다시 확인할 수 있으니까요. 이 검사로 모든 의미 오류를 잡을 수는 없습니다. 그래도 어떤 문장은 보여 주고 어떤 문장은 고쳐야 하는지 기준이 생겼어요.
일부러 틀린 답을 넣은 검사
보관된 회귀검사에는 잘못된 답을 일부러 넣어 검증하는 사례가 있습니다. 다음은 실제 시세나 실제 발송 사고가 아니라 검사를 확인하기 위한 시험 입력입니다.
| 일부러 넣은 답 | 검사에서 확인하는 것 |
|---|---|
| “S&P 500이 90% 상승했습니다.” | 근거에 없는 90%가 결과에서 제거되는가 |
| 존재하지 않는 근거 ID | 없는 출처를 인용한 설명이 교정되는가 |
| “신규 진입과 비중 조절을 권합니다.” | 정보 요약이 매매 지시로 바뀌는 문장을 거르는가 |
| 출처 없는 금리 인하 확정 문장 | 확인되지 않은 확정적 주장이 남지 않는가 |
| 검증되지 않은 테마 이름 | 실제 근거에 있는 이름으로 교정되는가 |
검사 코드에서 발췌하면 이렇게 확인합니다.
# 실제 회귀검사 발췌. 90%는 고의로 삽입한 잘못된 시험값이다.
self.assertNotIn("90%", validated["market_digest"]["global_summary"]["text"])
self.assertNotIn("신규 진입", validated["market_digest"]["view"]["text"])
자료: 보관된 시장 요약 회귀검사. 편집 지시·검사 발췌 파일을 함께 첨부했다. 시험 숫자는 투자 정보나 성과 수치가 아니다.
이런 검사 방법을 제가 먼저 알고 제안했던 건 아닙니다. 이 내용을 믿어도 되는지, 원문을 볼 수 있는지 같은 질문을 AI와 풀어 가다 보니 여기까지 왔어요. 처음에는 부족하게 느껴졌던 제 질문도 실제로 고칠 부분을 찾는 데 쓸모가 있었습니다.
무료 모델이 실패해도 버틸 수 있게
무료 모델도 호출할 때마다 원하는 답을 주지는 않습니다. 첫 모델이 실패할 수도 있고, 예비 모델이 답해도 프로그램에서 읽을 형식과 다를 수 있어요. 그래서 AI를 부르기 전에 수집 자료와 정해진 규칙으로 기본 결과부터 만들어 두었습니다. 1차 모델, 예비 모델을 차례로 시도하고 둘 다 실패하면 그 결과를 쓰도록 했어요.
기본 결과는 부족한 사실을 상상해 채운 문장이 아닙니다. 수집한 자료와 정해진 규칙으로 만든 요약입니다. 자료 자체가 부족하면 별도의 수집 완전성 검사와 발행 조건이 적용됩니다.
나중에 문제가 생겼을 때 다시 들여다볼 기록도 남겼습니다. 어떤 모델을 불렀는지, 왜 실패했는지, 시간이 얼마나 걸렸는지, 무엇을 교정했는지요. 어떻게든 결과가 나왔다고 한데 묶어 버리면 다음에 같은 일이 생겨도 원인을 찾기 어렵겠더라고요.
8월 21일에는 다른 종류의 실패도 개선했습니다. 원격 브리핑 프로그램이 종료코드 1로 실패했는데 n8n은 성공으로 기록한 문제였습니다. 실행과 카카오 발송 뒤에 각각 종료코드 검사를 추가해 실제 실패가 드러나게 했습니다.
추천 영상이 관심 주제와 어긋날 때는 수집 후보에서 다시 고르는 처리, 가짜 영상 주소를 막는 검사도 들어갔습니다. 8월 27일에는 실행일과 앞의 두 날짜를 남기는 보관 기준을 만들고, 오래된 자료 정리가 오늘의 결과 확인 뒤에 실행되도록 보강했습니다. 첫 정리 시험이 운영 자료에 접근한 실수도 있어, 발행이 차단된 시험에서는 외부 정리 함수가 호출되지 않는지 확인하도록 했습니다.
오류를 해결할 때마다 사용자의 요구도 구체적으로 변했다
처음에는 브리핑이 오기만 하면 좋겠다고 생각했습니다. 그런데 막상 받아 보니 읽기 편했으면 좋겠고, 관심 없는 내용은 빠졌으면 좋겠고, 숫자의 근거도 알고 싶어졌어요. 계속 쌓이는 결과를 어떻게 보관할지, 실패하면 어떻게 알아챌지도 챙기게 됐습니다. 써 보니까 할 말이 늘어났어요.
AI와 거뜬하게 가 보고 싶었지만, 모든 과정이 수월했던 건 아닙니다. 고친 줄 알았는데 다시 확인할 때도 있었어요. 그래도 혼자 원인을 몰라 멈춰 있기보다 AI와 기록을 살피고 바뀐 결과를 확인하면서 다음으로 갈 수 있었습니다. 한 번의 답보다 그 주고받는 과정이 도움이 됐어요.
이제 이렇게 손본 기능들을 한데 모아 볼 차례입니다. 3부에서는 아침에 한 번 받던 브리핑이 오전과 오후 두 번, 제 관심사를 챙겨 주는 도구로 어떻게 자리를 잡았는지 이야기해 볼게요. 여러 번 고치며 만든 결과라서 처음보다 더 애착이 가는 부분입니다.
작성일: 2026년 9월 7일 | 날짜별 작업일지, 보관된 구현·검사, 제공기관 공식 안내를 대조했다. 기능별 최초 도입일이 불명확한 부분은 날짜를 추정하지 않았다.
