[UNIKER] 대학생 AI 크루 UNIKER 1기 1주차 라이브 강의 정리: AI Agent와 MVP를 제품으로 만드는 법

2026년 6월 23일, UNIKER 1기 첫 번째 라이브 강의가 진행되었다.

 

이번 강의의 주제는 “AI Agent와 서비스 팀으로 일하는 법” 이었다. 단순히 Codex 사용법을 배우는 시간이 아니라 우리가 가진 아이디어를 실제 서비스 프로젝트로 바꾸기 위해 어떤 기준으로 문제를 정의하고, MVP 범위를 줄이고, Codex와 GitHub를 활용해 팀 단위로 작업해야 하는지를 배우는 시간이었다.

 

이번 글은 1주차 강의 내용을 정리하고, 우리 팀이 앞으로 어떤 방식으로 프로젝트를 진행해야 할지 기록하기 위해 작성했다.

---

1. 이번 강의의 핵심 주제

이번 강의의 큰 흐름은 다음과 같았다.

1. AI 서비스란 무엇인가
2. 10주차 최종 발표에서 무엇을 검증해야 하는가
3. MVP를 어떻게 작게 정의할 것인가
4. AI Agent와 Codex를 어떻게 활용할 것인가
5. GitHub로 팀 협업을 어떻게 관리할 것인가
6. 1주차 안에 어떤 문서 산출물을 만들어야 하는가

강의 초반에는 AI 서비스와 MVP 검증 기준에 대해 다뤘고 이후에는 Codex와 GitHub를 실제 팀 프로젝트에 어떻게 적용할지 설명이 이어졌다.

개발 경험이 있는 입장에서는 Codex 설치나 GitHub 기본 개념 자체는 익숙한 내용도 있었다. 하지만 이번 강의에서 중요한 부분은 도구 사용법 자체보다 AI Agent를 프로젝트 팀원처럼 다루는 방식이었다고 생각한다.

---

2. 10주차 발표 검증 기준

이번 강의에서 인상 깊었던 부분 중 하나는 10주차 발표 검증 기준이었다.

최종 발표에서 중요한 것은 단순히 “멋진 아이디어를 냈다”가 아니라, 다음 네 가지를 얼마나 설득력 있게 보여줄 수 있는지라고 이해했다.

문제

우리가 해결하려는 문제가 실제로 존재하는지 보여줘야 한다. 단순히 “있으면 좋겠다” 수준이 아니라 특정 사용자가 반복적으로 겪는 불편함이어야 한다.

캠퍼스로그의 경우 문제는 다음과 같이 정리할 수 있다.

대학생들은 여러 활동 경험을 쌓지만, 그 기록이 블로그, GitHub, 노션, 사진첩, 공모전 제출 자료 등에 흩어져 있어 취업 준비나 대외활동 지원 시 다시 정리하는 데 많은 시간을 쓴다.

사용자

누구를 위한 서비스인지 명확해야 한다. 모든 대학생을 대상으로 잡으면 너무 넓다.

1차 MVP에서는 다음과 같이 좁히는 것이 좋다고 생각한다.

대외활동, 공모전, 프로젝트 경험이 있고 이를 자기소개서나 포트폴리오로 정리해야 하는 대학생

특히 3~4학년 취업 준비생, 개발자 포트폴리오를 준비하는 학생, 대외활동 지원서를 자주 쓰는 학생이 초기 사용자로 적합하다고 생각한다.

제품

아이디어가 아니라 실제로 작동하는 제품이 필요하다.

이번 UNIKER 프로젝트는 발표 자료만 만드는 활동이 아니라 최종적으로 사용자가 직접 체험할 수 있는 서비스 링크를 만드는 것이 목표다. 따라서 우리 팀도 예쁜 기획서보다 실제 사용 가능한 흐름을 먼저 만들어야 한다.

증거

마지막으로 사용자가 실제로 이 서비스를 필요로 한다는 증거가 필요하다.

예를 들면 다음과 같은 방식으로 증거를 만들 수 있다.

