Builder Workflow

DBTower는 요구사항 목록을 받아 구현한 프로젝트가 아니라, 반복되는 운영 문제를 발견하고 제품 경계와 검증 방법까지 함께 정의한 프로젝트입니다.

1. 문제를 먼저 구조화한다

출발점은 개발팀이 DB 문제를 해결하려면 기종별 도구를 오가고 결국 DBA에게 같은 질문을 반복한다는 문제였습니다. 여기서 기능을 바로 나열하지 않고 사용자 흐름을 먼저 정했습니다.

문제 발견 -> 근거 수집 -> 원인 진단 -> 변경 요청 -> 승인 -> 실행 -> 결과 확인

관제와 워크벤치를 별도 제품으로 나누는 안도 검토했지만, 인스턴스·팀 범위·감사·티켓을 공유하고 한 운영 흐름이 두 화면을 오가므로 하나의 제품에 두 모드로 두었습니다.

질문	선택
AI가 SQL을 바로 실행해도 되는가	제안만 하고 실행은 사람과 워크벤치 경계를 통과
자연어 진단의 권한은 어디서 지키나	프롬프트가 아니라 도구 호출 가드와 REST 인가
변경 안전을 SQL 파서가 보장하나	행 사본·영향 행 수·상태 전이 불변식으로 보장
DBMS별 구현은 어디서 갈라지나	`DbmsOperatorFactory` 한 곳에서 선택
미지원 지표를 어떻게 보이나	값을 만들지 않고 `UNSUPPORTED`와 사유 표시

빠른 프로토타입 뒤에는 반드시 실제 DB와 브라우저에서 전체 흐름을 밟았습니다. 그 과정에서 발견한 한계는 문서에 남기고 다음 작업의 입력으로 사용했습니다.

영역	직접 다룬 범위
Frontend	관제·워크벤치 SPA, 스키마 트리, SQL 편집기, 결과 그리드, SSE 상태, 역할별 동작
Backend	16개 Modulith 모듈, REST, 보안, 감사, 작업 스케줄러, 변경 트랜잭션
Agent	tool-use loop, MCP, 컨텍스트 구성, 프롬프트 규칙, trace, 스트리밍, 평가
Data	PostgreSQL 메타 모델, 스냅샷·파티셔닝, 보존, 감사와 실행 사본
Infrastructure	Docker Compose, Kubernetes, Terraform, Ansible, Prometheus, Grafana
Reliability	커넥션 격리, 타임아웃, 분산 조회권, 백업·복원 검증, 장애 재현

Agent에게 많은 자율성을 주려면 자연어 지시만 늘리는 것이 아니라, 잘못된 변경이 자동으로 실패하는 환경이 필요합니다.

이 구조는 Agent가 코드를 많이 만드는 것보다, 변경 이유와 실패 조건을 다음 작업자에게 전달하고 스스로 검증하게 만드는 데 초점을 둡니다.

SQL Server의 실행 시간이 CI 머신마다 두 배 이상 흔들리자 성능 주장에서 제외하고, 반복해서 같았던 실행계획과 논리 읽기만 남겼습니다.
구조 비교가 외래키를 수집하지 못해 차이 없음을 표시한 사실을 먼저 기록한 뒤 모델과 diff를 확장했습니다.
소스의 원시 NUL 한 바이트가 Git diff를 바이너리로 만들자 값은 유지하고 표기를 고친 뒤 규약 검사로 재발을 막았습니다.
화면을 실제 역할별로 누르며 UTC 표시와 좁은 화면 오버플로를 발견하고 Playwright 회귀 테스트로 고정했습니다.

이 프로젝트는 Java/Spring과 정적 SPA를 사용합니다. Spring Modulith는 한 프로세스 안에서 모듈 경계를 빌드로 검증하기 위해, 정적 SPA는 별도 프론트 빌드체인 없이 셀프호스트 배포 단위를 하나로 유지하기 위해 선택했습니다.

MCP는 SDK 없이 JSON-RPC 코어를 구현해 프로토콜과 전송 분리를 직접 확인했습니다. 같은 문제를 프로덕션 팀에서 다시 푼다면 개발 속도, 생태계 호환성, 유지보수 책임을 비교해 공식 SDK 채택도 선택지에 둡니다.