[UNIKER] CampusLog, 디자인 문서에서 실제 MVP 구현 단계로 넘어가다

UNIKER 활동을 진행하면서 저희 팀 핏줄은 CampusLog를 실제로 작동하는 MVP로 만들기 위한 개발을 본격적으로 시작했습니다.

이전까지는 PRD.md, README.md, AGENTS.md, USER_FLOW.md, SCREEN_SPEC.md 등을 중심으로 문제 정의, 사용자 흐름, 화면 구조, Codex 협업 규칙을 정리하는 데 집중했습니다.

이번에는 그 문서들을 바탕으로 실제 화면과 기능을 구현하는 단계로 넘어갔습니다.

 

특히 이번 기간에는 다음 작업들이 이어졌습니다.

• 7월 7일 라이브 강의 수강
• 기존 .md 문서 재검토
• DESIGN.md 최종 확정
• IMPLEMENTATION_PLAN.md 작성
• 작업 브랜치와 PR 단위 확정
• Next.js 기반 기본 구조 구현
• 경험 기록 CRUD 구현
• AI 분석 기능 구현
• AI 추천 기능 구현
• 대시보드와 반응형 디자인 고도화
• 7월 12일 멘토링을 통한 방향 점검

처음에는 “문서를 잘 정리하면 Codex가 알아서 잘 만들어주지 않을까?”라는 기대도 있었습니다. 하지만 실제로 개발을 시작해보니, 문서는 개발을 대신해주는 것이 아니라 개발 방향이 흔들리지 않도록 잡아주는 기준에 가깝다는 것을 느꼈습니다.

7월 7일 라이브 강의: 화면 구조를 첫 프로토타입으로 연결하기

7월 7일에는 UNIKER 라이브 강의를 들었습니다.

이번 강의에서는 단순히 예쁜 화면을 만드는 것보다, 사용자의 흐름과 화면 구조를 실제 프로토타입으로 연결하는 방법을 중심으로 배웠습니다.

이전까지 저희 팀은 문제 정의, 사용자 흐름, 화면 명세를 문서로 정리해두었지만, 아직 실제 화면으로 구현되지는 않은 상태였습니다. 강의를 들으면서 USER_FLOW.md, SCREEN_SPEC.md, DESIGN.md가 따로 존재하는 문서가 아니라, 결국 하나의 제품 화면으로 이어져야 한다는 점을 다시 확인할 수 있었습니다.

특히 기억에 남았던 부분은 “디자인 완성이 먼저가 아니라, 사용자가 어떤 화면에서 무엇을 입력하고 어떤 결과를 받는지가 먼저”라는 흐름이었습니다.

그래서 저희 팀도 디자인을 단순히 색상이나 분위기만 정하는 것이 아니라 CampusLog의 핵심 흐름을 방해하지 않는 기준으로 정리하기로 했습니다.

 

라이브 강의 내용은 따로 정리한 블로그에 기록해두었습니다.

라이브 강의 정리 글: https://mkisos.tistory.com/entry/uniker5

기존 문서를 다시 검토하다

강의 이후에는 팀원들과 기존 .md 문서들을 다시 검토했습니다.

검토한 문서는 다음과 같습니다.

README.md
PRD.md
AGENTS.md
docs/GIT_WORKFLOW.md
docs/USER_FLOW.md
docs/IA.md
docs/SCREEN_SPEC.md
docs/DESIGN.md
docs/IMPLEMENTATION_PLAN.md
docs/TODO.md
docs/WORK_STATUS.md
docs/TASK_LOG.md
docs/ISSUE_LOG.md

 

문서를 다시 본 이유는 단순히 과제 제출용 문서를 확인하기 위해서가 아니었습니다.

이제 실제 개발에 들어가야 했기 때문에, 문서끼리 서로 충돌하는 내용이 없는지, MVP 범위를 벗어난 기능이 섞여 있지는 않은지, 개발자가 바로 작업 단위로 쪼갤 수 있는지 확인해야 했습니다.

 

특히 다음 기준을 중심으로 봤습니다.

 

