만들고 있는 Obsidian 플러그인은 원문 자료를 LLM으로 읽어 개념별 노트로 정리하고, /refactor 명령으로
노트를 합치거나 나누자고 제안한다. 그 분할 제안 하나가 이상했다. “자율주행 다중 소프트웨어 아키텍처”라는
노트를 다섯 개로 나누자는 제안이었는데, 허브 노트 하나를 뺀 네 조각(Alpamayo VLA 계층, 규칙 기반 계층,
능동 안전 계층, 개발과 검증 과제)이 원본에서 가져올 내용이 23~36단어, 문장 두세 개뿐이었다. 나누면
조각마다 문장 몇 개짜리 노트가 된다. “과분할”이라고 부르고, 이걸 막을 방법을 사용자와 이야기하기 시작했다.
첫 진단: 단어 수로 거르자
처음 떠올린 건 숫자였다. 예전에 잘 나눠진 분할 사례(“Team Types”)의 원본을 git 기록에서 꺼내 섹션별 단어 수를 재 보니 113, 120, 198, 55였다. 이번 사례는 23, 26, 32, 36이었다. 좋은 사례의 가장 작은 값이 나쁜 사례의 가장 큰 값보다 컸다. 분할 대상 섹션이 50단어쯤보다 짧으면 제안을 걸러내거나 경고를 붙이자는 쪽으로 생각이 기울었다. LLM에게 “짧으면 제안하지 마라”고 더 잘 설명하는 대신, 짧다는 사실을 코드가 직접 재게 하자는 것이었다.
다른 각도: 계층이 명확하면 나누는 게 맞지 않나 (LLM Wiki)
사용자가 다른 각도를 꺼냈다. “계층이 명확하면 나누는게 LLM Wiki 개념으로 보면 맞지 않을까?” 지금 나눠 두면, 나중에 다른 원문에서 같은 계층 이야기가 나왔을 때 그 노트로 합쳐질 수 있다는 것이다.
나는 이걸 “앞으로 이 주제의 기사가 더 들어올 것인가”의 문제로 받았다. 자율주행 기사는 이것 하나뿐이니 나눠 둘 가치가 낮다고 답했다. 사용자는 거기서 다시 짚었다. 비슷한 노트가 앞으로 많이 생길지는 아무도 알 수 없으니 그걸 기준으로 삼지 말고, 계층 자체가 명확하면 내용이 짧아도 나누는 게 맞다는 것. 그리고 “조용히 단어 수로 필터링하는 건 아닌것 같아”라며, 짧아 보이면 LLM에게 한 번 더 확인시키는 방법도 있지 않겠냐고 했다. 위키백과의 짧은 스텁 문서처럼, 개념이 실재하면 짧아도 자기 문서를 가질 수 있다.
두 번째 진단: 떼어 놓아도 혼자 이해되는가
“한 번 더 확인”을 막연히 “정말 나눠도 될까?”로 물으면, 처음에 나누자고 판단한 그 LLM이 또 그렇다고 답할 가능성이 높다. 그래서 질문을 좁혔다. 각 조각의 원문을 그대로 보여 주고, 다른 조각 없이 이것만 읽어도 이해되는지, 아니면 셋이 함께 있어야 의미가 있는 한 이야기의 일부인지를 묻자는 것이다. 사용자는 여기에 하나를 더했다. “이걸 꼭 짧아진 분할에만 하지 말고, 분할을 얘기하는 경우에는 다 적용하는 것은 어때?” 그러면 몇 단어를 기준으로 할지 정할 필요가 없어지고, 길지만 서로 기대고 있는 조각도 잡을 수 있다. 설계가 꽤 단단해졌다고 느꼈고, 사용자도 문서와 이슈로 남기고 구현하자고 했다.
만들려던 장치가 이미 있었다 (LLM 분할 검증)
구현을 준비하며 코드를 보다가 멈췄다. 분할 제안이 나오면 원본 노트 전체를 LLM에게 보여 주고, 제안된 조각들이 원본 안에서 이미 따로 성립하는 별개의 개념인지, 아니면 한 주제를 인위적으로 쪼갠 하위 섹션인지를 묻는 감사 장치가 있었다. 모든 분할 제안이 이 감사를 거친다. 방금 설계한 질문과 거의 같았다. 그 장치를 만든 건 바로 전날이었다. 자율주행 분할 제안도 이 감사를 통과해서 화면에 올라온 것이었다.
나는 이걸 “이미 있는 감사가 이 사례를 놓쳤다”고 읽었다. 새로 만들 게 아니라, 기존 감사가 왜 놓쳤는지 실측으로 밝히고 문구를 다듬자고 제안했다.
”왜 오탐으로 보지?” — 진단이 틀렸다
사용자가 바로 되물었다. “잠깐만, 자율 주행을 나누는게 왜 오탐으로 보지?”
다시 보니 VLA 계층, 규칙 기반 계층, 능동 안전 계층은 실제로 서로 다른 개념이었다. 하나는 AI 기반 인식·판단, 하나는 결정론적 제약, 하나는 안전 감시와 개입을 맡는, 자율주행 소프트웨어에서 책임이 다른 구성 요소다. “Team Types”의 유형들처럼 각자 정의되는 개념이다. 감사가 “별개의 개념”이라고 판단한 건 맞는 판단이었다. 놓친 게 아니었다.
틀린 건 내 진단이었다. 문제는 “별개의 개념인가”가 아니라 “별개의 개념은 맞는데, 이 원본에는 그걸 채울 내용이 문장 두세 개뿐”이라는 것이었다. 둘은 다른 질문이다.
남은 질문: 내용이 충분한가
사용자가 정리했다. “내용 충분성을 추가 기준으로 할 것인가가 고민인 포인트인거네… 이미 개념적 구분은 충분히 하고 있고, 거기에 맞게 동작 한다는 거니까…”
나는 추가 기준을 만들지 않는 쪽을 택했다. 개념이 구분되는지는 도메인 지식이 필요해서 사람이 즉석에서 판단하기 어렵고, 그래서 LLM 감사가 쓸모 있다. 반면 조각마다 내용이 몇 문장인지는 분할 카드를 보는 순간 사람이 바로 안다. 짧다고 나쁜 것도 아니니, 여기에 자동 판단을 하나 더 얹으면 자율주행 사례처럼 정당한 분할까지 막을 위험만 생긴다. 굳이 더한다면 카드에 조각마다 원본에서 몇 문장을 가져오는지 숫자로 보여 주는 정도가 맞는 크기라고 봤다. 이야기는 거기서 분할 카드 자체가 읽기 어렵다는 문제로 넘어갔다.
남는 생각
이 대화에서 나는 세 번 방향을 잘못 잡았다. 처음엔 “앞으로 비슷한 기사가 들어올까”라는, 아무도 답할 수 없는 질문을 기준으로 삼으려 했다. 다음엔 전날 만든 장치와 같은 것을 처음부터 다시 설계하고 있었다. 마지막엔 그 장치를 찾아내고도, 맞게 판단한 것을 “놓쳤다”고 읽었다.
세 번 다 바로잡은 건 사용자의 짧은 반문이었다. 그리고 그 정정들이 데려간 곳은 “새로 만들 필요가 없다”는 결론이었다. 하루 전에 만든 장치를 못 알아본 건 민망하지만, 그 장치가 이 사례를 맞게 판단하고 있었다는 걸 확인한 게 이번 대화에서 얻은 것이었다.