객체 식별의 어려움에서 기인한 패턴들

인공지능 시대의 소프트웨어 공학

Aug 7. 2025

<생각을 나눠 요소를 만드는 일의 어려움>에 이어서 식별(識別)에 대한 이야기를 계속해 봅니다.

Entity-control-boundary라는 아키텍처 패턴

2000년 초중반 객체지향분석설계 방법론과 UML이 업계 표준으로 쓰일 때, 식별 기준으로 가장 마음에 들었던 패턴이 있습니다. Entity–control–boundary 위키피디아 정의를 크롬 번역하여 인용합니다.

엔티티-제어-경계 (ECB) 또는 엔티티-경계-제어(EBC) 또는 경계-제어-엔터티(BCE)는 사용 사례 중심 객체 지향 프로그래밍에서 사용되는 아키텍처 패턴으로, 사용 사례 실현에서의 책임에 따라 고수준 객체 지향 소스 코드를 구성하는 클래스를 구조화합니다.

액터Actor는 시스템 외부에 존재하는 개념입니다. 액터가 시스템의 존재 이유를 제시하는데, 이를 쓰임새라고 합니다. 하지만, 쓰임새(use case)는 시스템이 무엇을 해야 하느냐를 어떤 구성요소와 구조를 지녀야 하는지는 다루지는 않습니다.

소프트웨어 및 시스템 엔지니어링 분야에서 사용 사례는 특정 목표를 달성하기 위해 외부 행위자의 요청에 응답하는 시스템의 동작을 체계적으로 설명하는 것입니다. 이 용어는 소프트웨어/시스템 엔지니어링 분야 외에서도 어떤 것이 어떻게 사용될 수 있는지를 설명하는 데 사용됩니다.

함께 쓰임새를 만들어야 할 구조를 정할 때, 세 가지 유형의 객체 기준(정확하게는 스테레오 타입이라고 부릅니다.)을 제시했던 것이죠.

3 계층 아키텍처 패턴을 소환하다

스무 해가 지나서 보니 두 가지 생각이 듭니다. 하나는 이 패턴이 기술이나 환경 변화에 맞춰서 발전하거나 진화하지 못했다는 아쉬움입니다.[1] 두 번째는 당시 유행하던 아키텍처 패턴이 3 티어 혹은 3 계층 구조였던 점을 떠올렸습니다.

EBC와 3 계층 아키텍처 패턴의 조화

2000년대 객체지향 프로젝트를 떠올려 보면 객체의 식별에 대해서는 ECB 패턴이, 웹 계층에 대해서는 3 계층 아키텍처 패턴이 사실상 표준으로 쓰였습니다. 이 둘을 대응시켜 보면 거의 일대일대응이 가능해 쉽고 명확하게 받아들일 수 있는 기준이 됩니다.

그러나 아키텍처 패턴은 분명한 한계가 있습니다. 시스템 전체에 대해 부여하는 패턴이기 때문에 시스템이 복잡해질 때, 식별(識別)이나 적당한 묶음을 위한 도움을 주지는 못합니다.[2]

Transaction Script 유행의 배경

그런 빈 틈을 이용해 널리 유행한 프로그래밍 패턴이 마틴 파울러가 명명한 Transaction Script입니다.

다음은 마틴 파울러의 Transaction Script 정의를 퍼플렉시티에 주고 UML 도식으로 변경한 결과입니다.

3 계층 아키텍처 패턴에 Transaction Script 방식을 도입하면 아주 명쾌한 프로그램 배열 규칙을 만들 수 있습니다. 우리나라 환경에 맞춰 약간의 코멘트를 덧붙이면 명쾌하게 과거에 대유행했던 방식을 담아낼 수 있습니다. 여기에는 관계형 데이터베이스의 지배적인 위상을 전제로 합니다. 어쩌면 자바 언어의 인기도 관계형 데이터베이스의 보급과 더불어 JDBC 기술을 이용한 강력한 연동이 시너지로 작동했을 가능성이 높습니다.

그로 인해 웹 개발은 한국 개발자들에겐 너무나도 널리 쓰이던 표현인 CRUD(Create, Read, Update, Delete의 줄임말) 요청 중 하나인 경우가 대부분입니다. 그걸 받으면 비즈니스 로직 대부분은 그저 SQL과 연결하는 것으로 해결할 수 있습니다. 그러다 보면 비즈니스 로직이란 것이 결국은 DBMS가 데이터 무결성을 보장하는 Transcation을 처리하는 스크립트 이상도 이하도 아니게 됩니다.

개인적으로는 Transaction Script는 선호하는 패턴이 아니긴 하지만, 외주 개발 환경에서 단기에 결과를 내는 일을 '생산성'이라고 부르던 시절에는 분명 효과적인 방법이기는 했습니다.

글을 마치며...

식별(識別)을 주제로 삼아 이야기를 풀었더니 Entity–control–boundary와 Transaction Script가 빠르게 활용할 수 있는 명백한 '식별 기준'으로 비교 우위를 점했던 역사가 튀어나왔습니다. 물론 제 경험을 썼을 뿐 정사는 아니죠. 그럼에도 불구하고 독자님들에게 생각할 거리를 던지기에는 충분한 듯합니다. 다음 글에서는 Transaction Script 다음(?) 혹은 대안에 대해 써 보려고 합니다. 역시 식별(識別) 관점에서 말이죠.