코드베이스 탐색 AI가 중요한 코드를 놓칠 때, 흔히 호출 횟수가 많은 함수나 연결이 많은 노드를 우선하는 방식을 의심한다. 그러나 이번 설계 검토에서 확인된 현행 구현은 전역 호출 수나 중심성 순위로 후보를 뽑는 구조가 아니었다. 먼저 이 전제를 바로잡고, 코드의 역할과 확인 가능한 증거를 중심에 두는 재설계안을 제안한다.

핵심은 세 단계다. 역할을 나눠 핵심 구조를 고르고, 선택된 구조 주변에서 제한된 증거를 읽은 뒤, 근거와 미확인 항목을 공유 출처 목록이 담긴 지식 패키지로 전달하는 것이다. 단, 이는 설계 제안이지 검증된 성능 개선 결과는 아니다.

현재 구현에서 확인된 것과 확인되지 않은 것

검토 자료에 따르면 현재 시나리오 A는 호출자가 지정한 필수 정적 증거의 정의를 먼저 확보한 뒤, 후보를 모델 탐색에 맡기고 선택된 코드를 읽어 요약을 요청한다. 로컬에서 모든 함수의 입·출차수나 중심성을 계산해 순위를 매기는 구조는 아니다. 시나리오 B도 그래프 차수가 아니라 질문 단어와 경로·정규화된 이름의 일치도를 사용한다.

또한 추출기가 기록하는 것은 호출 표현식이며, 호출 대상은 미확정으로 남을 수 있다. 따라서 ‘호출이 7,000건 넘는다’는 수치가 있더라도 이를 곧바로 7,000개의 확인된 호출 관계로 해석해서는 안 된다.

현재 설계의 더 분명한 빈틈은 후보 영역과 선택 계약에 있다. 클래스와 함수 정의 중심의 후보 목록만으로는 모듈 최상위 조립 코드나 진입점 보호 블록이 빠질 수 있다. 필수 증거를 미리 확보하는 기능도 호출자가 명시한 정적 선택에는 적용되지만, 의미를 추론해야 하는 항목의 생애주기별 커버리지를 보장하지는 않는다. 역할별 할당량이나 1단계 이웃 확장도 없다.

출처 공유 기능은 이미 일부 존재한다. 그러므로 반복 비용이 얼마나 큰지, 와이어 크기의 주요 원인이 무엇인지는 사실·관계·메타데이터별로 실제 측정해야 한다. 과거 실행 기록과 현재 소스 버전이 연결되지 않은 부분도 있어, 예전의 블록 거부 기록을 현행 코드 경로만으로 설명할 수는 없다.

제안: DAG, RAG, CAG의 책임을 분리한다

제안하는 처리 흐름은 다음과 같다.

권한이 확인된 스냅샷 → AST·바인딩 색인 → 역할 후보와 정적 관계 → 강연결요소를 합친 DAG → 골격 선택 → 1단계 증거 확장 → 로컬 사실 검증 → 선택적 문장 압축 → 출처 참조 압축 → 전체 응답 크기 검사

각 층은 할 일을 넘겨받지 않아야 한다.

층	맡을 일	해서는 안 되는 주장
DAG	확인된 정적 관계를 바탕으로 의존 구조와 순환 영역을 정리	정적 호출 구조가 런타임 실행 순서와 같다고 단정
RAG	요청의 증거 요건과 골격에 맞는 코드 구간을 제한적으로 선택	인접한 코드만으로 임의의 의미를 증명했다고 주장
CAG	검증된 사실과 출처, 미확인 항목을 재사용 가능한 패키지로 구성	서비스가 공급자의 KV 캐시를 직접 제어하거나 적중을 보장한다고 주장

코드 분류와 선택, 출처 검증, 직렬화는 결정론적으로 처리하는 것이 원칙이다. 기존에 허용된 모델 요약을 유지하더라도 모델은 이미 선택된 근거를 표현하고 압축할 뿐, 경로를 고르거나 필수 요건을 바꾸거나 증거 수준을 높여서는 안 된다.

