DevOn Enterprise·DevOn Boot 온라인 아키텍처

서론

기업 시스템 개발에서 프레임워크는 단순한 생산성 도구가 아니라, 요청 처리 방식과 비즈니스 계층 구조를 결정하는 아키텍처 기준에 가깝습니다. 같은 온라인 서비스를 구축하더라도 규모나 구현 아키텍처에 따라 목적에 맞는 개발 프레임워크를 선택하는 일은, 개발 생산성 보장을 통한 프로젝트의 성공적 이행뿐 아니라 시스템 오픈 후 운영 및 유지 보수의 효율성까지 담보하는 중요한 문제라 할 수 있습니다.

LG CNS는 DevOn Enterprise와 DevOn Boot 프레임워크를 통해 각각 다른 목적과 아키텍처의 시스템 구축을 지원합니다. DevOn Enterprise는 엔터프라이즈급 금융권 시스템의 코어 뱅킹이나 메인 시스템 영역에, DevOn Boot는 MSA 환경에서 Spring MVC 기반 구조 위에 웹과 API, 연계 요청을 유연하게 확장하여 구축하는 채널이나 단위 시스템 영역에 주로 적용됩니다.

이 글에서는 두 프레임워크의 온라인 서비스 처리 아키텍처에 초점을 맞춰, 각각의 구조적 특징과 적용 적합성을 정리합니다.

DevOn Enterprise의 온라인 아키텍처

DevOn Enterprise의 온라인 아키텍처에서 먼저 주목해야 할 부분은 Channel Interface, Business, Persistent로 이어지는 계층 구조와, 그 사이에 배치된 거래 처리 단계들입니다. DevOn Enterprise는 온라인 요청을 단순한 HTTP 호출이 아니라 규칙과 의미를 가진 거래로 다룹니다. 금융권에서 일반적으로 사용되는 표준 전문 방식을 통해 온라인 요청이 발생하면, 프레임워크는 전문 헤더 검증, Context 조립, 거래 제어, 전문 변환, 서비스 분기, 트랜잭션 관리, Biz 컴포넌트 조합 같은 단계를 선행하여 실행합니다. 따라서 서비스 계층에 진입하기 전부터 거래 관련 정보와 제어 조건이 표준화된 프로세스 내에서 정리됩니다.

각 레이어의 주요 역할은 아래와 같습니다.

Channel Interface Layer

Channel Interface Layer에서는 최초 Inbound Adapter를 통해 수신한 요청이 전문 헤더 검증 → Context 조립 → 거래 제어 → 전문 변환 → 서비스 호출 순서로 처리됩니다. 표준전문 헤더에 담겨 있는 다양한 공통 정보들을 기준으로 거래 처리에 필요한 파라메터들을 프레임워크 테이블에서 로드하고, 이를 Context에 적재하여 후속 처리 및 업무 서비스에서 관련 정보를 활용할 수 있도록 제공합니다. 이는 업무 서비스가 호출되기 전에 채널 정보, 전문 구조, 거래 규칙에 대한 해석이 Business Service 호출 전 완료된다는 의미로, 개발자 관점에서 중요한 점은 서비스가 "무엇을 처리할 것인가"에 집중할 수 있다는 것입니다. "이 요청은 어떤 채널에서 왔는가", "전문 헤더는 유효한가", "거래 통제 조건은 충족되었는가", "전문 구조는 어떤 내부 데이터 형태로 변환되어야 하는가"와 같은 판단은 Channel Interface Layer의 프레임워크 공통 처리를 통해 이뤄지고, 업무 개발자들은 비즈니스 로직 구현에 집중할 수 있습니다.

Business Layer

DevOn Enterprise의 Business Layer는 단순한 Service → DAO 직선 구조가 아닙니다. 서비스 Manager, 트랜잭션 관리, 서비스 분기, 서비스 선처리, 서비스(svc), 서비스 후처리가 하나의 흐름으로 이어지고, 실제 업무 구현 영역은 다시 Biz 컴포넌트(pbi), 업무공통 컴포넌트(cpi, cpbi), 엔티티 컴포넌트(ebi)로 나뉩니다. 프레임워크는 서비스 매니저나 연계 매니저 등의 공통 컴포넌트에서 전체 거래 프로세스 수행에 관련한 파라메터들을 로드하고 서비스 호출을 담당합니다. 업무 개발자들은 Biz 컴포넌트 영역에 비즈니스 로직을 구현하고, 필요한 경우 프레임워크에서 제공하는 Context 정보를 활용하거나 연계·연동 모듈을 호출하는 형태로 비즈니스 요건을 구현해낼 수 있습니다.

