텍스트 검색이 코드 이해와 다른 이유

한 개발자가 처음으로 방대한 레거시 코드베이스를 열어봅니다. 계정이 폐쇄될 때 고객 기록에 어떤 일이 발생하는지, 즉 어떤 프로그램이 기록을 업데이트하고, 어떤 배치 작업이 그 기록을 읽고, 어떤 필드가 수정되는지, 그리고 하위 시스템이 최종 상태에 의존하는지 여부를 파악해야 합니다. 가장 먼저 하는 일은 검색입니다. 필드 이름을 검색창에 입력하고, 결과를 훑어보고, 몇 개의 파일을 열어 읽기 시작합니다. 한 시간 만에 12개의 프로그램, 3개의 SQL 스크립트, 그리고 하나의 JCL 작업 스트림에서 해당 필드 이름을 찾았습니다. 또한 17개의 주석 블록, 4개의 로그 형식 문자열, 2개의 테스트 픽스처, 그리고 전혀 관련 없는 하위 시스템의 변수에서도 같은 필드 이름을 발견했습니다. 검색 결과만으로는 실제 데이터 읽기, 쓰기, 변환, 그리고 단순히 이름이 일치하는 부분을 구분할 수 없습니다. 필드 이름은 알지만, 코드가 그 필드를 어떻게 사용하는지는 아직 이해하지 못합니다.

문자열을 찾는 것과 코드를 이해하는 것 사이의 간극은 더 나은 검색으로 해소될 수 있는 간극이 아닙니다. 이는 근본적으로 다른 두 가지 유형의 질문 사이의 간극입니다. 하나는 "이 텍스트는 어디에 나타나는가?"를 묻는 질문이고, 다른 하나는 "이 코드는 무엇을 하는가?"를 묻는 질문입니다. 텍스트 검색은 첫 번째 질문에 대한 훌륭한 답변입니다. 하지만 두 번째 질문에 대한 답변은 전혀 아니며, 이 두 가지를 혼동하는 것은 소프트웨어 개발에서 노력 낭비, 의존성 누락, 잘못된 영향 평가의 가장 흔한 원인 중 하나입니다. 이러한 구분은 소규모의 최신 코드베이스보다 대규모의 이기종 엔터프라이즈 시스템에서 더욱 중요합니다. 왜냐하면 그러한 시스템에는 수십 년 동안 축적된 구조, 언어 간 의존성, 그리고 소스 파일에 나타나는 문자열이 아니라 코드의 동작에만 존재하는 암묵적인 관계가 포함되어 있기 때문입니다. 코드 품질 지표와 그 영향 분석에서 살펴본 바와 같이 , 코드베이스의 복잡성은 유지보수성에 상당한 영향을 미치며, 텍스트 패턴만으로 도출된 어떤 지표도 코드의 실제 동작 방식을 좌우하는 구조적 관계를 포착할 수 없습니다.

텍스트 검색의 실제 기능

텍스트 검색은 원시 문자열 시퀀스로 처리되는 파일에 적용되는 부분 문자열 일치 작업입니다. 쿼리는 문자열 또는 패턴입니다. 결과는 해당 패턴이 나타나는 위치 목록입니다. 이 도구는 파일이 작성된 언어에 대한 정보도 없고, 텍스트의 구조를 결정하는 문법에 대한 이해도 없으며, 텍스트가 나타내는 코드 요소 간의 관계에 대한 모델도 없습니다. 백만 줄의 COBOL 소스 코드에 대한 grep 작업은 백만 줄의 HTML에 대한 grep 작업과 동일한 모델로 작동합니다. 즉, 파일 경로별로 그룹화된 파일 내 문자 시퀀스 중에서 일치하는 경우 결과를 반환합니다.

이는 특정 유형의 작업에 매우 유용합니다. 예를 들어, 알려진 문자열이 어디에 나타나는지 찾거나, 특정 용어가 사용되었는지 여부를 확인하거나, 명명 규칙에 대한 간단한 검사를 수행하거나, 특정 오류 메시지가 포함된 파일을 찾는 경우입니다. 이러한 작업에는 텍스트 검색이 가장 적합한 도구입니다. 왜냐하면 이러한 작업은 본질적으로 문자열을 찾는 것이기 때문입니다. grep 및 유사 도구의 속도, 이식성, 그리고 설정이 필요 없다는 점은 "이 문자열이 이 파일들에 존재하는가? 존재한다면 어디에 있는가?"와 같은 질문에 완벽하게 부합하는 특징입니다.

