DevNinja

결론부터 말하자면, Claude Code를 사용하는 사람이 obra(Jesse Vincent)가 만든 Superpowers 플러그인을 설치하지 않으면 진정한 의미의 손해다. 이 플러그인을 설치하기 전에는 Claude에게 "기능을 만들어 달라"고 하면 곧바로 코드부터 작성했지만, 설치한 이후에는 알아서 브레인스토밍부터 시작해 계획을 세우고, TDD로 구현하며, 발행 직전에는 코드 리뷰까지 수행한다. 이것이 Claude Superpowers 스킬의 핵심이다. 이 글에서는 IT에 익숙하지 않은 사람도 이해할 수 있도록, "스킬"이라는 개념이 무엇인지부터 obra superpowers가 다른 도구와 어떻게 다른지, 실제 비포/애프터 차이가 어떠했는지를 모두 풀어보고자 한다. AI 코딩 자동화를 한다며 ChatG..

결론부터 쎄게 박고 시작하자LLM이 다른 언어로 컨버팅 한번에 "딸깍" 안된다. 이 글은 실험 후기가 아니라 학계 통계 정리글이다. 누가 LLM에게 "이 Python 코드 Go로 바꿔줘" 한 줄을 던져 깨진 적이 있다면 — 그것은 본인의 프롬프트 문제가 아니라 모델이 본질적으로 이 작업을 잘 하지 못한다는 사실이며, ICSE 2024 학회 논문에서 1700 샘플로 측정된 결과이다. 한 번에 끝내는 번역(one-shot translation)은 평균 정확도가 절반에도 미치지 못한다. 이를 모른 채 계속 시키기 때문에 매번 깨지는 것이다. 비유하자면, 외국어 통역사에게 사전 없이 즉석으로 의학 논문을 통역시키는 것과 비슷하다. 단어는 옮겨지지만 문맥이 박살난다. 이 글에서 풀어낼 4가지 질문이다. (1)..

운영 중에 504가 떴을 때 일단 nginx의 proxy_read_timeout부터 늘리고 보는 사람이 많은데, 그것이 답이 아닐 수 있다. 진짜로 끊은 주체가 nginx가 아니라 ALB(Amazon 로드밸런서)나 Cloudflare인 경우가 더 자주 있으며, 근거 없이 nginx만 만지면 같은 에러가 또 발생한다. 각설하고 결론부터 박는다. 504 Gateway Timeout 원인을 nginx에만 떠넘기면 ALB가 끊은 케이스를 놓친다. 4단 스택(backend → nginx → ALB → Cloudflare)에서는 누가 먼저 timeout을 만료시키느냐에 따라 응답 status 한 줄과 식별자 헤더 3개(X-Nginx-Trace, X-Amzn-Trace-Id, CF-Ray)의 존재·부재 조합이 결정론..

SQL 표준 표를 보면 REPEATABLE READ 칸에 phantom read "허용"이라고 명확히 적혀 있다. 학교에서도, 책에서도, 인터넷 블로그 99%가 그 표를 그대로 베껴 옮긴다. 그러나 정작 MySQL InnoDB에서 직접 돌려보면 phantom은 발생하지 않는다. 표가 거짓말을 하는 것인가 싶을 정도이다. 면접에서 "MySQL 기본 격리 수준이 무엇이며 phantom read를 막아주는가?"라는 질문이 나오면 답이 갈린다. 표를 외운 사람은 "RR이고 phantom은 막지 못한다"라고 답하고, MySQL을 실제로 다뤄본 사람은 "RR이고 phantom까지 막는다"라고 답한다. 둘 다 맞을 수 있는 미묘한 영역이지만 정확히 짚어주는 한국어 자료는 거의 없었다. 그래서 이번에 mysql 격리 ..

