[260803 25일차] 프로젝트 #6

# 포트폴리오 학습일지

[프로젝트 6일차] 2주차 시작 · 화면 설계
+ 요구사항·ERD 정합성 검토 · Pulse UI 조립

2026.08.03 (월) · 2주차 킥오프(화면 목록·와이어프레임) + 문서 정합성 검토 + 개인 UI 작업(Figma)

📋 오늘 다룬 것들

2주차 첫날. 팀은 화면 목록·와이어프레임·디자인 작업으로 넘어갔고, 협업 규칙(PR 템플릿·Squash and Merge)을 레포에 적용했다. 기획서 기준으로 요구사항 명세서·ERD 정합성을 검토해 모순·누락 항목을 정리했고, 개인적으로는 실시간 피드백 서비스 Pulse의 디자인 토큰부터 화면 조립까지를 Figma로 마무리해 갔다.

2주차 범위

화면 목록와이어프레임디자인

협업 적용

PR 템플릿Squash Merge

문서 검토

요구사항·ERD정합성

FE 역할

3축 재편

내 작업

디자인 토큰컴포넌트화면 조립

미니 프로젝트

코드 학습 도구

🗣 오전 공지 — 2주차 킥오프

1금주 범위화면 목록 / 와이어프레임 / 디자인 작업 + 프론트엔드 작업 분배(팀 R&R 참조)

2PR 템플릿팀원이 공유한 템플릿으로 레포에 적용

3머지 정책Squash and Merge로 확정 — GitHub 관련 설정도 함께 적용

4회의록오전 11:30 회의록 작성해 Notion 업로드 (플러그인으로 자동화)

5Notion 초대새로 만든 E조 페이지에 각자 개인 계정을 게스트로 초대(강사님 포함), 산출물은 "6. 산출물 관리" 섹션으로 이동

오늘/내일까지 결정할 항목
· (오늘) 전원 — 산출물(요구사항 명세서·데이터 모델링)의 "회의에서 결정할 것" 섹션에 의견 남기기
· (내일) FE 담당자 — 프론트엔드 각자 파트 분담 아이디어를 Slack/Notion에 공유

그 외 기타: 한국취업센터 1차 정규 상담이 팀원별 시간대로 배정됨 · AI API 지원 관련은 강사님 확인 후 공유 · 최종 발표 초청 희망 기업 조사(기한 미정).

🧑‍🏫 팀장 멘토링 (13:00~13:30)

1미니 프로젝트2주차 "코드 학습 스터디 도구" 아이디어가 주제에 부합('학습의 큰 범위')한다고 강사님 동의 — Claude 스킬/플러그인으로 구현해도 무방

2교재공유 예정 교재는 아직 검토 단계, 완료되면 공유

3환경 세팅기획서 기반 산출물·규칙을 이번 주 수요일까지 확정하고 GitHub/CLAUDE.md 업데이트

🔀 프론트엔드 역할 분담 재편 — 3축 구조

기존 분담안의 약점을 Claude Code 자문으로 다시 짰다.

구분	구조	문제/개선
기존	한 명이 실제 기능이 없는 공통 작업에 배정	공통만 맡은 사람은 눈에 보이는 기능 성과가 없음
신규	공통 작업을 제외하고 기능 기준 3축으로 분할	모두가 실제 기능을 나눠 맡는 구조

🧐 요구사항 명세서 · ERD 정합성 검토

기획서를 기준으로 요구사항 명세서·ERD에 이상이 없는지 Claude Code로 대조 검토했다. 세 문서의 관계를 이렇게 이해하면 쉽다.

기획서 · 요구사항 명세서 · ERD = 같은 서비스를 점점 자세히 그린 세 장의 그림
· 기획서: "우리 서비스가 무엇을 하는지"의 큰 그림
· 요구사항 명세서: 그 그림을 "화면에서 어떤 순서·조건으로 동작하는지" 규칙으로 풀어쓴 것
· ERD: 그 규칙을 지키려면 DB에 어떤 표(테이블)·칸(컬럼)이 필요한지 그린 것
뒤로 갈수록 앞 내용을 빠짐없이 담고 있어야 한다. 검토는 세 문서를 나란히 놓고 대조해 서로 다르거나 사라진 부분을 찾는 작업이다.

발견한 문제는 세 종류로 나뉜다. 🔴 모순(문서마다 다른 답) → 🟠 누락(앞엔 있는데 뒤에서 사라짐) → 🟡 미확정(규칙은 있으나 DB에 적용하면 앞뒤가 안 맞음) 순으로 우선순위. 이 중 1번·6번이 구현에 가장 직접적 영향을 준다.

