개인 자동화 18종

한 줄

n8n으로 만든 개인 자동화 18종입니다. 취업공고 알림, 아침 브리핑, 주식 요약, 학습 관리, 에러 감시까지 매일 실제로 돌고, 알림을 받는 사람은 저입니다.

왜 만들었나

필요한 정보가 흩어져 있고, 확인하는 시점을 제가 기억해야 한다는 게 불편했습니다. 매일 사이트를 열어 새 공고가 있는지 확인하는 일은 사람이 할 일이 아니라고 봤습니다.

목록

대표 사례 — 국가보훈부 채용공고 알림

보훈 취업지원 채용공고는 갱신 주기가 일정하지 않아, 매일 들어가 확인하지 않으면 마감을 놓칩니다. 하루 세 번(10·14·18시) 공고 페이지를 수집해 이전 수집분과 대조하고, 새로 올라온 것만 텔레그램으로 보냅니다.

국가보훈부에 가입하면 카카오톡으로 공식 알림이 오긴 합니다. 그런데 그 방식은 오늘 6건이 올라와도 내일부터 하루 1건씩 나눠서 뒤늦게 도착합니다. 제가 원한 건 반대였습니다. 최신 공고를 그날 바로 확인하고, 그중 제가 보려는 직무만 걸러 받는 것입니다. 그래서 직접 만들었습니다.

핵심은 중복 제거입니다. 공고 목록 전체를 매번 보내면 며칠 만에 알림을 무시하게 됩니다. 신규 건만 남기는 처리를 넣은 뒤에야 실제로 쓰이는 알림이 됐습니다. 지금도 매일 받고 있습니다.

처음에는 날짜로 신규 여부를 판정했는데, 게시일이 며칠 지난 뒤 올라오는 공고가 영구히 누락되는 것을 발견했습니다. 마지막으로 본 게시물 번호를 워터마크로 기억하는 방식으로 바꿨습니다.

실제로 고친 장애들

만들어 두면 알아서 도는 게 아니라는 걸 운영하면서 알게 됐습니다.

• 저장 지연 3.5초 — 워크플로우가 눈에 띄게 느려져 원인을 추적한 결과, 노드마다 실행 진행 상황을 DB에 다시 쓰는 옵션 때문이었습니다. n8n은 해외 호스팅이고 DB는 서울 리전이라 저장 한 번에 3.5초가 들었고 이것이 노드 수만큼 곱해졌습니다. 설정을 끄자 141노드 라우터가 60초에서 8.3초로 줄었습니다.
• 메시지 중간 절단 — 브리핑이 문장 중간에서 끊기던 현상을 처음엔 메신저 길이 제한으로 의심했으나, 실측 결과 LLM 응답 토큰 상한(3,000)이 원인이었습니다. 8,000으로 올려 해소했습니다.
• 인증 만료로 조용히 실패 — 메일 연동 OAuth가 만료되며 아침 브리핑이 며칠간 실패했는데, 에러 알림이 연결돼 있지 않아 한동안 몰랐습니다. 자동화의 가장 위험한 실패는 멈추는 게 아니라 조용히 멈추는 것임을 이때 배웠고, 실패를 감지하는 에러 알림 워크플로우를 따로 둔 계기가 됐습니다. 인증을 재연결해 지금은 매일 정상 수신 중입니다.
• DB 전환으로 워크플로우 7종 실종 — n8n 본체의 DB 호스트를 바꾸자 그 전에 만든 워크플로우 7개가 화면에서 사라졌습니다. 삭제된 것이 아니라 이전 DB에 남아 있는 것임을 생성 시각 패턴으로 규명하고 재임포트했습니다. 같은 시기 사라진 보훈부 알림도 재생성했습니다.
• DB 서비스 다운으로 무한 대기 — 인프라의 Postgres 서비스가 내려가자 연결이 거부되지 않고 매달려, 챗봇이 응답 없이 영원히 기다렸습니다. 실행 기록에서 "실행된 노드 0개"를 보고 원인을 찾아 자격증명을 옮겨 복구했습니다.
• PowerShell 인코딩 사고 — 배포 스크립트가 한글 노드 내용을 깨뜨린 사고 이후, 같은 실수를 반복하지 않도록 저장소 규칙 파일에 고정했습니다. 어떤 도구를 쓰더라도 먼저 읽게 되어 있습니다.
• 개인정보 보유기간 — 사용자 데이터를 받는 이상 보유기간이 지난 정보는 지워야 합니다. 매일 새벽에 도는 정리 작업을 별도 워크플로우로 분리했습니다.

