DB 변경 대기 21시간보다 중요한 숫자, 커밋한 사람 100명

21시간이 1.7시간이 됐다는 숫자가 제목감이긴 합니다. 오늘의집 DBRE 팀이 정리한 바로는 2024년 DDL 요청 티켓이 접수부터 반영까지 중앙값 약 21시간이 걸렸고, 지금 개발자가 직접 올리는 DDL PR은 생성부터 반영까지 약 1.7시간입니다. 하루 안에 끝나는 비율도 54%에서 84%로 올랐고요. 그런데 이 글에서 제가 가장 오래 본 숫자는 다른 겁니다. 스키마 저장소에 commit을 남긴 사람이 100명에 가깝고, 그 대부분이 DBRE가 아니라 각 서비스 개발자라는 것.

대기 시간은 도구가 줄여줍니다. 100명이 DB를 바꾸게 됐다는 건 일의 주인이 바뀌었다는 뜻이에요. 저는 이 사례를 'DB 업무 자동화'보다 'DB 변경 권한의 이전'으로 읽는 편이 실무에 더 쓸모 있다고 봅니다. 권한이 넘어가면 DBRE가 하는 일의 성격이 통째로 달라지고, AI를 어디에 붙여야 하는지도 그 변화가 정해주거든요.

요청서가 PR이 되면 무엇이 넘어가나

예전 흐름은 이랬습니다. 개발자가 Slack DM이나 Jira 티켓, 때로는 말로 "이 테이블에 컬럼 하나만 추가해 주실 수 있을까요?"라고 부탁하면, DBRE가 의도를 해석해 SQL로 옮기고 환경별로 직접 실행한 뒤 결과를 알려줬습니다. 검토 정책은 문서로 있었지만 적용하는 사람마다 숙련도가 달랐고, 이력은 흩어졌고, 사실상 운영 DB 자체가 스키마의 기준이었어요. 어떤 테이블이 언제 왜 바뀌었는지 알려면 티켓과 담당자의 기억을 뒤져야 했습니다.

지금은 모든 스키마가 git 저장소 하나에 있습니다. 환경(dev, qa, prod)과 클러스터, 데이터베이스, 테이블 단위로 디렉터리를 나누고, 테이블마다 최종 CREATE TABLE 문을 파일로 둡니다. 개발자는 이 파일을 원하는 모습으로 고쳐 PR을 올리고, ALTER 문은 직접 쓰지 않습니다. 현재 상태에서 최종 상태로 가는 방법은 파이프라인이 계산해요. 쿼리에 원하는 데이터만 적고 찾는 방법은 옵티마이저에 맡기듯 스키마도 같은 원리로 다루겠다는 겁니다.

PR이 열리면 GitHub Actions가 변경 파일을 신규·수정·삭제로 나누고, 수정된 테이블은 기존 스키마와 비교해 ALTER를 만들면서 INSTANT, INPLACE, LOCK=NONE 같은 Online DDL 옵션을 고릅니다. MongoDB도 인덱스 정의를 비교해 createIndex와 dropIndex를 만들고요. Skeema나 Atlas 같은 기존 도구 대신 직접 만든 이유는 엔진 범위였습니다. 여러 엔진을 한 저장소와 한 리뷰 흐름에서 다루면서 팀이 쌓아온 체크리스트를 게이트로 세우려면 어댑터 구조가 필요했다는 설명이에요.

직접 만든 파이프라인에는 직접 갚아야 할 비용이 따라옵니다. 엔진이 하나 늘 때마다 어댑터를 써야 하고, MySQL 버전이 바뀌어 Online DDL 동작이 달라지면 ALTER 생성 로직도 따라가야 해요. 오픈소스 도구를 쓰면 그 부담을 커뮤니티와 나누지만, 오늘의집처럼 체크리스트를 게이트로 세우는 게 목적이라면 결국 그 게이트 코드는 자기 것이어야 합니다. 저는 이 판단이 맞다고 보는데, 이건 DBRE가 소프트웨어 팀처럼 일할 각오가 있는 조직에서만 성립하는 선택이에요.

여기서 넘어간 게 무엇인지 짚어볼 만합니다. 의도를 SQL로 옮기는 일, 환경별로 실행하는 일, 기록을 남기는 일이 DBRE의 손에서 파이프라인으로 넘어갔습니다. 그리고 '무엇을 바꿀지 정확히 적는 책임'은 요청서를 쓰던 개발자에게 그대로 남았는데, 이제는 그게 리뷰 가능한 코드가 됐죠. 요청을 해석하던 사람이 사라지자 해석의 오차도 함께 사라진 셈입니다.

