https://wikied-steel.vercel.app/

프로젝트 개요

역할

팀장, 프론트엔드, 프로덕트 디자인

기간

2025년 4월 22일 ~ 5월 12일(약 3주)

설명

‘너의 TMI, 내가 정리해줌' 나무위키의 '인물 버전'이라는 컨셉에서 출발한 소셜 위키 플랫폼입니다. 친구들 사이의 재미있는 TMI를 위키 형식으로 함께 기록하고 공유하는 서비스입니다. 팀장을 맡아 프로젝트의 전반적인 기획과 개발을 이끌었습니다.

---

문제와 해결

• 프론트엔드 아키텍처: 인증 및 상태 관리 시스템 설계
• 협업 및 버전 관리: Git 히스토리 충돌 해결
• UI/UX 및 최적화: 사용자 경험 디테일 개선
• CSS-in-JS: Styled Components와 SSR의 상충 관계

---

프론트엔드 아키텍처: 인증 및 상태 관리 시스템 설계

• 문제 정의: 3주라는 짧은 개발 기간 내에 자체 로그인 시스템과 안전한 인증 시스템을 구축해야 했음. 또한 페이지 새로고침 시에도 사용자 로그인 상태가 유지되어야 했으며, 여러 컴포넌트에서 사용자 데이터를 공유하기 위한 효율적인 전역 상태 관리 전략이 필요했음.
• 해결 과정:

  • 인증 시스템 대안 분석:

    1. 자체 JWT 토큰 기반 시스템 구현
    2. NextAuth.js 라이브러리 도입

    1은 자유도가 높지만 보안 취약점(CSRF, XSS)에 대한 직접적인 대응이 필요하고 개발 시간이 오래 걸린다고 판단함. 2는 소셜 로그인 Provider를 제공하고, 보안이 검증되었으며, 개발 시간을 획기적으로 단축할 수 있어 최종 선택함.

  • 상태 관리 대안 분석: Redux, Zustand를 검토함. Redux는 보일러플레이트가 많았고, 프로젝트 규모에 비해 과했음. 보일러플레이트가 거의 없고, 빠르고 효율적으로 개발 가능한 Zustand를 최종 선택하여 개발 생산성을 극대화함.

• 결과: NextAuth.js 도입으로 인증 시스템 구축 시간을 단축하여, 팀이 서비스 핵심 기능 개발에 더 집중할 수 있었음. Zustand를 통해 상태관리의 효율성을 높임.
• 확장: 향후 Refresh Token 자동 갱신 로직을 구현하여 세션 만료 시간을 유연하게 관리하여 사용자 경험을 향상시킬 수 있음.

---

협업 및 버전 관리: Git 히스토리 충돌 해결

• 문제 정의: 팀원의 로컬 Git 작업 오류로 인해, 공유 브랜치(develop)의 HEAD가 이전 커밋으로 잘못 덮어씌워져 최신 기능 코드의 일부가 히스토리에서 보이지 않게 되는 긴급 상황이 발생함.
• 해결 과정:

  • 대안 분석:

    1. git reset --hard를 통한 강제 복구
    2. git revert를 통한 안전한 복구

    이미 문제의 커밋 위로 다른 팀원들의 새로운 커밋들이 push된 상황이었으므로, 1은 다른 팀원의 작업을 유실시킬 수 있는 매우 위험한 명령어라고 판단함.

  • 최종 선택: 팀 회의를 통해 reset과 revert의 차이점 및 각 명령어의 리스크를 설명하고, 가장 안전하며 협업 히스토리를 투명하게 유지할 수 있는 git revert를 통한 복구로 최종 결정됨.

• 결과: 이슈 발생 후 30분 이내에 모든 코드를 손실 없이 복구하여, 프로젝트 딜레이를 완벽하게 방지함. 이 사건을 계기로, 팀 내에 해당 이슈 방지를 위한 Git 가이드라인을 팀 전체에 공유하여 협업 안정성을 강화함.
• 확장: 향후 브랜치 보호 규칙을 적용하여 유사한 휴먼 에러를 시스템적으로 원천 차단할 수 있음.

---

UI/UX 및 최적화: 사용자 경험 디테일 개선

• 문제 정의: 서비스의 첫인상을 결정하는 랜딩 페이지의 경험, 사소하지만 반복적인 불편함을 유발하는 UI, 그리고 불필요한 리소스로 인한 성능 저하 등 개선이 필요했음.
• 해결 과정:
  • 인터랙티브 랜딩 페이지: '인물 위키'라는 생소한 개념을 친근하게 전달하기 위해, Matter.js의 물리 엔진과 직접 제작한 Lottie 애니메이션을 결합하여 사용자의 인터랙션에 반응하는 동적인 랜딩 페이지를 단독으로 개발함.
  • GNB 검색창 UX 개선: 사용자가 스크롤하여 검색창이 보이지 않게 될 경우, GNB에 검색창이 동적으로 나타나도록 구현하여 UI 접근성을 향상시킴.
  • 리소스 최적화: Figma 프로젝트의 비효율적인 구조를 재구성하여 페이지의 17%를 감축하고, 사용되지 않는 웹 폰트를 41% 제거하여 에셋 크기를 약 1.7MB 줄임. 이를 통해 초기 로딩 성능을 개선함.
• 결과: 동적인 랜딩 페이지를 통해 서비스의 첫인상을 긍정적으로 형성하고 초기 이탈률을 낮추는 효과를 기대할 수 있었음. 작은 UX 개선들이 모여 서비스의 전체적인 완성도를 높였으며, 리소스 최적화를 통해 실질적인 성능 향상을 이뤄냄.
• 확장: Lottie 애니메이션을 지연 로딩(lazy loading)하여 랜딩페이지 초기 로딩 속도를 개선할 수 있음.

---

CSS-in-JS: Styled Components와 SSR의 상충 관계

• 문제 정의: 팀원 모두가 Styled Components에 익숙했지만, CSS-in-JS 라이브러리의 런타임 특성은 Next.js의 SSR 환경에서 초기 로딩 시 스타일이 적용되지 않는 깜빡임 현상과 성능 저하를 유발하는 기술적 문제가 있었음.
• 해결 과정:

  • 대안 분석:

    1. 팀의 학습 곡선을 고려하여 익숙한 Styled Components를 유지하고 문제를 해결하는 방법
    2. Tailwind CSS와 같이 Next.js와 더 잘 맞는 다른 스타일링 솔루션을 도입하는 방법

    프로젝트의 짧은 기간을 고려하여 1을 선택하되, 문제 해결 과정을 통해 팀의 기술적 이해도를 높이는 것을 목표로 함.

  • 최종 선택: next.config에서 compiler에 styledComponents를 추가하고, 빌드 시점에 서버에서 생성된 스타일을 클라이언트에 미리 주입하는 방식으로 SSR 환경에서의 스타일 문제를 해결함.

• 결과: 팀원들이 익숙한 기술 스택을 유지하면서도 Next.js 환경에서 발생하는 기술적 문제를 성공적으로 해결함. 이 과정을 통해 팀 전체가 CSS-in-JS와 서버 사이드 렌더링의 동작 원리에 대해 더 깊이 이해하는 계기가 됨.
• 확장: 이 경험을 통해, 향후 Next.js 프로젝트에서는 'Zero-Runtime' CSS-in-JS 라이브러리나 Tailwind CSS를 사용하는 것이 프레임워크의 철학에 더 부합하며 장기적인 성능과 유지보수성 측면에서 더 유리하다는 기술적 결론을 내림.