문제는 문자열에 관한 질문이 아닌 경우에 텍스트 검색을 사용할 때 발생합니다. "이 함수를 호출하는 것은 무엇인가?"는 함수 이름이 어디에 나타나는지에 대한 질문이 아닙니다. 이는 호출 그래프에 대한 질문이며, 호출 그래프는 코드의 구조적 속성으로 구문 분석과 의미 분석이 필요합니다. "이 필드는 어디에 기록되는가?"는 필드 이름이 어디에 나타나는지에 대한 질문이 아닙니다. 이는 데이터 흐름에 대한 질문으로, 답변하려면 특정 언어의 할당 의미론을 이해해야 합니다. "이 인터페이스를 변경하면 어떤 문제가 발생하는가?"는 인터페이스 이름이 어디에 나타나는지에 대한 질문이 아닙니다. 이는 의존 관계에 대한 질문으로, 정확한 답변을 위해서는 임포트, 상속 및 모듈 간 결합을 해결해야 합니다.

이 질문들은 모두 이름을 출발점으로 삼고 있기 때문에 마치 검색 작업처럼 접근하기 쉽습니다. 하지만 이름은 단지 진입점일 뿐입니다. 해답은 소스 파일의 텍스트가 아니라 코드의 구조적 모델에 있습니다.

노이즈 문제: 의미 없는 결과가 너무 많음

코드 이해 작업에 텍스트 검색을 적용할 때 발생하는 첫 번째 실패 유형은 과잉 생산입니다. 관련성이 떨어지는 결과를 너무 많이 반환하면서 구조적으로 중요한 결과와 우연의 일치 결과를 구분할 수 있는 메커니즘이 없다는 것입니다.

짧은 식별자는 다음과 같습니다. status, id, type및 date 대규모 코드베이스에서는 수천 번 나타날 수 있습니다. 더 긴 식별자는 언어와 네임스페이스 간에 충돌을 일으킬 수도 있습니다. calculate_tax 파이썬 모듈의 함수 이름, COBOL 단락 이름, 데이터베이스 저장 프로시저, 자바스크립트 헬퍼, 로깅 설정의 문자열 등 다양한 곳에서 ''이 '텍스트' 검색 결과에 나타납니다. 하지만 개발자는 이러한 결과를 직접 필터링해야 하며, 코드에 대한 자신의 이해를 바탕으로 어떤 항목이 관련 있는지 판단해야 합니다. 이러한 수동 필터링 작업 자체가 코드 이해를 필요로 하므로, 개발자는 도구의 도움 없이 도구가 수행해야 할 작업을 직접 해야 합니다.

실제로 개발자들은 직관과 경험에 따라 필터링을 합니다. 테스트 파일의 결과는 실제 운영 환경에서 호출되는 코드가 아닐 가능성이 높다는 것을 알고, 주석 블록 안의 결과는 함수 호출이 아닌 문서일 뿐이라는 것을 인지합니다. 관련성이 없다고 판단되는 파일의 결과는 무시합니다. 하지만 이러한 필터링은 오류가 발생할 수 있고 검증할 수 없습니다. 확신에 차서 필터링하는 개발자도 틀릴 수 있고, 신중하게 필터링하는 개발자도 몇 시간을 소비할 수 있습니다. 두 경우 모두 결과는 개발자의 판단을 반영한 것일 뿐, 검증된 코드 구조 분석이 아닙니다.

구체적인 예를 들어보겠습니다. COBOL 개발자가 단락을 삭제하기 전에 단락 이름을 검색하는 경우를 생각해 보겠습니다.

코볼

SEARCH-RESULTS FOR "CALC-INTEREST":

1. CALC-INTEREST.PGM        line   5  : IDENTIFICATION DIVISION.
2. CALC-INTEREST.PGM        line  42  : CALC-INTEREST.
3. FINPROCESS.CBL            line 178  : PERFORM CALC-INTEREST
4. RPTMONTH.CBL              line  91  : * Old routine: CALC-INTEREST replaced by CALC-INT-V2
5. CUSTBATCH.CBL             line 234  : PERFORM CALC-INTEREST THRU CALC-INTEREST-EXIT
6. DATADICT.txt              line  12  : CALC-INTEREST - computes monthly interest for savings accts
7. TESTHARNESS.CBL           line  67  : PERFORM CALC-INTEREST
8. ARCHIVEJOB.CBL            line 156  : * PERFORM CALC-INTEREST (disabled 2019-03-14)