MVP 범위 밖 기능이 들어가 있지 않은가
로그인, DB, 파일 업로드, 외부 연동 같은 기능이 1차 MVP에 섞여 있지 않은가
사용자 흐름과 화면 구조가 자연스럽게 이어지는가
Codex가 참고할 기준 문서가 명확한가
작업 브랜치와 PR 단위로 나눌 수 있는가
팀원들이 같은 기준으로 이해할 수 있는가

 

이 과정을 거치면서 문서가 단순히 많다고 좋은 것이 아니라, 각 문서가 같은 방향을 바라보고 있어야 한다는 것을 느꼈습니다.

AGENTS.md 보강: Codex가 따라야 할 작업 규칙 정리

지난 멘토링에서 가장 중요하게 들었던 피드백 중 하나는 AGENTS.md에 대한 내용이었습니다.

Codex가 프로젝트 안의 모든 문서를 매번 알아서 참고한다고 기대하면 안 되고, 어떤 작업을 할 때 어떤 문서를 먼저 봐야 하는지 AGENTS.md에 명확히 적어두어야 한다는 피드백이었습니다.

그래서 AGENTS.md를 보강했습니다.

작업 유형별로 어떤 문서를 먼저 확인해야 하는지 정리하고, 기능 작업, UI 작업, 문서 작업, AI 분석/추천 작업, Git/PR 작업의 기준을 명확히 했습니다.

 

또한 구현 에이전트와 리뷰 에이전트를 분리하는 규칙도 넣었습니다.

개발을 수행한 AI가 자기 코드를 다시 리뷰하면 놓치는 부분이 생길 수 있기 때문에, 리뷰는 별도의 관점에서 진행하도록 정리했습니다.

리뷰 기준도 다음처럼 나누었습니다.

critical: 보안, 데이터 손실, 핵심 흐름 불능
major: 주요 기능을 사용할 수 없는 문제
minor: UI, 문구, 네이밍, 작은 정합성 문제
suggestion: 다음 작업에서 개선하면 좋은 제안

 

이번 작업을 통해 AGENTS.md는 단순한 규칙 문서가 아니라, Codex와 함께 일하기 위한 팀의 작업 매뉴얼에 가까워졌습니다.

DESIGN.md 확정: 대학생활을 단권화하는 AI 경험 기록장

7월 8일과 9일에는 팀원들과 디자인 방향을 정리했습니다.

처음에는 어떤 UI가 좋을지 막연했습니다. 개발 전공자가 모인 팀이다 보니 디자인을 어디까지 잡아야 할지, 어느 정도까지 Codex에게 맡겨도 되는지 고민이 많았습니다.

그래서 여러 레퍼런스를 찾아보고, CampusLog의 서비스 성격에 맞는 디자인 컨셉을 정리했습니다.

최종적으로 정한 대표 컨셉은 다음과 같습니다.

대학생활을 단권화하는 AI 경험 기록장

CampusLog는 대학생의 프로젝트, 공모전, 대외활동, 인턴, 수상, 블로그, GitHub 기록처럼 흩어진 경험을 하나의 기록장에 정리하는 서비스입니다.

 

그래서 단순한 대시보드보다는 “노트”, “기록장”, “책갈피”, “다시 꺼내보기” 같은 이미지가 잘 맞는다고 판단했습니다.

디자인 방향은 다음처럼 정리했습니다.

 

대표 컨셉: 노트 / 단권화
핵심 메시지: 대학생활을 단권화하는 AI 경험 기록장
메인 컬러: 캠퍼스 그린 + 민트
파비콘 방향: 책갈피가 꽂힌 노트
기능 시작점: /dashboard
브랜드 시작점: /의 인터랙티브 3D 노트 표지
데스크톱 구조: 좌측 사이드바형 대시보드
모바일 구조: 상단 앱 바 + 세로 스크롤 중심

또한 이번 프로젝트에서는 디자인 표현을 너무 보수적으로 제한하지 않기로 했습니다.

Three.js, React Three Fiber, WebGL, Framer Motion, GSAP 같은 고급 표현 방식도 성능과 접근성을 해치지 않는 선에서는 사용할 수 있도록 열어두었습니다.

 

