테마
화면 요구 재협상서 (템플릿)
09화에서 제정했다. T1 「단건 SQL 튜닝 리포트」의 자매 문서다. T1에 "이 SQL을 어떻게 고쳤는가"를 적는다면, 이 문서에서는 "이 화면이 정말 그것을 물어야 하는가"를 화면 주인과 함께 정한다. 설계를 바꾸는 것도 튜닝이다. 다만 혼자 정하지 않는다.
왜 이 문서가 있는가
2019-05-20 hd.kang
정산 목록 페이징: ROWNUM 을 안쪽 인라인뷰로 옮김. 바깥에 두면 전체를 정렬함.
총건수 표시는 정산팀 화면 요구사항.강도현의 SQL은 그때 할 수 있는 최선이었다(Top-N 정렬까지 챙겼다). 문제는 SQL 바깥에 있었다.
| 화면이 묻던 것 | 그 대가 (09화 실측) | 실제로 필요했던 것 |
|---|---|---|
"총 몇 건": 매 페이지 COUNT(*) | 페이지마다 5,826블록 | 아무도 보지 않았다. 정본은 월말 정산 리포트 |
| "990번째 다음 10건": 페이지 번호 | 페이지가 깊을수록 커진다(rev01 1,000페이지 10,037) | "어제 마감분": 날짜 하나 |
SQL만 고쳐서 도달한 바닥은 4,372였다. 화면의 질문을 바꾸자 약 15가 됐다. 그 질문을 정한 사람(예전 팀장)은 이미 팀을 떠났고, 그 요구를 다시 물은 사람은 없었다.
요구사항도 늙는다. 처음 정한 사람이 떠나면 그 요구의 이유도 같이 떠난다. 이 문서는 요구의 이유와 재협상 조건을 남기는 문서다(06화 힌트 유효기간 대장과 같은 생각이다).
언제 쓰는가
| 신호 | 예 |
|---|---|
| SQL을 고쳐도 바닥이 화면의 질문 때문에 정해질 때 | 총건수 · 임의 페이지 점프 · "전체 보기" · 모든 컬럼 정렬 허용 |
| 비용이 입력 크기·페이지 깊이에 비례하고 그 크기가 계속 자랄 때 | OFFSET 페이징 · 기간 제한 없는 조회 · 전체 내려받기 |
| 01화 T9 중단 기준 ⓓ: 설계를 바꿔야 하는 문제로 밝혀질 때 | "그건 튜닝이 아니라 재협상이다" → 이 문서를 쓴다 |
작성 규칙
| 규칙 | |
|---|---|
| 화면 주인과 같이 쓴다 | 튜너 혼자 채운 재협상서는 무효다. 서명란이 있는 것도 그래서다 |
| "왜"를 먼저 묻는다 | "총건수를 없애도 되나요?"가 아니라 "총건수는 어디에 쓰세요?"라고 묻는다 |
| 비용은 숫자로 쓰고, 사용자의 말로 옮긴다 | Buffers 11,652 → 15와 함께 "한 번 누를 때 읽는 양이 700분의 1 남짓"이라고 쓴다 |
| 없애는 것과 대신하는 것을 짝으로 쓴다 | "페이지 번호 점프 삭제"만 쓰지 않는다. "→ 날짜로 가기"를 같이 쓴다 |
| 기각한 안도 적는다 | 화면을 못 바꿀 때의 차선(B안)과 그 비용 |
| 「다음 재협상 조건」은 비울 수 없다 | 비어 있으면 반려한다. "필요시"는 쓰지 않는다. 사건으로 쓴다("정렬 기준이 추가될 때") |
양식
┌──────────────────────────────────────────────────────────────────────┐
│ 화면 요구 재협상서 — ○호 │
├──────────────────────────────────────────────────────────────────────┤
│ 화면 : ________________ 화면 주인 : ______ (부서·이름) │
│ 관련 SQL : 조각 ID / SQL_ID / 리비전 (rev__ → rev__) │
│ 연결 리포트 : T1 __호 │
├──────────────────────────────────────────────────────────────────────┤
│ 1. 지금 화면이 묻는 것과 그 값 │
│ 질문 │ 지금 방식 │ 한 번 조작의 값 (Buffers) │
│ ________________│________________________│___________________________│
│ │
│ 2. 화면 주인에게 물은 것 ★ 답을 그대로 적는다 │
│ Q1. 그 숫자(총건수 등)를 누가 · 무엇에 쓰나? → __________________ │
│ Q2. 그 페이지(깊은 페이지)까지 왜 가나? → __________________ │
│ Q3. 정렬 기준은 몇 개 필요한가? → __________________ │
│ Q4. (화면별) _____________________________ → __________________ │
│ │
│ 3. 합의 — 없애는 것 / 대신하는 것 │
│ 없앤다 : ________________ 대신 : ________________ │
│ │
│ 4. 효과 (전 → 후, 실측) │
│ 한 번 조작 : ______ → ______ 블록 (사용자 언어로: ______________) │
│ 페이지 깊이에 따른 변화 : ________________________________________ │
│ │
│ 5. 기각한 안 (B안) — 화면을 못 바꿀 때의 차선과 그 비용 │
│ __________________________________________________________________ │
│ │
│ 6. 정합성 — 같은 데이터를 보여 주는가 (양방향 MINUS · 경계 페이지) │
│ __________________________________________________________________ │
│ │
│ 7. 다음 재협상 조건 ★ 비우면 반려 │
│ __________________________________________________________________ │
│ │
│ 서명 : 화면 주인 ________ 튜너 ________ 일자 ________ │
└──────────────────────────────────────────────────────────────────────┘칸 설명
| 칸 | 적는 것 | 비었을 때 |
|---|---|---|
| 1. 지금 화면이 묻는 것 | 화면 요소 하나당 한 줄. 그 요소를 만드는 SQL과 한 번 조작의 Buffers | 무엇을 재협상하는지 알 수 없다 |
| 2. 물은 것 ★ | 질문과 화면 주인의 답을 그대로 적는다. 튜너의 해석은 3번에 적는다 | 반려 |
| 3. 합의 | "없앤다"와 "대신한다"를 짝으로 적는다 | 사용자가 잃는 것만 남는다 |
| 4. 효과 | 실측값. 페이지 깊이(또는 기간·건수)에 따른 변화도 적는다. 1페이지만 재면 OFFSET의 비용이 보이지 않는다 | 반려 |
| 5. 기각한 안 | 재협상이 안 됐다면 갔을 길 | 다음 사람이 같은 고민을 반복한다 |
| 6. 정합성 | 바뀐 화면이 같은 행을 같은 순서로 보여 주는가. 정합성_회귀_체크리스트.md를 쓴다. 페이징이면 C 항목(잘라 내기 전 전체)을 빼지 않는다 | 반려 |
| 7. 다음 재협상 조건 ★ | 사건으로: 정렬 기준 추가 · 검색 조건 추가 · 데이터 규모 N배 · 화면 주인 변경 | 반려 |
자주 나오는 질문 — 그리고 대개의 답
| 화면 요소 | 물을 것 | 흔한 답 | 대신하는 것 (09화 실측) |
|---|---|---|---|
| 총건수 | 누가 무엇에 쓰나 | 0건인지만 본다 · 정본은 다른 리포트 | "다음 있음" (11번째 행, 추가 0) · "1,000건 이상" (13) · 통계 행수 (14, 테이블 0) |
| 페이지 번호 점프 | 그 페이지에서 무엇을 찾나 | 특정 날짜 · 특정 거래처 | "날짜로 가기" (15) · 검색 조건 |
| 마지막 페이지 | 왜 끝으로 가나 | 가장 오래된 것을 보려고 | 정렬 방향 전환 (같은 인덱스를 반대로 읽는다) |
| 모든 컬럼 정렬 | 실제로 쓰는 정렬은 몇 개인가 | 한두 개 | 쓰는 정렬만 인덱스로 받친다. 나머지는 검색 결과 안에서만 |
| 전체 내려받기 | 몇 건을, 얼마나 자주 | 한 달 치 · 월 1회 | 기간 필수화 · Fetch 크기 확인 (ARRAYSIZE 15 → 1000: 왕복 1,827 → 29) |
작성 예 (09화 · 1호)
┌──────────────────────────────────────────────────────────────────────┐
│ 화면 요구 재협상서 — 1호 │
├──────────────────────────────────────────────────────────────────────┤
│ 화면 : 정산 목록 화면 주인 : 정산팀 조민우 │
│ 관련 SQL : Q4 + Q4c (PKG_ORD_STLM) · rev00 → rev02 │
│ 연결 리포트 : T1 7호 │
├──────────────────────────────────────────────────────────────────────┤
│ 1. 지금 화면이 묻는 것과 그 값 (100페이지째 기준) │
│ 페이지 번호 (10건씩) │ ROWNUM 페이징 + 전체 정렬 │ 5,826 │
│ 총 N건 │ 매 페이지 COUNT(*) │ 5,826 │
│ │ │ 계 11,652 │
│ │
│ 2. 화면 주인에게 물은 것 │
│ Q1. 총건수는 어디에 쓰나? → "0건인지만 본다. 정확한 건수는 월말 │
│ 정산 리포트에서 맞춘다." │
│ Q2. 100페이지까지 왜 가나? → "어제 마감분 보려고. 하루 900건이 넘어 │
│ 90 몇 페이지까지 가야 한다." │
│ Q3. 정렬 기준은? → "최신순. 금액순은 있으면 좋겠다." │
│ │
│ 3. 합의 │
│ 없앤다 : 총건수 · 페이지 번호 점프 │
│ 대신 : "다음 페이지 있음" · "날짜로 가기" · 다음/이전 │
│ │
│ 4. 효과 (실측) │
│ 한 번 조작 : 11,652 → 약 15 블록 (한 번 누를 때 읽는 양 700분의 1 남짓) │
│ 페이지 깊이 : rev00 어느 페이지든 5,826 / rev02 어느 페이지든 15~18 │
│ │
│ 5. 기각한 안 │
│ B안) 페이지 번호 유지 + 늦은 테이블 방문 (ROWID 만 인덱스에서 센다) │
│ 100페이지 16 · 1,000페이지 46 · 마지막 3,356. 깊을수록 커진다 │
│ C안) PGA 증설 — 멈추는 페이지가 뒤로 밀릴 뿐, Buffers 5,826 그대로 │
│ │
│ 6. 정합성 │
│ (정합성 회귀 체크리스트 · T1 7호 첨부) │
│ 100페이지 MINUS 0 / 0 · 92페이지(날짜 경계) 0 / 0 │
│ 10만 페이지 전체 순회 : 행 1,000,000 · 어긋난 행 0 │
│ │
│ 7. 다음 재협상 조건 │
│ · 정렬 기준이 추가될 때 (예: 금액순) — 기준마다 인덱스·포스트잇 필요 │
│ · 화면에 검색 조건이 생길 때 │
│ · 화면 주인(정산팀 담당)이 바뀔 때 │
│ │
│ 서명 : 화면 주인 조민우 튜너 (나) 일자 4월 29일 │
└──────────────────────────────────────────────────────────────────────┘운용
| 언제 | 무엇 |
|---|---|
| 재협상이 끝났을 때 | 리비전 파일 머리말에 재협상서 번호를 적는다(Q4_rev02 ← 재협상서 1호) |
| 다음 재협상 조건이 걸렸을 때 | 화면 주인과 다시 마주 앉는다. 이전 호의 Q를 그대로 다시 묻는다 |
| 화면 주인이 바뀌었을 때 | 새 주인에게 이 문서를 넘긴다. 요구의 이유가 사람과 함께 떠나지 않게 |
| 정기 점검 (T8) | 재협상서마다 4번의 값을 다시 잰다 |
| 졸업 판정 (18화) | 원장 재측정 때 재협상으로 바뀐 조각을 따로 표시한다. SQL 개선과 설계 개선을 섞지 않는다 |
관련: T1_단건SQL_튜닝리포트.md · 정합성_회귀_체크리스트.md · 힌트_유효기간_대장.md · 09화 2_파고들기.md §13