분류	항목	핵심 문제
🔴 모순	1. 감정 분석 실패 처리	실패 시 NEU(중립) vs UNKNOWN(판단 불가)이 절마다 다르고, 감정값이 3종 vs 4종으로 엇갈림. ERD는 옛 방식(NEU) 기준 → 진짜 중립 소감과 섞여 감정 비율·정확도 검증이 왜곡됨
🟠 누락	2. 이벤트 수정/삭제 규칙	기획서엔 이벤트 CRUD·삭제 권한이 있는데 요구사항엔 생성·시작/종료까지만. ERD엔 삭제 시 딸린 세션·소감 처리 규칙 없음
🟠 누락	3. 공유 링크·QR 생성 시점	기획서엔 필수인데 요구사항엔 설명 없음 — 생성 시점(생성 즉시/LIVE 전환 시)·저장 여부 미정
🟠 누락	4. 중복 제출 방지	기획서는 "결정 필요"로 표시했으나 요구사항엔 언급 없음. 반면 실시간 조회 절은 "제출 여부 추적"을 이미 전제로 함
🟠 누락	5. 어뷰징 제출 횟수	"IP/브라우저당 분당 N회"의 N이 빈칸 — 구현 시점에 즉흥 결정될 위험
🟠 누락	6. 태깅 버전 기록	taggerVersion을 항상 전송·없으면 거절한다면서, 정작 저장할 칸이 요구사항·ERD 어디에도 없음 → 받고 버려서 이력 추적 불가
🟡 미확정	7. 리포트 미생성 상태	ERD상 리포트 없으면 행 자체가 없는데, 요구사항은 "미생성"을 상태 기본값으로 설명 → 행 선생성 vs 버튼 시 생성 결정 필요
🟡 미확정	8. 세션 삭제 조건 충돌	"소감 없을 때만 세션 삭제" 규칙 + 소감은 소프트 삭제 → 한 번이라도 제출됐다 지워진 세션은 영영 못 지울 수 있음

배운 점 — 같은 서비스를 그린 문서인데도 절이 늘어나고 시점이 달라지면 조용히 어긋난다. 특히 "실패했을 때 어떤 값으로 저장하나", "이 데이터를 어디에 남기나" 같은 예외·저장 규칙이 문서 사이에서 가장 잘 사라진다. 구현 전에 세 문서를 대조하는 것만으로 나중의 재작업을 크게 줄일 수 있다.

🎨 내가 한 일 — Pulse: 디자인 토큰에서 화면 조립까지

실시간 이벤트 피드백 서비스 Pulse의 UI 작업. Foundations(색·타이포·간격 토큰) 등록을 끝낸 시점부터 컴포넌트를 만들고 화면을 조립하기까지의 과정과, 그 사이 내린 판단들을 정리했다.

1. 시작점의 착각 — "컴포넌트가 너무 적은데?"

토큰 등록 후 컴포넌트를 만들기 시작했을 때, 이전 프로젝트(Button·Chip·Modal·Toast… 수십 개)와 비교하며 다섯 개뿐이라 불안했다. 결론은 적은 게 아니라 순서가 다른 것이었다. 컴포넌트는 화면을 만들기 전에 다 예측해 채우는 게 아니라, 화면을 조립하다 "어, 이거 또 나오네" 싶을 때 뽑아 올리는 게 정상 흐름이다.

기준 — 지금 만들 화면 하나에 필요한 것만 먼저 만든다. 참가자 제출 화면 기준으로 보니 Chip은 있는데 정작 Textarea가 없었고, 감정 배지는 대시보드용이라 이 화면엔 안 쓰였다. "많고 적음"이 아니라 다음 화면에 필요한가가 판단 기준. 조립하며 Header·Banner·Hint·Toast·Stat·Thermometer·FeedItem·Alert·Logo 등이 그때그때 추가됐다.

2. 만든 컴포넌트

컴포넌트	형태	비고
Button	H 52/48/36, radius 8	primary / secondary / disabled
Chip	H 32, radius 999	default / selected
Badge	H 24, radius 999	positive / neutral / negative / toxic / none
Field/Input	H 48, radius 8	placeholder 속성
Field/Textarea	H 96, radius 8	소감·설명 입력
Header/Mobile · Desktop	H 56 / 64	로고 / 로고+계정 슬롯
Banner · Toast	padding 14/12 · 16/12	상태 배너 / 짧은 알림
Stat · FeedItem	padding 16/14 · 14/12	label+value / normal·flagged
Alert	W 360, padding 24	title+description
Logo/Lockup	Hug	마크 + 워드마크

