教程

介绍我正在使用的 PRD 生成技能

AAnonymous
15分钟阅读

引言

功能实现卡住的时刻,往往不是开始写代码之后,而是更常出现在那之前。要做什么、做到什么范围、该按什么顺序拆开、现有代码里该参考什么,如果这些都还没整理清楚就直接进入实现,代理会摇摆,人也会摇摆。

所以我并不把 PRD 只看作一份普通的策划文档。在当下这样的 AI 编程环境里,PRD 更接近执行计划。尤其是在使用 Claude Code 这类编码代理时,关键往往不只是做什么,而是要怎样把它结构化后交出去,这会显著改变最终结果的完成度。

这篇文章里,我想介绍一下我正在使用的 .claude/skills/prd-generator 技能。它会以交互方式收集新功能需求,并整理成 Claude Code 可以直接衔接实现阶段的 PRD 文档。既然这是一篇用于资料分享的文章,我不只做中途总结,后半部分也会把 SKILL.md 和模板全文原样附上。

为什么会需要这样的技能

在做功能之前随手留几条备忘,和真正写出一份可以落地实现的 PRD,完全是两回事。

简短的创意备忘虽然快,但很快就会漏东西。

  • 核心功能写下来了,却没有用户场景
  • 有实现计划,却没有验收标准
  • 明明有需要参考的现有代码,却没有把它们连起来
  • 后面应该调用什么实现技能,也没有写进去
  • 文档该保存到哪里、该起什么名字,每次都不一样

在这种状态下,就算有文档,也很难直接进入执行。最后还是得重新提问、重新整理、重新搭结构。

prd-generator 正是为了减少这类中间浪费而做出来的技能。只要把提问顺序、文档格式、保存规则、实现阶段以及实现技能联动一次性定好,PRD 就不再只是说明文,而会变成能立即执行的工作单元。

用一句话来描述这个技能

当我用最短的话介绍它时,我通常会这样说。

prd-generator 是一个先以交互方式收集新功能需求,再将其转换为适合 Claude Code 执行的完整 PRD 文档的技能

实际结构也很简单。

.claude/skills/prd-generator/
  SKILL.md
  assets/
    prd_template.md

但和这份简单的文件夹结构相比,它承担的角色要大得多。它不只是问几个问题就结束,而是会把文档保存规则、实现计划的格式、验收标准,甚至后续该使用哪些实现技能,一起定下来。

顺着工作流看,更容易理解它的设计意图

这个技能的核心,在于它把对话流程设计得很完整。它不是一次性把 PRD 写完,而是按顺序收集必要信息。

第 1 阶段:功能探索

首先会问功能概述、核心功能和主要使用场景。

这里重要的一点是,它不会一次性把所有问题都抛出来。技能文档里也明确写着「不要一次性抛出所有问题」。这句话比想象中更重要。好的 PRD 不是像问卷一样一股脑压出来的,而是沿着回答逐步收窄范围。

第 2 阶段:确认参考实现

然后会询问现有代码或实现模式。

这个步骤的价值很明确。在实际开发中,新功能更多时候不是在一张白纸上展开,而是必须沿着既有结构继续做。拿到路径,再确认要遵循的模式与规则之后,PRD 就不再是抽象的策划书,而是已经贴着真实代码库的工作文档。

第 3 阶段:扩展性与架构

接下来会问未来增长、集成点和性能要求。

我特别喜欢这一部分。即使只是实现一个简单功能,我们也很容易被「先能跑起来就行」的诱惑带走。但这个技能会从一开始就加入扩展性问题,让哪怕最低限度的未来负担也能留在文档里。

第 4 阶段:确定保存位置

在这里,它不会要求用户自己决定完整的目录路径。它只确认文件名,然后按照文档生成规则自动计算保存路径。

这个选择也很实用。每次都让人同时纠结路径和文件名,文档很容易散掉。反过来,如果把保存规则固定下来,之后查文档会更容易,PRD 也会持续积累为工作资产。

