Business Central 이벤트와 트리거 비교(AL): 개발자를 위한 타이밍 가이드

By Mirko Peters · 2026-08-22

AL에서 사용자 지정 비즈니스 로직, 유효성 검사, 전기 검사에 트리거와 이벤트 구독자 중 언제 무엇을 써야 하는지 이해하여 Business Central AL 개발을 제대로 익히십시오.

Automatically translated with AI from the original post. Read the English original

Microsoft Dynamics 365 Business Central AL 개발에서 트리거와 이벤트의 차이를 이해하는 것은 깔끔하고 유지 관리하기 쉬운 확장 프로그램을 작성하는 데 필수적입니다. 적절한 실행 메커니즘을 선택하면 유효성 검사 규칙이 정확한 시점에 실행되어 잘못된 데이터 입력을 방지하고, 기본 애플리케이션 코드를 중복하지 않으면서도 클라우드 업데이트를 원활하게 유지할 수 있습니다.

핵심 요약

• 트리거는 개체 이벤트나 데이터 변경이 발생할 때 즉시 코드를 실행하도록 특정 AL 개체 안에 내장되어 있습니다.
• 이벤트 구독자를 사용하면 기본 애플리케이션 코드를 수정하거나 대규모 기본 프로세스를 복사하지 않고도 확장 프로그램이 시스템 전반의 알림을 수신할 수 있습니다.
• 'on before' 이벤트와 'on after' 이벤트 중 무엇을 선택하느냐에 따라 사용자 지정 코드가 트랜잭션을 막을 수 있는지, 아니면 완료된 작업에 반응만 할 수 있는지가 결정됩니다.
• 적절한 타이밍은 유효성 검사 규칙이 오류를 조기에 포착하도록 보장하는 동시에, 판매 주문 전기와 같은 대용량 작업 중 성능 병목 현상을 방지합니다.

Business Central의 사용자 지정 로직 아키텍처

Microsoft의 Application Language(AL)를 사용하여 Dynamics 365 Business Central을 확장할 때 코드를 작성하는 것은 절반에 불과합니다. 진짜 과제는 해당 코드를 어디에서 그리고 언제 실행할지 결정하는 데 있습니다. 고객 레코드에 간단한 보상 등급 필드를 추가하든, 송장이 생성되기 전에 복잡한 규정 준수 검사를 적용하든, 확장 프로그램의 수명과 안정성은 시스템과 연결하는 방식에 달려 있습니다.

과거의 개발 모델에서는 개발자가 기본 애플리케이션 코드를 직접 다시 작성하는 방식이 흔했습니다. 문서가 전기되기 전에 검사를 실행하고 싶다면 핵심 전기 루틴에 로직을 직접 삽입했습니다. 이 방식은 한동안 작동했지만, Microsoft의 주요 업데이트가 있을 때마다 고통스러운 재조정 작업이 필요했습니다. 최신 Business Central 확장 프로그램 개발은 모듈식 앱 기반 모델에 의존합니다. 표준 루틴을 다시 작성하는 대신, 개발자는 내장된 연결 지점, 즉 트리거와 이벤트를 사용하여 표준 애플리케이션 코드와 함께 사용자 지정 로직을 안전하게 결합합니다.

AL 트리거 이해하기

트리거는 특정 작업이 발생할 때 자동으로 실행되는 코드를 작성할 수 있도록 AL 개체 안에 지정된 사전 정의 위치입니다. 테이블, 테이블 확장, 페이지, 페이지 확장, 보고서, 코드 단위를 포함한 모든 표준 개체와 사용자 지정 개체에는 이러한 기본 지점이 있습니다.

실제 시나리오를 살펴보겠습니다. 조직에서 고객 레코드에 사용자 지정 Reward ID 필드를 도입했다고 가정합니다. 사용자가 드롭다운 목록에서 보상 등급을 선택하면, 시스템이 즉시 고객 계정이 차단되었는지 확인하거나 보조 속성을 업데이트해야 하는지 검사해야 합니다. 해당 필드의 OnValidate 트리거를 활용하면 사용자가 값을 변경하는 바로 그 순간 코드가 실행됩니다.

트리거를 사용해야 하는 경우

트리거는 비즈니스 로직이 단일 개체와 그 직접적인 컨텍스트에만 속할 때 가장 효과적으로 사용할 수 있습니다. 예를 들면 다음과 같습니다.

• 사용자 지정 날짜 필드가 허용된 비즈니스 분기 내에 있는지 검증하기
• 새 항목을 위해 카드 페이지가 열릴 때 초기화 로직 실행하기
• 기본 옵션의 선택이 해제되면 종속 필드 값 지우기

트리거는 호스트 개체에 밀접하게 연결되어 있으므로, 지역화된 코드를 쉽게 찾고 읽고 장기간 유지 관리할 수 있습니다.

Business Central 이벤트 및 구독 활용하기

트리거가 지역화된 작업을 처리하는 반면, 판매 주문 전기, 재고 출하, 재무 분개 생성과 같이 여러 단계로 이루어진 광범위한 프로세스에는 보다 정교한 접근 방식이 필요합니다. 대규모 전기 루틴의 중간에 검증 코드를 단순히 넣으면 확장 모델이 깨질 수 있으므로 이 방식은 적절하지 않습니다.

