[UNIKER 1기] 2회차 라이브 강의 정리 — 화면 구조를 첫 프로토타입으로 바꾸는 법

UNIKER 1기 2회차 라이브 강의에서는 한서우 강사님과 함께 아이디어와 문서를 실제 프로토타입 화면으로 바꾸는 방법을 배웠다.

1회차에서는 AI Agent와 Codex의 기본 개념, GitHub 협업 방식, 프로젝트 문서화의 중요성을 배웠다면, 이번 2회차 강의는 한 단계 더 실전적이었다.

단순히 “Codex에게 만들어줘”라고 요청하는 것이 아니라 서비스 흐름을 화면 단위로 쪼개고, 화면 기준 문서를 만들고, 작업 브리프를 작성하고, 브라우저에서 직접 검증하는 방법까지 다뤘다.

 

우리 팀은 현재 대학생 활동 기록 기반 AI 포트폴리오 정리 서비스인 CampusLog를 만들고 있다.
그동안 PRD, USER_FLOW, IA, SCREEN_SPEC 같은 문서를 정리해왔다면 이번 강의를 들으면서 이제는 문서를 실제 MVP 화면으로 옮겨야 할 시점이라는 생각이 들었다.

이번 강의의 핵심: 디자인 완성이 먼저가 아니다

이번 강의에서 가장 기억에 남은 문장은 “디자인 완성이 먼저가 아닙니다”였다.

처음 서비스를 만들려고 하면 흔히 “일단 예쁘게 디자인부터 해야 하나?”라고 생각하기 쉽다. 나도 CampusLog의 화면을 만들기 전에 Figma를 제대로 해야 하는지, 아니면 DESIGN.md를 작성하고 바로 Codex에게 화면을 뽑게 할지 고민하고 있었다.

 

하지만 이번 강의에서 정리된 순서는 조금 달랐다.

먼저 PRD를 통해 누구의 어떤 문제를 풀 것인지를 고정한다.
그다음 사용자 흐름과 데이터 흐름을 정리한다.
이후 핵심 API나 AI 기능이 실제로 작동 가능한지 확인하고, MVP 화면만 잡는다.
그리고 더미 데이터로 프론트엔드를 구현한 뒤, 서버와 DB, 실제 API를 붙이면서 전체 흐름을 테스트한다.

 

즉, 처음부터 완성도 높은 디자인을 만들려고 하기보다, 핵심 흐름이 작동하는지 먼저 확인하는 것이 중요하다.

 

CampusLog에 적용하면 다음과 같다.

우리의 핵심 문제는 대학생들이 활동 경험을 흩어져 기록하고, 나중에 자기소개서나 포트폴리오로 활용하기 어렵다는 점이다.
그래서 첫 MVP에서는 모든 기능을 넣기보다, 사용자가 활동 경험을 입력하고, AI가 요약과 역량 태그, 활용 문장을 생성해주는 흐름이 먼저 작동해야 한다.

로그인, 회원가입, 커뮤니티, 파일 첨부, 고급 추천은 당장 핵심이 아니다.
지금은 “활동 기록 → AI 분석 → 결과 확인 → 저장/복사” 흐름이 실제 화면에서 자연스럽게 이어지는지가 더 중요하다.

첫 프로토타입은 두 화면으로 시작한다

강의에서는 첫 프로토타입을 만들 때 처음부터 많은 화면을 만들지 말고, 가장 핵심적인 두 화면부터 잡으라고 했다.

 

첫 번째는 사용자가 입력하는 화면이다.
여기에는 서비스 목적과 입력값이 들어간다.

두 번째는 결과 화면이다.
여기에는 사용자가 결과를 보고 판단할 수 있는 정보가 들어간다.

 

CampusLog 기준으로 생각하면 첫 번째 화면은 활동 경험 입력 화면이다.
사용자가 활동명, 활동 기간, 역할, 경험 내용, 느낀 점 등을 입력하고 “AI로 정리하기” 버튼을 누르는 화면이다.

두 번째 화면은 AI 분석 결과 화면이다.
여기에는 활동 요약, 역량 태그, 포트폴리오 문장, 자기소개서 문장, 복사 버튼, 저장 버튼이 들어간다.

처음에는 “활동 목록 화면도 필요하고, 저장된 결과 화면도 필요하고, 태그 모아보기 화면도 필요하지 않나?”라고 생각했지만, MVP 관점에서는 첫 화면과 결과 화면만으로도 핵심 가설을 검증할 수 있다.

사용자가 활동 경험을 입력했을 때 AI 결과가 유용하게 나오고, 그 결과를 복사하거나 저장하고 싶다고 느끼면 1차 가설은 어느 정도 검증되는 것이다.

실패 상태와 다시 시도 흐름도 기능이다

