DongHyeonkaandClaude Opus 5
0650d91def
rewriting-technical-prose-naturally 를 서브에이전트 셋으로 나눠 56편에 적용했다. ai-tells.md 의 첫 절대로 다른 표현으로 바꾸는 대신 문장을 통째로 지웠다. 설명한 것의 중요성을 다시 평가하는 꼬리 19 이미 설명한 것을 추상어로 되풀이 19 독자에게 읽는 법을 지시하거나 오해를 가정 9 자료가 뒷받침하지 않는 덧붙인 이득 4 문서군 전체의 문형 편중도 풀었다 — 함께 27→7(한 묶음), 그대로 22→12(두 묶음), 하게 된다 1→0. 한 편에서 세 번 반복되던 「같은 병이 ~에서도 났다」와 두 기록에 같은 문장으로 있던 세 쌍을 갈랐다. 계약 제목 「여덟 자리」가 본문의 「여덟 곳」과 어긋나 있었다. 제목이 spatial-metaphor 규칙에도 걸리므로 계약과 기록을 함께 「여덟 곳」으로 맞췄다. 검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS · check_evidence --repo 문제 없음 · verify-tech-log-tree error 0 warn 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
86 lines
3.8 KiB
Markdown
86 lines
3.8 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: the-sql-had-never-been-executed
|
|
title: 그 SQL 은 한 번도 실행된 적이 없었다
|
|
topic: seams-no-test-crosses
|
|
topicName: 테스트가 지나지 않는 이음매
|
|
project: TechLog
|
|
status: 게시 전
|
|
lastVerifiedOn: 2026-09-04
|
|
sourceRevision: tech-log@2026-09-02
|
|
source:
|
|
- final/document.md#§7.2
|
|
---
|
|
|
|
# 그 SQL 은 한 번도 실행된 적이 없었다
|
|
|
|
작업본 삭제가 500 을 돌려줬다. 참조 검사가 없는 컬럼을 조회하고 있었다. 진짜 문제는 그 SQL 이 한 번도 실행된 적이 없다는 것이었다 — 표준 `check` 는 Testcontainers 를 띄우지 않으므로 persistence SQL 을 한 줄도 돌리지 않고 빌드가 통과한다.
|
|
|
|
## 관계
|
|
|
|
- **이음매마다 그 이음매를 실제로 지나는 검사를 하나씩 둔다**
|
|
persistence SQL 이 그 목록의 한 줄이다.
|
|
- **파드가 두 번 CrashLoopBackOff 로 들어갔다**
|
|
같은 「지나지 않은 이음매」의 다른 예다.
|
|
- **삭제를 막는 이유 다섯 가지가 전부 같은 한 문장으로 나온다**
|
|
이 참조 검사가 지금도 남긴 문제다.
|
|
|
|
## 문제
|
|
|
|
작업본을 지우려 하면 500 이 났다. 참조 검사가 `public_resource_projection.document_id` 를 조회하는데 그런 컬럼이 없다.
|
|
|
|
이 테이블은 하나로 case·question·project·release 를 모두 담기 때문에 종류와 식별자 두 컬럼으로 기록을 가리킨다.
|
|
|
|
## 결론
|
|
|
|
컬럼 이름 하나가 틀렸고, 그 쿼리가 한 번도 실행된 적이 없었다.
|
|
|
|
> 그 쿼리의 여섯 컬럼 중 다섯은 마이그레이션과 대조했다. 이 하나만 가정했고, 그것이 틀렸다.
|
|
|
|
표준 `check` 는 Testcontainers 를 띄우지 않는다. persistence SQL 은 한 번도 실행되지 않은 채 빌드가 통과하고, 컴파일도 단위 테스트도 컬럼 이름을 검증하지 못한다.
|
|
|
|
삭제 경로 전용 통합 테스트 태스크를 만들고 실패했던 그 쿼리를 포함해 여덟 시나리오를 실제 PostgreSQL 에서 돌린다.
|
|
|
|
## 검증 환경
|
|
|
|
tech-log-backend : 37f474a 이후
|
|
DB : 실제 PostgreSQL (Testcontainers)
|
|
빌드 : 표준 check 는 Testcontainers 를 띄우지 않음
|
|
확인 방식 : 삭제 경로 전용 통합 테스트 태스크에서 여덟 시나리오 실행
|
|
|
|
## 재현 조건
|
|
|
|
1. 어댑터의 SQL 에서 컬럼 이름을 하나 틀리게 적는다
|
|
2. `./gradlew check` 를 돌린다 — 통과한다
|
|
3. 삭제 경로 통합 테스트 태스크를 돌린다 — 그 쿼리에서 멈춘다
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
## 없는 컬럼을 조회했다
|
|
|
|
`public_resource_projection` 은 한 테이블이 case·question·project·release 를 모두 담는다. 그래서 기록을 가리킬 때 종류와 식별자 두 컬럼을 함께 쓴다. `document_id` 라는 컬럼은 없다.
|
|
|
|
참조 검사가 그 이름을 쓰고 있었고, 실행하면 500 이 났다.
|
|
|
|
## 다섯은 대조했고 하나는 가정했다
|
|
|
|
> 그 쿼리의 여섯 컬럼 중 다섯은 마이그레이션과 대조했다. 이 하나만 가정했고, 그것이 틀렸다.
|
|
|
|
## 그 SQL 은 한 번도 실행되지 않았다
|
|
|
|
표준 `check` 는 Testcontainers 를 띄우지 않으므로 persistence SQL 이 한 줄도 실행되지 않은 채 빌드가 통과한다.
|
|
|
|
컴파일은 SQL 문자열 안을 보지 않는다. 단위 테스트는 어댑터를 스텁으로 바꾼다. 컬럼 이름이 맞는지 묻는 검사가 어디에도 없었다.
|
|
|
|
## 전용 태스크로 여덟 시나리오를 돌린다
|
|
|
|
삭제 경로 전용 통합 테스트 태스크를 만들었다. 실패했던 그 쿼리를 포함해 여덟 시나리오를 실제 PostgreSQL 에서 돌린다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
이 태스크가 덮는 것은 삭제 경로다. 표준 `check` 는 여전히 Testcontainers 를 띄우지 않고, 새 어댑터 SQL 이 이 태스크에 등록되는지 보는 검사도 없다.
|
|
|
|
<!-- body:end -->
|