00:00:00Postgres 데이터베이스가 바로 API가 되고 백엔드 코드를 전혀 짤 필요가 없다면 어떨까요?
00:00:05API를 구축할 때마다 매번 똑같은 백엔드 코드를 반복해서 작성합니다. 라우트, 컨트롤러, 유효성 검사, 인증 등 이 모든 게
00:00:14데이터베이스와 통신하기 위해서죠. 그러다 컬럼 하나만 바꿔도 모든 게 망가집니다. 커스텀 백엔드 코드도, 컨트롤러도, ORM 레이어도 필요 없습니다.
00:00:21PostgREST가 해주는 일이죠. 수파베이스(Supabase)를 지탱하는 엔진이기도 합니다. 심각한 프로덕션 트래픽도 처리하며, 단 몇 분 만에
00:00:29그 방법을 보여드리겠습니다.
00:00:31API를 구축해 보셨다면, 이 방식은 전체 스택에서 가장 짜증 나는 고충들을 해결해 줄 것입니다.
00:00:40첫째는 중복 로직입니다. 데이터베이스에서 데이터를 정의하고,
00:00:44다른 곳에서 액세스 규칙과 백엔드 코드, 유효성 검사를 또 정의하죠.
00:00:49그러고 나서 응답 처리 로직을 또 다른 곳에 만듭니다. 같은 시스템인데 여러 레이어가 존재하고, 그만큼 망가질 기회도 많아집니다.
00:00:56PostgREST는 이 모든 과정을 단축합니다. 깃허브 스타 26,000개 이상을 보유하고 있으며 수파베이스에서 프로덕션 규모로 사용됩니다.
00:01:03여러분의 스키마를 단 몇 분 만에 프로덕션용 REST API로 바꿔줍니다. ORM도, 컨트롤러도 없습니다.
00:01:10보안이 데이터베이스 안에 존재하므로 중복과 유지보수가 줄어들고, 지루한 연결 작업에 쓰는 시간도 훨씬 단축됩니다.
00:01:19직접 보여드리죠. 워크플로우 속도를 높여주는 코딩 도구를 좋아하신다면 꼭 구독해 주세요.
00:01:24항상 새로운 영상이 올라옵니다.
00:01:26자, 이제 실제로 만들어 봅시다. 여기 설정이 있습니다. 컨테이너 3개면 충분합니다.
00:01:32Postgres, PostgREST, 그리고 문서용 Swagger UI입니다.
00:01:38여기 Docker Compose 파일이 있습니다. 별거 없습니다. 그저 3개의 서비스를 서로 연결했을 뿐입니다.
00:01:45확실한 명령어인 Docker Compose로 실행하면 준비 끝입니다.
00:01:51의존성을 설치하거나 서버를 설정할 필요도 없죠. 이제 데이터베이스를 살펴봅시다.
00:01:55여기서 도커 명령어를 실행하면 끝입니다. 아주 간단한 할 일(todos) 테이블이죠. ID, 제목, 완료 여부, 생성일 등 기본적인 내용입니다.
00:02:04그게 전부입니다. 하지만 바로 이 부분이 유용해지는 지점입니다.
00:02:09행 단위 보안(Row Level Security, RLS)입니다. 누가 무엇에 액세스할 수 있는지를 데이터베이스 내부의 SQL로 직접 정의합니다.
00:02:17시스템의 다른 곳에 백엔드 인증 로직이 따로 있을 필요가 없죠. 여기 정책을 보세요.
00:02:22익명 사용자에게 전체 권한을 주도록 설정했습니다. 일단은 모든 게 허용되죠. 이제 보세요.
00:02:29이 curl 명령어로 todos를 호출하면 끝입니다. Postgres에서 바로 JSON 데이터가 나옵니다.
00:02:35API 코드는 전혀 없습니다. 더 나아가서 필터링을 해보겠습니다. 즉시 작동하죠.
00:02:41정렬을 해봐도 바로 됩니다. 이제 행을 하나 더 만들어 보죠. JSON 바디로 POST 요청을 보내면 끝입니다.
00:02:50이미 데이터베이스에 반영되었습니다. 따라잡으려고 애쓰는 ORM 레이어 같은 건 없죠.
00:02:56그리고 사람들이 정말 놀라는 부분은 바로 이겁니다. 자동 생성된 Swagger UI, OpenAPI 문서가 그냥 있습니다.
00:03:04열어보면 완전한 인터랙티브 API가 나타납니다. 모든 걸 탐색하고 엔드포인트를 테스트하고 스키마를 볼 수 있죠.
00:03:11아무것도 없는 상태에서 1분 만에 CRUD, 필터링, 정렬, 페이지네이션, RLS 기반 인증, 문서까지 갖춘 겁니다.
00:03:21사람들이 이걸 왜 쓸까요? 그것만으로 부족하다면, 전통적인 백엔드 작업에는 일종의 세금이 따르기 때문입니다.
00:03:26그리고 그 세금의 대부분은 제품 개발이 아니라 유지보수 작업이죠.
00:03:33일반적인 스택을 생각해보면 Express, Prisma, 컨트롤러, 서비스, 유효성 검사가 한곳에 있고,
00:03:40인증은 다른 곳에 있고, 데이터베이스 로직은 또 완전히 다른 곳에 있습니다.
00:03:45반면 PostgREST는 스키마가 API를 정의하고, 보안은 RLS가 담당합니다.
00:03:52관계는 이미 데이터베이스에 존재하죠. 따라서 데이터 주위에 번역 레이어를 구축하는 대신, 데이터를 올바르게 노출할 뿐입니다.
00:04:02그건 아주 다른 방식입니다. 커스텀 백엔드와 비교해 보면, 여러분이 모든 걸 직접 짜야 합니다.
00:04:07유연성은 있겠지만 유지보수해야 할 코드도 훨씬 많아집니다.
00:04:13PostgREST는 더 단순합니다. REST와 Postgres의 조합이죠. 보안은 데이터베이스에 있고 미들웨어나 라우트 핸들러에 흩어져 있지 않습니다.
00:04:23API가 스키마를 따르기 때문에 유지보수 비용이 낮게 유지됩니다. 그래서 사람들이 좋아하는 거죠.
00:04:28하지만 공정하게 말하자면, 여기서 문제가 생기기도 합니다. 방식이 깔끔해 보이면 모든 걸 해결해 줄 거라고 믿기 시작하거든요.
00:04:34이게 모든 걸 해결해 주지는 않습니다. 그쵸? 여전히 주의해야 할 것들이 있습니다.
00:04:38트레이드오프가 존재하며, 이걸 시작하기 전에 무엇을 조심해야 할지 알아야 합니다.
00:04:43사람들이 좋아하는 이유는 명확합니다. 구축 속도가 빠르다는 거죠. 아이디어에서 실제 작동하는 API까지 정말 빠르게 갈 수 있습니다.
00:04:51확장성 또한 매우 뛰어납니다. 수파베이스가 그 증거죠.
00:04:55그들도 이걸 쓰고 있으니까요. 하지만 단점은 과도한 RLS 사용이 데이터베이스 부하를 늘릴 수 있다는 점입니다.
00:05:02따라서 설계를 신중하게 해야 합니다. 복잡한 로직은 수많은 SQL 함수나 뷰를 만들게 할 수도 있죠.
00:05:10누구는 그걸 좋아하겠지만 누구는 싫어할 겁니다. 그럼 이걸 써보거나 시도해 봐야 할까요?
00:05:15적절한 프로젝트라면 그렇습니다. 프로토타입이나 MVP, 혹은 Postgres 중심의 서비스를 만든다면 당연히 시도해 볼 만하죠.
00:05:23더 빨리 움직이고 코드를 덜 쓰게 될 것이며, 규칙을 데이터베이스로 내려보냄으로써 더 강력한 기본 보안을 얻게 됩니다.
00:05:32물론 앱 로직이 정말 복잡하다면 엣지 케이스를 위해 그 위에 얇은 백엔드 레이어(BFF 레이어)를 두고 싶을 수도 있습니다.
00:05:40하지만 그 경우에도 Postgres가 밑바닥의 힘든 일 대부분을 처리할 수 있습니다. 결론은 이겁니다. PostgREST를 쓰면 더 빨리 출시하고, 더 잘 보호하고, 덜 관리하게 됩니다.
00:05:50데이터베이스가 실제 데이터의 원천이 되고, API는 별개의 시스템이 아니라 거기서 자연스럽게 파생되어 나옵니다.
00:05:58이런 코딩 도구와 팁이 마음에 드셨다면 Better Stack 채널을 구독해 주세요. 다음 영상에서 뵙겠습니다.