새 세션에서 프로젝트 구조를 설명하려면 어느 파일이 시작점인지부터 찾아야 한다. 블로그 프로젝트라면 글 파일, 파서, 목록 페이지, 배포 스크립트가 서로 연결된다. 파일 이름을 알고 검색하는 작업은 짧다. 이름을 모르고 관계를 찾아야 하는 작업에서는 읽을 범위가 커진다.
Graphify에 관심을 가진 이유는 이 탐색 과정을 미리 만든 관계로 좁힐 수 있는지 확인하고 싶어서다. 기존 글 제목에는 “돌려봤다”라고 적었지만 본문에는 실행할 계획만 있었다. 이번 수정에서는 직접 실행한 후기라는 표현을 바로잡는다. 토큰 절감률을 측정하지 않았으며 아래는 공식 저장소와 보안 문서를 바탕으로 만든 평가 설계다.
같은 이름의 패키지부터 구별한다
2026년 9월 8일 확인한 대상은 Graphify-Labs/graphify 저장소다. 공식 README는 PyPI 패키지 이름을 graphifyy라고 명시한다. 명령 이름과 패키지 이름이 다르고 비슷한 이름의 다른 프로젝트도 있으므로 검색 결과에서 이름만 보고 설치하지 않는다. 저장소에서 연결한 패키지와 문서가 맞는지 확인하는 작업부터 필요하다. Graphify 공식 저장소
버전도 기록해야 한다. 예전 영상에 나온 기능 설명과 현재 README의 설치 방법이 같다고 가정할 수 없다. 평가 노트에는 사용한 릴리스나 커밋, 운영체제, 분석 대상 저장소의 커밋을 함께 남긴다. 환경을 적지 않은 사용 후기는 다른 사람이 결과를 재현하기 어렵다.
현재 공식 문서는 코드 구조를 로컬 AST 파싱으로 추출하고 문서·이미지 등에는 별도의 의미 분석 경로를 사용한다고 설명한다. 문서 파일까지 어떤 모델로 처리하는지는 설정에 따라 달라진다. 코드 파싱이 로컬이라는 설명을 자료 전체가 기기 밖으로 나가지 않는다는 뜻으로 확대하지 않는다.
출력에는 관계 데이터와 사람이 읽는 보고서 등이 포함된다. 그래프를 만든 뒤에도 에이전트가 실제로 이를 참조하는지 확인해야 한다. 파일만 생성해놓고 기존 파일 탐색을 반복하면 저장·갱신 비용만 추가될 수 있다. 스킬이나 후크를 등록하는 절차는 설치한 플랫폼의 공식 안내에 맞추고, 기존 설정을 어떻게 바꾸는지도 검토한다.
그래프 연결에는 원문 근거가 있어야 한다
코드에 import가 있다는 사실과 두 모듈이 같은 업무를 수행한다는 해석은 구분해야 한다. 관계를 추출하는 도구가 보여주는 선을 실행 시점의 실제 호출로 읽으면 틀릴 수 있다. 조건부 import, 플러그인 로딩, 파일 이름을 문자열로 조합하는 코드처럼 정적 분석으로 놓칠 경로도 생각해야 한다.
공식 README는 추출된 연결과 추론한 연결을 구별하는 표식을 설명한다. 평가에서는 표식만 믿기보다 원본 파일의 위치를 열어 확인한다. “게시글 본문을 누가 읽는가”라는 질문에 답했다면 함수 이름, 호출 위치, 관련 테스트까지 찾아간다. 근거 파일이 없는 관계를 최종 설명에 사용하지 않는 기준을 두겠다.
블로그에서 요약 필드를 추가하는 상황을 가정해보자. 데이터 타입에 필드를 넣고 상세 화면만 수정하면 목록이나 발행 스크립트에서 값이 빠질 수 있다. 그래프에 필드명 검색 결과가 있어도 데이터가 어느 경로로 저장되는지까지 찾았는지는 다른 문제다. 이 경우 정답은 관련 파일의 나열과 값이 전달되는 순서다.
나는 답변 채점표에 존재하지 않는 파일, 실제로 호출하지 않는 함수, 누락된 소비자를 따로 적겠다. 토큰을 적게 썼어도 놓친 발행 경로 때문에 배포를 다시 해야 한다면 좋은 결과로 평가하지 않는다. 코드 변경 후에는 원본을 확인하는 책임이 개발자에게 남는다.
생성 비용을 포함한 비교 질문을 만든다
대조 조건은 그래프 없이 기존 검색·파일 읽기를 하는 방식이다. 실험 조건은 그래프를 먼저 조회한 뒤 필요한 원본을 읽는 방식이다. 두 조건에는 같은 모델, 같은 저장소 커밋, 같은 질문을 제공한다. 새 세션을 사용하고 질문 순서를 바꾸어 앞선 답의 영향을 줄이는 구성을 제안한다.
처음 시험할 질문은 작은 묶음으로 만든다. 아래는 이 블로그 같은 콘텐츠 저장소를 가정한 예시이며 실제 Graphify 실행 결과가 아니다. 사람이 코드로 확인한 정답을 먼저 준비해야 한다.
| 질문 | 정답에 포함할 내용 | 기록할 오류 |
|---|---|---|
| 글 본문은 어디에서 읽나? | 로컬·DB 경로와 선택 조건 | 한 경로만 답함 |
| 요약 필드를 추가하면 어디가 바뀌나? | 타입·로더·화면·저장 경로 | 소비자 누락 |
| sitemap에서 빠지는 글의 조건은? | 공개 조건과 필터 | 파일 존재만으로 판단 |
| 발행 실패 시 어느 상태가 남나? | 배포·DB의 처리 순서 | 성공한 단계와 혼동 |
| 이 함수를 옮기면 어떤 테스트를 보나? | 직접 참조와 회귀 검사 | 이름이 비슷한 테스트 선택 |
질문별로 입력·출력 토큰, 걸린 시간, 읽은 원본 파일 수, 정답 여부를 적는다. 모델 제공자가 캐시 입력을 별도로 과금한다면 캐시 사용량도 분리한다. 한 번의 평균값만으로 판단하지 않고 반복 실행에서 편차를 확인한다. 특정 질문 하나에서 큰 절감이 나왔다고 프로젝트 전체 비용에 적용하지 않는다.
그래프 비용은 별도 줄에 둔다. 최초 생성, 문서 의미 분석, 변경분 반영, 그래프 질의 비용을 모두 포함해야 한다. 다음 식은 계산 방법을 설명하는 예시다.
그래프 사용 총비용
= 최초 생성 + 변경분 갱신 + 질의 비용 + 추가 원문 확인 비용
비교 대상 총비용
= 기존 파일 탐색 + 원문 읽기 + 오류 재작업 비용
가령 초기 생성에 2만 단위의 비용이 들고 질의마다 1천 단위가 줄어든다는 가정을 놓으면, 갱신 비용을 제외해도 스무 번 질의해야 초기 비용을 회수한다. 이 숫자는 단위를 맞춘 가상 계산이며 Graphify 측정값이 아니다. 하루에 한 번 열어보는 작은 저장소와 여러 작업자가 반복 조회하는 저장소의 선택이 달라지는 이유를 설명하기 위한 예다.
개발자가 공개한 벤치마크도 같은 방식으로 읽는다. 대상 데이터, 질문 수, 평가 모델, 비교 기준과 재현 명령이 있는지 확인한다. 해당 벤치마크의 수치를 내 블로그 저장소에서 얻은 결과처럼 인용하지 않는다. Graphify 벤치마크 문서
갱신 실패를 일부러 넣어야 운영 가능성을 안다
그래프가 오래된 상태에서도 답변은 나올 수 있다. 이름을 바꾼 함수가 옛 이름으로 검색되거나 삭제한 문서의 설명이 남을 수 있다. 첫 시험에는 파일 이름 변경, 함수 이동, 문서 삭제를 포함한다. 각 변경 뒤에 그래프와 원본이 어느 시점에서 일치하는지 확인한다.
Git 후크를 쓴다면 커밋 이후 작업이 실패했을 때 개발자가 알아차릴 수 있는지도 본다. 후크가 실패해도 커밋은 만들어질 수 있고, GUI와 터미널의 실행 환경도 다를 수 있다. 자동 갱신이라는 문구만 보고 감시를 없애지 않는다. 마지막으로 성공한 인덱스의 커밋과 현재 커밋을 비교하는 표시가 있어야 잘못된 그래프를 계속 읽는 상황을 줄인다.
기존 Git 후크를 덮어쓰지 않는지, 큰 바이너리나 생성 파일을 계속 읽지 않는지도 확인한다. 배포 결과물과 의존성 폴더까지 분석하면 비용이 늘고 검색에 불필요한 관계가 섞인다. 제외 범위는 파일 목록으로 확인한다. 보안 문서를 읽고 민감한 자료를 입력하지 않는 작은 복사본에서 시작하는 편이 맞다. Graphify 보안 안내
첫 시험의 종료 조건을 적어둔다
나는 작은 저장소의 읽기 작업부터 비교하겠다. 그래프 조회를 추가한 뒤 정답 누락이 늘거나 전체 비용이 줄지 않으면 설정을 보완한 뒤 다시 판단한다. 그래프를 사용하는 조건에서도 필요한 원본 파일을 확인하는 단계는 유지한다. 보기 좋은 시각화 때문에 이 단계를 생략하지 않는다.
복구는 시험 전에 준비한다. 에이전트 지침, 후크, 생성 파일을 구분해 어떤 항목을 되돌릴지 목록을 만든다. 도구의 제거 기능을 쓰더라도 실제 바뀐 설정과 비교해야 한다. 원본 코드를 정리한다는 이유로 함께 삭제하지 않는다.
이 시험에서 얻고 싶은 것은 절감률 한 줄보다 질문별 차이다. 직접 이름을 검색하면 끝나는 질문에는 기존 도구가 더 단순할 수 있다. 여러 파일의 관계를 따라가야 하는 질문에서 그래프가 근거를 놓치지 않고 탐색 범위를 줄이는지 확인하면, 적용할 작업과 제외할 작업을 나눌 근거가 생긴다.