de

아래 프롬프트를 그대로 Claude에 붙여 넣어 사용하세요. 단, D:\de\... 경로는 Claude가 직접 접근할 수 없으므로 PDF·문서·Canvas 파일을 Claude에 직접 업로드하거나 Google Drive 공유 권한을 “링크가 있는 모든 사용자 보기 가능”으로 설정해야 합니다.

당신은 모바일 애플리케이션 분석가이자 UX/UI 디자이너, 프로토타이핑 전문가입니다.

나는 CITIZEN-107 모바일 애플리케이션의 기존 프로토타입을 완전히 재설계하려고 합니다. 기존 Canvas/화면은 수작업으로 제작되어 실제 구현된 애플리케이션과 정확히 일치하지 않을 수 있습니다. 따라서 기존 프로토타입을 기준으로 수정하지 말고, 실제 소스 코드와 프로젝트 문서를 기준으로 새로운 프로토타입을 처음부터 설계하세요.

프로젝트 정보:

- GitHub 저장소:
  https://github.com/kadarkadikadey/CITIZEN-107

- Google Drive 프로젝트 폴더:
  https://drive.google.com/drive/folders/1pYP_QEiu2Wd7KucYZoOcJWQ07qnCCgn_

Google Drive에는 다음 자료가 포함되어 있을 수 있습니다.

- 프로젝트 보고서 PDF
- 기존 Canvas 또는 화면 설계
- 추가 프로젝트 문서
- APK 또는 실행 파일
- 요구사항 문서
- 데이터베이스 및 기능 관련 자료
- 기타 프로젝트 참고자료

중요한 원칙:

1. GitHub 저장소를 먼저 전체적으로 분석하세요.
2. 프로젝트의 실제 소스 코드, 화면, 라우팅, API, 모델, 권한, 데이터 구조, 기능 구현을 확인하세요.
3. Google Drive의 프로젝트 보고서와 추가 문서를 읽고 GitHub 분석 결과와 비교하세요.
4. 기존 수작업 Canvas는 참고용으로만 확인하고, 최종 설계의 기준으로 사용하지 마세요.
5. 실제 구현되지 않은 기능, 화면, 버튼, 데이터, 사용자 역할 또는 워크플로를 임의로 추가하지 마세요.
6. 문서와 소스 코드의 내용이 서로 다르면 차이점을 명확히 기록하고, 실제 구현 상태를 우선하세요.
7. 확인할 수 없는 기능은 추측하지 말고 “확인 필요”로 표시하세요.
8. 앱의 실제 사용자 유형과 권한 구조를 확인한 뒤, 사용자 유형별로 필요한 화면과 흐름을 구분하세요.
9. 단순한 시각적 디자인이 아니라 실제 애플리케이션에서 작동 가능한 완전한 UX 프로토타입을 설계하세요.

먼저 다음 순서로 분석을 진행하세요.

## 1. 프로젝트 구조 분석

GitHub 저장소에서 다음 항목을 식별하세요.

- 사용한 프레임워크와 기술 스택
- Android/iOS 여부
- 앱의 시작 지점
- 화면 및 페이지 목록
- 네비게이션 구조
- 인증 방식
- 사용자 역할과 권한
- API 및 서버 통신
- 데이터 모델
- 로컬 저장소
- 위치 정보 사용 여부
- 알림 및 푸시 기능
- 카메라, 파일, 전화, SMS 등 기기 권한
- 외부 서비스 연동
- 오류 처리 방식
- 로그아웃 및 세션 만료 처리
- 실제로 구현된 기능과 미완성 기능

각 기능에 대해 다음 표를 작성하세요.

| 기능 | 관련 소스 파일 | 실제 구현 여부 | 사용자 역할 | 연결된 화면 | 비고 |
|---|---|---|---|---|---|

## 2. 문서 및 기존 자료 분석

Google Drive의 프로젝트 보고서와 추가 문서를 분석하세요.

다음 내용을 추출하세요.

- 프로젝트 목적
- 해결하려는 문제
- 주요 사용자
- 사용자 요구사항
- 기능 요구사항
- 비기능 요구사항
- 사용자 시나리오
- 시스템 흐름
- 데이터 흐름
- 역할별 사용 방식
- 긴급 상황 관련 요구사항
- 개인정보 및 보안 요구사항
- 보고서에 설명된 화면
- 실제 코드에 구현된 화면과의 차이

문서 내용과 코드가 일치하는지 다음과 같이 구분하세요.

