모니터링 워크플로 사례

왜 모니터링부터 시작할까요

자동화의 첫 대상으로 모니터링이 좋은 이유가 셋 있습니다.

트리거가 분명합니다. 정해진 요일이 되면 시작합니다. 앞 레슨에서 트리거를 적지 못하면 자동화할 수 없다고 말씀드렸는데, 모니터링은 그 칸이 처음부터 채워져 있습니다.

판단이 들어오지 않습니다. 모아서 보여 주는 데까지가 워크플로의 일이고, 무엇을 읽을지는 제가 표를 열어 정합니다.

그리고 실패해도 안전합니다. 워크플로가 하루 멈춰도 잃는 것은 알림 한 통입니다. 처음 만드는 워크플로가 원고 파일을 건드리거나 메일을 대신 보내는 것이라면 배우기 전에 사고가 납니다.

사례 1. 새 논문이 나오면 알기

먼저 알아야 할 것: 이 피드는 새 것만 주지 않습니다

앞 레슨에서 PubMed의 Create RSS로 검색 RSS 주소를 만들 수 있다고 말씀드렸습니다. 그 주소를 워크플로에 넣기 전에 반드시 알아야 할 사실이 하나 있습니다.

NLM은 새 PubMed의 RSS에 대해 이렇게 밝혔습니다. RSS 기능이 "완전한 검색 결과를 돌려주며, 저장된 검색 알림이 쓰는 'What's New' 방식을 더는 쓰지 않는다"고, 그리고 "표준적인 RSS 방식에 따라 모든 결과를 연속된 목록으로 가져온다"고 적었습니다.

풀어 쓰면 이렇습니다. 확인할 때마다 검색 결과 전체가 다시 옵니다. 지난주에 본 논문도 이번 주에 또 옵니다. 이메일 알림은 지난번 이후의 것만 보내지만 RSS는 그렇지 않습니다.

그래서 이 워크플로의 중심은 수집이 아니라 이미 본 것을 걸러 내는 자리입니다. 그 자리가 없으면 매주 같은 논문 목록을 받게 되고, 몇 주 만에 메일을 열지 않게 됩니다.

설계

단계	노드	하는 일
1	Schedule Trigger	매주 정해진 요일과 시각에 시작합니다
2	RSS Read	검색 RSS 주소를 읽습니다. 결과 전체가 들어옵니다
3	Remove Duplicates	이전 실행에서 이미 본 논문을 걸러 냅니다
4	Google Sheets — Append Row	남은 논문을 한 편에 한 줄씩 시트에 쌓습니다
5	Aggregate	논문들을 하나로 묶습니다
6	Send Email	이번 주에 새로 나온 것만 한 통으로 보냅니다

4단계와 5단계의 순서가 중요합니다. 앞 레슨에서 노드는 아이템마다 한 번씩 작동한다고 말씀드렸습니다. 3단계를 지나 논문 다섯 편이 남았다면 4단계는 다섯 번 작동해 다섯 줄을 만듭니다. 그런데 Aggregate는 여러 아이템을 하나로 묶습니다. 이것을 시트 쓰기 앞에 두면 다섯 편이 한 덩어리가 되어 시트에 한 줄만 들어갑니다. 한 편에 한 줄로 남기시려면 쌓아 두는 일을 먼저 하고, 묶는 일은 메일 직전에 하십시오.

3단계가 이 설계의 핵심입니다. Remove Duplicates 노드에서 Operation을 Remove Items Processed in Previous Executions로 고릅니다. 문서는 이 노드가 "이전 실행에서 본 항목과 같거나 그것을 넘지 못하는 아이템"을 지운다고 설명합니다. Keep Items Where는 Value Is New로 두고, Value to Dedupe On에는 논문마다 다른 값을 넣습니다. PMID가 이 자리에 가장 알맞습니다. 제목은 같은 논문이 조금 다르게 표기될 수 있고, 날짜는 여러 논문이 같습니다.

이 노드에 대해 문서가 밝혀 둔 것 셋을 미리 알고 계시면 당황하지 않으십니다.

