# 끼리 — 본서비스 디자인 스타일 가이드 제안

쏠 · 억지타협업소 · 2026-09-06 · 제안 v0.1

**추천: ‘안심하고 솔직해지는 조율 공간’.** 따뜻한 흰색 바탕, 깊은 보라색 행동 버튼, 담백한 한국어를 기본으로 삼는다. 참가자는 내 조건이 어떻게 쓰이는지 이해하고, 방장은 다음에 할 일이 무엇인지 바로 알 수 있어야 한다.

이 문서는 본서비스를 위한 제안이다. 기존 사이트에 적용하거나 제품 정책을 확정하지 않았다. 함께 만든 `STYLE_BOARD.html`에서 색상, 컴포넌트, 모바일 화면 예시를 확인할 수 있다. 화면의 인원·가격·후보는 모두 가상 예시다.

## 1. 브랜드가 전달할 것

| 항목 | 제안 |
|---|---|
| 서비스명 | 끼리 / KKIRI. 서비스 화면의 주인공은 ‘끼리’로 통일 |
| 팀명 | 억지타협업소. 소개·푸터·발표 자료에 보조 표기 |
| 브랜드 문장 | **속마음은 지키고, 결정은 함께.** 기존 공개 사이트의 문장 유지 |
| 성격 | 다정함, 명료함, 차분함. 의견이 다른 사람을 탓하지 않는 조율자 |
| 핵심 시각 모티프 | 떨어진 둥근 조각이 각자의 형태를 유지하면서 한 테이블 주위에 모이는 모습 |
| 상징의 의미 | ‘모두 똑같아짐’보다 ‘서로 다른 조건을 지키며 함께 결정함’ |
| 말투 | ‘추천안을 찾았어요’, ‘이 조건은 꼭 지킬까요?’, ‘아직 답하지 않은 분이 있어요’ |

팀명의 재치는 소개와 첫 진입에서 살린다. 예산, 식단, 재조율, 실패 화면에는 사람을 놀리거나 양보를 독촉하는 표현을 쓰지 않는다. ‘누가 발목을 잡았을까요?’, ‘이 정도는 양보해요’ 같은 문구는 배제한다.

## 2. 세 가지 시각 방향과 추천

| 방향 | 시각 언어 | 어울리는 경험 | 판단 |
|---|---|---|---|
| **A. 안심 조율 — 추천** | 따뜻한 흰색, 깊은 보라, 넉넉한 여백, 둥근 선택 카드 | 친구 모임과 직장 모임을 함께 다루는 서비스 | 기존 끼리의 보라색을 이어 가면서 사적인 조건 입력의 부담을 낮추는 방향 |
| B. 또렷한 결정 | 흰색·잉크색·청록, 촘촘한 목록, 정돈된 문서형 결과 | 조직의 반복적인 워크숍·회식 운영 | 방장 관리 화면에 일부 적용. 참가자 입력까지 관리 도구처럼 보이지 않도록 제한 |
| C. 가벼운 약속 | 크림·살구·보라, 큰 일러스트, 경쾌한 카드 | 친구 여행·선물 같은 가벼운 결정 | 초대 카드와 주제 선택에 한정. 민감한 입력과 합의 불가 화면에는 적용하지 않음 |

세 벌의 UI를 만들지 않는다. A를 공통 시스템으로 정하고, 방장 화면에는 B의 정리 방식, 초대와 주제 카드에는 C의 친근함을 가져온다. 이 판단은 디자인 가설이며 사용자 선호를 조사한 결과는 아니다.

## 3. 색상 — 예쁨보다 상태의 의미를 고정한다

| 토큰 | 값 | 사용 |
|---|---|---|
| `canvas` | `#FAF9F6` | 서비스 바탕 |
| `surface` | `#FFFFFF` | 입력·후보·결정 카드 |
| `text.primary` | `#262335` | 제목·본문·금액 |
| `text.secondary` | `#625E70` | 도움말·보조 정보 |
| `action.primary` | `#5842D8` | 주요 CTA·선택됨·현재 단계. 기존 공개 사이트의 주색 유지 |
| `action.soft` | `#F0EDFF` | 선택 카드·재확인 중 배경 |
| `border.subtle` | `#DCD7E5` | 장식적 구획선. 입력 요소의 유일한 식별선으로 쓰지 않음 |
| `border.control` | `#8C859B` | 입력창·미선택 컨트롤 경계 |
| `success.text / bg` | `#196C52 / #EAF7EF` | 전원 동의가 확인된 완료 |
| `warning.text / bg` | `#8A4B08 / #FFF3DF` | 만료 임박·다시 확인할 내용 |
| `danger.text / bg` | `#B43E46 / #FFF0F0` | 입력 오류·실행 실패 |

