AL 개발 이해하기: 사무실 건물 비유로 알아보기

By Mirko Peters · 2026-08-27

현대 기업을 운영할 때 전사적 자원 관리(ERP) 시스템은 일상 업무의 중심에 있습니다. Dynamics 365 Business Central 같은 플랫폼은 재무와 고객 관리부터 재고, 판매 주문, 송장까지 기본 기능으로 대부분을 처리합니다. 하지만 실제 업무 프로세스가 표준 기능에 딱 맞아떨어지는 경우는 드뭅니다. 회사에 특수한 승인 단계, 추가 데이터 필드, 고유한 계산 방식, 또는 표준 애플리케이션에 없는 업무 규칙이 필요하면 어떻게 해야 할까요? 오랫동안 ERP 시스템을 커스터마이징하는 일은 원하는 기능을 얻는 것과 향후 업그레이드 실패라는 악몽 사이에서 아슬아슬하게 줄타기하는 것과 같았습니다. 오늘날에는 현대적인 개발 접근 방식 덕분에 상황이 근본적으로 달라졌습니다. 이번 블로그 글에서는 Micro

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

현대적인 비즈니스를 운영할 때 전사적 자원 관리(ERP) 시스템은 일상 업무의 중심에 자리합니다. Dynamics 365 Business Central 같은 플랫폼은 재무와 고객 관리부터 재고, 판매 주문, 송장까지 기본 제공 기능으로 모두 처리합니다. 하지만 실제 비즈니스 프로세스가 모든 기업에 똑같이 맞는 경우는 드뭅니다. 회사에 특수한 승인 단계, 추가 데이터 필드, 고유한 계산 방식, 또는 표준 애플리케이션에 없는 비즈니스 규칙이 필요하다면 어떻게 해야 할까요? 오랫동안 ERP 시스템을 사용자 지정한다는 것은 필요한 기능을 얻는 것과 향후 업그레이드 실패라는 악몽에 갇히는 것 사이에서 위험한 줄타기를 하는 일이었습니다. 오늘날에는 최신 개발 방식 덕분에 상황이 근본적으로 달라졌습니다. 이 블로그 글에서는 Microsoft의 최신 확장 모델 뒤에 있는 개념을 살펴보고, AL 개발의 기본 구성 요소를 정리하며, 사용자 지정 코드를 핵심 애플리케이션과 분리하는 것이 안정적이고 미래에도 유효한 ERP를 만드는 가장 중요한 열쇠인 이유를 알아보겠습니다.

기업이 ERP 시스템을 커스터마이징하는 이유

개발이 어떻게 이루어지는지 살펴보기 전에, 먼저 왜 커스터마이징이 필요한지 이해하는 것이 도움이 됩니다. Business Central은 많은 전통 기업에 잘 맞는 방대한 표준 업무 프로세스를 제공합니다. 그렇더라도 같은 방식으로 운영하는 조직은 없습니다. 예를 들어 특수 식품 유통업체는 기본 재고 관리 이상의 엄격한 배치 추적 정보와 유통기한 지표가 필요할 수 있습니다. 지역 서비스 회사는 송장을 확정하기 전에 내부 승인 절차를 추가로 거쳐야 할 수도 있습니다. 전문 소매업체는 세분화된 고객 보상 등급과 로열티 추적이 필요할 수 있습니다.

이러한 고유한 요구 사항이 업무 프로세스를 전면적으로 다시 설계하거나 ERP를 포기해야 한다는 뜻은 아닙니다. 대부분의 경우 기업은 Business Central이 데이터 항목 하나를 추가로 이해하거나 특정 내부 검증 규칙 하나를 적용하기만 하면 됩니다. 그동안 과제는 시스템의 기본 무결성을 해치지 않으면서 이러한 변경을 안전하게 구현하는 방법이었습니다.

최신 확장을 설명하는 사무실 건물 비유