if user_id in user_ids 한 줄을 쓰려고 set에 100만 건을 올렸다가 메모리 60MB 가까이 날린 적이 있는가? 아니면 캐시 미스 때마다 DB로 가서 "없음" 답만 받아오는 네거티브 캐시 페널티 때문에 골치 아팠던 적은? 블룸 필터(Bloom Filter)는 이런 상황에서 메모리 1MB 남짓으로 DB 호출의 99%를 잘라내는 확률적 자료구조이다. 다만 인터넷에 떠도는 글들은 대부분 "1% false positive로 설정한다" 한 줄짜리 튜토리얼이거나, 위키백과식 원리 설명에 그치고 있어서 실제로 얼마나 이득인지 감이 잡히지 않는다. 각설하고, 직접 100만 사용자 ID 기준으로 set·dict·SQLite(:memory: PK 인덱스)·Bloom Filter 4종을 같은 조건에 박아..

회사가 좀 굴러간다 싶을 때 누구나 한 번씩 부딪히는 벽이 있다. "내가 영업도 제일 잘하고 개발도 제일 잘하는데 왜 직원을 뽑아야 하는가?" 이 본능적인 거부감을 깨지 못하면 회사는 절대 성장하지 못한다. 자기보다 뛰어난 사람을 채용하는 것이 왜 합리적인 결정인지, 어떻게 알아보는지, 한국 현실에서 무엇을 조심해야 하는지 짚어본다. 면접에서 바로 활용할 질문도 함께 정리했다. https://www.youtube.com/watch?v=_ZqtQ2ZbYIQ 사장이 제일 잘하는 회사는 100명이 되어도 그대로다 데이비드 오길비가 임원 책상마다 마트료시카 인형을 올려두고 메모를 끼워뒀다는 일화는 채용 이야기가 나올 때마다 등장한다. 메모 내용은 대략 이러했다. "각자 자기보다 작은 사람을 뽑으면 우리는 난쟁..

TTL 만료 1ms 사이에 DB로 1000건이 몰리는 redis 캐시 stampede 상황은 누구나 한 번쯤 겪어봤을 것이다. 이를 막는 패턴은 단일 프로세스용 single-flight, 확률적 사전 갱신 XFetch, Redis SET NX EX 기반 분산 lock 이렇게 셋이 표준인데, 실제로 어느 것이 얼마나 효과가 있는지 한국어 자료에는 숫자가 거의 없다. 그래서 직접 golang 1.22 환경에서 동시성 100/500/1000으로 10라운드씩 네 패턴을 돌려서 p99/p999 꼬리 지연까지 비교했다. 결론부터 말하면 DB 호출 수렴 효과는 셋 다 거의 동일하지만, 꼬리 지연과 lock 누적 대기 시간에서 갈림길이 명확하게 나뉜다. Redis Stampede가 무엇이며 왜 그렇게 큰 문제인가 캐시..

PostgreSQL을 운영하는 사람들이 거의 자동으로 설치하고 가는 것이 PgBouncer다. 다만 "PgBouncer 모드 비교"라고 검색해 보면 대부분 공식문서 번역이거나 "transaction 모드를 무조건 켜라"는 통념의 반복이다. 정말 맞는 말인지 의심스러워, 백엔드 슬롯 20개를 고정하고 클라이언트를 40개·200개로 스윕하면서 직접 연결과 session/transaction/statement 3가지 풀링 모드를 한 번에 측정했다. 결론부터 말하면 "무조건 정답"은 없으며, 트래픽 패턴과 세션 기능 의존도에 따라 답이 완전히 달라진다. 이 글에서는 실측 TPS·p99 지연·거절률·hop 오버헤드·세션 기능 호환성 데이터를 그대로 제시하고, 어떤 워크로드에 어떤 모드가 맞는지 정리한다. 출처:..

HTTP Keep-Alive를 켜라는 글은 도처에 널려 있다. 다만 정작 "얼마나 차이가 나는지" 한국어로 수치를 제시한 자료는 거의 없다. 이론 글만 읽다가 답답해서 직접 실행했다. 평문 HTTP, HTTPS, mTLS 세 시나리오 × fresh/keepalive 두 모드 × 동시성 1/8/32 = 18케이스 매트릭스로 1000회씩 호출했고, 결론부터 말하면 mTLS에서 keepalive를 사용하지 않으면 치명적이다. 결론부터 제시한다 핵심 한 줄로 정리한다. conc=1 기준 keepalive가 fresh 대비 RPS 비율은 평문 HTTP가 2.80배, HTTPS가 7.65배, mTLS가 9.60배다. 시나리오가 무거워질수록 keep-alive의 이득은 기하급수로 벌어진다. 시나리오fresh RPS..

