자바 백엔드 실무

들어가며

자산관리 시스템을 아무리 잘 만들어도, 인사 시스템에 있는 ‘신규 입사자 정보’나 재무 시스템의 ‘부서 코드’가 넘어오지 않는다면 무용지물입니다. 기업 IT 환경에서 각 시스템을 혈관처럼 연결해 주는 것이 바로 EAI(Enterprise Application Integration)입니다.

제가 지원하는 포지션의 주요 업무 중 하나인 ‘EAI 및 WEB 시스템 연계’는 단순히 데이터를 던지고 받는 것을 넘어, 데이터의 정합성을 보장하고 전송 실패 시의 대책을 마련하는 것이 핵심입니다.

오늘은 자산관리 시스템 운영자 입장에서 경험했던 EAI 연계 패턴과, 안정적인 인터페이스 구축을 위한 저만의 노하우를 정리해 봅니다.

EAI 연계의 3가지 핵심 패턴

EAI 솔루션(WebMethods, TIBCO 등)이 중간에 버티고 있지만, 결국 개발자가 구현해야 할 인터페이스 방식은 크게 세 가지로 나뉩니다.

1. DB-to-DB (Table Interface)

가장 전통적이고 흔한 방식입니다. 송신 측이 중간 테이블(Interface Table)에 데이터를 INSERT하면, EAI가 이를 감지하여 수신 측 테이블에 넣어줍니다.

• 장점: 대량 데이터 처리에 유리하고 트랜잭션 관리가 직관적입니다.
• 구현 전략:
  • I/F 테이블 설계: 반드시 IF_STATUS (처리상태: N/P/E/S), IF_DATE (생성일시), ERR_MSG (에러메시지) 컬럼을 포함해야 합니다.
  • 트리거 지양: 테이블에 INSERT 시 트리거로 로직을 태우는 것은 락(Lock) 유발 및 디버깅의 적입니다. 배치 잡(Job)으로 주기적으로 읽어가는 것이 안전합니다.

2. File Interface

이미지 파일이나 대용량 로그성 데이터를 주고받을 때 사용합니다. NAS를 공유하거나 FTP/SFTP를 통해 파일을 전송합니다.

• 주의점: 파일 생성 완료 시점과 EAI가 파일을 읽어가는 시점의 동기화(Timing Issue)가 중요합니다. 보통 .done 확장자 파일을 추가로 생성하여 전송 완료를 알리는 방식을 씁니다.

3. API 방식 (REST/SOAP)

실시간성이 중요한 업무(예: 모바일 사원증 인증)에 사용됩니다. 최근 차세대 프로젝트들은 레거시인 DB Link나 DB-to-DB 방식을 API 방식으로 전환하는 추세입니다.

실전 시나리오: 인사 정보 동기화 배치 (Spring Batch)

매일 새벽 2시, 인사 시스템으로부터 변동된 사원 정보를 받아와 자산 시스템의 사용자 테이블을 갱신하는 시나리오를 설계해 봅시다. (Spring Batch 활용)

@Bean
public Step userSyncStep() {
    return stepBuilderFactory.get("userSyncStep")
            .<UserIFDto, User>chunk(1000) // 1000건씩 끊어서 처리 (메모리 보호)
            .reader(userInterfaceReader()) // 1. 인터페이스 테이블 조회 (STATUS = 'N')
            .processor(userProcessor())    // 2. 비즈니스 로직 (신규/수정 판단, 유효성 검증)
            .writer(userWriter())          // 3. 자산 시스템 사용자 테이블 반영
            .faultTolerant()               // 4. 예외 발생 시 허용 범위 설정
            .skip(ValidationException.class) // 특정 에러는 건너뛰고 계속 진행
            .skipLimit(10)
            .build();
}

여기서 중요한 것은 faultTolerant()와 skip() 전략입니다. 1만 명 중 1명의 데이터가 꼬였다고 해서 전체 배치가 실패해서는 안 됩니다. 해당 건만 에러 로그(Error Log) 테이블에 기록하고 나머지는 정상 처리해야 다음 날 업무 마비가 오지 않습니다.

가장 중요한 것: “보냈는데 안 왔대요”를 방지하는 법

EAI 운영 업무의 8할은 “데이터 보냈는데 왜 반영 안 됐어?”라는 문의를 처리하는 것입니다. 이를 방어하기 위해서는 완벽한 로깅(Logging) 체계가 필요합니다.

1. 송신 로그: 언제, 몇 건을, 어떤 조건으로 보냈는지 기록
2. 수신 로그: 언제, 몇 건을 받았고, 그중 성공/실패 건수는 몇 건인지 기록
3. 데이터 매핑 정의서(Mapping Doc) 현행화:
   • 송신 측은 EMP_NAME(varchar 50)인데 수신 측은 USER_NM(varchar 30)이라면? -> Data too large 에러 발생
   • 이러한 메타데이터 불일치를 사전에 방지하기 위해 인터페이스 정의서를 꼼꼼히 관리해야 합니다.

마무리하며

시스템 통합은 기술의 문제이기도 하지만, 결국 커뮤니케이션의 문제입니다. “내 시스템에선 나갔으니 내 책임 아님”이라는 태도로는 운영 업무를 수행할 수 없습니다.

송신부터 수신, 그리고 최종 반영까지의 End-to-End 흐름을 모니터링하고, 문제 발생 시 어느 구간(송신 시스템 -> EAI -> 수신 시스템)에서 막혔는지 빠르게 파악하는 능력이 PI(Process Innovation) 및 개발 지원 업무의 핵심 역량입니다.

이제 일반적인 EAI 연계를 넘어, 기업 시스템의 심장부인 ERP(특히 SAP)와의 통신에 대해 이야기할 차례입니다. 자바 개발자에게는 조금 낯설 수 있는 RFC 통신, 다음 글에서 확실하게 파헤쳐 드리겠습니다.

다음 글: [Java에서 SAP ERP 연동하기 - JCo와 RFC 통신 실무]