이 여덟 개의 결과 중에서 해당 단락을 제거하면 오류가 발생하는 활성 호출자는 정확히 두 개뿐입니다. 바로 3번째 줄과 5번째 줄입니다. 2번째 줄은 정의이고, 4번째 줄과 8번째 줄은 주석입니다. 6번째 줄은 데이터 사전 항목이고, 7번째 줄은 테스트 하네스입니다. 이 여덟 개의 결과 중에서 어떤 두 개가 실제 호출 사이트를 나타내는지 판단하려면 각 파일을 문맥에 맞게 읽고, COBOL 구문을 이해하고, 8번째 줄의 주석에 있는 "disabled"가 실제로 실행에 어떤 의미를 갖는지 판단해야 합니다. 텍스트 검색을 통해 필요한 자료를 얻었고, 코드 이해를 통해 해답을 찾았습니다.

침묵의 문제: 관련 결과가 나오지 않는 경우

두 번째 실패 유형은 결과 부족입니다. 즉, 텍스트 검색이 일치시킬 수 있는 형태로 표현되지 않아 구조적으로 중요한 결과가 누락되는 것입니다.

간접 호출은 검색 결과가 누락되는 가장 흔한 원인입니다. 함수 A가 함수 B를 호출하고, 함수 B가 더 이상 사용되지 않는 함수 C를 호출하는 경우, C의 이름을 텍스트로 검색하면 함수 B는 직접 호출자로 나타나지만 함수 A는 간접 호출자로 나타나지 않습니다. A가 관련 결과인지 여부는 검색 목적에 따라 다릅니다. C를 호출하는 모든 과정을 파악하는 것이 목표라면 A는 매우 중요합니다. 하지만 직접 호출자만 찾는 것이 목표라면 A는 중요하지 않습니다. 텍스트 검색은 호출 그래프라는 개념이 없기 때문에 이러한 구분을 할 수 없습니다. 텍스트 검색은 일치하는 텍스트를 반환할 뿐, 해당 텍스트가 어떤 호출의 일부인지에 대한 정보는 제공하지 않습니다.

언어 간 참조는 체계적으로 누락되는 범주입니다. 미들웨어 계층을 통해 COBOL 프로그램을 이름으로 호출하는 Java 서비스는 COBOL 프로그램 이름을 문자열 리터럴로 포함하고 있으므로 텍스트 검색으로 찾을 수 있습니다. 그러나 프로그램 이름을 동적으로 구성하거나, 구성 파일에서 읽거나, 추상화 계층을 통해 디스패치하는 동일한 Java 서비스는 프로그램 이름을 전혀 포함하지 않습니다. 이러한 호출자는 텍스트 검색을 아무리 철저하게 적용하더라도 찾을 수 없습니다. 난독 화되고 동적으로 생성된 코드에 대한 정적 분석 맥락에서 살펴보면 , 실행 경로가 구성, 템플릿 또는 런타임 디스패치 메커니즘을 통해 간접적으로 표현될 때, 이러한 경로가 나타내는 구조적 관계는 소스 파일의 텍스트만으로는 복구할 수 없습니다.

필드 별칭과 변환은 또 다른 유형의 숨겨진 오류를 발생시킵니다. COBOL 필드 이름은 다음과 같습니다. WS-ACCT-BAL 그것은 라는 이름의 데이터베이스 열에 기록됩니다. ACCT_BALANCE이후 자바 서비스에서 다음과 같이 읽힙니다. accountBalance그리고 결국에는 다음과 같이 연재되었습니다. account_balance JSON 응답에서 'is'는 동일한 데이터 요소를 나타내는 네 가지 서로 다른 텍스트 문자열을 의미합니다. 이 문자열 중 하나를 검색하면 나머지 세 개는 누락됩니다. 이 네 가지 문자열이 모두 동일한 기본 비즈니스 개념을 나타낸다는 것을 이해하려면 특정 이름의 모든 발생 위치를 찾는 것이 아니라 변환 과정을 이해해야 합니다.

코드 이해에 실제로 필요한 것은 무엇일까요?

기술적 역량으로서 코드 이해는 표면적인 텍스트가 아닌 코드의 구조와 의미론을 바탕으로 추론하여 코드에 대한 질문에 답할 수 있는 능력입니다. 이는 코드가 무엇을 말하는지가 아니라 무엇을 의미하는지를 나타내는 코드 모델을 구축하고 질의하는 것을 요구합니다.

대규모 엔터프라이즈 시스템에서 개발 작업을 지원하는 데 필요한 수준의 코드 이해에 대한 최소 기술 요구 사항은 상당합니다. 이러한 요구 사항 각각은 텍스트 검색으로는 갖추지 못한 기능이며, 텍스트 검색과 수동 작업을 결합하더라도 대규모 환경에서 안정적으로 재현할 수 없습니다.

구문 분석: 텍스트에서 구조로

