한국어

0.9 지원 언어 실전 점검

2026-10-16 로컬 점검의 기준은 Java·TypeScript·JavaScript 프로젝트에서 AI가 구조를 파악하고, 정확한 원문을 읽고, 변경 영향을 판단하는 데 도움이 되는가입니다. 모든 언어를 지원하거나 모든 도구를 대체하는 것을 완료 조건으로 삼지 않았습니다.

세 프로젝트로 확인한 범위

프로젝트	분석 범위와 결과
주문 예제	Java 컨트롤러·서비스와 JavaScript import, 7개 파일·11개 선언. 오버로드와 함수 원문, 파일 추가·이름 변경·삭제·의존 대상 변경을 시험했습니다.
Ghostfolio	`f6b25eec05312a3cda466e00323b94f39c8f5a5f`의 NestJS API·Angular 클라이언트. 760개 파일·2,477개 선언, 디렉터리 깊이 5에서 86개 묶음·280개 의존 관계 묶음을 확인했습니다.
Cascade 자신	Java 분석기와 코어·CLI·뷰어·TS/웹 어댑터·스크립트의 JavaScript. 확대 후 확인한 세대에서 287개 파일·5,850개 선언, 12개 디렉터리 묶음·30개 의존 관계 묶음을 확인했습니다.

전체 저장소가 아닌 선택한 분석 입력의 수치입니다. Ghostfolio는 소스에서 확인한 접두어 예외 설정을 명시한 데모입니다. 예외를 모두 자동 추론했다고 주장하지 않습니다.

앞의 두 프로젝트는 같은 소스를 설치된 codebase-memory MCP에도 분석시켰습니다. 관련 검색 페이지와 분석 범위를 확인하고, 중요한 답은 실제 소스와 대조했습니다. 비교 도구 버전은 고정하지 않았으므로 모든 버전에 적용되는 결과는 아닙니다. 비교 도구의 Ghostfolio 전체 인덱스에는 부분 분석 파일 60개가 있었지만, 이번 비교에 사용한 account 서비스·컨트롤러는 메타데이터가 일치하고 기록된 분석 범위 문제가 없었습니다.

확인한 강점

Java 선언과 원문: 생성자, findOrder(String), findOrder(long)을 각각 구분했습니다. 비교 인덱스는 이 예제의 마지막 오버로드 하나만 남겼습니다.
정확한 원문 범위: 한 줄에 두 함수가 있고 Unicode 문자가 있어도 요청한 함수만 반환했습니다. 비교 도구는 이 사례에서 이웃 포함 옵션을 꺼도 두 함수를 반환했습니다. Ghostfolio에서 골라 본 세 메서드의 원문은 양쪽 모두 확인했습니다.
저장 후 갱신: 주문 예제의 JavaScript 파일을 추가·이름 변경·삭제하고 import 대상을 바꾼 뒤 첫 조회에서 갱신을 확인했습니다. 비교 도구의 짧은 관찰 구간에서는 이전 답이 남았지만 분석 범위 API는 변경을 감지했습니다. 감시 설정을 동일하게 맞추지 않았으므로 상대 도구가 자동 갱신을 못 한다는 결론은 아닙니다.
NestJS와 Prisma: 컨트롤러에서 주입된 서비스로 이어지는 연결을 확인했습니다. POST /api/v1/account에서 Account·TagsOnAccounts·AccountBalance·Tag까지 SOUND_SET 근거와 함께 이어졌습니다. 구조 파악 다음에 데이터 변경 영향을 볼 수 있습니다.

점검 중 고친 문제와 남은 한계

일반 JavaScript의 직접 import 호출 orderLabel → formatMoney가 처음에는 빠져 있었습니다. 기존 파서의 바인딩 근거로 별도 구조 관계인 references-call을 추가하고 서버에서 다시 확인했습니다. 영향도 그래프의 등급을 올리거나 실행을 보장하는 관계로 바꾸지는 않았습니다.

