주제 13개 · Case 28 · Concept 5 · Reference 15 · Question 4 · Decision 4. 계약의 노드마다 종류가 요구하는 칸을 채우고, 본문이 있는 두 종류에는 SSOT 가 이미 그려 둔 도식 셋(value-boundaries · decision-path-404 · topic-variant-model)을 tech-log-studio/ 로 옮겨 붙였다. 새로 그린 그림은 없다. 검사 셋 전부 통과한다. check_body.mjs 56 편 중 본문이 있는 33 편 PASS check_prose.mjs 56 편 error 0 check_evidence.mjs --repo 포함 문제 없음 verify-tech-log-tree.py 프로젝트 5 · error 0 · warn 0 인용한 코드블록은 전부 SSOT 에서 찾아 대조했다. check_evidence.mjs 가 본문의 각 줄과 source 앵커와 계약 제목을 다시 확인한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5.0 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | two-pods-crashlooped-with-no-test-starting-the-context | 파드가 두 번 CrashLoopBackOff 로 들어갔다 — 어떤 테스트도 애플리케이션 컨텍스트를 띄우지 않았다 | seams-no-test-crosses | 테스트가 지나지 않는 이음매 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
파드가 두 번 CrashLoopBackOff 로 들어갔다 — 어떤 테스트도 애플리케이션 컨텍스트를 띄우지 않았다
파드가 두 번 CrashLoopBackOff 로 들어갔다. 한 번은 스캔되는 컴포넌트에 생성자가 둘이었고, 한 번은 이 빌드에 없는 Jackson 2 의 타입을 import 했다. 컴파일도 단위 테스트도 실제 PostgreSQL 위에서 도는 통합 테스트 26개도 전부 통과했다. 그중 어느 것도 애플리케이션 컨텍스트를 띄우지 않는다.
관계
- 이음매마다 그 이음매를 실제로 지나는 검사를 하나씩 둔다 이 사건이 그 목록의 첫 줄이다.
- TypeScript 가 검사를 놓아 주는 네 곳 다른 언어에서 컴파일 통과가 반영의 증거가 아니었던 자매 사건이다.
- 그 SQL 은 한 번도 실행된 적이 없었다 같은 「지나지 않은 이음매」의 다른 예다.
문제
컴포넌트 스캔이 생성자를 고르지 못하면 컨텍스트가 refresh 에 실패한다. 컨텍스트를 띄우는 테스트가 없으면 그 실패는 배포에서 처음 나타난다.
두 번째 사건은 import 였다. JdbcProjectRepositoryAdapter 가 Jackson 2 의 ObjectMapper 를 요구했는데 이 빌드는 Jackson 3 이다.
결론
두 건 다 컨텍스트가 뜰 때 처음 드러났다.
첫 번째 : 스캔되는 컴포넌트에 생성자 둘, @Autowired 없음
두 번째 : Jackson 2 ObjectMapper 를 요구, 이 빌드는 Jackson 3
두 번째가 컴파일을 통과한 이유는 Jackson 2 타입이 어떤 전이 의존성을 통해 클래스패스에 남아 있어서다. 잘못된 import 가 정상적으로 해석된다.
첫 번째는 ArchUnit 규칙으로 막았다. 스캔되는 컴포넌트는 생성자가 하나이거나, 여럿이면 그중 하나에 @Autowired 가 붙어야 한다. 규칙이 실제로 잡는지 결함을 되돌려 확인했다.
검증 환경
tech-log-backend : ca63d7d · 0da7c7e 런타임 : k3s 위의 파드 Jackson : 이 빌드는 Jackson 3, 클래스패스에 Jackson 2 타입이 전이 의존성으로 남아 있음 확인 방식 : ArchUnit 규칙을 결함으로 되돌려 실제로 빨개지는지 확인
재현 조건
- 스캔되는 컴포넌트에 생성자를 둘 만들고
@Autowired를 붙이지 않는다 ./gradlew check를 돌린다 — 통과한다- ArchUnit D20 규칙을 켠 상태로 돌린다 — 그 컴포넌트를 짚는다
본문
어떤 테스트도 컨텍스트를 띄우지 않았다
새 활동 어댑터가 생성자를 둘 갖고 있었다. 하나는 운영용, 하나는 테스트가 id 생성기를 넣기 위한 것이다. 둘 중 어느 것에도 @Autowired 가 없어 컴포넌트 스캔이 고르지 못했다.
컴파일도, 단위 테스트도, 실제 PostgreSQL 위에서 도는 통합 테스트 26개도 전부 통과했다. 그 어느 것도 애플리케이션 컨텍스트를 띄우지 않기 때문이다. 운영에서 파드가 CrashLoopBackOff 로 들어갔고, 그때서야 드러났다.
클래스패스에 남은 옛 타입
두 번째 건은 import 였다. JdbcProjectRepositoryAdapter 가 com.fasterxml.jackson.databind.ObjectMapper 를 요구했다. 이 빌드는 tools.jackson.databind 를 쓰므로 그런 빈이 없고, 컨텍스트가 refresh 에 실패한다.
컴파일이 잡지 못한 이유는 어떤 전이 의존성이 Jackson 2 타입을 클래스패스에 올려 두어 import 가 정상적으로 해석되기 때문이다. 빈이 없다는 것은 컨텍스트를 띄워야 알 수 있다.
| 원인 | 왜 컴파일·테스트가 못 잡았나 | 커밋 |
|---|---|---|
스캔되는 컴포넌트에 생성자 둘, @Autowired 없음 |
어떤 테스트도 애플리케이션 컨텍스트를 띄우지 않는다 | ca63d7d |
Jackson 2 ObjectMapper 를 요구(이 빌드는 Jackson 3) |
Jackson 2 타입이 전이 의존성으로 클래스패스에 남아 있어 import 가 정상 해석된다 | 0da7c7e |
규칙 하나로 막은 절반
D20 규칙을 세웠다. 스캔되는 컴포넌트는 생성자가 하나이거나, 여럿이면 그중 하나에 @Autowired 가 붙어야 한다. 결함을 되돌려 규칙이 실제로 멈추는 것을 확인한 뒤 커밋했다.
막지 못한 절반
D20 은 생성자 쪽만 본다. 클래스패스에 남은 옛 라이브러리 타입을 import 하는 것은 이 규칙이 잡지 않는다. 그 경로를 막는 검사는 아직 없고, 컨테이너가 뜰 때 알게 된다.