디지털 소외 계층인 고령 성도들이 쉽고 빠르게 교회 소식에 접근할 수 있게 하고,
기술을 모르는 목사님이 복잡함 없이 운영할 수 있는 시스템.

• 기간: 2026.01.05 ~ 2026.02.13
• 역할: 기획 · 설계 · 개발 · 배포 전담 (1인)
• GitHub: 프로젝트 GitHub
• 프로덕션 URL (Web): https://www.mannachurch.or.kr
• 프로덕션 URL (Admin): https://manna-church-service.vercel.app

• Turborepo 모노레포 초기 구성 시 @repo/ui, @repo/database 등 내부 패키지를 JIT(Just-In-Time) 방식으로 트랜스파일하여, 앱 빌드 시 내부 패키지 소스를 매번 함께 컴파일하는 구조였음
• @repo/ui에 Radix 컴포넌트가 21개 이상 추가되면서 빌드 시간이 기하급수적으로 증가하고 Turborepo 캐시 히트가 반복 실패
• 내부 패키지 CSS를 절대 경로로 가져올 때 간헐적인 빌드 에러 발생, 이를 회피하기 위해 ../../packages/ui/... 같은 상대 경로를 사용하게 되어 패키지 간 강결합(Tight Coupling) 발생

1. 모든 내부 패키지에 tsc 사전 빌드 스크립트를 추가하여 dist/ 디렉토리로 출력물을 생성하도록 변경
2. package.json의 진입점을 소스 코드가 아닌 dist/ 내의 컴파일된 JS/DTS 및 CSS 파일로 명시 (exports 필드 설정)
3. turbo.json에 "dependsOn": ["^build"] 설정을 추가하여 패키지 선행 빌드 후 앱이 빌드되도록 순서 강제 보장

• 억지스러운 상대 경로를 제거하고 패키지 본연의 방식으로 import 가능, 모노레포 도입 목적에 맞는 느슨한 결합(Loose Coupling) 달성
• dist/ 출력물이 변경되지 않으면 Turborepo가 내부 패키지 재빌드를 완전히 스킵(Cache Hit)하여 앱 재빌드 시간 대폭 단축
• 타입 안전성 유지: .d.ts 파일을 통해 타입 추론 완전 지원

• 모노레포 환경에서 hidden lg:flex 등 반응형 유틸리티가 동작하지 않음. display: none이 미디어쿼리를 덮어씀
• 단일 앱 환경과 달리 모노레포 구조에서는 외부 패키지(@repo/ui/styles.css)와 메인 앱(globals.css)의 CSS가 개별적으로 컴파일되어 로드
• 병합 순서가 꼬이면서 메인 앱의 기본 .hidden 클래스가 UI 패키지의 반응형 미디어쿼리 규칙보다 나중에 선언되어 CSS Cascade Specificity를 덮어쓰는 아키텍처 결함 발생

1. 모노레포 환경에서 CSS가 어떤 순서로 컴파일·병합되는지 로드 순서를 추적하여 원인 파악
2. Turborepo 공식 패턴 적용: layout.tsx에서 @repo/ui/styles.css를 먼저 import한 뒤 globals.css를 import하여 로드 순서 보장

• 모든 반응형 유틸리티 정상 동작
• 모노레포 환경에서의 CSS 로딩 전략 확립, 이후 동일 문제 재발 방지

• 관리자 CMS에서 주보 PDF 업로드 시 pdfjs-dist를 Top-level Static Import로 사용했을 때, Node.js(SSR) 환경에서 ReferenceError: DOMMatrix is not defined 발생
• pdfjs-dist 내부 canvas.js에서 new DOMMatrix()를 전역 스코프에서 즉시 실행하는데, Node.js에는 DOMMatrix API가 존재하지 않음
• 'use client' 지시어가 있어도 서버가 모듈 그래프를 평가하는 과정에서 실행되어 에러 발생

1. Static Import를 Dynamic Import (await import('pdfjs-dist'))로 변경하여 실제 사용 시점에만 모듈 로드
2. 타입은 import type으로만 가져와 런타임 영향 없이 타입 안전성 유지

• SSR 환경 DOMMatrix 에러 완전 해소
• 수 MB에 달하는 PDF 파싱 라이브러리가 초기 번들(Initial Bundle)에서 제외되어 관리자 페이지 초기 로딩 속도(TTV) 개선
• PDF 업로드 요청 시에만 라이브러리가 로드되어 불필요한 리소스 낭비 제거