새벽 3시에 알람 폭탄을 맞아본 적이 있는가? FATAL: sorry, too many clients already 메시지가 로그에 도배되는 그 광경 말이다. 이는 거의 다 DB max_connections=100임에도 애플리케이션 풀을 200, 300으로 박아둔 상황에서 발생한다. 풀을 키우면 처리량이 늘어날 것이라는 직관 때문에 다들 한 번씩 밟는 함정인데, 실제로 어떻게 깨지는지 실측 데이터로 본 적은 거의 없을 것이다. 그래서 직접 측정했다. golang:1.22-bookworm 컨테이너에서 max_connections=100 천장을 고정해둔 채, pool 200을 넘기는 raw_saturate부터 pool=1 직렬화, pgbouncer 트랜잭션 풀링, 클라이언트 축소까지 5가지 풀 전략을 같은 ..

서버 응답이 느려졌다고 max_connections=200을 박아두었더니 오히려 더 느려진 경험이 있는가? 흔하게 마주치는 케이스다. PostgreSQL 커넥션 풀 사이즈를 무작정 키우면 처리량이 같이 올라간다는 명제가 한국 개발자들 사이에 거의 신앙처럼 박혀 있지만, 실제로 측정해 보면 정반대 곡선이 나타난다. 풀이 커질수록 평균 지연은 줄어드나 p99는 오히려 폭발하고, 어떤 구간부터는 처리량 자체가 떨어진다. 이 글은 단순한 위키 번역이 아니다. 풀 크기를 1부터 256까지 9개 구간으로 직접 스윕한 벤치마크 raw 데이터(2026-05-03 측정)를 그대로 실었다. (cores*2)+spindles 공식이 어디까지 진실이고 어디서부터 거짓말인지, 풀이 너무 작을 때와 너무 클 때의 죽는 모드가 어..

흔히 로그는 카프카나 래빗MQ로 받아야 한다는 식의 주장이 통용된다. 그러나 정말 그러한가? 로그 큐 필요성을 한 번이라도 의심해본 사람이라면 "이 계층을 빼도 되지 않을까" 하는 의문을 품어봤을 것이다. 큐 클러스터를 깔고 운영하는 비용이 만만치 않음에도, 제거 가능 여부에 대한 정량 근거를 찾기는 의외로 어렵다. 그래서 직접 측정했다. Go 1.22로 동일한 sink 앞에 direct goroutine 방식과 bounded queue + 워커 풀 방식을 두고 각각 5만 건을 흘렸다. 처리량, P99 지연, heap 피크, goroutine 수까지 모두 측정했다. 결과는 예상보다 명확하다. 출처: geeksforgeeks 결론부터 정리한다 큐가 항상 필요한 것은 아니다. 정리하면 다음과 같다. sin..

출처: jiffy.com 월요일 아침에 발이 떨어지지 않는 직장인은 매우 많다. 그러나 그 이유가 모두 같지는 않다. 누군가는 일이 너무 많아서 타들어가고 있고, 누군가는 일이 너무 없어서 굳어가고 있다. 전자가 번아웃이고 후자가 보어아웃이다. 이 둘의 차이를 모른 채 그저 "회사 가기 싫다"는 한마디로 뭉뚱그리면 처방이 정반대로 나가서 상태가 더 악화된다. 요즘 직장인 사이에서 번아웃은 누구나 알지만, 보어아웃은 처음 듣는 사람도 적지 않다. 한국 대기업, 공무원, 정년 보장 직군에서는 보어아웃이 번아웃보다 더 흔한 경우도 많다. 둘 다 회사를 싫어지게 만드는 점은 동일하지만 해법은 정반대로 갈린다. 이 글에서는 번아웃 보어아웃 차이부터 짚어보고, 직장인 시나리오 몇 가지로 본인 상태를 가늠해 보며, ..

