AI 코딩 도구를 쓰는 개발사에 무엇을 확인해야 합니까?

「쓰느냐」가 아니라 「어떻게 통제하느냐」를 묻습니다

AI 코딩 도구는 한 줄 자동 완성에서 여러 파일을 한 번에 고치는 에이전트형 도구까지 범위가 넓어졌습니다. 발주사가 계약서에 사용 금지를 넣을 수는 있지만, 실제로 지켜지는지 확인할 방법이 마땅치 않은 경우가 많습니다. 그래서 확인할 대상은 사용 여부가 아니라 AI가 만든 결과물이 반영되기 전에 거치는 통제입니다.

애플리케이션 보안 분야의 국제 비영리 단체인 OWASP는 「시민 개발(Citizen Development) 보안 위험 상위 10」에서 로우코드·노코드 같은 업무 혁신 플랫폼과 함께 AI 보조 코딩과 AI 에이전트까지 다루고, 그 첫 항목으로 맹목적 신뢰(Blind Trust) 를 꼽고 있습니다. 도구가 내놓은 코드를 검증 없이 받아들이는 것이 위험의 출발점이라는 뜻입니다.

품질 — AI가 쓴 코드도 같은 관문을 지나는가

AI가 만든 변경도 사람이 직접 쓴 코드와 같은 관문을 지나야 합니다. 관문이 하나라도 생략되면 「빨리 만들었다」는 장점이 운영 단계의 결함으로 돌아옵니다.

1. AI 생성
2. 개발자 검토
3. 자동 테스트
4. 보안 점검
5. 동료 리뷰 후 병합

미팅에서는 다음처럼 물어보시면 됩니다. AI가 만든 변경도 사람이 리뷰한 뒤 병합하는지, 그 리뷰 기록이 저장소에 남는지, 자동 테스트가 있고 통과해야 배포되는지, 새 외부 라이브러리를 추가할 때 누가 승인하는지입니다. AI 도구가 제안하는 라이브러리는 이름이 그럴듯해도 검증되지 않은 것일 수 있으므로, OWASP도 취약하거나 신뢰할 수 없는 구성 요소를 별도 위험으로 다룹니다. 답이 구체적일수록 통제가 실제로 돌아가고 있을 가능성이 높습니다.

「코드의 몇 퍼센트를 AI가 썼습니까」라는 질문은 큰 의미가 없습니다. 같은 비율이라도 검토와 테스트를 거쳤는지에 따라 품질은 전혀 다르기 때문입니다. 비율보다 관문을 건너뛴 변경이 있었는지를 묻고, 가능하면 저장소의 병합 기록으로 직접 확인하시는 편이 정확합니다.

보안 — 고객 코드와 데이터가 어디로 가는가

클라우드형 AI 코딩 도구는 편집 중인 코드와 주변 맥락을 서비스 쪽으로 보내 제안을 받습니다. 그 입력이 모델 학습에 쓰이는지, 얼마 동안 보관되는지는 도구와 요금제, 관리자 설정에 따라 다릅니다. 그러므로 「안전한 도구를 씁니다」라는 답으로는 부족하고, 도구 이름·요금제·설정과 그 근거가 되는 약관 조항을 서면으로 받아야 합니다.

더 직접적인 위험은 운영 데이터와 비밀값입니다. 고객 개인정보가 담긴 실제 데이터를 붙여 넣어 오류를 재현하거나, API 키를 코드에 직접 적는 습관이 AI 도구와 만나면 유출 경로가 늘어납니다. OWASP는 권한 오용(Authorization Misuse) 항목의 시나리오 가운데 하나로, 개발자가 건넨 개인 API 키를 AI 도우미가 스크립트에 그대로 넣고 그 스크립트가 팀에 공유된 뒤 다른 직원이 그 키로 관리자 권한을 얻는 상황을 들고 있습니다. 개발사에 다음 두 규칙이 있는지 확인하십시오.

• 운영 데이터는 AI 도구에 입력하지 않고, 테스트에는 가명 처리한 데이터를 씁니다
• 비밀값은 코드와 저장소에 두지 않고 별도 비밀값 관리 수단으로만 다룹니다

권리·라이선스 — AI가 만든 부분은 누구의 것인가

저작권법 제2조는 저작물을 「인간의 사상 또는 감정을 표현한 창작물」로 정의합니다. 방송통신위원회는 정책브리핑(2024년 4월)에서 생성형 AI가 자동으로 생성한 결과물은 현행 저작권법의 보호 대상이 아니고, 인간이 창작적 표현을 더한 부분에 대해서만 저작권을 가질 수 있다고 안내했습니다. 한국저작권위원회도 생성형 AI 저작권 안내서와 함께 저작권 등록, 분쟁 예방, 학습의 공정이용을 다룬 안내서를 모아 공개하고 있습니다.

실무에서 이것이 뜻하는 바는 두 가지입니다. 첫째, 계약서에 「저작권은 발주사에 귀속한다」는 조항이 있어도 AI가 만든 부분은 넘겨받을 권리 자체가 좁을 수 있습니다. 어디까지가 사람의 창작인지는 사안마다 달라 법률 검토가 필요한 지점입니다. 둘째, AI 제안이 공개 저장소의 코드와 겹치면 제3자의 권리나 오픈소스 라이선스 조건이 따라올 수 있습니다. GitHub Copilot은 제안을 공개 저장소 코드와 대조하는 기능(code referencing)을 두고, 조직 정책에 따라 일치하는 제안을 차단하거나 출처·라이선스 정보를 함께 표시하게 합니다. 개발사가 쓰는 도구에 이런 설정이 있는지, 켜 두었는지를 확인하십시오.

계약서에는 소유권 귀속 조항과 별도로 제3자 권리 비침해 보증을 두는 편이 안전합니다. 인도한 결과물이 다른 사람의 저작권이나 라이선스 조건을 침해하지 않는다는 보증과 함께, 문제가 확인되면 개발사가 해당 부분을 교체하고 그 비용을 부담한다는 대응 절차까지 적어 두면 실제로 쓸 수 있는 조항이 됩니다.

계약 전에 받아 둘 답

다섯 질문 모두에 문서로 답할 수 있는 개발사라면 AI 도구를 쓰는 것 자체를 걱정할 이유는 크지 않습니다. 반대로 답이 「괜찮습니다」 수준에 머문다면, 도구가 아니라 개발 절차 전체의 통제 수준을 다시 확인해 볼 필요가 있습니다. 받은 답은 계약서 별첨으로 옮기고, 계약 기간 중 도구나 요금제가 바뀌면 다시 알리도록 하는 문장도 함께 넣어 두면 진행 중의 변화도 놓치지 않습니다.

참고 자료

• 저작권법 제2조(정의) — 국가법령정보센터
• 대한민국 정책브리핑 — 생성형 AI가 만든 저작물 저작권은 누가 갖게 될까요?(방송통신위원회, 2024. 4. 4.)
• 한국저작권위원회 — AI-저작권 안내서(4종) 모음
• GitHub Docs — GitHub Copilot code referencing
• OWASP Citizen Development Top 10