05 세부사항 (1)

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

아키텍처 관점에서 데이터베이스는 엔티티가 아니다.

데이터베이스는 일개 소프트웨어일 뿐이며, 데이터에 접근할 방법을 제공하는 유틸리티다.

이러한 유틸리티는 저수준의 세부사항일 뿐이라서 아키텍처와 관련이 없으며, 저수준의 메커니즘이 시스템 아키텍처를 오염시켜서는 안된다.

관계형 데이터베이스

관계형 테이블은 특정한 형식의 데이터에 접근하는 경우에는 편리하지만, 데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요하지 않다.

많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기 저기에서 돌아다니게 허용하지만, 아키텍처 적으로 잘못된 설계이다.

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

그동안 데이터 저장소의 중심에는 디스크가 있었다. 디스크는 방대한 용량의 데이터를 얇은 원판에 담을 수 있도록 발전해왔다. 하지만 느리다는 단점이 있다.

이러한 단점을 완화하기위해 색인, 캐시, 쿼리 계획 최적화가 필요해졌다. 즉, 데이터 접근 및 관리 시스템이 필요했다. 바로 파일 시스템과 관계형 데이터베이스 관리 시스템이다.

파일 시스템은 문서 기반으로, 문서 전체를 자연스럽고 편리하게 저장하는 방법을 제공한다. 문서의 제목을 기준으로 조회하거나 저장하는건 잘 동작하지만, 내용을 기준으로 검색하는건 어렵다.

데이터베이스 시스템은 내용 기반이다. 레코드간 공유하는 일부 내용에 기반해서 다수의 레코드를 연관 짓는 데에 탁월하다. 하지만 정형화되지 않은 문서를 검색하는데는 부적합하다.

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

이제 디스크는 소멸중인 부품이며, RAM으로 대체되고 있다. 디스크가 모두 사라지고 RAM에 저장된다면 데이터를 어떻게 체계화할까?

테이블 구조나 파일 구조로 만드는 대신, 연결 리스트, 트리, 해시 테이블, 스택 큐 등 수많은 데이터 구조로 체계화 할 것이며, 데이터에 접근할 때는 포인터나 참조를 사용할 것이다.

이미 우리는 데이터가 데이터베이스나 파일 시스템에 있더라도, RAM으로 읽은 후에는 다루기 편한 형태로 그 구조를 변경한다.

세부사항

이것이 데이터베이스가 세부사항이라는 이유이다. 데이터베이스는 메커니즘에 불과하며, 디스크와 RAM 사이에서 데이터를 옮길 때 사용할 뿐이다. 아키텍처 관점에서는 데이터가 어디에 어떤 형태로 존재하는지 신경써선 안된다.

하지만 성능은?

성능은 아키텍처와 관련된 관심사가 맞다. 하지만 데이터 저장소 측면에서 성능은 완전히 캡슐화하여 업무 규칙과는 분리할 수 있는 관심사이다. 데이터 저장소에서 데이터에 빠르게 접근하는 것은 저수준의 관심사다.

개인적인 일화

우리는 데이터베이스가 필요한 합리적인 이유없이 필요하다는 인식만으로 소프트웨어에 데이터베이스를 도입한다. 이러한 인식은 기업의 '데이터 자산'은 보호할 필요가 있으며, 자신들의 시스템은 이러한 보호를 약속한다는 데이터베이스 업체의 마케팅에서 비롯되었다.

비슷한 종류로 '엔터프라이즈'라는 단어와 '서비스-지향 아키텍처'라는 개념 또한 현실보다는 마케팅과 더 관련이 깊다.