[260731 24일차] 프로젝트 #5

# 포트폴리오 학습일지

[프로젝트 5일차] Figma UI · 머지 정책 확정
+ ERD id 타입 결정 · JWT 저장 전략

2026.07.31 (금) · 개인 작업(디자인) + 오전 공지·팀장 멘토링 + 기술 결정(ERD·머지·JWT)

📋 오늘 다룬 것들

1주차 산출물 마무리 구간. 개인적으로는 Figma로 UI 작업을 이어갔고, 팀은 PR 템플릿·머지 정책(Squash)을 확정하고 ERD의 id 타입을 투표로 정했다. 팀장 멘토링에서 주간 미니 프로젝트 주제(2~6주차)와 Notion 워크스페이스 이슈가 공유됐고, 팀원이 학습한 JWT 저장 전략도 정리해 뒀다.

내 작업

Figma UI스크립트

협업 확정

PR 템플릿Squash merge

ERD 결정

id = bigintemail = 로그인 id

멘토링

발표 순서주간 도구 주제

인프라

NeonRender 배포

개념 학습

JWT 저장HttpOnly·CSRF

🎨 내가 한 일 — Figma UI

1UI 작업Figma로 화면 UI 제작 (진행중) — 어제 잡은 디자인 시스템·컴포넌트 기반으로 실제 화면 구성

2스크립트시간이 되면 발표/시연 스크립트까지 작성 예정

🗣 오전 공지 — 산출물·협업 규칙 확정

1일일 Recap팀원 recap을 취합해 Notion 팀 페이지 하단 별도 섹션에서 관리, 매일 오전 10시까지 공유

2PR 템플릿전날 팀원이 올린 pull_request_template.md를 그대로 레포에 적용

3머지 정책Squash vs Rebase → Squash로 확정 (어제 논의에서 Squash로 의견이 모였음)

구분	내용
1주차 산출물(이번 주)	기획서 · 요구사항 명세서 · ERD · API 명세서 초안 + 문서별 필요한 개념/기술 학습
2주차 예고(다음 주)	화면 목록 · 와이어프레임 · 디자인 작업, FE 작업 분배(팀 R&R 참조)

보안 메모 — 오후에 팀스페이스용 공용 Notion 계정 정보가 공유됐다. 자격증명(이메일·비밀번호)은 학습일지에는 남기지 않는다. 공용 계정은 노출되면 팀 전체가 영향을 받으므로 Slack 등 공유 채널에서만 확인하고, 문서·블로그에는 기록하지 않는 게 원칙.

🧑‍🏫 팀장 멘토링 — 발표·주간 도구 주제

팀장 멘토링에서 나온 내용 공유. 우리 팀(E팀)은 1주차 미니 프로젝트 발표 2번째 순서로 정해졌다.

주간 미니 프로젝트 주제

각 도구는 우리 팀 프로젝트 안에 실제로 적용한 결과를 내야 하고, Before/After가 정량 수치로 나오면 좋다.

22주차코드 학습 스터디 도구 (예: "이 도구를 쓰면 파이썬을 쉽게 배울 수 있다")

33주차클린 코드를 위한 도구 (컴파일러/인터프리터 제작 X — 유명 클린코드 규칙을 발췌·적용하는 방식도 무방)

44주차코드 리뷰 도구 (예: PR 리뷰 봇)

55·6주차자율 주제

그 외 멘토링 이슈
① Notion 팀스페이스 — 현재 수강생+강사가 모두 '멤버'라, 무료 블록을 다 쓰면 멤버마다 비용이 청구됨. 해결안은 팀장이 새 워크스페이스를 만들고 기존 페이지를 복제(복제 후에도 무료 블록이 충분한지 확인 필요).
② AI API 지원금 — 성남시 최대 지원 금액을 강사님이 담당자에게 확인 예정.
③ 최종 발표 초청 희망 기업 — 원하는 기업이 있으면 자유롭게 공유(제출 기한 확인 예정).

🗄 기술 결정 — ERD id 타입 & BE 머지 규칙

엔티티를 짜면서 ERD를 다시 점검했다. 테이블 id를 UUID string으로 할지 bigint number로 할지가 쟁점이었다. (ERD에 string으로 적혀 있던 건 Mermaid 기본값이 id string이라 그렇게 나온 것.)

결정 — id는 bigint · 이유: 순차적으로 자동 생성이 가능해 다루기 편함. 투표 결과(Claude 의견 포함) 과반 동의로 확정, ERD의 string도 bigint로 수정. 부가로 로그인 시 email이 id 역할을 하고, userName 필드는 MVP에선 사소해 우선 넘어감(그라운드 룰에 따라 결정).

BE 브랜치 머지 설정

1PR 필수as-is 팀원 1명 승인 필수 → to-be 승인 수 0 (대신 CodeRabbit 리뷰 확인 + CI 통과로 대체)

2CodeRabbit대화(conversation) 전부 resolve 필요

3보호 규칙force push / 브랜치 삭제 금지 (유지)

