[UNIKER] CampusLog, 사용자 흐름과 화면 설계를 개발 가능한 문서로 다듬다

UNIKER 활동을 진행하면서 저희 팀 핏줄은 CampusLog를 실제로 개발하기 위한 준비를 이어가고 있습니다.

이전까지는 CampusLog가 해결하려는 문제, MVP 범위, Codex 협업 규칙을 중심으로 PRD.md, README.md, AGENTS.md를 정리했습니다.

이번에는 7월 14일 화요일 마감 과제인 USER_FLOW.md와 SCREEN_SPEC.md를 중심으로 사용자가 서비스를 어떤 흐름으로 사용할지와 각 화면이 어떤 역할을 해야 하는지를 구체적으로 다듬었습니다.

 

이번 과제는 다음 두 가지였습니다.

USER_FLOW.md : 사용자가 서비스를 쓰는 3~5단계 흐름 정리

SCREEN_SPEC.md : 첫 화면, 결과 화면, 실패/빈 상태 설계 정리

 

단순히 문서를 제출하기 위한 작업이 아니라, 이제 실제 개발에 들어가기 전에 “어떤 화면을 먼저 만들고, 어떤 기능을 어떤 순서로 구현할지”를 정리하는 과정이었습니다.

전체 문서 검토부터 시작하다

https://github.com/fitjul-uniker/campuslog

GitHub - fitjul-uniker/campuslog: CampusLog - AI-powered growth archive for university students.

 

먼저 현재 GitHub 저장소에 있는 .md 문서들을 팀원들과 함께 다시 검토했습니다.

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

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

문서를 검토할 때는 단순히 오타나 표현만 본 것이 아니라, 앞으로 실제 개발로 이어질 수 있는지를 기준으로 확인했습니다.

 

중점적으로 본 기준은 다음과 같습니다.

MVP 범위 밖 기능이 들어가 있지 않은가
로그인, 결제, 커뮤니티, 외부 연동처럼 현재 범위에 맞지 않는 기능이 섞여 있지 않은가
팀원이 읽어도 이해할 수 있는가
개발자가 바로 작업 단위로 쪼갤 수 있는가
문서끼리 서로 충돌하는 내용이 없는가

이번 검토를 통해 문서가 많다고 좋은 것이 아니라, 각 문서가 같은 방향을 바라보고 있어야 한다는 것을 느꼈습니다.

 

특히 CampusLog는 활동 기록, AI 분석, 역량 태그, 자기소개서/포트폴리오 활용까지 연결되는 서비스이기 때문에, 사용자 흐름과 화면 구조가 조금만 어긋나도 개발 방향이 흔들릴 수 있었습니다.

USER_FLOW.md: 사용자의 실제 흐름을 더 명확하게 만들기

USER_FLOW.md에서는 사용자가 CampusLog를 어떤 순서로 사용하는지를 정리했습니다.

처음 정리한 흐름은 다음과 같았습니다.

 

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

 

팀원들과 검토하면서 이 흐름 자체는 유지하되, 몇 가지 부분을 더 명확하게 보완해야 한다는 의견이 나왔습니다.

 

먼저 “역량 태그”가 무엇을 의미하는지 더 구체적인 예시가 필요하다는 피드백이 있었습니다. 단순히 역량 태그라고만 쓰면 사용자가 어떤 결과를 받게 되는지 이해하기 어려울 수 있기 때문입니다.

 

그래서 역량 태그의 대표 예시는 다음과 같이 정리했습니다.

문제 해결력: 문제를 발견하고 원인을 분석해 해결한 경험
협업/커뮤니케이션: 팀원과 역할을 나누고 의견을 조율한 경험
실행력/주도성: 목표를 정하고 실제 결과물까지 만들어낸 경험
분석력/데이터 활용력: 자료, 피드백, 수치, 사용자 반응 등을 바탕으로 판단한 경험

 

