field notes

백엔드를 만들 때 가장 위험한 사고방식은 "앱 레이어에서 막으면 된다"는 것이다. 마이크로서비스, GraphQL 게이트웨이, 미들웨어 — 어디선가 한 곳만 새도 끝난다.

RLS는 데이터베이스 자체에 권한을 새기는 방식이다. SELECT, UPDATE, DELETE가 정책에 위배되면 DB가 거부한다. 앱 코드의 버그와 무관하게 작동한다.

추가 비용? 거의 없다. Postgres는 RLS를 위해 설계되었다. 단, 정책을 *틀리게* 쓰는 건 가능하니, has_role() 같은 SECURITY DEFINER 함수로 재귀 검사를 분리해야 한다.

초기 LLM 통합의 가장 큰 골치는 출력 일관성이었다. 같은 프롬프트에 어떤 날은 ```json 블록을, 어떤 날은 자연어 설명을, 어떤 날은 둘 다 섞어 보냈다.

Tool Calling (Function Calling)은 이 문제를 구조적으로 해결한다. JSON Schema로 응답 형태를 강제하면 모델이 그 형태로만 답한다. 파싱 코드 = 0줄.

Lovable AI Gateway에서도 동일하게 작동한다. brand-compiler · brand-diagnose Edge Function이 모두 이 방식 — 그래서 한 번도 클라이언트에서 try/catch JSON.parse 실패가 난 적이 없다.

AI 코딩 도구의 진짜 가치는 *타이핑 속도*가 아니다. 머릿속 설계와 화면 결과물 사이의 거리가 0에 가까워지는 것 — 그게 핵심이다.

그러나 그 설계를 할 줄 모르면 도구는 무용지물이다. 어떤 컴포넌트로 분리할지, 어떤 상태를 어디에 둘지, 어떤 API를 호출할지 — 이건 여전히 사람의 영역이다.

결론: 바이브 코딩으로 잘 만드는 사람은 "코딩을 안 하는 사람"이 아니라 "코딩을 너무 잘 알아서 매번 직접 칠 필요가 없는 사람"이다.

전통적 백엔드는 인프라 비용이 컸다. 서버 1대 + 모니터링 + 백업 + 보안패치 — DevOps에 시간의 30%가 갔다.

Edge Function은 이 모든 걸 0으로 만든다. 코드를 쓰면 글로벌 분산 + 자동 스케일 + 자동 SSL — 비용은 트래픽만큼만.

1인 스튜디오에게 이건 단순 비용 절감이 아니라 *집중력의 회수*다. 인프라에 쓸 시간을 제품 사고에 쓸 수 있다는 것 — 그게 차별점이 된다.

10년 동안 hex로 디자인 시스템을 짰다. 다크 모드를 만들 때마다 "이 빨간색이 너무 튀네" 같은 미세 조정이 끝없었다.

oklch는 인간 시각 모델 기반이라 L(명도) 값을 동일하게 두면 색상이 달라도 같은 명도로 *보인다*. 즉, 시스템적으로 일관성을 만들 수 있다.

Tailwind v4 + Lovable이 oklch를 1급 시민으로 다루기 시작했다. 지금이 옮길 가장 좋은 타이밍이다.