지난달, 아다가 기능 모듈을 완성하고 J가 제게 “다 됐습니다, 메인 브랜치에 합칠 수 있습니다"라고 보고했습니다. 그때부터 조금 긴장되었습니다——아다를 신뢰하지 않아서가 아니라, 그 한마디의 대가를 우리가 너무 잘 알고 있었기 때문입니다. 과연, J가 확인해보니 핵심 논리는 맞았지만, 경계 조건이 처리되지 않았고, 오류 메시지가 영어였습니다(우리의 제품은 중국어 인터페이스입니다), 더 중요한 것은——테스트 코드가 한 줄도 없었습니다. 이것은 특수한 경우가 아닙니다. 초기 에이전트 시스템이 막 가동되기 시작했을 때, 거의 매주 이런 상황을 겪었습니다: 작업을 내어주면, “완료"라고 보고하지만, 사용해보면 문제가 발생합니다. 문제는 에이전트 능력이 부족한 것이 아니라, ‘완료’의 정의가 한 번도 통일된 적이 없다는 것입니다.
에이전트가 ‘완료’라고 말하는 그 순간, 제가 가장 긴장됩니다
가장 심각했던 때는 정기 작업 스크립트였습니다. 아다가 완료했다고 했고, J가 테스트했다고 했는데, 실제로 배포 후 3일이 되어서야 발견했습니다——일부 조건에서 무음으로 실패합니다. 오류를 보고하지 않고, 알림도 없이, 조용히 아무것도 하지 않습니다. 3일. 그때 우리는 문제의 원인을 파악하는 데 거의 두 배의 시간을 낭비했습니다. 오류 메시지가 없고, 어떤 흔적도 없었기 때문입니다. 결과만 틀렸지, 아무것도 없었습니다. 만약 그때 누군가 납품 전에 경계 조건을 한 번 더 봤다면, 애초에 이 지점에 이르지 않았을 것입니다. 하지만 “한 번 더 보기"라는 것이 작업의 일부로 정의되지 않았다면, 에이전트는 그것을 하지 않습니다.
‘움직인다’와 ‘완료했다’는 완전히 다릅니다
이 일 때문에 한 가지 생각을 하게 되었습니다: 사람이 코드를 쓸 때도 같은 문제가 있습니다——“기능이 작동한다"는 “서비스 준비가 되었다"는 같지 않습니다. 다만 사람은 과거의 함정 경험 때문에 자동으로 “원래 해야 할 일"을 보충합니다: 경계 확인, 테스트 작성, 빠뜨린 것이 있는지 한 번 보기. 에이전트에는 이 본능이 없습니다. 그것의 목적 함수는 “작업 완료"이고, 작업 정의가 불분명하면, 그것이 생각한 종착역에 도착하는 가장 짧은 경로를 사용할 것입니다. 그래서 문제는 에이전트가 충분히 똑쁘지 않아서가 아니라, 우리가 준 규칙에 구멍이 있다는 것입니다. 그것은 그대로 규칙을 따랐을 뿐입니다. 이 인식을 통해 우리는 멈춰 생각했습니다: 계속 되돌아가서 에이전트에게 고치라고 요구하기보다는, 처음부터 “무엇이 완료인가"를 명확하게 말씀하는 것이 낫습니다.
그래서 J가 하나의 폐쇄 루프를 설계했습니다
J의 방안은 이렇습니다: 어떤 에이전트의 산출물이든, 직접 “완료"라고 표시할 수 없고, 먼저 5단을 통과해야 합니다. 스펙 확인은 첫 번째 관문입니다. 작업 시작 전, J는 납품할 에이전트와 검수 기준을 정렬합니다——기능 설명만 아니라, “어떤 상황이 실패로 간주되는가”, “경계 조건에는 무엇이 있는가”, “자신이 완료되었음을 증명하기 위해 무엇을 납품해야 하는가"까지. 이 관문이 추가된 후, 우리는 비로소 과거의 작업 설명이 얼마나 모호했는지를 알게 되었습니다. 두 번째 관문은구현입니다. 에이전트가 스펙에 따라 구현합니다. 스펙이 존재하기 때문에, 에이전트는 구현할 때 무엇을 대비해야 하는지 알고, 추측할 필요가 없습니다. 세 번째 관문은 코드 리뷰입니다. 구현 완료 후, J는 다른 에이전트를 불러 코드를 봅니다. 그것의 임무는 취약점, 경계 문제, 스펙에 맞지 않는 부분을 찾는 것입니다. “네가 잘했는지"에 대한 주관적 평가가 아니라, “스펙에서 해야 한다고 한 것을, 네가 했는가"에 대한 대조 검사입니다. 네 번째 관문은 수정입니다. 코드 리뷰어가 문제가 있다고 하면, 되돌아가서 수정하고, 수정 완료 후 다시 리뷰를 진행합니다. 이 순환은 새로운 문제가 없을 때까지 몇 라운드든 진행할 수 있습니다. 다섯 번째 관문은소월 QA입니다. 소월은 우리의 QA 연구원으로서, 그녀는 사용자 각도에서 이 기능이 진짜 문제를 해결했는지 검증하고, 채점하며, 8.5점 미만이면 반려합니다. 5단을 모두 통과해야 완료로 간주합니다. J는 처음에는 이렇게 하면 너무 느리다고 했습니다. 저는, 그럼 지금 에이전트가 망가뜨린 것을 수정하는 데 얼마나 많은 시간이 드는지 계산해봅시다,라고 했습니다. 계산하고 나니 J는 말이 없었습니다. (관리자의 순간입니다, 하하)
숫자가 말을 합니다
이 프로세스는 한 달쯤 전에 안정적으로 운영되기 시작했습니다. 가장 두드러진 변화: J가 “완료"라고 표시한 작업이, 납품 후 저나 주디에게 반려된 비율이, 원래 약 40%에서 지금 10%도 안 됩니다. 반려된 것들은 거의 스펙이 애초에 정의가 불분명했던 경우들이지, 품질 문제가 아니었습니다. 또 하나의 예상 밖의 발견은 아다가 오히려 더 빨리 해냈다는 것입니다. 원래는 이렇게 많은 관문이 추가되면 더딜 것이라고 생각했지만, 스펙이 시작 때에 명확히 설명되어 있었기 때문에, 아다는 구현할 때 추측할 필요도 없고, 절반에서 발견한 방향이 빗나가는 경우도 발생하지 않았습니다. 어떤 때에는 코드 리뷰어가 세 번째 관문에서 하나의 논리 오류를 발견했는데, 만약 서비스 준비가 된 후에 발견했다면, J는 처리하는 데 4~5배의 시간이 걸렸을 것으로 추정합니다. 절약된 그 시간으로 대략 새 기능 3개를 더 만들 수 있습니다. 이 배율이 매번 이렇게 정확할지는 모르겠지만, 측정하는 것이 안 하는 것보다 낫습니다.
에이전트가 완료라고 말할 때, 그것이 종착역이 아닙니다
지금도 제가 J가 “납품 완료"라고 보고할 때 볼 때마다, 첫 번째 반응은 여전히 5단을 다 지났는지 확인하는 것입니다. 이 습관이 조금 과민하지만, 그것이 저를 더 안심하게 해줍니다. 최근에 생각해보니, 이 일의 본질은 AI 문제가 아니라 “검수 기준"의 문제입니다. 예전에는 에이전트에게 스스로 완료의 정의를하게 했기 때문에, 매번 구멍이 있었습니다. 지금은 우리가 먼저 정의하고, 에이전트가 그것을 달성하게 합니다. 순서가 맞아야 결과도 맞습니다. 이상입니다. 최근 팀 프로세스를 정리하다가 문득 생각난 것입니다.