또한 동현이의 피드백을 반영해 역량 태그를 한 가지 종류로만 두기보다 넓은 범위의 핵심 역량 태그와 구체적인 세부 키워드를 나누는 방향이 좋겠다고 판단했습니다.

예를 들어 문제 해결력, 실행력, 분석력 같은 태그는 자기소개서나 면접에서 활용하기 좋습니다. 반면 AI 개발, Python, Git 협업, 데이터 구조화 같은 키워드는 포트폴리오나 경험 추천 정확도에 더 도움이 됩니다.

그래서 1차 MVP에서는 AI가 활동 경험을 분석할 때 넓은 역량 태그와 세부 키워드를 함께 생성하는 방향으로 정리했습니다.

추천 기능은 가장 적합한 경험 1개로 좁히기

회의 중에 “가장 적합한 경험 1개만 추천할 것인가, 아니면 1·2·3순위까지 추천할 것인가”에 대한 이야기도 나왔습니다.

기능적으로는 여러 경험을 추천해주는 편이 더 좋아 보일 수 있습니다. 하지만 1차 MVP에서 1·2·3순위 추천까지 구현하려면 추천 기준, 비교 UI, 정렬 이유, 후보 간 차이 설명까지 필요해집니다.

그래서 1차 MVP에서는 사용자가 자기소개서 문항, 포트폴리오 작성 목적, 면접 질문 등을 입력하면 저장된 경험 중 가장 적합한 경험 1개만 추천하는 방식으로 정리했습니다.

대신 추천 이유와 관련 역량 태그를 명확하게 보여주기로 했습니다.

 

1·2·3순위 추천은 2차 MVP 확장 항목으로 남겨두었습니다.

이번 결정은 MVP 범위를 줄이는 데 중요한 판단이었습니다. 좋은 아이디어를 모두 넣기보다, 가장 핵심적인 기능이 제대로 작동하도록 만드는 것이 먼저라고 생각했습니다.

IA.md: 메인 화면을 허브로 두기

IA.md를 검토하면서는 화면 간 이동 흐름에 대한 피드백이 많이 나왔습니다.

기존에는 활동 경험 작성/수정 화면에서 AI 경험 분석 결과 화면으로 이어지고, 다시 AI 경험 추천 및 활용 화면으로 넘어가는 선형 흐름이 중심이었습니다.

하지만 실제 사용성 측면에서는 사용자가 언제든 메인 화면으로 돌아와 활동 기록, 작성, 저장된 분석 결과, 활용 지원으로 들어갈 수 있어야 한다고 판단했습니다.

 

그래서 메인 화면을 전체 서비스의 허브로 두기로 했습니다.

메인 화면에서는 크게 두 가지 흐름으로 진입할 수 있도록 정리했습니다.

 

첫 번째는 활동 경험 기록/분석 흐름입니다.

메인 화면
활동 경험 목록
활동 경험 상세
AI 경험 분석 결과

 

두 번째는 활용 추천 흐름입니다.

메인 화면
AI 경험 추천 및 활용 화면
자기소개서 문항/포트폴리오 목적/면접 질문 입력
가장 적합한 경험 추천
참고 문장 저장 또는 복사

 

이렇게 나누니 서비스 구조가 더 명확해졌습니다.

활동 경험 분석은 개별 활동에 연결된 분석 기록이고, 활용 추천은 저장된 전체 경험을 바탕으로 특정 목적에 맞는 경험을 찾아주는 기능입니다.

이 둘을 분리하면서 CampusLog의 핵심 흐름이 더 선명해졌습니다.

SCREEN_SPEC.md: 화면별 역할을 다시 정리하다

SCREEN_SPEC.md에서는 각 화면이 어떤 정보를 보여주고, 어떤 행동을 제공해야 하는지를 정리했습니다.

