2화: 이거 그냥 러스트로 싹 갈아엎죠?





"우선 런북 절차에 따라 오라클 DB의 세션 상태와 스케줄러 큐를 확인했습니다. 외부 연동 응답이 다시 들어오기 시작해 모니터링을 진행하고 있습니다."


한지훈 선배가 모니터 화면의 콘솔 창을 정리하며 차분하게 보고를 마쳤다. 어제 저녁 늦게까지 이어진 1월 정기 배치 장애 조치는 우선 일시적인 정상화 상태로 둔 채 미결 티켓으로 남겨져 있었다.


그러나 내 마음 한구석에서는 답답한 거부감이 가라앉지 않았다.


'런북에 따라 세션을 확인하고 큐를 점검해 일시적으로 돌려놓았다니... 이건 근본적인 원인을 고친 게 아니라 그저 징후만 확인하고 지켜보는 단계잖아. 동기식 호출이 복잡하게 얽힌 자바 레거시 구조를 언제까지 매달 이런 식으로 수동 인계하며 안절부절못할 작정이지?'


대학 시절부터 깐깐한 컴파일 타임 검증을 자랑하는 Rust를 다뤄온 나에게는 이 시스템의 아키텍처가 언제든 다시 휘청일 불안정한 구조로 보였다. 물론 나 역시 DB 트랜잭션 병목이나 네트워크 타임아웃, 비즈니스 로직의 결함까지 프로그래밍 언어 하나로 모두 지워낼 수는 없다는 점 정도는 잘 알고 있었다.


하지만 safe Rust가 선사하는 혜택은 명확했다. 소유권(Ownership)과 빌림 검사(Borrow Checker)는 use-after-free나 안전하지 않은 공유 메모리 접근으로 인한 data race 같은 저수준 메모리 오류 범주를 컴파일 단계에서 확실히 막아준다. 가비지 컬렉션 지연(GC pause)이라는 큰 변수 하나를 떼어낼 수 있고, Result 타입을 활용한 명시적 에러 처리로 예외 누락을 방지할 수 있다. 여기에 마이크로서비스 설계로 독립 실행 바이너리를 나누면 배포 단위 격리와 모듈 간 경계 분리에도 유용했다.


'분산 운영이나 데이터 롤백의 위험성도 서비스 경계만 깔끔하게 분리하고 샌드박스 환경을 구축하면 충분히 통제할 수 있는 요소야. 레거시가 지닌 기술적 부채를 계속 안고 가는 것보다 신규 아키텍처로 전환할 때 얻는 실익이 비교할 수 없을 만큼 큰데...'


나는 기술적 우수성이 운영상의 위험을 상쇄하고도 남는다는 확신에 차 있었다.


다음 날 아침 9시 반, 플랫폼 1팀의 정기 주간 업무 회의가 시작되었다. 팀룸 내부의 회의용 테이블 주위로 박정수 팀장님과 한지훈 선배, 그리고 내가 자리를 잡고 앉았다.


"어제 발생한 한빛상사 정기 연동 장애 건은 런북에 따라 긴급 점검을 마쳤습니다. 다만 1월 전송 구간의 응답 지연 원인은 아직 확정되지 않아, 한빛상사 운영팀과의 미결 티켓으로 남아 모니터링을 계속하는 중입니다."


박정수 팀장님이 주간 안건을 정리하며 차분한 목소리로 입을 열었다. 바로 그때, 나는 가슴속에서 출렁이던 확신을 참지 못하고 손을 들었다.


"팀장님, 어제 장애 건과 관련해 개선 의견을 하나 제안해도 되겠습니까?"


박 팀장님이 나를 바라보며 천천히 고개를 끄덕였다.


"네, 현호 씨. 편하게 이야기해요."


나는 회의실 안의 시선을 느끼며 가슴을 펴고 당당하게 입을 열었다.


"어제 발생한 연동 지연과 매달 반복되는 시스템 불안정의 근본적인 배경에는 Java 8과 Spring Boot 2.1 기반의 비대한 모놀리식 아키텍처가 있습니다. 장애가 터질 때마다 런북 순서대로 세션만 모니터링하는 대처는 임시방편에 불과합니다. 저는 한빛상사 레거시 ERP 시스템 전체를 Rust 기반의 마이크로서비스 아키텍처로 전면 재작성할 것을 제안합니다!"


