0318 멘토링
Shared on March 18, 2026
팀 프로젝트 회의
개요
본 회의는 백엔드와 프론트엔드 팀이 LLM 프롬프트 설계, API 사양, 서버 아키텍처(서버리스 DB, Redis), UI/UX 및 운영 관련 사항을 논의하고 결정한 내용이다.
참여자 및 역할
| 역할 | 담당자(예시) | 주요 책임 |
|---|---|---|
| 멘토 | - | 전체 방향성 제시, 기술적 검증 |
| 백엔드 | - | API 설계, 서버리스 DB, Redis, 인증, rate‑limit |
| 프론트엔드 | - | UI 구현, API 호출, UX 개선 |
| 프로젝트 매니저 | - | 일정 관리, 결정 사항 문서화 |
정확한 인원 명시는 없으나, 각 팀이 역할을 명확히 나누어 진행.
결정 사항
| 항목 | 결정 내용 | 비고 |
|---|---|---|
| 서버 아키텍처 | Neon 서버리스 DB 사용, Redis 캐시 도입 | 비용 절감, 콜드 스타트 대응 |
| 인증 & Rate‑Limit | 토큰 헤더 기반 인증, 레이트 리밋 적용 | DDoS 방지 |
| 슬러그 처리 | 슬러그는 7일 후 삭제, Redis에 TTL 저장 | 중복 방지, 데이터 보존 |
| Ping 서비스 | 5분마다 Ping 전송으로 서버 절전 방지 | uptime‑robot 사용 |
| 오류 처리 | HTTP 표준 코드 사용, 메시지 커스텀 | 일관성 확보 |
| 타입스크립트 전환 | DTO 클래스로 정의, 인터페이스 활용 | 타입 안정성 강화 |
| API 스펙 | 프론트엔드에 messages 리스트, checkSlug 등 제공 | 미리 정의된 타입 사용 |
| MSA | Scheduler를 별도 서비스로 분리 | 향후 확장성 고려 |
| LLM 프롬프트 | 반복 피드백으로 최적화 진행 | 프롬프트 완성도 향상 |
액션 아이템
| 담당 | 작업 | 마감 |
|---|---|---|
| 백엔드 | - 슬러그 삭제 로직 구현<br>- Redis 캐시 설정<br>- rate‑limit 및 인증 엔드포인트 완성 | 4월 10일 |
| 프론트엔드 | - 메시지 리스트 페이지 구현<br>- Delete 버튼 비활성화 로직<br>- API 호출 예시 코드 작성 | 4월 10일 |
| 전체 | - LLM 프롬프트 테스트 및 개선<br>- Ping 서비스 배포 | 4월 10일 |
| 백엔드 | - 타입스크립트 전환 및 DTO 클래스 작성 | 5월 10일 |
| 프론트엔드 | - API 스펙에 따라 UI 업데이트 | 5월 10일 |
각 아이템은 진행 상황에 따라 추가 조정 가능.
논의 포인트
-
LLM 프롬프트 최적화
- 반복적인 피드백을 통해 원하는 출력 형태를 도출.
- 프롬프트를 정리하고 팀 내 공유.
-
서버리스 vs EC2
- 서버리스는 비용 절감이 장점이지만 콜드 스타트가 단점.
- 필요 시 5분 ping으로 절전 방지.
- 실시간성 필요 시 EC2와 병행 가능.
-
UI/UX 개선
- Delete 버튼 클릭 시 비활성화 → 재시도 가능하도록 구현.
- Rate‑limit 초과 시 사용자에게 명확한 메시지 제공.
-
데이터 보존 정책
- 슬러그와 메시지 데이터는 7일(슬러그) / 30일(기타) 후 자동 삭제.
- Redis에 TTL 설정으로 빠른 정리 가능.
-
오류 코드 표준화
- 4XX/5XX 구분, 커스텀 메시지로 사용자 친화적 제공.
-
타입스크립트 도입
- DTO 클래스를 활용해 타입 안정성 확보.
- 기존 JavaScript 코드와 병행해 점진적 전환.
-
Payload 개념
- API 요청·응답 데이터는 “페이로드”로 정의, 프론트엔드에서 구조화 필요.
-
MSA 설계
- Scheduler를 별도 서비스로 분리해 유지보수 용이성 확보.
마무리
회의에서는 프로젝트 전반에 걸친 기술적 방향과 구현 세부를 확정하였다. 각 팀은 정해진 마감일까지 액션 아이템을 수행하고, 진행 상황을 주기적으로 공유한다. 이번 회의 결과를 바탕으로 팀원들은 보다 명확한 목표와 역할을 인지하고, 프로젝트 완성도를 높이기 위한 협업이 기대된다.