게시판은 제목과 본문을 저장하는 기능으로 시작할 수 있습니다. 노션처럼 블록을 편집하고, 여러 사람이 협업하고, 권한과 검색까지 제공하려면 데이터 구조와 운영 범위가 달라집니다.
에디터 라이브러리를 고르는 일은 일부입니다. 먼저 문서를 무엇으로 저장하고, 변경 이력과 권한을 어떻게 관리하며, 외부로 내보낼 수 있는지 정해야 합니다.
이 글은 일반 게시판에서 블록 문서와 실시간 협업으로 확장할 때 필요한 선택을 정리합니다.
편집기 라이선스와 기능은 도입 시점의 공식 문서를 확인해야 합니다.
첫 단계: 어떤 문서를 만드는가
다음 요구는 비슷해 보이지만 구현 범위가 다릅니다.
- 공지와 블로그처럼 작성자 한 명이 발행하는 게시물
- 댓글과 답글이 있는 커뮤니티
- 업무 위키와 지식베이스
- 표, 체크리스트와 임베드를 조합하는 블록 문서
- 여러 사용자가 동시에 수정하는 협업 문서
일반 게시판에 실시간 협업 기능을 나중에 붙이는 것보다, 동시 편집과 이력이 핵심이면 처음부터 문서 모델과 동기화 방식을 별도로 설계하는 편이 낫습니다.
본문 저장 방식
HTML
완성된 본문을 HTML로 저장하면 렌더링이 단순합니다. 오래된 에디터와 CMS에서 널리 사용합니다.
사용자 입력 HTML을 그대로 보여주면 스크립트와 위험한 속성으로 XSS가 발생할 수 있습니다. 서버와 클라이언트에서 허용할 태그와 속성을 정하고 정화해야 합니다. OWASP의 XSS 예방 안내를 기준으로 출력 위치에 맞는 인코딩과 정화 방식을 검토할 수 있습니다.
에디터를 바꿀 때 기존 HTML을 새 편집 모델로 다시 읽을 수 있는지도 확인해야 합니다.
Markdown
텍스트 중심 문서와 개발자 문서에 적합합니다. 파일로 내보내기 쉽고 버전 비교도 단순합니다.
표, 임베드, 맞춤 블록과 복잡한 레이아웃을 표현하려면 별도 문법이나 메타데이터가 필요합니다. 같은 Markdown도 파서마다 지원 문법과 HTML 처리 방식이 다를 수 있습니다.
구조화된 JSON
문단, 제목, 이미지와 체크리스트를 노드나 블록으로 저장합니다. 블록 단위 편집, 이동과 변환에 유리하고, 특정 블록에 ID와 권한을 붙일 수 있습니다.
대신 에디터 버전이 바뀔 때 문서 스키마를 마이그레이션해야 합니다. 어떤 버전의 노드가 저장됐는지 기록하고, 알 수 없는 블록을 잃지 않고 보존하는 방법이 필요합니다.
노션 같은 제품을 만들 때 JSON으로 저장하면 된다가 끝이 아닙니다. 스키마 버전, 변환기, 내보내기와 검색용 텍스트 추출까지 포함해야 합니다.
에디터 선택 기준
CKEditor, TinyMCE, Tiptap, Editor.js, Lexical과 여러 오픈소스·상용 편집기가 있습니다. 기능 수보다 다음 조건을 비교합니다.
- 저장 데이터 형식과 스키마를 통제할 수 있는가
- 필요한 표·이미지·코드·임베드 블록을 지원하는가
- 한글 입력기와 모바일 브라우저에서 안정적인가
- 붙여넣기한 문서를 어떻게 정리하는가
- 접근성과 키보드 조작을 지원하는가
- 협업 플러그인과 변경 이력의 범위는 무엇인가
- 라이선스가 제품과 배포 방식에 맞는가
- 에디터를 바꿀 때 데이터를 내보낼 수 있는가
무료 패키지라고 상용 서비스의 모든 사용이 허용되는 것은 아니고, 오픈소스 코어와 유료 플러그인의 조건이 다를 수 있습니다. 도입 버전과 사용 기능별 라이선스를 기록합니다.
게시물 데이터 모델
일반 게시판도 다음 영역을 분리하면 확장하기 쉽습니다.
- 문서: 제목, 상태, 작성자와 발행일
- 현재 본문: 렌더링에 사용하는 최신 버전
- 버전: 수정자, 수정 시각과 변경 전후 데이터
- 댓글: 문서와 상위 댓글 관계
- 첨부 파일: 저장 위치, 크기, MIME 유형과 소유자
- 권한: 사용자·그룹별 읽기, 댓글, 수정과 관리
- 분류: 카테고리, 태그와 컬렉션
초안, 검토, 발행, 보관 상태를 한 개의 공개 여부 값으로만 관리하면 예약 발행과 승인 흐름을 붙이기 어렵습니다. 콘텐츠 수명주기에 맞는 상태를 정의합니다.
목록과 검색
페이지네이션
데이터가 적을 때는 offset 방식이 단순합니다. 최신 글을 계속 추가하면서 다음 페이지를 읽는 피드에서는 created_at과 id를 기준으로 하는 커서 페이지네이션이 중복과 누락을 줄일 수 있습니다.
정렬 조건과 필터에 맞는 복합 인덱스를 설계해야 합니다. 인덱스 이름을 미리 정하기보다 실제 쿼리와 실행 계획을 확인합니다.
본문 검색
초기에는 데이터베이스의 전문검색 기능으로 충분할 수 있습니다. 언어별 형태소 분석, 오타 허용, 검색어 추천, 권한별 검색과 대규모 색인이 필요할 때 전용 검색엔진을 검토합니다.
검색엔진을 별도로 쓰면 문서 저장과 색인 사이에 지연과 실패가 생깁니다. 재색인, 삭제 반영, 권한 변경과 장애 복구 절차가 필요합니다.
캐시
인기 글을 캐시하는 것은 읽기 부하가 실제 문제일 때 적용합니다. 댓글과 권한이 자주 바뀌는 데이터는 잘못된 캐시가 정보 노출로 이어질 수 있습니다. 캐시 키에 사용자 권한이 영향을 주는지 확인하고, 삭제·수정 시 무효화 방식을 정합니다.
파일 업로드는 별도 보안 기능이다
이미지와 문서 첨부에는 파일 크기 제한만으로 부족합니다.
- 허용 확장자와 실제 파일 형식 검사
- 저장 파일명 재생성
- 사용자별 업로드 권한과 용량
- 비공개 파일의 접근 제어
- 악성 파일 검사
- 이미지 변환과 메타데이터 처리
- 삭제와 보존기간
- 다운로드 응답 헤더
OWASP의 파일 업로드 보안 안내는 허용 목록, 파일명 변경과 저장 위치 분리 등을 권고합니다.
객체 스토리지와 CDN을 쓰더라도 비공개 파일 URL을 영구 공개하거나, 사용자가 올린 HTML·SVG를 같은 출처에서 바로 실행하게 만들면 위험할 수 있습니다.
권한은 화면 버튼보다 서버에서 검사한다
수정 버튼을 숨기는 것만으로 권한을 제한할 수 없습니다. 읽기, 댓글, 수정, 삭제, 공유와 관리 권한을 API에서 확인해야 합니다.
권한 모델은 다음 중 하나 또는 조합이 될 수 있습니다.
- 소유자와 작성자
- 조직·그룹 역할
- 문서별 공유 대상
- 링크를 아는 사람
- 공개 문서
문서가 다른 공간으로 이동하거나 사용자가 조직에서 나갈 때 권한이 어떻게 바뀌는지까지 정의합니다. 검색 결과와 알림에서도 읽을 수 없는 문서 제목이 노출되지 않아야 합니다.
버전과 감사로그
자동 저장이 있는 문서는 매 입력마다 전체 버전을 만들면 저장량과 복구 UX가 나빠질 수 있습니다. 일정 시간이나 의미 있는 편집 단위로 스냅샷을 만들고, 필요하면 변경 연산을 별도로 기록합니다.
버전 기능은 사용자가 복원할 문서 이력을 다룹니다. 감사로그는 관리자가 누가 권한과 상태를 바꿨는지 확인하는 기록입니다. 두 목적을 분리하면 보존기간과 접근 권한을 정하기 쉽습니다.
실시간 공동 편집
두 사용자가 같은 문서를 수정할 때 마지막 저장으로 덮어쓰는 방식은 변경을 잃을 수 있습니다.
간단한 서비스에서는 낙관적 잠금으로 내가 읽은 뒤 다른 사람이 수정했다는 충돌을 감지하고 다시 확인하게 할 수 있습니다. 문자 단위 동시 편집이 필요하면 CRDT나 OT 같은 동기화 모델을 검토합니다.
실시간 협업에는 WebSocket 연결 외에도 다음이 필요합니다.
- 문서별 세션과 인증
- 오프라인 편집 후 재연결
- 커서와 사용자 상태
- 변경 순서와 충돌 처리
- 서버 저장과 스냅샷
- 오래된 클라이언트 버전의 호환성
- 장애 뒤 문서 복구
WebSocket을 붙인다와 공동 편집을 구현하는 것은 다른 범위입니다. 핵심 요구가 아니라면 먼저 버전 충돌 감지와 수동 병합으로 시작할 수 있습니다.
AI 편집 기능을 추가하기 전에
요약, 문장 수정과 질의응답을 붙일 때 모델 API 호출만 보지 않습니다.
- 어떤 문서와 선택 영역을 외부 모델에 보내는가
- 개인정보와 회사 기밀을 어떻게 제거하는가
- 사용자 동의와 조직 관리자의 통제는 어떻게 제공하는가
- 프롬프트와 결과를 얼마나 보관하는가
- 모델 결과를 원문에 자동 반영할지 사용자가 승인할지 정한다
- 비용 한도와 호출 실패를 처리한다
비공개 문서를 외부 모델에 보내지 않는 구성이 필요하면 로컬 모델이나 전용 배포, 비식별화 흐름을 검토합니다.
단계별 구축 범위
1단계: 발행형 게시판
문서 작성·수정, 초안과 발행, 목록·검색, 이미지 업로드와 관리자 권한을 만듭니다.
2단계: 지식베이스
구조화된 문서, 내부 링크, 버전, 그룹 권한과 검색을 추가합니다.
3단계: 협업 문서
실시간 동기화, 커서, 댓글·멘션, 오프라인 복구와 감사로그를 추가합니다.
첫 버전에서 세 단계를 모두 만들기보다 사용자가 실제로 필요한 단계와 데이터 이전 경로를 정합니다.
에디터보다 문서의 수명을 설계한다
게시판과 문서 서비스는 작성 화면보다 저장 형식, 권한, 검색, 파일과 변경 이력에서 운영 차이가 생깁니다. 에디터를 교체해도 문서를 잃지 않고, 권한이 바뀌면 모든 노출 경로에 반영되며, 장애가 나도 이전 버전으로 복구할 수 있어야 합니다.
게시판, 지식베이스와 협업 문서 중 어느 범위가 필요한지 검토하려면 프로젝트 문의에 문서 유형, 사용자 역할과 동시 편집 필요 여부를 알려주세요. 첫 버전과 이후 확장 범위를 나눠 답하겠습니다.