이 도구가 해결하는 일

MyBatis 로그에는 SQL이 ? 투성이인 Preparing: 줄과, 값 목록인 Parameters: 줄로 나뉘어 찍힙니다. 장애 분석 때 이 둘을 눈으로 짝지어 물음표에 값을 하나씩 끼워 넣는 작업 — 파라미터가 스무 개쯤 되면 반드시 한 칸씩 밀립니다. 이 도구는 두 줄을 붙여넣으면 자동으로 짝지어 DB 툴에 바로 붙여 실행할 수 있는 SQL을 만들어 줍니다.

운영 쿼리와 파라미터는 민감한 데이터입니다 — 조립은 전부 브라우저 안에서 끝나고, 어떤 값도 외부로 전송되지 않습니다.

타입별 리터럴 규칙 — 왜 그냥 치환하면 안 되나

물음표에 값을 끼울 때는 JDBC 타입에 따라 SQL 리터럴 문법이 달라야 합니다. 이 도구는 Parameters 줄의 타입 표기((String)·(Integer)…)를 읽어 규칙을 적용합니다:

실무 시나리오

• 슬로우 쿼리 재현 — APM이 짚은 느린 쿼리의 로그를 조립해 DB 툴에서 실행 계획을 뜹니다. 물음표 상태로는 실행 계획을 볼 수 없습니다.
• "왜 0건이지?" 추적 — 서비스가 빈 결과를 돌려줄 때, 실제 바인딩된 값으로 조립한 SQL을 직접 실행해 조건 어디서 걸러졌는지 확인합니다.
• 이슈 공유 — 재현 SQL을 그대로 티켓에 붙입니다. 받은 사람이 로그 두 줄을 다시 짝지을 필요가 없습니다.

예시

Preparing: SELECT * FROM orders WHERE user_id = ? AND status = ? AND amount > ?
Parameters: 1024(Long), PAID(String), 50000(Integer)

→ 조립 결과

SELECT * FROM orders WHERE user_id = 1024 AND status = 'PAID' AND amount > 50000

자주 겪는 함정

• 물음표·파라미터 개수 불일치 — 로그가 잘렸거나 다른 쿼리의 Parameters를 붙인 경우입니다. 개수가 안 맞으면 어디서 어긋났는지 알려줍니다.
• 값 안의 쉼표 — 서울, 부산(String)처럼 값에 쉼표가 든 경우도 타입 표기를 기준으로 분리해 오분할을 줄입니다.
• 동적 SQL의 함정 — 로그의 SQL은 조건 분기(if·choose)가 이미 풀린 결과입니다. 매퍼 XML과 모양이 다른 것은 정상입니다.
• 재실행 주의 — 조립된 UPDATE·DELETE를 그대로 실행하면 운영 데이터가 바뀝니다. SELECT로 바꿔 확인하거나 트랜잭션으로 감싸세요.

사용 순서

• ① 로그에서 Preparing: 줄과 Parameters: 줄을 함께 복사합니다 — 접두사가 붙은 채로 붙여넣어도 인식합니다.
• ② 붙여넣는 즉시 물음표 개수와 파라미터 개수를 대조해 조립 결과 또는 불일치 경고가 나옵니다.
• ③ "정리해 보기"로 들여쓰기·구문 색을 입혀 조건 구조를 확인합니다.
• ④ 복사해 DB 툴에서 실행합니다 — 변경 쿼리라면 SELECT로 바꾸거나 트랜잭션으로 감싼 뒤에.

로그 설정 팁

바인더의 재료인 Parameters 로그는 MyBatis 로그 레벨이 낮으면 아예 찍히지 않습니다. 개발·검증 환경에서는 매퍼 로거를 상세 레벨로 열어 두는 편이 장애 분석 속도를 크게 줄입니다 — 단, 운영 환경은 파라미터에 개인정보가 실릴 수 있어 로그 정책과 마스킹 규정을 먼저 확인해야 합니다. 로그가 없어 재현 SQL을 못 만드는 상황과, 로그에 민감정보가 남는 상황 — 둘 사이의 균형은 조직의 규정이 정합니다.

바인더가 아끼는 시간의 정체

물음표 스무 개짜리 쿼리를 손으로 짝지으면 5분, 틀리면 다시 5분입니다 — 그리고 틀렸다는 사실은 실행 결과가 이상할 때에야 드러납니다. 장애 상황에서 이 왕복은 치명적입니다. 자동 조립은 시간 단축보다 확신을 줍니다: 개수 검증을 통과한 SQL은 적어도 "값이 밀려 들어간" 종류의 오류가 없다는 보증이 되고, 분석의 출발점을 신뢰할 수 있게 됩니다.

팀 차원에서는 장애 대응 절차에 이 도구를 끼워 넣는 방식이 효과적입니다 — "로그에서 Preparing/Parameters를 복사해 바인더로 조립한 SQL을 티켓에 첨부"를 표준 절차로 정하면, 담당자가 바뀌어도 재현 SQL의 품질이 일정해집니다.

자주 묻는 질문

여러 쿼리가 섞인 로그도 되나요?

Preparing/Parameters 짝 단위로 처리합니다. 한 쌍씩 붙여넣는 것이 가장 정확합니다.

조립된 SQL이 보기 어려운데요.

"정리해 보기"가 SQL 포맷터로 들여쓰기·구문 색을 입혀 줍니다 — 자매 앱 DoffKit의 SQL 포맷터와 같은 엔진입니다.

운영 파라미터를 붙여넣어도 안전한가요?

모든 처리가 브라우저 안에서 끝나고 네트워크 전송이 없습니다. 다만 조립 결과를 티켓에 붙일 때 개인정보가 남는지는 확인하세요.

타입 표기가 없는 로그는요?

타입을 모르면 문자열 취급이 안전한 기본값입니다 — 숫자 컬럼이면 따옴표만 지우면 됩니다.

IN (?, ?, ?) 같은 다중 바인딩도 되나요?

물음표 순서대로 값을 끼우므로 그대로 동작합니다. 개수 불일치가 있으면 경고합니다.

함께 쓰는 도구

조립한 SQL의 IN절을 새 값 목록으로 다시 만들려면 IN절·INSERT 생성기, 테이블 구조 확인은 DDL ↔ 정의서, 테스트 데이터가 필요하면 목데이터 생성으로 이어가세요.