Databricks Trigger 노드를 사용하면 Databricks의 이벤트에 반응하고 Databricks를 다른 애플리케이션과 통합할 수 있습니다. 이 노드는 Databricks 잡(job)의 실행(run)이나 Databricks 파이프라인의 업데이트가 시작, 성공 또는 실패할 때 워크플로를 시작합니다.

트리거 설정#

1. 워크플로에 Databricks Trigger 노드를 추가합니다. 노드 선택기에서 Databricks를 검색하고 Databricks 항목을 엽니다. 이 항목에는 잡 이벤트가 트리거로 나열됩니다. 그중 아무거나 선택한 다음 노드에서 Resource와 Events를 설정합니다.
2. Authentication을 Access Token 또는 OAuth2로 설정하고 자격 증명을 선택합니다. OAuth2 자격 증명의 경우 서비스 프린시펄(service principal)을 사용하려면 Grant Type을 **Client Credentials (Service Principal)**로, 로그인한 사용자를 사용하려면 **Authorization Code (User)**로 설정합니다. 서비스 프린시펄 사용을 참고하세요.
3. 잡의 실행을 감시하려면 Resource를 Job으로, Databricks 파이프라인의 업데이트를 감시하려면 Pipeline으로 설정합니다.
4. Job에서 잡을, Pipeline에서 파이프라인을 선택합니다. 각 필드에는 세 가지 모드가 있습니다.
   • From List: 워크스페이스에서 선택합니다. 이름으로 필터링하려면 입력합니다. 파이프라인 목록은 ID로도 검색됩니다. Databricks는 자격 증명의 ID(identity)가 CAN VIEW 권한을 가진 잡만 나열합니다.
   • By ID: ID를 입력합니다. 잡 ID는 정수이며, 예를 들어 281874479417551입니다. 파이프라인 ID는 UUID이며, 예를 들어 8199cd89-e2f5-4169-a6aa-656a24c8886d입니다.
   • By URL: Databricks의 페이지 URL을 붙여 넣습니다. 예를 들어 https://<your-workspace>/jobs/<job-id> 또는 https://<your-workspace>/pipelines/<pipeline-id>입니다. 이 노드는 두 페이지의 해시 형식도 허용하며, 예를 들어 https://<your-workspace>/?o=<workspace-id>#job/<job-id>와 https://<your-workspace>/?o=<workspace-id>#joblist/pipelines/<pipeline-id>가 있습니다.
5. 워크플로를 시작할 Events를 선택합니다. 이벤트를 참고하세요.
6. 출력에 설명된 출력을 받으려면 Simplify를 켜 둡니다. 원시 Databricks 객체를 받으려면 끕니다.
7. Poll Times에서 폴링 Mode를 선택해 트리거가 Databricks를 확인하는 빈도를 설정합니다. 기본값은 Every Minute입니다. 트리거의 폴링 방식을 참고하세요.
8. 설정을 확인하려면 Fetch Test Event를 선택합니다. 트리거 테스트를 참고하세요.
9. 워크플로를 게시합니다.

이벤트#

트리거는 각 실행 또는 업데이트의 이벤트마다 워크플로를 한 번씩 시작합니다. 실행이나 업데이트를 완료된 것으로 한 번 보고한 뒤에는 다시 보고하지 않습니다. 예를 들어 잡 실행을 복구(repair)한 경우에도 마찬가지입니다.

잡 이벤트#

Resource가 Job일 때 사용할 수 있습니다. 기본 선택은 Run Failed와 Run Succeeded입니다.

• Run Failed: 실행이 완전한 성공이 아닌 결과로 끝났습니다. 취소됨, 건너뜀, 부분 실패(SUCCESS_WITH_FAILURES)인 실행이 여기에 포함됩니다.
• Run Started: 트리거가 잡의 새 실행을 확인했습니다.
• Run Succeeded: 모든 태스크가 성공한 상태로 실행이 끝났습니다. 종료 코드는 SUCCESS입니다.

실행이 두 폴링 사이에 시작하고 끝나는 경우, Run Started와 그 최종 이벤트를 모두 선택하면 같은 실행(execution)에서 두 개의 항목이 생성됩니다. 이때 두 항목은 같은 종료 시점 정보를 가집니다.

파이프라인 이벤트#

Resource가 Pipeline일 때 사용할 수 있습니다. 기본 선택은 Update Completed와 Update Failed입니다.

