개발자들이 Supabase, LangChain, PostHog, Neon을 싫어하는 이유를 일주일 동안 조사하며 발견한 것

Reddit이나 Hacker News에서 충분히 시간을 보내다 보면 어떤 패턴을 발견하게 될 것입니다. 며칠마다 누군가 다음과 같은 글을 올립니다.

“Supabase의 RLS (Row Level Security) 때문에 미칠 것 같아요”
“LangChain은 수천 개의 추상화로 인한 죽음(death by a thousand abstractions)이에요”
“Neon의 콜드 스타트 (cold starts)가 API 응답 시간을 망치고 있어요”
“PostHog의 자동 캡처 (autocapture)는 그냥 노이즈일 뿐이에요”

저는 이 네 가지 도구를 모두 사용해 보았습니다. 그리고 네, 저도 그 고통을 느껴봤습니다. 하지만 저는 정말로 얼마나 심각한지 알고 싶었습니다. 단순히 느낌(vibes)이 아니라, 실제로 낭비된 시간 말입니다. 그래서 여유 시간이 있는 학생으로서 조금 무모한 일을 저질렀습니다.

제대로 조사해 보기로 한 것입니다.

GitHub 이슈, Reddit 스레드, Hacker News 댓글, 그리고 Discord의 불만 사항들을 모두 읽었습니다. 불만 사항들을 집계하고 분류하는 데는 AI의 도움을 받기도 했습니다. (네, AI의 도움을 받았습니다. 저는 저널리즘의 순수주의자가 아닌 학생이라는 점을 숨기지 않겠습니다.)

제가 배운 내용은 다음과 같습니다.

요약하자면:

이 네 가지를 모두 사용하는 팀의 경우, 이를 합치면 일주일에 40시간 이상의 비기능적 작업(non-feature work)이 발생합니다. 기본적으로 엔지니어 한 명이 도구와 싸우는 데만 시간을 쓰고 있는 셈입니다.

그리고 여기서 반전은, 이러한 문제들 중 상당수는 이미 해결책이 존재한다는 것입니다. 사람들이 단지 그 방법을 모를 뿐입니다.

Supabase RLS — 가장 큰 함정
Supabase는 스스로를 “주말 안에 구축 가능”하다고 마케팅합니다. 하지만 곧 Row Level Security (RLS)라는 벽에 부딪히게 됩니다.

“PostgreSQL을 더 잘 배워야 한다는 건 알지만, 속았다는 기분이 듭니다.” — 수천 명을 대변하는 어느 Reddit 사용자.

RLS 정책은 단순한 액세스 규칙이 아닙니다. 그것은 모든 쿼리와 함께 인라인으로 실행되는 PostgreSQL 표현식입니다. 정책이 실패하면, 왜 실패했는지에 대한 단서 없이 일반적인 “permission denied (권한 거부)” 메시지만 받게 됩니다.

한 엔지니어는 RLS를 디버깅한다는 것은 9개의 서로 다른 로그 탭을 열고 타임스탬프를 수동으로 대조하는 것을 의미한다고 말했습니다. 버그 하나를 잡기 위해 9개의 탭이라니 말이죠.

LangChain — 내가 AI 에이전트를 이것으로 만들지 않아 다행인 이유
저는 Kommit(저의 AI 커밋 CLI)을 만들 때 LangChain을 사용할 뻔했습니다. 사용하지 않아서 정말 다행입니다.

사람들은 LangChain을 디버깅하는 것을 "눈물이 날 때까지 추상화의 양파 껍질을 까는 것"이라고 묘사합니다. 단순한 API 호출 하나가 PromptTemplate → OutputParser → Chain → AgentExecutor → LCEL 파이프 연산자(pipe operators)로 변합니다.

한 팀은 1년 만에 LangChain을 완전히 제거했습니다. 그들은 이렇게 말했습니다: "기능을 만드는 것만큼이나 LangChain의 내부 동작(internals)을 이해하는 데 많은 시간을 소비했습니다."

가장 최악인 부분은 무엇일까요? 바로 숨겨진 LLM 호출입니다. 한 개발자는 에이전트(agent)가 루프 내에서 잘못된 도구(tool)를 14번이나 호출하여, 의미 없는 헛소리(gibberish)를 반환하기 전에 API 크레딧 40달러를 태워버렸다고 보고했습니다.

제 의견은 이렇습니다: 에이전트 오케스트레이션(agent orchestration)이 정말로 필요한 경우가 아니라면, 가공되지 않은 OpenAI/Anthropic SDK를 사용하세요. LangGraph가 더 낫긴 하지만 여전히 복잡합니다.