회의 과정에서 건우가 화면 설계와 사용자 흐름을 매우 꼼꼼하게 봐주었습니다. 덕분에 제가 놓쳤던 부분도 많이 발견할 수 있었습니다.

 

가장 먼저 수정한 부분은 활동 경험 목록 화면입니다.

처음에는 목록 화면에 AI 분석 상태나 여러 정보를 많이 보여주려고 했지만, 목록 화면은 너무 복잡하면 안 된다고 판단했습니다.

그래서 활동 경험 목록 화면에서는 제목, 기간, 대표 역할 또는 한 줄 설명, 주요 키워드/역량 태그 정도만 간결하게 보여주기로 했습니다.

AI 분석 상태는 완전히 제거하지 않고, “분석 완료 / 미분석” 정도의 작은 상태 배지로만 표시하기로 했습니다. 자세한 분석 결과 확인이나 분석 요청은 활동 경험 상세 화면에서 하도록 변경했습니다.

 

정렬과 필터에 대해서도 논의했습니다.

시간순 정렬은 반영하기로 했고, 키워드순/태그순 정렬은 명확한 순서 기준이 애매할 수 있어서 정렬보다는 주요 키워드 또는 역량 태그 기준 필터로 반영하는 방향이 더 적절하다고 판단했습니다.

활동 경험 상세 화면 추가

검토 과정에서 가장 중요하게 발견한 부분은 활동 경험 상세 화면이었습니다.

기존 SCREEN_SPEC.md에서는 활동 경험 상세 화면이 독립적으로 충분히 정리되어 있지 않았습니다. 하지만 실제 서비스 흐름을 생각해보면 상세 화면은 반드시 필요했습니다.

사용자는 목록에서 활동 경험을 선택한 뒤, 저장된 원본 내용을 확인하고, 수정하거나 삭제할 수 있어야 합니다. 또한 AI 분석 요청도 작성 화면이 아니라 상세 화면에서 실행되는 것이 더 자연스럽다고 판단했습니다.

 

그래서 활동 경험 상세 화면을 새로 추가했습니다.

상세 화면에서는 저장된 활동 경험 내용을 확인할 수 있고, 다음 행동을 할 수 있도록 정리했습니다.

 

활동 경험 수정
활동 경험 삭제
AI 분석 요청
저장된 AI 분석 결과 확인
활동 경험 목록으로 돌아가기

 

이렇게 정리하니 작성/수정 화면과 상세 화면의 역할도 분명해졌습니다.

작성/수정 화면은 입력과 수정에 집중하는 폼 UI입니다. 새 활동 경험 작성과 기존 활동 경험 수정은 같은 폼 구조를 공유합니다.

반면 상세 화면은 저장된 경험을 확인하고, 분석을 요청하거나 다음 행동으로 넘어가는 화면입니다.

AI 경험 추천 및 활용 화면 정리

AI 경험 추천 및 활용 화면도 다시 정리했습니다.

처음에는 “추천 경험 카드”라는 표현이 있었는데, 팀원 입장에서도 이것이 정확히 무엇을 의미하는지 모호하다는 피드백이 있었습니다.

그래서 추천 경험 카드를 다음과 같이 정의했습니다.

추천 경험 카드는 사용자가 입력한 자기소개서 문항, 포트폴리오 작성 목적, 면접 질문에 가장 적합하다고 AI가 판단한 활동 경험을 요약해서 보여주는 결과 카드입니다.

 

카드 안에는 다음 정보가 들어가도록 정리했습니다.

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

 

이렇게 정리하니 추천 경험 카드가 단순히 “AI가 고른 경험 하나”가 아니라, 사용자가 실제 자기소개서나 포트폴리오 작성에 바로 활용할 수 있는 결과물이라는 점이 분명해졌습니다.

또한 활용 추천 입력 유형에는 자기소개서 문항, 포트폴리오 작성 목적, 면접 질문 외에 “기타 문항”도 추가하기로 했습니다.

팀 디스코드 회의