• Update Completed: 업데이트가 끝까지 실행되었습니다.
• Update Failed: 업데이트가 실패했거나 Databricks가 취소했습니다. 파이프라인을 중지하면 실행 중인 업데이트가 취소되므로, 중지하면 이 이벤트가 발생합니다.
• Update Started: 트리거가 파이프라인의 새 업데이트를 확인했습니다.

출력#

Simplify를 켜면 두 리소스 모두에서 각 항목이 같은 최상위 키를 가집니다. 키는 event, 감시 대상 객체(job 또는 pipeline), 실행 또는 업데이트, result, timing입니다. result는 Run Started와 Update Started에는 없습니다. 이 노드는 값이 없는 키를 제거합니다.

잡 출력#

Run Failed 항목은 다음과 같습니다.

{
	"event": "runFailed",
	"job": { "id": 281874479417551 },
	"run": {
		"id": 41847992357943,
		"name": "nightly-etl",
		"url": "https://adb-example.cloud.databricks.com/?o=1234567890#job/281874479417551/run/41847992357943",
		"trigger": "ONE_TIME",
		"creator": "service-principal@example.com",
		"parameters": { "fail": "true" }
	},
	"result": {
		"state": "TERMINATED",
		"code": "RUN_EXECUTION_ERROR",
		"type": "CLIENT_ERROR",
		"message": "Task main failed with message: Workload failed, see run output for details."
	},
	"timing": {
		"startedAt": "2026-09-01T13:37:18.171Z",
		"endedAt": "2026-09-01T13:37:58.640Z",
		"durationMs": 40469,
		"queuedMs": 14111
	}
}

파이프라인 출력#

Update Completed 항목은 다음과 같습니다.

{
	"event": "updateCompleted",
	"pipeline": {
		"id": "8199cd89-e2f5-4169-a6aa-656a24c8886d",
		"name": "orders-ingest",
		"url": "https://adb-example.cloud.databricks.com/pipelines/8199cd89-e2f5-4169-a6aa-656a24c8886d"
	},
	"update": {
		"id": "01ee1dae-da54-415a-aba8-0c8b0de503f1",
		"url": "https://adb-example.cloud.databricks.com/pipelines/8199cd89-e2f5-4169-a6aa-656a24c8886d/updates/01ee1dae-da54-415a-aba8-0c8b0de503f1"
	},
	"result": {
		"state": "COMPLETED",
		"message": "Update 01ee1d is COMPLETED."
	},
	"timing": {
		"startedAt": "2026-09-01T14:20:31.066Z",
		"runningAt": "2026-09-01T14:20:31.066Z",
		"endedAt": "2026-09-01T14:20:35.738Z",
		"durationMs": 4672
	}
}

원시 출력#

Simplify를 끄면 각 항목은 Databricks가 반환한 객체에 event 키를 더한 형태입니다. 잡의 경우 Jobs API가 나열하는 실행 객체입니다. 파이프라인의 경우 Pipelines API가 나열하는 update_progress 이벤트입니다. Databricks API 레퍼런스의 list runs와 list pipeline events를 참고하세요.

트리거의 폴링 방식#

이 노드는 Poll Times에 설정한 일정에 따라 Databricks를 확인합니다. 이벤트는 발생한 시점부터 최대 한 폴링 간격 뒤에 워크플로에 도착합니다. 이것이 너무 느리다면 웹훅으로 몇 초 안에 이벤트 받기를 참고하세요.

• 워크플로를 처음 게시하면 트리거는 그 시점부터 시작합니다. 잡의 경우 그 이전에 시작된 실행은 보고하지 않습니다. 파이프라인의 경우 게시했을 때 이미 실행 중이던 업데이트의 종료는 timing.startedAt, timing.runningAt, timing.durationMs 없이 여전히 보고합니다.
• 게시를 취소했다가 다시 게시하면 트리거는 중단된 지점부터 이어서 시작하며, 워크플로가 게시되지 않은 동안 발생한 일을 보고합니다. 잡이나 파이프라인을 변경하거나 Resource를 전환하면 그 시점부터 새로 시작합니다.
• 트리거는 Databricks가 늦게 나열한 실행이나 업데이트도 보고하며, 한 번만 보고합니다. 오래 걸리는 실행은 소요 시간과 관계없이 실행이 끝날 때 보고합니다.
• 잡이 두 폴링 사이에 1,000건을 넘는 실행을 시작하면 트리거는 가장 최근 1,000건을 보고하고 n8n 로그에 경고를 기록합니다.
• 폴링할 때마다 Databricks에 최소 한 번 요청하므로, Every Minute은 트리거 노드당 하루 최소 1,440건의 요청입니다. 아무것도 찾지 못한 폴링은 실행(execution)을 만들지 않습니다. 하루에 몇 번 실행되는 잡에는 10분 또는 15분 간격의 Every X로 충분합니다. 파이프라인 폴링은 업데이트 이벤트만이 아니라 해당 구간의 모든 이벤트를 읽으므로, 바쁜 파이프라인은 폴링당 비용이 잡보다 큽니다.

