납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까? (06/10)

AI 시대의 사업관리 · Ep.06

기능은 통과했다.
여섯 달 뒤, 코드는 못 열어봤다.

납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까 · HFC Consulting

---

납품 검수 회의. 모든 기능이 작동한다. 도장이 찍힌다. 여섯 달 뒤, 새 요청사항이 온다. 개발자가 그 코드를 연다. 구조가 너무 복잡하다. 손대는 데 일주일이 걸린다. 처음 개발보다 오래 걸린다.

기능이 작동하는 것과, 코드가 건강한 것은 다른 이야기다.

기능 동작 ≠ 코드 품질

납품 시점엔 다 작동한다. 구조가 복잡하면, 유지보수 비용이 개발 비용을 넘어선다.

AI생성 코드에서 이 간극은 더 커진다. AI는 "돌아가는 코드"를 빠르게 만든다. "고치기 쉬운 코드"를 만들라고 지시받은 적이 없다면, 그렇게 만들지 않는다. 사람이 짠 코드라면 코드 리뷰 과정에서 걸러졌을 복잡도가, AI 코드에서는 검토자 없이 그대로 납품물에 들어온다.

보안 취약점이 그대로 들어온다

AI는 학습 데이터의 패턴을 따른다. 학습 데이터에는 오래된 코드가 많다. 오래된 코드에는 오래된 보안 취약점 패턴이 있다.

SQL인젝션에 열려 있는 쿼리 작성 방식, 하드코딩된 인증 정보, 검증 없는 입력 처리 — 사람이라면 요즘 교육과정에서 배우지 않는 방식들이, AI 생성 코드에는 여전히 섞여 나온다. 기능 테스트로는 절대 발견되지 않는다. 공격이 들어와야 발견된다.

라이선스 문제가 숨어 있다

AI가 생성한 코드 조각이 특정 오픈소스와 사실상 동일한 경우가 있다. 그 오픈소스가 GPL 같은 강한 조건의 라이선스라면, 상용 제품에 들어간 순간 분쟁의 소지가 된다. 납품받는 쪽은 그 코드가 어디서 왔는지 알 방법이 없다. 고지받지 못했다면 더더욱...

그래서, 검수 기준은 다섯 겹이 되어야 한다

검수 항목	확인 내용	방법 예시
① 기능 검수 (기존)	요구사항 대비 동작 여부	기존 테스트 시나리오
② 코드 품질	복잡도·컨벤션·중복	정적 분석 도구 (SonarQube 등) 리포트 첨부 요구
③ 보안 취약점	알려진 취약 패턴	SAST 스캔 결과 제출 (Semgrep, CodeQL 등)
④ 오픈소스 라이선스	유입된 코드의 출처·조건	라이선스 스캔 리포트 (FOSSA, Black Duck 등)
⑤ AI 생성 비율 고지	어느 모듈에 얼마나 썼는지	개발사 자체 고지서 (계약서에 양식 첨부)

핵심은 ②~⑤를 납품 후가 아니라 계약 전에 합의하는 것이다. 계약서에 한 줄이면 된다: "납품물에는 정적 분석 및 보안 스캔 리포트를 포함하며, AI 생성 코드가 포함된 모듈은 별도 고지한다."

검수 체크포인트 — 기능 검수(기존) / 코드 품질 검수(컨벤션·복잡도) / 보안 취약점 스캔(SAST) / 오픈소스 라이선스 검토 / AI 생성 코드 비율 고지

검수 기준은 계약 전에 합의해야 한다

납품 후에 "이것도 검수 범위였다"는 주장은, 분쟁의 시작이다. 반대로 계약 전에 다섯 줄의 기준을 넣는 것은, 협상의 일부일 뿐이다. 비용의 차이는 크지 않다. 시점의 차이가 전부다.

📎 더 읽을거리
· OWASP — 보안 취약점 스캔(SAST) 기준의 출발점
· SPDX License List — 오픈소스 라이선스 검토의 국제 표준 식별 체계

HFC Consulting의 관점

AI 생성 코드의 검수 기준을 어떻게 계약에 담을지 고민 중이시라면, 지금 준비 중인 계약서나 RFP를 보내 주십시오. 함께 살펴보겠습니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 연재 · AI시대의 사업관리
◀ 이전 편 (05/10) 개발자가 AI로 만들었다고 합니다 — 공수 산정은 어떻게 합니까?
다음 편 ▶ (07/10) AI가 잘못 만들었을 때, 책임은 개발사입니까 AI입니까?
연재 전체 보기 →