레거시 시스템을 표준 플랫폼으로 전환하는 엔지니어의 자산 통합 감각
개발 현장에서 새로운 프로젝트를 시작할 때 엔지니어들이 가장 먼저 보이는 본능은 백지상태에서 아키텍처를 새로 그리는 일입니다. 낡은 프레임워크와 스파게티처럼 얽힌 데이터베이스 스키마를 마주하면, 누구라도 레거시 코드를 모두 걷어내고 최신 스택을 도입해 처음부터 다시 짜고 싶어 합니다. 기존 코드를 분석하고 파편화된 인터페이스를 조율하는 작업은 지루하고 고통스럽지만, 빈 에디터에 모던 아키텍처를 설계하는 일은 기술적 만족감을 즉각적으로 채워주기 때문입니다.
하지만 비즈니스의 관점에서 시스템을 바닥부터 새로 짓는 선택은 막대한 시간과 비용을 요구하는 동시에, 기존 시스템이 수년에 걸쳐 증명해 온 현장 적합성과 고객 접점을 버리는 위험한 도박이 되기 쉽습니다. 인프라를 처음부터 구축하느라 1년이 넘는 시간을 소비하는 동안 시장의 기회는 사라지고, 과거의 엣지 케이스를 다루던 숨은 도메인 지식은 신규 시스템에서 누락되어 치명적인 장애로 돌아옵니다. 뛰어난 엔지니어링 리더십은 무조건적인 신규 구축이 아니라, 이미 동작하고 있는 거친 자산들을 어떻게 표준화된 플랫폼 위로 빠르게 흡수해 가치를 증폭시킬 것인가를 고민하는 지점에서 출발합니다.
벤처스퀘어에 따르면 글로벌 호텔 기업 IHG 호텔 & 리조트는 일본 교토에서 부동산 투자사 GCP 호스피탈리티와 손잡고 14개 호텔, 총 1,063개 객실 규모의 포트폴리오를 전환하는 계약을 체결했습니다. 새 호텔을 짓지 않고 기존에 운영되던 로컬 호텔 자산의 간판과 운영 체계를 바꾸는 '브랜드 전환' 방식을 택한 것입니다. 대상 호텔들은 향후 12개월 동안 리노베이션을 거쳐 IHG의 미드스케일 브랜드인 가너 호텔과 홀리데이 인 익스프레스 등으로 순차 개장합니다. 건물을 새로 올리는 대신, 교토역과 시조 등 핵심 상권에 이미 자리 잡은 현장 자산에 IHG의 글로벌 예약망과 1억 6,000만 명 이상의 회원을 보유한 'IHG 원 리워드' 플랫폼을 결합하는 전략입니다.
이러한 비즈니스 접근은 소프트웨어 아키텍처와 엔지니어의 커리어 경로에도 정확히 들어맞습니다. 소프트웨어 엔지니어의 진정한 몸값은 프레임워크를 최신 버전으로 갈아치우는 속도가 아니라, 서로 다른 프로토콜과 데이터 구조를 가진 분산 자산을 하나의 거대한 생태계로 묶어내는 시스템 통합 역량에서 결정됩니다.
신규 구축의 유혹과 검증된 자산의 전환 가치
많은 엔지니어링 팀이 레거시 개편 프로젝트를 실패로 끝맺는 이유는 소프트웨어의 가치가 코드가 아니라 도메인 데이터와 비즈니스 트랜잭션의 연속성에 있다는 사실을 간과하기 때문입니다. 기존에 돌아가던 시스템이 아무리 지저분해 보일지라도, 그 안에는 결제 오류를 방어하기 위해 수없이 덧대어진 예외 처리와 지역별 세무 규정, 그리고 고객의 특이한 주문 패턴을 수용해 온 수년 치의 도메인 지식이 녹아 있습니다. 이를 '기술 부채'라는 단어 하나로 폄하하고 제로베이스에서 다시 작성하려 들면, 팀은 과거의 선배들이 겪었던 수백 가지의 예외 상황을 프로덕션 환경에서 똑같이 다시 겪으며 대가를 치러야 합니다.
호텔 산업에서 신축 대신 기존 자산의 리브랜딩을 택하는 가장 큰 이유는 공사 기간을 획기적으로 줄이면서 이미 입지가 검증된 자산을 선점하기 위함입니다. 도심 한가운데에 땅을 파고 건물을 올리는 데는 수년이 걸리지만, 이미 영업 중인 호텔의 내장과 백오피스 인터페이스를 글로벌 표준 규격으로 맞추는 작업은 1년 안팎이면 충분합니다. 이는 엔지니어링 환경에서 Greenfield(신규 구축) 방식 대신 Brownfield(기존 자산 보존 및 확장) 전략을 택하는 이유와 동일합니다. 시장이 요구하는 기능 출시 기한은 점점 짧아지는데, 백엔드를 처음부터 다시 만들겠다는 고집은 비즈니스 경쟁력을 갉아먹는 원인이 됩니다.
시니어 엔지니어라면 레거시를 전면 폐기하는 대신 스트랭글러 피그(Strangler Fig) 패턴처럼 점진적으로 기존 시스템의 트래픽을 가로채고 인터페이스를 표준화하는 설계를 먼저 떠올려야 합니다. 스트랭글러 피그 패턴은 기존 시스템의 외곽에 새로운 인터페이스 계층을 둘러싸고, 특정 도메인 모듈부터 하나씩 신규 서비스로 라우팅을 넘기면서 점진적으로 레거시를 대체해 나가는 아키텍처 기법입니다. 이 방식을 취하면 전체 서비스를 중단하거나 빅뱅 방식의 마이그레이션 위험을 짊어지지 않고도, 기존 자산이 만들어내던 매출과 트래픽을 고스란히 유지한 채 아키텍처를 현대화할 수 있습니다.
엔지니어가 비즈니스 리더십을 설득할 때도 마찬가지입니다. "코드가 낡아서 유지보수가 불가능하니 6개월간 모든 기능 개발을 멈추고 새로 짜겠습니다"라는 보고는 경영진에게 개발팀의 무능과 공백기로 받아들여질 뿐입니다. 반면 "기존 주문 처리 파이프라인의 입출력 규격을 API 게이트웨이로 감싸고, 글로벌 통합 플랫폼과 연결해 다음 분기부터 신규 유통 채널의 트래픽을 즉시 받아내겠습니다"라고 제안하는 엔지니어는 비즈니스 가치를 수배로 증폭시키는 전략적 파트너로 인정받습니다.
분산된 레거시를 묶어내는 공통 인터페이스와 어댑터 계층
서로 다른 14개의 개별 호텔을 하나의 통합 브랜드 네트워크로 편입시키기 위해서는 각 호텔이 제각각 사용하던 로컬 예약 장부와 운영 방식을 글로벌 중앙 예약 시스템(CRS)에 맞물리게 해야 합니다. 소프트웨어 아키텍처에서도 마찬가지입니다. 인수합병이나 서비스 확장으로 인해 서로 다른 언어, 데이터베이스 스키마, 메시지 포맷을 가진 이종 시스템들이 조직 내로 들어올 때, 이를 억지로 단일 데이터베이스로 통합하려 들면 시스템 전체가 마비됩니다.
이때 필요한 아키텍처적 장치가 바로 어댑터(Adapter)와 도메인 추상화 계층입니다. 각 로컬 시스템의 고유한 데이터 모델을 글로벌 플랫폼의 표준 이벤트 포맷으로 변환하는 변환기를 중간에 배치하는 것입니다. 예를 들어 교토 현지 호텔의 룸 인벤토리 시스템이 제각각의 REST API나 심지어 배치 파일 형태로 잔여 객실 데이터를 뱉어내더라도, 중앙의 유통 플랫폼은 이를 카프카(Apache Kafka)와 같은 이벤트 스트림을 통해 표준화된 RoomInventoryUpdated 이벤트로 변환해 소비해야 합니다.
[로컬 레거시 인벤토리] -> (도메인 어댑터 계층) -> [표준화된 이벤트 버스] -> [글로벌 통합 플랫폼]이러한 인터페이스 추상화가 성공적으로 자리 잡으면, 중앙 플랫폼은 하위 시스템이 어떤 프레임워크로 작성되었는지, 온프레미스 서버에서 도는지 클라우드에서 도는지 알 필요가 없어집니다. 인터페이스 규격(Schema Registry)과 계약(API Contract)만 엄격하게 유지된다면, 새로운 레거시 자산이 10개가 추가되든 100개가 추가되든 중앙 플랫폼은 코드 한 줄 수정 없이 새로운 비즈니스 파이프라인을 확장해 나갈 수 있습니다.
이 단계에서 엔지니어의 핵심 역량은 비즈니스 엔티티의 공통 분모를 찾아내는 모델링 감각입니다. 각기 다른 하위 시스템들이 사용하는 용어와 데이터 구조 속에서 핵심 도메인 개념을 정제해야 합니다. 어떤 시스템에서는 Customer, 다른 곳에서는 Guest, 또 다른 곳에서는 Member로 불리는 개념을 중앙의 식별자 체계와 어떻게 맵핑할 것인가, 동시성 예약 충돌이 발생했을 때 분산 락(Distributed Lock)과 낙관적 락(Optimistic Lock) 중 무엇으로 데이터 정합성을 보장할 것인가를 결정하는 작업이 바로 시스템 아키텍트의 영역입니다.
자신이 익숙한 단일 프레임워크 내부의 컨트롤러-서비스-리포지토리 구조를 벗어나, 이종 시스템 간의 데이터 흐름과 결합도를 제어하는 어댑터를 설계할 수 있을 때 엔지니어의 시야는 비로소 거시적인 엔터프라이즈 레벨로 확장됩니다.
플랫폼 거버넌스가 야기하는 현장 운영과의 마찰 비용
어댑터를 붙여 기술적인 연동을 마쳤다고 해서 시스템 전환이 끝나는 것은 아닙니다. 플랫폼 아키텍처 전환에서 가장 큰 실패 요인은 중앙 집중화된 플랫폼 거버넌스와 현장 운영 조직 사이의 마찰 비용을 과소평가하는 데서 발생합니다. GCP 호스피탈리티가 현장의 호텔 운영을 총괄하고 IHG가 글로벌 예약망과 마케팅 플랫폼을 제공하는 구조처럼, 중앙 플랫폼 팀과 현장 도메인 팀 사이에는 필연적으로 권한과 책임의 충돌이 일어납니다.
중앙 플랫폼 엔지니어들은 데이터 표준화, 보안 규정 준수, 배포 파이프라인 통합, 글로벌 식별자 일원화와 같은 거버넌스 원칙을 강제하려 합니다. 반면 현장의 도메인 개발자나 운영 담당자들은 현지 고객의 특수성을 처리하기 위한 예외 규정, 빠른 기능 핫픽스, 레거시 백오피스의 자유도를 요구합니다. 중앙 플랫폼이 현장의 맥락을 무시하고 지나치게 경직된 API 규격과 배포 정책을 밀어붙이면, 현장 팀은 플랫폼을 우회하는 임시 파이프라인을 몰래 구축하기 시작합니다. 이는 결국 플랫폼 도입 이전보다 더 심각한 섀도우 IT와 데이터 정합성 파괴로 이어집니다.
이러한 마찰을 방지하기 위해 플랫폼 엔지니어는 '가드레일은 엄격하게, 확장은 자유롭게'라는 플랫폼 거버넌스 원칙을 세워야 합니다. 인증, 인가, 결제, 통합 로깅과 감사 추적 같은 전사적 보안과 규제 영역은 중앙 게이트웨이에서 단단하게 강제하되, 비즈니스 로직과 UI 표현 계층은 각 도메인 팀이 자유롭게 구성할 수 있는 플러그인 아키텍처를 제공해야 합니다.
또한 플랫폼 전환 과정에서 발생하는 데이터 마이그레이션과 장애 격리 대책을 명확히 세워두어야 합니다. 글로벌 예약 플랫폼에 장애가 발생하더라도 각 현장 호텔의 프런트 데스크 체크인 시스템은 로컬 캐시나 서킷 브레이커(Circuit Breaker)를 통해 독립적으로 정상 동작할 수 있어야 합니다. 중앙 시스템과의 네트워크가 단절되었을 때 로컬에서 오프라인 모드로 트랜잭션을 수용하고, 연결이 복구되었을 때 충돌 해결(Conflict Resolution) 알고리즘을 통해 데이터를 중앙으로 병합하는 비동기 복원력 설계가 갖춰지지 않은 플랫폼은 현장 운영 조직의 신뢰를 얻을 수 없습니다.
현장의 운영 연속성을 해치지 않으면서도 거버넌스를 관철하는 설계 감각, 이것이 바로 책상머리 아키텍트와 현장 중심의 엔지니어링 리더를 가르는 결정적인 차이입니다.
바닥부터 짓는 개발자에서 시스템 가치 승수자로의 전환
이력서에 "처음부터 프레임워크를 직접 구축했습니다"라고 적는 엔지니어는 많습니다. 하지만 "서로 다른 3개의 레거시 시스템을 무중단으로 공통 플랫폼에 통합하고 데이터 파이프라인을 일원화했습니다"라고 말할 수 있는 엔지니어는 드뭅니다. 기술 시장이 성숙해지고 효율성이 최우선 가치로 떠오르는 환경일수록 후자의 경험을 가진 엔지니어의 희소성은 기하급수적으로 높아집니다.
단순히 기능을 만드는 사람은 덧셈의 가치를 만듭니다. 하나의 서비스를 개발하면 하나의 결과물이 나옵니다. 그러나 플랫폼을 구축하고 기존 자산을 연결하는 엔지니어는 곱셈의 가치를 만듭니다. 14개의 독립된 호텔 자산이 글로벌 플랫폼과 결합하는 순간 1억 6,000만 명의 잠재 고객을 즉시 마주하게 되듯, 잘 설계된 공통 플랫폼 위에 올라탄 레거시 서비스들은 이전과는 비교할 수 없는 트래픽 처리량과 비즈니스 확장성을 확보하게 됩니다.
엔지니어로서 자신의 가치와 영향력을 한 단계 도약시키고 싶다면, 내 손으로 직접 모든 코드를 작성하겠다는 통제 욕심을 내려놓아야 합니다. 대신 이미 조직 내에 존재하는 수많은 파편화된 서비스, 외부의 파트너 시스템, 고객과 맞닿아 있는 레거시 파이프라인을 관찰하십시오. 그들이 서로 어떤 병목으로 인해 연결되지 못하고 있는지, 데이터가 어디서 단절되어 비즈니스 기회를 놓치고 있는지를 찾아내는 것이 우선입니다.
내일 출근해서 여러분 팀의 백로그나 코드베이스를 열어보십시오. 완전히 새로운 마이크로서비스를 만들겠다는 계획서 대신, 현재 가장 빈번하게 수동 작업이나 장애를 유발하고 있는 레거시 인터페이스 하나를 찾아내어 표준화된 API 규격과 어댑터로 감싸는 작업부터 시작해 보시기 바랍니다. 기존 자산의 흐름을 표준 플랫폼의 고속도로에 연결하는 그 설계 하나가, 팀의 개발 속도를 높이고 여러분을 대체 불가능한 시스템 통합자로 만들어줄 것입니다.
이 글과 함께 읽으면 좋은 인사이트
댓글 0