이번 강의에서 또 중요하게 느낀 부분은 실패 상태를 화면의 일부로 봐야 한다는 점이었다.

처음 MVP를 만들 때는 보통 성공 화면만 생각하기 쉽다.
“사용자가 입력한다 → AI 결과가 나온다 → 저장한다”처럼 정상 흐름만 생각한다.

하지만 실제 서비스에서는 항상 실패 상황이 생긴다.

AI 응답이 실패할 수도 있고, 결과가 너무 늦게 나올 수도 있다.
입력값이 부족할 수도 있고, 저장에 실패할 수도 있다.
모바일 화면에서 버튼이 잘릴 수도 있고, 글자가 너무 작게 보일 수도 있다.

 

그래서 이번 강의에서는 첫 프로토타입 단계에서도 empty, loading, error, success 같은 상태를 고려해야 한다는 점이 인상 깊었다.

CampusLog에도 이런 상태가 필요하다.

 

아직 기록한 활동이 없을 때는 빈 상태 화면이 필요하다.
AI가 분석 중일 때는 로딩 상태가 필요하다.
분석에 실패했을 때는 에러 메시지와 다시 시도 버튼이 필요하다.
결과가 정상적으로 나왔을 때는 저장, 복사, 다시 작성 버튼이 필요하다.

특히 실패 상태는 단순히 “오류가 발생했습니다”라고 끝내면 안 된다.
사용자가 다음에 무엇을 해야 하는지 알려줘야 한다.

 

예를 들면 이렇게 만들 수 있다.

“AI 분석에 실패했어요. 입력 내용은 사라지지 않았으니 다시 시도해보세요.”

이 문장 하나만 있어도 사용자는 안심할 수 있다.

 

이런 부분이 실제 사용성을 만든다는 점을 배웠다.

AI 빌딩 루프: 가설 → 기준 → 요청 → 실행 → 검증

이번 강의에서 정리한 작업 흐름 중 가장 실용적이었던 것은 AI 빌딩 루프였다.

강의자료에서는 AI로 제품을 만들 때 다음과 같은 흐름을 제시했다.

가설을 세운다.
기준을 문서로 남긴다.
Codex에게 요청한다.
실제로 실행한다.
브라우저와 모바일 화면에서 검증한다.

 

이 흐름을 보면서 Codex를 단순히 “코드 짜주는 AI”로 보면 안 된다는 생각이 들었다.
Codex는 내가 잘 정리한 문서와 기준을 바탕으로 작업하는 협업자에 가깝다.

결국 중요한 것은 프롬프트 한 줄이 아니라, Codex가 참고할 수 있는 기준을 얼마나 잘 남겨두느냐이다.

 

우리 팀은 이미 여러 문서를 작성해두었다.

PRD.md에는 어떤 문제를 풀지 정리했다.
USER_FLOW.md에는 사용자가 어떤 순서로 서비스를 쓰는지 정리했다.
IA.md에는 화면 구조와 이동 흐름을 정리했다.
SCREEN_SPEC.md에는 각 화면에 들어갈 요소를 정리했다.
이제 여기에 DESIGN.md를 추가해서 화면의 톤, 정보 우선순위, 모바일 기준, 상태 처리 기준을 정리하려고 한다.

 

이 문서들이 있어야 Codex에게 “알아서 예쁘게 만들어줘”가 아니라, “이 기준에 맞춰 구현해줘”라고 요청할 수 있다.

프롬프트보다 작업 브리프가 중요하다

강의에서 “프롬프트보다 작업 브리프”라는 말도 인상 깊었다.

나쁜 요청은 이런 식이다.

웹 예쁘게 만들어줘.
화면도 좋게 해주고 필요한 기능도 알아서 넣어줘.

 

이렇게 요청하면 Codex는 무엇을 기준으로 판단해야 하는지 알기 어렵다.
예쁜 게 무엇인지, 어떤 화면이 필요한지, 어떤 기능이 MVP에 포함되는지, 완료 기준이 무엇인지 모호하기 때문이다.

반면 좋은 요청은 목표, 맥락, 제약조건, 완료 기준이 들어간다.

@PRD.md @USER_FLOW.md @IA.md @SCREEN_SPEC.md를 읽고,
CampusLog 1차 MVP 기준으로 활동 경험 입력 화면과 AI 분석 결과 화면을 구현해줘.

목표:
사용자가 활동 경험을 입력하고, AI 분석 결과를 확인하는 핵심 흐름을 만든다.

제약:
로그인, 회원가입, 결제, 커뮤니티, 외부 연동은 구현하지 않는다.
1차 MVP는 sample data와 localStorage 기준으로 구현한다.

