릴리스는 빨라졌는데 장애를 고칠 사람은 줄어드는 상황이 있다. PR은 짧은 시간에 많이 올라오지만, 왜 이 코드가 필요한지, 어떤 예외를 막는지, 다음 변경에서 어디를 건드려야 하는지를 설명할 수 있는 사람이 없다면 생산성 향상은 오래가지 못한다.
AI 코딩 도구의 문제를 “코드가 틀릴 수 있다”는 수준에서만 다루면 대응도 테스트 추가나 리뷰 강화에 머문다. 더 어려운 문제는 생성된 코드가 팀의 설계 의도, 운영 지식, 책임 분담 안에 편입되지 못하는 데 있다. 코드가 저장소에 들어간 순간부터는 생성 도구가 아니라 팀이 수정, 검증, 장애 대응, 보안 조치를 맡아야 하기 때문이다.
AI가 작성한 코드를 어디까지 허용할지 정할 때 CTO와 개발 리드는 도구의 생성 능력보다 사람이 이해하고 인수할 수 있는 경계를 먼저 정해야 한다.
실패는 코드량보다 맥락의 단절에서 시작된다
AI는 함수, 클래스, 테스트, 설정 파일처럼 비교적 작은 단위부터 여러 파일에 걸친 변경까지 생성할 수 있다. 하지만 코드가 문법적으로 자연스럽고 테스트를 통과한다고 해서 서비스 맥락까지 이해한 것은 아니다.
운영 환경에서 중요한 질문은 대개 코드 바깥에 있다.
- 이 분기문은 어떤 고객 계약이나 운영 규칙을 반영하는가
- 이 재시도 로직은 외부 시스템의 어떤 실패를 전제로 하는가
- 이 데이터 변환은 이전 버전과의 호환성을 왜 유지해야 하는가
- 이 권한 검사는 어느 경로에서 우회되면 안 되는가
- 장애가 났을 때 누가 어떤 지표와 로그를 보고 원인을 좁힐 수 있는가
생성 과정에서 이런 질문의 답이 PR 설명, 설계 문서, 테스트 이름, 운영 문서에 남지 않으면 코드는 쌓여도 조직의 이해는 쌓이지 않는다. 이후 개발자는 기존 동작을 확신하지 못한 채 다시 AI에 설명을 요청하고, 도구는 저장소의 일부 단서만 바탕으로 또 다른 추정을 내놓는다. 이 과정이 반복되면 변경 비용은 낮아지는 대신 판단 비용이 누적된다.
특히 기능 단위로는 그럴듯하지만 시스템 전체의 규칙과 충돌하는 코드가 위험하다. 각 변경은 작은 편의 기능처럼 보이는데, 시간이 지나면 동일한 예외 처리, 서로 다른 인증 방식, 중복된 변환 규칙, 설명되지 않은 설정값이 남는다. 팀은 코드가 많아서가 아니라 어느 부분이 현재의 정답인지 몰라서 느려진다.
조기 신호는 “AI 사용량”이 아니라 인수 실패에서 보인다
AI 생성 비율 자체는 건강도를 보여 주지 않는다. 같은 비율이라도 한 팀은 생성물을 잘게 나누어 검증하고, 다른 팀은 큰 변경을 이해하지 못한 채 병합할 수 있다. 운영 단계에서 봐야 할 신호는 다음과 같다.
PR 작성자가 변경 이유를 설명하지 못한다
리뷰어가 “왜 이 방식이어야 하는가”, “대안은 무엇이었는가”, “실패하면 어떻게 되돌리는가”를 물었을 때 작성자가 생성 프롬프트나 도구의 설명으로 답을 대신한다면 인수가 끝나지 않은 상태다. 작성자가 코드를 타이핑하지 않았더라도, 병합을 요청하는 사람은 변경의 의도와 제한을 설명할 수 있어야 한다.
테스트가 동작만 확인하고 경계를 설명하지 못한다
AI는 테스트 코드도 빠르게 만들 수 있다. 그러나 정상 입력과 예상 출력만 확인하는 테스트는 권한, 데이터 손상, 중복 요청, 외부 연동 실패처럼 운영에서 중요한 경계를 놓칠 수 있다. 테스트 이름과 시나리오가 “무엇을 기대하는가”보다 “어떤 위험을 막는가”를 드러내지 못하면, 팀은 다음 변경 때 보호해야 할 조건을 잃는다.
리뷰가 문법과 스타일 검사로 축소된다
코드 리뷰에는 자동화하기 좋은 항목이 있다. 형식, 명명 규칙, 일부 관용구, 알려진 금지 패턴은 도구가 점검할 수 있다. 반면 변경이 서비스 동작과 운영에 미치는 영향, 설계 선택의 타당성, 예외 상황의 책임은 사람의 판단이 남는다.
코드 리뷰 자동화 연구도 이런 구분을 전제로 한다. 자동화는 일부 코딩 관행을 확인할 수 있지만, 기여 코드의 의미와 파급 효과까지 모두 대신 검토하지는 못한다. AI가 작성한 PR일수록 “스타일을 통과했는가”와 “우리 시스템에 들어와도 되는가”를 별도 질문으로 다뤄야 한다.
수정 속도는 빠른데 장애 분석 시간이 길어진다
새 기능을 만드는 시간은 줄었지만, 장애가 발생했을 때 변경 이력을 따라가거나 책임 모듈을 찾는 시간이 늘어난다면 코드 소유권이 약해졌을 가능성을 점검할 만하다. 이 신호만으로 AI가 원인이라고 단정할 수는 없다. 다만 생성량 증가와 함께 나타난다면, 팀이 변경을 이해한 뒤 병합하는지 확인해야 한다.
허용 범위는 업무 종류가 아니라 인수 난이도로 나눈다
“개발자는 써도 되고 비개발자는 안 된다”거나 “테스트 코드는 허용하고 제품 코드는 금지한다”는 식의 구분만으로는 부족하다. 같은 제품 코드라도 영향 범위와 복구 가능성이 다르기 때문이다.
조직 정책은 아래 네 질문으로 경계를 정하는 편이 더 실용적이다.
| 판단 질문 | 허용 범위를 넓혀 볼 조건 | 사람의 설계·검증을 강화할 조건 |
|---|---|---|
| 실패를 쉽게 되돌릴 수 있는가 | 격리된 내부 도구, 독립적인 보조 기능 | 데이터 변경, 외부 연동, 비가역 처리 |
| 영향 범위를 파악할 수 있는가 | 호출 경로와 사용자 범위가 명확함 | 여러 서비스, 고객별 정책, 공용 라이브러리에 영향 |
| 기대 동작을 테스트로 표현할 수 있는가 | 입력·출력과 실패 조건이 명확함 | 업무 규칙이 문서화되지 않았거나 예외가 많음 |
| 담당자가 운영까지 인수할 수 있는가 | 수정자 또는 명확한 오너가 장애 대응 가능 | 생성자와 운영자가 분리되고 책임자가 불명확함 |
이 표는 위험도를 자동 계산하는 규칙이 아니라, 병합 전에 팀이 합의해야 할 질문 목록이다. 네 항목 중 하나라도 답하기 어렵다면 AI 사용을 금지해야 한다는 뜻은 아니다. 대신 생성 범위를 줄이거나, 설계 검토와 인수 기준을 더 명확히 둘 이유가 생긴다.
예를 들어 반복적인 데이터 포맷 변환이나 기존 패턴을 따른 테스트 보완은 비교적 좁은 경계 안에서 검토할 수 있다. 반면 인증·권한, 결제나 정산 상태, 고객 데이터 접근, 운영 설정, 배포 자동화처럼 실수의 영향이 큰 영역은 “AI가 만들 수 있는가”보다 “사람이 변경의 결과를 설명하고 복구할 수 있는가”를 통과 기준으로 삼아야 한다.
품질 검증은 일반 체크리스트만으로 끝나지 않는다
최근 대규모 비교 연구에서는 AI 생성 코드와 사람이 작성한 코드가 서로 다른 결함 특성을 보였고, AI 생성 코드에서 고위험 보안 취약점이 더 많이 관찰됐다고 보고했다. 해당 결과가 모든 모델, 언어, 조직에 같은 비율로 적용된다고 볼 수는 없다. 다만 AI 생성 코드를 기존 품질 관리 절차에 그대로 흘려보내기보다, 별도의 점검 초점을 둘 근거는 된다.
AI 생성 변경에 추가할 검토 질문은 다음처럼 구체적이어야 한다.
- 사용하지 않는 코드, 임시 디버깅 흔적, 하드코딩된 값이 남지 않았는가
- 보안 검토가 필요한 입력 처리, 인증, 권한 확인, 비밀 정보 접근이 포함됐는가
- 기존 모듈의 책임을 복제하거나 우회하는 새 경로가 생기지 않았는가
- 오류 처리와 재시도 동작이 호출하는 외부 시스템의 조건과 맞는가
- 생성된 의존성, 라이선스 조건, 버전 선택을 사람이 확인했는가
- 작성자 외에 이 변경을 수정할 수 있는 담당자가 있는가
여기서 중요한 점은 AI 코드에만 더 엄격한 형식 규칙을 적용하는 것이 아니다. 생성 속도가 빨라질수록 사람의 검토 시간은 희소해진다. 따라서 모든 줄을 같은 깊이로 읽기보다, 보안·데이터·상태 변경·외부 연동처럼 잘못됐을 때 큰 비용이 드는 경로에 검토를 집중해야 한다.
“생성 허용”과 “병합 허용”을 분리해야 한다
조직이 AI 코딩 도구를 도입할 때 가장 먼저 정할 문장은 사용 허가 여부가 아니라 병합 기준이다. 개인 개발자가 초안 작성, 코드 탐색, 테스트 보조에 AI를 쓰는 것과 조직 저장소에 변경을 반영하는 것은 다른 결정이다.
운영 가능한 정책은 다음 순서로 시작할 수 있다.
-
인수 책임자를 지정한다. AI가 생성한 변경마다 사람 한 명이 코드 의도, 테스트 범위, 운영 영향을 설명할 수 있어야 한다. 작성자와 인수자는 같을 수 있지만, 이름 없는 공동 책임 상태는 피한다.
-
영향이 큰 경로를 먼저 표시한다. 권한, 고객 데이터, 금전 상태, 배포 설정, 공용 기반 모듈처럼 별도 검토가 필요한 영역을 저장소와 리뷰 규칙에서 식별한다. 모든 코드를 위험하게 취급하면 규칙은 곧 무시된다.
-
PR에 맥락을 남긴다. AI를 사용했는지 고백하는 형식보다, 무엇을 바꾸었고 어떤 조건을 확인했으며 어디까지 검증했는지를 남기는 편이 중요하다. 다음 담당자가 이해할 수 있는 기록이 목적이다.
-
생성 코드의 결함 양상을 따로 관찰한다. 보안 취약점, 불필요한 코드, 하드코딩, 중복 구현이 반복되는지 살핀다. 특정 유형이 반복되면 개인의 주의 부족으로만 처리하지 말고 프롬프트, 템플릿, 리뷰 기준, 자동 점검 범위를 조정한다.
-
허용 범위를 작은 단위로 갱신한다. 전사적인 찬반 결정보다 팀과 저장소의 특성에 맞춰 범위를 조정하는 편이 낫다. 인수와 복구가 잘 되는 영역은 넓히고, 설명할 수 없는 변경이 늘어나는 영역은 줄인다.
AI 코딩 도구는 코드를 만드는 시간을 줄일 수 있다. 그러나 운영 조직이 사야 하는 것은 코드량이 아니라 변경을 이해하고 책임질 수 있는 능력이다. 다음 분기 도입 계획을 논의한다면 “몇 퍼센트를 AI로 작성할 것인가”보다 먼저, 누가 어느 변경을 설명하고 검증하며 장애 때 인수할 것인가를 PR 정책과 서비스 오너십 표에 적어 두는 편이 낫다.
