"글루 코드(Glue Code)" 위기: 분산 워크플로 오케스트레이션이 어려운 이유

SchemaBridge Team · 2025-12-01 · Distributed Systems, Architecture, DevOps

API 배관 작업에 엔지니어링 시간을 낭비하지 마세요. 2026년 파편화된 시스템을 확장하는 열쇠가 왜 분산 워크플로 오케스트레이션인지 알아보세요.

아키텍처 병목: 소리 없는 생산성 킬러

시니어 개발자나 아키텍트라면 이런 사이클을 겪어보셨을 겁니다. "단순한" 통합, 이를테면 Shopify 주문을 레거시 ERP와 동기화하는 작업으로 시작합니다. 50줄짜리 스크립트를 작성하고, Lambda나 Cron 작업으로 감싸서 배포합니다. 첫날에는 잘 작동합니다. 열흘째에도 잘 작동합니다. 하지만 그다음, 세상이 변합니다. Shopify API에 요청 제한이 추가됩니다. 레거시 ERP는 새벽 2시에 데이터베이스 락 경합을 겪습니다. 타사 배송 프로바이더가 JSON 응답 구조를 변경합니다.

어느샌가 여러분의 "간단한 스크립트"는 미션 크리티컬한 인프라의 일부가 되어버립니다. 하지만 그것은 인프라처럼 만들어지지 않았습니다. 스크립트처럼 만들어졌습니다. 제대로 된 오류 처리가 없고, 상태(state)라는 개념을 이해하지 못하며, 내장된 복원력도 없습니다. 실패할 때는 조용히 실패하거나, 더 나쁘게는 부분적으로 실패하여 데이터를 손상된 상태로 남기고, 이를 고치는 데 며칠간의 수작업이 필요합니다.

석 달 뒤, 그 50줄짜리 스크립트는 5,000줄짜리 괴물로 변이해 있습니다. 이제는 (무한 루프로 형편없이) 재시도를 처리하고, 세 곳의 서로 다른 장소에 로그를 남기며(그중 한 곳은 가득 찼습니다), 진짜 오류를 숨기는 중첩된 try-except 블록을 담고 있습니다. 여러분의 인프라에는 이런 스크립트가 20개나 돌아가고 있습니다. 이들이 바로 조직의 "글루 코드"입니다. 이는 엔지니어링이 아니라 반응적인 배관 작업입니다.

이것이 바로 글루 코드 위기(Glue Code Crisis)입니다. 이는 엔지니어링 속도를 소리 없이 죽이는 살인자입니다. 여러분은 더 이상 비즈니스에 실질적인 변화를 가져오는 기능을 만들고 있지 않습니다. 데이터를 흘리고, 부하 속에서 막히고, 새벽 3시에 터져서 최고의 엔지니어들을 깨우는 호출 알림을 발생시키는 취약한 "파이프"를 만들고 유지보수하고 있을 뿐입니다. 파편화된 마이크로서비스와 끝없는 SaaS API의 세계에서, 영속적 오케스트레이션 전략이 없다면 여러분은 사실상 빨리 마르는 시멘트 위에 집을 짓고 있는 셈입니다. 일주일 동안은 견고해 보이지만, 균열은 필연적입니다.

위기의 역사적 뿌리: CGI-BIN에서 클라우드까지

우리가 왜 이러한 위기에 처했는지 이해하려면, 소프트웨어 통합의 역사를 살펴봐야 합니다. 1990년대에는 CGI 스크립트와 Perl이 있었습니다. 이들은 요청을 응답으로 변환하는 작고 상태 없는(stateless) 명령이었습니다. 이들이 원조 "글루 코드"였습니다. 당대에는 훌륭했지만, 현대 디지털 비즈니스의 다단계, 다일 단위 여정을 처리하도록 만들어진 것은 결코 아니었습니다. 이들은 아직 상시 가동되고 전 세계적으로 연결되지 않았던 세상에서 "쏘고 잊어버리는(fire and forget)" 도구였습니다.

2000년대에는 Tibco나 BizTalk 같은, 거대하고 무거운 미들웨어인 ESB(Enterprise Service Bus)로 옮겨갔습니다. 이들은 강력했지만 대단히 복잡하고 비쌌습니다. 모든 것을 중앙화하려고 시도했고, 결과적으로 "버스 아키텍트"라는 병목을 낳았습니다. 모든 변경 사항에는 위원회 회의가 필요했습니다. 버스는 자신이 해결하려던 바로 그 문제, 즉 단일 장애점(single point of failure)이자 조직 마찰의 거대한 원천이 되어버렸습니다.

