CodeGraph로 결제 화면 인수인계하기: 이동 경로와 제출 함수 연결하기
결제 화면을 고치다가 배송지 입력으로 돌아가는 경로를 빠뜨리는 일이 있습니다. 제출 버튼에서 다음 화면으로 넘어가는 코드만 읽으면, 화면 안쪽에 있는 배송지 확인 분기는 눈에 잘 들어오지 않습니다. 인수인계할 때 필요한 것은 URL 목록보다 어느 화면의 어느 함수가, 어떤 조건에서 이동하는지를 정리한 작은 지도입니다.
CodeGraph는 소스 코드를 분석해 함수와 파일, 라우트 사이의 관계를 그래프로 만드는 개발 도구입니다. AI 코딩 도구에 관련 코드를 전달하거나, 사람이 변경할 부분을 좁혀 읽는 데 사용할 수 있습니다. 이번에는 공식 저장소의 React Router 예제로 결제 화면 인수인계 메모를 만들어 보겠습니다.
이 글은 CodeGraph v1.6.2의 공식 문서·구현·테스트 소스를 읽고 정리했습니다. 프로그램을 설치하거나 테스트를 실행하지 않았습니다. 아래 지도는 테스트에 작성된 코드와 기대값을 재구성한 설명이며, 실제 서비스의 실행 결과가 아닙니다.
먼저 읽을 곳: 결제 화면과 그 안의 제출 함수
공식 테스트는 쇼핑몰 형태의 작은 프런트엔드를 임시로 만듭니다. App.js에서는 /payment에 PaymentScreen을 연결하고, 화면 안에는 다음 두 경로를 둡니다.
- 화면 본문:
shippingAddress.address가 없으면history.push('/shipping')을 호출합니다. - submitHandler: 폼 제출 시
savePaymentMethod(paymentMethod)를 dispatch한 뒤history.push('/placeorder')를 호출합니다.
둘 다 history.push를 쓰지만 코드가 속한 위치가 다릅니다. 첫 번째는 PaymentScreen 자신의 이동이고, 두 번째는 화면이 참조하는 내부 제출 함수의 이동입니다. 공식 테스트도 이 소유 관계를 따로 확인합니다. 라우트 연결과 이동 관계의 테스트 기대값에서 확인할 수 있습니다.
AI로 생성한 설명 이미지. 공식 테스트 소스의 배송지 확인 분기와 제출 함수 경로를 재구성했으며, 실제 화면이나 실행 결과가 아닙니다.
화면이 렌더링하는 CheckoutSteps의 /cart·/login 링크는 생략하고, 이번 수정에서 볼 두 경로만 정리했습니다.
소스에서 만든 인수인계 메모
다음 표는 위 예제를 읽고 작성한 편집용 요약입니다. CodeGraph가 출력한 표를 복사한 것은 아닙니다.
| 읽을 위치 | 코드에서 확인한 연결 | 수정할 때 함께 볼 것 |
|---|---|---|
| App.js | /payment → PaymentScreen | 화면의 진입 경로 |
| PaymentScreen.js의 화면 본문 | !shippingAddress.address → /shipping | 배송지 상태를 읽는 부분과 이동 조건 |
| PaymentScreen.js의 submitHandler | onSubmit → 결제수단 저장 요청 → /placeorder | 폼 연결, 저장 액션, 다음 화면 |
| actions/cartActions.js | savePaymentMethod → Redux 액션과 localStorage 기록 | 저장할 결제수단 값과 저장 위치 |
여기서 다음 화면으로 간다는 설명에 ‘결제 성공’을 붙이면 의미가 달라집니다. 이 예제의 제출 함수에는 결제 서버의 응답을 확인하는 코드가 없습니다. 이 코드에서 확인되는 순서는 결제수단 저장 액션 호출, 그리고 주문 확인 단계로의 이동입니다. 실제 결제 완료 여부는 별도의 코드와 실행 흐름에서 확인해야 합니다.
팀에 넘길 메모는 짧게 써도 됩니다. “PaymentScreen을 나누면 배송지 확인 분기와 submitHandler의 폼 연결을 함께 옮긴다. 결제수단 저장은 cartActions에 있으므로 해당 파일도 읽는다.” URL만 적은 목록보다 다음 사람이 열어 볼 파일이 분명해집니다.
CodeGraph가 연결해 주는 부분
공식 테스트의 Screens 결과 기대값은 /payment에서 /placeorder로 향하는 연결에 submitHandler라는 중간 경로를 둡니다. Steps 결과 기대값에는 배송지로 돌아가는 이동의 조건 !shippingAddress.address도 들어 있습니다. 따라서 이 예제에서는 화면 이동과 이를 만든 함수·조건을 함께 읽는 데 초점을 맞출 수 있습니다. Screens와 Steps의 기대값이 근거입니다.
기존에 CodeGraph를 쓰는 저장소라면 codegraph explore에 화면과 확인할 연결을 함께 적어 관련 소스와 호출 경로를 좁혀 볼 수 있습니다. 예를 들어 질문을 “PaymentScreen에서 배송지로 돌아가는 경로와 submitHandler가 /placeorder로 이동하기 전에 호출하는 코드를 찾아줘”로 잡습니다. 특정 파일이나 심볼을 자세히 읽을 때는 문서에 있는 codegraph node도 참고할 수 있습니다. 이 문장은 질문 예시이며, 이 글에서 실행해 받은 응답은 없습니다.
그래프에서 연결을 찾았으면 원문으로 돌아가 조건과 부수 효과를 읽습니다. 이 예제에서도 저장 액션이 localStorage에 값을 기록한다는 사실은 관련 함수의 본문까지 읽어야 인수인계 메모에 넣을 수 있습니다.
지도에 비어 있는 곳은 어떻게 다룰까
같은 테스트의 LoginScreen에는 쿼리 문자열에서 읽은 redirect를 history.push(redirect)에 넣는 코드가 있습니다. 이 첫 번째 예제에서는 그 목적지를 확정하지 않고, 소스에 명시된 Link to='/shipping'만 이동 관계로 확인합니다. 이런 부분은 메모에 “목적지 추가 확인”으로 남겨 두면 됩니다. 다른 예제에는 일부 문자열 대안이나 템플릿 경로를 해석하는 경우도 있으므로, 모든 계산식이 똑같이 빠진다고 일반화할 필요는 없습니다.
반대로 배열에 경로 문자열을 넣는 paths.push('/placeorder')는 화면 이동으로 취급하지 않는 기대값이 있습니다. 단순히 push라는 이름을 검색했을 때 섞이는 결과를 구분하는 대목입니다. 다만 정적 분석에서 연결이 보이지 않는다는 이유로 실제 이동이 없다고 결론 내리면 안 됩니다.
프레임워크별 차이도 있습니다. 10월 17일 등록된 Nuxt navigateTo 관련 공개 이슈에는 v1.6.2에서 이동 관계가 빠진다는 재현 보고가 있습니다. 작성자의 보고이며 여기서 재현하지는 않았습니다. React 예제에서 확인한 연결 방식을 다른 라우터에 그대로 적용하기 전에, 해당 프로젝트의 소스와 알려진 이슈를 함께 보는 편이 좋습니다.
작게 도입하고 되돌릴 준비하기
처음이라면 전체 서비스 구조도를 목표로 잡기보다 변경 예정인 화면 하나를 고릅니다. 진입 라우트, 화면 함수, 이벤트 핸들러, 이동 목적지를 한 장에 적고 원문 링크를 붙이면 작은 팀의 리뷰 자료로 쓸 수 있습니다. 그다음 주소가 없는 경우와 제출하는 경우를 실제 앱에서 확인해, 소스 기반 메모와 실행 흐름이 맞는지 비교합니다.
도입 전에는 연결할 에이전트의 현재 설정을 백업해 두세요. 시험을 마치고 사용을 중단한다면 새로 추가한 연결을 해제하고, 변경 전 설정과 비교해 해당 부분만 되돌립니다. 팀의 기존 설정까지 일괄 복원하지 않도록 변경 범위를 따로 기록해 두면 좋습니다.
구조 분석과 인덱스는 로컬에서 처리하지만, 연결한 AI 코딩 도구가 받은 소스를 외부 모델 제공자에게 보낼 수 있습니다. 또 공식 문서에는 선택적 사용 통계 설정이 별도로 안내돼 있습니다. 비공개 코드를 다룬다면 로컬 인덱싱 여부와 에이전트의 데이터 전송 설정을 각각 확인하세요.
버전과 실행 환경 메모
확인한 프로젝트는 colbymchenry/codegraph이며 npm 패키지 이름은 @colbymchenry/codegraph입니다. 이 글의 기준은 2026년 10월 3일 공개된 v1.6.2, 커밋 6560052입니다. 라이선스는 MIT입니다.
공식 README는 배포된 CLI에 Node 런타임이 포함된다고 설명합니다. 라이브러리 API를 자신의 프로그램에 넣어 쓰는 경우에는 내장 SQLite를 위해 Node 22.5 이상이 필요하다고 구분합니다. 패키지의 engines 표기는 Node 20 이상·25 미만이므로 이 표기만 보고 라이브러리 API가 Node 20에서도 동작한다고 판단하면 안 됩니다. 아래 공식 문서는 모두 같은 커밋을 가리키며, 여기서 운영체제별 설치 호환성을 직접 시험하지는 않았습니다.
10월 19일 확인한 저장소의 누적 별 수는 약 7만 4천 개였습니다. 이것만으로 최근 증가 속도를 알 수는 없습니다. 화면 이동을 함수와 조건까지 연결하는 구현을 살펴보고, 최근 재현 논의에서 적용 범위도 확인할 수 있는 프로젝트입니다.
체크아웃을 수정하는 팀이라면 먼저 “어디로 가는가” 옆에 “누가 이동시키는가”를 적어 보세요. PaymentScreen 예제에서는 배송지 확인 분기와 제출 함수가 갈라지는 지점이 보입니다. 그 작은 차이를 소스 링크와 함께 남기는 것이 이번 도구 검토의 실용적인 결과물입니다.
댓글
댓글 쓰기