NNZZ 사이드 프로젝트(1)

이건우·2025년 9월 25일
0

사이드 프로젝트

목록 보기
1/1
post-thumbnail

작년 8월 14일부터 시작해서 1년이 넘는 시간 동안 진행한 사이드 프로젝트에 대한 회고(아직 ~ing)를 시작합니다.

현재 웹 버전은 완성되어 유지보수를 진행하고 있고, 이제 앱으로 포팅을 준비하는 단계에서 그동안의 여정을 정리해보고자 합니다.

사이드 프로젝트를 시작한 계기

2024년 08월 12일 지인의 제안으로 시작된 사이드 프로젝트, 지인의 놀라운 섭외력으로 우린 스타트업과 맞먹는 인재들이 모였습니다 .

구성원으로는 프론트엔드 개발자(나), 백엔드 개발자, 기획자, 프로덕트 디자이너, 3D 에셋 디자이너, 마케터로 구성되었고 추진력 좋은 기획자가 모두를 모아 어떤 사이드 프로젝트를 할 것 이란 이야기와 프로젝트 논의를 시작했습니다

1.팀 규칙

정기회의일

주 2회

  • 수요일 **시
  • 일요일 **시

규칙

  • 당일 불참시 공금에 5천원씩 입금
  • 맘 상하면 아무말 대잔치에 남기기

2. 프로젝트 선정

회의 결과 우리 모두 직장인이고 매일매일 하는 고민을 해결 하고 싶어 했습니다

문제 정의

  • 직장인들은 한정된 점심시간을 점심 메뉴를 고민하는데에 낭비하고 있음
    • 매번 가는 곳만 가게 됨
    • 오늘 고민한다고 해서 내일 안해도 되는 고민이 아님
    • 그렇다고 매번 똑같은 건 먹고 싶지 않음

타겟

점심을 주로 밖에서 사먹지만 매번 똑같은 식당에 가기는 싫은 직장인

MVP 범위

  • 지도 범위 : 강남역 역삼역 부근
  • 식당리스트 : (평일 점심에 운영하는) 식당
  • 타겟 : 강남역 역삼역 부근에서 점심식사를 하는 직장인
    🍽️

MVP 기능

  1. 사용자 등록 및 로그인

    • 소셜 로그인(구글)
  2. 메뉴 선택 기능

    • 사용자가 먹고 싶은 메뉴와 안 먹고 싶은 메뉴를 선택할 수 있는 스와이프 UI 제공
  3. 이전 식사 기록

    • 사용자가 이전에 먹었던 메뉴와 식당을 저장하고 조회할 수 있는 기능
  4. 식당 추천 알고리즘

    사용자의 선호도와 이전 식사 데이터를 기반으로 식당을 추천

  5. 위치 기반 필터링

    회원의 위치와 가까운 식당만 추천하는 기능

  6. 반응형 웹 디자인

    다양한 화면 크기에서 최적화된 UI 제공

  7. 기본적인 피드백 시스템

    사용자가 추천 식당 및 메뉴에 대한 피드백을 제공할 수 있는 기능

3. 프로덕트 컨셉

💌 메뉴계의 틴더

오늘의 당신과 매칭될 메뉴는 무엇일까요? 지금 바로 확인해보세요!

4. 프론트엔드 스팩

1.배포: GitHub Actions + Vercel

사이드 프로젝트에서 가장 중요한 것은 간단하고 빠른 연결이라고 생각했다. 복잡한 CI/CD 파이프라인을 구축할 시간도, 서버를 관리할 여유도 없었기 때문에 최소한의 설정으로 자동화된 배포가 필요했다.

  • 제로 컨피그: Vercel과 GitHub 연결만으로 자동 배포 완성
  • 무료 티어: 사이드 프로젝트 규모에 충분한 무료 사용량
    즉시 반영: 코드 푸시 후 1-2분 내 배포 완료
  • Preview 배포: PR마다 자동으로 미리보기 URL 생성
  • 롤백 용이성: 클릭 한 번으로 이전 버전 복구 가능

2.스타일링: Tailwind CSS