第 5 阶段:实际生成 PRD

最后一步会读取模板、填入占位符、判断要使用哪些实现技能,并完成文档。

这里最能看出这个技能的定位。它的目标不是简单地「帮你写一份策划书」,而是完整补齐下列元素,生成一份可执行的 PRD

  • 功能名称与概述
  • 详细功能说明
  • 参考实现
  • 扩展性考虑事项
  • 4 个阶段的实现计划
  • 各阶段的验收标准
  • 文件结构
  • 核心实现细节
  • 测试策略
  • 潜在问题与解决方案
  • 后续改进项
  • 实现时要使用的技能

重要的是,它把文档生成规则也一起带上了

prd-generator 不只是一个会提问的技能。它连生成后的 PRD 应该保存到哪里,也明确规定好了。

documents/PRD/{연}-{월}-{주차}w/{일}d-{hh}h-{파일명}.md

这个规则比看起来更重要。文档若要成为项目资产,除了内容本身,保存方式也必须保持一致。这个技能甚至把周次计算规则都定好了,并明确要求目录不存在时自动创建。

也就是说,它不会停在「把文档写好」这件事上,而是进一步关心如何让文档在之后依然处于可管理状态。

模板很长,反而是优点

第一次看到这个技能的模板时,确实会觉得它相当长。但我反而认为,这个长度本身就是优点。

短模板固然快,但也意味着更多空白要靠人自己去补。相反,这个模板从一开始就把几乎所有必要的栏位都摊开了。

  • 概要
  • 功能说明
  • 参考实现
  • 核心功能
  • 扩展性考虑事项
  • 4阶段实现计划
  • 文件结构
  • 核心实现细节
  • 测试策略
  • 潜在问题与解决方案
  • 后续改进项
  • 实现时要使用的技能
  • Claude Code 执行参考事项

当这些栏目被完整打开时,至少你会立刻知道自己漏掉了什么。我认为 PRD 模板的价值就在这里。好的模板不是把文档做得好看的工具,而是减少思考遗漏的工具。

与实现技能的联动,才是这个技能的核心

这个技能里,我最喜欢的还有一点:它在生成 PRD 时,会判断需要哪些实现技能,并把它们写进文档

很多 PRD 到文档本身就结束了。但真正更重要的是接下来的工作。如果不能继续指向该用什么实现技能、应该按什么顺序调用,PRD 和实现就会再次分离。

prd-generator 为了避免这一点,专门设置了一个实现技能联动章节。

按照当前文档的标准,主要会判断下面两个技能。

技能名激活条件负责范围
endpoint-implement-skill包含 Entity、Repository、Service、Controller、DTO 中任意一项实现 CRUD API 的完整层级
sse-streaming-skill包含 SSE 流式传输、TEXT_EVENT_STREAM_VALUE、实时响应实现 SSE Controller/Service

这套判断逻辑之所以好,原因很明确。因为 PRD 不再只是说明书,而是会指定下一步动作的文档。

例如,如果某个功能从 Entity 一直到 Controller 都需要,就可以明确写下应使用 endpoint-implement-skill。如果需求里包含 AI 响应流式输出,也可以指明该在第几个阶段接入 sse-streaming-skill。有了这种连接,无论是读文档的人还是代理,都不容易迷路。

什么时候适合用这个技能

这个技能并不是任何时候都必须用。但在下面这些场景里,它尤其好用。

  • 需要从零设计一个新功能时
  • 明确存在需要参考的既有代码时
  • 已经有功能需求,但实现顺序还不够清晰时
  • 之后打算直接衔接 Claude Code 或其他实现技能时
  • 文档需要沉淀为团队资产时

反过来,如果只是非常短的配置修改或小范围修补,它可能就有些过头了。这个技能与其说是给轻量备忘录准备的工具,不如说更接近把功能开发结构化后交付出去的工具

也把原文全文留在这里,方便资料共享

