회고
[우테코] 8편 : 오픈미션 2일차
| 서론
안녕하세요 팡일입니다!
오늘은 우아한테크코스 8기 프리코스의 오픈미션 2일차 포스팅입니다. 오늘은 진행한 점들에 대해서 기록하고 공유하려고 합니다!
| 오늘 한 일
1) 개발
필요한 페이지 구성
기능 명세서 작성
구현할 기능 목록 정리
저장할 데이터 구체화
2) 영상
Svelte 관련 영상 찾아보기
어떤 영상 찾아보면 좋을지 고민하기
| 어려웠던 점
1) 기능 목록 정리 시, 'MVP 범위'를 명확히 정하기 어려웠다.
: 초기 기획 단계에서 가장 많은 시간을 잡아먹은 부분은 바로 ‘어디까지를 MVP로 볼 것인가’였습니다. 구현하고 싶은 부분을 더 구체화하면 할수록, 구현하고 싶은 기능이 많이 생겨나곤 했는데요? 감정 통계 시각화, 주차별 회고 리포트, AI 질문 추천, 친구 간 회고 공유 등처럼 말이죠.
하지만 실제로는 2주라는 짧은 기간 안에 1주차 때 완성 가능한 최소 기능이면서, 2주차 때 확장 가능한 기능을 선택해야 했고, 그 과정이 생각보다 쉽지 않았습니다. ‘이건 꼭 필요하지 않을까?’라는 생각이 들 때마다, 기능을 추가하고 싶은 마음과 일정 사이에서 갈등이 생기곤 했습니다. 특히, 회고 작성과 감정 태그 기능은 서비스의 핵심이었지만, 통계나 피드백 기능은 MVP 범위를 벗어나는지 계속 판단이 흔들리곤 했습니다.
결국 “사용자가 회고를 작성하고 저장할 수 있는 최소한의 흐름”을 기준으로 삼아 기능을 확정했지만, 그 과정에서 ‘가치를 유지하면서도 단순화하는 힘’이 얼마나 중요한지 새삼 느낄 수 있었습니다.
2) 데이터 컬렉션 구조를 결정하는 데 시간이 많이 소요됐다.
: Firebase의 Firestore를 처음부터 만들어보는 것은 처음이었기에, 제작하기 전에 데이터 컬렉션 구조를 어떻게 결정해야 할지 고민이 많이 됐습니다. 학습을 통해서 Firestore의 가장 큰 장점은 스키마가 자유롭다는 점을 알게되었는데, 그만큼 명확한 구조를 직접 정의해야 하는 점이 부담으로 다가온다는 점을 알게 되어, 더 고민이 커져만 갔던 것 같습니다.
특히 회고 내용을 관리하는 컬렉션을 설계하면서, 감정 태그나 질문 데이터를 어떻게 다룰지가 가장 큰 고민이었습니다. 하나의 문서 안에 감정 태그 배열과 질문 텍스트를 함께 넣어두는 단순한 구조를 선택할 것인지, 아니면 컬렉션을 구분하여 답변 단위 수정과 조회를 용이하게 할 것인지에 대해 고민했습니다. 그 결과 현재 MVP 수준에서는 단순한 구조를 선택하고, 이후 리팩토링하면서 개선하는 부분으로 진행하기로 했습니다.
| 배운 점
1) 기능 명세서 작성 시, "필요한 기능만!"
: 기능 명세서를 작성하면서 가장 크게 느낀 점은, ‘모든 아이디어를 다 담는 것보다 진짜 필요한 기능만 남기는 것’이 훨씬 더 어렵다는 것이었습니다. 기능을 하나씩 줄여나가는 과정에서 “이건 나중에 추가해도 괜찮을까?”, “지금 빠지면 서비스의 흐름이 끊기지 않을까?” 같은 불안감이 계속 들었지만, 결국 MVP 단계에서 중요한 것은 '사용자가 최소한의 가치 있는 행동을 문제없이 수행할 수 있는가’였습니다. 즉, 불필요한 기능을 줄이고 핵심 경험에 집중해야 개발 속도와 완성도 모두를 잡을 수 있다는 점을 깨달을 수 있었습니다.
2) Firestore 설계 과정에서도 "필요한 기능만!"
Firestore 구조를 구상하는 단계에서, 처음에는 컬렉션을 세분화하고 관계를 세밀하게 설정하려 했습니다. 하지만 구상만으로도 구조가 너무 복잡해져서, “이대로 구현에 들어가면 오히려 속도가 느려질 것 같다”는 생각이 들었습니다. 아직 실제 개발을 진행하지 않았지만, 초반 설계에서부터 완벽한 구조를 만들려는 욕심이 오히려 발목을 잡을 수 있다는 걸 느꼈습니다.
그래서 “일단 작동 가능한 최소한의 구조로 시작하고, 필요할 때 확장한다”는 원칙을 세웠습니다. 지금 단계에서는 사용자 정보(users)와 회고 데이터(retrospectives) 두 개의 핵심 컬렉션만으로 MVP 기능을 충분히 구현할 수 있다고 판단했습니다. 감정 태그나 질문 관리 기능 등은 이후에 별도의 컬렉션으로 분리해도 늦지 않을 것 같았습니다.
결국 이 과정을 통해, 초기 설계에서 가장 중요한 것은 ‘미래를 예측하는 정교함’이 아니라 ‘지금 바로 실행할 수 있는 단순함’이라는 점을 배우게 되었습니다.
3) 문서화의 중요성
오늘 하루 동안 여러 문서를 작성하면서 느꼈던 점은 문서화의 힘이었습니다. 초반에는 기획서를 작성하면서 정리한 아이디어를 머릿속에만 기억해두고, 기능 명세서나 데이터 설계를 진행하면서 그 내용을 자연스럽게 이어간다고 생각했습니다. 하지만 다음 단계에 들어가 구체화하는 과정속에서 보니, MVP 기획 단계에서 정했던 내용이 일부 누락되거나 일관되지 않은 부분이 여러 곳에서 드러났습니다. 그로 인해 의도했던 흐름이 자꾸 어긋나곤 했습니다.
이 문제를 해결하기 위해 Notion에 별도의 ‘문서 모음’ 공간을 만들었습니다. 기획서, 페이지 구성, 기능 명세서, 데이터 구조 설계 문서를 각각 페이지 단위로 분리하고, 링크를 통해 서로 참조할 수 있도록 연결했습니다. 이렇게 체계를 잡으니, 문서를 작성하는 시간이 조금 더 걸리긴 했지만 대신 아이디어의 누락이 줄고, 팀원 간의 소통과 의사결정 속도도 훨씬 빨라졌습니다.
| 내일 목표
1) 개발
Svelte + Vite 초기 세팅
폴더 구조 설계
Github Repo 생성하기
회고 작성 페이지 뼈대 구현
input, texarea, store 상태 관리 학습
| 한 줄 회고
: 완벽하게 하지 말고, 일단 작은 것부터 시도해보고 더 늘려가보자!!