[UNIKER] CampusLog, 로그인·DB와 오늘의 기록을 구현하고 사용자 흐름을 다시 점검하다

지난 7월 12일 멘토링에서 저희 팀은 CampusLog의 1차 MVP를 보여드리고, 현재 기능만으로는 아직 사용자가 계속 사용하고 싶을 만큼 매력적인 프로덕트로 느껴지지 않을 수 있다는 피드백을 받았습니다.
당시 CampusLog에는 활동 경험 기록, AI 분석, 경험 추천이라는 핵심 흐름이 구현되어 있었습니다. 하지만 경험을 단순히 카드 목록으로 보여주는 것에서 그치지 않고, 캘린더·타임라인·태그·마인드맵처럼 경험이 쌓일수록 더 편리해지는 탐색 구조가 필요하다는 이야기를 들었습니다.
또한 개발 프로젝트나 공모전 경험에 치우친 팀 내부 데이터만으로 테스트하지 말고 다양한 전공과 활동을 가진 지인들에게 실제 서비스를 사용하게 해보라는 조언도 받았습니다.
이번 주에는 이 피드백을 바탕으로 단순히 화면을 다듬는 것을 넘어, CampusLog를 실제 사용 가능한 서비스 구조로 확장하고 AI 결과의 활용도를 높이는 작업을 진행했습니다.
기능은 많이 발전했지만, 7월 19일 멘토링에서는 오히려 기능이 늘어난 만큼 사용자 흐름이 복잡해졌다는 새로운 문제를 발견했습니다.
이번 글에서는 7월 12일 멘토링 이후 진행한 개발 작업과 7월 19일 멘토링에서 받은 피드백을 함께 정리해보려고 합니다.

1차 MVP에서 2차 MVP 단계로

기존 CampusLog의 1차 MVP는 브라우저의 localStorage를 이용해 활동 경험과 AI 분석 결과를 저장하는 구조였습니다.
이 방식은 빠르게 핵심 기능을 검증하기에는 적합했지만, 브라우저나 기기가 바뀌면 데이터를 이어서 사용할 수 없고 사용자별로 데이터를 구분하기도 어려웠습니다.
저희 팀은 1차 MVP의 핵심 흐름을 기준선으로 남겨두고, 이번 주부터 프로젝트를 2차 MVP 단계로 전환했습니다.
2차 MVP는 크게 두 방향으로 나누었습니다.
첫 번째는 인증·데이터·AI 기능 고도화입니다.
두 번째는 디자인과 사용자 경험 고도화입니다.
기능과 디자인을 하나의 큰 작업에서 동시에 수정하면 충돌이 발생하기 쉽기 때문에, 작업 범위를 나누고 기능별 브랜치와 Pull Request를 통해 개발을 진행했습니다.

Supabase 기반 로그인과 회원가입 구현

이번 주에 진행한 가장 큰 기반 작업 중 하나는 로그인과 회원가입 기능이었습니다.
Supabase Auth를 이용해 다음 인증 방식을 구현했습니다.

• 이메일과 비밀번호를 이용한 회원가입·로그인
• Google OAuth 로그인
• 로그아웃
• 로그인 여부에 따른 보호 페이지 접근 제한
• 신규 사용자의 이름·닉네임 온보딩

처음 서비스에 접속한 사용자는 CampusLog의 브랜드 화면을 본 뒤 로그인 또는 회원가입 영역으로 이동할 수 있습니다.
이메일 회원가입은 이메일과 비밀번호를 입력한 뒤 이름과 닉네임을 설정하는 단계형 흐름으로 구성했습니다. Google로 가입한 사용자도 필요한 프로필 정보가 없으면 온보딩 화면으로 이동해 동일한 정보를 입력하도록 했습니다.
로그인하지 않은 사용자가 대시보드나 AI 기능에 접근하면 로그인 화면으로 이동하고, 인증이 완료된 사용자만 자신의 기록을 관리할 수 있도록 구조를 변경했습니다.
단순히 로그인 버튼만 붙인 것이 아니라, 인증 상태가 전체 사용자 흐름과 자연스럽게 연결되도록 정리하는 작업이었습니다.