• 첫 실행에는 전부 새 것으로 잡힙니다. 기억이 비어 있기 때문입니다. 첫 메일은 검색 결과 전체가 들어와 길 것이고, 그다음 주부터 짧아집니다.
• 이 방식은 같은 실행 안에서 중복된 것은 걸러 주지 않습니다. 문서는 그 경우 Remove Duplicates 노드를 두 개 이어 붙이라고 안내합니다. 앞의 것을 Remove Items Repeated Within Current Input으로 두면 됩니다.
• 기억하는 항목 수의 기본값은 10,000개입니다(History Size). 필요하면 늘릴 수 있고, Clear Deduplication History 오퍼레이션으로 기억을 비울 수도 있습니다. 검색식을 바꾸셨다면 비우고 다시 시작하는 편이 깔끔합니다.

초록 요약을 붙이고 싶다면

3단계 뒤, 시트에 쌓기 전에 AI 호출을 한 단계 넣을 수 있습니다. n8n이 제공하는 체인 노드는 셋인데, 요약에는 Summarization Chain을 씁니다. 초록을 한 편씩 넣으신다면 더 단순한 Basic LLM Chain으로도 됩니다.

이때 원문 초록 열을 반드시 함께 남기십시오. 요약만 남으면 나중에 확인할 방법이 없어집니다.

사례 2. 실제로 운영해 본 워크플로 하나

이 코스를 만든 사람이 헬스케어 AI 윤리 분야의 뉴스레터를 한동안 발행했습니다. 지금은 발행하지 않지만, 가설이 아니라 실제로 만들어 돌려 본 것이라서 무엇을 자동화했고 무엇을 남겨 두었는지 그대로 적을 수 있습니다.

자동화했던 것. 헬스케어 AI 윤리 관련 논문과 기사를 매일 수집하고, 요약하고, 미리 정한 기준에 따라 평가해 등급을 매기고, 상위 항목과 하이라이트와 참고문헌을 정해진 틀에 배치하는 데까지입니다.

사람이 하던 것. 완전 자동 발행이 아니었습니다. 최종 검수는 사람이 했고, 뉴스레터 앞부분의 한 주 요약과 중요 기사 소개는 직접 썼습니다.

이 경계가 이 사례에서 가장 중요한 부분입니다. 수집과 정리와 배치는 순서가 매번 같은 손일이라 넘겼습니다. 반면 "이번 주에 무엇이 중요했는가"는 넘기지 않았습니다. 그것이 그 뉴스레터를 읽을 이유였기 때문입니다.

설계를 앞의 어휘로 옮기면 이렇습니다.

단계	하는 일	판단이 들어가는가
1	정해진 시각에 시작	없음
2	자료원에서 논문·기사 수집	없음
3	이미 본 것 걸러 내기	없음
4	요약하고 정해진 기준으로 등급 매기기	들어감 — 확인 가능한 형태로
5	틀에 맞춰 배치	없음
6	최종 검수와 앞부분 서술	사람이 쥠

4단계에 판단이 들어가지만, 등급과 그 근거가 표에 남았기 때문에 나중에 대조할 수 있었습니다. 6단계는 아예 넘기지 않았습니다. 다음 레슨에서 이 4단계와 6단계의 차이를 정확히 어디서 나누는지 다룹니다.

조용히 멈춘 워크플로를 알아차리기

여기가 이 레슨에서 가장 중요한 절입니다. 워크플로는 소리 없이 멈춥니다. 자료원 주소가 바뀌거나 자격 증명이 만료되면 그날부터 아무 일도 일어나지 않는데, 저는 알림이 없는 것을 이번 주에는 새 논문이 없구나로 읽습니다. 침묵과 고장이 똑같이 생겼습니다.

실행 기록을 눈으로 확인하는 방법은 왜 부족한가

Executions 탭을 가끔 열어 보면 되지 않을까 싶지만, 그 방법에는 두 가지 구멍이 있습니다.

첫째, 기록이 오래 남지 않습니다. n8n Cloud 문서는 보관 기간을 플랜별로 밝혀 두었는데, Start·Starter 플랜은 7일, Pro는 30일입니다. 자체 호스팅은 기본값이 336시간, 즉 14일입니다. 한 달에 한 번 열어 보는 습관으로는 이미 지워진 실패를 보게 됩니다.

