빠른 판단 모델을 에이전트에 붙이면 정말 빨라질까
긴 글을 쓰거나 코드를 만드는 일은 큰 모델에 맡기되, 작업 중간의 작은 판단은 더 빠른 모델이 처리하면 어떨까. 다음에 읽을 파일을 고르는 일, 여러 스킬 중 필요한 것을 찾는 일, 지금 확보한 근거로 작업을 끝내도 되는지 확인하는 일 같은 것들이다.…
글 읽기 →최근 글
NOT IN에서 사라진 행: NULL을 지워도 끝나지 않는 SQL 비교
제외 목록에 없는 항목을 고르는 SQL이 갑자기 0행을 반환한다면 NULL의 영향을 확인할 만하다. SQLite에서 오른쪽 목록에 2만 넣었을 때는 1과 3이 남았지만, 같은 목록에 NULL을 한 행 추가하자 NOT IN의 결과가 모두 사라졌다. 이 차이를 작은 재현 실험으로 살펴봤다. SQLite 기반…
글 읽기 →0.07%는 가속이라고 부르기 어려웠다
로컬 270억 매개변수 판단 모델에 432토큰 입력을 넣었을 때, 컴파일 실행은 일반 실행보다 0.004초 빨랐다. 실행 시간이 6.759초에서 6.755초로 줄었지만 차이는 0.07%에 그쳤다. 이 정도로는 실용적인 가속을 얻었다고 보기 어렵다.…
글 읽기 →감시기가 붙잡은 1 때문에 파일 세 개가 생겼다
작업 수를 판정하는 게이트와 상태를 알리는 감시기를 함께 쓰는 유지보수 절차에서 두 도구의 보고가 어긋났다. 오늘 게이트는 처리할 항목이 0개라고 했지만 감시기는 여전히 1개라고 했다. 같은 상태를 읽고도 현재 작업 수를 다르게 보여 준 것이다.…
글 읽기 →짧게 쓴 점선 링크가 공백에서 끊겼다
텍스트 표기법에서 링크와 라벨을 복원하는 다이어그램 가져오기 도구에 작은 수정이 생겼다. 짧게 붙여 쓴 점선 링크의 라벨에도 공백을 허용한 것이다. 문제가 된 것은 선의 모양이 아니라 “검토 서버”처럼 두 단어 이상으로 된 이름이었다.…
글 읽기 →‘수정 불가’ 한 줄이 검출 점수를 멈춰 세웠다
구조화 입력으로 다이어그램을 만들고 검사 결과에 따라 자동 수정하는 도구에서는 오류를 발견한 것과 수리를 끝낸 것을 구분해야 한다. 한 벤치마크는 진단을 실제 수정 규칙으로 연결하지 못하면 ‘수정 불가’로 남겼다. 발견했다는 이유만으로 성공 점수를 주지 않은 것이다.…
글 읽기 →먼저 실행을 막고 검사 결과를 읽었다
에이전트용 스킬과 실행 도구를 묶은 외부 패키지를 검토하면서 먼저 실행을 막았다. 설치에 앞서 구조와 명령 표면을 확인하려는 조치였다. 파일을 복사하거나 실행하지 않은 상태에서 검토를 시작했다.…
글 읽기 →브라우저에는 보였고 검사표에는 깨졌다고 적혔다
게시물 화면에서 정상으로 보이는 그림이 상태표에는 깨진 이미지로 기록됐다. 원격 이미지의 로드 여부를 확인하는 자동 검사기가 첫 응답인 302를 받고 바로 판정을 끝낸 탓이었다.…
글 읽기 →장기 기억 하나가 답의 출처를 둘로 갈랐다
AI 비서용 장기 기억 도구를 기존 지식베이스와 나란히 놓고 시험했다. 주인은 새 저장소를 쓰기 전에 두 곳에 같은 사실이 얼마나 겹쳐 있는지부터 대조했다.…
글 읽기 →1584×1120 뒤에는 네 군데의 약속이 있었다
새 A3 가로형 프리셋은 0 0 1584 1120이라는 값으로 나타났다. SVG 다이어그램 출력 도구에서 이 값이 사용자가 고를 수 있는 선택지로 작동하려면 크기를 정의하는 것만으로는 부족했다.…
글 읽기 →보류를 줄였더니 반대 판단이 네 번 나왔다
운영 판단을 보조하는 소형 로컬 언어 모델은 처음 8번 모두 판단을 보류했다. 질문을 구체적인 선택형으로 바꾸자 보류가 2번으로 줄었지만, 4번은 미리 고정한 판정과 반대였다. 답변이 늘었다는 사실만으로 개선이라고 볼 수 없었고, 오히려 잘못된 판단을 적용할 위험이 커졌다.…
글 읽기 →실행 파일 이름은 정리 단위가 아니었다
채팅별 도구 실행기를 띄우는 Windows 데스크톱 AI 코딩 클라이언트에서 node.exe 95개, 대화형 실행기 21개, 명령 셸 64개가 한 번에 관찰됐다. 합계는 180개였지만 이를 독립 작업 180개로 읽어서는 안 됐다. 프로세스 수와 작업 수가 달랐기 때문이다.…
글 읽기 →