4비상 탈출구admin 우회 가능은 유지

인프라 쪽은 Neon(PostgreSQL) 연결 + Render 무료 호스팅으로 스캐폴드 배포까지 진행, 엔티티 클래스는 package-by-feature 구조로 작성 중.

📚 개념 정리 — JWT를 어디에 저장할까 (HttpOnly 쿠키 vs 헤더 vs localStorage)

팀원이 JWT 저장 전략을 파고들어 정리해 줬다. 핵심은 "토큰을 어디에 두느냐"가 곧 보안 성격을 결정한다는 것.

저장 방식	서버가 로그인 확인	주요 위험 / 특성
HttpOnly 쿠키 JWT	자동 (브라우저가 알아서 전송)	JS가 못 읽어 XSS 탈취에 강함 · 대신 CSRF 방어 필요
Authorization 헤더 JWT	가능, 단 JS가 매 요청마다 첨부해야 함	새로고침·SSR·미들웨어에서 번거로움 · JS가 토큰을 읽어 XSS 탈취 위험
localStorage + 헤더	가능	XSS에 특히 취약 → 보통 비권장

핵심 정리 — 일반 브라우저 웹 서비스(React/Next/Vue)라면 권장 기본값은 access JWT를 HttpOnly + Secure + SameSite 쿠키에 담고, 별도 CSRF 토큰을 X-CSRF-Token 헤더로 보내는 구성이다. "헤더에 실으면 로그인 상태를 못 판단한다"는 반만 맞는 말 — 서버는 Authorization: Bearer로도 당연히 확인하지만, 브라우저가 그 헤더를 자동으로 붙여주지 않는다는 것이 차이다. 쿠키는 해당 도메인 요청에 자동 전송되므로 서버가 곧바로 인증할 수 있다.

왜 localStorage는 비권장? — localStorage에 JWT를 넣으면 헤더 인증은 되지만, XSS 취약점이 한 번만 있어도 악성 JS가 토큰을 읽어 외부로 빼낼 수 있다. HttpOnly 쿠키는 JS가 읽을 수 없어 이 "토큰 탈취" 위험을 크게 줄인다. 단, 모바일 앱·외부 공개 API·타 도메인 클라이언트가 주 구조라면 Authorization 헤더 방식이 더 자연스러울 수 있다.

Spring Boot / Spring Security 메모 — 원칙은 동일하다. JWT를 쿠키로 보내면 SessionCreationPolicy.STATELESS여도 브라우저가 쿠키를 자동 전송하므로 CSRF 위험이 사라지지 않는다. 따라서 JWT 인증 필터 + CSRF 보호를 함께 적용한다. 관례: 인증 JWT 쿠키는 HttpOnly=true(JS 접근 차단), CSRF 토큰 쿠키(XSRF-TOKEN)만 HttpOnly=false로 두어 SPA가 읽어 X-XSRF-TOKEN 헤더로 옮기게 한다. __Host- 접두사를 쓰려면 Secure·Path=/·Domain 미설정 조건이 필요.

※ 팀원 B는 이 외에 서버 액션·zod도 학습했고, 상세 자료는 jwt_저장_전략.md로 팀에 공유됨.

🧾 주간 미니 프로젝트 발표 — meeting-notes

오늘 팀별로 1주차 미니 프로젝트를 발표했다. 우리 팀이 만든 건 meeting-notes — 회의록과 액션 아이템을 Notion에 자동으로 등록해 주는 Claude Code 슬래시 커맨드 플러그인이다.

항목	내용
프로젝트 기간	2026-07-27(월) ~ 2026-07-30(목)
프로젝트명	meeting-notes (Claude Code 슬래시 커맨드 플러그인)
주제	Notion MCP 연동으로 회의록·액션 아이템을 자동 등록하는 Claude Code 플러그인

사용 기술

1실행 플랫폼Claude Code 플러그인(슬래시 커맨드) — 별도의 서버·프론트엔드 코드는 없음

2외부 연동notion-team MCP 서버를 통한 Notion API 연동

3설정 관리config.json 파일에 팀원 정보를 저장해 관리

🐙 GitHub — github.com/ndopy/meeting-notes-plugin

✍️ 마치며

1주차의 마지막 날답게 "정하고 넘어가는" 결정이 많았다. 머지 정책은 Squash로, ERD의 id는 bigint로 못을 박았고, PR 템플릿까지 레포에 붙였다. 개인적으로는 Figma가 조금씩 손에 익어 실제 화면을 만들기 시작했다. 특히 팀원이 정리해 준 JWT 저장 전략이 인상 깊었다 — "토큰을 어디 두느냐"가 곧 XSS·CSRF 방어 설계로 이어진다는 걸 처음 구체적으로 이해했다. 다음 주 8/3부터 본격 구현이라, 이번 주에 잡아둔 문서·규칙이 그대로 뼈대가 된다.

🏷️ 포트폴리오  |  Figma  |  Squash merge  |  ERD  |  JWT  |  HttpOnly·CSRF  |  Neon·Render