n8n Jamf 패치 관리 자동화 — 슬랙으로 받는 소프트웨어 컴플라이언스 리포트

n8n.io 공식 템플릿을 쓰면, Jamf Pro 콘솔에 매번 로그인해 소프트웨어 패치 현황을 확인하는 대신 지정한 소프트웨어의 최신 버전과 최신·구버전 설치 대수를 주기적으로 조회해 슬랙 채널에 자동으로 보고하는 구조를 설계할 수 있습니다.

이 템플릿 하나로 보여줄 수 있는 것

면접에서 "IT 운영이나 보안 쪽 자동화도 해보셨어요?"라는 질문을 받으면, 이 템플릿은 "사내 기기의 소프트웨어 패치 현황을 MDM API로 조회해 추적 대상만 걸러내고, 사람이 읽기 좋은 형태로 슬랙에 자동 보고하도록 설계했습니다"라고 답할 재료를 줍니다.

짧은 문장이지만 안에 들어간 역량은 세 가지입니다.

• 엔터프라이즈 API 연동 — 아무나 가입할 수 없는 사내 시스템의 REST API를 인증해 호출해본 경험
• 조건 필터링으로 범위 좁히기 — 전체 소프트웨어 목록 중 실제로 추적할 몇 개만 골라 이후 조회 대상을 줄이는 설계
• 리포트 포맷팅 — API가 돌려주는 원시 데이터(버전·대수)를 사람이 채널에서 바로 읽을 수 있는 메시지로 조립하는 경험

이 세 가지는 Jamf 패치 관리뿐 아니라 서버 인증서 만료 점검, 라이선스 갱신 알림, 보안 취약점 스캔 결과 보고처럼 "사내 시스템을 매번 열어보는 대신 정기적으로 요약해서 채널에 던져주는" 유형의 IT 운영 자동화 전반에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Monitor software compliance with Jamf patch summaries in Slack라는 이름으로 공개된 템플릿이고, 제작자는 Jean-Marie Rizkallah입니다. 카테고리는 SecOps로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿은 Jamf 패치 요약을 슬랙에 자동으로 게시해, IT/보안팀이 Jamf에 직접 로그인하지 않고도 오래된 설치본을 빠르게 파악하도록 돕는 워크플로우입니다. 배경을 풀어보면 이렇습니다. 회사가 지급한 맥북이 여러 대라면, IT팀은 크롬이나 엣지 같은 필수 소프트웨어가 전 직원 기기에서 최신 버전인지 주기적으로 확인해야 합니다. 지금까지는 그때마다 Jamf Pro 콘솔에 로그인해 대시보드를 열고 소프트웨어별 화면을 하나씩 넘겨봤을 겁니다. 이 자동화는 그 확인 과정을 없애고, 결과만 슬랙 채널로 밀어 넣습니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글에서는 워크플로우 자체에 집중합니다.

다만 미리 짚어둘 게 있습니다. 이 템플릿은 Jamf Pro라는 특정 시스템이 이미 있다는 전제 위에 서 있습니다. Jamf Pro는 회사 소유의 맥·아이폰·아이패드를 기업 단위로 관리하는 MDM(모바일 기기 관리) 플랫폼으로, 조직 단위 유료 라이선스로 판매되고 개인이 가입할 수 있는 무료 요금제는 없습니다. 그래서 취준생이 이 워크플로우를 그대로 재현해 실행해보기는 현실적으로 어렵습니다. 배치3의 ERP 재고관리 템플릿과 같은 이유로, 이 글도 "직접 실습"보다는 "판단 순서를 배우고 면접에서 설명할 수 있는 설계 학습용"으로 읽는 편을 권합니다.

구조 — Trigger / Task / Target

공식 문서의 "How it works" 6단계를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다.

• Trigger — 수동 실행 또는 웹훅으로 시작합니다. 공식 문서는 두 방식을 모두 허용한다고만 안내하고, 웹훅을 어떤 이벤트에 연결할지는 사용자 몫으로 남겨둡니다.
• Task — Jamf Pro API로 전체 소프트웨어 타이틀 목록을 가져온 뒤, 실제로 추적하는 소프트웨어(예: Chrome, Edge)만 필터로 남깁니다. 그 소프트웨어의 패치 요약(최신 버전, 최신 버전 유지 대수, 구버전 대수)을 다시 조회하고, 이 값을 슬랙 Block Kit 형식으로 정리합니다.
• Target — 지정된 슬랙 채널에 정리된 요약을 게시합니다.

공식 템플릿 카드의 노드 미리보기에는 HTTP Request, Edit Fields(Set), Slack 노드가 표시되고 그 외 4개가 더 있다고 나와, 전체는 7개 노드로 구성됩니다. 위 6단계가 그 7개 노드에 그대로 대응한다고 보면 됩니다.

만들기

공식 Setup 안내(약 5~10분 소요, 원문 기준)를 취준생 눈높이로 풀면 다섯 단계입니다. Jamf Pro 계정이 없다면 아래는 "실행할 절차"가 아니라 "각 단계가 왜 필요한지 이해하는 자료"로 읽으면 됩니다.

