AI 리팩터링 요청이 불안하다면 작은 커밋부터

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

처음엔 한 번에 고치려다 더 불안해졌습니다

큰 요청은 빠르게 보이지만 검토가 무거웠습니다

레거시 서비스의 주문 계산 함수를 처음 AI 코딩 도구에 맡겼을 때, 저는 “이 파일을 깔끔하게 리팩터링해줘”라고 요청했습니다. 결과는 그럴듯했습니다. 변수명은 좋아졌고 중복 조건문도 줄었지만, 정작 제가 해야 할 일은 줄지 않았습니다. 변경된 줄이 너무 많아서 AI 리팩터링이 맞는지, 기능이 살짝 바뀐 것인지, 테스트가 빠진 것인지 확인하는 데 시간이 더 들었습니다.

그 뒤로 방식이 완전히 바뀌었습니다. 파일 전체를 맡기기보다 함수 하나, 조건문 한 묶음, 예외 처리 한 군데처럼 작게 잘랐습니다. 체감상 가장 큰 차이는 속도가 아니라 마음의 부담이었습니다. 작은 변경은 리뷰하기 쉽고, 문제가 생기면 되돌리기도 쉽습니다. 특히 팀원이 함께 보는 저장소에서는 AI가 만든 코드보다 AI가 만든 변경 단위가 더 중요하다는 걸 느꼈습니다.

저는 보안 관련 로직에서는 더 보수적으로 접근했습니다. 인증, 결제, 개인정보, 환경 변수, 로그 출력처럼 민감한 부분은 리팩터링이 아니라 검토 요청부터 시작했습니다. 코드 보안의 기본 의미를 확인하고 싶다면 지식백과 코드 보안 설명을 같이 읽어두면 좋습니다. AI 코딩 도구는 빠른 조수지만, 보안 판단까지 자동으로 믿을 대상은 아니었습니다.

• 장점: 반복되는 조건 정리, 변수명 개선, 함수 분리 제안은 사람이 혼자 할 때보다 훨씬 빠르게 초안을 줍니다.
• 단점: 맥락이 부족하면 비즈니스 규칙을 “일반적인 코드 스타일”로 바꿔버릴 수 있습니다. 이때는 코드가 예뻐져도 제품 동작은 위험해집니다.
• 제일 좋았던 순간: 테스트는 그대로 두고 내부 구현만 바꾸라고 했을 때, 변경 범위가 좁아져 리뷰가 눈에 들어왔습니다.
• 가장 조심한 부분: 예외 메시지, 로그 레벨, 권한 체크 순서는 사용자 경험과 장애 대응에 연결되므로 자동 수정 후 반드시 직접 읽었습니다.

사용 팁: AI에게 “더 좋은 코드”를 요청하기보다 “현재 동작을 유지하면서 중복 조건만 줄여줘”처럼 금지선과 목표를 함께 말하면 결과가 훨씬 안정적입니다.

작은 커밋으로 나누니 리뷰 속도가 달라졌습니다

프롬프트는 기능보다 범위를 먼저 말했습니다

제가 계속 쓰게 된 방식은 단순합니다. 먼저 브랜치를 만들고, 테스트가 있는 파일부터 고릅니다. 그다음 AI 코딩 도구에 “새 기능 추가”가 아니라 “이 함수의 역할을 보존한 채 읽기 쉽게 나눠달라”고 말합니다. 이렇게 말하면 도구가 갑자기 구조를 크게 바꾸거나 새로운 추상화를 만들 가능성이 줄어듭니다. 코드 리뷰를 염두에 둔 요청이기 때문에 결과물도 리뷰 가능한 모양으로 나오는 편입니다.

비용도 이 방식에서 더 현실적으로 판단할 수 있었습니다. 무료 플랜이나 체험 환경에서는 컨텍스트 길이, 요청 횟수, 대기 시간이 먼저 걸립니다. 유료 플랜을 쓰더라도 “많이 생성했는가”보다 “리뷰 시간을 줄였는가”가 기준이 되어야 했습니다. 저는 하루 종일 AI에게 맡기는 날보다, 어려운 함수 세 개만 정확히 맡기는 날에 만족도가 높았습니다. 결국 개발 워크플로우에서 중요한 건 생성량이 아니라 검토 가능한 변경량이었습니다.

아래처럼 요청 범위를 나눴을 때 실패 확률이 눈에 띄게 줄었습니다. 특히 이미 테스트가 있는 저장소에서는 AI가 제안한 변경을 바로 실행해보고, 실패하면 실패 로그를 다시 붙여주는 흐름이 잘 맞았습니다. 반대로 테스트가 없는 파일은 리팩터링보다 먼저 현재 동작을 설명하게 만들었습니다. 이 과정만 거쳐도 “AI가 코드를 망쳤다”는 느낌보다 “내가 변경을 통제하고 있다”는 느낌이 강해졌습니다.

