ERP 개발자 가이드 | 아키텍처부터 커스터마이징까지 완벽 정리

핵심 요약

ERP(Enterprise Resource Planning)는 기업의 핵심 업무 프로세스를 하나의 통합 시스템으로 관리하는 소프트웨어입니다. 개발자 관점에서 ERP는 단순한 업무 도구가 아니라 복잡한 비즈니스 로직, 데이터 모델, API 설계가 집약된 시스템 아키텍처의 집합체입니다. 이 글에서는 ERP 시스템의 구조, 핵심 모듈 설계, 개발 시 고려사항, 그리고 현대적 ERP 트렌드까지 개발자 시각에서 깊이 있게 살펴봅니다.

2026년 (예비)사회적기업 이차보전 지원 신청 방법 총정리

목차

• ERP란 무엇인가 — 개발자 관점에서 바라보기
• ERP 시스템 아키텍처
• 핵심 ERP 모듈과 데이터 모델
• 오픈소스 ERP: Odoo 개발 살펴보기
• ERP 커스터마이징과 개발 시 고려사항
• 현대적 ERP 트렌드: 클라우드, API, 마이크로서비스
• 자주 묻는 질문 (FAQ)

ERP란 무엇인가 — 개발자 관점에서 바라보기

ERP(Enterprise Resource Planning)는 경영학 교과서에서는 "기업 자원 통합 관리 시스템"으로 정의되지만, 개발자 입장에서는 조금 다른 관점이 필요합니다. ERP는 회계, 인사, 재고, 구매, 영업, 생산 등 서로 다른 비즈니스 도메인의 데이터를 하나의 데이터베이스에서 통합적으로 관리하는 복잡한 소프트웨어 시스템입니다.

개발자 관점에서 ERP를 이해할 때 가장 중요한 개념은 데이터 정합성과 모듈 간 의존성입니다. 예를 들어, 구매 주문이 발생하면 재고 모듈, 회계 모듈, 지급 모듈이 동시에 영향을 받습니다. 이 모든 처리가 하나의 트랜잭션으로 묶여야 데이터 일관성이 보장됩니다.

ERP 개발이 일반 웹 애플리케이션 개발과 다른 핵심 이유는 바로 이것입니다. 단순 CRUD가 아니라 복잡한 비즈니스 규칙(Business Rule)이 코드에 깊이 녹아들어야 하기 때문입니다. 세금 계산 로직, 재고 평가 방식(선입선출/후입선출/이동평균), 외환 환산 처리 등이 모두 코드로 구현됩니다.

대표적인 ERP 솔루션으로는 SAP S/4HANA, Oracle ERP Cloud, Microsoft Dynamics 365가 있으며, 오픈소스 진영에는 Odoo, ERPNext 등이 있습니다. 이 중 SAP는 ABAP이라는 자체 언어를 사용하고, Odoo는 Python/PostgreSQL 기반으로 개발자 친화적인 편입니다.

ERP 개발자가 되려면 단순히 코딩 실력 외에도 해당 비즈니스 도메인에 대한 깊은 이해가 필수입니다. 회계 원리, 공급망 관리, 인사 제도 등을 모르면 요구사항을 코드로 옮기는 데 큰 어려움을 겪습니다.

SAP ERP 공식 사이트에서 더 자세한 기술 문서를 확인할 수 있습니다.

ERP 시스템 아키텍처

3계층 아키텍처

전통적인 ERP 시스템은 3계층(3-Tier) 아키텍처로 구성됩니다. 프레젠테이션 레이어(UI), 애플리케이션 레이어(비즈니스 로직), 데이터 레이어(DB)로 나뉘며 각 레이어는 명확한 역할 분리가 핵심입니다.

• 프레젠테이션 레이어: 웹 클라이언트, 모바일 앱, 데스크톱 클라이언트
• 애플리케이션 레이어: 비즈니스 로직, 워크플로우 엔진, 규칙 처리기
• 데이터 레이어: 관계형 DB, 파일 스토리지, 캐시 서버

