POOOLING FOREST
지하 광산의 서류더미를 클라우드로: 기술적 부채와 결단에 대하여 - 미국 연방 인사 관리처(OPM)의 지하 광산 서류 시스템 현대화 사례를 통해, 기술적 부채를 직시하고 과감한
Case Studies

지하 광산의 서류더미를 클라우드로: 기술적 부채와 결단에 대하여

미국 연방 인사 관리처(OPM)의 지하 광산 서류 시스템 현대화 사례를 통해, 기술적 부채를 직시하고 과감한 결단을 내리는 엔지니어링 정신의 중요성을 살펴봅니다.

송찬영

CTO

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

오늘은 조금 충격적이면서도, 엔지니어라면 누구나 가슴 한켠이 뜨거워질 만한 이야기를 해보려 합니다. 최근 미국의 연방 인사 관리처(OPM)가 수십 년 묵은 퇴직 처리 시스템을 현대화한 사례를 접했습니다. 처음 이 이야기를 들었을 때, 저는 단순한 비유인 줄 알았습니다. "지하 광산에 서류가 쌓여 있다"는 표현 말이죠. 그런데 그것은 비유가 아니었습니다. 실제로 펜실베이니아의 옛 석회암 광산 지하 230피트(약 70미터) 아래, 2만 6천 개의 캐비닛에 4억 건이 넘는 종이 서류가 보관되어 있다는 사실을 알게 되었을 때, 저는 묘한 전율과 함께 깊은 탄식을 내뱉었습니다.

이 시스템은 말 그대로 '관료제의 싱크홀'이었습니다. 연방 공무원이 퇴직하면, 그들의 기록을 찾기 위해 누군가 물리적으로 광산에 들어가 서류를 꺼내야 했습니다. 이 과정 때문에 퇴직자들은 연금을 받기까지 평균 6개월을 기다려야 했고, 그동안 재정적 불안에 시달려야 했습니다. 우리 개발자들이 흔히 말하는 '레거시(Legacy)'가 코드가 아니라, 물리적인 종이 더미로 존재하는 극단적인 형태였던 셈이죠.

흥미로운 점은 정부가 이 문제를 해결하기 위해 손을 놓고 있었던 게 아니라는 사실입니다. 지난 수십 년간 수천억 원의 세금을 들여 전산화를 시도했지만 번번이 실패했습니다. 가장 최근의 시도는 마이크로소프트의 'PowerApps'라는 노코드(No-code) 툴을 활용하는 것이었습니다. 개발자가 부족하니 쉽게 앱을 만들 수 있는 도구를 선택한 것이었겠죠. 하지만 결과는 처참했습니다. 복잡한 퇴직 로직을 노코드 툴로 구현하는 것은, 100층짜리 마천루를 레고 블록으로 짓는 것과 같았습니다. 5MB가 넘는 파일은 업로드조차 할 수 없었고, UI는 90년대 웹사이트에 머물러 있었습니다. 현장의 개발자들은 이 도구가 너무 불편해서 손대기조차 두려워하는 상황이었습니다.

여기서 투입된 두 명의 엔지니어, Yat Choi와 Dennis Li가 내린 결단이 저에게 큰 울림을 주었습니다. 그들은 기존에 진행되던 7년짜리 프로젝트와 PowerApps 기반의 개발을 전면 중단했습니다. 대신, 현대적인 웹 기술 스택을 사용하여 처음부터 다시 시스템을 구축하기로 결정했습니다.

이것은 엄청난 용기가 필요한 일입니다. 조직 생활을 해본 분들은 아실 겁니다. 이미 예산이 집행되었고, 고위층에 보고가 끝난 프로젝트를 "이건 틀린 방향입니다"라고 말하며 뒤집는 것이 얼마나 어려운지를요. 흔히 말하는 '매몰 비용(Sunk Cost)'의 함정에서 빠져나오는 것은 논리보다 정치적, 심리적 압박이 더 큰 문제입니다. 하지만 그들은 "기존 방식을 고수하면 절대 성공할 수 없다"는 것을 냉철하게 직시했습니다.

그들은 단 몇 주 만에 `retire.opm.gov`라는 새로운 플랫폼을 만들어냈습니다. 그리고 반년이 걸리던 처리를 거의 실시간으로 단축시켰습니다. 비결은 마법 같은 신기술이 아니었습니다. 그저 개발자 생태계에서 널리 쓰이는, 검증된 표준 웹 기술을 사용했을 뿐입니다. 이를 통해 유지보수가 쉽고, 확장이 가능하며, 무엇보다 사용자(퇴직자)에게 존엄성을 돌려줄 수 있는 서비스를 만들었습니다.

풀링포레스트에서 일하는 우리에게도 시사하는 바가 큽니다. 우리에게도 우리만의 '지하 광산'이 있습니다. 당장의 편의를 위해 작성한 스파게티 코드, 수동으로 관리되는 엑셀 시트, 혹은 "나중에 고치자"며 미뤄둔 배포 스크립트들이 그것입니다. 때로는 노코드 툴이나 특정 솔루션이 만능열쇠처럼 보일 때도 있습니다. 하지만 문제의 본질(Why)을 꿰뚫지 못한 도구 선택은 결국 더 큰 부채로 돌아옵니다.

기술적 의사결정의 핵심은 '무엇을 더하느냐'가 아니라 '무엇이 문제의 본질인가'를 파악하는 데 있습니다. OPM의 사례에서 보듯, 진정한 혁신은 화려한 기술 도입이 아니라, 비효율을 직시하고 그것을 과감히 끊어내는 용기에서 시작됩니다.

저 또한 CTO로서 스스로에게 되묻습니다. 우리가 지금 붙잡고 있는 레거시가, 단지 "지금까지 해왔으니까"라는 이유로 유지되고 있는 것은 아닐까? 두려움 때문에 혁신을 미루고 있는 '광산'은 어디일까?

변화는 기술이 아니라 태도에서 옵니다. 오늘 하루, 여러분의 코드가, 그리고 여러분의 결정이 누군가의 6개월을 1초로 단축시키는 기적의 씨앗이 되기를 응원합니다.

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

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