IMS는 단순히 구식 시스템이라는 의미가 아닙니다. 주요 은행의 매출채권 관리, 보험 회사의 정책 관리, 의료 보험사의 청구 처리 등을 담당하는 데이터베이스 엔진입니다. IBM은 IMS를 계속해서 개발하고 있습니다. 문제는 IMS가 작동을 멈췄다는 것이 아니라, 계층적 세그먼트 트리 구조를 다룰 줄 아는 개발자들이 모두 은퇴하고, IMS 기반 시스템을 변경할 때마다 SQL이 없는 데이터 모델을 이해해야 하며, IMS를 관계형 데이터베이스처럼 취급하는 모든 마이그레이션 계획은 그 차이를 뼈아프게 깨닫게 된다는 점입니다.
어려운 점은 마이그레이션 도중에 COBOL 프로그램이 단순한 키 조회 방식이 아니라 계층적 탐색을 통해 IMS에 접근한다는 사실을 발견하는 것입니다. 이 계층적 탐색 방식은 대상 시스템에서도 동일한 탐색 로직으로 구현되어야 합니다. 또는 두 개의 물리적 IMS 데이터베이스 간의 논리적 관계가 데이터베이스 설계 문서(DBD)에 완전히 문서화되지 않은 종속성을 생성하고, 마이그레이션 과정에서 두 데이터베이스가 독립적으로 변환되면서 해당 논리적 관계를 사용하는 모든 프로그램이 오류로 인해 작동하지 않게 된 것을 발견하는 경우도 있습니다. 혹은 대부분의 마이그레이션 계획에서 고려조차 하지 않는 구조인 보조 인덱스 데이터베이스가 중요한 보고 프로그램이 데이터에 접근하는 유일한 경로였다는 사실을 발견하는 경우도 있습니다.
이러한 놀라운 사실들은 엄격한 이주 전 의존성 분석과 접촉하면 사라지지만, 기존의 가정과 접촉하면 살아남습니다.
IMS 종속성 분석이 다른 점은 무엇일까요?
관계형 데이터베이스 환경(DB2, Oracle, SQL Server 등)에서의 종속성 분석은 잘 알려진 경로를 따릅니다. 애플리케이션 코드의 SQL을 분석하고, 테이블 및 열 참조를 식별하고, 어떤 프로그램이 어떤 테이블에 접근하는지 매핑한 다음, 이 매핑을 사용하여 마이그레이션 범위와 순서를 결정합니다. 구조는 명확하며, 종속성은 SQL 텍스트에서 확인할 수 있습니다.
IMS 종속성 분석은 모든 측면에서 더욱 복잡해졌습니다.
구조는 계층적이며, 관계적이지 않습니다. IMS 데이터베이스는 세그먼트 유형의 트리 구조로 구성되어 있으며, 각 세그먼트 유형은 정의된 부모-자식 관계를 갖습니다. IMS 데이터베이스에서 환자 기록을 읽는 COBOL 프로그램은 실행되지 않습니다. SELECT * FROM PATIENTS WHERE ID = ?이 프로그램은 계층 구조를 탐색하여 루트 세그먼트로 이동하기 위해 Get Unique(GU) 호출을 실행한 다음, 자식 세그먼트를 탐색하기 위해 Get Next Within Parent(GNP) 호출을 실행합니다. 프로그램의 의존성은 테이블이 아니라 계층 구조를 통한 특정 경로에 있으며, 해당 구조를 변경하면 SQL 수준 분석으로는 감지할 수 없는 방식으로 해당 구조를 탐색하는 프로그램이 제대로 작동하지 않을 수 있습니다.
종속성은 세 개의 서로 다른 구조에 분산되어 있습니다. COBOL 프로그램이 IMS를 사용하여 수행하는 작업을 전체적으로 파악하려면 다음 사항들을 분석해야 합니다.
- DBD(데이터베이스 설명자): 물리적 세그먼트 계층 구조, 주요 필드, 액세스 방식(HDAM, HIDAM, HISAM, HSAM) 및 보조 인덱스 또는 논리적 관계를 정의합니다.
- PSB(프로그램 명세 블록): 프로그램이 어떤 데이터베이스에 접근할 수 있는지, 어떤 PCB를 통해 접근할 수 있는지, 어떤 민감도 및 의도 사양을 사용할 수 있는지를 정의합니다.
- COBOL 소스 코드: 여기에는 어떤 세그먼트에 어떤 호출 함수를 사용하여 어떤 순서로 어떤 SSA를 통해 액세스하는지를 결정하는 실제 DL/I 호출이 포함됩니다.
어떤 단일 소스도 전체적인 상황을 완벽하게 보여주지는 않습니다. COBOL 소스 코드만 읽는 분석은 호출 유형과 세그먼트 이름만 보여줄 뿐 물리적 데이터베이스 구조는 알 수 없습니다. 마찬가지로 DBD와 PSB만 읽는 분석은 프로그램이 수행할 수 있는 작업만 보여줄 뿐 실제로 수행하는 작업은 알 수 없습니다.
탐색은 위치에 따라 달라집니다. 관계형 데이터베이스에서는 모든 행을 키를 통해 독립적으로 접근할 수 있습니다. 하지만 IMS에서는 프로그램의 현재 위치가 계층 구조에서 이후 호출의 반환 값에 영향을 미칩니다. GN(Get Next) 호출은 프로그램의 현재 위치에서 계층 구조 순서대로 다음 세그먼트를 반환합니다. 이러한 의존성은 세그먼트 유형뿐만 아니라 현재 위치에 도달한 경로에도 적용됩니다. IMS의 암묵적인 계층 구조 순서에 의존하는 프로그램은 데이터가 관계형 데이터베이스로 마이그레이션될 때 이러한 의존성이 사라지게 됩니다. 관계형 데이터베이스에서는 이와 동등한 순서가 보장되지 않기 때문입니다.
DL/I 호출 목록: COBOL 소스 코드가 드러내는 것
마이그레이션 전에 가장 직접적으로 유용한 분석은 IMS에 액세스하는 모든 COBOL 프로그램의 모든 DL/I 호출에 대한 완전한 목록입니다. 이 목록을 통해 마이그레이션 팀은 각 프로그램이 IMS에서 무엇을 하는지, 즉 허용된 작업(PSB에서 정의)이 아니라 실제로 무엇을 하는지 알 수 있습니다.
COBOL에서 DL/I 호출은 두 가지 형태로 나타납니다.
코볼
* Form 1: EXEC DLI interface (CICS-compatible, high-level syntax)
EXEC DLI
GU DB2PCB
SEGMENT(CUSTROOT)
WHERE(CUSTID = WS-CUST-ID)
END-EXEC
* Form 2: xxxTDLI call interface (batch programs, assembler-compatible)
CALL 'CBLTDLI' USING WS-FUNCTION-CODE
PCB-CUSTOMER
WS-CUSTOMER-SEGMENT
WS-SSA-CUSTOMER두 형식 모두 동일한 분석 정보를 포함합니다. 즉, 기능 코드, 사용 중인 PCB, 대상 세그먼트, 그리고 선택적으로 호출을 한정하는 SSA(세그먼트 검색 인수)가 포함됩니다. 완전한 DL/I 호출 목록은 모든 프로그램에서 이 모든 정보를 추출합니다.
함수 코드 분류 체계 및 마이그레이션에 대한 시사점
DL/I 함수 코드는 각 호출에서 마이그레이션에 가장 중요한 요소입니다. 각 함수 코드는 대상 관계형 데이터베이스에서 반드시 복제되어야 하는 서로 다른 데이터 액세스 패턴을 의미합니다.
읽기 전용 함수: GUGet Unique: 적격 SSA를 사용하여 세그먼트로 직접 이동합니다. 관계형 데이터베이스에서 WHERE 절이 있는 SELECT 문과 동일합니다. 세그먼트 키가 관계형 기본 키에 깔끔하게 매핑되는 경우 마이그레이션이 간단합니다.
GNGet Next: 계층적 순서에서 다음 세그먼트로 이동합니다. 이 함수 코드는 직접적인 관계형 대응어가 없으며, IMS의 위치 상태와 암묵적인 순서에 의존합니다. GN을 광범위하게 사용하는 프로그램은 어떤 순서에 의존하는지 신중하게 분석해야 합니다.
GNPGet Next Within Parent: 현재 부모 세그먼트의 다음 자식을 검색합니다. 외래 키 관계에서 모든 행을 가져오는 것과 동일합니다. 일반적으로 외래 키 WHERE 절이 있는 SELECT 문과 깔끔하게 매핑됩니다.
유지 기능(업데이트를 위한 전제 조건): GHU, GHN, GHNPGU, GN, GNP에 해당하는 Hold 호출을 가져옵니다. "hold" 플래그는 업데이트(REPL) 또는 삭제(DLET) 작업이 뒤따를 것임을 나타냅니다. hold 호출을 사용하는 프로그램은 읽기-수정-쓰기 프로그램이므로 마이그레이션은 hold 및 후속 업데이트 전반에 걸쳐 트랜잭션 무결성을 유지해야 합니다.
업데이트 기능: ISRT삽입: 새 세그먼트 발생을 추가합니다. INSERT와 동일합니다. DLET삭제: 현재 유지 중인 세그먼트와 해당 세그먼트의 모든 종속 세그먼트를 제거합니다. "모든 종속 세그먼트" 제거 동작은 IMS 관련 계층적 처리 방식이므로 대상 시스템에 명시적으로 구현해야 합니다. REPLReplace: 현재 저장된 세그먼트를 새 데이터로 업데이트합니다. UPDATE와 동일한 기능입니다.
이것이 마이그레이션 범위에 중요한 이유는 다음과 같습니다. GU 및 GNP 호출만 사용하는 프로그램은 IMS 데이터를 읽기 전용으로 소비하므로 마이그레이션 위험이 낮고 검증이 간단합니다. GHU, REPL 및 DLET를 사용하는 프로그램은 계층 구조를 수정하는 트랜잭션 처리 프로그램이므로 마이그레이션 시 IMS가 현재 원자적으로 보장하는 작업 전반에 걸친 트랜잭션 무결성을 유지해야 합니다.
모든 이주를 망치는 세 가지 유형의 의존 관계
논리적 관계
IMS의 논리적 관계는 물리적으로 분리된 두 데이터베이스의 세그먼트를 연결합니다. 데이터베이스 A의 논리적 자식 세그먼트는 데이터베이스 B의 논리적 부모 세그먼트를 가집니다. COBOL 프로그램이 논리적 관계를 통해 탐색할 때, 데이터베이스 경계를 물리적으로 가로지르는 경로를 따라 이동하게 되는데, IMS는 이러한 경로를 투명하게 관리하지만 데이터베이스를 독립적으로 마이그레이션할 경우 이 경로는 사라집니다.
논리적 관계는 IMS 마이그레이션에서 가장 위험한 종속성 유형입니다. 그 이유는 COBOL 소스 코드에서 논리적 관계를 확인할 수 없기 때문입니다. COBOL 프로그램은 GNP를 호출하여 세그먼트의 자식을 가져옵니다. 이때 GNP 호출이 물리적 부모-자식 관계를 거치는지, 논리적 관계를 거치는지는 COBOL 코드가 아닌 PSB와 DBD에 의해 결정됩니다. COBOL 소스 코드만 분석하는 마이그레이션 팀은 PSB와 DBD를 별도로 분석하지 않고는 GNP 호출이 논리적 관계 경계를 넘는지 여부를 알 수 없습니다.
논리적 관계를 사용하는 프로그램은 마이그레이션 과정에서 대상 시스템에 논리적 관계의 의미론(일반적으로 관계형 모델의 JOIN)을 복제하고, 해당 관계를 사용하는 모든 프로그램이 IMS 논리적 탐색에서 받은 것과 동일한 JOIN 결과를 받는지 검증해야 합니다.
보조 색인 데이터베이스
IMS 보조 인덱스 데이터베이스는 기본 데이터베이스에 대한 대체 액세스 경로를 제공하여 프로그램이 루트 키가 아닌 다른 필드를 사용하여 세그먼트를 검색할 수 있도록 합니다. 보조 인덱스 데이터베이스는 자체 DBD를 가진 별도의 IMS 데이터베이스이지만, 해당 데이터는 기본 데이터베이스에서 파생됩니다.
마이그레이션 팀은 계획 단계보다는 분석 단계에서 보조 인덱스 데이터베이스를 발견하는 경우가 많은데, 그 이유는 다음과 같습니다.
- 이러한 DBD는 기본 데이터베이스 DBD와 항상 함께 그룹화되지는 않는 DBD에 정의되어 있습니다.
- 보조 인덱스를 사용하는 프로그램은 PSB(프로그램 서비스)에서 인덱스 데이터베이스의 이름을 지정하지만, 보조 인덱스를 통해 기본 데이터베이스로 이동하는 프로그램은 COBOL 소스 코드에서 이를 명확하게 나타내지 않을 수 있습니다.
- 문서에는 기본 데이터베이스에 대한 설명이 포함될 수 있지만, 보조 인덱스에 대한 언급은 없을 수도 있습니다.
보조 인덱스를 통해 IMS에 액세스하는 프로그램은 대상 시스템에서 기본 키가 아닌 인덱스 또는 다른 쿼리 전략으로 복제되어야 하는 액세스 패턴 종속성을 가지고 있습니다. 마이그레이션 중에 이 부분을 누락하면 프로그램은 오류 없이 실행되지만 원하는 레코드를 찾을 수 없습니다.
GSAM 데이터베이스
GSAM(Generalized Sequential Access Method) 데이터베이스는 IMS의 순차 배치 처리 인터페이스로, COBOL 배치 프로그램이 기능적으로 순차적인 파일 I/O 작업을 DL/I 호출을 통해 수행할 수 있도록 합니다. GSAM 데이터베이스는 세그먼트 계층 구조를 가지지 않고, IMS를 통해 접근하는 평면 순차 구조로 되어 있어 IMS의 복구 및 재시작 기능을 활용할 수 있습니다.
GSAM 데이터베이스를 사용하는 프로그램은 IMS의 체크포인트/재시작 기능을 복구 동작에 활용하는 배치 프로그램입니다. 마이그레이션 시에는 이러한 복구 동작을 유지하거나 대상 플랫폼에서 동등한 메커니즘으로 대체해야 합니다.
이주 전 의존 관계 목록 구축
완전한 IMS 종속성 분석을 통해 마이그레이션 범위, 위험 및 순서를 정의하는 6가지 결과물이 생성됩니다.
결과물 1: PCB-데이터베이스 매핑
모든 PSB의 모든 PCB는 특정 DBD(특정 IMS 데이터베이스)에 매핑됩니다. 모든 PSB에 걸쳐 모든 PCB를 나열하고 각각을 해당 DBD에 매핑하면 어떤 프로그램이 어떤 데이터베이스에 접근할 수 있는지에 대한 정확한 목록을 얻을 수 있습니다. 이는 스코프를 이해하는 출발점이지만, 프로그램이 실제로 사용하는 데이터베이스보다 더 많은 데이터베이스를 포함하는 PSB를 가질 수 있으므로 실제 종속성을 과장할 수 있습니다.
산출물 2: 프로그램별 실제 통화량
모든 COBOL 프로그램의 DL/I 호출을 분석하면 실제 사용 목록을 얻을 수 있습니다. 즉, 각 프로그램이 실제로 호출하는 PCB, 사용하는 함수 코드, 액세스하는 세그먼트 유형, 그리고 적격 SSA(세그먼트 키 액세스)를 사용하는지 또는 비적격 탐색(위치 순회)을 사용하는지 여부를 알 수 있습니다. 이를 통해 PSB에 정의된 권한에서 실제 프로그램 동작으로 범위를 좁힐 수 있습니다.
결과물 3: 논리적 관계 사용 맵
호출 목록을 DBD와 상호 참조하면 어떤 프로그램의 GNP 또는 GN 호출이 논리적 관계를 거치는지 확인할 수 있습니다. 이를 위해서는 COBOL 소스 코드와 PSB뿐만 아니라 어떤 부모-자식 관계가 물리적이고 어떤 관계가 논리적인지를 정의하는 DBD 구조까지 분석해야 합니다.
산출물 4: 보조 색인 사용 지도
PSB에 보조 인덱스 데이터베이스 이름을 지정하거나 루트 키 필드가 아닌 필드를 참조하는 SSA 호출을 실행하는 프로그램은 보조 인덱스 사용자로 식별됩니다. 이 맵 문서에는 어떤 보조 인덱스가 존재하는지, 어떤 기본 데이터베이스를 지원하는지, 그리고 어떤 프로그램이 보조 인덱스에 의존하는지가 나와 있습니다.
산출물 5: 데이터베이스별 통화 유형 분포
대상 IMS 데이터베이스 각각에 대해, 해당 데이터베이스에 접근하는 모든 프로그램에서 나타나는 호출 유형의 분포는 마이그레이션의 복잡성을 나타냅니다.
- 읽기 함수(GU, GN, GNP)로만 접근하는 데이터베이스는 마이그레이션이 더 간단합니다.
- 보류 기능 및 업데이트(GHU + REPL, GHN + DLET)에서 액세스하는 데이터베이스는 트랜잭션 무결성 복제가 필요합니다.
- GN 사용량이 높은 데이터베이스는 위치 기반 내비게이션 종속성을 나타내므로 순서 분석이 필요합니다.
- 논리적 관계를 가진 데이터베이스는 대상에서 데이터베이스 간 JOIN 의미 체계를 필요로 합니다.
산출물 6: 프로그램 위험 분류
호출 유형 분포와 종속성 유형 목록을 사용하여 각 프로그램을 마이그레이션 위험도에 따라 분류합니다.
적격 SSA를 사용하여 GU 및 GNP만 사용하고, 논리적 관계가 없는 단일 데이터베이스에 액세스하며, 홀드/업데이트 호출이 없는 프로그램은 초기 마이그레이션 단계에서 가장 위험도가 낮은 후보입니다. 반면 GN을 광범위하게 사용하고, 논리적 관계를 통해 여러 데이터베이스에 액세스하거나, 복잡한 홀드/업데이트 시퀀스를 수행하는 프로그램은 마이그레이션 전에 가장 철저한 분석 및 검증이 필요한 가장 위험도가 높은 프로그램입니다.
이번 분석이 이주 계획에 어떤 변화를 가져오는가
의존성 분석은 단순히 현재 상황을 기록하는 데 그치지 않고, 이후의 의사결정을 변화시킵니다.
순서 결정. 논리적 관계를 통해 IMS 데이터베이스를 공유하는 프로그램은 독립적으로 마이그레이션할 수 없습니다. 프로그램 A가 프로그램 B의 루트 세그먼트와 동일한 데이터베이스에 있는 논리적 부모 세그먼트를 가진 논리적 자식 세그먼트를 읽는 경우, B를 마이그레이션하지 않고(또는 브리지를 생성하지 않고) A만 마이그레이션하면 A가 작동하지 않습니다. 종속성 그래프는 어떤 프로그램이 함께 마이그레이션되어야 하는지를 결정합니다.
대상 설계 결정. 호출 유형 분포는 대상 관계형 스키마의 구조를 결정하는 데 중요한 역할을 합니다. 키로 한정된 GU 및 GNP 호출을 통해서만 접근하는 계층적 부모-자식 관계는 대상에서 외래 키 관계로 깔끔하게 변환됩니다. 위치 종속성을 사용하는 GN 호출을 통해 접근하는 동일한 관계의 경우, 대상 스키마는 명시적인 ORDER BY 절, 시퀀스 필드 또는 동일한 결과를 달성하는 다른 접근 패턴을 통해 동일한 순서를 유지해야 합니다.
검증 범위 결정. 분석을 통해 IMS 데이터를 읽기 전용으로 소비하는 프로그램과 트랜잭션 처리 프로그램을 구분합니다. 읽기 전용 프로그램은 원래 IMS 시스템과 마이그레이션된 시스템 간의 출력 결과를 비교하여 검증할 수 있습니다. 트랜잭션 처리 프로그램은 트랜잭션 동등성 테스트를 통해 대상 시스템에 대한 동일한 일련의 작업이 원래 시스템과 동일한 데이터 상태 변화를 생성하는지 확인해야 합니다.
위험 분류. 논리적 관계 및 보조 지표 분석 결과는 위험 분류의 주요 입력값입니다. 모든 마이그레이션 프로그램에는 위험 등록부가 있습니다. IMS 종속성 분석은 팀에게 등록부에 어떤 항목을 추가해야 하는지 알려줍니다.
방법 SMART TS XL IMS 종속성 분석을 수행합니다.
SMART TS XL의 정적 코드 분석 이 도구는 모든 COBOL 프로그램의 DL/I 호출(EXEC DLI 및 xxxTDLI 호출 인터페이스 형식 모두 포함)을 분석하여 각 호출에서 기능 코드, PCB 참조, 세그먼트 이름 및 SSA 구조를 추출합니다. 이를 통해 실행 중인 IMS 시스템이나 수동 코드 검토 없이 전체 COBOL 포트폴리오에 걸쳐 프로그램 수준의 실제 호출 목록을 생성할 수 있습니다.
애플리케이션 종속성 매핑은 이러한 인벤토리를 프로그램 간 종속성 그래프로 확장합니다. 즉, 어떤 프로그램이 어떤 IMS 데이터베이스에 대한 접근 권한을 공유하는지, 어떤 프로그램이 동일한 PCB를 사용하는지, 어떤 프로그램의 접근 패턴이 중복되어 조정된 마이그레이션이 필요한지 등을 나타냅니다. 논리적 관계가 데이터베이스 간의 세그먼트를 연결하는 경우, 종속성 맵은 이러한 데이터베이스 간 연결을 대상 시스템에서 반드시 유지해야 하는 명시적인 관계로 표현합니다.
영향 분석 기능은 모든 마이그레이션 팀이 데이터베이스 변환 전에 반드시 답해야 하는 질문, 즉 이 IMS 데이터베이스를 마이그레이션할 경우 어떤 프로그램이 영향을 받는지, 어떤 액세스 패턴을 복제해야 하는지, 그리고 동등성을 확인하기 위해 어떤 테스트 케이스를 검증해야 하는지에 대한 답을 제공합니다. 이 답은 추정치가 아니라 실제 DL/I 호출 인벤토리에서 도출된 열거형 목록입니다.
JCL 확장 기능은 운영 컨텍스트를 추가합니다. 즉, 어떤 JCL 작업 단계가 어떤 프로그램을 호출하고, 어떤 순서로 어떤 PSB 사양을 사용하여 IMS에 액세스하는지를 지정합니다. 여러 프로그램을 통해 IMS 데이터를 처리하는 배치 작업 시퀀스인 운영 종속성 체인은 프로그램 수준의 액세스 패턴만큼 마이그레이션 계획에 중요합니다. 데이터베이스를 마이그레이션할 때 이를 둘러싼 배치 작업 오케스트레이션을 마이그레이션하지 않으면, 개별적으로는 레코드를 올바르게 처리하는 시스템이 생성되지만, 프로덕션 환경에서 작업 시퀀스가 실행될 때 오류가 발생합니다.
진행하는 팀의 경우 레거시 현대화 IMS 지원 시스템에서 생성된 구조적 증거 SMART TS XL 이는 이후 모든 마이그레이션 결정의 입력값입니다. 어떤 프로그램을 어떤 단계에서 마이그레이션할지, 어떤 데이터베이스를 독립적으로 변환할 수 있고 어떤 데이터베이스는 조정된 변환이 필요한지, 어떤 액세스 패턴은 직접 변환보다는 재설계가 필요한지 등을 결정합니다. 이는 앞서 설명한 맥락에서 이해할 수 있습니다. COBOL 프로그램과 함께 IMS 및 VSAM 구조를 마이그레이션합니다.COBOL 프로그램과 기존 데이터 구조 간의 상호 연결로 인해 데이터 마이그레이션과 코드 분석은 병렬적으로 진행되어야 하며, 종속성 목록은 병렬 계획을 가능하게 하는 메커니즘입니다.
재고는 이주가 아닙니다
IMS 종속성 분석은 지식을 생성합니다. 마이그레이션에는 여전히 의사 결정, 엔지니어링 및 검증이 필요합니다. 분석을 통해 달라지는 것은 의사 결정의 질, 엔지니어링 범위의 완성도, 그리고 검증의 신뢰도입니다.
IMS 데이터베이스를 성공적으로 마이그레이션하는 조직은 가장 촉박한 일정이나 가장 큰 마이그레이션 예산을 가진 조직이 아닙니다. 그들은 마이그레이션을 시작하기 전에 데이터베이스를 정확히 파악하고 있었습니다. 각 데이터베이스에 접근하는 모든 프로그램, 각 프로그램의 접근 패턴을 드러내는 모든 함수 코드, 데이터베이스 간 종속성을 생성하는 모든 논리적 관계, 명시적인 복제 없이는 변환 과정에서 유지되지 않는 접근 경로를 제공하는 모든 보조 인덱스까지 말입니다.
그러한 지식은 문서에서 얻는 것이 아닙니다. 코드를 분석함으로써 얻는 것입니다.
