디자이너의 역할 변화
UX/UI 디자이너는 이제 노트 정리자가 아니라 AI가 활용할 수 있는 데이터 시스템 설계자가 되어야 한다. Obsidian은 이 전환의 실용적 인터페이스다.
LLM Wiki Reference Analysis
이 페이지는 Obsidian 기반 LLM wiki가 UX/UI 디자인 업무에서 왜 실무 자산이 되는지 분석한 문서를 HTML로 재구성한 것이다. 핵심은 디자인 산출물을 잘 만드는 것을 넘어, AI 에이전트가 반복적으로 참고하고 실행할 수 있는 로컬 지식 시스템을 설계해야 한다는 주장이다.
영상의 중심 메시지는 UX/UI 디자이너가 개별 산출물 제작자에 머무르지 않고, AI가 읽고 실행할 수 있는 로컬 지식 시스템의 설계자가 되어야 한다는 것이다. 발표자는 그 중심 도구로 Obsidian을 제시한다. Obsidian은 로컬 Markdown 파일, 문서 간 링크, 그래프 구조를 기반으로 하므로 사람이 지식의 관계를 관리하기 쉽고 AI 에이전트도 파일을 읽고 쓰기 쉽다.
LLM wiki, vibe coding, agentic engineering 흐름은 디자인 리서치, 디자인 시스템, 사용성 평가, 시나리오 설계, 인터뷰 분석, 보고서 기준 같은 UX/UI 업무와 직접 연결된다. 이런 지식을 Markdown으로 축적하면 AI는 단순 답변 도구가 아니라 프로젝트 맥락을 기억하고 반복 업무를 수행하는 동료에 가까워진다.
가장 중요한 전략은 데이터 독립성이다. 누구나 같은 모델을 사용할 수 있는 환경에서는 보편적인 70점 또는 80점 수준 결과물이 빠르게 평준화된다. 차이를 만드는 것은 팀과 디자이너가 축적한 로컬 프로젝트 사례, 리서치 데이터, 디자인 시스템, 평가 기준, 프롬프트와 스킬 문서다.
UX/UI 디자이너는 이제 노트 정리자가 아니라 AI가 활용할 수 있는 데이터 시스템 설계자가 되어야 한다. Obsidian은 이 전환의 실용적 인터페이스다.
디자인 방법론, 리서치, 결정 기록, 평가 기준을 Markdown 파일로 구조화하면 일회성 문서가 아니라 반복 사용 가능한 운영 지식이 된다.
사용성 평가 계획, 인터뷰 코딩, 페르소나 도출, 디자인 시스템 비교, 개선안 작성은 스킬 문서와 로컬 데이터의 조합으로 반복 실행될 수 있다.
영상은 Andrej Karpathy가 제시한 LLM wiki, vibe coding, agentic engineering 흐름을 UX/UI 실무로 가져온다. LLM wiki는 단순 메모장이 아니라 AI가 읽고, 관련 문서를 찾아보고, 작업 기준까지 참고할 수 있는 운영 시스템이다. 이 관점에서 Obsidian은 메모 앱보다 인간과 AI 사이의 파일 기반 인터페이스에 가깝다.
Markdown은 구조가 단순하고 텍스트 중심이며 불필요한 태그와 스타일 노이즈가 적다. AI 에이전트가 파일을 읽고 수정하는 상황에서는 제목, 목록, 링크, 표, 메타데이터가 명확한 문서가 유리하다. 다만 발표자가 말하는 읽기 시간과 토큰 사용량 절감 수치는 조직별 벤치마크로 별도 검증해야 한다.
Notion은 협업 문서와 데이터베이스에 강하지만, 발표자는 AI 에이전트 워크플로에서는 로컬 파일과 Markdown을 직접 조작할 수 있는 Obsidian의 장점을 강조한다. 같은 vault를 VS Code, Cursor, Claude Code, Codex, Gemini 같은 도구에서 열면 지식 관리와 작업 실행 사이의 거리가 줄어든다.
Obsidian의 그래프와 링크 구조는 사람이 주제 간 관계를 이해하는 데 도움을 주고, AI에게는 관련 파일을 찾는 단서가 된다. 에이전트에게 폴더 전체를 무작정 읽히는 대신 관련 프로젝트, 평가 기준, 디자인 시스템 문서를 링크로 연결하면 탐색 범위와 토큰 사용을 줄일 수 있다.
공개 자료만 활용하는 팀은 비슷한 결과물을 얻게 된다. 실제 고객 인터뷰, 사용성 테스트 결과, 실패 사례, 내부 의사결정 기록, 디자인 시스템 히스토리, 제품별 제약 조건을 축적한 팀은 AI에게 훨씬 강한 맥락을 제공한다. 결과적으로 AI 결과물의 품질은 모델뿐 아니라 로컬 지식의 품질에 의해 결정된다.
AI는 평가 계획, 과업 시나리오, 체크리스트, 리스크 탐지, 보고서 구조화에 유용하다. 그러나 실제 사용자 테스트를 완전히 대체해서는 안 된다. 사용자의 감정, 망설임, 상황 맥락, 조직 제약, 관찰 기반 통찰은 여전히 현장 리서치와 전문가 검토가 필요하다.
사용성 평가 계획서 작성법, 인터뷰 분석 기준, 시나리오 설계 방식, 보고서 작성 기준, 개선안 제안 기준을 Markdown 스킬로 만들면 에이전트가 동일한 절차와 기준을 반복 실행할 수 있다. 좋은 스킬 문서는 목적, 입력, 절차, 산출물 형식, 검토 기준, 금지 사항을 포함해야 한다.
실습 흐름은 Obsidian vault 생성, 같은 폴더를 에디터에서 열기, AI 플러그인이나 CLI 연결, Web Clipper로 웹 자료를 Markdown 저장, 저장 자료를 스킬 문서와 디자인 시스템 문서로 발전시키는 순서다. 처음에는 공개 레퍼런스를 씨앗으로 삼고, 시간이 지나면서 실제 프로젝트 사례로 보강하는 접근이 현실적이다.
| 영역 | 기존 방식 | AI-native LLM wiki 방식 | 핵심 산출물 |
|---|---|---|---|
| 사용자 리서치 | 인터뷰 후 수동 정리 | 인터뷰 데이터와 분석 스킬을 기반으로 보고서, 페르소나, 시나리오 초안 생성 | Research report, persona, insight map |
| 디자인 시스템 | 문서와 컴포넌트가 분리됨 | 디자인 토큰, 컴포넌트 원칙, 사용 예시를 Markdown으로 연결 | Design system notes, component rules |
| 사용성 평가 | UT 룸, 전문가 평가, 수동 보고서 | AI 예비 평가, 시나리오 생성, 결과 요약, 개선안 초안 | UT plan, heuristic review, improvement proposal |
| 디자인 자산화 | 프로젝트별 파일 저장 | 성공 사례와 실패 사례를 지식 카드로 축적 | Case study, pattern note, decision log |
| 구현 연계 | 디자이너와 개발자 간 전달 | Markdown 설계 문서를 에이전트가 코드 작업의 맥락으로 활용 | Design MD, implementation brief |
운영 모델의 핵심은 각 단계가 다음 단계의 입력으로 축적된다는 점이다. 리서치 데이터는 페르소나와 시나리오의 입력이 되고, 시나리오는 사용성 평가의 입력이 되며, 평가 결과는 디자인 시스템과 개선안의 입력이 된다. LLM wiki는 이 순환을 파일과 링크로 고정한다.
영상 후반부는 Hermes Agent와 OpenClove류 자율 에이전트의 가능성을 다룬다. 핵심은 AI가 질문에 답하는 데서 끝나지 않고, 정해진 시간에 뉴스를 수집하고, 웹 콘텐츠를 확인하고, Markdown 문서를 생성하고, 웹사이트를 갱신하는 식의 반복 업무를 맡을 수 있다는 점이다.
목적, 입력 자료, 과업 시나리오, 평가 기준, 리스크 예측, 관찰 항목, 실제 사용자 테스트를 대체하지 않는다는 caveat를 포함한다.
발화 정리, 코드 부여, 패턴 탐색, 상충 의견 분리, 인사이트 도출, 페르소나 초안, 과잉 일반화 금지 기준을 포함한다.
컴포넌트 이름, 사용 사례, 상태, 접근성 기준, 금지 패턴, 토큰, 예외 케이스, 관련 프로젝트 링크를 기록한다.
배경, 사용자 문제, 제약, 의사결정, 실험, 결과, 배운 점, 재사용 가능한 패턴을 다음 프로젝트의 입력으로 남긴다.
이 영상의 가치는 Obsidian 사용법 자체보다 UX/UI 디자이너의 역할 변화를 분명히 설명한다는 데 있다. 디자이너는 AI에게 일을 잘 시키는 수준을 넘어, AI가 계속 일할 수 있는 지식 구조와 운영 시스템을 만들어야 한다. 이는 생산성 팁이 아니라 디자인 조직의 작업 방식 전환에 가깝다.