PostHog — 데이터 정리 세금
PostHog의 자동 캡처(autocapture)는 축복이자 저주입니다. 클릭, 분노의 클릭(rageclicks), 양식 제출 등 무엇이든 모든 것을 추적합니다.

하지만 그 후에는 노이즈를 걸러내는 데 수 시간을 소비하게 됩니다.

제가 발견한 한 GitHub 이슈는 이렇습니다: 한 개발자가 사용자가 날짜 선택기(date picker)에서 위/아래 화살표를 클릭할 때 $rageclick 이벤트가 발생하는 것을 막으려 노력하고 있었습니다. 이는 정상적인 동작이지 분노의 클릭이 아닙니다.

PostHog에는 "이벤트 드롭(drop events)" 변환 기능이 있지만, 이는 사후 대응적입니다. 난장판이 된 후에 뒤처리를 하는 셈이죠.

효과적인 방법: 첫날부터 자동 캡처를 비활성화하고 스키마(schema)를 사용하여 명시적인 이벤트 추적(explicit event tracking)을 구현하세요. 지루하지만 주말을 지켜줍니다.

Neon — 잠들기 전까지만 멋진 서버리스(serverless)
Neon의 스케일 투 제로(scale-to-zero)는 비용을 절감해 줍니다. 하지만 데이터베이스가 깨어날 때, 300~700ms의 콜드 스타트(cold start)가 발생합니다. 무료 티어에서는 상황이 더 심각합니다.

그리고 커넥션 풀링(connection pooling)은 어떨까요? 트랜잭션 모드(transaction mode)로 PgBouncer를 사용합니다. 이는 SET search_path와 준비된 문구(prepared statements)가 깨진다는 것을 의미합니다. 앱이 로컬(직접 연결)에서는 잘 작동하지만, 프로덕션(풀링된 연결)에서는 실패합니다. 참 즐거운 경험이죠.

해결책: 최소 컴퓨팅 크기(minimum compute size)를 설정하여 워밍업 상태를 유지하거나, 콜드 스타트를 받아들이세요. 또한 마이그레이션(migrations)을 위한 직접 연결용과 풀링된 연결용, 두 개의 커넥션 문자열(connection strings)을 유지하세요.

예상치 못했던 패턴
거의 모든 문제는 세 가지 범주로 나뉩니다:

누출되는 추상화(Leaky abstractions) - 도구가 복잡성을 숨기다가 결국 문제가 생기면, 어차피 내부 동작을 이해해야만 합니다.

설정 피로 (Configuration fatigue) - 너무 많은 환경 변수 (env vars), YAML 파일, 그리고 기묘한 방식으로 상호작용하는 대시보드 설정들.

데이터/스키마 드리프트 (Data/schema drift) - 마이그레이션 (migrations) 대신 대시보드에서 이루어지는 변경 사항, 또는 거버넌스 (governance) 없이 쌓여가는 이벤트들.

이 중 어느 것도 새로운 것은 아닙니다. Joel Spolsky는 2002년에 누출되는 추상화 (leaky abstractions)에 대해 글을 쓴 적이 있습니다. 하지만 왠지 모르게 모든 새로운 도구들은 똑같은 실수를 반복합니다.

이 글을 쓰는 목적
도구들을 비난하려고 이 글을 쓰는 것이 아닙니다. 이 도구들은 모두 잘 설계되었으며 실제 문제들을 해결해 줍니다.

하지만 인턴십을 찾는 학생으로서, 저는 다음과 같은 점을 이해하고 싶었습니다: 엔지니어들이 실제로 싫어하는 것은 무엇인가? 만약 제가 그 문제의 작은 조각이라도 해결할 수 있는 무언가를 만들 수 있다면, 어쩌면 그 문제와 싸우는 대신 그것을 만드는 대가로 보상을 받을 수 있을지도 모르기 때문입니다.

이미 몇 가지 아이디어가 있습니다. 하지만 우선, 이 조사를 Dev.to의 작은 시리즈로 전환하려고 합니다. 다음 포스트는 다음과 같습니다: “조사 과정에서 발견한 해결되지 않은 세 가지 문제 (그리고 내가 다음에 만들 것).”

마지막으로 한 가지 더
만약 여러분이 Supabase, LangChain, PostHog, 또는 Neon을 사용하고 있다면 — 여러분의 가장 큰 고충 (pain point)은 무엇인가요? 저는 진심으로 궁금합니다. 그중 하나에 대한 해결책을 만들어 보려고 할지도 모릅니다.

댓글을 남겨주시거나 GitHub 또는 Dev.to에서 저를 찾아주세요.

– 터미널에서 너무 많은 시간을 보내는 2학년, Mujib.