자동화: 설정, 트리거, 레시피 및 모니터링

자동화는 Edvisor에서 어떤 일이 발생했을 때 자동으로 실행되는 규칙입니다. 예를 들어 새 학생에게 이메일을 보내거나, 제안서가 조회되거나 수락되었을 때 후속 조치를 하거나, 파이프라인 단계가 변경될 때 상담원에게 알림을 보내거나, 작업을 생성하거나, 웹훅으로 데이터를 전송하거나, 비자 또는 보험 증서 날짜 전에 알림을 보낼 수 있습니다. 이 통합 문서에서는 전체 설정 흐름(Automations를 찾는 방법, 기능 활성화, 규칙 생성, 찾기, 복제 및 관리), 5개 영역(학생, 제안서, 등록, 세일, 보험)에 걸쳐 제공되는 18개 이벤트와 '실행 시점' 타이밍 옵션, 조건, 작업 및 변수에 대한 참고 자료, 바로 사용할 수 있는 자동화 레시피, 그리고 로그에서 자동화 실행을 모니터링하는 방법을 다룹니다.

자동화는 Edvisor에서 어떤 일이 발생했을 때 자동으로 실행되는 규칙입니다. 각 규칙에는 이벤트(규칙을 시작하는 항목), 선택적 조건(필터), 하나 이상의 작업(수행할 작업)이 있습니다. 이 기사에서는 Automations를 찾는 방법, 기능을 활성화하는 방법, 규칙을 생성하고 찾고 복제하고 관리하는 방법을 다룹니다.

정의

자동화는 Edvisor에서 어떤 일이 발생했을 때 자동으로 실행되는 규칙입니다. 각 자동화에는 다음이 포함됩니다.

• 이벤트 — 자동화를 시작하는 항목입니다.
• 선택적 조건 — 충족해야 하는 필터입니다.
• 하나 이상의 작업 — 자동화가 실행될 때 수행할 작업입니다.

일반적인 사용 사례:

• 새 학생이 생성되면 환영 이메일을 보냅니다.
• 학생이 업데이트되면 상담원에게 알립니다.
• 학생이 특정 국적에 해당하면 후속 조치 작업을 생성합니다.
• 웹훅을 통해 학생 데이터를 자체 시스템으로 전송합니다.
• 학생의 비자가 만료되기 전에 알림을 보냅니다.
• 학생이 제안서를 조회하거나 수락했을 때 또는 제안서가 만료되기 전에 후속 조치를 합니다.
• 학교가 등록을 수락하면 인계 작업을 생성합니다.
• 세일이 생성되면 온보딩 작업을 생성합니다.
• 학생이 특정 파이프라인 단계로 이동하면 상담원에게 알림을 보냅니다.
• 보험 증서가 시작되거나 종료되기 전에 학생에게 알림을 보냅니다.

사용 가능한 이벤트

자동화는 이벤트에 의해 트리거됩니다. 5개 영역으로 그룹화된 18개의 이벤트가 있습니다. 각 이벤트에 대한 전체 세부 정보는 아래의 트리거, 조건 및 작업 참고 자료 섹션을 참조하세요.

학생

• 새 학생이 생성됨
• 학생이 업데이트됨
• 학생이 삭제됨
• 학생의 생일
• 학생의 비자가 곧 만료됨

제안서

• 제안서가 생성됨
• 제안서 발행됨 — 학생에게 발행되거나 전송됨. 이전에는 Proposal Published라고 불렸으며, 제품의 나머지 부분과 일치하도록 이름이 변경됨.
• 제안서 조회됨 — 학생이 제안서를 처음 열 때 한 번만 실행됨.
• 제안서 수락됨 — 수락됨으로 전환될 때 실행됨.
• 제안서 만료 날짜 — 제안서가 만료되는 날 이전, 당일 또는 이후.

등록

• 학생의 새 등록이 생성됨
• 학교에서 등록을 수락함

세일

• 세일이 시작됨
• 숙박 세일이 시작됨
• 세일이 생성됨
• 파이프라인 단계 변경 — 단계로 이동됨 및 단계에서 이동됨 조건 사용. 일괄 재할당은 이를 실행하지 않음.

보험

• 보험 시작 날짜
• 보험 종료 날짜

보험 이벤트는 확정된 예약에만 적용됨.