ChatGPT 응답 스트리밍을 보고 "이것은 우리도 만들어야 한다"는 분위기가 형성된 지 1년이 넘었다. 그래서 SSE(Server-Sent Events)가 갑자기 다시 부상했고, 백엔드를 설계할 때 "Go가 좋다더라", "FastAPI가 빠르다더라", "Rust를 쓰면 끝장난다더라" 식의 잡담만 무성하다. 다만 SSE 스트림 언어 비교 글을 살펴보면 벤치마크 없이 일반론만 나열하거나, 단일 언어 튜토리얼에서 끝나버린다. 진짜 중요한 질문은 "누가 빠른가"가 아니다. 운영에 들어가면 답은 달라진다. "구독자 200명을 넘어도 죽지 않는가, 1000명에서는 손실률이 얼마나 누적되는가" 가 실제 SLA를 깨먹는 변수이다. 그래서 직접 돌려봤다. 50/200/500/1000명 구독자 구간에서 동일 하드웨어·동..

블룸버그 터미널 한 자리에 연 $26,000~$32,000을 지불해야 한다는 사실을 알고 있는가? 환산하면 한국 돈으로 약 3,500만~4,200만원이다. 헤지펀드, IB, 자산운용사에서나 사용하는 도구이지 개인 투자자가 손댈 수 있는 가격이 아니다. 다만 최근 오픈소스 금융 분석 플랫폼들이 빠르게 성장하면서 분위기가 다소 바뀌고 있다. 그중에서도 Fincept Terminal이라는 프로젝트가 GitHub 스타 18.8k를 기록하며 "오픈소스 블룸버그 터미널" 포지션을 노리고 있다. 이 글에서는 Fincept Terminal이 진정한 블룸버그 대안이 될 수 있는지, 유사한 오픈소스 도구들과 어떻게 다른지, 한국 개인 투자자 입장에서 활용할 만한지를 정리한다. 결론부터 말하자면 "완벽한 대체는 아니지만 보..

Matt Pocock이 본인 .claude 디렉토리를 통째로 GitHub에 공개했다. 그 안의 TDD 스킬 하나가 며칠 동안 개발자 트위터에서 회자됐는데, 좋은 테스트는 Mock이 아니라 실제 연결이라고 못 박은 것이 핵심이었다. 본인 X 계정에서는 "Before: dozens of shit tests, coupled to implementation. After: only the tests required, validating real behavior"라고 결과를 요약했다. 한마디로 "내가 통제하는 코드는 mock 하지 마라"이다. 또 하나의 흔한 TDD 글로 넘기기 쉽지만, AI 코딩 시대에는 얘기가 좀 다르다. Claude Code 같은 LLM이 한 번에 테스트 10개를 갈겨쓰는 환경에서 mock 남..

LLM 답변이 엉뚱한 결과를 내놓는다면 90%는 retrieval이 잘못된 경우다. 모델을 탓하기 전에 검색부터 의심해야 한다. 그리고 검색이라는 것이 임베딩 한 번 박아 넣는다고 끝나는 일이 아니라는 사실은, RAG를 한 번이라도 돌려본 사람이라면 모두 안다. 처음에는 다들 비슷하게 시작한다. OpenAI 임베딩을 뽑아 pgvector나 Qdrant에 넣고, 코사인 유사도로 top-k를 뽑으면 알아서 잘 동작할 것이라 기대한다. 그러나 막상 운영에 들어가면 사용자가 "PRD-2024-031 문서를 찾아달라"고 했는데 엉뚱한 결과가 나오고, "환불 정책"을 검색했는데 정확한 정책 문서 대신 환불 관련 잡담 글이 1등을 차지한다. 이것이 바로 시맨틱 검색만 사용할 때 무너지는 전형적 사례다. 이 글에서는 ..

