user.tagHistory — 임베딩 vs 별도 테이블 분리 검증

마지막 업데이트 2026-07-22

PPI-1103 "음성 불가 사유 태그 변경 히스토리"를 별도 테이블로 분리하는 게 데이터구조 관점에서 타당한지 실측 데이터로 검증.

1. 배경 — 지금 어떻게 저장되나

PPI-1103은 사유 태그 변경 이력을 별도 테이블이 아니라 기존 user 아이템의 tagHistory 속성(임베딩 배열)으로 저장한다. 태그/사유가 바뀔 때만 updateUser()가 diff를 최신순으로 prepend(최대 200개 상한).

각 이력 항목: changedAt, changedByName, changedById?, addedTags/removedTags, addedTagReasons/removedTagReasons. guest GET 응답에선 관리자 실명 보호를 위해 destructuring으로 제외.

2. 실측 데이터 (prod scan, 2026-07-19)

tagHistory 속성 자체 크기: max 962B / avg 338B. 상한(200)과 실사용(max 3)은 100배 격차 → 아이템 크기 압박 없음.

3. 검토 대상 — "user 조회 시 히스토리까지 오는 게 문제"

분리 근거로 제시된 의도는 오버페치 회피다. 코드상 getUser(GetCommand)·getUsers(Scan) 모두 ProjectionExpression이 전혀 없어 항상 full item(= tagHistory 포함)을 읽는다. guest 경로는 full fetch 후 메모리에서 버린다. 관찰 자체는 사실이다.

4. 두 읽기 경로 분석

5. 판정 매트릭스

6. 권장 해법 — ProjectionExpression

주의: DynamoDB ProjectionExpression은 포함할 속성을 나열하는 방식이라 "tagHistory만 제외"가 아니라 필요한 속성을 열거해야 한다. guest 경로는 애초에 몇 개만 쓰므로 특히 잘 맞는다.

// AS-IS — getUser: full item(=tagHistory 포함) 항상 조회
const data = await ddbDocClient.send(new GetCommand({
  TableName: `ppi-user-${stage}`,
  Key: { id },
}));

// TO-BE — 히스토리가 불필요한 경로(guest 등)는 필요한 속성만 project
const data = await ddbDocClient.send(new GetCommand({
  TableName: `ppi-user-${stage}`,
  Key: { id },
  ProjectionExpression: "id, #nm, tags, tagReasons, conversationMode, lessonTypes",
  ExpressionAttributeNames: { "#nm": "name" },
}));
// getUsers(Scan)도 목록에 쓰는 컬럼만 project → 풀스캔 ~40KB/~10 RCU 절감

7. 분리가 정당해지는 조건 (지금은 아님)

추가로, 현재 tagHistory는 200개 상한으로 오래된 항목을 조용히 버리므로 "전체 감사 로그"가 아닌 "최근 이력 보존"이다(실사용 max 3건이라 무해). 규정상 영구 감사 추적이 요구된다면 그건 테이블 분리가 아니라 append-only 감사 저장소가 필요한 별개 요구사항이다.