Overview

2년간 아마추어 작가와 전시 공간을 연결하는 양면 플랫폼을 기획부터 배포까지 주도. 기능을 만들고, 운영 가능한 구조를 만들었음.

양면 플랫폼 기획

작가·공간주 양면 User Flow 설계 → MVP 범위·리소스 정의

SSR 전환 결정

SPA 구조의 SEO 한계 → Next.js SSR로 렌더링 방식 재설계

CMS 기반, SaaS 재설계

인력 이탈·운영 병목 → Firebase에서 Sanity로 구조 전환

CI/CD 자동화

GitHub Flow + Vercel 연동 → 브랜치 전략·배포 신뢰성 확보

개발 프로세스 설계

출시 지연 → Agile+Waterfall 혼합·M/M 기반 일정 재조정

Problem

SPA 구조 → 검색에 보이지 않는 서비스

React 기반 SPA로 출시한 직후, SNS 홍보와 무관하게 검색 유입이 거의 없었음.

크롤러가 JS 렌더링 이전의 빈 HTML만 읽는 구조였기 때문.

메타데이터/콘텐츠 문제가 아니라, 렌더링 방식 자체가 검색 노출을 막는 구조
React SPA → 크롤러 접근 불가 → 검색 유입 차단

콘텐츠 한 줄 수정 = 재배포 20분

전시 정보·작가 소개 수정마다 코드 수정 → 빌드 → 배포 필요.

하루 5건 이상의 단순 수정이 개발 자원을 잠식함.

콘텐츠와 로직이 결합된 구조 → 운영 불가 상태
인력 이탈 후 백엔드 공백 → 수동 DB 관리 → 오류·지연 반복

출시일 없는 Agile

빠른 실험을 명분으로 Agile 방식을 채택했으나, 마일스톤 없이 기능만 쌓였음.

명확한 완료 기준이 없어 출시가 무기한 지연됨.

방법론의 문제가 아니라, 팀에 맞는 프로세스 설계 부재

Solution

해결한 문제 요약
문제 영역	Before	After
검색 노출	SPA → 크롤러 접근 불가	SSR → 정상 인덱싱
콘텐츠 수정	재배포 필요 (20분+)	CMS 수정 (5분)
출시 일정	마일스톤 없음, 무기한 지연	M/M 기반 일정관리, 6개월 단축
배포 신뢰성	브랜치 혼재, 내용 누락	문서화 규칙 수립

렌더링 방식 변경

메타 태그 보완이 아닌, 렌더링 방식 자체를 SSR로 전환.

JavaScript → TypeScript 마이그레이션을 병행해 타입 불명확성으로 인한 런타임 오류를 사전 차단함.

SEO 문제 발생 → Next.js SSR 선택 (JS 렌더링 의존 제거)
타입 오류 반복 → TypeScript 전환 → 데이터 흐름 재정의

콘텐츠-로직 분리 → 운영 가능한 구조로

백엔드 인력 이탈 후, 복잡한 관리 및 재배포 없이 DB 운영 가능한 구조로 전환.

Firebase 커스텀 백엔드 → Sanity CMS 전환
이미지 서버 직접 관리 → Cloudinary 외부화 → 로딩 속도·비용 최적화
전환 결정 근거: 1개월 수정 요청 건수·소요 시간·오류 발생률 수치화

배포 구조 정비 → 신뢰 가능한 릴리즈

GitHub + Vercel 자동 배포 설계 후 브랜치 혼재로 배포 충돌 발생.

Develop / Release 브랜치 분리 → 테스트 절차 도입
커밋·PR 가이드 문서화 → 비개발자도 릴리즈 관리 가능한 구조

개발 프로세스 재설계 → 출시 일정 확보

소프트웨어공학 이론 기반으로 팀 특성에 맞는 혼합 프로세스를 제안함.

전체 방향: Agile (유연성 유지)
단위 기능: Waterfall (명확한 시작·완료 기준)
개발자별 M/M 측정 → 일정·우선순위 재조정 근거로 활용

Implementation

Next.js SSR + TypeScript 전환

