DB부터 화면까지, 코드 변경의 영향을 따라가는 Cascade

주문 상태를 저장하는 DB 컬럼의 길이를 늘린다고 해보겠습니다. 테이블 정의에서 수정할 곳을 찾는 일은 어렵지 않습니다. 그런데 수정을 끝내고 나면 다른 질문이 남습니다.

이 값을 읽는 코드는 어디에 있고, 어느 화면까지 다시 확인해야 할까요?

컬럼 이름을 검색하면 데이터를 읽고 쓰는 SQL은 찾을 수 있습니다. 그 SQL을 부르는 서버 코드를 따라가고, 서버에 요청을 보내는 화면도 찾아야 합니다. 코드를 고친 사람에게는 익숙한 연결이라도, 검토하는 사람이 같은 흐름을 이해하려면 다시 소스를 열어봐야 합니다. 변경된 파일 목록만으로는 이 범위가 잘 드러나지 않습니다.

제가 만들고 있는 Cascade는 이 연결을 살펴보는 도구입니다. DB 컬럼에서 SQL과 서버 코드를 거쳐 화면까지, 반대로 화면에서 데이터가 있는 곳까지 따라갈 수 있도록 소스의 관계를 모읍니다. 그 사이에는 화면이 서버에 작업을 요청하는 창구인 API가 있습니다. ALEXSOFT의 공개 오픈소스 프로젝트로 개발하고 있습니다.

연결 경로와 근거를 함께 읽습니다

프로그램을 구성하는 요소와 그 사이의 관계를 모으면 하나의 지도가 됩니다. Cascade에서는 이것을 변경 영향 지식 그래프라고 부릅니다. 이름은 조금 거창하지만, 알고 싶은 것은 구체적입니다. 이 컬럼을 읽는 SQL은 무엇이고, 그 SQL을 실행하는 기능과 사용자 화면은 어디인지입니다.

현재는 Java Spring과 MyBatis 계열의 서버, DB 테이블 정의, JavaScript·TypeScript로 작성한 웹 코드와 Vue·React의 화면 경로 등을 읽습니다. 소스를 실행하지 않고 연결을 찾는 정적 분석이 바탕입니다.

같은 선으로 보이는 연결도 근거는 서로 다릅니다. 소스에서 직접 확인한 관계인지, 실행할 수 있는 후보인지, 실행 기록에서 관측한 관계인지에 따라 읽는 방식이 달라집니다. Cascade는 연결마다 이 근거를 등급으로 표시합니다.

검토자는 화면에 이른 경로를 따라가며 어떤 코드를 확인해야 하는지 살펴볼 수 있습니다. 개발자가 찾아본 연결을 검토자도 같은 화면에서 이어서 읽을 수 있다는 점에 의미가 있습니다.

변경 목록을 검토할 수 있는 보고서로

최근에는 변경 전후를 비교하는 부분을 다듬었습니다. 기존에도 두 시점의 분석 결과를 비교할 수 있었지만, 같은 이름을 가진 요소 안에서 내용이 달라진 경우까지 더 잘 읽을 필요가 있었습니다. 컬럼 이름은 그대로인데 타입이 달라지거나, 같은 서버 메서드(처리 함수)에 트랜잭션 표시가 붙는 경우입니다. 트랜잭션은 여러 데이터 작업을 한 묶음으로 처리하는 단위를 말합니다.

검증용으로 만든 작은 주문 예제에서 DB 정의의 VARCHAR(16)을 VARCHAR(64)로 바꾸고, 서버 메서드에 트랜잭션 표시를 추가하고, 화면 이름도 바꿨습니다. API 하나를 추가하고 다른 하나를 삭제하는 변경도 함께 넣었습니다. Spring·MyBatis·Vue로 구성한 합성 주문 예제입니다.

그 비교에서는 속성이 바뀐 요소 세 개와 관련 API 세 개, 화면 한 개가 나왔습니다. 이 숫자는 예제에 넣은 여러 변경을 함께 분석한 결과입니다.

보고서에서는 컬럼 타입의 이전 값과 새 값을 나란히 읽을 수 있습니다. 내용이 바뀐 것과 소스의 파일·줄 위치만 이동한 것도 구분합니다. 검토자는 실제 값의 변화부터 읽고, 위치 이동은 따로 확인할 수 있습니다.

