회고
[우테코] 13편 : 오픈미션 7일차
| 서론
안녕하세요 팡일입니다!
오늘은 우아한테크코스 8기 프리코스의 오픈미션 7일차 포스팅입니다. 오늘은 진행한 점들에 대해서 기록하고 공유하려고 합니다!
| 오늘 한 일
1) 기타
기능 명세서 수정하기
2) List 페이지
날짜 정렬 기능 추가
타이틀 검색 기능 추가
개별 또는 전체 삭제 기능 추가
드롭다운 컴포넌트 제작
컴포넌트화 진행
상태 관리와 UI 분리
3) Detail 페이지
삭제 기능 추가
컴포넌트화 진행
공통 상수 도입하여 구조 일관성 확보
상태 관리와 UI 분리
4) 작성 페이지
컴포넌트화 진행
상태 관리와 UI 분리
5) My 페이지
기본 UI 구성
정보 조회 기능 추가
정보 수정 기능 추가
회원 탈퇴 기능 추가
상태 관리와 UI 분리
6) 랜딩 페이지
컴포넌트화 진행
공통 버튼과 공통 레이아웃 기반 구조 도입
7) 로그인/회원가입 페이지
컴포넌트화 진행
재사용 가능한 컴포넌트로 분리하여 사용
레이아웃 구조 일관성 확보
상태 관리와 UI 분리
8) UX 개선
Toast를 사용하여 피드백 표시
prompt/confirm을 커스텀 Comfirm, Prompt를 제작하여 통일된 디자인 사용
폼에서 Enter 키 제출 시, 액션 취할 수 있도록 진행
삭제 전 확인 모달, 삭제 중 로딩 상태, 완료 후 토스트 메세지 표시
모바일 뷰의 구조 개선
중복 Footer 제거 및 레이아웃 구조 통합
| 어려웠던 점
1) 서버리스 함수 도입 과정에서 마주한 복잡성
: 사용자 탈퇴 기능을 구현하면서, 단순히 Firebase Auth 계정만 삭제하는 게 아니라 Firestore의 users 컬렉션과 retrospectives 컬렉션에 저장된 사용자 데이터까지 함께 지워야 했습니다.
이걸 클라이언트에서 직접 처리하기엔 복잡하다고 판단해 Firebase Functions로 자동화를 시도했습니다. 하지만 막상 써보니 생각보다 까다로웠습니다. Auth와 Firestore를 동시에 다루려면 Admin SDK 초기화, 트리거(onDelete) 등록, 비동기 삭제 순서 관리 등 세세한 구성이 필요했는데, 조금만 잘못 연결해도 로그가 찍히지 않거나 함수가 중간에 종료되는 일이 생겼습니다. 게다가 Firebase Functions는 호출 횟수와 실행 시간에 따라 비용이 발생한다는 점도 나중에서야 알게 되었어요.
테스트를 반복하다 보니 실험만으로도 사용량이 빠르게 쌓여 부담스럽게 느껴졌습니다. 결국 실제 배포까지는 가지 못했지만, 이번 시도를 통해 서버리스 구조의 복잡성과 비용 구조, 그리고 백엔드 자동화의 책임 범위를 직접 체감할 수 있었습니다. “서버가 없다”는 말이 단순히 쉬움을 의미하지 않는다는 걸 분명히 느낀 경험이었습니다.
2) Toast 알림 및 Svelte 버전 호환의 골칫거리
: UI 강화를 위해 여러 Toast 라이브러리를 비교하던 중, svelte‑5‑french‑toast 등 Svelte 전용 혹은 SvelteKit 호환 버전이 아닌 패키지를 설치해버려서 빌드가 깨지는 경험을 했습니다.
Svelte의 릴리스 버전마다 내부 API가 조금씩 바뀌고, 특히 컴포넌트 슬롯, 리액티브 선언 방식 등이 달라서 “이 라이브러리는 v3까지만 지원한다” 같은 문구가 적힌 README를 보고 머리를 갸웃거리기도 했습니다.
결국 적합한 버전 탐색, peer-dependency 경고 확인, SvelteKit과의 호환성 확보 등이 생각보다 많은 시간을 잡아먹었고, UI 알림 기능이 안 되면서 사용자에게 피드백이 사라지는 문제도 겪었습니다. 이로 인해 단순히 기능을 추가하는 것이 아니라, 프레임워크 버전과 라이브러리 호환성을 고려하는 것이 얼마나 중요한지 깨달았습니다.
| 배운 점
1) UX 개선은 단순한 기능 추가 이상의 가치
: “커스텀 Prompt, Confirm, Toast”를 적용해보면서, 기능이 제대로 동작하는 것 이상으로 사용자 경험(UX)이 중요하다는 사실을 새삼 깨달았습니다. 브라우저 기본 prompt나 alert를 사용하던 시절에는 “그냥 동작하면 되지”라는 생각이 있었는데, 실제로 커스텀 Modal을 넣고 사용자에게 부드러운 확인 흐름과 피드백을 줄 수 있게 되니 서비스 전체의 품질이 달라졌습니다.
예컨대, 회원 탈퇴 시 브라우저 prompt 대신 PromptModal을 띄우고 비밀번호 입력 UI를 개선하자 사용자 입장에서 두세 단계 흐름 속에서 자신의 행동을 명확히 인지하게 되었고, 피드백 토스트 메시지를 통해 “저장이 완료되었습니다” 같은 안내를 주자 만족도가 올라갔습니다. 코드도 재사용 가능하게 모듈화되니 새로운 기능을 만들 때 모달·토스트 구성 요소를 다시 쓰기만 하면 돼서 개발 속도도 올라갔습니다.
2) 스크립트 자동화와 개발 흐름 개선
: 이번 기간 동안 package.json의 scripts 항목을 살펴보면서, 단순히 npm run dev나 npm run build 정도만 쓰던 이전과 달리 훨씬 다양한 명령어가 있다는 걸 알게 되었습니다. 그동안은 개발 서버를 켜거나 빌드하는 기본적인 명령만 알고 있었는데, 실제로는 개발 효율을 높일 수 있는 여러 스크립트가 존재한다는 걸 새삼 깨달았어요.
npm run check 명령을 통해 Svelte와 TypeScript 오류를 한 번에 검사할 수 있고,
npm run preview 명령을 실행하면 배포 전에 실제 프로덕션 환경에서 페이지가 어떻게 보일지를 미리 확인할 수 있다는 걸 이번에 처음 알게 되었습니다.
이 두 명령어는 단순히 확인용 도구가 아니라, 개발 과정에서 놓치기 쉬운 문제를 사전에 점검해주는 역할을 했습니다. 특히 npm run preview는 실제 Firebase Hosting 환경에서 발생할 수 있는 UI·라우팅 문제를 미리 잡아낼 수 있어 굉장히 유용했습니다.
기능을 만드는 것도 중요하지만, 그 기능이 어떻게 관리되고 실행되는가를 다루는 과정 자체가 개발자로서 한 단계 성장할 수 있는 기회였던 것 같습니다. 결국 이번 경험을 통해 “코드를 짜는 것”에서 “개발 흐름을 설계하는 것”으로 사고가 확장되었고, npm 스크립트라는 작은 도구 안에서도 배울 점이 정말 많다는 걸 느꼈습니다.
3) 스토어 분리를 통해 전역 상태 관리의 본질을 이해하기
: 이번에 store 구조를 actions와 store로 분리하면서, 단순히 값을 저장하는 전역 상태가 아니라 상태와 행동을 명확히 구분하는 설계 방식을 직접 경험할 수 있었습니다.
그동안 전역 상태 관리는 쇼핑몰의 장바구니나 로그인 정보처럼 “여러 페이지에서 공통으로 써야 하는 데이터”에만 필요하다고 생각했는데,
이번 작업을 통해 그 인식이 완전히 바뀌었습니다. 실제로 프로젝트에서는 도메인별(store 단위) 로 상태를 관리하고, 그 안에서 필요한 행동(action)을 모듈화함으로써 각 기능이 독립적으로 유지되면서도 필요한 정보는 자연스럽게 공유되는 구조를 만들 수 있었습니다.
예를 들어 listStore에서는 회고 목록과 필터링 로직을, detailStore에서는 상세 데이터 로딩과 삭제 로직을 담당하도록 분리했더니 코드의 흐름이 훨씬 명확해지고, 수정 시 다른 영역에 영향을 주지 않아 안정성이 높아졌습니다. 이 경험을 통해 전역 상태 관리란 단순히 “공용 데이터 저장소”가 아니라, 도메인 간 경계를 유지하면서 필요한 정보만 공유할 수 있게 하는 설계 도구라는 걸 배웠습니다.
즉, 전역 스토어의 가치는 ‘모두가 같은 상태를 쓰는 것’이 아니라, ‘각 도메인이 필요한 만큼만 공유하도록 구조를 나누는 것’에 있다는 걸 깨달은 배움이었습니다.
| 내일 목표
1) Write 페이지
감정 버튼 기능 추가
임시 저장 기능 추가
2) 고민할 부분
우리 프로젝트에서 단위 테스트는 어떻게?
모니터링 도구 알아보기
QA 요청할 부분 정리하기 (대상 선정, 기간, QA 기록, 진행 방법)
3) Update 페이지
기본 UI 구성
조회 기능 추가
수정 기능 추가
4) 로그인/회원가입 페이지
구글 로그인 아이콘으로 커스텀
5) 작성 페이지
작성 후 Toast로 Alert 대체
6) Detail 페이지
수정 페이지 이동 기능 추가
7) 랜딩 페이지
후킹할만한 포인트 고민하기
8) 리팩토링
코드 개선 필요한 부분 찾고 개선
감정 칩 추가로 인한 변경 사항 고민
| 한 줄 회고
: "서비스 완성을 위해 더 디테일을 신경 쓰고 도전하자"