처음으로 실제 클라이언트가 있는 프로젝트였다. 공부하면서 알고만 있던 것들을 실제 서비스에 적용해보는 경험이었고, 그 무게감이 달랐다.

클라이언트를 생각한 설계를 처음으로 진지하게 고민했다. 60대 이상 어르신들이 쓰는 서비스라는 걸 항상 염두에 두고, 화면이 밀리지 않아야 하고(CLS 0.00), 느린 기기에서도 즉시 반응해야 하고(TBT 0ms), 오프라인에서도 안내 페이지가 떠야 한다는 요구사항을 기술로 풀었다. 목사님을 위한 관리자 CMS도 최대한 간편하게, 클릭 몇 번으로 콘텐츠를 올릴 수 있도록 설계했다.

번들 크기와 복잡성을 줄이는 결정들을 의식적으로 했다. Zustand 대신 useSyncExternalStore로 번들을 줄이고, useState 범벅 대신 useActionState로 Server Actions와 폼 상태를 통합했다. 통신 비용을 아끼기 위해 이미지를 클라이언트에서 WebP로 압축한 뒤 서버로 전송하고, 서버에서도 Zod로 한 번 더 검증하는 이중 구조를 만들었다.

SSG 기반 렌더링 전략과 SEO 최적화가 실제 결과로 이어졌다. JSON-LD 구조화 데이터, sitemap, robots.txt까지 직접 설계했고, 현재 '만나교회' 검색 시 수백 개의 동명 교회 사이트 중 2번째로 노출된다. SSR로 HTML 뼈대를 미리 만들어두고 메타데이터를 꼼꼼히 채운 결과다.

모노레포 아키텍처와 렌더링 전략에 대해 가장 깊이 고민한 프로젝트였다. 이론으로만 알던 것들이 실제 트러블슈팅과 성능 수치로 돌아왔을 때, 왜 그 결정이 맞았는지 체감할 수 있었다.

버스커와 팬이 실시간으로 소통하는 공연 홍보 · 라이브 스트리밍 · 결제 기반 팬 플랫폼

• 기간: 2025.05.02 ~ 2025.07.15
• 역할: 프론트엔드 전체 (1인 전담)
• 프로젝트 성격: 신세계 Spharos Academy 기업연계 프로젝트
• GitHub: 프로젝트 GitHub
• 인원: 총 4명 (프론트엔드 1명, 백엔드 3명)

• User App, Busker App 두 개의 Next.js 앱을 독립적으로 운영하면서 UI 컴포넌트, ESLint 설정, Tailwind 설정, TypeScript 설정이 각 앱에 중복 존재
• 공통 컴포넌트 수정 시 두 앱을 각각 수정해야 하는 유지보수 비용 발생
• 설정 파일이 파편화되면서 앱 간 코드 스타일 불일치 발생

1. Turborepo + pnpm 워크스페이스 기반 모노레포 구성
2. 공통 패키지 4개(ui, eslint-config, tailwind-config, typescript-config) 모듈화 및 분리
3. Tailwind JIT + @source 디렉티브로 packages/ui 최적화
4. Husky 커스텀 스크립트로 커밋·푸시 전 린트·빌드 자동 검증

• 공통 로직 모듈화로 코드 중복 최소화 및 유지보수성 향상
• 설정 일원화로 앱 간 코드 스타일 일관성 확보
• DeepSource 정적 분석 및 AI 어시스턴트(MCP) 도입으로 1인 개발 환경에서 코드 품질 상시 모니터링 체계 구축

• WebRTC 단일 스트리밍 방식으로 시청자 환경을 구성했을 때 네트워크 상태에 따라 버퍼링 빈번 발생
• 고정 비트레이트로 인해 저사양·저속 네트워크 환경의 시청자는 지속적인 끊김 경험
• 버스커(송출)와 시청자(수신)의 요구사항이 달라 단일 기술로 두 역할을 최적화하기 어려움

1. 역할 분리 설계: Busker App은 WebRTC + MediaRecorder로 200ms 청크 단위 실시간 송출 담당
2. User App은 HLS.js 기반 적응형 비트레이트(ABR) 스트리밍으로 시청 담당
3. 네트워크 상태에 따라 HLS.js가 자동으로 화질을 조정하여 끊김 없는 재생 보장