연결 수보다 먼저 볼 것: 역할과 증거

후보를 진입점, 조립·초기화, 상태 조율, 영속성 경계, 예외·자원 경계, 보조 코드 등으로 나누는 방안이다. 역할은 AST와 확인 가능한 바인딩을 근거로 판정한다. 이름이나 파일 경로는 참고 신호일 수 있지만, 그것만으로 핵심 코드라고 확정하지 않는다.

호출 관계도 먼저 안전하게 해석해야 한다. 같은 이름의 함수가 있다는 이유만으로 호출 대상으로 연결하지 않고, 스코프와 재할당, import 별칭 등을 확인할 수 있는 경우에만 확정 관계로 취급한다. 동적 import, 리플렉션, 복잡한 별칭이나 불명확한 상속 디스패치는 미확인으로 남긴다. 확인되지 않은 표현식은 기록하되 확정된 간선처럼 사용하지 않는다.

호출 그래프에는 순환이 생길 수 있으므로 원래 그래프 자체를 DAG라고 부를 수는 없다. 먼저 강연결요소를 하나의 묶음으로 합쳐 응축 그래프를 만들고, 그 그래프를 위상 정렬한다. 이 순서는 정적 의존관계의 정리 방식이지, 프로그램이 실제로 반드시 그 순서대로 동작한다는 뜻은 아니다.

중심성은 역할과 구조 신호가 같은 후보 사이에서만 보조 점수로 쓸 수 있다. 중복 호출은 서로 다른 이웃 수를 늘리지 않게 하고, 차수가 커질수록 점수 증가를 완만하게 제한한다. 무엇보다 연결이 많다는 이유로 보조 코드가 진입점이나 저장 경계를 밀어내지 않도록 역할별 선택을 먼저 분리한다.

블록 수와 본문 예산을 함께 제한

설계안은 기본적으로 골격 최대 16블록, 맥락 최대 12블록, 예외·자원 경계 최대 4블록으로 나눈다. 전체는 최대 32블록, 본문 합계 96KiB를 넘지 않는다. 맥락 후보가 골격용 자리를 가져갈 수 없도록 각 통로의 할당량을 별도로 관리한다.

다만 역할마다 똑같이 네 블록씩 배정하는 식의 고정 규칙은 적절하지 않다. 필수 증거를 먼저 배치한 뒤 아직 대표가 없는 역할과 구성요소를 차례로 보완하는 편이 낫다. 필수 증거 그룹이 할당량이나 본문 예산에 들어가지 않으면 몰래 다른 통로에 끼워 넣거나 요건을 낮추지 않고, 미해결 또는 차단 상태로 보고해야 한다.

코드 구간은 완전한 함수·메서드, 모듈 최상위 문장, 필요한 경우의 완전한 클래스처럼 문법적으로 온전한 단위여야 한다. 장식자, 조건문, 예외 처리와 같은 구조를 잘라 의미가 달라지게 해서는 안 된다. 클래스 전체와 그 안의 여러 메서드를 동시에 넣을 때는 중복을 계산하고, 이미 읽은 본문을 출처 별칭으로 표시하더라도 읽지 않은 내용을 읽은 것처럼 취급하지 않아야 한다.

골격 선택이 끝난 뒤에는 그 골격의 확인된 정적 이웃만 한 단계 확장한다. 첫 확장으로 들어온 코드가 다시 다음 확장의 출발점이 되지 않게 해 범위가 연쇄적으로 불어나지 않도록 한다. 파일별 확장 블록 수에도 상한을 둘 수 있지만, 필수 증거를 같은 파일에서 읽는 경우까지 막아서는 안 된다.

응답 크기는 안쪽 JSON이 아니라 전체 프레임으로 잰다