4월에 Anthropic으로부터 "Extra Usage Credit이 지급되었다"는 알림을 받고 console.anthropic.com을 뒤져보다가 잔액에 $200이 보이지 않아 당황한 사람이 분명 있을 것이다. 나도 그랬다. 결론부터 말하면 이 보상 크레딧은 console.anthropic.com이 아니라 claude.ai 사용량 페이지에 표시되며, Extra Usage(추가 사용량) 토글을 켜고 배너에서 Claim까지 눌러야 비로소 사용할 수 있다. 클레임한 날부터 90일 안에 사용하지 않으면 그대로 소멸된다. 환불도 되지 않는다. 이 글에서는 Anthropic 크레딧 사용방법을 진입 경로부터 차감 순서, 만료일 확인까지 한 번에 정리한다. 영어 docs만 보고 헤매던 독자라면 이 글을 읽고 clau..

Total TypeScript를 만든 Matt Pocock이 본인 .claude/skills 폴더를 깃허브에 올렸다. 레포 이름은 mattpocock/skills이고, 설명은 "Skills for Real Engineers. Straight from my .claude directory."로 박아두었다. 본인이 매일 쓰던 것을 그대로 던졌다는 뜻이다. 영어권 TypeScript 교육 시장에서 워낙 인지도가 높은 사람이라, 본인 AI 코딩 워크플로우를 통째로 공개하는 일은 흔치 않은 케이스다. 2026년 5월 1일 기준 별 4만 8천 개, 포크 3,900개 가까이 찍혔다. 2026년 2월 초에 공개됐으니 약 석 달 만에 이 정도면 상당한 화제다. 각설하고, Matt Pocock skills 레포 안을 카테..

LLM 에게 코드를 맡긴 지 6개월쯤 지나면, 어느 날 갑자기 그 코드가 폭탄으로 변하는 경험을 하게 된다. 처음에는 "빠르다" 싶다가도 시간이 지나면 "이 코드는 누가 짠 것인가, 왜 이렇게 짰는가" 하면서 머리를 쥐어뜯게 된다. 이를 그저 LLM 기술 부채라는 한 단어로 뭉뚱그려 부르고 있었으나, 마틴 파울러가 2026-04-02 fragments 섹션에 올린 글에서 이것이 한 종류가 아니라고 짚었다. 빅토리아대 마거릿-앤 스토리(Margaret-Anne Storey) 교수가 arXiv 논문에서 제안한 분류이며, 파울러가 fragments 에서 공유하면서 알려졌다. 기술 부채, 인지 부채, 의도 부채. 세 갈래로 쪼개서 봐야 한다는 것이다. 이번 글에서는 스토리 교수가 나눈 세 부채가 각각 무엇인지,..

Kafka를 다뤄본 사람이라면 Apache Flink라는 이름을 한 번쯤 들어봤을 것이다. 다만 막상 "Flink가 무엇인가?"라고 물으면 제대로 답하는 사람이 별로 없다. 공식 docs는 영어로 깔끔하게 정리되어 있으나 입문자에게는 다소 불친절하다. 한국어 블로그 글들도 대부분 "스트리밍 프레임워크다"라는 한 줄로 끝내고 넘어간다. 각설하고 이 글에서는 Apache Flink가 실제로 무엇을 하는 도구인지, 왜 만들어졌는지, Spark와 어떻게 다른지, 언제 써야 하고 언제 쓰면 안 되는지 정리한다. 2~7년차 백엔드 개발자가 실시간 데이터 처리 요구사항을 받았을 때 "이것을 Flink로 가야 하는가"를 판단할 수 있는 수준까지 다룬다. 코드 예제도 있고 국내 기업 도입 사례도 함께 살펴본다. 출처:..

새벽 3시에 슬랙 알람이 울려 일어났는데 "Citus shard placement inconsistent"라는 메시지가 떠 있다면 누구라도 당황한다. Citus 샤딩 복구는 한국어 자료가 거의 없어 영문 깃허브 이슈를 뒤지다 시간만 날리는 경우가 보통이다. 그래서 실전에서 쓸 만한 진단 흐름과 복구 절차, 그리고 직접 겪었던 장애 사례 3개를 한 번에 정리한다. Citus는 PostgreSQL 위에 얹는 분산 익스텐션으로, 코디네이터(coordinator) 노드가 메타데이터를 보유하고 워커(worker) 노드들이 실제 샤드를 보유하는 구조다. 운영하다 보면 워커가 죽거나, 리밸런싱(rebalancing) 도중 락이 걸려 멈추거나, pg_dist_shard 같은 메타데이터가 워커의 실제 상태와 어긋나는 일..

