개발팀이 코드 작성에 AI를 쓸 때 PM이 챙길 것

요지

개발자가 AI로 쓴 코드를 PM은 어디까지 알아야 할까. 코드를 한 줄씩 읽는 일까지 PM이 맡을 필요는 없을 수 있다. 그러나 그 코드를 확인하는 시간과 사람이 일정에 잡혀 있는지, 회사의 정책이나 외부와 맺은 계약에 걸리는 것이 섞이지 않는지, 산정과 일정에 어떻게 반영되는지는 PM이 팀과 정할 일이다. 지도 앱 개발사의 기능 개발 한 건을 예로 리뷰에 드는 시간과 사람, 라이선스와 비밀값 확인, 산정과 일정, 팀 밖에 확인할 것을 순서대로 다룬다. 어느 AI 서비스를 쓸지나 자료 등급 같은 팀 사용 규칙은 이미 정해져 있다고 보고, 코드 작성에 관한 것으로 좁힌다.

산정을 줄여도 된다는 말

한 지도 앱 개발사가 교통 정보 제공처에서 실시간 버스 도착 정보를 불러와 길찾기 화면에 붙이는 기능을 만든다(가상의 예). 계획 회의를 앞두고 개발 리더가 PM에게 말한다. 「이번 연동 코드는 AI로 많이 쓸 거라서 산정을 좀 줄여도 될 것 같습니다.」

이 한마디에서 PM이 물을 것은 셋이다. 코드를 쓰는 시간이 줄어든다면 그 코드를 확인하는 시간은 어디에 잡혀 있는가. 그 코드에 회사 정책이나 계약에 걸리는 것이 섞이지 않는지 누가 확인하는가. 줄인다는 산정에 팀의 기록이 근거로 있는가.

표는 가로로 밀어서 볼 수 있습니다.

리뷰: 시간과 사람이 일정에 있는지 본다

리뷰를 어떻게 하는지는 팀의 개발 규칙을 따른다. PM은 AI로 쓴 코드도 사람이 쓴 코드와 같은 리뷰를 거치는지, 리뷰 요청에 AI로 쓴 부분을 밝히고 한 번에 올리는 변경의 크기를 팀이 정해 두었는지만 확인한다.

PM이 직접 챙길 것은 그 리뷰에 드는 시간과 사람이다. 리뷰 시간은 일정의 작업으로 잡는다. 작성 산정만 줄이고 리뷰에 드는 시간을 따로 잡지 않으면, 줄였다고 본 시간이 리뷰 대기에서 다시 나타날 수 있다. 코드를 빨리 쓸 수 있으면 리뷰 요청이 한꺼번에 몰릴 수 있으니, 리뷰가 한 사람에게 쌓이지 않는지도 계획 회의에서 묻는다. 이 기능처럼 외부 제공처와 연결되는 코드는 그 연동을 아는 사람을 리뷰어로 미리 정해 둔다. 그 사람이 다른 작업에도 배정되어 있다면, 리뷰가 밀릴 때 누가 대신 볼지도 함께 정한다.

라이선스: 회사의 정책과 계약을 먼저 본다

AI로 쓴 코드에 외부 라이브러리를 불러오는 줄이 섞일 수 있다. 새 라이브러리가 들어오면 AI를 쓰기 전과 같은 라이선스 확인 절차를 거치게 한다. 무엇이 허용되는지를 PM이나 개발자가 혼자 판단하지 않는다. 회사에 오픈소스 사용 정책이 있으면 그것을, 데이터 제공처나 협력사와 맺은 계약에 제3자 코드나 소스 공개에 관한 조건이 있으면 그것을 먼저 본다. 계약 용어의 뜻은 정의 조항을 먼저 보고, 해석이 갈리면 법무 담당이나 회사가 정한 자문 창구에 묻는다. PM은 이 확인을 누가 맡았는지, 확인한 날과 결과가 기록에 남는지를 본다.

생성된 코드의 권리와 사용에 대해서도 회사가 정한 입장이 있는지, 쓰고 있는 AI 서비스의 이용 약관이 무엇을 정하는지 확인한다. 정한 것이 없으면 팀 안에서 결론을 내리지 않고 정책을 맡은 쪽에 묻는다. 답이 올 때까지 어떻게 할지도 함께 묻고, 받은 답을 확인 기록에 적어 둔다. 약관은 바뀔 수 있으므로 확인한 날과 약관 버전을 같이 적는다.

비밀값과 사용자 데이터: 들어가는 쪽과 나오는 쪽

