287. 상호운용성 (Interoperability) - 시스템 간 정보 교환 전술

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

1. 본질: 상호운용성(Interoperability)은 서로 다른 플랫폼, 언어, 아키텍처로 만들어진 독립적인 시스템들이 서로 유의미한 정보(Data)와 서비스(Service)를 원활하게 교환하고 사용할 수 있는 능력을 뜻하는 품질 속성이다.
2. 가치: 현대의 엔터프라이즈 환경은 단일 시스템(Monolith)에서 수많은 외부 SaaS, 레거시 시스템, 마이크로서비스가 얽힌 생태계로 진화했다. 상호운용성이 확보되지 않으면 비즈니스의 고립(Silo)과 확장 불능을 초래한다.
3. 융합: 상호운용성 전술은 "위치 파악(Discovery) → 연결 및 통신(Communication) → 언어 번역(Translation)"이라는 3단계 아키텍처 뼈대로 구성되며, 이는 SOA, REST API, ESB, 그리고 현대의 Service Mesh 설계 사상과 완벽하게 일치한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 상호운용성은 내 시스템(System A)이 외부 시스템(System B)과 상호작용할 때, 양쪽 모두 특별한 수작업이나 코드의 하드코딩 없이도 표준화된 방법으로 정보를 주고받을 수 있는 아키텍처적 능력이다.

• 필요성: 우리 회사의 '주문 서버(Java)'가 택배사의 '배송 서버(C++)'에 주문 정보를 넘겨야 한다. 자바의 내장 객체를 그대로 넘기면 C++ 서버는 이를 읽을 수 없다. 택배사 서버가 어디에 있는지 IP를 하드코딩하면, 택배사 서버가 이사 갈 때 우리 서버도 같이 다운된다. 서로의 언어와 위치가 달라도 대화할 수 있는 '공용어'와 '우체국' 같은 체계가 필요하다.

• 💡 비유: 한국인(System A)과 프랑스인(System B)이 대화하는 것과 같습니다. 서로의 집 주소를 외우는 대신 스마트폰 연락처(Discovery)로 전화를 걸고, 각자의 언어로 말하는 대신 영어(Standard Protocol)로 대화하거나, 중간에 통역사(Translator/Broker)를 두어 소통하는 방법이 바로 상호운용성 전술입니다.

• 등장 배경 및 발전 과정:

  1. 강결합과 포인트 투 포인트(Point-to-Point): 초기 시스템은 필요할 때마다 시스템끼리 1:1로 직접 연결망을 구축했다(스파게티 네트워크). 통신 규격이 다 달라 확장이 불가능했다.
  2. EAI와 ESB (통역사 도입): 이기종 레거시 시스템들을 묶기 위해, 중앙에 무거운 버스(Enterprise Service Bus)를 두고 메시지 포맷을 강제로 변환(Translation)시켰다.
  3. RESTful API와 마이크로서비스 (표준어 도입): 무거운 중앙 통제 대신, 모두가 JSON과 HTTP라는 가벼운 세계 공용어를 사용하도록 표준화하여 시스템들이 독립적으로 소통하는 시대로 진화했다.

• 📢 섹션 요약 비유: 옛날엔 110V 전자제품을 쓰려면 각 나라에 맞는 돼지코(변환기)를 일일이 들고 다녀야 했지만, 지금은 전 세계 어디서나 똑같은 USB-C 포트(표준화된 상호운용성) 하나면 모든 기기가 서로 연결되고 충전되는 혁명과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

상호운용성 시나리오 (6요소)

상호운용성 요구사항은 다음 6가지 요소로 구체화된다.

• 자극원: 내부의 다른 마이크로서비스, 외부 서드파티(3rd Party) 시스템
• 자극: 데이터 제공 요청, 서비스 실행 요청, 상태 변경 알림 이벤트 발생
• 환경: 런타임, 서로 다른 네트워크 망, 시스템 추가/변경 시
• 대상: 시스템의 통신 인터페이스, API 게이트웨이, 메시지 브로커
• 응답: 상대방의 위치를 파악하고, 요청을 해석하여 적절한 포맷으로 변환 후 응답함
• 응답 척도: 연동 시 시스템 수정 공수(예: 0 MD), 거절되는 메시지 비율 0%, 데이터 파싱 및 변환 소요 시간(10ms 이내)

