프로그래밍 언어가 두 개 이상일 때 코드 탐색이 제대로 작동하지 않는 이유는 무엇일까요?

개발자가 단일 코드베이스 내에서 단일 언어만 사용할 때는 코드 탐색이 매우 효율적입니다. F12 키를 누르면 정의 위치로 이동하고, 메서드를 마우스 오른쪽 버튼으로 클릭하면 모든 참조를 찾을 수 있습니다. 이러한 상호 작용은 IDE가 코드에 대한 완벽하고 일관된 모델을 가지고 있기 때문에 즉각적으로 느껴집니다. IDE는 모든 심볼, 모든 타입, 모든 임포트 체인을 알고 있습니다. 하지만 두 번째 언어가 포함되도록 경계가 확장되는 순간, 이러한 모델은 무너집니다. IDE는 자신이 사용하는 언어는 알지만 다른 언어는 알지 못합니다. 개발자는 함수 호출을 발견하고 현재 파일의 끝까지 따라가다가 벽에 부딪힙니다. 호출된 함수는 다른 언어로 작성되었거나, 다른 저장소에 있을 수 있으며, IDE가 이해하지 못하는 다른 규칙이 적용되기 때문입니다. 그 시점부터 탐색은 수동이 됩니다. 개발자는 다른 도구를 사용하고, 텍스트로 검색하고, 원하는 결과를 얻기를 바라야 합니다.

진정한 의미의 다국어 환경에서 작업하는 팀에게 이는 가끔 발생하는 불편함이 아닙니다. 모든 중요한 작업에서 기본적으로 발생하는 문제입니다. 엔터프라이즈 시스템은 COBOL과 Java, JCL과 SQL, Python과 C++ 등 수십 년에 걸쳐 기술 결정이 겹겹이 쌓인 수많은 조합으로 구성됩니다. 이러한 스택의 각 언어 경계는 자동화된 탐색이 멈추고 수동 재구성이 시작되는 지점입니다. 이러한 마찰은 모든 개발자, 모든 작업, 모든 팀에 걸쳐 누적되어 결국 구조적인 비용으로 이어집니다. 즉, 온보딩 속도 저하, 변경 위험 증가, 사고 조사 시간 연장, 그리고 여러 언어에 대한 지식을 보유한 소수의 인력에 대한 의존도 증가로 이어집니다. COBOL 정적 분석 솔루션 의 맥락에서 살펴보면 , 언어 경계를 넘나드는 추론의 어려움은 단순히 도구의 문제가 아닙니다. 이는 대규모의 이기종 시스템을 안전하게 운영하는 데 있어 근본적인 장애물입니다.

이러한 문제가 발생하는 이유와 실제적인 비용을 이해하는 것이 문제 해결의 첫걸음입니다. 이 글에서는 문제의 기술적 근원부터 운영상의 결과에 이르기까지 추적하고, 일반적으로 사용되는 도구들이 언어 장벽에서 제대로 작동하지 못하는 이유를 분석하며, 기업 규모에서 진정한 다국어 탐색이 가능하려면 무엇이 필요한지 설명합니다.

코드 내비게이션이 제대로 작동하기 위해 실제로 필요한 것

코드 탐색은 검색 작업이 아니라 해결 작업입니다. 개발자가 "이 함수는 어디에 정의되어 있나요?"라고 질문할 때, IDE는 파일에서 일치하는 텍스트를 검색하는 것이 아닙니다. IDE는 해당 식별자를 코드베이스의 구조화된 모델과 비교하여 해결합니다. 이 모델은 범위 내에 존재하는 모든 클래스, 메서드, 변수 및 형식과 그들 간의 관계를 구문 분석한 표현입니다. 이 모델은 인덱싱 과정에서 구축되고, 파일이 변경될 때마다 지속적으로 유지 관리되며, 탐색 작업이 트리거될 때 즉시 쿼리됩니다. 모델의 정확성과 완전성은 개발자가 받는 모든 탐색 결과의 정확성과 완전성을 결정합니다.

검색과 해결 사이의 이러한 구분은 언어 간 탐색에 필요한 요건을 정의하기 때문에 중요합니다. 텍스트 검색은 코드를 코드로 읽는 것이 아니므로 언어에 관계없이 모든 파일을 검색할 수 있습니다. 탐색 도구는 단순히 한 언어의 파일에서 문자열을 찾을 수 있는 모델이 아니라, 두 언어를 모두 아우르는 모델을 구축하지 않으면 언어 경계를 넘어 제대로 작동할 수 없습니다. 이러한 통합 모델을 구축하는 것은 단일 언어 탐색과는 달리 기술적으로 매우 까다로우며, 관련된 언어의 수가 많을수록 난이도가 높아집니다. 데이터 및 제어 흐름 분석 에 대한 자세한 검토에서 살펴본 바와 같이 , 실행 경로 전반에 걸쳐 올바르게 작동하는 코드는 특정 도구의 범위에 속하는 부분뿐만 아니라 전체 경로에 대한 구조적 이해를 필요로 합니다.

