지식 그래프의 선이 많다고 모두 사실일까?

먼저 노드와 선의 뜻을 나눕니다

노드는 문서, 구성요소, 작업, 개념처럼 그래프에서 가리킬 대상을 나타냅니다. 선은 두 대상 사이의 관계입니다. 예를 들어 문서 A에 “모듈 B가 파일 C를 처리한다”고 명시돼 있다면, 그 문장과 위치를 근거로 관계를 후보로 만들 수 있습니다. 하지만 두 노드가 화면에서 가까이 놓였다는 이유만으로 의존 관계나 사실 관계가 생기는 것은 아닙니다.

AI Systems Atlas의 관계 모델에는 구조, 명시, 추론 같은 층이 있습니다. 구조 관계는 문서와 하위 항목의 포함처럼 파서가 확인하는 계층이고, 명시 관계는 텍스트에 직접 드러난 표현을 바탕으로 합니다. 추론 관계는 더 신중한 근거 검사가 필요합니다. 저장소의 온톨로지 문서는 의미 관계에 source block과 고정된 소스 URL 등 근거가 있어야 한다는 기준을 둡니다. 이것은 모든 화면의 선이 똑같이 검증됐다는 말과 다릅니다.

오른쪽의 점선은 설명을 위한 그림입니다. 실제 Atlas 코드의 화면용 display 연결은 떨어진 클러스터를 하나의 그래프로 읽도록 도울 수 있지만, 저장된 근거 관계나 분석 지표에 합산하지 않는 별도 시각 층입니다. 화면에 선이 많아져도 ‘새로운 사실이 많이 발견됐다’고 계산하지 않아야 하는 이유입니다.

같은 문서를 놓고 두 가지 선을 생각해 봅니다

다음은 원리를 이해하기 위한 가정 예시입니다. 문서 A에 “수집기가 이벤트를 저장소로 보낸다”는 문장이 있고, 그래프에는 ‘수집기’와 ‘저장소’ 노드가 있습니다. 이 문장을 원문 블록과 파일 경로로 다시 찾을 수 있다면 두 노드를 잇는 관계는 검토할 근거가 있습니다. 그래도 관계의 방향과 표현이 문장을 과장하지 않았는지 읽어야 합니다. ‘보낸다’를 ‘항상 성공한다’로 바꾸면 원문을 넘어선 주장입니다.

반면 화면에서 ‘수집기’ 묶음과 ‘관측’ 묶음이 너무 멀리 떨어져 있어 읽기 어려워, 시각화를 위해 두 군집을 연결했다고 해 보겠습니다. 이것은 탐색을 돕는 선입니다. 독자가 전체 지도를 한눈에 보는 데는 유용하지만, 두 군집이 원문에서 직접 의존한다고 말할 근거는 아닙니다. 앞의 선과 뒤의 선이 같은 굵기·색으로 보이면 오해하기 쉬워서 계층 구분이 중요합니다.

이 사례에서 말하는 ‘근거’도 한 단계 더 나눠야 합니다. 로컬의 전체 앱은 문서 블록, commit, 경로, 줄 번호 같은 정보를 관계와 연결하도록 설계됐습니다. 그러나 공개 정적 데모는 개인정보와 내부 식별 정보를 줄이기 위해 검증된 JSON 스냅샷만 읽고 내부 relation evidence와 block ID를 공개 산출물에서 제거합니다. 따라서 공개 화면에서 선을 본 것만으로 개별 원문 블록이 함께 전달됐다고 말하면 안 됩니다.

공개 데모와 전체 로컬 앱은 같은 화면이 아닙니다

AI Systems Atlas 저장소는 공개 배포와 로컬 전체 앱의 기능 경계를 따로 설명합니다. 공개 배포는 GitHub에 고정된 검증 JSON을 읽는 정적 화면입니다. 운영 D1 데이터베이스, OAuth 토큰, 변경 API를 실어 보내는 방식이 아닙니다. 그래프를 돌리고 확대하고 노드를 탐색하는 경험은 제공할 수 있지만, 이것을 문서 업로드·쓰기·계정 연결 기능이 공개 데모에서 작동한다는 증거로 삼을 수는 없습니다.

위 이미지는 저장소의 Gold Graph 검토 표본 캡처입니다. 읽기 위한 실제 저장소 자료이지만 현재 공개 Production의 전체 노드 수나 최신 동작을 증명하는 실시간 화면은 아닙니다. 저장소 README에도 배포 화면과 로컬 최신 캡처가 일시적으로 다를 수 있다고 적혀 있습니다. 따라서 캡처 안에 보이는 숫자를 이 글의 보편적 성능 수치처럼 재사용하지 않습니다.

