[우테코] 11편 : 오픈미션 5일차

| 서론

안녕하세요 팡일입니다!

오늘은 우아한테크코스 8기 프리코스의 오픈미션 5일차 포스팅입니다. 오늘은 진행한 점들에 대해서 기록하고 공유하려고 합니다!

| 오늘 한 일

1) Write 페이지

• 회고 작성 페이지 뼈대 구현

• 마크다운 에디터 구현

• 감정 버튼 / 랜덤 질문 표시 기능 구현

2) List 페이지

• 리스트 페이지 뼈대 구현

• 전체 데이터 불러오기 구현

3) Detail 페이지

• 상세 페이지 뼈대 구현

• 데이터 불러오기 구현

4) Firebase

• 프로젝트 생성 후 프로젝트와 연결

• hosting 배포

• Firestore로 DB 생성

• 회고 컬렉션 추가

• 사용자 컬렉션 추가

| 어려웠던 점

1) 어떤 에디터를 사용해야 할까?

: 이번 과정에서 가장 고민이 많았던 부분은 바로 “어떤 마크다운 에디터를 사용해야 할까?”였습니다. 처음에는 단순히 “그냥 입력창에서 마크다운만 작성되면 되겠지”라고 생각했지만, 막상 구현하려고 하니 선택지가 너무 많았습니다.

특히나, mdsvex, svelte-markdown-input, marked 등 다양한 라이브러리를 테스트하면서, 단순히 작동 여부보다 프로젝트의 방향성과 어울리는 도구를 고르는 일이 얼마나 중요한지를 깨달았습니다.

처음 시도한 mdsvex는 Svelte 안에서 .svx 또는 .md 파일을 컴포넌트처럼 불러올 수 있다는 점이 매력적이었습니다. 하지만 사용자가 실시간으로 입력하고 미리보는 “에디터” 형태로는 적합하지 않았습니다. 한마디로 정적 문서를 보여줄 때는 강력했지만, 실시간 반응형 구조에는 한계가 뚜렷했습니다.

이후 선택한 svelte-markdown-input은 그 한계를 정확히 해결해줄 것처럼 보였습니다. textarea와 preview가 한 번에 제공되어 ‘즉시 미리보기’ 구조를 쉽게 구현할 수 있었죠. 하지만 TypeScript 환경에서 타입 충돌과 빌드 오류가 끊임없이 발생했고, micromark 버전 호환 문제까지 겹치면서 안정성이 떨어졌습니다. 결국 실무에 적용하기엔 불안정하다는 판단을 내렸습니다.

마지막으로 테스트한 marked는 기본적인 렌더링은 훌륭했지만, 확장성 측면에서 아쉬움이 컸습니다. 체크박스나 코드 하이라이트 같은 기능을 추가하려면 모두 직접 구현해야 했고, 보안 이슈(XSS)까지 수동으로 처리해야 했습니다.

이러한 시행착오 끝에, markdown-it을 직접 적용하는 쪽으로 방향을 잡았습니다. 덕분에 렌더링 로직을 완전히 제어하면서 필요한 플러그인을 자유롭게 붙일 수 있었고, 프로젝트의 특성에 맞는 구조를 스스로 설계할 수 있었습니다.

이 과정을 통해 단순히 “잘 동작하는 도구”를 고르는 것이 아니라, “내가 구현하려는 서비스의 방향성과 맞는 도구를 선택하는 안목”이 얼마나 중요한지를 배웠습니다. 앞으로는 새로운 기술을 사용할 때도, 편의성보다는 제어력과 유지보수성을 중심으로 판단하는 습관을 가지려 합니다.

2) Firebase에 대한 학습

: 오늘은 Firebase를 처음부터 끝까지 다뤄보며, 서비스의 전반적인 구조를 직접 체감할 수 있었습니다. 이전에는 Firebase를 사용한 프로젝트 코드를 분석하는 수준이었지만, 이번에는 프로젝트 생성부터 호스팅, Firestore 연동, 색인 추가까지 모든 과정을 스스로 해봤습니다.

처음에는 Firebase 설정과 연결 과정이 낯설었지만, 공식 문서를 따라 하나씩 연결하면서 전반적인 흐름을 이해하게 되었습니다. 특히 Firebase Hosting 후 화면이 보이지 않는 문제나 복합 쿼리에서 색인 오류가 발생한 문제를 직접 해결하면서, 단순히 기능 구현을 넘어서 문제 원인을 추적하고 이해하는 능력이 얼마나 중요한지를 배웠습니다.