1. Jamf Pro 서버 주소 등록

Set 노드에 사내 Jamf Pro 서버의 BaseURL을 변수로 넣습니다. 이후 HTTP Request 노드들이 이 변수를 참조해 실제 요청 주소를 조립합니다.

2. Jamf Pro API 크리덴셜 연결

HTTP Request 노드 두 곳(소프트웨어 목록을 가져오는 Get, 패치 요약을 가져오는 Retrieve)에 Jamf Pro API 크리덴셜을 넣습니다. 이 크리덴셜은 소프트웨어 타이틀과 패치 요약을 읽을 권한이 있어야 한다고 공식 문서는 명시합니다.

3. Filter 노드에 추적 대상 소프트웨어 지정

Filter 노드에 실제로 모니터링할 소프트웨어의 ID를 넣습니다. 크롬이나 엣지처럼 회사가 관리 대상으로 정한 소프트웨어만 이 단계를 통과해 다음 조회로 넘어갑니다.

4. 슬랙 웹훅 또는 토큰 등록

마지막 노드에 슬랙 인커밍 웹훅 URL 또는 봇 토큰을 넣습니다. 둘 중 어느 쪽을 쓰든 원하는 채널에 게시할 권한이 있어야 합니다.

5. (옵션) 메시지 포맷 조정

Function 노드 안에서 슬랙에 보여줄 메시지 형태를 원하는 대로 손볼 수 있다고 안내돼 있습니다. 다만 Function 노드는 n8n에서 레거시로 분류된 노드입니다. 최신 n8n에서는 같은 역할을 하는 Code 노드를 쓰는 편을 권장합니다.

주의할 점 · 제약

공식 문서의 Prerequisites와 Setup 항목에 적힌 제약 중 실제로 부딪히기 쉬운 것들을 추립니다.

• Jamf Pro 접근 권한이 필요합니다 — 소프트웨어 타이틀과 패치 요약을 읽을 수 있는 API 키가 전제입니다. Jamf Pro는 조직 단위로 계약하는 유료 MDM 플랫폼이라, 개인이 학습용으로 따로 가입하기는 어렵습니다. 이 시리즈에서 구글시트나 슬랙처럼 계정만 있으면 되는 템플릿보다 재현 난이도가 확실히 높은 이유입니다.
• 슬랙 게시 권한도 별도로 필요합니다 — 인커밍 웹훅이든 봇 토큰이든, 원하는 채널에 글을 쓸 수 있는 권한을 슬랙 쪽에서 먼저 준비해야 합니다.
• 세부 파라미터는 원문에 나와 있지 않습니다 — 소프트웨어 ID를 Jamf Pro 화면 어디에서 찾는지, 패치 요약 API가 정확히 어떤 JSON 필드를 돌려주는지, 슬랙 Block Kit 구조가 어떻게 짜여 있는지는 이 글이 근거로 삼은 공식 페이지 텍스트에 실려 있지 않습니다. 실제로 재현하려면 n8n 캔버스를 열어 각 노드의 설정값을 직접 확인해야 합니다.
• 레거시 노드가 포함돼 있습니다 — 포맷팅 단계에 쓰인 Function 노드는 지금 새로 만드는 워크플로우라면 Code 노드로 대체하는 편이 낫습니다.

포트폴리오·면접 포인트

Jamf Pro 계정이 없어도 이 구조를 포트폴리오에 담을 방법은 있습니다. Jamf API를 부르는 두 개의 HTTP Request 노드를 계정 없이 쓸 수 있는 다른 REST API(예: 깃허브의 릴리스 조회 API)로 바꿔치기하고, "전체 목록 조회 → 추적 대상만 필터링 → 요약 포맷 → 채널 게시"라는 뼈대만 그대로 재현하면 됩니다. 실물 Jamf 계정이 없어도 왜 이런 순서로 설계했는지 설명할 수 있으면 충분합니다.

면접에서는 "왜 전체 소프트웨어를 다 보고하지 않고 필터를 넣었나요?"라는 질문이 나올 수 있습니다. 답은 명확합니다. 회사가 실제로 관리 대상으로 지정한 몇 개 소프트웨어만 추적하면 되는데, 전체 목록을 그대로 보고하면 정작 봐야 할 정보가 소음에 묻히기 때문입니다. 이런 답을 할 수 있으면 API를 그대로 호출만 해본 사람과, 필요한 범위를 좁혀 설계한 사람이 구분됩니다.

다음 액션

다음 편은 완전히 다른 도메인으로 넘어갑니다. 폼과 이메일을 통해 정해진 Docker 앱 스택을 VPS에 배포하는 자동화인데, 이번 편이 "이미 존재하는 사내 시스템의 상태를 조회해 보고하는" 쪽이었다면 다음 편은 "n8n이 직접 서버 인프라를 조작하는" 쪽입니다. 둘 다 셀프호스팅 n8n이나 유료 인프라가 전제인 진입장벽이 있는 자동화라는 공통점도 함께 짚어볼 만합니다.