데이터베이스 설계 특징

ERP의 데이터베이스는 일반 웹 서비스와 비교할 수 없을 만큼 복잡합니다. SAP의 경우 수천 개의 테이블이 존재하며, 각 테이블 간의 관계가 매우 촘촘하게 엮여 있습니다. 개발자가 알아야 할 핵심 DB 설계 패턴은 다음과 같습니다.

• 마스터 데이터 vs 트랜잭션 데이터 분리: 고객, 상품, 직원 정보(마스터)와 주문, 전표, 급여(트랜잭션)를 명확히 구분
• 이력 관리: 데이터 변경 이력을 감사(Audit) 로그로 보관하는 것이 필수
• 다통화 지원: 기준 통화와 현지 통화를 별도 컬럼으로 관리
• 회계 기간 관리: 연도와 월로 구분된 회계 기간 테이블과 각 트랜잭션의 연계

-- 트랜잭션 테이블 예시 (구매 주문 라인)
CREATE TABLE purchase_order_line (
    id              BIGINT PRIMARY KEY,
    order_id        BIGINT NOT NULL REFERENCES purchase_order(id),
    product_id      BIGINT NOT NULL REFERENCES product(id),
    qty_ordered     NUMERIC(16,4) NOT NULL,
    qty_received    NUMERIC(16,4) DEFAULT 0,
    unit_price      NUMERIC(20,6) NOT NULL,
    currency_id     INT NOT NULL REFERENCES currency(id),
    price_subtotal  NUMERIC(20,6) GENERATED ALWAYS AS (qty_ordered * unit_price) STORED,
    state           VARCHAR(20) DEFAULT 'draft',
    create_date     TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    write_date      TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

Odoo 공식 개발자 문서 보기 →

핵심 ERP 모듈과 데이터 모델

ERP는 여러 모듈의 집합체입니다. 각 모듈은 독립적으로 동작하면서도 서로 긴밀하게 연동됩니다. 개발자라면 각 모듈의 핵심 엔티티(Entity)와 이들 간의 관계를 이해하는 것이 출발점입니다.

주요 모듈별 핵심 엔티티

• 회계(Accounting): Account, Journal, JournalEntry, Tax, FiscalYear
• 재고(Inventory): Product, StockLocation, StockMove, StockQuant, Warehouse
• 구매(Purchase): Vendor, PurchaseOrder, PurchaseOrderLine, Receipt
• 영업(Sales): Customer, SaleOrder, SaleOrderLine, Invoice, Delivery
• 인사(HR): Employee, Department, Contract, Payslip, LeaveAllocation
• 생산(Manufacturing): BOM(Bill of Materials), WorkCenter, ProductionOrder, WorkOrder

모듈 간 연동 흐름 예시: 영업 주문 처리

영업 주문이 확정되면 다음과 같은 연쇄 반응이 일어납니다. 개발자는 이 흐름을 코드로 구현하고 각 단계에서 발생하는 예외 상황을 모두 처리해야 합니다.

"""
영업 주문 확정(confirm) 시 연동 흐름 (Odoo 스타일 예시)
"""
class SaleOrder(models.Model):
    _name = 'sale.order'

    def action_confirm(self):
        # 1. 주문 상태 변경
        self.state = 'sale'
        
        # 2. 재고 출고 예약 (Inventory 모듈 연동)
        self._create_delivery()
        
        # 3. 생산 계획 수립 (Manufacturing 모듈 연동)
        if self._needs_manufacturing():
            self._create_production()
        
        # 4. 세금 계산 및 회계 전표 생성 예약 (Accounting 연동)
        self._compute_taxes()
        
        return True

    def _create_delivery(self):
        """재고 모듈에 출고(picking) 생성"""
        StockPicking = self.env['stock.picking']
        for line in self.order_line:
            StockPicking.create({
                'sale_id': self.id,
                'product_id': line.product_id.id,
                'product_qty': line.product_uom_qty,
                'picking_type_id': self.warehouse_id.out_type_id.id,
            })

오픈소스 ERP: Odoo 개발 살펴보기

ERP 개발을 입문하기 가장 좋은 플랫폼은 단연 Odoo입니다. Python과 PostgreSQL 기반으로 개발되어 코드 접근성이 높고, 문서도 잘 정리되어 있습니다. Odoo의 개발 철학과 핵심 개념을 이해하면 다른 ERP 시스템을 이해하는 데도 큰 도움이 됩니다.

Odoo ORM과 모델 정의

Odoo는 자체 ORM을 사용하며, 모델 정의부터 비즈니스 로직까지 모두 Python 클래스로 표현합니다. 특히 computed field와 onchange 메커니즘은 ERP 특유의 실시간 계산 요구사항을 처리하는 핵심 도구입니다.

from odoo import models, fields, api

class ProductTemplate(models.Model):
    _name = 'product.template'
    _description = '제품 마스터'

    name = fields.Char('제품명', required=True, index=True)
    list_price = fields.Float('판매가', digits=(12, 2))
    standard_price = fields.Float('원가', digits=(12, 2))
    
    # Computed Field: 마진율 자동 계산
    margin_rate = fields.Float(
        '마진율(%)',
        compute='_compute_margin',
        store=True
    )
    
    categ_id = fields.Many2one('product.category', '카테고리', required=True)
    tag_ids = fields.Many2many('product.tag', string='태그')

    @api.depends('list_price', 'standard_price')
    def _compute_margin(self):
        for product in self:
            if product.list_price:
                product.margin_rate = (
                    (product.list_price - product.standard_price)
                    / product.list_price * 100
                )
            else:
                product.margin_rate = 0.0

Odoo의 보안 모델: Record Rules

ERP에서 권한 관리는 매우 중요합니다. Odoo는 Record Rules와 Access Control List(ACL) 두 가지 메커니즘으로 데이터 접근을 제어합니다. Record Rules는 사용자별로 어떤 레코드에 접근할 수 있는지를 도메인 필터로 정의합니다. 예를 들어, 영업 담당자는 본인이 담당하는 고객의 데이터만 볼 수 있도록 제한할 수 있습니다.

Odoo 오픈소스 코드는 GitHub에서 직접 확인할 수 있습니다. 실제 프로덕션 코드를 읽어보는 것이 ERP 개발을 배우는 가장 빠른 방법 중 하나입니다.

Odoo GitHub 소스코드 보기 →

ERP 커스터마이징과 개발 시 고려사항

ERP 개발에서 가장 많이 하는 작업은 기존 기능의 커스터마이징입니다. 표준 ERP를 그대로 쓰는 기업은 드물고, 대부분 자사 업무 프로세스에 맞게 수정합니다. 개발자 입장에서 커스터마이징 시 반드시 고려해야 할 사항들을 정리합니다.

업그레이드 안전성(Upgrade Safety)

ERP 코어(표준 모듈)를 직접 수정하면 절대 안 됩니다. 버전 업그레이드 시 수정 사항이 모두 날아갈 수 있고, 보안 패치 적용도 어려워집니다. 반드시 Extension(확장) 패턴을 사용하세요.

• Odoo: Custom Module로 기존 모델 상속(Inheritance) 사용
• SAP: BAdI(Business Add-In), Enhancement Spot 활용
• ERPNext: Custom Field, Client Script, Server Script 활용

성능 최적화: N+1 문제

ERP는 한 화면에서 수천 건의 데이터를 처리하는 경우가 많아 성능 문제가 자주 발생합니다. ORM을 사용할 때 가장 흔한 함정은 N+1 쿼리 문제입니다.

# 잘못된 방식: N+1 쿼리 발생
orders = SaleOrder.objects.all()
for order in orders:
    print(order.partner_id.name)  # 매 반복마다 쿼리 실행!

# 올바른 방식: prefetch_related 또는 with_context 사용 (Odoo)
orders = self.env['sale.order'].search([])
# Odoo ORM은 자동으로 레코드셋 캐싱을 활용하지만
# 명시적으로 prefetch 힌트를 주면 더 효율적
orders = orders.with_prefetch(orders._ids)
for order in orders:
    print(order.partner_id.name)  # 배치 쿼리로 처리

동시성 처리: 재고 마이너스 방지

ERP에서 동시성 문제는 치명적입니다. 특히 재고 처리에서 여러 사용자가 동시에 같은 재고를 소진하려 할 때 마이너스 재고가 발생할 수 있습니다. 이를 방지하기 위해 SELECT FOR UPDATE(비관적 잠금) 또는 Optimistic Locking 패턴을 반드시 적용해야 합니다.

현대적 ERP 트렌드: 클라우드, API, 마이크로서비스

전통적인 ERP는 단일 모놀리식(Monolithic) 구조였습니다. 하지만 최근 ERP 개발 패러다임은 빠르게 변화하고 있습니다.

API-First ERP

현대 ERP는 REST API와 GraphQL을 통해 외부 시스템과 쉽게 연동됩니다. 쇼핑몰, 물류 시스템, CRM 등 다양한 서비스와 ERP를 연결하는 시스템 통합(System Integration)이 중요한 개발 과제가 되었습니다.

• 웹훅(Webhook): ERP 이벤트 발생 시 외부 시스템에 실시간 알림
• 메시지 큐: Kafka, RabbitMQ를 통한 비동기 데이터 동기화
• ETL 파이프라인: ERP 데이터를 분석 DB(Data Warehouse)로 주기적 적재

클라우드 ERP와 멀티테넌시

SaaS 형태의 클라우드 ERP는 멀티테넌시(Multi-tenancy) 아키텍처를 기반으로 합니다. 여러 고객사의 데이터를 하나의 인프라에서 완전히 격리하여 운영하는 것이 핵심 기술 과제입니다. 테넌트별 스키마 분리(Schema-per-tenant) 또는 Row-level 격리 방식을 사용하며, 각각 장단점이 있습니다.

ERP 개발은 진입 장벽이 높지만 한번 깊이 이해하면 기업 소프트웨어 전반에 대한 통찰을 얻을 수 있습니다. ERPNext나 Odoo를 로컬에 설치해 소스코드를 직접 뜯어보는 것을 강력히 추천합니다.

ERPNext 공식 문서 바로가기 →

자주 묻는 질문 (FAQ)

Q. ERP 개발자가 되려면 어떤 언어를 배워야 하나요?

ERP 플랫폼마다 다릅니다. Odoo/ERPNext는 Python, SAP는 ABAP, Microsoft Dynamics는 C#과 X++ 언어를 사용합니다. 입문자라면 Python 기반의 Odoo나 ERPNext로 시작하는 것이 가장 접근하기 쉽습니다.

Q. ERP와 일반 웹 개발의 가장 큰 차이점은 무엇인가요?

비즈니스 로직의 복잡도와 데이터 정합성 요구 수준이 다릅니다. ERP는 회계, 세무, 재고, 인사 등의 도메인 지식이 코드에 직접 반영되어야 하며, 트랜잭션 처리의 정확성과 감사 추적(Audit Trail)이 매우 중요합니다.

Q. ERP를 처음 공부할 때 어떤 것부터 시작해야 하나요?

Odoo Community Edition을 Docker로 로컬에 설치하고, 구매-재고-회계 모듈의 연동 흐름을 직접 테스트해보는 것을 추천합니다. 이후 GitHub 소스코드를 읽으면서 각 모듈이 어떻게 구현되어 있는지 분석하는 것이 실력 향상에 가장 효과적입니다.

Q. ERP 커스터마이징 시 가장 주의할 점은 무엇인가요?

코어(표준) 모듈을 직접 수정하지 않는 것이 철칙입니다. 반드시 확장(Extension) 패턴을 사용해야 향후 업그레이드와 유지보수가 가능합니다. 또한 커스터마이징 전에 표준 기능으로 요구사항을 충족할 수 있는지 충분히 검토해야 합니다.