텍스트 검색 다음 단계는 구문 분석입니다. 즉, 해당 언어의 문법에 따라 소스 코드를 읽고 코드 요소 간의 구문적 관계를 나타내는 구조화된 표현(일반적으로 추상 구문 트리)을 생성하는 것입니다. 구문 분석된 표현은 다음과 같습니다. PERFORM CALC-INTEREST THRU CALC-INTEREST-EXIT 문자열이 아닙니다. 이는 현재 프로그램의 단락 이름인 범위 대상을 가진 PERFORM 문임을 식별하는 구조화된 객체이며, 프로그램의 PROCEDURE DIVISION 구조에 대해 확인할 수 있습니다.

구문 분석은 언어별로 다릅니다. COBOL 파서는 COBOL 문법을 이해하고, Java 파서는 Java 문법을 이해하며, JCL 파서는 JCL 구문을 이해합니다. 다국어 엔터프라이즈 시스템에서 코드 이해를 위해서는 환경에 존재하는 모든 언어에 대한 파서가 필요하며, 이를 통해 언어에 관계없이 일관된 방식으로 추론할 수 있는 구조적 표현을 생성해야 합니다. 엔터프라이즈 규모의 TypeScript 정적 분석 에 대한 자세한 분석에서 논의되었듯이 , 코드 구성 방식, 모듈 상호 작용 방식, 애플리케이션 내 제어 및 데이터 흐름 방식을 이해하는 구조적 및 의미적 분석은 구문 검사를 넘어 진정한 코드 인텔리전스로 나아가기 위한 기본 요소입니다.

심볼 해석: 이름에서 엔티티로

구문 분석 후, 소스 코드의 이름은 해당 이름이 참조하는 엔티티로 해석되어야 합니다. 식별자 CALC-INTEREST PERFORM 문에 있는 메서드 이름은 특정 프로그램이나 카피북의 특정 단락 정의로 해석되어야 합니다. calculateLegacyFee Java 호출에서 해당 열 이름은 상속 및 오버로딩을 고려하여 특정 클래스의 특정 메서드 정의로 해석되어야 합니다. ACCT_BALANCE SQL 쿼리에서 지정된 값은 데이터베이스 스키마 내의 특정 테이블에 있는 특정 열로 해석되어야 합니다.

심볼 해석은 문자열 이름을 특정 코드 엔티티에 대한 참조로 변환하는 과정입니다. 이 참조에는 위치, 유형, 그리고 다른 엔티티와의 관계 집합이 포함됩니다. 심볼 해석이 없으면 모든 코드 쿼리는 텍스트 쿼리가 됩니다. 하지만 심볼 해석이 있으면 "이 함수를 호출하는 모든 코드"를 쿼리할 때 호출 관계의 그래프를 기반으로 하는 구조적 쿼리가 되어, 함수 이름이 우연히 나타나는 모든 파일이 아니라 실제로 특정 함수를 호출하는 코드만 반환합니다.

다국어 환경에서는 동일한 개념이 언어 경계에 따라 다르게 명명되기 때문에 기호 해석이 훨씬 더 복잡해집니다. 언어 간 색인화를 통해 복구 시간 단축 이라는 더 넓은 맥락에서 살펴보는 필드 등가성의 언어 간 해석은 언어 경계를 넘나드는 데이터 또는 제어 흐름을 추적하는 모든 구조 분석에 필수적입니다. 이것이 없으면 분석은 언어 경계에서 끝나고, 분석을 통해 얻는 이해는 불완전해집니다.

제어 흐름 분석: 실행 경로 이해하기

제어 흐름 분석은 프로그램의 가능한 실행 경로를 매핑합니다. 즉, 어떤 조건에서 어떤 분기가 실행되는지, 어떤 명령문이 도달 가능한지, 어떤 코드 경로가 실행되지 않는지, 그리고 명령문들이 서로 어떤 순서로 실행되는지를 보여줍니다. 이러한 정보는 제어 흐름 그래프로 표현되며, 노드는 순차적인 코드의 기본 블록을 나타내고, 에지는 조건부 또는 무조건적인 제어권 이동을 나타냅니다.

