감사 대응에도 난이도 조절이 필요하다

감사 로그 대응 문서를 정리하다가, 꽤 웃긴 장면을 만났다.

처음 목표는 단순했다.

“고객이 감사 로그를 달라고 할 때, 더 정확하게 대응하자.”

좋은 목표다. 그런데 문서를 만들다 보면 이상한 일이 벌어진다. 정확하게 하려다 보니 체크리스트가 생긴다. 체크리스트가 생기니 템플릿이 생긴다. 템플릿이 생기니 패키지가 생긴다. 패키지가 생기니 manifest, validation status, evidence matrix 같은 친구들이 줄지어 들어온다.

어느 순간 이런 생각이 든다.

“잠깐. 고객은 그냥 이 로그가 Export 되는지 물어본 것뿐인데?”

오늘 이야기는 그 지점에서 시작한다. 감사 대응을 정확하게 하려면 원칙이 필요하다. 하지만 모든 요청을 풀코스 정찬처럼 대접하면, 대응 자체가 무거운 제품이 된다.

로그 요청은 다 같은 요청이 아니다

고객이 “감사 로그가 필요합니다”라고 말할 때, 실제 의미는 천차만별이다.

어떤 고객은 메뉴 위치를 묻는다.

DB 접속 이력은 어디서 볼 수 있나요?

어떤 고객은 Export 가능 여부를 묻는다.

이 기간의 Query Audit을 파일로 받을 수 있나요?

어떤 고객은 여러 증거를 이어 붙이고 싶어 한다.

승인된 SQL Request가 실제로 실행됐고,
그 실행의 Before/After 값까지 제출해야 합니다.

세 요청을 같은 무게로 처리하면 안 된다. 첫 번째 요청에 evidence matrix를 만들면 과하다. 세 번째 요청에 “화면에서 확인 가능합니다”라고만 답하면 위험하다.

그래서 이번에 정리한 핵심은 단순하다.

Light / Standard / Full

감사 대응에도 난이도 조절이 필요하다는 뜻이다.

Light: 그냥 길을 알려주면 되는 순간

Light 대응은 가장 가볍다.

표준 기능으로 답할 수 있는 경우다. 메뉴 위치, Export/API 가능 범위, 어떤 로그를 봐야 하는지 정도를 안내한다.

이때 필요한 건 거대한 패키지가 아니다. 좋은 첫 답변이다.

예를 들면 이런 식이다.

DB 접속/해제 이력은 DB Access History 또는 Audit Log Export,
실제 실행 SQL은 Query Audit,
Workflow 승인 이력은 Workflow Report/Export 기준으로 나누어 확인하는 것이 적절합니다.

짧지만 중요한 구분이 들어 있다.

접속 이력과 실행 SQL은 다르다. Workflow 승인 이력과 실제 실행 이력도 다르다. 고객이 “감사 로그”라고 뭉뚱그려 말해도, 우리는 먼저 무엇을 확인하려는지 나눠줘야 한다.

Light에서 하지 말아야 할 것도 있다.

• schema evidence matrix 만들기
• preflight SQL 만들기
• COUNT preview 만들기
• manifest 만들기
• validation status 붙이기

이런 건 정확해 보이지만, 단순 문의에는 불필요한 무게다. 작은 질문에는 작은 답변이 더 친절하다.

Standard: SQL을 줄 거면 안전벨트는 매자

Standard는 고객에게 MetaDB 보조 SQL을 전달해야 하는 경우다.

여기서부터는 분위기가 달라진다. 운영 DB를 직접 조회하는 순간, “대충 이런 쿼리입니다”로 끝내면 안 된다.

최소한 안전벨트가 필요하다.

1. 고객 버전 확인
2. schema preflight
3. COUNT preview
4. main query
5. limitation 주석
6. 결과 컬럼의 짧은 설명

이건 형식주의가 아니다.

감사 로그 테이블은 크다. 버전마다 schema가 다를 수 있다. 어떤 컬럼은 고객 환경에 없을 수 있다. 기간 조건을 잘못 잡으면 운영 DB에 괜한 부담을 줄 수도 있다.

그래서 Standard의 핵심은 “SQL 하나”가 아니라 “안전하게 실행할 수 있는 SQL”이다.

다만 여기서도 과하게 갈 필요는 없다. 산출물이 1~2개라면 하나의 SQL 파일 안에 섹션을 나눠도 충분하다.

-- 00_preflight
-- 01_count_preview
-- 02_main
-- limitation

고객에게 파일 7개를 보내는 것보다, 잘 정리된 파일 하나가 더 나을 때가 많다.

Full: 진짜 감사 패키지가 필요한 순간

Full은 무겁다. 대신 무거워야 하는 상황에 쓴다.

예를 들어 이런 요청이다.

SQL Request 요청/승인 이력,
실제 Query Audit 실행 이력,
DML Snapshot Before/After,
Ledger 설정 현황과 변경 이력,
업무 사유와 티켓 링크를 함께 제출해야 합니다.

이건 단일 SQL로 해결할 일이 아니다. 사실 단일 SQL로 해결하려고 하면 오히려 위험하다.

Workflow는 요청과 승인 절차를 말한다. Query Audit은 실제 실행을 말한다. DML Snapshot은 변경 전후 값을 말한다. Ledger 설정은 현재 상태와 변경 이력을 또 나눠야 한다.

이 모든 것을 한 줄로 뭉치면 보고서는 빨라 보일지 몰라도, 감사 증거로는 약해진다.

