[오류신고 관리 시스템] DB 설계서 작성하기

지난 글에서는 오류신고 관리 시스템의 요구사항 정의서를 작성했다.

요구사항 정의서를 통해 회원 기능, 사용자 오류신고 기능, 관리자 오류신고 기능, 공통 요구사항을 정리했다면,

이번에는 이 요구사항을 바탕으로 어떤 데이터를 저장해야 하는지 정리해보려고 한다.

 

이번 글에서는 db-schema.md 파일에 작성한 DB 설계서를 기준으로,

오류신고 관리 시스템의 테이블을 어떻게 나누었는지 정리해본다.

---

DB 설계서를 작성한 이유

기능을 구현하기 전에 먼저 생각해야 할 것이 있다.

바로 어떤 데이터를 저장할 것인가이다.

 

오류신고 관리 시스템에서는 단순히 오류신고 제목과 내용만 저장하면 되는 것이 아니다.

다음과 같은 정보도 함께 필요하다.

 

필요 정보

누가 오류신고를 작성했는가?
오류신고의 현재 처리상태는 무엇인가?
관리자가 답변을 등록했는가?
누가 답변을 등록했는가?
언제 등록되고 언제 수정되었는가?

 

이런 기준을 미리 정리하지 않으면, 기능을 구현하다가 컬럼을 계속 추가하거나 테이블 구조를 다시 수정해야 할 수 있다.

그래서 이번 프로젝트에서는 구현 전에 DB 설계서를 먼저 작성했다.

---

1차 개발 범위의 테이블

이번 프로젝트의 1차 개발에서는 테이블을 크게 두 개로 나누었다.

 

테이블명	설명
users	사용자 정보
error_reports	오류신고 정보

 

처음부터 너무 많은 테이블을 만들기보다, 1차 개발에 필요한 핵심 테이블만 먼저 설계했다.

users 테이블은 회원가입, 로그인, 권한 구분을 위해 필요하다.

error_reports 테이블은 사용자가 등록한 오류신고와 관리자의 답변, 처리상태를 저장하기 위해 필요하다.

 

---

테이블 구성도

 

이번 DB 설계서에서는 1차 개발 범위의 테이블을 users, error_reports 두 개로 정리했다. users는 사용자 정보를 저장하고, error_reports는 사용자가 등록한 오류신고 정보를 저장하는 테이블로 설계했다.

---

users 테이블 설계

users 테이블은 사용자 정보를 저장하는 테이블이다.

주요 컬럼은 다음과 같다.

컬럼명	설명
id	사용자 ID
login_id	로그인 아이디
password	암호화된 비밀번호
name	사용자 이름
role	사용자 권한
created_at	가입일시

여기서 가장 중요한 컬럼은 login_id, password, role이다.

 

login_id는 사용자가 로그인할 때 입력하는 아이디다.

로그인 아이디는 중복되면 안 되기 때문에 UNIQUE 제약조건을 두었다.

 

password는 비밀번호를 저장하는 컬럼이다.

비밀번호는 평문으로 저장하면 안 되기 때문에 암호화된 값을 저장하는 것을 기준으로 잡았다.

 

role은 사용자 권한을 저장하는 컬럼이다.

이번 프로젝트에서는 일반 사용자와 관리자를 구분해야 하므로, 권한 정보를 사용자 테이블에 저장하도록 했다.

---

error_reports 테이블 설계

error_reports 테이블은 사용자가 등록한 오류신고 정보를 저장하는 테이블이다.

주요 컬럼은 다음과 같다.

컬럼명	설명
id	오류신고 ID
user_id	작성자 ID
title	제목
content	내용
status	처리상태
answer	관리자 답변
admin_id	답변한 관리자 ID
answered_at	답변일시
created_at	등록일시
updated_at	수정일시

이 테이블에서는 user_id, status, answer, admin_id가 중요하다.

 

user_id는 오류신고를 작성한 사용자를 나타낸다.

일반 사용자는 본인이 작성한 오류신고만 조회할 수 있어야 하므로, 오류신고와 작성자 정보를 연결해야 한다.

 

status는 오류신고의 처리상태를 저장한다.

이번 프로젝트에서는 처리상태를 접수, 확인중, 처리완료, 반려로 나누었다.

 

answer는 관리자가 작성한 답변을 저장한다.

 

admin_id는 답변을 등록한 관리자를 나타낸다.

 

즉, 하나의 오류신고에는 작성자와 답변 관리자가 함께 연결될 수 있다.

---

users와 error_reports의 관계

이번 DB 설계에서 가장 중요하게 본 부분은 users와 error_reports의 관계다.

사용자 한 명은 여러 개의 오류신고를 작성할 수 있다.

따라서 users와 error_reports는 다음 관계를 가진다.

users 1 : N error_reports

 

그리고 error_reports.user_id는 users.id를 참조한다.