그 결과 현재 CampusLog의 첫 화면은 단순한 랜딩 페이지가 아니라, 사용자가 3D 노트 표지를 선택해 대시보드로 들어가는 형태로 발전했습니다.

IMPLEMENTATION_PLAN.md 작성: 개발을 기능 단위로 나누기

디자인 방향을 정한 뒤 바로 개발을 시작하지는 않았습니다.

먼저 IMPLEMENTATION_PLAN.md를 작성해, 어떤 순서로 어떤 기능을 개발할지 정리했습니다.

 

CampusLog의 1차 MVP는 다음 핵심 흐름을 목표로 잡았습니다.

메인/경험 목록 대시보드
활동 경험 작성
활동 경험 상세
AI 분석 요청
AI 경험 분석 결과 저장
AI 경험 추천 및 활용
추천 경험 1개와 활용 문장 확인

이 흐름을 만들기 위해 개발 단계를 다음처럼 나누었습니다.

 

1단계: base-structure
Next.js App Router 기반 기본 구조, 라우트, AppShell, Navigation, 공통 스타일 준비

2단계: experience-crud
localStorage 기반 활동 경험 작성, 목록, 상세, 수정, 삭제 구현

3단계: ai-analysis
특정 활동 경험을 AI로 분석하고, 요약, 역량 태그, 주요 성과, 키워드를 저장

4단계: ai-recommendation
저장된 경험 전체와 분석 결과를 기준으로 목적에 맞는 경험 1개 추천

5단계: dashboard-polish
대시보드 정보 구조, 빈 상태, 로딩 상태, 분석 상태 배지, CTA 위계 정리

6단계: responsive/brand-polish
캠퍼스 그린 + 민트 브랜드 톤, 반응형 레이아웃, 모바일 CTA, 카드 간격 정리

7단계: QA/refinement
실제 사용자 흐름을 따라가며 오류, 빈 상태, 실패 상태, 모바일 사용성 검증

 

이렇게 작업을 나누니 “무엇부터 만들어야 할지”가 훨씬 명확해졌습니다.

또한 기능 개발과 디자인 고도화를 같은 PR에 섞지 않기로 했습니다. 기능 로직은 기능 브랜치에서 먼저 안정화하고, 디자인 고도화는 별도 브랜치에서 진행하는 방식으로 정리했습니다.

본격적인 개발 시작: base-structure 구현

먼저 feature/base-structure 작업을 통해 Next.js 기반 프로젝트 골격을 만들었습니다.

이 단계에서는 실제 기능을 모두 구현하기보다, 앞으로 기능이 들어갈 수 있는 기본 구조를 잡는 데 집중했습니다.

구현한 내용은 다음과 같습니다.

 

Next.js App Router 기본 설정
web/ 폴더 구조 정리
메인 화면 라우트
대시보드 라우트
경험 작성 라우트
경험 상세 라우트
경험 수정 라우트
AI 분석 결과 라우트
AI 추천 라우트
공통 AppShell
Navigation
기본 타입 파일
공통 스타일

 

이 작업을 통해 CampusLog가 단순한 문서 프로젝트에서 실제 웹 애플리케이션 형태로 바뀌기 시작했습니다.

처음에는 빈 화면에 가까웠지만, 라우트와 레이아웃이 잡히면서 팀원들이 “이제 진짜 개발을 시작했다”는 느낌을 받을 수 있었습니다.

experience-crud 구현: 기록 서비스의 기본 흐름 만들기

다음으로는 feature/experience-crud 작업을 진행했습니다.

CampusLog의 가장 기본 기능은 활동 경험을 기록하고 다시 확인하는 것입니다.

AI 분석이나 추천 기능이 아무리 좋아도, 사용자가 경험을 저장할 수 없다면 서비스의 핵심이 성립하지 않습니다.

그래서 먼저 localStorage 기반으로 다음 흐름을 구현했습니다.

