프로젝트 현황 파악 및 로드맵 정리

[always0ne]

프로젝트 현황을 파악한 후, 로드맵을 정리한다.

[always0ne]

2025.04.02
새로운 기획
https://forested-war-a1d.notion.site/1c3b3ce23e218030ad18e2b2a3c61bd1

올해의 목표는 커뮤니티를 만드는 것까지 진행한다.
이터레이션 1 은 설계하는것으로 잡는다.
설계할 내용

정적인 커뮤니티 서비스
에디터 없이 일반 텍스트 기반
댓글은 1댑스까지
좋아요 싫어요 반응 기능 댓글에도 달 수 있게
모바일 UI만 설계
게시판을 동적으로 관리하는 시스템
내 게시판 기능

계정
닉네임 정책
사용자 데이터를 어디까지 받을건지
이름 닉네임 이메일 비밀번호
3rd party 로그인 할건지
회원탈퇴 전략(탈퇴시 닉네임 바꿔버리기)

이터레이션 2는 구현
이터레이션 3은 고도화
4월은 Poc 위주로

[chohanjoo]

프로젝트 기획안 - 텍스트 커뮤니티 서비스

1. 프로젝트 개요

• 프로젝트 이름: (임시) “텍스트 커뮤니티 서비스”
• 목표: 사용자들이 텍스트 중심으로 간단하게 글을 작성하고 반응(좋아요/싫어요) 및 댓글을 달 수 있는 커뮤니티 플랫폼을 제공
• 핵심 가치:
  • 간결함: 복잡한 에디터 없이, 텍스트만 작성할 수 있는 최소한의 기능 제공
  • 확장성: 여러 개의 게시판(Board)을 유동적으로 추가·관리할 수 있고, 일부는 사용자 개인 보드로 운영 가능
  • 모바일 친화: 모바일 UI를 우선적으로 디자인 및 개발

---

2. 기능 개요

1. 게시글 작성/보기
   • 텍스트 기반의 게시글 작성, 편집, 조회, 삭제
   • 에디터 없이 단순 텍스트만 작성 (글자 제한, 개행 처리 등 최소 기능만 고려)
   • 1 Depth 댓글(대댓글 불가)

게시글
  ㄴ 댓글 (root)
      ㄴ 댓글 (1 depth?)

2. 댓글 작성/보기

   • 게시글에 댓글 작성/수정/삭제 가능
   • 댓글 정렬 기준(작성 시간순 등) 고려
   • 댓글은 root 라고 하고, 대댓글을 1 depth 라고 명명한다.

3. [Admin] 게시판(Bulletin Board) 관리

   • Group 의 걔념, admin 이 새로운 Group 을 생성하면, 유저들이 조인할 수 있음
   • 1차적으로는 Query 로 대체

4. 계정 & 회원 관리

   • 회원가입: 이름, 닉네임, 이메일, 비밀번호, 전화번호
     • 초기 가입시 비밀번호 인증 : 메일을 통해 인증
   • 닉네임 정책:
     • 게시글을 작성하면 닉네임이 노출된다.
     • 닉네임 중복 허용하지 않는다.
   • 로그인/로그아웃: 이메일+비밀번호 방식
   • 회원탈퇴: 탈퇴 시 닉네임 식별 불가 처리, 개인 정보 삭제/보존 정책
     • 기존에 사용하던 닉네임을 새로운 사람이 사용할 수 있다.
     • 작성된 게시글을 그대로 유지된다. 닉네임은 랜덤한 String 으로 대체된다.
   • 비밀번호 찾기/재설정
     • 메일을 통해 재설정

5. 모바일 UI/UX 우선 설계

   • 모바일 퍼스트로 화면 설계

6. 추가 검토 사항

   • 권한(Role) 체계: 관리자, 일반 회원 등

---

3. 주요 요구사항 상세

3.1 기능 요구사항

3.1.1 게시글 작성/보기

• 텍스트만 작성
  • Markdown, HTML 등 별도 포맷 지원 없음
  • 단순 개행/줄바꿈 정도만 가능
• 글자 제한
  • 예: 최소 1자, 최대 5,000자
• 작성/수정 시간 기록
  • 작성, 수정 시각이 표시
