[개발일지][1인 프로젝트] 2일차 개발일지

2일차는 1일차에 기획한 웹 애플리케이션(12:12 오프라인 릴레이 소개팅 이벤트)의 핵심 명세 작업에 대해 완료했다.

기획에서 나온 서비스를 실제 개발 가능한 단위로 나누고 DB 구조/API 흐름/화면 흐름/라운드 운영 방식/실시간 상태 반영 방식까지 정리했다.

Issue : 기존 DB를 Docker에 올려 진행하려 했었는데, windows에 docker를 설치하는 과정에서 docker desktop의 Linux Engine 실행 문제로 인해 DB는 로컬 개발 실행 방식으로 변경했다.(다양한 방법의 troubleshooting을 진행했으나.. 해결 되지 않았고 PostgreSQL단일 DB로 갈것이고 1인 개발이다 보니, 당장 필요가 없다 판단해 넘어가기로 했다.)

 

<명세 작업>

1. 프로젝트 방향 :

  기획 단계에서 정한 것과 동일하게 오프라인 이벤트 운영에 발생될 수 있는 문제를 줄이기 위한 운영 보조 웹 애플리케이션으로 확정.

핵심 목적 :

• 현장 혼선 방지
• 체계적이고 안정적인 현장 운영을 통한 참가자 UX 만족
• 매칭 품질 향상
• 운영자 데이터 확보

즉, 행사 현장에서 동선, 회차, 좌석, 평가, 매칭 결과, 안전장치까지 운영을 매끄럽게 만들기 위한 도구로 행사 종료 시에는 참가자에게 공정하고 빠른 결과를 제공하고, 운영자 입장에서는 이벤트가 꼬이지 않도록 현장을 통제할 수 있어야 한다.

 

2. 사용자 역할 정리 :

  참가자와 운영자를 분리해서 기능을 정의. 참가자는 이벤트 신청, 자기소개서 작성 및 제출, 체크인, 현재/과거 페어링 상대 공개용 자기소개서 열람, 라운드 확인 및 평가 입력, 최종 선택, 결과 확인 역할.

  운영자는 참가자 승인 관리, 체크인 현황 확인, 라운드 진행, 좌석 및 페어링 관리, 공지 발송, 매칭 결과 집계, 예외 상황 대응 역할.

=> 현장 스태프 역할도 초기 명세에 반영해 별도로 분리하려 했으나, 구상한 구조 상 체크인은 공통 QR로 자동 처리되는 방식이기에 스태프의 역할은 필요하지 않다고 판단, 하지만 현장 안내 및 예외 상황 대응, 좌석 안내, QR 인식 실패 시 대응 등의 보조 역할이 필요할 수 있기에 향후 운영 구조 피드백을 받아 필요하다 판단되면 권한을 세분화하는 방향으로 구현 예정  

 

3. DB 설계 :

  users / event_participants를 분리하는 구조로 설계. users는 회원 계정 자체를 의미하는 것이고 event_participants는 특정 이벤트에 참가하는 참가자 상태를 관리. 이를 통해 한명의 user가 여러개의 이벤트에 참여가 가능하고 이벤트별로 승인 상태, 체크인 상태, 좌석, 평가, 매칭 결과 등을 독립적으로 관리할 수 있도록 함.

  자기소개서는 사용자 공통 프로필이 아닌 각 이벤트 별 참가 데이터에 대한 종속된 정보로 정리함(같은 사용자가 다른 새 이벤트에 참여할 경우 자기소개서를 자동으로 재사용하지 않고 새 이벤트 기준으로 새로 제출 해야 함)

 

4. 인증 방식 결정 :

  JWT Bearer 인증 방식을 사용, default login은 소셜 로그인으로 잡았지만, 소셜 로그인이 어려운 사용자들을 위해 수동 회원가입/로그인을 포함하기로 결정.(비밀번호 찾기 및 재설정 또한 MVP 범위에 포함시킴)

 