DBRE에게 남은 일은 게이트다

변경을 대신 해주는 사람이 없어지면 그 자리를 무언가 지켜야 합니다. 오늘의집은 그 자리에 여러 겹의 게이트를 세웠어요. 문법은 sqlfluff가 보고, 예약어를 쓴 컬럼명이나 명명 규칙에 어긋난 인덱스 이름, 문자열 대신 enum을 쓰려는 시도처럼 기준이 분명한 건 코드로 거릅니다. 규칙만으로 판단하기 어려운 건 LLM이 팀의 DDL 체크리스트를 기준으로 읽고 PR에 코멘트를 남기고요. 어느 단계든 문제가 걸리면 고치기 전에는 merge가 안 됩니다.

LLM 코멘트가 단순한 경고문이 아니라는 점이 좋습니다. 대상 테이블의 크기와 행 수, 인덱스 구성을 조회하고, 같은 테이블의 과거 실행 이력으로 이번 변경의 예상 소요 시간을 신뢰도와 함께 보여줍니다. 개발자 입장에서 "이 ALTER가 운영에서 몇 분 걸릴까"는 원래 DBA에게 물어야 알던 정보인데, 그게 PR 화면으로 내려온 거예요. 리뷰 결과를 반영하고 싶으면 코멘트 하나로 수정이 적용되기도 하고요.

그 위에 사람이 있습니다. dev는 최소 요건만 통과하면 바로 반영되지만, qa와 prod는 코드 오너인 DBRE의 승인이 있어야 들어갑니다. 테이블 삭제는 prod에서 바로 DROP하지 않고 이름을 바꿔 격리해 두었다가 배치로 정리하는 rename-then-batch로 처리해서, 잘못된 판단에도 되돌릴 시간이 남습니다. 저는 이 장치가 LLM 리뷰보다 먼저 만들어져야 할 것이라고 봐요. 리뷰가 아무리 좋아도 언젠가는 놓치고, 그때 살려주는 건 되돌릴 수 있는 설계니까요.

DBRE가 LLM 리뷰 자체를 관리하는 방식도 눈에 띕니다. 프롬프트는 Langfuse에서 중앙 관리하고 DBMS별 템플릿을 버전 관리하며, 정답이 정해진 테스트 케이스로 매주 리뷰를 다시 돌려 품질이 떨어졌는지 확인합니다. 멀쩡한 변경을 LLM이 잘못 막는 오탐이 나오면 예외 처리로 넘기지 않고 원인을 찾아 기준을 고친다고 했어요. 결국 DBRE의 하루는 DDL을 실행하는 시간에서 게이트의 정확도를 관리하는 시간으로 바뀐 셈입니다.

같은 방식은 새 데이터베이스를 만드는 일에도 적용됐습니다. 새 서비스를 시작하는 개발자가 같은 저장소에 스키마나 인덱스 정의 파일을 추가해 PR을 올리면, merge 뒤 파이프라인이 데이터베이스를 만들고 계정과 권한을 설정하고 접속 정보를 발급합니다. 비밀번호까지 파이프라인이 만들고, 팀은 계정과 권한 관리 전반으로 이 방식을 넓히는 것도 검토 중이라고 해요. 저는 이 확장이 가장 조심스러운 단계라고 봅니다. 스키마 변경은 되돌릴 장치를 만들 수 있지만, 잘못 열린 권한은 열려 있던 시간만큼의 위험을 남기니까요. 권한 PR에는 DDL보다 한 단계 더 엄격한 승인 규칙이 붙어야 맞습니다.

범용 챗봇이 퇴장한 자리

이 글에서 가장 정직한 대목은 실패담입니다. 팀은 GPT 기반 대화형 어시스턴트 Portal Assistant를 2,468줄의 코드로 시작해 기능을 붙여 나갔지만, 약 6개월 뒤 3,222줄을 들어내며 퇴장시켰습니다. 범용 챗봇보다 쿼리 분석이나 DDL 리뷰처럼 특정 작업에 붙은 AI가 훨씬 많이 쓰였기 때문이에요. 당시 팀이 AI의 능력을 다소 과대평가했다는 고백도 붙어 있습니다.

