介绍我正在使用的 PRD 生成技能
引言
功能实现卡住的时刻,往往不是开始写代码之后,而是更常出现在那之前。要做什么、做到什么范围、该按什么顺序拆开、现有代码里该参考什么,如果这些都还没整理清楚就直接进入实现,代理会摇摆,人也会摇摆。
所以我并不把 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.md 和 assets/prd_template.md 的全文一并放在这里。
附录 1. .claude/skills/prd-generator/SKILL.md 全文
---
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 全文
# 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`