기존 코드에 테스트를 추가한다. AI가 테스트 코드를 만들고 다른 AI가 리뷰한다. CI까지 통과하면 리뷰어가 승인한다. PR이 병합되고 완료 기록이 하나 늘어난다. 각 단계만 보면 성실하게 품질을 높이는 작업이다.

그런데 같은 팀의 다른 작업은 계속 막혀 있다. 배포 기한은 다가오고, 외부 시스템의 동작을 확인해야 하고, 승인 권한을 가진 사람을 찾아야 한다. 테스트와 리뷰를 만드는 속도가 빨라졌다고 이 일들까지 끝나는 것은 아니다.

최근 두 가지 일이 있었다. 테스트 보강과 작은 개선 PR이 계속 올라왔다. 한편 출시를 앞둔 다른 작업에서는 자동 승인과 재리뷰가 반복된 뒤에도 작성자가 늦은 시간까지 동료에게 승인과 배포 지원을 요청했다. 이 기록만으로 업무가 어떻게 배정됐는지 전부 알 수는 없다. 하지만 완료 기록이 늘어나는 것과 팀의 막힌 일이 해결되는 것은 따로 봐야 한다는 점은 분명했다.

이전에 테스트의 목적을 물었을 때는 어떤 실패를 막는지에 집중했다. 이번에는 작업을 선택한 이유부터 묻고 싶다. 왜 지금 이 일을 먼저 하는가.

테스트가 없다는 사실만으로 그 코드의 테스트부터 작성해야 하는 것은 아니다. 코드 수정 후 결제 금액이 잘못 계산되는 문제를 막는 테스트와, 드물게 바뀌는 내부 구현을 그대로 옮긴 테스트는 투자 이유가 다르다. 작성과 리뷰가 쉬워졌어도 무엇을 보호할지, 다른 작업보다 왜 먼저 할지는 정해야 한다. 테스트가 통과했다는 것은 정해 둔 조건에서 코드의 실행 결과가 기대값과 일치했다는 뜻이다. 그 기대값이 실제 요구사항에 맞는지, 지금 여기에 시간을 써야 하는지는 별도의 판단이다.

이 판단이 빠지면 AI는 필요성이 설명되지 않은 작업도 빠르게 완성해 준다. 작성자는 테스트를 추가했고, 리뷰어는 문제를 찾지 못했고, CI는 통과했다. 누구도 왜 지금 이 작업을 선택했는지 답하지 않았는데 모든 단계가 성공으로 끝날 수 있다.

리뷰에서도 비슷한 빈틈이 있었다. 테스트를 포함한 작은 UI 수정 PR이었다. 화면에 표시되는 동작을 보완했고, 리뷰에서 나온 의견 일부도 수정에 반영됐다. 그런데 결함이 없다며 승인한 리뷰 안에 중복 지적과 수정 범위를 확인하는 질문이 섞여 있었다. 승인을 남긴 뒤 사용자에게 읽히는 문구가 의도한 것인지 다시 묻는 리뷰도 있었다.

선택 사항인 개선이면 지금 반영하지 않아도 된다고 명시하면 된다. 수정 범위에 따라 승인 여부가 달라지는 질문이면 답을 받아야 한다. 그 구분 없이 확인 요청과 승인을 함께 남기면 작성자는 지금 고쳐야 하는지까지 대신 판단해야 한다. 승인 수는 늘어도 결정이 끝난 것은 아니다.

내 리뷰도 동료의 일을 늘렸다. 이미 나온 수정 범위 질문을 반복했고, 브라우저 확인이 필요하다고 쓰면서 어떤 조건에서 무엇을 확인해야 하는지 구체적으로 적지 않았다. 중복 리뷰를 줄이는 규칙을 만들었지만, 규칙을 만드는 것과 다음 리뷰에서 지키는 것은 별개의 일이었다.

이런 작업에는 만든 사람의 시간만 들어가지 않는다. 동료가 요청을 읽고, 테스트의 의미를 확인하고, 리뷰의 결론을 해석한다. 이후 코드를 바꾸는 사람은 기대값을 유지할지 바꿀지도 판단한다. 생성 비용이 낮아졌다고 검토와 유지보수 비용까지 사라지지는 않는다. 필요성이 낮은 PR도 다른 사람에게 일을 만든다.

반대로 팀의 급한 일을 끝내려면 PR 개수만으로 드러나지 않는 일을 해야 한다. 외부 담당자에게 답을 받고, 테스트 환경 사용 순서를 조율하고, 배포 순서를 확인하고, 배포 후 문제가 없는지 확인하는 일이다. 실제로 동료들은 테스트 환경 사용 순서를 조율하고 다른 사람의 배포를 도왔다. 이런 도움도 검증과 배포를 마치는 데 필요한 기여였다.

테스트는 배포하지 않아도 개발 과정에 도움이 될 수 있다. 기능 수정은 운영에 배포돼야 고객이 이용할 수 있다. 두 작업 모두 목적에 맞는 완료 조건이 필요하다. 테스트를 추가했다면 무엇을 보호하는지 설명해야 하고, 출시가 필요한 일은 병합 뒤 배포와 확인까지 마쳐야 한다. PR이 병합됐다는 사실만으로 두 작업의 기여를 똑같이 평가할 수는 없다.

그래서 우선순위를 각자가 알아서 정하도록 두어서는 안 된다. 팀이 지금 막힌 일을 공유하고, 그 일을 끝내기 위해 무엇을 미룰지 정해야 한다. 특정 위험을 줄이는 테스트가 중요하다면 시간을 확보하면 된다. 지금의 병목이 외부 확인이나 배포라면 그 일을 나눠 맡아야 한다. 각자가 만들기 쉬운 PR을 선택하는 동안 어려운 일이 같은 사람에게 남는 구조를 방치해서는 안 된다.

모든 사람이 모든 일을 맡을 수는 없다. 담당 영역과 권한이 다르고, 바로 투입하기 어려운 일도 있다. 그렇더라도 맡을 수 있는 일은 정할 수 있다. 검증 조건을 함께 정리하거나, 리뷰에서 답이 나오지 않은 질문을 확인하거나, 배포 확인 일부를 맡을 수 있다. 이런 기여가 완료 기록에 잘 드러나지 않는다는 이유로 평가에서 빠지면, 결국 완료하기 쉬운 산출물을 더 많이 만들도록 유도하게 된다.

AI로 테스트를 만드는 능력만으로는 팀에 기여했다고 할 수 없다. 왜 그 일이 필요했는지, 무엇을 보호했는지, 동료의 부담을 얼마나 줄였는지까지 설명해야 한다. 리뷰 역시 승인했다는 기록뿐 아니라 무엇을 판단했고 어떤 의문을 해결했는지가 남아야 한다.

그 설명 없이 산출물만 늘리는 행동을 계속 성과로 인정하면, 중요한 일을 맡는 사람보다 쉽게 완료 기록을 만드는 사람이 유리해진다. 팀이 바꿔야 할 것은 바로 그 평가 방식이다.

AI로 생긴 여유를 팀의 막힌 일을 함께 해결하는 데 쓰는 동료라면, AI를 잘 활용한다고 인정하겠다. 반대로 필요 없는 산출물로 동료의 집중력을 흐트러뜨리고 검토할 일만 늘렸다면, 일을 잘한 것이 아니라 남에게 일을 떠넘긴 것이다.