참고: 자동화를 트리거할 수 있는 이벤트의 범위를 확장하기 위해 새로운 이벤트가 시간이 지남에 따라 추가될 예정임.

찾아가는 방법

설정 > 모집 > 자동화로 이동합니다.

관리자만 자동화를 생성, 편집, 활성화, 비활성화 또는 삭제할 수 있습니다. 상담사는 자동화를 볼 수 있지만 변경할 수는 없습니다.

자동화 활성화

자동화 섹션을 처음 열면 기능을 설명하는 활성화 화면이 표시됩니다. 활성화하면 계정에 대한 API 키 쌍이 생성되며, Edvisor는 이를 내부적으로 사용하여 자동화를 실행합니다. 키를 직접 관리할 필요는 없습니다.

활성화 후 자동화 목록 보기로 이동합니다. 헤더에는 총 개수가 표시되며(예: "자동화 (21)"), 각 자동화는 카드로 표시됩니다.

각 카드에는 다음이 표시됩니다:

• 자동화 이름.
• 이를 트리거하는 이벤트.
• 조건 요약 칩(예: "조건 3개 · 임의")으로, 규칙을 열지 않고도 조건 수와 모든 조건 또는 임의 조건 로직 사용 여부를 확인할 수 있습니다.
• 작업 칩.
• 활성화 / 비활성화 토글.
• 자동화를 복제할 수 있는 카드 메뉴.

자동화 생성

시작하는 방법은 두 가지입니다:

• 처음부터 — 오른쪽 상단에서 자동화 생성을 클릭합니다.
• 템플릿에서 — 목록 보기 오른쪽 패널에서 템플릿을 선택합니다(예: "신규 학생 환영"). 템플릿은 이벤트, 조건 및 작업을 미리 입력하므로 세부 정보만 사용자 지정하면 됩니다.

빌더

빌더는 세 부분으로 구성됩니다:

• 상단 — 자동화 이름(필수), 설명, 그리고 "이 자동화가 실패하면 이메일 보내기" 토글입니다. 이 자동화의 실행이 실패할 때마다 이메일을 받으려면 토글을 켜 두세요.
• 왼쪽 패널 — 세 개의 단계가 차례로 쌓여 표시되는 규칙 순서: 이벤트 > 조건 > 작업. 구성하려는 단계를 클릭하세요.
• 오른쪽 패널 — 선택한 단계의 구성 화면입니다.

오른쪽 패널 하단의 이벤트 / 조건 / 작업 버튼을 사용해 단계를 앞뒤로 이동할 수도 있습니다.

이벤트를 구성할 때 자동화가 실행되는 시점도 선택합니다 — 즉시 실행하거나, 날짜와 연결된 이벤트의 경우 해당 날짜의 이전 / 당일 / 이후에 실행하도록 설정할 수 있습니다(일수로 기간을 설정합니다). 날짜 기반 이벤트의 경우 빌더가 규칙을 구성하는 동안 이를 일반적인 언어로 다시 설명하므로 저장하기 전에 타이밍을 확인할 수 있습니다.

완료되면 오른쪽 상단의 저장을 클릭하세요. 모든 필수 필드가 입력될 때까지 저장 버튼은 비활성화되어 있습니다.

자동화 찾기

규칙이 몇 개 이상 있으면 자동화 목록에서 검색을 사용해 이름으로 자동화를 찾을 수 있습니다:

• 검색 상자에 입력하면 목록이 입력하는 동안 필터링됩니다.
• 일치하는 항목의 결과 수가 표시됩니다.
• 일치하는 항목이 없으면 전용 결과 없음 상태가 표시됩니다. 이는 이제 자동화가 실제로 하나도 없을 때만 표시되는 "첫 번째 자동화 만들기" 빈 화면과는 다릅니다.

자동화 복제

규칙을 다시 만들지 않고 재사용하려면 자동화의 카드 메뉴를 열고 복제를 선택하세요. 한 번 클릭하면 됩니다.

복사본은 꺼진 상태로 생성되며, 이를 알리는 배너가 표시됩니다. 이는 의도된 동작입니다. 검토를 마칠 때까지 아무것도 실행되지 않습니다. 복사본을 열고 이름과 변경이 필요한 항목을 수정한 다음 토글로 활성화하세요.

기존 자동화 관리

자동화 목록에서 다음 작업을 수행할 수 있습니다:

• 카드를 클릭해 자동화를 엽니다. 그러면 자동화 편집 화면이 열리며, 자동화(빌더)와 로그(실행 기록)의 두 탭이 표시됩니다.
• 카드의 토글을 사용해 활성화하거나 비활성화합니다. 비활성화된 자동화는 유지되지만 실행되지 않습니다.
• 카드 메뉴에서 자동화를 복제합니다(위 내용 참조).
• 편집 화면에서 자동화를 삭제합니다. 과거 실행 로그는 유지됩니다.

언어

자동화는 22개 언어로 완전히 번역되며 계정 언어를 따릅니다.

트리거, 조건 및 작업 참조

이 문서는 자동화를 구성하는 데 사용하는 구성 요소, 즉 자동화를 시작하는 이벤트, 실행 여부를 결정하는 조건, 그리고 자동화가 수행하는 작업에 대한 참조입니다.

무엇인가요

모든 자동화는 세 부분으로 구성됩니다:

• 이벤트 — 자동화를 시작하는 Edvisor에서 발생하는 일입니다(예: 새 학생이 생성됨).
• 조건(선택 사항) — 자동화가 실행되기 위해 충족되어야 하는 추가 규칙입니다.
• 작업 — 자동화가 실행될 때 수행하는 작업입니다(예: 이메일 보내기).

자동화 빌더에서 이러한 항목을 선택합니다. 이 섹션에는 선택할 수 있는 모든 옵션이 나와 있습니다.

이벤트

이벤트는 자동화를 시작하는 트리거입니다. 학생, 제안서, 등록, 세일, 보험의 5개 카테고리로 그룹화된 18개의 이벤트가 있습니다.

학생 (5개 이벤트)

• 새 학생이 생성됨
• 학생이 업데이트됨
• 학생이 삭제됨
• 학생의 생일임
• 학생의 비자가 곧 만료됨

제안서 (5개 이벤트)

• 제안서가 생성됨
• 제안서 발행 — 제안서가 발행되거나 학생에게 전송됩니다. 이 이벤트는 이전에 제안서 게시라고 불렸으며, 제품의 다른 부분과 명칭을 맞추기 위해 이름이 변경되었습니다.
• 제안서 조회 — 학생이 제안서를 처음 여는 시점입니다. 한 번만 실행되며 이후에 다시 조회해도 실행되지 않습니다.
• 제안서 수락 — 실제로 수락 상태로 전환될 때 실행됩니다. 학생이 옵션 A를 수락한 후 옵션 B를 수락하더라도 이벤트는 두 번이 아니라 한 번 발생합니다.
• 제안서 만료 날짜 — 날짜 기반입니다. 제안서가 만료되기 전, 당일 또는 이후에 실행할 수 있습니다.

등록 (2개 이벤트)

• 학생의 새 등록이 생성됨
• 학교에서 등록을 수락함

세일 (4개 이벤트)

• 세일이 시작됨
• 숙박 세일이 시작됨
• 세일이 생성됨
• 파이프라인 단계 변경 — 학생이 파이프라인의 단계 간 이동합니다. 이동한 단계 및 이동 전 단계 조건을 사용하여 단계를 선택합니다(아래 조건 참조). 대량 재할당은 이 이벤트를 트리거하지 않습니다.

보험 (2개 이벤트)

• 보험 시작 날짜
• 보험 종료 날짜

두 보험 이벤트는 날짜 기반이며 확정된 예약에만 적용됩니다. 확정되지 않은 예약의 보험은 해당 이벤트를 트리거하지 않습니다.

참고: 시간이 지남에 따라 새로운 이벤트가 추가되어 자동화를 트리거할 수 있는 이벤트의 범위가 확대됩니다.

실행 시점

각 이벤트에 대해 실행 시점을 설정합니다.

• 즉시 — 이벤트가 발생하는 즉시 자동화가 실행됩니다.
• 이전 — 날짜 이전의 지정된 일수만큼 앞서 실행됩니다.
• 당일 — 해당 날짜에 실행됩니다.
• 이후 — 날짜 이후의 지정된 일수만큼 지나서 실행됩니다.

날짜 기반 이벤트(학생의 비자 만료일, 제안서 만료일 또는 보험 증권 시작일이나 종료일 등)는 이전 또는 이후에 대한 기간을 일수로 입력하도록 요청합니다. 날짜 기반 이벤트는 미래 날짜에 의존하므로 "즉시" 실행할 수 없습니다.

