다형성 에이전트: 언어 인지 지능이 특정 언어 도구보다 우월한 이유

요약 (TL;DR)

대규모 프로덕션 시스템은 다국어(polyglot) 환경입니다. 기업에서 Java 서비스, Python 파이프라인, Go API, Ruby on Rails 프런트엔드, C++ 처리 엔진, SQL 저장 프로시저, Bash 자동화 스크립트, 그리고 독점 DSL을 보유하고 있으며, 이들이 수백만 줄의 코드를 가로질러 복잡하게 얽혀 있고, 시간이 흐르면서 여러 팀에 의해 구축되는 것은 이상한 일이 아닙니다. 하지만 현재 시장의 대부분 AI 코드 인텔리전스 도구들은 하나의 언어나 하나의 패러다임만을 위해 구축되었으며, 나머지 모든 것을 미래 로드맵 항목으로 취급합니다. CoreStory는 근본적으로 다른 접근 방식을 취합니다: 자신이 마주치는 언어, 구조, 그리고 문맥에 따라 추론 전략, 도구 선택, 분석 기술을 동적으로 적응시키는 다형성 에이전트(polymorphic agents)입니다. 그 결과는 모든 언어를 네이티브하게 지원하고, 시스템 경계를 가로질러 추적하며, 결정론적 발견과 추론된 발견을 구별하고, 새로운 언어를 배울 때마다 더 똑똑해지는 아키텍처를 구현합니다.

대규모 프로덕션 시스템은 단일 언어 문제가 아니다

대규모로 시스템을 운영하는 어떤 엔지니어링 조직에 가도 깔끔하게 정리된 단일 언어 코드베이스는 찾을 수 없을 것입니다. 대신, 여러 해에 걸쳐 구축된 계층적 생태계를 발견할 것입니다: 핵심 비즈니스 로직을 처리하는 Java 마이크로서비스, 데이터 파이프라인과 ML 추론(inference)에 동력을 공급하는 Python, 고처리량 API를 실행하는 Go, 고객 대면 제품을 제공하는 Ruby on Rails, 성능이 중요한 처리에 내장된 C++, 수십 년간의 비즈니스 규칙을 캡슐화한 SQL 저장 프로시저, 그리고 운영상의 접착제 역할을 하는 Bash 스크립트 등이 그것입니다.

일반적인 기업 프로덕션 시스템은 최소 여섯 개에서 열 개의 서로 다른 언어가 수천 개의 컴포넌트에 걸쳐 교차되어 있습니다. 이러한 다국어(polyglot) 현실은 예외적인 경우가 아닙니다. 이는 각기 다른 시점에, 각기 다른 팀이, 각기 다른 이유로 내린 기술 선택의 불가피한 결과이며—이 모든 것이 여전히 프로덕션에서 함께 작동해야 합니다.

하지만 코드 인텔리전스 (code intelligence) 도구 시장은 역사적으로 고립된 언어나 패러다임에 집중해 왔으며, 교차 언어 분석 (cross-language analysis)을 기본 요구 사항이 아닌 고급 기능으로 취급해 왔습니다.

이는 근본적인 격차를 만들어냅니다. 프로덕션 시스템의 상당 부분이 인텔리전스 도구가 완전히 이해하지 못하는 언어로 작성되어 있다면, 당신은 전체 그림을 갖는 것이 아니라 시스템 구성 요소가 언어 경계를 넘나드는 곳마다 사각지대가 존재하는 부분적인 시야만을 갖게 됩니다.

경쟁 구도: 대부분의 도구는 하나의 컨텍스트를 위해 구축되었습니다

시장 전반에 걸친 패턴은 놀라울 정도로 일관적입니다. 접근 방식이 정적 분석 (static analysis), 미세 조정된 LLM (fine-tuned LLMs), 또는 기호 추론 (symbolic reasoning)이든 관계없이, 대부분의 도구는 단일 언어나 생태계에서 시작하여 파서 (parser)를 하나씩 천천히 추가하며 외부로 확장해 나갑니다.