上面是说明,下面则是为了实际资料共享准备的附录。为了让人可以不做删减地查看 .claude/skills/prd-generator 的核心内容,我会把 SKILL.mdassets/prd_template.md 的全文一并放在这里。

附录 1. .claude/skills/prd-generator/SKILL.md 全文

Markdown
---
name: prd-generator
description: 기능 개발을 위한 대화형 PRD(제품 요구사항 문서) 생성기. 사용자가 새로운 기능에 대한 체계적인 구현 계획을 작성하고자 할 때 사용합니다. 이 스킬은 대화형 질문을 통해 요구사항을 수집한 후, Claude Code 실행에 최적화된 포괄적인 PRD 문서를 생성합니다. "PRD 만들어줘", "기능 기획해줘", "구현 계획 작성해줘", "기능 요구사항 문서화해줘" 등의 요청 시 활성화됩니다.
---

# PRD Generator (한글 버전)

이 스킬은 대화형 질문 프로세스를 통해 포괄적인 제품 요구사항 문서(PRD)를 생성합니다. 생성된 PRD는 Claude Code가 구현 계획을 효율적으로 실행할 수 있도록 최적화되어 있습니다.

## 워크플로우

스킬이 활성화되면 다음 대화형 워크플로우를 따르세요:

### 1단계: 기능 탐색

사용자가 원하는 기능에 대해 질문합니다. 다음 가이드 질문을 사용하세요 (상황에 맞게 조정):

1. **기능 개요**: "어떤 기능을 구현하고 싶으신가요? 상위 수준의 설명을 제공해주세요."
2. **기능 상세**: "이 기능의 핵심 기능과 사용자 상호작용을 설명해주실 수 있나요?"
3. **사용 사례**: "이 기능의 주요 사용 사례나 시나리오는 무엇인가요?"

사용자 응답을 기다린 후 진행하세요. 모든 질문을 한 번에 던지지 마세요.

### 2단계: 참조 구현

참조로 사용할 수 있는 기존 코드에 대해 질문합니다:

1. **기존 구현**: "참조해야 할 기존 코드나 구현이 있나요?"
2. **파일 경로**: 있다면: "이러한 참조 구현의 파일 경로는 무엇인가요?"
3. **따라야 할 패턴**: "이러한 참조에서 따라야 할 특정 패턴, 아키텍처 또는 규칙이 있나요?"

### 3단계: 확장성 및 아키텍처

확장성 및 확장 가능성에 대한 정보를 수집합니다:

1. **향후 성장**: "어떤 확장성 고려사항을 다루어야 하나요? 예: 사용자 부하, 데이터 볼륨, 기능 확장 등"
2. **통합 지점**: "이 기능이 다른 시스템이나 서비스와 통합되어야 하나요?"
3. **성능 요구사항**: "특정 성능 요구사항이나 제약사항이 있나요?"

### 4단계: 저장 위치

PRD 문서는 **문서 생성 규칙**에 따라 자동으로 경로가 결정됩니다.
사용자에게 파일명만 확인받고, 디렉토리는 자동 생성합니다.

1. **파일명 확인**: "PRD 문서의 파일명을 지정해주세요 (예: `AI_SCENARIO_GENERATOR`)"
   - 제공되지 않으면 기능명을 UPPER_SNAKE_CASE로 변환하여 사용

---

## 문서 생성 규칙

### 디렉토리 구조

```

documents/PRD/{연}-{월}-{주차}w/

```

- **연**: 4자리 연도 (예: 2025)
- **월**: 2자리 월 (예: 12)
- **주차**: 해당 월의 주차 (1~5) + `w` 접미사 (week의 약자)

**주차 계산**: 해당 월 1일부터 시작하여 7일 단위로 계산
- 1~7일: 1w (1주차)
- 8~14일: 2w (2주차)
- 15~21일: 3w (3주차)
- 22~28일: 4w (4주차)
- 29일~: 5w (5주차)