새 경험 작성
저장된 경험 목록 확인
경험 상세 조회
경험 수정
경험 삭제
새로고침 후에도 데이터 유지
경험 수정 시 재분석 필요 상태 처리

1차 MVP에서는 로그인과 DB를 제외했기 때문에, 데이터는 브라우저 localStorage에 저장했습니다.

저장 key는 campuslog:v1:experiences, campuslog:v1:analyses, campuslog:v1:recommendations처럼 버전을 붙여 관리하도록 했습니다.

사용자가 경험을 작성하면 상세 화면으로 이동하고, 수정하면 최근 수정일이 갱신되도록 구현했습니다. 기존 분석 결과가 있는 경험을 수정하면 재분석 필요 상태로 바뀔 수 있도록 저장 구조도 준비했습니다.

이 단계에서 CampusLog는 “경험을 기록하는 서비스”로서의 기본 흐름을 갖추게 되었습니다.

AI 분석 기능 구현: 경험을 역량과 성과로 정리하기

이후에는 feature/ai-analysis 작업을 진행했습니다.

AI 분석 기능은 저장된 특정 활동 경험을 바탕으로 다음 결과를 생성합니다.

경험 요약
핵심 역량 태그
주요 성과
활용 가능한 키워드
분석 생성일

 

OpenAI API는 클라이언트에서 직접 호출하지 않고, Next.js API Route인 /api/analyze를 통해 서버 측에서 호출하도록 구현했습니다.

API Key가 클라이언트에 노출되지 않도록 OPENAI_API_KEY는 서버 환경 변수에서만 읽도록 했습니다.

사용자는 활동 경험 상세 화면에서 AI 분석을 요청할 수 있고, 분석 결과는 해당 경험 ID에 연결되어 localStorage에 저장됩니다. 분석이 완료되면 경험의 상태도 분석 완료로 바뀝니다.

이 과정에서 API Key 환경 변수 문제도 있었습니다.

 

로컬 환경에서 기존 쉘에 남아 있던 OPENAI_API_KEY가 .env.local보다 우선 적용되어 invalid_api_key 오류가 발생했습니다. 이후 환경 변수를 정리하고 다시 실행하면서 문제를 확인하고 해결했습니다.

이 경험을 통해 API 연동에서는 코드뿐 아니라 실행 환경도 중요한 검증 대상이라는 것을 느꼈습니다.

AI 추천 기능 구현: 저장된 경험 중 가장 적합한 경험 찾기

다음 단계는 feature/ai-recommendation이었습니다.

AI 추천 기능은 사용자가 자기소개서 문항, 포트폴리오 작성 목적, 면접 질문 등을 입력하면 저장된 경험 전체와 분석 결과를 기준으로 가장 적합한 경험 1개를 추천하는 기능입니다.

1차 MVP에서는 여러 개의 추천 후보를 보여주지 않기로 했습니다.

처음에는 1순위, 2순위, 3순위 추천도 고민했지만, 추천 후보를 여러 개 보여주려면 비교 기준, 정렬 이유, 후보 간 차이 설명까지 필요해집니다. 그래서 1차 MVP에서는 가장 적합한 경험 1개를 정확하게 추천하고, 추천 이유를 명확히 보여주는 데 집중했습니다.

 

추천 결과에는 다음 정보가 포함됩니다.

추천 경험 제목
추천 이유
관련 역량 태그
강조할 성과
활용 방향
참고 문장

또한 추천 결과는 localStorage에 저장되어, 나중에 추천 기록 화면에서 다시 확인할 수 있도록 구현했습니다.

추천 로직 오류 수정: 경험과 추천 이유가 섞이는 문제

AI 추천 기능을 테스트하면서 중요한 문제도 발견했습니다.

추천 경험 제목은 A 경험인데, 추천 이유나 참고 문장은 B 경험을 기준으로 생성되는 문제가 있었습니다.

예를 들어 추천된 경험은 “대학 축제 메인 무대 운영 및 음향 장비 돌발 상황 대응”인데, 추천 이유에서는 CampusLog MVP 개발 경험처럼 다른 경험의 내용이 섞이는 식이었습니다.

 