GitHub Copilot은 코드 완성 (code completion)을 위해 폭넓은 언어 지원을 제공하지만 파일 수준에서 작동합니다. 즉, 당신의 Python 데이터 파이프라인이 이를 소비하는 Java 서비스와 어떻게 연결되는지에 대한 모델을 가지고 있지 않습니다. Sourcegraph는 강력한 코드 검색 및 구조적 분석을 제공하지만, 교차 언어 시스템 동작에 대해 추론하지는 않습니다. Amazon Q Developer는 Java와 Python에 집중하며 다른 언어는 부분적으로 지원합니다. Swimm은 정적 분석을 통해 언어에 구애받지 않는 문서화를 제공하지만, 시스템 간 인텔리전스 문제는 해결하지 못합니다. ChatGPT나 Claude와 같은 범용 LLM 도구는 컨텍스트 윈도우 (context window)에 들어가는 내용으로 제한되며, 당신의 특정 코드베이스에 대한 지속적인 모델을 가지고 있지 않습니다.

여기서 핵심적인 통찰은 이러한 도구들이 잘못 만들어졌다는 것이 아닙니다. 그들의 아키텍처 (architecture)가 선형적 확장 (linear scaling)을 강제한다는 점입니다. 새로운 언어가 추가될 때마다 전용 파서 (parser) 또는 미세 조정된 모델 (fine-tuned model)이 필요하며, 수개월의 연구 개발 (R&D)과 지속적인 유지보수가 뒤따릅니다. 이는 제품 전략의 선택이 아니라 아키텍처의 제약 사항입니다.

CoreStory는 언어 지원을 단순한 기능 추가가 아닌 아키텍처 결정으로 취급합니다. 즉, 특정 언어에 맞춰 하드코딩된 파서 (parser)를 만드는 것이 아니라, 어떤 언어에 대해서도 추론할 수 있는 에이전트 (agent)를 구축합니다.

다형성 에이전트 (Polymorphic Agents)란 무엇인가?

다형성 에이전트 (polymorphic agent)란 자신이 마주하는 언어, 구조, 문맥 (context)에 따라 추론 전략, 도구 선택, 분석 기법을 동적으로 적응시키는 에이전트입니다. 고정된 분석 파이프라인 (analysis pipeline)을 실행하는 대신, 각 에이전트는 자신이 보고 있는 것이 무엇인지 평가하고 실시간으로 적절한 접근 방식을 선택합니다.

이는 세 가지 핵심 역량을 통해 작동합니다.

언어 인지 추론 (Language-aware reasoning). 다형성 에이전트가 코드 산출물 (code artifact)을 마주했을 때, 단순히 언어를 식별하는 데 그치지 않고 방언 (dialect), 프레임워크 (framework), 버전 시대 (version era), 그리고 사용 중인 특정 패턴을 식별합니다. Python 2 데이터 처리 스크립트는 Python 3 비동기 (async) FastAPI 서비스와는 다르게 취급되는데, 이는 두 서비스의 동시성 모델 (concurrency models), 의존성 패턴 (dependency patterns), 런타임 동작 (runtime behaviors)이 다르기 때문입니다. REST를 사용하는 Java Spring Boot 서비스는 gRPC나 메시지 큐 (message queues)를 사용하는 서비스와 다르게 분석됩니다. 결정적으로, 이러한 버전 인지 (version awareness)는 단일 코드베이스 내에서도 적용됩니다. 일부 서비스는 Java 8에서 실행되고 다른 서비스는 Java 17에서 실행되는 시스템의 경우, 버전 간의 차이점을 놓치는 일률적인 파싱 (parse) 대신 각 버전에 특화된 분석을 수행합니다.

동적 도구 선택 (Dynamic tool selection). 언어당 단일 파서 (parser)에 의존하는 대신, 다형성 에이전트 (polymorphic agents)는 분석 기술 툴킷 중에서 선택합니다. 즉, 정형 문법을 가진 구조화된 언어를 위한 AST 파싱 (AST parsing), 프레임워크 특화 관용구 및 DSL 확장을 위한 패턴 매칭 (pattern matching), 복잡한 조건부 로직을 통한 제어 흐름 추적을 위한 심볼릭 실행 (symbolic execution), 그리고 함수 이름, 주석 및 구조적 패턴에서 비즈니스 의도를 추출하기 위한 LLM 추론 (LLM inference) 등이 있습니다. 중요한 점은, 에이전트가 어떤 기술이 각 발견 사항을 생성했는지 추적한다는 것입니다. AST 파싱 및 심볼릭 실행에서 얻은 결정론적 (deterministic) 결과는 높은 신뢰도의 사실로 표시되는 반면, LLM으로 추론된 의도는 확률적 (probabilistic)인 것으로 표시되어 인간의 검토 대상으로 분류됩니다.

