데이터베이스 면접 질문

트랜잭션의 ACID 속성은 데이터베이스의 신뢰성을 보장하는 핵심적인 요소입니다.

ACID는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)의 약자입니다.

원자성은 트랜잭션 내의 모든 연산이 전부 성공하거나 전부 실패해야 함을 의미합니다. 일부만 성공하는 경우는 없어야 데이터가 꼬이지 않습니다.

일관성은 트랜잭션이 실행된 후에도 데이터베이스의 제약 조건이 항상 만족되어야 함을 의미합니다. 데이터의 무결성을 유지하는 데 중요합니다.

격리성은 동시에 실행되는 트랜잭션들이 서로에게 영향을 주지 않아야 함을 의미합니다. 각 트랜잭션은 독립적으로 실행되는 것처럼 보여야 합니다.

지속성은 트랜잭션이 성공적으로 완료되면 그 결과가 영구적으로 데이터베이스에 반영되어야 함을 의미합니다. 시스템 장애가 발생해도 데이터가 유실되지 않도록 보장합니다.

이러한 ACID 속성 덕분에 데이터베이스는 안정적으로 데이터를 관리하고, 예기치 않은 상황에서도 데이터의 무결성을 유지할 수 있습니다.

SQL에서 JOIN은 여러 테이블의 데이터를 연결해서 하나의 결과 집합으로 만드는 데 사용됩니다. 크게 INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN 이렇게 네 가지 종류가 있습니다.

INNER JOIN은 두 테이블에 모두 존재하는, 즉 교집합에 해당하는 데이터만 반환합니다. 예를 들어, 고객 테이블과 주문 테이블이 있을 때, INNER JOIN을 사용하면 주문이 있는 고객 정보만 얻을 수 있습니다.

LEFT JOIN은 왼쪽 테이블의 모든 데이터와 오른쪽 테이블에서 일치하는 데이터를 반환합니다. 만약 오른쪽 테이블에 일치하는 데이터가 없으면 NULL 값으로 채워집니다. 고객 테이블을 기준으로 LEFT JOIN을 하면, 주문이 없는 고객 정보도 함께 볼 수 있습니다.

RIGHT JOIN은 LEFT JOIN과 반대로, 오른쪽 테이블의 모든 데이터와 왼쪽 테이블에서 일치하는 데이터를 반환합니다.

FULL OUTER JOIN은 왼쪽 테이블과 오른쪽 테이블의 모든 데이터를 반환합니다. 일치하는 데이터가 없으면 NULL 값으로 채워집니다. 즉, 양쪽 테이블의 모든 정보를 빠짐없이 보고 싶을 때 사용합니다.

데이터베이스 커넥션 풀은 데이터베이스 연결을 미리 생성해두고 관리하는 기술입니다.

데이터베이스에 접속할 때마다 새로운 커넥션을 생성하는 것은 비용이 많이 드는 작업입니다. 매번 TCP 핸드셰이크를 하고 Connection 객체를 만드는 과정이 필요하죠. 커넥션 풀은 이러한 과정을 줄여줍니다.

미리 만들어둔 커넥션을 필요할 때 가져다 쓰고, 사용이 끝나면 다시 풀에 반환하여 재사용합니다. 이렇게 함으로써 데이터베이스 연결 및 해제에 드는 시간과 자원을 절약하여 전체적인 애플리케이션 성능을 향상시킬 수 있습니다. 또한, 풀에서 커넥션 개수를 제한하여 데이터베이스 서버의 과부하를 방지하고 안정적인 자원 관리를 가능하게 합니다.

뷰(View)는 물리적인 테이블이 아니라, 저장된 쿼리입니다. 즉, 실제 데이터를 저장하는 테이블과는 달리 뷰는 데이터를 저장하지 않고, 테이블을 기반으로 만들어진 가상 테이블이라고 생각하시면 됩니다.

뷰를 사용하는 목적은 크게 세 가지입니다. 첫째, 보안입니다. 특정 컬럼만 보여주는 뷰를 만들어 민감한 정보에 대한 접근을 제한할 수 있습니다. 둘째, 복잡한 쿼리를 단순화할 수 있습니다. 여러 테이블을 조인하는 복잡한 쿼리를 뷰로 만들어두면, 사용자는 간단한 뷰 이름으로 원하는 결과를 얻을 수 있습니다. 셋째, 데이터 독립성을 확보할 수 있습니다. 테이블 구조가 변경되더라도 뷰를 통해 사용자에게 동일한 인터페이스를 제공하여 애플리케이션의 변경을 최소화할 수 있습니다.