이 문제는 추천 생성 흐름을 2단계로 나누면서 수정했습니다.

1단계에서는 저장된 경험 전체와 분석 결과를 기준으로 가장 적합한 recommendedExperienceId만 선택합니다.

2단계에서는 서버가 확정한 선택 경험 1개와 해당 분석 결과만 다시 전달해 추천 이유, 관련 태그, 강조할 성과, 활용 방향, 참고 문장을 생성합니다.

이렇게 바꾸면서 추천 결과가 서로 다른 경험의 내용을 섞는 문제를 줄일 수 있었습니다.

이 과정은 AI 기능을 만들 때 “응답이 그럴듯한가”보다 “응답이 정확히 어떤 근거를 기준으로 생성되었는가”를 확인해야 한다는 점을 알게 해주었습니다.

대시보드와 반응형 디자인 고도화

기능 구현 이후에는 대시보드와 반응형 디자인을 다듬었습니다.

design/dashboard-polish 작업에서는 대시보드의 CTA 위계, 빈 상태, 로딩 상태, 실패 상태, 경험 카드 정보 구조, 분석 상태 배지, 정렬/필터 UI를 정리했습니다.

대시보드에서 가장 중요한 버튼은 새 경험 기록하기입니다. AI 추천 기능도 중요하지만, 저장된 경험이 없으면 추천이 불가능하기 때문에 첫 행동은 경험 기록이어야 합니다.

그래서 새 경험 기록하기를 Primary CTA로 두고, AI 추천 및 활용은 Secondary CTA로 정리했습니다.

또한 경험 카드에는 제목, 분석 상태, 기간, 역할, 내용 미리보기, AI 태그, 최근 수정일이 자연스럽게 보이도록 정보 구조를 조정했습니다.

design/responsive-brand-polish 작업에서는 Campus Green + Mint 브랜드 톤을 적용하고, 데스크톱 좌측 사이드바와 모바일 상단 앱 바 구조를 정리했습니다.

모바일에서는 CTA 버튼이 겹치지 않도록 한 줄 배치를 피하고, 카드의 긴 제목이나 긴 태그도 줄바꿈되도록 개선했습니다.

인터랙티브 노트 UI 적용

디자인 고도화 과정에서 가장 큰 변화는 / 첫 화면이었습니다.

CampusLog의 대표 컨셉이 “대학생활을 단권화하는 AI 경험 기록장”으로 정리되면서, 첫 화면도 단순한 랜딩 페이지가 아니라 인터랙티브 노트 표지 형태로 구현했습니다.

React Three Fiber 기반으로 3D 노트 표지를 만들고, 사용자가 노트를 선택하면 /dashboard로 들어가는 흐름을 구성했습니다.

이 작업을 통해 CampusLog의 브랜드 컨셉이 화면에서 더 명확하게 드러나기 시작했습니다.

단순히 기능 목록을 보여주는 서비스가 아니라, 대학생활의 경험을 하나의 노트처럼 정리하고 다시 꺼내보는 서비스라는 인상을 줄 수 있었습니다.

다만 고급 비주얼을 사용하는 만큼 WebGL 렌더링 실패 시 fallback, 모바일 성능, reduced motion 같은 부분은 앞으로 더 점검해야 할 항목으로 남겨두었습니다.

7월 12일 멘토링: 프로덕트의 매력과 사용성 점검

7월 12일에는 멘토링을 통해 현재까지의 진행 상황을 공유했습니다.

저희 팀은 지난주 멘토링 피드백을 반영해 AGENTS.md를 보강했고, 7월 7일 강의 이후 DESIGN.md와 IMPLEMENTATION_PLAN.md를 확정한 뒤 실제 개발을 시작했다고 공유했습니다.

현재는 문기가 전체 구조와 핵심 기능을 먼저 구현했고, 건우가 디자인 고도화 방향을 함께 준비하고 있는 상태였습니다.

멘토링에서 나온 핵심 피드백은 “현재까지 기능은 만들어지고 있지만, 프로덕트 자체가 더 매력적으로 느껴지도록 차별화가 필요하다”는 방향이었습니다.

 