Ghostfolio의 기본 디렉터리 깊이 2는 API 내부를 한 묶음으로 모읍니다. 화면에서 깊이 5를 선택하면 내부 모듈 연결을 보기 좋습니다. 미확인 관계 4,216개는 여러 종류의 참조를 합친 수이며, 호출 4,216개가 빠졌다는 뜻은 아닙니다.

초기 비교에서 양쪽 모두 놓쳤던 array.map(orderLabel)은 이제 Cascade에서 콜백 인자로 전달된 참조로 표시합니다. 로컬 함수와 변경되지 않는 별칭도 연결하며, 콜백의 실제 실행은 단정하지 않습니다. code_trace는 중간 선언을 포함한 호출 관계를 조회하고, 호출자·호출 대상 방향을 섞지 않습니다. 동적·멤버 호출과 재수출 경로 등은 여전히 미확인으로 남습니다. 영향도 flow는 별도 용도입니다.

2초마다 전체 파일 내용을 확인하던 유휴 비용도 발견했습니다. 세 프로젝트가 바뀌지 않은 20초 구간에서 CPU 한 코어의 32.93%를 사용했습니다. 서버의 실제 설정까지 포함해 기본 주기를 30초로 바꿨고, 조회 시 내용 검증은 유지했습니다. 한 번의 검사에서 중복된 파일 읽기는 제거했습니다. 전체 내용 해시 비용과 무관한 문서 수정으로 분석이 실행되는 점은 여전히 남습니다. 다른 도구보다 빠르다거나 토큰을 몇 배 절약한다고 주장할 수 있는 동일 조건 측정은 하지 않았습니다. 실제 30초 주기 적용 후 동일한 로컬 입력의 35초 구간에서는 CPU 한 코어의 2.06%를 사용했습니다. 두 구간 모두 당시 아직 제외하지 않은 데모 산출물도 파일 목록에 포함됐으며, 이후 산출물은 로컬에서 제외했습니다. 이 수치는 관찰한 데모 환경의 변화이고 일반 저장소 성능 보장은 아닙니다.

세 프로젝트의 브리핑은 모두 12,288바이트 답변 예산 안에 들어왔고, 원문은 실제 UTF-16 범위와 파일 해시를 대조했습니다. 편집기에 저장하지 않은 내용은 대상이 아닙니다.

판단과 직접 확인 방법

실제 stdio MCP 프로세스에서도 초기화·알림·초기 25개 도구 목록을 확인하고 세 프로젝트의 브리핑·구조·검색·선언·정확한 원문·문맥·상태 조회를 검증했습니다. Ghostfolio는 85회 응답에 걸쳐 구조 목록의 페이지를 모두 확인했습니다. 다중 프로젝트에서 프로젝트를 잘못 지정하거나 생략하면 명시적으로 실패했습니다. 주문 예제는 파일 추가·이름 변경· import 대상 변경·삭제 직후 첫 MCP 조회에서 갱신됐습니다. --no-watch 연결에서는 최신성을 알 수 없음으로 표시하고, 변경된 파일의 원문을 stale-source로 거절했습니다. 연결 종료 시 대기 응답과 정상 종료도 확인했으며, 시험한 소스는 정확히 복원했습니다. 웹 API만 시험한 결과가 아니며, 모든 외부 AI 클라이언트 앱을 연결해 보았다는 뜻도 아닙니다.

에이전트에게 실제로 “계좌 생성의 초기 잔고 처리를 바꾸려면 어디를 수정해야 하는가”를 MCP로 조사시켰습니다. 전체 저장소 검색 없이 서비스·DTO·컨트롤러·공유 upsert·import 호출부를 찾아 API 2개와 테이블 4개의 영향 근거를 연결하고, 회귀 확인 항목까지 제시했습니다. 반환된 원문 5개를 소스와 대조했습니다. 수정 계획을 세운 시험이며 Ghostfolio를 수정하거나 애플리케이션 테스트를 실행한 것은 아닙니다.

