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

왜 이렇게 쓰는가

이 프롬프트는 블록 5개로 짜여 있습니다

블록을 누르면 그 문단이 보입니다

역할 역할 · 누구로서 답할지

당신은 서비스가 느려졌다는 신고를 받고 원인을 찾아 온 경험이 많은 백엔드 엔지니어입니다.

역할 누구로서 답할지 ×1
재료 AI가 알아야 할 것 ×2
할 일 무엇을 어떻게 할지 ×1
결과물 어떤 모양으로 돌려받을지 ×1

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

해설 더 읽기 · 3문단

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

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

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

용어가 낯설면 아하AI에서: chain-of-thought, hallucination

나쁜 예와 비교

나쁜 예에 없는 것: 역할 · 맥락 · 단계 · 제약

흔한 나쁜 예

이 코드 너무 느린데 최적화해줘 for order in orders: ... (코드 붙여넣기)

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

변형

1

코드가 아니라 화면이 느릴 때

어느 코드가 문제인지도 모를 때 씁니다. 범위를 좁히는 순서를 먼저 받아 두면 헛되이 코드를 뒤지는 시간이 줄어듭니다.

프롬프트 보기

저희 서비스에서 특정 화면이 느리다는 신고가 들어왔습니다. 실행 환경은 {{실행 환경}}, 데이터는 {{데이터 규모}} 입니다. 코드를 보기 전에, 이 상황에서 원인이 될 수 있는 곳을 서버·데이터베이스·네트워크·브라우저로 나눠 목록으로 만들고, 각 항목을 확인할 순서와 방법을 알려 주세요. 확인이 쉬운 것부터 순서를 정해 주세요.

2

고친 뒤 부작용을 확인할 때

성능을 이유로 한 수정은 조용히 동작을 바꿔 놓기 쉽습니다. 속도 검토와 정확성 검토를 따로 요청하는 편이 안전합니다.

프롬프트 보기

아래는 성능을 이유로 제가 고친 코드입니다. 더 빠른지가 아니라, 고치면서 동작이 달라졌을 가능성만 봐 주세요. 결과 순서, 중복 처리, 오류가 났을 때의 동작, 동시에 여러 요청이 들어올 때를 각각 확인하고 문제가 될 입력의 예를 들어 주세요.

""" {{코드}} """

모델별 주의

실제 실행 시간을 재 본 숫자가 있으면 함께 붙여 넣으세요. 숫자가 없으면 AI는 코드 모양만 보고 추측할 수밖에 없습니다