결과 예시
아직 실제 결과를 확인하지 않았습니다. 확인 후 예시가 채워집니다.
왜 이렇게 쓰는가
리팩터링 프롬프트에서 가장 자주 겪는 사고는, "이 함수 좀 정리해 줘"라고 했더니 깔끔해 보이는 새 코드가 통째로 나오고 그것을 붙여 넣은 뒤에야 동작이 달라졌다는 것을 아는 경우입니다. 어디서 틀어졌는지 찾으려면 결국 두 코드를 한 줄씩 대조해야 합니다.
역할을 "남이 만든 코드베이스를 관리해 온 개발자"로 둔 것은 태도를 정하기 위해서입니다. 남의 코드를 오래 만진 사람은 마음대로 구조를 바꾸지 않습니다. 과제 문단에서 "겉으로 드러나는 동작"을 입력과 출력, 예외, 부수 효과로 풀어 쓴 이유도 같습니다. 그냥 "동작을 유지해 주세요"라고 하면 반환값만 맞추고 메일 전송 순서는 바꿔 놓습니다.
제약은 변수로 받습니다. 팀마다 못 바꾸는 것이 다르고, 함수 이름 하나가 바뀌면 호출하는 쪽이 전부 깨지기 때문입니다. 조건과 충돌하면 고치지 말고 이유만 말하라고 한 것은, AI가 제약을 슬쩍 어기고 더 좋은 코드를 내미는 일을 막습니다.
계획을 먼저 받고 "진행"이라고 답할 때 코드를 쓰게 한 것이 이 프롬프트의 중심입니다. 한 번에 다 받으면 검토할 것이 너무 많아 그냥 믿고 붙여 넣게 됩니다. 이렇게 이어서 다듬으면 함수 하나마다 확인할 수 있고, 마음에 안 드는 이름이나 경계는 계획 단계에서 바로잡을 수 있습니다. 함수 분리 ai 도구를 쓸 때도 순서는 같습니다.
계획 표에 "인자와 반환값" 열을 넣은 것도 작은 장치입니다. 이름과 역할만 정하면 쪼갠 함수들이 서로 전역 변수를 주고받는 구조가 되기 쉬운데, 무엇을 받고 무엇을 돌려주는지 먼저 적게 하면 그 경계가 계획 단계에서 드러납니다.
용어가 낯설면 아하AI에서: role-prompting, output-format
나쁜 예와 비교
이 함수 너무 긴데 리팩토링 해줘
(코드 붙여넣기)
전혀 다른 모양의 코드가 한 번에 나오고, 그 안에서 조건 하나가 조용히 뒤집혀 있습니다. 어떤 조건을 지켜야 하는지 말하지 않았으니 새 라이브러리가 끼어들거나 함수 이름이 바뀌어 호출하는 쪽이 깨지기도 합니다. 무엇을 왜 바꿨는지 설명도 없어 검토가 사실상 불가능하고, 결국 원래 코드로 되돌리게 됩니다.
변형
쪼개기 전에 무슨 일을 하는지부터 알고 싶을 때
아래 {{언어}} 함수가 하는 일을 위에서부터 순서대로 번호를 붙여 나열해 주세요. 각 줄은 "무엇을 한다"로 짧게 쓰고, 조건 분기는 어떤 경우에 어디로 가는지 함께 적어 주세요. 고치자는 제안은 하지 마세요.
""" {{코드}} """
남이 짠 함수를 물려받았을 때 먼저 씁니다. 고치자는 제안을 막아야 이해와 수정이 섞이지 않습니다.
중복된 코드만 걷어낼 때
당신은 {{언어}} 개발자입니다. 아래 코드에서 같은 일을 반복하는 부분만 찾아 주세요. 반복이 세 번 이상 나오는 것만 대상으로 하고, 묶었을 때 오히려 읽기 어려워지는 것은 제외해 주세요. 찾은 것마다 "반복되는 부분 · 몇 번 나오는지 · 묶은 뒤 코드" 순으로 보여 주고, {{지켜야 할 조건}}은 지켜 주세요.
""" {{코드}} """
구조를 바꾸지 않고 중복만 줄이고 싶을 때 씁니다. "세 번 이상"이라는 기준이 없으면 두 번 나온 두 줄까지 함수로 빼내 오히려 읽기 어려워집니다.
모델별 주의
함수가 길수록 한 번에 다 고치려 하면 뒷부분이 잘립니다. 계획을 먼저 받고 한 덩어리씩 진행하세요
관련 프롬프트
마지막 수정 2026-09-02 · 잘못된 점이 있나요? 알려 주세요