5. 운영자 권한 구조 결정 :

  운영자 전용 테이블을 만들지 않고 users에 운영자 권한을 부여하고 이벤트별 운영자가 관리하는 방식으로 설계.(운영자 초대 및 권한 부여, 권한 회수 API도 MVP 범위에 포함시킴)

 

6. API 명세 :

  회원가입, 로그인, 비밀번호 재설정, 이벤트 신청, 자기소개서 저장 및 제출, 체크인, 라운드 진행, 평가 제출, 최종 선택, 운영자 관리, 공지, 매칭 결과 공개 등의 주요 API 흐름 정리 완료

 

7. QR 체크인 방식 결정 :

  오프라인 이벤트는 공통 QR을 통해 로그인했으며 해당 이벤트 참여에 승인된 참가자가 체크인을 할 수 있는 방식으로 결정, 이를 통해 운영자는 누가 실제로 이벤트장에 도착했는지 체크인 현황을 통해 확인이 가능

  기본 룰은 공통 QR을 통한 참가자 자동 체크인 이지만, QR인식 실패 / 로그인 이슈 / 네트워크 이슈 / 브라우저 이슈등 예외 상황 대응을 위해 운영자 전용 수동 체크인 기능을 추가하는 것이 적절함.

=> 수동 체크인 기능은 운영자 전용 기능이고 본인 확인 절차가 꼭 필요, 사유 기록 및 자동 체크인과 구분되게 이력을 관리하는 게 추후 운영 편리하다 판단.  

 

8. 라운드 평가 정책 결정 :

  각 라운드가 종료가 되었을 때, 페어링 되었던 상대방의 인상을 까먹지 않도록 빠른 시간내에 간단하게 바로 작성할 수 있게 하고 최초 제출 후 잠기는 방식으로 정함. 다만 실수 혹은 운영상 수정이 필요한 경우가 있기에 운영자가 특정 참가자의 평가 잠금을 풀 수 있는 기능을 포함시킬 예정

 

9. 최종 선택 방식 결정 :

  최종 관심 상대 선택은 단순 3명 선택이 아닌 순위형 3명 선택으로 진행. 이를 통해 1,2,3 순위처럼 선호도를 반영한 매칭 결과 집계가 가능하도록 함.

  또한 이벤트 종료 후 참가자가 최종 선택한 1~3순위 상대에 한해 72시간동안 공개용 자기소개서 요약본을 다시 열람이 가능함(72시간이 지나면 해당 열람 권한은 사라짐)

 

10. 페어링 중복 정책 결정 : 

  같은 이벤트 안에서는 기본적으로 같은 두 사람이 다시 만나지 않도록 설계. 다만 지각, 노쇼, 중도 이탈 등 운영상 예외 상황이 발생할 수 있으므로 운영자가 강제 override로 중복 페어링을 허용이 가능함.

 

11. 라운드 및 페어링 로직 :

  기본 페어링 방식은 한 그룹은 고정 좌석에 머무르고, 다른 그룹이 라운드마다 이동하는 로테이션 방식으로 정리. 이를 통해 참가자는 라운드별로 다른 상대와 만나고, 운영자는 좌석과 이동 흐름을 예측 가능하게 관리가 가능.(추후 자기소개서를 받았을 때, 해당 자기소개서에 맞는 상대방을 우선 매칭하거나 후반 라운드에 매칭하는 복잡한 보조 로직을 확장 시킬 예정)

 

12. 운영자 개입 기능 :

  운영자는 이벤트 중 라운드를 시작, 종료, 일시정지, 재개할 수 있고, 좌석 배치나 페어링을 수동으로 변경이 가능. 노쇼나 지각이 발생했을 때 참가자를 자동 페어링에서 제외하거나 강제로 재배치하는 운영 흐름도 포함시켰음.(추가적으로 노쇼나 지각으로 인한 공석 발생 시, 대기자 명단 순서대로 참여 여부 연락이 갈 수 있는 기능도 명세)