교차 언어 문맥 융합 (Cross-language context fusion). 이것이 바로 이 아키텍처가 가장 큰 이점을 창출하는 지점입니다. Python 데이터 파이프라인이 Kafka 토픽을 통해 Java 처리 서비스로 결과를 전달할 때, 또는 COBOL CICS 트랜잭션이 DB2 테이블에 기록하고 다운스트림 Java 서비스가 JDBC를 통해 동일한 테이블을 읽어 REST API를 채울 때, 다형성 에이전트는 전체 데이터 흐름을 추적하여 언어와 런타임 (runtime) 경계를 가로지르는 문맥을 통합된 명세 (specifications)로 융합합니다. 단일 언어 도구들은 정확히 이러한 통합 지점에서 멈추며, 시스템 동작의 가장 중요한 부분을 미지의 영역으로 남겨둡니다.

결정론적 vs. 추론된: 모든 명세에 포함된 신뢰 계층 (The Trust Layer in Every Spec)

AI 기반 분석 도구를 평가하는 아키텍트들은 타당한 질문을 던집니다. 만약 에이전트가 파싱 (parsing)이 아닌 추론 (reasoning)을 하고 있다면, 출력의 어느 부분을 신뢰해야 하는지 어떻게 알 수 있습니까?

CoreStory는 모든 명세에 내장된 명시적인 신뢰 계층 (confidence layer)을 통해 이에 답합니다. 각 발견 사항은 그것이 어떻게 도출되었는지에 따라 신뢰 지표를 가집니다.

높은 신뢰도 (High confidence) 발견 사항은 결정론적 분석에서 비롯됩니다. 즉, 잘 형성된 구문 (syntax)의 AST 파싱, 명시적인 함수 호출, 정의된 API 계약 (contracts), 추적된 이벤트 스키마 (event schemas) 등이 이에 해당합니다. 이것들은 코드에서 직접 추출된 사실입니다.

중간 신뢰도 (Medium confidence) 결과는 패턴 매칭 (pattern matching) 및 심볼릭 실행 (symbolic execution)에서 도출됩니다. 증거는 강력하고 구조적이지만, 경로 간의 추론 (inference)을 포함합니다. 예를 들어, 프로듀서 (producer)와 컨슈머 (consumer)가 필드 이름에는 합의했지만 계약 (contract)이 공식적으로 문서화된 적은 없는 추적된 Kafka 이벤트 스키마 (event schema)가 이에 해당합니다.

낮은 신뢰도 (Low confidence) 결과는 LLM 추론 (inference)에서 도출됩니다. 함수 이름, 주석 (comments), 아키텍처 패턴 (architectural patterns) 또는 명명 규칙 (naming conventions)에서 추출된 의도 (intent)가 이에 해당합니다. 여기서 오래된 주석은 리스크가 됩니다. 만약 주석이 3년 전에 작성되었고 그 이후 코드가 변경되었다면, 에이전트는 주석을 액면 그대로 묵인하는 대신 구조적 증거와 주석에 담긴 의도 사이의 불일치를 플래그 (flag)로 표시합니다.

그 결과, 아키텍트 (architects)는 계층별로 작업할 수 있는 명세서 (specification)를 얻게 됩니다. 즉, 모든 것을 수동으로 전수 검토할 필요 없이, 높은 신뢰도의 결과는 권위 있는 시스템 지도 (system map)로 사용하고, 중간 신뢰도의 결과는 검증해야 할 강력한 가설로 사용하며, 낮은 신뢰도의 결과는 해당 분야 전문가 (subject matter experts)를 위한 타겟 리뷰 목록으로 사용하는 것입니다.

왜 에이전트가 파서 (Parsers)보다 우월한가