완료 기준:
- 390px 모바일 화면에서 좌우 스크롤이 생기지 않아야 한다.
- empty, loading, error, success 상태가 있어야 한다.
- 주요 버튼의 글자가 잘리지 않아야 한다.
- 결과 화면에는 요약, 역량 태그, 추천 문장, 복사 버튼이 보여야 한다.
- 브라우저에서 직접 버튼을 눌러보고 이상 여부를 알려줘.

 

이번 강의 이후 앞으로 Codex에게 요청할 때는 “무엇을 만들어줘”보다 “무엇을 기준으로, 어디까지 만들고, 어떻게 검증할지”를 함께 적어야겠다고 느꼈다.

DESIGN.md와 SCREEN_SPEC.md는 다르다

강의를 듣기 전에는 DESIGN.md와 IA.md, SCREEN_SPEC.md가 비슷하게 느껴졌다.

하지만 이번 강의를 통해 역할을 구분할 수 있었다.

 

IA.md는 화면 구조와 이동 흐름을 정리하는 문서다.
예를 들어 메인 화면에서 입력 화면으로 이동하고, 입력 후 결과 화면으로 이동하는 구조를 정리한다.

 

SCREEN_SPEC.md는 각 화면에 들어가는 구체적인 요소를 정리하는 문서다.
예를 들어 입력 화면에는 활동명 입력창, 기간 입력창, 역할 입력창, AI 분석 버튼이 있어야 한다고 적는다.

 

반면 DESIGN.md는 화면을 만들 때 지켜야 할 기준을 정리하는 문서다.
버튼은 어떤 느낌이어야 하는지, 결과 카드는 어떤 순서로 보여야 하는지, 모바일에서는 어떤 요소가 깨지면 안 되는지, 실패 상태는 어떻게 보여야 하는지를 정리한다.

 

CampusLog 기준으로 DESIGN.md에는 이런 내용이 들어가야 한다.

 

첫 화면은 서비스 목적과 입력값이 바로 보여야 한다.
결과 화면은 요약, 역량 태그, 추천 문장 순서로 보여야 한다.
버튼은 모바일에서 누르기 쉬워야 한다.
로딩 중에는 사용자가 기다릴 수 있도록 상태가 보여야 한다.
실패했을 때는 입력 내용이 사라지지 않아야 한다.
복사 버튼과 저장 버튼은 명확하게 구분되어야 한다.

 

즉, DESIGN.md는 “예쁘게 만드는 문서”가 아니라 Codex가 화면을 만들 때 흔들리지 않도록 잡아주는 기준 문서다.

디자인 감각도 입력값이다

강의자료에서 “디자인 감각 = 입력값”이라는 표현이 나왔다.

AI에게 디자인을 맡길 때도 그냥 감각에 맡기는 것이 아니라, 레퍼런스와 시스템, 컴포넌트를 입력값으로 줘야 한다는 의미로 이해했다.

예를 들어 우리 팀이 원하는 느낌은 단순히 “예쁘게”가 아니다.

 

건우가 말한 방향처럼, 핵심은 기능 구현에 더해서 마이크로 인터랙션, 상태 처리, 시각적 일관성을 갖춘 화면이다.

버튼 하나도 그냥 눌리는 것이 아니라, hover 시 살짝 밝아지고, 클릭하면 0.97배 정도 눌리는 느낌이 있으면 좋다.
비활성화 상태는 흐리지만 형태는 유지되어야 한다.
로딩 중에는 텍스트가 갑자기 사라지는 것이 아니라 spinner나 ellipsis로 자연스럽게 전환되면 좋다.

이런 기준을 말로만 기억하면 흐려진다.
그래서 DESIGN.md나 DESIGN_SYSTEM.md에 남겨야 한다.

 

우리 팀은 다음과 같은 디자인 기준을 정리해볼 수 있다.

• 전체 톤: 깔끔한 대학생 생산성 도구
• 화면 구조: 카드 기반
• 아이콘: Lucide Icons 사용
• 스타일링: Tailwind CSS
• UI 컴포넌트: shadcn/ui
• 프레임워크: Next.js / React
• 모바일 기준: 390px 기준 검증
• 참고 레퍼런스: Mobbin, Page Flows, Musinsa 등

디자인을 잘 모르는 팀이어도, 이렇게 기준을 문서화하면 Codex에게 훨씬 안정적으로 화면을 맡길 수 있다.

사진 삽입 추천: “디자인 감각 = 입력값”, “초보 팀 추천 스택” 장표

Figma를 먼저 할까, Codex로 바로 갈까?

강의를 들으면서 가장 현실적으로 고민했던 부분은 Figma였다.

우리 팀에는 전문 디자이너가 없다.
Figma를 써도 결국 AI 기능을 활용해서 초안을 만들 가능성이 높다.
그렇다면 굳이 Figma를 먼저 거쳐야 할까, 아니면 DESIGN.md를 작성하고 바로 Codex로 화면을 구현해도 될까?