Persistence Layer

Persistant Layer에서는 DBMS와 상관없이 동일한 Connection 관리와 데이터베이스 접근에 대한 표준 컴포넌트를 제공합니다. 다건, 단건, 복합형, 페이징, 배치 처리를 위한 공통 DAO를 포함해 다양한 데이터베이스 컨트롤 관련 기능을 제공함으로써, 개발자들은 쿼리만 작성하는 방식으로 필요한 데이터를 신속하게 처리할 수 있습니다.

Layer별 핵심 기능

Layer별 핵심 기능을 성격에 따라 묶으면 아래와 같습니다.

Layer	구분	주요 기능
Channel Interface	통신 Adapter	HTTP, AJAX, TCP/IP, REST/SOAP
	어댑터	Inbound/Outbound Adapter
	전문 변환	FixedLength, JSON, XML, Key-Value
	검증	전문헤더 검증, 권한 검증, 유효성 검증
	거래 처리	Context 조립, 거래 제어, 채널별 View 구성, 거래 로그 연계
	장전문 처리	MCI, Hand-Shaking
Business	서비스 제어	서비스 Manager, Service Proxy/Delegator, 서비스 분기
	선·후처리	시스템 선·후처리, 서비스 선·후처리
	컴포넌트 조합	svc, pbi, cpi/cpbi, ebi
	트랜잭션 관리	JDBC, JTA, Nested Transaction
	연계	동기·비동기 연계 매니저, 응답 시뮬레이터
	운영 지원	서비스별 Timeout 제어, 시뮬레이션 거래, 책임자 승인 처리
Persistent	DAO	AutoDao, Custom DAO, 단건, 다건, 복합형, 페이징, 배치 DAO
	SQL 관리	Query Maker, Executer, Converter, Query.xml 기반 SQL 관리, Query Editor
	연결 관리	DB 연결관리, DataSource/ConnectionPool 추상화, 다중 DBMS 지원
	추적·이력	DB Trace, DWIO 변경 이력 연계

온라인 서비스 처리 관점에서 각 Layer가 갖는 의미는 다음과 같습니다.

• Channel Interface — 다양한 채널과 전문 형식을 서비스 앞단에서 공통 모델로 정규화합니다. 업무 서비스는 채널별 구현 차이를 직접 처리하지 않고, 표준화된 입력 구조를 기반으로 거래 로직에 집중할 수 있습니다.
• Business — 온라인 요청을 단순 메서드 호출이 아니라 통제 가능한 거래 흐름으로 다룹니다. 서비스 실행 전후 제어, 업무 공통 처리, 연계 처리, 예외 흐름을 표준 단계로 구성해 대규모 협업과 복합 거래 처리에 적합한 구조를 제공합니다.
• Persistent — 조립된 거래 로직을 일관된 데이터 접근 구조로 연결합니다. DBMS 차이를 흡수하면서 SQL, 커넥션, Trace, 변경 이력 기록까지 표준 방식으로 처리해 데이터 계층의 구현 편차를 줄입니다.

대형 금융권 개발 프로세스와의 적합성

금융권의 온라인 개발은 일반적인 웹 서비스 개발과 성격이 다릅니다. 화면 몇 개를 빠르게 만드는 것보다 전문 기반 거래, 다채널 요청, 엄격한 계층 분리, 공통 업무 규칙, 대규모 병렬 개발을 동시에 만족하는 것이 더 중요할 때가 많습니다.

이러한 요구를 DevOn Enterprise의 아키텍처 관점에서 정리하면 다음과 같습니다.

금융권 개발 요구	DevOn Enterprise 아키텍처가 적합한 이유
전문 기반 거래 처리	서비스 진입 전에 전문 헤더 검증, Context 조립, 전문 변환이 공통 흐름으로 정리됩니다.
거래 단위 통제	채널 계층과 서비스 계층 사이에 거래 제어 포인트가 명확하게 존재합니다.
대규모 협업	svc, pbi, cpi, cpbi, ebi처럼 역할이 구분되어 병렬 개발이 용이합니다.
공통 로직의 반복 방지	업무공통 컴포넌트와 엔티티 컴포넌트 구조를 통해 같은 패턴을 재사용할 수 있습니다.
복합 거래 처리	서비스 분기, 서비스 연동, 외부 연계가 아키텍처 안에서 자연스럽게 연결됩니다.