코드 탐색에 필요한 세 가지 구체적인 기능은 심볼 해석, 호출 그래프 구성, 그리고 의존성 추적인데, 이 세 가지 기능은 모두 언어 경계에서 각기 다른 방식으로 실패합니다. 각각의 기능은 실제 상호 작용을 고려하기 전에 개별적으로 살펴볼 필요가 있습니다.

기호 해석과 언어 경계에서 문제가 발생하는 이유

심볼 해석은 소스 코드의 식별자를 해당 정의에 매핑하는 과정입니다. 단일 언어 환경에서는 이 과정이 잘 알려져 있습니다. 컴파일러나 인터프리터가 이미 이 작업을 수행하고, IDE는 동일한 문법 및 타입 시스템 규칙을 사용하여 해당 해석 로직을 재현합니다. 단일 언어 환경에서는 규칙이 명확하기 때문에 해석이 정확합니다.

언어 경계에서 문제를 해결하려면 두 언어의 기호를 통합된 구조로 표현하고 언어 A의 식별자에서 언어 B의 해당 정의로의 연결을 추적할 수 있는 브리지 모델이 필요합니다. 이러한 브리지는 표준 IDE나 언어 서버에는 존재하지 않습니다. 언어 서버 프로토콜은 각 언어 서버가 하나의 언어만 처리한다는 가정하에 설계되었기 때문입니다. 자바 메서드가 정의된 인터페이스를 통해 COBOL 프로그램을 호출할 때, 자바 언어 서버는 메서드 호출은 이해하지만 COBOL 대상을 확인할 수는 없습니다. 개발자는 호출을 보고 어디로 향하는지는 알지만, 도구를 완전히 벗어나지 않고는 추적할 수 없습니다.

대표적인 예를 들어 보겠습니다. 자바 서비스가 미들웨어 계층을 통해 COBOL 프로그램을 이름으로 호출합니다.

자바

// Java service calling a COBOL program via a legacy middleware adapter
LegacyAdapter.invoke("CUSTINQ", customerRequest);

Java IDE가 해결합니다 LegacyAdapter.invoke 어려움 없이. 메서드 시그니처를 알고 있고 해당 구현체로 이동할 수 있습니다. 하지만 "CUSTINQ" 자바 레벨에서는 문자열 리터럴입니다. IDE는 COBOL 프로그램 이름에 대한 개념이 없으며, 이를 이해하지 못합니다. CUSTINQ 이 문자열은 자체 데이터 정의 및 단락 구조를 가진 특정 컴파일된 프로그램 단위를 나타냅니다. 탐색은 해당 문자열에서 멈춥니다. 개발자는 COBOL 소스 코드를 수동으로 찾아 다른 편집기에서 열고, 해당 프로그램이 호출하는 Java 코드와 어떻게 관련되는지에 대한 구조적 맥락 없이 읽기 시작해야 합니다.

이질적인 코드베이스 전반에 걸친 호출 그래프 구성

호출 그래프는 코드베이스 전체에서 어떤 함수가 다른 함수를 호출하는지를 나타내는 데이터 구조입니다. IDE는 호출 그래프를 사용하여 "모든 호출자 찾기" 및 "호출 계층 구조"와 같은 기능을 구현합니다. 이러한 기능은 개발자에게 특정 함수로 이어지는 모든 경로와 특정 함수가 호출하는 모든 함수를 보여줍니다. 단일 언어 환경에서 호출 그래프 구축은 코드베이스 인덱싱의 자연스러운 결과물입니다.

다국어 환경에서 완전한 호출 그래프는 언어 경계를 아우르도록 작성되어야 합니다. 실행이 다른 언어로 넘어가는 모든 지점에서 종료되는 호출 그래프는 시스템의 호출 그래프가 아니라, 언어별로 하나씩 존재하는 부분 그래프들의 모음이며, 각 언어 경계에서 연결이 끊어진 간선이 존재합니다. 여러 언어가 혼합된 시스템에서 실행 경로를 추적하는 개발자의 경우, 경로가 언어 경계를 넘을 때마다 추적이 중단되므로 다음 언어에서 다시 추적을 시작하려면 수동으로 단계를 거쳐야 합니다.

메인프레임 환경에서는 이 문제가 특히 심각한데, 단일 비즈니스 트랜잭션에 JCL이 실행 순서를 조율하고, COBOL 프로그램이 핵심 비즈니스 로직을 수행하며, SQL 쿼리가 데이터를 읽고 쓰는 등 여러 계층이 복합적으로 작용하기 때문입니다. JCL과 COBOL 매핑 분석에서 자세히 설명했듯이 , 이 세 계층은 서로 깊이 얽혀 있습니다. JCL은 어떤 코드가 어떤 순서로 실행될지 정의하고, COBOL은 프로그램의 동작을 정의하며, SQL은 프로그램이 어떤 데이터에 접근할지 정의합니다. COBOL, JCL, 또는 SQL만을 포함하는 호출 그래프는 시스템 전체가 아닌 시스템의 일부분만을 나타낼 뿐입니다. 의미 있는 추적을 위해서는 이 세 계층 모두를 하나의 모델로 연결해야 합니다.

언어 간 데이터 공유 시 의존성 추적

