116. 참조 모델 (Reference Model) - 아키텍처 재사용의 극의

⚠️ 이 문서는 엔터프라이즈 아키텍처(EA)를 구축할 때, 매번 빈 종이(백지)에서 처음부터 도면을 그리는 멍청한 짓을 막기 위해, **국가나 글로벌 표준 협회에서 미리 "보통의 회사들은 이 기능과 이 장비를 주로 씁니다"라고 모범 답안지(베스트 프랙티스)와 부품 카탈로그를 정립하여 배포하는 '참조 모델(BRM, DRM, SRM, TRM)'**의 구성 체계를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 다른 사람들이 이미 고민해서 훌륭하게 만들어놓은 '분류 체계'이자 '표준 레고 블록 세트'다. 내가 새로 지을 시스템이 이 거대한 국가 공통 분류표 중 어디에 속하는지 꼬리표를 달아 매핑(Mapping)하는 작업표다.
  2. 가치: 이 참조 모델에 맞춰 시스템을 등록해 두면, 전국 수백 개 부처가 "어? 행안부가 작년에 만들어 둔 '문자 발송 모듈(SRM)'이 여기 있네? 우리 새로 개발하지 말고 쟤네 거 API로 가져다 쓰자!" 라며 극적인 중복 투자 방지와 소스코드 재사용이 가능해진다.
  3. 기술 체계: BRM(업무), DRM(데이터), SRM(서비스/소프트웨어 기능), TRM(기술 인프라/하드웨어) 이라는 4대 참조 모델로 나뉘어 비즈니스부터 하드웨어까지 전 계층을 카탈로그화하여 감시한다.

Ⅰ. 백지 설계의 낭비와 참조 모델의 탄생 원리

맨땅에 헤딩하는 것은 용감한 게 아니라 세금을 태우는 것이다.

  1. 상호운용성(Interoperability)의 단절:
    • 옛날에는 국방부와 경찰청이 각자 맘대로 시스템을 지었다.
    • 국방부는 이름을 저장할 때 필드명을 USER_NM이라 하고 10자리로 짰고, 경찰청은 NAME이라 하고 20자리로 짰다. 나중에 범죄자 데이터를 합치려(연동) 하니 규격이 달라 데이터베이스가 붕괴했다.
  2. 참조 모델(Reference Model)의 강제성:
    • 국가(행정안전부 등)에서 4개의 거대한 책(카탈로그)을 발간했다.
    • "앞으로 대한민국 공공기관은 어떤 IT 시스템을 만들든 무조건 이 4권의 책에 있는 표준 단어와 표준 분류 체계를 베껴서 써라. 이 책에 없는 이상한 걸 마음대로 창조해서 쓰면 예산을 안 주겠다."
  3. 분류와 재사용의 마법:
    • 참조 모델은 '분류표'다. 마트의 진열대와 같다. 내가 새로 짠 결제 프로그램 코드를 쓱 내버려 두는 게 아니라, [SRM-결제-카드모듈] 이라는 정확한 진열대 위치 번호를 달아서 전사 시스템(EA 포털)에 등록해야 한다. 그래야 내년에 딴 부서가 진열대를 뒤져서 그 코드를 다시 꺼내 쓴다.

📢 섹션 요약 비유: 각자 집에서 알아서 요리를 해 먹으라 하면, 누구는 소금을 'Salt'라 적고 누구는 '소곰'이라 적어 나중에 레시피(데이터)를 합칠 수 없습니다. 참조 모델은 국가에서 배포한 '통일된 요리 백과사전'입니다. "야채를 썰 땐 무조건 도감 3페이지의 '채썰기(표준안)' 방식을 따르고, 불을 켤 땐 도감 10페이지의 '가스레인지 규격(기술 표준)'을 지켜라"라고 강제해 온 나라의 식당 시스템을 통일시키는 법전입니다.

Ⅱ. 4대 참조 모델의 해부 (BRM, DRM, SRM, TRM)