Prepared Statement를 사용하는 주된 이유는 SQL Injection 공격을 방지하고 성능을 향상시키기 위해서입니다.

SQL Injection은 사용자 입력값을 제대로 검증하지 않고 SQL 쿼리에 포함시킬 때 발생하는데요. Prepared Statement는 쿼리 구조와 데이터를 분리하여 처리합니다. 쿼리 구조는 미리 컴파일되고, 데이터는 나중에 파라미터로 바인딩됩니다.

예를 들어, 사용자 이름으로 검색하는 쿼리가 있다면, 쿼리 자체는 SELECT * FROM users WHERE username = ? 와 같이 정의하고, '?' 부분에 사용자 입력값을 바인딩하는 방식으로 처리합니다. 이렇게 하면 사용자 입력값이 SQL 코드로 해석되지 않고 단순한 데이터로 처리되어 SQL Injection 공격을 막을 수 있습니다. 또한, 동일한 쿼리를 반복적으로 실행할 때 컴파일 과정을 생략하여 성능 향상에도 도움이 됩니다.

외래 키는 데이터베이스 테이블 간의 관계를 설정하고, 참조 무결성을 유지하는 데 중요한 역할을 합니다. 특정 테이블의 컬럼이 다른 테이블의 기본 키를 참조하도록 설정하여, 데이터의 일관성을 보장하는 것이죠.

예를 들어, '주문' 테이블의 '고객ID' 컬럼이 '고객' 테이블의 '고객ID'를 참조하도록 설정할 수 있습니다. 이렇게 하면 '주문' 테이블에 존재하지 않는 '고객ID'로 주문을 생성하는 것을 방지할 수 있습니다.

사용 시 주의사항으로는, 외래 키 제약 조건이 데이터 삽입/삭제 시 성능에 영향을 줄 수 있다는 점입니다. 또한, CASCADE 옵션을 사용할 경우, 참조되는 테이블의 데이터 변경이 참조하는 테이블에 연쇄적으로 영향을 미치므로 신중하게 고려해야 합니다. 예를 들어, 고객 정보를 삭제할 때 해당 고객의 주문 정보도 함께 삭제될 수 있습니다.

GROUP BY 절과 HAVING 절은 모두 SQL에서 데이터를 그룹화하고 필터링하는 데 사용되지만, 중요한 차이점이 있습니다.

GROUP BY 절은 특정 열을 기준으로 데이터를 그룹화합니다. 예를 들어, '부서별 평균 급여'를 구하려면 '부서' 열로 GROUP BY를 사용합니다.

HAVING 절은 GROUP BY로 그룹화된 결과에 대한 조건을 필터링합니다. WHERE 절은 개별 행에 대한 조건을 필터링하는 반면, HAVING 절은 그룹화된 결과에 대한 조건을 필터링합니다. 예를 들어, '평균 급여가 500만원 이상인 부서'를 찾으려면 HAVING 절을 사용합니다.

WHERE 절은 GROUP BY 절보다 먼저 실행되어 개별 행을 필터링하고, HAVING 절은 GROUP BY 절 이후에 실행되어 그룹화된 결과를 필터링합니다. 따라서 집계 함수(SUM, AVG, COUNT 등)를 사용하여 조건을 필터링하려면 HAVING 절을 사용해야 합니다.

예를 들어, 다음과 같은 쿼리를 생각해볼 수 있습니다.

SELECT 부서, AVG(급여) AS 평균급여
FROM 직원
GROUP BY 부서
HAVING AVG(급여) > 5000000;

이 쿼리는 '직원' 테이블에서 '부서'별로 그룹화한 후, '평균 급여'가 500만원 이상인 부서만 결과로 반환합니다.

데이터베이스 인덱스는 책의 색인과 비슷합니다. 특정 데이터를 빠르게 찾기 위해 테이블의 열 값과 해당 데이터의 위치 정보를 저장하는 자료구조입니다. 인덱스가 없으면 데이터베이스는 테이블 전체를 스캔해야 하지만, 인덱스를 사용하면 필요한 데이터가 있는 위치로 바로 이동하여 검색 성능을 향상시킬 수 있습니다.