트리거 테스트#

Fetch Test Event를 선택하면 트리거를 수동으로 한 번 실행합니다. 잡의 경우 노드가 최근 25개의 실행을 읽습니다. 각 실행은 항목 하나를 만들며, 실행 중이면 Run Started, 완료되었으면 그 최종 이벤트입니다. 파이프라인의 경우 노드가 최근 100개의 이벤트를 읽고 그중 업데이트 이벤트를 반환합니다. 하나의 업데이트가 시작과 종료 이벤트를 모두 만들 수 있습니다. 노드는 항목을 오래된 순서로 나열하고 Events 선택에 해당하는 이벤트만 유지합니다. 일치하는 실행이나 업데이트가 없으면 테스트는 아무것도 반환하지 않습니다. 예를 들어 Run Started만 선택했는데 진행 중인 실행이 없는 경우입니다. 테스트는 게시된 워크플로가 이후에 보고하는 내용에 영향을 주지 않습니다.

서비스 프린시펄 사용#

워크플로가 게시된 상태로 유지되는 동안 트리거는 무인으로 실행되므로, 서비스 프린시펄에 속한 자격 증명을 사용하세요. 즉 Grant Type을 **Client Credentials (Service Principal)**로 설정한 OAuth2 자격 증명입니다. 사람에게 연결된 자격 증명은 그 사람이 퇴사하거나 동의를 철회하면 작동을 멈춥니다. 설정 단계는 OAuth2 사용(서비스 프린시펄)을 참고하세요. 시크릿의 만료일을 추적하세요. 시크릿이 만료되면 트리거가 멈춥니다.

CAN VIEW 권한 부여#

자격 증명의 ID는 감시하는 각 잡 또는 파이프라인에 대해 CAN VIEW 권한이 필요합니다. 이는 둘 모두에서 가장 낮은 권한 수준입니다. 잡에 권한을 부여하려면 Databricks에서 잡을 열고 Job details 창에서 Edit permissions를 선택합니다. 사용자 또는 서비스 프린시펄을 고르고 권한을 Can View로 설정한 다음 Add와 Save를 선택합니다. 파이프라인은 파이프라인의 권한 설정에서 부여합니다. Databricks 문서의 잡 권한과 파이프라인 액세스 제어 목록을 참고하세요. 자격 증명에 필요한 나머지 권한은 필요한 Databricks 권한 표에 나와 있습니다.

웹훅으로 몇 초 안에 이벤트 받기#

트리거는 폴링하므로 이벤트는 발생한 시점부터 최대 한 폴링 간격 뒤에 워크플로에 도착합니다. 잡 이벤트를 몇 초 안에 받아야 한다면, 대신 Databricks가 Webhook 노드로 이벤트를 푸시하도록 하세요. Databricks 잡 알림은 실행이 시작, 성공 또는 실패할 때 웹훅을 호출할 수 있습니다. 파이프라인은 웹훅을 보낼 수 없습니다. 잡을 통해 파이프라인 감시를 참고하세요.

시작하기 전에 확인할 사항은 다음과 같습니다.