24KiB는 24,576바이트다. 22KiB는 22,528바이트이므로 두 값의 차이는 2,048바이트다. 최소 2.5KiB의 여유 공간을 남기려면 통상 응답을 22,016바이트, 즉 21.5KiB 이하로 잡아야 한다.

크기 검사는 요약 본문만이 아니라 JSON-RPC 봉투, 이스케이프, 응답 ID와 끝의 줄바꿈까지 포함한 실제 전송 바이트를 대상으로 해야 한다. 검사한 바이트와 전송하는 바이트도 같아야 한다. 필수 내용과 출처 참조를 먼저 넣고, 선택 항목은 참조 관계가 닫힌 상태로 더했을 때 한도를 지키는 경우에만 추가한다. 최소 오류 응답조차 호출자 예산에 들어가지 않으면 한도를 넘어 보내지 말고 실패를 명시해야 한다.

출처를 공유하는 패키지는 재사용성을 높일 수 있지만, 캐시 적중을 보장하진 않는다

지식 패키지는 파일과 해시를 한 번만 기록하고, 출처 표에서 파일·기호·범위를 정의하며, 사실과 관계는 출처 번호를 참조하도록 구성할 수 있다. 모든 항목에 같은 경로와 메타데이터를 되풀이하는 방식보다 간결할 가능성이 있지만, 실제 절감량은 완성된 프레임을 측정해야 알 수 있다. 데이터가 작거나 중복이 적으면 공유 표의 고정 비용 때문에 오히려 커질 수도 있다.

안정적인 지식 패키지와 요청별 정보를 분리하는 것도 중요하다. 프로젝트 스냅샷, 알고리즘·정책 버전, 정규화된 사실과 출처는 재사용 가능한 접두부에 두고, 요청 ID나 실행 시간처럼 매번 달라지는 정보는 분리한다. 권한, 코드 스냅샷, 정책이 달라지면 캐시 키도 무효화해야 한다.

CAG는 외부 지식을 미리 불러와 재사용 가능한 KV 캐시에 두는 접근으로 설명된다.1 하지만 그 개념만으로 현재 서비스나 공급자 환경에서 캐시 적중, 비용 절감, 지연시간 개선이 입증되는 것은 아니다. 공급자별 캐시 동작과 실제 사용량은 소비자 측 기록으로 별도 검증해야 한다. 미리 만든 골격으로 모든 질문을 해결할 수 있다고 보는 대신, 더 깊은 내용이 필요하면 RAG로 추가 근거를 찾아야 한다.

관련 연구도 설계 원칙을 참고하는 수준에서 읽어야 한다. Codebase-Memory는 Tree-sitter 기반 지식 그래프를 제시하고,10 Reliable Graph-RAG for Codebases는 AST 기반 그래프와 LLM 추출 지식 그래프를 비교하는 연구다.11 다만 이번 검토 자료로는 ‘30~60배’, ‘정확도 95.5%’, ‘누락률 0%’ 같은 구체적 성능 수치를 원문 실험 조건과 함께 확인할 수 없었다. 따라서 이 수치들을 현재 프로젝트의 성능 약속으로 옮겨서는 안 된다.

13개 항목 완전 포착은 조건부다

예산과 증거 보존에 관한 일부 속성은 테스트로 확인할 수 있다. 예를 들어 블록 수가 32개를 넘지 않고, 본문 합계가 96KiB 이하이며, 맥락 후보가 골격 자리를 빼앗지 않는지 검증할 수 있다. 중복 호출이 차수를 부풀리지 않는지, 모든 인용이 실제로 읽고 신원을 확인한 출처를 가리키는지도 확인 대상이다.

그러나 이것이 임의의 코드 사실을 모두 이해했다는 증명은 아니다. 13개 평가 항목마다 선택 가능한 완전한 증거 그룹이 존재하고, 그 그룹들이 할당량과 예산에 들어가며, 선택기가 실제로 이를 골라야 한다. 출처 검증기도 새 문법 단위를 지원해야 한다. 모든 조건이 맞을 때에만 13개 항목의 본문 커버리지를 기대할 수 있다.