제어 흐름 분석은 "이 코드 경로는 어떤 조건에서 실행되는가?" 또는 "이 코드는 모든 진입점에서 접근 가능한가?"와 같은 질문에 답할 수 있게 해줍니다. 텍스트 검색으로는 이러한 질문에 답할 수 없습니다. 왜냐하면 이러한 질문은 실행 경로에 관한 것이지 문자열이 나타나는 위치에 관한 것이 아니기 때문입니다. 소스 코드에 나타나는 문장은 해당 문장이 속한 분기의 조건에 따라 실행될 수도 있고 실행되지 않을 수도 있습니다. 모듈에 정의된 함수는 실행 경로가 호출 지점에 도달하는지 여부에 따라 호출될 수도 있고 호출되지 않을 수도 있습니다. 이러한 속성을 파악할 수 있는 것은 오직 제어 흐름 분석뿐입니다. 현대화 과정에서 정적 코드 문제의 우선순위를 정하는 과정에서 살펴본 것처럼 , 실제로 어떤 코드 경로가 실행되는지, 얼마나 자주 실행되는지, 그리고 어떤 조건에서 활성화되는지를 이해하는 것이 실질적인 분석과 겉보기에는 중요해 보이지만 실제 운영 상황을 반영하지 못하는 분석을 구분하는 핵심 요소입니다.

데이터 흐름 분석: 코드 내 값 추적

데이터 흐름 분석은 프로그램 내에서 값이 어떻게 이동하는지 추적합니다. 변수에 값이 할당되는 위치, 값이 읽히는 위치, 할당과 사용 사이에 적용되는 변환, 그리고 한 변수의 값이 다른 변수의 값에 의존하는지 여부 등을 파악합니다. 이 정보는 "이 필드의 값은 어디에서 오는가?" 또는 "이 필드의 값이 변경되면 어떤 코드가 영향을 받는가?"와 같은 질문에 대한 답을 제공합니다.

데이터 흐름 분석은 값 수준에서 필드 추적, 오염 분석 및 종속성 추적을 위한 기술적 기반입니다. 프로그램의 제어 흐름 그래프에서 작동하며, 실행 경로를 따라 값 정보를 전파하고 값이 어디에서 시작되고, 어디로 흐르고, 어디에서 소비되는지를 기록합니다. 그 결과, 소스 파일의 순차적인 텍스트 영역뿐만 아니라 프로그램의 전체 실행 공간에서 정의와 사용처를 연결하는 데이터 흐름 그래프가 생성됩니다.

엔터프라이즈 시스템에서 데이터 흐름 분석은 유용하려면 언어 경계를 넘어서야 합니다. COBOL 프로그램에서 생성된 값이 데이터베이스에 기록되고 Java 서비스에서 읽히는 경우, 데이터 흐름은 두 언어 경계를 넘나듭니다. 이러한 흐름을 추적하려면 COBOL 할당 의미론, SQL 데이터 이동, Java 변수 할당을 동일한 통합 분석의 일부로 이해하는 데이터 흐름 분석이 필요합니다. 즉, 결과를 수동으로 연결해야 하는 세 가지 개별 분석으로 나누어서는 안 됩니다. COBOL 전문가(SME)에서 최신 개발 팀으로의 지식 이전 분석에서 자세히 설명했듯이 , 개발자가 COBOL 언어를 숙달하지 않고도 복잡한 COBOL 시스템을 이해할 수 있도록 하려면 소스 텍스트를 초월하는 형태로 시스템 동작을 표현할 수 있는 구조적 분석이 필수적입니다.

차이가 가장 중요한 업무들

텍스트 검색과 코드 이해의 차이는 단순히 이론적인 문제가 아닙니다. 잘못된 도구를 사용하면 결과가 완전해 보이지만 실제로는 그렇지 않은 경우가 발생하고, 불완전한 결과를 바탕으로 조치를 취할 경우 심각한 결과를 초래할 수 있는 구체적이고 중요한 개발 작업에서 이러한 차이가 드러납니다.

변경을 시행하기 전에 영향 분석을 실시하십시오.

함수 시그니처를 수정하거나, 필드 이름을 바꾸거나, 공유 유틸리티의 동작을 변경하기 전에 개발자는 어떤 부분이 영향을 받을지 알아야 합니다. 이것이 바로 영향 분석입니다. 영향 분석은 변경 대상 요소에 의존하는 모든 구성 요소를 열거하여 변경을 안전하게 수행하고 영향을 받는 모든 구성 요소를 업데이트하는 작업입니다. 영향 분석은 코드 이해 작업입니다. 구성 요소 간의 의존 관계를 파악하고, 변경 대상 요소에서부터 이러한 관계를 따라가며 의존성 트리의 모든 수준에서 영향을 받는 모든 구성 요소를 반환해야 합니다.

