처음 보는 코드의 전체 흐름 파악하기

폴더 여섯 곳의 역할이 확신 상·중·하와 함께 나왔고, 경로는 자료가 끊긴 지점에서 멈췄다.

1. controller/ 요청을 받는 자리 (상) · mapper/ SQL 매핑으로 추정 (하)
2. POST /api/orders → OrderController.create → OrderService.place → (자료 없음)
3. 끊긴 곳: place 안의 재고 차감 여부, repository와 mapper 중 어느 쪽으로 DB에 닿는지
4. 다음 파일: OrderService.java, application.yml, SchedulerConfig.java

받은 파일 3개를 붙여 넣고 변형의 "이어서 채우기"로 넘어가면 된다.

코드 분석을 chatgpt 에 맡길 때 흔한 실수는 파일을 잔뜩 붙여 넣고 "이 프로젝트 설명해 줘" 라고 하는 것입니다. 돌아오는 것은 "주문과 재고를 관리하는 서비스입니다" 수준의 요약인데, 이런 문장은 이미 알고 있는 내용이라 다음에 어느 파일을 열지 정하는 데 아무 도움이 안 됩니다.

그래서 이 프롬프트는 한 번에 다 읽지 않고 여러 차례로 나눠 진행합니다. 첫 요청에서는 폴더 목록과 파일 하나만 주고, 답 안에 "다음에 넣을 파일 3개" 를 받아 그다음 요청을 만듭니다. 이렇게 하면 한 번에 넣을 수 있는 분량 한계에 걸리지 않고, 매 차례마다 지도가 조금씩 넓어집니다. 답의 마지막이 다음 요청의 재료가 되니 무엇을 물어야 할지 고민할 일도 없습니다.

단계 를 넷으로 정한 것에도 순서의 이유가 있습니다. 폴더 역할을 먼저 추정해 두면 그다음에 나오는 함수 이름이 어디에 속하는지 자리를 잡고, 요청 하나가 지나가는 경로를 이어 붙이면 남의 코드 이해하기의 핵심인 "이 파일이 언제 불리는가" 가 손에 잡힙니다. 3번의 "끊긴 지점" 이 곧 다음에 읽을 곳이라, 읽는 순서를 스스로 정하지 않아도 됩니다.

제약 의 두 줄은 지도를 믿을 수 있게 만듭니다. 확신도 표시와 "추정" 표시가 없으면 추측과 확인된 사실이 같은 문장으로 섞여 나오고, 그 지도를 믿고 코드를 고치다 시간을 잃습니다. 자료를 """ 로 감싸는 것은 코드 주석이 지시로 읽히는 것을 막기 위해서입니다.

분량이 많아 요약 수준의 설명만 돌아오고, 자료에 없는 파일까지 프레임워크 관례로 짐작해 그럴듯하게 적어 넣습니다. 어디까지가 확인된 사실인지 구분이 없어 그대로 믿기 어렵고, 다음에 무엇을 읽어야 할지도 알 수 없어 결국 처음부터 다시 뒤지게 됩니다. 답이 길어질수록 앞에 넣은 파일의 내용은 흐려져, 두 번째 질문부터는 엉뚱한 파일 이름이 섞여 나오기도 합니다.