TRADEOFF

• TRADEOFF
• ENGINEERING THINKING

TRADEOFF

소프트웨어 아키텍처 선정, 구현, 시스템 설계 등 정답이 없는 과정에서 올바른 결정을 내리기 위해 근거와 논리를 가지고 균형을 고민하고 선택하는 과정은 엔지니어가 얻을 수 있는 낭만이자 즐거움이다.

ENGINEERING THINKING

엔지니어링에서 중요한 결정의 대부분은 정답을 고르는 문제가 아니라 트레이드오프를 선택하는 문제이다.

트레이드오프를 잘 하기 위해서는 정보를 객관적으로 분석하고 평가하여 합리적인 판단을 내리는 사고 과정인 CRITICAL THINKING 을 잘해야 한다.

• 비판적 사고를 잘 하기 위한 핵심 프레임은 문제 정의 → 가설 수립 → 검증 이다.
• 트레이드오프를 잘 하기 위한 핵심 프레임은 문제 정의 → 제약 → 선택지 → 결정 사항 이다.

가장 중요한 것은 문제 정의 이다. 문제를 제대로 정의해야 헛걸음을 하지 않는다. 다음으로는 불변 조건 등을 고려해야 한다. 즉, "어떤 상황에서도 절대 깨지면 안되는 것" 을 고려하는 것이다. 예를 들면 "한 차량은 동시에 두 배차를 갖지 않는다", "돈은 중복 생성되지 않는다", "하나의 계정은 하나의 활성 세션만 가진다" 와 같은 것이다.

다음으로는 제약 조건(constraints) 을 명시하는 것이다. 트래픽 규모, 지연 허용 범위, 팀 역량, 운영 복잡도, 확장성, 유지보수성, SLA/SLO, 컨슈머 특징 등을 명시해야 한다. 더 나아가 시간의 흐름에 따른 변화 도 고려해보면 좋다. 예를 들어 단기간 내에 우리 서비스가 글로벌 서비스로 나가야 한다던지, 트래픽이 얼마나 예상되는지 등이 있다. 이러한 제약 조건은 설계를 결정함에 있어서 중요한 역할을 한다.

예를 들어 플랫폼을 구축할 때는 아키텍처 원칙(Architecture Principle) 이 엄청 중요한데, 아키텍처 원칙을 제대로 세우려면 제약 조건이 필요하다. 아키텍처 원칙을 잘 수립하기 위해서는 만들고자 하는 서비스(서버)의 역할 및 책임 을 명확히 해야 한다. 즉, 어떠한 기능적 요구 사항을 수행해야하는지를 알아야 한다. 그 다음으로는 비기능적 요구 사항으로 어떤 것이 중요한지 정하는 것이다. 위에서 설명한 원칙은 비기능적 요구사항에 부합한다. 예를 들면 Latency 보다 데이터 정합성이 중요하다는 등이 있다. 이러한 비기능적 요구사항은 역할 및 책임을 명확히 하지 않으면 도출할 수 없다.

다음으로는 선택지를 열거하는 것이다. 예를 들어 메시징을 위한 무언가를 도입해야하는데 MQ 와 Pub/Sub 중 어떤 것을 사용할지, 이는 제약 조건을 기반으로 결정되며 더 나아가 구체적인 제품을 열거 할 수 있다. 예를 들어 Pub/Sub 이라면 Redis 를 쓸지, NATS 를 쓸지 등을 나열하는 것이다.

그 다음 평가 기준을 세워본다. 일관성, 처리량, 레이턴시, 비용, 복잡성, 운영 난이도 등이 있다. 그리고 지금까지 정리한 내용을 바탕으로 가장 합리적인 선택 을 내리는 것이다. 결정을 내릴 때는 선택한 이유만큼이나 버린 이유를 명확히 아는 것이 중요하다.