개발 기록이 많아지면 예전 문서도 그럴듯한 현재 설명처럼 읽힌다. 북극성에는 내장 CLI와 모델, 자동수리 경로를 다루던 기록이 남아 있다. 하지만 현재 제품을 설명할 때는 그 문서가 언제의 구조를 말하는지부터 구별해야 했다.
삭제한 기능의 기록도 쓸모가 있다
내부 모델 경로를 제품에서 제거했다고 개발의 이유와 실패 기록까지 지울 필요는 없었다. 그 구조를 왜 만들었고 어디서 비용과 책임이 커졌는지 설명할 자료가 남는다. 과거를 지우면 현재 구조를 선택한 판단도 설명하기 어려워진다.
문제는 보관과 활성화를 혼동하는 데 있었다. 소스가 아카이브에 있다는 것과 설치된 앱에서 실행된다는 것은 다르다. 과거 시험이 성공했다고 그 경로가 지금도 제품에 연결돼 있다고 쓸 수 없다. 나는 역사 기록을 유지하되 현재 기능이라는 표시를 별도로 확인했다.
아키텍처 문서 한 장으로 현재를 판단하지 않는다
초기 구조도에는 ModelGateway와 Agent Worker가 등장한다. 같은 문서 안에서도 버전별 변경 내용이 뒤따른다. 한 문단만 떼어 읽으면 지금도 브라우저가 자체 모델을 호출하고 자동으로 고친다는 설명을 만들기 쉽다.
현재 외부 제어 계약은 0.1.148에서 내장 CLI·모델 연결·수리 런타임과 관련 진입점을 제거했다고 명시한다. 나는 구조도와 최신 계약, 실제 설치 포함 범위를 함께 봤다. 문서의 제목이 아키텍처라고 해서 그 모든 문장이 같은 시점의 현재 상태인 것은 아니었다.
코드가 있다는 사실 다음에 연결을 확인한다
실행되지 않는 예전 코드도 검색 결과에 잘 나타난다. 함수 이름만 찾아 기능이 존재한다고 쓰면 삭제된 경로를 다시 소개할 수 있다. 어떤 진입점에서 호출하는지, 현재 빌드에 포함되는지, 시험 전용인지까지 질문해야 한다.
외부 MCP의 stdio 서버와 현재 도구 계약은 실제 실행 입구를 설명한다. 반면 과거 모델 시험은 오프라인 회귀 자료로 남을 수 있다. 둘 다 파일이 있다는 공통점만으로 같은 상태를 부여하지 않는다. 현재 사용자가 호출할 수 있는 경로와 과거 판단을 설명하는 자료를 나눠 적는다.
옛날 숫자에는 옛날 조건을 붙인다
내장 CLI 시기의 자동 재사용 시험에는 토큰과 호출 수가 기록돼 있다. 그 수치를 현재 외부 대화의 모든 실행에 적용하면 측정 경계가 달라진다. 저장 프로그램 내부 모델 호출 0과 전체 대화의 모델 호출 0도 같은 말이 아니다.
그래서 숫자를 소개할 때 버전·입력·실행 경로와 포함 비용을 함께 적는다. 캐시 분해가 없는 과거 영수증에서 현재 기준의 캐시 절감률을 새로 만들지 않는다. 기록이 오래돼 쓸모없는 것이 아니라 어디까지 해석할 수 있는지 정확히 남겨야 재사용할 수 있다.
중단한 계획도 완료와 구별한다
예전에 검토했던 외부 PC 주피터 연결이 지금 지원되는 기능인 것처럼 쓰지 않는다. 기존 내부 NotebookBrowser SDK와 외부 노트북 연결은 서로 다른 범위다. 한쪽이 있다는 이유로 다른 쪽의 호환성까지 완료됐다고 연결할 수 없다.
계획·구현·시험·설치·실제 업무 완료를 별도 상태로 남기면 이런 혼동이 줄어든다. 여러 파일을 검토한 일과 전체 소스를 의미 단위로 다 읽은 일도 구별한다. 공개 제작기가 많아질수록 글의 양보다 근거의 상태를 관리하는 구조가 더 중요해졌다. 같은 자료를 다시 쓰더라도 이번 글이 확인한 부분과 아직 읽지 않은 부분을 구분해 남긴다.
과거를 남기는 목적은 현재를 정확히 설명하는 것이다
독자가 필요한 것은 완벽하게 일직선으로 진행된 성공담이 아니다. 어떤 선택을 바꿨고 무엇이 현재 실행되며 어떤 한계가 남는지 알 수 있어야 한다. 나는 실패와 변경 기록을 지우지 않으면서 현재 제품 설명의 근거를 따로 연결하려 한다.
이 글은 문서와 현재 계약을 대조한 기록이며 새 운영 시험 보고서는 아니다. 이후 기능이 바뀌면 옛 글의 역사적 의미는 남기고 현재 기능 안내를 다시 확인해야 한다. 제작 기록이 쌓여도 오래된 설계를 현재의 약속으로 착각하지 않게 하는 것이 지속 발행의 기본 관리라고 본다.