이때 이벤트와 이벤트 구독자가 필수적인 역할을 합니다. 이벤트는 표준 Business Central 애플리케이션이 브로드캐스트하는 공식 알림이라고 생각하면 됩니다. 시스템은 '레코드가 삽입되기 직전'이나 '판매 문서가 전기되기 직전'과 같은 주요 시점을 알립니다. 확장 기능은 이벤트 구독자 프로시저를 사용하여 이러한 알림을 수신할 수 있습니다.

Business Central이 지정된 이벤트를 발생시키면 구독된 프로시저가 실행되어 사용자 지정 규칙을 수행하고, 프로세스를 승인하거나 설명이 포함된 오류 메시지와 함께 중단합니다. 중요한 점은 확장 기능이 기본 전기 엔진을 복사, 붙여넣기 하거나 다시 작성할 필요가 없다는 것입니다.

시점의 중요성: OnBefore와 OnAfter 비교

AL에서 이벤트 구독자를 작성할 때 명명 규칙을 보면 실행 시점을 알 수 있습니다. 이 시점을 이해하는 것은 시스템 안정성에 매우 중요합니다.

• OnBefore 이벤트: 표준 작업이 완료되거나 커밋되기 직전에 실행됩니다. 차단 로직과 검증 확인에 가장 적합한 위치입니다. 판매 주문에 필수 규정 준수 문서가 없으면 OnBefore 전기 이벤트가 이를 감지하고 트랜잭션을 중단한 뒤 유용한 경고 메시지를 표시할 수 있습니다.
• OnAfter 이벤트: 표준 프로세스가 성공적으로 완료된 직후에 실행됩니다. 완료된 작업에 대응해야 할 때 OnAfter 구독자를 사용합니다. 예를 들어 후속 작업을 자동으로 생성하거나, 외부 로그 테이블을 업데이트하거나, 주문 전기가 완료되면 계정 관리자에게 알리는 경우가 여기에 해당합니다.

너무 늦게 실행되는 규칙은 잘못된 트랜잭션을 막을 수 없고, 너무 일찍 실행되는 규칙은 표준 루틴에서 계산된 필요한 데이터가 없을 수 있습니다. 로직을 올바른 이벤트 시그니처에 매핑하면 이러한 함정을 피할 수 있습니다.

결론

개체 트리거와 이벤트 구독자 사이의 균형을 익히면 Business Central 확장 기능을 접근하는 방식이 달라집니다. 필드 검증에는 지역화된 트리거를, 시스템 전반의 프로세스에는 이벤트 구독자를 활용하면 사용자 지정 기능이 클라우드 업데이트에도 견고하게 유지되면서 환경을 빠르고 안전하게 유지할 수 있습니다.

현대적인 애플리케이션 설계 원칙을 더 깊이 알아보고 전문가의 아키텍처 분석을 듣고 싶다면, M365 FM 팟캐스트의 전체 에피소드를 들어보십시오. 클라우드 아키텍트와 개발자가 실제 비즈니스 성공을 위해 Microsoft 생태계를 최적화하는 방법을 살펴보세요!

자주 묻는 질문

AL에서 트리거와 이벤트 구독자의 가장 큰 차이점은 무엇인가요?

트리거는 특정 AL 개체(테이블 필드나 페이지 등) 내부에 직접 만들어진 사전 정의된 코드 실행 지점인 반면, 이벤트 구독자는 기본 애플리케이션이나 다른 개체가 게시한 알림을 수신하는 확장 기능 내의 별도 프로시저이며, 원본 코드는 변경하지 않습니다.

이벤트 구독자가 판매 주문의 전기를 막을 수 있나요?

네, 전기 프로세스에 연결된 'on before' 이벤트 구독자를 사용하면 사용자 지정 코드가 비즈니스 조건을 평가하고 오류 메시지를 발생시킨 후, 전기 루틴이 항목을 확정하기 전에 트랜잭션을 중단할 수 있습니다.

이벤트 구독자 대신 테이블 필드 검증 트리거를 사용해야 하는 경우는 언제인가요?

비즈니스 규칙이 특정 필드 값의 변경에만 엄격하게 연결되어 있을 때 테이블 필드 검증 트리거를 사용해야 합니다. 예를 들어 사용자 지정 Reward ID가 존재하는지 확인하거나, 사용자 입력 즉시 관련 상태 필드가 업데이트되도록 보장하는 경우가 이에 해당합니다.

AL 이벤트 구독자를 작성할 때 실행 시점이 중요한 이유는 무엇인가요?

실행 시점은 코드가 핵심 프로세스가 완료되기 전에 실행되는지, 완료된 후에 실행되는지를 결정합니다. 규칙이 너무 일찍 실행되면 필요한 데이터가 아직 채워지지 않았을 수 있고, 너무 늦게 실행되면 잘못된 트랜잭션을 차단할 기회를 잃게 됩니다.