localStorage에서 사용자별 Supabase DB로 전환

인증 기능을 구현한 뒤에는 활동과 경험 데이터를 Supabase Postgres에 저장하도록 전환했습니다.
기존에는 같은 브라우저를 사용하는 모든 데이터가 localStorage에 저장되었습니다. 이제는 로그인한 사용자의 ID를 기준으로 데이터가 분리됩니다.
 
이를 위해 다음 데이터를 사용자별 테이블 구조로 정리했습니다.

• 활동 경험
• 진행 중인 활동
• 날짜별 기록
• AI 경험 분석
• AI 추천 기록
• AI 답변 초안
• 경험 보완 답변
• 활동 종료 후 생성된 AI 초안

데이터 접근은 Repository 구조로 분리했습니다.
화면 컴포넌트가 localStorage나 Supabase를 직접 다루지 않고, 공통 Repository 인터페이스를 통해 데이터를 읽고 쓰도록 변경했습니다. 덕분에 화면 구조를 크게 바꾸지 않으면서 저장소를 localStorage에서 Supabase로 교체할 수 있었습니다.
또한 Row Level Security, 즉 RLS를 적용했습니다.
RLS는 단순히 화면에서 다른 사용자의 데이터를 숨기는 것이 아니라 데이터베이스 단계에서 로그인한 사용자가 자신의 데이터만 조회·수정·삭제할 수 있도록 제한하는 기능입니다.
서로 다른 Google 계정으로 로그인해 각 계정의 데이터가 분리되는 것도 직접 확인했습니다.

팀 테스트 계정 9개 준비

팀원들이 하나의 Google 계정을 공유해 테스트하려고 하자, 접속 위치와 기기가 달라 보안 차단이 발생하는 문제가 있었습니다.
이를 해결하기 위해 Supabase Auth의 이메일·비밀번호 인증을 이용한 테스트 계정을 별도로 만들었습니다.
test1부터 test9까지 총 9개의 계정을 생성할 수 있는 서버 전용 시드 스크립트를 추가했습니다.

test1@campuslog.test
...
test9@campuslog.test

 

각 계정에는 온보딩이 완료된 사용자처럼 사용할 수 있도록 테스트용 프로필 정보도 함께 넣었습니다.
계정 생성에는 Supabase의 관리자 권한이 필요하기 때문에 관리자 키는 앱 코드나 브라우저에 포함하지 않고, 계정을 생성하는 담당자의 서버 환경에서만 사용하도록 분리했습니다.
이제 팀원들은 서로 다른 테스트 계정으로 로그인해 데이터가 섞이지 않는 상태에서 기능을 검증할 수 있습니다.

하루하루 기록할 수 있는 ‘오늘의 기록’ 기능

지난 멘토링에서 경험을 목록뿐 아니라 캘린더나 시간의 흐름으로 보여주는 방향을 고민해보라는 피드백을 받았습니다.
기존 CampusLog는 활동이 끝난 뒤 사용자가 제목, 역할, 내용, 성과 등을 자세히 입력하는 방식이었습니다.
하지만 활동이 끝난 뒤 한 번에 정리하려고 하면 그동안 했던 세부 작업과 문제 해결 과정을 잊기 쉽습니다. 또 매번 긴 내용을 정성스럽게 입력해야 한다면 서비스 사용 자체가 부담이 될 수 있습니다.
그래서 이번 주에는 진행 중인 활동을 먼저 등록하고, 날짜별로 실제 한 일을 간단하게 기록하는 기능을 추가했습니다.
현재 흐름은 다음과 같습니다.

활동 추가
→ 날짜별로 오늘 한 일 기록
→ 월간 캘린더에서 기록 확인
→ 활동 종료
→ AI가 날짜별 기록을 하나의 완료 경험 초안으로 정리
→ 사용자가 검토한 뒤 나의 활동으로 저장

예를 들어 CampusLog 프로젝트를 진행 중인 활동으로 추가한 뒤, 매일 다음처럼 짧게 기록할 수 있습니다.

7월 14일
Supabase 로그인 구현 및 Google OAuth 연결