B-Tree 인덱스는 가장 널리 사용되는 인덱스 구조 중 하나입니다. B-Tree는 균형 트리 구조로, 모든 리프 노드가 같은 레벨에 있어 예측 가능한 검색 성능을 제공합니다. 각 노드는 여러 개의 키와 자식 노드에 대한 포인터를 가질 수 있습니다.

B-Tree 인덱스를 통해 검색하는 과정은 루트 노드부터 시작하여 찾고자 하는 키 값과 노드의 키 값을 비교하면서 자식 노드로 이동하는 방식으로 진행됩니다. 만약 노드가 가득 차면 페이지 분할이 일어나 새로운 노드가 생성되고 트리의 균형을 유지합니다. 이러한 구조 덕분에 B-Tree 인덱스는 대용량 데이터에서도 효율적인 검색 성능을 보장합니다.

데이터베이스 정규화는 데이터 중복을 최소화하고 데이터 무결성을 유지하기 위한 과정입니다. 데이터베이스 내의 이상 현상(삽입, 삭제, 갱신 이상)을 줄이는 것이 주 목적입니다.

1NF(제1정규형)는 테이블의 모든 컬럼이 원자값을 가지도록 하는 것입니다. 즉, 하나의 컬럼에 여러 개의 값이 들어가면 안 됩니다.

2NF(제2정규형)는 1NF를 만족하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수적 종속을 만족해야 합니다. 부분적 종속이 존재하면 테이블을 분리해야 합니다.

3NF(제3정규형)는 2NF를 만족하고, 기본키가 아닌 속성이 기본키에 이행적 함수적 종속을 가지지 않도록 하는 것입니다. 이행적 종속이 존재하면 테이블을 분리합니다. 예를 들어, A -> B이고 B -> C이면 A -> C (이행적 종속) 관계가 성립하는데, 이 경우 테이블을 분리해야 합니다.

RDBMS와 NoSQL은 데이터 저장 방식에 큰 차이가 있습니다. RDBMS는 정해진 스키마를 기반으로 데이터를 테이블 형태로 저장하고, SQL을 사용하여 데이터를 관리합니다. ACID 속성을 보장하며 데이터의 일관성이 중요한 금융 거래 등에 적합합니다.

반면 NoSQL은 스키마가 유연하고, key-value, document, graph 등 다양한 데이터 모델을 지원합니다. 수평적 확장이 용이하여 대용량 데이터 처리나 실시간 데이터 분석에 유리합니다. CAP 이론에 따라 일관성, 가용성, 파티션 내성 중 일부를 선택하여 시스템을 설계할 수 있습니다. 예를 들어, 소셜 미디어 데이터나 IoT 데이터처럼 데이터 양이 많고 빠른 읽기/쓰기가 필요한 경우에 NoSQL이 좋은 선택이 될 수 있습니다. RDBMS는 데이터 관계가 명확하고 조인이 많이 필요한 경우에, NoSQL은 데이터 구조가 유연하고 확장성이 중요한 경우에 선택하는 것이 좋습니다.

SQL 쿼리 성능 최적화는 데이터베이스 성능 향상에 중요한 부분입니다. 몇 가지 방법을 말씀드리겠습니다.

첫째, 인덱싱을 활용합니다. WHERE절이나 JOIN 조건에 자주 사용되는 컬럼에 인덱스를 생성하면 검색 속도를 크게 향상시킬 수 있습니다. 하지만 과도한 인덱스는 오히려 성능 저하를 일으킬 수 있으므로 신중하게 선택해야 합니다.

둘째, 쿼리 실행 계획을 분석합니다. EXPLAIN 명령어를 사용하여 쿼리가 어떻게 실행되는지 확인하고, 비효율적인 부분을 찾아 쿼리를 수정합니다. 예를 들어, 풀 테이블 스캔이 발생하는 경우 인덱스 추가를 고려해볼 수 있습니다.

셋째, 쿼리 리팩토링을 통해 성능을 개선할 수 있습니다. 불필요한 JOIN을 줄이거나, 서브쿼리 대신 JOIN을 사용하는 등 쿼리 구조를 변경하여 성능을 향상시킬 수 있습니다.

넷째, 데이터베이스 파티셔닝을 고려할 수 있습니다. 대용량 테이블의 경우 파티셔닝을 통해 데이터를 분할하여 쿼리 성능을 향상시킬 수 있습니다.

