느린 코드에서 병목 후보 찾기

고친 코드 대신 후보 3개가 가능성 순으로 나왔고, 후보마다 직접 재 볼 방법이 붙었다.

1순위 — 반복문 안의 개별 조회. 3천 행이면 쿼리도 3천 번이고, 왕복 1밀리초만 잡아도 호출당 3초입니다. 확인: 커서 실행 이벤트로 호출당 쿼리 수를 세어 3천 근처인지 본다. 고치면: user_id 를 모아 한 번에 조회해 쿼리가 3천에서 1~2회로 줄어든다.

인덱스 유무, calc_fee 내부의 조회 여부처럼 코드에 없는 정보 5가지도 목록으로 나왔다.

코드 성능 개선 프롬프트를 "빠르게 고쳐 줘" 로 시작하면, AI는 눈에 보이는 곳부터 손을 봅니다. 반복문을 축약 문법으로 바꾸고 변수를 합치는 수정이 잔뜩 붙는데, 정작 시간을 다 잡아먹는 것은 반복문 안에서 매번 데이터베이스를 부르는 한 줄인 경우가 많습니다. 측정 없이 시작하면 효과 없는 수정만 늘어납니다.

역할 을 "원인을 찾아 온 엔지니어" 로 두면 답의 성격이 바뀝니다. 코드 리뷰어에게 물으면 변수 이름과 스타일 지적이 먼저 나오고, 원인을 찾는 사람에게 물으면 시간이 어디로 새는지부터 봅니다. 같은 코드라도 누구에게 묻느냐에 따라 답의 첫 문단이 달라집니다.

단계 를 넷으로 못 박은 것이 이 프롬프트의 중심입니다. 후보를 순서대로 세우게 하면 근거를 적을 수밖에 없고, 확인 방법까지 요구하면 추측과 사실이 분리됩니다. 특히 3번은 "고쳐 준 것을 믿고 배포" 하는 대신 직접 숫자를 보고 판단하게 만듭니다. AI에게 느린 쿼리 최적화를 맡길 때도 마찬가지여서, 흔한 조언은 3번을 건너뛰고 4번만 말합니다.

맥락의 두 값도 그냥 붙인 것이 아닙니다. 400만 행과 400행은 문제의 종류가 다릅니다. 제약 에서 "체감 차이가 없을 미세한 최적화는 빼라" 고 한 것은 이 규모를 기준으로 걸러 달라는 뜻이고, "보이지 않는 정보는 목록으로" 는 인덱스가 있는지 모르는 채 인덱스를 추가하라고 하는 답을 막습니다. 코드는 """ 로 감싸 주석이 지시로 읽히지 않게 합니다.

데이터가 얼마나 되는지 모르니 AI는 일반론을 폅니다. 리스트를 집합으로 바꾸고 반복문을 컴프리헨션으로 고친 코드가 돌아오는데, 실행 시간은 그대로입니다. 반복문 안의 데이터베이스 호출이 진짜 원인이어도 근거를 요구하지 않았으니 여러 제안 중 하나로만 묻혀 나오고, 고친 코드를 그대로 받았으니 무엇을 재 봐야 하는지도 남지 않습니다.