7월 15일
AI 분석 결과에 STAR 구조와 근거 정보 추가

7월 16일
추천 결과 오류 수정 및 모바일 화면 점검

 

활동이 종료되면 AI는 해당 활동의 기본 정보와 날짜별 기록을 바탕으로 내용, 역할, 성과, 부족한 근거를 정리합니다.
사용자는 처음부터 완성된 경험을 작성하지 않아도 되고, 실제로 했던 일을 조금씩 기록해두었다가 나중에 하나의 경험으로 완성할 수 있습니다.
/dashboard는 오늘의 기록과 캘린더를 중심으로 바뀌었고, /experiences에서는 진행 중인 활동과 완료된 경험을 함께 볼 수 있도록 구성했습니다.

과거 경험과 진행형 활동을 함께 관리하기

CampusLog에는 두 가지 경험 등록 방식이 존재합니다.
첫 번째는 이미 끝난 프로젝트, 공모전, 대외활동 등을 직접 자세하게 작성하는 방식입니다.
두 번째는 현재 진행 중인 활동을 먼저 등록하고, 날짜별 기록을 쌓아 완료 경험으로 정리하는 방식입니다.
진행형 활동에는 다음 기능을 추가했습니다.

• 활동 제목과 내용 수정
• 시작일과 예상 종료일 수정
• 활동 삭제
• 종료한 활동을 다시 진행 중 상태로 복원
• 활동 기간에 맞는 날짜에만 기록 작성
• 활동 타임라인에서 연도·월·일·요일 표시
• 예상 종료일 전이라도 실제로 종료하면 즉시 AI 초안 생성

이 과정에서 날짜와 상태에 관련된 여러 예외 상황도 발견했습니다.
예를 들어 과거에 종료된 활동이 오늘의 기록 목록에 나타나는 문제, 종료 버튼을 누르면 기존 예상 종료일이 의도치 않게 바뀌는 문제, 화면이 작은 경우 기록 팝업의 저장 버튼까지 스크롤할 수 없는 문제 등이 있었습니다.
이번 주에는 이러한 문제를 하나씩 수정하면서 실제 사용 흐름을 안정화했습니다.

AI 경험 분석을 STAR와 근거 중심으로 고도화

기존 AI 경험 분석은 경험 요약, 역량 태그, 주요 성과, 키워드를 보여주는 수준이었습니다.
하지만 실제 자기소개서나 면접에 활용하려면 단순한 요약만으로는 부족했습니다.
그래서 AI 경험 분석을 v2 구조로 확장했습니다.
새 분석 결과에는 다음 내용이 포함됩니다.

• 상황, 과제, 행동, 결과를 구분한 STAR 구조
• 분석 결과가 원본 경험의 어떤 문장을 근거로 했는지
• 기록에서 빠진 정보
• 자기소개서에서 활용할 수 있는 소재 방향
• 역량별 근거
• 과장해서 표현하면 안 되는 부분

AI가 기록에 없는 성과나 수치, 역할을 임의로 만들어내지 않도록 프롬프트와 응답 구조도 제한했습니다.
근거가 부족한 내용은 사실처럼 작성하는 대신 부족한 정보나 주의할 점으로 따로 보여주도록 했습니다.
이번 작업의 목적은 단순히 AI가 더 길게 답하도록 만드는 것이 아니라, 사용자가 결과를 신뢰하고 실제 지원서 작성에 활용할 수 있도록 만드는 것이었습니다.

질문과 JD를 분석하는 AI 추천 v2

AI 추천 기능도 기존의 한 개 경험 추천에서 더 구체적인 구조로 확장했습니다.
사용자가 자기소개서 문항, 면접 질문, 포트폴리오 목적, 채용공고의 JD 등을 입력하면 AI가 먼저 요구사항을 분석합니다.
그다음 저장된 경험과 AI 분석 결과를 비교해 적합한 경험을 최대 3개까지 추천합니다.
추천 결과에는 다음 정보가 포함됩니다.

• 입력 문항이나 JD에서 추출한 핵심 요구사항
• 추천 경험
• 경험별 적합도
• 해당 경험을 추천한 근거
• 부족한 근거
• 과장해서는 안 되는 부분
• 자기소개서나 면접에서 활용할 방향