알림과 분석을 나눈 이유

같은 주식 데이터를 다루면서 도구를 둘로 나눴습니다. 매일 아침 받는 요약 알림은 n8n 워크플로우로, 보유 종목의 손익과 추이를 직접 뜯어보는 대시보드는 Python(FastAPI)과 순수 HTML/JS로 따로 만들었습니다. KB증권 OpenAPI로 계좌 잔고·보유종목 손익·주문가능금액·당일 체결을 가져오고, 시세·캔들차트·기술지표, 조건 감시(가격·등락률·이동평균 이격·거래량 배수)를 한 화면에 뒀습니다. 조건은 참으로 바뀌는 순간에만 알리고 30분 쿨다운을 두어 같은 알림이 반복되지 않게 했습니다. 장 시간 밖에는 API를 호출하지 않습니다.

주문 기능은 기본이 실행 없는 검토 모드입니다. KB증권 OpenAPI에는 모의투자 서버가 없어 주문 전문을 보내면 실제 체결됩니다. 그래서 전문을 조립해 필드별로 보여주기만 하고, 실제 전송은 설정에서 명시적으로 켜야 하게 했습니다.

나눈 이유는 소비 방식이 다르기 때문입니다. 알림은 정해진 시각에 한 번, 스마트폰에서 몇 초 안에 읽는 것입니다. 여기에 표와 차트를 넣으면 읽히지 않습니다. 반대로 종목을 실제로 판단할 때는 숫자를 정렬하고 기간을 바꿔 봐야 하는데, 이건 메신저로 할 수 없습니다.

하나의 도구로 둘 다 하려다 보면 알림은 무거워지고 분석은 빈약해집니다. 자동화를 늘리다 보면 이 구분을 놓치기 쉽습니다.

설계 판단

실패를 감지하는 워크플로우를 따로 뒀습니다. 연결된 워크플로우가 실패하면 그 에러를 포맷해 텔레그램으로 보냅니다. 자동화의 가장 위험한 실패는 멈추는 게 아니라 조용히 멈추는 것입니다. 현재 챗봇·개인정보 정리·학습 시스템 계열이 연결돼 있고, 브리핑·공고 알림 계열은 아직 연결하지 않았습니다.

중단한 것은 지우지 않고 남겼습니다. 국내 주식 분석, Slack 중계, 구버전 봇은 중단 상태로 보관 중입니다. 왜 접었는지가 다음 설계의 근거가 됩니다.

검증 없이 "고쳤다"고 쓰지 않습니다. 이 저장소에는 테스트도 빌드도 없습니다. 대신 무엇을 고쳤을 때 무엇으로 확인하는지를 표로 정해 두고, 확인하지 않았으면 확인하지 않았다고 적습니다. 워크플로우를 통째로 올린 뒤에는 되읽어 원본과 대조합니다. 과거에 그 과정에서 노드가 유실된 적이 있기 때문입니다.

한계

전부 1인 사용 기준이며, 다중 사용자 부하나 장애 복구 절차는 갖추지 않았습니다. 워크플로우 원본이 n8n 데이터베이스에만 있어 저장소에는 주기적 내보내기 스냅샷만 보관하고 있습니다.

화면과 시연

• 스크린샷 — 보훈부 공고 알림이 도착한 텔레그램 화면 (실제 수신 날짜가 보이게)
• 스크린샷 — 해당 워크플로우 캔버스 (9노드 전체)
• 스크린샷 — 아침 브리핑 텔레그램 메시지
• 스크린샷 — 에러 알림 워크플로우가 잡아낸 실패 메시지
• 스크린샷 — 주식 대시보드 화면 (계좌번호·보유 금액은 마스킹 또는 데모 값으로 교체)