**추천 결과가 나온 것만으로 초록색 완료 배지를 붙이지 않는다.** ‘재확인 중’은 보라, ‘전원 동의 완료’는 초록, ‘방장 확정·전원 동의 미확인’은 중립색과 명시적 문구로 구별한다. 한 사람이 거절했다는 이유로 사람이나 프로필을 빨갛게 표시하지 않는다.

로컬 sRGB 계산 결과: 버튼 흰 글씨/보라 **6.59:1**, 보조 글씨/흰색 **6.26:1**, 완료 글씨/연초록 **5.76:1**. 모든 지정 본문 조합은 4.5:1 이상이다. 상세 값은 `CONTRAST.json`. WCAG는 일반 텍스트 4.5:1, 큰 텍스트 3:1을 기준으로 설명한다. 이 색상 계산은 제품 전체 접근성 인증이 아니다. [W3C 대비 기준](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html)

## 4. 글꼴·간격·형태

| 항목 | 기본 제안 |
|---|---|
| 글꼴 | Pretendard. 대체 순서: 시스템 글꼴 → Apple SD Gothic Neo → sans-serif. 자체 호스팅 권장 |
| 제목 | 화면 제목 28px/1.35, 섹션 제목 22px/1.4, 카드 제목 18px/1.45 |
| 본문 | 16px/1.6, 보조 정보 14px/1.5. 중요한 안내를 작은 각주로 밀지 않음 |
| 굵기 | 본문 400, 레이블 600, 제목 700. 긴 문장 전체를 굵게 하지 않음 |
| 간격 | 4·8·12·16·24·32·48px. 카드 안 20~24px, 관련 항목 사이 8~12px |
| 모서리 | 입력·버튼 12px, 카드 16px, 브랜드 일러스트 영역 24px |
| 아이콘 | 같은 굵기의 24px 선 아이콘. 문구를 함께 붙여 의미 전달 |
| 그림자 | 떠 있는 메뉴·모달처럼 실제 층이 있는 경우에 제한 |
| 모션 | 선택 전환 160~240ms 제안. 운영 속도 측정치가 아닌 인터랙션 토큰 |

한국어 문장은 단어 단위 줄바꿈을 우선하되 긴 URL·연속 문자열은 넘치지 않게 처리한다. 금액·인원·마감에는 단위를 붙인다. 보관 기간과 예상 소요 시간은 정책 또는 실측이 확보됐을 때만 실제 값으로 표시한다.