팀원들과 디스코드 회의를 진행했습니다.

이번 회의에서는 각자 문서를 읽고 피드백을 공유했습니다.

 

건우는 USER_FLOW.md, IA.md, SCREEN_SPEC.md를 보면서 실제 화면 흐름과 사용성 관점에서 많은 피드백을 주었습니다. 특히 활동 경험 목록 화면을 간결하게 만들고, AI 분석 요청은 상세 화면에서 실행하도록 분리하자는 의견이 좋았습니다.

 

동현이는 GitHub 협업 방식과 사용자 기능 관점에서 질문과 피드백을 주었습니다. 특히 Pull Request가 무엇인지, 브랜치와 어떻게 다른지에 대해 질문했고, 이를 정리하면서 팀원 모두가 GitHub 협업 흐름을 더 명확히 이해하게 되었습니다.

 

앞으로는 기능별로 브랜치를 만들고, 작업이 끝나면 Pull Request를 올리고, 팀원이 검토한 뒤 main에 머지하는 방식으로 개발을 진행할 예정입니다.

이번 회의의 핵심은 단순히 문서를 수정하는 것이 아니라, 팀원들이 같은 기준으로 문서를 읽고 같은 방향으로 개발할 수 있도록 맞추는 것이었습니다.

7월 5일 멘토링 정리

오후 4시에는 멘토링도 진행했습니다.

멘토링에서는 지난 한 주 동안 진행한 문서 작업과 GitHub 협업 준비 상황을 공유했습니다. 저희 팀은 아직 본격적인 개발을 시작하지는 않았지만, GitHub Organization과 저장소를 만들고, 팀원들이 Git과 Pull Request를 공부하고, 여러 .md 문서를 함께 검토한 상태였습니다.

멘토님은 먼저 .md 파일 구조를 생각보다 잘 잡아놓았다고 말씀해주셨습니다. 저도 이렇게 많은 문서를 갖추고 개발을 시작하는 것은 처음이었기 때문에 이 구조가 실제 개발에 도움이 될지 궁금했습니다.

 

가장 중요한 질문은 이것이었습니다.

문서와 설계를 어느 정도 정리했으니, 이제 Codex가 이 문서들을 참고해서 개발을 잘해줄 수 있을까?
그리고 팀원들과 협업할 때는 어떤 방식으로 개발을 시작하는 것이 좋을까?

멘토님은 처음부터 모든 기능을 한 번에 개발하기보다, 먼저 메인 화면 하나를 구성해보고 그 과정을 통해 협업 흐름을 연습하는 방향이 좋다고 조언해주셨습니다.

 

즉, 바로 전체 서비스를 만들려고 하기보다, 메인 화면을 먼저 만들고, 그 후 기능 단위로 브랜치를 나누어 개발하는 방식입니다.

이 피드백을 듣고 저희 팀도 개발 시작 방식을 더 현실적으로 잡을 수 있었습니다.

기능 단위로 브랜치를 나누기

멘토님은 협업에서 브랜치 전략이 중요하다고 강조하셨습니다.

기업 환경에서도 보통 큰 기능 단위를 기준으로 브랜치를 따고, 해당 기능 개발이 끝나면 Pull Request를 통해 main 브랜치에 합치는 방식으로 많이 개발한다고 설명해주셨습니다.

 

저희 팀도 앞으로 다음과 같은 방식으로 개발하려고 합니다.

먼저 메인 화면을 만든다.
그 화면을 기준으로 전체 UX를 확인한다.
이후 활동 경험 작성, 활동 경험 목록, 활동 경험 상세, AI 분석 결과, 활용 추천 화면처럼 기능 단위로 브랜치를 나눈다.
각 기능 개발 후 Pull Request를 올린다.
팀원이 변경 사항을 검토한 뒤 main에 머지한다.

 