기존에는 질문에 특정 경험을 유도하는 표현을 넣으면 원하는 경험이 추천되는 정도를 확인했습니다.
하지만 실제 서비스에서는 유도 질문이 아닌 일반적인 문항에서도 적합한 경험을 찾아야 합니다.
그래서 추천 결과가 그럴듯하게 보이는 것뿐 아니라, 실제 경험 데이터와 일치하는지를 계속 검증하고 있습니다.

500자·800자·1000자 자기소개서 초안 생성

추천된 경험을 바탕으로 답변 초안을 생성하는 기능도 추가했습니다.
사용자는 다음 형태 중 하나를 선택할 수 있습니다.

• 500자 자기소개서
• 800자 자기소개서
• 1000자 자기소개서
• 면접 답변
• 포트폴리오 설명

AI는 사용자가 입력한 원래 문항과 추천된 경험, 경험 분석 결과를 바탕으로 초안을 생성합니다.
초안에 사용된 근거와 부족한 정보, 과장 위험도 함께 표시합니다.
테스트 과정에서는 500자 초안을 선택했지만 실제 결과가 글자 수를 크게 벗어나는 문제도 발견했습니다.
이를 해결하기 위해 초안 유형별 최소·최대 글자 수 기준을 정하고, 결과가 범위를 벗어나면 다시 교정하도록 수정했습니다. 화면에도 실제 공백 포함 글자 수를 표시하도록 개선했습니다.

부족한 경험을 다시 보완하는 루프

경험을 분석하거나 자기소개서 초안을 만들다 보면 다음과 같은 문제가 자주 발생합니다.

구체적인 성과 수치가 부족합니다.
본인이 직접 해결한 행동이 명확하지 않습니다.
팀 내에서 맡은 역할을 더 자세히 작성할 필요가 있습니다.

 

이전에는 이런 부족한 정보를 발견해도 사용자가 원본 경험을 직접 수정한 뒤 다시 분석해야 했습니다.
이번 주에는 AI가 부족한 부분을 바탕으로 보완 질문을 생성하고, 사용자가 질문에 답한 뒤 재분석할 수 있는 기능을 구현했습니다.
예를 들어 AI가 다음과 같이 질문할 수 있습니다.

팀원 간 의견이 달랐을 때 어떤 방식으로 조율했나요?

기능 개선 전후의 사용자 반응이나 수치가 있나요?

해당 문제를 해결하기 위해 본인이 직접 수행한 행동은 무엇인가요?

 
사용자의 답변은 원본 경험을 자동으로 덮어쓰지 않고 별도의 보완 데이터로 저장됩니다.
사용자가 재분석을 요청하면 AI는 원본 경험과 보완 답변을 함께 사용해 새로운 분석 결과를 만듭니다.
이 기능을 통해 CampusLog는 단순히 경험을 분석해주는 서비스에서, 사용자가 자신의 경험을 더 구체적으로 떠올리고 보완하도록 돕는 서비스로 확장되었습니다.

AI API 보호와 비용 관리 기반 추가

로그인과 DB가 도입되면서 AI API도 인증된 사용자만 호출할 수 있도록 변경했습니다.
/api/analyze, /api/recommend, /api/synthesize-activity에서는 화면 접근 제한과 별개로 서버 내부에서 다시 사용자 세션을 확인합니다.
비로그인 요청은 공통 오류 형식으로 차단하고, 다음 보호 장치도 추가했습니다.

• 요청 데이터 크기 제한
• 입력 필드 길이 제한
• OpenAI 응답 대기 시간 제한
• 사용자별 기본 호출 빈도 제한
• 재시도 시간 안내
• API Key의 클라이언트 노출 방지

현재 적용한 호출 제한은 단일 서버 실행 환경을 기준으로 한 기본 구조입니다.
향후 실제 공개 배포 환경에서는 여러 서버 인스턴스에서도 유지되는 호출 제한과 OpenAI 비용 알림 설정이 추가로 필요합니다.

UI와 QA 작업