### 파일명 형식

```

{일}d-{hh}h-{파일명}.md

```

- **일**: 2자리 일 + `d` 접미사 (day의 약자, 예: 27d)
- **hh**: 2자리 시간(24시간제) + `h` 접미사 (hour의 약자, 예: 14h)
- **파일명**: UPPER_SNAKE_CASE (예: AI_SCENARIO_GENERATOR)

### 예시

2025년 12월 27일 14시에 AI 시나리오 생성기 PRD 생성 시:
```

documents/PRD/2025-12-4w/27d-14h-AI_SCENARIO_GENERATOR.md

```

### 디렉토리 자동 생성

지정된 디렉토리가 없으면 자동으로 생성합니다.

### 5단계: PRD 생성

모든 정보가 수집되면:

1. `assets/prd_template.md`에서 템플릿 읽기
2. **구현 시 사용할 스킬 판단** (아래 "구현 스킬 연동" 섹션 참조)
3. 다음 내용으로 모든 템플릿 플레이스홀더를 채워 포괄적인 PRD 생성:
   - 기능 이름 및 개요
   - 상세한 기능 설명
   - 참조 구현 세부사항 (제공된 경우)
   - 확장성 고려사항
   - 구체적인 작업이 포함된 4단계 구현 계획
   - 각 단계별 수용 기준
   - 파일 구조 개요
   - 논리적 섹션으로 나뉜 핵심 구현 세부사항
   - 테스트 전략
   - 잠재적 과제 및 해결책
   - 향후 개선 아이디어
   - **구현 시 사용할 스킬 (필수)**

3. 적절한 구조로 PRD 생성:
   - 명확한 단계별 구현 계획
   - 구체적이고 실행 가능한 작업
   - 구체적인 수용 기준
   - Claude Code가 따를 수 있는 기술적 세부사항
   - 파일 조직 지침

4. 지정된 경로에 PRD 저장
5. 사용자에게 문서 링크 제공

## 템플릿 구조

PRD 템플릿(`assets/prd_template.md`)은 다음을 포함합니다:

- **개요**: 기능의 상위 수준 요약
- **기능 설명**: 상세한 기능
- **참조 구현**: 기존 코드에 대한 링크
- **기술 요구사항**: 핵심 기능 및 확장성
- **구현 계획**: 작업 및 수용 기준이 포함된 4단계
  - 1단계: 설정 및 기반
  - 2단계: 핵심 구현
  - 3단계: 통합 및 테스트
  - 4단계: 다듬기 및 최적화
- **파일 구조**: 제안된 디렉토리 레이아웃
- **핵심 구현 세부사항**: 기술적 세부사항
- **테스트 전략**: 구현 검증 방법
- **과제 및 해결책**: 예상되는 문제
- **향후 개선사항**: 확장 지점
- **Claude Code 실행 참고사항**: PRD 사용 방법

## 모범 사례

1. **대화형으로 진행**: 한 번에 한두 가지 질문을 자연스럽게 던지세요
2. **질문 조정**: 사용자 응답에 따라 후속 질문을 맞춤화하세요
3. **모호함 명확화**: 사용자 응답이 모호하면 구체적인 예를 요청하세요
4. **모듈식 사고**: 복잡한 기능을 논리적 단계로 나누세요
5. **구체적으로**: 추상적인 목표가 아닌 구체적인 작업을 생성하세요
6. **코드 참조**: 참조 구현이 있다면 읽고 패턴을 통합하세요
7. **확장성 고려**: 간단한 기능이라도 항상 확장성 고려사항을 포함하세요
8. **실행 가능하게**: 각 단계는 Claude Code가 실행할 수 있는 명확한 작업이 있어야 합니다

## 대화 흐름 예시