특히 13개 항목이 서로 다른 골격 블록 하나씩만 요구한다면, 16개 골격 한도 안에 들어갈 수 있다는 계산은 가능하다. 하지만 각 항목이 실제로 한 블록으로 충분한지, 분류기가 숨은 평가 항목을 선택할 수 있는지는 별도의 문제다. 이번 작업에서는 고정된 평가 답안을 다시 읽거나 검증을 실행하지 않았다. 따라서 13/13 통과, 의미적 정답성, 실제 호스트 환경의 성공은 확인되지 않았다.

지금의 결과와 다음 단계

이번 결과물은 읽기 전용 설계 검토다. 서비스나 게이트웨이를 수정하지 않았고, 테스트·수락 검증·모델 호출도 하지 않았다. 다음 단계에서는 새 데이터 구조와 선택 규칙을 버전이 명시된 계약으로 도입하고, 기존 호출자와 응답 형식의 의미를 조용히 바꾸지 않아야 한다.

검증에는 중복 호출이 많은 경우, 단일 파일·복수 진입점, 동적 호출과 이름 가림, 부모·자식 구간 중복, 비ASCII 문자가 포함된 전체 프레임 크기 경계, 필수 증거 부족, 스냅샷 변경에 따른 캐시 무효화가 포함돼야 한다. 제한 시간도 분석뿐 아니라 출처 재확인, 저장, 직렬화와 전송까지 포함해 점검해야 한다.

결국 목표는 ‘연결이 많아 보이는 코드’를 더 잘 고르는 것이 아니다. 무엇을 필수 증거로 삼았는지, 무엇을 실제로 읽었는지, 어떤 한계 때문에 모르는지를 끝까지 추적할 수 있는 선택·검증·전달 체계를 만드는 데 있다.

코드베이스 탐색 AI가 중요한 코드를 놓칠 때, 흔히 호출 횟수가 많은 함수나 연결이 많은 노드를 우선하는 방식을 의심한다. 그러나 이번 설계 검토에서 확인된 현행 구현은 전역 호출 수나 중심성 순위로 후보를 뽑는 구조가 아니었다. 먼저 이 전제를 바로잡고, 코드의 역할과 확인 가능한 증거를 중심에 두는 재설계안을 제안한다.

핵심은 세 단계다. 역할을 나눠 핵심 구조를 고르고, 선택된 구조 주변에서 제한된 증거를 읽은 뒤, 근거와 미확인 항목을 공유 출처 목록이 담긴 지식 패키지로 전달하는 것이다. 단, 이는 설계 제안이지 검증된 성능 개선 결과는 아니다.

현재 구현에서 확인된 것과 확인되지 않은 것

검토 자료에 따르면 현재 시나리오 A는 호출자가 지정한 필수 정적 증거의 정의를 먼저 확보한 뒤, 후보를 모델 탐색에 맡기고 선택된 코드를 읽어 요약을 요청한다. 로컬에서 모든 함수의 입·출차수나 중심성을 계산해 순위를 매기는 구조는 아니다. 시나리오 B도 그래프 차수가 아니라 질문 단어와 경로·정규화된 이름의 일치도를 사용한다.

또한 추출기가 기록하는 것은 호출 표현식이며, 호출 대상은 미확정으로 남을 수 있다. 따라서 ‘호출이 7,000건 넘는다’는 수치가 있더라도 이를 곧바로 7,000개의 확인된 호출 관계로 해석해서는 안 된다.

현재 설계의 더 분명한 빈틈은 후보 영역과 선택 계약에 있다. 클래스와 함수 정의 중심의 후보 목록만으로는 모듈 최상위 조립 코드나 진입점 보호 블록이 빠질 수 있다. 필수 증거를 미리 확보하는 기능도 호출자가 명시한 정적 선택에는 적용되지만, 의미를 추론해야 하는 항목의 생애주기별 커버리지를 보장하지는 않는다. 역할별 할당량이나 1단계 이웃 확장도 없다.

