[UNIKER] CampusLog, 개발 전에 먼저 MVP 범위와 협업 문서를 정리하다

UNIKER 활동이 본격적으로 시작되면서, 저희 팀 핏줄은 서비스 아이디어를 실제 프로젝트로 만들기 위한 준비를 진행하고 있습니다.

저희가 기획하고 있는 서비스는 CampusLog입니다.

CampusLog는 대학생들이 프로젝트, 대외활동, 공모전, 수상, 블로그, GitHub 기록 등 흩어진 대학생활 경험을 하나의 성장 기록으로 정리하고, 이를 자기소개서·포트폴리오·면접 준비에 활용할 수 있도록 돕는 AI 기반 서비스입니다.

 

이번에는 바로 개발부터 들어가기보다, 팀원들과 함께 서비스의 문제 정의, MVP 범위, 협업 방식, Codex 활용 규칙을 먼저 정리했습니다.
특히 7월 6일 마감 과제인 PRD.md, README.md, AGENTS.md를 작성하면서 CampusLog가 어떤 문제를 해결해야 하는지, 어떤 기능부터 만들어야 하는지, 그리고 AI와 어떻게 협업해야 하는지를 구체화했습니다.

 

이번에 작성한 핵심 문서

이번에 팀원들과 함께 작성한 문서는 크게 세 가지입니다.

• PRD.md
• README.md
• AGENTS.md

세 문서는 단순한 제출용 문서가 아니라 앞으로 Codex를 활용해 실제 서비스를 개발하기 위한 기준 문서라고 생각하고 작성했습니다.

 

PRD.md: 문제 정의와 MVP 범위 정리

먼저 PRD.md에는 CampusLog가 해결하려는 문제와 타깃 사용자, 그리고 MVP 핵심 기능을 정리했습니다.

저희가 집중한 문제는 대학생들이 다양한 활동을 하면서도 그 경험을 나중에 제대로 활용하기 어렵다는 점입니다.

프로젝트를 하고, 공모전에 참여하고, 대외활동을 하고, 블로그나 GitHub에 기록을 남기지만 막상 자기소개서나 포트폴리오를 작성할 때는 다시 기억을 더듬어야 하는 경우가 많습니다.
활동 기록은 존재하지만 여러 곳에 흩어져 있고, 그 경험이 어떤 역량으로 연결되는지 정리되어 있지 않기 때문입니다.

 

그래서 CampusLog의 핵심 사용자는 다음과 같이 정의했습니다.

취업, 인턴, 대외활동, 포트폴리오 준비를 앞두고 자신의 대학생활 경험을 정리하고 싶은 대학생

 

처음에는 넣고 싶은 기능이 많았습니다.
활동 기록 저장, AI 요약, 역량 태그 분석, 자기소개서 문장 생성, 포트폴리오 문장 생성, 면접 답변 정리, 외부 링크 연동 등 여러 아이디어가 나왔습니다.

하지만 MVP에서는 모든 기능을 한 번에 구현하기보다, 가장 핵심적인 흐름에 집중하기로 했습니다.

 

현재 정리한 CampusLog의 MVP 흐름은 다음과 같습니다.

활동 기록 입력 → AI 요약 생성 → 역량 태그 확인 → 포트폴리오/자소서 문장 생성 → 저장/복사

 

이 흐름이 제대로 작동하면, 사용자는 단순히 활동을 기록하는 것에서 끝나는 것이 아니라 자신의 경험을 실제 지원서나 포트폴리오에 활용할 수 있게 됩니다.

README.md: 서비스 소개와 실행 방법 초안 작성

README.md에는 프로젝트를 처음 보는 사람이 CampusLog를 빠르게 이해할 수 있도록 서비스 소개와 실행 방법 초안을 작성했습니다.

README는 단순히 GitHub 첫 화면을 채우는 문서가 아니라, 프로젝트의 첫인상을 결정하는 문서라고 생각했습니다.
멘토님이나 팀원이 저장소에 들어왔을 때 이 서비스가 무엇을 하는지, 왜 필요한지, 어떻게 실행하는지 바로 알 수 있어야 하기 때문입니다.

 

CampusLog의 한 줄 소개는 다음과 같이 정리했습니다.

CampusLog는 대학생의 흩어진 활동 기록을 AI로 정리해 포트폴리오와 자기소개서에 활용할 수 있도록 돕는 성장 기록 서비스입니다.

아직 본격적인 구현 전이기 때문에 실행 방법은 초안 수준으로 작성했습니다.

 

이후 MVP 개발이 진행되면 실제 실행 명령어, 사용 방법, 배포 링크 등을 계속 업데이트할 예정입니다.

README를 작성하면서 느낀 점은, 서비스 설명이 명확하지 않으면 개발 방향도 흔들릴 수 있다는 것이었습니다.
그래서 단순히 예쁘게 소개하는 것보다, “이 서비스가 어떤 문제를 해결하는가”와 “사용자가 어떤 흐름으로 사용할 것인가”를 중심으로 정리했습니다.