```

사용자: "사용자 인증 시스템에 대한 PRD를 만들고 싶어요"

Claude: "좋습니다! 사용자 인증 시스템에 대한 포괄적인 PRD를 작성하도록 도와드리겠습니다.

먼저, 원하시는 핵심 기능을 설명해주시겠어요? 예를 들어:

- 어떤 인증 방법을 사용하나요? (이메일/비밀번호, OAuth 등)
- 어떤 사용자 역할이나 권한이 필요한가요?
- 특정 보안 요구사항이 있나요?"

사용자: [세부사항 제공]

Claude: "감사합니다! 제가 참조해야 할 기존 인증 코드나 유사한 구현이 코드베이스에 있나요?"

사용자: [경로 제공 또는 없다고 답변]

Claude: "어떤 확장성 고려사항을 염두에 두어야 할까요? 예를 들어:

- 예상 사용자 수는?
- 속도 제한이 필요한가요?
- 세션 관리 전략은?"

사용자: [세부사항 제공]

Claude: "마지막으로, 이 PRD 문서를 어디에 저장하시겠어요?"

사용자: [경로 제공 또는 Claude가 기본값 사용하도록 함]

Claude: [포괄적인 PRD 생성 및 저장]
"사용자 인증 시스템에 대한 PRD를 작성했습니다. [문서 보기](computer:///path/to/prd.md)"

```

## PRD 생성 팁

- **1단계**는 설정에 집중: 의존성, 기본 구조, 구성
- **2단계**는 핵심 기능 구현
- **3단계**는 통합 지점 및 테스트 처리
- **4단계**는 다듬기 추가: 오류 처리, 엣지 케이스, 최적화
- 각 단계는 이전 단계를 기반으로 구축되어야 함
- 수용 기준은 테스트 가능하고 구체적이어야 함
- 참조 구현 패턴을 따르는 파일 구조 포함 (제공된 경우)
- **모든 내용은 한글로 작성**: 기능 설명, 작업, 수용 기준, 주석 등 모두 한글로 작성

---

## 구현 스킬 연동 (핵심)

PRD 생성 시 **반드시** 구현에 필요한 스킬을 판단하여 문서에 포함해야 합니다.
이를 통해 구현 일관성을 확보하고, 프로젝트 규약을 자동으로 준수할 수 있습니다.

### 스킬 판단 기준

| 스킬명 | 활성화 조건 | 담당 범위 |
|--------|------------|----------|
| `endpoint-implement-skill` | Entity, Repository, Service, Controller, DTO 중 **하나라도** 포함 | CRUD API 전체 레이어 구현 |
| `sse-streaming-skill` | SSE 스트리밍, `TEXT_EVENT_STREAM_VALUE`, 실시간 응답 포함 | SSE 컨트롤러/서비스 구현 |

### 스킬 판단 로직

PRD 내용을 분석하여 다음 키워드가 있으면 해당 스킬 사용을 안내합니다:

**endpoint-implement-skill 활성화 키워드:**
- Entity, 엔티티
- Repository, 레포지토리, JPA
- Service, 서비스
- Controller, 컨트롤러, API 엔드포인트
- DTO, Request, Response
- CRUD, 생성, 조회, 수정, 삭제

**sse-streaming-skill 활성화 키워드:**
- SSE, Server-Sent Events
- TEXT_EVENT_STREAM_VALUE
- 스트리밍 응답, 실시간 스트리밍
- SseEmitter, Flux<ServerSentEvent>
- 실시간 이벤트 전송

### PRD에 작성할 스킬 안내 예시