• 송출·시청 환경 각각 최적화, 다수 접속 상황에서도 끊김 없는 양방향 소통 서비스 시연 성공
• 역할별 최적화된 스트리밍 아키텍처 확립

• 프론트엔드 1인, 백엔드 3인 체제로 진행되며 API 개발 속도 차이나 명세 누락이 발생할 경우, 프론트엔드 화면 단 연동에 심각한 병목이 발생할 위험이 컸음.
• 다수의 백엔드 개발자가 각기 다른 도메인(채팅, 스트리밍, 결제)을 개발하고 있어, 통합된 커뮤니케이션 채널 부재 시 일정 딜레이가 우려됨.

• Notion을 활용하여 주 단위 스프린트 백로그를 구성하고, 작업 진행 상황을 투명하게 시각화함.
• 개발 착수 전, 화면 요구사항을 바탕으로 백엔드 팀과 API 인터페이스 및 엔드포인트를 주도적으로 사전 조율함.

• API 명세 변경으로 인한 프론트엔드 재작업을 방지하고 연동 대기 시간을 최소화함.
• 다수결의 백엔드 요구사항 속에서도 일정 지연 없이 2.5개월 만에 실시간 스트리밍 SNS의 프론트엔드 전 과정을 성공적으로 완주함.

MSA 아키텍처를 도입한 백엔드와 Turborepo 기반 모노레포 프론트엔드를 조합하면서, 초기에는 각 시스템의 독립성과 모듈화를 성공적으로 달성했다.

하지만 서비스가 확장될수록 CI/CD 파이프라인 통합, 공통 환경변수 관리, 배포 간 연동 테스트 자동화 등에서 많은 시행착오를 겪었다. 단일 서비스 구조보다 MSA + 모노레포 조합은 운영 복잡도가 훨씬 높다는 점을 직접 체감했다.

프론트엔드 1인으로 기획부터 설계, 개발, 배포, 모니터링까지 서비스 전 과정을 수행하면서, 동료 없이 코드 품질을 지키기 위해 정적 분석 도구와 AI 어시스턴트를 적극적으로 활용했다. 기술 도구로 1인 개발의 한계를 극복하는 방법을 배운 프로젝트였다.

• 신세계 Spharos Academy 기업연계 프로젝트 우수상 (2등) 수상 (2025.07.15)
• 구조적 완성도 및 실시간 서비스 구현에서 높은 평가를 받으며 우수팀으로 선정
• Google Search Console 인덱싱을 통한 실제 서비스 수준의 SEO 기반 마련

Next.js 15 + React 19 기반으로 스타벅스 온라인 쇼핑몰을 리뉴얼하며 SSR/CSR 혼합 구조, Optimistic UI, 태그 기반 캐싱 전략을 실무 수준에서 적용한 프로젝트

• 기간: 2025.03.10 ~ 2025.04.28
• 역할: 프론트엔드 (메인 페이지, 상품 상세페이지, 장바구니)
• GitHub: 프로젝트 GitHub
• 인원: 총 5명 (프론트엔드 1명, 백엔드 4명)

• Frontend: Next.js 15, React 19, Zustand, shadcn UI, Tailwind CSS
• Backend: Spring Boot 3.4.4, Spring Security, Spring Data JPA, QueryDSL, MySQL 9.2.0, JWT
• Infra: AWS EC2, GitHub, Notion, Slack

• 클릭 시 서버 데이터 패칭이 완료될 때까지 UI가 반영되지 않아 사용자가 느리게 느끼는 UX 발생

• useOptimistic 훅으로 클릭 즉시 UI 반영, 백그라운드에서 서버 동기화 처리

• 서버 응답과 무관하게 UI 즉시 반영, 사용자 체감 속도 및 반응성 향상

• useOptimistic은 컴포넌트 로컬 상태 기반으로 동작하여 화면 하단 등 다른 컴포넌트와 상태 공유 불가
• Optimistic UI 적용 시 상태 변경이 일부 컴포넌트에만 반영되는 불일치 발생

• Zustand 도입으로 글로벌 상태 관리 전환
• Optimistic UI 상태와 전역 상태를 동기화하는 구조로 재설계