기능이 늘어나면서 화면의 세부적인 문제도 많이 발생했습니다.
이번 주에는 다음과 같은 UI와 버그를 수정했습니다.

• 빠른 기록 패널을 화면 중앙에 배치
• 작은 화면에서 기록 패널 내부 스크롤 지원
• 저장·취소 버튼 접근성 개선
• 활동 추가 화면을 별도 페이지 대신 확장형 패널로 제공
• 로그인 후 프로필과 로그아웃 메뉴 정리
• AI 실행 버튼의 시각적 구분 강화
• 체크박스와 복사 버튼의 상태 표현 통일
• 추천 점수와 등급이 일치하도록 규칙 고정
• 보완 질문을 숨긴 뒤 다시 복원할 수 있도록 개선
• 다른 질문의 답변을 저장해도 작성 중인 내용이 사라지지 않도록 수정
• 활동 삭제 시 연결된 기록과 AI 결과의 삭제 범위 안내
• 완료 활동 복원 기능 추가
• 활동 날짜와 종료 상태 처리 개선

테스트 과정에서 발견한 문제를 ISSUE_LOG.md에 기록하고, 해결한 내용과 남은 검증 사항을 함께 관리했습니다.
코드 변경 후에는 lint, TypeScript 검사, production build 등을 반복해 기본적인 오류가 없는지도 확인했습니다.

7월 19일 멘토링: 기능은 많아졌지만 길을 잃기 시작하다

7월 19일 멘토링에서는 이번 주에 구현한 인증, DB, 오늘의 기록, AI 고도화 기능을 직접 화면으로 보여드렸습니다.
저희는 로그인과 Google 인증, Supabase 사용자별 DB 분리, STAR 기반 AI 분석, 답변 초안 기능을 구현했다고 보고했습니다.
동시에 현재 CampusLog에 기능이 예상보다 많이 추가되면서 UI와 사용자 흐름이 복잡해졌다는 고민도 말씀드렸습니다.
멘토님께서 화면을 보신 뒤 가장 먼저 확인한 것은 사용자의 전체 흐름이었습니다.

사용자가 처음 들어와서 기록하고, 분석하고, 추천받기까지 어떤 경로를 거치게 되는가?

 
저희가 설명한 현재 흐름은 다음과 같았습니다.

활동 등록
→ 날짜별 기록 또는 과거 경험 직접 작성
→ 활동 상세 확인
→ AI 분석
→ 부족 정보 보완
→ 재분석
→ AI 추천
→ 자기소개서 초안 생성

기능 하나하나는 연결되어 있었지만, 실제 화면에서는 상세 페이지 안으로 들어가고 다시 분석 결과 페이지로 이동하는 과정이 반복되었습니다.
저희 팀원도 중간에 현재 위치를 잃을 정도로 화면을 타고 들어가야 했고, 멘토님도 한눈에 흐름이 들어오지 않는다는 의견을 주셨습니다.

기능보다 UX 정리가 더 필요한 시점

멘토님은 현재 상태를 다음과 같이 정리해주셨습니다.

기능적으로는 어느 정도 완성되었지만, 하고 싶은 것을 계속 추가하면서 UX가 복잡해진 상태다.

 
지금 CampusLog의 기술적인 문제보다 더 중요한 것은, 사용자가 어떤 순서로 무엇을 해야 하는지 명확하게 보여주는 것입니다.
저희 팀은 활동 원본과 AI 분석 결과를 같은 화면에서 볼 수 있도록 좌우 Split View 형태로 구성하는 방안을 논의하고 있었습니다.
멘토님도 사용자가 페이지를 계속 타고 들어가지 않도록 다음과 같은 개선이 필요해 보인다고 말씀해주셨습니다.

• 왼쪽 사이드바의 카테고리와 진입 경로 활용
• 활동과 분석 결과를 한 화면에서 확인
• 중첩된 상세 페이지 이동 최소화
• 핵심 기능으로 바로 들어갈 수 있는 경로 제공
• 현재 위치를 잃지 않도록 정보 구조 단순화