둘째, 폴링 트리거는 결과가 없으면 실행 기록을 남기지 않을 수 있습니다. 문서는 폴링 노드에 대해 "새 자료를 찾았을 때만 실행 한 번으로 셉니다. 결과가 없는 폴링은 실행으로 세지 않습니다"라고 적습니다. 반면 Schedule Trigger는 "결과와 무관하게 노드가 작동할 때마다 실행 한 번"으로 셉니다. 사례 1에서 RSS Feed Trigger 대신 Schedule Trigger를 쓴 이유가 여기 있습니다. 매주 돌았다는 흔적 자체가 남아야 합니다.

실패하면 사람에게 알리기

n8n이 문서로 안내하는 방식은 오류 워크플로입니다. 순서는 이렇습니다.

문서가 밝혀 둔 제약 하나를 미리 알려 드립니다. 수동 실행으로는 오류 워크플로를 시험할 수 없습니다. 문서는 "Error Trigger는 자동으로 실행된 워크플로가 실패했을 때만 작동한다"고 적습니다. Execute Workflow를 눌러 보고 알림이 안 온다고 고장 났다고 판단하지 마십시오.

결과가 0건인 것은 오류가 아닙니다

이것이 마지막 구멍입니다. 검색식에 오타를 내거나 자료원이 조용히 빈 결과를 돌려주면, 워크플로는 성공적으로 아무것도 하지 않습니다. 오류가 아니므로 오류 워크플로도 울리지 않습니다.

이럴 때 쓰는 노드가 Stop And Error입니다. 문서는 이 노드를 "직접 정한 오류 메시지를 표시하고, 특정 조건에서 실행을 실패하게 만들고, 오류 워크플로에 오류 정보를 보내는" 노드로 설명합니다.

Filter나 If로 "결과가 0건인가"를 판정해 그 갈래를 Stop And Error로 보내면, 침묵이 실패로 바뀌어 알림이 옵니다. 다만 새 논문이 없는 주가 정상인 주제라면 매주 울릴 것이므로, "4주 연속 0건" 같은 조건을 쓰시거나 이 장치를 빼셔도 됩니다. 무엇이 이상 신호인지는 주제마다 다릅니다.

잠깐 실패한 것과 정말 고장 난 것

자료원 서버가 잠시 응답하지 않는 일은 흔합니다. 그때마다 알림이 오면 알림을 무시하게 됩니다. 노드의 Settings 탭에 Retry On Fail을 켜고 Wait Between Tries (ms) 로 간격을 주면, 잠깐 실패한 것은 스스로 다시 시도해 넘어갑니다. 그래도 안 되면 그때 오류 워크플로가 울립니다.

On Error 는 기본값인 Stop Workflow로 두십시오. Continue로 바꾸면 실패한 채로 다음 단계가 진행되어, 빈 결과가 정상처럼 흘러갑니다.

자료원을 예의 있게 부르기

자동화는 사람보다 훨씬 자주 요청을 보낼 수 있습니다. 공개 자료원은 대부분 무료로 열려 있고, 그 상태를 유지하는 것은 쓰는 쪽의 몫이기도 합니다.

PubMed E-utilities. NCBI는 "초당 세 건을 넘지 말 것"과 "많은 양의 작업은 주말이나 평일 미 동부 시간 21시부터 5시 사이에 할 것"을 지침으로 적어 두었습니다. 지키지 않으면 IP가 차단될 수 있다고도 밝혀 두었습니다. NCBI 계정에서 API 키를 받아 요청에 붙이면 초당 열 건까지 올라갑니다.

결과 페이지를 긁지 마십시오. NCBI가 "스크래핑 금지"라고 적어 둔 문장은 없습니다. 다만 자동 질의는 일반 웹 주소가 아니라 E-utilities 서버로 보내라고 명시적으로 지시합니다. 화면을 긁는 방식은 화면 구조가 바뀌면 조용히 멈추기도 하므로, 문서화된 API나 RSS를 쓰십시오.