텍스트 검색은 변경된 요소의 이름이 나타나는 위치를 찾아 영향 분석을 대략적으로 수행합니다. 그러나 텍스트 검색은 의존성과 주석, 직접 의존성과 간접 의존성, 활성 의존성과 비활성 코드의 참조를 구분할 수 없습니다. 중요한 변경을 하기 전에 영향 분석을 위해 텍스트 검색에 의존하는 개발자는 근사치에 기반하여 안전에 매우 중요한 결정을 내리는 것입니다. 규모가 작고 단일 언어로 작성된 코드베이스에서는 이러한 근사치가 충분히 정확할 수 있습니다. 그러나 여러 언어에 걸쳐 의존성이 존재하고, 많은 서비스에서 공유 라이브러리를 사용하며, 수십 년 동안 축적된 호출 관계를 가진 엔터프라이즈 시스템에서는 텍스트 검색 결과와 실제 변경 영향 간의 차이가 상당할 수 있습니다.

널리 사용되는 데이터베이스 열의 스키마 변경에 대해 이 두 가지 접근 방식이 반환하는 결과의 차이점을 고려해 보십시오.

개발자가 알아야 할 사항	텍스트 검색 결과	코드 이해 결과
이 칼럼을 읽는 프로그램	주석을 포함하여 열 이름이 포함된 모든 파일	이 열을 참조하는 SQL SELECT 문이 있는 프로그램만 해당됩니다.
이 칼럼을 작성하는 프로그램	필터링되지 않은 동일한 목록	SQL INSERT 또는 UPDATE 문을 사용하여 이 열에 쓰는 프로그램만 해당됩니다.
이 열에 의존하는 서비스	언어 간 호환성이 없습니다.	Java, Python 및 .NET 서비스는 열을 객체 필드에 매핑합니다.
사용되지 않는 코드 참조	결과에 포함되었으나 표시되지 않음	제외되거나 별도로 표시됨
전이 종속절	보이지 않음	어떤 깊이까지든 열거 가능
완전성에 대한 확신	알 수 없는	인덱싱된 범위에 대해 검증 가능

온보딩 및 코드 탐색

대규모 코드베이스를 처음 접하는 개발자는 코드의 기능에 대한 정신적 모델을 구축해야 합니다. 즉, 구성 요소들이 어떻게 연결되는지, 시스템을 통해 어떤 데이터가 흐르는지, 어떤 프로그램이 진입점이고 어떤 프로그램이 유틸리티인지, 그리고 특정 비즈니스 프로세스의 실행 경로는 어떻게 되는지 등을 파악해야 합니다. 이러한 모델 구축 작업은 주로 코드 이해에 기반합니다. 텍스트 검색은 특정 문자열을 찾는 데는 도움이 되지만 구조적 맥락을 제공하지는 않습니다. 단어가 나타나는 위치는 찾을 수 있지만, 해당 단어가 포함된 코드가 시스템에서 어떤 역할을 하는지는 알 수 없습니다.

코드 이해 도구는 시스템 구조를 쉽게 파악할 수 있도록 함으로써 온보딩 속도를 높여줍니다. 대화형 호출 그래프는 어떤 프로그램이 다른 프로그램을 호출하는지 보여주고, 데이터 흐름 추적은 필드가 어디에서 시작되고 어디로 가는지 보여줍니다. 제어 흐름 시각화는 어떤 조건이 어떤 분기를 실행하는지 결정한다는 것을 보여주고, 종속성 맵은 어떤 구성 요소를 독립적으로 수정할 수 있고 어떤 구성 요소는 다른 팀과의 협업이 필요한지 보여줍니다. 이러한 기능들은 단순히 텍스트 검색으로 얻을 수 있는 것이 아닙니다. 코드 이해 도구가 수행하는 구조적 분석을 통해 얻을 수 있는 결과물입니다. 정적 코드 분석 의 맥락에서 살펴보면 , 수동적인 읽기가 아닌 구조적 분석을 통해 복잡성을 파악하는 능력은 개인이 머릿속에 담아둘 수 없을 정도로 큰 시스템에서 팀이 효과적으로 작업할 수 있도록 해줍니다.

사용되지 않는 코드와 요소 식별

데드 코드는 정의되었지만 실행되지 않는 코드입니다. 즉, 호출되지 않는 함수, 도달하지 않는 분기, 할당되었지만 읽히지 않는 변수 등이 이에 해당합니다. 데드 코드를 식별하는 것은 코드 이해 작업으로, 완전한 호출 그래프를 구성하고 도달 가능한 진입점에서 들어오는 호출 에지가 없는 정의된 요소를 찾아내는 것을 포함합니다. 텍스트 검색으로는 데드 코드를 식별할 수 없습니다. 데드 코드는 정의상 어디에서도 참조되지 않기 때문입니다. 참조가 없다는 것은 텍스트 검색이 찾을 수 있는 문자열이 아닙니다.