상호운용성 3대 전술 (Interoperability Tactics)

두 시스템이 성공적으로 대화하려면 다음의 세 가지 장애물을 넘어야 한다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 시스템 간 대화를 위한 3대 아키텍처 전술           │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │     [1. 위치 파악]               [2. 통신 및 라우팅]           │
  │   (너 어디에 있니?)              (데이터를 어떻게 전달할까?)       │
  │                                                             │
  │  - Service Discovery         - 메시징 (Pub/Sub)             │
  │  - DNS / Registry            - 오케스트레이션 (Orchestration) │
  │                              - 코레오그래피 (Choreography)    │
  │                                                             │
  │                 ＼                 ／                       │
  │                   ▼               ▼                       │
  │             [3. 데이터 번역 및 매핑 (Translation)]           │
  │                (네가 한 말을 내가 이해하게 바꿔줘)              │
  │                                                             │
  │         - 표준 데이터 포맷 사용 (XML, JSON, Protobuf)         │
  │         - 어댑터(Adapter) / 파사드(Facade) 도입              │
  │         - ESB / API Gateway의 페이로드 변환                   │
  └─────────────────────────────────────────────────────────────┘

1. 위치 파악 (Locate) 전술

통신할 상대방 시스템의 IP나 주소를 알아내는 기술. 하드코딩을 피하기 위한 핵심 전술이다.

• Service Discovery (서비스 디스커버리): 클라우드 환경에서는 서버(Pod)가 수시로 생기고 죽으며 IP가 바뀐다. 넷플릭스 Eureka나 Consul 같은 중앙 레지스트리(Registry)에 서버들이 자신의 IP를 등록하고, 클라이언트는 "배송 서버 주소 좀 알려줘"라고 물어봐서 동적으로 위치를 찾는 기술.

2. 통신 및 상호작용 (Communicate / Manage Interfaces) 전술

데이터를 어떤 타이밍에, 어떤 방식으로 주고받을지 결정하는 기술.

• 오케스트레이션 (Orchestration): 중앙의 지휘자(예: 로직 서버)가 A에게 일 시키고, 끝나면 B에게 지시하는 동기식 제어 방식. 구현이 쉽지만 지휘자에게 병목(결합도)이 생길 수 있다.
• 코레오그래피 (Choreography): 중앙 지휘자 없이, 각 시스템이 이벤트 큐(Kafka)에 "나 결제 끝났어"라고 던지면, 알아서 배송 시스템이 주워 가서 일하는 완전 비동기/탈중앙화 통신 방식. 상호운용성의 궁극적 형태다.

3. 데이터 번역 및 매핑 (Translate / Tailor) 전술

서로 다른 언어나 데이터 구조를 맞추는 기술.

• 표준화 (Standardization): 변환기가 필요 없도록, 애초에 모든 시스템이 RESTful 원칙과 JSON 포맷으로 대화하자고 전사적 표준을 강제하는 전술.

• 어댑터(Adapter) 패턴: B 시스템이 낡은 XML 포맷만 고집한다면, 내 시스템과 B 사이에 'XML ↔ JSON 변환기(어댑터)'를 하나 끼워 넣어 내 시스템의 순수성을 지키는 전술. (Anti-Corruption Layer)

• 📢 섹션 요약 비유: (위치 파악)은 전화번호부를 검색하는 것이고, (통신)은 전화를 걸지 카톡을 남길지 정하는 것이며, (번역)은 전화기 중간에 동시통역 앱을 켜두는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 상호운용성 통신 포맷 비교: JSON vs gRPC (Protobuf)

현대 아키텍처에서 상호운용성을 위한 데이터 포맷(표준)의 2대 산맥이다.

상호운용성(범용성)만 본다면 JSON이 압도적이지만, 시스템 내부망에서 수만 번의 통신(번역 전술)이 일어난다면 성능(Performance) 품질 속성과 충돌하므로 gRPC라는 타협점을 선택해야 한다.