AGENTS.md: Codex가 따라야 할 협업 규칙 정의

이번 문서 작업에서 가장 중요하게 느낀 문서는 AGENTS.md였습니다.

UNIKER 프로젝트에서는 Codex를 활용해 개발을 진행하게 됩니다.
그렇기 때문에 사람끼리의 협업 규칙뿐만 아니라, AI가 프로젝트 안에서 어떤 방식으로 작업해야 하는지도 문서로 정의할 필요가 있었습니다.

AGENTS.md에는 Codex가 따라야 할 작업 방식과 가드레일을 정리했습니다.

예를 들어 다음과 같은 규칙을 포함했습니다.

• 기능을 크게 벌리지 말 것
• 요청한 범위만 수정할 것
• 불필요하게 전체 코드를 갈아엎지 말 것
• 작업 전 계획을 먼저 세울 것
• 작은 단위로 구현할 것
• 작업이 끝나면 변경 사항을 기록할 것
• GitHub에 자주 커밋하고 푸시할 것
• 사람이 최종 검토할 수 있도록 작업 내용을 명확히 남길 것

AI에게 개발을 맡기면 빠르게 결과물이 나오지만, 동시에 예상하지 못한 파일이 수정되거나 요청하지 않은 코드까지 바뀔 수 있습니다.
그래서 Codex가 마음대로 프로젝트 범위를 넓히지 않도록 기준을 정해두는 것이 중요하다고 판단했습니다.

결국 AGENTS.md는 단순한 규칙 문서가 아니라, AI와 함께 일하기 위한 팀의 작업 방식 문서라고 볼 수 있습니다.

6월 28일 멘토링 정리

6월 28일 일요일에는 팀원들과 함께 멘토링에 참여했습니다.

멘토링에서 가장 크게 얻은 방향은 다음 문장으로 정리할 수 있습니다.

지금은 “개발을 많이 했다”보다 MVP 범위가 명확하고, Codex가 바로 개발할 수 있는 상태를 만드는 것이 중요하다.

 

멘토님은 저희 아이디어가 아직 넓고 추상적인 부분이 있기 때문에 다음 단계로 넘어가기 전에 기능 범위를 더 좁히는 것이 필요하다고 말씀해주셨습니다.

서비스 아이디어 자체는 괜찮지만 10주 안에 실제로 작동하는 결과물을 만들기 위해서는 처음부터 너무 많은 기능을 넣으면 안 된다는 피드백이었습니다.

기술 스택보다 중요한 것은 핵심 기능 작동

멘토링에서 기술 스택에 대한 이야기도 나왔습니다.

처음에는 Spring Boot, MySQL, 로그인, 클라우드 배포까지 고려할 수 있었습니다.
하지만 멘토님은 3~4주 안에 첫 MVP를 만들어야 하는 상황이라면, 처음부터 백엔드와 운영 DB, 복잡한 배포 구조를 크게 잡는 것은 부담이 될 수 있다고 조언해주셨습니다.

 

그래서 저희는 1차 MVP에서는 핵심 기능이 작동하는 것에 집중하기로 했습니다.

정리한 방향은 다음과 같습니다.

항목	방향
로그인	MVP 제외
MySQL / 복잡한 DB	일단 제외
Spring Boot	1차 MVP에서는 제외 가능
Next.js	적합
LocalStorage	1차 MVP에는 충분히 가능
SQLite	저장 구조를 조금 더 실제 앱처럼 만들고 싶을 때 고려
Vercel 배포	하면 좋지만, 1차 목표는 핵심 기능 작동
최우선	기능 1~2개를 제대로 구현

이번 피드백을 통해 “좋은 기술을 많이 쓰는 것”과 “좋은 MVP를 만드는 것”은 다르다는 것을 느꼈습니다.

지금 CampusLog에 필요한 것은 거대한 구조가 아니라, 사용자가 활동 기록을 입력하고 AI 결과물을 확인할 수 있는 최소한의 흐름입니다.

AI 세션 기억에 의존하지 않기

멘토링에서 특히 인상 깊었던 부분은 작업 상태 관리였습니다.

Codex를 사용하다 보면 Plus, Edu, Pro 계정을 바꿔가며 사용할 수도 있습니다.
계정 전환 자체는 가능하지만 문제는 AI 세션의 맥락이 이어지지 않을 수 있다는 점입니다.

예를 들어 A 계정에서 작업하다가 토큰이 부족해 B 계정으로 바꾸면, B 계정은 이전 세션에서 어떤 작업을 했는지 모를 수 있습니다.

그래서 멘토님은 AI 세션 기억에 의존하지 말고, 작업 상태를 반드시 파일로 남겨야 한다고 강조하셨습니다.

저희가 추가로 정리하려는 파일 구조는 다음과 같습니다.