2010년대에는 ESB를 거부하고 마이크로서비스를 택했습니다. 우리는 REST API와 경량 스크립트(Python, Go, Node.js)로 옮겨갔습니다. 우리는 자유를 얻었다고 생각했습니다. 하지만 실제로 우리가 한 일은 복잡성을 "버스"에서 "서비스 사이의 공간"으로 옮긴 것뿐이었습니다. 우리는 단일하고 무거운 미들웨어를, 환경 전체에 흩어진 수천 개의 작고 취약한 스크립트로 대체했습니다. 이제 우리는 복잡성이 서비스 수에 비례해 O(N^2)가 되는 세상에 살고 있습니다. 우리는 중앙화된 병목을 탈중앙화된 혼돈과 맞바꾼 것입니다.

스크립트의 심리학: 우리가 계속 취약한 경로를 선택하는 이유

우리는 왜 계속 스크립트를 작성할까요? 분산 시스템의 함정을 잘 아는 시니어 엔지니어들조차 "영속적 오케스트레이터" 대신 "빠른 스크립트"에 자주 손을 뻗습니다. 그 이유는 심리적입니다.

1. "빠른 승리"의 오류

비즈니스 이해관계자가 새로운 통합을 요청할 때, 그들은 그것을 "어제" 원합니다. 스크립트는 빠르게 느껴집니다. 한 시간 만에 작성할 수 있습니다. 생산적이라는 느낌이 듭니다. "체크박스에 표시"를 합니다. 하지만 이는 거짓 생산성입니다. 여러분은 미래의 역량에 대해 고금리 대출을 받고 있는 셈입니다. 오늘 4시간을 절약하지만, 다음 달에는 프로덕션에서의 부분적 실패를 디버깅하느라 40시간을 쓰게 됩니다. 스크립트는 장기적 안정성보다 단기적 지표를 중시하는 엔지니어링 매니저들에게 중독성 있는 마약입니다.

2. 분산 시스템의 더닝-크루거 효과

많은 개발자가 "재시도는 쉽다"고 믿습니다. API 호출을 sleep 타이머가 있는 while 루프로 감싸는 것만으로 충분하다고 생각합니다. 이들은 진짜 프로덕션 환경에서 발생하는 재시도 폭풍, 고아가 된 ID(Orphaned Identity), 또는 상태 손상(State Corruption)을 아직 경험해보지 못했습니다. 이들은 실패를 다룰 수 있는 자신의 능력에 대해 "과장된 기대의 정점"에 있는 것입니다. 새벽 3시에 첫 번째 대규모 장애를 겪고 나서야, 분산 상태가 인프라 수준의 해결책을 필요로 하는 문제라는 것을 깨닫게 됩니다.

3. 더 나은 작업 단위의 부재

최근까지 우리는 오케스트레이션을 위한 표준 작업 단위가 없었습니다. "함수(Functions)"와 "서비스(Services)"는 있었지만, "여정(Journeys)"은 없었습니다. SchemaBridge는 이러한 작업 단위로서 영속적 워크플로(Durable Workflow)를 도입합니다. 이는 여러분이 다단계 여정을 머신 장애, 네트워크 분할, 심지어 인간의 실수까지도 견뎌내는 단일하고 영속적인 개체(entity)로 표현할 수 있게 해줍니다.

실패의 해부: "스크립트"가 확장되지 않는 이유

10명의 사용자에게는 잘 작동하는 스크립트가 10,000명에서는 실패합니다. 이는 분산 시스템의 본질에 내재된 세 가지 주된 이유 때문입니다. 우리는 이러한 문제를 "더 나은 코드"만으로는 해결할 수 없습니다. 인프라로 해결해야 합니다.

1. 부분 성공 문제: "어중간하게 완료된" 상태

분산 시스템에서 성공은 이분법적이지 않습니다. 스크립트가 세 단계를 수행한다고 해봅시다: 1) Stripe로 고객에게 결제 청구. 2) 내부 재고 데이터베이스 업데이트. 3) SendGrid로 확인 이메일 발송. 1단계 이후에 프로세스가 크래시하면 어떻게 될까요?

