“유지보수 부담을 줄이자”, “빌드 시간을 낮추자”, “접근성 문제를 정리하자”는 목표는 대개 맞는 말이지만 곧바로 개발 티켓이 되지는 않습니다. 어느 저장소의 어느 모듈을 봐야 하는지, 변경이 안전한지, 우선순위가 무엇인지 조사하는 비용이 먼저 발생하기 때문입니다.
AI 코드 스캔은 이 조사 단계를 넓게 병렬화하는 데 쓸 수 있습니다. 다만 가치는 AI가 코드를 알아서 고치는 데 있지 않습니다. 조직이 가진 포괄적 개선 목표를 근거가 붙은 변경 후보 목록으로 만들고, 그 후보를 기존의 테스트·리뷰·승인 절차에 태우는 데 있습니다.
운영 단계의 팀이라면 “스캔 결과를 얼마나 많이 PR로 바꿀 수 있는가”보다 “어떤 결과가 승인 가능한 작업인지 일관되게 가를 수 있는가”를 먼저 결정해야 합니다.
스캔에 맡길 일과 맡기지 않을 일을 먼저 가릅니다
코드 스캔은 반복되는 패턴을 넓은 범위에서 찾고, 파일·호출 경로·설정값 같은 근거를 연결해야 하는 과제에 잘 맞습니다. 반대로 제품 정책, 서비스 계약, 위험 수용 수준처럼 조직의 선택이 먼저 필요한 과제는 스캔만으로 결론을 내리기 어렵습니다.
다음 기준으로 나누면 위임 범위가 선명해집니다.
| 과제 유형 | AI 코드 스캔의 역할 | 사람의 결정이 필요한 지점 |
|---|---|---|
| 미사용 코드·중복 의존성 정리 | 후보 탐색, 참조 관계 확인, 삭제 영향 설명 | 공개 API 여부, 향후 로드맵상 보존 필요성 |
| 빌드 시간·번들 크기 개선 | 병목 후보와 의존성·빌드 설정 조사 | 개발 경험, 배포 환경, 기능 분리의 제품 영향 |
| 접근성·SEO·코딩 표준 점검 | 체크리스트 기반 누락 탐색, 일관성 점검 | 디자인 의도, 콘텐츠 우선순위, 예외 허용 여부 |
| 보안·개인정보 관련 수정 | 알려진 위험 패턴과 노출 지점의 후보 제시 | 위협 모델, 데이터 분류, 보안 책임자의 승인 |
| 대규모 프레임워크 전환 | 마이그레이션 범위와 호환성 문제 조사 | 전환 시점, 지원 종료 정책, 롤백 계획 |
| 도메인 규칙 변경 | 관련 구현 위치를 찾는 보조 수단 | 업무 규칙의 해석과 변경 권한 |
여기서 중요한 구분은 ‘발견’과 ‘결정’입니다. 예를 들어 스캔이 특정 라이브러리의 사용량이 적고 의존성 비용이 크다고 찾아낼 수는 있습니다. 그러나 그 라이브러리를 제거해도 되는지는 향후 기능 계획, 장애 대응 방식, 외부 고객과의 호환성까지 고려해야 판단할 수 있습니다.
따라서 스캔 요청도 “성능을 개선해 달라”보다 “기본 빌드에 포함되지만 특정 명령에서만 쓰이는 의존성을 찾고, 제거 또는 선택적 로딩 시 영향 범위를 제시하라”처럼 써야 합니다. 목표, 제외 범위, 판단 규칙, 산출물 형식을 함께 지정할수록 결과가 검토 가능한 작업 목록에 가까워집니다.
좋은 발견은 설명이 아니라 재현 가능한 증거를 남깁니다
스캔 결과가 길어도 개발팀이 행동할 수 없다면 백로그만 늘어납니다. 각 발견은 최소한 다음 질문에 답해야 합니다.
- 무엇이 문제인가. 코드 품질, 성능, 접근성, 운영 위험 중 어느 범주의 문제인가.
- 어디에 있는가. 저장소, 모듈, 파일, 설정, 호출 경로를 식별할 수 있는가.
- 왜 문제인가. 규칙 위반, 실제 참조 관계, 측정값, 테스트 실패 가능성 중 어떤 근거가 있는가.
- 무엇을 바꾸는가. 수정 범위와 예상되는 부작용이 드러나는가.
- 어떻게 확인하는가. 빌드, 단위 테스트, 통합 테스트, 크롤링, 정적 분석, 수동 확인 중 어떤 검증이 필요한가.
- 누가 승인하는가. 코드 소유자, 보안 담당자, 제품 담당자 중 결정권자가 분명한가.
이 기준이 없으면 AI는 그럴듯한 개선 제안을 대량으로 만들 수 있고, 개발자는 매번 처음부터 사실 여부를 조사하게 됩니다. 조사 비용을 줄이려고 도입한 스캔이 오히려 리뷰 대기열을 키우는 방식입니다.
특히 “사용되지 않는 코드”라는 판정에는 주의가 필요합니다. 정적 참조가 없어도 동적 로딩, 리플렉션, 플러그인 등록, 외부 스크립트, 운영용 수동 절차에서 쓰일 수 있습니다. 삭제 후보에는 직접 참조뿐 아니라 간접 참조와 런타임 사용 여부를 확인한 범위를 적도록 요구하는 편이 안전합니다. 확인하지 못한 영역은 ‘미확인’으로 남겨야 합니다.
PR 생성은 마지막 단계이며, 승인 규칙은 그보다 앞에 둡니다
스캔 도구가 발견 내용을 곧바로 PR로 바꿀 수 있더라도, 모든 결과를 자동 변경으로 넘길 이유는 없습니다. 운영 환경에서는 변경의 가역성과 검증 가능성에 따라 흐름을 나누는 편이 낫습니다.
1. 낮은 위험도: 제한된 조건에서 PR까지 자동화
포맷 통일, 죽은 import 제거, 명백한 오타 수정, 기계적으로 갱신 가능한 설정처럼 변경 전후를 자동 검사로 확인할 수 있는 작업이 여기에 속합니다. 조건은 분명합니다. 변경 범위가 작고, 테스트가 충분하며, 실패 시 되돌리기 쉬워야 합니다.
이 그룹은 스캔 결과에서 바로 브랜치를 만들 수 있습니다. 그래도 기본 CI, 코드 소유자 리뷰, 변경 이력은 건너뛰지 않는 편이 좋습니다. 자동 생성 PR은 승인 권한을 가진 변경이 아니라 검토 대기 중인 제안입니다.
2. 중간 위험도: 발견과 패치 초안을 분리
의존성 제거, 빌드 설정 조정, 캐시 정책 변경, 접근성 속성 보완은 코드 변경 자체는 작아 보여도 다른 환경에서 영향이 나타날 수 있습니다. 이 경우 스캔은 근거와 패치 초안까지 만들되, 담당자가 영향 범위를 확인한 뒤 PR 생성을 승인하게 두는 방식이 적절합니다.
승인자는 “변경이 맞는가”만 보지 말고 “이 변경을 검증할 환경이 있는가”를 확인해야 합니다. 예를 들어 빌드 시간 개선은 로컬 한 번의 측정만으로 판단하기 어렵습니다. CI 환경, 캐시 상태, 주요 개발 경로에서 같은 방향의 변화가 있는지 확인할 계획이 있어야 합니다.
3. 높은 위험도: 조사 보고서까지만 자동화
인증·권한, 결제, 개인정보 처리, 데이터 삭제, 공개 API, 데이터베이스 마이그레이션처럼 실패 비용이 큰 영역은 스캔을 조사 보조로 제한하는 편이 낫습니다. 여기서 AI가 제시한 수정안은 보안 검토나 설계 검토를 대체하지 않습니다.
특히 보안 관련 발견은 ‘취약점 확정’과 ‘추가 확인이 필요한 의심 지점’을 구분해야 합니다. 스캔 결과가 경보를 많이 내는 환경에서는 심각도와 신뢰도, 악용 가능성, 노출 조건을 분리하지 않으면 담당자가 중요한 문제를 놓칠 수 있습니다.
스캔 운영이 실패하는 초기 신호를 관찰합니다
도입 초기에 도구 정확도를 논하기 전에, 결과가 팀의 작업 흐름을 어떻게 바꾸는지 봐야 합니다. 다음 신호가 보이면 프롬프트나 모델보다 운영 규칙부터 손봐야 할 가능성이 큽니다.
첫째, 발견 수는 많은데 실제로 처리되는 항목이 적습니다. 우선순위 기준이 없거나, 발견마다 증거 형식이 달라 비교할 수 없을 때 흔히 생깁니다. 서비스 영향, 변경 난이도, 검증 가능성, 담당 팀을 공통 필드로 고정해 보십시오.
둘째, 리뷰어가 AI가 작성한 설명을 다시 검증하느라 더 오래 걸립니다. 이때는 발견의 품질 기준을 강화해야 합니다. 파일 링크를 늘리는 것으로 충분하지 않습니다. 어떤 경로를 조사했고, 무엇을 확인하지 못했는지까지 결과에 남겨야 합니다.
셋째, 동일한 유형의 문제가 다음 스캔에서 다시 나옵니다. 개별 PR은 병합됐지만 린트 규칙, 템플릿, CI 검사, 코드 생성기 같은 재발 방지 장치가 추가되지 않았다는 뜻일 수 있습니다. 반복되는 발견은 수정 작업이 아니라 개발 가드레일을 만드는 과제로 승격하는 편이 낫습니다.
넷째, 스캔이 코드 소유권 경계를 무시합니다. 여러 팀이 공유하는 모듈에서 수정 후보가 나오면, 기술적으로 옳은 변경도 일정과 책임 문제로 멈춥니다. 스캔 범위에 저장소뿐 아니라 서비스 소유자와 승인 경로를 포함해야 하는 이유입니다.
첫 번째 운영 단위는 작고 측정 가능해야 합니다
처음부터 “전사 기술 부채를 찾아 달라”고 요청하면 결과를 평가할 기준도 흐려집니다. 한 저장소와 한 목표를 고르십시오. 예를 들면 특정 웹 애플리케이션의 이미지 대체 텍스트 누락, 특정 워크스페이스의 빌드 의존성, 특정 서비스의 폐기 예정 API 사용처럼 범위를 제한합니다.
그다음 스캔 시작 전에 세 가지를 문서로 고정합니다. 발견이 충족해야 할 증거 기준, PR 생성이 가능한 변경 등급, 배포 후 확인할 지표입니다. 이 세 가지가 있어야 결과가 좋아도 왜 좋았는지, 결과가 나빠도 어느 단계에서 멈춰야 하는지 판단할 수 있습니다.
AI 코드 스캔을 도입하는 팀의 첫 산출물은 많은 PR이 아니라 승인 가능한 발견의 정의여야 합니다. 그 정의가 잡히면 스캔은 기술 부채 목록을 늘리는 도구가 아니라, 개선 목표를 검증과 책임이 붙은 작업 흐름으로 바꾸는 도구가 됩니다.