docs/
  WORK_STATUS.md
  TASK_LOG.md
  TODO.md
  ISSUE_LOG.md

 

각 파일의 역할은 다음과 같습니다.

• WORK_STATUS.md: 현재 프로젝트 진행 상태 정리
• TASK_LOG.md: 작업별 변경 내역 기록
• TODO.md: 남은 작업 목록 정리
• ISSUE_LOG.md: 문제 상황과 해결 과정 기록

앞으로 Codex에게 작업을 요청할 때는 작업이 끝난 뒤 상태 기록까지 함께 업데이트하도록 요청할 예정입니다.

예를 들면 다음과 같은 문장을 함께 사용할 수 있습니다.

이번 작업이 끝나면 docs/WORK_STATUS.md와 docs/TASK_LOG.md를 업데이트해줘.
완료한 작업, 수정한 파일, 남은 작업, 다음 작업자가 이어서 봐야 할 내용을 정리해줘.

 

이렇게 하면 세션이 바뀌거나 계정을 바꿔도, 프로젝트의 현재 상태를 다시 파악할 수 있습니다.

GitHub 협업 규칙 정리

멘토링에서는 GitHub 협업 방식도 중요하게 다뤘습니다.

AI를 활용해 개발하면 작업 속도는 빨라질 수 있지만, 그만큼 변경 사항을 제대로 관리하지 않으면 코드가 꼬이거나 이전 상태로 되돌리기 어려울 수 있습니다.

특히 멘토님은 AI에게 기능 개발을 시키면 요청하지 않은 코드까지 많이 수정하거나, 심하면 기존 코드를 날리는 경우도 있다고 경고해주셨습니다.

그래서 저희 팀은 앞으로 다음 흐름을 지키기로 했습니다.

작은 작업 → 커밋 → 푸시 → 검토

작업 단위를 작게 나누고, 변경 사항을 자주 GitHub에 반영해야 문제가 생겼을 때 롤백할 수 있습니다.

앞으로 정리해야 할 GitHub 협업 규칙은 다음과 같습니다.

• 브랜치 전략 정하기
• PR 방식 정하기
• 작업 단위를 작게 쪼개기
• Codex가 만든 코드도 바로 GitHub에 싱크하기
• 이상하게 수정되면 GitHub에서 롤백할 수 있도록 관리하기

GitHub는 단순히 코드를 올리는 저장소가 아니라, AI와 함께 개발할 때 필요한 안전장치라는 생각이 들었습니다.

현재까지의 진행 상황

현재 저희 팀은 7월 6일 마감 과제인 PRD.md, README.md, AGENTS.md를 작성했습니다.

추가로 서비스 흐름과 화면 구조를 더 구체화하기 위해 다음 문서들도 함께 정리하고 있습니다.

• FLOW.md
• IA.md
• SCREEN_SPEC.md

문서의 개수만 늘리는 것이 목표는 아닙니다.
중요한 것은 PRD에서 문제와 MVP 범위가 명확한지, README에서 서비스 소개와 실행 방법이 잘 드러나는지, AGENTS에서 Codex가 따라야 할 작업 규칙이 충분히 구체적인지입니다.

다음 목표

앞으로의 우선순위는 다음과 같이 정리했습니다.

1. MVP 기능 범위 최종 확정
2. PRD.md, README.md, AGENTS.md 보완
3. 작업 상태 기록 파일 추가
4. GitHub 협업 규칙 정리
5. 다음 멘토링 질문 준비

7월 6일 전까지는 개발보다 문서 최종 검토가 우선입니다.

이후에는 본격적으로 MVP 구현에 들어갈 예정입니다.
현재 생각하고 있는 핵심 흐름은 다음과 같습니다.

활동 기록 입력 → AI 요약 생성 → 역량 태그 확인 → 포트폴리오/자소서 문장 생성 → 저장/복사

 

이 흐름을 가장 먼저 작동하게 만드는 것이 CampusLog의 첫 번째 목표입니다.

마무리

이번 활동을 통해 느낀 점은, AI로 개발한다고 해서 바로 코드를 많이 작성하는 것이 정답은 아니라는 점입니다.

오히려 AI가 제대로 일할 수 있도록 문제를 명확히 정의하고, MVP 범위를 좁히고, 협업 규칙을 문서로 남기는 과정이 먼저 필요했습니다.

CampusLog는 아직 완성된 서비스는 아니지만, 이번 문서 작업과 멘토링을 통해 조금씩 “만들 수 있는 서비스”의 형태로 바뀌고 있습니다.

앞으로는 문서로 정리한 기준을 바탕으로 실제 사용자가 활동 기록을 입력하고, AI가 이를 자기소개서와 포트폴리오에 활용 가능한 문장으로 바꿔주는 MVP를 구현해보려고 합니다.

AI와 함께 개발하는 과정에서 중요한 것은 결국 사람의 판단과 방향 설정이라는 것을 느꼈습니다.