고객에게는 결제가 청구되었지만, 재고는 여전히 "재고 있음"으로 표시되어 있고, 사용자에게는 영수증이 없습니다. 이를 순수한 코드로 해결하려면 복잡한 사가 패턴(Saga Patterns)을 수동으로 작성해야 합니다. 사실상 스크립트 하나하나마다 미니 오케스트레이터를 작성하는 셈입니다. 결제가 실제로 이루어졌는지 확인하고, 재고 상태를 확인하고, 롤백을 처리해야 합니다. 이러한 보일러플레이트는 개발 시간의 80%를 차지하며, 분산 상태는 어렵기 때문에 그럼에도 여전히 20%는 잘못 처리하게 됩니다.

2. 멱등성 격차: 재시도의 위험성

연결은 불안정합니다. 스크립트가 API로부터 타임아웃을 잡아내고 재시도합니다. 하지만 만약 API가 실제로는 성공했고, 단지 응답만 타임아웃된 것이라면 어떨까요? 멱등성(Idempotency) 없이는, 재시도가 이중 청구나 중복 배송으로 이어집니다. 대부분의 "글루 코드" 개발자들은 고객에게 500달러 대신 5,000달러가 청구되는 첫 사건이 벌어지기 전까지는 이를 무시합니다.

수십 개의 서비스에 걸친 모든 API 호출에 멱등성 키를 추가하는 것은 몇몇 팀만이 일관되게 관리할 수 있는 물류적 부담입니다. 통합이 100개라면, 키를 잊어버릴 수 있는 지점도 100군데입니다. 진정한 오케스트레이션 엔진은 이를 인프라 수준에서 처리하며, 워크플로 컨텍스트를 기반으로 이러한 키를 자동으로 생성하고 관리합니다.

여덟 가지 오류: 실패를 위한 토대

글루 코드가 왜 실패하는지 제대로 이해하려면, Peter Deutsch를 비롯한 Sun Microsystems의 여러 사람들이 처음 명문화한 분산 컴퓨팅의 여덟 가지 오류(Eight Fallacies of Distributed Computing)로 돌아가야 합니다. 이는 모든 개발자가 네트워크 코드를 처음 작성할 때 하게 되는 잘못된 가정들입니다. 엔지니어링의 "거짓 천국"입니다.

1. 네트워크는 안정적이다: 그렇지 않습니다. 패킷은 유실되고, 라우터는 재부팅되며, 케이블은 절단됩니다. 클라우드 환경에서는 대규모에서 매일같이 간헐적인 네트워크 장애가 발생할 것으로 예상해야 합니다.

2. 지연 시간은 0이다: 그렇지 않습니다. 가장 빠른 글로벌 광섬유 네트워크조차 수천 번의 호출에 걸쳐 누적되는 밀리초 단위의 지연을 유발합니다. 이 지연은 지터가 있고 예측할 수 없어, 로컬에서 디버깅하려고 하면 사라지는 경쟁 조건을 유발합니다.

3. 대역폭은 무한하다: 그렇지 않습니다. 큰 페이로드는 파이프를 막고 타임아웃을 유발합니다. 클라우드 프로바이더 역시 엄격한 대역폭 할당량을 두어 여러분의 "글루 코드"를 예고 없이 스로틀링할 것입니다.

4. 네트워크는 안전하다: 그렇지 않습니다. 중간자 공격(Man-in-the-middle), DNS 포이즈닝, 유출된 토큰은 끊임없는 위협입니다. 여러분의 "글루 코드" 스크립트는 적절히 격리되지 않으면 자격 증명 탈취의 주요 표적이 됩니다.

5. 토폴로지는 변하지 않는다: 변합니다. 로드 밸런서는 옮겨가고, 노드는 죽으며, IP 주소는 재활용됩니다. 여러분의 스크립트에 하드코딩된 IP는 시한폭탄입니다.

6. 관리자는 한 명뿐이다: 존재하지 않습니다. 여러분은 AWS, Cloudflare, 그리고 스택 안의 모든 SaaS 프로바이더의 처분에 달려 있습니다. 이들이 API를 변경하면, 여러분의 스크립트가 첫 번째 희생양이 됩니다.