다국어 시스템에서 구성 요소 간의 의존성은 종종 공유 데이터를 통해 매개됩니다. 예를 들어 COBOL이 쓰고 Java가 읽는 데이터베이스 테이블, 배치 작업이 생성하고 API가 소비하는 파일, Python 프로듀서가 작성하고 Go 컨슈머가 읽는 메시지 큐 등이 있습니다. 이러한 데이터 매개 의존성은 실제적이며 중요한 영향을 미칩니다. 테이블 스키마, 파일 형식 또는 메시지 구조의 변경은 프로듀서와 컨슈머 모두에게 영향을 미치지만, 이러한 변경 사항은 어떤 단일 언어의 의존성 모델에도 표현되지 않습니다.

따라서 다국어 환경에서의 의존성 추적은 코드 간 호출뿐만 아니라 데이터와 코드 간의 관계, 즉 특정 테이블 열을 읽거나 쓰는 프로그램, 특정 파일 형식에 의존하는 서비스, 메시지 스키마 변경의 영향을 받는 소비자 등을 이해하는 것을 요구합니다. 이러한 종류의 추적은 표준 IDE 탐색 범위를 완전히 벗어나며, 각 언어의 코드를 개별적으로 처리하는 것이 아니라 데이터 계층을 포함한 전체 시스템을 모델링하는 도구가 필요합니다.

일반적인 다국어 환경에서 탐색이 실패하는 구체적인 방식

언어 간 코드 탐색의 실패 유형은 추상적인 것이 아닙니다. 이러한 실패 유형은 기업 개발 환경에서 일상적으로 발생하는 구체적이고 예측 가능한 상황에서 나타납니다. 이러한 실패 유형을 구체적으로 살펴보면 일반적인 검색 도구가 진정한 언어 간 탐색을 대체할 수 없는 이유가 명확해집니다.

COBOL과 Java: 가장 일반적인 기업 경계

COBOL과 Java 간의 경계는 특히 금융, 보험, 정부 기관과 같은 대규모 엔터프라이즈 시스템에서 가장 흔한 언어 경계입니다. 수십 년간의 COBOL 투자와 Java 현대화 노력이 공존하는 하이브리드 아키텍처에서 COBOL은 배치 처리를, Java는 트랜잭션 처리 및 API를 담당합니다. 두 언어는 CICS 트랜잭션, 메시지 큐, 공유 데이터베이스, 파일 기반 핸드오프와 같은 정의된 인터페이스를 통해 통신합니다.

실제로 이러한 경계를 넘나들다 보면 문제의 심각성을 깨닫게 됩니다. 트랜잭션에서 예상치 못한 동작을 조사하는 Java 개발자는 실행 경로를 따라 기본 데이터를 처리한 COBOL 배치 프로그램까지 추적해야 합니다. Java IDE는 인터페이스가 호출되는 위치만 보여줄 뿐, COBOL 프로그램이 입력값을 어떻게 처리하는지, 어떤 데이터를 읽는지, 어떤 계산을 수행하는지, 또는 어떤 결과를 출력하는지는 보여주지 못합니다. 개발자는 작업을 계속하기 위해 COBOL 전문 지식과 COBOL 도구가 필요한데, Java 중심 팀에서는 이러한 자원을 쉽게 확보하기 어려울 수 있습니다. 그 결과, 시간이 오래 걸리는 수동 조사를 하거나 필요한 지식을 갖춘 담당자에게 문제를 이관해야 하는데, 이는 모두 문제 해결에 시간과 비용을 낭비하는 잘못된 접근 방식입니다.

COBOL 측면에서도 비슷한 문제가 발생하는데, COBOL 개발자가 COBOL 프로그램이 생성하는 데이터를 어떤 Java 서비스가 소비하는지 파악해야 할 때입니다. 표준 COBOL 툴에는 Java 코드 모델이 없습니다. 개발자는 데이터베이스 쓰기나 파일 업데이트와 같은 COBOL 프로그램의 출력은 볼 수 있지만, 해당 출력을 따라가 어떤 Java 서비스가 읽는지 식별할 수는 없습니다. 출력 형식이 변경될 경우 Java 팀과 수동으로 협의해야 하는데, 소비자를 자동으로 열거할 수 있는 도구가 없기 때문입니다. COBOL 현대화는 바로 이러한 격차를 해소하는 데 매우 중요합니다. 두 언어 모두에서 전체 종속성 체인이 명확하게 드러나지 않는 한 안전한 현대화는 불가능합니다.

JCL과 COBOL: 가시성 없는 오케스트레이션

JCL은 메인프레임 배치 처리를 위한 오케스트레이션 계층입니다. JCL은 어떤 프로그램이 어떤 순서로, 어떤 매개변수를 사용하여, 어떤 파일과 데이터셋을 대상으로 실행될지를 제어합니다. JCL과 JCL이 호출하는 COBOL 프로그램 간의 관계는 근본적인 구조적 종속성을 갖습니다. JCL을 변경하면 COBOL 프로그램의 동작도 변경됩니다. COBOL 프로그램의 예상 입력 형식을 변경하면 해당 프로그램에 제공되는 JCL 데이터셋도 변경해야 할 수 있습니다.

