모바일에서 읽히지 않던 문서 다이어그램을 Mermaid에서 Pele로 바꾼 과정
화면이 좁으면 통째로 줄어들던 문서 속 Mermaid 다이어그램 84개를 Pele로 바꿨습니다. Claude Code로 후보를 검증하고 다크 모드 색상 문제를 CSS로 푼 과정을 375px 캡처와 함께 정리했습니다.
결과 없음
화면이 좁으면 통째로 줄어들던 문서 속 Mermaid 다이어그램 84개를 Pele로 바꿨습니다. Claude Code로 후보를 검증하고 다크 모드 색상 문제를 CSS로 푼 과정을 375px 캡처와 함께 정리했습니다.
위키 원문이 200만 단어를 넘자 인덱스 파일을 통째로 읽는 방식이 한계에 다가왔습니다. 모델 용량이 큰 도구를 제외하고 SQLite와 정적 임베딩으로 하이브리드 검색을 만든 과정과, 에이전트가 사용법을 몰라도 이를 쓰게 만든 방법을 정리했습니다.
질의 20개에서 0.95점이던 위키 검색은 더 어려운 질의 40개에서 0.70점으로 내려갔습니다. 평가 세트를 만들고, 번역과 더 큰 모델을 시험하고, 마지막에 두 가지 개선으로 영어 점수를 0.80에서 0.97로 올린 과정을 정리했습니다.
에이전트 준비도를 갖춘 문서를 코딩 에이전트가 실제 연동 작업에서 어떻게 읽었는지 세션 기록으로 확인했습니다. 에이전트는 저희가 만든 마크다운 페이지를 한 번도 직접 요청하지 않았고, 저희가 쓴 스캐너들은 그 원인인 서버 버그를 잡아내지 못했습니다.
프로덕트 오너인 제가 AI 코딩 에이전트 Claude Code와 함께 한 달 동안 개발자 온보딩 사이트 DoveRunner Lab과 튜토리얼 영상 9편을 만든 과정입니다. 무엇을 AI에게 맡겼고 무엇이 사람의 몫으로 남았는지 정리했습니다.
190년 전 권위를 도용해 뉴욕을 속인 '그레이트 문 사기' 사건을 통해, 텍스트, 이미지, 영상 워터마킹과 C2PA 콘텐츠 출처 인증 기술이 AI 시대의 가짜 콘텐츠 문제에 어떤 답을 내놓고 있는지 살펴봅니다.
블로그에 'AI-assisted' 태그를 붙이려다 부딪힌 문제와, 도구가 아니라 노력과 가치를 기준으로 삼기로 한 이유.
GeekNews에서 우연히 접한 두 마이크로소프트 오픈소스 프로젝트, Zork와 Comic Chat을 하나로 엮어 만든 사이드 프로젝트 '그루스 인 코믹'의 제작 과정과 퍼블릭 베타 공개 소식입니다.
코딩 에이전트의 세션 간 컨텍스트 문제를 해결하기 위해 Mem0를 도입했다가 제거한 경험을 공유합니다. 전용 메모리 도구 없이 두 개의 마크다운 파일만으로도 크로스 세션, 크로스 에이전트 연속성을 유지하는 방법을 소개합니다.
이 프로젝트를 시작한 뒤로 직접 읽어본 위키 페이지가 몇 개나 될지 세어봤더니 거의 없었습니다. AI가 모든 연결을 만들면 지식 그래프는 AI의 것이 됩니다. 주간 리뷰 워크플로우와 슬랙 알림 루틴을 만들어 제 사고를 시스템 안에 남기려 한 과정.
5개월 만에 What If Classics를 다시 꺼내면서 분명해진 것이 있습니다. AI와의 협업에서 병목은 문제를 얼마나 잘 포장해서 넘기느냐에 있었습니다.
소스 한두 개는 신중하게 검토했습니다. 일곱 개가 쌓이자 다섯 번째부터는 제목만 훑어보고 승인하고 있었습니다. '묵인 승인' 패턴을 발견하고 인제스트를 분석·검토·쓰기 세 단계로 분리한 이야기.
'이 레지스트리 항목들, 어디서 나온 거야?' 12개 초기 데이터 중 10개는 AI의 추측이었습니다. 과거 인제스트 이력에서 증거를 역추적해 초기 데이터를 바로잡은 과정, 그리고 AI가 생성한 데이터와 사람이 확인한 데이터를 구분하지 않으면 생기는 일.
기술 문서에는 이제 두 번째 독자가 있습니다. 바로 AI 에이전트입니다. 에이전트 준비도가 무엇인지, 문서가 어디서 무너지는지, 그리고 어떻게 측정하는지 살펴봅니다.
소스 신뢰도 판단이 세션마다 달라지는 문제를 해결하기 위해 레지스트리를 만들었습니다. S축(출처 유형)과 V축(검증 가능성)을 분리하고 저자 단위까지 확장하기까지의 과정. 그리고 그 레지스트리 씨앗 데이터가 이미 같은 문제를 안고 있었다는 발견.
매번 Claude의 요약을 보고 '맞네'라고 넘어갔는데, 어느 순간 제 생각 자체가 이미 AI의 프레임 안에서 형성되어 있었습니다. 소피아 킨테로의 글에서 배운 '마찰 주입' 원칙을 위키 워크플로우에 적용한 이야기.
개인 메모, 범용 템플릿, 공개 블로그가 한 공간에 뒤섞이면 AI 에이전트도 경계를 구분하지 못합니다. 위키를 네 개의 레이어로 물리적으로 분리한 이유와, 그 과정에서 제 시스템의 어떤 부분이 사실 보편적 원리가 아니었는지 알게 된 이야기.
세션을 시작하자마자 50,000 토큰이 사라졌습니다. 93KB짜리 개발 프레임워크가 모든 프로젝트에 자동으로 로드되고 있었기 때문입니다. AI 설정에도 최소 권한 원칙이 필요하다는 것을 배운 과정.
OTT 보안 기술과 AI 에이전트가 만나는 지점을 찾다가, 첫 번째 답이 틀렸다는 것을 알게 됐습니다. 억지 연결을 버리고 진짜 연결점 하나를 찾아낸 과정을 공유합니다.
AI에게 아티클을 던져주기만 하면 위키가 저절로 채워지던 시절, 저는 지식을 쌓고 있다고 착각했습니다. 나쁜 소스를 걸러내는 3단계 품질 체크 시스템 'Ingest 2.0'을 만들게 된 과정을 공유합니다.
지난 10년간 쌓아온 OTT·DRM 경험을 AI와 함께 정리하는 개인 지식관리 시스템, LLM-Wiki를 만들어가는 과정을 공개로 기록합니다. 왜 시작했는지, 그리고 몇 주 만에 무엇이 쌓였는지 살펴봅니다.