# task-3044 — InfoKeyword 리포트 공개 노출 차단 + 정리 스크립트 GCS 전환
- **팀**: dev2-team (오딘) · **레벨**: Lv.2 · **작성**: 2026-08-28
- **저장소**: `Jeon-Jonghyuk/InfoKeyword` (기본 브랜치 `master`)
- **브랜치**: `task/task-3044-dev2` · **워크트리**: `/home/jay/projects/InfoKeyword/.worktrees/task-3044-dev2`
- **PR**: https://github.com/Jeon-Jonghyuk/InfoKeyword/pull/4 (**DRAFT · 머지 안 함**)
---
## 봉투 (한 줄)
**무인증 403 실증 = 예**(직접 측정: 무인증 403 / 서명 URL 200 / 서명 제거 시 403 / allUsers ACL False).
**0건을 성공으로 위장하지 않음 = 예**(`scanned=95` 를 근거로 제시하는 HEALTHY, 접근 실패는 exit 2, 대상 0건은 exit 3).
---
## S — 상황
InfoKeyword 리포트는 GCS 버킷 `infokeyword-j2h-reports` 에 저장된다. 두 가지 결함이 동시에 있었다.
1. `drive_uploader.py:51` 이 업로드마다 `blob.make_public()` 을 호출 → 모든 리포트가 인터넷 전체에 공개.
파일명에 분석 대상 블로그 URL 이 들어 있어 **어느 설계사가 어떤 블로그를 분석했는지가 URL 만으로 노출**.
2. 매일 02:00 정리 스케줄(`57DC9232`)이 **Google Drive 폴더**를 대상으로 하는데 실제 저장소는 **GCS** → 구조적 no-op.
## C — 문제
정리 스케줄의 실행 이력을 직접 집계한 결과:
```
/home/jay/.cokacdir/schedule_history/57DC9232.log (chat 6937032012)
총 111회 · status: ok 101 / error 10
기간: 2026-05-08 ~ 2026-08-28
```
**101회가 "성공"으로 보고됐고 그 전부가 0건 no-op이었다.** 약 3.7개월간 정리는 한 번도 일어나지 않았다.
이 사건의 본질은 삭제 실패가 아니라 **"대상을 못 찾은 것을 성공이라고 보고한 것"** 이다.
## Q — 무엇을 해야 하는가
새로 올라오는 리포트가 무인증으로 열리지 않게 하고, 정리 작업이 GCS 를 실제로 조회하며,
**대상을 못 찾는 상황을 성공으로 위장하지 않게** 한다.
## A — 한 일
### ① 공개 노출 차단 — 서명 URL 채택 (설계 근거)
**인증 프록시 라우트가 아니라 V4 서명 URL을 택했다.** 근거는 취향이 아니라 실측된 제약이다:
| 프록시가 불가능한 이유 | 근거 |
|---|---|
| 앱 인증이 **클라이언트 전용** | `src/middleware.ts` 는 `NextResponse.next()` 만 하는 통과 미들웨어. 실제 검사는 `AuthGuard`(클라이언트) |
| 서버가 검증할 세션 쿠키가 **없음** | Firebase 클라이언트 SDK 기반. 세션 쿠키 발급 경로 부재 |
| `![]()
`/`