날짜 기반 트리거를 만들 때 빌더는 규칙을 일반 언어로 다시 설명하므로 저장하기 전에 타이밍이 의도한 대로 읽히는지 확인할 수 있습니다.

조건

조건은 자동화가 실행되기 위해 충족되어야 하는 선택적 규칙입니다.

조건 결합

• 조건을 모두 논리(모든 조건이 참이어야 함) 또는 하나라도 논리(최소 하나의 조건이 참이어야 함)로 결합할 수 있습니다.
• 목록 보기의 자동화 카드에는 설정한 내용의 요약이 표시됩니다. 예: "조건 3개 · 하나라도".
• 하나의 자동화에서 동일한 필드를 두 번 이상 사용할 수 있으므로 단일 필드에서 범위와 여러 부분으로 구성된 규칙을 만들 수 있습니다.

필드 유형

기존의 목록 스타일 필드와 함께 조건은 이제 다음을 지원합니다:

• 날짜 필드.
• 텍스트 필드.
• 예/아니요 필드.

알려진 조건 필드

• 학생 국적 — "다음 중 하나"와 같은 연산자를 사용합니다. 예를 들어 특정 국적의 학생에 대해서만 자동화를 실행할 수 있습니다.
• 보험 목적지 국가 — 보험 관련 규칙에 사용됩니다.
• 보험 제공업체 — 보험 관련 규칙에 사용됩니다.
• 단계로 이동됨 및 단계에서 이동됨 — 파이프라인 단계 변경 이벤트와 함께 사용됩니다. 선택기에는 사용 가능한 파이프라인과 해당 단계가 표시되므로 먼저 파이프라인을 선택한 다음 단계를 선택합니다.

최근 변경 사항

• 이전에 숨겨져 있던 두 개의 제안서 조건을 이제 사용할 수 있습니다. 릴리스 노트에는 이름이 명시되지 않았으므로 제안서 이벤트의 조건 선택기에서 현재 목록을 확인하세요.
• 한 연산자가 폐기되었습니다. 해당 필드에는 의미가 없었기 때문입니다. 릴리스 노트에는 이름이 명시되지 않았습니다. 이전에 사용하던 연산자를 찾을 수 없다면 이것이 원인일 가능성이 높습니다. 조건을 다시 열고 남아 있는 연산자 중 가장 가까운 것을 선택하세요.

작업

작업은 자동화가 실행될 때 수행하는 작업입니다. 하나 이상 추가할 수 있습니다. 작업은 하나씩 실행되며 각각 독립적으로 실행됩니다. 한 작업이 실패해도 다른 작업은 계속 실행됩니다.

작업은 두 가지 범주로 그룹화됩니다.

커뮤니케이션

• 학생에게 이메일 보내기 — 학생에게 이메일을 보냅니다. 학생의 이메일이 자동으로 입력됩니다. 제목과 본문(둘 다 필수)을 설정하고 변수를 사용할 수 있습니다(아래 참조).
• 상담사에게 이메일 보내기 — 학생에게 배정된 상담사에게 이메일을 보냅니다.

통합

• 작업 생성 — 작업을 생성합니다. 작업 이름, 마감일 및 담당자를 설정합니다.
  • 참고: 작업의 변수는 일반 텍스트로 저장되며 실제 값으로 대체되지 않습니다. 작업 이름 안의 변수에 의존하지 마세요.
• 웹훅 보내기 — 선택한 URL로 데이터를 보냅니다. URL과 페이로드를 설정합니다. 안전을 위해 웹훅은 공개 주소로만 전송할 수 있으며 최대 5회의 리디렉션을 따릅니다.

변수

변수를 사용하면 실제 학생 및 기관 세부 정보를 이메일에 삽입할 수 있습니다. 자동화가 실행되면 각 변수가 실제 값으로 대체됩니다.

학생

• 학생 ID
• 이름
• 성
• 이메일
• 생년월일

기관

• 기관 이름
• 사무실 이름

변수를 채울 수 없는 경우(예: 학생에게 생년월일이 없는 경우) 메시지에서 해당 자리 표시자가 제거됩니다.

언어

이벤트, 조건 및 작업을 포함한 자동화 빌더는 22개 언어로 완전히 번역되며 계정 언어를 따릅니다.

자동화 레시피: 일반적인 설정