• 주변 대학생 인터뷰
• 기존 자기소개서 작성 경험 조사
• 활동 기록 정리 전후 비교
• AI가 만든 문장에 대한 사용자 만족도
• 데모 링크를 사용해본 사람들의 피드백

결국 최종 발표에서는 “우리가 열심히 만들었다”보다 “이 문제가 실제로 있고 우리가 만든 MVP가 그 문제를 어느 정도 해결했다”를 보여줘야 한다.

---

3. MVP는 작게 시작해야 한다

이번 강의에서 가장 많이 남은 메시지는 기능을 줄여야 한다는 것이었다.

처음 서비스를 기획하다 보면 넣고 싶은 기능이 계속 늘어난다. 로그인, 회원가입, 대시보드, 커뮤니티, 친구 기능, 알림, 공유 기능, 고급 개인화 등 생각나는 기능은 많다.

하지만 10주 안에 실제로 작동하는 서비스를 만들어야 한다면 기능을 많이 넣는 것이 오히려 위험할 수 있다. 기능이 많아질수록 개발해야 할 범위가 커지고, 테스트해야 할 경우의 수도 늘어나며, 정작 핵심 기능의 완성도가 떨어질 수 있다.

그래서 1차 MVP에서는 다음 기준으로 기능을 줄여야 한다고 생각했다.

반드시 남길 기능

캠퍼스로그 기준으로는 다음 세 가지가 핵심이다.

1. 활동 기록 입력
2. AI 경험 요약 및 역량 추출
3. 포트폴리오 또는 자기소개서 문장 생성

이 세 가지 흐름만 제대로 작동해도 사용자는 캠퍼스로그의 핵심 가치를 체험할 수 있다.

과감히 제외할 기능

반대로 1차 MVP에서 제외해도 되는 기능은 다음과 같다.

• 로그인
• 회원가입
• 결제
• 커뮤니티
• 친구 기능
• 활동 피드
• 알림
• 실시간 협업
• 고급 개인화
• 복잡한 통계 대시보드

특히 로그인과 회원가입은 보통 서비스 개발에서 기본처럼 느껴지지만 MVP 검증 단계에서는 꼭 필요하지 않을 수 있다. 사용자가 활동 기록을 입력하고 AI 결과를 확인하는 것이 핵심이라면, 초기 데모에서는 로그인 없이도 충분히 검증할 수 있다.

이번 강의를 들으며 “기능을 많이 만드는 것”보다 “핵심 기능을 전면에 배치하는 것”이 더 중요하다고 느꼈다.

---

4. 레이턴시와 사용자 경험

AI 서비스를 만들 때는 LLM API를 어떻게 붙일지도 중요하지만 사용자가 체감하는 반응 속도도 중요하다.

AI 기능은 일반적인 버튼 클릭보다 응답 시간이 길어질 수 있다. 사용자가 활동 기록을 입력하고 분석 버튼을 눌렀는데 아무 반응이 없다면 서비스가 멈춘 것처럼 느껴질 수 있다.

따라서 MVP에서도 최소한 다음 상태를 고려해야 한다.

• loading: AI가 분석 중인 상태
• empty: 입력값이 없거나 결과가 없는 상태
• error: API 호출 실패 또는 분석 실패 상태
• success: 분석 결과가 정상적으로 나온 상태

이 부분은 강의에서 다룬 화면 명세 파일과도 연결된다. 단순히 “결과 화면을 만든다”가 아니라 사용자가 기다리는 동안 어떤 문구를 볼지, 실패했을 때 어떻게 다시 시도할지까지 설계해야 한다.

캠퍼스로그에 적용하면 다음과 같은 문구를 생각해볼 수 있다.

• loading: “활동 경험을 분석하고 있습니다.”
• empty: “아직 입력된 활동 기록이 없습니다.”
• error: “분석 중 문제가 발생했습니다. 잠시 후 다시 시도해주세요.”
• success: “경험 요약과 역량 분석이 완료되었습니다.”

