소개
여러 사이트에 흩어진 Aside 사용 사례를 찾아 원문을 확인하고, 다시 검색할 수 있는 Obsidian 지식베이스로 만들었어요.
이런 분들께 도움돼요
여러 사이트의 자료를 정기적으로 모으고 싶은 분
AI가 조사한 결과를 Obsidian에 축적하고 싶은 분
검색 결과와 실제 사용 사례를 구분해 관리하고 싶은 분
처음에는 Aside 유즈케이스 정리.md라는 긴 문서 하나에 사례를 계속 붙이려고 했어요. 하지만 자료가 늘어나자 같은 사례가 중복되고, 실제 사용 후기와 제품 소개가 섞이고, 어느 글을 원문까지 확인했는지 구분하기 어려워졌습니다.
단순 링크 모음이 아니라 Aside가 실제로 무엇을 맡아 어떻게 처리했는지 원문을 확인한 뒤, 관련 내용(상황, 어사이드로 한일, 승인지점 등)을 정리해서 보관하는 것이 목표가 됐습니다.
-> 이렇게 정리한 이유는 다음번에 Aside 유용한 사례를 좀 더 쉽게 따라해보기 위해서였습니다.
진행 방법
사용한 도구
Aside Browser: 사이트 검색, 로그인된 페이지 확인, 본문·댓글 검토
Obsidian: 사례별 Markdown 노트와 작업 기록 보관
Dataview: 실사용·공식 예시·제외 사례 조회
YouTube 자막: 영상 전체 내용 확인
Aside 루틴: 정기적인 신규 사례 수집 시도
aside-usecases 스킬: 반복되는 사례 정리 기준 재사용(자체제작)
1. 긴 문서를 개별 노트와 색인으로 바꾸기
처음에는 긴 문서 하나에 사례를 추가했습니다. 사례가 늘어나자 중복을 확인하기 어렵고, 한 줄짜리 사례와 긴 사례가 뒤섞였어요. 전체 노트 수를 실제 사용 사례 수로 오해하기도 쉬웠습니다.
그래서 사례 하나를 Markdown 노트 하나로 분리했습니다.
00. Inbox/04. AI Agent/Aside/
유즈케이스/에는 사례별 본문을 저장하고, Aside 유즈케이스 정리.md는 Dataview 조회용 색인으로 사용했습니다. 조사 범위, 제외 이유, 다음에 확인할 후보는 Aside 유즈케이스 작업파일.md에 따로 남겼습니다.
한국어 웹사이트의 스크린샷
2. 검색 결과가 아니라 원문을 확인하기
주요 수집·검토 출처는 다음과 같습니다.
YouTube
X
Threads
Reddit
지피터스
클리앙
Aside 공식 블로그와 문서
GitHub
AI코리아, Disquiet, GeekNews, 브런치 등도 후보 출처로 확인했지만, Aside가 실제로 수행한 구체적인 작업이나 결과를 확인하지 못한 자료는 바로 사례에 넣지 않았습니다.
YouTube는 제목과 설명만으로 정리하지 않고 전체 자막을 확인했습니다. 원영상 14개의 전체 스크립트를 보관하고 관련 사례 노트 36개를 다시 정리했어요. 스크립트만 읽은 경우에는 화면 결과까지 확인한 것처럼 적지 않았습니다.
X와 Threads는 원글뿐 아니라 작성자의 연결된 답글을 확인했습니다. Reddit는 게시글과 실제 사용 경험이 담긴 댓글을 함께 읽었습니다. 지피터스 는 Aside, 어사이드, 아사이드 등의 검색어로 본문·공개 댓글·작성자 후속 답변을 확인했습니다.
3. 완료·부분 작업·공식 예시를 나누기
사례마다 다음을 구분했습니다.
실제 사용자가 완료했다고 보고한 작업
영상에서 직접 보여준 데모
공식 문서가 제시한 예시
아직 실행하지 않은 계획
일부 단계만 끝난 부분 작업
Aside가 참여하지 않은 사례
설치 안내나 제품 홍보
verified_source는 원문을 확인했다는 뜻으로만 사용했습니다. 작업 결과를 제가 독립적으로 재현했다는 뜻으로 사용하지 않았어요.
결과도 completed, partial, failed, planned, unverified 등으로 분리했습니다. 예약 신청 완료와 실제 방문·수령처럼 서로 다른 결과를 합치지 않았습니다.
4. 반복 수정 기준을 스킬로 만들기
채널별로 케이스를 잡아서 여러 번 다듬어봤는데, 모든 사례를 같은 길이로 쓰면 안 된다는 점을 확인했습니다.
짧은 사례를 억지로 길게 쓰면 원문에 없는 설명이 늘어났고, 복잡한 사례를 짧게 줄이면 중요한 실패·수정·인계가 사라졌어요.
최종적으로 다음 기준을 정했습니다.
출처가 아니라 내용량·복잡도·중요도에 따라 상세도를 결정한다.
실제 공개된 프롬프트만 인용한다.
프롬프트와 이미지는 각각 최대 3개만 사용한다.
3개는 목표가 아니라 상한이다.
실제 참여한 사람과 에이전트의 역할만 기록한다.
연결 모델과 외부 CLI 에이전트를 구분한다.
결제·게시·삭제·메시지·권한 변경의 승인 여부를 표시한다.
원문에 없는 단계나 결과를 추정하지 않는다.
이 기준을 aside-usecases 사용자 스킬로 만들었으며, 맥미니에 루틴으로 등록해서 모으고 있습니다.
결과와 배운 점
확인된 결과
사례를 개별 Markdown 노트로 분리하고 Dataview 색인을 만들었습니다.
반복되는 정리 기준을 aside-usecases 스킬로 저장했습니다.
시행착오
1. 로그인 여부를 확인하지 않고 막혔다고 판단
Threads는 로그인 세션이 살아 있었지만 직접 열어보지 않고 로그인 벽이라고 기록했습니다. 이후 실제 탭을 열어보니 로그인 상태가 유지되고 있었어요. 이 경험 뒤에 “안 된다고 말하기 전에 실제 페이지와 로그인 세션을 먼저 연다”는 규칙을 작업파일에 추가했습니다.
2. 빈 응답 한 번으로 Reddit 조사를 중단했어요
처음에는 Reddit의 빈 응답만 보고 열리지 않는다고 판단했습니다. 사용자가 다시 확인을 요청한 뒤 브라우저 탭으로 접근했고, 관련 게시물의 댓글 46개를 읽을 수 있었습니다.
API나 검색 결과가 비어 있어도 실제 사이트가 열리지 않는다는 뜻은 아니었습니다.
3. YouTube 제목을 결과처럼 해석했어요
일부 영상은 제목에 시장조사, 가격 비교, 결제 등이 적혀 있었습니다. 전체 자막을 읽어보니 결제 전 단계에서 끝나거나 기능을 설명하기만 한 경우가 있었습니다.
이후 전체 스크립트를 확보하지 못하면 YouTube 사례 정리를 완료하지 않았습니다.
다른 업무에 적용한다면
이 구조는 AI 도구 사용 사례뿐 아니라 판례·논문·경쟁사 사례·고객 VOC·제품 후기처럼 여러 출처에서 자료를 수집하고 검증해야 하는 작업에도 적용할 수 있습니다.
핵심은 웹에서 많은 링크를 가져오는 것이 아니라 원문·근거·결과 상태를 유지한 채 다시 찾을 수 있는 노트로 만드는 것입니다.
앞으로의 계획
Mac Mini에서 루틴을 다시 연결하고 실제 실행 확인
YouTube와 X의 대표 사례를 추가로 검토해 상세도 기준 보완
새로운 입력에서도 스킬이 같은 품질을 내는지 평가
도움 받은 글 (옵션)
지피터스 지아코모의 GPTERS24-GIACOMO-WRITE-POST
닿님의 write-post: https://github.com/daht-mad/write-post
Codex Community Korea의 Skill 작성·평가 가이드
Aside 공식 블로그와 문서
