목적
각 디자인 사례를 8가지 카테고리(제품 카테고리, 사용자, 사용 맥락, 문제, 경험 가치, 형태 전략, CMF, 기술/생산 선택)로 정리합니다.
설계 이유(디자이너·브랜드·평가자가 바라본 문제-의도-해결 방식-사용자 경험)와 함께 기록합니다.
각 판단에 근거와 신뢰도를 연결해 디자인 리서치·디자인 매핑, 요약/보고서 에이전트가 필요한 맥락을 검색하고 재사용할 수 있게 만듭니다.
결과물 분리 원칙
| 버전 | 쓰임 | 기록 기준 |
|---|---|---|
| 원문 기반 버전 | 첨부 문서를 학습용·참고용으로 활용할 때 씁니다. | 원문에 포함된 내용만 추출합니다. 할루시네이션 우려를 줄이기 위해 AI 해석은 넣지 않습니다. |
| 추론 포함 버전 | Flowboard 안에서 실제 자료를 첨부하고 사용자에게 결과를 보여줄 때 씁니다. | AI의 해석과 추론을 추가하되, 원문 기반 판단과 분리해서 라벨과 등급을 붙입니다. |
작업 결과물 확인 후, 논의 내용
지금까지 나온 결과물을 검토하면서 정한 보완 방향입니다. 핵심은 문체 품질을 올리되 구조와 근거 연결은 흔들지 않고, 원문 기반 결과와 AI 추론이 포함된 결과를 분리해서 비교하는 것입니다.
| 주제 | 현재 확인한 문제 | 진행 방식 |
|---|---|---|
| 문체 개선 | 일부 결과에서 문장이 문단 단위로 끊기고, 번역체처럼 느껴지는 표현이 보입니다. PM이나 디자이너가 바로 읽기에는 자연스럽지 않은 부분이 있습니다. | 현재 설정값을 먼저 확인합니다. 같은 문제가 실제 테스트 결과에서 반복되면, 읽는 문장만 골라 재작성·비평·반복 방식으로 개선합니다. enum, 라벨, Gold/Silver/Bronze, 근거 연결은 바꾸지 않습니다. |
| 추론 포함 여부 분리 | 현재 참고 문서에 대해 원문에 포함된 내용만 추출한 결과물을 먼저 보여주고 있습니다. 이는 할루시네이션 우려를 줄이기 위한 선택입니다. | 첨부 문서를 학습용·참고용으로 쓸 때는 원문 기반 버전을 유지합니다. Flowboard 안에서 사용자에게 결과를 보여줄 때는 AI 해석과 추론이 필요할 수 있으므로, 원문 기반 버전과 추론 포함 버전을 분리해 비교합니다. |
| 테스트 범위 | 한두 개 사례만으로는 구조가 충분한지 판단하기 어렵습니다. 문체 문제와 추론 분리 기준도 여러 사례에서 반복 확인해야 합니다. | 원문 기반 버전 10개, 추론 포함 버전 10개를 따로 뽑아 총 20개 샘플로 비교합니다. 이후 최소 1000개 이상 데이터를 색인해 검색 품질과 구조 안정성을 확인합니다. |
| 가상 디자인 콘셉트 | “미래의 자동차를 디터 람스가 디자인한다면?” 같은 질문은 기존 사례 검색과 성격이 다릅니다. 사실 검색이 아니라 레퍼런스 기반 콘셉트 생성에 가깝습니다. | 관련 레퍼런스 검색 → 디자이너 철학과 조형 특징 추출 → 새 주제에 매핑 → 콘셉트 문장 또는 이미지 프롬프트 생성 흐름으로 별도 검증합니다. |
저장 흐름
원본 자료(웹 문서·이미지·OCR) │ ├─ 출처 고정 │ └─ source_documents / raw_refs / source_context │ ├─ 원문 문맥 분리 │ └─ source_passages │ ├─ 근거 단위 생성 │ └─ basis: 원문 문장 / 이미지 관찰 / 자료 기반 추론 / 정보 없음 │ ├─ 판단 기록 │ └─ knowledge(8가지 카테고리) + design_logic(문제-의도-해결 방식-사용자 경험) │ └─ 재사용 준비 └─ summary / rag_hints / display
핵심은 원본에서 바로 요약으로 넘어가지 않고, 원본 → 근거 → 판단 → 재사용 순서로 나누어 저장하는 것입니다.
활용 흐름
input(아이디어) │ ├─ 디자인 리서치 │ └─ 저장소 검색(에이전트용) → 유사 사례·근거로 리서치 문장 생성 │ ├─ 디자인 매핑 │ └─ 저장소 검색(형태·CMF·문제해결 패턴) → 새 방향에 매핑 │ └─ 이미지 프롬프트 └─ 매핑된 형태·소재·CMF 언어를 그대로 프롬프트로 변환
문체 재귀개선기
v1 카드 → ① 추출 → ② 재작성 → ③ 비평·반복 → ④ 제자리 교체 → 개선 카드
| ① 추출 | 읽는 문장만 골라냅니다. 요약, 설계논리, 문장형 값만 대상으로 삼습니다. enum, 라벨, Gold/Silver/Bronze, 근거는 손대지 않습니다. |
|---|---|
| ② 재작성 | 로컬 Claude 또는 Codex에 문체 기준, 번역체 금지 예시, taxonomy 권장 표기를 주입해 자연 문장으로 바꿉니다. |
| ③ 비평·반복 | 독립 비평가가 남은 번역체와 문장 끊김을 찾습니다. 더 고칠 부분이 없을 때까지 반복합니다. |
| ④ 제자리 교체 | 개선 문장만 원래 위치에 끼웁니다. 구조는 유지하고 읽는 값만 자연스럽게 바뀝니다. |
RAG 흐름
| [build] | 카드 → 필드 청크(요약·8가지 카테고리·설계논리, CMF 중첩) + 카드 메타(이미지·태그) → 임베딩 → index.json |
|---|---|
| [search] | 질의 → 임베딩 → 청크와 코사인 유사도 계산 → 라벨(원문/추론)·신뢰도 필터 → 상위 N개 반환 |
| 두 모드 | 에이전트용은 판단 단위, 근거, 신뢰도를 반환합니다. 사람용은 카드, 이미지, 태그, 매칭 이유를 반환합니다. |
저장소 사례 구조
| 기본 정보 | 제품명, 브랜드/디자이너, 출처 |
|---|---|
| 표시 자산 | 대표 이미지, 썸네일, 캡션. 사람용 화면에서 쓰며 판단 근거와는 분리합니다. |
| 8가지 카테고리 | 제품 카테고리, 사용자, 사용 맥락, 문제, 경험 가치, 형태 전략, CMF, 기술/생산 선택 |
| 설계 이유 | 문제, 의도, 해결 방식, 사용자 경험 |
| 근거 | 원문 문맥, 이미지 관찰, 출처 위치, raw asset |
| 검색 정보 | 검색 청크, 근거 라벨, Gold/Silver/Bronze, 근거 연결 |
저장소 사례 구조
실제 카드에 저장되는 필드명은 영어 snake_case를 사용합니다. 괄호 안의 한국어는 PM·디자이너가 구조를 읽기 위한 표시입니다.
| 순서 | 해당 묶음 | 판단 기준 |
|---|---|---|
| 1. 식별 | schema, identity | 먼저 이 카드가 어떤 사례인지 고정합니다. |
| 2. 원본과 출처 | source_documents, raw_refs, source_context, source_passages, assets | 판단보다 원본과 맥락을 먼저 둡니다. 그래야 뒤의 값이 어디서 왔는지 검증할 수 있습니다. |
| 3. 근거 | basis | 원문과 이미지에서 판단으로 넘어가기 전에 근거 단위를 정리합니다. |
| 4. 판단 | knowledge, design_logic | 8가지 카테고리와 설계 이유는 저장소의 핵심 판단입니다. |
| 5. 재사용 | summary, rag_hints, display | 요약, 검색 힌트, 표시 자산은 앞의 판단을 사람이 읽고 에이전트가 재사용하기 위한 파생 정보입니다. |
전체 묶음
| 묶음 | 하위 속성 | 의도 |
|---|---|---|
schema / card_version / case_key(스키마 / 카드 버전 / 사례 키) | schema(카드 형식), card_version(카드 버전), case_key(사례 고유 키) | 카드가 어떤 형식으로 저장됐는지, 어떤 버전의 규칙을 따르는지, 어떤 사례를 가리키는지 흔들리지 않게 고정하는 것입니다. |
identity(기본 정보) | product_name(제품명), brand(브랜드), designers(디자이너), studio(스튜디오), source_url(출처 URL), source_type(출처 유형), collected_at(수집일) | 이 사례가 무엇이고 누가 만들었으며 어디서 온 자료인지 먼저 식별하는 것입니다. |
source_documents(출처 문서) | url(문서 URL), source_type(출처 유형), speaker_role(발화 주체), raw_text_ref(원문 텍스트 참조), raw_html_ref(원문 HTML 참조), fetched_at(수집 시각), reliability(출처 신뢰도) | 원문으로 되돌아갈 수 있는 경로를 남기는 것입니다. |
raw_refs(원본 참조) | raw_text_refs(원문 텍스트 참조), raw_html_refs(원문 HTML 참조), ocr_refs(OCR 참조), scrape_result_ref(스크래핑 결과 참조) | 카드가 요약본으로 바뀐 뒤에도 원본 자료를 다시 확인할 수 있게 하는 것입니다. |
source_context(출처 맥락) | primary_voice(주 발화 주체), summary(원문 맥락 요약), raw_text_policy(원문 저장 정책) | 이 자료가 디자이너의 설명인지, 브랜드의 주장인지, 평가자의 해석인지 구분하는 것입니다. |
source_passages(원문 문맥) | passage_text(충분한 원문 문맥), passage_summary(문맥 요약), speaker_role(발화 주체), source_location(출처 위치), supports(연결되는 판단 필드) | 짧은 인용 조각이 아니라 판단이 기대는 문맥을 보존하는 것입니다. |
assets(자산) | image_dir_ref(이미지 폴더 참조), image_count(이미지 수), images(image_ref(이미지 참조), role(역할), local_ref(로컬 경로), source_url(원본 URL), relevance(관련도), observation_targets(관찰 대상)) | 이미지와 원본 자산을 판단 필드와 분리해 관리하는 것입니다. |
basis(근거) | basis_text(근거 문장), basis_type(근거 유형), source_location(출처 위치), supports(연결되는 판단 필드) | 모든 판단에 왜 그렇게 기록했는지 설명할 수 있는 근거를 붙이는 것입니다. |
knowledge(8가지 카테고리) | 8가지 카테고리의 세부 판단 필드입니다. 각 필드는 value/values(값), grounding_label(근거 라벨), grade(Gold/Silver/Bronze), basis_text(근거 문장)를 가집니다. | 디자인 사례를 비교 가능한 판단 단위로 쪼개는 것입니다. |
design_logic(설계 이유) | perspective_source(관점 출처), perceived_problem(문제), design_intent(의도), solution_approach(해결 방식), key_design_choices(주요 디자인 선택), user_experience(사용자 경험), reusable_principle(재사용 원칙) | 결과물의 형태만 저장하지 않고 왜 그런 설계가 나왔는지 연결하는 것입니다. |
summary(요약) | one_line(한 줄 요약), why_it_matters(기록 가치/의의) | 앞의 원문, 근거, 판단을 사람이 빠르게 이해할 수 있는 문장으로 압축하는 것입니다. |
rag_hints(RAG 힌트) | index_targets(색인 대상), do_not_index(색인 제외), primary_queries(대표 질의) | 저장된 카드를 검색 가능한 지식 단위로 바꾸는 기준을 남기는 것입니다. |
display(표시 자산) | hero_asset_ref(대표 이미지 참조), thumbnail_refs(썸네일 참조), preferred_caption(화면 표시 캡션) | 사람이 사례를 훑어볼 때 필요한 대표 이미지를 제공하되, 디자인 판단의 근거와는 분리하는 것입니다. |
필드 타입
| 타입 | 구성 | 의도 |
|---|---|---|
list_field(목록 필드) | values(값 목록) + grounding_label(근거 라벨) + grade(Gold/Silver/Bronze) + basis_text(근거 문장) | 여러 값이 자연스러운 항목을 한 필드에 모으는 것입니다. |
scalar_field(단일값 필드) | value(값) + grounding_label(근거 라벨) + grade(Gold/Silver/Bronze) + basis_text(근거 문장) | 하나의 대표값으로 판단해야 하는 항목을 안정적으로 저장하는 것입니다. |
statement_logic(문장형 설계 이유) | statement(서술) + actor(관점 주체) + grounding_label(근거 라벨) + grade(Gold/Silver/Bronze) + basis_text(근거 문장) | 문제, 의도, 해결 방식처럼 문장으로 설명해야 의미가 살아나는 판단을 저장하는 것입니다. |
basis_item(근거 단위) | basis_text(근거 문장) + basis_type(근거 유형) + source_location(출처 위치) + supports(연결되는 판단 필드) | 판단을 검증 가능한 단위로 만드는 것입니다. |
8가지 카테고리
| 카테고리 | 하위 속성 | 의도 |
|---|---|---|
| product_category(제품 카테고리) | domain(대분류), product_type(구체 제품유형), sub_categories(하위 카테고리), adjacent_domains(인접 도메인) | 이 사례가 어떤 제품군에 속하고 어떤 인접 영역으로 확장될 수 있는지 잡는 것입니다. |
| user(사용자) | user_group(사용자군), persona(페르소나), skill_level(숙련도), needs(욕구), avoidances(회피하고 싶은 것) | 누구의 어떤 욕구와 부담을 다루는 사례인지 기록하는 것입니다. |
| use_context(사용 맥락) | use_space(사용 공간), use_situation(사용 상황), use_moment(사용 순간), use_frequency(사용 빈도), surrounding_context(주변 환경) | 제품이 언제, 어디서, 어떤 순간에 의미가 생기는지 기록하는 것입니다. |
| problem(문제) | problem_definition(문제 정의), pain_points(불편 지점), tension(긴장 관계), opportunity_area(기회 영역), limits_of_existing_solution(기존 방식의 한계) | 디자인이 풀려고 한 문제를 하나의 문장과 세부 단서로 나누는 것입니다. |
| experience_value(경험 가치) | core_value(핵심 가치), emotional_tone(정서 톤), user_effect(사용자 효과), before_after(전후 변화), brand_experience(브랜드 경험) | 기능 설명을 넘어 사용자가 어떤 감정과 변화를 경험하는지 기록하는 것입니다. |
| form_strategy(형태 전략) | form_keywords(형상 키워드), composition(구성 방식), volume_language(볼륨 언어), detail_strategy(디테일 전략), visual_hierarchy(시각적 위계), product_typology(제품 유형 언어) | 제품의 형태가 문제 해결과 경험 가치에 어떻게 기여하는지 기록하는 것입니다. |
| cmf(CMF) | color(primary_color(주 색상), secondary_color(보조 색상), tone(톤), contrast(대비)), material(primary_material(주 소재), secondary_material(부 소재), structural_material(구조 소재), surface_material(표면 소재), transparent_material(투명 소재), flexible_material(유연 소재)), finish(surface_finish(표면 마감), gloss(광택), texture(질감), tactility(촉감), fabrication_feel(가공 느낌)) | 색, 소재, 마감이 어떤 인상과 사용감을 만드는지 구조화하는 것입니다. |
| technology_production_choice(기술/생산 선택) | core_technology(핵심 기술), internal_components(내부 구성요소), structure_type(구조 타입), production_method(생산 방식), manufacturing_hints(제조 힌트), constraints(제약 조건), interface(인터페이스), safety_durability_conditions(안전/내구 조건) | 형태와 경험을 가능하게 한 기술적 선택을 분리해 보는 것입니다. |
설계 이유
| 흐름 | 하위 속성 | 의도 |
|---|---|---|
| perspective_source(관점 출처) | designer(디자이너), brand(브랜드), jury(평가자), journalist(기자/필자), image_inference(이미지 추론) 중 어떤 관점에서 판단했는지 기록합니다. | 이 설계 이유가 누구의 시선에서 나온 말인지 분명히 하는 것입니다. |
| perceived_problem(디자이너/평가자가 본 문제) | statement(문제 서술), actor(관점 주체), grounding_label(근거 라벨), grade(등급), basis_text(근거 문장) | 디자인의 출발점을 기록하는 것입니다. |
| design_intent(디자인 의도) | statement(의도 서술), actor(관점 주체), grounding_label(근거 라벨), grade(등급), basis_text(근거 문장) | 디자이너가 무엇을 바꾸려 했는지 보존하는 것입니다. |
| solution_approach(해결 방식) | statement(해결 방식 서술), actor(관점 주체), grounding_label(근거 라벨), grade(등급), basis_text(근거 문장) | 문제와 결과물 사이의 방법을 기록하는 것입니다. |
| key_design_choices(주요 디자인 선택) | values(주요 선택 목록), actor(관점 주체), grounding_label(근거 라벨), grade(등급), basis_text(근거 문장) | 형태, 인터랙션, 소재, 구조 중 핵심 선택만 따로 잡는 것입니다. |
| user_experience(사용자 경험) | statement(사용자 경험 서술), actor(관점 주체), grounding_label(근거 라벨), grade(등급), basis_text(근거 문장) | 사용자가 결과적으로 무엇을 느끼고 어떻게 행동하는지 기록하는 것입니다. |
| reusable_principle(재사용 가능한 원칙) | statement(다른 프로젝트에 옮길 수 있는 원칙), grounding_label(근거 라벨), grade(등급), basis_text(근거 문장) | 사례를 그대로 복사하지 않고 원칙으로 추상화하는 것입니다. |
근거 라벨과 등급
| 라벨 | 뜻 | 사용 기준 |
|---|---|---|
| 원문 기재 | 원문 텍스트에 직접 적힌 사실입니다. | 학습용 원문 기반 버전과 사실 확인 답변에 우선 사용합니다. |
| 이미지 관찰 | 이미지에서 직접 보이는 형태, 색, 소재, 구조입니다. | 형태 전략, CMF, 구조 관찰처럼 시각 자료가 근거인 판단에 사용합니다. |
| 자료 기반 추론 | 원문, 이미지, 맥락을 바탕으로 구조화하거나 해석한 판단입니다. | 사용자에게 보여주는 추론 포함 버전, 디자인 리서치, 디자인 매핑에 사용합니다. |
| 정보 없음 | 원문, 이미지, OCR, 출처 어디에서도 값을 뒷받침할 근거가 없는 상태입니다. | 값을 만들지 않고 빈 상태로 남깁니다. RAG 검색 대상에서는 제외하거나 낮은 우선순위로 둡니다. |
Gold / Silver / Bronze / No data
| 등급 | 뜻 | 사용 기준 |
|---|---|---|
| Gold | 근거가 직접적이고 값이 안정적입니다. | 원문에 명시되어 있거나 이미지에서 명확히 보입니다. 사실 확인과 보고서 문장에 그대로 쓸 수 있습니다. |
| Silver | 근거는 있으나 분류, 요약, 해석이 일부 들어갑니다. | 리서치와 매핑에는 사용할 수 있지만, 사실처럼 단정하기 전에 라벨과 근거 문장을 함께 보여줘야 합니다. |
| Bronze | 단서가 약하거나 여러 해석 중 하나입니다. | 아이디어 탐색의 참고로만 씁니다. 보고서나 사용자-facing 문장에는 추가 검토가 필요합니다. |
| No data | 판단하지 않는 상태입니다. | 값이 비어 있거나 근거가 없습니다. 이 상태에서는 라벨도 정보 없음으로 맞추고 검색 결과에 확정값처럼 노출하지 않습니다. |
조합 규칙
| 상황 | 라벨 | 등급 | 처리 |
|---|---|---|---|
| 원문에 직접 적힌 값 | 원문 기재 | Gold 또는 Silver | 원문 기반 버전에 포함합니다. 근거 문장을 함께 저장합니다. |
| 이미지에서 직접 보이는 값 | 이미지 관찰 | Gold 또는 Silver | 이미지 관찰 결과로 분리합니다. 형태, CMF, 구조 판단에 사용합니다. |
| 원문과 이미지에서 해석한 값 | 자료 기반 추론 | Silver 또는 Bronze | 추론 포함 버전에만 넣습니다. 사용자에게 보여줄 때도 추론임을 표시합니다. |
| 값을 뒷받침할 근거가 없음 | 정보 없음 | No data | 값을 생성하지 않습니다. 빈 값에 Gold/Silver/Bronze를 붙이면 품질 오류로 봅니다. |
근거 구조
| 속성 | 역할 |
|---|---|
basis_text(근거 문장) | 판단을 뒷받침하는 원문 문맥이나 이미지 관찰 내용을 충분한 문장으로 저장합니다. |
basis_type(근거 유형) | original_text(원문 문장), image_observation(이미지 관찰), ocr(OCR), source_url(출처 URL), raw_asset(원본 자산) 중 무엇에 기대는지 구분합니다. |
source_location(출처 위치) | 어느 문서, 문단, 이미지에서 온 근거인지 추적합니다. 화면에서는 세부 참조값을 숨겨도 됩니다. |
supports(연결 판단) | 이 근거가 어떤 판단 필드와 연결되는지 기록합니다. |
display_policy(표시 정책) | 사람용 화면에는 근거 문장을 먼저 보여줍니다. 에이전트용 검색에는 출처 위치까지 함께 넘깁니다. |
검증 기준
검증 기준은 샘플의 성공 여부가 아니라, 저장소 구조가 계속 쓸 수 있는 판단 단위로 설계됐는지 확인하는 기준입니다.
| 검증 영역 | 통과 기준 | 실패 예 |
|---|---|---|
| 구조 순서 | 식별 → 원본과 출처 → 근거 → 판단 → 재사용 순서로 읽힙니다. | 요약이나 대표 이미지가 먼저 나오고, 원본과 근거가 뒤에 숨어 있습니다. |
| 필수 묶음 | identity, source_documents, source_passages, basis, knowledge, design_logic, rag_hints가 빠지지 않습니다. | 값은 있지만 출처나 근거를 따라갈 수 없습니다. |
| 원문/추론 분리 | 원문 기반 버전에는 원문에 포함된 내용만 들어가고, AI 해석은 추론 포함 버전에만 들어갑니다. | 추론값이 원문 기재처럼 저장됩니다. |
| 근거 연결 | 값이 있으면 basis_text, basis_type, source_location이 함께 연결됩니다. | 검색 결과는 나오지만 왜 그렇게 판단했는지 설명할 수 없습니다. |
| 정보 없음 | 근거가 없으면 값을 만들지 않고 정보 없음 + No data로 남깁니다. | 빈 값이 Gold나 Silver로 표시됩니다. |
| 등급 | Gold/Silver/Bronze가 근거 강도와 해석 정도에 맞습니다. | 약한 추론이 확정 사실처럼 재사용됩니다. |
| 문체 | 요약과 설계 이유는 사람이 읽을 수 있는 문장이고, enum·라벨·등급·근거 연결은 문체 개선으로 바뀌지 않습니다. | 문장은 좋아졌지만 구조 값이나 근거 연결이 달라집니다. |
| RAG | 카드 전체가 아니라 필드 단위 청크로 검색되고, 결과에 라벨·등급·근거 문장이 함께 나옵니다. | 검색 결과가 큰 요약문만 반환되어 어떤 판단이 맞았는지 알기 어렵습니다. |
| 표시 자산 | 대표 이미지와 썸네일은 display에 두고, 판단 근거와 분리합니다. | 대표 이미지가 제품 정체성이나 근거처럼 섞입니다. |
검증 흐름
1. 원본 확인 source_documents / raw_refs / source_passages가 원문으로 되돌아갈 수 있는가 2. 근거 확인 basis_text / basis_type / source_location이 판단 필드와 연결되어 있는가 3. 판단 확인 knowledge와 design_logic 값이 원문 기재, 이미지 관찰, 자료 기반 추론으로 분리되어 있는가 4. 빈 값 확인 근거 없는 값은 정보 없음 + No data로 남아 있는가 5. 재사용 확인 summary, rag_hints, display가 앞의 판단에서 파생된 정보로만 쓰이는가 6. 검색 확인 RAG 결과가 값, 라벨, 등급, 근거 문장을 함께 반환하는가
구조 논의 지점
아래 두 항목은 바꿔야 한다는 뜻이 아니라, PM과 디자이너가 구조를 검토할 때 먼저 확인해야 할 지점입니다.
| 항목 | 객관적 판단 | 구조상 위험 | 권장 방향 |
|---|---|---|---|
| 대표 이미지 | 사례의 핵심 판단값이라기보다 사람이 훑어볼 때 필요한 표시 자산에 가깝습니다. | identity 안에 두면 제품 정체성처럼 보일 수 있습니다. display에서 이미지 참조로 관리하는 편이 더 분명합니다. | RAG 판단 단위에는 넣지 않고, 사람용 검색 결과와 보고서 표지에서만 사용합니다. |
| 근거 문장 | 짧은 인용문을 별도 구조로 관리하기보다, 판단이 기대는 원문 문맥을 충분히 보여주는 편이 낫습니다. | 짧은 조각만 남기면 본질 판단보다 인용 조각 관리가 중심처럼 보이고, 문맥이 빠져 해석이 흔들릴 수 있습니다. | 원문 기반 버전은 원문에 적힌 내용만 기록하고, 추론 포함 버전은 AI 해석을 분리해 보여줍니다. |
| 리뷰 메모 | 사람이 리뷰하는 공간을 따로 두지 않는다면 자유 메모 필드는 구조를 흐릴 가능성이 큽니다. | 자유 메모가 생기면 원문 근거, 이미지 관찰, AI 해석이 한 칸에 섞일 수 있습니다. | 근거 문장, 이미지 관찰 내용, 출처 위치처럼 역할이 분명한 필드만 둡니다. |
검토 질문
| 질문 | 보는 이유 | 결정할 기준 |
|---|---|---|
| 이 필드는 실제로 재사용되는 판단인가? | 저장소가 모든 정보를 모으는 곳이 아니라 재사용 가능한 판단을 남기는 곳인지 확인합니다. | 검색, 매핑, 보고서, 프롬프트 중 하나에 쓰이지 않으면 우선순위를 낮춥니다. |
| 근거 문장만 보고도 판단 이유가 이해되는가? | 내부 ID나 메모 없이도 PM과 디자이너가 판단을 검토할 수 있어야 합니다. | 근거 문장이 부족하면 원문 문맥을 더 길게 저장합니다. |
| 원문 기반 버전과 추론 포함 버전이 화면에서 분리되는가? | 학습용 데이터와 사용자-facing 결과는 허용되는 해석 범위가 다릅니다. | 추론값은 반드시 자료 기반 추론 라벨과 Silver/Bronze 등급을 가집니다. |
| 정보 없음이 억지로 채워지지 않았는가? | 빈 값을 채우는 순간 저장소가 사실보다 그럴듯한 문장을 우선하게 됩니다. | 근거가 없으면 No data로 둡니다. |
| 대표 이미지는 판단이 아니라 표시 자산으로 남아 있는가? | 사람용 탐색에는 필요하지만 RAG 판단 단위와 섞이면 구조가 흐려집니다. | 대표 이미지는 display에 두고, 이미지 관찰 근거는 basis로 따로 연결합니다. |
실행 샘플
이 샘플로 검증하는 것
디자인 저장소가 실제 자료를 받아 카드로 저장하고, 판단 단위로 검색되고, 필요하면 원문·로그·이미지로 되돌아갈 수 있는지 확인합니다.
1. 입력
Red Dot 10건 URL을 같은 큐로 넣습니다.
2. 스크래핑
원문, 이미지, 기본 메타를 수집합니다.
3. 카드 저장
8가지 카테고리, 설계 이유, 근거 라벨을 카드로 저장합니다.
4. RAG 검색
카드 전체가 아니라 판단 필드 단위로 검색합니다.
5. 근거 확인
카드 원문, 로그, 이미지, index로 되돌아갑니다.
검증 결과
세 실행계열 모두 10건 저장을 끝냈고, 실패 항목은 재시도로 해소했습니다. 재시도 이력은 상세 로그에 남겨두었습니다.
대표 사례로 보는 산출물
한 사례가 어떤 형태로 저장되고 다시 검증되는지 보여줍니다. 전체 30개 카드는 상세 파일에서 확인합니다.
입력 자료
https://www.red-dot.org/project/baenue-the-new-lamp-61504
저장된 카드 요약
BAENUE The New Lamp는 밝기 조절에 따라 조명 스펙트럼을 자동 전환해 주간 집중과 야간 생체리듬을 모두 고려하는 데스크 램프다.
근거 확인 경로
카드 원문, 실행 로그, 원본 MD, 수집 이미지를 같은 사이트 안에서 열 수 있습니다.
RAG 검색 샘플
사용자가 조작법을 따로 익히지 않아도 바로 쓰기 쉬운 제품 사례가 있을까요?
접근성, 조작 단순화, 즉시 피드백 관련 판단을 찾는 질문입니다.
- 검색 사례: BAENUE, EndoLight, IPEVO, Ergobaby
- 비교: 원문 기반 결과와 추론 포함 결과
공간을 많이 차지하지 않으면서 기능을 잘 정리한 제품 사례가 있을까요?
형태·CMF·기능 배치를 새 제품 방향에 매핑하기 위한 질문입니다.
- 검색 사례: POWER-UP Air Purifier, YAASA Desk Four, IPEVO TOTEM 360, Ergobaby Metro 3
- 비교: 기능 통합, 공간 조화, 형태 정리 판단
자세히 볼 곳
샘플 탭은 검증 흐름만 보여줍니다. 원문과 전체 결과는 아래에서 확인합니다.
RAG 결과
이번 RAG 결과는 같은 Red Dot 10건 큐를 세 실행계열로 돌린 뒤 생성한 index를 기준으로 확인합니다. 검색 단위는 카드 전체 요약이 아니라 각 판단 필드입니다.
Codex419 chunks
저장 10/10 · 실패 0
로컬 Claude340 chunks
저장 10/10 · 실패 0
idc-1 Claude330 chunks
저장 10/10 · 실패 0
두 가지 검색 모드
| 모드 | 화면에서 확인할 것 | 재사용 기준 |
|---|---|---|
| 원문 기반 | 원문에 직접 적힌 값만 검색 결과에 올립니다. 결과에는 원문 기재 라벨과 Gold/Silver/Bronze 등급이 함께 표시됩니다. | 학습용 데이터, 사실 확인, 보고서의 근거 문장으로 재사용합니다. |
| 추론 포함 | 원문 단서와 이미지·맥락을 바탕으로 확장한 판단까지 함께 검색합니다. 자료 기반 추론 라벨이 붙습니다. | 디자인 리서치, 디자인 매핑, 이미지 프롬프트 생성 초안에 씁니다. |
질문 예시
| 질문 | 확인되는 결과 | 보는 이유 |
|---|---|---|
| 사용자가 조작법을 따로 익히지 않아도 바로 쓰기 쉬운 제품 사례가 있을까요? | BAENUE, EndoLight, IPEVO, Ergobaby 등에서 조작 단순화와 즉시 피드백 관련 판단이 검색됩니다. | 접근성, 진입 장벽, 인터페이스 부담을 낮춘 사례를 찾기 위한 질문입니다. |
| 공간을 많이 차지하지 않으면서 기능을 잘 정리한 제품 사례가 있을까요? | POWER-UP Air Purifier, YAASA Desk Four, IPEVO TOTEM 360, Ergobaby Metro 3 등에서 기능 통합과 공간 조화 판단이 검색됩니다. | 형태·CMF·기능 배치를 새 제품 방향에 매핑하기 위한 질문입니다. |
검색 결과 위치
검색 결과 상세는 샘플 탭의 전체 실행 리포트와 /samples/ 페이지에서 확인합니다. 카드 원문과 실행 로그는 /files/에 따로 묶었습니다.