clean-architecture

30장. 데이터베이스는 세부사항이다

Introduction

• 아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아님
• 즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없음
• 명확히 짚고 가자면, 지금 데이터 모델을 말하는 건 아님
  • 애플리케이션 내부 데이터의 구조는 시스템 아키텍처에서 대단히 중요함
• 하지만 데이터베이스는 데이터 모델이 아님
• 데이터베이스는 일개 소프트웨어일 뿐
• 데이터베이스는 데이터에 접근할 방법을 제공하는 유틸리티
• 아키텍처 관점
  • 이러한 유틸리티는 저수준의 세부사항 (메커니즘) 일 뿐, 아키텍처와는 관련이 없음
  • 그리고 뛰어난 아키텍처라면 저수준의 메커니즘이 시스템 아키텍처를 오염시키는 일을 용납하지 않음

관계형 데이터베이스

• 에드거 커드는 1970년에 관계형 데이터베이스의 원칙을 정의함
• 관계형 모델은 계속 성장하여 1980년대 중반이 되자 데이터 저장소의 지배적인 형태가 됨
  • 이 모델은 우아했고, 절제되었으며, 강건했음
• 관계형 데이터베이스는 데이터를 저장하고 접근하는 데 탁월한 기술이었음
• 하지만 관계형 데이터베이스의 기술이 어떻든 결국은 그저 기술일 뿐
  • 그리고 이는 관계형 데이터베이스가 세부사항임을 뜻함
• 관계형 테이블은 특정한 형식의 데이터에 접근하는 경우에는 편리하지만, 데이터를 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요하지 않음
  • 데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 함
• 많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기 저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계

데이터베이스 시스템은 왜 이렇게 널리 사용되는가?

• 어떻게 데이터베이스 시스템이 소프트웨어 시스템과 소프트웨어 기업을 장악할 수 있었을까?
• 한마디로 답하자면, 바로 ‘디스크’ 때문
• 디스크가 반세기동안 회전식 자기 디스크부터 엄청나게 발전할 동안, 프로그래머는 디스크 기술이 가진 치명적인 한 가지 특성으로 인해 괴롭힘을 당함, 바로 느리다는 특성
• 디스크 때문에 피해갈 수 없는 시간 지연이라는 짐을 완화하기 위해, 색인, 캐시, 쿼리 계획 최적화가 필요해짐
• 그리고 데이터를 표현하는 일종의 표준적인 방식도 필요했는데, 이러한 색인, 캐시, 쿼리 계획에서 작업중인 대상이 어떤 데이터인지 알 수 있어야 했기 때문
• 간단히 말해서 데이터 접근 및 관리 시스템이 필요
  • 시간이 지나면서 이러한 시스템은 뚜렷이 구분되는 두 가지 유형으로 구분됨
    • 파일 시스템
    • 관계형 데이터베이스 관리 시스템, RDBMS
• 파일 시스템
  • 문서 기반, document
  • 문서 자체를 자연스럽고 편리하게 저장하는 방법을 제공
  • 일련의 문서를 이름을 기준으로 저장하거나 조회할 때는 잘 동작하지만, 내용을 기준으로 검색할 때는 그리 크게 도움되지 않음
• 관계형 데이터베이스 관리 시스템, RDBMS
  • 내용 기반
  • 내용을 기반으로 레코드를 자연스럽고 편리하게 찾는 방법을 제공함
  • 레코드가 서로 공유하는 일부 내용에 기반해서 다수의 레코드를 연관 짓는 데 매우 탁월
  • 하지만 안타깝게도 정형화되지 않은 문서를 저장하고 검색하는 데는 대체로 부적합
• 두 시스템 모두 데이터를 빠르게 조작할 수 있도록 결국에는 관련 있는 데이터를 RAM 으로 가져옴

디스크가 없다면 어떻게 될까?

• 디스크는 현재 소멸 중인 부품
• 디스크는 RAM 으로 대체되고 있음
• 디스크가 모두 사라진다면, 그래서 모든 데이터가 RAM에 저장된다면 데이터를 어떻게 체계화할 것인가?
  • 데이터를 테이블 구조로 만들어 SQL을 이용해 접근할 것인가?
  • 파일 구조로 만들어 디렉터리를 통해 접근할 것인가?
• 당연히 아니다
• 이 데이터들을 연결 리스트, 트리, 해시 테이블, 스택, 큐 혹은 여타 무수히 많은 데이터 구조로 체계화할 것이며, 데이터에 접근할 때는 포인터나 참조를 사용할 것
• 이것이 프로그래머가 하는 일이기 때문
• 사실 이미 그렇게 하고 있음

세부사항

• 데이터베이스가 세부사항이라고 말하는 이유는 바로 이러한 현실 때문
• 데이터베이스는 그저 메커니즘에 불과함
• 따라서 아키텍처 관점에서 본다면, 데이터가 어떤 형태인지는 절대로 신경 써서는 안 됨
• 정말로 우리는 디스크 자체가 존재한다는 사실조차도 인식해서는 안 됨

하지만 성능은?

• 성능은 당연히 아키텍처적인 관심사
• 하지만 데이터 저장소의 측면에서 성능은 완전히 캡슐화하여 업무 규칙과는 분리할 수 있는 관심사임
• 데이터 저장소에서 데이터를 빠르게 넣고 뺄 수 있어야 하는 것은 맞지만, 이는 저수준의 관심사
• 이 관심사는 저수준의 데이터 접근 메커니즘 단에서 다룰 수 있음
• 성능은 시스템의 전반적인 아키텍처와는 아무련 관련이 없음

개인적인 일화

• RDBMS 도입과 관련해서 싸움
• 저자는 반대함
• 공학적인 부분에서는 저자가 옳았다고 말함
• 하지만 현실은 다름

결론

• 데이터는 중요
• 데이터베이스는 세부사항