토큰 고정값 — radius: 버튼·입력·박스 8 / 카드 12 / 칩·배지·온도계 999. 간격: 라벨↔요소 4, 칩·버튼 8, 카드 12, 폼 필드 16, 섹션 24, 큰 블록 32. 컨트롤 높이: 헤더 56·64, 입력 48, 버튼 52·48·36, 칩 32, 배지 24. 그리드: 모바일 393(4컬럼·마진20·거터16), 데스크톱 1440(12컬럼·마진80·거터24).

3. 완성한 화면

대상	화면
참가자 (모바일 393)	소감 제출 /e/{code} · 종료된 이벤트 · 실시간 반응 /live · 공개 리포트 /report
주최자 (데스크톱 1440)	로그인/회원가입 · 이벤트 목록 /dashboard · 이벤트 편집(기본/세션 추가·삭제 확인/이벤트 삭제 확인) · 실시간 대시보드(LIVE/QR 모달/복사 토스트/종료 확인) · 대시보드 ENDED(요약 전/생성 중/완료)

4. 하면서 내린 판단들

리포트는 모바일 우선 + SSR — 처음엔 데스크톱으로 그렸지만, 참가자 "종료된 이벤트" 화면에 "결과 리포트 보기" 버튼이 있어 되돌렸다. 리포트는 주최자 전용이 아니라 로그인 없이 열리는 공개 페이지라 모바일 기준. 또한 이 프로젝트에서 SSR이 실제로 값하는 유일한 화면이다(대시보드=CSR, 제출=단순). SEO·OG·빠른 첫 로드가 의미 있는 건 공유되는 리포트뿐.

카드 클릭 → 상태별로 다른 곳으로. 이벤트 목록에 "수정" 버튼을 따로 두지 않고 카드 전체를 클릭 가능하게 해 상태별로 목적지를 나눴다.

상태	이동 화면	이유
DRAFT	이벤트 편집	아직 시작 전이니 설정하러
LIVE	실시간 대시보드	진행 중이니 모니터링하러
ENDED	공개 리포트	끝났으니 결과 보러

클릭 힌트로 카드 오른쪽 끝에 화살표만 붙였다(hover만으로는 알기 어려움). 덕분에 DRAFT 대시보드 화면 자체를 없앨 수 있었다 — DRAFT 카드는 편집 화면으로 가므로 그 화면에 들어올 경로가 없어서.

위험도에 따라 피드백 방식을 나눔.

액션	방식	이유
세션 수정	인라인 입력행	되돌릴 수 있음
링크 복사	토스트	알림만 필요
세션 삭제	Alert	되돌릴 수 없음
이벤트 삭제	Alert(문구 더 무겁게)	소감·리포트까지 사라짐
이벤트 종료	Alert(버튼 빨강 아님)	상태 변경이지 파괴 아님
요약 생성	확인 없음 + 캡션	실패해도 다시 누르면 됨

빨강은 최종 확정 순간에만 — 삭제 버튼 위계를 두 단계로. 편집 화면의 "삭제"는 secondary(흰 배경)+빨간 글자로 왼쪽 끝에, Alert 안의 "삭제"만 primary+빨간 배경. 빨간 채움 버튼은 시선을 가장 먼저 끄는데, 편집 화면의 주요 액션은 "저장/시작"이지 삭제가 아니므로 삭제를 강조하면 위계가 뒤집힌다.

세션 추가는 모달 대신 인라인 — 세션은 필드가 제목 하나뿐이라 모달을 쓰면 Modal 컴포넌트가 더 필요. "+ 세션 추가"를 누르면 그 자리가 입력 필드+"확인" 버튼으로 바뀐다. 버튼 라벨을 "추가"가 아니라 "확인"으로 한 건 수정 때도 같은 UI를 재사용하려고 — 추가는 빈 필드, 수정은 기존 제목이 채워진 필드, 그것만 다르다.

요약 생성은 자동이 아니라 수동 — 종료 시 자동 생성도 가능했지만 주최자가 버튼을 눌러야 생성되게 했다. LLM 무료 티어 레이트리밋 때문에 종료마다 자동 호출되면 발표날 한도에 걸릴 수 있어서. 상태는 LIVE(disabled)/ENDED 요약 전(활성)/생성 중(disabled)/완료(요약 카드) 네 개로. "생성 시 공개 링크가 열려요" 캡션은 실수로 참가자 소감이 공개되는 걸 막으려고 남겼다.

