n8n 2.30 Microsoft 앱 전용 인증: 퇴사자 계정 없는 자동화로 전환하기

n8n은 2026년 7월 7일 2.30 변경 사항으로 Microsoft 노드의 앱 전용 인증 확대를 발표했다. Microsoft Entra 서비스 프린시펄을 쓰면 사람이 로그인한 OAuth 세션 대신 관리자가 만든 앱 등록으로 워크플로가 실행된다. OneDrive와 Outlook은 2.29에서 먼저 지원됐고, Excel 365·Microsoft Teams·Microsoft To Do가 2.30에서 뒤따랐다. 퇴사자 계정이나 개인 동의에 묶인 자동화를 줄일 기회지만, 개인 계정을 앱 계정으로 바꾸는 것만으로 운영 문제가 끝나지는 않는다. 앱이 누구의 메일함·드라이브·팀에 어떤 권한으로 접근하는지를 더 명시적으로 관리해야 한다.

7월 7일 발표에서 확인된 범위

n8n 공식 변경 기록은 하나의 앱 전용 자격 증명을 여러 Microsoft 노드에서 공유할 수 있고, 워크플로가 로그인한 사용자 대신 애플리케이션으로 인증한다고 설명한다. 공식 자격 증명 문서는 Excel(OneDrive), Excel(SharePoint), OneDrive와 트리거, Outlook과 트리거, Teams와 트리거, To Do를 지원 대상으로 열거한다. 일부 노드는 특정 노드 버전부터 지원하므로 기존 워크플로의 노드 버전을 확인해야 한다.

앱 전용 인증에는 로그인 사용자가 없다. 따라서 노드에서 Access As, Mailbox, User처럼 실제 작업 대상을 지정해야 한다. 사용자 전용 의미를 가진 검색이나 Teams 채팅 같은 일부 작업은 숨겨지거나 오류로 차단될 수 있다. 기존 OAuth 흐름과 동작이 같다고 가정하고 일괄 교체하면 기능 공백이 생길 수 있다.

확인된 사실: Entra 앱 등록에는 위임된 권한이 아니라 Microsoft Graph의 애플리케이션 권한과 관리자 동의가 필요하다. 자격 증명 테스트는 조직 조회 권한도 요구한다.

POEMORA 해석: 개인 토큰 만료 위험은 줄지만 앱 권한이 넓어지면 사고 반경은 오히려 커질 수 있다. 서비스 프린시펄 하나를 모든 자동화가 공유하는 편의성보다 업무별 경계가 우선이다.

개인 OAuth에서 옮기기 전 자산 조사

먼저 n8n에서 Microsoft 자격 증명을 사용하는 워크플로를 내보내 목록화한다. 각 항목에 소유자, 노드 버전, 대상 메일함·드라이브·사이트, Graph 작업, 실행 주기, 실패 시 영향, 현재 OAuth 사용자 계정을 적는다. “마케팅팀 공용”처럼 모호한 소유자는 실제 승인 책임자로 바꾼다.

같은 Microsoft 365를 쓰더라도 급여 파일 처리와 뉴스레터 첨부 저장은 앱을 분리하는 편이 낫다. 최소한 데이터 민감도와 쓰기 권한을 기준으로 서비스 프린시펄을 나누면 한 비밀 유출이나 잘못된 동작의 범위를 제한할 수 있다.

권한과 비밀을 운영 가능한 단위로 만들기

설정 절차 자체는 단순하다. Entra 관리 센터에서 단일 테넌트 앱을 등록하고, 필요한 Microsoft Graph 애플리케이션 권한을 추가한 뒤 관리자 동의를 부여한다. 테넌트 ID, 클라이언트 ID, 클라이언트 비밀을 n8n 자격 증명에 넣는다. 그러나 실제 품질은 다음 통제에서 갈린다.