=> 대기자 정책으로는 이벤트 신청자 중 승인 순서를 기준으로 대기자를 각 성별별 3명씩 선정해 대기자 명단에 추가, 공석 발생 시 운영자가 우선순위에 따라 연락을 하도록 할 수 있게 함(방식은 메시지 전송 or 전화), 참여 의사를 밝힌 경우 참가자로 전환하고 좌석 및 페어링에 반영될 수 있게 조치, 운영 혼선을 줄이기 위해 대기자 참가 전환은 이벤트 시작 전이나 1라운드 시작 전까지만 허용하는 방향이 적절하다고 판단.

 

13. 공지 기능 추가 : 

  운영자가 참가자에게 일반 공지와 긴급 공지를 보낼 수 있음. 공지는 목록형, 배너형, 모달형으로 구분하고, 긴급 공지는 참가자 화면에 즉시 표시될 수 있도록 설계.(예약 발송은 MVP에서는 제외시켰음)

 

14. 실시간 반영 처리 :

  Rest API 중심으로 초기 개발을 진행하고 이후 이벤트 진행 상태, 라운드 타이머, 긴급 공지, 좌석 변경, 체크인 현황과 같은 실시간 반영이 필요한 기능은 Socket.io를 통해 확장시킬 예정 (서버리스 배포보다는 작은 환경이더라도 계속 떠 있는 서버 환경이 적합다 판단했기에 초기 구상은 OCI VM 활용을 검토 중)

 

15. 구현 스킬 :

  백엔드는 Nest.js 프레임워크를 사용하고(인증 방식 구현에 용이) 프론트 엔드는 Vite + React, 상태 관리는 React Query, 폼은 React Hook Form + Zod, DB는 PostgreSQL, ORM은 Prisma, 패키지 관리는 pnpm, 프로젝트 구조는 모노레포로 확정

 

16. 자기소개서 :

  운영 측 피드백을 반영 해, 참가자는 이벤트 신청 시 자기소개서를 필수로 작성해야 함(신청 후 참가 확정 전까지는 수정이 가능), 자기소개서 폼은 고정 폼으로 운영할 예정이다.

  다른 이벤트 재 참가 시, 이전 자기소개서는 자동 복사되지 않지만 참가자가 원할경우 이전 제출본을 초안 형태로 불러오기 가능하게 설정 예정(새 이벤트에는 반드시 다시 제출 확정을 해야 함), 운영자는 이전 이벤트 이력 참고가 가능.

  자기소개서 공개 범위로는 운영자는 자기소개서 원본 전체를 열람이 가능하지만 참가자는 타인의 원본 전체를 절대 볼 수 없고 공개 허용 항목만으로 구성된 요약본만 열람이 가능하도록 설계, 참가자 공개 정보 기준은 유출되더라도 치명적인 개인정보가 드러나지 않는 수준의 공개 범위로 제한.

  자기소개서 출력도 운영 측 피드백을 통해 출력이 필요할 수 있는 상황이 있다고 판단해 운영자용 출력물(원본 전체) / 참가자용 출력물(공개용 요약본) 두 형태 모두 출력이 가능하도록 기능을 만들 예정

  자기소개서 화면에 대한 강한 캡쳐 방지 기능은 넣지 않지만 자기소개서 하단에 "상대방 정보는 행사 목적 외 저장/공유 금지" 안내 문구를 제공할 것임 (기술적 차단보다는 민감정보를 숨기고 공개 범위를 최소화하는 것에 중점을 둠) 

  열람 시점 경우 참가자는 이벤트 참가 후 QR로 체크인 이후에 현재 페어링 된 상대의 공개본 열람이 가능하고 라운드 종료가 되면 이벤트 종료시점까지 과거 페어링 상대 공개본을 재열람 할 수 있음, 여기서 전체 참가자 목록은 제공하지 않고 본인이 실제로 만난 상대 목록만 라운드 기반으로 노출할 것임, 이벤트 종료 후에는 본인이 최종 선택한 1~3순위 상대 공개본을 72시간 동안 다시 열람 가능하게 하고 시간이 만료되면 자동 차단되도록 설계