워드클라우드는 Figma와 코드가 다르다 — Figma에선 단어를 Absolute로 흩뜨려 회전을 줘야 자연스럽지만, 실제 데이터는 개수·빈도가 매번 달라 좌표를 미리 못 잡는다. 구현은 두 갈래: ① 태그 클라우드(flex-wrap + 폰트 크기만 빈도 비례, CSS만으로) ② 진짜 패킹(d3-cloud로 겹침 방지·나선 배치). 시안 느낌은 1번으로 충분하고, 2번은 리사이즈·SSR·번들 크기가 붙어 MVP엔 과해서 미뤘다.

5. Figma 삽질 기록

같은 오류를 여러 번 반복했는데 원인은 대부분 두 가지로 수렴했다.

① Fill 옵션이 안 보인다 — Fill은 부모가 오토레이아웃일 때만 나타난다. 컴포넌트 원본은 부모가 없으니 안 뜬다 → 원본은 폭을 숫자로 고정하고, 화면에 인스턴스로 배치할 때 Fill로 바꾼다. 부모가 Hug면 자식만 Fill로 걸어도 안 늘어난다(부모부터 Fill).

② 요소가 엉뚱한 데 있다 — Absolute position이 켜져 있으면 오토레이아웃 흐름에서 빠져 좌표가 제멋대로가 된다(좌표가 마이너스거나 X/Y 직접 입력 가능하면 켜진 상태). 반대로 딤 배경처럼 화면 전체를 덮는 요소는 켜야 한다.

증상	원인 / 해결
요소가 안 보임	Opacity가 0%
라벨까지 가운데로 밀림	카드 전체에 중앙 정렬 → 가운데 정렬할 요소만 Fill 프레임으로 감싸기
텍스트 정렬이 안 먹음	텍스트가 Hug라 여백 없음 → 부모 프레임 정렬 변경
벡터 아이콘이 안 커짐	일반 리사이즈로는 패스가 안 바뀜 → Scale 툴(K)
체크 표시 색이 안 바뀜	✔️는 이모지 → ✓(U+2713) 또는 SVG
도넛 조각이 세로로 쌓임	오토레이아웃 안에선 Align이 안 먹음 → 밖에서 겹치고 그룹으로 묶기
variant 충돌 경고	값 이름 겹침 → type=primary 형식으로 각각 다르게
텍스트 속성이 안 만들어짐	컴포넌트화가 먼저, 속성 연결은 그다음

Ellipse Arc 함정 — Sweep은 각도가 아니라 퍼센트다. 58%를 넣으려고 208.8(=360×0.58)을 입력했다 한참 헤맸다. 그냥 58이 맞다. Ratio(도넛 구멍)는 조각 세 개 모두 같은 값이어야 구멍이 안 어긋난다.

6. 토큰을 정해놓고도 안 지키게 되는 순간

작업 중반에 v2 HTML 목업 값을 그대로 옮기다 토큰에 없는 숫자를 심었다(상하 간격 18/20/24 제각각, 버튼 높이 44, 모더레이션 버튼 32). v2 목업은 토큰을 정하기 전 초안이라 값이 서로 안 맞았는데, 그걸 정답처럼 참조한 게 문제였다.

교훈 — 기준은 나중에 등록한 토큰 쪽. 간격은 전부 24, 버튼은 48·36으로 다시 통일했다. 시안이 여러 버전일 때 어느 쪽이 기준인지 먼저 정해두지 않으면 이런 일이 생긴다.

7. 남은 일

1Prototype카드 상태별 이동 경로를 실제 클릭으로 확인 가능하게 연결

2데이터 모델이벤트 날짜 필드 추가 여부 결정(현재 createdAt만 있음)

3컴포넌트 정리Section으로 묶어 이름표 노출

4개발 착수화면 완성 후 Contract-First 원칙에 따라 API 명세부터

✍️ 마치며

2주차 첫날은 "정리하고 넘어가는" 날이었다. 협업 규칙을 레포에 붙였고, 문서 세 장을 대조해 어긋난 부분을 8건 찾아냈다. 특히 "실패했을 때 어떤 값으로 저장하나" 같은 예외 규칙이 문서 사이에서 가장 잘 사라진다는 걸 배웠다. 개인 작업에서는 컴포넌트는 화면을 조립하며 뽑는 것, 빨강은 최종 확정에만, 요약은 레이트리밋 때문에 수동으로 같은 판단들이 남았다. 화면을 다 완성하면 그다음은 Contract-First로 API 명세부터다.

🏷️ 포트폴리오  |  화면 설계  |  요구사항·ERD 정합성  |  Figma  |  디자인 토큰  |  Squash Merge  |  Pulse