7. 전송 비용은 0이다: 그렇지 않습니다. 대규모로 JSON을 직렬화/역직렬화하는 데는 실질적인 CPU와 메모리 비용이 듭니다. 여러분의 Python 스크립트는 시간의 40%를 그저 json.loads()에 쓰고 있습니다.

8. 네트워크는 동질적이다: 그렇지 않습니다. 여러분의 스택은 Linux, Windows, JVM, Node, 레거시 SOAP 서비스가 뒤섞여 있습니다. 이 환경 전반에 걸쳐 일관된 동작을 기대하는 것은 착각입니다.

기술 심층 분석: 이벤트 소싱과 DynamoDB의 확장성

영속적 오케스트레이션 엔진을 구축할 때 가장 어려운 부분 중 하나는 상태의 영속화(Persistence of State)를 관리하는 것입니다. 10만 개의 워크플로가 동시에 실행 중이고, 각 워크플로가 10단계를 수행한다면, 몇 분마다 100만 건의 데이터베이스 쓰기가 발생하게 됩니다.

DB 병목

전통적인 관계형 데이터베이스(Postgres, MySQL)는 결국 이 부하 아래에서 무너지게 됩니다. workflow_history 테이블의 인덱스 경합이 주된 병목이 됩니다. SchemaBridge는 영속화 파티셔닝(Persistence Partitioning)을 사용해 이를 해결합니다.

1. 워크플로 ID별 파티셔닝: 우리는 서로 다른 워크플로의 이력을 표준 NoSQL 스토리지(DynamoDB)에 분산시킵니다. 이는 단일 파티션이 전역 트래픽의 전체 무게를 짊어지지 않도록 보장합니다. 특정 워크플로에 대한 모든 이벤트는 동일한 파티션에 기록되어, 해당 특정 여정에 대해 강한 일관성을 제공합니다.

2. 추가 전용 실행 로그: 우리는 성능 경로에서 워크플로 레코드를 절대 "업데이트"하지 않습니다. 이벤트 소싱 패턴을 사용해 새로운 이벤트를 이력에 추가(append)할 뿐입니다. 이는 쓰기 작업을 매우 효율적이고 충돌 없는 연산으로 바꿔줍니다. 또한 모든 행동에 대한 불변 감사 추적을 제공합니다.

3. 이벤트 재생: 워커가 워크플로를 처리할 때, 이벤트 이력을 재생하여 상태를 재구성합니다. 이는 크래시와 재시작 이후에도 메모리상의 상태가 항상 영속적인 진실과 일치하도록 보장합니다.

거버넌스 격차: 배관은 누구의 것인가?

기술적 과제 너머에는 문화적 과제가 있습니다: 거버넌스 격차(Governance Gap). 전통적인 마이크로서비스 아키텍처에서는 소유권이 사일로화되어 있습니다. "제품 서비스" 팀은 제품 데이터베이스를 소유합니다. "배송 서비스" 팀은 FedEx 통합을 소유합니다.

하지만 이들 사이의 다리(Bridge)는 누가 소유할까요?

대개는 아무도 소유하지 않습니다. "글루 코드" 스크립트는 빠른 수정이 필요한 개발자가 작성하고, 그 후 방치됩니다. 이것이 고장 나면, 제품 팀은 배송 팀을 탓하고, 배송 팀은 API 프로바이더를 탓합니다. 비즈니스 프로세스가 실제로 어떻게 연결되어 있는지에 대한 중앙 "진실의 원천(Source of Truth)"이 존재하지 않습니다.

SchemaBridge는 통합을 전사적 자산(Global Asset)으로 만듦으로써 이 문제를 해결합니다.

생물학적 은유: 신경계로서의 소프트웨어

우리는 소프트웨어가 더 이상 정적인 도구들의 집합이 아니라 살아있는 신경계(Living Nervous System)가 되어가는 세상으로 나아가고 있습니다. 생물학적 신경계에서 신호는 손가락(센서)에서 뇌(로직)로 이동한 뒤 근육(행동)으로 되돌아갑니다. 경로의 일부가 차단되면 시스템은 적응합니다. 반사가 있습니다. 기억이 있습니다.

영속적 오케스트레이션은 기업의 신경계입니다. 이는 파편화된 서비스들이 마치 하나의 응집력 있는 유기체처럼 느껴지도록 해줍니다.

1. 반사: 자동 재시도는 뇌(개발자)를 개입시키지 않고도 작은 "고통"(타임아웃)을 처리합니다. 시스템은 자동으로 스스로를 부상으로부터 보호합니다.