작은 문구처럼 보이지만, 이런 상태 설계가 실제 사용성에 큰 영향을 줄 수 있다고 생각한다.

---

5. AI Agent는 작업 단위로 이해해야 한다

이번 강의에서 AI Agent를 이해하는 방식도 인상 깊었다.

기존의 ChatGPT 사용 방식은 질문을 던지고 답변을 받는 것에 가까웠다. 하지만 Codex 같은 AI Agent는 답변을 잘하는 도구라기보다 폴더와 파일을 읽고, 목표를 이해하고, 작업을 수행하고, 결과를 검증하는 작업 환경에 가깝다.

즉 AI Agent에게 중요한 것은 단순히 “좋은 답변”이 아니라 작업 단위다.

예를 들면 다음과 같다.

• ChatGPT: 아이디어를 설명하고 의견을 받는다
• IDE Copilot: 코드 한 줄 또는 파일 단위 보완을 받는다
• Codex: 프로젝트 폴더를 기준으로 실제 작업을 맡긴다
• Team: 사람이 방향을 정하고 결과를 검토한다

여기서 사람은 방향을 정하고, 범위를 줄이고, 결과를 판단해야 한다. Codex는 파일을 읽고, 명령을 실행하고, 증거를 남길 수 있다.

강의에서 언급된 Human in the Loop 방식도 이와 연결된다. AI에게 모든 것을 맡기는 것이 아니라 사람이 목표와 기준을 정하고 AI가 작업한 결과를 검토하는 방식이다.

 

나는 이 부분이 앞으로의 개발 방식과도 연결된다고 느꼈다. 예전에는 React 문법, Spring 구조, 데이터베이스 설계 등을 바텀업으로 공부한 뒤 서비스를 만들었다면 이제는 문제와 사용자 흐름을 먼저 잡고 필요한 만큼 코드를 생성하고 검증하는 탑다운 방식이 점점 중요해지고 있다.

다만 AI가 코드를 만들어준다고 해서 개발자가 코드를 몰라도 된다는 뜻은 아니다. 직접 코딩하지 않았더라도, 이후에는 생성된 코드를 다시 읽고 이해하면서 내 코드로 만드는 과정이 필요하다.

---

6. 하네스는 모델의 작업 환경이다

강의 중 “하네스”라는 개념도 나왔다.

처음 들으면 낯설지만, 쉽게 말하면 하네스는 모델이 실제로 작업할 수 있도록 연결된 환경이라고 이해했다.

• Model은 생각하고 답을 만든다
• Harness는 파일, 도구, 실행 환경, 권한, 검증을 연결한다
• Agent는 모델과 하네스를 활용해 실제 작업을 수행한다

즉 Codex를 잘 쓰려면 단순히 좋은 모델을 고르는 것만으로는 부족하다. 모델이 어떤 파일을 볼 수 있는지, 어떤 명령을 실행할 수 있는지, 어떤 기준으로 검증해야 하는지를 함께 설계해야 한다.

이 관점에서 보면 PRD.md, README.md, AGENTS.md 같은 문서들은 단순한 문서가 아니라 AI Agent에게 프로젝트 맥락을 제공하는 작업 환경의 일부라고 볼 수 있다.

---

7. GitHub 협업: 공용 문서와 제안 모드

이번 강의에서는 GitHub 협업도 다뤘다.

팀 프로젝트에서는 각자 작업한 내용을 안전하게 공유하고, 변경 사항을 추적하고, 필요한 경우 되돌릴 수 있어야 한다. GitHub는 단순히 코드를 저장하는 공간이 아니라, 팀의 작업 맥락을 공유하는 공간이다.

이번 프로젝트에서 우리 팀은 GitHub Organization을 만들고 그 안에 캠퍼스로그 repository를 생성하는 방식이 적절해 보인다.

예상 구조는 다음과 같다.

organization: team-pitjul 또는 campuslog-team
repository: campuslog
main branch: 배포 가능한 안정 버전
develop branch: 통합 개발 버전
feature branches: 기능별 작업 브랜치

 