요약하면 DevOn Enterprise는 요청을 서비스 호출로 단순화하기 전에, 먼저 거래 단위로 구조화하는 프레임워크라고 볼 수 있습니다. 이 점이 대형 금융권 프로젝트와의 높은 적합성으로 이어집니다.

DevOn Boot의 온라인 아키텍처

DevOn Boot의 온라인 아키텍처는 Presentation, Business, Persistence/Integration 구조로 정리됩니다. DevOn Enterprise가 거래를 정교하게 분해해 다루는 구조라면, DevOn Boot는 Spring MVC 기반의 익숙한 요청·응답 흐름을 유지하면서 웹 요청과 연계 요청을 서비스 중심 구조로 확장한 형태에 가깝습니다. 즉 DevOn Boot의 핵심은, 가장 보편적인 REST API 구현 방식에 맞게 Controller → Service → Persistence/Integration이라는 직관적인 흐름을 기반으로 다양한 요청 유형을 하나의 서비스 처리 모델 안에 수용하는 데 있습니다.

각 레이어의 주요 역할은 아래와 같습니다.

Presentation Layer

Presentation Layer는 외부로부터 요청을 수신하고 응답 형태로 조립하는 계층입니다. Controller가 URL, 파라미터, 요청 본문을 받아들이고, 입력값 검증이나 화면·JSON 응답 형식 결정 같은 웹 진입점 역할을 담당합니다. 즉 "요청을 어떻게 받는가, 응답을 어떻게 내보내는가"에 집중하는 Layer로, DevOn Boot에서는 기본 SpringBoot에서 제공하는 기능 외에 Custom View나 다양한 입출력 데이터 유형(XML/JSON/FILE 등)에 따른 처리를 지원하는 Converter 등을 통해 안정적인 API 요청·응답 처리를 보장합니다.

Business Layer

Business Layer는 실제 비즈니스 로직을 수행하는 계층입니다. 보통 Service가 이 역할을 맡고, 여러 도메인 로직을 조합하거나 트랜잭션 범위를 제어하며, 화면 기술과 무관하게 "업무적으로 무엇을 처리해야 하는가"를 담당합니다. 예를 들어 주문 승인, 계좌 이체, 한도 검증 같은 핵심 로직이 여기에 들어갑니다. DevOn Boot에서는 원활한 비즈니스 로직 구현을 위한 다양한 유틸리티성 컴포넌트들과 부가적인 트랜잭션 제어 방식, 유연하게 확장 가능한 서비스 전후처리 인터셉터 기능, 그리고 기본 SpringBoot에서는 지원하지 않는 서비스 제어 기능 등을 제공합니다.

Persistence Layer

Persistence Layer는 데이터 저장소와 직접 통신하는 계층입니다. 보통 Repository나 DAO가 여기에 해당하고, DB 조회·저장·수정·삭제, SQL 실행, ORM 매핑 같은 작업을 맡습니다. DevOn Boot에서는 SpringBoot와 같이 개발자나 업무별로 각각 DAO를 만들지 않고, 제공된 Common DAO를 통해 DB 처리 기능을 제공함으로써 표준화와 생산성 향상에 기여합니다.

Spring MVC 기반 구조를 확장한 아키텍처의 장점

DevOn Boot는 단순히 Spring MVC를 사용한다는 점보다, 그 흐름 위에 서비스 제어와 공통 처리, 퍼시스턴스, 연계 호출 구조를 덧대어 서비스 확장을 더 쉽게 만든다는 점이 중요합니다.

확장 포인트	의미	개발자에게 주는 장점
서비스 제어	Controller 뒤에서 서비스 호출을 일정한 방식으로 정리	기능이 늘어나도 서비스 호출 패턴이 쉽게 흔들리지 않습니다.
업무 공통 전·후처리	서비스 앞뒤에 공통 업무 로직 배치	화면·API·연계별 중복 코드를 줄이고 같은 규칙을 재사용할 수 있습니다.
CommonDao + SQL files	데이터 접근 구조를 공통화	익숙한 MVC 흐름을 유지하면서도 DB 접근 방식을 표준화할 수 있습니다.
Persistence/Integration 분리	DB 처리와 외부 연계 호출을 함께 구조화	단순 CRUD를 넘어 연계형 서비스까지 같은 구조 안에서 확장할 수 있습니다.
View와 Data View 분리	화면 응답과 XML/JSON 응답을 함께 수용	화면 중심 서비스와 API 중심 서비스를 동시에 설계하기 쉽습니다.

