들어가며: 클라우드 ERP 마이그레이션의 숨은 과제

ERP(전사적 자원 관리) 시스템을 클라우드로 옮기는 건 많은 기업이 꿈꾸는 디지털 전환의 핵심 단계입니다. 하지만 막상 마이그레이션을 진행해보면 '온프레미스에서 당연하게 누리던 실시간 리포팅이 클라우드에서는 불가능해지는' 아이러니한 상황에 부딪히곤 합니다.

북미 건자재 시장의 거인 Oldcastle APG도 예외는 아니었습니다. Asphalt, 콘크리트 등 건설 자재 공급과 포장 서비스를 제공하는 이 회사는 150개 이상의 시설을 운영하며, 매일 수백 명의 사용자가 고객 서비스, 재무, 물류, 제조 부문에서 복잡한 실시간 보고서에 의존하고 있었습니다.

문제는 Infor Cloud ERP로 이전하면서 시작됐습니다. Infor의 기본 리포팅 기능은 온프레미스 환경에서 사용하던 복잡한 다차원 분석과 실시간 데이터 접근을 충족하지 못했죠. 배치(Batch) 방식으로 하루에 한두 번 생성되는 리포트는 의사결정 속도를 현저히 떨어뜨렸습니다.

핵심 문제: "배치 리포팅을 기다리는 동안 우리는 경쟁 우위를 잃고 있었다" - Oldcastle IT 팀

이번 글에서는 Oldcastle이 AWS 솔루션즈 아키텍트와 협력하여 어떻게 이 문제를 해결했는지, 그 아키텍처의 핵심 요소와 실무 적용 포인트를 상세히 분석합니다. (참고: 이 사례는 AWS Architecture Blog에 게재된 내용을 기반으로 재구성했습니다.)

Architecture diagram of real-time data streaming from Infor ERP to Amazon Aurora and QuickSight Algorithm Concept Visual

아키텍처 핵심: Infor Data Fabric → AWS 실시간 파이프라인

Oldcastle이 선택한 접근법은 Infor Data Fabric Stream Pipelines를 활용한 실시간 데이터 스트리밍입니다. 이 구조는 전통적인 ETL 배치 작업을 대체하고, 데이터가 생성되는 즉시 분석 시스템으로 전달되도록 설계되었습니다.

전체 워크플로우 개요

  1. 데이터 수집 (Ingestion): Infor ERP 테이블(판매 주문, 재고, 재무 트랜잭션 등)에서 변경 사항이 발생하면 Stream Pipelines가 즉시 이벤트를 캡처합니다. INSERT, UPDATE, DELETE 연산과 타임스탬프 메타데이터가 포함됩니다.

  2. 로드 분산 (Load Distribution): Infor가 직접 Private VPC에 접근할 수 없기 때문에, Network Load Balancer(NLB)를 퍼블릭 서브넷에 배치하여 안정적인 Elastic IP를 제공합니다. 이 IP는 Infor 측에서 방화벽 허용 목록에 등록됩니다.

  3. 연결 관리 (Connection Management): Amazon RDS Proxy를 Private 서브넷에 배치하여 데이터베이스 연결을 풀링(Pooling)하고 자동 장애 조치(Failover)를 지원합니다. IAM 인증을 사용해 보안을 강화했습니다.

  4. 데이터 저장 (Storage): Amazon Aurora PostgreSQL (Multi-AZ)을 사용하여 실시간 데이터를 저장합니다. JSONB 컬럼을 활용해 유연한 스키마를 유지하면서, 자주 조회되는 필드에는 인덱스를 생성하여 쿼리 성능을 최적화했습니다.

  5. 분석 및 시각화 (Analytics): Amazon QuickSight가 대시보드와 픽셀 퍼펙트 리포트를 제공합니다. SPICE(Super-fast, Parallel, In-memory Calculation Engine) 캐싱을 활성화하여 복잡한 분석도 서브세컨드 응답 시간을 보장합니다.

  6. 임베디드 통합 (Embedded Integration): Amazon API Gateway + Lambda를 통해 QuickSight 대시보드를 Infor OS 내부에 iframe으로 삽입했습니다. 사용자는 ERP 화면을 벗어나지 않고 실시간 분석을 확인할 수 있습니다.

코드로 보는 핵심 설정 (Python 예시)

다음은 RDS Proxy를 통한 연결 풀링 설정과 QuickSight 임베디드 URL 생성을 간략히 표현한 코드입니다.

import boto3
from botocore.config import Config

# 1. RDS Proxy를 통한 데이터베이스 연결
# 실제로는 SQLAlchemy나 psycopg2로 연결하지만, 여기서는 개념을 보여줍니다.
rds_proxy_endpoint = "oldcastle-proxy.proxy-xxxxxx.us-east-1.rds.amazonaws.com"

def get_db_connection():
    """RDS Proxy를 통해 Aurora에 연결 (IAM 인증 사용)"""
    # IAM 인증 토큰 생성
    session = boto3.Session()
    client = session.client('rds')
    token = client.generate_db_auth_token(
        DBHostname=rds_proxy_endpoint,
        Port=5432,
        DBUsername='oldcastle_user',
        Region='us-east-1'
    )
    # 실제 연결 로직 (생략)
    return token

# 2. QuickSight 임베디드 대시보드 URL 생성
quicksight = boto3.client('quicksight')