브랜치는 사람별로 나눌 수도 있고 기능별로 나눌 수도 있다. (고민중에 있다)

사람별 브랜치 예시는 다음과 같다.

feature/moongi
feature/donghyun
feature/geonwoo

하지만 실제 개발에서는 기능별 브랜치가 더 명확할 수 있다.

feature/activity-input
feature/ai-summary
feature/result-page
feature/readme-docs

기능별 브랜치로 나누면 어떤 기능이 어떤 PR에 들어갔는지 명확하고 팀원들이 리뷰하기도 쉽다.

강의에서는 Git 명령어를 직접 외우기보다 Codex에게 요청하는 방식도 소개됐다. 예를 들어 다음처럼 요청할 수 있다.

현재 브랜치와 변경 파일을 확인하고,
어떤 파일이 수정되었는지 요약해줘.
아직 commit, push, merge는 하지 마.

또는 다음처럼 요청할 수 있다.

현재 변경 사항을 확인하고,
커밋 메시지를 추천해줘.
내가 확인하기 전에는 commit 하지 마.

이 방식의 핵심은 AI에게 바로 실행시키는 것이 아니라 먼저 확인하게 하는 것이다. 특히 commit, push, merge는 팀 프로젝트에 영향을 주는 작업이므로 사람이 마지막에 검토해야 한다.

---

8. 1주차 핵심 산출물: md 파일 정리

강의에서 본 예시와 첨부된 화면을 보면 1주차 안에 팀 프로젝트에 적용해야 할 가능성이 높은 문서 파일들이 있었다.

대표적으로 다음 파일들이다.

AGENTS.md
FLOW.md
IA.md
PRD.md
README.md
SCREEN_SPEC.md

여기에 추가로 NEXT_REQUEST.md까지 만들면 Codex에게 다음 구현을 맡기기 쉬워진다.

각 파일의 역할은 다음과 같이 이해했다.

PRD.md

Product Requirements Document의 약자다. 제품 요구사항 문서라고 볼 수 있다.

여기에는 다음 내용이 들어가야 한다.

• 해결하려는 문제
• 타깃 사용자
• 핵심 가설
• MVP 범위
• 제외할 기능
• 성공 기준

캠퍼스로그의 경우 PRD.md에는 “대학생 활동 경험 정리 문제”와 “활동 입력 → AI 요약 → 역량 추출 → 문장 생성” 흐름이 명확히 들어가야 한다.

README.md

프로젝트를 처음 보는 사람이 이해할 수 있는 문서다.

여기에는 다음 내용이 필요하다.

• 서비스 소개
• 팀 소개
• 실행 방법
• 기술 스택
• 폴더 구조
• 협업 규칙
• 배포 링크
• 현재 구현 상태

README.md는 나중에 최종 발표와 포트폴리오에서도 중요한 문서가 될 가능성이 높다.

AGENTS.md

AI Agent가 프로젝트를 이해하고 작업할 때 참고하는 규칙 파일이다.

여기에는 다음 내용이 들어가면 좋다.

• 프로젝트 목표
• Codex가 지켜야 할 작업 규칙
• 수정하면 안 되는 범위
• 코드 스타일
• MVP 범위
• 민감정보 금지
• 작업 전 확인할 문서 목록
• 완료 전 검증 기준

예를 들어 “로그인, 결제, 커뮤니티 기능은 만들지 않는다” 같은 제약을 AGENTS.md에 적어두면 Codex가 불필요한 기능을 만들 가능성을 줄일 수 있다.

IA.md

Information Architecture의 약자다. 서비스의 정보 구조를 정리하는 문서다.

MVP 기준으로 페이지는 3개 이하로 유지하는 것이 좋아 보인다.

캠퍼스로그의 1차 IA 예시는 다음과 같다.

1. Home / 입력 페이지
- 활동 기록 입력
- 분석 버튼
- 예시 입력 안내

2. Result / 분석 결과 페이지
- 경험 요약
- 핵심 역량
- 포트폴리오 문장

