MySQL, PostgreSQL, SQL Server, Oracle, MongoDB를 한곳에서 관제하고 안전하게 변경하는
셀프호스트 DB 운영 플랫폼입니다. 기종별 차이는 DbmsOperator 뒤로 숨기고, 관제부터
진단, 승인, 실행, 전후 비교까지 하나의 흐름으로 연결합니다.
Java 21 + Spring Boot 4로 만들었으며 웹 콘솔은 별도 빌드 체인이 없는 정적 SPA입니다.
관제 -> 문제 구간 비교 -> 실행계획·원인 분석 -> 변경 요청 -> 승인 -> 실행 -> 전후 비교
변경은 승인된 티켓만 실행합니다. 실행 직전 행을 복사하고, 복사한 행 수와 실제 영향 행 수가 다르면 커밋하지 않습니다. 되돌리기도 사본과 현재 행이 같은 경우에만 허용합니다.
수십만 행을 고치는 일은 사본 방식으로 감당할 수 없어(행 수에 비례해 락을 쥡니다) 기본 키 범위 배치로 쪼개 구간마다 따로 커밋합니다. 이 경로의 되돌리기는 사본이 아니라 복원 검증에 성공한 최근 백업이며, 그 백업이 없으면 실행을 거부합니다. 취소해도 이미 커밋한 배치는 되돌리지 않고, 어디까지 적용됐는지는 마지막 키로 남깁니다.
| 영역 | 제공 기능 |
|---|---|
| 관제 | 쿼리 통계, 활동 그래프, 시점 비교, Wait Event, 세션·블로킹, 복제·백업 상태 |
| 진단 | 실행계획 규칙 분석, AI 1차 분석, 심층 원인 진단, 플랜 변경·이상·데드락 감지 |
| AI 운영 작업 | Slack 한 문장·웹 콘솔·경보·DB팀 문의에서 시작된 비동기 진단. 사실은 DBTower가 모으고 모델은 1차 소견만 내며, 소견의 수치는 사실과 대조해 어긋나면 "검증되지 않음"으로 남깁니다 |
| 운영 | 통합 헬스 스코어, SLO·에러 버짓, Advisors, FinOps 신호, 백업·복원 검증 |
| 변경 관리 | 읽기 전용 워크벤치, 마스킹, 변경 리뷰, 승인 티켓 실행·되돌리기 |
| 대량 일괄 변경 | 승인된 티켓을 기본 키 범위 배치로 쪼개 실행합니다. 복제가 밀리면 멈췄다 재개하고, 되돌리기는 행 사본이 아니라 복원 검증된 최근 백업을 실행 전 조건으로 걸어 보장합니다. 복합 기본 키와 5기종을 지원하며, 여러 테이블에 걸친 변경과 _id 타입이 섞인 MongoDB 컬렉션은 담지 않습니다 |
| 연동 | 웹 콘솔, MCP stdio·HTTP, Discord·Slack 웹훅, K8s·Terraform·Ansible |
| 화면 | 관제·워크벤치를 한 페이지의 두 모드로. 관제 AI 채팅은 대화를 서버에 저장하고 대화 목록에서 이어 보며, AI로 보내는 쿼리와 실행계획의 값은 가림 수준(NONE·STRUCTURE·FULL)으로 가립니다 |
기종별 통계와 실행 방식이 달라도 플랫폼 코드는 같은 운영 능력을 사용합니다.
| DBMS | 쿼리 통계 | 실행계획 | 백업 방식 |
|---|---|---|---|
| MySQL | performance_schema |
JSON EXPLAIN | mysqldump 등 외부 CLI |
| PostgreSQL | pg_stat_statements |
TEXT/JSON EXPLAIN | pg_dump 등 외부 CLI |
| SQL Server | DMV·Query Store | 플랜 XML | BACKUP DATABASE |
| Oracle | V$SQL |
DBMS_XPLAN |
DBMS_DATAPUMP·RMAN |
| MongoDB | profiler·server status | explain JSON | mongodump |
- 모니터링 조회는 읽기 전용 계정과 타임아웃을 사용합니다.
- 변경은 요청자, 승인자, 운영자의 역할을 분리하고 전 과정을 감사 기록에 남깁니다.
- MCP와 AI에는 변경 실행 도구를 노출하지 않습니다. AI는 사람이 정한 규칙 위에서 분석만 합니다.
- 대상 DB 장애가 플랫폼 전체를 멈추지 않도록 커넥션과 수집 작업을 인스턴스별로 격리합니다.
- 비밀번호는 AES-256-GCM으로 저장하며 API 응답과 외부 명령 인자에 노출하지 않습니다.
자세한 결정과 위협 경계는 설계 문서, 최소 권한 가이드, 검증 기록에서 확인할 수 있습니다.
Docker와 Docker Compose만 있으면 앱과 전용 메타 DB를 실행할 수 있습니다.
현재 정식 버전은 v1.6.2입니다. 운영에서는 재현 가능한 업그레이드를 위해 latest 대신
DBTOWER_TAG=1.6.2처럼 버전을 고정하는 것을 권장합니다.
cp .env.example .env.env에서 최소 두 값을 설정합니다.
DBTOWER_DB_PASSWORD=change-me-strong-password
DBTOWER_ENCRYPTION_KEY=<openssl rand -base64 32 결과>
DBTOWER_TAG=1.6.2그다음 컨테이너를 시작합니다.
docker compose -f docker-compose.app.yml up -d웹 콘솔은 http://localhost:8080에서 열립니다. DBTOWER_ADMIN_PASSWORD를 비워 두었다면
최초 관리자 비밀번호는 다음 명령으로 확인합니다.
docker compose -f docker-compose.app.yml logs dbtower이 구성은 DBTower와 메타 DB만 실행합니다. 관리 대상 DB는 로그인 후 웹 콘솔에서 등록합니다. 배포와 프록시, 백업 설정은 운영 가이드를 참고하세요.
JDK 21과 Docker가 필요합니다. 아래 compose는 개발용 대상 DB 5종과 모니터링 스택을 띄웁니다.
docker compose up -d
DBTOWER_WEBHOOK_URL="" DBTOWER_ADMIN_PASSWORD=devpass \
DBTOWER_ENCRYPTION_KEY=$(openssl rand -base64 32) ./gradlew bootRunApple Silicon의 Rosetta 없는 Colima에서는 amd64 전용 SQL Server 2022가 기동되지 않습니다.
이 머신에서 docker-compose.arm64.yml의 Azure SQL Edge도 S_SbtUnimplementedInstruction로
종료됐습니다. SQL Server까지 확인할 때는 Rosetta를 켠 별도 Colima 프로필에 실제 2022 이미지를 띄웁니다.
colima start mssql2022 --vm-type vz --vz-rosetta --cpu 4 --memory 6 --disk 20
MSSQL_SA_PASSWORD='...' docker --context colima-mssql2022 run -d \
--name dbtower-mssql2022 --platform linux/amd64 \
-e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD -p 14330:1433 \
mcr.microsoft.com/mssql/server:2022-latest계정·데모 데이터 준비와 실제 SQL Server 2022 검증 결과는 VERIFICATION.md 132·164절에 기록했습니다. 이 실행은 Microsoft가 지원하는 네이티브 ARM64 구성이 아니라 로컬 개발용 번역 환경입니다.
등록한 대상의 비밀번호를 다음 실행에서도 사용하려면 암호화 키를 고정해서
보관해야 합니다.
키 없이 로컬에서만 실행하려면 SPRING_PROFILES_ACTIVE=dev를 사용할 수 있습니다.
변경을 마치기 전에는 저장소 규칙에 따라 세 검증을 모두 실행합니다.
./gradlew compileJava
./scripts/check-conventions.sh
./gradlew test| 역할 | 주 사용자 | 주요 권한 |
|---|---|---|
VIEWER |
온콜·팀장 | 관제, 비교, 리포트 조회 |
REQUESTER |
개발자·데이터 요청자 | 워크벤치 조회, 변경 요청 |
APPROVER |
DBA 리드 | 변경 승인·반려, 드라이런 |
OPERATOR |
DBA 운영자 | 승인 티켓 실행·되돌리기, 백업, 세션 종료 |
ADMIN |
플랫폼 관리자 | 인스턴스, 계정, 보안, 감사 관리 |
승인자와 운영자는 서로를 포함하지 않습니다. 화면은 /api/me가 반환한 능력으로 동작을
표시하고, 최종 권한은 서버가 검사합니다.
직접 역할을 바꿔 가며 확인하는 순서는 역할별 수동 테스트에 있습니다.
플랫폼은 Spring Modulith 기반 17개 모듈로 나뉩니다. 다른 모듈은 공개 서비스와 DTO만
사용하며 구현, 엔티티, 저장소는 각 모듈의 internal 패키지에 숨깁니다. 순환 의존과
레이어 위반은 테스트와 규약 검사에서 실패합니다.
보장하는 것은 넷입니다. 입구가 사람과 에이전트 둘이고, 조회와 변경이 다른 계정으로 갈리며, AI는 판단자가 아니라 1차 분석기이고, 플랫폼 저장소는 대상 DB와 분리됩니다. 모듈 17개의 실제 의존 관계는 Modulith가 생성하는 docs/modules/에 있습니다.
데이터 모델은 한 문장으로 읽힙니다. 인스턴스 하나에 관측·백업·변경 증거가 매달리고, 변경은 요청부터 실행까지 한 사슬로 남습니다.
핵심은 operator 모듈입니다. 새 DBMS 지원은 Operator 구현체가 본체이고 enum, 팩토리,
백업 도구, JDBC 드라이버, 화면 자산은 등록 절차로 다룹니다. 전체 구조는
DESIGN.md, 생성된 모듈 문서는 docs/modules/에 있습니다.
성능과 안정성 주장은 모두 재현 가능한 로그를 남깁니다. 대표 결과만 추리면 다음과 같습니다.
| 검증 | Before | After |
|---|---|---|
| 시점 비교 조회, 50만 행 | 21.269 ms | 0.062 ms |
| 같은 부하의 인덱스 티켓 전후 평균 지연 | 46.378 ms | 0.521 ms |
| 무응답 대상이 폴러 전체를 막던 시간 | 25초 초과 | 약 2초 |
| 세션 화면 10명의 30초간 대상 조회 | 150회 | 14회 |
| Slack 한 문장에서 검증된 소견까지(라이브) | 확인 응답 65.6 ms | 결과 도착 31.7초 |
측정 환경, 명령, 원문 출력은 VERIFICATION.md의 9, 132, 134, 140, 169절에 있습니다.
개발은 2026년 3월에 시작했고 지금까지 커밋 582개가 쌓였습니다. 태그와 CHANGELOG.md를 기준으로 단계를 나누면 다음과 같습니다.
| 기간 | 단계 | 산출물 |
|---|---|---|
| 2026-03 ~ 06월 | MVP 세 가지(이기종 등록·헬스체크, 시점 비교, EXPLAIN 규칙 분석)와 성능·확장 작업 | 태그 이전, 커밋 42개 |
| 2026-07-06 ~ 07-07 | 5기종 지원과 인증·암호화·감사·백업 복원 검증으로 첫 공개, 이어서 심화 네 아크로 다섯 기종을 고르게 다듬고 하드닝 | v1.0.0, v1.0.1, v1.1.0 |
| 2026-07-19 | 운영 병목 다섯 곳(설정 드리프트, 리뷰 게이트, 인덱스 사용 통계, 인시던트, 월간 리포트)을 끊고 콘솔을 사이드바 구조로 개편 | v1.2.0 |
| 2026-07-19 ~ 09-14 | 거버넌스 SQL 워크벤치(조회부터 승인 실행까지), 역할 5종 분리, 실시간 세션 관제, 세션 샘플링 | v1.3.0, v1.3.1 |
| 2026-09-15 ~ 09-17 | Slack 등 네 입구를 하나의 AI 운영 작업 모델로 묶고 콘솔 화면을 사람이 쓰는 순서로 다시 짬 | v1.4.0 |
| 2026-09-17 ~ 09-18 | 화면 재설계 2차, AI로 나가는 값의 가림 수준 셋, 대량 일괄 변경(MySQL·PostgreSQL) | v1.5.0 |
| 2026-09-18 | 대량 일괄 변경을 복합 키와 5기종으로 넓히고, 담지 못하는 범위를 판정으로 못 박음 | v1.6.0 |
| 2026-09-18 | 게시 뒤 확인에서 나온 복합 키 결함 둘(SQL Server 문법, MySQL 성능)과 그것을 놓친 CI 구멍을 막음 | v1.6.1 |
| 2026-09-18 ~ 09-19 | 메타 DB 보존 정책을 표마다 정하고, 그림이 GitHub에서 글자를 잃던 것과 CI 12분을 고침 | v1.6.2 |
이슈와 PR로 작업을 나누는 방식은 v1.3.0 전후부터 자리잡았습니다. 문제는 이슈로 먼저 적습니다. 고친 내용은 PR로 올립니다. 실제로 돌려 본 명령과 출력은 VERIFICATION.md에 절 번호를 붙여 남깁니다. 배포되는 변경은 CHANGELOG에 적습니다. 착수할 작업은 작업 이슈 템플릿으로 예상과 예상 마감을 먼저 적고 끝나면 실제 마감과 어긋난 이유를 채웁니다(CONTRIBUTING.md 참고). 지금까지 이슈 60건(열림 0건, 닫힘 60건), PR 91건이 쌓였습니다.
착수 전에 적은 예상과, 끝난 뒤 채운 실제입니다. 어긋난 이유는 짐작이 아니라 그 작업에서 실제로 있었던 일을 적습니다.
| 이슈 → PR | 작업 | 예상 | 예상 마감 | 실제 마감 | 어긋난 이유 |
|---|---|---|---|---|---|
| #126 → PR #134 | 대량 변경에 복합 기본 키 지원 | 1일 | 09-19 | 09-18 | 행 값 비교가 두 기종 모두 인덱스를 타서 기종별 분기가 필요 없었습니다 |
| #127 → PR #134 | 대량 변경을 Oracle·SQL Server로 확장 | 2일 | 09-21 | 09-18 | 방언에 붙은 것이 메서드 둘뿐이라 배치 실행기 본체를 손대지 않았습니다 |
| #131 → PR #136 | AI 가림 기본값 전환 여부 판정 | 2일 | 09-23 | 09-18 | 판정 일치율이 착수 전에 정한 기준에 못 미쳐 바꾸지 않기로 했고, 전환 작업 자체가 없어졌습니다 |
| #140 → PR #142 | SQL Server 복합 키 문법 오류 수정 | 반나절 | 09-19 | 09-18 | 고치는 것보다 찾는 데 시간이 들었습니다. 고친 뒤 CI가 그 테스트를 아예 돌리지 않던 것도 드러나 워크플로까지 손봤습니다 |
마감을 넘기면 원래 값을 지우지 않고 새 예상을 한 줄 더 적습니다. 없는 예상을 뒤늦게 만들어 넣지 않습니다.
문서가 길어져도 README가 다시 목차가 되지 않도록 별도의 문서 안내에 목적별 읽기 순서와 기록 위치를 정리했습니다.
- 처음 둘러보기: 한 장 요약, 5분 시연
- 설계 이해하기: 설계, AI 판단 규칙, AI 운영 자동화
- 운영·배포하기: 운영, 최소 권한
- API 연동하기: API 빠른 참조
- 직접 눌러보기: 역할별 수동 테스트
- 현재 화면 보기: 화면 갤러리
- 근거 확인하기: 검증 기록, 변경 이력
- 개발에 참여하기: 기여 가이드, 저장소 규칙
| 용도 | 요구사항 |
|---|---|
| 셀프호스트 | Docker, Docker Compose, 앱 컨테이너 메모리 512MB~1GB 권장 |
| 소스 개발 | JDK 21, Docker |
| 메타 DB | PostgreSQL 16, compose에 포함 |
| 관리 대상 | MySQL 8.0+, PostgreSQL 13+, SQL Server 2019+, Oracle 19c/Free, MongoDB 6.0+ |