def get_embedded_dashboard_url(user_arn, session_token, dashboard_id):
    """사용자별 Row-Level Security가 적용된 임베디드 URL 생성"""
    response = quicksight.generate_embed_url_for_registered_user(
        AwsAccountId='123456789012',
        UserArn=user_arn,
        SessionLifetimeInMinutes=600,
        ExperienceConfiguration={
            'Dashboard': {
                'InitialDashboardId': dashboard_id
            }
        },
        AllowedDomains=['https://infor.oldcastle.com']
    )
    return response['EmbedUrl']

💡 실무 팁: Aurora의 JSONB 컬럼과 SPICE 캐싱을 함께 사용할 때는 자주 조회되는 필드를 별도 컬럼으로 추출하고 인덱스를 거는 전략이 효과적입니다. JSONB는 유연성을 주지만, 복잡한 조인이나 집계가 필요한 경우 성능 저하가 발생할 수 있습니다.

Dashboard screenshot showing real-time analytics for ERP operational metrics

실무 적용 시 고려사항과 한계

1. 데이터 지연(Latency)에 대한 현실적인 기대치

스트리밍 파이프라인은 '거의 실시간(near real-time)'에 가깝지만, 완전한 동기식 트랜잭션은 아닙니다. Infor Data Fabric Stream Pipelines는 일반적으로 수초에서 수분 이내의 지연을 가집니다. 만약 밀리초 단위의 정합성이 필요한 금융 거래 등에는 추가적인 CDC(Change Data Capture) 솔루션 고려가 필요합니다.

2. 보안: Allow List와 IAM 인증의 이중 방어

이 아키텍처의 보안 핵심은 NLB의 고정 IP를 통한 Allow List와 RDS Proxy의 IAM 인증 조합입니다. Infor 측에서는 NLB의 Elastic IP만 허용하고, AWS 측에서는 IAM 토큰 없이는 데이터베이스 접근이 불가능합니다. 국내 금융권이나 공공기관에서도 이 패턴을 참고할 만합니다.

3. 비용 최적화 전략

  • SPICE 캐싱: 자주 조회되는 데이터는 SPICE에 캐싱하여 QuickSight SPICE 용량 비용과 Aurora 읽기 트래픽 비용을 절감합니다.
  • Aurora Auto Scaling: 읽기 워크로드가 증가하면 자동으로 리더 인스턴스가 추가되지만, 예상 피크 시간에 맞춰 최소/최대 인스턴스 수를 설정하는 것이 중요합니다.
  • API Gateway 캐싱: 임베디드 URL 생성 요청이 많을 경우 API Gateway 캐싱을 활성화하여 Lambda 호출 비용을 줄일 수 있습니다.

4. 국내 SI/클라우드 환경에서의 적용 맥락

한국 기업들이 이 아키텍처를 참고할 때 주의할 점:

  • Infor ERP 국내 도입 사례: Infor는 국내 제조/유통 기업에서도 사용 중이지만, Stream Pipelines 기능은 라이선스 옵션에 따라 제한될 수 있습니다. 도입 전 Infor 계정팀과 반드시 확인하세요.
  • 레거시 DB와의 공존: 많은 국내 기업이 Oracle이나 MS SQL Server를 온프레미스에 유지한 채 클라우드 ERP를 도입합니다. 이 경우 AWS DMS(Database Migration Service)를 활용한 실시간 복제를 고려할 수 있습니다.
  • 네트워크 구성: 한국의 IDC 환경에서는 전용선(Direct Connect) 또는 VPN을 통해 AWS와 연결하는 경우가 많습니다. NLB 대신 PrivateLink를 사용하면 퍼블릭 서브넷을 거치지 않는 더 안전한 연결이 가능합니다.

Developer configuring AWS services for ERP integration with cloud-native analytics Programming Illustration

결론: ERP의 미래는 '열린 분석'에 달렸다

Oldcastle의 사례는 클라우드 ERP 마이그레이션이 단순한 인프라 이전이 아니라, 데이터 접근성과 분석 능력을 근본적으로 재정의할 기회임을 보여줍니다.

핵심 교훈을 정리하면:

  1. 배치 리포팅은 더 이상 선택지가 아니다. 실시간 스트리밍 파이프라인을 통해 의사결정 속도를 획기적으로 개선할 수 있습니다.
  2. 임베디드 분석이 사용자 경험을 바꾼다. ERP 화면을 벗어나지 않고 분석 결과를 확인할 수 있게 함으로써 도구 전환 비용을 없앴습니다.
  3. 클라우드 네이티브 서비스의 조합이 핵심이다. Aurora + QuickSight + API Gateway + Lambda의 조합은 확장성과 유지보수성에서 큰 이점을 제공합니다.

앞으로 이 아키텍처를 발전시킬 방향으로는 Amazon Bedrock을 활용한 생성형 AI 기반의 자연어 질의(예: "이번 분기 매출이 가장 높은 지역은?") 나 ML 기반 수요 예측 모델의 통합을 고려해볼 수 있습니다.

다음 단계 학습 방향:

  • Infor Data Fabric Stream Pipelines 공식 문서 숙독
  • Amazon QuickSight SPICE 용량 및 성능 모니터링 실습
  • AWS Lambda + API Gateway를 활용한 서버리스 백엔드 구축 핸즈온

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.