클라우드 조사 및 설계 결정 로그 - 100-hours-a-week/KTB4-7th-Cloud GitHub Wiki
조사와 설계 선택의 근거를 남기는 기록입니다. 기술 후보를 적었다고 팀이 채택한 것은 아닙니다. 계획, 제안, 합의, 구현, 검증 상태를 분리해 표시합니다.
기록 상태
| 상태 | 뜻 |
|---|---|
| 계획 | 실행·검토하기로 한 내용. 완료된 결과가 아님 |
| 제안 | 근거와 대안을 바탕으로 제시했지만 팀 합의 전 |
| 검토 중 | 담당자·팀의 확인이나 추가 증거를 기다림 |
| 결정 | 팀이 선택과 범위에 합의함 |
| 구현 | 코드·인프라에 반영했으며 실행 환경 확인은 별도 |
| 검증 | 같은 기준의 증거로 기대 효과를 확인함 |
| 보류 | 선택을 미루며 재검토 조건을 기록함 |
| 대체·철회 | 이후 결정으로 효력을 잃음. 이전 기록은 유지 |
기록 원칙
- 결정마다 ID를 부여하고 날짜, 상태, 기록자·검토자를 적습니다.
- 선택 이유뿐 아니라 검토한 대안, 제외·보류 이유, 비용·운영 영향, 실패 시 영향도 적습니다.
- 근거는 출처, 확인 날짜, 실제 확인한 항목을 함께 적습니다. 실측·실행 코드·공식 문서·가정·구두 피드백을 구별합니다.
- 설계가 바뀌면 기존 문장을 조용히 교체하지 말고 새 변경 이력이나 후속 결정으로 연결합니다. 이전 상태와 테스트 결과는 보존합니다.
- 새 결정의 효과는 관련 실행 ID와 결과 보고서로 연결합니다. 구현됨과 검증됨을 같은 상태로 취급하지 않습니다.
기존 문서에서 이어받은 기록
아래 항목은 현재 SLI·SLO 문서에 적힌 상태를 요약한 것입니다. 위키 문서에 제안·계획으로 적힌 내용을 팀의 최종 승인이나 실행 완료로 바꾸어 해석하지 않습니다.
DEC-001 — 조회 품질의 초기 내부 목표
- 상태: 제안·검증 대기
- 기록일: 2026-09-29
- 범위: 제공이 확인된 사용자 API별 운영 품질
- 내용: 정상 완료율 99.9% 이상, 정상 응답 중 500ms 이내 완료율 95% 이상, 1초 이내 완료율 99% 이상. 각 API는 별도로 집계하고 실제 운영 제공 시작 후 14일 파일럿을 평가합니다.
- 선정 이유: 기준선과 외부 SLA가 확인되지 않아 첫 관측으로 검토할 내부 목표가 필요합니다. 500ms는 일반 조회 응답의 초기 예산, 1초는 느린 꼬리 응답 제한의 출발점입니다.
- 한계: 사용자 조사나 운영 실측으로 정한 수치가 아니며 약속된 SLA가 아닙니다. 첫 운영 관측과 표본 수를 확인해 재검토합니다.
- 근거: SLI·SLO 설계, 목표 선정 근거
DEC-002 — 2026-09-30 Q1·Q2 예상 부하 확인 계획
- 상태: 계획
- 범위: 매출 분석 당월 조회 Q1과 지정 기간 조회 Q2. 두 조건은 각각 판정합니다.
- 내용: Smoke 1 RPS 2분, 필수 Load 5 RPS 10분. 5 RPS가 안정적이고 다른 사용자나 환경에 영향을 주지 않을 때만 10 RPS 30분을 선택적으로 실행합니다.
- 선정 이유: 기존 예상 피크 3~5 RPS에서 먼저 동작과 대표 부하를 확인하고, 더 높은 부하는 환경이 안정적일 때에만 추가합니다.
- 한계: 예상 부하 가정이며 실제 운영 트래픽이 아닙니다. 계획은 완료 증거가 아니므로 실행 ID, 시각, 조건과 결과를 별도 보고서에 남깁니다.
- 근거: SLI·SLO 설계, 목표 선정 근거
DEC-003 — 기능별 조회를 분리해 기록
- 상태: 측정 범위 정의·일부 확인 대기
- 내용: 매출 분석 Q1·Q2, 오늘의 솔루션 조회, 매출 업로드 상태 조회의 SLI를 합산하지 않습니다. 먼저 확인된 경로와 응답 계약만 측정에 넣고, 미확인 계약은 확인 절차와 제한을 기록합니다. AI 생성과 파일 업로드 POST는 현재 조회 부하 시험에서 제외합니다.
- 선정 이유: 사용자 여정과 응답 상태가 다른 기능을 합치면 개별 기능의 실패나 지연을 가릴 수 있습니다.
- 근거: SLI·SLO 설계
새 결정 기록 양식
아래 틀을 복사해 새 ID를 부여합니다. 구현·테스트 전에도 조사 결과와 열린 질문을 기록할 수 있습니다.
DEC-YYYYMMDD-NN — 결정 제목
| 항목 | 기록 |
|---|---|
| 상태 | 계획 / 제안 / 검토 중 / 결정 / 구현 / 검증 / 보류 / 대체·철회 |
| 작성일 / 기록자 | |
| 담당자 / 검토자 | |
| 영향 범위 | 기능·환경·사용자 흐름 |
| 관련 문제·SLO | |
| 관련 실행 ID·PR·배포 |
문제와 목표
어떤 사용자 상황에서 무엇이 문제인지, 해결되었다고 판단할 기준은 무엇인지 적습니다. 사실과 가정은 구분합니다.
조사 근거
| 근거 종류 | 출처·확인일 | 확인한 사실·측정 | 적용 범위와 한계 |
|---|---|---|---|
| 예: 실행 결과 / 코드 / 공식 문서 / 가정 |
비교한 대안
| 대안 | 기대 효과 | 비용·운영 부담 | 장애·보안 영향 | 확인 방법 |
|---|---|---|---|---|
선택과 이유
무엇을 선택·보류했는지 적고, 근거가 서비스 요구와 어떻게 연결되는지 설명합니다. 선택하지 않은 대안과 그 이유도 남깁니다.
영향과 남은 위험
연결된 구성요소, 배포·복구·비용 변화, 새로 생기는 의존성, 이번 범위에서 감수하는 한계를 적습니다.
검증 계획과 결과
| 항목 | 기준·결과 |
|---|---|
| 비교 기준 실행 ID | |
| 바꿀 변수 | |
| 고정할 조건 | |
| 통과 기준 | |
| 실행 결과 페이지 | |
| 검증 상태·재검토 조건 |
변경 이력
| 날짜 | 이전 상태 → 새 상태 | 바꾼 내용과 이유 | 근거·검토자 |
|---|---|---|---|
| YYYY-MM-DD |