• 좋아요/싫어요 반응
  • 게시글 본문 하단에 버튼 배치
  • 중복 클릭 방지 처리

3.1.2 댓글 작성/보기

• 1 Depth만 지원
  • 대댓글 불가
• 좋아요/싫어요
  • 댓글에도 동일하게 적용
• 정렬 기준
  • 작성 시간순(오래된/최신 순)

3.1.3 게시판(Bulletin Board) 관리

• 게시판 생성/편집/삭제
  • 관리자 혹은 특정 권한 보유자
• 게시판 설정 항목
  • 게시판 이름, 소개 문구, 공개/비공개, 접근 권한
• 개인 게시판
  • 사용자별 독립 게시판 생성 가능(옵션)
  • 소유자(게시판 주인)가 관리

3.1.4 계정/회원 관리

• 회원가입
  • 필수: 이름, 닉네임, 이메일, 비밀번호
• 닉네임 정책
  • 중복 허용 여부, 특수문자 사용 범위, 변경 주기
• 로그인/로그아웃
  • 이메일 + 비밀번호
  • (옵션) 3rd Party(OAuth)
• 회원탈퇴
  • 즉시 탈퇴 vs 유예 기간
  • 탈퇴 시 게시글/댓글 닉네임 “탈퇴회원” 등으로 변환
  • 필요 데이터(로그, 통계)는 보존, 개인정보는 삭제

3.1.5 알림(Notification) (선택/추후 고려)

• 알림 조건
  • 내 게시글에 댓글, 좋아요/싫어요
• 알림 채널
  • 앱 푸시, 이메일, 웹 알림 등

3.1.6 운영/관리 기능

• 관리자 권한
  • 회원 목록, 게시글 목록, 통계 페이지 접근
  • 게시글/댓글 삭제, 사용자 제재(차단)
• 신고/차단 시스템
  • 게시글/댓글에 대한 신고 기능
  • 일정 횟수 이상 신고 시 자동 블라인드 등

3.1.7 로깅/통계

• 로그
  • 사용자 로그인/로그아웃, 게시글/댓글 CRUD
• 통계
  • 일/주/월 방문자 수, 신규 가입자 수
  • 게시글/댓글 수, 좋아요/싫어요 수

---

3.2 비기능 요구사항

1. 성능
   • 동시 접속자 수 목표, 서버 스펙, 응답 시간 목표
   • DB(예: RDBMS/NoSQL) 설계
2. 보안
   • 비밀번호 암호화(BCrypt 등)
   • 인증(JWT/세션), HTTPS 적용
   • 웹 보안(CSRF, XSS 등)
   • 3rd Party 로그인 시 OAuth 프로토콜 준수
3. 확장성
   • 게시판이 늘어날 때 최소한의 구조 변경
   • 트래픽 증가 시 수평 확장 고려(로드 밸런싱, 서버 증설)
4. 가용성
   • 장애 발생 시 대응(백업/복원, 이중화 등)
5. 유지보수성
   • 코드 구조 모듈화(Controller, Service, Repository 등)
   • CI/CD 파이프라인 구축
6. UI/UX
   • 모바일 퍼스트 디자인
   • 반응형(옵션)
   • 사용자 친화적 화면 플로우

---

3.3 사용자 플로우 예시

1. 회원가입
   1. 이름, 닉네임, 이메일, 비밀번호 입력
   2. (옵션) 이메일/휴대폰 인증
   3. 가입 완료
2. 로그인
   1. 이메일, 비밀번호 입력
   2. JWT 세션(토큰) 발급
   3. 대시보드/홈 화면 이동
3. 게시글 작성
   1. 원하는 게시판(또는 내 게시판) 선택
   2. 글 제목(옵션), 본문(필수) 작성
   3. 등록 및 DB 저장
4. 댓글 작성
   1. 게시글 상세 진입
   2. 댓글 작성 후 등록
   3. 댓글 목록 갱신
5. 좋아요/싫어요
   1. 글/댓글에 버튼 클릭
   2. 중복 클릭 방지(이미 클릭 시 해제)
6. 회원탈퇴
   1. 마이페이지 -> 계정 설정 -> 탈퇴
   2. 탈퇴 이유, 비밀번호 재확인, 데이터 삭제 동의
   3. 탈퇴 처리, 닉네임 “탈퇴회원” 등으로 변경