• Databricks 워크스페이스 관리자가 알림 대상(destination)을 만들어야 합니다. Databricks는 페이로드에 서명하지 않으므로 Webhook 노드의 Basic Auth 사용자 이름과 비밀번호가 유일한 검증 수단입니다.
• 페이로드에는 ID만 들어 있으므로, 워크플로가 Databricks 노드로 실행 정보를 읽어야 합니다.
• Databricks는 재시도를 문서화하지 않으므로, 누락된 이벤트에 대비한 대체 수단으로 Databricks Trigger 노드를 함께 두세요.
• Databricks는 호출 순서를 보장하지 않습니다. jobs.on_success 호출이 같은 실행의 jobs.on_start 호출보다 먼저 도착할 수 있고, 대상을 추가한 뒤 첫 실행에서는 jobs.on_start가 생략될 수 있습니다. 호출이 도착하는 순서가 아니라 $json.body.event_type을 기준으로 분기하세요.
• Databricks가 HTTPS로 n8n 인스턴스에 접근할 수 있어야 합니다. 방화벽 뒤의 셀프 호스팅 인스턴스라면 알림 대상 페이지의 Networking requirements에 나열된 Databricks 아웃바운드 IP 대역을 허용하세요.

설정 방법은 다음과 같습니다.

1. n8n에서 Webhook 노드를 추가합니다. HTTP Method를 POST로 설정합니다. Authentication을 Basic Auth로 설정하고 User와 Password가 있는 Basic Auth 자격 증명을 만듭니다. Respond는 Immediately로 유지합니다. Production URL을 복사합니다.
2. Webhook 노드 뒤에 Databricks 노드를 추가합니다. Resource를 Job으로, Operation을 Get Run으로 설정합니다. Run을 By ID로 설정하고 표현식 {{ $json.body.run.run_id }}를 입력합니다. 이 노드는 run_state, run_result, run_error_message가 포함된 전체 실행 정보를 반환합니다. Get Run을 참고하세요.
3. 워크플로를 게시합니다.
4. Databricks에서 워크스페이스 관리자가 대상을 만듭니다. 상단 바에서 사용자 이름을 선택한 다음 Settings를 선택합니다. Workspace admin 섹션에서 Notifications 탭을 열고 Manage를 선택합니다. Add destination을 선택하고 Webhook을 고른 다음, 프로덕션 URL을 입력하고 1단계의 User와 Password를 입력합니다. Create를 선택합니다. 알림 대상 관리를 참고하세요.
5. 잡에서 Job details 창을 열고 Job notifications 아래의 Edit notifications를 선택합니다. Add notification을 선택하고 Destination에서 대상을 고른 다음 Start, Success, Failure 중 필요한 항목을 선택합니다. Save를 선택합니다. 잡에 알림 추가를 참고하세요.

그러면 Databricks는 이벤트마다 POST 요청을 한 번 보냅니다. 본문은 $json.body로 도착합니다.

{
	"event_type": "jobs.on_failure",
	"workspace_id": 1234567890,
	"run": { "run_id": 41847992357943 },
	"job": { "job_id": 281874479417551, "name": "nightly-etl" }
}

event_type은 jobs.on_start, jobs.on_success, jobs.on_failure 또는 jobs.on_duration_warning_threshold_exceeded입니다. Databricks에서 필요한 확인란만 선택하거나, If 노드로 $json.body.event_type에 따라 분기하세요. 하나의 잡은 이벤트 유형마다 최대 세 개의 대상에 알릴 수 있습니다.

잡을 통해 파이프라인 감시#

Pipeline 리소스는 무엇이 시작했든 Databricks 파이프라인의 모든 업데이트를 감시합니다. 다음 세 가지 경우에는 대신 잡을 감시하세요.

파이프라인이 잡의 태스크로 실행되는 경우#

파이프라인 태스크 뒤에 다른 태스크가 이어지는 경우처럼 잡 전체가 중요하다면 잡을 감시하세요. 잡은 자신이 시작한 업데이트만 봅니다. 실패한 업데이트의 예외와 스택을 result.errors에서 확인해야 한다면 파이프라인을 감시하세요.

파이프라인이 연속형인 경우#

연속 파이프라인은 Update Completed를 만들지 않습니다. 완료 신호를 얻으려면 파이프라인 태스크가 있는 트리거형(triggered) 잡에서 실행하세요. 잡이 파이프라인을 완료되는 단일 업데이트로 실행하므로 잡의 Run Succeeded와 파이프라인의 Update Completed가 모두 발생합니다. 이 경우 파이프라인은 연속적으로가 아니라 잡이 실행될 때 데이터를 처리합니다.

이벤트를 몇 초 안에 받아야 하는 경우#

잡은 웹훅을 보낼 수 있지만 파이프라인은 보낼 수 없습니다. 파이프라인 태스크가 있는 잡을 사용하면 파이프라인도 웹훅으로 몇 초 안에 이벤트 받기의 웹훅 경로를 쓸 수 있습니다.