마지막으로, 정규화/비정규화를 적절히 활용합니다. 정규화는 데이터 중복을 줄여 데이터 무결성을 높이지만, JOIN 연산이 많아질 수 있습니다. 반대로 비정규화는 JOIN 연산을 줄여 성능을 향상시킬 수 있지만, 데이터 중복이 발생할 수 있습니다. 상황에 맞게 적절한 방법을 선택해야 합니다.

클러스터형 인덱스와 논클러스터형 인덱스는 데이터베이스에서 데이터를 빠르게 검색하기 위해 사용되는 인덱스 방식입니다. 가장 큰 차이점은 데이터의 물리적인 정렬 방식에 있습니다.

클러스터형 인덱스는 테이블의 데이터를 인덱스 키 값에 따라 물리적으로 정렬합니다. 따라서 테이블 당 하나의 클러스터형 인덱스만 존재할 수 있습니다. 마치 사전처럼 데이터 자체가 정렬되어 있기 때문에 검색 속도가 매우 빠릅니다.

반면, 논클러스터형 인덱스는 데이터의 물리적인 정렬에는 영향을 주지 않고, 인덱스 키와 해당 데이터의 위치 정보(row ID 또는 클러스터형 인덱스 키)를 별도의 공간에 저장합니다. 테이블 당 여러 개의 논클러스터형 인덱스를 생성할 수 있으며, 책의 색인과 유사하게 원하는 데이터를 찾기 위한 포인터를 제공합니다. 실제 데이터는 별도로 찾아가야 하므로 클러스터형 인덱스보다는 검색 속도가 느릴 수 있습니다.

서브쿼리와 JOIN은 둘 다 여러 테이블의 데이터를 결합하는 데 사용되지만, 상황에 따라 선택이 달라집니다.

가독성 측면에서는 JOIN이 일반적으로 더 명확합니다. 특히 복잡한 쿼리일수록 JOIN을 사용하면 어떤 테이블이 어떻게 연결되는지 쉽게 파악할 수 있습니다.

성능은 데이터의 양과 쿼리 최적화에 따라 달라집니다. 서브쿼리는 때때로 비효율적인 실행 계획을 생성할 수 있지만, 특정 경우에는 JOIN보다 빠를 수도 있습니다. 예를 들어, 서브쿼리가 인덱스를 잘 활용하거나, 메인 쿼리의 조건에 따라 서브쿼리의 결과가 크게 줄어들 경우에 그렇습니다.

실행 계획을 확인하여 어떤 방식이 더 효율적인지 판단하는 것이 중요합니다. 데이터 종속성을 고려해야 하는데, 서브쿼리는 외부 쿼리에 종속적인 경우가 많아 성능에 영향을 줄 수 있습니다. 쿼리 최적화 도구를 사용하여 성능을 비교하고, 가독성과 유지보수성을 고려하여 최종적으로 선택합니다.

"EXPLAIN 명령어는 쿼리 실행 계획을 보여줘서 쿼리 성능을 분석하고 개선하는 데 아주 유용합니다. 실행 계획을 통해 쿼리 옵티마이저가 어떻게 쿼리를 처리할지 예상되는 단계를 확인할 수 있습니다.

주로 확인하는 것은 다음과 같습니다. 첫째, 인덱스 사용 여부입니다. 인덱스를 사용하는지, 어떤 인덱스를 사용하는지 확인하여 불필요한 Full Table Scan을 줄일 수 있는지 파악합니다. 둘째, 조인 방식입니다. Nested Loop Join, Hash Join 등 어떤 조인 방식을 사용하는지 보고, 더 효율적인 방식으로 변경할 수 있는지 검토합니다. 셋째, 예상 비용입니다. 쿼리 실행에 필요한 예상 비용을 확인하여 어떤 부분이 가장 많은 비용을 차지하는지 파악하고, 해당 부분을 집중적으로 개선합니다.

예를 들어 EXPLAIN SELECT * FROM users WHERE id = 1; 명령어를 실행하면, id 컬럼에 인덱스가 있는지, 있다면 해당 인덱스를 사용하는지 등을 확인할 수 있습니다. 실행 계획을 분석하여 쿼리 성능을 개선하는 데 활용할 수 있습니다."

