POOOLING FOREST
37바이트 메모리의 추억과 API 호환성 지옥에서 살아남기 - 1978년 레트로 콘솔 Interton VC 4000의 37바이트 메모리와 물리적 호환성 이슈를 통해 현대
Engineering & Tech

37바이트 메모리의 추억과 API 호환성 지옥에서 살아남기

1978년 레트로 콘솔 Interton VC 4000의 37바이트 메모리와 물리적 호환성 이슈를 통해 현대 MSA 환경의 API 통합 문제를 분석하고 얻은 인사이트를 공유합니다.

김영태

테크리드

안녕하세요. 풀링포레스트 테크리드 김영태입니다.

얼마 전, 레트로 하드웨어 역사를 뒤적이다가 흥미로운 물건을 하나 발견했습니다. 1978년에 독일의 보청기 제조사 'Interton'에서 출시한 Interton Video Computer 4000이라는 콘솔입니다. 보청기 회사가 게임기를 만들었다는 사실도 재미있지만, 제가 주목한 건 이 기기가 가진 독특한 '호환성' 이슈였습니다. 이게 묘하게도 요즘 우리가 MSA(마이크로서비스 아키텍처) 환경에서 겪는 API 통합 문제와 너무나 닮아 있더군요. 오늘은 이 오래된 하드웨어 이야기를 빌려, 최근 우리 팀이 겪었던 트러블슈팅 경험을 나눠보려 합니다.

이 콘솔의 스펙을 보면 지금 기준으로는 상상도 안 되는 수치가 나옵니다. CPU는 Signetics 2650A를 썼고, 데이터 메모리는 고작 37바이트였습니다. 37킬로바이트도, 메가바이트도 아닌 그냥 37바이트요. 요즘 우리는 JSON 응답 하나만 내려줘도 수백 바이트는 우습게 쓰는데, 당시 개발자들은 그 공간 안에서 'Tank Battle'이나 'Invaders' 같은 게임의 상태를 관리해야 했습니다. 리소스 낭비가 심한 요즘의 클라우드 인프라 운영 방식을 뼈저리게 반성하게 만드는 대목입니다.

하지만 진짜 이야기는 하드웨어 파편화에 있습니다. VC 4000은 1292 Advanced Programmable Video System이라는 계열에 속하는데, 이 계열의 콘솔들은 소프트웨어적으로는 서로 호환이 됩니다. 즉, 게임 코드는 똑같다는 뜻이죠. 그런데 제조사마다 카트리지 슬롯의 모양이나 규격을 미묘하게 다르게 만들었습니다. 알맹이(소프트웨어)는 같은데, 껍데기(인터페이스)가 달라서 A사 기계의 팩을 B사 기계에 꽂을 수가 없는 상황이 벌어진 겁니다.

솔직히 이 대목을 읽으면서 며칠 전 배포 상황이 떠올라 식은땀이 흘렀습니다.

최근 저희 팀은 레거시 시스템을 쪼개면서 새로운 결제 정산 서비스를 런칭했습니다. 서비스 A와 서비스 B가 통신해야 하는데, 로컬 테스트 환경에서는 아무 문제가 없었습니다. Swagger 문서상으로도 요청 필드와 응답 타입이 완벽하게 일치했고요. '소프트웨어 호환성'은 확보된 상태였던 셈입니다.

그런데 막상 스테이징 환경에 배포하자마자 500 Internal Server Error가 쏟아졌습니다. 로그를 까보니, 게이트웨이 단에서 헤더(Header) 처리 방식이 미묘하게 달랐던 게 원인이었습니다. 로컬에서는 허용되던 커스텀 헤더 형식이, 실제 운영 인프라의 보안 정책(WAF)과 맞물리면서 거부당하고 있었던 겁니다. 마치 VC 4000의 게임 카트리지가 내용은 똑같은데 슬롯 모양이 안 맞아서 안 들어가는 것처럼 말이죠.

막막했습니다. 코드는 완벽하다고 생각했으니까요. 우리는 비즈니스 로직(게임)에만 집중하느라, 그 로직이 담길 컨테이너와 네트워크라는 물리적 규격(카트리지 슬롯)의 차이를 간과했던 겁니다. 결국 팀원들과 밤을 새우며 인프라 레벨의 설정을 하나하나 뜯어보고 나서야 문제를 해결할 수 있었습니다.

이 경험을 통해 우리는 '논리적 호환성'과 '물리적 호환성'을 철저히 구분해야 한다는 걸 배웠습니다.

  1. 계약(Contract)은 코드 이상이다: API 스펙만 맞춘다고 끝이 아닙니다. 실제 패킷이 오가는 네트워크 환경, 헤더의 대소문자 처리, 타임아웃 설정 같은 '물리적 슬롯'의 모양까지 맞춰야 진짜 호환입니다.

  2. 리소스에 대한 겸손함: 37바이트로 게임을 만들던 시절을 생각하며, 무분별하게 늘어나는 파드(Pod)의 메모리 리밋을 다시 점검했습니다. "클라우드니까 괜찮아"라는 생각이 우리 시스템을 비만으로 만들고 있었으니까요.

Interton VC 4000은 1983년에 단종됐지만, 그들이 겪었던 호환성 문제는 40년이 지난 지금도 클라우드 어딘가에서 다른 형태로 반복되고 있습니다. 혹시 여러분도 지금 "로컬에선 되는데 왜 배포하면 안 되지?"라는 말을 하고 계신가요? 그렇다면 코드 밖의 세상, 즉 여러분의 서비스가 꽂혀야 할 '슬롯'의 모양을 한번 살펴보시기 바랍니다.

기술은 변해도 엔지니어링의 본질적인 고민은 돌고 도는 법이니까요. 오늘도 호환성 지옥에서 고군분투하는 모든 개발자분들을 응원합니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.