[INFRA] 운영에 prod 프로파일이 꺼져 있다 — fail-fast 미작동, API 문서가 외부에 열려 있다

[minyongP]

인프라 작업이 필요한 항목이라 백엔드 단독으로 진행하지 않고 이슈로 남긴다. @cherry-go-round

요약

운영 배포에 JWT_PRIVATE_KEY가 주입되지 않는다. 그런데 prod 프로파일도 활성화되어 있지 않아서, 이 누락을 잡아내려고 만든 기동 실패(fail-fast)가 동작하지 않는다. 결과적으로 파드는 정상적으로 뜨고 서명 키를 스스로 만들어 쓴다 — 배포할 때마다 로그인 세션이 전부 끊긴다.

왜 이 값이 필요한가

세션 JWT는 RS256으로 서명한다(BD-31). 키가 주입되지 않으면 JwtKeyProvider가 기동할 때 임시 키쌍을 만든다. 프로세스가 하나뿐인 로컬에서는 문제가 없다 — 발급한 키와 검증하는 키가 항상 같다.

운영에서는 같은 동작이 이렇게 나타난다.

상황	결과
롤링 배포 중 (maxSurge: 1, maxUnavailable: 0)	새 파드와 기존 파드가 다른 키로 동시에 트래픽을 받는다 → 요청이 어느 파드로 가느냐에 따라 간헐적 401
배포·재시작 완료 후	기존 토큰이 전부 무효 → 전체 사용자 로그아웃
replicaCount를 2 이상으로 올리면	배포 중이 아니어도 간헐적 401이 상시 발생

재현이 안 되는 로그인 실패로 나타나기 때문에, 원인을 찾기 어려운 종류의 고장이다. BD-31이 운영에서 기동 실패를 택한 이유가 이것이다 — 조용히 망가지는 쪽보다 뜨지 않는 쪽이 낫다고 판단했다.

확인한 것

확인 대상	상태
back/src/main/resources/application.yml:72	private-key: ${JWT_PRIVATE_KEY:} — 기본값은 빈 문자열
infra/apps/prod/back/values.yaml (env: 53~68행)	JWT_PRIVATE_KEY 없음. DB 비밀번호만 secretKeyRef로 들어온다
infra/secrets/prod/	ghcr-back-pull, postgres-credentials 둘뿐. JWT 키용 SealedSecret 없음
back/Dockerfile:26	ENTRYPOINT ["java", "-jar", "/app.jar"] — 프로파일 지정 없음
infra 전체	SPRING_PROFILES_ACTIVE 설정이 어디에도 없음

즉 back/src/main/resources/application-prod.yml이 운영에서 적용되지 않고 있다. DB가 정상 동작하는 것은 인프라가 SPRING_DATASOURCE_* 환경변수로 직접 주입하기 때문이고(환경변수가 프로파일 파일보다 우선한다), 그래서 프로파일이 꺼져 있다는 사실이 지금까지 드러나지 않았다.

이 프로파일이 꺼져 있어서 함께 어긋난 것이 하나 더 있다. application-prod.yml은 springdoc.api-docs.enabled: false로 API 문서를 끄는데, 프로파일이 적용되지 않으므로 운영 파드에서 문서 경로가 켜진 상태다(springdoc-openapi-starter-webmvc-ui 의존성 있음). back의 ingress.enabled: false라 외부에서 실제로 닿는지는 라우팅에 달려 있어서, 이 부분은 확인이 필요하다.

해야 할 일 (인프라)

1. 키 만들기 — 저장소가 public이므로 PEM 원본을 커밋하지 않는다.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out jwt-prod.pem

2. SealedSecret으로 봉인 — 예: infra/secrets/prod/pinlog-back-jwt.sealedsecret.yaml, 키 이름 private-key.

PEM은 실제 개행이 들어간 그대로 넣으면 된다. JwtKeyProvider가 파싱 전에 공백·개행을 모두 지운다. 반대로 \n 두 글자 문자열로 바꿔 넣으면 역슬래시가 남아 파싱이 깨진다 — 로컬 .env에 \n으로 적는 방식(properties 파서가 실제 개행으로 되돌린다)과 다르다.

3. infra/apps/prod/back/values.yaml의 env:에 추가

  - name: JWT_PRIVATE_KEY
    valueFrom:
      secretKeyRef:
        name: pinlog-back-jwt
        key: private-key
  - name: SPRING_PROFILES_ACTIVE
    value: prod

SPRING_PROFILES_ACTIVE를 같이 넣어야 fail-fast가 살아난다. 이게 없으면 다음에 또 키가 빠져도 같은 방식으로 조용히 넘어간다.