조회 쪽 셀프서비스 포털의 사용 기록이 그 판단을 뒷받침합니다. 최근 90일 동안 약 120명이 28개 기능을 1,514회 썼고, 그중 Table Growth 74회, Query Analyzer 63회, Slow Query 조회 51회, DDL Deploy History 50회가 상위였어요. EXPLAIN 실행 계획에 AI 인덱스 제안을 얹은 Query Analyzer는 살아남았고, 아무거나 물어보라던 챗봇은 사라졌습니다.

포털이 조회에서 끝나지 않는다는 점도 짚어둘 만합니다. 환경 사이에 형상이 어긋난 테이블을 발견하면 스키마 파일을 맞추는 PR을, 쓰이지 않는 인덱스를 찾으면 지우는 PR을 그 자리에서 올릴 수 있고, 그 PR도 개발자가 직접 올린 PR과 같은 파이프라인을 지납니다. "제 테이블 얼마나 커졌어요?" 같은 질문이 DBRE에게 오지 않게 된 것도 성과지만, 저는 조회가 곧바로 같은 게이트를 지나는 변경으로 이어지는 이 고리가 셀프서비스의 진짜 가치라고 봐요. 보는 도구와 고치는 도구가 따로 놀면 셀프서비스는 결국 문의 채널 하나를 더 만드는 데 그칩니다.

저는 이 차이를 '파이프라인의 한 칸에 붙어 있느냐'로 봅니다. DDL 리뷰의 LLM에는 입력(변경 파일), 기준(체크리스트), 출력 위치(PR 코멘트), 검증(매주 회귀 테스트), 그리고 뒤에 서 있는 사람(코드 오너 승인)이 모두 정해져 있어요. 범용 챗봇에는 그중 아무것도 없었습니다. 무엇을 물어야 할지는 사용자가, 답이 맞는지는 아무도 확인하지 않는 구조에서는 쓰임새가 쌓이지 않죠. 팀이 이 경험 뒤로 실사용 데이터로 수요를 확인한 다음에만 새 기능을 만들기로 한 것도 같은 교훈으로 읽힙니다.

변경이 싸지면 변경이 는다

처리량 숫자도 큽니다. 매달 30건 안팎이던 DDL 작업이 2026년에는 MySQL DDL PR merge 기준 월평균 120건을 넘었고, 도구가 자동으로 올리는 PR을 빼고 개발자가 직접 올린 것만 세도 월평균 100건이 넘습니다. 이전의 3배가 넘는 변경량이에요. 저장소에 merge된 PR은 2,000건이 넘습니다.

다만 저는 이 숫자를 성과로만 읽는 데는 동의하기 어렵습니다. 변경 비용이 떨어지면 변경은 늘어나기 마련이고, 그중 일부는 예전 같으면 "티켓 쓰기 귀찮아서" 하지 않았을 변경입니다. 그게 꼭 나쁜 건 아니지만, 스키마가 세 배 자주 바뀌는 시스템이 더 건강한지는 대기 시간이나 merge 건수로는 알 수 없어요. 이 글에는 도입 전후의 DDL 관련 장애 건수나 롤백 횟수, LLM 리뷰의 오탐률 같은 숫자가 없습니다. 이 사례를 따라 하려는 팀이라면 처리량과 함께 그 숫자를 처음부터 재야 합니다.

dev 환경이 최소 검사만 통과하면 바로 반영된다는 점도 같은 맥락에서 봐둘 만합니다. 개발 속도에는 좋지만, dev와 qa·prod 사이의 형상 차이가 커질 수 있어요. 포털에서 환경 간 형상이 어긋난 테이블을 찾아 맞추는 PR을 바로 올릴 수 있게 해둔 건 그 차이를 이미 문제로 보고 있다는 뜻이겠고요.

DBA 병목에 시달리는 팀이 이 글에서 가져갈 순서는 분명하다고 봅니다. 먼저 스키마를 선언형 저장소에 모아 기준을 하나로 만들고, rename-then-batch처럼 되돌릴 수 있는 장치를 세우고, 그 다음에 LLM을 붙이되 체크리스트와 회귀 테스트와 사람의 승인이 있는 칸에만 붙이는 것. 이 순서를 뒤집어 챗봇부터 만들면 오늘의집이 3,222줄을 지우며 배운 걸 다시 배우게 될 겁니다. 그리고 100명이 DB를 바꾸는 조직이 됐다면, 그때부터 재야 할 건 대기 시간이 아니라 그 100명이 낸 변경이 운영에서 얼마나 조용히 지나갔느냐입니다.