• 전역 상태와 Optimistic UI 상태 동기화 관리 가능한 구조 확립
• 컴포넌트 간 상태 불일치 해소

• Zustand로 상태가 전역으로 연결되면서 체크박스 연속 클릭 시 API가 여러 번 호출되어 서버 부하 및 DB 트래픽 증가

• 커스텀 훅(useDebouncedFetch) 개발
• 클릭 시 UI는 즉시 반영하되 서버 요청은 debounce/throttle 처리
• API 요청 중 추가 요청 차단, 요청 실패 시 로컬 상태 롤백

• API 요청량 절감, 서버 부하 감소 및 네트워크 트래픽 최적화
• 요청 실패 시 상태 롤백으로 데이터 정합성 유지

• 상태 변화마다 모든 컴포넌트가 리렌더링되어 퍼포먼스 저하 발생
• 콜백 함수가 매 렌더링마다 새로운 인스턴스로 생성되어 하위 컴포넌트의 불필요한 리렌더링 유발

1. useCallback으로 콜백 함수 메모이제이션, 불필요한 함수 인스턴스 생성 방지
2. React.memo로 prop 변경 없을 시 컴포넌트 리렌더링 방지

• 데이터 변경 시 모든 API 요청 캐시를 일괄 무효화하여 필요 없는 요청까지 갱신
• 장바구니처럼 개별 상품, 리스트, 배송지 등 다양한 단위의 데이터가 혼재하여 캐시 관리 어려움

1. fetch 요청에 next: { tags: [...] } 옵션으로 캐시 단위 세분화
2. 데이터 변경(POST, PUT, DELETE) 시 정확한 revalidateTag() 호출로 관련 태그만 무효화
3. 목록 데이터와 단건 데이터는 별도 태그로 분리 관리

주요 태그 설계:

• CartItem:uuid → 장바구니 개별 상품, 변경 시 해당 상품만 무효화
• CartUuidsList-cartType → 장바구니 리스트, 전체 선택·삭제 후 무효화
• Product-uuid → 상품 상세, 수정 시 해당 상품만 무효화
• cart:address-uuids-list, cart:address-detail-uuid → 배송지 리스트·상세 분리 캐싱

• 필요한 데이터만 갱신하여 불필요한 API 호출 최소화
• 복잡한 상태 변화에도 캐시 동기화 정확도 유지

공부하면서 이론으로만 알던 Next.js 렌더링 전략을 처음으로 실제 서비스에 적용해본 프로젝트였다. SSR을 도입하면 무조건 좋을 거라 생각했는데, 오히려 SSR로 전환했을 때 사용자 경험이 내려가는 지점이 생겼다. 서버 응답 대기 시간 동안 아무것도 보이지 않는 구간이 생기면서, 렌더링 전략은 무조건 최신이 답이 아니라 페이지 성격에 따라 전략을 골라야 한다는 걸 직접 체감했다. 실제로 SSR과 CSR을 적재적소에 배치하는 전략을 통해 SEO 점수 향상 (Lighthouse SEO 점수 68 → 80)을 경험할 수 있었다.

React 19의 useOptimistic, useActionState와 Next.js 15의 revalidateTag 기반 캐싱 전략을 실무 수준에서 처음 도입해봤다. 트러블슈팅을 보면 알 수 있듯, 하나를 해결하면 다음 문제가 생기는 연쇄적인 흐름이었다. 단계별로 문제를 마주하고 해결하면서 기술을 단순히 쓰는 것과 구조를 설계하는 것이 다르다는 걸 배웠다.

백엔드 4인과의 협업이 특히 좋았다. 내가 구조를 설계하고 피드백받고, 다시 개발하고 피드백받는 사이클이 반복되면서 API 응답 형식, 에러 핸들링, 예외 상황 처리 방식이 점점 단단해졌다. 혼자 개발할 때는 보이지 않던 것들이 협업 과정에서 드러났고, 그 과정에서 프론트가 주도적으로 방향을 잡는 경험을 할 수 있었다.

• 프로젝트명: FSD 아키텍처 기반 기술 블로그
• 진행 기간: 2025.11 ~ 현재 운영 중
• 팀 구 성: 1명
• 담당 역할: 프론트엔드 아키텍처 설계, 개발 및 배포 전 과정 수행
• 배포 링크: demopeu.vercel.app
• GitHub: 저장소 링크 (각 트러블슈팅 및 아키텍처 의사결정(ADR)에 대한 상세한 기록은 GitHub README에서 확인하실 수 있습니다.)