4. 순서 주의 — 키보다 프로파일을 먼저 켜면 파드가 기동에 실패한다. 두 값을 같은 커밋으로 넣거나, Secret을 먼저 만든 뒤 프로파일을 켠다.

프로파일을 켜도 DB 접속은 지금과 같다. 환경변수가 application-prod.yml보다 우선하므로 주소·계정·비밀번호는 인프라가 주는 값이 계속 이긴다.

알아 둘 것

키 회전은 아직 구현하지 않았다. kid 헤더만 심어 뒀고 여러 키를 동시에 검증하지 않는다. 한번 정한 키를 바꾸면 그 시점에 전체 로그아웃이 된다. 키를 잃어버리는 경우도 같다.

참고

• 결정 근거: docs/backend/decisions/BD-31-jwt-rs256-key-management.md
• 설정 규약: docs/development/configuration.md (JWT_PRIVATE_KEY — 운영 필수)
• 인증 계약: docs/development/authentication.md 8장 (로컬에서 키를 고정하는 방법)
• 구현 보고: docs/backend/implements/BI-18-2026-07-28-jwt-cookie-session.md — "인프라에 JWT_PRIVATE_KEY 요청" 항목으로 남아 있던 건이다

[minyongP]

정정 — 위 "해야 할 일"의 3·4번이 불완전하다. 프로파일을 켜려면 값이 하나 더 필요하다.

AiProcessClient의 requireSecret도 JwtKeyProvider와 같은 기준으로 갈린다 — 운영 프로파일이면 기동 실패다. 그런데 PINLOG_AI_INTERNAL_SECRET도 인프라가 주입하지 않는다.

따라서 JWT_PRIVATE_KEY만 넣고 SPRING_PROFILES_ACTIVE=prod를 켜면 이 값이 없어서 파드가 여전히 뜨지 않는다. 자세한 내용과 함께 필요한 PINLOG_AI_BASE_URL 문제는 #102에 정리했다.

프로파일을 켜기 전에 갖춰져야 하는 것:

값	이슈
JWT_PRIVATE_KEY	이 이슈
PINLOG_AI_INTERNAL_SECRET	#102

PINLOG_AI_BASE_URL(정확히는 application-prod.yml의 pinlog.ai.base-url)은 기동을 막지 않으므로 프로파일 활성화를 붙잡지는 않는다. 다만 주소가 없으면 운영에서 localhost:8000으로 해석되고 실패가 조용히 삼켜지므로, 같이 처리하는 편이 낫다.

[minyongP]

본문의 열린 항목 확인 — API 문서는 외부에서 닿습니다.

"ingress.enabled: false라 외부에서 실제로 닿는지는 라우팅에 달려 있어서 확인이 필요하다"고 남긴 부분을 운영 도메인으로 직접 확인했습니다.

$ curl -s -o /dev/null -w '%{http_code}\n' https://pin-log.com/api/core/v3/api-docs
200
$ curl -s -o /dev/null -w '%{http_code}\n' https://pin-log.com/api/core/swagger-ui/index.html
200