이렇게 하면 팀원 세 명이 동시에 작업하더라도 충돌을 줄이고, 각자 어떤 기능을 맡았는지 명확하게 관리할 수 있습니다.

코드 전체를 다 이해하려고 하기보다 워크플로우를 이해하기

멘토링에서 인상 깊었던 또 하나의 내용은 코드 이해에 대한 부분이었습니다.

저희 팀은 모두 컴퓨터공학, 인공지능 관련 전공이기 때문에 Codex가 만든 코드도 최대한 이해하면서 개발하고 싶었습니다. 하지만 멘토님은 AI Agent가 만들어내는 코드의 속도를 사람이 모두 따라가기는 어렵다고 말씀해주셨습니다.

AI Agent는 짧은 시간 안에 많은 코드를 생성할 수 있습니다. 사람이 그 코드를 한 줄 한 줄 전부 이해하고 리뷰하려고 하면 오히려 사람이 병목이 될 수 있습니다.

 

그래서 모든 코드를 완벽히 이해하겠다는 접근보다, 기능이 어떤 워크플로우로 돌아가는지, API가 어떻게 호출되는지, 데이터가 어떤 흐름으로 이동하는지를 이해하는 방향이 더 현실적이라고 조언해주셨습니다.

물론 코드 리뷰를 포기하라는 뜻은 아니었습니다.

 

오히려 코드 리뷰도 Codex에게 시키되, 개발한 에이전트와 리뷰하는 에이전트를 분리해야 한다는 점을 강조해주셨습니다.

개발을 한 에이전트가 자기 코드를 다시 리뷰하면 사람처럼 자기 판단을 더 신뢰하는 오류가 생길 수 있기 때문입니다.

따라서 앞으로는 기능 개발을 시킬 때와 코드 리뷰를 시킬 때 역할을 분리해서 요청하려고 합니다.

예를 들어 프론트엔드 개발 에이전트, 백엔드 개발 에이전트, UI/UX 검토 에이전트, 코드 리뷰 에이전트를 명확히 나누어 요청하는 방식입니다.

이 부분은 AGENTS.md에도 추가로 반영할 예정입니다.

AGENTS.md를 중심 문서로 관리하기

멘토님은 여러 .md 문서 중에서도 AGENTS.md의 중요성을 다시 강조해주셨습니다.

Codex가 기본적으로 참고하도록 설계된 문서는 AGENTS.md이기 때문에, 다른 문서를 언제 참고해야 하는지, 작업 후 어떤 로그를 남겨야 하는지, 어떤 방식으로 코드 리뷰를 해야 하는지 등을 AGENTS.md에 명확히 적어두는 것이 좋다고 했습니다.

 

현재 저희 팀은 WORK_STATUS.md, TASK_LOG.md, ISSUE_LOG.md, TODO.md 같은 작업 상태 기록 문서도 만들고 있습니다.

하지만 Codex가 이 문서들을 매번 알아서 참고하지 않을 수 있기 때문에, AGENTS.md 안에 다음과 같은 규칙을 더 명확히 넣어야 한다고 판단했습니다.

작업 전 관련 문서 확인하기
작업 범위 먼저 계획하기
요청한 범위만 수정하기
개발 후 작업 상태 기록하기
WORK_STATUS.md와 TASK_LOG.md 업데이트하기
필요한 경우 별도 코드 리뷰 에이전트 사용하기
기능 단위 브랜치와 Pull Request 흐름 지키기

 

이렇게 정리하면 Codex가 단순히 코드를 만드는 도구가 아니라, 팀의 작업 규칙을 따르는 협업 파트너처럼 움직일 수 있을 것이라고 생각했습니다.

디자인 참고 자료도 찾기 시작하다

이번 멘토링에서는 디자인에 대한 질문도 했습니다.

저희 팀은 모두 개발 쪽 전공이라 디자인 감각이나 UI 참고 자료를 어디서 찾아야 할지 막막했습니다. 멘토님은 design.md 형태로 여러 기업의 디자인 시스템을 참고할 수 있는 자료를 알려주셨습니다.

 