출처 공유 기능은 이미 일부 존재한다. 그러므로 반복 비용이 얼마나 큰지, 와이어 크기의 주요 원인이 무엇인지는 사실·관계·메타데이터별로 실제 측정해야 한다. 과거 실행 기록과 현재 소스 버전이 연결되지 않은 부분도 있어, 예전의 블록 거부 기록을 현행 코드 경로만으로 설명할 수는 없다.

제안: DAG, RAG, CAG의 책임을 분리한다

제안하는 처리 흐름은 다음과 같다.

권한이 확인된 스냅샷 → AST·바인딩 색인 → 역할 후보와 정적 관계 → 강연결요소를 합친 DAG → 골격 선택 → 1단계 증거 확장 → 로컬 사실 검증 → 선택적 문장 압축 → 출처 참조 압축 → 전체 응답 크기 검사

각 층은 할 일을 넘겨받지 않아야 한다.

층	맡을 일	해서는 안 되는 주장
DAG	확인된 정적 관계를 바탕으로 의존 구조와 순환 영역을 정리	정적 호출 구조가 런타임 실행 순서와 같다고 단정
RAG	요청의 증거 요건과 골격에 맞는 코드 구간을 제한적으로 선택	인접한 코드만으로 임의의 의미를 증명했다고 주장
CAG	검증된 사실과 출처, 미확인 항목을 재사용 가능한 패키지로 구성	서비스가 공급자의 KV 캐시를 직접 제어하거나 적중을 보장한다고 주장

코드 분류와 선택, 출처 검증, 직렬화는 결정론적으로 처리하는 것이 원칙이다. 기존에 허용된 모델 요약을 유지하더라도 모델은 이미 선택된 근거를 표현하고 압축할 뿐, 경로를 고르거나 필수 요건을 바꾸거나 증거 수준을 높여서는 안 된다.

연결 수보다 먼저 볼 것: 역할과 증거

후보를 진입점, 조립·초기화, 상태 조율, 영속성 경계, 예외·자원 경계, 보조 코드 등으로 나누는 방안이다. 역할은 AST와 확인 가능한 바인딩을 근거로 판정한다. 이름이나 파일 경로는 참고 신호일 수 있지만, 그것만으로 핵심 코드라고 확정하지 않는다.

호출 관계도 먼저 안전하게 해석해야 한다. 같은 이름의 함수가 있다는 이유만으로 호출 대상으로 연결하지 않고, 스코프와 재할당, import 별칭 등을 확인할 수 있는 경우에만 확정 관계로 취급한다. 동적 import, 리플렉션, 복잡한 별칭이나 불명확한 상속 디스패치는 미확인으로 남긴다. 확인되지 않은 표현식은 기록하되 확정된 간선처럼 사용하지 않는다.

호출 그래프에는 순환이 생길 수 있으므로 원래 그래프 자체를 DAG라고 부를 수는 없다. 먼저 강연결요소를 하나의 묶음으로 합쳐 응축 그래프를 만들고, 그 그래프를 위상 정렬한다. 이 순서는 정적 의존관계의 정리 방식이지, 프로그램이 실제로 반드시 그 순서대로 동작한다는 뜻은 아니다.

중심성은 역할과 구조 신호가 같은 후보 사이에서만 보조 점수로 쓸 수 있다. 중복 호출은 서로 다른 이웃 수를 늘리지 않게 하고, 차수가 커질수록 점수 증가를 완만하게 제한한다. 무엇보다 연결이 많다는 이유로 보조 코드가 진입점이나 저장 경계를 밀어내지 않도록 역할별 선택을 먼저 분리한다.

블록 수와 본문 예산을 함께 제한

