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

| 서론

안녕하세요 팡일입니다!

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

| 오늘 한 일

1) 랜딩 페이지

• 후킹할 수 있도록 컨텐츠 수정하기

2) 리팩토링

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

3) list 페이지

• 회고 카드에 감정 칩 추가하기

4) Detail 페이지

• 공유 기능 만들어보기

• share 폴더 기반 공유 기능 구현

| 어려웠던 점

1) 컴포넌트 재사용성과 인증 상태 관리의 복잡성

: 공유용 회고 페이지(/share/[id])를 구현하면서 가장 먼저 부딪힌 문제는 인증 상태에 따라 UI가 달라지는 기존 컴포넌트 구조를 그대로 재사용하기 어려웠다는 점이었습니다.

DetailContainer, DetailHeader 같은 컴포넌트들은 로그인한 사용자를 기준으로 만든 구조였기 때문에, 로그인하지 않은 익명 사용자에게도 보여줘야 하는 공유 페이지에서는 isAuthenticated, isOwner 같은 상태를 최상단에서 하위 컴포넌트까지 계속 전달해야 했습니다.

이 과정에서 prop drilling이 심해지고, 혹시라도 잘못 전달된 상태 때문에 “익명이 공유 페이지에서 수정/삭제 버튼을 보게 되는 위험”을 막기 위해 여러 단계에서 방어 코드를 추가하며 구조를 재점검해야 했습니다.

2) SvelteKit의 (private)/(public) 라우팅 구조를 실제 서비스에 적용하는 과정

: SvelteKit의 레이아웃 그룹은 강력하지만, 처음에는 이 구조를 어떻게 안전하게 나눌지 고민이 많았습니다.

• (private)/detail/[id]에서는 인증된 사용자만 접근해야 하고

• (public)/share/[id]에서는 누구나 접근할 수 있어야 하는데

• 두 페이지는 같은 데이터를 기반으로 해야 한다

이 특성 때문에 서로 다른 +layout.ts / +page.svelte 로직을 가지면서도 중복 코드를 최소화하는 균형점을 찾는 게 쉽지 않았습니다.

결국 데이터 로딩 구조를 공통화하고, 인증 검증 로직만 (private) 그룹에 두면서 문제를 해결했습니다.

| 배운 점

1) 기술 선택은 결국 ‘문제의 본질’에서 출발해야 한다

: 공유 기능을 처음 설계할 때, “서버리스로 SSR처럼 구현하면 더 멋지고 안전하겠다”는 생각으로 Firebase Functions를 도입했지만, 실제로 구현하는 과정 속에서 보니 이는 과한 설계(Over-engineering)였다는 걸 깨달았습니다. 공유 기능은 본질적으로 단순했고, 복잡한 서버 계층 없이도 충분히 구현할 수 있는 문제였기 때문입니다. 오히려 서버 계층을 제거하고 SvelteKit의 기본 구조로 돌아갔을 때 유지보수성과 개발 경험이 훨씬 좋아졌습니다. 이 경험을 통해 “멋진 기술이 항상 최선의 선택은 아니며, 기술 선택의 출발점은 언제나 '지금 해결해야 하는 문제의 본질’이어야 한다”는 중요한 교훈을 얻었습니다.

2) 라우팅 구조 설계가 곧 안정적인 인증·보안 구조의 기반이 된다

: (private)과 (public) 두 라우트가 같은 데이터를 사용하면서도 서로 다른 인증 정책을 가져야 하는 상황을 해결하는 과정에서,

“라우팅 구조 자체가 보안 설계의 핵심이 된다”는 것을 깨달았습니다. 처음에는 두 경로가 사용하는 데이터 로직이 서로 달라지고,

+layout.ts / +page.svelte 파일 간 중복도 늘어나는 등 복잡도가 계속 높아졌습니다.

하지만 구조를 다시 정리해 보니, 데이터 로딩 로직은 공통화하고, 인증이 필요한 부분만 (private) 그룹에서 일괄적으로 처리하는 방식

으로 분리하는 것이 가장 깔끔하고 안전한 방법이라는 걸 깨달았습니다.

이 경험을 통해 “인증과 접근 제어는 개별 페이지가 아니라 라우팅 레벨에서 설계해야 한다.”와 같은 인사이트를 얻을 수 있었습니다. 즉,

페이지마다 조건문을 추가하는 방식은 유지보수가 어렵고 위험하지만, 라우트 그룹 차원에서 인증 규칙을 선언해두면 전체 구조가 단순해지고, 보안도 훨씬 명확해집니다. 이 경험 덕분에 앞으로 기능을 설계할 때도 페이지 내부가 아니라 라우팅 단계에서의 패턴 설계를 먼저 고민해야 한다는 중요한 교훈을 얻게 되었습니다.

| 내일 목표

1) 기타

• CI/CD 구축

2) 고민할 부분

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

• 모니터링 도구 알아보기

3) 공유

• 카카오톡 공유하기

• pdf 또는 이미지로 저장하기

4) QA

• QA에 대해 고민하기

• QA 대상자 찾아보기

• QA 요청 멘트 구해보기

• QA 아카이빙 노션 만들기

| 한 줄 회고

: "어려워도 꾸준히 시도하는 사람이 됩시다!"