스타트업에서 '야생형 개발자'로 지내던 시절, 저는 "코드가 돌아가기만 하면 장땡"이라는 생각으로 살았습니다. 하지만 트래픽이 몰리는 대기업 환경으로 넘어오면서, 그 안일한 생각은 산산조각 났습니다. 분산 환경에서의 동시성 문제, 데이터 정합성 깨짐, 그리고 알 수 없는 레이턴시 튀는 현상들은 밤잠을 설치게 만들었습니다. 그러다 저는 '정형 기법(Formal Methods)'이라는 구원자를 만났습니다. TLA+나 P 같은 도구를 통해 시스템의 논리적 결함을 수학적으로 증명할 수 있다는 사실은 충격적이었습니다. 드디어 완벽한 시스템을 만들 수 있을 것 같았습니다. 하지만 최근 AWS의 Marc Brooker가 쓴 글을 읽으며 저는 다시 한번 망치로 머리를 맞은 듯한 기분을 느꼈습니다. 논리적으로 완벽한 코드가 비즈니스적으로는 완전히 실패작일 수 있다는 사실을 뼈저리게 깨달았기 때문입니다.
정형 기법은 분명 강력합니다. TLA+와 같은 명세 언어는 우리가 설계한 분산 프로토콜에서 발생할 수 있는 'Safety(나쁜 일이 발생하지 않음)'와 'Liveness(좋은 일이 결국 발생함)'를 검증해 줍니다. 저 역시 MSA 환경에서 결제 모듈의 상태 머신을 설계할 때, 이 도구들이 주는 확신에 매료되었습니다. 데이터 손실이나 교착 상태(Deadlock) 같은 치명적인 버그를 코딩 전에 잡아낼 수 있다는 건 축복과도 같으니까요. 하지만 Marc Brooker는 냉정하게 지적합니다. "정형 기법은 내 문제의 절반만 해결해 줄 뿐이다."라고 말이죠. 우리가 마주하는 문제는 단순히 '시스템이 멈추지 않는가'에 그치지 않습니다. 고객이 체감하는 응답 속도(Latency), 이 시스템을 운영하는 데 드는 클라우드 비용, 그리고 트래픽이 폭주할 때의 가용성 같은 '비기능적 요구사항'들이 나머지 절반, 아니 어쩌면 그 이상을 차지하기 때문입니다.
현실의 엔지니어링은 "이 설계가 올바른가?"를 넘어 "이 설계가 얼마나 효율적인가?"를 묻습니다. 예를 들어, 네트워크 지연 시간이 두 배로 늘어날 때 전체 트랜잭션 처리량(Throughput)은 어떻게 변할까요? 데이터 복제본(Replica)을 3개에서 5개로 늘리면 내구성은 좋아지겠지만, 그로 인한 쓰기 지연과 인프라 비용 증가는 감당할 수 있는 수준일까요? 정형 기법은 이 질문에 답해주지 않습니다. 우리는 여전히 이 답을 찾기 위해 막대한 리소스를 들여 프로토타입을 만들고, 실제와 유사한 부하를 주어 벤치마킹을 돌리는 '삽질'을 반복합니다. 혹은 엑셀 시트에 의존한 부정확한 닫힌 모델링(closed-form modelling)으로 위안을 삼곤 합니다. 저 또한 설계 단계에서 성능을 예측하지 못해, 배포 후에야 비싼 인스턴스 비용을 청구 받고 부랴부랴 코드를 뜯어고쳤던 부끄러운 기억이 있습니다.
우리가 진정으로 필요로 하는 것은 논리적 정합성뿐만 아니라, 성능 특성까지 시뮬레이션할 수 있는 도구입니다. Marc Brooker가 제안하는 이상적인 도구는 정형 명세(Formal Specification)에 실제 네트워크 지연, 패킷 손실률, 사용자 워크로드 같은 파라미터를 입력하여 시뮬레이션을 돌릴 수 있는 형태입니다. 이를 통해 "네트워크 지연을 10ms 줄이면 고객 이탈률에 어떤 영향을 미칠까?" 같은 질문에 대해 정량적인 답을 내놓을 수 있어야 합니다. 현재 우리는 몬테카를로(Monte Carlo) 시뮬레이션 같은 기법을 알음알음 사용하고 있지만, 이를 시스템 설계의 표준 도구로 통합해서 사용하는 경우는 드뭅니다. 대부분은 "넷플릭스가 이렇게 하더라", "요즘은 이게 트렌드(Best Practice)래" 같은 카더라 통신이나 과거의 관습에 의존하여 설계를 결정합니다. 솔직히 말해, 이는 엔지니어링이라기보다 주술에 가깝습니다.
결국, 좋은 엔지니어는 '코드를 잘 짜는 사람'을 넘어 '설계를 증명하고 예측하는 사람'이 되어야 합니다. 주니어 시절에는 기능 구현에 급급했지만, 연차가 찰수록 저는 '정량적 설계(Quantitative Design)'의 중요성을 절감합니다. 단순히 논리적으로 오류가 없다는 것을 넘어, 이 시스템이 비즈니스 목표를 달성하기 위해 얼마나 많은 자원을 소모할지, 최악의 시나리오에서 어떤 성능을 보여줄지 숫자로 이야기할 수 있어야 합니다. 정형 기법으로 논리를 다지고, 시뮬레이션으로 성능을 예측하는 것. 이 두 가지 축이 맞물려야만 비로소 우리는 '운'이 아닌 '실력'으로 시스템을 통제할 수 있습니다. 막연한 감이나 유행이 아닌, 치밀한 검증과 예측으로 무장한 엔지니어가 되시기를 응원합니다. 저 또한 그 길을 가기 위해 오늘도 부단히 공부하고 있습니다.