설계안은 기본적으로 골격 최대 16블록, 맥락 최대 12블록, 예외·자원 경계 최대 4블록으로 나눈다. 전체는 최대 32블록, 본문 합계 96KiB를 넘지 않는다. 맥락 후보가 골격용 자리를 가져갈 수 없도록 각 통로의 할당량을 별도로 관리한다.

다만 역할마다 똑같이 네 블록씩 배정하는 식의 고정 규칙은 적절하지 않다. 필수 증거를 먼저 배치한 뒤 아직 대표가 없는 역할과 구성요소를 차례로 보완하는 편이 낫다. 필수 증거 그룹이 할당량이나 본문 예산에 들어가지 않으면 몰래 다른 통로에 끼워 넣거나 요건을 낮추지 않고, 미해결 또는 차단 상태로 보고해야 한다.

코드 구간은 완전한 함수·메서드, 모듈 최상위 문장, 필요한 경우의 완전한 클래스처럼 문법적으로 온전한 단위여야 한다. 장식자, 조건문, 예외 처리와 같은 구조를 잘라 의미가 달라지게 해서는 안 된다. 클래스 전체와 그 안의 여러 메서드를 동시에 넣을 때는 중복을 계산하고, 이미 읽은 본문을 출처 별칭으로 표시하더라도 읽지 않은 내용을 읽은 것처럼 취급하지 않아야 한다.

골격 선택이 끝난 뒤에는 그 골격의 확인된 정적 이웃만 한 단계 확장한다. 첫 확장으로 들어온 코드가 다시 다음 확장의 출발점이 되지 않게 해 범위가 연쇄적으로 불어나지 않도록 한다. 파일별 확장 블록 수에도 상한을 둘 수 있지만, 필수 증거를 같은 파일에서 읽는 경우까지 막아서는 안 된다.

응답 크기는 안쪽 JSON이 아니라 전체 프레임으로 잰다

24KiB는 24,576바이트다. 22KiB는 22,528바이트이므로 두 값의 차이는 2,048바이트다. 최소 2.5KiB의 여유 공간을 남기려면 통상 응답을 22,016바이트, 즉 21.5KiB 이하로 잡아야 한다.

크기 검사는 요약 본문만이 아니라 JSON-RPC 봉투, 이스케이프, 응답 ID와 끝의 줄바꿈까지 포함한 실제 전송 바이트를 대상으로 해야 한다. 검사한 바이트와 전송하는 바이트도 같아야 한다. 필수 내용과 출처 참조를 먼저 넣고, 선택 항목은 참조 관계가 닫힌 상태로 더했을 때 한도를 지키는 경우에만 추가한다. 최소 오류 응답조차 호출자 예산에 들어가지 않으면 한도를 넘어 보내지 말고 실패를 명시해야 한다.

출처를 공유하는 패키지는 재사용성을 높일 수 있지만, 캐시 적중을 보장하진 않는다

지식 패키지는 파일과 해시를 한 번만 기록하고, 출처 표에서 파일·기호·범위를 정의하며, 사실과 관계는 출처 번호를 참조하도록 구성할 수 있다. 모든 항목에 같은 경로와 메타데이터를 되풀이하는 방식보다 간결할 가능성이 있지만, 실제 절감량은 완성된 프레임을 측정해야 알 수 있다. 데이터가 작거나 중복이 적으면 공유 표의 고정 비용 때문에 오히려 커질 수도 있다.

안정적인 지식 패키지와 요청별 정보를 분리하는 것도 중요하다. 프로젝트 스냅샷, 알고리즘·정책 버전, 정규화된 사실과 출처는 재사용 가능한 접두부에 두고, 요청 ID나 실행 시간처럼 매번 달라지는 정보는 분리한다. 권한, 코드 스냅샷, 정책이 달라지면 캐시 키도 무효화해야 한다.

