에이전트 개발의 궁극적인 목표는 뭘까?
에이전트 개발을 하지 않는 것이다.
말장난 같지만 진심이다. 내가 개발 루프에서 빠져나와서, 개발에 점점 참여하지 않게 되는 것. 코드를 대신 짜게 하는 게 목적이 아니라 그 반복되는 실행 자리에서 내가 아예 없어지는 것. 자동화라는 단어를 나는 그런 뜻으로 쓴다.
그러려면 해야 하는 일이 하나 있다. 내가 할 일과 에이전트가 할 일을 구분하는 것. 구분해보니 내 자리는 루프의 시작과 끝이었다.
시작에 사람이 필요한 이유
처음에는 목표만 정해주면 알아서 굴러갈 줄 알았다. 실제로는 그렇게 안 됐다. 방향만 주고 맡긴 초안은 일반론으로 돌아왔고, 명세 없이 목표만 준 세션은 중간에 방향이 샜다. 결국 모든 스킬이 같은 모양으로 수렴하더라는 글에서 길게 다뤘는데, 요지는 이거다. 에이전트는 사람이 정해놓은 맥락 안에서만 똑똑하다. 컨텍스트를 안 주면 그럴듯한 걸 지어낸다.
그 맥락을 만드는 게 시작에서 내가 할 일이다. 두 가지로 좁혀진다. 요구사항과 의사결정.
요구사항은 뭘 만들지, 어떤 제약이 있는지, 뭐가 뭐에 의존하는지를 문서로 박아두는 것. 에이전트한테 주는 지도다. 의사결정은 되돌리기 어려운 선택을 미리 정해두는 것. 스택을 뭘로 갈지, 저장 구조를 어떻게 짤지 같은 것들. 이걸 흐릿하게 둔 채 자동으로 흘려보내면 0.5%만 틀어져도 그 위에 쌓인 게 전부 그 오류를 상속한다. 뒤에서 디버깅하는 비용이 자동화로 아낀 것보다 커진다.
여기에 하나 더, 항목마다 종료조건을 단다. “뭐가 통과하면 끝인지”를 정해두는 것. 이게 있으면 에이전트는 “다 된 것 같은데요”가 아니라 조건 통과로 끝을 판정하고, 나는 그 조건만 믿고 자리를 비울 수 있다. myWiki 빌드플랜을 짜던 세션에서 내가 정리한 규칙이 이거였다.
“울타리 안에서 정할 수 있는 건 자율, 울타리 밖이거나 못 되돌리는 건 너한테.”
요구사항 박고, 의사결정 내리고, 종료조건 달고. 이 셋이 준비되면 실행은 goal로 던진다. 그때부터 루프는 에이전트 거다.
끝에 사람이 필요한 이유
루프가 돌고 나면 결과가 나온다. 여기가 두 번째 내 자리다.
이 자리를 비웠다가 멘탈이 터진 적이 있다. 마이위키를 만들 때였는데, 테스트를 안 돌리고 무인으로 만들기만 시켰다. 결과물은 쌓이는데 현황 파악은 안 되고, 그 사이 요구사항은 또 바꾸고 싶어지고. 부채가 쌓였다고 해야 하나. 그러고 3일을 쉬었다.
그러니까 종료조건을 통과했다고 다 끝난 게 아니다. 나온 걸 리뷰하고, 방향이 맞는지 보고, 아니면 조정한다. 이 부분은 아직까지는 사람이 필요하다. 초안은 내 검수를 꽤 받아야 하고, 방향도 수시로 다시 잡아준다.
리뷰가 필요하다는 게 매번 결과를 붙잡고 고친다는 뜻은 아니다. 그건 자동화가 아니라 감시를 자동화한 거다. 판단할 것만 올라오게 하고, 나는 판단만 한다. 실행 중에도 올라오는 게 있긴 하다. 못 정하는 결정, 비가역이라 내 몫인 결정은 루프를 멈추고 나한테 올라온다. 그러니 정확히는 시작과 끝, 그리고 가끔 중간. 그래도 반복되는 실행 자체에서는 빠져 있다.
경계를 긋고 우선순위를 정하면
정리하면 이 그림이다. 시작과 끝에 내가 있고, 그 안에 루프가 있다.
이 경계를 잘못 그으면 양쪽 다 망가진다. 사람이 해야 할 자리에 에이전트를 들이면 품질이 무너지고, 에이전트가 해야 할 자리에 사람이 앉아 있으면 생산성이 떨어진다. 초안 한 편을 내가 직접 쓰거나 plan 항목을 하나씩 손으로 실행하면 자동화가 무슨 의미인가 싶어진다.
경계가 서고부터는 역할이 바뀌었다. 예전엔 모든 키 입력을 내가 쳤는데, 지금은 에이전트가 실행하고 나한테는 판단만 올라온다. 실행자에서 관리자로. 하루에 여러 갈래가 동시에 굴러가는데 내가 실제로 붙잡고 있는 시간은 얼마 안 된다.
루프에서 완전히 빠졌다고 말하면 시기상조다. 끝자리의 리뷰와 조정은 여전히 내 몫이니까. 그래도 경계를 잘 긋고, 뭐부터 맡길지 우선순위를 정하면, 점점 개발 루프에서 빠져나오게 되지 않을까. 지금은 시작과 끝 사이를 조금씩 넓혀가는 중이다.