React SPA → Next.js 기반 SSR 전환 → 크롤러 접근 가능 구조 확보
기존 JavaScript 코드 → TypeScript로 마이그레이션 → 필드명 불일치·타입 오류 사전 차단
API 스키마 문서화 → 페이지별 예상 활용 데이터 정의 → undefined/null 체크 로직 추가

Firebase → Sanity CMS 전환

Firebase 문서 구조 → Sanity 스키마 재설계 (필드·타입 재정의)
백엔드 담당자 퇴사 전 협업 → 데이터 이전 완료 후 전환
Cloudinary 연동 → 이미지 로딩 속도·비용 최적화

GitHub Flow + CI/CD 구조 정비

Develop / Release 브랜치 분리 → Develop 테스트 후 Release 병합·배포
컨벤션 문서화 → 브랜치 혼재로 인한 배포 충돌 제거
Github Actios → 자동 버전관리
Vercel 자동 배포 연동 → 수동 배포 제거

Problem Solving

Firebase → Sanity 전환 중 API 구조 오류

문제: 마이그레이션 중 필드명 불일치·타입 미반영 → 프론트 컴포넌트 오류 빈발
원인: Firebase 평면 구조 vs Sanity 문서 기반 구조 차이 → 필드 매핑 미정의
해결: API 스키마 문서화 → 페이지별 데이터 정의 → TypeScript 타입 강화 → null 체크 추가
결과: 오류 재발 없이 전환 완료 → 이후 요구사항 변경 시 API 스키마 우선 검토 원칙 수립

배포 자동화 후 수정 내용 누락

문제: GitHub + Vercel 자동 배포 구조에서 일부 수정이 반영 안 되거나 이전 상태로 배포됨
원인: 테스트·릴리즈 브랜치 배포 시점 혼재 → 이전 커밋이 재배포되는 사례 발생
해결: Develop/Release 브랜치 분리 → 커밋·PR 가이드 문서화 → 테스트 절차 도입
결과: 배포 충돌 제거 → 신뢰 가능한 릴리즈 구조 확보
인사이트: 자동화는 사람이 쉽게 활용할 수 있는 수준까지 완성해야 한다

Agile 방식 하에서 출시 무기한 지연

문제: 마일스톤 없이 기능만 쌓임 → 출시일 확정 불가
원인: 유연성만 강조, 완료 기준·역할 정의 없이 빠른 개발만 추구
해결: Agile+Waterfall 혼합 프로세스 제안 → M/M 기반 일정 재조정
결과: 예정보다 6개월 조기 출시

Insight

기술 결정은 운영 가능성으로 검증

Next.js, TypeScript, Sanity 모두 "6개월 후에도 혼자 운영 가능한가" 기준으로 선택함
이후 모든 기술 선택 시 유지보수 비용·인적 자원 투입 구간을 함께 검토

데이터가 필요한 이유

CMS 전환 제안 당시 반대 有 → 1개월간 수정 요청 건수·소요 시간·오류 수치화 → 시범 적용 허용
"지금도 돌아간다"는 저항을 데이터로 넘는 경험 → 이후 기술 의사결정 방식 정립

프로세스는 팀에 맞게 설계한다

Agile이 항상 옳지 않고, Waterfall이 항상 느리지 않다
M/M 기반 일정 수치화 → 팀의 기술 의사결정 신뢰도 향상

Result

Outcomes

서버 자원 사용량 70% 감소 — CMS 전환 + 미디어 Cloudinary 외부화 → 로딩 지연 해소
콘텐츠 수정 시간 20분 → 5분 — 재배포 없이 CMS 직접 수정 가능한 구조로 전환
출시 일정 6개월 단축 — M/M 기반 일정·우선순위 재조정 후 예정 대비 조기 출시
런타임 오류 감소 — JavaScript → TypeScript 전환 → 타입 불일치 오류 사전 차단
배포 신뢰성 확보 — Develop/Release 브랜치 분리·PR 가이드 문서화 → 배포 충돌 제거
SEO 개선 — SPA → SSR 전환 → 검색 노출 및 유입 개선

Before / After Metrics

서버 자원 사용량

100% → 30%

Before100%

After70% 감소

콘텐츠 수정 소요 시간

20분 → 5분

Before20분

After75% 감소

[IRUTI] 양면 웹 플랫폼: 기획 - 개발 - 출시 A to Z