면접관님, 데이터베이스 격리 수준은 트랜잭션 간의 간섭을 얼마나 허용할지 결정하는 설정입니다. ANSI 표준에서는 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE 이렇게 4가지 격리 수준을 정의하고 있습니다.

READ UNCOMMITTED는 가장 낮은 수준으로, 다른 트랜잭션에서 아직 커밋되지 않은 데이터도 읽을 수 있습니다. 이 경우 Dirty Read 문제가 발생할 수 있습니다.

READ COMMITTED는 커밋된 데이터만 읽을 수 있어 Dirty Read는 방지하지만, 트랜잭션 도중 다른 트랜잭션이 데이터를 변경하면 Non-repeatable Read 문제가 발생할 수 있습니다.

REPEATABLE READ는 트랜잭션이 시작된 후 읽은 데이터는 트랜잭션이 끝날 때까지 동일하게 유지되도록 보장합니다. Non-repeatable Read는 방지하지만, 새로운 레코드가 삽입되는 Phantom Read 문제는 발생할 수 있습니다.

SERIALIZABLE은 가장 높은 수준으로, 트랜잭션을 완전히 격리하여 모든 문제를 방지하지만, 동시성이 크게 떨어질 수 있습니다.

데이터베이스 락은 크게 공유 락(Shared Lock)과 배타 락(Exclusive Lock)으로 나눌 수 있습니다. 공유 락은 데이터를 읽을 때 사용하며, 여러 트랜잭션이 동시에 획득할 수 있습니다. 반면 배타 락은 데이터를 수정할 때 사용하며, 하나의 트랜잭션만 획득할 수 있습니다.

데드락은 두 개 이상의 트랜잭션이 서로 상대방이 점유한 락을 기다리면서 무한정 대기하는 상황을 말합니다. 예를 들어, 트랜잭션 A가 테이블1에 배타 락을 걸고 테이블2에 배타 락을 걸기 위해 대기하고, 트랜잭션 B가 테이블2에 배타 락을 걸고 테이블1에 배타 락을 걸기 위해 대기하는 경우 발생합니다.

데드락 해결 방법으로는 타임아웃 설정, 데드락 감지 후 트랜잭션 강제 종료, 락 획득 순서 규칙 정의 등이 있습니다. 타임아웃은 특정 시간 이상 락을 기다리는 트랜잭션을 강제로 종료하는 방법입니다. 락 획득 순서 규칙은 모든 트랜잭션이 동일한 순서로 락을 획득하도록 하여 데드락 발생 가능성을 줄입니다.

데이터베이스 파티셔닝과 샤딩은 둘 다 데이터를 분할하는 방식이지만, 목적과 구현 방식에 차이가 있습니다.

파티셔닝은 하나의 데이터베이스 내에서 테이블을 논리적으로 나누는 것을 의미합니다. 주로 성능 향상을 위해 사용되며, 수직 파티셔닝(컬럼 분할)과 수평 파티셔닝(로우 분할)이 있습니다. 예를 들어, 큰 테이블을 날짜별로 분할하여 특정 기간의 데이터만 빠르게 조회할 수 있습니다.

샤딩은 데이터를 여러 물리적인 데이터베이스 서버에 분산 저장하는 방식입니다. 데이터 양이 너무 많아 하나의 서버에서 처리하기 어려울 때 사용하며, 가용성과 확장성을 높이는 데 목적이 있습니다. 샤딩은 데이터베이스를 완전히 분리하여 관리하므로, 파티셔닝보다 복잡도가 높습니다. 예를 들어, 사용자 ID를 기준으로 데이터를 여러 서버에 분산하여 저장할 수 있습니다.

데이터베이스 복제는 데이터를 여러 데이터베이스 서버에 복사하여 데이터 가용성과 성능을 향상시키는 기술입니다. 크게 마스터-슬레이브(주-종) 방식과 마스터-마스터(다중-마스터) 방식으로 나눌 수 있습니다.

마스터-슬레이브 방식은 하나의 마스터 서버에서 쓰기 작업을 처리하고, 슬레이브 서버는 마스터 서버의 데이터를 복제하여 읽기 작업을 처리합니다. 장점으로는 읽기 성능 향상과 데이터 백업이 용이하다는 점이 있지만, 마스터 서버에 장애가 발생하면 쓰기 작업이 중단되는 단점이 있습니다. 복제 방식은 주로 비동기 방식으로 이루어지기 때문에 데이터 일관성이 완벽하게 보장되지는 않습니다.