https://getdesign.md/

https://getdesign.kr/

 

예를 들어 글로벌 기업이나 국내 서비스의 디자인 스타일을 .md 파일 형태로 정리한 자료를 참고하고, 원하는 디자인 컨셉을 골라 CampusLog의 design.md에 반영할 수 있다고 설명해주셨습니다.

이 조언을 듣고, 단순히 화면을 아무렇게나 만드는 것이 아니라 우리가 원하는 서비스 분위기와 UI 기준을 문서로 정의해야겠다고 느꼈습니다.

 

7월 7일 라이브 강의에서도 design.md와 프론트엔드, 백엔드, DB 개념을 다룰 예정이기 때문에, 강의를 듣고 CampusLog의 디자인 기준도 정리할 예정입니다.

이번 주에 할 일

이번 회의와 멘토링을 바탕으로 이번 주에 해야 할 일을 정리했습니다.

 

먼저 USER_FLOW.md와 SCREEN_SPEC.md를 최종 보완해야 합니다.

특히 이번 회의에서 나온 내용들을 반영해 활동 경험 상세 화면, 분석 완료/미분석 상태 배지, 추천 경험 카드 정의, 기타 문항 입력, 역량 태그 구조 등을 문서에 반영할 예정입니다.

 

다음으로 AGENTS.md를 다시 보완해야 합니다.

멘토링에서 들은 것처럼 Codex가 어떤 문서를 언제 참고해야 하는지, 개발 에이전트와 코드 리뷰 에이전트를 어떻게 분리할지, 작업 후 어떤 기록을 남길지 더 명확하게 적어야 합니다.

 

또한 design.md도 준비해야 합니다.

7월 7일 라이브 강의를 들은 뒤 CampusLog의 디자인 방향을 정하고, 메인 화면부터 먼저 구현해볼 예정입니다.

 

이번 주의 목표는 다음과 같습니다.

 

USER_FLOW.md 최종 보완
SCREEN_SPEC.md 최종 보완
AGENTS.md에 서브 에이전트와 코드 리뷰 규칙 추가
design.md 작성
메인 화면 1차 구현
기능 단위 브랜치 전략 적용
Pull Request 기반 협업 흐름 연습
활동 경험 작성/목록/상세 화면 개발 준비

마무리

이번 활동을 통해 느낀 점은, 개발을 시작하기 전 문서를 정리하는 과정이 생각보다 중요하다는 것입니다.

처음에는 문서가 많으면 Codex가 더 잘 개발해주지 않을까 하는 막연한 기대가 있었습니다. 하지만 회의와 멘토링을 거치면서 단순히 문서가 많은 것보다, 각 문서가 충돌하지 않고 실제 개발 작업으로 이어질 수 있어야 한다는 것을 알게 되었습니다.

또한 AI로 개발한다고 해서 사람이 할 일이 줄어드는 것만은 아니었습니다.

오히려 사람이 방향을 정하고, MVP 범위를 좁히고, 어떤 기능을 어떤 순서로 만들지 판단해야 했습니다. AI가 코드를 빠르게 만들 수 있다면, 사람은 그 속도를 관리할 수 있는 구조와 규칙을 만들어야 합니다.

 

이번 주에는 USER_FLOW.md와 SCREEN_SPEC.md를 중심으로 사용자 흐름과 화면 구조를 다시 정리했고, 팀원들의 피드백을 통해 놓쳤던 화면과 기능을 발견할 수 있었습니다.

이제 CampusLog는 단순한 아이디어 문서에서 조금씩 실제 개발 가능한 프로젝트 구조로 바뀌고 있습니다.

다음 단계에서는 design.md를 정리하고, 메인 화면부터 하나씩 구현하면서 본격적인 MVP 개발을 시작해보려고 합니다.