전체적인 아키텍처

• Frontend: Next.js 16, React 19, Tailwind CSS v4
• Architecture / Infra: Feature-Sliced Design (FSD), Turborepo (Monorepo), Vercel Microfrontends

문제 원인 및 해결 과정

• [모노레포 마이그레이션 및 빌드 최적화]
  • 문제: 멀티레포 환경에서 UI 컴포넌트와 설정 파일의 중복이 발생하고, 의존성 동기화의 복잡성이 증가함.
  • 해결: Turborepo를 도입하여 apps와 packages로 분리하는 모노레포 구조를 설계하고 공통 모듈을 패키지화함. 증분 빌드(Incremental Build)와 함수 수준 캐싱을 적용하여 초기 180초였던 빌드 시간을 40초로 약 77% 단축함.
• [Tailwind v4 JIT 스캔 한계 극복]
  • 문제: Tailwind v4가 앱 소스만 스캔하여, 분리된 packages/ui 내부의 유틸리티 클래스가 빌드된 CSS에 포함되지 않는 현상 발생.
  • 해결: 선택적 @source 지시어를 활용해 UI 패키지의 컴포넌트 디렉토리만 명시적으로 스캔하도록 전략을 구성하여 동적 클래스명 누락을 방지하고 CSS 번들 크기를 최소화함.
• [Vercel Microfrontends 도입으로 RSC 404 에러 해결]
  • 문제: Multi-Zone 배포를 위한 Reverse Proxy 환경에서, 브라우저 단에서 직접 발생하는 RSC(React Server Components)의 prefetch 요청을 프록시가 가로채지 못해 404 에러가 발생함.
  • 해결: @vercel/microfrontends를 도입하고 커스텀 Link 컴포넌트를 구현하여, 클라이언트 레벨에서 크로스존(Cross-Zone) 라우팅을 가로채고 처리하는 방식으로 근본적인 네비게이션 문제를 해결함.
• [Next.js Reverse Proxy 정적 자산 404 에러 해결]
  • 문제: vercel.json으로 프록시 구성 시 CSS/JS 번들 파일 등 정적 자산 경로 문제로 404 에러가 발생함.
  • 해결: Multi Zones 패턴을 적용하여 basePath: '/blog' 설정 및 redirects를 구성해 모든 정적 자산 경로에 prefix를 추가했으며, 최종적으로 Microfrontends 패키지 도입을 통해 basePath 없이도 완벽하게 문제를 해결함.

결과 및 회고

• FSD 패턴의 계층적 의존성 규칙을 적용하여 확장성과 유지보수성이 뛰어난 프론트엔드 구조를 설계.
• 아키텍처 도입, 모노레포 마이그레이션, 마이크로프론트엔드 라우팅 등 복잡한 기술적 의사결정 과정과 트러블슈팅을 ADR(Architecture Decision Record) 기반으로 체계적으로 문서화하여 기술 선택의 타당성을 입증.
• 프레임워크 내부 동작 원리(RSC prefetch 등)를 파악하여 구조적인 문제를 해결.

프로젝트 설명: 실시간 댓글 요약 AI 플랫폼으로, 게시글에 달린 깊이 제한 없는 무한 댓글 쓰레드를 제공하고 각 쓰레드의 요약 정보를 AI가 실시간 생성하여 보여주는 기능을 구현한 프로젝트

• 프로젝트 명: 실시간 댓글 요약 AI 플랫폼
• 진행 기간: 2024.10.28 ~ 2024.11.19 (약 3주)
• 팀 구 성: 총 5명 (프론트엔드 1, 백엔드 2, AI 2)
• 담당 역할: 프론트엔드 전담 및 팀장

전체적인 아키텍처

• Frontend: Next.js 14, React 18, Tailwind CSS

구현 화면 및 주요 기능

댓글 페이지	대댓글 페이지	요약 기능

• 무한 대댓글: 깊이 제한 없는(무한 뎁스) 대댓글 로직 직접 설계 및 API 페이징 연동
• 댓글 페이징: localStorage를 활용해 새로고침이나 페이지 이동 후에도 사용자의 이전 위치(페이지 상태) 유지