이 섹션에서는 설정 > 모집 > 자동화에서 만들 수 있는 일반적인 자동화 설정을 설명합니다. 각 레시피는 동일한 형식으로 구성됩니다 — 달성하는 목표, 선택할 트리거, 실행 시점, 추가할 조건, 권장 작업 및 주의할 사항 — 따라서 필요한 레시피를 빠르게 찾아 몇 분 안에 만들 수 있습니다.

새로운 트리거와 조건이 출시됨에 따라 시간이 지나면서 더 많은 레시피가 추가될 예정이므로, 이 목록을 고정된 목록이 아니라 계속 확장되는 라이브러리로 생각하세요. 아직 여기에 없는 유용한 설정을 만든 경우 다른 섹션으로 추가할 수 있습니다.

사용 가능한 전체 목록은 위의 트리거, 조건 및 작업 참조 섹션을 확인하세요.

레시피 1 — 제안서 후속 조치

달성하는 목표: 수동으로 독촉하지 않아도 제안서가 진행되도록 합니다. 제안서가 만료되기 전에 학생에게 알림을 보내고, 학생이 제안서를 확인했지만 조치를 취하지 않은 경우 후속 조치를 수행하며, 학생이 수락하는 즉시 내부적으로 인계합니다.

선택할 트리거: 원하는 동작마다 하나의 자동화를 설정하며, 제안서 그룹에서 선택합니다:

• 제안서 조회됨 — 학생이 제안서를 처음 열었을 때입니다.
• 제안서 수락됨 — 학생이 수락했을 때입니다.
• 제안서 만료일 — 제안서가 만료되는 날 전, 당일 또는 후에 실행되도록 설정할 수 있는 날짜 기반 트리거입니다.

실행 시점:

• Proposal Viewed는 학생이 제안서를 처음 열 때 실행되며, 이후 다시 열어도 실행되지 않습니다.
• Proposal Accepted는 실제로 수락 상태로 전환될 때 실행됩니다.
• Proposal expiry date는 만료일을 기준으로 실행됩니다. 알림을 보내려면 며칠 전으로 설정하세요. 날짜 기반 트리거를 만들 때 빌더는 규칙을 일반 언어로 다시 설명해 주므로, 올바른 오프셋과 방향을 선택했는지 확인할 수 있습니다.

추가할 조건: 자동화가 원하는 학생에게만 실행되도록 범위를 좁히세요. 예를 들어 학생 국적이나 목적지 또는 프로그램 유형과 같은 제안서 필드를 기준으로 설정할 수 있습니다. 하나의 규칙에서 동일한 필드를 두 번 이상 사용하여 두 가지 테스트를 수행할 수도 있으며, 카드에는 설정한 내용의 요약이 표시됩니다(예: "조건 3개 · 임의"). 모든 조건이 일치해야 한다면 일치 모드를 전체로 유지하고, 하나의 조건만 충족해도 된다면 임의를 사용하세요.

추천 작업:

• 만료 전: 학생에게 제안서 링크가 포함된 알림 이메일을 보내고, 담당 상담원이 전화하도록 작업을 생성합니다.
• 수락 시: 축하 이메일을 보내고, 다음 단계 작업(예치금, 서류)을 생성하며, 웹훅 또는 내부 알림을 통해 팀에 알립니다.
• 열람했지만 수락하지 않은 경우: Proposal Viewed 자동화를 설정하여 일정 시간이 지난 후 후속 이메일을 보내거나, 만료일 알림을 사용하여 공백을 보완합니다.

주의할 점: Proposal Viewed는 처음 열 때만 실행됩니다. 학생이 제안서를 다섯 번 다시 열어도 하나의 이벤트만 생성되므로, 반복 열람을 전제로 한 로직을 만들지 마세요. Proposal Accepted는 상태가 전환될 때 한 번만 실행됩니다. 학생이 옵션 A를 수락한 후 옵션 B로 변경하더라도 이는 두 개가 아닌 단일 이벤트이므로, 수락 자동화는 변경 시 다시 실행되지 않습니다.

레시피 2 — 학생에게 보험 날짜 알림 보내기

달성되는 결과: 학생은 보험 보장이 시작되기 전과 종료되기 전에 미리 안내를 받아 유효한 보장을 유지한 채 여행하고 갱신 시기를 알 수 있습니다. 또한 팀은 적절한 시점에 서류를 확인할 수 있는 알림을 받습니다.