표준 COBOL 분석 도구는 JCL을 구문 분석하지 않습니다. 표준 JCL 분석 도구도 COBOL을 구문 분석하지 않습니다. JCL 단계와 해당 단계 사이의 연결은 다음과 같습니다. PGM=CUSTINQ 그리고 COBOL 프로그램은 다음과 같습니다. CUSTINQ 실행 중인 시스템에는 존재하지만, 특정 툴의 모델에는 존재하지 않습니다. 개발자는 어느 툴 하나만으로는 전체적인 상황을 파악할 수 없습니다. JCL 단계가 호출하는 이름은 알지만, 프로그램이 실제로 무엇을 하는지는 알 수 없습니다. 마찬가지로 COBOL 프로그램이 무엇을 하는지는 알지만, 어떤 매개변수로 어떤 방식으로 호출되는지, 또는 어떤 작업 스트림 순서로 호출되는지는 알 수 없습니다.

이러한 격차는 운영 시스템에 특정한 위험을 초래합니다. COBOL 프로그램의 작업 저장소 정의를 수정하는 개발자는 의도치 않게 특정 JCL 단계에서 전달된 데이터를 프로그램이 처리하는 방식을 변경할 수 있으며, 이러한 변경 사항이 JCL에 정의된 실행 컨텍스트에 영향을 미친다는 경고를 도구에서 확인할 수 없습니다. 또한, JCL 프로시저를 재구성하는 개발자는 프로그램 실행 순서를 변경할 수 있으며, 어떤 COBOL 프로그램이 올바른 작동을 위해 해당 순서에 의존하는지 도구에서 보여주지 않습니다. JCL 정적 분석 솔루션 검토에서 자세히 설명했듯이 , JCL 환경 내에서 프로그램 간 종속성 및 데이터 세트 사용에 대한 가시성을 확보하려면 표준 도구로는 제공할 수 없는 전용 분석이 필요합니다.

표준 도구를 사용하여 각 언어 관점에서 동일한 의존성이 어떻게 보이는지, 그리고 통합 모델에서는 어떻게 보이는지를 아래에 비교했습니다.

개발자가 보는 것	JCL 전용 보기	COBOL 전용 보기	통합된 언어 간 보기
프로그램 실행	PGM=CUSTINQ (이름만)	보이지 않음	CUSTINQ는 특정 PARM 값을 가진 3개의 JCL 프로시저에 의해 호출됩니다.
입력 데이터 세트	DD 이름 목록	보이지 않음	CUSTMAST.JCL 2단계에 정의된 CUSTFILE을 읽습니다.
출력 데이터 세트	DD 이름 목록	보이지 않음	CUSTRPT를 기록합니다(RPTPRT 작업에서 사용됨).
비즈니스 로직	보이지 않음	절차 구분 표시됨	JCL 호출부터 COBOL 로직을 거쳐 출력까지의 전체 흐름
변화의 영향	알 수 없는	알 수 없는	4개의 JCL 프로시저, 2개의 하위 COBOL 프로그램, 1개의 데이터베이스 테이블

최신 언어 스택: 다양한 서비스에서 사용되는 Python, Go 및 C#

최신 언어로 구축된 분산 시스템에서 탐색 문제는 다른 양상을 띱니다. COBOL과 Java 간의 언어적 격차보다는, 서비스 경계와 다양한 언어로 구성된 스택이 결합된 환경이 과제입니다. 예를 들어, Python으로 처리된 데이터 처리 서비스는 Go API를 통해 데이터를 처리하고, Go API는 다시 C# 프런트엔드에 데이터를 제공합니다. 각 서비스는 고유한 도구, IDE 구성, 그리고 의존성 모델을 사용하여 구축됩니다. 서비스 간의 연결은 API 계층에서 이루어지지만, 표준 탐색 도구는 서비스 간 API 관계에 대한 모델을 제공하지 않습니다.

Python 서비스에서 응답 구조를 수정하는 개발자는 Go API가 의존하는 필드와 C# 프런트엔드가 최종적으로 표시하는 필드를 알아야 합니다. 언어와 서비스를 넘나드는 탐색 기능이 없다면, 개발자는 각 하위 서비스의 코드를 수동으로 검사하고 관련 필드 이름에 대한 참조를 검색해야 하며, 명명 규칙이 일관성이 있어 검색 결과가 신뢰할 수 있기를 바랄 수밖에 없습니다. Go 정적 분석 도구 와 관련하여 논의되었듯이 , 단일 Go 서비스 내에서도 호출 계층 구조를 이해하고 모듈 간의 종속성을 추적하는 것은 결코 간단한 문제가 아닙니다. 이러한 문제를 서비스 경계와 언어 경계를 넘어 동시에 확장하는 것은 훨씬 더 어렵습니다.

C# 시스템이 Java로 작성된 공유 서비스를 호출하거나, Python 파이프라인이 .NET 애플리케이션에서 사용하는 데이터베이스에 쓰는 경우 에도 동일한 패턴이 적용됩니다 . 각 경우에, 각 언어의 표준 도구는 해당 언어 내에서는 정확한 탐색을 제공하지만, 실행이 다른 언어나 서비스로 넘어가는 경계에서는 유용한 결과를 제공하지 못합니다.