---

3.4 개발/아키텍처 고려사항

1. 백엔드 스택
   • Spring Boot / Node.js / Django 등
   • 인증 방식(JWT, 세션), 보안 적용(OAuth2, HTTPS)
   • DB(RDB + Redis Cache 등)
2. 프론트엔드 스택
   • 모바일 우선 프레임워크(React Native, Flutter 등) 혹은 반응형 웹
   • React/Vue/Angular 선택 가능
3. 호스팅/배포
   • 클라우드(IaaS/PaaS) 활용, 자동 스케일링, 로드밸런싱
   • SSL 인증서(HTTPS)
4. 테스트/CI-CD
   • 단위/통합/E2E 테스트
   • Git 브랜치 전략(feature, develop, main 등)
   • Jenkins/Github Actions 등 CI/CD 파이프라인 구축

---

3.5 정책/운영 고려사항

1. 약관 및 개인정보 처리방침
   • 정보통신망법, 개인정보보호법 준수
   • 수집 항목, 보유 기간 명시
2. 콘텐츠 관리 정책
   • 유해 게시물, 스팸, 저작권 침해, 명예훼손 등 처리 기준
   • 신고 절차
3. 모더레이션
   • 게시글/댓글 삭제, 사용자 정지, 로그 기록
4. 회원탈퇴/데이터 삭제 정책
   • 즉시 삭제 vs 유예 기간
   • 커뮤니티 기여 기록(게시글/댓글)은 닉네임만 비식별화 처리, 개인정보는 삭제

---

3.6 일정 및 마일스톤 (예시)

1. 요구사항 정의: 2주
2. UI/UX 설계: 3주
3. 아키텍처 & DB 설계: 2주
4. 핵심 기능 개발(글/댓글/좋아요): 4주
5. 계정/회원 관리(가입/로그인/탈퇴): 2주
6. 게시판 관리: 2주
7. 테스트 & 버그 수정: 3주
8. 알림 기능 / 기타 기능 개발: 2주 (옵션)
9. 배포 & 운영: 이후 지속

---

4. 결론

• 핵심 포인트:
  • 텍스트 기반, 1 Depth 댓글, 좋아요/싫어요 기능, 모바일 중심 UI, 동적 게시판 관리
• 추가 고려:
  • 개인정보 보호, 닉네임 관리 정책, 운영정책(불법/유해 게시물), 알림 기능 등
• 비기능 요구:
  • 성능, 보안, 확장성, 유지보수성, 서비스 운영 정책

지속적으로 PRD를 업데이트하며 이해관계자 피드백을 반영해야 하며, 세부 화면 설계, REST API 스펙, DB 스키마, 운영 정책 등을 명확히 수립한 뒤 개발하는 것이 바람직하다.

[chohanjoo]

다음주 Action Item

FE : 보일러플레이트 정리
BE : 게시판/댓글 에 대한 ERD
기획 : 화면 UI 구성

[chohanjoo]

ERD 개요

• user: 회원 정보 테이블
• board: 게시판 정보 테이블
• post: 게시글 테이블
• comment: 댓글(대댓글 포함) 테이블

┌────────────┐          ┌─────────────┐
│    user    │ 1     N  │    board     │
└────────────┘          └─────────────┘
      1  \                   1  \
         \                     \
          \  N                       ┌────────────┐
           \------------------------>│    post    │
                                     └────────────┘
                                            1
                                            |
                                            | N
                                     ┌──────────────┐
                                     │   comment    │
                                     └──────────────┘
                                     (자기 자신 참조를 통해 2뎁스 대댓글)

• user (1) - (N) board: 한 유저는 여러 게시판을 만들 수 있음(관리자/특정 권한자)
• user (1) - (N) post: 한 유저가 여러 게시글을 작성
• board (1) - (N) post: 한 게시판에는 여러 게시글 존재
• post (1) - (N) comment: 한 게시글에는 여러 댓글 존재
• comment는 parent_id를 통해 자기 자신(comment.id)을 참조함으로써 2 Depth 대댓글까지 가능하도록 설계