지금 CampusLog는 활동 경험을 기록하고 AI로 분석하고 추천받는 기본 흐름은 갖추고 있습니다. 하지만 사용자가 처음 봤을 때 “이 서비스 써보고 싶다”라고 느끼게 만들기 위해서는 경험 목록 화면과 탐색 방식에서 더 차별화가 필요하다는 피드백을 받았습니다.

특히 프론트엔드에서는 경험 목록을 단순 카드 리스트로만 보여주기보다, CampusLog만의 방식으로 보여줄 수 있는 아이디어를 고민해볼 수 있었습니다.

예를 들면 다음과 같은 방향입니다.

경험 목록에 넘버링을 붙여 성장 기록처럼 보여주기
활동 경험을 캘린더처럼 시각화하기
경험과 역량 태그를 마인드맵처럼 연결해 보여주기
사용자가 태그를 직접 달고 관리할 수 있게 하기
경험을 단순 목록이 아니라 위키처럼 쌓이는 구조로 만들기

 

이 피드백을 들으면서 현재 MVP는 기능적으로는 어느 정도 흐름을 갖추고 있지만, 아직 CampusLog만의 강한 사용 경험은 부족하다는 것을 느꼈습니다.

추천 기능의 확장 아이디어

멘토링에서는 AI 추천 기능의 확장 방향도 이야기했습니다.

현재 1차 MVP에서는 사용자가 자기소개서 문항이나 면접 질문을 텍스트로 직접 입력하면, 저장된 경험 중 가장 적합한 경험을 추천받는 구조입니다.

하지만 실제 사용 상황을 생각하면 사용자가 매번 문항을 직접 입력하지 않을 수도 있습니다.

 

예를 들어 자기소개서 문항 캡처본을 올리거나, 이력서 일부를 붙여넣거나, 채용 공고의 JD를 복사해서 넣으면 CampusLog가 그 맥락을 읽고 적합한 경험을 추천해주는 방식이 더 자연스러울 수 있습니다.

 

즉, 추천 입력이 단순한 텍스트 문항 하나가 아니라 다음처럼 확장될 수 있습니다.

자기소개서 문항 캡처
채용 공고 JD
이력서 내용
포트폴리오 목적
면접 질문
기타 지원 상황

이 기능은 1차 MVP에는 넣지 않기로 했지만, 2차 MVP에서 충분히 고민해볼 만한 방향이라고 생각했습니다.

 

특히 CampusLog가 단순 기록 서비스에서 더 나아가 “지원 상황에 맞게 내 경험을 꺼내주는 서비스”가 되려면, 추천 입력 방식도 더 실제 사용자 상황에 가까워져야 한다고 느꼈습니다.

지인 테스트의 필요성

멘토링 이후 가장 중요하게 느낀 것은 지인 테스트였습니다.

팀 안에서만 보면 우리가 만든 흐름이 자연스러워 보일 수 있습니다. 하지만 실제 사용자가 봤을 때는 어디를 눌러야 하는지, 어떤 경험을 입력해야 하는지, AI 분석 결과가 도움이 되는지 전혀 다르게 느낄 수 있습니다.

그래서 앞으로는 주변 대학생 지인들에게 직접 테스트를 부탁하려고 합니다.

 

테스트에서 확인하고 싶은 부분은 다음과 같습니다.

첫 화면을 보고 서비스 목적을 이해하는가
어떤 경험을 입력해야 할지 바로 알 수 있는가
경험 작성 폼이 부담스럽지 않은가
AI 분석 결과가 실제로 유용한가
추천 이유가 납득되는가
자기소개서나 포트폴리오에 활용할 수 있을 것 같은가
대시보드가 다시 들어와서 보고 싶게 느껴지는가
모바일에서도 핵심 기능을 사용할 수 있는가

지인 테스트를 통해 기능 오류뿐 아니라, 제품이 매력적으로 느껴지는지까지 확인해야 한다고 생각했습니다.

현재 남은 이슈

현재까지 개발이 꽤 진행되었지만, 아직 남은 이슈도 있습니다.

 