강의를 들은 뒤 내 결론은 이렇다.

 

완성도 높은 Figma 디자인을 오래 붙잡고 있을 필요는 없다.
하지만 화면 방향을 맞추기 위한 짧은 레퍼런스 탐색과 시안 비교는 의미가 있다.

그래서 우리 팀은 이렇게 진행하려고 한다.

건우는 Codex와 Figma 연동을 활용해서 디자인 초안을 뽑아본다.
나는 다른 AI 디자인 툴(스티치)이나 레퍼런스를 활용해서 CampusLog에 맞는 UI 방향을 정리해본다.
이후 둘 중 괜찮은 방향을 선택하고, 스크린샷을 Codex에게 다시 전달해 화면별 이름을 붙인 뒤 UI/UX를 반영해서 개발을 요청한다.

 

중요한 것은 Figma 자체가 아니라, Codex에게 넘길 수 있는 명확한 화면 기준을 만드는 것이다.

Figma를 쓰든, Stitch 같은 AI 도구를 쓰든, 바로 Codex로 가든 최종적으로는 다음 기준을 만족해야 한다.

사용자가 입력할 수 있어야 한다.
결과를 판단할 수 있어야 한다.
실패 상태와 다시 시도 흐름이 있어야 한다.
모바일에서 깨지지 않아야 한다.
버튼과 카드의 시각적 일관성이 있어야 한다.

우리 팀 CampusLog에 적용할 계획

이번 강의 이후 우리 팀은 문서에서 개발로 넘어가기 위한 계획을 다시 정리했다.

7월 7일 라이브 강의를 듣고, 7월 8일에는 강의 내용과 강의자료, 기존 md 문서, 노션에 정리한 레퍼런스를 바탕으로 DESIGN.md를 완성한다.

이후 건우와 동현이가 DESIGN.md를 검토하고, 피드백을 반영해 최종본을 만든다.

7월 9일부터 10일 사이에는 개발 초안을 시작한다.
건우가 Codex Pro 계정을 사용할 수 있는 기간이 15일까지라서, 그 전에 Figma 연동과 AI 디자인 초안을 최대한 활용해보기로 했다.

이후에는 디자인 초안을 바탕으로 Codex에게 화면 구현을 요청하고, 동현이와 나는 결과를 검토하면서 피드백을 주는 방식으로 진행할 예정이다.

 

현재 생각하는 흐름은 다음과 같다.

1. 기존 PRD, USER_FLOW, IA, SCREEN_SPEC 점검
2. DESIGN.md 작성
3. 필요하면 DESIGN_SYSTEM.md 작성
4. Figma 또는 AI 디자인 툴로 MVP 화면 초안 생성
5. 화면별 스크린샷을 Codex에 전달
6. Codex에게 UI/UX 반영 개발 요청
7. 브라우저에서 버튼 클릭, 결과 확인, 실패 상태 확인
8. 모바일 폭에서 버튼 크기, 폰트 크기, 카드 배치 검증
9. 팀원 피드백 반영
10. 기능 단위로 PR 생성 후 리뷰

이번 강의 덕분에 막연히 “이제 개발해야 한다”가 아니라, 어떤 문서를 기준으로, 어떤 순서로, 어떤 화면부터 개발해야 하는지가 조금 더 명확해졌다.

다른 프로젝트에도 적용할 수 있는 체크리스트

이번 강의 내용은 CampusLog뿐만 아니라 앞으로 다른 프로젝트를 만들 때도 계속 쓸 수 있을 것 같다.

 

새로운 아이디어가 생기면 먼저 PRD로 문제와 사용자를 고정한다.
그다음 USER_FLOW로 사용자가 어떤 순서로 움직이는지 정리한다.
IA로 화면 구조를 잡고, SCREEN_SPEC으로 각 화면의 구성 요소를 정리한다.
DESIGN.md로 화면의 기준, 정보 우선순위, 모바일 검증 기준을 남긴다.
그 후 Codex에게 작업 브리프 형태로 요청한다.
마지막으로 브라우저와 모바일 화면에서 직접 검증한다.

 

앞으로 어떤 프로젝트를 하든 다음 질문을 먼저 던져보려고 한다.

사용자는 첫 화면에서 무엇을 해야 하는가?
결과 화면에서 무엇을 판단해야 하는가?
실패했을 때 어떻게 다시 시도할 수 있는가?
AI가 만든 결과를 사람이 어떻게 검증할 것인가?
모바일에서 실제로 쓸 수 있는가?

 

이 질문들에 답하지 못하면 아직 개발을 시작할 준비가 덜 된 것이다.