3. About 또는 Guide 페이지
- 서비스 목적
- 사용 방법
- 예시

하지만 더 줄인다면 입력과 결과를 한 화면에서 처리할 수도 있다.

FLOW.md

사용자 흐름을 정리하는 문서다.

예를 들면 다음과 같다.

사용자가 활동 기록을 입력한다.
분석 버튼을 클릭한다.
AI가 경험을 요약한다.
역량과 키워드를 추출한다.
포트폴리오 문장을 생성한다.
사용자는 결과를 복사하거나 저장한다.

여기에는 정상 흐름뿐 아니라 실패 상태도 들어가야 한다.

• 입력값이 비어 있을 때
• AI 응답이 실패했을 때
• 결과가 너무 짧거나 부정확할 때
• 네트워크 오류가 발생했을 때

SCREEN_SPEC.md

화면 명세 문서다.

각 화면에 어떤 요소가 들어가는지, 그리고 loading, empty, error, success 상태에서 어떤 문구와 UI를 보여줄지 정리한다.

캠퍼스로그 기준으로는 다음 요소가 필요하다.

입력 영역
분석 버튼
예시 입력 버튼
로딩 메시지
결과 카드
역량 태그
포트폴리오 문장 영역
복사 버튼
오류 메시지

NEXT_REQUEST.md

다음에 Codex에게 바로 맡길 첫 구현 요청문을 정리하는 문서다.

이 파일이 있으면 “이제 뭘 만들지?”를 매번 다시 고민하지 않아도 된다. PRD, IA, FLOW, SCREEN_SPEC을 바탕으로 Codex에게 복사해서 넣을 수 있는 요청문을 준비해두는 것이 목적이다.

---

9. 1주차 안에 해야 할 일 예상

아직 과제 안내가 최종적으로 어떻게 나올지는 봐야 하지만, 강의 흐름상 1주차 안에 우리 팀이 해야 할 일은 다음과 같다고 예상한다.

1. GitHub Organization 생성

팀 단위 협업을 위해 개인 repository보다 Organization을 만드는 것이 좋다고 생각한다.

예상 작업은 다음과 같다.

1. GitHub Organization 생성
2. 팀원 초대
3. campuslog repository 생성
4. README.md 기본 작성
5. main branch 보호 규칙 설정 여부 검토
6. feature branch 작업 방식 합의

2. 핵심 md 파일 작성

다음 파일들을 우선 작성해야 한다.

PRD.md
README.md
AGENTS.md
IA.md
FLOW.md
SCREEN_SPEC.md
NEXT_REQUEST.md

6개의 md 파일과 강의에서 받은 goal 명령어 흐름상 NEXT_REQUEST.md까지 만들면 다음 구현 단계로 넘어가기 쉽다고 생각한다.

3. MVP 범위 확정

캠퍼스로그의 1차 MVP 범위는 다음처럼 잡는 것이 적절해 보인다.

1. 활동 기록 입력
2. AI 요약 및 역량 추출
3. 포트폴리오 문장 생성

제외할 기능은 다음과 같다.

로그인
회원가입
결제
커뮤니티
친구 기능
실시간 협업
고급 개인화
복잡한 대시보드

4. 멘토링 질문 및 준비 내용 정리

이번 주 일요일에 20분 동안 멘토링이 진행되기 때문에, 짧은 시간 안에 최대한 많은 인사이트를 얻기 위해 질문을 미리 정리해두는 것이 중요하다.

멘토링에서는 단순히 궁금한 점을 묻기보다 현재 우리 팀의 방향과 고민을 기반으로 구체적인 질문을 준비하는 것이 좋다.

우선 우리 팀 상황을 간단히 정리하면 다음과 같다.

• 캠퍼스로그라는 AI 서비스 아이디어를 가지고 있음
• 1차 MVP 범위를 설정하는 단계
• Codex와 GitHub를 활용한 협업 구조를 고민 중
• 실제 구현을 시작하기 전 문서 정리 단계

이 상태를 기준으로 다음과 같은 질문들을 준비할 수 있다.