단순히 “화면을 편하게 만들자”라고 접근하면 어디서부터 수정해야 할지 판단하기 어렵습니다.
멘토님은 먼저 사용자 흐름과 스토리보드를 다시 그리고, 각 단계에서 사용자가 수행해야 하는 행동 수를 줄이는 방식으로 접근하라고 조언해주셨습니다.

사용자가 어떤 행동을 해야 하는지 정리하고, 그 플로우에서 불필요한 클릭과 이동을 줄이는 방향으로 UX를 설계해야 한다.

 
이번 멘토링을 통해 다음 주 디자인 작업의 기준이 더 명확해졌습니다.

AI 대기 시간에는 스트리밍도 고려

AI 분석을 요청하면 사용자는 결과가 나올 때까지 기다려야 합니다.
현재는 로딩 상태만 표시되기 때문에 처리 시간이 길어질 경우 사용자가 서비스가 멈춘 것으로 느낄 수 있습니다.
멘토님은 대기 시간이 불편하게 느껴진다면, AI가 생성하고 있는 내용을 스트리밍 형태로 조금씩 보여주는 방법도 고려할 수 있다고 말씀해주셨습니다.
스트리밍이 모든 상황의 해결책은 아니지만, 사용자가 “현재 AI가 작업하고 있다”는 것을 확인할 수 있어 체감 대기 시간을 줄일 수 있습니다.
당장 반드시 구현해야 하는 기능은 아니지만, UX를 개선하는 후보로 기록해두었습니다.

캘린더와 과거 경험의 연결

현재 캘린더에는 진행 중인 활동에서 날짜별로 남긴 기록이 표시됩니다.
하지만 과거 경험을 직접 작성한 경우에는 해당 활동의 기간이 캘린더에 나타나지 않습니다.
멘토님은 사용자가 과거에 했던 활동도 시작일과 종료일을 입력하는 만큼, 캘린더나 타임라인에서 함께 확인할 수 있으면 좋겠다는 의견을 주셨습니다.
예를 들어 다음처럼 전체 대학생활을 시간순으로 볼 수 있습니다.

2025년 3월~6월
학부 프로젝트

2025년 7월
공모전 참가

2026년 3월~현재
대외활동 진행

2026년 7월
UNIKER CampusLog 개발

 

앞으로는 날짜별 기록뿐 아니라 과거 경험과 진행 중인 활동을 하나의 시간 흐름에서 볼 수 있도록 검토할 예정입니다.
또한 경험이 많아졌을 때는 날짜, 활동 유형, 역량 태그 등을 기준으로 필터링할 수 있는 탐색 기능도 필요합니다.

OCR과 JD 입력은 여전히 중요한 확장 방향

지난 멘토링에서 멘토님은 자기소개서 문항을 직접 입력하는 대신 화면을 캡처해 올리는 방식을 제안해주셨습니다.
이번 멘토링에서도 해당 기능이 아직 반영되지 않았다는 점을 확인했습니다.
현재는 사용자가 자기소개서 문항이나 JD를 텍스트로 입력해야 합니다.
하지만 실제 지원 상황에서는 다음 자료를 그대로 전달할 수 있어야 더 편리합니다.

• 자기소개서 문항 캡처
• 지원서 화면 이미지
• 채용공고의 JD
• 우대사항
• 이력서
• 포트폴리오 요구사항

이미지에서 문항을 추출하고, JD와 요구 역량을 분석해 경험을 추천할 수 있다면 사용자가 CampusLog를 훨씬 가볍게 사용할 수 있습니다.
다만 현재는 기능을 더 추가하기 전에 전체 UX를 정리해야 하는 상황이기 때문에, OCR과 이미지 입력은 텍스트 기반 추천 흐름을 안정화한 뒤 진행할 예정입니다.

지인 테스트는 어떻게 해야 할까?

이번 멘토링에서 저희가 가장 궁금했던 부분은 지인 테스트 방법이었습니다.
처음에는 주변 대학생들에게 링크를 보내고 자유롭게 사용해달라고 부탁하려고 했습니다.
하지만 CampusLog는 한 번 버튼을 누르면 바로 가치를 이해할 수 있는 단순한 서비스가 아닙니다.
사용자가 활동을 등록하고, 기록을 쌓고, AI 분석을 실행하고, 지원 문항에 맞는 경험을 추천받는 과정을 거쳐야 하기 때문에 어느 정도 학습이 필요합니다.
멘토님은 지인 테스트를 진행할 때 사용자가 원하는 흐름을 따라갈 수 있도록 가이던스가 필요하다고 말씀해주셨습니다.
가장 좋은 방법은 서비스 안에 단계별 튜토리얼을 제공하는 것입니다.
예를 들면 다음과 같습니다.

