3.6 KiB
3.6 KiB
title, source_type, status, related_branches, related_projects, tags, created, status_label
| title | source_type | status | related_branches | related_projects | tags | created | status_label | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| interview / startup-fail-fast-config-validation-2026-06-06 | interview-prep | raw |
|
|
|
2026-06-06 | captured |
interview: startup-fail-fast-config-validation-2026-06-06
Layer:
raw/interviews/— env-driven runtime configuration 구현에서 정직하게 도출 가능한 면접 질문/답변 원석.
Parent / 부모
Q1. env 조합 기반 fail-fast 검증을 Spring 라이프사이클의 어디에 두어야 하나? EnvironmentPostProcessor / SmartInitializingSingleton / ApplicationReadyEvent 비교
- 결론: bean presence 검사가 필요하면
SmartInitializingSingleton이 적정. - 근거:
EnvironmentPostProcessor— bean 정의 이전에 실행. property 값은 보지만 bean 존재 여부는 알 수 없음 → multi-instance 5종 bean presence 검사 불가.SmartInitializingSingleton#afterSingletonsInstantiated— 모든 non-lazy singleton 초기화 직후, context refresh 완료 전 1회. bean presence 검사 가능 + 위반 시throw하면 context 가 기동 거부.ApplicationReadyEvent— 트래픽 수용 직전. 너무 늦음(이미 포트 바인딩/warm-up 비용 지불 후 실패).
- 보강: 동일 계약을 contract test 로 이중화해 CI 회귀 방지.
Q2. @ConfigurationProperties 검증을 "선언적 JSR-303" 과 "compact constructor throw" 로 나누는 기준은?
- 단순 제약(필수·범위·정규식):
@Validated+ JSR-303(@NotBlank/@PositiveOrZero/@Min…) 선언. startup 시BindValidationException자동 발생. - 조건부/교차필드(JSR-303 로 표현 불가): record compact constructor 에서 검사 후 invalid 면
throw(fail-fast). 예)enabled=true일 때만origins필수. - 정상 default(absent → 안전한 기본값, 예
enabled=false시 빈 origins)는 invalid 아님 → default 허용. - 안티패턴: invalid 값을
log.warn+ 조용히 기본값으로 대체(lenient). 운영 misconfig 가 숨는다.
Q3. prod 안전 가드에서 Spring profile 매칭을 case-sensitive 로 할까 case-insensitive 로 할까?
Environment#matchesProfiles/acceptsProfiles는 case-sensitive. 따라서SPRING_PROFILES_ACTIVE=PROD(대문자 오타)는"prod"와 매칭되지 않아 prod 가드를 우회할 수 있음.- prod-unsafe 토글(내부 에러 노출 / body 로깅)을 막는 가드라면, 오타로 가드가 풀리는 것이 더 위험 → 의도적으로
equalsIgnoreCase로 대문자 변형까지 잡는 편이 안전. - 트레이드오프: case-insensitive 는 profile expression(
!prod,prod | staging)을 지원하지 않음. 표현식이 필요하면matchesProfiles를, 단순 단일 profile 안전가드면 case-insensitive 동등 비교를 선택.
Q4. optional capability bean 을 "이름"으로 presence 검사하는 것의 장단점
- 장점: 해당 capability 의 구체 타입이 아직 존재하지 않아도(다른 branch 가 미구현) 계약(bean name)만으로 검사 가능 → skeleton 단계에서 cross-branch 계약을 강제.
- 단점: 이름 오타에 취약, 타입 안전성 없음. → 계약 이름을
static final상수 + 주석(owner branch)으로 고정하고 contract test 가 상수를 직접 참조하게 해 drift 를 줄임.