과목 융합 관점

• 소프트웨어 공학 (SE): 디자인 패턴 중 어댑터(Adapter) 패턴, 파사드(Facade) 패턴은 시스템 내부 코드 레벨에서 이기종 클래스들의 상호운용성을 맞춰주는 핵심 구조 패턴이다.

• 클라우드 / 엔터프라이즈: API Gateway 패턴이 바로 상호운용성의 최전방 수문장이다. 외부의 잡다한 요청을 받아, 내부 마이크로서비스들이 이해할 수 있는 프로토콜로 라우팅하고 헤더를 번역(Translation)해 주는 역할을 전담한다.

• 도메인 주도 설계 (DDD): 외부 시스템의 더러운 데이터 모델이 우리 핵심 도메인 모델을 오염시키지 못하도록 막는 **부패 방지 계층(ACL, Anti-Corruption Layer)**이 데이터 번역 전술의 최고급 아키텍처 철학이다.

• 📢 섹션 요약 비유: JSON이 누구나 쉽게 떠듬떠듬 말할 수 있는 '쉬운 영어'라면, gRPC는 고도로 숙련된 스파이들끼리 0.1초 만에 눈빛으로 교환하는 '비밀 수어'와 같습니다. 상호운용성을 위해 누구와 대화하느냐에 따라 언어를 바꿔야 합니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 구형 레거시(Legacy) 시스템 연동의 지옥: 우리 회사의 최신 스프링 부트(Spring Boot) 서버가, 20년 된 은행의 메인프레임 서버(TCP Socket, 전문 길이 100Byte 고정 포맷)와 연동해야 한다. 신입 개발자가 비즈니스 로직(Service 계층) 한가운데에 byte[] 배열을 자르고 붙이는 코드를 500줄이나 짜넣었다.

   • 아키텍트의 해결책: 번역 전술과 어댑터 패턴의 부재로 도메인 로직이 오염되었다. 아키텍트는 비즈니스 로직에 은행의 통신 규격이 단 한 줄도 스며들지 않게 막아야 한다. 인프라스트럭처 계층에 BankAdapter를 만들고, 데이터의 변환(Translation)은 어댑터 내부에서만 일어나도록 캡슐화해야 한다. 그래야 내년에 은행이 REST API로 망을 업그레이드해도 우리 비즈니스 코드는 안전하다(ACL 적용).