원본 크기로 보기 ↗

이번에 다듬은 Compare 화면은 위에서부터 한 편의 보고서로 읽도록 구성했습니다. 어느 시점끼리 비교했는지, 두 시점을 같은 조건으로 분석했는지부터 보여 줍니다. 그다음 변경 요약과 관련 API·화면, 이전 값과 새 값이 이어집니다. 현재 빌드에 남아 있는 항목은 Flow 화면으로 열어 연결을 더 따라갈 수 있습니다.

보고서는 Markdown 파일로 저장하거나 인쇄할 수도 있습니다. 비교 기준과 분석 조건, 변경 내역이 함께 남아 다른 사람이 같은 근거로 검토를 이어갈 수 있습니다.

원본을 대조하며 비교 결과를 다듬었습니다

이번 작업에서는 Codex와 Claude가 분석 엔진과 보고서 화면을 나누어 작업하고, 실제 응답과 화면을 교차 검토했습니다. 테스트를 통과한 뒤에는 합성 예제의 원본 기록과 보고서가 맞는지 하나씩 대조했습니다.

처음 보고서에는 실제로 바뀌지 않은 연결 근거 일곱 건이 변경으로 표시됐습니다. 원본 기록에는 차이가 없었는데, 조회를 위해 한쪽 데이터에 채운 빈 값이 비교에 섞여 들어간 것이 원인이었습니다. 두 시점의 원본 기록을 같은 기준으로 비교하도록 바로잡은 뒤, 같은 예제에서 불필요한 일곱 건이 사라지는지 확인했습니다.

수정 후에는 명령줄과 AI 연결 도구, 화면이 같은 비교 결과를 보여 주는지도 확인했습니다. 어느 쪽에서 검토를 시작하더라도 같은 변경을 읽을 수 있도록 하는 작업이었습니다.

Cascade를 이렇게 발전시켜 가려 합니다

우선은 분석 품질을 더 다듬으려 합니다. 실제 프로젝트에서 만난 코드와 연결 관계를 재현 가능한 검증 사례로 남기고, 이미 운영하는 회귀 검사와 공개 저장소 기반 측정을 보강할 생각입니다. 분석 방식을 고쳤을 때 기존에 읽던 연결도 계속 잘 읽는지 확인하는 데 이런 사례들이 쓰입니다.

분석 범위도 실제 프로젝트가 요구하는 순서로 넓혀가려 합니다. 지금의 Java·DB·웹 연결을 바탕으로 프레임워크별 코드 구조와 동적으로 결정되는 관계를 더 다양하게 읽는 방향입니다. 브라우저 요청 기록인 HAR과 서버의 실행 경로를 남기는 OpenTelemetry 기록을 읽는 기능은 이미 있습니다. 앞으로는 이 실행 기록과 정적 분석 결과를 더 잘 대조해, 소스에서 찾은 후보 경로와 실행 중 관측된 경로를 나란히 읽을 수 있도록 다듬고 싶습니다.

개발자의 평소 변경 검토에도 더 자연스럽게 이어지면 좋겠습니다. 기존 명령줄 도구와 변경 비교, 내보내기를 바탕으로 코드 리뷰와 자동 검사 과정에서 보고서를 쉽게 읽고, 먼저 확인할 지점과 테스트할 범위를 고르는 데 도움을 주려 합니다.

사람과 AI가 같은 근거를 읽게 하는 것도 이어갈 방향입니다. Cascade에는 이미 AI 에이전트가 분석 결과를 요청하는 연결 방식인 MCP가 있습니다. 개발자가 화면에서 읽는 연결 경로와 근거 등급을 에이전트도 같은 기준으로 사용하고, 왜 그 부분을 검토해야 하는지 설명할 수 있도록 다듬으려 합니다. 실제 사용에서 자주 만나는 검토 과제를 기준으로 개발 순서도 잡아가겠습니다.

코드를 검토하다 보면 “여기까지 확인했습니다”라고 설명해야 할 때가 있습니다. 어떤 변경을 확인했고, 어떤 연결을 따라 검토했는지 함께 보여 주고 싶습니다. Cascade를 그런 설명에 쓸 수 있는 도구로 계속 만들어가려 합니다.