1. 먼저 테스트를 실행합니다. 실패가 없는 상태를 기준점으로 남겨야 AI 변경 후 차이를 볼 수 있습니다.
2. 수정 범위를 한 문장으로 제한합니다. 예를 들어 “calculateDiscount 함수 안의 중복 분기만 줄여줘”처럼 말합니다.
3. 새 의존성 추가를 금지합니다. 작은 리팩터링에 라이브러리가 따라오면 배포와 보안 검토가 커집니다.
4. 커밋 메시지에 AI 사용 맥락을 남깁니다. 나중에 되돌릴 때 “왜 바꿨는지”가 보이면 팀 리뷰가 편해집니다.

제가 실제로 쓴 요청문은 짧았습니다

• 좋았던 요청: 현재 테스트를 통과해야 하며, 공개 함수 시그니처는 바꾸지 말고, 중복 조건만 줄여주세요.
• 애매했던 요청: 전체적으로 더 좋은 코드로 만들어주세요. 이 말은 AI에게 너무 많은 자유를 줬습니다.
• 팀에서 반응이 좋았던 요청: 변경 전후의 동작 차이가 없다는 근거를 bullet로 설명해 주세요.

오늘 저장소에서 한 파일만 골라 맡겨보세요

잘 되는 파일과 아직 맡기면 안 되는 파일이 있었습니다

실제 사용 후기로 말하자면, 모든 파일이 AI 리팩터링에 적합하지는 않았습니다. 가장 잘 맞았던 파일은 입출력이 분명하고 테스트가 있으며, 도메인 규칙이 코드 안에 비교적 드러나는 파일이었습니다. 반대로 오래된 관리자 화면, 외부 API 예외가 얽힌 배치, 장애 대응용 임시 로직이 섞인 코드는 AI가 너무 자신 있게 단순화하려고 했습니다. 이런 파일은 리팩터링보다 “이 코드가 어떤 흐름인지 설명해줘”부터 시작하는 편이 나았습니다.

특히 코드 보안과 연결된 부분은 작은 요청이라도 근거를 남기게 했습니다. 권한 체크 위치, 토큰 검증, 민감정보 마스킹은 코드 모양보다 운영 위험이 먼저입니다. 보안 관점에서 어떤 요약 기준을 잡아야 할지 고민된다면 코드 보안 요약 항목을 참고해 용어를 맞춰두는 것도 도움이 됩니다. 팀 안에서 같은 단어를 쓰면 AI에게 주는 지시도 덜 흔들립니다.

제가 지금도 쓰는 최소 절차는 아래와 같습니다. 거창한 도입이 아니라, 오늘 작업 중인 브랜치에서 한 파일을 고르고 한 번만 실험해보는 방식입니다. 이 정도면 실패해도 잃는 것이 작고, 성공하면 다음 커밋부터 바로 반복할 수 있습니다. 개발 워크플로우에 AI를 붙이는 첫 경험은 화려한 자동화보다 이런 작은 성공이 더 오래갑니다.

• 맡기기 좋은 파일: 테스트가 있고, 함수 역할이 분명하고, 외부 상태 변경이 적은 파일입니다.
• 먼저 설명만 받아야 하는 파일: 장애 대응 코드, 권한 로직, 결제 흐름, 레거시 예외 처리가 많은 파일입니다.
• 요청 전에 적을 것: 바꾸면 안 되는 동작, 유지해야 하는 함수명, 추가하면 안 되는 의존성입니다.
• 요청 후 볼 것: 테스트 결과, 변경 줄 수, 삭제된 예외 처리, 로그 메시지 변화입니다.

복사해서 쓸 요청문: 이 파일에서 가장 작은 리팩터링 후보 하나만 골라 주세요. 현재 동작은 유지하고, 공개 함수명과 반환값은 바꾸지 마세요. 변경 이유와 위험한 부분을 함께 설명해 주세요.

1. 현재 브랜치에서 테스트가 있는 파일 하나를 고릅니다.
2. AI에게 전체 수정이 아니라 “가장 작은 후보 하나”만 고르게 합니다.
3. 제안이 마음에 들면 그 부분만 적용하고 테스트를 다시 실행합니다.
4. 리뷰 화면에서 변경 줄 수가 부담스럽다면 즉시 범위를 더 줄입니다.

지금 당장 해볼 행동은 하나면 충분합니다. 저장소에서 테스트가 붙어 있는 함수 하나를 열고, 위 요청문을 그대로 붙여 넣은 뒤 AI가 고른 리팩터링 후보를 읽어보세요. 적용은 나중이어도 괜찮습니다. 먼저 “이 정도 변경이면 내가 리뷰할 수 있겠다”는 감각을 잡는 것이 AI 코딩을 오래 쓰는 출발점입니다.