결론적으로 DevOn Boot는 Spring MVC의 직관성을 유지한 채, 온라인 서비스가 점점 더 API화되고 연계 중심으로 확장되는 흐름에 자연스럽게 대응하도록 만든 아키텍처라고 볼 수 있습니다.

DevOn Boot 적용에 적합한 프로젝트 상황

프로젝트 상황	DevOn Boot를 권장할 수 있는 이유
화면과 API가 함께 존재하는 업무 시스템	View와 Data View(XML/JSON)를 같은 구조 안에서 함께 다룰 수 있습니다.
빠른 기능 확장이 필요한 서비스	Controller → Service → Dao 중심 흐름이 직관적이어서 변경 속도가 빠릅니다.
Spring 기반 개발 문화가 익숙한 조직	개발자 온보딩이 빠르고 이해 비용이 낮습니다.
연계가 자주 발생하는 서비스	Persistence/Integration 구조를 통해 DB 처리와 연계 호출을 함께 정리할 수 있습니다.

각 프레임워크의 온라인 아키텍처 비교

두 프레임워크의 차이는 기능 개수보다 온라인 요청을 어떤 단위로 바라보는가에서 가장 크게 드러납니다.

DevOn Enterprise는 요청을 거래로 해석합니다. 그래서 서비스 앞단에서 전문 헤더, Context, 거래 제어, 서비스 분기, Biz 컴포넌트 조합 같은 단계가 촘촘하게 배치됩니다. 복잡한 거래 규칙과 대규모 협업이 중요한 프로젝트에 강한 이유가 여기에 있습니다.

반면 DevOn Boot는 요청을 서비스 호출 흐름으로 해석합니다. 웹이든 API든 연계든 결국 Controller를 거쳐 Service로 진입하고, 이후 Persistence/Integration으로 연결됩니다. 이 구조는 직관적이며, 화면과 API가 함께 진화하는 서비스에 특히 잘 맞습니다.

비교 항목	DevOn Enterprise	DevOn Boot
온라인 요청을 보는 관점	거래 중심	서비스 중심
아키텍처의 출발점	전문과 거래를 먼저 정리	Controller 기반 요청 흐름을 먼저 정리
핵심 처리 방식	거래 제어, 서비스 분기, Biz 컴포넌트 조합	MVC 흐름 위에서 웹·API·연계를 확장
잘 맞는 프로젝트	대형 금융권, 전문 기반 거래, 대규모 병렬 개발	화면+API 공존 시스템, Spring 기반 업무 시스템, 연계형 서비스
가장 큰 장점	복잡한 거래를 표준화된 단계로 세밀하게 통제	익숙한 구조 위에서 빠르고 유연하게 확장

적용 권장 시나리오

정리하면 선택 기준은 비교적 명확합니다.

• DevOn Enterprise는 거래 구조가 복잡하고, 전문 기반 요청과 공통 규칙이 많으며, 여러 개발자가 병렬로 대형 프로젝트를 수행해야 하는 경우에 더 적합합니다.
• DevOn Boot는 화면, API, 연계 요청이 함께 존재하고, 익숙한 Spring MVC 흐름 위에서 서비스를 빠르게 확장해야 하는 경우에 더 적합합니다.

즉 DevOn Enterprise는 복잡한 거래를 안정적으로 표준화해야 하는 프로젝트, DevOn Boot는 서비스를 직관적으로 확장해야 하는 프로젝트에 더 잘 맞는다고 정리할 수 있습니다.

결론

LG CNS의 DevOn Enterprise와 DevOn Boot는 모두 온라인 서비스를 위한 프레임워크이지만, 같은 문제를 같은 방식으로 해결하지는 않습니다. DevOn Enterprise는 거래를 중심으로 요청을 정교하게 통제하는 아키텍처이고, DevOn Boot는 익숙한 Spring MVC 흐름을 기반으로 웹과 API, 연계 요청을 유연하게 확장하는 아키텍처입니다.

결국 중요한 것은 어느 프레임워크가 더 우수한가가 아니라, 현재 구축하려는 온라인 서비스가 어떤 성격을 가지는가입니다. 이 관점으로 보면 두 프레임워크는 경쟁 관계라기보다, 서로 다른 프로젝트 상황에 더 적합한 선택지로 이해하는 편이 자연스럽다는 말로 글을 맺습니다.

※ 본 게시글의 이미지는 AI를 활용해 제작되었습니다.