MongoDB가 나에게 Postgres에 대해 가르쳐준 것

Source: Dev.to

MongoDB를 사용한 것이 오히려 Postgres를 사용한 것보다 Postgres에 대해 더 많이 가르쳐 주었습니다.

제 말에 귀 기울여 주세요. 이전에는 새로운 프로젝트를 시작할 때마다 무조건 Postgres를 선택하는 것이 저의 즉각적인 반응이었습니다. 솔직히 말해서 꽤 안전한 선택이었죠. 하지만 Postgres만 사용하다 보니 그에 대한 이해—즉 장점과 한계—가 제한되었습니다.

사용하지 않음으로써 무언가를 더 많이 배웠다고 말하는 것이 이상하게 들릴 수도 있습니다. 하지만 사실이며, 그래서 이번 글을 시리즈의 첫 번째 글로 계획하고 있습니다. Postgres를 사용하지 않음으로써 정말 많은 것을 배웠기 때문입니다.

어떻게 처음에 MongoDB를 사용하게 되었나요?

제가 합류했을 때 현재 스타트업은 이미 MongoDB를 선택한 상태였습니다. 이는 현장의 경험과 스키마가 급격히 변하고 있다는 사실 때문이었습니다. 사실상 무제한에 가까운 스키마 유연성을 제공하는 문서 기반 데이터베이스가 자연스러운 선택이었습니다.

하지만 이 유연성에는 대가가 따랐습니다

처음에는 수백 번의 왕복 마이그레이션 속에 얽힌 “마이그레이션 폴더 오브 데스”가 없다는 것이 큰 기쁨이었습니다. 스키마 변경이 빠르고—Pydantic과 결합되면—코드베이스 전반에 걸쳐 높은 일관성을 유지할 수 있었습니다.

아무것도 깨지지 않았고, 시스템은 언제나 계속 실행되었습니다. 그러나 점점 느려지고 비용이 증가했습니다. 엄격한 스키마가 없으니 검증을 애플리케이션 코드에서 반복해서 수행해야 했으며, 이는 쓰기뿐 아니라 읽기에서도 마찬가지였습니다.

대규모로 Pydantic 검증이 이루어지면서 서비스의 CPU 비용이 눈에 띄게 증가했습니다. 이는 검증이 전체 모델에 의존했기 때문에 효과적인 프로젝션 사용이 제한된 것이 원인이었습니다. 간단한 쿼리조차 전체 문서 읽기로 바뀌었습니다.

그때 저는 Postgres의 의도적인 경직성을 새롭게 인식하게 되었습니다. 검증을 데이터와 바로 옆에 두는 것이 효율적인데, 이는 최적화된 덕분일 뿐만 아니라 검증이 한 번만 일어나기 때문입니다. Postgres 제약조건은 강력하여 가정을 보장으로 바꿔줍니다.

그렇다고 해도 비즈니스 로직에 가까운 곳에서 검증을 수행하는 것이 여러 면에서 좋습니다. 마이그레이션을 더 잘 관리했다면 방어적이고 비용이 많이 드는 애플리케이션 코드를 줄일 수 있었을 것입니다. 그리고 MongoDB 스키마 검증—제가 충분히 활용하지 못한 기능—도 잊지 말아야 합니다.

MongoDB의 유연성에 처음 느꼈던 기쁨에서 저는 중요한 진실을 깨달았습니다: 스키마에 대한 규율은 사라지지 않으며, 그 규율이 애플리케이션 코드에 존재할지 데이터베이스에 존재할지는 선택할 수 있습니다.