다중 언어 지원에 대한 전통적인 접근 방식은 예측 가능한 패턴을 따릅니다. Java 파서를 만들고, Java 지원을 출시합니다. Python 파서를 만들고, Python 지원을 출시합니다. Go 파서를 만들고, Go 지원을 출시합니다. 새로운 언어가 추가될 때마다 6개월에서 12개월의 R&D가 필요합니다. 교차 언어 추적 (cross-language tracing)에는 수동 통합이 필요합니다. 또한 프레임워크 특정 패턴 (framework-specific patterns)과 버전 수준의 차이로 인해 이전 버전이나 방언 (dialect)을 위해 구축된 파서가 일상적으로 깨지곤 합니다.

CoreStory의 다형성 에이전트 (polymorphic agent) 아키텍처는 이러한 모델을 완전히 제거합니다.

에이전트가 코드를 마주하면, 언어를 식별하고 특정 컨텍스트 (context)에 가장 적합한 도구를 선택합니다. 에이전트는 하드코딩된 규칙 (hardcoded rules) 대신 추론 (reasoning)을 통해 프레임워크 관용구 (framework idioms)와 버전 차이를 처리합니다. 새로운 언어는 인프라를 재구축하는 것이 아니라 학습 (training)을 통해 추가됩니다. 그리고 언어 간 트레이싱 (cross-language tracing)은 별도로 추가되는 기능이 아니라, 첫 번째 분석부터 나타나는 네이티브 동작 (native behavior)입니다.

이 차이는 점진적인 수준이 아닙니다. 에이전트는 숙련된 엔지니어와 같은 방식으로 도구를 조합합니다. 즉, 눈앞에 있는 특정 코드에 맞는 적절한 분석 기술을 선택하고, 컨텍스트가 요구할 때 분석 도중에 접근 방식을 전환하며, 언어와 서비스의 경계를 넘나드는 조사 결과들을 일관되고 신뢰 계층화된 명세 (specifications)로 합성합니다.

다형성 에이전트 결정 루프 (The Polymorphic Agent Decision Loop)

모든 분석은 5단계 결정 루프 (decision loop)를 따릅니다. 이를 이해하는 가장 좋은 방법은 실제 다중 언어 프로덕션 시스템 (multi-language production system)을 가로지르는 구체적인 사례를 따라가는 것입니다:

에이전트가 코드 아티팩트(code artifact)인 order-processor/src/main/java/OrderService.java를 만납니다 (encounters).
에이전트는 REST 엔드포인트(endpoints)와 PostgreSQL 커넥션 풀(connection pool)을 사용하는 Spring Boot 기반의 Java 17임을 식별합니다 (identifies).
에이전트는 이 아티팩트에 가장 적합한 도구들을 선택합니다 (selects): AST 파서(AST parser)와 Spring 어노테이션 분석기(Spring annotation analyzer), 그리고 SQL 스키마 링커(SQL schema linker)의 조합입니다.
에이전트는 코드를 분석합니다 (analyzes) — Python 기반의 가격 책정 서비스(pricing service)로 향하는 아웃바운드 HTTP 호출과, Go 기반의 알림 서비스(notification service)가 소비하는 Kafka 토픽(Kafka topic)에 게시된 이벤트를 발견합니다. Python 서비스를 분석하는 동안, 에이전트는 JSON 페이로드(payload) 내에서 문서화되지 않은 필드, 즉 응답에는 존재하지만 공식 API 정의에는 없는 "섀도우(shadow)" 필드를 발견합니다. 에이전트는 이를 무시하는 대신 중간 신뢰도(medium-confidence)의 발견 사항으로 표시합니다: 해당 필드는 관찰된 응답에 존재하며, 그 이름은 할인 적용을 암시하지만, 정확한 의미론(semantics)은 가격 책정 서비스를 소유한 팀을 통한 확인이 필요하다는 것입니다.
에이전트는 세 서비스 전체와 PostgreSQL 스키마, 그리고 Kafka 이벤트 계약(event contract)에 걸친 발견 사항들을 종합합니다 (synthesizes) — 각 요소에 신뢰도 수준을 태깅하고, 섀도우 필드를 출력 사양(output spec)의 명시적인 어노테이션(annotation)으로 드러냅니다.