[UNIKER 1기] 비전공자 개발일지(2) | 화면별 상세 PRD 작성, 피그마 와이어프레임 제작, GITHUB 수정 w. 코덱스

이전 이야기

 

 

 

 

지난주까지 기본 기획과 PRD 작성을 마쳤다.

이번 주에는 화면별 상세 PRD를 구체화하고, 피그마로 화면별 와이어프레임을 제작했다.

 

이번 주 한눈에 보기

• 사용 도구: 코덱스(PRD 작성), 클로드(와이어프레임 제작), 피그마
• 산출물: 화면별 상세 PRD, 피그마 와이어프레임 + 프로토타입 Flow
• 핵심 인사이트: 도구를 역할별로 나눠 쓰면 토큰은 아끼지만 맥락 공유가 끊긴다 / 디자인 일관성 유지는 클로드가 더 안정적이었다

 

---

1. 화면별 상세 PRD 구체화
PRD 상세화, 파일 나누기

 

기존에는 서비스 전체 개요 PRD만 작성했다면, 이제는 화면 단위로 PRD를 나눠 작성하기로 했다.

우리 서비스는 크게 아래 세 화면으로 구성된다.

 

1. 친구 목록 / 친구 추가
2. 채팅 목록 / 채팅 생성
3. 채팅 화면

 

나는 이 중 친구 목록 페이지를 맡아 구체화했다.

 

[AS-IS] 채팅 화면 PRD

- 채팅 헤더 (참여 멤버 표시)
- 메시지 리스트
- 입력창
- 전송 버튼
- 사용자 메시지 즉시 표시
- AI 입력 중 상태
- AI 생각 중 상태
- 채팅방 생성 직후 기본 메시지 표시
- 메시지 저장과 복원

 

 

기존 PRD는 화면에 어떤 요소가 있는지 나열하는 수준에 그쳤다.

여기에 지난 강의에서 배운 아래 프레임을 적용해 코덱스에게 화면 PRD 상세화를 요청했다.

 

• 첫 화면: 서비스 목적과 입력값
• 결과 화면: 사용자가 판단할 정보
• 실패 상태: 추천 없음, 오류, 미선택
• 다시 시도: 조건을 바꿔 다시 실행

 

 

별다른 설명 없이 요청했을 뿐인데, 코덱스가 알아서 위 프레임을 반영해 문서를 구체화해줬다.

진행 과정을 보니 기존에 작성해둔 상위 문서(README, PRD, Agent 파일)를 참고해 흐름을 짠 것 같았다.

 

💡 코덱스는 하나의 프로젝트에 로컬 파일을 연결해두면 새 채팅창에서도 해당 프로젝트 파일을 계속 참고한다. 덕분에 이전 작업 내용을 매번 설명하지 않아도 되고 토큰도 아낄 수 있어서 정말 편했다.

 

 

코덱스가 작성해준 상세 화면별 PRD를 검토하고, 수정할 부분을 다시 요청해 화면별 PRD 작성을 마무리했다.

 

 

 

PRD를 읽다 보니 상태별(입력 중, 오류 메시지 등) 와이어프레임을 따로 만들어야 하는지 궁금해져서 와이어프레임 제작 방법도 함께 물어봤다. 

 

그랬더니 UI 흐름도 만드는 방법도 알려줬다...

이렇게나 똑똑했다고...

---

2. 피그마로 PRD 기반 와이어프레임 만들기
Claude + Figma 연동하기

 

화면별 PRD를 구체화했다면 다음 단계는 와이어프레임 제작이다.

 

원래는 코덱스에 피그마 플러그인을 설치해 와이어프레임을 만들려고 했는데, 계정 관리자인 유니커/DAY1컴퍼니 쪽에서 아직 해당 플러그인을 승인하지 않은 상태였다.

 

유니커 운영매니저님께 승인 여부를 문의해두고, 그 사이에 개인 계정 클로드로 와이어프레임 제작을 진행했다.

 

1) 서식 세팅하기

 

AI에게 와이어프레임 제작을 요청하기 전에, 참고할 서식과 기본 요소를 먼저 세팅했다. 요즘 AI가 알아서도 꽤 깔끔하게 만들어주지만, 디자인 요소를 뺀 와이어프레임이라도 최대한 정돈된 레이아웃을 유지하고 싶었다.

 

 

아이콘은 피그마 커뮤니티에 공개된 리소스를 활용해 미리 페이지에 배치해뒀다.

피그마는 사용자들이 다양한 아이콘·UI 리소스를 커뮤니티에 공유해두기 때문에 필요한 요소를 쉽게 가져다 쓸 수 있다는 게 큰 장점이다.

 

 

이 중 하나를 골라 팀 피그마 페이지에 추가하고, 원하는 깔끔한 디자인으로 예시 페이지를 만들어뒀다.

 

2) 클로드에게 와이어프레임 제작 요청하기

클로드에게 피그마 페이지, PRD, README 파일을 주고 와이어프레임 제작을 요청했다.

 

글씨체·여백·색 등은 미리 만들어둔 기본 서식을 참고하도록 요청했고, 컴포넌트 구성이나 파일명 설정도 알아서 처리해달라고 했다.

 

 

결과물: 폰트가 잘 적용됐고, 미리 만들어둔 아이콘도 잘 들어갔으며, 텍스트·컴포넌트도 겹치지 않고 깔끔하게 만들어졌다.