```markdown
## 구현 시 사용할 스킬

이 PRD를 구현할 때 다음 스킬을 **반드시** 활용하세요:

| 구현 영역 | 사용 스킬 | 활성화 조건 |
|----------|----------|------------|
| Entity ~ Controller | `endpoint-implement-skill` | 시나리오 CRUD API 구현 필요 |
| SSE 스트리밍 | `sse-streaming-skill` | AI 응답 실시간 스트리밍 필요 |

### 스킬 사용 순서

1. **1단계 (Entity/Repository)**: `endpoint-implement-skill` 호출
   - Entity 정의, Repository 생성
2. **2단계 (Service/Controller)**: `endpoint-implement-skill` 계속 사용
   - Service 비즈니스 로직, Controller 엔드포인트
3. **3단계 (SSE 통합)**: `sse-streaming-skill` 호출
   - SSE 컨트롤러, 스트리밍 서비스 구현

### 스킬별 담당 범위

**endpoint-implement-skill:**
- `entity/Scenario.kt`, `entity/Character.kt` 등 Entity 파일
- `ScenarioRepository.kt` 등 Repository 인터페이스
- `ScenarioService.kt` 등 Service 클래스
- `ScenarioController.kt` 등 Controller 클래스
- `ScenarioRequestDto.kt`, `ScenarioResponseDto.kt` 등 DTO

**sse-streaming-skill:**
- `GameChatSseController.kt` SSE 전용 컨트롤러
- `GameChatStreamService.kt` 스트리밍 서비스
- SSE 이벤트 타입, 이미터 설정
```

### 복합 스킬 사용 시 주의사항

1. **스킬 간 경계를 명확히**: Entity~Controller는 endpoint-implement-skill, SSE 전용 로직은 sse-streaming-skill
2. **순서 준수**: 기반 Entity/Service가 먼저, SSE 통합은 나중에
3. **스킬 호출 시점 명시**: PRD의 각 단계에서 어떤 스킬을 호출해야 하는지 명시

### 스킬이 필요 없는 경우

다음 경우에는 스킬 연동 섹션을 생략할 수 있습니다:

- 설정 파일(application.yml) 변경만 필요한 경우
- 기존 코드 수정/리팩토링만 필요한 경우
- 문서화, 마이그레이션 가이드 등 비코드 작업

附录 2. .claude/skills/prd-generator/assets/prd_template.md 全文

Markdown
# PRD: {{기능명}}

## 개요

{{기능_개요}}

## 기능 설명

{{기능_상세_설명}}

## 참조 구현

{{참조_구현}}

## 기술 요구사항

### 핵심 기능

{{핵심_기능}}

### 확장성 고려사항

{{확장성_고려사항}}

## 구현 계획

### 1단계: 설정 및 기반

**목표**: {{1단계_목표}}

**작업**:

1. {{1단계_작업1}}
2. {{1단계_작업2}}
3. {{1단계_작업3}}

**수용 기준**:

- {{1단계_수용기준1}}
- {{1단계_수용기준2}}

---

### 2단계: 핵심 구현

**목표**: {{2단계_목표}}

**작업**:

1. {{2단계_작업1}}
2. {{2단계_작업2}}
3. {{2단계_작업3}}

**수용 기준**:

- {{2단계_수용기준1}}
- {{2단계_수용기준2}}

---

### 3단계: 통합 및 테스트

**목표**: {{3단계_목표}}

**작업**:

1. {{3단계_작업1}}
2. {{3단계_작업2}}
3. {{3단계_작업3}}

**수용 기준**:

- {{3단계_수용기준1}}
- {{3단계_수용기준2}}

---

### 4단계: 다듬기 및 최적화

**목표**: {{4단계_목표}}

**작업**:

1. {{4단계_작업1}}
2. {{4단계_작업2}}
3. {{4단계_작업3}}

**수용 기준**:

- {{4단계_수용기준1}}
- {{4단계_수용기준2}}

## 파일 구조

```

{{파일_구조}}

```

## 핵심 구현 세부사항

### {{세부사항1_제목}}

{{세부사항1_내용}}

### {{세부사항2_제목}}

{{세부사항2_내용}}

### {{세부사항3_제목}}

{{세부사항3_내용}}

## 테스트 전략

{{테스트_전략}}

## 잠재적 과제 및 해결책

{{과제_및_해결책}}

## 향후 개선사항

{{향후_개선사항}}

## 구현 시 사용할 스킬