들어가는 쪽부터 본다. 도착 정보 연동 오류를 고치려고 오류 기록 전체를 AI 서비스에 붙여 넣으면 그 안의 제공처 접속 키나 사용자의 위치 기록이 함께 들어갈 수 있다. 무엇을 넣지 않을지는 팀 사용 규칙과 회사의 개인정보 처리 기준, 제공처와 맺은 계약의 비밀유지 조항을 따르고, 오류 기록은 키와 사용자 정보를 지운 뒤에 넣는다는 순서를 정한다. 테스트용 데이터를 AI로 만들 때 실제 사용자의 이동 기록을 예시로 넣지 않는 것도 함께 정한다.

나오는 쪽도 본다. 생성된 코드에 키를 직접 적은 곳이나 예시 값이 들어 있을 수 있다. 키는 설정 파일이나 비밀값 저장소로 옮긴다는 항목을 리뷰 기준에 넣고, 저장소에 올리기 전에 비밀값이 섞였는지 점검하는 절차가 있다면 AI로 쓴 코드도 같이 거치게 한다.

산정과 일정: 줄일 근거가 있는지부터 본다

개발 리더의 말로 돌아가 보자. 산정을 줄일 근거가 팀에 아직 없다면, 이번 산정은 지금까지의 방식대로 한다. 작업마다 산정치와 실제로 들인 시간을 적어 두고, 리뷰와 결함 수정에 든 시간도 함께 적는다.

다음 산정을 줄일지는 회고에서 팀이 정한다. 작성 시간이 줄어든 작업이라도 리뷰나 결함 수정에 시간이 더 들었다면 작업 전체의 산정은 그대로일 수 있다.

승인된 일정 기준선은 팀이 산정을 줄이기로 정해도 바로 당기지 않는다. 변경요청이 승인된 뒤에 고친다. 스폰서가 AI를 쓰니 일정이 당겨지느냐고 물으면, 산정은 회고에서 정하고 기준선은 변경요청으로 다룬다고 알린다.

팀 밖에 확인할 것

여기까지 정한 것은 개발팀 안에만 두지 않는다. 외주 개발자가 같은 저장소에 코드를 올린다면, 같은 규칙이 그 사람에게도 적용되는지와 외주 계약에 그 규칙을 따른다는 조건이 있는지를 확인한다. 외부와 맺은 계약에 AI 사용을 알리거나 동의를 받아야 하는 조건이 있는지도 계약 담당에게 확인한다.

쓰고 있는 AI 서비스의 약관이나 요금이 바뀌거나, 서비스가 한동안 멈출 수도 있다. 그럴 때 일정이 밀릴 수 있는 작업이 무엇인지를 미리 리스크로 올려 두고 지켜볼 사람을 정한다.

코드 작성에 AI를 쓰는 팀의 확인 목록

• AI로 쓴 코드도 같은 리뷰를 거친다고 팀의 개발 규칙에 적혀 있는가
• 리뷰 요청에 AI로 쓴 부분을 밝히고, 한 번에 올리는 변경의 크기를 정했는가
• 리뷰 시간이 일정의 작업으로 잡혀 있고, 제공처 연동 코드의 리뷰어와 대신 볼 사람이 정해져 있는가
• 새 라이브러리의 라이선스를 회사 정책과 계약을 기준으로 확인하는 절차가 있는가
• 생성된 코드에 대한 회사 입장과 서비스 이용 약관을 확인했거나, 정책을 맡은 쪽에 묻고 받은 답을 기록했는가
• 오류 기록을 AI 서비스에 넣기 전에 키와 사용자 정보를 지우는 순서를 정했는가
• 코드에 적힌 키를 리뷰와 저장소 점검에서 찾아내는가
• 작업마다 산정치와 실제로 들인 시간을 적어 두는가
• 산정을 줄일지를 회고에서 팀이 정하기로 했는가
• 일정 기준선을 바꿀 때 변경요청 절차를 거치는가
• 외주 인력에게도 같은 규칙이 적용되고, 계약이 AI 사용에 두는 조건을 계약 담당에게 확인했는가
• AI 서비스의 약관 변경과 중단을 리스크로 올리고 지켜볼 사람을 정했는가

참고

• 외부 자료를 근거로 쓰지 않았다. 본문은 일반적인 소프트웨어 개발 관리와 프로젝트 일정 관리의 원리로 썼다.
• 라이선스와 계약에 관한 문장은 확인할 곳과 순서만 적은 것이며 법률 조언이 아니다.
• 지도 앱 개발사, 실시간 버스 도착 정보 연동 기능 개발 장면과 대화는 이 글을 위해 만든 가상의 예다.