데이터베이스, 개발자들이 너무 멀리했나?

과거 개발자들은 객체 지향 프로그래밍(Object-Oriented Programming) 패러다임에 따라 객체 중심 설계(Object-Oriented Design)를 선호했다. 데이터베이스는 객체를 저장하는 수단으로 여겨졌으며, 도메인 모델(Domain Model)과 데이터베이스 간의 직접적인 연결은 지양되었다. 이러한 접근 방식은 ORM(Object-Relational Mapping)의 발전을 이끌었지만, 데이터베이스의 역할은 축소되었다. 하지만, 댓글에서는 이러한 방식이 데이터베이스의 강력한 기능을 활용하지 못하게 했다고 지적한다.

마이크로서비스(Microservices) 아키텍처는 서비스 간의 자율성(Autonomy)을 강조하며, 공유 데이터베이스는 종종 병목 현상(Bottleneck)으로 간주되었다. 각 서비스는 자체 데이터베이스를 소유하는 것이 일반적이었으며, 이는 데이터 일관성(Data Consistency) 문제를 야기했다. 하지만, 댓글에서는 데이터 격리 아키텍처(Data Isolation Architecture)가 오히려 데이터 중복과 복잡성을 증가시켰다고 비판하며, 데이터베이스의 강력한 기능을 활용하는 방안을 모색해야 한다고 주장한다.

GraphQL은 클라이언트가 원하는 데이터를 정확하게 요청할 수 있도록 하여 데이터 쿼리(Data Query)의 유연성을 제공한다. 하지만, GraphQL은 데이터베이스가 이미 제공하는 스키마(Schema), 쿼리 계획(Query Planning), 권한 관리(Authorization) 등의 기능을 다시 구현해야 하는 문제를 야기했다. 댓글에서는 GraphQL이 데이터베이스의 기능을 재발견하는 계기가 되었으며, 데이터베이스의 역할 확대를 고려해야 한다고 주장한다.

최근 데이터베이스는 JSON 지원, 윈도우 함수(Window Functions), CTE(Common Table Expressions), Row-Level Security 등 다양한 기능을 추가하며 발전해왔다. 또한, 자동 쿼리 최적화(Query Optimization)를 통해 성능을 향상시키고 있다. 댓글에서는 이러한 데이터베이스의 발전을 고려할 때, 과거의 개발 방식에 대한 근본적인 질문(Fundamental Question)을 던져야 한다고 주장하며, 데이터 중심 아키텍처(Data-Centric Architecture)로의 전환을 제안한다.