문제 원인 및 해결 과정

• [트리 구조 렌더링 최적화]
  • 문제: 서버 API가 parent_idx만 포함된 1차원(flat) 형태의 리스트 데이터만 제공하여, 무한 뎁스의 대댓글을 화면에 계층적으로 그려내기 어려움.
  • 해결: 프론트엔드 단에서 parent_idx를 기반으로 한 계층화 로직을 작성하고 children 배열을 생성하여 트리 구조로 데이터를 변환, 뎁스가 증가해도 렌더링 시간과 메모리 사용량을 최소화함.
• [UX 및 네트워크 성능 개선]
  • 문제: 댓글 작성 후 1페이지로 리셋되어 사용자 동선이 끊기거나, 최상위 댓글 조회(fetchTopLevelComments)가 반복 호출되어 서버 부하가 발생함.
  • 해결: localStorage로 페이지 상태를 복원하여 UX를 개선하고, refetch + skeleton UI 전략을 도입하여 불필요한 API 요청과 네트워크 트래픽을 감소시킴.

결과 및 회고

• SSAFY 기업 연계 실무 프로젝트로서, 기업이 요구한 기술적/기능적 조건(무한 대댓글, 실시간 요약 등)을 구현하여 실제 결과물 코드가 업무에 활용됨.
• 사용자 경험에 중점을 두고 구조를 설계한 결과, UX 평가에서 "댓글 흐름과 동선이 자연스럽다"는 긍정적인 피드백을 획득함.
• 프론트엔드 1인 개발과 동시에 팀장 역할을 수행하며 매일 아침 스크럼 진행 및 데일리 목표를 공유하였고, 전체 일정 조율과 프로젝트 방향성을 이끄는 협업을 경험함.

• 프로젝트명: 버츄얼 아이돌 팬 페이지
• 진행 기간: 2024.09 (약 1주)
• 팀 구 성: 1명
• 담당 역할: 프론트엔드 기획, UI/UX 디자인, 개발 및 배포 전 과정 단독 수행
• 배포 링크: 팬페이지 바로가기

전체적인 아키텍처

• Frontend: React, react-router-dom, SweetAlert2, CSS
• Infra/Deploy: Firebase Hosting

문제 원인

• React 기반의 SPA로 개발 후 Firebase Hosting에 배포했으나, 특정 라우팅 경로에서 새로고침 시 서버가 해당 경로의 정적 파일을 찾지 못해 404 Not Found 에러가 발생함.
• 달력 UI에서 날짜 요소에 마우스 오버 및 클릭 시, hover, opacity, transform 등의 CSS 애니메이션 속성들이 겹치면서 클릭 이벤트 영역에 미세한 오작동이 발생함.

해결 과정

• [SPA 라우팅 이슈 해결] Firebase 환경 설정 파일(firebase.json)의 rewrites 속성을 수정하여, 모든 경로(**)에 대한 요청을 클라이언트 라우터의 진입점인 index.html로 향하도록 설정해 SPA 라우팅 문제를 해결함.
• [UI 인터랙션 최적화] 달력의 clickable 클래스에 적용된 transition 속성을 세밀하게 재조정하고, transform의 scale 변경 범위를 최적화하여 애니메이션 충돌을 방지하고 부드러운 사용자 경험을 구현함.

결과

• 기획 단계부터 React 컴포넌트 설계, 상태 관리, react-router-dom을 활용한 월간 이동 라우팅, 서버리스 배포까지 프론트엔드 사이클 전체를 완수함.
• SPA의 클라이언트 사이드 라우팅 원리와 배포 환경 간의 관계 이해, React의 이벤트 흐름, 라우팅 처리, CSS 레이아웃 구조 이해.

• 프로젝트명: 영화 추천 서비스 - TWM (Travel With Movies)
• 진행 기간: 2024.05.08 ~ 2024.05.23
• 팀원: 2명 (풀스텍 1, 백엔드 1)
• 역할: 프론트엔드 전반, UI/UX 디자인, Django 연동 일부까지 담당
• GitHub: 프로젝트 GitHub

전체적인 아키텍처

• Frontend: Vue.js, Bootstrap, Figma (UI/UX 디자인)
• Backend: Python, Django

문제 원인