가장 먼저 실제 사용자 흐름을 처음부터 끝까지 따라가며 QA를 해야 합니다.

경험 작성
경험 목록 확인
경험 상세 확인
AI 분석 요청
분석 결과 확인
AI 추천 요청
추천 결과 저장
추천 기록 확인
경험 수정 후 재분석 필요 상태 확인
모바일에서 같은 흐름 확인

 

이 전체 흐름을 반복해서 테스트하면서 오류를 찾아야 합니다.

또한 모바일 화면에서 AI 추천과 추천 기록으로 진입하는 흐름이 부족한 부분도 있습니다. 데스크톱에서는 좌측 내비게이션을 통해 접근할 수 있지만, 모바일에서는 사이드바가 숨겨지기 때문에 진입 경로를 별도로 보완해야 합니다.

WebGL이나 3D 노트 표지가 실패했을 때의 fallback도 고민해야 합니다.

디자인적으로는 멋있지만, 특정 환경에서 화면이 비어 보이면 첫인상이 크게 떨어질 수 있기 때문입니다.

마지막으로 localStorage 파싱 실패와 빈 상태를 구분하는 문제, 실제 정렬/필터 동작 구현, Vercel 배포 준비도 남아 있습니다.

다음 단계

다음 단계는 크게 세 가지입니다.

첫 번째는 MVP 검증입니다.

지금까지는 기능을 빠르게 구현하는 데 집중했다면, 이제는 실제 사용자 흐름을 기준으로 문제를 찾아야 합니다.

두 번째는 프로덕트 매력 강화입니다.

단순 카드 목록을 넘어 CampusLog만의 경험 탐색 방식을 고민하려고 합니다. 넘버링, 캘린더, 마인드맵, 위키형 구조, 태그 직접 관리 같은 아이디어를 팀원들과 논의해 2차 MVP 범위를 정리할 예정입니다.

세 번째는 2차 MVP 범위 논의입니다.

1차 MVP가 안정되면 로그인, 회원가입, DB, Supabase 같은 기능도 슬슬 검토할 수 있습니다. 다만 바로 넣기보다는, 현재 localStorage 기반 흐름이 충분히 검증된 뒤에 적용하는 것이 맞다고 생각합니다.

또한 추천 기능도 장기적으로는 자기소개서 문항 직접 입력뿐 아니라 캡처 이미지, 이력서, JD, 포트폴리오 목적까지 받을 수 있는 구조로 확장할 수 있을 것 같습니다.

마무리

이번 기간은 CampusLog가 문서 중심 프로젝트에서 실제 작동하는 MVP로 넘어간 시간이었다고 생각합니다.

처음에는 PRD, USER_FLOW, SCREEN_SPEC, DESIGN 같은 문서들이 각각 따로 존재하는 느낌이었지만, 개발을 시작하면서 이 문서들이 실제 화면과 코드의 기준이 되기 시작했습니다.

또한 Codex를 활용한 개발은 생각보다 빠르게 진행되었습니다. 하지만 그만큼 사람이 해야 할 일도 명확했습니다.

MVP 범위를 정하고, 기능 단위를 나누고, 브랜치를 관리하고, PR을 검토하고, AI가 만든 결과물이 실제 사용자 흐름에 맞는지 판단하는 일은 결국 사람이 해야 했습니다.

 

이번 주를 지나면서 CampusLog는 이제 활동 경험 기록, AI 분석, AI 추천이라는 핵심 흐름을 어느 정도 갖추게 되었습니다.

하지만 멘토링을 통해 느낀 것처럼, 기능이 있다고 해서 곧바로 매력적인 프로덕트가 되는 것은 아닙니다.

앞으로는 실제 사용자 테스트를 통해 문제를 찾고, CampusLog만의 차별화된 경험 탐색 방식을 고민하면서 MVP를 더 다듬어가려고 합니다.

다음 목표는 단순히 “작동하는 서비스”가 아니라, 대학생이 자신의 경험을 다시 정리하고 싶어지는 서비스로 만드는 것입니다.