그 코드는 누가 썼는가

PMO 실전 노트 · Note 26

코드는 통과했다.
저자는 없었다.

그 코드는 누가 썼는가 · HFC Consulting

---

장면

통합테스트 3주차였다. 결함 목록의 맨 위에 정산 모듈이 있었다. 같은 유형의 오류가 열일곱 건이었다. 회의실에서 수행사 PL이 화면을 넘기다가 멈췄다. 그리고 말했다. "이 모듈은 생성형 도구로 작성한 비중이 높습니다. 저희 개발자가 전부 직접 쓴 코드가 아닙니다."

결함 자체는 특별할 것이 없었다. 예외 처리가 빠진 경계 조건, 흔한 유형이었다. 특별한 것은 그다음 문장이었다. 발주기관 담당자가 물었다. "그러면 이 결함의 책임은 누구에게 있습니까." 방이 조용해졌다. 감리도 답하지 못했다. 계약서를 폈다. 과업범위에도, 검수기준에도, 하자담보책임 조항에도 AI가 만든 산출물이라는 말은 없었다. 도구는 이미 현장에 들어와 있었다. 문서만 이전 시대에 있었다.

그때의 선택

갈림길은 둘이었다. 하나는 생성 코드 전수 재검토를 요구하는 길. 명분은 있었다. 그러나 어느 코드가 생성분인지 구분할 기록이 없었고, 전수 재검토는 남은 일정을 무너뜨릴 것이 분명했다. 다른 하나는 저자를 묻지 않는 길이었다.

PMO는 두 번째를 택했다. 논리는 하나였다. 계약의 상대는 개발자도 도구도 아니고 수급인이다. 산출물이 검수기준을 통과하지 못하면 그것은 결함이고, 결함의 이행 책임은 수급인에게 있다. 하도급 인력이 썼든 생성형 도구가 썼든, 납품의 주체는 달라지지 않는다. 누가 썼는가는 책임의 소재를 바꾸지 못한다. 대신 조건을 하나 붙였다. 이후 산출물부터 생성 코드 구간을 형상관리에 표시하고, 해당 구간의 테스트 커버리지를 별도로 보고할 것. 도구를 금지하지 않았다. 기록을 요구했다.

복기

지금 다시 본다면, 그날의 판정은 옳았지만 늦었다. 저 질문은 통합테스트가 아니라 계약 단계에서 나왔어야 했다. AI 산출물을 어떻게 검증할 것인가는 감리·PMO 위탁 가이드 5화 - AI 산출물을 감리한다는 것에서 다룬 그대로, 도구의 문제가 아니라 검증 체계의 문제다. 그리고 지적이 검수로 이어지려면 6화 - 지적사항과 검수기준의 정합이 말하는 정합이 먼저 있어야 한다. 검수기준에 없는 것은, 회의실에서 아무리 목소리가 커도 판정할 수 없다. 판정할 수 없는 것은 결국 힘의 문제로 넘어가고, 힘의 문제가 된 순간 양쪽 모두 지식재산권과 하자담보책임의 회색지대에 서게 된다.

그때는 몰랐다. 생성 도구가 이렇게 빨리 개발 현장의 기본값이 될 줄은. 지금은 안다. 다음 계약서에는 이 문장이 들어가야 한다는 것을.

원칙 한 줄

코드의 저자는 도구가 아니라 계약이 정한다 — 산출물의 책임 구조를 계약과 검수기준에 명문화하라. 도구는 금지할 대상이 아니라 기록할 대상이다.

도구는 바뀐다. 책임은 바뀌지 않는다. 바뀌지 않게 만드는 것이 문서의 일이다.

지금 검수기준에 AI 산출물 조항이 있습니까?

HFC컨설팅은 발주기관과 수행사의 계약·검수 체계에 AI 산출물 검증 구조를 설계합니다. 진행 중인 사업이라도 늦지 않았습니다.

changks@hfcconsulting.co.kr

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

본 사례는 실제 경험을 바탕으로 재구성·익명화되었습니다. 기관·기업·시스템을 특정하지 않으며, 복수 사업의 요소가 합성되어 있습니다. 본 글은 일반적인 정보 제공을 목적으로 하며 개별 사안에 대한 법률 자문이 아닙니다.

---

📚 PMO 실전 노트 — 현장의 판단이 어려웠던 순간들

◀ 이전 노트: 지적사항 87건이 도착했다 (Note 25)

코너 전체 보기 →