- 코드와 문서 모두 확인됨
- 문서에만 존재함
- 코드에만 존재함
- 구현 여부 확인 필요

## 3. 실제 기능 목록 작성

코드와 문서 분석을 바탕으로 최종적으로 다음 목록을 작성하세요.

### 인증 및 계정

- 시작 화면
- 로그인
- 회원가입
- 이메일 또는 전화번호 인증
- 비밀번호 재설정
- 사용자 유형 선택
- 로그아웃
- 세션 만료
- 인증 실패
- 계정 삭제 또는 비활성화

위 항목 중 실제로 존재하는 것만 포함하세요.

### 주요 기능

실제 저장소에서 확인된 기능을 기준으로 다음과 같은 범주를 조사하세요.

- 대시보드
- 긴급 신고 또는 긴급 호출
- 긴급 연락처
- 도움 요청
- 경찰, 소방, 구급 관련 기능
- 병원 및 의료 리소스
- 도움 기관 또는 기관 디렉터리
- 지도 및 위치 기반 기능
- 공지사항
- 알림
- 신고 내역
- 요청 상태 확인
- 프로필
- 설정
- 고객지원
- FAQ
- 접근성 설정
- 언어 설정

이 목록에 없는 기능도 코드에 실제로 존재한다면 포함하세요. 반대로 코드에 존재하지 않는 기능은 포함하지 마세요.

## 4. 사용자와 사용자 역할 정의

실제 코드와 문서에 나타난 사용자 역할을 식별하세요.

각 역할에 대해 다음을 작성하세요.

- 역할 이름
- 주요 목적
- 접근 가능한 기능
- 접근할 수 없는 기능
- 로그인 후 첫 화면
- 주요 작업
- 권한 제한
- 역할별 사용자 흐름

관리자 화면이나 기관용 화면이 실제 애플리케이션에 존재하지 않는다면 임의로 설계하지 마세요.

## 5. 사용자 흐름 설계

실제 애플리케이션의 기능을 기준으로 완전한 사용자 흐름을 작성하세요.

최소한 다음 흐름을 검토하세요.

### 신규 사용자 흐름

앱 실행 → 온보딩 여부 → 회원가입 → 인증 → 프로필 설정 → 권한 요청 → 대시보드

### 기존 사용자 로그인 흐름

앱 실행 → 로그인 → 인증 성공 → 대시보드

### 인증 실패 흐름

로그인 실패 → 오류 메시지 → 재시도 또는 비밀번호 재설정

### 긴급 기능 흐름

대시보드 → 긴급 기능 선택 → 긴급 유형 선택 → 위치 또는 추가 정보 확인 → 확인 대화상자 → 요청 전송 → 접수 상태 → 처리 상태 또는 완료

단, 위 흐름의 각 단계는 실제 코드에 구현된 경우에만 포함하세요. 앱이 긴급 요청을 어떤 방식으로 처리하는지 소스 코드에서 확인하고 정확히 반영하세요.

### 도움 디렉터리 흐름

대시보드 → 도움말/기관 디렉터리 → 카테고리 → 검색 또는 필터 → 기관 상세 → 전화, 위치, 웹사이트 또는 기타 실제 액션

### 의료 리소스 흐름

대시보드 → 의료 리소스 → 병원 또는 의료기관 목록 → 상세 정보 → 지도, 전화 또는 기타 실제 액션

### 프로필 및 설정 흐름

대시보드 → 프로필 → 개인정보 수정 → 저장 → 성공 또는 오류 상태

대시보드 → 설정 → 실제 구현된 설정 항목 → 변경 결과

### 오류 및 예외 흐름

다음 상태를 실제 구현에 맞게 설계하세요.

- 네트워크 오류
- 서버 오류
- 빈 데이터
- 검색 결과 없음
- 위치 권한 거부
- 알림 권한 거부
- 유효하지 않은 입력
- 필수 입력 누락
- 로딩 중
- 요청 처리 중
- 요청 성공
- 요청 실패
- 권한이 없는 화면 접근
- 세션 만료

각 사용자 흐름은 다음 형식으로 작성하세요.

