---
task_id: task-1969
type: context
scope: task
created: 2026-04-20
updated: 2026-04-20
status: in-progress
---

# 맥락 노트: task-1969

**task**: task-1969

---

## 결정 근거

### 3 Step Why 자문

**1st Why: 왜 이 설계가 필요한가?**
전수조사에서 적발률 34%(16/47)로 체크리스트 [x] 표기와 실제 코드 사이에 큰 괴리가 발견됨. Gemini PR 리뷰의 CRITICAL/HIGH 지적이 파서 결함으로 무시되어 보안/성능 이슈가 main에 머지됨. 이를 일괄 수정하지 않으면 서비스 품질과 보안에 실질적 위험이 존재함.

**2nd Why: 왜 일괄 수정 접근이 최선인가?**
13건의 수정 사항이 모두 같은 프로젝트(InsuRo)에 속하며, 파일 간 의존성이 있음(server/main.py가 B1~B7, C5, D1에 걸쳐 있음). 개별 task로 분리하면 머지 충돌이 빈번해지고 QC 오버헤드가 증가함. 한 브랜치에서 일괄 수정하면 교차 영향을 한 번에 검증 가능.

**3rd Why: 왜 일괄 수정이 개별 task 분리보다 나은가?**
server/main.py 1274줄에 B1~B7, C5, D1의 8개 수정이 집중되어 있어, 개별 task로 분리 시 8번의 머지 충돌 위험이 있음. 일괄 수정은 1회 머지로 해결. 또한 전수조사/Gemini 리뷰 두 보고서의 지적사항을 한 번에 해소하여 추적 관리가 단순해짐.

### Phase A: 브랜치 머지 방식
- task-1962-dev1을 워크트리 브랜치에 머지 (main 직접 수정 금지)
- 워크트리에서 모든 수정 후 PR로 main에 반영

### Phase D: OAuth 암호화 방식 선택
- Fernet(cryptography 라이브러리) 선택: Python 표준적 대칭 암호화, 키 관리 단순
- AES-256-GCM 대비 장점: API가 간결, 키 파생/IV 관리 자동화
- 마스터 키는 환경변수 OAUTH_ENCRYPTION_KEY로 관리

### _keyword_jobs 이관 전략
- 전체 DB 이관은 스키마 설계 필요 → 이번에는 주석 경고 + 재시작 데이터 유실 로깅으로 최소화
- 실질적 DB 이관은 별도 task로 분리

## 참조 자료

- 전수조사 보고서: `memory/reports/task-1967+1.md`
- Gemini 강제 적용 분석: `memory/reports/task-1968.md`
- InsuRo 프로젝트: `/home/jay/projects/InsuRo/`

## 주의사항

- server/main.py 1274줄 대형 파일 — Edit 시 offset/limit으로 주변 확인 필수
- premiumOnly 미완성 디자인 절대 건드리지 말 것
- 기존 테스트 회귀 방지 — 각 수정 후 pytest 실행
- API 직접 호출 금지 — AI 호출은 CLI로만