에이전트형 개발은 검증에 달려 있다. 클라우드 네이티브 소프트웨어에서는 이것이 런타임 문제다.
출처: The New Stack
비동기 에이전트는 반환하는 결과를 신뢰할 수 있을 때만 유용합니다. 분산 시스템에서는 그 신뢰가 에이전트에게 제공할 수 있는 런타임에 달려 있습니다: 내부 루프, PR 전에.
Cognition의 Ido Pesok이 최근 글을 발표했습니다. 이는 주목할 만한 이정표에 관한 내용입니다.
그는 처음으로 그의 팀이 이벤트, 일정, 자동화 및 다른 에이전트로부터 비동기적으로 더 많은 Devins를 트리거한다는 점을 강조했습니다. 이제 에이전트는 개발자가 직접 구동하는 것이 아니라 스스로 실행되어 작업을 반환합니다.
숫자는 이정표일 뿐이며, 중요한 것은 그것이 강요하는 점입니다.
개발자가 모든 에이전트를 직접 구동했을 때, 그 개발자는 동시에 검증자이기도 했습니다. 그들은 차이를 검토하고 실제 시스템에 적용해 보며 올바른지 판단했습니다. 각 단계에서 개발자를 제외하면 검증자도 사라집니다. 이제 에이전트는 자신이 생성한 코드의 속도와 양에 맞춰 스스로 작업을 검증해야 합니다. Ido가 말했듯이, 비동기 에이전트는 개발자가 반환 결과를 신뢰할 수 있을 때만 유용합니다.
“스스로 검증할 수 없는 비동기 에이전트는 누구의 시간도 절약해 주지 못합니다. PR을 열고 하위 단계에 평가를 맡기는 것이죠.”
이 말은 문제 전체를 재구성합니다. 생성 자체는 이미 오래전부터 제약이 아니었습니다. 현재의 제약은 검증이며, 스스로 검증하지 못하는 비동기 에이전트는 아무도 시간을 절약해 주지 못합니다. PR을 열고 하위 단계에 평가를 맡기는 것이죠.
왜 초록색 테스트 실행이 아무 의미가 없을 수 있는가
harnessed agent는 스스로 실제 작업을 수행합니다. 코드를 작성하고, 로컬에서 실행 가능한 단위 테스트를 돌리며, 목(mock)들을 활용해 초록색 결과를 반환합니다. 문제는 초록색이 무엇을 의미하느냐입니다.
에이전트는 그 목들을 직접 만들었습니다. 이는 의존성이 어떻게 동작할지에 대한 자체 모델에 맞추어 만든 것이며, 바로 그 모델이 잘못될 가능성이 있습니다. 따라서 에이전트는 자신의 가정에 대해 변경 사항을 테스트합니다. 가정이 통과하면, 실제 현실에서 에이전트가 추측한 부분은 한 번도 건드려지지 않습니다. 스텁에 대한 깨끗한 실행은 에이전트가 내부적으로 일관됨을 증명할 뿐, 변경 사항이 실제로 동작한다는 증거는 아닙니다.
서비스가 한 곳에서만 실행되는 경우 이 격차는 작습니다. 하지만 클라우드 네이티브 시스템에서는 전체 위험이 됩니다. 변경 사항은 단독으로 존재하지 않습니다. 호출하는 서비스, 의존하는 브로커와 데이터베이스, 그리고 에이전트 자체 프로세스에서는 볼 수 없는 타임아웃·재시도 메시와 같은 메시가 함께 존재합니다. 중요한 실패는 이러한 경계에서 발생합니다. 계약이 어긋났거나, 필드가 소비자가 기대하는 방식과 다르게 직렬화되었거나, 재시도 정책 하에서 하위 호출이 타임아웃되었거나, 스키마 변경이 로컬에서는 감지되지 않을 수 있습니다.
이러한 동작은 변경 사항이 시스템의 나머지와 함께 실행될 때 비로소 드러납니다. 따라서 에이전트는 완벽한 실행을 기록하면서도 실제 트래픽 하에서는 두 단계 떨어진 서비스까지 다운시키는 코드를 배포할 수 있습니다. 로컬에서는 초록색, 프로덕션에서는 붉은색. 에이전트는 모든 것을 올바르게 수행했지만, 문제가 된 환경이 원인이었습니다.
루프가 닫히는 위치가 결함 비용을 결정한다
여기가 비용이 급증하는 부분입니다.
에이전트가 반복 중에 잡아낸 실패는 몇 초 안에 해결됩니다. 변경을 실행하고 실제 오류를 확인한 뒤 수정하고 다시 실행합니다. 인간이 이를 알 일조차 없습니다.
반면 PR이 머지된 뒤에 잡힌 동일한 실패는 시간을 많이 소모합니다. 그때는 에이전트가 이미 다음 작업으로 넘어갔고, 컨텍스트는 차가워졌습니다. 어떤 엔지니어가 코드를 디버깅해야 하는데, 그 코드는 에이전트가 만든 것이며 에이전트는 자신의 사고 과정을 다시 설명할 수 없습니다.
이것이 좋은 경우입니다. 나쁜 경우는 이미 깨진 변경 위에 다른 변경들이 쌓여 있다는 점입니다. 다른 에이전트들이 잘못된 동작을 기반으로 빌드된 것이죠. 이제는 하나의 PR을 고치는 것이 아니라, 체인을 풀어야 합니다.
데모에서는 절대 드러나지 않지만, 분기마다 반드시 나타나는 비용입니다. 한 개발자가 한 에이전트를 실행했을 때 재작업은 그 개발자에게만 국한됩니다. 하지만 에이전트가 에이전트를 실행하고 병렬로 머지될 때, 내부 루프를 빠져나온 모든 결함은 이미 다른 작업이 정상이라고 가정하고 있는 공유 시스템에 침투합니다.
생성은 저렴해졌지만, 나쁜 변경을 늦게 잡는 비용은 줄어들지 않았습니다. 검증을 PR 뒤(오른쪽)로 미루면, 에이전트를 추가할수록 재작업이 기하급수적으로 늘어납니다. 검증을 내부 루프(왼쪽)로 옮기면 대부분의 결함이 PR 자체가 되기도 전에 사라집니다.
“생성은 저렴해졌지만, 나쁜 변경을 늦게 잡는 비용은 줄어들지 않았습니다.”
에이전트를 추가한다고 자동으로 처리량이 늘어나는 것은 아닙니다. 검증이 머지 후에 이루어진다면, 더 많은 에이전트는 사람이 틀린 것을 증명하기 위해 기다리는 긴 대기열을 만들 뿐입니다. 작성은 확장했지만, 신뢰는 그대로였습니다.
PR 뒤에 검증하고, 경계 실패가 늦게 드러나 인간 재작업으로 되돌아가는 경우. 내부 루프에서 검증하면 에이전트가 실제 일시적인 런타임에서 실행돼 자체 실패를 수정하고, 이미 시스템에 대해 검증된 PR을 엽니다.
실제 루프를 닫는 모습
해결책은 사후 검증이 아니라 PR 전에 닫히는 루프입니다.
에이전트에게 프로덕션과 동일한 격리된 런타임을 제공하십시오. 그곳에 변경을 배포하고, 목이 아닌 실제 주변 서비스와 함께 실행합니다. 실제 실패를 읽고, 수정하고, 다시 실행합니다. 검사 범위는 의도적으로 넓게 잡습니다: 단위 테스트뿐 아니라 통합 경로, 계약, 실제 라우팅 하에서의 하위 동작까지 포함합니다. 에이전트는 모든 검사가 실제 시스템에서 초록색이 될 때까지 반복하고, 그때 비로소 PR을 엽니다.
이제 PR은 다른 의미를 갖습니다. 이미 살아갈 세계에 대해 검증된 상태로 도착합니다. 인간 리뷰는 의도와 설계에 집중하고, “이 에이전트가 조용히 세 서비스 떨어진 곳을 깨뜨렸는가?” 같은 질문은 에이전트가 PR이 존재하기 전 몇 초 안에 이미 답했습니다.
이것이 비동기 개발에 필요한 폐쇄 루프입니다. 에이전트는 채점용 초안을 제출하는 것이 아니라, 이미 검증된 변경을 전달합니다.