```text
[시작 화면]
  ↓
[사용자 행동]
  ↓
[다음 화면]
  ↓
[시스템 응답]
  ↓
[성공/실패/취소 분기]

6. 전체 화면 인벤토리

실제로 필요한 모든 화면을 빠짐없이 정의하세요.

각 화면마다 다음 정보를 제공하세요.

• 화면 ID
• 화면 이름
• 화면 목적
• 접근 가능한 사용자 역할
• 진입 경로
• 다음 화면
• 주요 UI 요소
• 표시되는 데이터
• 사용자 액션
• 성공 상태
• 오류 상태
• 빈 상태
• 로딩 상태
• 뒤로가기 동작
• 확인/취소 동작
• 실제 코드와 연결된 파일
• 구현 여부

화면 ID 예시:

• AUTH-01
• AUTH-02
• HOME-01
• EMERGENCY-01
• DIRECTORY-01
• MEDICAL-01
• PROFILE-01
• SETTINGS-01

예시 이름에 제한되지 말고 실제 앱에 맞게 사용하세요.

7. 화면별 UI 설계

각 화면을 다음 수준으로 구체적으로 설계하세요.

• 화면 크기 기준
• 상단 앱바
• 뒤로가기 버튼
• 제목과 설명
• 콘텐츠 영역
• 카드
• 리스트
• 버튼
• 입력 필드
• 드롭다운
• 탭
• 필터
• 검색창
• 지도
• 아이콘
• 배지
• 상태 표시
• 하단 네비게이션
• 플로팅 액션 버튼
• 바텀시트
• 다이얼로그
• 토스트 또는 스낵바
• 로딩 인디케이터
• 빈 상태 안내
• 오류 안내
• 접근성 레이블

모든 요소에 대해 다음을 설명하세요.

• 표시 텍스트
• 기능
• 클릭 시 동작
• 이동하는 화면
• 비활성화 조건
• 유효성 검사
• 성공 및 실패 피드백

버튼이나 아이콘이 화면 이동, 전화 연결, 위치 열기, 긴급 요청 전송, 데이터 저장 등의 기능을 수행한다면 정확히 정의하세요.

8. 네비게이션 설계

전체 앱의 네비게이션 구조를 설계하세요.

다음 내용을 포함하세요.

• 인증 전 네비게이션
• 인증 후 네비게이션
• 하단 네비게이션 탭
• 사이드 메뉴가 실제로 필요한지 여부
• 모달 및 다이얼로그 구조
• 중첩 네비게이션
• 뒤로가기 규칙
• 딥링크 또는 알림을 통한 진입
• 세션 만료 시 이동
• 권한 부족 시 이동
• 완료 후 이전 화면으로 돌아가는 규칙

다음과 같은 구조로 표현하세요.

앱 시작
├── 인증되지 않음
│   ├── 로그인
│   ├── 회원가입
│   └── 비밀번호 재설정
└── 인증됨
    ├── 대시보드
    ├── 긴급 기능
    ├── 도움 디렉터리
    ├── 의료 리소스
    ├── 프로필
    └── 설정

실제 존재하지 않는 메뉴는 삭제하세요.

9. Material Design 기반 시각 디자인

전반적인 디자인은 전문적이고 현대적인 Material Design 원칙을 따르세요.

다음 디자인 시스템을 제안하세요.

색상

긴급 서비스와 시민 지원 애플리케이션에 적합한 전문적인 색상 팔레트를 설계하세요.

포함 항목:

• Primary
• Secondary
• Background
• Surface
• Error
• Success
• Warning
• Info
• 주요 텍스트
• 보조 텍스트
• 비활성 텍스트
• 테두리
• 긴급 액션 색상

색상은 명확한 대비를 가져야 하며, 빨간색은 긴급한 액션과 오류에 제한적으로 사용하세요.

타이포그래피

• 화면 제목
• 섹션 제목
• 본문
• 보조 설명
• 버튼 텍스트
• 입력 필드 라벨
• 오류 메시지
• 배지 텍스트

각각의 크기, 굵기, 줄 간격, 사용 목적을 정의하세요.

컴포넌트

다음 컴포넌트를 일관되게 설계하세요.

• 버튼
• 텍스트 필드
• 검색창
• 카드
• 리스트 아이템
• 탭
• 칩
• 배지
• 앱바
• 하단 네비게이션
• 다이얼로그
• 바텀시트
• 스낵바
• 로딩 상태
• 빈 상태
• 오류 상태
• 권한 요청
• 확인 메시지

Material 3 원칙을 사용하되, 앱의 목적에 맞는 전문적인 시각적 정체성을 부여하세요.

레이아웃

• 모바일 우선 설계
• 일반적인 Android 모바일 화면 기준
• 적절한 좌우 여백
• 충분한 터치 영역
• 명확한 시각적 계층
• 긴급 상황에서 빠르게 인식할 수 있는 정보 구조
• 긴 텍스트와 다국어에 대한 대응
• 작은 화면에서의 오버플로 방지

10. 프로토타입 상호작용

완성된 프로토타입에는 다음 상호작용을 포함하세요.

• 탭
• 뒤로가기
• 화면 전환
• 입력
• 입력 유효성 검사
• 검색
• 필터
• 정렬
• 스크롤
• 토글
• 체크박스
• 라디오 버튼
• 드롭다운
• 위치 권한 요청
• 전화 연결
• 외부 지도 열기
• 확인 다이얼로그
• 취소
• 저장
• 삭제 확인
• 성공 피드백
• 실패 피드백
• 로딩
• 빈 상태
• 네트워크 오류
• 세션 만료
• 하단 네비게이션 전환

각 액션에 대해 다음을 명시하세요.

사용자 액션:
현재 화면:
시스템 반응:
전환 애니메이션:
다음 화면 또는 상태:
성공 상태:
실패 상태:

11. 최종 Canvas/Figma 제작 명세

디자인 도구에서 바로 재현할 수 있도록 다음 내용을 제공하세요.

• 화면별 프레임 목록
• 프레임 이름
• 프레임 순서
• 화면 크기
• 각 화면의 레이아웃 구조
• 재사용 컴포넌트 목록
• 컴포넌트 변형
• 색상 토큰
• 텍스트 스타일 토큰
• 간격 토큰
• 아이콘 목록
• 상태별 화면
• 연결할 프로토타입 링크
• 사용자 흐름별 시작점과 종료점

각 화면은 다음 형식으로 작성하세요.

[프레임 ID] 화면 이름

목적:
진입 경로:
사용자 역할:

레이아웃:
1. 상단 영역
2. 주요 콘텐츠
3. 보조 콘텐츠
4. 하단 액션 또는 네비게이션

UI 요소:
- 요소 이름:
- 표시 텍스트:
- 동작:
- 상태:
- 연결 화면:

상태 화면:
- 기본 상태
- 로딩 상태
- 빈 상태
- 오류 상태
- 성공 상태

프로토타입 연결:
- 버튼/요소 → 대상 화면

12. 누락 기능 검증

최종 설계 전에 다음을 점검하세요.

• 저장소의 모든 실제 화면이 포함되었는가?
• 인증 흐름이 완성되었는가?
• 사용자 역할별 권한이 반영되었는가?
• 긴급 기능의 모든 단계가 포함되었는가?
• 성공, 실패, 취소, 로딩, 빈 상태가 정의되었는가?
• 실제 API 응답에 필요한 화면 상태가 반영되었는가?
• 프로필과 설정 기능이 빠지지 않았는가?
• 뒤로가기 동작이 논리적인가?
• 모든 버튼의 목적이 정의되었는가?
• 실제 구현되지 않은 기능을 임의로 추가하지 않았는가?
• 모바일 화면에서 텍스트가 잘리거나 요소가 겹치지 않는가?
• 접근성 및 터치 영역이 적절한가?
• 개인정보와 민감한 정보가 안전하게 표시되는가?

최종 답변 형식

최종 결과는 다음 순서로 작성하세요.

1. 프로젝트 분석 요약
2. 기술 스택 및 앱 구조
3. 실제 구현 기능 목록
4. 사용자 역할
5. 기존 Canvas와 실제 구현의 차이
6. 최종 정보 구조
7. 전체 사용자 흐름
8. 전체 화면 목록
9. 화면별 상세 설계
10. 네비게이션 구조
11. Material Design 시스템
12. 상호작용 및 화면 전환 명세
13. 오류·빈 상태·로딩 상태
14. Figma/Canvas 제작 순서
15. 확인되지 않은 사항
16. 구현과 문서 간 불일치 사항
17. 최종 검증 체크리스트

중요:

• 확인하지 못한 내용은 사실처럼 작성하지 마세요.
• 실제 소스 코드에 없는 화면이나 기능은 “제안”으로도 추가하지 마세요. 필요한 경우 별도의 “추가 검토 사항”으로만 표시하세요.
• 모든 화면은 실제 앱 기능과 연결되어야 합니다.
• 기존 수작업 프로토타입의 구조를 그대로 답습하지 마세요.
• 결과물은 디자이너가 Figma, Canva 또는 유사한 도구에서 바로 제작할 수 있을 정도로 구체적이어야 합니다.
• 최종 목표는 실제 구현된 CITIZEN-107 애플리케이션과 정확히 일치하는 전문적이고 완전한 모바일 프로토타입입니다.