그동안 클로즈드 소스라고 적잖이 비판받던 Warp 터미널이 결국 오픈소스로 풀렸다. GitHub 저장소(github.com/warpdotdev/warp)에 코드가 통째로 올라왔고, "에이전틱 개발 환경(Agentic Development Environment)" 컨셉을 그대로 들고 왔다. Warp 터미널 오픈소스 전환은 단순 코드 공개 이벤트가 아니다. 그동안 회원가입 강제와 텔레메트리 이슈로 갈라섰던 개발자 커뮤니티와 화해해보자는 시도다. 각설하고, 진짜 풀린 것이 맞는가? 라이선스 디테일은? AI 에이전트 기능은 정말 쓸만한가? 기존 iTerm2나 Alacritty를 쓰던 사람이 갈아타도 되는가? 이 글에서는 GitHub 저장소를 직접 까보고, 과거 논란을 정리하고, 다른 터미널과 솔직하게 비교했다...

DB 락이 두 종류로 나뉘는 근본 이유는 설명하지 않고 코드만 던지는 글이 너무 많다. 그래서 "비관적 락 낙관적 락" 차이를 검색해도 결국 신입은 개념만, 주니어는 판단 기준만 따로 보다가 둘 다 어정쩡하게 알게 된다. 이 글에서는 두 락의 차이부터 시작해 실무에서 어느 도메인에 어느 락을 써야 하는지, 그리고 데드락이나 OptimisticLockException 같은 함정까지 한 번에 정리한다. JPA를 쓰든 raw SQL을 쓰든 모두 적용되도록 케이스 위주로 풀었다. 출처: vladmihalcea.com 락이 두 종류로 갈라진 근본 이유 동시성 문제란 무엇인가 — 30초 요약 DB에서 동시성 문제는 결국 두 트랜잭션이 같은 행을 동시에 건드릴 때 발생한다. 대표적인 사례가 Lost Update다...