이 작업의 도구 호출은 11회, 근거와 한계를 포함한 응답 텍스트는 111,399바이트였습니다. 도구 목록은 별도로 44,731바이트였습니다. 그중 상위 영향 추적 하나가 45,234바이트로 컸고 프런트엔드까지의 경로가 반복됐습니다. 이 문제를 확인한 뒤 압축 응답과 도구 설명 축약을 추가했습니다. 토큰 수나 상대 도구 대비 절약률로 환산하지 않았습니다. 같은 상위 영향 질문을 limit: 2로 좁혀 다시 물었을 때 필요한 API는 2/2개 모두 유지됐고 응답은 15,933바이트였습니다. 서비스 2/5개·프런트엔드 함수 2/8개라는 생략 표시도 남았습니다. 작은 목록 제한에서 시작하고 실제 필요한 영역의 생략 수와 다음 페이지를 확인하는 사용법이 효과적입니다. 축약된 답을 전체 영향이라고 오해하면 안 되며, 이 추가 시험은 앞의 11회 호출 합계와 별도입니다.

릴리스 전 같은 Ghostfolio 상위 영향 질문을 실제 MCP로 다시 비교했습니다. 전체 응답 45,248바이트가 압축 응답 20,685바이트로 줄었고, 공유 근거를 다시 펼쳐 모든 원래 경로·행·등급이 일치하는지 확인했습니다. 8,192바이트 답변 예산은 7,464바이트의 답변과 명시적인 행 생략 정보를 반환했습니다. code_trace를 포함한 최종 26개 도구 목록은 32,915바이트였습니다. 이번 응답의 직렬화 크기 비교입니다.

별도 실제 코딩 과제로, 생성된 MCP 설정이 사용자 지정 저장소 경로를 잃는 버그를 Cascade MCP로 찾아 재현하고 수정했습니다. JSON과 Codex TOML에 절대 경로의 CASCADE_HOME을 보존하며, 생성된 설정을 다른 환경에서 실행하는 테스트를 포함해 CLI 테스트 9개가 통과했습니다. 수정 후 MCP 원문 해시도 실제 파일과 일치했습니다. 도구 호출 10회와 초기화 등 총 14개 요청의 응답은 106,340바이트였습니다. 영향도는 해당 CLI·코어 파일에 readNoFacts를 보고했으므로, 실제 동작 테스트로 검증했습니다. 빈 영향도 결과를 안전하다는 뜻으로 해석하지 않았습니다.

독립 검토에서 양방향 탐색에 무관한 형제 호출자가 섞이는 문제, 오버로드 모호성, 기본 인자·switch의 변수 범위, 기본 export와 타입 전용 export, 캐시 재조립의 순서 차이도 수정하고 실제 파서 회귀 테스트를 추가했습니다.

같은 입력의 해시 검사를 3회씩 측정한 Ghostfolio에서는 중복 읽기 제거 전후 읽은 양이 53.47MB→29.13MB, 중앙 실행 시간이 299ms→224ms였습니다. 매번 새 검사는 저장된 내용을 다시 읽습니다. 문서 변경을 안전하게 제외하려면 설정·탐색 실패까지 포함한 전체 분석 입력 목록이 필요하므로 그 최적화는 남겨 두었습니다. 최신성 검증을 약하게 만들어 속도 수치를 높이지 않았습니다.

테스트한 지원 스택에서는 구조 파악부터 서비스·DB 변경 영향까지 이어지는 주 도구로 활용할 근거가 있습니다. 정확한 선언·원문과 최신성 표시를 함께 제공하는 점이 강점입니다. 세 프로젝트의 결과가 모든 프레임워크의 완전성을 보장하지는 않습니다.

직접 확인 가이드의 브리핑 → 모듈 연결 → 선언·원문 → 저장 후 갱신 순서로 확인하세요. 새 프로젝트에서는 먼저 분석 경로와 미확인 관계를 확인하고, 실제로 바꿀 함수의 원문과 영향 경로를 대조하는 방식이 적합합니다.