Skip to content

Latest commit

 

History

History
70 lines (39 loc) · 5.78 KB

File metadata and controls

70 lines (39 loc) · 5.78 KB

30장 컴포넌트는 세부사항이다

아키텍처 관점에서 데이터베이스는 엔티티가 아니고, 세부사항이다.

데이터베이스는 데이터 모델이 아닌, 일개 소프트웨어일 뿐이다. 데이터베이스는 데이터에 접근할 방법을 제공하는 유틸리티다. 그러므로 뛰어난 아키텍트라면 저수준의 메커니즘에 해당하는 데이터베이스가 시스템 아키텍처를 오염시키는 일을 용납하지 않는다.

관계형 데이터베이스

관계형 데이터베이스는 데이터 저장소의 지배적인 형태가 되었다. 하지만 결국 그 기술이 얼마나 뛰어나든 그저 기술이며, 세부사항에 해당한다.

데이터를 테이블에 행 단위로 접근한다는 사실은 아키텍처적으로 볼 때 전혀 중요하지 않다. 애플리케이션의 유스케이스는 이러한 방식을 알아서도 관여해서도 안된다.

많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계다. 이렇게 하면 유스케이스, 업무 규칙, 심지어 UI 조차 관계형 데이터 구조에 결합되어 버린다.

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

어떻게 데이터베이스 시스템이 SW 시스템과 SW 기업을 장악할 수 있었을까? 한마디로 답하면, '디스크' 때문이다.

디스크는 지난 반세기동안 많은 발전을 거쳐왔지만, '느리다' 라는 특성을 개선할수는 없었다.

디스크로써 피해갈 수 없는 시간 지연이라는 짐을 완화하기 위해, 색인, 캐시, 쿼리 계획 최적화가 필요해졌다. 그리고 데이터를 표현하는 표준적인 방식, 즉 작업 중인 대상이 어떤 데이터인지 알수 있는 방법이 필요했다.

간단히 말해, 데이터 접근 관리 및 시스템이 필요했다. 시간이 지나며 이러한 시스템이 두 가지 유형으로 분리되었는데, 하나는 파일 시스템이었고, 다른 하나는 **관계형 데이터베이스 관리 시스템(RDBMS)**이었다.

파일 시스템과 데이터베이스 시스템은 각각의 차이를 보인다.

  • 파일 시스템
    • 문서 기반이다.
    • 문서 전체를 자연스럽게 저장하는 방법을 제공한다.
    • 이름 기준 저장, 조회에는 잘 동작하지만, 내용을 기준 검색할 때는 크게 도움되지 않는다.
  • 데이터베이스 시스템
    • 내용 기반이다.
    • 내용을 기반으로 레코드를 자연스럽게 찾는 방법을 제공한다.
    • 하지만 정형화 되지 않은 문서를 저장하고 검색하는 데는 대체로 부적합하다.

이들 두 시스템은 데이터를 디스크에 체계화해서, 각 시스템에 특화된 방식으로 접근해야 할 때 가능한 효율적으로 데이터를 저장하고 검색할 수 있도록 한다.

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

한때는 디스크가 성행했지만, 이제는 소멸 중인 부품이다.

그렇다면 디스크가 모두 사라진다면, 그래서 모든 데이터가 RAM에 저장된다면 데이터를 어떻게 체계화할 것인가?

이 데이터들을 연결 리스트, 트리, 해시 테이블, 스택, 큐 혹은 여타 무수히 많은 데이터 구조로 체계화할 것이며, 데이터에 접근할 때는 포인터나 참조를 사용할 것이다.

사실 이를 곰곰히 생각해보면, 이미 이런 방식으로 일하고 있다는 사실을 알아챌 수 있다. 데이터베이스나 파일시스템에 데이터가 존재해도, 다루기 편리한 형태로 그 구조를 변경한다. 리스트, 집합, 스택, 큐, 트리 등 입맛에 맞는 임의의 구조로 말이다. 데이터를 파일이나 테이블 형태로 그대로 두는 경우는 거의 없다.

세부사항

데이터베이스가 세부사항이라 말하는 이유는 바로 이러한 현실 때문이다. 데이터베이스는 그저 메커니즘에 불과하며, 디스크 표면과 RAM 사이에서 데이터를 옮길 때 사용할 뿐이다.

따라서 아키텍처 관점에서 본다면, 우리는 디스크 자체가 존재한다는 사실조차도 인식해서는 안된다.

하지만 성능은?

성능은 분명 아키텍처와 관련된 관심사이다. 하지만 데이터 저장소의 차원에서 데이터를 빠르게 넣고 빼는 관심사는 저수준의 관심사다. 또한 이 관심사는 저수준의 데이터 접근 메커니즘 단에서 다룰 수 있다. 성능은 시스템의 전반적인 아키텍처와는 아무런 관련이 없다.

개인적인 일화

네트워크 관리 시스템을 구축하여 판매하고 있었는데, 데이터를 간단한 랜덤 액세스 파일 형태로 저장했다. 데이터 사이에 내용에 기반한 관계가 없었기 때문이다.

하지만 마케팅 담당자와 하드웨어 엔지니어는 RDBMS를 쉬지않고 외쳤다. 결국 RDBMS를 선택하게 되었는데, 그 이유는 고객이 원해서였다.

고객이 원했던 그 인식의 배경을 생각하보면, 당시 데이터베이스 업체에서 실시한 마케팅 캠페인에서 비롯된 것이었다.

오늘날에도 같은 종류의 마케팅 캠페인을 볼수 있으며, '엔터프라이즈'라는 단어와 '서비스-지향 아키텍처'라는 개념은 현실보다는 마케팅과 관련이 더 깊다.

결론

체계화된 데이터 구조와 데이터 모댈은 아키텍저적으로 중요하다. 하지만, 데이터를 디스크 위에서 이리저리 옮기는데 필요할 뿐인 기술과 시스템은 아키텍처적으로 중요치 않다. 관계형 데이터베이스는 후자와 훨씬 관련이 깊다. 데이터는 중요하지만, 데이터베이스는 세부사항이다.