선택할 트리거: 트리거 선택기의 새로운 보험 카테고리에서 다음을 선택하세요.

• 보험 시작 날짜 — 입국 전 안내 및 "보장이 곧 시작됩니다" 메시지에 사용합니다.
• 보험 종료 날짜 — 갱신 및 만료 알림에 사용합니다.

실행 시점: 두 트리거 모두 날짜 기반이므로 해당 날짜를 기준으로 전, 당일 또는 후를 선택할 수 있습니다. 예를 들어 보험 시작 날짜 7일 전이나 보험 종료 날짜 14일 전으로 설정할 수 있습니다. 설정하는 동안 빌더가 규칙을 일반 언어로 다시 설명하므로 저장하기 전에 오프셋이 의도한 대로 표시되는지 확인할 수 있습니다.

추가할 조건: 국가별 지침을 보내려면 보험 목적지 국가를 사용하고, 보험 제공업체에 따라 문구나 문서가 다른 경우에는 보험 제공업체를 사용하세요. 두 가지가 모두 필요하면 함께 사용하고, 카드의 조건 요약을 사용하여 규칙이 설명한 내용과 일치하는지 확인하세요.

권장 작업:

• 학생에게 보험 증권 세부 정보와 휴대해야 할 물품을 이메일로 보내세요.
• 상담원이 학생이 서류를 가지고 있는지 확인하도록 작업을 생성하세요.
• 종료 날짜의 경우 갱신 안내 이메일을 보내고 보장 연장에 대해 논의할 작업을 생성하세요.

주의할 점: 보험 트리거는 확정된 예약에만 적용됩니다. 아직 확정되지 않은 예약에 연결된 보험은 이러한 트리거를 실행하지 않으므로, 대기 상태의 학생에게는 아무것도 전송되지 않습니다. 이 레시피를 유일한 보장 확인 방법으로 의존하지 마세요.

레시피 3 — 파이프라인 단계 변경에 반응하기

달성하는 목표: 파이프라인 이동을 자동으로 작업으로 전환합니다. 학생이 단계에 진입하면 환영 메시지를 보내고, 진행하면 인계 작업을 생성하며, 단계로 되돌아가거나 단계를 벗어나면 내부 알림을 보냅니다.

선택할 트리거: 파이프라인 단계 변경.

실행 시점: 학생의 파이프라인 단계가 변경될 때마다 실행됩니다. 그런 다음 트리거의 조건을 사용하여 어떤 변경을 처리할지 결정합니다.

추가할 조건: 학생이 특정 단계에 도착했을 때 작업을 수행하려면 "단계로 이동됨"을 사용하고, 단계를 떠났을 때 작업을 수행하려면 "단계에서 이동됨"을 사용하세요. 두 가지를 결합하여 특정 전환(한 단계에서 나와 다른 단계로 이동)을 포착하고, 국적, 목적지, 프로그램 등 다른 조건을 추가하여 적절한 학생에게만 규칙이 적용되도록 범위를 좁히세요.

권장 작업:

• 새 단계로 이동됨: 단계에 맞는 이메일을 보내고 담당자를 위한 다음 작업을 생성하세요.
• 활성 단계에서 뒤로 이동됨: 관리자에게 알리거나 검토 작업을 생성하세요.
• 모든 단계 변경: 웹훅을 실행하여 보고 시스템이나 CRM이 최신 상태를 유지하도록 하세요.

주의할 점: 대량 재할당은 이를 트리거하지 않습니다. 단계를 대량으로 변경하면 자동화가 실행되지 않으므로, 대규모 정리나 마이그레이션이 로그에 아무런 기록 없이 진행된 것처럼 보입니다. 대량 단계 이동을 계획할 때 후속 이메일과 작업이 생성되지 않는다는 점을 전제로 하고, 이를 수동으로 처리하세요.

자동화 실행 모니터링

자동화가 실행될 때마다 로그 항목이 기록됩니다. 이 섹션에서는 해당 로그를 찾는 위치, 각 필드의 의미, 문제가 발생했을 때 로그를 읽는 방법을 설명합니다.

자동화는 학생, 제안, 등록, 판매 및 보험 이벤트 등 다양한 이벤트에 의해 시작될 수 있으므로, 특정 자동화의 로그는 해당 자동화가 기반으로 구축된 트리거를 반영합니다. 아래의 필드, 상태 및 실패 사유는 어떤 트리거가 실행되었는지와 관계없이 동일합니다.