SQL과 애플리케이션 코드: 보이지 않는 데이터 계층

SQL은 거의 모든 엔터프라이즈 시스템에 존재하지만, 언어 간 탐색에서 가장 간과되는 요소이기도 합니다. 애플리케이션 코드는 테이블 이름, 열 이름, 조인 조건 및 저장 프로시저를 참조하는 SQL 쿼리를 작성합니다. 데이터베이스 스키마는 이러한 테이블과 열을 정의합니다. 애플리케이션 코드와 데이터베이스 스키마 간의 관계는 의존성 관계이며, 스키마 변경으로 인해 이 관계가 깨지면 런타임 오류가 발생합니다. 하지만 표준 IDE는 SQL 문자열을 탐색 가능한 구조를 가진 코드가 아닌 단순한 문자열로 취급합니다.

스키마에서 열 이름을 변경한 개발자는 모든 애플리케이션, 모든 언어, 모든 쿼리에서 해당 열에 대한 모든 참조를 찾아야 합니다. 열 이름을 텍스트로 검색하는 것은 신뢰할 수 없습니다. 짧은 열 이름은 변수 이름, 로그 메시지, 주석과 충돌하기 때문입니다. 기호를 인식하는 검색을 위해서는 SQL 스키마와 이를 참조하는 애플리케이션 코드를 모두 모델링하고 이해하는 도구가 필요합니다. "customer_id" Java 쿼리 문자열에서 는 데이터베이스 열에 대한 참조입니다. customer_id또한, 언어 전반에 걸쳐 이러한 모든 참조를 열거할 수 있습니다. 이러한 모델이 없으면 스키마 변경은 수작업이 많이 필요하고 통계적으로 불완전합니다.

IDE 확장 기능과 언어 서버가 이 문제를 해결할 수 없는 이유는 무엇일까요?

IDE 확장 기능과 언어 서버는 언어별 인텔리전스를 제공하도록 설계되었습니다. 이러한 기능은 특정 문법에 따라 코드를 구문 분석하고, 언어별 기호 색인을 구축하며, 언어 서버 프로토콜을 통해 쿼리를 처리합니다. 언어 서버 프로토콜은 정의로 이동, 참조 찾기, 마우스 오버 시 문서 표시 등의 언어 기능을 위한 표준 인터페이스를 제공합니다. 이 프로토콜은 전송 계층에서는 언어에 구애받지 않지만, 내용은 언어별로 특화되어 있습니다. 즉, 각 언어 서버는 자체 언어에 대한 결과만 생성합니다.

같은 IDE 내에서 두 개의 언어 서버를 연결한다고 해서 언어 간 탐색 문제가 해결되는 것은 아닙니다. 각 서버는 자체적인 인덱스를 가지고 있습니다. 개발자가 특정 심볼에 대한 "모든 참조 찾기"를 요청하면, 해당 요청은 현재 파일이 속한 언어의 언어 서버로 전송됩니다. 해당 서버는 자신이 알고 있는 참조만 반환하는데, 이는 자신이 인덱싱한 파일에 한정됩니다. 다른 언어 서버에는 쿼리를 보내지 않으며, 설령 쿼리를 보낸다고 하더라도 언어 간 관계를 표현할 수 있는 공유 심볼 모델이 존재하지 않습니다.

이는 LSP 아키텍처의 구조적 한계이지 구성 문제는 아닙니다. 파이썬 f-string 내의 인라인 SQL도 파싱하는 언어 서버와 같은 특정하고 제한적인 경우에는 부분적으로 해결할 수 있지만, 어떤 언어 서버도 제공하도록 설계된 범위를 넘어서는 통합된 다국어 모델을 구축하지 않고서는 임의의 언어 간 종속성에 일반화할 수 없습니다. 단일 언어 내에서 메타프로그래밍을 다룰 때 정적 분석이 직면하는 어려움은 이 문제의 심각성을 보여줍니다. 하나의 언어 내에서 동적으로 생성된 코드를 추론하는 데 특화된 기술이 필요하다면, 서로 다른 문법과 런타임 모델을 가진 여러 언어에 걸쳐 추론하려면 완전히 다른 아키텍처적 접근 방식이 필요합니다.

언어 서버가 잘하는 점 (그리고 한계점)

언어 서버는 실시간 진단, 지능형 코드 완성, 단일 언어 기호 해결, 제한된 범위 내에서의 에디터 내 리팩토링 등 설계된 목적에 부합하는 작업에서 탁월한 성능을 발휘합니다. 이러한 기능들은 매우 가치 있으며 간과해서는 안 됩니다. 문제는 언어 서버 자체가 부적절한 도구라는 것이 아니라, 단일 언어 도구가 다국어 문제에 적용되고 있다는 점입니다. 이러한 불일치는 정확성이 가장 중요한 지점에서 예측 가능하고 값비싼 오류를 초래합니다.

아래 표는 특정 탐색 작업과 언어 서버에서 제공하는 기능, 그리고 그 차이가 발생하는 지점을 보여줍니다.