또한 Firestore에서 데이터를 다루는 과정에서, 단순히 addDoc, getDocs 같은 함수 호출이 아니라 그 뒤에 있는 색인(Index) 개념과 데이터 검색 구조를 이해하게 되었고, 쿼리 성능이 왜 인덱스 설정에 따라 달라지는지를 몸소 느꼈습니다.

이번 경험은 단순히 “Firebase를 쓸 줄 안다”로 끝나는 것이 아니라, “Firebase가 어떻게 동작하고 왜 그렇게 설계되어 있는가”를 이해하는 과정이었습니다. 시행착오가 많았지만, 그만큼 배움의 깊이도 컸던 하루였습니다.

| 배운 점

1) SvelteKit 그리고 빌드 정적 파일에 대한 학습

: 오늘은 SvelteKit 프로젝트에서의 빌드와 정적 파일 처리 과정에 대해 집중적으로 학습했습니다. 기존에 SPA 방식으로만 개발해 왔기 때문에 “빌드 후 정적 파일이 어떻게 배포되고 서비스되는가”에 대해서는 막연히 알고만 있었으며, SvelteKit의 빌드 후 정적 파일에 대해서도 경험해보지 못했었습니다.

프로젝트를 생성하고 npm run build 혹은 pnpm build 같은 명령으로 빌드를 실행해 본 후, 생성된 .svelte-kit/output 또는 build 폴더 안의 정적 파일들을 직접 들여다보면서 여러 가지 깨달음을 얻었습니다.

• SvelteKit은 라우트 구조에 따라 폴더와 파일 구조가 자동으로 생성되고, 각 페이지가 HTML + JS + CSS 형태로 정적으로 변환된다는 점이 인상적이었습니다.

• 정적 파일 배포 시에는 정적 호스팅 환경(예: Firebase Hosting, AWS S3 + CloudFront, Netlify 등) 에서 이 파일들을 제공할 준비가 되어야 한다는 것을 몸으로 느꼈습니다.

• 특히 실시간 개발 환경인 개발 모드(npm run dev)와 최적화된 배포 환경인 빌드된 프로덕션 모드의 동작 차이를 체감하면서, “개발 → 빌드 → 배포”가 단지 순서가 아니라 서비스 안정성과 사용자 경험(UX)을 확보하기 위한 필수 흐름이라는 걸 다시 깨달았습니다.

• 배포 후 정적 파일이 잘 보이지 않거나, 리소스가 잘못 로드되는 이슈를 겪으면서, base path 설정, 공개 폴더 설정, 404 처리 같은 사소해 보이는 설정이 실제 서비스 안정성에 얼마나 큰 영향을 미치는지도 학습했습니다.

이 과정을 통해 저는 단지 UI를 구성하고 기능을 구현하는 것을 넘어서, 프론트엔드 애플리케이션이 어떻게 ‘패키징’되어 인터넷상에 배포되는가라는 전체 흐름을 직접 경험했습니다. 이전까지는 “개발 → 배포”라는 단계를 자동화된 블랙박스로만 여겼다면, 이번엔 그 내부를 조금 들여다본 셈입니다.

앞으로는 프론트엔드 개발 시 “이 모듈이 빌드 결과물에 어떻게 포함될까?”, “이 라우트가 번들 크기에 어떤 영향을 미칠까?”, “정적 파일이 배포환경에서 어떻게 로드될까?” 같은 질문을 먼저 던지는 습관을 가지려 합니다. 그렇게 함으로써 단지 코드가 ‘동작하는’ 수준을 넘어, 실제 서비스 환경에서 ‘안정적으로 동작하는’ 구조를 설계할 수 있겠다는 자신감을 얻고 싶습니다.

| 내일 목표

1) Write페이지

• userId를 실제 userId로 수정

• userId까지 잘 저장되는지 검토

• (보류) 감정 버튼 / 랜덤 질문 표시 기능 구현

2) Login페이지

• 로그인 페이지 뼈대 구현

• 로그인 API 연결

3) Register 페이지

• 회원가입 페이지 뼈대 구현

• 일반 회원가입 API 연결

• 구글 로그인 API 연결

4) Firebase

• 사용자 컬렉션 추가

5) 고민할 부분

• 우리 프로젝트에서 단위 테스트는 어떻게?

| 한 줄 회고

: "기본 기능 끝내보자!"