[UNIKER] CampusLog, 중간 데모를 앞두고 제품을 다듬고 실제 크루들 앞에서 시연하다

이번 주 팀 핏줄은 CampusLog의 새로운 기능을 무작정 늘리기보다, 이미 구현한 기능이 하나의 서비스처럼 자연스럽게 연결되도록 화면과 사용자 경험을 다듬는 데 집중했다.

 

나의 활동과 AI 분석 화면을 정리하고, 추천 결과와 추천 기록의 정보 구조를 통일했다. 여러 기기와 탭에서 같은 계정을 사용할 때 발생하던 세션 문제, 긴 경험을 AI로 분석했을 때 발생하던 저장 오류 등 실제 사용 과정에서 발견한 문제도 수정했다.

 

그리고 8월 2일에는 서울에서 열린 UNIKER 중간 데모데이에 참여해 CampusLog를 실제 크루들과 멘토님들 앞에서 발표하고 직접 시연했다.

 

이번 글에서는 7월 27일부터 8월 2일까지 진행한 CampusLog 개발 과정과 중간 데모데이에서 받은 현장 피드백을 함께 정리해보려고 한다.

 

중간 데모데이 글 : 

https://mkisos.tistory.com/entry/uniker10

[UNIKER] AI 서비스를 직접 시연하다, 팀 핏줄 CampusLog 중간 데모데이 후기 (“가장 안전했던 선택이

 

기능을 더하는 단계에서 제품을 정리하는 단계로

CampusLog에는 이미 상당히 많은 기능이 구현되어 있었다.

 

사용자는 이메일이나 Google 계정으로 로그인하고, 진행 중인 활동과 이미 끝난 경험을 기록할 수 있다. 저장한 경험은 AI로 분석할 수 있으며, 자기소개서·면접·JD 분석 등의 목적에 맞는 경험을 추천받을 수도 있다.

여기에 활동별 날짜 기록, AI 보완 질문, 추천 경험 Top 3, 답변 초안, 이미지 기반 추천까지 추가되면서 기능적인 범위는 빠르게 확장되었다.

 

하지만 기능이 많아질수록 새로운 문제가 생겼다.

화면마다 다른 스타일이 적용되거나, 같은 종류의 정보가 서로 다른 구조로 나타났다. 사용자가 목록과 상세 화면, AI 분석 결과와 추천 기록 사이를 오갈 때 화면의 기준점이 조금씩 달라지는 문제도 있었다.

 

이번 주에는 기능 추가보다 다음 질문에 집중했다.

CampusLog의 여러 기능이 하나의 제품 안에 있다는 느낌을 어떻게 만들 수 있을까?

 

이를 위해 화면 전반의 색상, 표면, 간격, 제목 위치, 목록과 상세 구조를 하나의 디자인 기준으로 다시 정리했다.

CampusLog 전체를 하나의 Liquid Glass 디자인으로 통일하기

이번 주 디자인 작업의 중심은 CampusLog 전체 화면을 쿨 뉴트럴 Liquid Glass 스타일로 통일하는 것이었다.

기존 화면에는 웜 화이트, 크림색, 회색, 투명한 카드와 불투명한 카드가 섞여 있었다. 각각의 화면만 보면 문제가 크지 않았지만, 메뉴를 이동할 때마다 서로 다른 서비스처럼 보일 수 있었다.

그래서 공개 첫 화면과 인증 화면부터 오늘의 기록, 나의 활동, AI 추천, 추천 기록, 경험 작성·상세·분석 화면까지 공통 디자인 토큰을 적용했다.

 

기능을 조작하는 사이드바, 팝업, 메뉴와 오버레이에는 반투명 Glass 표현을 사용하고, 긴 내용을 읽거나 작성하는 화면은 가독성을 위해 비교적 불투명한 표면을 유지했다.

 

또한 화면 안에 여러 겹의 흰색 카드가 중첩되어 보이던 구조를 줄였다.

하나의 큰 표면 안에서는 메타 정보, 본문, 근거, 답변 영역을 다시 별도 카드로 감싸지 않고 구분선과 간격으로 연결했다. 이를 통해 화면의 정보량은 유지하면서도 훨씬 단순하게 읽히도록 정리했다.

‘나의 활동’을 목록과 상세가 연결된 작업 공간으로

CampusLog에서 가장 자주 사용하게 될 화면 중 하나는 나의 활동이다.

사용자는 이곳에서 진행 중인 활동과 완료된 경험을 찾고, 내용을 확인하고, AI 분석을 실행한다.

 

이번 주에는 나의 활동의 페이지 제목과 설명을 목록 패널 밖으로 분리했다. 목록 안에는 전체 활동이라는 별도 제목과 활동 개수, 검색 기능을 배치했다.

 

왼쪽 목록에서 경험을 선택하면 오른쪽에서 상세 내용을 확인할 수 있는 Split View 구조는 유지하되, 목록과 상세가 동일한 재질과 간격을 사용하도록 조정했다.

 

선택된 활동도 별도의 흰색 카드처럼 떠 보이지 않도록 바꾸었다. 대신 옅은 차콜 배경과 왼쪽 인디케이터를 이용해 현재 선택된 항목을 구분했다.

 

스크롤바 역시 평소에는 화면을 방해하지 않도록 숨기고, 실제로 사용자가 스크롤하는 동안에만 표시하도록 수정했다.

데스크톱뿐 아니라 390px 모바일 화면에서도 목록, 상세, AI 분석 결과가 잘리지 않도록 반복해서 확인했다. 7월 27일 작업에서는 관련 구조 테스트와 lint, TypeScript 검사, production build까지 통과했다.

활동과 추천 기록을 빠르게 다시 찾는 즐겨찾기

경험과 추천 기록이 많아지면 사용자는 자주 확인해야 하는 항목을 다시 찾기 어려워질 수 있다.

이를 보완하기 위해 나의 활동과 추천 기록에 즐겨찾기 기능을 추가했다.

사용자가 별을 누르면 해당 활동이나 추천 기록이 목록 위쪽의 즐겨찾기 영역으로 이동한다. 다시 별을 누르면 원래 목록으로 돌아간다.

처음에는 Pin 아이콘을 사용했지만, 사용자가 더 직관적으로 이해할 수 있도록 노란색 별 아이콘으로 변경했다.

즐겨찾기 버튼을 눌렀을 때 상세 화면이 함께 열리지 않도록 항목 선택과 별 조작 영역을 분리했고, 키보드 사용자도 기능을 이용할 수 있도록 접근성 속성과 44px 조작 영역을 유지했다.

진행 중인 활동도 완료 경험과 구분되는 저장 키를 사용해 즐겨찾기에 추가할 수 있도록 확장했다.

 

화면이 바뀌어도 기준점이 흔들리지 않도록

작은 차이지만 계속 서비스를 사용하면 불편하게 느껴지는 부분도 수정했다.

기존에는 오늘의 기록, 나의 활동, AI 추천, 추천 기록, 활동 추가, 경험 추가 화면마다 제목과 Breadcrumb의 시작 위치가 조금씩 달랐다.

페이지를 이동할 때마다 제목이 미세하게 좌우로 움직였고, 화면에 스크롤바가 있는지에 따라서도 콘텐츠 폭이 달라졌다.

이번 주에는 상위 화면과 하위 화면이 동일한 최대 폭과 여백을 사용하도록 공통 내비게이션 레일을 적용했다.

스크롤바가 나타날 때 화면 폭이 달라지지 않도록 모든 제품 화면에 동일한 스크롤바 공간도 예약했다. 그 결과 메뉴를 이동해도 Breadcrumb와 제목이 같은 위치에 유지되도록 만들었다.

오늘의 기록으로 이동할 때 이전 메뉴와 새 메뉴가 동시에 활성화되어 보이던 문제와 페이지가 부드럽게 미끄러지며 이동하던 현상도 함께 수정했다.

사용자가 메뉴를 누르면 목적지 한 곳만 즉시 활성화되고, 새 화면의 상단에 바로 정착하도록 정리했다.

AI 분석과 추천 결과의 정보 구조 통일

AI 분석 결과와 추천 기록은 모두 AI가 생성한 결과를 읽는 화면이지만, 이전에는 제목과 생성일, 본문 카드의 위계가 서로 달랐다.

이번 주에는 두 화면을 같은 서비스의 결과 화면처럼 보이도록 통일했다.

AI 분석 화면은 다음 순서로 정보를 보여준다.

AI 경험 분석 결과
→ 분석 생성일
→ 대표 제목
→ 요약
→ STAR
→ 주요 성과
→ 부족 정보
→ 키워드

 

정상적으로 분석된 상태에서 반복적으로 나타나던 안내 문구와 하단의 중복 생성일은 제거했다. 경험 원본이 수정되었거나 다시 분석해야 하는 경우처럼 실제 행동이 필요한 안내만 조건에 따라 표시하도록 했다.

추천 결과 화면도 저장된 질문이나 문항을 대표 제목으로 사용하도록 변경했다.

기존에는 추천된 경험의 이름, 기간, 역할, 사용자가 입력한 질문이 여러 위치에서 반복되었다. 이제 질문을 중심으로 활용 목적과 요구사항 분석, 추천 경험 Top 3, 추천 근거, 답변 생성 흐름이 이어지도록 정리했다.

다양한 전공과 지원 상황을 고려한 추천 예시

CampusLog의 AI 추천 화면에는 사용자가 입력 방식을 이해할 수 있도록 예시 질문이 제공된다.

기존 예시는 개발자 경험과 특정 상황에 치우친 부분이 있었다.

이번 주에는 면접, 자기소개서, JD 분석, 기타 목적마다 대표 질문을 6개씩 구성했다.

면접과 자기소개서 예시는 다음과 같은 공통 역량을 중심으로 정리했다.

• 자신의 역할과 기여
• 문제 해결
• 협업
• 주도성
• 성과
• 실패와 성장

기타 목적에는 포트폴리오, 이력서, 1분 자기소개, 대외활동과 인턴 지원, 발표 준비, 전공과 직무 연결 등의 상황을 포함했다.

JD 분석에는 단순한 짧은 문장뿐 아니라 실제 채용공고에 가까운 형태의 예시도 추가했다. 플랫폼·결제 서버와 커머스 백엔드 직무의 역할, 지원 자격, 기술 스택과 면접 관점이 포함된 샘플을 선택하면 전체 내용이 입력되도록 구성했다.

다양한 전공과 직무를 가진 대학생이 CampusLog의 사용법을 더 쉽게 이해하도록 만드는 작업이었다.

실제 사용 과정에서 발견한 세션과 동시 작업 문제

중간 데모를 준비하면서 여러 기기와 탭에서 같은 테스트 계정을 사용했다.

이 과정에서 refresh token 갱신 오류와 데이터 조회 실패가 연속으로 발생하는 문제가 발견되었다.

한 기기에서 로그아웃하면 다른 기기의 세션까지 영향을 받거나, 오래된 화면에 남아 있던 경험 데이터로 AI 분석을 요청하면서 최신 DB 데이터와 충돌할 가능성도 있었다.

이를 해결하기 위해 로그아웃 범위를 현재 기기의 세션으로 제한하고, 브라우저에서 사용하는 Supabase Client를 하나의 인스턴스로 관리하도록 변경했다.

AI 분석을 실행하기 직전에는 화면에 남아 있는 데이터만 믿지 않고 DB에서 최신 경험과 보완 답변을 다시 조회하도록 했다.

같은 경험을 여러 곳에서 동시에 수정하는 경우에는 한쪽 변경이 조용히 덮어써지지 않도록 updated_at을 기준으로 충돌을 감지했다.

분석 결과 저장 역시 경험별 atomic upsert 방식을 사용해 동일 경험의 분석이 중복 저장되거나 충돌하지 않도록 수정했다.

상세한 역할을 입력했더니 AI 분석이 실패한 문제

실제 데이터로 AI 분석을 테스트하면서 예상하지 못한 오류도 발견했다.

경험 작성 화면에서는 역할을 비교적 길게 입력할 수 있었지만, AI API에서는 역할 길이를 200자로 제한하고 있었다.

테스트 데이터 중 역할 내용이 220자인 경험을 분석하자 OpenAI를 호출하기도 전에 400 BAD_REQUEST가 발생했다.

 

문제는 화면의 입력 기준과 API의 검증 기준이 서로 달랐다는 점이었다.

이를 해결하기 위해 경험 작성 화면과 AI 분석, 추천, 답변 초안, 보완 질문 API에서 사용하는 역할 입력 한도를 1,000자로 통일했다.

수정 이후에는 동일한 경험으로 AI 분석을 다시 실행해 API 응답, SSE 완료, Supabase 저장과 결과 화면 표시까지 확인했다.

분석 결과 저장 과정에서는 related_links 객체 배열이 [object Object]로 전달되어 PostgreSQL JSON 오류가 발생하는 문제도 이어서 발견했다. 해당 값은 JSON 문자열로 비교하도록 수정했다.

긴 경험을 분석한 뒤 결과가 저장되지 않던 문제

8월 2일에는 긴 경험 원문을 AI로 분석한 뒤 결과 저장 단계에서 400 오류가 발생했다.

원인을 확인해보니 AI 분석 결과를 저장할 때 경험의 제목, 역할, 내용, 성과, 관련 링크 전체를 Supabase URL의 비교 조건으로 전달하고 있었다.

경험 내용이 길어지자 요청 URL이 약 26,000자를 넘어갔고, 결국 결과를 저장할 수 없었다.

이를 해결하기 위해 경험 원문 전체를 비교하는 대신 경험 ID와 updated_at만 사용해 분석 도중 경험이 변경되었는지 확인하도록 수정했다.

 

경험 내용이 길어도 URL 길이는 일정하게 유지되며, 분석 도중 원본이 수정되는 문제도 계속 감지할 수 있다.

입력 제한도 화면과 네 개의 AI API에서 공통으로 관리하도록 변경했다.

현재 활동 내용은 최대 8,000자, 성과는 최대 4,000자까지 입력할 수 있다. 제한의 90%에 도달하기 전에는 글자 수를 표시하지 않고, 입력량이 많아졌을 때만 카운터와 안내를 보여준다.

제한을 넘긴 내용을 자동으로 잘라버리지 않고, 사용자가 얼마나 줄여야 하는지 알려준 뒤 해당 입력란으로 초점을 이동하도록 했다.

중간 데모 제출 문서와 시연 흐름 준비

중간 데모를 앞두고 코드뿐 아니라 현재 구현 상태를 설명할 문서도 다시 정리했다.

제출용 문서는 다음 세 가지로 구성했다.

• 요구사항 명세서
• WBS 및 마일스톤
• 시퀀스 플로우

요구사항 명세서에는 CampusLog가 해결하려는 문제와 핵심 사용자, 기능 요구사항, 현재 구현 상태를 정리했다.

WBS에는 문제 정의부터 경험 CRUD, AI 분석·추천, 인증과 Supabase DB, UI 고도화까지 어떤 순서로 개발했는지 기록했다.

시퀀스 플로우에는 사용자의 조작이 CampusLog 화면과 Repository, Supabase, Next.js API Route, OpenAI Responses API로 어떻게 연결되는지를 정리했다.

 

중간 데모 시점의 대표 흐름은 다음과 같았다.

로그인
→ 경험 기록
→ AI 경험 분석
→ 부족한 정보 보완
→ 자기소개서·면접·JD 입력
→ 적합한 경험 Top 3 추천
→ 목적에 맞는 답변 생성
→ 추천 기록에서 다시 확인

 

실제 발표에서 오류가 발생할 가능성에 대비해 미리 생성한 분석 결과와 추천 화면도 준비했다. 요구사항 문서에도 중간 데모 이후 최우선 과제로 데모 계정과 샘플 데이터 준비, 대표 시나리오 리허설, 사전 생성 결과와 대체 설명 순서를 명시했다.

8월 2일, UNIKER 중간 데모데이

8월 2일에는 서울 역삼역 인근 센터필드 7층에서 UNIKER 1기 중간 데모데이가 진행되었다.

오후 2시부터 레크리에이션과 팀별 발표, 멘토 피드백이 이어졌고, 공식 발표가 끝난 뒤에는 식사와 네트워킹도 진행되었다. 각 팀은 약 5~10분 동안 자신들이 개발한 AI 서비스를 소개하고, 실제 화면을 보여준 뒤 공개 피드백을 받았다.

웹캠을 활용한 자세 관리 서비스, AI 대화 친구, 연구 주제와 교수 매칭 서비스, 번아웃 예방 스케줄러, 패션 스타일링, 대학생활 AI 비서 등 다양한 프로젝트를 볼 수 있었다.

같은 AI 도구를 사용하더라도 팀마다 문제를 정의하는 방식과 제품의 형태는 전혀 달랐다.

멘토님들은 기능이 얼마나 많은지보다 다음과 같은 내용을 중심으로 질문했다.

• 누구의 어떤 문제를 해결하는가
• 사용자가 계속 이용할 이유가 있는가
• 일반적인 생성형 AI와 무엇이 다른가
• 서비스의 가설을 어떤 지표로 검증할 것인가

다른 팀의 발표와 피드백을 들으며 CampusLog 역시 기능의 완성도뿐 아니라 실제 사용자 문제를 해결했다는 증거가 필요하다는 점을 다시 느꼈다.

실제 크루들 앞에서 CampusLog 발표하기

우리 팀 핏줄은 대학생의 경험을 기록하고, 필요한 순간에 다시 활용할 수 있도록 돕는 AI 경험 관리 서비스 CampusLog를 발표했다.

CampusLog는 팀원들이 실제로 겪었던 불편함에서 출발했다.

대외활동, 프로젝트, 학교 프로그램, 인턴과 채용에 지원할 때 자기소개서와 면접을 준비해야 하지만, 막상 질문을 받으면 어떤 경험을 활용해야 할지 바로 떠오르지 않는 경우가 많다.

블로그, Notion, GitHub, 갤러리와 AI 대화 기록 등 여러 공간에 기록이 남아 있더라도 지원 시점에는 다시 모든 공간을 뒤져야 한다.

저희는 이 문제를 다음 흐름으로 해결하려고 했다.

경험 기록
→ AI 경험 분석
→ 목적에 맞는 경험 추천
→ 자기소개서·면접·지원에 활용

 

발표에서는 설명에만 머무르지 않고 실제 배포된 CampusLog를 직접 조작했다.

이메일과 Google 계정으로 로그인한 뒤 새로운 경험을 등록하고, AI 분석을 실행했다.

AI는 경험을 요약하고 STAR 구조와 주요 성과를 정리한다. 기록만으로 판단하기 어려운 내용은 역할 범위, 수치화된 성과, 문제 해결 과정 등의 부족 정보로 구분해 다시 질문한다.

 

사용자가 기억하거나 확인할 수 있는 내용만 답변하면 그 정보가 이후 추천과 답변 생성에 반영된다.

이미지와 JD를 활용한 경험 추천 시연

CampusLog의 메인 기능인 AI 경험 추천도 함께 시연했다.

사용자는 면접, 자기소개서, JD 분석, 기타 중 활용 목적을 선택하고 실제 질문이나 채용공고 내용을 입력할 수 있다.

직접 입력하기 번거로운 경우에는 자기소개서 문항이나 채용공고를 캡처한 이미지를 첨부할 수도 있다.

AI는 사용자의 저장 경험과 분석 결과, 부족 정보에 대한 보완 답변을 살펴보고 가장 적합한 경험을 최대 세 개까지 추천한다.

추천 결과에는 단순한 경험 제목만 나타나지 않는다.

• 해당 경험을 추천한 이유
• 질문과 연결되는 역할과 성과
• 원본 기록에서 확인되는 직접 근거
• 현재 기록에서 부족한 부분
• 과장해서 표현하면 안 되는 내용
• 자기소개서나 면접에서 강조할 방향

자기소개서 목적이라면 요구 글자 수에 맞는 초안을 생성할 수 있다.

JD 분석에서는 채용공고가 요구하는 역량과 사용자의 경험을 비교해 충족, 부분 충족, 미충족 여부와 앞으로 보완할 부분을 보여준다.

실전 시연 중 발생한 AI 분석 오류

아무리 미리 준비해도 실전 데모에서는 예상하지 못한 문제가 발생한다.

CampusLog 발표 중 AI 분석을 요청했을 때 일시적인 오류가 발생했다.

다행히 사전에 준비한 분석 결과 화면이 있었기 때문에 바로 화면을 전환해 다음 기능 설명을 이어갈 수 있었다.

발표 흐름 자체는 중단되지 않았지만, 실제 시연에서는 기능 구현뿐 아니라 실패했을 때 어떤 화면과 설명으로 넘어갈지를 준비해야 한다는 점을 체감했다.

 

발표가 끝난 직후에는 오류 코드를 확인하고 원인을 추적했다.

쉬는 시간 동안 문제를 수정한 뒤 다시 배포해 서비스가 정상적으로 동작하는 것도 확인했다.

 

최종 발표에서는 같은 상황이 반복되지 않도록 단순히 한 번 기능을 눌러보는 수준이 아니라 실제 발표 순서 그대로 여러 차례 시뮬레이션해야겠다고 생각했다.

“기다리는 시간을 또 다른 경험으로 연결해보세요”

발표가 끝난 뒤 멘토님들로부터 공개 피드백을 받았다.

이전 멘토링 때보다 서비스가 많이 발전했고, 팀원들이 실제로 경험한 문제에서 출발했다는 점을 긍정적으로 평가해주셨다.

특히 AI가 경험을 한 번 분석하고 끝나는 것이 아니라, 부족한 정보를 다시 질문하고 사용자가 답변한 내용을 다음 분석과 추천에 반영하는 UX를 좋게 봐주셨다.

 

가장 구체적인 피드백은 AI 응답을 기다리는 시간에 관한 것이었다.

현재는 분석이나 추천을 요청하면 사용자가 결과가 나올 때까지 해당 화면에서 기다려야 한다.

 

멘토님께서는 AI 작업을 백그라운드에서 진행하고, 화면에는 프로그레스 바나 현재 처리 단계를 보여주는 방식을 제안해주셨다.

사용자가 기다리는 동안에는 다음 행동으로 연결할 수도 있다.

“분석이 진행되는 동안 다른 경험을 기록해보시겠어요?”

“오늘의 기록을 먼저 작성해보세요.”

 

작업이 끝났을 때 별도의 알림을 제공하면 사용자는 로딩 화면만 바라보지 않고 CampusLog 안에서 다른 일을 계속할 수 있다.

AI 응답 시간을 기술적으로 줄이는 것도 중요하지만, 사용자가 느끼는 대기 시간을 어떻게 설계할지도 중요한 문제라는 것을 배웠다.

폼을 채우는 서비스에서 자료를 넘기는 서비스로

경험을 입력하는 방식에 대한 피드백도 받았다.

현재 CampusLog는 제목, 기간, 역할, 활동 내용과 성과를 정해진 폼에 맞춰 입력한다.

그러나 사용자가 이미 가지고 있는 문서나 활동 자료가 있다면 이를 다시 하나씩 옮겨 적는 과정도 부담이 될 수 있다.

멘토님께서는 기존 자기소개서, 프로젝트 자료, 활동 기록, 이미지와 문서를 올리면 AI가 CampusLog의 경험 형식에 맞게 자동으로 정리해주는 방식을 고려해보라고 조언해주셨다.

 

현재 질문과 JD 이미지를 분석하는 기능은 구현되어 있지만, 앞으로는 경험을 등록하는 단계에서도 멀티모달 입력을 활용할 수 있다.

사용자가 완성된 경험을 처음부터 작성하는 대신, 이미 가지고 있는 기록을 전달하면 AI가 초안을 만들고 사용자가 검토하는 방식이다.

이는 CampusLog의 입력 부담을 줄이는 중요한 확장 방향이 될 수 있다.

자기소개서를 대신 작성하는 서비스에서 끝나지 않기

생성형 AI와 취업 준비에 관한 피드백도 기억에 남았다.

최근에는 많은 지원자가 AI를 활용해 자기소개서를 작성한다.

하지만 AI가 만들어준 문장을 그대로 제출해 서류에 합격하더라도, 면접에서 자신의 경험을 제대로 설명하지 못할 수 있다.

CampusLog가 보기 좋은 자기소개서를 대신 작성하는 서비스에서 끝난다면 사용자가 자신의 경험을 실제로 이해하도록 돕지 못할 수도 있다.

 

멘토님께서는 자기소개서 이후의 면접 과정까지 연결해보면 좋겠다는 의견을 주셨다.

 

예를 들어 추천된 경험을 기준으로 다음 기능을 연결할 수 있다.

• 예상 면접 질문 생성
• 경험의 핵심 행동과 성과 다시 확인
• 부족한 근거를 묻는 꼬리 질문
• 사용자가 직접 답변한 뒤 AI 피드백 받기
• 자신의 언어로 경험을 설명하는 연습

CampusLog가 지향해야 할 방향은 AI가 사용자의 경험을 새로 만들어주는 것이 아니다.

사용자가 이미 가지고 있는 경험을 더 정확하게 기억하고, 자신의 언어로 설명하도록 돕는 것

 

이번 피드백을 통해 이 가치가 더욱 분명해졌다.

‘오늘의 기록’을 더 가볍고 꾸준한 기능으로

현재 CampusLog에는 진행 중인 활동을 등록하고 날짜별로 한 일을 남기는 오늘의 기록 기능이 있다.

활동을 종료하면 AI가 여러 날짜의 기록을 바탕으로 완료 경험 초안을 생성한다.

발표에서는 이 기능을 앞으로 더 가볍고 자동화된 방식으로 발전시키고 싶다는 방향도 소개했다.

사용자는 매일 긴 경험을 작성하지 않고 다음처럼 짧은 기록만 남길 수 있다.

• 사용자 흐름 수정
• AI 추천 프롬프트 개선
• 팀 회의에서 기능 우선순위 결정
• 배포 오류 해결

AI가 여러 기록의 연관성을 파악해 하나의 프로젝트 경험으로 묶고, 사용자의 역할과 문제 해결 과정, 성과를 정리해준다면 경험을 한 번에 작성하는 부담을 크게 줄일 수 있다.

이는 입력 편의성뿐 아니라 사용자가 CampusLog에 꾸준히 방문하도록 만드는 핵심 기능이 될 수 있다.

발표가 끝난 뒤 시작된 네트워킹

공식 발표가 마무리된 뒤에는 피자, 치킨, 떡볶이 등을 함께 먹으며 네트워킹이 이어졌다.

발표 시간에는 각 팀의 기능과 문제 정의를 중심으로 이야기했다면, 식사 시간에는 AI 시대의 개발자, 취업과 포트폴리오, 창업, 해외 커리어 등 더 넓은 주제로 대화했다.

다른 크루들에게 CampusLog를 다시 소개하고, 추후 베타테스트에 참여해달라고 부탁했다.

실제 사용 중 발생하는 오류와 불편한 점을 편하게 알려달라고 이야기했고, 단순히 연락처를 교환한 것을 넘어 앞으로 CampusLog를 사용하고 피드백을 줄 수 있는 잠재 사용자를 만날 수 있었다.

 

멘토님들과의 대화에서는 AI를 활용해 개발한 프로젝트를 어떻게 자신의 경험으로 설명할 것인지에 대한 이야기도 들었다.

중요한 것은 AI가 코드를 만들었는지가 아니라, 사람이 어떤 문제를 발견했고 어떤 기준으로 결과를 판단하고 검증했는지 설명할 수 있는가였다.

CampusLog 역시 단순히 “Codex로 만들었다”라고 설명해서는 안 된다.

왜 이 기능을 선택했는지, AI가 경험을 과장하지 않도록 어떤 구조를 사용했는지, 추천 결과의 근거를 어떻게 검증했는지, 실제 오류를 어떻게 발견하고 해결했는지를 설명할 수 있어야 한다.

중간 데모 이후의 개발 방향

이번 주에는 많은 화면과 기능을 다듬었지만, 중간 데모를 통해 앞으로 필요한 작업도 더 분명해졌다.

1. AI 작업의 백그라운드 처리와 완료 알림

AI 분석과 추천을 요청한 뒤 사용자가 다른 작업을 계속할 수 있도록 작업 상태를 관리하는 구조를 검토할 예정이다.

단순한 로딩 문구에서 끝나지 않고 진행 단계, 백그라운드 작업, 완료 알림과 실패 후 재시도를 함께 설계해야 한다.

2. 데모 시나리오와 오류 대응 강화

최종 발표 전에는 실제 발표 순서 그대로 반복해서 리허설할 계획이다.

정상 흐름만 확인하지 않고 다음 상황도 준비해야 한다.

• OpenAI 응답 지연
• Supabase 세션 만료
• AI 결과 저장 실패
• 네트워크 오류
• 이미지 인식 실패
• 배포 환경 문제

사전 생성 결과, 화면 캡처와 대체 설명 순서도 함께 준비하려고 한다.

3. 경험 입력 방식의 멀티모달 확장

질문과 JD뿐 아니라 사용자가 가지고 있는 기존 경험 자료도 이미지와 문서로 전달할 수 있도록 입력 방식을 확장할 예정이다.

다만 AI가 자동으로 만든 내용을 바로 저장하지 않고, 사용자가 검토하고 수정한 뒤 경험으로 확정하는 구조는 유지해야 한다.

4. 다양한 전공을 대상으로 한 사용자 테스트

현재까지의 테스트는 개발과 AI 분야의 경험에 치우친 부분이 있다.

앞으로는 기획, 디자인, 마케팅, 경영, 인문·사회 등 다양한 전공의 대학생에게 서비스를 사용해보도록 요청하려고 한다.

단순한 만족도보다 다음 지표를 확인할 계획이다.

• 첫 경험 등록 완료율
• AI 분석까지 도달한 사용자 비율
• 추천 결과의 납득도
• 추천 경험을 실제 지원에 활용할 의향
• 어느 단계에서 사용자가 이탈하는지
• 다시 방문해 기록할 의향
• 가장 불편했던 입력 단계

5. 자기소개서 이후 면접 준비까지 연결

추천된 경험을 사용자가 자신의 언어로 설명할 수 있도록 면접 질문과 꼬리 질문, 답변 연습 기능을 검토하려고 한다.

CampusLog의 목표는 완성된 문장을 대신 제출해주는 것이 아니라, 사용자가 자신의 경험을 더 정확하게 이해하고 활용하도록 돕는 것이다.

중간 점검을 넘어 실제 사용자에게

이번 주는 CampusLog의 화면과 기능을 다듬는 일로 시작해, 실제 크루들과 멘토님들 앞에서 서비스를 시연하는 것으로 마무리되었다.

개발 과정에서는 디자인 시스템과 정보 구조를 통일하고, 즐겨찾기와 검색, AI 결과 화면의 위계를 정리했다.

동시에 여러 기기에서 같은 계정을 사용할 때 발생하는 세션 문제와 긴 경험을 분석했을 때 발생하는 저장 오류처럼 실제 데이터에서만 발견할 수 있는 문제도 해결했다.

 

그리고 중간 데모에서는 준비한 모든 기능을 완벽하게 보여주지는 못했다.

AI 분석 중 오류가 발생했고, 준비해둔 화면으로 발표를 이어간 뒤 쉬는 시간에 문제를 찾아 수정하고 다시 배포했다.

당황스러운 순간이었지만, 오히려 실제 서비스를 운영하고 시연하기 위해 무엇을 준비해야 하는지 배울 수 있었다.

이번 데모데이는 단순히 현재까지의 결과물을 평가받는 자리가 아니었다.

다른 팀의 서비스를 보면서 우리가 놓친 관점을 발견했고, 공개 피드백을 통해 CampusLog가 앞으로 지향해야 할 가치를 다시 확인했다.

 

기억에 남은 문장도 있었다.

“가장 안전했던 선택이 나를 위험하게 만들었고, 위험한 선택이 나를 안전하게 만들었다.”

 

무작정 위험한 선택을 하라는 의미라기보다, 감당할 수 있는 범위에서 직접 시도하고 그 결과를 다음 판단의 근거로 만들어야 한다는 이야기로 받아들였다.

 

CampusLog 역시 아직 완성된 서비스가 아니다.

하지만 아이디어를 문서로만 남기는 데서 멈추지 않고, 실제로 작동하는 서비스를 만들고, 사람들 앞에서 시연하고, 오류와 피드백을 다시 개발에 반영하고 있다.

 

남은 기간에는 기능의 개수를 늘리는 것보다 CampusLog가 대학생의 경험 관리 문제를 실제로 얼마나 잘 해결하는지 증명하는 데 집중하려고 한다.

 

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

 

중간 데모를 넘어, 이제 실제 사용자가 계속 사용하고 싶은 CampusLog를 만들어가려고 한다.