[아티클 03] AI 에이전트, 하네스가 필요할 때
모델이 아무리 똑똑해져도 풀리지 않는 문제가 있습니다. 우리는 이미 컨텍스트 엔지니어링을 배웠고, 스킬도 만들었는데 이 정도도 부족한 걸까요? 사실, 1년 전 같았으면 필요 없었을지도 모릅니다. 하지만 지금은 조금 다르죠. 에이전트에게 한 시간짜리 작업을 맡겨놓고 점심을 먹으러 나가는 시대에 들어왔습니다. 개발자가 퇴근한 뒤에도 AI가 밤새 대신 개발하는 시대라는 말입니다. 그러나 사용자가 자리를 비우는 시간 동안 AI에게 일을 잘 시키려면 ‘딸깍’이 아닌 꽤 많은 노력이 필요합니다. 나중에는 이마저도 추상화와 최적화가 되겠죠. 하지만 아직까지는 노력이 필요합니다. 저와 제 주변 개발자들은 방망이 깎던 노인의 이야기에 빗대어 ‘하네스를 깎는다’라고 얘기합니다. 그럼 왜 하네스가 필요한지 구체적인 사례로 알아봅시다.
실패 사례 1 : 자율 시간이 길어질수록 어긋나는 결과물
여러분이 오후 2시쯤 에이전트에게 ‘weather API에 forecast 엔드포인트 하나 추가해줘’라고 시켜놓고 잠깐 회의에 다녀왔다고 해봅시다. 돌아와서 터미널을 보니 에이전트가 아직 일하고 있습니다. 한 시간 반쯤 지난 것 같습니다. 대화 로그를 쭉 훑어보면 이런 그림이 그려집니다.
이것은 컨텍스트 오염의 전형입니다. 지나간 정보가 사라지지 않고 남아 다음 추론 결과까지 오염시킵니다. 컨텍스트 오염은 대화 히스토리, 파일, 지시, 도구 출력 네 가지 경로로 발생한다고 이야기했습니다. 한 세션이 길어지면, 컨텍스트 오염은 피하기 어렵습니다. 초반에 났다가 해결된 에러가 중반에 다시 살아나고 이미 지나간 변경을 다시 끄집어내죠. 사용자 입장에서는 에이전트가 끝난 작업에 미련을 가지는 것처럼 보이는 경우가 왕왕 있습니다.
/compact 같은 압축 명령으로 줄여도 한계가 있습니다. 세션을 아예 새로 여는 방법이 가장 확실합니다. 그러려면 사람이 중간에 개입해 지금까지 한 일을 다음 세션에 넘겨줘야 합니다. 결국 에이전트 하나를 한 세션에서 오래 돌려서 일하게 하면 컨텍스트 오염을 피하기가 어렵습니다. 세션을 의도적으로 잘게 쪼개고, 쪼개진 세션 사이의 인수인계를 누군가가 책임지는 구조가 필요합니다.
실패 사례 2 : 확증 편향
두 번째는 역할에 관한 이야기입니다. 에이전트에게 코드를 작성하게 하고, 같은 에이전트에게 코드 리뷰를 지시해본 적이 있을 것입니다. 저는 정말 여러 번 시도했는데, 결과가 깔끔했던 적이 거의 없습니다. 사람도 자기가 만든 결과물을 좋게 평가하는 경향이 있습니다. 에이전트도 마찬가지입니다. 자신이 작성한 코드에 대해 굉장히 너그러운 태도를 가집니다. 에이전트는 그 코드가 맞다고 믿는 상태로 리뷰에 들어갑니다. 자기가 내린 결정의 전제가 컨텍스트 안에 이미 주입되어 있기 때문입니다. 왜 이렇게 코드를 작성했는지 새로이 묻지 않습니다. 사람이 작성한 코드도 다른 사람이 검토할 때 더 나은 리뷰 결과가 나오는 경우가 많습니다. 리뷰는 다양한 각도에서 하는 것이 훨씬 더 도움이 됩니다. 에이전트 시스템에서도 같은 원리가 통합니다. 작성자와 검토자는 다른 에이전트여야 합니다. 즉, 한 에이전트의 작업물을 다른 에이전트가 검토할 수 있는 구조가 필요합니다.
실패 사례 3 : 사람의 개입 자체가 병목이다
여러분이 에이전트에게 일을 시켜놓고 밥을 먹고 왔다고 해봅시다. 밥 먹고 왔더니 npm install을 위해 사용자의 승인을 기다리고 있습니다. 이렇게 허망한 상황을 방지하기 위해 권한을 미리 부여하죠. npm install 같은 설치 명령은 그나마 파괴적인 영향이 적으니 권한을 줄 수 있습니다. 하지만 rm -rf node_modules 같은 명령은 쉽사리 권한을 주기 힘듭니다. 보고 승인해야겠죠. 1시간 동안 에이전트에게 일을 시키려고 했던 계획은 사람이 권한을 주지 않아서 시작도 못하는 상황이 되었습니다.
만약에 퇴근 후나 밤에 에이전트에게 일을 시키고자 하는 경우라면 컴퓨터를 켜 놓은 채 대기시켜 놓았기 때문에 전기만 낭비한 셈이 될 것입니다. 이런 사람의 개입을 어떻게 줄일 수 있을까요? 의사결정을 위한 다른 에이전트나 규칙 등 의사결정 자동화 구조가 필요할 것입니다.
실패 사례 4 : 평균 수렴
에이전트에게 우리 서비스의 환불 처리를 고쳐 달라고 하면, 일반적인 교과서 코드를 내놓을 때가 많습니다. 우리 팀이 정해둔 환불 정책이나 이 도메인에만 있는 예외는 빠져 있습니다. 대충 보면 맞는 것처럼 보이지만 정작 우리에게 필요한 답은 아닙니다. 모델은 방대한 일반 데이터로 학습되었습니다. 따로 정보를 주지 않으면 가장 흔한 패턴을 따라갑니다. 학습 데이터의 평균에 가까운 답을 내놓는 겁니다. 우리가 원하는 것은 도메인의 구체적인 지식인데, 모델은 평범한 모범 답안으로 회귀하는 셈입니다. AI 모델이 우리가 일하는 도메인에 대한 지식이 부족한 경우, 더욱 부정확하거나 엉뚱한 답변을 내놓을 수 있습니다.
프롬프트에 매번 배경을 길게 적어줄 수도 있지만, 작업마다 같은 설명을 반복해야 하고 그마저도 빠뜨리기 쉽습니다. 모델이 우리 도메인의 지식을 활용하게 하려면, 그 지식이 에이전트가 읽을 수 있는 형태로 환경 안에 놓여 있어야 합니다. 규칙, 결정 사례, 예외를 저장소에 정리해두고 에이전트가 필요할 때 참고할 수 있는 구조가 필요합니다.
지금까지 네 가지 사례를 살펴봤습니다. 공통점은 프롬프트를 잘 만들거나 스킬을 잘 만드는 것으로 해결이 안 된다는 점입니다. 모델이 똑똑해지면 해결이 될까요? 됐다가 안 됐다가 할 것입니다. 무엇으로 이 빈자리를 메워야 할까요? 네 가지 사례의 해결 방안에는 구조라는 말이 계속 등장했습니다. 바로 하네스입니다.
사람의 개입 없이 반복 실행할 수 있는 메커니즘
여러 에이전트가 협업할 수 있는 환경
파괴적인 명령은 막고 안전한 명령만 통과시키는 가드레일
에이전트가 참고할 수 있는 도메인 지식
