AI 에이전트에게 “이 기능을 만들어 달라”고 요청하면 작은 유틸리티나 화면 기능은 빠르게 나옵니다. 그래서 기존 패키지를 찾고 README와 이슈를 읽던 과정이 불필요해 보일 수 있습니다. 그러나 요구사항 단계에서 더 중요한 질문은 따로 있습니다. 외부 패키지를 쓰든 생성 코드를 넣든, 그 결과를 누가 검토하고 장애가 났을 때 누가 고칠 것인가입니다.
오픈소스 패키지는 남이 만든 코드에 의존하는 선택이고, AI 생성 코드는 우리 팀이 사실상 새 의존성을 만들어 떠안는 선택입니다. 둘 중 하나가 본질적으로 더 안전하다고 볼 수는 없습니다. 기능의 성격, 실패 비용, 팀의 유지보수 여력에 따라 책임 구조가 달라집니다.
CTO와 개발 리드는 “에이전트가 구현할 수 있는가”보다 “이 기능의 변경 이력을 계속 이해할 사람이 있는가”를 먼저 확인해야 합니다.
먼저 구분할 것: 재사용하는 기능과 우리만의 업무 규칙
패키지가 강한 영역은 여러 조직이 반복해서 겪는 문제입니다. 날짜 처리, 암호화 알고리즘 구현, 파일 포맷 파싱, HTTP 통신, 데이터베이스 마이그레이션처럼 표준과 호환성이 중요한 기능이 여기에 속합니다. 이런 영역은 코드 분량보다 예외 처리와 상호운용성의 축적이 가치입니다.
AI 에이전트로 직접 구현하기 좋은 영역은 우리 조직의 업무 규칙이 핵심인 기능입니다. 예를 들어 내부 승인 단계, 특정 부서의 입력 화면, 자사 데이터 모델에만 맞춘 조회 조건, 일시적인 운영 자동화가 그렇습니다. 이미 존재하는 범용 패키지를 억지로 맞추느라 복잡한 확장 코드를 붙이는 것보다, 작고 명확한 범위로 직접 만드는 편이 나을 수 있습니다.
다만 “우리만 쓰는 기능”이라는 이유만으로 생성 코드를 택하면 안 됩니다. 다음 조건을 함께 봐야 합니다.
| 판단 대상 | 패키지 도입이 유리한 조건 | AI 생성 코드가 유리한 조건 |
|---|---|---|
| 문제의 성격 | 업계 표준, 복잡한 호환성, 넓은 예외 범위가 있음 | 업무 규칙이 독특하고 범위가 좁음 |
| 변경 빈도 | 기능 요구가 비교적 안정적임 | 현업 규칙이 자주 바뀌고 즉시 수정해야 함 |
| 장애 영향 | 보안, 정합성, 외부 연동 오류의 영향이 큼 | 실패해도 격리하거나 되돌릴 수 있음 |
| 팀의 이해도 | 내부에 해당 기술을 깊게 아는 사람이 부족함 | 담당 팀이 코드와 도메인을 계속 소유할 수 있음 |
| 검증 방식 | 널리 쓰이는 테스트·문서·호환성 정보가 중요함 | 요구사항을 예시와 테스트로 구체화할 수 있음 |
이 표는 패키지와 생성 코드 중 하나만 고르라는 뜻이 아닙니다. 한 서비스 안에서도 인증은 검증된 구성요소를 채택하고, 고객사별 업무 흐름은 직접 만들 수 있습니다. 기능 단위로 선택해야 합니다.
생성 비용이 내려가도 검토 비용은 자동으로 내려가지 않는다
에이전트는 구현 초안을 빠르게 만들 수 있습니다. 하지만 코드가 늘어날수록 사람이 확인해야 할 범위도 함께 커집니다. 특히 생성된 코드에는 요구하지 않은 가정이 들어갈 수 있습니다. 입력값이 비어 있을 때의 처리, 동시 요청, 권한 확인, 오류 복구, 데이터 삭제 순서처럼 평소에는 보이지 않던 조건이 대표적입니다.
패키지를 도입할 때도 검토는 필요합니다. 다만 검토의 대상이 다릅니다. 패키지는 API, 라이선스, 보안 공지, 릴리스 주기, 유지보수 상태, 의존성 트리를 확인해야 합니다. 생성 코드는 이와 더해 설계 의도와 경계 조건을 우리 팀이 새로 만들어 검증해야 합니다.
따라서 “패키지를 설치하지 않았으니 의존성이 없다”는 판단은 맞지 않습니다. 생성 코드도 모델, 에이전트 도구, 프롬프트에 담긴 가정, 생성 당시의 라이브러리 버전, 이를 이해하는 특정 개발자에게 의존할 수 있습니다. 저장소에 코드가 들어왔다는 사실만으로 운영 주체가 생기는 것은 아닙니다.
다음 징후가 보이면 생성 코드의 도입 범위를 줄이거나 검토 체계를 먼저 보강하는 편이 좋습니다.
- 생성한 사람이 코드 리뷰에서 핵심 분기와 데이터 흐름을 설명하지 못한다.
- 테스트가 정상 흐름만 확인하고 실패, 재시도, 권한, 동시성 조건을 다루지 않는다.
- 수정 요청이 들어올 때마다 에이전트에게 전체 파일을 다시 생성하게 된다.
- 배포 후 장애가 나면 어떤 입력과 변경이 원인인지 추적할 로그와 기록이 없다.
- 담당자가 바뀌면 코드를 읽을 수는 있어도 왜 그렇게 만들었는지 알 수 없다.
이 문제는 AI 코드에만 생기지 않습니다. 다만 생성 속도가 빨라질수록 문제를 뒤로 미루기 쉬워집니다.
의존성 검토와 생성 코드 검토는 다른 질문을 요구한다
요구사항 문서에는 “라이브러리 사용” 또는 “AI로 개발” 같은 선택만 적지 말고, 검토 항목과 책임자를 함께 적어야 합니다.
외부 패키지를 도입한다면 기술 책임자는 다음을 확인해야 합니다.
- 이 패키지가 해결하는 문제를 우리 팀이 정확히 정의했는가.
- 현재 버전과 주요 의존성이 우리 실행 환경, 보안 정책, 배포 방식과 맞는가.
- 유지보수가 느려지거나 중단될 경우 어느 버전까지 고정하고, 누가 대체안을 판단하는가.
- 라이선스 의무, 재배포 조건, 고지 필요 여부를 누가 확인하고 기록하는가.
- 취약점 공지나 호환성 변경이 생겼을 때 업데이트를 승인할 담당자는 누구인가.
AI 에이전트로 직접 생성한다면 질문이 바뀝니다.
- 사람이 읽을 수 있는 설계 설명과 테스트가 코드와 함께 남는가.
- 에이전트가 수정할 수 있는 파일, 접근 가능한 데이터, 실행 가능한 명령의 범위를 제한했는가.
- 생성 결과를 병합하기 전에 도메인 담당자와 코드 리뷰어가 각각 무엇을 확인하는가.
- 운영 환경에서 실패했을 때 되돌릴 버전과 데이터 복구 절차가 있는가.
- 다음 담당자가 에이전트 없이도 수정할 수 있는가.
여기서 중요한 점은 리뷰어를 “개발팀”처럼 뭉뚱그리지 않는 것입니다. 보안상 중요한 인증 흐름은 보안 책임자가 확인해야 하고, 정산 규칙은 재무 또는 업무 책임자가 예외 조건을 검토해야 합니다. 개발자는 구현의 정확성을 보지만, 업무 규칙의 정당성까지 혼자 보장할 수는 없습니다.
기능을 세 등급으로 나눠 도입 속도를 조절한다
모든 기능에 같은 승인 절차를 적용하면 작은 개선도 늦어집니다. 반대로 모든 코드를 빠르게 생성해 병합하면 중요한 기능까지 검증 없이 들어갈 수 있습니다. 요구사항 단계에서 기능을 세 등급으로 나누면 균형을 잡기 쉽습니다.
1등급, 표준 기반 핵심 기능입니다. 인증, 결제 연동, 암호화, 개인정보 처리, 권한 제어, 데이터 변환처럼 오류가 외부 피해나 큰 복구 비용으로 이어질 수 있는 영역입니다. 검증된 패키지나 플랫폼 기능을 우선 검토하고, 직접 생성한 코드를 넣어야 한다면 별도 설계 검토와 테스트 기준을 둬야 합니다.
2등급, 업무 핵심이지만 범위가 제한된 기능입니다. 고객별 가격 규칙, 승인 경로, 내부 정산 보조, 운영 대시보드가 여기에 해당할 수 있습니다. 생성 코드를 활용할 수 있지만, 요구사항 예시와 반례를 먼저 작성해야 합니다. “할인 적용”이라는 문장보다 “취소된 주문에는 적용하지 않는다”, “상한을 넘으면 담당자 승인이 필요하다”처럼 판정 조건을 테스트로 옮길 수 있어야 합니다.
3등급, 되돌릴 수 있는 생산성 기능입니다. 개발용 스크립트, 관리자용 일회성 데이터 점검 도구, 내부 문서 변환, 제한된 실험 화면 등이 해당합니다. 이 영역은 에이전트 활용의 효과가 큽니다. 다만 운영 데이터 접근권한과 실행 범위는 분리해야 합니다. 작아 보이는 도구가 삭제나 대량 변경 권한을 가지면 등급이 달라집니다.
운영권을 넘기지 않는 도입 순서
첫 도입에서는 큰 기능 하나를 통째로 생성하거나 대형 패키지를 한꺼번에 넣기보다, 장애가 나도 영향이 제한적인 기능을 고르는 편이 낫습니다. 그 기능을 통해 팀이 실제로 확인해야 할 것은 에이전트의 코딩 속도가 아닙니다. 리뷰가 얼마나 걸리는지, 테스트가 빈틈을 잡는지, 수정 요청이 들어왔을 때 담당자가 코드를 이해하고 바꿀 수 있는지를 봐야 합니다.
요구사항에는 최소한 다음 산출물을 남겨 두는 것이 좋습니다.
- 선택한 이유와 선택하지 않은 대안
- 기능이 다루는 데이터와 권한 범위
- 정상 사례, 실패 사례, 금지해야 할 동작
- 코드 병합 승인자와 운영 변경 승인자
- 패키지 업데이트 또는 생성 코드 수정 시 재검증할 항목
- 담당자가 부재할 때 인수인계받을 팀 또는 역할
AI 에이전트는 코드 작성의 병목을 줄일 수 있습니다. 그러나 코드가 운영 환경에서 맡게 되는 책임까지 대신 지지는 않습니다. 이번 분기에 도입할 기능 하나를 정했다면, 먼저 패키지냐 생성 코드냐를 고르기보다 그 기능의 오너, 리뷰 기준, 장애 대응자를 요구사항에 이름과 역할로 적어 보십시오. 그 문서가 없는 선택은 빠른 구현처럼 보여도 운영 단계에서 가장 비싼 의존성이 될 수 있습니다.