• 기획 단계에서 페이지 전체 단위로만 UI를 설계하다 보니, 실제 Vue.js 개발에 돌입했을 때 반복되는 UI 요소의 재사용성이 떨어지고 코드 유지보수가 어려워지는 문제 발생.
• 프론트엔드와 백엔드(Django)를 분리하여 개발하고 API를 연동하는 과정에서 CORS 에러가 발생하여 데이터 통신이 차단됨.

해결 과정

• [컴포넌트 설계] 화면을 NavBar, CountrySelector, MovieCard 등 독립적인 단위로 쪼개고, Vue.js의 prop과 slot을 적극 활용하여 재사용 가능하고 확장성 높은 컴포넌트 구조로 리팩토링함.
• [통신 및 UX 개선] Django corsheaders 미들웨어 설정 및 Vue 프록시 환경 구성을 통해 통신 에러를 해결함. 더불어 위시리스트 추가 시 즉각적인 시각적 피드백(색상 변경 및 알림 메시지)을 구현하여 디테일한 사용자 경험(UX)을 개선함.

결과

• 디자이너 없이 UI/UX 디자인부터 기능 구현까지 단독 수행, Vue.js + Bootstrap으로 SPA 반응형 인터페이스 설계 경험
• 컴포넌트화, 상태 관리, 라우팅, 백엔드 연동까지 직접 다루며 프론트 중심의 풀스택 개발 경험 축적
• Django API 연동 및 Axios 사용, CORS 이슈 해결을 통해 프론트-백 간의 통신 구조에 대한 실무 이해도 향상

• 프로젝트명: 인물 퀴즈쇼
• 진행 기간: 2024.04 ~ 2024.04 (3주)
• 인원: 4명
• 참고 링크: https://www.ssafy11th-songsam.site

전체적인 아키텍처

• Frontend: HTML, CSS, Vanilla JavaScript
• Backend: Python, Django

문제 원인

• 백엔드의 데이터(API) 구현 및 전달이 지연되면서, 프론트엔드에서 화면과 로직을 붙여볼 수 없어 전체적인 개발 일정이 늦춰지고 팀원 간 작업 속도 차이로 인한 협업 갈등이 발생함.

  해결 과정

• 백엔드의 개발 상황을 이해하고 작업 병목 현상을 해소하기 위해, 프론트엔드에서 화면 테스트용 더미 데이터를 직접 제작함.

• 서버 개발이 완료될 때까지 기다리지 않고 독립적으로 JS 로직(퀴즈 결과 제어 등)을 우선 구현하여 백엔드의 부담을 줄이고 작업 속도를 유연하게 맞춤.

결과

• 백엔드와 프론트 간의 상황 이해 및 갈등 해결.
• 생애 처음으로 화면 구동부터 서버 통신까지 동작하는 웹 페이지를 완성했으며, 실제 30명의 사용자가 직접 퀴즈쇼를 이용해 보는 유의미한 첫 서비스 배포 경험을 달성함.

• 프로젝트명: 자율 주행 보드를 활용한 무인 주차 서비스

• 기간 / 인원: 2024.07.08 ~ 2024.08.16 (6주), 6명

• 개요: 자율 주행 보드를 활용해 차량의 무인 주차 시스템을 제공하는 서비스로, 사용자 편의를 극대화하고 주차장 관리자의 운영 효율성을 높임

• 기술 / 환경:

  • 백엔드(BE): Java 17, SpringBoot, RabbitMQ 3.13.6
  • 임베디드 시스템(EM): Python 3.11.2, C++, ROS noetic, Mosquitto 2.0.11
  • AI: Python 3.9.13, Gymnasium, stable-baselines3 2.3.2, highway-env 1.8.2, CUDA 12.1

• 담당 역할:

  • 팀장
  • 강화학습 환경 제작
  • 핵심 알고리즘 설계 및 실제 환경 조성

• 구현 사항: 강화학습 기반 자율 주차 모델 개발

  • 강화 학습 환경 제작:
    • 강화학습을 위한 시뮬레이션 환경 구축

• 핵심 알고리즘 설계:

  • Soft Actor-Critic (SAC) 알고리즘과 Hindsight Experience Replay (HER) 알고리즘 적용
  • 모델의 학습 효율성을 높이기 위한 최적화 작업

• 실제 환경 조성:

  • 실물 차량과 자율 주행 보드의 통합