더 이상 사용되지 않는 함수를 제거할 때, 데드 코드 식별은 매우 중요합니다. 사용되지 않는 함수를 호출하는 것처럼 보이는 요소들이 실제로는 데드 코드일 수 있습니다. 즉, 해당 함수를 호출하도록 작성되었지만 실제로 호출되지 않는 함수들이 있으며, 이러한 함수들은 활성 의존성을 나타내지 않습니다. 활성 호출자와 데드 호출자를 구분하려면 일반적인 데드 코드 식별과 동일한 호출 그래프 분석이 필요합니다. 필수적인 리팩토링 기법 의 맥락에서 살펴보았듯이 , 정적 사용 분석은 함수, 레이블, 단락 또는 모듈이 호출되는지 여부를 판단하는 데 충분한 정보를 제공하며, 이러한 분석은 텍스트 발생 횟수 계산이 아닌 구조적 호출 그래프 구성을 통해서만 가능합니다.

보안 및 규정 준수 감사

보안 및 규정 준수 감사는 시스템 내에서 민감한 데이터의 흐름을 추적하는 것을 요구합니다. 즉, 개인 식별 정보가 어디에 저장되는지, 어떤 코드 경로가 해당 정보에 접근할 수 있는지, 민감한 데이터로 이어지는 모든 실행 경로에 접근 제어 검사가 올바르게 배치되었는지, 그리고 로깅, 오류 메시지 또는 API 응답을 통해 민감한 데이터가 시스템 외부로 유출될 수 있는지 여부를 파악해야 합니다. 이러한 작업은 데이터 흐름 및 제어 흐름 분석에 해당하며, 텍스트 검색으로는 제대로 수행할 수 없습니다.

민감한 필드 이름을 텍스트로 검색하면 해당 이름이 포함된 파일만 찾을 수 있습니다. 하지만 이러한 파일에 대한 접근이 허가된 것인지, 허가되지 않은 것인지, 아니면 전혀 접근하지 않은 것인지는 판단할 수 없습니다. 또한 필드 접근 경로에 접근 제어 검사가 있는지 여부도 알 수 없습니다. 필드 값이 이후 로그에 기록되거나, 해당 값이 포함되어서는 안 되는 API 응답에 포함되는지 여부도 추적할 수 없습니다. 시스템을 통해 민감한 값이 어떻게 흐르는지 추적하고 신뢰할 수 없는 출력에 도달할 수 있는 지점을 식별하는 오염 분석은 데이터 흐름 분석 기능입니다. 이는 보안에 민감한 코드 이해 도구가 제공하는 기능이며, 텍스트 검색으로는 결코 따라잡을 수 없는 부분입니다.

방법 SMART TS XL 기업 전반에 걸쳐 코드 이해도를 향상시킵니다.

SMART TS XL 이 플랫폼은 엔터프라이즈 시스템에는 텍스트 검색이 아닌 구조적 이해가 필요하다는 전제에 기반하여 구축되었습니다. 소프트웨어 인텔리전스 플랫폼은 환경 내 모든 언어와 플랫폼의 소스 코드를 분석하여 각 언어에 대한 추상 구문 트리를 생성하고, 이러한 트리를 통합된 언어 간 그래프로 변환하여 전체 시스템의 구조적 관계를 나타냅니다. COBOL 프로그램, JCL 작업 스트림, Java 서비스, .NET 애플리케이션, Python 스크립트, SQL 스키마, TypeScript 모듈 및 구성 아티팩트는 모두 이 그래프의 노드와 에지로 표현되며, 관계는 호출, 데이터 흐름, 카피북 포함, 스키마 참조 및 언어 간 동등성과 같은 유형화된 연결로 표현됩니다.

플랫폼의 엔터프라이즈 검색 기능은 코드 이해 작업을 위한 진입점을 제공하지만, 텍스트 검색과는 근본적으로 다른 방식으로 작동합니다. 검색 결과는 문자열 발생 빈도가 아닌 관계 유형 및 아티팩트 구조별로 구성됩니다. 필드 이름을 검색하면 정의, 읽기, 쓰기, SQL 참조 및 카피북 포함 항목이 각각 별도로 분류된 결과 유형으로 반환됩니다. 따라서 개발자가 "이 필드에 쓰기를 하는 것은 무엇인가?"라고 질문할 때, 필드 이름이 나타나는 모든 파일의 목록이 아닌 쓰기 관계에 대한 정확한 정보를 얻을 수 있습니다. 이러한 구조적 검색 결과 구성은 기본 상호 참조 모델을 반영하며, 개발자가 문자열 발생 빈도를 수동으로 필터링할 필요 없이 필요한 구체적이고 실행 가능한 정보를 제공합니다.