=> 운영측의 피드백을 반영 해 추후 블라인드 소개팅도 진행하기 위해 이벤트 당일 이전 블라인드 열람, 사진 비공개 상태에서의 자기소개서 확인 및 사전 선호 표시, 그에 따른 이벤트 당일 페어링 보조 로직 연결 등 기능 추가를 고려 해 열람 컨텍스트를 분리하는 방향으로 설계했음   

 

17. 회원 탈퇴 및 복구 :

  회원 탈퇴 시, 즉시 사용자는 비활성화 되고 로그인이 차단됨. 또한 서비스 이용 제한 및 신청중이거나 참여 중인 모든 이벤트 참가 상태를 비활성화가 되도록 설계(탈퇴 시점에 진행 중인 모든 이벤트에서 자동 제외 됨).

  복구 정책으로는 탈퇴 후 재 로그인 시, 탈퇴 요청된 회원임을 안내하고 휴대폰 인증과 같은 본인 인증을 통해 계정 복구가 가능하다. 이 때, 복구 되는건 개인정보 및 회원정보로 탈퇴 당시 제외된 이벤트 참가 상태는 복구되지 않게 설정.

  탈퇴 정책 문구 : 

- 회원 탈퇴 요청이 완료되는 즉시 계정은 비활성화되며, 로그인 및 서비스 이용이 제한됩니다. 또한 탈퇴 시점에 신청 중이거나 참여 중인 모든 이벤트의 참가 상태도 함께 비활성화되어 더 이상 해당 이벤트에 참여할 수 없습니다. 탈퇴 요청을 번복하여 계정을 복구하더라도 개인정보 및 회원정보만 복구되며, 탈퇴로 인해 제외된 이벤트 참가 상태는 복구되지 않습니다.

  탈퇴 완료 안내 문구 : 

- 탈퇴 요청이 접수되어 계정이 비활성화되었습니다. 30일 이내에는 본인 인증을 통해 계정 복구가 가능하지만, 탈퇴 시 제외된 이벤트 참가 상태는 복구되지 않습니다.

 

18. 데이터 보관 :

  회원 탈퇴 시, 계정 식별정보는 최대 30일까지 보관할 것이고 이후에는 개인식별정보 전체를 삭제, 자기소개서 원문은 60일을 보관 기간으로 잡음, 일반 이벤트 참가 운영 이력은 최대 6개월로 잡았고 운영 로그 / 신고 / 차단 관련 데이터 경우는 분쟁 대응, 신고 및 차단 이력 확인, 운영 통계, 노쇼 및 지각 기록, 반복 악성 사용자 대응을 위해 1년의 보관 기간을 잡았음.(이 때, 운영 로그와 행동 이력은 남기지만 직접적인 사용자 식별 정보는 분리시키거나 최소화 해 개인 식별 가능성을 줄이는 방향으로 설계할 예정)     

 

Any comments : 명세 작업을 통해 프로젝트의 기능, 운영 흐름을 개발 가능한 수준으로 구체화 시켰는데, 개발 하면서 실시간 피드백을 받아 수정하거나 추가해야 할 기능이 있을 것으로 예상된다. 핵심 기능 관련 내용을 고민할 때에는 이벤트 당일 운영자가 이벤트 진행 중 어떤 문제가 발생될 것이고 참가자는 어떤 화면을 보면 좀 더 매끄러운 진행이 될까라는 고민을 하며 기준을 잡았다.

오랜만의 개발이라 버전도 다 옛날 버전이고 설치해야 할 툴도 많아서 일단 백그라운드부터 세팅 완료 후 명세 기반의 실제 기능 구현을 진행할 것이다.