RSS 주소를 얼마나 자주 확인해도 되는지는 문서에 없습니다. NLM이 숫자를 밝혀 두지 않았습니다. 그래서 이 코스도 숫자를 드리지 않겠습니다. 다만 새 논문은 분 단위로 나오지 않으므로 시간 단위 이상으로, 하루 한두 번이면 충분합니다.

Crossref. 키 없이 쓸 수 있습니다. 연락처를 붙이지 않으면 공개 풀에 들어가고, 문서가 밝힌 공개 풀의 한도는 요청 5건에 동시 요청 1건입니다. 여기서 시간 단위는 문서에 적혀 있지 않습니다. 실제 간격은 응답 헤더로 옵니다.

Europe PMC. 키가 필요 없습니다. 속도 제한은 문서에 적혀 있지 않습니다. 제한이 없다는 뜻이 아니라 문서에 없다는 뜻입니다.

직접 해 보기약 20분

자신의 주제로 모니터링 워크플로를 하나 설계합니다. 자료원은 PubMed 검색이어도 되고, 늘 확인하시는 학회나 기관 페이지여도 됩니다.

단계	노드	설정할 값	여기서 실패하면	어떻게 알아차리는가
				선택오류 워크플로Stop And Error눈으로 확인모름
				선택오류 워크플로Stop And Error눈으로 확인모름
				선택오류 워크플로Stop And Error눈으로 확인모름
				선택오류 워크플로Stop And Error눈으로 확인모름
				선택오류 워크플로Stop And Error눈으로 확인모름
				선택오류 워크플로Stop And Error눈으로 확인모름

1행

단계

노드

설정할 값

여기서 실패하면

어떻게 알아차리는가선택오류 워크플로Stop And Error눈으로 확인모름

2행

단계

노드

설정할 값

여기서 실패하면

어떻게 알아차리는가선택오류 워크플로Stop And Error눈으로 확인모름

3행

단계

노드

설정할 값

여기서 실패하면

어떻게 알아차리는가선택오류 워크플로Stop And Error눈으로 확인모름

4행

단계

노드

설정할 값

여기서 실패하면

어떻게 알아차리는가선택오류 워크플로Stop And Error눈으로 확인모름

5행

단계

노드

설정할 값

여기서 실패하면

어떻게 알아차리는가선택오류 워크플로Stop And Error눈으로 확인모름

6행

단계

노드

설정할 값

여기서 실패하면

어떻게 알아차리는가선택오류 워크플로Stop And Error눈으로 확인모름

복사하기내려받기지우기이 브라우저에만 저장됩니다. 서버로 보내지 않습니다.

마지막 칸에 모름이나 눈으로 확인이 있으면 그 줄은 아직 완성이 아닙니다. 기록은 이레에서 보름이면 지워지고, 사람은 잘 돌아가는 것을 확인하러 들어가지 않습니다.

설계를 다 적으셨으면 실제로 만들어 한 번 돌려 보시고, 첫 결과가 예상과 다른 자리를 게시판에 남겨 주시면 좋겠습니다. 자료원마다 걸리는 지점이 달라서, 그 기록이 다음 분에게 그대로 쓸모가 됩니다.

내려받기를 눌러 저장해 두십시오.

커뮤니티에 결과를 남겨 보세요

연구에 적용하면

모니터링은 트리거가 분명하고 판단이 없어서 첫 자동화로 좋습니다. 다만 자료원의 성질을 먼저 알아야 합니다. PubMed RSS는 매번 결과 전체를 주므로, 이미 본 것을 걸러 내는 자리가 설계의 중심입니다.

그리고 자동화의 진짜 위험은 틀린 결과가 아니라 아무 일도 일어나지 않는 것입니다. 실행 기록은 이레에서 보름이면 지워지고 침묵은 정상과 구별되지 않으므로, 실패를 사람에게 알리는 장치를 워크플로 안에 넣어 두십시오.

여기까지는 판단이 거의 들어오지 않았습니다. 그런데 "읽을 만한 것만 골라 달라"는 한 줄을 넣는 순간 성격이 달라집니다. 다음 레슨에서 그 경계를 정합니다.