1. 문제 정의 및 방향성 관련 질문

• 현재 설정한 문제 정의가 충분히 구체적인지
• 타깃 사용자를 더 좁혀야 하는지
• 캠퍼스로그의 핵심 가치가 명확한지
• 비슷한 서비스와 차별화 포인트를 어떻게 잡아야 하는지

2. MVP 범위 관련 질문

• 현재 설정한 MVP 범위가 적절한지 (너무 크거나 작은지)
• 반드시 포함해야 할 기능과 제외해도 되는 기능
• 10주 안에 구현 가능한 현실적인 범위인지
• MVP 검증을 위해 꼭 필요한 사용자 경험 요소는 무엇인지

3. AI 기능 설계 관련 질문

• 활동 기록 → 요약 → 역량 추출 → 문장 생성 흐름이 적절한지
• AI 결과의 품질을 높이기 위한 방법 (프롬프트 설계 등)

4. Codex 및 개발 방식 관련 질문

• Codex를 활용할 때 가장 효율적인 작업 방식
• 문서 기반 개발 흐름(PRD, IA 등)이 실제로 효과적인지
• AI Agent에게 작업을 맡길 때 주의할 점
• 개발 경험이 있는 팀원이 어떤 역할을 맡는 것이 좋은지

5. GitHub 협업 관련 질문

• 팀 규모에서 적절한 브랜치 전략
• PR 리뷰를 어떻게 운영하는 것이 좋은지
• 초보 팀원과 함께 협업할 때 추천하는 방식
• Organization 구조를 어떻게 가져가는 것이 좋은지

6. 발표 및 검증 관련 질문

• 10주차 발표에서 가장 중요하게 보는 요소
• 사용자 검증을 어떻게 진행하면 좋은지
• 데모 수준에서 어느 정도 완성도를 목표로 해야 하는지
• 발표 자료와 실제 서비스 중 어디에 더 집중해야 하는지

멘토링 시간은 짧기 때문에 모든 질문을 다 하기보다는 우선순위를 정해서 핵심 질문 3~5개 정도를 중심으로 진행하는 것이 좋다.

또한 질문만 준비하는 것이 아니라, 현재 우리 팀의 상태를 1~2분 안에 설명할 수 있도록 간단한 요약도 준비해두면 멘토가 상황을 빠르게 이해하고 더 구체적인 피드백을 줄 수 있다.

멘토링은 단순히 답을 얻는 시간이 아니라, 우리 팀의 방향을 점검하고 수정할 수 있는 중요한 기회이기 때문에 최대한 준비해서 활용하는 것이 중요하다.

5. 팀 협업 규칙 정리

팀원들이 GitHub 사용 경험이 많지 않을 수 있으므로, 처음부터 복잡한 협업 규칙을 적용하기보다 단순한 규칙을 정하는 것이 좋다.

예상 규칙은 다음과 같다.

main에는 직접 push하지 않는다.
모든 작업은 feature branch에서 진행한다.
작업 전 README.md, PRD.md, AGENTS.md를 먼저 확인한다.
큰 변경 전에는 Slack이나 노션, 카톡으로 공유한다.
PR에는 변경 내용과 확인한 내용을 간단히 적는다.
merge는 팀장이 최종 확인한다.

---

10. 문서 완성용 Goal 명령어 예시

강의 마지막에 받은 goal 명령어는 매우 유용했다. 우리 팀 프로젝트에 맞게 바꾸면 다음과 같이 사용할 수 있다.

/goal 현재 폴더에서 캠퍼스로그의 1주차 제품 기획 산출물을 완성해줘.

먼저 PRD.md, README.md, AGENTS.md를 읽고 현재 상태를 5줄 이내로 요약해줘.

그 다음 아래 산출물을 만들거나 정리해줘.
- IA.md: 페이지 3개 이하, 각 페이지의 목적과 포함 정보
- FLOW.md: 기본 사용자 흐름과 실패 상태
- SCREEN_SPEC.md: 각 화면의 주요 요소와 loading, empty, error, success 상태
- NEXT_REQUEST.md: 다음에 Codex에게 맡길 첫 구현 요청문