회의실 안에는 순간 짧은 정적이 흘렀다. 한지훈 선배는 조용히 믹스커피를 한 모금 마시며 나를 가만히 건너다보았다.


나는 내 제안의 정당성을 입증하기 위해 설명을 이어갔다.


"Rust는 컴파일 타임에 소유권과 빌림 검사를 통해 use-after-free나 data race 같은 저수준 메모리 오류 범주를 컴파일 단계에서 확실히 막아줍니다. 가비지 컬렉션 지연(GC pause)이라는 변수를 제거할 수 있고, Result 타입을 통한 명시적 에러 처리로 코드 수준의 예외 누락을 줄여줍니다. 서비스 경계를 정리하고 독립 실행 바이너리로 나누면 모듈 간 결합도를 낮추고 배포 단위를 안전하게 격리할 수 있습니다. 시스템 경계만 제대로 설계한다면 지금처럼 매달 장애 티켓에 매여 수동 대응하는 구조를 개선할 수 있습니다!"


내 설명을 들은 박정수 팀장님은 턱을 괴고 잠시 생각에 잠겼다. 신입 개발자의 뜨거운 열정을 무작정 깎아내리려는 기색은 아니었다. 하지만 잠시 후, 박 팀장님이 던진 질문들은 내가 단순하게 넘겨짚었던 실무의 현실적인 영역이었다.


"현호 씨, Rust라는 언어가 지닌 컴파일 타임 검증과 배포 단위 격리의 장점은 잘 들었어요. 기술적으로 매우 뛰어난 요소들이라는 점은 인정합니다. 하지만 비즈니스와 현장 운영 관점에서 몇 가지 짚고 넘어가야 할 점이 있네요."


박 팀장님이 차분한 눈빛으로 나를 바라보며 말을 이어갔다.


"첫째, 현재 우리 플랫폼 1팀과 SI 사업부 전체를 통틀어, Rust로 백엔드 프로덕션 코드를 작성하고 24시간 장애 발생 시 즉각 핫픽스를 투입할 수 있는 숙련 인력이 현호 씨 외에 얼마나 있죠?"


"그건 제가 내부 스터디를 진행해 팀원분들께 빠르게 공유해 드리면..."


"둘째, 한빛상사와 체결된 현재 유지보수 계약 범위는 기존 Java 8 애플리케이션의 운영 및 유지관리입니다. 전체 시스템을 신규 언어로 전면 재작성할 경우 발생하는 수개월의 개발 공수와 대규모 통합 테스트, 그리고 서비스 전환기 동안의 롤백 병행 운영 예산은 어느 항목에서 집행해야 합니까?"


"그건 근본적인 장애 예방을 위한 투자 관점으로 고객사를 설득하면..."


"셋째, 데이터베이스 경계 분리와 분산 트랜잭션 처리 문제입니다. 기존 데이터의 정합성을 보장하면서 마이크로서비스로 전환하는 과정의 이관 리스크와, 외부 인터넷이 차단된 폐쇄망 환경에서 사내 Nexus 보안 검수를 거쳐 관측성 라이브러리를 확보하고 당직 인수 주체를 세우는 문제는 어떻게 해결할 생각이죠?"


박 팀장님의 묵직한 질문들에 나는 순간 말문이 막혔다. 언어의 우수성과 기술적 완벽함만 바라보던 내 생각 너머로, 현장의 인력 구성과 기술 역량, 유지보수 계약 범위, 데이터 정합성과 폐쇄망 관측성이라는 거대한 벽이 솟아오르는 기분이었다.


바로 그 순간, 회의실 벽면에 설치된 대형 모니터에서 알림음이 울리며 원격 화상 회의 연결이 활성화되었다.


화면 중앙에는 이번 프로젝트의 발주처이자 한빛상사 운영팀을 총괄하는 PM 임동현 부장이 모습을 드러냈다.


"아, 박 팀장님. 공유해 주신 주간 회의에 원격으로 참석해 듣고 있었습니다."


화상 모니터 너머의 임동현 PM은 날카로운 눈빛으로 회의실 안을 둘러보며 입을 열었다.


"새벽기술 측 신입 개발자분께서 시스템 전체의 Rust 전면 재작성을 제안하셨다고 들었습니다만, 저희 한빛상사 운영팀 입장에서는 이 안건을 정식으로 거절하겠습니다."