RabbitMQ vs Kafka를 검색하면 비슷한 글이 200개쯤 쏟아지지만, 다 읽어봐도 결국 "둘 다 메시징 시스템인데 다르다"는 한 줄로 귀결된다. 그러나 현업에서 두 시스템을 모두 운영해본 입장에서는 그렇게 단순히 정리될 사안이 아니다. 같은 카테고리의 도구가 아닌데도 자꾸 비교 대상이 되는 이유, 그리고 진정 언제 무엇을 사용해야 하는지를 본 글에서 정리한다. 2025년 기준 최신 정보를 모두 반영했고, 옛 글에서 자주 언급되는 잘못된 통설도 함께 짚는다. RabbitMQ vs Kafka, 두 시스템은 같은 카테고리의 도구가 아니다 출처: slideshare.net 먼저 못 박고 시작하자. RabbitMQ는 메시지 큐(Message Queue)이고, Kafka는 분산 로그(Distributed..

출처: thenewstack.io 요즘 개발자 면접에 가서 "도커(Docker)는 써본 적이 없다"고 답하면 분위기가 어색해진다. 백엔드, 데브옵스를 가리지 않고 도커는 거의 기본 소양으로 취급되는 시대다. 다들 docker run은 매일 치면서, 정작 도커 개발자가 누구인지 아는 사람은 드물다. 이 점이 다소 의아하다. 리누스 토르발즈의 이름은 누구나 알면서, 도커를 만든 사람의 이름은 잘 떠올리지 못한다. 도커는 등장 1년 만에 깃허브 스타 1만 개를 찍고 인프라 시장의 표준이 된 도구임에도 그렇다. 면접 준비를 하다가 문득 궁금해져서 찾아봤다. 솔로몬 하익스(Solomon Hykes)가 누구인지, dotCloud라는 PaaS 스타트업에서 도커가 어떻게 튀어나왔는지, 2013년 PyCon에서 5분짜리..

PRD 작성 방법을 검색해 보면 대부분 PM이 PM에게 쓴 글이다. 그러나 정작 부실한 PRD 때문에 야근하는 쪽은 개발자다. 모호한 한 줄짜리 요구사항을 받고 "이것이 어떻게 동작해야 하는가"를 슬랙으로 50번 물어본 경험은 누구에게나 있을 것이다. 이 글은 개발자 입장에서 PRD(Product Requirements Document)를 어떻게 바라보아야 하는지, 직접 작성하게 되었을 때 어떻게 써야 하는지를 정리한다. 2026년 현재 Cursor, Claude Code 같은 AI 코딩 도구가 PRD를 직접 읽어서 코드를 생성하는 시대이며, PRD 품질이 곧 코드 품질로 직결되는 흐름까지 함께 다룬다. 형식적인 SW공학 교과서 톤은 배제하고 현장에서 실제로 쓸 수 있는 내용만 추렸다. 출처: www...

Kafka 내부 구조를 살펴보면 RocksDB가 등장한다. TiKV 문서를 보면 또다시 RocksDB가 나온다. CockroachDB의 옛 버전도 RocksDB를 썼고, MyRocks라는 MySQL 변종 역시 RocksDB 기반이다. 도대체 이 컴포넌트가 무엇이길래 이렇게 광범위하게 채택되는 것인가? 다만 한국어로 RocksDB를 제대로 정리한 글은 많지 않다. 위키백과는 너무 짧고, 개발 블로그들은 LSM-Tree만 깊게 파고들거나 코드만 던져둔다. "이게 무엇이고 왜 쓰며 어디서 쓰이는지"가 한 번에 잡히는 글이 부족하다고 느껴 직접 정리한다. 각설하고 한 줄로 요약하면, RocksDB는 데이터베이스라기보다 "데이터베이스의 부품"에 가깝다. 그래서 직접 사용할 일은 거의 없지만, 그럼에도 알아 두어야..

마이크로서비스를 도입한 회사에 들어가보면 흥미로운 패턴이 있다. 외부 클라이언트에는 모두 REST API로 응답하면서, 내부 서비스끼리는 모두 gRPC로 통신한다. 토스도 그렇고 우아한형제들도 그렇고 넷플릭스도 그렇다. 왜 이렇게 안과 밖을 갈라놓는 것인가? REST를 잘 쓰고 있었는데 왜 굳이 gRPC를 또 배워야 하는지 궁금했다. 그래서 gRPC vs REST 비교는 결국 어디서 갈라지는지, gRPC가 왜 만들어졌고 HTTP와 무엇이 다른지, 어디에 써야 하고 어디에 쓰지 말아야 하는지 직접 파봤다. 결론부터 말하면 "둘 중 무엇이 더 좋다"가 아니라 "각자 잘하는 영역이 다르다" 이며, 그 차이를 만드는 것은 결국 HTTP/2와 Protocol Buffer라는 두 기술이다. 출처: slidesha..

PlanetScale 무료티어가 사라진 이후 개발자 커뮤니티에서 "Vitess를 직접 띄우자"는 글이 슬슬 보이기 시작했다. 다만 Vitess가 무엇이냐고 물으면 대부분 "MySQL 샤딩 도구?" 정도로만 알고 있는 듯하다. 사실 Vitess는 단순한 샤딩 도구가 아니라, 유튜브가 14년째 운영하고 있는 MySQL 클러스터 매니저이다. 슬랙, Square, GitHub, HubSpot 같은 곳들이 핵심 인프라에서 사용하고 있으며, CNCF에서 2019년에 졸업한 8번째 프로젝트이기도 하다. 이번 글에서는 Vitess가 정확히 무엇인지, 어떤 회사들이 실제 프로덕션에서 사용하고 있는지, 왜 2024~2025년에 갑자기 다시 화제가 되었는지를 한 번에 정리한다. 마지막에는 "그래서 우리 회사도 도입해야 하는..