제약:
- 아직 앱 코드는 만들지 마.
- MVP 기능은 1-3개로 유지해.
- 로그인, 결제, 커뮤니티, 친구 기능, 고급 개인화는 제외해.
- 실제 학생 이름, 전화번호, 카카오톡 ID, API 키 예시는 쓰지 마.
- PRD.md의 MVP 범위를 넘기는 아이디어는 "나중 후보"로 분리해.

검증:
- PRD.md, README.md, AGENTS.md, IA.md, FLOW.md, SCREEN_SPEC.md, NEXT_REQUEST.md가 서로 모순되지 않는지 확인해.
- 각 파일이 짧고 초보 팀원이 읽을 수 있는지 확인해.
- 완료 전에 파일 목록과 핵심 변경 사항을 요약해.

종료 조건:
- 위 7개 파일이 모두 존재하고,
- MVP 범위가 1-3개 기능으로 유지되고,
- 다음 구현 요청문을 그대로 복사해 쓸 수 있으면 멈춰.

진행 방식:
- 큰 변경 전에는 짧게 체크포인트를 남겨줘.
- 막히면 여러 질문을 하지 말고, 꼭 필요한 의사결정 하나만 물어보고 멈춰.

이 명령어에서 중요한 점은 단순히 “문서 만들어줘”라고 하지 않는다는 것이다. 읽어야 할 파일, 만들어야 할 산출물, 제외할 기능, 검증 기준, 종료 조건이 모두 들어 있다.

Codex에게 일을 잘 맡기려면 요청 자체가 하나의 작업 명세서가 되어야 한다는 것을 배웠다.

---

11. 구현용 Goal 명령어 예시

문서가 어느 정도 정리되면 다음 단계는 첫 웹 프로토타입 구현이다. 이때도 무작정 “웹사이트 만들어줘”라고 하는 것이 아니라, 문서를 기준으로 구현 범위를 제한해야 한다.

캠퍼스로그에 적용하면 다음과 같이 쓸 수 있다.

/goal Demo 폴더의 제품 문서를 기준으로 캠퍼스로그의 첫 번째 웹 프로토타입을 구현해줘.

반드시 먼저 PRD.md, README.md, AGENTS.md, IA.md, FLOW.md, SCREEN_SPEC.md를 읽고 구현 범위를 요약해줘.

목표:
- PRD.md의 1차 MVP 범위 안에서만 구현한다.
- 사용자가 활동명, 활동 기간, 역할, 수행 내용, 성과를 입력한다.
- AI 분석 결과로 경험 요약, 핵심 역량, 포트폴리오 문장 초안을 볼 수 있다.
- loading, empty, error, success 상태를 화면에서 확인할 수 있다.

제약:
- 로그인, 결제, 커뮤니티, 친구 기능, 고급 개인화는 만들지 않는다.
- 실제 외부 API 연결은 처음에는 만들지 않는다. 필요한 경우 로컬 mock 데이터로 처리한다.
- 실제 학생 개인정보나 API 키 예시는 쓰지 않는다.

검증:
- 프로젝트 실행 방법을 README.md에 적는다.
- 가능하면 로컬 실행 명령을 실행하고 결과를 확인한다.
- 브라우저 확인이 가능하면 주요 화면을 열어 상태별로 확인한다.
- 확인하지 못한 것은 완료했다고 말하지 않는다.

종료 조건:
- 첫 화면 프로토타입이 실행 가능하고,
- MVP 흐름이 화면에서 확인되고,
- README.md에 실행 및 검증 방법이 있으며,
- 남은 작업과 제외한 기능이 정리되어 있으면 멈춰.

이렇게 작성하면 Codex가 작업 범위를 지나치게 넓히는 것을 막을 수 있다. 특히 로그인이나 데이터베이스 설계부터 시작하지 않고, 사용자가 바로 체험할 수 있는 핵심 흐름부터 만들 수 있다.

---

