소프트웨어 트레이드오프 (Software Tradeoffs)

원래 lavkesh.com에서 게시되었습니다.

당신이 내리는 모든 설계 결정은 다른 무언가를 차단하며, 이는 소프트웨어가 작동하는 방식 그 자체입니다. 따라서 복잡성을 증가시키는 기능을 추가하거나 지연 시간 (latency)을 유발하는 방식으로 성능을 최적화하여 의도치 않게 트레이드오프 (tradeoff)를 발생시키기보다는, 의식적으로 트레이드오프를 수행하는 것이 핵심입니다.

기능성 (functionality)과 성능 (performance) 사이의 트레이드오프는 흔히 발생하는 사례입니다. 기능을 깔끔하고 표현력 있게 구현하면 속도가 느려질 수 있고, 빠르게 만들면 읽기 어려운 코드가 될 수 있으며, 그 해답은 당신의 구체적인 사례에서 무엇이 중요한지에 달려 있습니다.

코드가 배치 프로세스 (batch process)에서 하루에 한 번 실행된다면 가독성 (readability)을 위해 최적화하는 것이 합리적이지만, 요청당 수천 번 실행되는 핫 패스 (hot path)에 있다면 성능을 최적화하는 것이 정답입니다. 모든 곳에 동일한 답을 적용하는 것은 실수입니다.

저는 지연 시간 (latency)을 추측하는 것이 심야의 긴급 상황을 초래하는 지름길이라는 것을 고통스러운 경험을 통해 배웠습니다. 하루에 약 500만 건의 요청을 처리하는 결제 게이트웨이 (payment-gateway) 서비스에서, 저희는 서류상으로는 몇 마이크로초 (microseconds)를 절약할 수 있는 JSON 직렬화기 (serializer)에 마이크로 최적화 (micro-optimisation)를 추가했습니다. 하지만 이 변경 사항은 몇 시간 후 힙 (heap)을 300MB 증가시키는 메모리 누수 (memory leak)를 유발했습니다. 저희는 힙 덤프 (heap dump)를 추출하고 Pyroscope로 플레임그래프 (flamegraph)를 실행한 후에야 이를 발견할 수 있었습니다. 프로파일러 (profiler)는 실제 핫 패스 (hot path)가 직렬화 (serialization)가 아닌 네트워크 I/O (network I/O)에 의해 지배되고 있음을 보여주었습니다. 교훈은 먼저 계측 (instrument)을 하고, eBPF 트레이싱 (eBPF tracing)이나 저부하 프로파일러 (low-overhead profiler)를 사용한 다음, 그제야 코드 경로가 재작성할 가치가 있는지 결정해야 한다는 것이었습니다.

유연성 (flexibility) 대 단순성 (simplicity) 또한 큰 트레이드오프 중 하나입니다. 많은 시나리오를 처리하기 위해 추상화 (abstraction)를 구축하면 코드를 이해하기 더 어려워질 수 있습니다. 올바른 접근 방식은 작동하는 가장 단순한 것을 작성하되, 필요할 경우 확장하기 쉽도록 구조화하는 것입니다.

확장성 (Scalability) 대 비용 (Cost) 또한 중요합니다. 현재의 트래픽에 맞춰 설계하고 비용을 최적화하는 방식은 나중에 고통스러운 재작성 (Rewrite)을 요구할 수 있습니다. 따라서 성장률과 런웨이 (Runway)를 측정하여 올바른 결정을 내리는 것이 매우 중요합니다. 예를 들어, 매달 20%씩 성장하고 있는데 자본이 6개월치밖에 남지 않은 상황이라면 더욱 그렇습니다.

보안 (Security) 대 사용성 (Usability)은 끊임없는 트레이드오프 (Tradeoff) 관계입니다. 다요소 인증 (Multi-factor authentication)과 하드웨어 키 (Hardware keys)를 요구하면 사용자 경험 (User experience)은 깔끔해질 수 있지만 번거로워질 수도 있습니다. 대부분의 경우 정답은 최대한의 보안 (Maximally secure)이 아니라, 합리적인 수준의 보안 (Reasonably secure)입니다.