2. 기억: 영속적 지속성은 전체 시스템이 "기절"하더라도(클러스터 전체 장애) 정확히 무엇을 하고 있었는지 기억하고 깨어난 후 그 지점부터 이어간다는 것을 보장합니다. 모든 생각이 안정적인 저장소에 저장됩니다.

3. 인지: 시각적 관측 가능성(8부 참고)을 통해 실시간으로 조직의 정확한 "맥박"을 확인할 수 있습니다. 오류의 로그와 성공의 흐름을 실시간으로 볼 수 있습니다.

사례 연구: 5,000만 달러 규모의 대사(Reconciliation) 붕괴

이 위기의 심각성을 이해하기 위해, 우리가 최근 협업한 핀테크 기업의 사례를 살펴봅시다. 그들은 내부 원장과 여러 은행 파트너 사이의 일일 거래를 대사(reconcile)하기 위해 대량의 Python 스크립트를 사용했습니다.

장애

어느 금요일, 은행 파트너가 SFTP 서버의 암호화 설정을 업데이트했습니다. Python 스크립트는 크래시하지 않았습니다. 단지 연결에 실패했고, 예외를 잡아냈으며, 그날의 대사 상태를 "조용히" "대기 중"으로 표시했습니다. 시각적 대시보드가 없었기 때문에, 이 장애는 3일 동안 알아채지지 못했습니다.

월요일이 되자, 그 불일치는 5,000만 달러까지 불어나 있었습니다. 재무 감사관에게 호출이 갔고, CEO에게 보고되었으며, 엔지니어링 팀은 대사 타임라인을 수작업으로 재구축하는 데 꼬박 일주일을 써야 했습니다. 스크립트는 "정상 경로"에서는 완벽하게 작동했지만, "자가 치유" 능력도, "시각적 진실"도 전혀 없었습니다.

SchemaBridge로의 마이그레이션

이 재난 이후, 그들은 대사 로직을 SchemaBridge로 이전했습니다. 그 차이는 하늘과 땅이었습니다. 6개월 후 유사한 연결 문제가 발생했을 때, 게이트웨이 버텍스는 즉시 지속적인 실패를 겪었습니다. 대시보드가 빨갛게 변했습니다. Slack 알림이 발동했습니다. 엔지니어링 팀은 2분 이내에 실패를 확인했습니다. 그들은 구성을 수정하고 "재개"를 클릭했으며, 아무도 눈치채기 전에 회사의 재무적 진실이 복원되었습니다.

오류 없는 오케스트레이션을 위한 추천 자료

영속적 실행의 기술을 마스터하고 싶다면, 다음과 같이 엄선한 읽을거리를 추천합니다.

결론: 아키텍트의 새로운 사명

글루 코드 위기는 전환의 증상입니다. 우리는 "사일로와 스크립트"의 세계에서 "연결된 생태계(Connected Ecosystems)"의 세계로 이동하고 있습니다. 이 새로운 세계에서는 서비스 간의 연결이 서비스 자체만큼이나 중요합니다.

아키텍트로서 여러분의 사명은 더 이상 신뢰할 수 있는 서비스를 구축하는 것에 그치지 않습니다. 신뢰할 수 있는 연결(Reliable Connections)을 구축하는 것입니다. 글루 코드는 신뢰성의 정반대입니다. 그것은 필연적으로 영구적인 부담이 되는 임시방편입니다. 이제는 취약한 파이프를 만드는 것을 멈추고 디지털 신경계를 구축할 때입니다.

SchemaBridge와 같은 영속적 오케스트레이션 엔진을 도입함으로써, 여러분은 엔지니어링의 미래를 되찾게 됩니다. 여러분은 자신의 상태를 인지하고, 실패에 회복력을 가지며, 조직 전체에 가시화되는 시스템을 구축하게 됩니다. 이것이 바로 속도를 되찾고 오래 지속되는 시스템을 구축하는 방법입니다.

이 글은 "다리 놓기(Building the Bridge)"라는 15부작 시리즈의 1부입니다. 다음 주에는 2부 "속도를 위한 설계(Designing for Velocity)"에서 스키마 없는(Schema-less) 이벤트 수집의 힘과 지연 바인딩(late-binding) 혁명을 탐구합니다.

살펴보기