back의 ingress가 꺼져 있어도 경로 기반 라우팅으로 pin-log.com/api/core/**가 그대로 내려오고 있어, 인증 없이 누구나 API 명세와 Swagger UI를 볼 수 있는 상태입니다. 프로파일 활성화가 선행 조건(#102) 때문에 늦어지는 동안 이 노출은 계속됩니다.

노출만 먼저 끊을 필요가 있다면 프로파일과 무관하게 base application.yml에서 springdoc을 끄고 로컬·개발에서만 켜는 방법도 있습니다. 다만 그건 프로파일 구조를 뒤집는 변경이라, #102의 시연 범위 결정이 곧 나온다면 그대로 기다리는 편이 낫다고 봅니다. 판단이 필요한 지점이라 남겨 둡니다.

[minyongP]

범위 정정 — JWT_PRIVATE_KEY 주입은 해결됐습니다. 제목을 남은 범위로 고쳤습니다.

07-31 기준으로 다시 확인한 결과, 이 이슈가 처음 보고한 두 문제 중 하나가 #105로 해소됐습니다.

항목	07-29 보고	07-31 현재
JWT_PRIVATE_KEY 운영 주입	없음	해결 — #105
SPRING_PROFILES_ACTIVE=prod (fail-fast 복원)	없음	없음
API 문서 외부 노출	노출	노출

근거:

$ gh api repos/Team-PinLog/back/environments/pinlog-secrets-prod/secrets --jq '.secrets[].name'
... JWT_PRIVATE_KEY ... PINLOG_INFRA_SECRET_PR_TOKEN ...

Seal backend runtime secrets  run 30526570990  2026-07-30T08:24:32Z  success
infra 5ed376d  chore: refresh back prod owner Secret (#101)
  → secrets/prod/back-owner-secrets.sealedsecret.yaml (7개 키)
  → apps/prod/back/values.yaml  envFrom.secretRef: back-owner-secrets

남은 범위

apps/prod/back/values.yaml의 env:에 SPRING_PROFILES_ACTIVE가 여전히 없습니다. 그래서 application-prod.yml이 적용되지 않고, 두 가지가 그대로입니다.

• fail-fast가 죽어 있어 다음에 또 값이 빠져도 조용히 넘어갑니다
• springdoc이 꺼지지 않아 문서 경로가 열려 있습니다

$ curl -s -o /dev/null -w '%{http_code}\n' https://pin-log.com/api/core/v3/api-docs
200
$ curl -s -o /dev/null -w '%{http_code}\n' https://pin-log.com/api/core/swagger-ui/index.html
200

선행 조건이 풀렸습니다

첫 코멘트에서 프로파일을 켜기 전에 갖춰져야 한다고 적은 두 값이 지금은 둘 다 주입됩니다 — JWT_PRIVATE_KEY, PINLOG_AI_INTERNAL_SECRET 모두 back-owner-secrets에 들어 있습니다. PINLOG_AI_BASE_URL(#102)은 기동을 막지 않으므로, 프로파일 활성화를 지금 붙잡는 것은 없습니다.

본문의 "해야 할 일 (인프라)" 절 1~3번은 #105로 대체됐고, 4번(순서 주의)만 유효합니다.

[minyongP]

본문이 보고한 두 문제 중 하나는 해소됐고, 남은 하나는 인프라가 values.yaml에서 두 줄로 끝내는 일이라 이슈로 붙들고 있지 않는다. 닫으면서 확인 결과와 조치 내용을 남긴다.

항목	07-29 보고	07-31 현재
JWT_PRIVATE_KEY 운영 주입	없음	해결 — #105 (infra 5ed376d)
SPRING_PROFILES_ACTIVE=prod	없음	없음 — 미해결
API 문서 외부 노출	노출	노출 — 미해결

아직 열려 있다 (07-31 측정)

$ curl -s -o /dev/null -w '%{http_code}\n' https://pin-log.com/api/core/v3/api-docs
200
$ curl -s -o /dev/null -w '%{http_code}\n' https://pin-log.com/api/core/swagger-ui/index.html
200
$ curl -s https://pin-log.com/api/core/v3/api-docs | tr ',' '\n' | grep -c '"/v1/'
20

인증 없이 운영 엔드포인트 20개의 명세와 Swagger UI가 보인다. 저장소가 public이라 명세 자체가 비밀은 아니지만, 운영 인스턴스에 붙은 실행 가능한 콘솔이 열려 있는 것은 별개다.

조치 — 두 줄

# infra/apps/prod/back/values.yaml  env:
  - name: SPRING_PROFILES_ACTIVE
    value: prod

application-prod.yml이 springdoc.api-docs.enabled: false·swagger-ui.enabled: false를 갖고 있어 프로파일만 켜면 함께 닫힌다. 동시에 JwtKeyProvider·AiProcessClient의 fail-fast가 살아나 다음에 값이 빠졌을 때 조용히 넘어가지 않는다.

선행 조건은 전부 풀렸다. 프로파일을 막던 JWT_PRIVATE_KEY·PINLOG_AI_INTERNAL_SECRET이 back-owner-secrets로 주입되고 있고, PINLOG_AI_BASE_URL(#122)은 기동을 막지 않는다.

켜기 전 확인할 것 하나

application-prod.yml:11이 password: ${DB_PASSWORD}인데 인프라는 SPRING_DATASOURCE_PASSWORD라는 다른 이름으로 주입한다(values.yaml:68). 환경변수가 우선순위에서 이겨 yml의 placeholder가 평가되지 않으므로 정상 기동할 것으로 보지만, 만약 평가되면 Could not resolve placeholder 'DB_PASSWORD'로 기동 실패다.

프로파일 활성화의 실질 리스크는 이것 하나다. 이름을 SPRING_DATASOURCE_PASSWORD로 맞추면 불확실성이 사라진다.

참고

• chore: JWT_PRIVATE_KEY를 pinlog-secrets-prod에 등록하고 Secret 전달 workflow로 운영에 주입한다 #105 — JWT_PRIVATE_KEY 주입. 완료
• [INFRA] 운영에 AI가 배포되어 있지 않다 — apps/prod/ai 등록과 PINLOG_AI_BASE_URL 주입 #122 — 운영 AI 배포·주소. 별건이며 이 건을 기다리지 않는다
• 결정 근거: BD-31 · docs/development/configuration.md