마스터-마스터 방식은 여러 마스터 서버에서 쓰기 작업을 처리할 수 있도록 구성됩니다. 장점으로는 하나의 마스터 서버에 장애가 발생해도 다른 서버에서 쓰기 작업을 계속할 수 있어 가용성이 높다는 점이 있지만, 데이터 충돌 가능성이 있고, 복잡도가 높다는 단점이 있습니다. 데이터 일관성을 위해 동기 복제를 사용할 수 있지만, 성능 저하를 야기할 수 있습니다.

CAP 정리는 분산 시스템이 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 세 가지 속성을 동시에 만족할 수 없다는 것을 말합니다. 네트워크 분할이 발생했을 때, 시스템은 일관성을 유지하거나 가용성을 유지하는 둘 중 하나를 선택해야 합니다.

예를 들어, 분산 데이터베이스에서 사용자가 데이터를 읽을 때, 모든 노드가 항상 최신 데이터를 가지고 있도록 보장하는 것이 일관성입니다. 반면, 가용성은 시스템이 항상 요청에 응답할 수 있음을 의미합니다. 만약 네트워크 분할로 인해 일부 노드와 통신이 불가능해지면, 일관성을 유지하려면 해당 노드에 대한 요청을 거부해야 하므로 가용성이 떨어집니다. 반대로 가용성을 유지하기 위해 응답한다면, 최신 데이터가 아닌 데이터를 반환할 수 있어 일관성이 깨질 수 있습니다. 따라서 실제 시스템에서는 이 세 가지 중 두 가지만 선택적으로 보장하게 됩니다.

데이터베이스 마이그레이션은 크게 오프라인 마이그레이션과 온라인 마이그레이션으로 나눌 수 있습니다. 무중단 스키마 변경은 온라인 마이그레이션의 핵심입니다.

가장 일반적인 전략 중 하나는 블루-그린 배포입니다. 기존 운영 환경(블루)과 동일한 새로운 환경(그린)을 준비하고, 스키마 변경을 그린 환경에 먼저 적용합니다. 이후 트래픽을 점진적으로 그린 환경으로 전환하며, 문제가 없을 시 블루 환경을 제거하는 방식입니다.

또 다른 접근법은 카나리 배포입니다. 소수의 사용자에게만 새로운 스키마를 적용한 버전을 먼저 노출시켜 안정성을 확인한 후, 점차 확대하는 방식입니다.

스키마 변경 시에는 온라인 스키마 변경(Online Schema Change) 도구를 활용하여 서비스 중단 없이 테이블 구조를 변경합니다. 이때 중요한 것은 스키마 호환성을 유지하는 것입니다. 예를 들어, 기존 애플리케이션이 새 스키마에서도 정상 동작하도록 필드 추가 시에는 null 허용으로 변경하거나, 기존 필드를 삭제하기 전에 새로운 필드로 데이터를 이전하는 등의 조치가 필요합니다. 데이터 정합성을 보장하기 위해 마이그레이션 전후로 데이터 검증 절차를 반드시 포함해야 합니다.

2단계 커밋(2PC)은 분산 환경에서 트랜잭션의 원자성을 보장하지만, 몇 가지 중요한 한계가 있습니다. 가장 큰 문제는 동기적인 블로킹입니다. 코디네이터가 준비 단계를 진행하는 동안 참여자들은 응답을 기다리며 자원을 점유한 채 블록될 수 있습니다. 또한, 코디네이터에 장애가 발생하면 전체 시스템이 멈추는 단일 실패점 문제가 있습니다.

Paxos나 Raft 같은 분산 합의 알고리즘은 이러한 문제를 완화합니다. 이들은 리더 기반 합의를 통해 동작하며, 리더가 장애가 발생해도 다른 노드가 리더가 되어 시스템 가용성을 유지합니다. Paxos는 복잡하지만 이론적으로 안정성이 높고, Raft는 이해하기 쉽고 구현이 간단하다는 장점이 있습니다. 하지만 Paxos와 Raft 모두 합의를 이루는 과정에서 네트워크 지연이 발생할 수 있고, 리더 선출 과정에서 일시적인 서비스 중단이 발생할 수 있다는 단점이 있습니다.