2. 시나리오 — MSA 환경에서 서버 IP 하드코딩으로 인한 연쇄 장애: 마이크로서비스 A가 서비스 B의 API를 호출하기 위해 소스 코드의 application.yml에 url=http://10.0.0.5:8080을 하드코딩해 두었다. 서버 B가 오토스케일링으로 늘어나며 IP가 변경되자, A 서버가 길을 잃고 Connection Refused 에러를 내며 뻗어버렸다.

   • 아키텍트의 해결책: 위치 파악(Discovery) 전술을 도입해야 한다. 정적인 IP 하드코딩을 버리고, Netflix Eureka 같은 Service Registry나 쿠버네티스의 내장 DNS 서비스(http://service-b.default.svc.cluster.local)를 활용하여 동적 라우팅을 구성해야 한다. A는 B의 '이름'만 부르고, 인프라가 '위치'를 찾아주는 완벽한 상호운용성 아키텍처다.

도입 체크리스트

• 기술적: API 통신 시 서로의 데이터가 맞지 않으면 시스템이 터지지 않도록, JSON 역직렬화(Deserialization) 시 모르는 필드(Unknown Properties)가 들어와도 무시하도록(Fail-safe) 설정되어 있는가? (견고성 원칙: 보낼 때는 엄격하게, 받을 때는 너그럽게)
• 설계적: 두 시스템 간에 데이터를 주고받을 때 동기(Sync/HTTP)로 할지 비동기(Async/MQ)로 할지 결정했는가? 결제 모듈처럼 즉각적인 결과가 필요한 건 동기(오케스트레이션)로 짜야 하지만, 포인트 적립처럼 나중에 처리해도 되는 건 비동기(코레오그래피)로 끊어 상호운용성의 결합도를 낮춰야 한다.

안티패턴

• 내부 DB 직접 접근 (DB Integration): 가장 끔찍한 상호운용성 안티패턴. A 서버가 B 서버의 데이터를 원할 때, B 서버의 API를 호출하지 않고 B 서버의 데이터베이스(DB)에 꽂힌 렌선으로 직접 쿼리(Select)를 날리는 행위. B 서버 개발자가 DB 칼럼 이름을 바꾸는 순간 A 서버가 폭파된다. 상호운용성은 반드시 공개된 'API 계층(인터페이스)'을 통해서만 이루어져야 한다.

• 📢 섹션 요약 비유: 이웃집(B 서버)에 간장을 빌리러 갈 때, 벨을 누르고 현관(API)에서 간장을 달라고 해야지, 이웃집 담을 넘어 몰래 부엌 찬장(DB)을 뒤져 간장을 꺼내오면 나중에 이웃집이 이사 갈 때 저는 도둑으로 몰려 철창(버그)에 갇히게 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 서비스 메시 (Service Mesh): 과거에는 상호운용성 전술(Discovery, 암호화, 번역)을 개발자가 소스 코드(라이브러리)에 일일이 짜 넣었다. 이제는 Istio나 Linkerd 같은 인프라스트럭처(Service Mesh)가 서버 앞단의 프록시(Sidecar)로 붙어, 개발자는 비즈니스 로직만 짜고 네트워크 상호운용성은 인프라가 100% 대행하는 시대로 완벽히 넘어왔다.
• 데이터 패브릭 (Data Fabric): 사일로(Silo)화 된 수많은 클라우드와 온프레미스 DB들을 가상으로 엮어, 사용자가 데이터의 물리적 위치(Discovery)나 포맷(Translation)을 신경 쓰지 않고 하나의 통합된 뷰로 접속할 수 있게 해주는 차세대 데이터 아키텍처 개념이 대두되고 있다.

참고 표준

• REST (Representational State Transfer): Roy Fielding이 제안한 가장 보편적이고 위대한 웹 상호운용성 아키텍처 스타일 표준.
• OpenAPI Specification (Swagger): 서로 다른 시스템 간에 REST API 스펙을 기계가 읽을 수 있도록 표준화한 언어 중립적 명세.

상호운용성은 아키텍트에게 **"겸손과 배려의 철학"**을 요구한다. 내 시스템이 세상의 중심이 아님을 인정하고, 언젠가 완전히 낯선 외계어(이기종 시스템)를 쓰는 시스템과 소통해야 할 날이 올 것임을 대비하는 설계다. 기술사는 외부의 더러운 데이터와 프로토콜이 내 아름다운 시스템을 오염시키지 못하도록 '어댑터'라는 방패를 들고, 반대로 남들이 내 시스템을 쉽게 부를 수 있도록 '표준화된 API'라는 훌륭한 이정표를 세워주는 외교관 역할을 수행해야 한다.

• 📢 섹션 요약 비유: 상호운용성 전술은 훌륭한 공항을 짓는 것과 같습니다. 전 세계의 어떤 비행기(이기종 시스템)가 오더라도 활주로의 규격(표준화)이 맞아야 하고, 관제탑(디스커버리)이 길을 안내하며, 입국 심사대(어댑터)에서 규정에 맞게 여권을 번역해 주어야만 전 세계와 통하는 허브 공항이 될 수 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 영어를 쓰는 미국 친구와 한국어를 쓰는 여러분이 전화를 해야 해요. (서로 다른 시스템)
2. 먼저 친구의 진짜 전화번호를 주소록에서 찾아야 하고(위치 파악), 전화를 걸어 연결한 뒤(통신), 중간에 통역사 앱을 켜서(번역) 대화를 나눕니다.
3. 이렇게 말도 다르고 사는 곳도 다른 컴퓨터들이 마치 한 동네 친구처럼 자연스럽게 대화하고 정보를 주고받을 수 있게 하는 기술을 **'상호운용성'**이라고 부른답니다!