[우테코] 15편 : 오픈미션 9일차

| 서론

안녕하세요 팡일입니다!

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

| 오늘 한 일

1) Write 페이지

• 임시 저장 기능 추가

2) Update 페이지

• 기본 UI 구성

• 조회 기능 추가

• 수정 기능 추가

3) 로그인/회원가입 페이지

• 구글 로그인 아이콘으로 커스텀

4) Detail 페이지

• 수정 페이지 이동 기능 추가

5) 리팩토링

• 코드 개선 필요한 부분 찾고 개선하기

• 감정 칩 추가로 인한 변경 사항 고민하기

| 어려웠던 점

1) ‘수정’과 ‘작성’ 기능의 공존시키기

: 회고 수정 기능은 ‘회고 작성’ 페이지와 UI가 거의 동일했습니다. 두 페이지를 별도로 만들면 코드 중복이 심해질 것이 뻔했기 때문에, 하나의 컴포넌트를 재사용하는 방식을 택했습니다. 하지만 이로 인해 컴포넌트는 ‘작성 모드’일 때와 ‘수정 모드’일 때의 로직을 모두 고려해야 했습니다. mode라는 prop을 만들어 분기 처리를 했는데, ‘수정 모드’일 때만 기존 데이터를 불러와 폼을 채워주는 로직을 onMount에서 처리하는 등, 하나의 컴포넌트에서 두 가지 시나리오를 매끄럽게 다루는 과정이 가장 큰 고민이었습니다.

2) ‘자동 저장’ 기능의 적절한 구현 방식 찾기

: 사용자의 모든 키 입력마다 저장을 요청하면 데이터베이스에 엄청난 부하가 갈 것이 분명했습니다. 이 문제를 해결하기 위해 debounce라는 기법을 도입해, “사용자의 타이핑이 멈추고 일정 시간이 지났을 때만 저장하도록” 구현했습니다. 처음에는 debounce의 개념과 타이밍을 잡는 것이 낯설어 여러 번의 테스트가 필요했습니다. 또한, 페이지에 다시 접속했을 때 “임시저장된 글을 불러올지” 사용자에게 확인받고, 최종 제출 후에는 임시 데이터를 삭제하는 등 세심한 UX 흐름을 전체적으로 설계하는 것이 쉽지 않았습니다.

3) 컴포넌트 간의 복잡한 상태 흐름 관리

: 수정 기능을 구현하면서 데이터 흐름이 페이지 → 컴포넌트 → 중앙 저장소(Store) → API 호출 등 여러 단계를 거치게 되었습니다. 특히 수정 페이지 진입 시, URL의 id 값으로 DB에서 데이터를 가져와 중앙 저장소의 상태를 ‘채워주고(hydrate)’, 이 상태를 폼 컴포넌트가 구독하여 화면에 그리게 하는 과정이 복잡했습니다. 데이터가 어떤 순서로, 어디서부터 어디로 흘러가는지를 명확히 하지 않으면 상태가 꼬이기 쉬워, 전체적인 데이터 흐름을 설계하고 디버깅하는 데 많은 시간을 쏟았습니다.

| 배운 점

1) 컴포넌트 재사용 패턴의 강력함 (mode prop)

: mode prop 하나로 작성/수정 기능을 모두 처리하는 컴포넌트를 만들면서, “하나의 잘 만든 컴포넌트가 두 개, 세 개의 페이지 역할을 할 수 있다”는 것을 직접 체감했습니다. 덕분에 코드의 양이 획기적으로 줄었고, 폼의 UI를 변경해야 할 때 단 한 곳만 수정하면 되므로 유지보수성이 매우 높아졌습니다. 이는 앞으로 비슷한 기능을 만들 때 계속해서 활용할 수 있는 강력한 패턴이 될 것입니다.

2) 사용자 경험을 고려한 비동기 처리의 중요성 (debounce)

: 자동 저장 기능을 구현하며 debounce의 필요성과 효과를 명확히 알게 되었습니다. 단순히 기능을 만드는 것을 넘어, “어떻게 하면 시스템에 부하를 주지 않으면서 사용자에게 최고의 경험을 줄 수 있을까?”를 고민하는 계기가 되었습니다. 사용자의 흐름을 방해하지 않으면서도 데이터의 안정성을 보장하는 이 경험은, 앞으로 비동기 로직을 다룰 때 중요한 자산이 될 것입니다.

3) 상태 관리와 로직의 명확한 분리

: hydrateWriteStore(데이터 채우기), resetWriteStore(초기화) 같은 함수를 만들며 중앙 저장소의 역할을 명확히 정의했고, submitModifyRetrospect(수정 제출)와 같은 함수로 비즈니스 로직을 분리하면서 코드의 의도가 훨씬 명확해졌습니다. 이제 컴포넌트는 “어떻게” 동작하는지 몰라도, 그저 필요한 함수를 “호출”하기만 하면 됩니다. 이렇게 각자의 역할과 책임을 명확히 나누는 것이 결국 더 안정적이고 테스트하기 쉬운 아키텍처를 만든다는 것을 배웠습니다.

| 내일 목표

1) Write 페이지

• 감정 버튼 기능 추가

2) detail 페이지

• 감정 리스트 UI 추가

3) update 페이지

• 감정 리스트 UI 추가

• 감정 수정 기능 추가

4) 고민할 부분

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

• 모니터링 도구 알아보기

5) 랜딩 페이지

• 후킹할만한 포인트 고민하기

6) 리팩토링

• 감정 칩 추가로 인한 변경 사항 고민하기

• theme 파일 만들어서 디자인 통일화

• toast 메세지 컴포넌트화

| 한 줄 회고

: "MVP 수준은 거진 다 만들었으니, 이제 디테일을 신경써보자!"