ACID와 제약조건으로 견고한 시스템 구축하기

게시일: 2025년 11월 22일 | 원문 작성일: 2017년 1월 1일 | 저자: Brandur Leach | 원문 보기

이차 효과란 무엇인가요?

데이터베이스를 선택할 때 우리는 종종 직접적인 기술적 특성만 봐요. “이 데이터베이스는 얼마나 빠른가?”, “스케일이 잘 되나?” 같은 질문이죠. 하지만 Brandur Leach는 더 중요한 걸 물어봐요: “이 선택이 우리 팀의 일상적인 업무 방식을 어떻게 바꿀까?”

ACID 보장(Atomicity, Consistency, Isolation, Durability)을 제공하지 않는 데이터베이스를 선택하면, 직접적인 효과는 명확해요. 작업이 부분적으로 실패할 수 있고, 무효한 데이터가 저장될 수 있어요. 하지만 진짜 문제는 이차 효과예요.

원자성이 없으면 팀이 “데이터 청소부”가 돼요

원자성(Atomicity)이 없으면 작업이 중간에 실패할 수 있어요. GitHub 풀 리퀘스트를 예로 들어볼게요. PR을 만들 때 여러 단계가 필요해요:

• 브랜치 생성
• 커밋 추가
• PR 메타데이터 생성
• 알림 발송

만약 세 번째 단계에서 실패하면 어떻게 될까요? 원자성이 있는 데이터베이스라면 전체 작업이 롤백돼요. 하지만 원자성이 없다면? 엔지니어가 직접 정리해야 해요.

직접적인 결과는 뭘까요? 작업이 중간에 실패할 수 있다는 거예요. 하지만 진짜 문제는 그 다음이에요:

• 엔지니어가 정리 스크립트를 작성하는 데 시간을 써요
• 수동 개입이 필요한 상황이 늘어나요
• 팀이 기능 구축 대신 데이터 정리에 집중하게 돼요
• 새로운 팀원이 합류하면 이런 “부채”를 배워야 해요

제약조건이 없으면 데이터 손상이 시스템 전체로 퍼져요

제약조건(Constraints)이 없으면 무효한 데이터가 데이터베이스에 저장될 수 있어요. 처음엔 작은 문제로 보이지만, 시간이 지나면서 손상이 시스템 전체로 퍼져요.

제약조건이 없으면 디버깅이 “고고학”이 돼요. 버그가 언제 도입됐는지, 어떤 데이터가 영향을 받았는지 추적해야 해요. 데이터를 신뢰할 수 없게 되고, 엔지니어는 항상 “이 데이터를 믿을 수 있나?”라고 의문을 가져요.

NoSQL “웹스케일”의 함정: 코드에서 ACID를 다시 만들게 돼요

2010년대 중반에는 NoSQL 데이터베이스가 한창 유행이었어요. “웹스케일”을 위해 ACID 보장을 포기하는 게 트렌드였죠. 하지만 Brandur는 이것이 잘못된 트레이드오프라고 주장해요.

”확장성”을 위해 단순한 키-값 저장소를 선택한다고 해볼게요. 당장은 괜찮아 보이지만, 실제로는:

• 애플리케이션 계층이 복잡한 트랜잭션 코디네이터가 돼요
• 버그가 증식해요 (데이터베이스에서 처리하던 것을 이제 코드로 구현해야 하니까요)
• 새로운 팀원의 온보딩이 더 어려워져요
• 시스템을 이해하기 위해 더 많은 코드를 읽어야 해요

대부분의 애플리케이션은 Google 규모에 도달하지 않아요. “ACID냐 스케일이냐”는 잘못된 질문이에요. PostgreSQL 같은 현대적인 ACID 데이터베이스는 대부분의 워크로드에 충분히 스케일돼요.

강력한 보장이 있으면 개발 속도가 빨라져요

반대로, 강력한 ACID 보장을 제공하는 데이터베이스를 선택하면 긍정적인 이차 효과가 있어요:

데이터베이스가 보장을 제공하면, 엔지니어는 “이 데이터가 유효할까?” 대신 “이 기능을 어떻게 구현할까?”에 집중할 수 있어요. 시스템 차원에서 보장해주면 개발자가 신경 쓸 게 줄어들어요.

조직적 영향

데이터베이스 선택은 단순히 기술적 결정이 아니에요. 조직 전체에 파급 효과를 미쳐요:

• 팀 구성: 약한 데이터베이스를 선택하면 데이터를 정리하는 엔지니어가 더 많이 필요해요
• 기술 요구사항: 복잡한 애플리케이션 트랜잭션 로직을 이해할 수 있는 시니어 엔지니어가 필요해요
• 인시던트 대응: 데이터 손상 관련 인시던트가 늘어나요
• 개발 속도: 기능 개발 대신 기술 부채 관리에 시간을 써요

핵심 통찰

Brandur가 가장 강조하는 건 이거예요: “ACID냐 스케일이냐”는 잘못된 질문이라는 거죠. 대부분의 애플리케이션은:

• Google이나 Facebook 규모에 도달하지 않아요
• 단일 PostgreSQL 인스턴스로 충분해요
• 수평 확장이 필요하더라도, 이제는 ACID를 제공하는 분산 데이터베이스가 있어요

“웹스케일”을 위해 ACID를 포기하는 것은 실제로 필요하지 않은 복잡성을 도입하는 거예요. 대부분의 경우, 스케일 문제가 아니라 엔지니어링 문제예요.

지속적 가치

이 글의 진짜 가치는 “PostgreSQL을 써라”는 추천이 아니에요. 대신, 아키텍처 결정이 어떻게 팀의 일상적인 업무 방식을 바꾸는지에 대한 프레임워크를 제공해요.

이 통찰은 데이터베이스를 넘어 모든 아키텍처 선택에 적용돼요:

• 타입 시스템을 선택할 때 (강한 타입 vs. 약한 타입)
• 배포 전략을 정할 때 (수동 vs. 자동)
• 테스트 전략을 설계할 때 (통합 테스트 vs. 단위 테스트)
• 모니터링 도구를 고를 때 (능동적 vs. 반응적)

모든 경우에 질문은 동일해요: “이 선택이 우리 팀이 기능을 구축하게 할까, 아니면 문제를 해결하는 데 시간을 쓰게 할까?”

결론

Brandur Leach의 핵심 메시지는 단순해요: 약한 기반을 선택하면 결국 애플리케이션 코드에서 보장을 다시 만들어야 해요. 그런데 원래보다 더 나쁘게요.

ACID 데이터베이스는 그냥 기술적으로만 좋은 게 아니에요. 팀이 데이터 손상과 싸우는 대신 기능을 구축하게 해줘요. 데이터베이스 아키텍처 결정은 개발 관행부터 채용, 속도까지 영향을 미쳐요.

2017년에 쓰인 이 글은 2025년에도 여전히 관련성이 있어요. 왜냐하면 핵심은 여전히 같거든요: 겉보기에 단순해 보인다고 시스템 수준 보장을 포기하면 장기적으로 복잡성만 증가해요.