스와핑 인프라의 실제 비용
Source: Dev.to
The Real Cost of Swapping Infrastructure
나는 건축가로서 충분히 많은 인프라 평가를 해왔기에, 방 안의 에너지가 사라지는 순간을 바로 알아차릴 수 있다. 이는 누군가가 성능 수치나 비용 모델에 의문을 제기할 때가 아니다. 누군가가 코드베이스를 열어 몇 개의 서비스가 변경되어야 하는지를 세기 시작할 때다.
인프라가 더 안정적이거나 운영이 쉬워지거나 경제성이 더 좋을 수 있지만, 수십 개의 서비스에 걸쳐 안정적인 프로덕션 코드를 건드려야 한다면 그것은 의미가 없다. 대화는 “우리가 이걸 해야 할까?” 에서 “우리가 이걸 감당할 수 있을까?” 로 옮겨가고, 답은 보통 ‘아니다’이다. “이게 더 좋다” 와 “우리가 실제로 도입할 수 있다” 사이의 그 간극이 많은 결정이 멈추거나 거절되는 지점이다.
아키텍처 논의는 익숙한 패턴을 따른다. 화이트보드에 박스와 화살표가 가득하고, 트레이드‑오프는 합리적으로 보이며, 모두가 끝에선 더 나아질 것이라고 동의한다. 그러다 누군가가 묻는다: 우리가 얼마나 많은 코드를 건드려야 할까?
그 질문은 기능이나 벤치마크에 관한 것이 아니다. 위험에 관한 것이다. 건축가들은 성능과 안정성뿐 아니라 변경의 블래스트 반경을 평가한다. 이동해야 할 애플리케이션 코드 한 줄, 교체해야 할 클라이언트 라이브러리 하나, 다시 배워야 할 동작 하나마다 개념 증명조차 실행하기 전에 비용이 증가한다.
프로덕션에 이미 배포된 시스템의 경우, 안정적인 코드를 건드리는 것은 불확실성을 초래한다. 리뷰 사이클이 늘어나고, 회귀 테스트가 시작되며, 롤백이 복잡해진다. 좋은 아이디어도 기존 애플리케이션에 얽어넣는 비용이 너무 커서 이 단계에서 사라지는 경우가 많다.
Why Code Changes Matter
- Risk amplification – each touched service expands the blast radius.
- Review overhead – larger changes require longer code reviews and more reviewers.
- Testing burden – regression suites must be run across many components, increasing CI time.
- Rollback complexity – undoing a multi‑service change is far more involved than flipping a configuration flag.
이것은 특히 핫 패스에 있는 인프라와 관련이 깊다. 캐시가 오작동하면 다른 시스템까지 끌어내릴 수 있다. 제안된 인프라가 설득력 있더라도, 팀은 여기서의 변경에 대해 당연히 신중하다.
팀은 프로덕션에서 관찰한 동작—명령이 직렬화되는 방식, 오류가 표면에 드러나는 방식, 부하가 걸렸을 때 재시도가 어떻게 동작하는지—을 신뢰한다. 그 동작은 수백만 번 실행되고, 실제 트래픽, 부하 테스트, 수년간의 점진적 수정으로 견고해졌다. 실제로 이 동작은 앱 코드와 인프라 사이의 계약 역할을 한다.
Contractual Compatibility (RESP)
Redis 혹은 Valkey 기반의 캐시‑중심 시스템에서는 계약이 종종 와이어 프로토콜 자체인 RESP(Redis Serialization Protocol)이다. 애플리케이션은 “캐시”에 의존하는 것이 아니라, 이 특정한 방식으로 통신하는 데 의존한다.
계약을 그대로 유지하고 뒤에 있는 서비스를 교체하면 위험 잠재력은 크게 감소한다. 캐시 레이어를 다시 작성하거나 서비스 전반에 SDK를 교체하는 대신, 팀은 다음을 할 수 있다:
- 기존 Redis/Valkey 클라이언트를 호환 가능한 서비스(예: Momento)로 지정한다.
- 동일한 인증과 명령을 그대로 사용한다.
인프라가 바뀐다. 운영 모델이 바뀐다. 애플리케이션 코드는 대부분 변경되지 않는다.
Reducing Risk with Configuration Changes
스와프를 리팩터가 아닌 구성 변경으로 다루면 팀은 다음을 할 수 있다:
- 전체 리라이트 없이 실제 프로덕션 동작을 관찰한다.
- 쉽게 롤백한다 – 엔드포인트만 원래대로 바꾸면 된다.
- 평가 위험을 애플리케이션 코드에서 인프라로 전환한다. 인프라는 모니터링과 판단이 더 쉽다.
이 접근법이 모든 위험을 없애는 것은 아니다. RESP 호환성에는 이해해야 할 한계와 제약이 있다—모든 Redis 명령이 지원되는 것은 아니다. 그러나 위험 프로파일이 크게 바뀌어 작업의 대부분이 코드베이스가 아닌 운영 차원으로 이동한다.
Takeaways
- “더 좋다”는 충분하지 않다 만약 그것을 달성하기 위해 누군가가 건드리기 싫어하는 코드를 불안정하게 만든다면.
- 실제 채택을 얻는 플랫폼은 팀이 이미 사용하고 있는 곳에서 만나, 기존 계약과 사고 모델을 존중한다.
- RESP 호환성은 이 철학을 구현한다: 팀은 신뢰받는 클라이언트 계약을 유지하면서, 확장성, 가용성, 운영 복잡도 감소와 같은 이점을 위해 기반 서비스를 교체할 수 있다.
- 평가가 되돌릴 수 있다고 느껴질 때, 팀은 트레이드‑오프에 대해 솔직하게 논의하고, 머무르는 이유를 억지로 만들지 않는다.
실제로 그 되돌릴 수 있음이 흥미로운 기술과 실제 채택되는 기술을 구분하는 핵심 요소가 된다.