기술 용어에 휘둘리지 않고 최신 개발 방식을 이해하려면 Business Central을 크고 전문적으로 설계된 사무실 건물에 비유해 보는 것이 도움이 됩니다. 과거의 ERP 개발 모델에서 시스템을 커스터마이징하는 일은, 누군가 새 방이 필요할 때마다 내력벽을 무작위로 허물고, 콘크리트 바닥에 구멍을 뚫고, 주 기반 시설에 맞춤 배관을 직접 연결하는 것과 비슷했습니다. 그렇게 하면 원하는 방은 바로 얻을 수 있지만, 건물을 유지 관리하기는 극도로 어려워졌습니다. 원래 시공사가 지붕을 보수하거나 기초를 현대화하려고 찾아올 때마다, 기존 커스터마이징이 업데이트와 정면으로 충돌하여 비용과 스트레스가 큰 문제가 생겼습니다.

Microsoft의 확장 모델은 이 구조를 완전히 바꿉니다. 사무실 건물 비유에서 Microsoft는 핵심 골조, 안전 기준, 설비, 표준 사무실 같은 주 건물의 구조를 유지합니다. 조직에 추가 공간이나 맞춤 기능이 필요하면 주 건물의 내부 골조를 건드리지 않습니다. 대신 건물 외부에 있는 승인된 연결 지점에 안전하게 부착되는 모듈형 부속 건물을 만듭니다. 사용자 지정 기능은 표준 애플리케이션 옆에 별도의 독립된 단위로 자리합니다. Microsoft는 언제든지 주 건물을 업그레이드할 수 있고, 사용자 지정 부속 건물은 안전하고 온전하게 유지됩니다.

AL과 확장 모델 이해하기

AL은 Application Language의 약자입니다. Dynamics 365 Business Central 전용 사용자 지정 기능을 개발하기 위해 Microsoft가 만든 전문 프로그래밍 언어입니다. AL을 사용하면 개발자가 업무 프로세스, 계산, 검증, 레코드, 페이지를 추가하고 수정하며 개선할 수 있습니다.

가장 먼저 이해해야 할 핵심은 AL 문법 자체보다 확장 모델이라는 아키텍처 패러다임입니다. 이전 버전의 제품에서는 흔히 Dynamics NAV의 레거시 C/AL 개발 환경과 연관되어, 개발자가 원본 애플리케이션 객체를 직접 수정하는 경우가 많았습니다. 이 방식은 깊은 수준의 커스터마이징을 가능하게 했지만, 핵심 시스템과 사용자 정의 코드 사이에 강한 결합을 만들었습니다. Microsoft가 업데이트를 출시할 때마다 개발자는 원본 소스 코드와 수정 사항을 수작업으로 비교하고 조정해야 했습니다. 최신 AL 확장 모델은 수정 사항을 표준 애플리케이션 코드를 덮어쓰지 않고 그 옆에서 실행되는 독립적인 확장으로 패키징함으로써 이러한 번거로움을 없앱니다.

표준 우선, 커스터마이징은 그다음

Business Central을 커스터마이징할 수 있다고 해서 반드시 그래야 하는 것은 아닙니다. 기존 레거시 소프트웨어와 기본 워크플로가 약간 다르게 보인다는 이유만으로 시스템을 변경하면 불필요한 장기 유지 관리 부담이 생길 수 있습니다. ERP 관리의 모범 사례는 항상 "표준 우선, 커스터마이징은 그다음"이라는 원칙을 따르라고 합니다.

AL 코드를 한 줄이라도 작성하기 전에 개발팀과 비즈니스 리더는 세 가지 근본적인 질문을 던져야 합니다. 직원들이 정확히 어떤 문제를 겪고 있는가? 대신 무엇이 일어나야 하는가? 비즈니스 프로세스를 조정하면 표준 Business Central만으로 이 문제를 해결할 수 있는가? AL 개발은 표준 제품이 중요한 비즈니스 요구 사항을 실제로 충족하지 못하는 시나리오에만 사용해야 합니다.

핵심 AL 구성 요소 살펴보기

개발자가 확장을 만들 때는 객체라고 부르는 특정 프로그래밍 구성 요소를 다룹니다. 객체는 특정 작업을 처리하도록 설계된 애플리케이션의 독립적인 부분입니다. 그럼 AL 솔루션을 구성하는 주요 구성 요소를 살펴보겠습니다.

테이블, 필드, 페이지