위에서 아래로 흘러가는 완벽한 4개의 서랍장이다.

  1. BRM (업무 참조 모델, Business Reference Model):
    • "이 시스템은 도대체 **무슨 일(업무)**을 하려고 띄운 거야?"
    • 대한민국의 모든 정부 업무를 최상위, 중위, 하위로 쪼개놓은 트리(Tree) 구조의 엑셀 표다.
    • 예: 새로 개발한 '코로나19 재난지원금 시스템'은 맘대로 이름을 짓는 게 아니라, BRM 카탈로그의 [보건복지(대) - 사회복지(중) - 재난지원(소)] 이라는 공식 꼬리표를 달아서 EA 포털에 등록해야 한다. 그래야 국가가 보건 복지 쪽에 예산을 얼마나 썼는지 한눈에 파악한다.
  2. DRM (데이터 참조 모델, Data Reference Model):
    • "서로 데이터 좀 섞어 쓰게 단어와 구조 좀 통일하자!"
    • 데이터 표준 사전이다. 앞서 말한 이름, 주민번호, 주소 등을 DB에 저장할 때 반드시 지켜야 할 타입(Type)과 길이 규격을 명시해 두어, 부처 간 데이터 연계(API) 시 충돌이 안 나게 막아준다.
  3. SRM (서비스 컴포넌트 참조 모델, Service Component RM):
    • "너 이거 진짜 처음 만드는 거 맞아? 작년에 딴 부서가 비슷한 기능(소프트웨어) 안 만들었어?"
    • IT 시스템에 들어가는 모든 소프트웨어 조각(로그인, 파일업로드, 전자결재 등)의 카탈로그다. 개발팀은 이 SRM 장터를 먼저 뒤져서 남이 만들어둔 조각(컴포넌트)을 훔쳐다 쓰고, 진짜 없는 기능만 돈 들여서 새로 개발해야 한다(중복 개발 원천 차단).
  4. TRM (기술 참조 모델, Technology Reference Model):
    • "해킹당하기 쉬운 싸구려 장비 쓰지 마. **국가가 허락한 검증된 기술(인프라/표준)**만 써!"
    • 서버 OS는 Linux CentOS 8.0 이상, 데이터베이스는 Oracle 19c 또는 PostgreSQL 14, 암호화 알고리즘은 AES-256 등 국가가 사용을 허락한(표준 규격) 소프트웨어와 하드웨어 장비의 리스트업이다. 이 TRM 리스트에 없는 이상한 중국산 DB를 도입하면 감리에서 박살이 난다.

📢 섹션 요약 비유: 쇼핑몰을 창업한다고 관공서에 기안을 올립니다. ① BRM: "업종이 뭐니?" $\rightarrow$ 전자상거래-식품 입니다. ② DRM: "고객 장부 양식은 국가 규격을 썼니?" $\rightarrow$ 성함(Varchar 20) 지켰습니다. ③ SRM: "장바구니 기능 새로 만들었니?" $\rightarrow$ 아니요, 옆 팀이 만든 거 [장바구니 컴포넌트] 복사해서 공짜로 달았습니다. ④ TRM: "서버 냉장고는 안전한 거 샀니?" $\rightarrow$ 예, 국가에서 허락한 [삼성 1등급 냉장고(TRM 기술 표준)] 샀습니다. 이 4개의 질문에 통과해야만 허가가 떨어집니다.

Ⅲ. 전사 연속체 (Enterprise Continuum)와의 융합

가장 추상적인 것에서 우리 회사만의 것으로 살이 붙는다.

  1. 기반 아키텍처에서 산업 아키텍처로:
    • 이 참조 모델들을 모아둔 가상의 거대한 도서관이 바로 TOGAF에서 말하는 **'엔터프라이즈 연속체(Continuum)'**다.
    • 처음에는 Foundation Architecture(전 세계 공통 기술 기반, 예: TCP/IP)에서 시작해서, Common Systems Architecture(공통 시스템, 예: 이메일 서버), 그다음 Industry Architecture(금융업계 공통 모델), 마지막에 가장 오른쪽인 **Organization-Specific Architecture(우리 회사만의 고유한 찐 아키텍처)**로 조금씩 살을 붙여 넘어온다.
  2. 참조 모델의 생명력:
    • 참조 모델은 고정된 화석이 아니다. 새로운 AI 기술(예: ChatGPT)이 나오면 국가 기관은 헐레벌떡 TRM(기술 참조 모델) 리스트를 업데이트하여 "이제 공공기관도 생성형 AI API를 써도 좋다!"라고 허락해 주어야 하며, 현장은 이 업데이트된 카탈로그를 바탕으로 다시 시스템을 진화시킨다.

📢 섹션 요약 비유: 자동차 회사가 새 차를 만들 때 100% 전부 백지에서 발명하지 않습니다. 바퀴 4개로 굴러간다는 전 세계 공통 법칙(Foundation)을 가져오고, '자동차 산업 공통 안전 규격(Industry RM)'을 베낀 다음, 마지막으로 우리 회사 특유의 호랑이 코 그릴 디자인(Organization-Specific)만 살짝 추가해서 차를 완성합니다. 참조 모델 도서관이 있기에 인류의 기술 발전 속도가 수백 배 빨라진 것입니다.