1. 노드 작업에서 필요한 Graph 권한만 역산하고 별도 승인 기록을 남긴다.
2. 개발·운영 앱과 비밀을 분리하고 운영 자격 증명의 공유 범위를 제한한다.
3. 클라이언트 비밀의 만료일 30일 전 경보와 교체 담당자를 지정한다.
4. 노드의 대상 사용자·메일함 필드를 고정하거나 허용 목록으로 검증한다.
5. Entra 로그인·감사 기록과 n8n 실행 ID를 사건 조사에서 연결할 수 있게 보존한다.

공식 문서는 비밀을 만든 직후 값이 한 번만 표시된다고 안내한다. 복사한 값을 채팅이나 문서에 남기지 말고 승인된 비밀 저장소를 거쳐 n8n에 주입해야 한다. 회전 후 n8n이 캐시한 토큰 때문에 테스트가 계속 실패하면 자격 증명을 다시 만드는 절차도 런북에 포함한다.

전환 실패와 중복 실행에 대비하기

인증 전환은 정상 실행 한 번으로 검증이 끝나지 않는다. 관리자 동의 누락, 조직 조회 권한 누락, 잘못된 테넌트 ID, 만료된 비밀, 앱 전용에서 지원하지 않는 작업을 각각 시험해야 한다. 실패한 실행을 사람이 다시 눌렀을 때 메일이 두 번 발송되거나 파일이 두 번 이동되지 않도록 업무 키를 저장한다.

단계적 전환 순서는 다음이 안전하다.

• 읽기 전용 복제 워크플로에서 앱 인증 연결과 대상 조회를 확인한다.
• 실제 쓰기 대신 로그나 격리 폴더로 결과를 보내 대상 선택을 검증한다.
• 한 워크플로만 전환하고 기존 OAuth 자격 증명은 짧은 롤백 기간 동안 비활성 상태로 보존한다.
• 인증 실패율, 403 응답, 대상 불일치, 중복 실행을 관찰한 뒤 범위를 넓힌다.
• 전환 완료 후 개인 OAuth 연결과 불필요한 앱 권한을 회수한다.

비밀 회전 훈련도 필요하다. 새 비밀을 발급하고 n8n 자격 증명을 교체한 뒤 테스트 실행을 통과시키며, 이전 비밀을 폐기한 상태에서 예약 실행이 정상인지 확인한다. 이 절차를 실제 만료일 직전에 처음 해보면 복구 시간이 길어진다.

어떤 팀이 지금 전환해야 하나

퇴사·부서 이동이 잦고, 공유 메일함이나 팀 드라이브를 무인 처리하며, 개인 OAuth 토큰 만료로 정기 작업이 멈춘 적이 있다면 우선순위가 높다. 반대로 사용자 개인의 맥락이 필요한 Teams 채팅이나 개인 검색 작업이 핵심이면 앱 전용에서 지원되는 작업인지 먼저 확인해야 한다. 모든 흐름을 하나의 서비스 프린시펄로 통합하는 계획은 피한다.

도입 판단은 편의성과 권한 반경을 함께 본다. 개인 계정 종속성 감소, 야간 무인 실행 안정성, 중앙 회전 가능성이 이점이다. 반면 관리자 동의가 필요한 테넌트 권한, 비밀 관리 비용, 작업 대상 명시 책임은 새 부담이다. POEMORA 자동화 서비스에서는 현재 자격 증명과 업무 소유권을 기준으로 앱 분리 단위와 전환 순서를 설계할 수 있다.

사람 없는 자동화에도 책임자는 필요하다

앱 전용 인증의 목표는 소유자를 없애는 것이 아니라 실행 신원을 개인에서 관리 가능한 애플리케이션으로 옮기는 것이다. 각 서비스 프린시펄에는 업무 책임자, 기술 관리자, 권한 승인자, 비밀 회전일, 비상 중지 방법이 있어야 한다. 이 다섯 항목이 없다면 개인 OAuth를 제거해도 운영 부채는 다른 형태로 남는다.

POEMORA는 첫 전환 대상으로 읽기 위주의 공유 드라이브 자동화를 권한다. 권한을 좁게 시작하고 대상 필드를 고정하며, 회전과 인증 실패를 실제로 시험한 뒤 메일 발송이나 파일 삭제처럼 되돌리기 어려운 작업으로 확대해야 한다.