프로젝트
b-studio — 사내 도구를 만드는 AI 앱 빌더
요청을 말하면 에이전트가 코드를 쓰고, 그 코드를 격리된 샌드박스에서 실제로 실행합니다. 체크포인트마다 파일과 DB 상태를 함께 남기고, 샌드박스의 출입구를 edge 컨테이너 하나로 모아 허용 규칙과 감사 기록을 강제합니다.
dbtower-lakehouse — 버려지는 관측 데이터의 장기 분석 파이프라인
DBTower의 단기 관측 데이터를 장기 보관하고, 기간별 쿼리 성능 변화를 조회·분석하는 데이터 파이프라인입니다.
DBTower — 이기종 DBMS 운영 관리 플랫폼
MySQL·PostgreSQL·Oracle·SQL Server·MongoDB를 한곳에서 모니터링하고, 쿼리 이상과 성능 회귀를 비교·진단하는 데이터베이스 운영 플랫폼입니다.
pay — Spring Modulith 결제 시스템
결제 승인·취소부터 원장·정산·대사·구독·분쟁까지 처리하고, FDS와 배치·AI 기반 운영 자동화로 이상 거래와 운영 예외를 탐지·분류하는 결제 시스템입니다.
위키엔진
1,215만 건의 위키 문서를 Lucene으로 색인·검색하고, 캐시와 읽기·쓰기 분리로 트래픽을 처리하는 통합 검색 플랫폼입니다.
db-hobby — C로 만든 미니 RDBMS
psql로 접속해 SQL을 실행할 수 있고, 저장·인덱스·트랜잭션·복구·복제를 직접 구현한 C 기반 학습용 RDBMS입니다.
최신 스토리
AI 코딩, 저는 이렇게 개발하고 있습니다
설계는 메인 세션이, 구현은 싼 코더가, 검토는 다른 모델이 맡습니다. 이 구조를 직접 자동화하면서 가장 오래 붙잡은 문제는 AI가 정말 일을 끝냈는지 믿는 방법이었습니다. 완료 표식이 두 번 거짓으로 통과한 뒤 판정 방식을 다시 세웠습니다.
AI가 짜준 코드를 어디까지 기계한테 검증시킬 수 있을까?
처음에는 검증 충분성을 기계가 결정적으로 판정하게 만들려 했다. 그런데 사람이 하던 그 판단은 원래 확률적이었다. 그래서 갈라야 할 것은 무엇을 고정하고 무엇을 맡길 것인가였다. 고정할 자리에는 경계와 검사를 두고, 맡길 자리에는 판단할 재료를 준다. 다만 자기를 심판하는 자리 하나는 기계가 붙잡아야 한다.
데이터베이스 인덱스 ⑥: 운영과 한계
인덱스 시리즈 마무리. 운영 환경의 인덱스 작업은 DDL이 DB를 멈출 수 있다는 사실에서 출발합니다. CREATE INDEX CONCURRENTLY의 4단계 phase와 제약, 장기 트랜잭션이 클러스터 전반의 VACUUM/IOS에 미치는 영향, 인덱스 bloat과 REINDEX, 수십억 행을 위한 파티셔닝/샤딩, Bloom Filter, 그리고 6가지 안티패턴까지 1차 자료 기준으로 정리합니다.
데이터베이스 인덱스 ⑤: 클러스터형 인덱스와 DBMS별 차이
PostgreSQL의 heap-organized 모델과 MySQL InnoDB의 clustered index 모델은 근본적으로 다른 세계관입니다. 같은 SQL이라도 저장 구조에 따라 plan과 비용이 전혀 달라지고, secondary index 동작·PK 선택 전략·DBMS 이전 시 함정이 모두 달라집니다. PG/MySQL/SQL Server/Oracle 비교를 1차 자료 기준으로 정리.
데이터베이스 인덱스 ④: 복합 인덱스와 좌측 컬럼 규칙
복합 인덱스는 컬럼들의 정렬 순서를 그대로 B-tree에 반영한 자료구조입니다. 같은 세 컬럼이라도 순서를 바꾸면 전혀 다른 인덱스가 되고, leftmost prefix rule이 활용 방식을 결정합니다. ESR Rule(Equality·Sort·Range) 가이드라인, PG18 skip scan, AND vs OR, INCLUDE와의 차이까지 1차 자료 기준으로 정리.
데이터베이스 인덱스 ③: Covering Index와 Index-Only Scan
plan에 Index Only Scan이 잡혔다고 진짜 IOS는 아닙니다. PostgreSQL의 IOS는 covering(쿼리 컬럼이 인덱스에)과 visibility(VM all-visible) 두 단계 조건을 모두 만족해야 Heap Fetches가 0이 됩니다. INCLUDE 절은 covering을, VACUUM은 visibility를 충족시키는 도구입니다. INCLUDE의 leaf-only 저장 메커니즘과 인덱스 타입별 IOS 지원, 그리고 PG12 이전 insert-only Mandrill 함정까지 다룹니다.
데이터베이스 인덱스 ②: 스캔의 종류와 옵티마이저의 선택
인덱스가 있다고 모든 쿼리가 같은 방식으로 그 인덱스를 쓰는 것은 아닙니다. PostgreSQL의 Sequential / Index / Index-Only / Bitmap Scan 4가지 전략과, 옵티마이저가 통계 기반 셀렉티비티 추정으로 그 중 하나를 고르는 메커니즘을 1차 자료 기준으로 정리합니다. correlation, work_mem, BitmapAnd, Index Cond vs Filter까지.
데이터베이스 인덱스 ①: 인덱스 기초와 EXPLAIN 읽기
인덱스는 검색용 보조 자료구조이고, 그 인덱스를 쓸지 말지를 결정하는 것은 옵티마이저입니다. 옵티마이저의 결정을 검증하는 도구가 EXPLAIN이고, 실측까지 더하는 것이 EXPLAIN ANALYZE입니다. cost가 임의 단위라는 점, 추정과 실측의 격차가 진단의 핵심 신호라는 점, 인덱스가 있어도 안 쓰이는 4가지 패턴까지 1차 자료 기준으로 정리합니다.