Skip to content

Engineering Case Studies

범수 edited this page Sep 12, 2026 · 1 revision

Engineering Case Studies

기능 수보다 판단 과정을 보여주기 위해, DBTower에서 가장 중요한 다섯 사례를 상황 -> 결정 -> 검증 -> 배운 점으로 정리했습니다.

1. Agent 권한 경계를 프롬프트 밖으로 옮기기

상황. 자연어 진단 Agent가 관리자 서비스 토큰으로 MCP 도구를 호출했고, 대상 DB의 SQL 문자열도 모델 입력에 포함됐습니다. 프롬프트 인젝션이 모델을 설득하면 다른 팀 인스턴스를 조회할 여지가 있었습니다.

결정. 도구 정책을 순수 함수로 분리하고, 허용 도구·호출자 팀 범위·대상 인스턴스 ID를 코드로 고정했습니다. 검사한 입력과 실행할 입력도 같은 정규화 값을 사용했습니다.

검증. 공격 문자열을 넣은 세션 결과와 규칙을 무시하는 가짜 모델로 다른 인스턴스 호출을 시도했지만 REST 도달은 0건이었습니다. 가드를 제거하면 새 테스트 2건이 실패했습니다.

배운 점. Agent 보안은 모델이 지시를 따를 확률이 아니라, 모델이 틀려도 넘지 못하는 실행 경계에서 나옵니다.

2. 승인된 변경만 실행하기

상황. SQL 분류기와 승인 화면만으로는 승인된 SQL과 실제 실행된 SQL이 같거나 안전하다고 보장할 수 없습니다. 동시 실행과 되돌리기 충돌도 별도 문제였습니다.

결정. APPROVED 상태의 조건부 UPDATE로 실행권을 한 요청만 획득합니다. 같은 트랜잭션에서 변경 전 행을 잠그고 복사한 뒤, 사본 행 수와 DB가 보고한 영향 행 수가 같을 때만 커밋합니다. 되돌리기는 사본과 현재 행이 같은 경우에만 파라미터 바인딩으로 수행합니다.

검증. MySQL, PostgreSQL, SQL Server, Oracle, MongoDB에서 변경과 되돌리기를 확인했습니다. 동시에 실행한 두 요청은 [200, 409], 일부러 틀린 사본 조회를 준 계획은 커밋 0건이었습니다.

배운 점. 안전은 텍스트를 잘 해석하는 데서 끝나지 않고, 해석이 틀려도 상태를 보호하는 불변식으로 완성됩니다.

승인 티켓의 실행과 전후 비교

3. 느린 외부 호출이 내부 자원을 점유하지 않게

상황. AI 응답을 SSE로 흘려도 서비스 메서드 전체가 트랜잭션이면 모델을 기다리는 동안 플랫폼 DB 커넥션을 계속 점유합니다. 멈춘 CLI 자식은 부모만 종료해도 출력 파이프를 잡고 남았습니다.

결정. AI 호출과 스트리밍은 트랜잭션 밖에서 실행하고 저장 구간만 짧게 묶었습니다. 프로세스 제한 시간은 출력 소비와 독립적으로 재고, 시간 초과 시 자손부터 종료했습니다.

검증. 동시 AI 요청 4건의 active 커넥션은 4 -> 0, Linux CI에서 20초 넘게 남던 프로세스는 약 2.01초에 종료됐습니다.

배운 점. 사용자가 보는 스트리밍과 서버 자원 수명은 별개의 문제이며 둘 다 계측해야 합니다.

4. 응답 없는 대상 하나가 전체를 멈춘 장애

상황. 연결만 받고 말이 없는 SQL Server 대상에서 풀 생성이 prelogin 읽기에 멈췄습니다. 그 상태로 computeIfAbsent 락을 잡아 다른 인스턴스의 폴러와 삭제 API까지 줄을 섰습니다.

결정. 소켓 서버로 장애를 재현한 뒤 드라이버 로그인 단계에만 읽기 제한을 걸었습니다. 실제 백업처럼 로그인 후 오래 걸리는 작업에는 같은 제한을 적용하지 않았습니다.

검증. SQL Server·Oracle 헬스체크가 25초 초과 -> 약 2초로 줄었고, 로그인 뒤 7초 동안 응답하는 장기 작업은 끝까지 받았습니다.

배운 점. 타임아웃은 짧을수록 좋은 설정이 아니라, 실패 단계와 정상 장기 작업의 경계를 이해하고 두어야 합니다.

5. 테스트가 초록이어도 실제 DB를 믿기

상황. 공통 JDBC setReadOnly(true) 테스트가 통과했지만 Oracle에서는 쓰기를 막지 않았습니다. Data Guard 지연 쿼리의 value != ''도 빈 문자열을 NULL로 보는 Oracle에서는 항상 거짓이었습니다.

결정. 쓰기 권한 계정으로 실제 INSERT를 시도하고, 복제 환경의 서버 값을 플랫폼 응답과 대조했습니다. Oracle에는 명시적 읽기 전용 트랜잭션 훅을 추가하고 쿼리를 수정했습니다.

검증. 실제 Data Guard 서버의 41초 지연과 플랫폼의 41.0초가 일치했습니다. 변경 계정의 최소 권한도 승인 티켓을 끝까지 실행하며 검증했습니다.

배운 점. 이기종 시스템의 공통 인터페이스는 동작을 같게 보이게 하는 장치이지, 기종 차이를 없애는 장치가 아닙니다.

근거 찾기

사례 상세 문서 검증 절
Agent 권한 경계 PORTFOLIO-AX 사례 1 126
승인 변경 실행 PORTFOLIO-AX 사례 5 130~132
AI 스트리밍과 자원 PORTFOLIO-AX 사례 11 141~148
무응답 대상 격리 PORTFOLIO-AX 사례 9 134
실DB 검증 한 장 요약 123·128·151

Clone this wiki locally