이 PRD를 구현할 때 다음 스킬을 **반드시** 활용하세요:

| 구현 영역 | 사용 스킬 | 활성화 조건 |
|----------|----------|------------|
| {{skill_table_rows}} |

### 스킬 사용 순서

{{skill_usage_order}}

### 스킬별 담당 범위

{{skill_coverage}}

---

## Claude Code 실행 참고사항

이 PRD는 순차적 구현을 위해 구조화되었습니다:

1. 1단계 작업부터 순서대로 시작
2. 각 단계는 이전 단계를 기반으로 구축됨
3. 다음 단계로 넘어가기 전에 수용 기준 검증
4. 구체적인 지침은 "핵심 구현 세부사항" 섹션 참조
5. 각 단계 검증 시 "테스트 전략" 사용
6. **위 "구현 시 사용할 스킬" 섹션의 스킬을 반드시 활용하여 구현 일관성 확보**

结语

我认为,像现在这样 AI 编程环境越快,重要的就越不是单纯把实现做得好,而是进入实现之前的整理能力。prd-generator 处理的正是这个环节。

它做的事并不夸张。无非是询问功能、确认参考实现、询问扩展性、应用保存规则,再整理成可执行的 PRD。但只要把这套过程先结构化一次,后续的实现就会稳定得多。

如果你经常用 Claude Code 做功能开发,但每次都是点子有了、执行计划却模糊,导致启动总是偏慢,我会相当建议先把这个技能整理好。很多生产力提升,往往不是来自更快地写代码,而是来自在写代码之前先把事情整理得更准确。

附件

这里再附上一份由该技能生成的文档。猜一猜它可能是用什么提示生成的,应该也挺有意思。

# Blog Service 다국어 번역 구조 도입 PRD

## 📋 개요

| 항목 | 내용 |
|------|------|
| **문서 ID** | PRD-2026-01-24-BLOG-MULTILANG |
| **작성일** | 2026-01-24 |
| **작성자** | Claude Code |
| **상태** | ✅ 완료 |
| **대상 서비스** | blog-service |

## 🎯 목표

Flashcard/FlashcardTranslation 패턴을 blog-service에 도입하여 Post, Category, Comment, Tag 엔티티의 다국어 지원을 구현한다.

## 📊 진행 현황

| # | Phase | 작업 항목 | 상태 | 완료일 |
|---|-------|----------|------|--------|
| 1 | Entity | PostTranslation.kt | ✅ 완료 | 2026-01-24 |
| 2 | Entity | CategoryTranslation.kt | ✅ 완료 | 2026-01-24 |
| 3 | Entity | CommentTranslation.kt | ✅ 완료 | 2026-01-24 |
| 4 | Entity | TagTranslation.kt | ✅ 완료 | 2026-01-24 |
| 5 | Repository | PostTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 6 | Repository | CategoryTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 7 | Repository | CommentTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 8 | Repository | TagTranslationRepository.kt | ✅ 완료 | 2026-01-24 |
| 9 | DTO | PostDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 10 | DTO | CategoryDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 11 | DTO | CommentDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 12 | DTO | TagDto.kt 수정 | ✅ 완료 | 2026-01-24 |
| 13 | DTO | TranslationDto.kt 신규 | ✅ 완료 | 2026-01-24 |
| 14 | Service | PostService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 15 | Service | CategoryService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 16 | Service | CommentService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 17 | Service | TagService.kt 수정 | ✅ 완료 | 2026-01-24 |
| 18 | Service | TranslationService.kt 신규 | ✅ 완료 | 2026-01-24 |
| 19 | Controller | PostController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 20 | Controller | CategoryController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 21 | Controller | CommentController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 22 | Controller | TagController.kt 수정 | ✅ 완료 | 2026-01-24 |
| 23 | Controller | BoTranslationController.kt 신규 | ✅ 완료 | 2026-01-24 |

**진행률: 23/23 (100%) ✅ 완료**

---

## 🏗️ 기술 설계