테이블은 Business Central의 디지털 파일 캐비닛 역할을 하며, 데이터를 안전하게 저장합니다. 고객 테이블에는 고객 프로필이, 품목 테이블에는 재고 정보가 저장되며, 거래 테이블은 판매 문서를 처리합니다. 이러한 테이블 안에는 이름, 주소, 전화번호, 날짜처럼 개별 속성을 나타내는 필드가 있습니다.

그러나 직원이 데이터와 상호 작용할 수 없다면 데이터베이스 테이블에 저장된 데이터는 그다지 유용하지 않습니다. 여기서 페이지가 등장합니다. 페이지는 Business Central 내에서 시각적 표현과 사용자 인터페이스 화면을 결정합니다. 고객 카드는 단일 레코드의 세부 정보를 보여주도록 설계된 페이지이고, 목록 페이지는 여러 레코드를 한눈에 보여줍니다. 테이블은 데이터를 저장하고, 페이지는 이를 사용자에게 보여줍니다.

테이블 확장과 페이지 확장

표준 Business Central에 거의 모든 기능이 갖춰져 있지만 고객의 사용자 지정 로열티 보상 등급처럼 데이터 항목 하나가 더 필요하다면 어떻게 해야 할까요? 기존 핵심 데이터를 중복하는 완전히 새로운 고객 테이블을 만드는 대신, 개발자는 테이블 확장을 만듭니다. 표준 고객 테이블은 그대로 두고, 확장이 새 필드를 그 옆에 추가할 뿐입니다.

물론 테이블에 필드를 추가한다고 해서 직원에게 자동으로 보이는 것은 아닙니다. 이를 해결하기 위해 개발자는 페이지 확장을 사용합니다. 페이지 확장은 새 필드와 필요한 그룹, 작업, 버튼을 표준 Business Central 사용자 인터페이스 화면에 직접 삽입합니다. 직원은 익숙한 표준 페이지에서 계속 작업하고, 확장은 비즈니스에 필요한 전문 데이터를 자연스럽게 드러냅니다.

코드 단위, 트리거, 이벤트

데이터 저장과 사용자 인터페이스는 중요하지만, 애플리케이션에는 값을 계산하고 워크플로를 처리하는 로직도 필요합니다. 코드 단위(Codeunit)는 이렇게 재사용 가능한 비즈니스 로직을 담는 전용 공간을 제공합니다. 예를 들어 고객의 보상 등급에 따라 특정 할인율이 정해진다면, 그 계산 코드를 여러 페이지와 보고서에 어색하게 중복하지 않고 중앙의 코드 단위에 둘 수 있습니다.

코드는 트리거라고 부르는 애플리케이션 수명 주기의 특정 지점에서 실행됩니다. 트리거는 사용자가 페이지를 열거나, 필드 값을 수정하거나, 송장 전기를 시도하는 등 특정 작업이 발생하면 자동으로 실행됩니다. 마찬가지로 이벤트를 사용하면 확장 기능이 표준 애플리케이션이 브로드캐스트하는 알림을 수신할 수 있습니다. 예를 들어 Business Central이 문서가 곧 전기된다고 알리면, 확장 기능은 이 이벤트를 즉시 감지하고 정확한 시점에 자체 사용자 지정 유효성 검사 로직을 실행할 수 있습니다.

결론: ERP 업그레이드 준비 상태 유지하기

전사적 자원 관리(ERP) 시스템을 사용자 지정하는 일은 더 이상 업그레이드를 망가뜨릴 수 있는 위험한 작업일 필요가 없습니다. Microsoft의 최신 확장 모델을 도입하고 AL 개발의 강점을 활용하면, 조직은 핵심 애플리케이션을 완전히 깔끔하고 안정적으로 유지하면서도 Business Central을 고유한 운영 요구에 정확히 맞춰 조정할 수 있습니다. ERP를 내부 구조를 허물지 않고 사용자 지정 요소가 외부에 안전하게 연결되는 잘 설계된 사무용 건물처럼 다룬다면, 비즈니스는 민첩하고 효율적인 상태를 유지하며 앞으로 나올 모든 소프트웨어 업데이트에 완벽하게 대비할 수 있습니다.

이 주제를 더 깊이 살펴보고 최신 개발 방식에 대한 전문가의 통찰을 듣고 싶다면, 관련 팟캐스트 에피소드 Dynamics 365 Business Central AL Development을(를) 꼭 확인해 보시기 바랍니다.