• 성과 / 학습:

  • 성과:
    • 강화학습 기반 자율 주차 모델의 성공적인 구현
    • 500만번 중 0번의 사고 발생
  • 학습:
    • 강화학습 모델의 설계 및 최적화 경험 축적
    • 팀 리더로서의 프로젝트 관리 및 팀원 간의 효과적인 커뮤니케이션 능력 향상

• 참고 링크:

  • AI README.md
  • 프로젝트 기획서
  • API 명세서
  • 목업
  • 포팅 메뉴얼

• 프로젝트명: O-OTd - 패션 추천 서비스

• 기간 / 인원: 2024.08.26 ~ 2024.10.25 (6주), 6명

• 개요: "O-OTd"는 남성들이 자신의 스타일을 손쉽게 찾고, 새로운 패션을 발견할 수 있도록 돕는 패션 추천 및 참고 서비스. 사용자들은 언제 어디서나 자신의 개성을 표현할 수 있는 스타일을 쉽게 탐색하고, 유사한 스타일을 추천받아 새로운 패션에 도전할 수 있게 해주는 어플리케이션.

• 기술 / 환경:

  • Frontend: Typescript, React-native, NodeJs, Axios, Zustand
  • Backend: Java, Spring Boot, Spring Cloud, Eureka, MySql, Redis
  • Infra: Docker, Docker Compose, Nginx, Kafka, Zookeeper
  • CI/CD: Jenkins

• 담당 역할:

  • AI 개발
  • AI 모델을 사용한 API 개발

• 구현 사항: AI 기반 패션 추천 시스템 개발:

  • ImageFusion API 개발:

    • 목표: YOLO 모델을 사용하여 이미지에서 특정 클래스를 감지하고, 감지된 정보를 기반으로 6차원 벡터를 생성하여 외부 클러스터 예측 서버로 전송하는 API 개발.
    • 역할:
      • YOLO 모델 통합 및 이미지 처리 파이프라인 설계.
      • 6차원 벡터 생성 로직 구현.
      • 외부 클러스터 예측 서버와의 데이터 통신 API 개발 및 최적화.

  • AI LENS 기능 개발:

    • 목표: 사용자 스타일을 분석하고, 유사한 스타일을 추천하는 AI 기반 렌즈 기능 개발.
    • 역할:
      • 스타일 분석 모델 설계 및 학습.
      • 추천 알고리즘 개발 및 테스트.
      • 프론트엔드와의 연동을 위한 API 인터페이스 설계.

• 성과 / 학습:

  • 성과:

    • AI 기반 패션 추천 시스템을 성공적으로 구현하여 사용자 만족도 25% 향상.
    • AI LENS 기능 출시 후 사용자 참여도 30% 증가.

  • 학습:

    • 머신러닝 모델 학습 및 최적화 경험 축적.
    • 팀 협업을 통한 문제 해결 및 프로젝트 관리 능력 향상.

• 참고 링크:

  • 객체 인식 AI README.md
  • 앙상블 기반 AI README.md
  • 프로젝트 기획서

• 프로젝트명: IMS (I’m Solo)
• 기간 / 인원: 2025.05.23 ~ 2025.05.25 (2일), 1명
• 개요: GitHub Pull Request(PR)에 자동으로 시맨틱 리뷰를 생성하여 댓글로 남기는 AI 코드 리뷰 시스템 개발
• 기술 / 환경: TypeScript, Fastify, Node.js, LLaMA 3
• 담당 역할: 전체 시스템 설계 및 개발, GitHub Webhook 연동, LLM 기반 리뷰 로직 구현
• 구현 사항:
  • PR 이벤트 감지 및 diff 코드 추출
  • LLaMA 3 기반 자연어 리뷰 생성 및 프롬프팅
  • 리뷰 내용을 한국어로 Markdown 포맷화 후 자동 댓글 작성
  • 리뷰 로그 JSON 저장 시스템 구축
• 성과 / 학습:
  • GitHub Webhook을 활용한 자동화 서비스 개발 경험
  • LLM을 활용한 코드 리뷰 자동화 로직 설계 및 적용
  • 실사용 워크플로우에 AI 리뷰 기능을 통합하는 시스템 구축 역량 향상
• 참고 링크:
  • IMS (I’m Solo)