임 PM의 단호한 선언에 내 가슴이 철렁했다. 임동현 PM은 차분하면서도 명확한 논리로 운영 권한과 리스크의 경계를 짚어 내려갔다.


"첫째, 저희 한빛상사의 핵심 인프라인 Oracle 11g 데이터베이스에는 수년간 쌓여온 트랜잭션 트리거와 스토어드 프로시저, 고유 인덱스와 시퀀스 구조가 복잡하게 얽혀 있습니다. 이는 당사 전산실 DBA의 엄격한 승인과 사전 변경 창구(Change Window) 절차를 거쳐야 하는 영역이며, 위탁 개발자가 임의로 변경할 수 없는 운영 권한의 경계입니다."


나는 화상 화면을 향해 조심스럽게 말을 건넸다.


"PM님, 하지만 기존 레거시 구조를 그대로 두면 동시성 지연과 결합도 문제로 인한 정기 장애를 계속 안고 가야 합니다. 서비스 경계를 정리하고 신규 아키텍처를 도입하면 그 구조적 부담을 줄일 수 있습니다."


내 설명에 임동현 PM은 단호한 태도로 응수했다.


"강현호 씨, 롤백 시나리오와 데이터 이관 정합성이 검증되지 않은 상태에서 대규모 전환을 시도했다가 당사의 24시간 물류 영업망에 장애가 발생할 경우, 그로 인한 영업 손실과 계약상 법적 책임은 새벽기술에서 전적으로 부담할 수 있습니까?"


"그건..."


"저희 한빛상사에 중요한 것은 언어의 기술적 화려함이 아닙니다. 권한 경계가 명확하고, 문제가 발생했을 때 기존 런북과 인력으로 즉시 수습할 수 있는 예측 가능하고 안정적인 운영 체계입니다. 전면 재작성안은 받아들일 수 없으니, 기존 Java 및 Spring 기반 환경 내부에서 원인을 명확히 규명하고 안정화해 주십시오."


임동현 PM의 말을 끝으로 화상 회의 연결이 종료되었다. 모니터 화면이 검게 꺼지자 회의실 안에는 묵직한 정적이 감돌았다.


박정수 팀장님이 서류를 정리하며 나를 향해 나지막하게 입을 열었다.


"현호 씨, 기술적 이점에 대해 고민한 자세는 좋습니다. 하지만 다음 제안 때부터는 단순히 기술의 우수성만 말할 것이 아니라, 서비스 영향 범위, 데이터 이관과 롤백 시나리오, 추가 예산, 그리고 운영 인수 주체와 계약 책임까지 구체적인 문서로 갖추어 가져오도록 하세요."


박 팀장님은 구체적인 업무 가이드를 제시하며 서류를 다듬었다.


"네, 알겠습니다. 팀장님."


나는 정중하게 고개를 숙이며 회의를 마쳤다. 하지만 퇴근길, 사옥 엘리베이터를 내려와 강남대로의 인파 속을 걸어가면서도 가슴속에서는 거센 오기가 식지 않고 있었다.


'결국 비즈니스나 롤백 책임이라는 명분 뒤에 숨어 레거시의 불편함에 안주하려는 거잖아. 기술적 구조가 얼마나 얽혀 있는지 눈으로 직접 확인해보지 못했으니까 저렇게 쉽게 거절하는 거지.'


나는 내 기술적 판단에 대한 자부심을 거두지 않았다. 오히려 현장의 보수적인 태도에 오기가 발동했다.


'말로만 설득하려 해봤자 소용없어. 엔지니어라면 객관적인 메트릭과 구조적 수치로 증명해야 한다. 예전에 개인 프로젝트용으로 만들어둔 Rust 정적 분석 도구가 있지.'


나는 밤공기를 마시며 생각에 잠겼다.


그 도구는 코드베이스의 AST를 파싱하여 모듈 간 의존성 순환, 사이클로매틱 복잡도, 널 가능성이 높은 호출 경로를 수치화해 도식화해 주는 분석 툴이었다.


'내일 출근하면 사내 보안 규정과 운영 절차를 벗어나지 않는 선에서, 이 정적 분석 도구를 사내 레거시 코드베이스에 적용할 방법부터 찾아야겠어. 말뿐인 제안이 아니라 누구도 부정할 수 없는 수치화된 의존성 리포트로 내 주장을 증명해 보이겠어.'




<3화에서 계속됩니다>