신규 구독 연결과 기능 코드 변경을 분리하기
상황과 문제
AI 기능에 신규 구독을 연결하려는데, PC와 서버가 각각 구독을 판별하고 있었습니다.
- 요청 차단: 서버에서 신규 구독을 지원해도 PC가 AI 전용 구독만 허용하면 요청을 차단할 수 있었습니다.
- 모호한 응답: 협력사의 true/false 응답은 유효 여부와 구독 유형을 구분하기 어려웠습니다.
해결
- 책임 통합: 협력사에서 유형과 유효 여부를 받아 서버가 권한과 횟수를 검증하고, PC는 결과를 표시하도록 했습니다.
- 정책 분리: 구독 추가 때마다 기능 코드를 수정하지 않으려 Stripe Entitlements의 상품과 기능 연결 방식을 참고했습니다. 구독별 사용 권한과 한도를 기능 처리 코드에서 분리했습니다.
| AS-IS | TO-BE |
|---|---|
 |  |
결과
- 신규 구독은 기능 연결과 한도 설정으로 추가하고, 기능 코드는 새 기능이나 계산 규칙이 필요할 때 수정합니다. 전환 중에는 기존 응답 형식과 사용 이력을 유지합니다.
다음 배포의 대기를 줄이기 위한 타임아웃과 작업 종료 확인하기
상황과 문제
『Release의 모든 것』을 읽고 배포 플랫폼의 무응답 처리를 점검했습니다. 활성 작업은 하나인데 빌드와 테스트에 시간 제한이 없어, 한 작업이 멈추면 다른 프로젝트의 배포도 대기할 수 있었습니다.
해결
- 동적 타임아웃: 짧은 고정값이 정상 빌드를 중단하지 않도록 AWS의 백분위수 선택 방식을 참고했습니다. 프로젝트와 빌드 유형별 최근 정상 완료 시간의 p99 + 여유 시간을 최소 타임아웃과 최대 타임아웃 사이로 제한했습니다. 표본이 부족하면 기본값을 사용하고, 테스트에는 별도 제한을 적용합니다.
- 종료 확인: CLI가 종료돼도 실제 작업이 남을 수 있어, 시간 초과 후 프로세스와 컨테이너의 종료를 확인하도록 했습니다. 종료 확인에도 시간 제한을 두고, 불명확하면 복구 상태를 보존해 자동 재시도를 막았습니다.
| AS-IS | TO-BE |
|---|---|
 |  |
결과
- 정리가 확인된 작업 뒤에는 다음 배포를 진행하고, 종료가 불명확한 작업은 복구 대기로 구분합니다. 기존 Preview와 데이터는 보존합니다.
책의 5장 「안정성 패턴」에서 5.1 「시간 제한」(145–149쪽)은 대기 상한, 5.3 「격벽」(154–158쪽)은 장애 전파 범위, 5.8 「테스트 하네스」(174–178쪽)는 무응답과 종료 실패의 검증 기준으로 활용했습니다.