1. 진행 중인 활동을 하나 등록해주세요.
2. 오늘 한 일을 기록해주세요.
3. 활동을 종료하고 AI 초안을 확인해주세요.
4. AI 분석을 실행해주세요.
5. 자기소개서 문항을 입력하고 경험 추천을 받아보세요.

 

다만 현재 일정에서 완성된 튜토리얼까지 만드는 것이 부담이라면, 짧은 사용 안내 영상이나 가이드 문서를 먼저 제공하는 방법도 제안해주셨습니다.
사용자 테스트 전에 다음과 같은 자료를 준비할 수 있습니다.

• 1~2분 사용 방법 영상
• 테스트 과업이 정리된 안내 문서
• 테스트용 계정
• 테스트 후 응답할 Google Form
• 오류 제보 양식

사람보다 먼저 합성 데이터로 추천 정확도 검증하기

이번 멘토링에서 가장 중요한 피드백 중 하나였습니다.
지인 테스트는 UI와 사용성 피드백을 받는 데 유용합니다.
하지만 CampusLog의 핵심 가치는 저장된 경험 중에서 질문에 가장 적합한 경험을 제대로 찾아주는 것입니다.
이 기능은 실제 사람에게 서비스를 보여주기 전에, 합성 데이터를 이용해 먼저 체계적으로 검증할 수 있습니다.
멘토님은 하나의 가상 사용자 페르소나를 만들고, 그 사람의 활동 경험을 10개에서 20개 정도 생성한 뒤 다양한 질문을 입력해보라고 조언해주셨습니다.
예를 들어 다음과 같은 페르소나를 만들 수 있습니다.

소프트웨어학과 3학년 대학생
프로젝트, 공모전, 학생회, 아르바이트, 봉사활동 경험 보유
백엔드 인턴 지원 준비 중

 
이 사용자에게 다음과 같은 경험 데이터를 넣을 수 있습니다.

• 팀 프로젝트에서 API 개발
• 공모전에서 일정 관리 실패 후 개선
• 학생회 행사 운영
• 아르바이트 중 고객 불만 대응
• 봉사활동에서 교육 자료 제작
• 동아리 내 갈등 조율
• 해커톤에서 MVP 완성
• 데이터 분석 프로젝트
• 발표와 팀 피드백 경험
• 개인 서비스 배포 경험

그다음 질문별로 어떤 경험이 추천되어야 하는지를 미리 정합니다.

“팀원과 갈등을 해결한 경험”
→ 동아리 갈등 조율

“예상치 못한 문제를 해결한 경험”
→ 공모전 일정 실패 개선 또는 행사 돌발 상황 대응

“데이터를 활용해 의사결정을 내린 경험”
→ 데이터 분석 프로젝트

“빠르게 실행해 결과를 만든 경험”
→ 해커톤 MVP 완성

 

CampusLog가 예상한 경험을 추천하는지, 추천 근거가 실제 기록에 존재하는지, 다른 경험의 내용을 섞지는 않는지를 반복해서 테스트할 수 있습니다.
대규모 정형 데이터가 필요한 작업이 아니기 때문에, AI와 함께 페르소나와 더미 경험을 만들면 비교적 빠르게 검증할 수 있다는 조언도 받았습니다.
즉, 다음 테스트 순서는 다음과 같이 정리할 수 있습니다.

합성 데이터로 추천 로직 검증
→ 팀 내부 사용자 흐름 점검
→ 지인 테스트
→ 피드백 반영
→ 최종 시연 흐름 정리

다음 주 계획