이 플랫폼의 영향 분석, 호출 그래프 탐색, 제어 흐름 시각화 및 데이터 흐름 추적 기능은 모두 동일한 통합 구조 모델을 기반으로 작동합니다. 개발자가 더 이상 사용되지 않는 함수를 발견하면 호출 그래프는 계층 구조의 모든 레벨에서 해당 함수를 호출하는 모든 호출자를 보여줍니다. 스키마 변경을 계획할 때 영향 분석은 모든 언어에 걸쳐 모든 사용자를 열거합니다. 신규 개발자가 배치 프로세스를 이해해야 할 때 제어 흐름 시각화를 통해 수백 줄의 소스 코드를 순차적으로 읽지 않고도 실행 경로를 쉽게 파악할 수 있습니다. 레거시 코드베이스의 개발자 경험 및 DX 지표라는 더 넓은 맥락에서 살펴보면 코드 복잡성과 구조적 복잡성은 유지 관리성을 결정하는 요소이며, 표면적인 텍스트뿐 아니라 이러한 구조적 속성을 드러내는 도구가 복잡한 시스템을 대규모로 관리할 수 있도록 해줍니다.

무엇과 무엇의 차이 SMART TS XL 텍스트 검색이 제공하는 것과 제공하는 것의 차이는 질문에 대한 답을 얻는 것과 질문을 시작하는 것 사이의 차이입니다. 텍스트 검색은 조사를 시작하게 하고, 코드 이해는 조사를 완료하게 합니다.

이해를 위한 탐색을 대체하는 데 드는 지속적인 비용

텍스트 검색을 코드 이해를 대신하는 수단으로 사용하는 것의 실질적인 결과는 코드베이스의 구조적 지식이 필요한 모든 개발 작업에 걸쳐 조용히 누적됩니다. 텍스트 검색에 의존하는 모든 영향 평가는 알 수 없는 수의 종속성 누락을 수반합니다. 언어 경계에서 멈추는 모든 필드 추적은 시스템의 일부를 숨깁니다. 호출 그래프 도달 가능성 분석 대신 문자열 발생 횟수를 세는 모든 데드 코드 식별은 오탐을 포함하고 실제 데드 코드를 놓칩니다. 실행 경로를 통한 데이터 흐름 추적 대신 민감한 필드 이름을 검색하는 모든 보안 감사는 불완전하고 검증 불가능한 보증만을 제공합니다.

규모가 작고 단일 언어로 작성되었으며 자주 수정되는 코드베이스에서는 이러한 비용이 감당 가능할 수 있습니다. 개발자는 검색 결과를 정확하게 필터링할 수 있는 충분한 컨텍스트를 가지고 있고, 팀의 모든 구성원이 시스템의 경계를 이해하고 있으며, 수동 검사를 통해 텍스트 검색으로 해결되지 않는 부분을 신속하게 보완하여 심각한 오류를 방지할 수 있습니다. 그러나 여러 언어로 작성되고 수십 년 동안 축적된 코드, 그리고 팀 구조상 누구도 시스템 전체를 이해하지 못하는 대규모 엔터프라이즈 시스템에서는 비용이 눈덩이처럼 불어납니다. 누락된 종속성이 프로덕션 환경에서 드러나고, 회의실에서는 확신을 주었던 영향 평가가 릴리스에서 예상치 못한 오류로 이어지며, 모든 문자열 발생을 검토한 보안 감사에서도 민감한 데이터를 노출하는 데이터 흐름 경로를 놓치게 됩니다. 또한, 이미 팀을 떠난 개발자들이 이해하고 있던 구조적 관계가 소스 파일의 어떤 문자열에도 인코딩되어 있지 않기 때문에 텍스트 검색으로는 그들의 지식을 복원할 수 없습니다.

텍스트 검색에서 코드 이해로의 전환은 단순히 한 도구를 다른 도구로 대체하는 것이 아닙니다. 텍스트 검색은 문자열 찾기, 빠른 방향 파악, 구성 검사, 파일 탐색 등 자신에게 적합한 작업에서 여전히 중요한 역할을 합니다. 반면 코드 이해는 텍스트 검색으로는 불가능한 구조적 분석을 제공합니다. 예를 들어 호출 그래프, 데이터 흐름 추적, 영향 분석, 사용되지 않는 코드 식별, 언어 간 의존성 해결 등이 있습니다. 두 도구는 서로 다른 추상화 수준에서 작동하며, 서로 다른 유형의 질문에 답하고, 서로 다른 목적을 수행합니다. 이 둘을 혼동할 경우 의존성 누락, 잘못된 평가, 그리고 시스템의 실제 동작에 대한 불완전한 모델로 인해 복잡한 시스템에 중대한 변경을 가함으로써 발생하는 위험 누적이라는 대가를 치르게 됩니다.