### 1. 번역 대상 필드

| 엔티티 | 번역 필드 | 원본 길이 | 번역 길이 (2배) |
|--------|----------|----------|----------------|
| Post | title | 200 | 400 |
| Post | excerpt | TEXT | TEXT |
| Post | content | TEXT | TEXT |
| Category | name | 100 | 200 |
| Category | description | TEXT | TEXT |
| Comment | content | TEXT | TEXT |
| Tag | name | 50 | 100 |

### 2. 핵심 패턴 (Flashcard 검증 완료)

#### 2.1 Entity 패턴
```kotlin
@Entity
@Table(indexes = [...])
@IdClass(PostTranslationPk::class)
data class PostTranslation(
  @Id @Column(updatable = false)
  val postId: Long,

  @Id @Column(length = 5, updatable = false)
  val languageCode: String,

  // 번역 필드들
  var title: String,
  var excerpt: String?,
  var content: String
) : BaseTimeEntity()

data class PostTranslationPk(
  val postId: Long? = null,
  val languageCode: String? = null,
) : Serializable
```

#### 2.2 DTO 패턴

```kotlin
data class DetailResponse(
  // 원본 필드
  @get:JvmName("titleOriginal")
  private val title: String,

  // 번역 필드 (JSON 숨김)
  @JsonIgnore
  val translatedTitle: String? = null,

  // 실제 응답 (번역 우선)
  @JsonGetter("title")
  fun getTitle(): String =
    translatedTitle?.takeIf { it.isNotBlank() } ?: title
)
```

#### 2.3 Service JOIN 패턴

```kotlin
queryFactory
  .select(PostDto.ListResponse.buildProjectionWithTranslation())
  .from(post)
  .leftJoin(postTranslation)
  .on(postTranslation.postId.eq(post.id)
    .and(postTranslation.languageCode.eq(lang)))
  .fetch()
```

#### 2.4 Controller 패턴

```kotlin
@GetMapping("/posts")
fun findAll(
  @RequestParam(required = false) lang: String?,
  // ...
): JPage<PostDto.ListResponse>
```

### 3. 지원 언어 코드

---

## 📁 파일 경로

```
modules/blog-service/src/main/kotlin/com/jongmin/blog/
├── entity/
│   ├── PostTranslation.kt       # 신규
│   ├── CategoryTranslation.kt   # 신규
│   ├── CommentTranslation.kt    # 신규
│   └── TagTranslation.kt        # 신규
├── repository/
│   ├── PostTranslationRepository.kt       # 신규
│   ├── CategoryTranslationRepository.kt   # 신규
│   ├── CommentTranslationRepository.kt    # 신규
│   └── TagTranslationRepository.kt        # 신규
├── dto/
│   ├── PostDto.kt         # 수정
│   ├── CategoryDto.kt     # 수정
│   ├── CommentDto.kt      # 수정
│   ├── TagDto.kt          # 수정
│   └── TranslationDto.kt  # 신규
├── service/
│   ├── PostService.kt         # 수정
│   ├── CategoryService.kt     # 수정
│   ├── CommentService.kt      # 수정
│   ├── TagService.kt          # 수정
│   └── TranslationService.kt  # 신규
└── controller/
    ├── PostController.kt         # 수정
    ├── CategoryController.kt     # 수정
    ├── CommentController.kt      # 수정
    ├── TagController.kt          # 수정
    └── BoTranslationController.kt # 신규
```

---

## 📝 작업 로그

### 2026-01-24

- **15:00** - PRD 문서 생성, 작업 계획 수립 완료

---

## 🔗 참조

- **레퍼런스 구현**: `legacy-service/catch_on/platform/entity/FlashcardTranslation.kt`
- **레퍼런스 서비스**: `legacy-service/catch_on/platform/service/SubjectService.kt`
- **레퍼런스 DTO**: `legacy-service/catch_on/platform/dto/response/FlashCardResponseDto.kt`