Pretendard는 공식 프로젝트를 기준으로 배포 파일과 라이선스를 확인해 적용한다. 시각 보드는 외부 폰트를 요청하지 않으며 기기에 Pretendard가 없으면 시스템 글꼴로 표시된다. [Pretendard 공식 저장소](https://github.com/orioncactus/pretendard)

## 5. 화면 구성 원칙

**참가자 화면은 한 번에 한 가지 판단.** 첫 화면에서 방의 목적·마감·답변 공개 범위를 읽고, 질문 → 내 조건 확인 → 제출 → 추천안 확인 → 내 최종 의사 표시로 진행한다. 현재 필요한 행동을 상단에 두고, 설명은 해당 입력 가까이에 둔다.

**방장 화면은 진행 관리.** 방 만들기 → AI 질문 초안 검토 → 설정 확정 → 초대 → 응답 진행 → 추천안 → 재확인 상태 → 결정 기록. 참가자별 답변 내용, 예산 상한, 개인 리포트는 관리 화면에 들어가지 않는다.

**모바일 우선.** 질문은 최대 640px 안의 단일 열, 방장 관리·후보 비교는 데스크톱에서 최대 1120px를 활용한다. 모바일 320px에서도 가로 스크롤 없이 주요 과업을 수행하게 한다. 하단 CTA는 키보드와 포커스된 입력을 가리지 않아야 하며, 작은 화면에서는 본문 흐름 안 배치로 전환한다.

**주요 조작 영역은 48×48px 이상을 내부 기준으로 제안한다.** WCAG 2.2 AA의 최소 타깃 규정은 24×24 CSS px 또는 간격 등 예외 조건을 포함한다. 48px은 끼리의 더 넉넉한 설계 선택이다. [W3C 타깃 크기](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)

키보드 포커스 표시, 레이블, 오류 원인과 복구 행동, 200% 확대, 모션 감소 설정을 함께 검수한다. 고정 헤더·하단 버튼이 포커스 대상을 가리지 않는지 확인한다. [W3C 포커스 가림 기준](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html)

## 6. 먼저 만들 컴포넌트

| 컴포넌트 | 변형·상태 | 필수 규칙 |
|---|---|---|
| 주요 버튼 | 기본 / 누름 / 키보드 포커스 / 처리 중 / 사용 불가 | 한 단계의 주요 CTA 하나. ‘다음’보다 ‘내 조건 확인하기’처럼 결과를 설명 |
| 선택 카드 | 미선택 / 선택 / 포커스 / 오류 | 색 외에 선택 표시와 문구를 함께 사용. 카드 전체가 터치 영역 |
| 조건 입력 | ‘가능하면’ 선호 / ‘꼭 지킬’ 조건 | 작은 토글 하나에 의미를 숨기지 않음. 절대 조건을 켜면 후보 제외 효과 설명 |
| 비공개 안내 | 입력 근처 / 내 조건 요약 / 내 리포트 | ‘다른 참가자·방장에게 공개되지 않아요’와 시스템 처리 범위를 구분해 안내 |
| AI 초안 카드 | 검토 전 / 수정됨 / 확인됨 / 생성 실패 | 생성된 질문을 확정본처럼 표시하지 않음. 문구 수정·추가·삭제 지원 |
| 진행 상태 | 질문 준비 / 응답 수집 / 비교 / 재확인 / 완료 | 수집 시 응답 여부와 내용을 분리. 허구의 대리인 대화·가짜 퍼센트 금지 |
| 추천 카드 | 재확인 전 / 조건부 / 확정 | 장소·일정·비용 기준·후보 출처·갱신 시점·현재 상태를 구분 |
| 개인 조건 리포트 | 지켜짐 / 선호와 다름 / 확인 필요 | 본인에게만 노출. 내 조건을 다른 사람 값과 비교하는 순위표 금지 |
| 재확인 선택 | 동의 / 조건부 동의 / 재조율 요청 | 세 선택의 시각적 위계를 비슷하게 유지. 거절을 찾기 어렵게 만들지 않음 |
| 안내·빈 상태 | 미응답 / 후보 없음 / 만료 / 연결 실패 | 무엇이 일어났는지와 다음 행동을 같이 표시. 불일치를 사용자 잘못으로 표현하지 않음 |

금액 입력 예시: ‘희망 예산 15만 원’과 ‘넘기면 참여하기 어려운 금액 20만 원’을 분리한다. 두 값이 모순되면 어떤 값을 바꿀지 본인에게 확인한다. AI가 임의로 상한을 낮추거나 절대 조건으로 승격하지 않는다.

## 7. 핵심 화면 시나리오

| 화면 | 가장 먼저 보여 줄 것 | 주요 행동 | 피할 것 |
|---|---|---|---|
| 초대 | 무엇을 정하는 방인지, 마감, 답변 공개 범위 | 내 의견 입력하기 | 가입 안내가 과업을 덮는 화면 |
| 비공개 질문 | 질문 한 개, 왜 필요한지, 선호·절대 조건의 차이 | 내 조건 확인하기 | 모든 민감 정보를 한 긴 폼에 몰아넣기 |
| 제출 전 요약 | 내 원문을 시스템이 어떻게 조건으로 이해했는지 | 이 조건으로 제출 | 확인 없이 AI 해석을 확정 |
| 방장 진행 | 제출 현황, 마감, 다음 가능한 행동 | 초대 공유 / 마감 조정 | 누구의 어떤 조건이 까다로운지 드러내기 |
| 조율 중 | 실제 수행 단계와 마지막으로 완료한 일 | 필요 시 돌아가기·재시도 | 에이전트가 대신 양보했다는 가상 채팅 |
| 추천 결과 | ‘재확인 중’, 추천안 한 개, 비용·일정, 공통 설명 | 내 의견 남기기 | 만족도 92.7%를 전원 동의처럼 전시 |
| 개인 리포트 | 내 절대 조건의 반영과 선호 차이 | 내 조건 수정 / 결과로 돌아가기 | 다른 참가자의 금액·취향 추정 단서 |
| 재확인 | 동의·조건부·재조율의 의미, 공개될 내용 | 내 최종 의사 제출 | 무응답을 동의로 표시 |
| 후보 없음 | 현재 조건을 함께 만족하는 후보가 없다는 사실 | 내 조건 확인 / 후보 범위 다시 찾기 | 누가 어떤 조건으로 막았는지 공개하거나 상한 완화 강요 |
| 결정 기록 | 선택안·확정 방식·미확인 여부·실행 담당 | 일정 보기·공유 등 연결된 기능 | 예약·결제가 끝난 것 같은 완료 표현 |

후보 점수는 실제 감정이나 검증된 만족도처럼 이름 붙이지 않는다. 필요할 때 ‘입력 조건 기준 비교값’과 계산 방법을 상세 영역에 둔다. 예약·영업 여부·실제 가격을 확인하지 못한 후보에는 그 상태를 표시한다.

## 8. AI 질문·추가 설정 UX

1. **상황 입력** — ‘다음 달 팀 회식, 술을 안 마시는 사람도 편했으면 좋겠어요’처럼 자연어로 입력.
2. **질문 초안 검토** — 주제별 기본 질문과 추가 제안을 분리. 추가 질문마다 ‘왜 필요한가’를 한 줄로 설명. 기본 문항 수는 5~7개를 검토 출발점으로 제안하되 실제 이탈·누락을 보고 조정.
3. **모호함 해소** — ‘늦지 않게’처럼 시간 기준이 없는 표현은 질문으로 바꾼다. 확정한 시간으로 가장하지 않는다.
4. **설정 추천** — 인원·마감·확정 방식을 제안값으로 표시. 방장이 확인한 다음 초대를 시작한다.
5. **질문 버전 고정** — 수집 시작 후 질문 변경은 영향 범위와 재응답 대상을 먼저 안내. 기존 답변을 새 의미에 조용히 재사용하지 않는다.
6. **개인 추가 질문** — 부족하거나 모순된 조건을 본인에게만 확인. 다른 사람의 원문을 질문에 섞지 않는다.
7. **실패 복구** — ‘질문 초안을 만들지 못했어요. 기본 질문으로 시작할 수 있어요.’ 입력을 보존하고 재시도·기본 템플릿을 제공.

현재 배포본은 규칙 기반 시제품이며 실제 LLM은 미연결이다. 위 흐름은 본서비스 설계 제안이다. 실제 자동 저장, 재시도, 계정·비공개 저장 등도 구현 후에만 완료형 문구를 사용한다.

## 9. 다섯 가지 상황을 같은 제품으로 보이게

| 상황 | 작은 시각 단서 | 전용 질문·정보 |
|---|---|---|
| 워크숍 | 둥근 조각 아이콘·연보라 | 목적, 일정, 활동 강도, 숙박·이동 |
| 여행지 | 지도 핀·연파랑 | 여행 기간, 예산, 이동 방식, 숙박 |
| 회식 메뉴·장소 | 접시·살구 | 식단 제한, 선호 메뉴, 술자리 여부, 종료 시간 |
| 모임 시간·장소 | 시계·옅은 민트 | 가능 시간, 온라인·오프라인, 이동 부담 |
| 단체 선물 | 리본·연분홍 | 분담 상한, 받는 사람 취향, 전달 방식·기한 |

주제색은 아이콘 타일에만 쓰고 선택·오류·완료의 의미를 바꾸지 않는다. 회식에서 ‘못 먹는 음식’은 결과에 필요한 제한만 받고 진단명·사유까지 요구하지 않는 방향을 권한다. 사진은 실제 후보의 이해에 도움이 될 때만 사용하고 출처·사용 권한을 확보한다.

## 10. 본서비스에서 먼저 정리할 정책 차이

기존 문서의 워크숍 범위와 현재 확장본의 5개 시나리오는 버전이 다르다. 스타일 작업은 현재 5개 상황을 기준으로 하되, 아래 정책은 이 문서에서 확정하지 않는다.

| 쟁점 | 기존 근거 | 본서비스 제안·디자인 영향 |
|---|---|---|
| 전원 합의와 방장 확정 | 기존 정책 P-09는 무응답을 기권으로 처리. 새 스튜디오는 전원 재확인 게이트 제공 | **전원 명시 동의를 기본값으로 추천.** 방장 확정을 허용하면 별도 이름과 상태로 표시. 무응답은 동의로 합산하지 않음 |
| 소규모 방의 추정 위험 | 기존 P-12는 2명 이상 공통 조건을 구체화 | ‘2명 이상’만으로 익명성이 보장된다고 말하지 않음. 본서비스에서는 인원·맥락으로 개인을 추정할 수 있는 주제·집계를 억제하고 공개 문구를 별도 검토 |
| 조건부 동의 공개 | 기존 조건부 의견은 공개 조건을 작성 | 제출 전에 공개될 실행 조건을 미리 보여 주고 본인 확인. 개인 사유는 자동 공개하지 않음 |
| 권한·보관 | 기존 개인 토큰·원문 보관에는 미구현·미결 항목 존재 | ‘나만 볼 수 있음’은 다른 참가자에 대한 권한 경계와 시스템 처리 설명을 함께 설계. 인증·권한 검증 전 제품 보장 문구로 사용하지 않음 |

## 11. UI/UX 설계에 넘길 순서

1. 역할·정보 공개 범위·합의 상태의 의미부터 확정한다.
2. 회식 한 흐름으로 초대 → 비공개 질문 → AI 해석 확인 → 추천 → 재확인 → 완료를 연결한다. 거절과 민감 조건을 함께 검토하기 좋은 시작점이라는 설계 판단이다.
3. 같은 컴포넌트에 여행·워크숍·모임·선물 데이터를 적용한다.
4. 후보 없음·미응답·생성 실패·만료·질문 변경을 별도 상태로 설계한다.
5. 방장 관리 화면과 개인 리포트를 역할별로 검수한다.
6. Figma 라이브러리에 색·타입·간격의 변수와 컴포넌트 상태를 정의하고 개발에 넘긴다. 이 제안 단계에서 Figma 파일을 생성하지는 않았다.

사용성 확인 과제: 참가자가 선호와 절대 조건을 구분하는가, 누가 내 답변을 볼 수 있는지 설명할 수 있는가, 재확인 중과 합의 완료를 구별하는가, AI 오해를 스스로 고칠 수 있는가. 목표 시간·성공률은 첫 관찰 뒤 정한다.

## 근거

- 현재 5개 시나리오·질문 스튜디오: `../KKIRI_EXPANSION_2026_09_06/README.md`, [공개 스튜디오](https://kkiri-plan.pages.dev/studio/). README의 미배포 표기는 작성 시점 기록이며 이후 배포는 `../../WORK_LOGS/KKIRI_EXPANSION_DEPLOYMENT_2026_09_06.md`에 기록됨.
- 기존 제품 규칙·미결 정책: `../KKIRI/KKIRI_REQUIREMENTS_AND_POLICY.md`, 특히 P-09·P-12·P-17 및 FR-15~19.
- 현재 시각 토큰: `../KKIRI_EXPANSION_2026_09_06/site/assets/reading.css`.
- 이전 벤치마킹: `../../RESEARCH/KKIRI_DESIGN_BENCHMARK_SOURCES_2026_09_05.md`. 참고 패턴의 기존 조사이며 이번에 외부 제품 화면을 다시 검증한 것은 아님.
- 접근성·폰트의 이번 확인 출처: `../../RESEARCH/KKIRI_STYLE_GUIDE_SOURCES_2026_09_06.md`.

색·수치·문구 중 ‘제안’은 디자인 기준값이며 성과 측정치가 아니다. 이 가이드는 확정된 디자인 시스템이나 구현 완료 보고가 아니다.