[소프트웨어 개발자 면접] 시스템 디자인 - CAP 이론 정리

시스템 디자인 면접을 처음 준비할 때 제가 저질렀던 실수가 있습니다. 면접관이 "데이터베이스를 어떤 기준으로 선택하셨나요?"라고 묻자, 저는 자신 있게 "CA 시스템으로 설계해서 일관성과 가용성을 모두 보장합니다"라고 답했습니다. 면접관은 잠시 멈추더니 조용히 "그 시스템에서 네트워크 파티션이 발생하면 어떻게 되나요?"라고 되물었습니다. 그 순간 머릿속이 하얘졌습니다. CA를 선택했다고 해서 파티션이 안 생기는 게 아니라는 것, 분산 시스템에서 파티션 내성은 선택 사항이 아니라는 것을 그때 처음 제대로 깨달았습니다.

CAP 이론이란?

CAP 정리는 분산 소프트웨어에서 다음 세 가지 조건을 모두 만족하는 시스템은 존재하지 않음을 증명한 정리입니다. 최대 두 가지만 만족하는 시스템만 존재하며, 조합마다 발생하는 트레이드오프를 먼저 이해하셔야 합니다.

• 일관성(Consistency): 모든 노드는 동일한 데이터를 동시에 봅니다. 추가 읽기를 허용하기 전에 여러 노드를 업데이트하여 일관성을 확보합니다. 여기서 말하는 일관성은 ACID의 일관성과 다른 개념입니다. CAP에서의 일관성은 분산 노드 간 데이터 동기성, 즉 선형화 가능성(linearizability)에 가깝습니다. 면접에서 이 둘을 혼용하면 면접관이 즉시 알아챕니다.
• 가용성(Availability): 모든 요청은 성공이나 실패에 대한 응답을 받아야 합니다. 가용성은 서로 다른 서버에 데이터를 복제함으로써 달성됩니다. 주의할 점은 가용성이 업타임(uptime)과 같은 개념이 아니라는 것입니다. CAP에서 가용성이란 장애가 없는 모든 노드가 요청에 반드시 응답해야 한다는 의미입니다.
• 분할 내성(Partition tolerance): 메시지 손실 또는 부분 장애에도 불구하고 시스템은 계속 작동합니다. 노드와 네트워크 조합에 데이터가 충분히 복제되어 있으면 간헐적인 가동 중단 속에서도 시스템은 유지됩니다.

제가 면접에서 저질렀던 가장 큰 실수는 분할 내성을 선택 가능한 옵션으로 이해했다는 점입니다. 실제로는 그렇지 않습니다. 네트워크는 항상 신뢰할 수 없고, 분산 시스템을 운영하는 한 파티션은 반드시 발생합니다. 분산 시스템에서 파티션 내성을 포기한다는 것은, 파티션이 생겼을 때 아무 처리도 하지 않겠다는 뜻과 같습니다. 실제로는 단일 노드인데 여러 서버에 배포한 것처럼 보이는 취약한 구성이 될 뿐입니다.

따라서 실제로 선택해야 하는 트레이드오프는 CP(일관성 + 분할 내성)냐, AP(가용성 + 분할 내성)냐의 문제입니다. "세 가지 중 두 개를 고르라"는 문장이 맞긴 하지만, 분산 환경에서는 사실상 CP와 AP 중 하나를 선택하는 것과 같습니다.

네트워크는 항상 신뢰할 수 없습니다. 따라서 분할 내성(Partition tolerance)은 대부분의 분산 시스템에서 반드시 전제됩니다. 시스템 설계 시에는 일관성과 가용성 사이의 트레이드오프를 고민하고 둘 중 하나를 선택하셔야 합니다.

일관성 vs 가용성

CP (Consistency & Partition tolerance) - 일관성과 분할 내성 조합

분할된 노드에서 응답을 기다리는 경우 시간 초과 오류(timeout error)가 발생할 수 있습니다. CP는 원자성 읽기와 쓰기를 필요로 하는 비즈니스 로직에 좋은 선택이 됩니다. 금융 도메인에서 트랜잭션 정합성이 중요한 시스템을 다룰 때는 항상 CP 쪽으로 기울게 됩니다. 가용성보다 정확성이 중요한 경우, 즉 오래된 데이터를 제공하느니 차라리 요청을 거부하는 편이 나은 경우가 CP에 해당합니다. 대표적인 CP 시스템으로는 HBase, MongoDB(기본 설정 기준), ZooKeeper가 있습니다.

AP (Availability & Partition tolerance) - 가용성과 분할 내성 조합

응답 요청은 어느 노드에서든 받을 수 있고, 그 노드에 준비된 버전의 데이터를 반환합니다. 반환된 데이터는 최신 버전이 아닐 수 있습니다. 모든 파티션에 새로운 데이터나 업데이트가 전파되는 데 다소 시간이 걸릴 수 있습니다. AP는 외부 장애에도 시스템을 유지해야 하고 데이터가 궁극적 일관성(eventual consistency)만 갖춰지면 되는 비즈니스 모델에 좋은 선택입니다. 피드, 알림, 쇼핑 카트처럼 사용자 경험 흐름에서는 AP를 선택하는 편이 응답성을 확보하는 데 유리합니다. 대표적인 AP 시스템으로는 Cassandra, DynamoDB, CouchDB가 있습니다.

면접에서 실제로 통했던 설명 방식

면접관이 "왜 Cassandra를 선택하셨나요?"라고 물을 때, 단순히 "NoSQL이라서요"라고 답하면 다음 질문으로 이어지지 않습니다. 제가 실제로 면접에서 효과가 있었던 답변 흐름은 이렇습니다.

• 먼저 서비스 특성을 제시합니다. "이 서비스는 초당 수만 건의 알림을 처리해야 하고, 알림이 1~2초 지연되어도 비즈니스에 치명적이지 않습니다."
• 그다음 CAP 관점을 연결합니다. "따라서 일관성보다 가용성을 우선시하는 AP 시스템이 적합했고, Cassandra는 AP 모델로 네트워크 파티션 상황에서도 쓰기 요청을 받아낼 수 있었습니다."
• 마지막으로 트레이드오프를 솔직하게 인정합니다. "대신 데이터 복제 중 일시적으로 다른 노드에서 오래된 값을 읽는 문제가 있었고, 이는 읽기 수준 설정을 QUORUM으로 맞춰 보정했습니다."

CAP 이론을 단순 암기 지식으로 아는 것과, 트레이드오프를 실제 선택의 근거로 연결할 수 있는 것은 면접관에게 완전히 다르게 보입니다. "세 가지를 다 만족하면 좋겠다"고 처음에는 생각하지만, 분산 환경을 실제로 운영해보면 불가능한 조합이 있다는 걸 체감하게 됩니다. 그 경험이 바탕이 되어야 비로소 데이터베이스 선택이 설득력을 얻습니다.