생성된 화면을 하나씩 확인하며 수정이 필요한 부분을 정리한 뒤 다시 클로드에 전달해 수정을 요청했다. 또한 피그마 프로토타입 기능으로 화면 간 Flow도 함께 연결해달라고 요청했다.

 

 

Flow를 연결해두니 실제 화면이 어떻게 이어지는지, 사용자 흐름이 어떻게 구성되는지 한눈에 확인할 수 있어 편리했다.

실무에서 이 기능을 어느 정도까지 활용하는지는 아직 잘 모르겠지만, 피그마에 AI나 API를 연동해 프로토타입을 더 효율적으로 활용한다는 이야기도 들어본 것 같다. 나중에 시도해봐야지..

 

 

이 과정을 팀원들도 모두 거치면서 페이지별 PRD와 와이어프레임 제작을 완료했다.

 

작업하며 얻은 인사이트

1. AI 도구를 혼용하면서 느낀 점
- 이번에 코덱스로는 PRD 작성, ​클로드로 와이어프레임을 제작했는데, 역할을 분담하니 산출물 생성에 필요한 토큰을 분산해서 사용할 수 있어 좋았다.
- 하지만 두 AI가 서로의 작업 내용을 공유하지 않기 때문에 수정 사항이나 디자인 요소를 다시 전달해야 하는 경우가 자주 발생했다.
- 토큰을 분산해서 사용하니 토큰 관리 측면에서는 효율적이었지만, 작업의 연속성과 맥락 유지 측면에서는 아쉬움이 있었다. 앞으로도 AI를 역할별로 분리해서 사용하는 것이 좋은 방식인지에 대해서는 조금 더 고민해 볼 필요가 있다고 느꼈다.

2. 와이어프레임은 누가 더 잘 만들까?
- 이후 코덱스에서도 피그마 연동이 가능해져 동일한 작업을 진행해 보았다. 기존 디자인 서식을 유지해 달라고 요청했지만, 글꼴, 자간, 색상 등 세부 스타일은 반영되지 않는 경우​가 있었다.
- 프롬프트를 더 구체적으로 작성하면 될 것 같긴 하지만 디자인의 일관성을 유지하거나 기존 스타일을 반영하는 부분에서는 클로드가 더 안정적이라는 인상을 받았다.

 

---

3. 3주차 멘토링 정리

 

 

팀원들이 만든 나머지 PRD를 합치고 와이어프레임도 마무리한 뒤, 궁금한 점을 모아 3주차 멘토링을 진행했다.

 

멘토링을 요약해보자면 다음과 같다.

 

1. PRD 작성
- PRD는 하나의 문서에 모든 내용을 담기보다 전체 구조와 핵심 내용만 담는 것이 좋음
- 기능별로 spec/ 폴더를 만들어 chatting.md, user.md처럼 세부 문서 분리
- 문서가 길어졌다면 AI에게 구조를 개선하도록 요청하는 것도 좋은 방법
- 불필요한 내용을 제거하기사소한 작업도 AI에게 맡기되, 최종 검수는 사람이 꼼꼼하게 진행하는 것이 중요

2. Agents 활용
- 메인 시스템 프롬프트는 지나치게 길어지면 성능이 저하될 수 있음
- 강한 제약이나 규칙이 필요한 경우에는 메인 프롬프트뿐 아니라 Agent 프롬프트도 함께 관리하는 것이 좋음

3. 와이어프레임과 디자인
- 피그마에서 디자인한 결과물은 코덱스와 연동하여 활용할 수 있음
- 다만 현재 기준으로는 코덱스가 디자인을 100% 정확하게 재현하는 것은 어려움
- 피그마 연동 품질은 스킬(프롬프트)을 얼마나 정교하게 작성하느냐에 크게 영향을 받음
- 한 번에 전체 화면을 수정하기보다 화면 단위로 작업을 요청하는 방식이 더 안정적
- 프로젝트 규모가 커진다면 디자인 시스템을 먼저 구축하고 AI가 이를 참고하도록 하는 방식도 고려

4. 데이터 저장 방식
- 서버와 데이터베이스를 활용하는 방식이 가장 이상적
- 간단한 프로젝트라면 브라우저 스토리지를 사용하는 것도 현실적인 선택지
- 구현은 쉽지만 데이터가 삭제될 수 있다는 단점
- 여러 저장 방식을 AI에게 제안받고 프로젝트 목적에 맞게 선택하는 것도 좋은 방법

5. Gemini API 연동
- LLM API는 시스템 프롬프트와 사용자 프롬프트를 함께 전달하는 방식으로 동작
- 페르소나, 응답 규칙, 최근 대화 등을 함께 전달해 AI의 행동을 제어할 수 있음
- AI에게 API 구조를 Markdown 문서로 정리하거나, 페르소나 수정 위치를 설명하도록 요청하면 이해하기 쉬움
- Agent SDK는 메모리 활용과 복잡한 작업 처리에 강점이 있어, 향후 고도화 단계에서 검토해 볼 만한 선택지

 

우리가 궁금한 점에 대해 너무 잘 설명해주셨고, 진행도 원활히 되고 있는 것 같다고 해주셔서 너무 안심이 되었다..ㅎㅎ

 

이런 내용에 맞춰서, 다음주에는

 

(1) 프론트 개발(와이어프레임 기반 프로토타입 제작)

(2) 백엔드 개발(API 학습, 연동)

(3) 디자인 md 제작

 

으로 역할을 나누어 진행하려 한다.

 

그럼 다음주에 계속...