research

User Customization UX

User Customization UX

핵심 긴장

개발자:  YAML, JSON, 코드로 설정
일반인:  YAML이 뭔지도 모름

이 간극을 메우는 게 UX 설계의 전부.

세 가지 UX 접근

접근 1 — 폼 기반 (가장 단순)

이름: [회의 전 준비]
실행 시점: [회의 ▼] [30 ▼] 분 전

할 일:
  ☑ 관련 자료 검색
  ☑ PDF 다운로드
  ☑ Markdown 변환
  ☐ RAG 인덱싱

저장 위치: [/Users/lee/Research]

내부적으로 YAML 생성, 사용자는 몰라도 됨.

  • 장점: 진입 장벽 낮음
  • 단점: 미리 만들어진 옵션 밖으로 못 나감

접근 2 — 자연어 입력

> 회의 30분 전에 논문 검색해서 Obsidian에 저장해줘

[이렇게 설정할게요]
  ✓ 트리거: 회의 30분 전
  ✓ 작업: 논문 검색 → MD 변환 → Obsidian 저장

맞으면 [확인], 수정하려면 [다시 말하기]

LLM이 자연어 파싱 → 사용자가 검토.

  • 장점: 자유도 높음
  • 단점: 파싱 실패 가능성, 검증 필요

접근 3 — 레고 블록 (시각적 조합)

[회의 30분 전] → [논문 검색] → [MD 변환] → [Obsidian 저장]

Zapier, n8n 방식.

  • 장점: 흐름이 시각적으로 보임
  • 단점: 구현 복잡, 모바일 불편

단계별 제공 전략

초보: 폼 (접근 1)
중급: 자연어 (접근 2)
고급: 블록 or 직접 YAML

처음엔 폼만으로 충분. 나머지는 나중에 추가.

최종 저장 구조

폼이든 자연어든 블록이든, 목표는 이 JSON 생성:

{
  "user_id": "lee",
  "skills": [
    {
      "name": "research_before_meeting",
      "trigger": {
        "type": "before_event",
        "minutes": 30,
        "filter": "title contains '논문'"
      },
      "params": {
        "save_path": "/Users/lee/Obsidian/research",
        "wants_md": true,
        "wants_rag": true
      }
    }
  ]
}

UI는 이 JSON을 만드는 방법의 차이일 뿐.

자연어 파싱 시 주의사항

파싱 결과를 바로 저장하지 않는다. 사용자가 검토하고 확인하는 단계가 반드시 필요. LLM이 잘못 파싱할 수 있기 때문.

관련 개념

← research 목록으로홈으로