내비게이션 작업	한 언어 내의 LSP	언어 경계를 넘나드는 LSP
정의로 이동	정확하고 즉각적인	실패: 호출 지점에서 멈춤
모든 참고 자료를 찾아보세요	색인된 파일 내에서 완료됨	불완전함: 다른 언어에 대한 참조가 누락됨
호출 계층	단일 언어 사용자 발신자에게 정확합니다.	축약됨: 경계 호출자가 없습니다.
기호 이름 변경	한 가지 언어 내에서 안전하게 보호됩니다.	위험: 이름 변경 시 언어 간 용법을 놓칠 수 있습니다.
영향 분석	현재 언어에 맞춰 범위 지정	다른 언어를 사용하는 하위 소비자를 고려하지 않음

Grep과 텍스트 검색: 왜 이것들이 적절한 대체재가 될 수 없는가

언어 서버가 언어 경계를 제대로 인식하지 못할 때, 개발자들은 텍스트 검색에 의존하게 됩니다. grep, IDE 수준 검색, 그리고 GitHub Code Search와 같은 플랫폼 검색 도구들은 모두 언어에 관계없이 파일 내의 문자열을 찾습니다. 이러한 도구들은 "심볼"이나 "참조"라는 개념이 없고, 단지 문자열의 발생 빈도만을 인식합니다. 짧고 공통적인 식별자의 경우, 이는 방대한 검색 결과를 초래하여 수동으로 필터링해야 하는 번거로움을 야기합니다. 또한, 여러 언어에서 서로 다른 의미를 갖는 식별자의 경우, 이름이 같은 서로 다른 코드 요소들이 검색 결과에 혼용되어 나타날 수 있습니다.

소음보다 더 위험한 것은 불완전성입니다. 텍스트 검색은 언어마다 명명 규칙이 다르거나, 식별자가 동적으로 생성되거나, 구성이나 이름 레지스트리를 통해 연결되거나, 직접적인 코드 참조가 아닌 데이터를 통해 관계가 표현되는 경우 참조를 놓칩니다. 이러한 누락은 검색 결과에 나타나지 않습니다. 개발자는 검색 결과에서 찾은 내용만 볼 뿐, 무엇을 놓쳤는지 알 수 없으며, 완전해 보이는 불완전한 정보를 바탕으로 결정을 내립니다. 유지보수성을 위한 정적 코드 분석 이라는 더 넓은 맥락에서 살펴보면 , 코드의 기능과 연결 관계를 정확하게 파악할 수 없는 것은 단순한 불편함이 아니라 기술 부채 누적, 유지보수 중 발생하는 결함, 그리고 안전하게 변경하는 데 드는 비용 증가의 근본 원인입니다.

언어 장벽에서 발생하는 운영 비용

위에서 설명한 탐색 오류는 단일 사건으로 나타나는 문제가 아닙니다. 이러한 오류는 다국어 환경에서 작업하는 모든 작업, 모든 개발자, 모든 팀에 걸쳐 누적됩니다. 비용을 이해하려면 탐색 오류가 발생하는 반복적인 상황을 살펴보고 총체적인 영향을 계산해야 합니다.

다국어 팀의 온보딩 과정은 훨씬 더 오래 걸립니다.

단일 언어와 단일 코드베이스를 사용하는 팀에 합류하는 개발자는 비교적 빠르게 생산성을 높일 수 있습니다. IDE가 탐색을 지원하고, 코드 구조 자체가 자체적으로 설명적이며, 개발자가 구축하는 개념 모델이 실제 시스템을 반영하기 때문입니다. 하지만 여러 언어를 사용하는 팀에 합류하는 개발자는 근본적으로 다른 상황에 직면하게 됩니다. 도구가 언어 경계를 넘나들며 작업하지 않기 때문에, 개념 모델은 문서화, 페어 프로그래밍, 시행착오를 통해 직접 구축해야 합니다.

이러한 수동 모델 구축은 며칠이 아닌 몇 주가 걸립니다. 개발자는 자신이 주로 사용하는 언어의 코드뿐만 아니라 인접 언어에 대해서도 충분히 학습하여 어떤 함수가 해당 함수를 호출하고, 어떤 함수가 해당 함수를 호출하며, 어떤 데이터가 언어 간에 흐르는지 이해해야 합니다. 이직률이 높거나 팀 구성원 변동이 잦은 대규모 조직에서는 이러한 장기간의 온보딩 시간이 일회성 투자가 아닌 지속적인 비용이 됩니다. 다국어 팀에 합류하는 모든 사람은 언어 간 상호 이해 모델을 처음부터 다시 구축하는 데 드는 모든 비용을 부담해야 합니다. 왜냐하면 기존 도구는 이러한 모델 구축을 지원하는 기능을 전혀 제공하지 않기 때문입니다.

언어 경계를 넘나드는 흔적이 발견될 경우, 제작 과정에서 발생하는 문제들은 더 오래 지속됩니다.