내부 관리 콘솔 (Admin console)에 의무적인 하드웨어 토큰 (Hardware tokens)을 도입했을 때, 로그인 성공률이 하룻밤 사이에 98%에서 84%로 떨어졌습니다. 지원 티켓 (Support tickets)이 급증했고, 새벽 2시 30분에 시니어 엔지니어가 시스템에서 차단되는 심각한 사고 (Critical incident)가 발생했습니다. 우리는 회사에서 지급한 모바일 앱을 활용한 푸시 기반의 2차 인증 요소를 추가하여 대응했습니다. 그 결과 전환율 (Conversion)은 96%로 회복되었고 사고 횟수는 급격히 감소했습니다. 이 수치를 통해 저는 사용성이 10% 떨어지는 것이 매주 몇 시간의 엔지니어링 시간 손실로 이어질 수 있다는 것을 배웠습니다. 그래서 저는 프로세스를 강화하기 전에 항상 사용자에게 미치는 영향을 벤치마크 (Benchmark)합니다.

이러한 결정을 내리기 위해서는 무엇을 최적화하려 하는지 명확히 하고, 비용을 이해하며, 추측하는 대신 측정하고, 단순한 솔루션에서 시작하여 필요에 따라 최적화하며 반복 (Iterate)해야 합니다. 또한 미래의 엔지니어들을 위해 결정 사항과 그 근거를 문서화해야 합니다.

기술 부채 (Technical debt)와 장기적인 사고 또한 매우 중요합니다. 코드를 이해하기 어렵게 만드는 지름길을 택하는 것은 누군가 그 코드를 작업할 때마다 비용을 치르게 할 수 있습니다. 잘못되었을 때의 비용과 그럴 가능성이 얼마나 되는지를 생각하는 것이 올바른 결정을 내리는 데 도움이 됩니다.

우리가 물려받은 한 레거시 서비스 (legacy service)의 경우, 테스트 커버리지 (test coverage)가 30% 미만이었고 코드베이스 (codebase) 곳곳에 전역 상태 (global state)가 흩어져 있었습니다. 우리는 단계적인 리팩터링 (refactor) 전략을 도입했습니다. 먼저 Pact를 사용하여 계약 테스트 (contract tests)를 추가했고, 그다음 인터페이스 (interfaces) 뒤로 부작용 (side effects)을 격리했으며, SonarQube를 사용하여 코드 스멜 (code smells)을 추적했습니다. 6개월에 걸쳐 커버리지를 78%로 끌어올렸고, 버그 해결 평균 시간 (mean time to resolve)을 4일에서 1.2일로 단축했습니다. 핵심은 리팩터링을 전체 서비스 중단 (outage)이 필요한 거대한 재작성 (rewrite)이 아니라, 일련의 작고 즉시 배포 가능한 (shipping-ready) 변경 사항들로 취급한 것이었습니다.

때로는 타협이 필요하며, 한 서비스에서는 가독성 (readability)을 최적화하고 다른 서비스에서는 처리량 (throughput)을 최적화하는 것과 같이 무엇이 가장 중요한지에 대해 구체화하고, 그 결정과 근거를 문서화하는 것은 미래의 엔지니어들이 트레이드오프 (tradeoff)를 이해하고 필요할 때 변경할 수 있도록 하는 데 필수적입니다.

트레이드오프를 영구적인 것으로 취급하는 것은 실수입니다. 결정 사항을 주기적으로 재검토하고, 당신이 최적화했던 대상이 여전히 중요한지 측정하는 것이 매우 중요하며, 트레이드오프에 대해 전략을 가지고 의도적으로 접근하는 것이 모든 면에서 어중간한 시스템을 피하는 핵심입니다.