Full에서는 산출물을 나누는 편이 맞다.

workflow_requests.csv
query_audit_executions.csv
dml_snapshot_index.csv
dml_snapshot_before_after_*.csv
ledger_policy_inventory.csv
ledger_policy_change_history.csv
result-column-guide.md
limitation-notice.md

여기서는 manifest나 validation status도 의미가 있다. 나중에 누가 봐도 “무엇을 추출했고, 무엇은 한계였고, 어떤 기준으로 해석해야 하는지”가 남아야 하기 때문이다.

대형 감사 대응은 사건 해결이 아니라 재현 가능한 업무 절차여야 한다.

가장 위험한 말: “쿼리 하나로 뽑아드릴게요”

감사 대응에서 가장 위험한 친절은 이 말일 수 있다.

“쿼리 하나로 뽑아드릴게요.”

물론 가끔은 가능하다. 하지만 복합 감사 요청에서는 이 말이 많은 것을 숨긴다.

• 현재 상태와 과거 이벤트가 섞일 수 있다.
• 승인된 요청과 실제 실행이 섞일 수 있다.
• 실행 건수와 변경 row 수가 섞일 수 있다.
• DML Snapshot UUID와 실제 Before/After 본문이 섞일 수 있다.
• 고객이 제출해야 하는 증거와 내부 분석 근거가 섞일 수 있다.

감사 대응에서 섞임은 편리함처럼 보이지만, 나중에는 설명 부채가 된다.

좋은 대응은 “한 방 쿼리”를 자랑하지 않는다. 대신 이렇게 말한다.

이 요청은 산출물을 나누어 보는 것이 안전합니다.
표준 기능으로 가능한 범위를 먼저 확인하고,
부족한 조합 항목만 고객 버전과 schema 확인 후 보조 조회로 검토하겠습니다.

조금 덜 멋있지만 훨씬 믿음직하다.

문서에도 브레이크가 필요하다

이번 정리에서 가장 마음에 든 부분은 새 템플릿보다 “브레이크”를 넣은 것이다.

문서가 많아질수록 사람은 문서를 더 만들고 싶어진다. 새로운 케이스가 나오면 새 섹션을 붙이고, 새 템플릿을 만들고, 새 상태값을 붙인다.

하지만 운영 문서는 백과사전이 되면 잘 안 쓰인다. 필요한 순간에 빨리 판단하게 해줘야 한다.

그래서 catalog에도 기준을 넣었다.

단발성 고객 요청은 QCP 기록에 둔다.
반복 가능하지만 검증이 부족하면 후보로만 둔다.
2회 이상 반복되고 표준화 가능하면 catalog로 승격한다.
제품 기능으로 제공해야 할 반복 요청은 roadmap 후보로도 남긴다.

이 기준은 문서를 작게 유지하기 위한 방어막이다.

문서화의 목표는 모든 것을 넣는 게 아니다. 다음 사람이 덜 헤매게 하는 것이다.

제품 개선도 한 입 크기로

감사 대응을 하다 보면 금방 큰 아이디어가 나온다.

“Workflow, Query Audit, DML Snapshot, Ledger, Reason, Ticket Link를 모두 연결한 통합 감사 패키지를 만들자!”

멋있다. 그런데 너무 크다.

이런 아이디어는 방향성으로는 좋지만, 제품 구현 단위로 잡으면 범위가 터진다. 그래서 이번에는 이런 기준을 세웠다.

큰 패키지는 umbrella concept로 둔다. 실제 제품 개선은 작게 쪼갠다.

예를 들면:

• Workflow에서 관련 Query Audit으로 이동하기
• Query Audit에서 DML Snapshot availability 보여주기
• Ledger inventory export 만들기
• Workflow approval step pivot export 만들기
• Reason과 ticket link를 구조화하기

큰 문제를 작은 기능으로 쪼개야 제품팀도 움직일 수 있다. “감사 대응 전체 개선”은 너무 크지만, “SQL Request와 실제 Query Audit 연결 개선”은 논의할 수 있다.

좋은 운영 문서는 요리 레시피와 닮았다

좋은 요리 레시피는 모든 요리에 풀코스를 강요하지 않는다.

라면 끓이는데 코스 요리 순서를 들이밀면 웃기다. 반대로 결혼식 케이터링을 라면 끓이듯 처리하면 큰일 난다.

감사 대응도 비슷하다.

Light: 길을 알려준다.
Standard: SQL에 안전벨트를 채운다.
Full: 증거 패키지를 만든다.

이 세 줄만 있어도 대응 품질이 꽤 달라진다.

문서가 좋은 이유는 많아서가 아니다. 선택을 줄여주기 때문이다. 지금 이 요청은 가볍게 끝내도 되는지, 아니면 위험해서 안전장치를 채워야 하는지, 아니면 정식 패키지로 올려야 하는지 알려주면 된다.

오늘의 결론

감사 대응에서 중요한 건 더 많은 SQL이 아니다.

더 정확한 분류다.

모든 고객 요청을 대형 프로젝트로 만들지 않는 것. 반대로 진짜 위험한 요청을 가볍게 넘기지 않는 것. 그 균형이 운영 문서의 실력이다.

그래서 이번 정리의 핵심은 새 프레임워크가 아니다.

오히려 반대다.

프레임워크가 커지기 전에 멈추는 법이다.

작은 질문에는 작은 답변을.
SQL이 필요하면 안전벨트를.
감사 제출이면 재현 가능한 패키지를.

이 정도면 꽤 괜찮은 운영 철학 아닐까.