CSS-in-JS 대신 Tailwind를 선택한 이유
처음에는 styled-components나 emotion 같은 CSS-in-JS를 고려했지만, 빠른 프로토타이핑과 일관된 디자인이 더 중요했다. 또한 디자인 파일과 tailwind config 파일에서 변수명을 일치 시키면 디자이너와의 협업에도 용이하고 컬러나 타이포그래피를 디자인 토큰을 가져와 한번에 적용 시키기 때문에 빠르게 디자인 설정을 끝낼 수 있었다. 또한 디자인 QA를 할 때에도 같은 변수명을 사용하기에 디자인 QA도 빠르게 진행 할 수 있었다.

프레임워크: Next.js + TypeScript

복잡한 라우팅 요구사항
음식 선택 앱의 특성상 다음과 같은 복잡한 라우팅이 필요했다:
/onboarding -> /food-selection -> /preferences -> /results -> /details/[id]
Next.js를 선택한 핵심 이유

  1. 파일 기반 라우팅의 직관성
    pages/
    ├── onboarding/
    │ ├── index.tsx // /onboarding
    │ └── preferences.tsx // /onboarding/preferences
    ├── food-selection.tsx // /food-selection
    ├── results.tsx // /results
    └── details/
    └── [id].tsx // /details/123

  2. 이미지 최적화

  • 음식 이미지가 많은 앱에서 Next.js의 Image 컴포넌트는 필수적이었다.

앱으로 개발 ? 웹으로 개발 ?

앱과 web을 많이 고민했는데 아직은 앱은 만들어본적이 없어서 기간내에 완성 할 수 없을 것 같다는 판단데 web기반 앱인 pwa로 개발하기로 했습니다.

PWA 최적화 전략

  1. 캐싱 전략

    NetworkFirst: 최신 데이터 우선, 네트워크 실패 시 캐시 사용
    음식 이미지와 사용자 선택 데이터의 효율적인 캐시 관리

  2. 오프라인 지원

    사용자가 음식 선택 과정에서 네트워크가 끊어져도 계속 진행 가능
    네트워크 복구 시 자동으로 서버와 동기화

  3. 개발 환경 최적화

    Next.js와의 시너지 효과
    자동 최적화

    Next.js의 이미지 최적화 + PWA 캐싱 = 빠른 로딩 속도
    정적 에셋의 자동 사전 캐싱

    SEO + 앱 경험

검색 엔진 최적화와 네이티브 앱 같은 UX를 동시에 확보
웹에서 접근 후 홈 화면 추가로 앱처럼 사용 가능

Fetch 기반 API

토큰 기반 인증 분리

사용자 인증이 필요한 API와 그렇지 않은 API를 명확히 구분하여 관리했다.

typescript// 회원가입, 로그인 등 토큰 불필요
export function fetchWithoutToken(url: string, options: RequestInit = {}): Promise<Response> {
    return customFetch(url, options, false);
}

// 사용자 데이터 토큰 필요  
export function fetchWithToken(url: string, options: RequestInit = {}): Promise<Response> {
    return customFetch(url, options, true);
}

URL 생성 유틸리티
복잡한 쿼리 파라미터를 처리하기 위한 공통 함수를 구현했다.

abstract class BaseApi {
public static generateSearchUri(url: string, params: Record<string, any>): string {
let queryString = "";
if (Object.keys(params).length === 0) {
return url;
}

    for (const key in params) {
        if (!key || !params[key]) continue;
        if (key === "search") {
            for (const searchKey in params[key]) {
                if (!searchKey || !params[key][searchKey]) continue;
                queryString += `&${searchKey}=${encodeURIComponent(params[key][searchKey])}`;
            }
            continue;
        }
        queryString += `&${key}=${encodeURIComponent(params[key])}`;
    }

    return url.includes("?") ? url + queryString : url + `?${queryString}`;
}

}

이렇게 2024 8월에 6차례에 걸친 회의끝에 사이드 프로젝트의 MVP , 기능, 컨셉, 개발 스팩 등이 정해졌다. 나는 웹 개발자이기 떄문에 앱 개발에 망설임은 있었다 그래도 도전하고 싶었기에 우리는 PWA로 먼저 개발을 하고 나중에 앱으로 전환하기로 했다.

계속된 회의와 협업을 통해 프로젝트 팀원들에 대한 고마움이 많았다. 팀원들은 굉장히 능동적이고 의견 표현이 명확해서 같이 하면 뭐든 만들 수 있을 것 같다는 느낌이 들었었다.

profile
주니어 개발자 이건우 입니다 .

0개의 댓글