좋은 질문이고, 결론부터 말하면 가능하고, 스키마 변경도 작습니다. 정확히 답하려고 현재 데이터 모델을 확인해볼게요.스레드 구조와 리치 에디터 옵션을 비교 검토했습니다스레드 구조와 리치 에디터 옵션을 비교 검토했습니다네, 가능합니다. 현재 구조와 바꾸는 방법을 먼저 정리할게요. 지금은 카테고리 → 주제(Post: 제목 + CKEditor 리치 본문) → 댓글(Comment: 평문, 평면 리스트) 구조예요. Comment 에 parentId 가 없어서 댓글이 서로 답글로 이어지지 못하고, 내용도 평문이라 말씀하신 대로 "큰 주제"를 담기 어렵습니다. 스레드로 만드는 표준 방법은 자기참조 parentId 컬럼을 추가해 트리로 만드는 것입니다. 핵심은 트리를 어느 층위에 넣느냐인데, 두 갈래가 있어요. A. 중첩 답글 (댓글을 트리로) — 추천 Comment 에 parentId 추가 → 댓글에 답글, 그 답글에 또 답글이 달리는 Reddit식 트리. Post 는 그대로 최상위 주제로 유지됩니다. 여기에 답글 본문을 CKEditor 리치로 승격하면(이미 sanitize.ts 파이프라인 있음) 각 답글이 긴 글·이미지까지 담을 수 있어요. 마이그레이션은 ALTER TABLE "Comment" ADD COLUMN "parentId" ... ON DELETE CASCADE 한 줄이고, 기존 댓글은 전부 최상위 스레드로 그대로 보존됩니다(데이터 유실 없음). B. 주제를 트리로 (주제 안에 하위 주제) Post 에 parentId 추가 → 카테고리 안에서 주제가 하위 주제를 갖는 재귀 구조. 각 노드가 제목+리치 본문을 온전히 가지니 "큰 주제를 담는다"에 가장 부합하지만, 목록/상세/캐시 키/라우팅/UI가 전부 재귀적으로 바뀌어 변경 폭이 큽니다. 둘 다 되돌리기 쉽고, 어느 쪽이든 이전처럼 dist 빌드까지 넣은 완성본 tgz로 만들어 드릴게요. 방향만 정해주시면 바로 작업하겠습니다.질문: 스레드를 어떤 구조로 만들까요? 답변: 둘 다 설명 더 듣고 결정질문: 답글/노드 본문에 서식(CKEditor)을 넣을까요? 답변: 리치 에디터로 (긴 글·이미지)구조화된 비교분석 후 권장사항 제시하려 준비했다구조화된 비교분석 후 권장사항 제시하려 준비했다좋습니다. 리치 에디터는 확정으로 두고, A와 B를 더 깊이 비교해볼게요. 먼저 구조 차이를 그림으로 보여드리겠습니다.A와 B의 핵심 차이는 트리(스레드)가 어느 층에 생기느냐입니다. 그림으로 보면: ::view-transition-group(*), ::view-transition-old(*), ::view-transition-new(*) { animation-duration: 0.25s; animation-timing-function: cubic-bezier(0.19, 1, 0.22, 1); } VvisualizeVvisualize show_widget왼쪽이 A, 오른쪽이 B입니다. 이제 각각을 좀 더 깊이 볼게요. A · 댓글을 트리로 (중첩 답글) 데이터는 Comment 에 parentId string | null 한 컬럼만 추가합니다. Post 는 지금처럼 최상위 주제로 유지되고, 댓글끼리 답글로 가지치기합니다. 조회는 지금 listByPost 가 이미 한 글의 댓글을 평면으로 다 가져오니, 거기에 앱단에서 parentId 로 트리를 조립하는 코드만 얹으면 됩니다(재귀 CTE 불필요). 리치 에디터는 댓글 content 를 CKEditor HTML 로 올리고 기존 sanitize.ts 로 정화 — Post 본문과 완전히 같은 파이프라인이라 새로 만들 게 없습니다. UI는 글 상세의 댓글 영역이 들여쓰기 트리가 되고, 각 노드에 "답글" 버튼 → 인라인 리치 에디터가 열립니다(시각적 들여쓰기는 3~4단계에서 멈추고 저장은 무제한). 변경 파일은 schema.ts, comment.service(트리 조립 + parentId 검증: 같은 postId 인지·순환 방지), comment.controller/validator, index.html 정도. 마이그레이션은 ALTER TABLE "Comment" ADD COLUMN "parentId" text NULL REFERENCES "Comment"(id) ON DELETE CASCADE 한 줄이고, 기존 댓글은 전부 최상위로 그대로 보존됩니다. 성격: "하나의 주제 안에서 토론이 갈라진다." 질문/답변, 논쟁, 심화 토론에 맞고 대부분의 커뮤니티가 이 방식입니다. B · 주제를 트리로 (하위 주제) 데이터는 Post 에 parentId 를 추가해 카테고리 안에서 주제가 하위 주제를 갖는 재귀 구조가 됩니다. 각 노드가 이미 제목 + 리치 본문을 온전히 가지니 "큰 주제를 담는다"에는 가장 잘 맞습니다(리치 작업이 사실상 이미 끝나 있음). 대신 목록·상세·postsList 캐시 키·페이지네이션·라우팅이 전부 부모 기준으로 바뀌고, UI도 카테고리 → 주제 → 하위 주제 네비게이션(브레드크럼/트리)과 상세 페이지의 "하위 주제 목록" 섹션이 필요해 변경 폭이 훨씬 큽니다. 댓글은 각 주제에 평면으로 그대로 남습니다. 성격: "카테고리를 더 잘게 나눈다 / 하위 게시판·문서 트리." 위키·지식베이스·서브포럼형 사이트에 어울립니다. 정리하면 — 원래 하신 말씀("댓글이 큰 주제를 못 담는다")을 직접 푸는 건 A입니다. 각 답글이 리치 + 가지치기가 되니 사실상 하위 주제를 댓글 자리에서 담게 되고, 변경 폭이 작으며 무손실입니다. B는 좋은 기능이지만 "분류 계층"에 가까워서, 지금 겪는 문제와는 결이 조금 다릅니다. (원하면 나중에 A 위에 B를 얹는 것도 가능합니다 — 지금 둘 다는 과함.) 저는 A + 리치 답글을 추천합니다. 어느 쪽으로 갈지 골라주세요.