CAG는 외부 지식을 미리 불러와 재사용 가능한 KV 캐시에 두는 접근으로 설명된다.1 하지만 그 개념만으로 현재 서비스나 공급자 환경에서 캐시 적중, 비용 절감, 지연시간 개선이 입증되는 것은 아니다. 공급자별 캐시 동작과 실제 사용량은 소비자 측 기록으로 별도 검증해야 한다. 미리 만든 골격으로 모든 질문을 해결할 수 있다고 보는 대신, 더 깊은 내용이 필요하면 RAG로 추가 근거를 찾아야 한다.

관련 연구도 설계 원칙을 참고하는 수준에서 읽어야 한다. Codebase-Memory는 Tree-sitter 기반 지식 그래프를 제시하고,10 Reliable Graph-RAG for Codebases는 AST 기반 그래프와 LLM 추출 지식 그래프를 비교하는 연구다.11 다만 이번 검토 자료로는 ‘30~60배’, ‘정확도 95.5%’, ‘누락률 0%’ 같은 구체적 성능 수치를 원문 실험 조건과 함께 확인할 수 없었다. 따라서 이 수치들을 현재 프로젝트의 성능 약속으로 옮겨서는 안 된다.

13개 항목 완전 포착은 조건부다

예산과 증거 보존에 관한 일부 속성은 테스트로 확인할 수 있다. 예를 들어 블록 수가 32개를 넘지 않고, 본문 합계가 96KiB 이하이며, 맥락 후보가 골격 자리를 빼앗지 않는지 검증할 수 있다. 중복 호출이 차수를 부풀리지 않는지, 모든 인용이 실제로 읽고 신원을 확인한 출처를 가리키는지도 확인 대상이다.

그러나 이것이 임의의 코드 사실을 모두 이해했다는 증명은 아니다. 13개 평가 항목마다 선택 가능한 완전한 증거 그룹이 존재하고, 그 그룹들이 할당량과 예산에 들어가며, 선택기가 실제로 이를 골라야 한다. 출처 검증기도 새 문법 단위를 지원해야 한다. 모든 조건이 맞을 때에만 13개 항목의 본문 커버리지를 기대할 수 있다.

특히 13개 항목이 서로 다른 골격 블록 하나씩만 요구한다면, 16개 골격 한도 안에 들어갈 수 있다는 계산은 가능하다. 하지만 각 항목이 실제로 한 블록으로 충분한지, 분류기가 숨은 평가 항목을 선택할 수 있는지는 별도의 문제다. 이번 작업에서는 고정된 평가 답안을 다시 읽거나 검증을 실행하지 않았다. 따라서 13/13 통과, 의미적 정답성, 실제 호스트 환경의 성공은 확인되지 않았다.

지금의 결과와 다음 단계

이번 결과물은 읽기 전용 설계 검토다. 서비스나 게이트웨이를 수정하지 않았고, 테스트·수락 검증·모델 호출도 하지 않았다. 다음 단계에서는 새 데이터 구조와 선택 규칙을 버전이 명시된 계약으로 도입하고, 기존 호출자와 응답 형식의 의미를 조용히 바꾸지 않아야 한다.

검증에는 중복 호출이 많은 경우, 단일 파일·복수 진입점, 동적 호출과 이름 가림, 부모·자식 구간 중복, 비ASCII 문자가 포함된 전체 프레임 크기 경계, 필수 증거 부족, 스냅샷 변경에 따른 캐시 무효화가 포함돼야 한다. 제한 시간도 분석뿐 아니라 출처 재확인, 저장, 직렬화와 전송까지 포함해 점검해야 한다.

결국 목표는 ‘연결이 많아 보이는 코드’를 더 잘 고르는 것이 아니다. 무엇을 필수 증거로 삼았는지, 무엇을 실제로 읽었는지, 어떤 한계 때문에 모르는지를 끝까지 추적할 수 있는 선택·검증·전달 체계를 만드는 데 있다.