운영 환경에서 발생한 사고를 추적하기 위해 언어 경계를 넘나드는 실행 경로를 조사해야 할 경우, 경계를 넘을 때마다 수동으로 작업을 처리해야 합니다. 이미 시간적 압박에 시달리는 당직 개발자는 도구를 전환하고, 다른 언어의 코드베이스에서 텍스트를 검색하고, 그 결과를 기존에 구축하던 추적 정보에 수동으로 연결해야 합니다. 3~4개의 언어 계층으로 구성된 시스템에서는 완전한 근본 원인 조사를 위해 이러한 경계 넘나들기가 4~5번 발생할 수 있으며, 각 단계는 조사 시간을 몇 분씩 추가하게 되고, 이는 결국 사용자에게 미치는 영향 시간으로 측정됩니다.

여러 언어를 지원하는 서비스를 운영하는 조직에서 누적되는 영향은 언어 경계를 넘나드는 모든 문제에 대한 평균 해결 시간이 체계적으로 증가하는 것입니다. 이는 개별 개발자의 실패가 아니라 시스템의 실제 연결을 제대로 모델링하지 못하는 도구의 구조적 결과입니다. 언어 간 가시성 확보에 투자한 조직은 문제 해결 속도 향상을 가장 직접적이고 측정 가능한 이점 중 하나로 일관되게 보고하는데, 이는 바로 그러한 투자가 조사 시간을 늘리는 수동적인 언어 경계 넘나들기 단계를 제거하기 때문입니다.

언어 간 영향 가시성이 없으면 위험한 변경 사항은 더욱 위험해집니다.

다국어 시스템에서 공유 코드를 변경할 때마다 모든 언어의 사용자가 해당 코드를 어떻게 사용하는지 완전히 파악하기 전까지는 알 수 없는 위험이 따릅니다. 언어 간 탐색 기능이 없다면 변경 전에 위험을 확인할 수 없습니다. 위험은 변경 후에 테스트 또는 더 심각하게는 운영 환경에서 문제가 발생했을 때 발견됩니다. 이는 드문 실패 사례가 아닙니다. 하위 사용자들이 서로 다른 언어를 사용하는 시스템에서 공유 데이터 구조, 인터페이스 또는 유틸리티를 유지 관리할 때 흔히 발생하는 결과입니다.

이러한 불확실성에 대한 보수적인 대응은 지나친 신중함입니다. 즉, 더 많은 테스트 노력, 더 긴 검토 주기, 더 잦은 조정 회의, 그리고 중요한 시기에 더 빈번한 변경 동결이 그것입니다. 이 모든 것은 다국어 시스템에서 매 변경 주기마다 누적되는 실질적인 비용입니다. 이는 가치 창출에 투자되는 것이 아니라, 언어 간 탐색 기능의 부재를 보완하는 데 소요되는 시간과 노력을 의미합니다. 레거시 시스템 현대화 환경은 이러한 누적 비용에 의해 상당 부분 좌우됩니다. 조직들이 현대화를 추진하는 이유는 기존 시스템 유지 관리 비용이 감당하기 어려울 정도로 높아졌기 때문이며, 언어 간 탐색 기능의 실패는 이러한 유지 관리 비용 증가의 주요 원인입니다.

다국어 내비게이션에 실제로 필요한 것은 무엇일까요?

여러 언어에 걸친 코드 탐색 문제를 해결하려면 개별 언어 서버가 제공할 수 없는 통합 모델을 구축해야 합니다. 이 모델은 유용한 언어 간 탐색을 위한 필수 조건인 여러 요구 사항을 충족해야 하며, 이는 선택적인 개선 사항이 되어서는 안 됩니다.

모든 언어에 걸쳐 사용되는 단일 공통 심볼 인덱스. 함수, 클래스, 필드, 프로시저, 테이블 및 데이터 정의를 포함하여 모든 언어의 모든 명명된 요소는 공통된 식별 모델을 사용하여 하나의 인덱스에 표현되어야 합니다. 언어 간 참조를 해결하려면 심볼의 식별 정보가 언어별로 다를 수 없습니다.

시스템에 포함된 모든 언어에 대해 언어 인식 파서가 필요합니다. 각 언어는 일반 파서나 패턴 매칭이 아닌, 해당 언어 고유의 문법을 사용하여 파싱해야 합니다. 각 파서의 구조적 출력은 공유된 아이덴티티 모델에 매핑되어야 하며, 이를 통해 언어 간 관계를 올바르게 식별된 기호 간의 연결로 표현할 수 있어야 합니다.

언어 간 인터페이스의 명시적 모델링. 프로그램 이름 호출, 데이터베이스 테이블, 파일 형식, 메시지 스키마, API 계약 등 서로 다른 언어가 상호 작용하는 메커니즘은 불투명한 문자열로 취급하거나 모델에서 완전히 제외하는 것이 아니라, 일급 연결 유형으로 모델에 표현되어야 합니다.

데이터 계층 관계를 포함하는 의존성 추적. 모델은 코드 간 호출뿐만 아니라 데이터를 매개로 하는 의존성도 표현해야 합니다. 다국어 시스템에서는 데이터가 한 언어의 출력이 다른 언어의 입력이 되는 주요 매개체인 경우가 많기 때문입니다.