그런데 여기서 하나 더 고려할 점이 있다.

관리자도 사용자다.

 

관리자가 오류신고에 답변을 등록하면, 해당 답변을 누가 등록했는지도 저장해야 한다.

그래서 error_reports 테이블에는 admin_id 컬럼도 두었다.

 

admin_id 역시 users.id를 참조한다.

정리하면 다음과 같다.

users.id → error_reports.user_id
users.id → error_reports.admin_id

 

user_id는 오류신고 작성자를 의미하고, admin_id는 답변한 관리자를 의미한다.

같은 users 테이블을 참조하지만, 역할이 서로 다르다.

---

error_reports 테이블은 작성자를 나타내는 user_id와 답변 관리자를 나타내는 admin_id를 통해 users 테이블을 두 번 참조한다.

 

조금 더 간단하게 표현하면 이렇게 만들 수도 있다.

users.id ── 작성자 ──> error_reports.user_id

users.id ── 답변 관리자 ──> error_reports.admin_id

 

이 관계도에서 핵심은 error_reports가 users를 두 번 참조한다는 점이다.

하나는 작성자를 나타내기 위한 참조이고, 다른 하나는 답변한 관리자를 나타내기 위한 참조다.

---

처리상태 컬럼을 둔 이유

오류신고는 단순히 등록만 되는 데이터가 아니다.

등록 이후 관리자가 확인하고, 처리하거나 반려할 수 있다.

그래서 status 컬럼을 두어 오류신고의 현재 상태를 저장하도록 했다.

상태	의미
접수	사용자가 오류신고를 등록한 초기 상태
확인중	관리자가 내용을 확인 중인 상태
처리완료	처리가 완료된 상태
반려	처리 대상이 아니거나 부적절한 신고

처리상태를 컬럼으로 관리하면 목록 화면에서 상태별로 구분해서 보여줄 수 있다.

또한 관리자 화면에서 아직 처리되지 않은 오류신고만 확인하거나, 처리완료된 오류신고를 따로 확인하는 기능으로 확장할 수 있다.

---

인덱스를 고려한 이유

DB 설계서에는 인덱스 고려사항도 함께 정리했다.

처음에는 데이터가 많지 않겠지만, 오류신고가 계속 쌓인다고 가정하면 조회 성능을 고려해야 한다.

특히 다음 컬럼들은 자주 조회될 가능성이 있다.

테이블	컬럼	목적
users	login_id	로그인, 아이디 중복 확인
error_reports	user_id	사용자별 오류신고 목록 조회
error_reports	admin_id	관리자별 답변 이력 조회
error_reports	status	처리상태별 조회
error_reports	created_at	최신순 목록 조회

예를 들어 사용자가 내 오류신고 목록을 조회할 때는 user_id 기준으로 조회하게 된다.

관리자 화면에서는 status나 created_at 기준으로 목록을 조회할 가능성이 높다.

그래서 이런 컬럼들은 인덱스 적용을 검토할 대상으로 정리했다.

---

추후 확장 예정 테이블

1차 개발에서는 users, error_reports 두 개의 테이블만 사용한다.

하지만 기능이 확장되면 추가 테이블이 필요할 수 있다.

예를 들면 다음과 같다.

테이블명	설명
attachments	첨부파일 정보
report_histories	처리상태 변경 이력

첨부파일 기능을 추가하려면 오류신고와 연결되는 첨부파일 테이블이 필요하다.

또한 처리상태 변경 이력을 남기려면 별도의 이력 테이블이 필요할 수 있다.

 

처음부터 모든 테이블을 만들기보다, 1차 개발에서는 핵심 기능에 필요한 테이블만 만들고

이후 기능 확장에 따라 테이블을 추가하는 방향으로 잡았다.

---

정리

이번 글에서는 오류신고 관리 시스템의 DB 설계서를 작성한 내용을 정리했다.

1차 개발 범위에서는 users, error_reports 두 개의 테이블을 사용하기로 했다.

 

users 테이블은 사용자 정보와 권한 정보를 저장하고, error_reports 테이블은 오류신고 내용, 처리상태, 관리자 답변을 저장한다.

특히 error_reports 테이블에서는 user_id와 admin_id를 통해 작성자와 답변한 관리자를 구분하도록 설계했다.

 

이번 DB 설계서를 작성하면서 단순히 컬럼을 나열하는 것보다,

각 컬럼이 어떤 기능을 위해 필요한지 함께 생각하는 것이 중요하다고 느꼈다.

 

다음 글에서는 이 DB 설계와 요구사항을 바탕으로 URL/API 설계를 어떻게 정리했는지 작성해보려고 한다.

 

프로젝트 진행 과정과 관련 문서는 아래 GitHub 저장소에서 확인할 수 있다.

👉 https://github.com/hwangjihwan-dev/error-report-system