이번 주에는 기능을 많이 구현했습니다.
하지만 7월 19일 멘토링을 통해, 지금 필요한 것은 기능을 더 추가하는 것이 아니라 현재 기능을 사용자가 이해하기 쉬운 구조로 다시 정리하는 것이라는 결론을 내렸습니다.
다음 주에는 다음 작업을 중심으로 진행할 예정입니다.

1. 사용자 흐름과 스토리보드 재정리

현재의 전체 흐름을 다시 그린 뒤, 각 단계에서 필요한 클릭과 페이지 이동을 줄일 예정입니다.
특히 다음 부분을 중점적으로 보려고 합니다.

• 활동 원본과 AI 분석 결과를 Split View로 함께 보기
• 사이드바를 활용한 직접 진입 경로
• 분석과 보완 답변을 한 화면에서 처리
• 사용자가 현재 위치를 잃지 않는 구조
• 중복되거나 우선순위가 낮은 기능 제거

2. 합성 데이터 기반 추천 로직 테스트

가상 사용자 페르소나와 10~20개의 경험 데이터를 만들 예정입니다.
질문별 기대 추천 결과를 미리 정의한 뒤 다음 항목을 검증하려고 합니다.

• 추천 경험 적합성
• 추천 근거의 원본 일치 여부
• 누락된 근거 표시
• 과장 위험 안내
• 경험 간 내용 혼합 여부
• Top 3 추천 순서

3. 지인 테스트 준비

UI 대공사와 기본 추천 테스트가 끝나면 주변 대학생을 대상으로 지인 테스트를 진행하려고 합니다.
자유롭게 사용해보라고 요청하기보다, 사용 안내 영상과 과업을 제공하는 방식으로 준비할 예정입니다.
테스트에서는 다음 항목을 확인하려고 합니다.

• 서비스 목적을 이해하는가
• 첫 활동을 어렵지 않게 등록할 수 있는가
• 날짜별 기록 방식이 부담스럽지 않은가
• AI 분석 결과가 자신의 경험과 일치하는가
• 추천된 경험을 납득할 수 있는가
• 자기소개서나 면접에 실제로 활용하고 싶은가
• 다시 사용할 의향이 있는가

4. OCR·JD 이미지 입력 검토

텍스트 기반 추천 흐름과 UX가 안정된 뒤, 자기소개서 문항 캡처와 JD 이미지 입력을 추가하는 방향을 검토할 예정입니다.

마무리

이번 주는 CampusLog의 개발 규모가 가장 크게 확장된 시기였습니다.
기존 localStorage 기반 MVP에서 벗어나 로그인, Google OAuth, 사용자별 Supabase DB, RLS를 적용했습니다.
진행 중인 활동을 매일 기록하고 캘린더에서 확인한 뒤, 활동 종료 시 AI가 완료 경험을 정리하는 흐름도 만들었습니다.
 
AI 경험 분석은 STAR와 원본 근거 중심으로 확장했고, 추천 기능은 문항과 JD의 요구사항을 분석해 경험 Top 3를 제안하도록 고도화했습니다. 답변 초안과 부족한 경험을 다시 보완하는 기능도 추가했습니다.
기술적으로는 많은 부분이 완성되었습니다.
 
하지만 이번 멘토링을 통해 기능을 많이 구현하는 것과 사용하기 좋은 프로덕트를 만드는 것은 다른 문제라는 점을 다시 느꼈습니다.
기능이 추가될수록 화면과 흐름도 복잡해졌고, 사용자가 어디서 무엇을 해야 하는지 명확하게 안내하지 않으면 오히려 서비스의 가치가 가려질 수 있었습니다.
앞으로는 새로운 기능을 계속 추가하기보다, 사용자 흐름을 다시 설계하고 합성 데이터로 핵심 추천 로직을 검증한 뒤 실제 사용자 테스트로 넘어가려고 합니다.
CampusLog의 목표는 단순히 많은 기능을 가진 서비스가 아닙니다.

대학생이 자신의 경험을 부담 없이 기록하고, 필요한 순간에 가장 적합한 경험을 다시 꺼내 쓸 수 있도록 돕는 서비스

 
다음 주에는 이 목표가 더 분명하게 보이는 화면과 사용자 흐름으로 CampusLog를 다시 정리해보겠습니다.