[11/25] 프론트–백엔드 1차 회의

[yoorli]

회의 개요

• 날짜: 2025.11.25(화)
• 회의 안건
  • 정기 회의 일정 및 협업 방식 확정
  • API 문서, 배포, 인증 방식 논의
  • 기획 및 디자인 변경 사항 초안 공유 및 추가 기능(채팅) 방향 확인

---

회의 내용 요약

1. 정기 회의
   • 현재 시간 기준으로 주 1회 정기 회의 진행
2. 커뮤니케이션
   • 일반 이슈: GitHub Issue + 멘션
   • 긴급 이슈: Discord DM
3. API 문서
   • 초기: Notion 등 문서 기반 명세
   • 이후: Swagger 제공
4. 인증
   • Access Token + Refresh Token 방식 사용
   • 1차는 응답 바디로 토큰 전달, HttpOnly 쿠키는 추후 검토
   • 시계 오차를 고려한 토큰 만료 유예/조정 로직 적용
5. 배포
   • 프론트: AWS에 배포/도메인 연결 완료, 향후 Vercel 전환 예정
   • 백엔드: 5만 원 지원금 범위 내에서 호스팅 결정 후 공유
6. 도메인 분배
   • 인증/회원·유저 관리, 모임 등으로 분리 후 담당자 배정
7. 기획/디자인
   • 기존 같이 달램 시안은 참고만 하고, 모바일 퍼스트·인스타그램 스타일로 전면 재설계
   • 모임은 세션(인스턴스) 단위, 종료 시 삭제 모델로 진행
8. 채팅 기능
   • MVP 이후 추가 기능으로 검토, 1:1 + 모임 내 텍스트 채팅을 기본 범위로 상정
9. 협업
   • REST API 고정, 기획 변경 시 API 명세 변경 내용을 빠르게 공유
   • 백엔드에 Figma 권한 제공, 디자이너 미팅 시 백엔드 합류 방향으로 조율

---

회의 내용

정기 회의 일정

• 화요일 오후 6시, 주 1회 정기 회의 진행

이슈 발생 시 전달 방식

• GitHub Issue 등록 후 백엔드 담당자 멘션
• 긴급한 사안은 Discord DM 사용

API 문서 관리 방식

• 1차: Notion / Jira 등 협업 툴에 간단한 CRUD API 명세 작성
• 2차: Swagger 문서 제공
• 3차: 시간이 허용되면 별도 API 문서 웹 페이지 제공
• 결론
  • 초기에는 Notion 등 문서 기반으로 기본 응답 형식/엔드포인트 공유 이후 개발 진행 상황에 맞춰 Swagger로 확장

배포/인프라 전략

• 프로젝트 전체 예산 기준으로 AWS 지원금 5만 원 내에서 백엔드 인프라 결정
• 백엔드는 내부 협의 후 선택한 호스팅·배포 전략을 추후 공유

인증/인가 방식 및 토큰 정책

• Access Token + Refresh Token 2가지 토큰 발급으로 진행
  • 토큰 값을 응답 바디로 전달
  • HttpOnly 쿠키 세팅은 추후 논의
• 시계 오차(clock skew) 처리
  • 서버 시간과 클라이언트 시간 차이로 인한 만료 처리 문제 가능성 논의
    • 예: 아주 작은 시간 차이로 로그인 튕김, 사용자 정보 조회 실패 등
  • 방안
    • 토큰 만료 후 일정 시간(예: 30초~1분) 유예 시간 허용
    • 혹은 프론트에서 만료 전(예: 30초 이전)에 미리 토큰 재발급 요청
• 결론
  • 백엔드에서 시계 오차를 고려한 만료 처리 적용

백엔드 작업 영역 분배 방식

• 구분
  • 인증/회원 가입/로그인/유저 정보 관리
  • 모임 관리
• 결론
  • 백엔드 팀 내에서 역할 분배 후, 결정된 구조를 프론트에 공유

기획 및 디자인 변경 전달

• 전달 내용: 디자인 및 일부 기획을 전면 수정
• 새로운 방향
  • 모바일 퍼스트, 웹앱 느낌의 인스타그램 유사 UI
  • 모임 구조 변경
    • 기존: 하나의 모임에 여러 타임슬롯(10–11시, 14–15시 등)을 열고 닫는 구조
    • 변경: 번개 모임처럼 하나의 세션(인스턴스)을 만들고, 종료 시 인스턴스 삭제
  • 모임에는 UUID를 부여하여 알림 기능 등과 연계 계획
  • 기능 구상
    • 모임 생성, 참여 신청
    • 참가 중인 모임 조회
    • 모임 참가자 기반 단체 채팅방(모임 종료 후 입장/채팅 제한)

채팅 기능 도입 여부 및 난이도

• 기본 기능(인증, 모임 등) 완성 후, 추가 기능으로 도입 검토
• 희망 범위
  • 1:1 채팅
  • 모임 내 단체 채팅
  • 이미지 업로드 없이 텍스트 채팅만
• 기술/난이도 논의
  • 단순히 웹소켓 기반으로 러프하게 구현하는 것은 2~3일 내 가능
  • 다만 실제 서비스 수준
    • 트래픽 증가 시 메시지 손실 가능성
    • 메시지 큐, 카프카 등 추가 인프라까지 고려하면 난이도 상승
• 결론
  • 우선은 기본 기능 완성에 집중
  • 채팅은 “필수 최소 구현(텍스트, 1:1 + 모임 채팅)”을 기준으로,
    MVP 이후 일정/리소스를 보고 도입 여부 최종 결정

협업 방식 및 Figma 공유, 회의 구성

• 요청 사항
  • 응답 형식(API 스키마)을 초기 단계에서 명확히 정의
  • 기획 변경으로 명세가 바뀌는 경우, 가능한 한 빠른 공유 필요
• 디자인/기획–백엔드 연계
  • Figma 화면 흐름을 참고해 API 설계를 하고자 함
• 디자이너 회의 참여 방식
  • 현재: 기획 변경/요구사항 재정리 단계라, 프론트–백–디자인이 모두 함께 있을 경우 오히려 혼선 우려
  • 그래서 1차로는 팀별 별도 미팅 진행 중
  • 제안
    • 디자이너 미팅 시간에 백엔드도 합류 가능한지 검토
    • 목요일 제외 평일 18시 이후 가능하므로, 3팀 모두 참여 가능한 시간대 탐색
• 결론
  • 디자이너 미팅 시 백엔드 참여를 최대한 조율하는 방향으로 진행

---

후속 액션

• 변경된 기획/플로우 정리 및 최신 Figma 공유
• MVP 범위와 추가 기능(채팅 등) 구분 명확화
• 다음 정기 회의 일정 캘린더 공유
• 디자이너와의 미팅 일정 및 3자 회의 가능 시간 조율