CREATE TABLE `user` (
  `id` INT AUTO_INCREMENT PRIMARY KEY,
  `name` VARCHAR(50) NOT NULL,
  `nickname` VARCHAR(50) NOT NULL UNIQUE,
  `email` VARCHAR(100) NOT NULL UNIQUE,
  `password` VARCHAR(255) NOT NULL,
  `phone_number` VARCHAR(20),
  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

CREATE TABLE `board` (
  `id` INT AUTO_INCREMENT PRIMARY KEY,
  `name` VARCHAR(100) NOT NULL,
  `description` VARCHAR(255),
  `created_by` INT NOT NULL,
  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  CONSTRAINT `fk_board_user`
    FOREIGN KEY (`created_by`) REFERENCES `user`(`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE
);

CREATE TABLE `post` (
  `id` INT AUTO_INCREMENT PRIMARY KEY,
  `board_id` INT NOT NULL,
  `user_id` INT NOT NULL,
  `content` TEXT NOT NULL,  -- 텍스트 최대 5000자 (애플리케이션 레벨에서 길이 제한 권장)
  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  CONSTRAINT `fk_post_board`
    FOREIGN KEY (`board_id`) REFERENCES `board`(`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_post_user`
    FOREIGN KEY (`user_id`) REFERENCES `user`(`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE
);

CREATE TABLE `comment` (
  `id` INT AUTO_INCREMENT PRIMARY KEY,
  `post_id` INT NOT NULL,
  `user_id` INT NOT NULL,
  `parent_id` INT NULL,
  `content` TEXT NOT NULL,
  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  CONSTRAINT `fk_comment_post`
    FOREIGN KEY (`post_id`) REFERENCES `post`(`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_comment_user`
    FOREIGN KEY (`user_id`) REFERENCES `user`(`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_comment_parent`
    FOREIGN KEY (`parent_id`) REFERENCES `comment`(`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE
);

parent_id: 대댓글(2 Depth)을 위한 자기참조 컬럼

• NULL이면 일반 댓글, 값이 있으면 해당 id의 댓글에 대한 대댓글
• DB 스키마 레벨에서 제한하기 어려우므로, 애플리케이션 로직에서 parent_id가 이미 다른 댓글의 parent_id를 갖고 있으면 추가 대댓글을 작성 불가하도록 제한하는 방식을 사용

추가 고려사항

1. 닉네임 식별 불가 처리:
   • 회원 탈퇴 시 nickname 필드를 변경( ex. 탈퇴회원xxxx )하거나, 별도의 is_active 플래그를 두고 탈퇴 회원임을 표시하는 방법을 사용할 수 있습니다.
2. 게시글 삭제 여부:
   • 요구사항상 “작성된 게시글은 삭제하지 않는다”는 방침이므로, 유저가 탈퇴하더라도 post.user_id를 그대로 두거나 ‘탈퇴회원’ 등으로 닉네임만 바꾸는 방식을 적용할 수 있습니다.
3. 권한(Access Level) 확장:
   • 게시판별 접근 권한 로직이 복잡해질 경우, board_access(board와 user를 매핑) 테이블을 별도로 두어 권한을 부여할 수 있습니다.
4. 인덱스(Index):
   • 데이터 규모가 커지면 board_id, user_id, post_id 등에 대한 인덱스를 생성하여 조회 성능을 개선해야 합니다.
5. 데이터 무결성:
   • 외래키(FOREIGN KEY)로 테이블 간 관계를 맺어, 관련된 엔티티가 삭제될 때 어떻게 처리할지(ON DELETE CASCADE 등) 정책을 설정합니다.
6. 글자수 제한:
   • MySQL은 TEXT 타입에서 길이 제한을 엄격히 강제하기 어렵습니다.
   • 실제 애플리케이션 서비스에서는 **서버단(또는 DB 트리거)**에서 글자수를 제한하거나, 프론트엔드에서 입력 제한을 적용하는 것을 권장합니다.

[chohanjoo]

FE/BE 모두 cursor 로 개발 시작

user 는 무시, post 만 CRUD 개발 -> FE 랑 같이 개발해서 연동

스터디는 1달에 1번으로 일정 변경 -> 다음 스터디는 7월 2일, 개발 완료되는대로 카톡으로 공유