Digging

0. 개요 CMS는 대부분의 개발자가 가장 먼저 접하는 친숙한 구조입니다. CRUD를 기반으로 한 패턴으로 어떤 기술을 배우든 자연스럽게 마주하게 되죠. 라프텔, 넷플릭스, 네이버 쇼핑, 다음 웹툰, 링크드인까지 우리가 쓰는 대부분의 서비스도 사실상 CMS의 확장 버전이라 볼 수 있습니다. 가장 단순해 보이지만, 그만큼 끝 없이 파고들 수 있는 구조로 그동안 당연하게 써왔지만 정리를 해본 적이 없었네요. 이번에 처음으로 쭉 정리해봤습니다, 부족한 점이 있다면 가감 없이 피드백 부탁 드려요 1. 콘텐츠 CRUD 1.1 생성 (Create) SEO용 slug 자동 생성 (핵심 키워드, stop word 제거, 소문자 사용, 특수문자 제거) XSS, SQL Injection 검증 캐시 데이터에 추가 스케줄링 처리: 작은 작업은 cron을, 대용량은 메시지 큐(Kafka, BullMQ)를 사용하여 백그라운드 작업 자동화 테스트: CRUD API가 정상적으로 작동하는 지를 CI/CD 파이프라인에 포함하여 매번 체크 다양한 플랫폼 지원: 부 모바일/TV 앱이 동일 API 사용 가능 형태로 설계 요금제 플랜: Redis를 이용해서 계정마다 현재 접속 수 체크해서 요금제 플랜에 맞게 관리 모니터링: 업로드 실패율, 렌더링 지연, 승인 리뷰 대기 시간, 서버 리소스 등 수치 트래킹 sentry: 모니터링 도구로 실시간 에러 트래킹과 프론트, 백엔드에서 발생하는 예외, 로그, 버그 정보를 수집하여 UI로 시각화 해줌 datadog: 서버, 애플리케이션, 로그, 메트릭, 인프라를 통합 모니터링 툴로 sentry보다 범용적이며 DevOps에서 많이 사용됨 리소스 파일 업로드: 리소스 파일들을 Multipart Upload Protection, 즉 chunk 단위로 업로드해서 악성파일, 과도한 용량문제 해결, 보안 룰 적용 (확장자, MIME 타입, 바이러스 검사) API 문서화: drf-spectacular 같은 걸로 자동 문서화 1.2 읽기 (Read) 상태, 태그와 같은 조건에 따라 필터링된 대용량 데이터에 대한 쿼리 캐시 지원 공개된 데이터는 Redis / Memcached로 select list를 캐싱 변경시는 수동으로 캐시를 지우거나 TTL이 짧다면 자동 갱신 비디오/이미지/정적 리소스는 CDN으로 읽기 비용 감소 발행이 Draft로 콘텐츠여도 미리보기 링크로 확인 가능 1.3 수정 (Update) 업데이트 충돌 방지를 위해, Optimistic Concurrency로 글을 수정을 진행할 때와 가져온 글 버전과 저장할 떄 글 버전이 같아야 함 slug나 파일 링크 변경시 유효한지 검사 변경전 슬러그도 지원하기 위한 alias 기능 콘텐츠 변경시 이전 버전들을 저장해서 글의 버전 관리 비디오 파일이 바뀌면 자동으로 썸네일 재생성 콘텐츠가 업데이트되면 관련 select 캐시나 cdn 캐시 데이터 수정 콘텐츠 수정 시 어떤 Text가 바뀐지를 Diff 뷰로 보여줌 1.4 삭제 (Delete) Deleted At 또는 Disabled로 soft 삭제를 하고, 추후에 관리자나 유저가 DB에서 완전 삭제후 자동 purge soft 삭제로 db 리소스 접근을 최소 화하는 방법으로 좋아요나 이모지 같이 사용자가 장난 칠 수 있는 기능에 적합 연관 데이터, 댓글, 조회수/통계 테이블, 썸네일, 원본 정적 리소스 파일간의 관계 제거 soft 삭제의 경우 복원 가능 누가, 언제, 어떻게 삭제했는 지를 기록 삭제된 콘텐츠로 접근 시 301로 리디렉트하거나 404로 반환 2. 콘텐츠 관리 2.1 콘텐츠 상태 관리 발행 관리: Draft, Published, Scheduled 시간 관리: Updated At, Created At 2.2 동영상 콘텐츠 실시간 방송 스트리밍 (단방향 실시간 통신) 장르, 태그, 시리즈, 년도(분기), 현재 방영 여부, 출시타입(TAV,극장판 OVA)로 영상 콘텐츠 분리 현재 방영 작은 요일별 신작으로 확인 가능하게 분리 원할한 스트리밍 서비스를 위한 캐싱이나 인코딩 처리 필요 2.3 콘텐츠 일정 설정 예약 게시일 등록 콘텐츠에 유효기간이 있다면 만료일도 등록 2.4 팀 기반 콘텐츠 작성자 관리 (PD, 편집자, 운영자) 권한별로 접근할 수 있는 메뉴, 페이지 분리 3. 데이터 보안 3.1 데이터 암호화 암호화 대상: 개인정보 (주민등록번호, 이름, 이메일, 비밀번호 등) 암호화 방법 대칭키 암호화: 암복호화에 같은 키 사용, 빠르고 효율적 대상: 이메일, 주소, 이름 등 자주 조회 및 수정이 필요한 데이터 암호화: AES-256, AES-GCM 비대칭키 암호화: 공개키로 암호화, 개인키로 복호화하고 느리지만 공개 키 배포 가능 대상: 민감한 서명, 토큰, 공개키 기반 인증 구조 (JWT, OAuth, SSH 등) 암호화: RSA 비밀번호는 복호화가 불가능한 해시 알고리즘 채택 (bcrypt, scrypt) 암호화 레이어 별 특징 애플리케이션 레벨: 코드에서 작업하므로 필드 단위로 세밀한 제어가 되지만 코드의 복잡잡도 증가 DB 레벨 (TDE): 전체 테이블/디스크를 설정만으로 암호화가 되지만 필드 제어가 불가능하고 느림 하이브리드: 민감한 데이터는 앱단에서 나머지는 TDE로 진행하면 성능과 보안의 밸런스를 조절할 수 있지만 설정에 복잡도 증가 키 관리: 암호화 키는 별도의 키 시스템으로 관리 ex: AWS KMS 참고 사항: 암호화된 데이터는 로그에 찍으면 안됨 잦은 검색 조건이 있는 건 인덱스 때문에 암호화 지양하고 민간함 정보만 암호화화 환경에 맞게 코드 컨밴션 툴 사용해서 코드 스타일 유지 Python의 black, PEP8 스타일 가이드 준수 Python의 isort, import 정렬기로 black과 같이 사용 4. 동영상 업로드 및 변환 4.1 동영상 업로드 시나리오 업로드 → 인코딩 → 썸네일 생성 → 배포 4.2 인코딩 포맷 MP4: 범용 포멧으로 대부분의 브라우저에서 지원하지만 스트리밍에서 성능이 제한적 HLS(HTTP Live Streaming): Apple 주도로 ios 친화적 스트리밍에 적합하고 현재는 다양한 장치에서 지원 DASH (MPEG-DASH): MPEG 표준, 크롬/안드로이드 친화적이고 유연한 확장성 제공 보통 두 가지 스트리밍 포맷(HLS & DASH)을 생성하고 클라이언트에서 상황에 맞춰 제공 4.3 Resumable Upload (중단 후 다시 업로드) tus(open protocol, 업로드 중단/복원 대응 강력), multipart upload, chunked upload 방식 사용 AWS S3 multipart upload도 해당 기능을 제공하니 클라우드를 활용 클라이언트에서 chunk 관리를 위해 JS 기반 상태 저장 로직 필요 4.4 자동 해상도 변환 (240p~4K) 하나의 동영상을 다양한 해상도 변환해서 저장 (360p, 480p, 720p, 1080p, 1440p, 4K) 자동 트랜스코딩 워크플로우는 큐 기반으로 비동기 처리 4.5 썸네일 자동 생성 프레임 수 기준 중간 지점이나 가장 밝은 장면 등 다양한 조건으로 썸네일 생성 AI 기반 썸네일 추출 기능 관리자 수동 업로드도 지원 4.6 FFmpeg + Redis + Worker 기반 트랜스코딩 큐 업로드된 파일은 곧바로 트랜스코딩하지 않고 큐에 등록 후 비동기 처리 ...