자세한 내용은 잡의 파이프라인 태스크와 트리거형 및 연속형 파이프라인 모드를 참고하세요.

일반적인 문제#

트리거가 워크플로를 시작하지 않는 경우#

• 워크플로를 처음 게시하면 트리거는 그 시점부터 시작하며 이전 실행을 다시 재생하지 않습니다. 테스트하려면 새 실행이나 업데이트를 시작하세요.
• Executions 목록을 엽니다. 실패한 폴링은 Databricks 오류와 함께 그곳에 표시됩니다.
• 잡의 경우 CAN VIEW 권한이 없어도 오류가 발생하지 않습니다. 트리거는 실패 없이 폴링하지만 절대 시작되지 않습니다. 권한 오류를 참고하세요.
• Events 선택을 확인하세요. Run Started와 Update Started는 기본으로 선택되어 있지 않습니다.
• 연속 파이프라인은 Update Completed를 만들지 않습니다. 잡을 통해 파이프라인 감시를 참고하세요.
• 아직 진행 중인 실행은 Run Started만 만듭니다. 최종 이벤트는 Databricks가 실행을 완료로 보고한 뒤에 이어집니다.
• 자격 증명이 만료되었습니다. 서비스 프린시펄 시크릿의 유효 기간은 최대 730일이고, 사용자 로그인 연결은 리프레시 토큰이 만료되면 끝납니다. OAuth 시크릿 만료와 토큰 수명 구성을 참고하세요.

잡이나 파이프라인이 목록에 없는 경우#

Databricks는 자격 증명의 ID가 CAN VIEW 권한을 가진 잡만 나열합니다. 검색은 워크스페이스의 처음 1,000개 잡 또는 파이프라인까지만 훑습니다. 대신 By ID 또는 By URL을 사용하거나, 먼저 CAN VIEW 권한을 부여하세요.

권한 오류#

자격 증명의 ID에 CAN VIEW가 없으면 Databricks는 PERMISSION_DENIED로 요청을 거부합니다. n8n은 Databricks 메시지를 오류로 표시하고 다음 힌트 중 하나를 설명으로 추가합니다.

Grant Can View on the job to the user or service principal of the credential, then retry.

Grant Can View on the pipeline to the user or service principal of the credential, then retry.

Fetch Test Event를 선택하면 노드에서 오류가 표시됩니다. 게시된 워크플로에서는 실패한 폴링마다 Executions 목록에 실패한 실행으로 나타납니다. CAN VIEW 권한 부여를 참고하세요.

잡의 경우, ID에 CAN VIEW가 없으면 Databricks는 PERMISSION_DENIED 대신 빈 결과로 실행 목록에 응답합니다. 그러면 Fetch Test Event는 아무것도 반환하지 않고, 게시된 트리거는 오류 없이 폴링하지만 절대 시작되지 않습니다. 눈에 보이는 유일한 징후는 From List 선택기에 잡이 없다는 점입니다. 잡에 CAN VIEW 권한을 부여한 다음 Fetch Test Event를 다시 선택하세요. 트리거는 권한 부여 전 5분 동안 발생한 실행을 다음 폴링에서 보고합니다.

잘못된 잡 또는 파이프라인 ID#

노드는 Databricks를 호출하기 전에 ID를 확인합니다.

• Job ID must be a whole number: Databricks의 잡 URL에 표시된 숫자 ID를 사용하세요.
• Job ID is too large to send exactly: 9007199254740991을 초과하는 ID는 JavaScript에서 정밀도가 손실되므로 노드가 이 잡을 감시할 수 없습니다.
• Pipeline ID must be a UUID: Databricks의 파이프라인 URL에 표시된 ID를 사용하세요. 예: 8199cd89-e2f5-4169-a6aa-656a24c8886d.

예기치 않은 응답#

자격 증명의 Host가 Databricks 워크스페이스 URL이 아니면 n8n이 Databricks did not return a JSON list of job runs 또는 Databricks did not return a JSON list of pipeline events를 표시합니다. Host를 확인하고 다시 시도하세요.

관련 리소스#

• Databricks 노드
• Databricks 자격 증명
• Jobs API: list runs
• Pipelines API: list pipeline events
• Databricks 액세스 제어 목록