12. 참고하면 좋은 확장 도구

강의 이후 참고 자료로 몇 가지 GitHub repository도 공유받았다.

https://github.com/obra/Superpowers
https://github.com/code-yeongyu/lazycodex
https://github.com/garrytan/gstack

이 자료들은 Codex를 더 체계적으로 활용하기 위한 확장 도구나 작업 방식에 가깝다.

아직 1주차부터 모두 적용할 필요는 없다고 생각한다. 우선은 기본 문서 구조와 MVP 범위를 먼저 잡고, 이후 프로젝트가 커지면 참고하는 방식이 적절해 보인다.

---

13. 우리 팀 캠퍼스로그에 적용할 방향

이번 강의를 듣고 캠퍼스로그의 방향도 조금 더 명확해졌다.

초기에는 대학생활 전체를 아카이빙하는 서비스로 생각했지만 MVP 단계에서는 범위가 너무 넓을 수 있다. 따라서 1차 MVP는 “대학생 활동 경험을 포트폴리오 문장으로 바꾸는 AI 도구”에 집중하는 것이 좋다고 생각한다.

현재 기준으로 캠퍼스로그의 MVP는 다음 한 문장으로 정리할 수 있다.

캠퍼스로그는 대학생이 흩어진 활동 경험을 입력하면, AI가 경험 요약·핵심 역량·포트폴리오 문장으로 정리해주는 서비스다.

 

이 문장에 포함되지 않는 기능은 일단 뒤로 미루는 것이 맞다.

 

예를 들어 “활동 기록을 장기적으로 저장하는 기능”은 중요하지만, 첫 데모에서는 로컬 상태나 임시 저장으로도 충분할 수 있다. “로그인 후 내 기록을 관리하는 기능”도 나중에는 필요하지만, 사용자가 AI 결과를 체험하는 데 반드시 필요한 것은 아니다.

지금 가장 중요한 것은 사용자가 활동 내용을 넣고, AI가 쓸 만한 결과물을 만들어주는 경험을 빠르게 보여주는 것이다.

---

15. 1주차를 마치며

이번 1주차 강의는 Codex와 GitHub를 처음 접하는 사람들에게는 기본 도구를 익히는 시간이었고 개발 경험이 있는 사람에게는 AI Agent 시대의 작업 방식 자체를 다시 생각하게 하는 시간이었다.

 

가장 크게 느낀 점은 세 가지다.

 

첫째, AI 서비스는 AI 기능 자체보다 사용자의 문제와 서비스 흐름이 중요하다.

둘째, MVP에서는 기능을 많이 넣는 것이 아니라 핵심 기능을 작게 검증해야 한다.

셋째, Codex는 단순 코드 생성기가 아니라 프로젝트 문서를 읽고, 목표에 맞게 작업을 수행하는 협업 파트너처럼 다뤄야 한다.

 

앞으로 우리 팀은 캠퍼스로그를 개발하면서 이 기준을 계속 의식해야 한다.
기능을 늘리고 싶은 마음이 들 때마다 “이 기능이 지금 MVP 검증에 꼭 필요한가?”를 먼저 물어봐야 한다.

 

또한 Codex에게 바로 구현을 맡기기보다 PRD, README, AGENTS, 화면 명세, 사용자 흐름을 먼저 정리해야 한다.

 

이번 주 안에는 GitHub Organization을 만들고, 팀 repository를 정리한 뒤, 1주차 핵심 md 파일을 작성하는 것을 목표로 한다.

이후에는 문서 기반으로 Codex에게 첫 웹 프로토타입 구현을 맡기고, 빠르게 작동하는 화면을 만들어볼 계획이다.

이번 강의를 통해 UNIKER 프로젝트가 단순한 교육 프로그램이 아니라, 실제 서비스를 만들어가는 실전 프로젝트라는 점을 다시 느꼈다.

앞으로 10주 동안 캠퍼스로그가 단순한 아이디어에서 실제 사용 가능한 AI 서비스로 발전하는 과정을 꾸준히 기록해보려고 한다.