공개 스냅샷의 테스트는 내부 ID, 비공개 block ID, source URL 같은 정보를 결과에서 제거하는지 확인합니다. 이 테스트가 의미하는 것은 ‘공개 화면에 모든 근거가 있다’가 아니라 오히려 공개 범위가 의도적으로 제한된다는 것입니다. 특정 관계의 사실성을 확인해야 한다면 공개 스냅샷에 없는 근거를 지어내지 말고 원본 문서와 고정된 저장소 버전을 별도로 대조해야 합니다.

선 하나를 판단하는 네 단계

그래프를 자료 탐색에 활용할 때는 다음 순서가 안전합니다. 사용자가 보는 제품마다 기능 이름은 다르지만 판단 질문은 비슷합니다.

1. 노드를 정확히 고릅니다. 이름이 비슷한 다른 저장소·문서·버전의 노드를 하나로 섞지 않습니다. 같은 라벨이라도 source-local 노드일 수 있습니다.
2. 관계의 층을 봅니다. 구조·명시·추론 관계인지, 단순 display 선인지 확인합니다. 화면용 연결이라면 그 선은 원문 주장의 증거가 아닙니다.
3. 원문 근거를 찾습니다. 관계가 주장하는 방향과 표현을 문서 문장, 파일 경로, commit 또는 제공된 근거 블록에서 확인합니다. 공개 데모가 원문 블록을 제공하지 않으면 해당 화면에서만 검증을 끝냈다고 쓰지 않습니다.
4. 결론을 조건부로 적습니다. 원문이 말하는 범위를 넘지 않으면 채택하고, 근거가 없거나 버전이 다르면 보류합니다. ‘선이 보임’과 ‘관계가 입증됨’을 메모에서 구별합니다.

간단한 기록 양식을 만들어도 좋습니다. 노드 A / 노드 B / 관계 유형 / 확인한 문서·버전 / 원문 위치 / 판단(확인·보류)를 한 줄에 적습니다. 가령 “수집기 → 저장소 / 전송 / 문서 A의 해당 문단 / 확인”처럼 남기되, 문장이 단지 ‘전송을 시도한다’고만 했다면 판단도 그 수준으로 제한합니다. 반대로 display 선뿐이었다면 원문 위치를 억지로 채우지 말고 ‘탐색용 연결, 사실 관계 미확인’으로 둡니다.

이 절차는 단순히 그래프의 오류를 찾기 위한 것이 아닙니다. 그래프는 방대한 문서에서 어디를 읽을지 제안하는 지도로 매우 유용합니다. 다만 지도 위의 길과 원문이 말하는 사실을 동일하게 취급하지 않아야 합니다. 시각화 덕분에 서로 떨어진 개념을 발견했더라도, 최종 설명에는 확인 가능한 출처와 범위를 다시 연결하는 편이 좋습니다.

그래프가 특히 쉽게 오해되는 순간

첫째, 선의 밀도를 신뢰도의 지표로 읽을 때입니다. 연결선 수가 많다는 것은 화면 배치 방식이나 추출 규칙의 결과일 수 있습니다. 근거 품질과 선 개수는 같은 척도가 아닙니다. 둘째, 이름이 비슷한 노드를 같은 대상으로 합칠 때입니다. 저장소의 온톨로지 문서는 저장소·문서·작업 같은 대상을 source-local로 유지하는 규칙을 둡니다. 다른 문서의 같은 라벨을 무조건 하나로 병합하지 않으려는 이유입니다.

셋째, 공개 데모에서 보지 못한 기능까지 짐작할 때입니다. 그래프를 클릭할 수 있다고 데이터 수정도 되는 것은 아니며, 정적 JSON에 선이 있다고 내부 D1의 원문 근거가 그대로 공개된 것도 아닙니다. 넷째, 오래된 캡처의 수치와 현재 화면의 수치를 섞을 때입니다. 그래프는 입력 문서와 스냅샷 버전에 따라 바뀌므로 수량을 인용하려면 시점과 대상 버전을 함께 적어야 합니다.

결론은 선의 종류를 지우지 않는 것입니다. 화면용 연결은 탐색에, 근거 관계는 원문 검토에 사용하세요. 그래프를 출발점으로 삼고 문서·버전·관계 방향을 확인한 뒤에야 자신의 설명에 사실 관계로 옮겨 적는 것이 안전합니다. 선이 많다는 이유만으로 더 많은 사실을 안다고 말하지 않는 태도가 이 도구를 더 유용하게 만듭니다.

세 편의 공통 원칙도 같습니다. 녹음 파일의 완료 표시, 한도 화면의 %, 그래프의 연결선은 모두 맥락을 가진 상태입니다. 표면적인 표시 하나보다 그것이 만들어진 조건과 검증할 경로를 확인할 때 실제 판단에 도움이 됩니다.