대화형 탐색을 지원하는 쿼리 성능을 제공해야 합니다. 인덱스는 일반적인 탐색 작업에 대해 1초 미만의 쿼리 응답 속도를 지원해야 합니다. 대화형 쿼리 대신 배치 분석 실행이 필요한 모델은 오프라인 영향 분석에 유용하지만, 실제 개발 중 실시간 탐색을 대체할 수는 없습니다.

이러한 요구사항은 IDE 확장 기능이나 언어 서버가 아닌 엔터프라이즈 코드 인텔리전스 플랫폼을 설명합니다. 이러한 플랫폼을 구축하고 유지 관리하는 것은 다국어 코드 탐색을 실제로 구현하기 위한 기술적 기반입니다. 탐색 오류를 감수하고 그 비용을 무기한으로 지불하는 대안은 다국어 시스템의 규모와 복잡성이 커질수록 점점 더 지속 불가능해집니다.

방법 SMART TS XL 주소 다국어 내비게이션

SMART TS XL 이 플랫폼은 엔터프라이즈 시스템을 단일 언어나 단일 저장소의 관점에서 이해할 수 없다는 전제에 기반하여 구축되었습니다. 소프트웨어 인텔리전스 플랫폼은 환경 내 모든 언어와 플랫폼의 소스 코드를 수집하고, 언어별 분석을 통해 각 코드를 파싱한 후, 언어에 관계없이 요소 간의 관계를 나타내는 통합 상호 참조 인덱스를 구축합니다. 이 인덱스에 대한 탐색 쿼리는 언어 경계를 넘어 결과를 반환하는데, 이는 인덱스가 시스템의 언어별 일부가 아닌 전체 시스템을 모델링하기 때문입니다.

이 플랫폼은 표준 도구들이 무시하는 언어 간 인터페이스를 명시적으로 모델링합니다. COBOL 프로그램을 이름으로 호출하는 JCL 단계는 상호 참조 그래프에서 종속성으로 표현되어 JCL 단계와 COBOL 프로그램 단위를 연결합니다. 데이터베이스 테이블에 쓰는 Java 메서드는 데이터 종속성으로 표현되어 Java 코드와 테이블 정의를 연결하고, 거기에서 동일한 테이블을 읽는 다른 언어와도 연결합니다. 여러 프로그램에서 참조되는 COBOL 카피북은 공유 정의로 표현되므로 카피북 구조가 변경되면 언어에 관계없이 변경의 영향을 받는 모든 프로그램이 즉시 표시됩니다. 이러한 언어 간 종속성의 명시적 모델링은 진정한 크로스 언어 탐색 플랫폼을 병렬로 작동하는 언어별 도구 모음과 구별하는 요소입니다.

SMART TS XL이 통합 모델의 실질적인 가치는 영향 분석 기능을 통해 입증됩니다. 개발자가 COBOL 데이터 정의, 데이터베이스 스키마 요소, Java 인터페이스 또는 JCL 프로시저와 같은 공유 구성 요소를 변경할 때 발생하는 결과를 파악해야 할 경우, 플랫폼은 해당 구성 요소에서 모든 언어 경계를 넘어 종속성 그래프를 추적하고 영향을 받는 모든 요소에 대한 완전한 정보를 제공합니다. 결과는 언어별, 구성 요소별, 특정 참조 위치별로 정리된 탐색 가능한 보고서 형태로 제공되므로 개발자는 변경 후 결과를 발견하는 대신 변경 전에 필요한 모든 정보를 얻을 수 있습니다. 이 기능은 이전 섹션에서 설명한 위험 누적 문제를 직접적으로 해결하여, 불확실한 언어 간 위험을 정량화하고 열거 가능한 영향으로 변환합니다.

전체 시스템의 속성으로서의 다국어 탐색

이 글의 핵심은 다국어 환경에서의 코드 탐색은 특정 언어 도구의 특성이 아니라 전체 시스템의 특성이라는 점입니다. COBOL을 완벽하게 탐색하는 IDE와 Java를 완벽하게 탐색하는 IDE를 함께 사용한다고 해서 COBOL과 Java 사이의 경계를 탐색하는 시스템이 만들어지는 것은 아닙니다. 오히려 두 개의 독립적인 탐색 시스템을 만들어내며, 그 사이에 간극이 존재하게 됩니다. 그리고 바로 그 간극에 시스템에서 가장 중요한 관계들이 존재합니다.

이러한 격차를 해소하려면 시스템 전체를 모델링하고, 언어 경계를 넘나드는 관계를 일급 객체로 표현하며, 이러한 관계가 이끄는 곳이라면 어디든 따라갈 수 있는 탐색 기능을 제공하는 새로운 유형의 도구가 필요합니다. 엔터프라이즈 규모로 복잡한 다국어 시스템을 운영하는 조직에게 이러한 기능은 선택이 아닙니다. 이러한 기능 없이 개발하는 하루하루가 지날수록 언어 간 탐색 오류로 인한 비용이 누적됩니다. 온보딩 속도 저하, 문제 해결 시간 연장, 변경 작업의 위험성 증가, 그리고 도구가 제공할 수 없는 언어 간 정신적 모델을 수동으로 구축해 온 담당자들의 귀중한 지식이 점차 고갈되는 현상이 발생합니다.