배포 직전의 AI 생성 코드가 요구사항을 통과했고, 리뷰어도 겉보기 오류를 찾지 못했다면 어디까지 고쳐야 할까. 모든 코드를 즉시 정리하려 하면 기능 개발이 늦어지고, 반대로 “동작하니 나중에 보자”를 반복하면 다음 변경 때 누구도 안전하게 손댈 수 없는 영역이 늘어난다.
운영 단계의 조직에는 둘 중 하나만 고르는 답이 맞지 않다. AI가 만든 코드도 일반 코드와 마찬가지로 변경할 가능성, 변경 결과를 검증할 수 있는 정도, 실패했을 때의 업무 영향, 책임자가 분명한지를 기준으로 나눠야 한다. 중요한 것은 AI가 코드를 얼마나 빨리 생산했는지가 아니라, 팀이 그 코드를 다음 변경에서도 통제할 수 있는가다.
리팩터링 대상은 보기 싫은 코드가 아니라 통제하기 어려운 코드다
리팩터링은 기능을 새로 만드는 작업이 아니다. 외부에서 관찰되는 동작을 유지하면서 내부 구조를 바꾸는 작업이다. 작은 변경을 연속해서 적용하고, 각 단계에서 테스트로 동작이 유지되는지 확인할 수 있을 때 위험을 낮출 수 있다.
따라서 “AI가 생성한 코드가 길다”, “스타일이 팀 취향과 다르다”만으로 즉시 리팩터링을 결정할 이유는 부족하다. 반대로 짧은 코드라도 다음 상황이면 우선순위를 높게 잡는 편이 낫다.
- 한 함수나 모듈이 여러 업무 규칙을 함께 판단한다.
- 데이터 조회, 권한 확인, 계산, 외부 호출, 화면용 변환이 한 흐름에 뒤섞여 있다.
- 수정하려면 여러 파일과 서비스의 호출 순서를 동시에 추적해야 한다.
- 오류가 나도 어느 규칙, 어느 입력, 어느 외부 연동에서 문제가 생겼는지 분리해 알기 어렵다.
- 담당자가 바뀌었을 때 코드의 의도와 수정 범위를 설명할 사람이 없다.
이런 코드는 현재 기능이 정상이어도 다음 요구사항이 들어오는 순간 비용을 만든다. AI가 생성한 코드에서는 특히 비슷한 로직의 중복, 지나치게 넓은 예외 처리, 호출 책임이 불명확한 추상화가 섞일 수 있다. 코드가 자동 생성됐다는 사실보다, 팀이 변경 결과를 예상할 수 없다는 사실을 경고 신호로 봐야 한다.
네 가지 질문으로 즉시 수정과 조건부 허용을 나눈다
CTO나 개발 리드는 PR 리뷰와 운영 개선 계획에서 아래 네 질문을 같은 순서로 적용할 수 있다. 하나의 점수로 기계적으로 판정하기보다, 어느 질문에서 위험이 겹치는지 확인하는 방식이 적합하다.
| 판단 축 | 확인할 질문 | 즉시 리팩터링 쪽으로 기우는 조건 |
|---|---|---|
| 테스트 가능성 | 변경 후 기존 동작이 유지됐는지 빠르게 확인할 수 있는가 | 핵심 분기, 오류 처리, 권한 규칙을 검증하는 테스트가 없거나 실행 결과를 신뢰하기 어렵다 |
| 복잡도 | 한 사람이 수정 범위와 영향 경로를 설명할 수 있는가 | 한 코드 단위에 여러 업무 책임이 섞였고, 조건문과 외부 의존성이 얽혀 있다 |
| 변경 빈도 | 가까운 시일 안에 같은 영역을 다시 바꿀 가능성이 높은가 | 정책, 요금, 권한, 상품, 화면 흐름처럼 요구사항이 자주 조정되는 영역이다 |
| 업무 영향도 | 잘못 변경됐을 때 고객, 운영자, 재무, 보안에 어떤 일이 생기는가 | 접근 권한, 정산, 계약 상태, 주문 처리, 고객 통지처럼 오류를 되돌리기 어렵다 |
네 축 가운데 업무 영향도와 테스트 가능성은 함께 봐야 한다. 영향이 큰데 테스트가 약한 코드는 리팩터링 이전에 검증 장치부터 보강해야 한다. 구조를 깨끗하게 만드는 작업보다, 현재 동작을 재현하고 변경 결과를 확인할 수 있게 만드는 일이 먼저다.
반대로 영향이 제한적이고, 변경 가능성이 낮으며, 명확한 테스트가 있는 코드는 조건부로 허용할 수 있다. 예를 들어 일회성 내부 관리 화면이나 교체 예정인 실험 기능이라면, 구조 개선보다 기능 종료 또는 교체 시점을 기록하는 편이 합리적일 수 있다. 다만 조건부 허용은 방치가 아니다. 누가 언제까지 책임질지와 재검토 조건을 남겨야 한다.
“나중에 고친다”를 허용하려면 종료 조건을 적는다
AI가 만든 코드를 당장 리팩터링하지 않기로 했다면 PR이나 작업 기록에 최소한 세 가지를 남긴다.
첫째, 허용한 이유다. 변경 빈도가 낮은지, 영향 범위가 제한적인지, 대체 계획이 있는지 적는다. “시간이 없다”는 이유만으로는 다음 담당자가 위험을 판단할 수 없다.
둘째, 다시 열어볼 조건이다. 같은 모듈에 두 번째 기능 변경이 들어올 때, 운영 오류가 발생했을 때, 다른 서비스가 이 모듈을 호출하게 될 때처럼 구체적인 계기를 둔다. 변경 빈도는 처음부터 정확히 예측하기 어렵기 때문에, 실제 변화가 나타났을 때 결정을 갱신할 장치가 필요하다.
셋째, 현재 확보된 검증 범위다. 어떤 입력과 결과를 테스트하는지, 테스트하지 못한 외부 연동이나 예외 흐름은 무엇인지 적어야 한다. 이 기록이 있어야 후속 개발자가 “테스트가 있다”는 말과 “중요한 동작이 검증됐다”는 말을 구분할 수 있다.
조건부 허용은 기술 부채를 없애는 선택이 아니다. 부채의 위치, 책임자, 상환 시점을 보이게 만드는 선택이다.
테스트가 없으면 큰 정리보다 관찰 가능한 경계부터 만든다
테스트가 빈약한 코드에 대규모 구조 변경을 시작하면, 개선 작업 자체가 장애 원인이 될 수 있다. 이때는 설계를 이상적으로 바꾸려는 목표보다 먼저 현재 동작을 붙잡아야 한다.
우선 입력과 출력이 비교적 명확한 경계를 찾는다. 예를 들어 계산 로직, 상태 전환 규칙, 요청값 변환처럼 외부 시스템 없이 결과를 확인할 수 있는 부분이다. 그 부분의 현재 동작을 테스트로 고정한 뒤, 작은 단위로 이름을 바꾸거나 중복을 줄이거나 책임을 분리한다.
외부 API, 데이터베이스, 메시지 처리처럼 실행 결과가 환경에 따라 달라지는 영역은 호출 자체를 한곳으로 모으는 작업이 도움이 될 수 있다. 이는 외부 연동을 추상화하라는 형식적 요구가 아니다. 장애가 났을 때 호출 위치와 실패 처리 규칙을 찾을 수 있게 하려는 목적이다.
이 과정에서 팀은 AI에게도 더 구체적인 작업을 맡길 수 있다. “이 기능을 리팩터링해 달라”보다 “현재 테스트를 통과하는 범위에서 이 계산 규칙을 별도 함수로 분리하고, 바뀌면 안 되는 입출력 사례를 테스트로 추가하라”가 검토하기 쉽다. AI의 산출물을 받아들이는 기준도 구현 속도가 아니라 검증 가능한 변경 단위가 된다.
책임 경계가 흐린 코드는 기능이 맞아도 멈춰 세워야 한다
AI는 요구사항을 바탕으로 데이터 모델, API 호출, 권한 판단, 화면 처리 코드를 한 번에 연결할 수 있다. 문제는 코드가 연결됐다는 사실이 책임까지 정리했다는 뜻은 아니라는 점이다.
다음 질문에 답하기 어렵다면, 기능이 정상이어도 구조 개선을 우선 검토할 만하다.
- 이 규칙이 바뀌면 제품 담당자와 개발팀 중 누가 변경을 승인하는가?
- 고객 상태를 바꾸는 권한 판단은 어느 계층에서 하는가?
- 외부 서비스 오류가 발생했을 때 재시도, 취소, 운영자 확인 중 무엇을 선택하는가?
- 같은 업무 규칙이 웹, 관리자 화면, 배치 작업에 중복되어 있지는 않은가?
- 오류가 발생했을 때 운영자가 확인할 기록과 개발자가 확인할 기록은 구분되어 있는가?
여기서 리팩터링의 목표는 코드를 더 세련되게 보이게 만드는 일이 아니다. 업무 규칙의 소유자, 변경 승인자, 시스템 실패 시 대응 책임을 코드와 운영 절차에서 찾을 수 있게 만드는 일이다.
운영 조직은 리팩터링 백로그를 기능 백로그와 분리해 관리해야 한다
AI 도입 뒤 기능 요청이 빨라지면 리팩터링은 눈에 보이지 않는 후순위 업무가 되기 쉽다. 그러나 변경이 잦고 영향이 큰 영역의 구조 문제를 계속 미루면, 나중에는 기능 개발 일정 안에서 더 큰 비용을 치르게 된다.
다음 계획 회의에서는 AI 생성 코드 전체를 정리 대상으로 잡기보다, 최근 변경이 반복된 업무 흐름 하나를 고르는 편이 좋다. 그 흐름에 대해 테스트 범위, 얽힌 책임, 변경 요청의 종류, 장애 시 영향만 먼저 확인한다. 그다음 “이번 변경에 포함할 구조 개선”과 “조건부로 남기되 재검토할 항목”을 나눈다.
AI 시대의 리팩터링 역량은 더 빠르게 코드를 다시 쓰는 능력이 아니다. 어떤 코드는 즉시 멈춰 세우고, 어떤 코드는 제한된 조건 아래 통과시키며, 어느 시점에 다시 판단할지를 팀이 합의하는 능력에 가깝다. 그 기준이 있어야 생산 속도가 늘어도 코드베이스의 통제력은 줄지 않는다.
