C#/.NET 솔루션에 Roslyn 기반의 정확한 코드 지도를 제공하는 aicb

C#/.NET 솔루션에 Roslyn 기반의 정확한 코드 지도를 코딩 에이전트에게 제공합니다. aicb

is C# 및 .NET을 위한 코드 인텔리전스 서버입니다. 호출자, 구현, 의존성 주입(dependency injection), 테스트, 부작용(side effects) 및 변경 영향에 대한 질문에 답한 다음, 관련 코드를 LLM(대규모 언어 모델)이 처리하기 쉽도록 간결한 Markdown으로 패키징합니다. MCP 서버와 CLI로 로컬에서 실행되며, Windows 데스크톱 앱은 시각적 컨텍스트 선택, 분석 및 편집 기능을 추가합니다.

이 소프트웨어는 클로즈드 소스입니다. 이 공개 저장소에는 문서, 라이선스 및 릴리스가 포함되어 있습니다. 개인, 교육 기관 및 라이선스 임계값 이하의 조직에게는 무료입니다.

이 페이지는 간략한 소개이며 참조 문서는 아닙니다. 에이전트가 기본적으로 보는 54개 도구 중 35개를 언급합니다. 세 개의 매뉴얼은 35개의 장으로 구성되어 이 페이지 길이의 약 37배에 달합니다.

코딩 에이전트에게 질문해 보세요:

ColorMixerService를 변경하면 무엇이 영향을 받을 수 있을까요?
AICB를 사용하세요.

또는 터미널에서 동일한 도구를 호출할 수 있습니다:

aicb call impact_of_change --sln C:/repo/App.sln --arg symbol=ColorMixerService

번들된 ColorMixer.SelectionLab의 간략 출력 샘플:

{
"symbol": "ColorMixerService",
"resolvedKind": "type",
...

데스크톱 앱의 MCP 사용(Usage) 페이지는 호출을 로컬에 기록하고, 안내된 거부와 의심되는 결함을 분리합니다:

이 답변은 서브스트링 검색이 아니라 Roslyn 심볼 그래프에서 나옵니다. AICB는 오버로드(overloads)를 구별하고, 인터페이스 및 오버라이드 관계를 추적하며, 부분 타입(partial types)과 DI 구성 경로를 이해합니다.

AICB는 개별 심볼 질문에 답하는 것 이상을 합니다. 필터링되지 않은 소스 덤프를 전송하는 대신, 에이전트를 위한 초점을 맞춘 작업별 컨텍스트 패키지를 조립할 수 있습니다.

포커스 컨텍스트 도구들은 **토큰 예산(token budget)**을 받아, 에이전트가 가질 공간에 맞는 패키지를 구성합니다. 이름 지어진 심볼은 그대로 유지되며, 예산이 빠듯할 경우 블록 중간에서 잘리는 대신 해당 심볼 주변의 상세도가 낮아지며, 어떤 타입, 테스트 또는 형제 요소가 제외되었는지 알려주는 안내 문구가 추가됩니다. 따라서 AICB는 번들(bundle)이 축소되거나 제한되었다고 알려줄 수는 있지만, 남아있는 내용이 작업을 올바르게 해결하기에 충분하다는 것을 보증할 수는 없습니다. 전체 문서 렌더링은 파이프라인 프로파일을 통해 동일한 예산을 사용할 수 있으며, 초과분에 대한 허용치와 어떤 부분이 잘렸는지에 대한 선택적 보고서가 제공됩니다.

그 결과물은 AI-Builder-MD입니다: 심볼 관계, 아키텍처 그래프, 의미론적 메타데이터 및 출처(provenance)와 함께 선택된 코드를 포함하는 LLM용 구조화된 Markdown 형식입니다. 이는 확립된 태그 표기법이나 YAML을 사용할 수 있습니다. 컨텍스트 문서 가이드(context-document guide)와 작업 패킹 도구(task-packing tools)를 참조하십시오.

AICB는 주석 없이 작동합니다. 소스 구조나 관례만으로는 충분하지 않은 경우, 선택적 <ai> 태그를 XML 문서화에 추가하여 개발자가 타입이나 메서드의 의도된 역할을 명시할 수 있습니다:

/// <ai
/// role="service"
/// layer="Application"
...

어노테이션(Annotations)은 역할(role), 도메인(domain), 아키텍처 계층(architectural layer), 우선순위(priority), 안정성(stability), 책임(responsibility), 그리고 부작용(side effects)과 같은 의미론적 정보를 설명할 수 있습니다. 명시적인 값은 휴리스틱 추론보다 우선하며, none과 같은 센티넬(sentinel) 값은 특정 필드에 대한 추론을 의도적으로 억제할 수 있습니다. AICB는 출처를 보존하므로 에이전트가 소스에서 파생된 사실, 작성자가 제공한 의미, 그리고 추론된 힌트를 구별할 수 있습니다. AI 어노테이션 참조(AI annotation reference) 문서는 지원되는 형식과 필드를 기록합니다.

.sln / .slnx / .slnf + C# + XAML/AXAML
↓
MSBuild + Roslyn 의미론적 모델
...

AICB는 단순히 Roslyn 주변의 응답 캐시를 넘어섭니다. 분석 과정에서 솔루션의 C# 문서를 순회하고, 선언(declarations), 호출(calls), 타입 참조(type references) 및 기타 사실들을 기록한 다음, 호출자 및 타입 팬인(fan-in), 구현체(implementations), 해결된 마크업 참조(resolved markup references), 그리고 전이적 부작용 분류(transitive side-effect classifications)를 통합합니다. 도구들은 특정 질문을 위해 이 따뜻하게 준비된 모델(warm model)을 순회하거나 투영하며, 컨텍스트 도구들은 작업별 슬라이스(task-specific slice)를 선택하고 렌더링합니다. 이는 모든 가능한 답변이나 런타임 관계가 미리 계산된다는 것을 의미하지 않습니다.

MCP 세션은 하나의 aicb mcp 프로세스에 속하며, 분석된 그래프와 그 Roslyn 작업 공간(workspace)을 모두 고정합니다. 두 번째 서버 프로세스는 자체 세션을 구축합니다. 데스크톱 앱, CLI 및 MCP 서버는 동일한 분석 및 렌더링 엔진을 사용하고 로컬 데이터베이스를 통해 구성을 공유하고 영속화된 스냅샷을 공유할 수 있지만, 하나의 실시간 인메모리 그래프(live in-memory graph)를 공유하지는 않습니다. 한 세션 내에서는 오직 하나의 새로고침(refresh)만 실행되며, 동시 호출자들(concurrent callers)이 이를 참여합니다. 소스 전용 편집은 증분 경로(incremental path)를 취하여 작업 공간을 다시 로드하는 것 없이 변경된 문서 텍스트를 재연할 수 있습니다. 이 경로가 사용 불가능하거나 force: true가 요청되면, AICB는 완전히 다시 로드합니다.

이러한 상태들은 서로 다른 목적을 가지므로 상호 교환 가능하게 취급되어서는 안 됩니다:

remember_codebase, recall_codebase, 및 refresh_remembered는 옵트인 도구입니다: MCP 프로파일이 이를 노출하므로, 서버를 시작할 때 AICB_MCP_TOOLS로 이름 지정하거나 (AICB_MCP_TOOLS=all) 설정하세요. recall_codebase는 영속화된 모델이 소스, 페이로드 스키마 및 분석기 식별자와 여전히 일치하는지 보고합니다. 이는 의도적으로 재활성화된 모델을 반환하며, 에이전트에게 언제 라이브 재분석이 필요한지를 알려주는 메타데이터를 포함합니다. 세션, 재활성화(recall), 그리고 오래됨(staleness)에 대해 참조하세요.

• AICB는 정적으로 보이는 C# 및 선택된 XAML/AXAML 관계를 분석합니다. 리플렉션(reflection), 런타임 어셈블리 스캐닝(runtime assembly scanning), 동적 구성 또는 외부 소비자를 통해서만 도달하는 코드는 여전히 보이지 않을 수 있습니다.
• DI 분석은 정적으로 읽을 수 있는 Microsoft-DI 형태의 등록 정보를 인식합니다. 런타임에 생성된 등록 정보는 '발명'되었다기보다는 동적 또는 알 수 없는 것으로 공개됩니다.
• XAML 바인딩 분석은 소스 및 데이터 유형이 확립하기에 안전한 경우에만 경로를 해결합니다. 알려지지 않은 범위(scope)는 보수적으로 건너뜁니다.
• 보고된 부작용(side effect)은 알려진 호출 엣지(call edges)를 통해 전파되는 보수적인 정적 접촉 분류입니다. 이는 일반적인 데이터 흐름(data-flow), 오염(taint) 또는 런타임 상태 분석이 아닙니다.
• 응답에는 만료된 세션(stale sessions), 해결되지 않은 프로젝트(unresolved projects) 및 제한된 결과 집합(capped result sets)이 포함됩니다.
  'staleness',
  'incompleteProjects',
  'totalFound'
  및 'truncated'
  을 확인하여 빈 답변이나 짧은 답변을 증거로 취급하는 것을 방지합니다.

AICB 응답은 그 한계와 함께 제공되는 증거입니다. 비어 있거나, 짧거나, 명백히 결정적인 결과에 따라 행동하기 전에 동반되는 신호(signals)를 검사하십시오:

MCP 프로필은 자동 새로고침을 제어합니다. Off는 드리프트(drift)만 공개하고,
Reactive는 읽기 도구가 답변하기 전에 새로고침되며 일반적인 기본 설정입니다. 반면, Proactive는 저장된 편집이 안정화된 후에 분석을 시작합니다. 자동 새로고침은 절대로 저장되지 않은 에디터 버퍼를 볼 수 없습니다. 또한 staleness는 참조 불완전성과도 다릅니다: 전자는 새로고침이 필요하고, 후자는 일반적으로 복원(restore) 또는 빌드 후 강제 새로고침이 필요합니다.

AICB는 또한 unknown과 verified absent를 구별합니다. assert_absence와 같은 도구는 누락된 증거를 거짓 음성(false negative)으로 바꾸기보다는 confirmed, refuted 또는 indeterminate를 반환합니다.

질문 중심 아키텍처(question-first architecture), 제한 사항 및 증거 가이드(limits and evidence guide)는 메모리에 무엇이 존재하는지, 새로 고침 및 컨텍스트 선택이 어떻게 작동하는지, 어떤 클레임이 측정되는지, 그리고 게시된 스케일 벤치마크가 어디에 위치하는지를 설명합니다.

기본 프로필은 이 표의 모든 도구를 노출하지만, 다음 도구들은 제외됩니다:
semantic_diff, diff_review, find_by_concurrency_risk, find_by_resource_leak, find_structural_twins, check_pattern_drift, 그리고 check_doc_drift는 Full Select 프로필이 필요하며, compare_public_api는 옵트인입니다(Tool sets and Agent Skills 참조).

이러한 도구들은 평면적인 검색 카탈로그라기보다는 더 광범위한 역량 맵을 형성합니다:

데스크톱 앱은 코드 품질, 보안, 설계 및 아키텍처 관련 발견 사항을 실행 가능한 검토 큐로 변환합니다:

AICB는 사소하지 않은 C#/.NET 솔루션과 일반 텍스트 검색으로는 신뢰성 있게 답변할 수 없는 시맨틱 질문에 가장 유용합니다. 이는 C#를 분석하며, 선택된 XAML/AXAML 관계가 해당 그래프를 보완합니다. 다른 프로그래밍 언어는 범위 밖에 있습니다.

다중 대상 프로젝트(Multi-targeted projects)는 기본적으로 대상 프레임워크당 한 번 로드되며, 쿼리 표면은 일반적으로 이를 하나의 논리적 프로젝트로 중복 제거합니다. <Solution>.aicb.json에서 analyzePreferredTfmOnly를 설정하면 분석 및 내보내기 작업이 가장 최신 대상 프레임워크 인스턴스로 축소됩니다. 심볼 인벤토리(symbol inventory)는 계속 사용 가능하지만, 다른 대상에만 존재하는 팬인 엣지(fan-in edges)는 사라질 수 있으므로, 이는 투명한 최적화라기보다는 문서화된 정밀도 대 비용의 선택입니다.

에이전트는 도구 카탈로그를 암기하지 않고도 AICB를 사용할 수 있습니다:

• server_info를 호출하여 연결을 확인하고 바이너리 또는 구성 드리프트(drift)를 감지합니다. 전체 역량 맵은 list_skills를 사용하고, 내장 운영 매뉴얼은 docs()를 사용합니다. - prepare_task로 편집 작업을 시작합니다.

이름 지정된 심볼(named symbols), 관련 컨텍스트, 테스트 커버리지 및 잠재적인 형제 구현체들을 하나의 예산 내에서 수집합니다. 다른 코드가 사용하는 심볼을 변경하기 전에 impact_of_change를 호출하십시오.

; use find_tests_for

작업 번들(task bundle)이 충분한 테스트 증거를 제공하지 않을 때 사용합니다. 결과를 빈 값으로 간주하기 전에 불확실성 및 완전성 신호(uncertainty and completeness signals)를 읽으십시오. 모호한 심볼 이름에 대해 질의하고, 불완전한 프로젝트를 복원하며 강제 새로고침하십시오.

• 변경을 수행하고 저장합니다. 그런 다음 get_diagnostics 전에 refresh_session을 호출하십시오.

일반적인 Reactive 프로필에서는 보통 중복적이지만, 모든 모드에서 올바르게 작동하며 의도된 경계를 명확하게 만듭니다. - review_context, evaluate_change_set 또는 verify_claim을 사용하십시오.