[우테코] 23편 : 오픈미션 17일차

| 서론

안녕하세요 팡일입니다!

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

| 오늘 한 일

1) QA

• QA 진행하기

• 받은 QA 정리하기

2) 리스트 페이지

• 정렬 버튼 밖에 클릭하면 닫히게 수정하기

3) 디테일 페이지

• 수정, 삭제 공유 버튼 개선하기

4) 수정 페이지

• 회고 작성 종료 모드에 따른 수정 페이지 개선

5) 기타

• 불필요한 주석, 미사용 import 제거

• ESLint 경고 해결

| 어려웠던 점 & 배운 점

1) 타입스크립트의 any와 작별하기: 보이지 않는 버그와의 전쟁

(1) 어려웠던 점

: 프로젝트를 리팩토링하는 과정에서 가장 골칫거리였던 부분은 코드 곳곳에 남아 있던 any 타입이었습니다. 특히 updateUserProfile 같이 여러 페이지에서 사용하는 함수는 동일한 인터페이스로 호출되는 것처럼 보였지만, 실제로는 서로 다른 형태의 데이터를 전달받고 있었습니다. 예를 들면, 관리자 페이지에서는 Firestore의 UserDoc 구조를 전달하고, 마이페이지에서는 Firebase Auth의 User 구조를 전달하는 방식이었습니다. any 덕분에 오류가 감춰져 있었고, 타입 검사기가 전혀 경고를 줄 수 없었습니다. 이 문제를 해결하려면 단순히 하나의 파일에서 타입을 고치는 수준이 아니라, 서비스 레이어부터 load 함수, 중앙 상태 store, 그리고 실제 컴포넌트까지 하나의 흐름으로 이어지는 전체 데이터 구조를 추적해야만 했습니다. 마치 실타래처럼 얽힌 타입 오류를 하나씩 풀어내는 작업이었고, 상당한 집중이 필요했습니다.

(2) 배운 점

: 이번 과정을 통해 any는 단순한 편의가 아니라 장기적인 위험이라는 사실을 확실하게 깨달았습니다. 그래서 src/types/interfaces 폴더를 새로 만들고 UserDoc, CreatedAt 같은 공통 타입들을 명확하게 정의했습니다. 타입을 정비하고 나니 코드 자체가 명확한 문서가 되었고, IDE 자동완성과 타입 추론이 훨씬 강력하게 동작하며, 컴파일 단계에서 대부분의 잠재적 문제를 미리 잡을 수 있게 되었습니다. 타입 시스템을 구축하는 데 초기 비용이 드는 건 사실이지만, 장기적인 유지보수성과 안정성을 고려하면 반드시 투자해야 하는 부분이라는 것을 몸으로 느낀 하루였습니다.

2) 데이터 흐름 바로잡기: SvelteKit의 load 함수와 중앙 스토어의 시너지

(1) 어려웠던 점

: 가장 당황스러웠던 버그는 KPT 회고를 수정하러 들어갔는데 Daily 회고의 질문이 나오는 문제였습니다. 원인은 구조적인 문제에 있었습니다. 기존 구조에서는 컴포넌트 내부에서 URL 파라미터를 읽고, onMount에서 비동기로 데이터를 가져오고, 가져온 내용으로 상태를 초기화하는 등 너무 많은 책임을 한 컴포넌트가 떠안고 있었습니다. 이 방식은 렌더링보다 데이터 로딩이 늦어 UI가 잠깐 잘못된 상태를 보여주는 문제를 만들었고, 어떤 시점에 어떤 데이터가 들어오는지 예측하기 어렵게 만들었습니다. 각각의 흐름이 완전히 분리되지 않은 상태였기에, 데이터의 정확한 출처와 흐름을 파악하는 데 오랜 시간이 걸렸습니다.

(2) 배운 점

: 해결 과정에서 SvelteKit의 +page.ts에 있는 load 함수의 진짜 가치에 대해 깨달을 수 있었습니다. 페이지가 렌더링되기 전에 필요한 데이터를 load에서 모두 준비하고, 이후에는 중앙 store에서 초기 상태를 구성하도록 구조를 재편했습니다. 예를 들어 initializeEditorFromDoc 같은 초기화 액션을 만들어 모든 컴포넌트가 동일한 방식으로 초기 상태를 구성하게 했습니다. 이 방식으로 바꾸고 나니 컴포넌트는 단순히 store 값을 렌더링하는 역할만 맡게 되었고, “데이터 로딩 → 상태 결정 → UI 렌더링”의 책임이 명확하게 분리되었습니다. 그 결과 버그는 자연스럽게 해결되었고, 전체 코드 구조가 더 깔끔하고 테스트하기 쉬운 형태로 진화했습니다.

3) 사용자 경험(UX)은 디테일에서 완성된다: 사소하지만 강력한 개선들

(1) 어려웠던 점

: Enter 또는 Escape 키로 모달을 제어하는 기능은 단순해 보였지만 실제로는 사이드 이펙트가 많았습니다. 특히 전역 이벤트 리스너가 중복으로 등록되면 메모리 누수가 발생하거나, 하나의 키 입력이 여러 모달을 동시에 닫아버리는 문제가 생길 수 있었습니다. 또 이벤트가 제대로 제거되지 않으면 화면 이동 후에도 남아 있는 키 핸들러가 의도하지 않은 UI 동작을 일으키는 등의 문제도 있었습니다. 작은 기능이라 생각했지만 내부적으로는 신중한 제어가 필요한 영역이었습니다.

(2) 배운 점

: Svelte의 생명주기 관리(onMount → return cleanup)를 올바르게 사용하는 것이 얼마나 중요한지 다시 한 번 체감했습니다. 컴포넌트가 사라질 때 이벤트 리스너를 정확하게 제거하니 모든 이상 동작이 깔끔하게 사라졌습니다. 또한 lucide-svelte 아이콘을 버튼에 추가하면서 UX도 크게 개선되었습니다. 같은 버튼이라도 아이콘 하나가 있으면 사용자가 기능을 더 직관적으로 이해할 수 있었고, 전체 UI의 완성도가 올라갔습니다. 작은 개선들이 모여 결국 서비스 전체의 경험을 좌우한다는 점을 다시 느낀 하루였습니다.

| 내일 목표

1) QA

• QA 진행하기

• 받은 QA 정리하기

2) 리스트 페이지

• 내용 검색 기능 고민하기

3) 작성 페이지

• 마크다운 에디터 가이드라인 고민하기

• 감정 커스텀에 대해서 고민하기

• 글 별 카테고리 추가에 대해서 고민하기

4) 로그인 페이지

• 비밀번호 찾기 기능 고민하기

| 한 줄 회고

: "타입스크립트,, 어렵지만 친해져가는중"