오랫동안 코딩 에이전트에 대한 질문은 "정말 일을 해낼 수 있는가"였다. 그 질문은 조용히 매듭지어지고 있다. 범위가 명확한 작업이라면, 저장소가 눈앞에 있고 테스트를 실행할 수 있는 환경에서 좋은 에이전트는 리뷰를 통과하는 실제 변경을 만들어낸다. 그리고 그것을 믿기 시작하는 순간, 아무도 미리 경고해 주지 않은 문제에 부딪힌다. 에이전트를 계속 바쁘게 만들 만큼 빠르게 일을 생각해낼 수 없다는 것이다.
실행은 더 이상 제약이 아니다
소프트웨어 제품에는 항상 무한한 할 일이 있다. 백로그는 결코 비지 않으며, 더 나아질 수 있는 것들의 목록은 끝이 없다. 그래서 팀이 에이전트에게 줄 일이 바닥날 수 있다는 말은 이상하게 들린다. 하지만 "무한한 일이 존재한다"는 것과 "에이전트가 가져다가 끝낼 수 있는 형태의 일이 존재한다"는 것은 매우 다른 두 명제이며, 팀이 막히는 지점은 바로 이 둘 사이의 간극이다.
에이전트는 명확한 작업을 몇 분 만에 실행할 수 있다. 그 명확한 작업—충분한 맥락과 적절한 범위, 완료의 정의를 갖춘—을 작성하는 데는 여전히 사람이 예전과 같은 20분이 걸린다. 실행이 느린 부분이었을 때는 이것이 괜찮았다. 명세 작성은 노력의 5퍼센트였고 나머지 95퍼센트가 실행이었기 때문이다. 실행 비용을 거의 0으로 낮추면 이 비율은 뒤집힌다. 이제 명세 작성이 비싼 절반이 되고, 에이전트 하나를 먹여 살릴 수 있던 팀이 세 개는 먹여 살릴 수 없다는 것을 발견한다.
병목이 상류로, 당신에게로 옮겨갔다
이것이 작업 공급 문제다. 에이전트 주도 개발의 제약은 더 이상 에이전트가 일을 해내는 능력이 아니라, 조직이 잘 다듬어진 일거리를 만들어내는 능력이다. 그리고 이 제약은 당신이 가진 가장 희소한 사람들—다음에 무엇을 해야 하는지, 왜 해야 하는지를 말할 만큼 충분한 맥락을 가진 사람들—에게 떨어진다.
당신은 이것을 기묘한 압박감으로 느낀다. 에이전트는 빠르고 믿을 만해서 대기열은 당신이 채울 수 있는 속도보다 빠르게 비워지고, 그 채우는 작업이야말로 판단력과 제품 감각, 시스템이 향하는 방향에 대한 지식을 필요로 하는 부분이다. 병목은 사라지지 않았다. 키보드에서, 키보드가 무엇을 해야 하는지 아는 사람의 머릿속으로 옮겨갔을 뿐이다.
에이전트가 일 공급을 도와야 한다
공급 문제를 넘어서는 유일한 방법은 공급을 늘리는 것이며, 작업을 정의하는 사람은 확장되지 않는다. 그래서 일을 실행하는 에이전트가 그 일을 만들어내는 것도 돕기 시작해야 한다—의미 없는 잡무를 지어내는 것이 아니라, 당신의 시스템을 이미 흐르고 있는 신호를 구체적이고 바로 실행 가능한 작업으로 바꿈으로써다.
TaskGoblin은 오늘날 이미 이를 실천하고 있다. "작업 생성"이라고 생각하지 못했을 두 곳에서다.
- 리뷰 발견 사항이 일이 된다. 에이전트가 리뷰하는 모든 머지 리퀘스트는 구체적이고 위치가 명확한 발견 사항을 만들어낸다—이 함수에는 정확성 버그가 있다, 이 경로는 테스트되지 않았다, 이건 보안상 의심스럽다 등. 각 사항은 사실상 완료의 정의를 갖춘, 미리 작성된 작업이다.
@taskgoblin fix라고 답하면 그 발견 사항이 변경으로 바뀐다. 누구도 앉아서 그 티켓을 작성할 필요가 없었다. 리뷰가 그것을 공급한 것이다. - 상시 루프가 일이 된다. Loops은 시계에 따라 실행되는 작업 생성기다. "평일마다 머지되었지만 해당 이슈가 아직 열려 있는 작업을 찾아 닫는다", "CI가 너무 오래 빨간불인지 감시한다". 지시는 한 번만 작성하면 되고, 이후에는 계속해서 구체적인 일을 만들어낸다—혹은 할 일이 없을 때는 올바르게 아무것도 만들지 않는다—누구도 대기열을 수동으로 채우지 않아도 된다.
두 경우 모두 에이전트는 무엇을 할지 지시받기를 기다리지 않는다. 시스템의 상태를 읽고 구체적이고 끝낼 수 있는 다음 일을 스스로 제안한다.
왜 맥락이 모든 것을 좌우하는가
에이전트가 제안하는 일이 대체로 가치가 낮은 이유는 모델이 충분히 똑똑하지 않아서가 아니다. 에이전트가 당신에게 무엇이 중요한지 모르기 때문이다. 제품의 의도에 눈이 먼 채로는, 에이전트는 자신이 볼 수 있는 스무 가지 리팩터링을 기꺼이 제안하면서도, 실제로 비즈니스를 움직이는 단 하나의 변경은 제안하지 않는다—코드는 무엇이 가능한지를 알려줄 뿐, 무엇이 중요한지는 알려주지 않기 때문이다.
그래서 유용한 작업 생성 지점은 실제 의도에 뿌리를 둔 곳들이다. 리뷰 발견 사항이 중요한 이유는 누군가 선택해서 만든 변경 위에 자리하고 있기 때문이다. 예약된 루프가 중요한 이유는 이슈와 머지를 매일 동기화된 상태로 유지하는 것이 가치 있다고 사람이 판단했기 때문이다. 제안된 작업을 할 가치가 있게 만드는 맥락은 코드 안에만 있지 않다. 그것은 이슈와 논의, 코드를 둘러싼 결정들 속에 있다—그리고 우리 에이전트처럼 그런 시스템 안에서 살아가는 에이전트는 추측하는 대신 그 의도를 읽어낼 수 있다.
이제 가치는 어디에 있는가
이것이 우위를 어디에 남기는지 분명히 해 둘 가치가 있다. 모델들이 거의 모든 것을 실행할 수 있는 방향으로 수렴함에 따라, 불균형한 가치는 더 이상 가장 똑똑한 에이전트를 가진 쪽에 쌓이지 않고, 좋은 에이전트에게 의미 있는 일을 계속 공급할 수 있는 쪽에 쌓이기 시작한다. 승리하는 한 수는 더 영리한 모델이 아니다. 당신의 도구들에 흩어진 의도와 그에 따라 행동할 수 있는 에이전트 사이의 고리를 닫는 것이며, 그럼으로써 "다음에 무엇을 해야 하는가"가 더 이상 당신 자신이 짊어진 병목이 되지 않게 하는 것이다.
이것이 우리가 실제로 맞서 만들고 있는 문제다. 에이전트가 코드를 작성할 수 있게 만드는 것은 전반전이었다. 무엇이 할 가치가 있는지 항상 알게 하고—당신을 기다리지 않고도 당신의 맥락을 다음의 구체적인 작업으로 바꿀 수 있게 하는 것—이것이 전반전의 가치를 결정하는 후반전이다.