무엇인가요

로그는 단일 자동화 실행 기록입니다. 실행할 때마다 하나의 로그 항목이 생성되므로 정확히 무슨 일이 언제 발생했는지, 그리고 정상적으로 작동했는지 확인할 수 있습니다. 로그는 편집하거나 삭제할 수 없으며 영구적인 기록으로 남습니다.

로그를 찾는 위치

1. 설정 > 채용 > 자동화로 이동합니다.
2. 확인하려는 자동화를 엽니다.
3. 자동화 편집 화면에서 자동화 탭을 로그 탭으로 전환합니다.

자동화가 아직 실행된 적이 없다면 "아직 실행되지 않음"이라는 빈 상태와 자동화 구성을 확인할 수 있는 버튼이 표시됩니다.

로그 읽기

로그 보기에는 다음이 표시됩니다.

• 결과별로 실행을 필터링하는 상태 필터(예: "모든 상태").
• 목록에 표시된 실행 횟수를 보여주는 카운터(예: "12개 표시").
• 실행당 하나의 행.

각 로그 행에는 다음 필드가 표시됩니다.

• 시간 — 실행이 발생한 시간입니다.
• 상태 — 결과입니다(아래 참조).
• 트리거 — 실행을 시작한 이벤트입니다. 자동화가 기반으로 하는 트리거에 따라 달라지므로 사용 가능한 모든 이벤트가 될 수 있습니다. 예를 들어 제안서 생성됨, 제안서 발행됨(이전 명칭: 제안서 게시됨), 제안서 조회됨, 제안서 수락됨, 제안서 만료 날짜, 파이프라인 단계 변경, 보험 트리거인 보험 시작 날짜 및 보험 종료 날짜 등이 표시될 수 있습니다.
• 실행 ID — 실행을 식별하는 고유 ID입니다("exec-"로 시작). 문제를 신고할 때 실행 ID를 알려 주면 정확한 실행을 찾을 수 있습니다.
• 작업 — 실행된 작업 수를 비율로 표시합니다(예: "1/1" 또는 "0/1 건너뜀").
• 소요 시간 — 실행에 걸린 시간입니다.

행을 클릭하면 확장되어 해당 실행의 각 작업에 대한 세부 정보를 볼 수 있습니다.

상태

• 성공 — 자동화가 실행되었고 모든 작업이 완료되었습니다.
• 실패 — 실행이 완료되지 않았습니다.
• 부분 실패 — 일부 작업은 완료되었지만 일부는 완료되지 않았습니다.

실행 기록이 표시되는 다른 위치

자동화 실행은 학생의 최근 활동 피드에도 표시되므로 학생 프로필에서 자동화 활동을 확인할 수 있습니다.

일반적인 실패 이유

실행이 실패하는 경우는 일반적으로 다음 중 하나입니다.

• 웹훅이 2xx가 아닌 응답을 반환했습니다.
• 웹훅 URL이 내부 또는 비공개 IP 주소를 가리켰습니다(이러한 주소는 차단됩니다).
• 웹훅이 5회 넘게 리디렉션되었습니다.
• 필수 변수를 입력할 수 없습니다.

자동화에 실행 기록이 없을 수 있는 이유

예상한 항목이 있는데도 로그 탭이 비어 있다면 자동화가 켜져 있는지 확인하세요. 특히 카드 메뉴에서 자동화를 복제하면 복사본은 꺼진 상태로 생성되며, 자동화에 이를 알리는 배너가 표시됩니다. 비활성화된 자동화는 실행되지 않으므로 활성화할 때까지 로그 항목이 전혀 생성되지 않습니다. 새로 복제한 자동화가 아무 작업도 하지 않는 것처럼 보이는 가장 일반적인 이유입니다.

또한 트리거가 실제로 발생했는지, 자동화의 조건이 예상하는 레코드와 일치하는지 확인하는 것이 좋습니다. 트리거가 실행되고 조건이 충족될 때만 실행 기록이 로그에 남습니다.

로그를 확인해야 하는 경우

예상한 이메일, 작업 또는 웹후크가 실행되지 않았거나 누군가 자동화가 작동하지 않는다고 보고한 경우 로그를 확인하세요. 상태와 확장된 작업 세부 정보에서 어떤 단계가 실패했는지, 그리고 그 이유가 무엇인지 확인할 수 있습니다.