RLS라는 게 나타났다
로그인을 만들기로 했으니, 이제 Supabase의 RLS(Row Level Security) 정책이라는 걸 설정해야 했다.
쉽게 말하면 "이 사람은 이 데이터만 볼 수 있고, 저 사람은 저 데이터만 볼 수 있다"를 DB 단에서 제어하는 거다.
말로 들으면 당연한 건데, 이걸 하나하나 설정하고, SQL을 업데이트하고, 맞추는 과정이 고통 그 자체였다.
설정하고 테스트하면 안 되고, 고치면 다른 데가 터지고. 이건 뭐 두더지 잡기도 아니고.
혹시 AI가 멍청한 건가?
처음엔 Antigravity 탓을 했다.
이게 안 되는 이유가 AI가 RLS를 제대로 모르는 건가? 싶어서 다른 도구로 옮겨봤다. Opus도 써보고, 이것저것 다 해봤다.
결론은 — 어디서 해도 잘 안 됐다.
지금 생각하면 AI의 문제라기보다 RLS 정책만으로 로그인과 권한 구조를 전부 가져가는 것 자체가 빡센 접근이었던 것 같다.
근성의 사나이
하지만 내가 또 누군가. 근성의 사나이다.
무대뽀로 고치고, AI 채찍질하고, 또 고치고. 그러다 보니 어떻게어떻게 로그인 구성을 만들어냈다.
되긴 된다. 내가 다 이해하고 만든 건 아니지만, 되긴 된다.
SaaS가 뭔데?
로그인을 만들고 나니 자연스럽게 다음 질문이 떠올랐다.
우리 병원 말고 다른 병원에도 쓸 수 있게 만들려면?
사람들이 자꾸 SaaS, SaaS 하길래 찾아보니, 여러 곳에서 쓸 수 있게 만드는 게 그런 거였다. 그래서 테넌트 구조라는 걸 만들기 시작했다.
이건 로그인 구조 위에 한 겹만 덮어씌우면 되는 거라 생각보다 어렵진 않았다.
여기까지는 좋았다.
"그건 일반적인 구조가 아닙니다"
다른 분이랑 이야기하다가 한 마디를 들었다.
"지금 만들고 있는 거, 일반적인 풀스택 구조가 아니에요."
네? 나야 아무것도 모르니까 — 그럼 제가 하고 있는 건 뭔가요?
알고 보니 지금까지 Supabase가 백엔드 역할까지 같이 해주고 있었던 거다. 프론트엔드에서 DB를 직접 찌르는 구조.
그분 말씀으로는, 이건 나중에 무조건 유지보수 문제가 생길 거라고. 아예 갈아엎는 게 낫다고 하셨다.
일반적인 구조인 프론트엔드 + 백엔드 + DB를 따르고, 어차피 Supabase 쓰고 있으니 DB만 Supabase로 쓰라는 것이었다.
백엔드는 뭘로?
이건 또 뭔 말이야, 싶어서 찾아보고 AI에게 물어봤다.
이해는 했는데 그러면 백엔드는 뭘로 하지?
파이썬을 추천하시는 분들도 있었다. 그런데 그러면 프론트엔드랑 또 다른 언어를 써야 하잖아. 고민이 됐다.
여러 AI에게 물어보니 그냥 NestJS 쓰라길래, 그냥 NestJS 쓰기로 했다.
뭐 어차피 내가 짜나. AI가 짜지.
2주의 마이그레이션
그렇게 프론트엔드 + Supabase 구조에서 프론트엔드 + NestJS + Supabase(DB) 구조로 마이그레이션을 시작했다.
DB에 쌓인 게 별로 없어서 그런가, 데이터 이전 자체는 오래 걸리지 않았다. 하지만 고민하고, 구성하고, 다시 만들고 하는 데 프로젝트 진척은 못 한 채로 2주를 보냈다.
2주 동안 새로운 기능은 하나도 안 만들고, 구조만 뜯어고친 셈이다.
삽질이 쌓여 실력이 된다
지금 돌이켜보면, 이런 삽질을 많이 했기 때문에 지금 조금 더 나은 상태가 된 게 아닐까 싶다.
구조를 나누고 나니 로그인도 더 깔끔하게 돌아갔다. RLS 정책 하나로 로그인과 권한을 전부 끌고 가는 건 확실히 무리였던 것 같다.
물론 지금의 JWT 토큰 기반 구조도 내가 100% 이해하고 있는 건 아니다. 하지만 적어도 전보다는 왜 이렇게 하는지 감이 온다.
이제 재정비를 마쳤다. 다시 만들기 시작할 때다.
다음 편에서 계속.