AI가 만든 코드, 버그의 책임은 누구에게 있는가
작년 말 팀의 주니어 개발자가 나에게 보여준 코드를 보고 깜짝 놀랐다. Copilot이 생성한 결과물이었는데, 문법적으로는 완벽했지만 보안 취약점이 여섯 군데나 있었다. 보안을 담당하는 선임 개발자가 발견하지 못했다면, 그 코드는 그대로 프로덕션으로 들어갔을 것이다. 그 순간 내 머릿속을 스친 질문이 있다: 그 버그의 책임은 누구의 것인가?
이건 더 이상 이론적인 질문이 아니다. 하루가 다르게 개발팀들이 AI 코드 자동완성 도구를 도입하고 있고, 실제로 문제가 터지고 있기 때문이다. 지난 3년간 여러 프로덕션 장애를 목격했는데, 그중 상당수가 AI가 생성한 코드에서 비롯되었다.
사건: Copilot이 남긴 것들
먼저 구체적인 사례부터 살펴보자. 2024년 초에 한 개발자가 GitHub Copilot의 도움을 받아 CSV 파싱 라이브러리의 일부를 작성했다. Copilot이 생성한 코드는 특정 에지 케이스에서 버퍼 오버플로우를 야기했다. 이것이 공개 NPM 패키지로 배포되었고, 수백만 개의 다운로드 이후에야 발견되었다.
더 흥미로운 사건은 라이선스 문제였다. 몇 가지 Copilot 생성 코드가 GNU GPL 라이선스의 오픈소스 코드를 거의 그대로 재생산한 것으로 밝혀졌다. 학습 데이터에 포함되어 있던 GPL 코드를 Copilot이 그냥 뱉어낸 것이다. 이 경우 책임은 누구에게 있을까? Copilot을 제공한 GitHub? 코드를 작성한 개발자? 아니면 회사?
내가 일하는 카카오도 지난해 AI 코드 생성 도구 사용 가이드라인을 정리하는 과정을 거쳤다. 법무팀과 기술팀이 몇 달간 긴장 관계에 있었다. 법무팀은 책임을 최소화하려 했고, 기술팀은 개발자의 자율성을 지키려 했다.
법적 책임의 불명확함
현실의 법률 체계는 아직 이 질문에 명확한 답을 주지 못하고 있다. 대부분의 국가에서 관련 판례가 거의 없다. 미국에서 진행 중인 몇 가지 소송을 보면 상황이 얼마나 복잡한지 알 수 있다.
2023년 미국에서 제출된 클래스 액션 소송에서는 Copilot이 학습 데이터로 사용된 오픈소스 코드의 기여자들의 동의 없이 모델을 훈련시켰다고 주장했다. 아직 판결이 나지 않았지만, 만약 원고들이 이기면 어떻게 될까? GitHub는 배상을 해야 할 것이다. 하지만 그 배상금이 Copilot을 사용한 개발자나 회사에까지 책임을 지울까?
한국의 경우는 더욱 모호하다. 저작권법, 소프트웨어 보호법, 제조물책임법 등 여러 법이 관련되어 있는데, 어느 것을 우선으로 봐야 하는지 명확하지 않다. 내가 아는 몇몇 법조인들은 "현재로서는 판단이 어렵다"고 손을 들고 있다.
기술적으로는 누가 검증해야 하는가
법적 책임이 모호하다면 기술적 책임은 어떨까? 이것은 더 명확해 보인다. 그리고 더 무서워 보인다.
기본 원칙부터 시작하자. 코드 리뷰는 개발팀의 가장 기본적인 품질 보증 메커니즘이다. 내가 처음 입사한 시절, 2000년대 초반만 해도 많은 개발팀들이 코드 리뷰를 제대로 하지 않았다. 그러다가 오픈소스 운동과 함께 코드 리뷰의 문화가 정착되었다. GitHub의 Pull Request 시스템이 나오면서 리뷰는 개발 프로세스의 핵심이 되었다.
그런데 AI가 생성한 코드가 들어오면서 리뷰의 난이도가 확 올라갔다. 일반적인 코드라면 리뷰어가 논리적 흐름, 성능, 보안을 한 번에 점검할 수 있다. 하지만 AI 코드의 경우 정말 이상한 부분들이 있다. 겉으로는 말이 되지만, 깊이 파고들면 미묘한 버그가 있다. 혹은 장황한 설명과 함께 필요 없는 코드가 섞여 있다.
팀의 경험상 AI 생성 코드를 리뷰하는 데 걸리는 시간이 일반 코드의 1.5배에서 2배가 된다. 개발자가 직접 작성한 코드라면 "왜 이렇게 썼을까?"라는 의도를 어느 정도 짐작할 수 있다. 하지만 AI가 생성한 코드는 의도를 알 수 없다. 그냥 "이 코드가 정말 맞는가?"를 처음부터 끝까지 검증해야 한다.
// AI가 생성한 코드 예시
function parseUserInput(input) {
const data = input.split(',');
return {
id: parseInt(data[0]),
name: data[1],
email: data[2],
role: data[3]
};
}
// 문제점: data[3]이 없으면?
// 예외 처리 없음, 타입 검증 없음, 악의적 입력에 취약이런 코드를 보면 리뷰어는 깊은 한숨을 쉬게 된다. 왜냐하면 이것은 단순히 "고쳐"라고 말할 수 있는 수준이 아니기 때문이다. 경우에 따라 처음부터 다시 작성해야 할 수도 있다.
보안 취약점의 확산
가장 우려되는 부분은 보안 취약점이다. 내가 작년에 참여했던 보안 감사 중에 주니어 개발자가 작성한 인증 로직에서 심각한 결함을 발견했다. 코드 리뷰 시점에 그것을 놓쳤다면 프로덕션에서 큰 사고가 났을 것이다.
문제는 AI 모델이 학습 데이터의 패턴을 따라간다는 것이다. 인터넷에는 보안 취약점이 있는 코드가 매우 많다. Stack Overflow, GitHub, 블로그 등에 "빠르게 작동하는" 코드라는 이름으로 보안이 떨어진 예제들이 가득하다. AI 모델은 이런 코드들을 학습하고, 개발자가 비슷한 요청을 하면 같은 패턴으로 생성한다.
예를 들어 암호화 관련 코드를 Copilot에게 생성하도록 요청했을 때, 약한 암호화 알고리즘이나 고정된 소금(salt)을 사용하는 코드가 나올 수 있다. 표면적으로는 작동하지만, 보안 전문가는 즉시 문제를 알아챈다. 그런데 리뷰어가 보안 전문가가 아니라면?
// 약한 암호화 예시
const crypto = require('crypto');
function hashPassword(password) {
const salt = 'fixed_salt_value'; // 위험!
return crypto.createHmac('sha1', salt) // SHA1은 deprecated!
.update(password)
.digest('hex');
}
// 올바른 방식
const bcrypt = require('bcrypt');
async function hashPasswordSecure(password) {
const saltRounds = 10;
return await bcrypt.hash(password, saltRounds);
}라이선스 문제의 미로
Copilot의 GPL 코드 재생산 문제는 더 복잡하다. GitHub는 이미 여러 번 이 문제에 대해 입장을 밝혔다. "모든 도구의 결과물이 라이선스를 준수하는 것은 아니다"라고, 매우 신중한 표현으로. 즉, Copilot이 생성한 코드가 라이선스를 위반할 수도 있다는 뜻이다.
현재 Copilot의 설정에는 GPL 코드와 유사한 결과가 나올 가능성을 줄이는 옵션이 있다. 하지만 "가능성을 줄인다"는 것이지, "100% 막는다"는 것이 아니다. 또한 개발자가 이 옵션을 알고 있고 사용하는 경우는 많지 않다.
법적 관점에서 보면 상황은 이렇다:
- Copilot이 GPL 코드를 재생산했다 → GPL 위반
- 개발자가 이를 회사의 프로젝트에 사용했다 → 회사가 GPL 의무(전체 소스 공개)를 따라야 함
- 회사가 이를 모르고 있었다 → 책임은 누구?
한국의 판례를 보면, 프로그래머나 회사가 "몰랐다"는 것이 법적 책임을 완전히 제거하지는 못한다. 특히 전문가 집단에서 "당연히 알아야 할" 사항은 더욱 그렇다.
현실의 개발팀들은 어떻게 대응하는가
내 경험상 현재 대부분의 개발팀들은 AI 코드 생성 도구에 대해 세 가지 입장 중 하나를 취하고 있다.
첫 번째는 "우리는 안 쓴다"는 입장이다. 금융사, 의료 기관, 보안이 중요한 기업들이 이 입장을 취한다. 내가 만난 한 증권사의 개발팀은 회사 정책으로 Copilot 사용을 명시적으로 금지했다. 책임이 애매하면 애초에 도구를 쓰지 않겠다는 보수적 접근이다.
두 번째는 "신뢰할 수 없는 곳에만 제한적으로 쓴다"는 입장이다. 예를 들어 테스트 코드나 문서 생성, 간단한 유틸리티 함수 작성에만 허용한다. 비즈니스 로직이나 보안 관련 코드에는 절대 쓰지 않는다. 이것이 가장 현실적인 접근으로 보인다.
세 번째는 "다 쓰되, 리뷰를 강화한다"는 입장이다. Copilot이 생성한 모든 코드에 대해 보안 전문가의 리뷰를 강제한다. 추가 인력과 시간이 들지만, 생산성 향상의 이익이 이를 상쇄한다고 믿는다. 몇몇 규모 있는 회사들이 이 방식을 취하고 있다.
개발자의 실질적 책임
법적 책임이 모호하더라도, 개발자의 실질적 책임은 명확해 보인다. 나는 이것을 "기술자의 양심"이라고 부른다.
내가 코드를 작성한다는 것은 그 코드에 대한 책임을 진다는 뜻이다. AI가 생성했든 내가 직접 작성했든 상관없다. 내가 그 코드를 제출하고 리뷰 요청을 하는 순간, 그것은 "내 코드"가 되는 것이다. 이것이 전문 개발자와 아마추어를 구별하는 기본적인 태도다.
따라서 AI 생성 코드를 사용할 때는 일반 코드보다 더 철저한 검증이 필요하다. 나는 팀에 이렇게 말한다: "Copilot을 쓰는 것은 좋다. 하지만 그것이 생성한 모든 코드를 이해하고 테스트하는 것은 너의 책임이다."
미래는 어떻게 될까
앞으로 3년 정도면 AI 코드 생성에 대한 법적 프레임워크가 어느 정도 정리될 것으로 예상한다. 특히 EU는 AI 규제에 앞서가고 있고, 미국도 관심이 높아지고 있다. 한국도 뒤따를 것이다.
그때까지는 개발팀과 회사가 스스로 기준을 정해야 한다. 내가 제시하는 체크리스트는 이렇다:
- AI 생성 코드인지 명확히 표시하고 추적할 수 있는 체계 구축
- 라이선스 스캐닝 도구 도입 (FOSSA, Black Duck 등)
- 보안 취약점 자동 감지 도구 사용 (SonarQube, Snyk 등)
- AI 생성 코드에 대한 강화된 리뷰 프로세스
- 팀원들을 위한 AI 코드 생성 도구 사용 가이드 문서화
- 법무팀과의 사전 협의 (특히 오픈소스 프로젝트인 경우)
책임의 공백을 메우는 것은 결국 개발자 자신이어야 한다. 법으로 다 정해질 때까지 기다릴 수 없기 때문이다. 사용하는 도구에 대해 깊이 있게 이해하고, 그 도구가 생성한 결과물에 책임을 지는 것. 이것이 기술자의 기본 자세가 아닐까.