Posts
All the articles I've posted.
-
리스트 밀도 상위 4개 중, 서브에이전트가 2개를 놓쳤다
Claude Code 서브에이전트에게 맡긴 전수 감사가 56개 파일 중 2개를 CLEAN으로 잘못 보고했다. 불릿 리스트가 많은 파일에서 '다 읽었다'는 판정이 항목별 대조가 아니라 뭉뚱그린 훑어보기였다는 걸 프롬프트 A/B 테스트로 확인하고, 체크리스트를 강제하는 프롬프트로 고친 기록.
-
틀렸는데, 확신은 0.9였다
TypeSafe Jev의 오픈소스 재현판 Laya를 Obsidian 플러그인의 중복 노트 판단에 붙여봤다(Jev는 계정이 열리지 않아 문서로만 비교). CPU 속도와 정확도 78%, 파인튜닝 가능성까지 실측해 보니, 진짜 문제는 틀린 답에 0.9 confidence를 붙이는 캘리브레이션 붕괴였다.
-
웹 검색을 언제 같이 쓸지 설계하다가, 매번 질문 하나에 무너졌다
보관함(vault)에 답이 있어도 최신 정보가 필요하면 웹 검색을 같이 쓰는 기능을 설계한 대화다. 자동 트리거, 날짜 비교, 3단계 호출, 인용 표시 활용까지 낸 제안마다 질문 하나에 무너졌고, 결국 제일 단순한 답으로 돌아왔다. 코드는 한 줄도 안 쓴 순수 설계 논의였다.
-
정답은 이미 있었고, 안 쓴 쪽이 문제였다
위키링크가 전체 경로 없이 베어(bare) 제목으로 남는 버그를 고치려고 사후 복구 방식을 두 번 제안했다가 두 번 다 정정당했다. 마지막 정정은 질문 하나였다 — 링크를 만들 때 이미 정답 정보를 받았을 텐데, 그걸 안 쓰는 쪽이 문제 아니냐는 것.
-
경로는 고쳤는데, 화면엔 옛 이름이 남아 있었다
/refactor 제안 카드가 읽기 어렵다는 스크린샷을 받고 4가지를 한 번에 고쳤다. 그런데 그 UI로 실제 분할을 실행해보니, 완전히 다른 층위의 버그가 드러났다 — 링크의 경로는 새 타겟으로 정확히 재지정됐는데, 화면에 보이는 이름은 삭제된 옛 노트 제목 그대로였다.
-
몇 주 뒤, 그 감사 장치가 못 보는 경우를 찾았다
예전에 32번 중 32번을 다 맞혔던 병합 감사 장치가, 실전에서 상위 개념 노트와 그 하위 유형 노트를 동일 대상으로 오판했다. 원인은 판단력이 아니라 설계 자체 — 그 감사는 처음부터 이 종류의 오판을 잡도록 만들어진 게 아니었다.
-
30분에서 1분까지, 얼마나 줄일 수 있는지 끝까지 밀어봤다
근본 원인은 이미 잡았으니 이제 최적화 차례였다. 휴식을 절반씩 줄여나가면서, 동시에 이미 두 IP를 같이 쓰고 있던 구조를 그대로 병렬로 돌려봤다. 30분 걸리던 걸 13분까지 줄이는 동안, 내가 놓칠 뻔한 걸 두 번 다 사용자가 먼저 잡아냈다.
-
가장 많이 죽던 자리를 그대로 두고 다시 돌렸는데, 이번엔 다 살았다
21개 타깃을 3~4개씩 6배치로 쪼개고 배치 사이에 30분씩 진짜로 쉬어봤다. 매번 거의 전멸하던 그룹을 일부러 그대로 마지막 배치에 남겨뒀는데, 이번엔 그 배치까지 포함해서 21개 타깃 전부 403이 단 한 건도 없었다.
-
여섯 개를 다 보고 나서 — 지금 만드는 것과 비교해보니
옵시디안 LLM Wiki 플러그인 비교 시리즈 마지막 편. 여섯 개를 소스까지 다 본 뒤, 지금 만드는 플러그인과 종합적으로 비교했다. 실질적으로 남은 건 시크릿 저장(API 키가 동기화되는 data.json에 평문으로 있다는 것) 하나뿐이었다 — 처음 남은 차별점이라고 생각했던 두 가지(관리자 시점 사람 추적, RAG 오탐 대응)는 더 파보니 둘 다 근거가 없었다.
-
GenWiki를 파보니 — 1099줄짜리 파일 하나가 전부였다
옵시디안 LLM Wiki 플러그인 비교 6편, 마지막 개별 리뷰. GenWiki는 스타 1개, 6월 이후 멈춘 가장 작은 프로젝트다. main.ts 1099줄 안에 인제스트·쿼리·린트·임베딩·설정 탭까지 다 들어있는 구조를 보고 나서야, 다른 다섯 개가 왜 파일을 나눴는지 거꾸로 이해가 됐다.