트레이더, 리서처, 운영 담당자가 AI 코딩 도구로 필요한 분석 스크립트나 보고서 초안을 빠르게 만들고 싶어 할 수 있다. 반대로 CTO와 보안 책임자는 그 도구가 읽는 파일, 실행하는 명령, 만들어 낸 결과물이 업무 시스템으로 흘러가는 경로를 걱정한다.
이 갈등을 “개발자만 허용할 것인가”라는 직군 문제로 풀면 대체로 오래가지 못한다. 개발자도 민감한 운영 환경에 과도한 권한을 가질 수 있고, 비개발자도 격리된 데이터에서 검토 가능한 분석 코드를 만들 수 있기 때문이다.
금융기관의 최근 AI 코딩 도구 제한 사례에서도 중요한 지점은 특정 직군의 역량 자체보다 도구가 사용자 권한으로 파일을 읽고, 코드를 쓰고, 명령을 실행할 수 있다는 점이다. Claude Code의 명령행 인터페이스도 파일 내용을 입력으로 전달해 처리하는 방식을 지원한다. 이 기능은 개발 생산성에 유용하지만, 고객 정보, 거래 정보, 인증 정보가 같은 작업 환경에 있으면 입력 범위와 실행 범위를 분리하지 않은 채 사용하기 어렵다.
핀테크 조직이 결정해야 할 질문은 “누가 코딩을 잘하는가”가 아니다. 누가 어떤 데이터를 보고, 어디까지 실행하며, 산출물을 누가 어떤 절차로 검증할 수 있는가다.
실패는 도구 사용 자체보다 통제 경로가 끊길 때 시작된다
AI 코딩 도구 배포에서 흔히 생기는 실패는 모델이 틀린 코드를 한 번 생성하는 일이 아니다. 더 위험한 실패는 임시 산출물이 검토와 기록 없이 반복 업무에 들어가고, 시간이 지나면서 사실상 운영 소프트웨어가 되는 과정에서 발생한다.
예를 들어 현업 담당자가 고객 흐름이나 포지션 관련 데이터를 다루는 환경에서 스크립트를 만들었다고 하자. 처음에는 개인 분석용일 수 있다. 그러나 동료가 복사해 쓰고, 정기 실행 작업에 연결하고, 보고서나 의사결정 자료의 입력값으로 쓰기 시작하면 성격이 달라진다. 누가 변경했는지, 어떤 데이터가 입력됐는지, 예외 상황에서 어떤 계산을 하는지 확인하지 못한다면 그 스크립트는 개인 도구가 아니라 통제 밖 운영 구성요소가 된다.
소프트웨어 변경이 다음 단계로 넘어가기 전에 기술적 또는 조직적 통제 관문을 둬야 한다는 DevSecOps 원칙은 이 문제에 직접 연결된다. AI가 만든 코드도 예외가 아니다. 코드 생성 속도가 빨라질수록 검토, 테스트, 승인, 배포 경로를 생략하려는 압력도 커진다.
다음 세 가지가 동시에 나타나면 배포 정책을 다시 봐야 한다.
- 개인 작업 폴더의 스크립트가 팀의 일일 업무나 보고서 생성에 쓰이기 시작한다.
- 현업 사용자가 만든 결과물을 검증할 데이터 기준, 테스트 절차, 책임자가 정해져 있지 않다.
- AI 도구가 접근하는 단말이나 저장소에 고객 식별 정보, 거래 정보, 자격 증명, 운영 설정이 함께 있다.
이 신호는 사용자가 개발자가 아니라서 생기는 문제가 아니다. 데이터 접근, 실행 권한, 결과 사용처가 한 환경에 겹쳐서 생긴다.
허용 여부는 세 개의 축으로 나누어 판단한다
전사 배포를 검토할 때는 직무명 대신 아래 세 축을 함께 평가하는 편이 낫다. 한 축만 낮다고 해서 전체 위험이 낮아지는 것은 아니다.
| 판단 축 | 확인할 질문 | 제한이 필요한 조건 |
|---|---|---|
| 데이터 민감도 | 도구에 전달되거나 작업 폴더에 존재하는 데이터는 무엇인가 | 고객 정보, 거래 정보, 비밀정보, 접근 토큰, 내부 제한 정보가 포함될 수 있다 |
| 실행 권한 | 도구가 파일 변경, 쉘 명령, 외부 연결, 배치 실행을 어디까지 할 수 있는가 | 운영 계정, 공유 저장소, 업무 자동화 계정과 같은 권한을 사용한다 |
| 결과 검증 가능성 | 결과물을 누가 재현하고, 테스트하고, 승인할 수 있는가 | 개인 산출물이 검토 없이 보고·거래·고객 처리·운영 의사결정에 들어간다 |
이 기준으로 보면 허용군은 직무별로 고정되지 않는다.
가령 개발 조직이라도 운영 데이터에 직접 연결된 환경에서 자유 실행을 허용하는 것은 별도 판단이 필요하다. 반대로 비개발 직군이라도 비식별 또는 승인된 샘플 데이터만 쓰고, 명령 실행이 막힌 환경에서 분석 초안을 만들며, 결과를 담당 개발팀 또는 데이터 책임자가 검토한다면 제한적 사용을 검토할 여지가 있다.
핵심은 “현업은 금지, 엔지니어는 허용” 같은 단순 구분이 아니라, 업무 환경별로 세 축의 조합을 문서화하는 데 있다.
권한 설계는 ‘도구 사용’과 ‘업무 반영’을 분리해야 한다
AI 코딩 도구를 쓸 수 있게 하는 일과, 그 결과를 업무 시스템에 반영할 수 있게 하는 일은 다른 권한이다. 이 둘을 같은 승인으로 묶으면 생산성 실험이 곧 운영 권한 확대로 이어진다.
핀테크 운영 단계에서는 최소한 다음 네 경로를 구분해 둘 필요가 있다.
-
학습·탐색 경로
승인된 공개 자료, 합성 데이터, 비식별 샘플만 사용한다. 파일 변경이나 명령 실행보다 설명, 초안, 코드 예시 생성에 초점을 둔다. -
개인 분석 경로
제한된 작업 공간에서 코드를 만들 수 있지만, 공유 데이터 저장소·운영 계정·배치 시스템에는 연결하지 않는다. 결과는 개인 판단 보조용으로 남긴다. -
팀 개발 경로
소스 코드 관리, 코드 리뷰, 테스트, 빌드 절차를 거쳐야 한다. AI가 생성한 코드도 사람 작성 코드와 같은 변경 관리 대상이다. -
운영 반영 경로
거래, 정산, 고객 처리, 접근 제어, 보고 산출처럼 영향이 큰 업무로 이어지는 변경은 별도 승인과 재현 가능한 검증 기록을 요구한다.
이 구분은 현업의 실험을 막기 위한 장치만은 아니다. 현업이 문제를 빠르게 정의하고 시제품을 만들더라도, 운영에 들어가는 순간에는 책임 있는 팀이 검증 가능한 형태로 넘겨받을 수 있게 한다.
조기 신호는 생성된 코드보다 주변 행동에서 먼저 보인다
운영 책임자가 봐야 할 것은 AI 도구의 사용 횟수만이 아니다. 사용량이 늘었다는 사실만으로 위험이나 가치가 확정되지는 않는다. 대신 통제 경로가 약해지는 행동을 관찰해야 한다.
다음 질문에 답하기 어려우면 해당 업무 흐름은 제한하거나 재설계할 대상이다.
- 사용자가 AI 도구에 어떤 파일이나 로그를 전달했는지 확인할 수 있는가.
- 생성된 스크립트가 어느 저장소, 공유 폴더, 자동 실행 작업으로 이동했는지 추적할 수 있는가.
- 데이터 계산, 고객 분류, 위험 신호 탐지처럼 결과 오류의 영향이 큰 작업에 사람이 확인하는 단계가 있는가.
- 담당자가 바뀌어도 다른 사람이 코드를 읽고 같은 결과를 재현할 수 있는가.
- 문제가 발견됐을 때 실행을 중지하고 이전 상태로 돌아갈 책임자와 절차가 정해져 있는가.
여기서 “코드를 이해하지 못해도 잘 작동하면 된다”는 태도는 특히 위험하다. AI 생성 코드의 정확성은 한 번의 정상 결과로 증명되지 않는다. 입력 누락, 권한 오류, 데이터 형식 변화, 예외 조건에서 어떤 동작을 하는지 확인해야 한다. 금융 업무에서는 작은 계산 오류나 정보 경계 위반도 업무 영향이 커질 수 있다.
정책은 금지 목록보다 승인 가능한 작업 목록으로 시작한다
전사 배포 초기에 모든 위험을 예측해 금지 목록을 완성하려 하면 정책이 추상적으로 남기 쉽다. 대신 각 조직이 승인할 수 있는 작업을 먼저 좁게 정의하는 편이 실행하기 쉽다.
예를 들면 보안, 플랫폼, 개발 생산성, 현업 시스템 책임자가 함께 다음을 결정할 수 있다.
- 허용 데이터 분류: 어떤 등급의 데이터는 입력·파일 접근·로그 처리에서 제외할지
- 허용 실행 범위: 읽기 전용 분석, 로컬 초안 생성, 테스트 환경 실행, 운영 환경 실행을 어떻게 나눌지
- 필수 검토 조건: 어떤 산출물은 코드 리뷰, 테스트, 데이터 검증, 업무 책임자 확인을 모두 거쳐야 하는지
- 인계 기준: 개인 도구가 팀 업무 또는 정기 업무에 쓰이기 시작할 때 어느 팀이 소유권을 넘겨받는지
- 중단 기준: 민감 데이터 노출 우려, 승인되지 않은 외부 연결, 검증 불가한 자동 실행이 발견됐을 때 누가 접근을 중지할지
이 목록은 제품별 기능 비교표가 아니라 운영 경계 문서다. 도구가 바뀌어도 데이터 분류, 실행 권한, 검증 책임이라는 기준은 유지할 수 있다.
CTO와 개발 리더가 먼저 할 일은 전 직원에게 같은 라이선스를 배포할지 결정하는 일이 아니다. 현재 조직에서 이미 개인 스크립트, 자동 보고, 분석 노트북, 배치 작업이 어떤 데이터와 권한을 사용하고 있는지 한 흐름씩 확인하는 일이다. 그 흐름 가운데 검증 경로를 만들 수 있는 곳부터 제한적으로 허용하고, 만들 수 없는 곳은 도구가 아니라 작업 환경부터 분리해야 한다.
