Agent가 작업을 맡은 후 가장 먼저 조이는 것은 작업 단위입니다.

최근 Agent에 대한 많은 토론을 읽었는데, 결국 항상 같은 질문으로 돌아왔습니다. 작품을 누구에게 주어야 하는지, 전달하기 전에 어떻게 포장해야 하는지, 반환된 후에는 어떻게 받아들여야 하는지. 프로젝트에서 이 문제가 발생하면 가장 먼저 증가하는 것은 모델 비용이 아니라 작업 단위의 복잡성인 경우가 많습니다. 작업이 너무 크게 축소되면 모델은 “마치 수행할 수 있는 것처럼” 나타납니다. 실제 문제는 일반적으로 롤백, 재생산 및 수용에 있습니다.

작업 단위가 먼저 승인될 수 있어야 합니다.

지난 며칠 동안 Thoughtworks Future of Software Development Retreat에서 Martin Fowler의 조각난 메모와 여러 토론을 하나로 묶은 후 가장 분명한 느낌은 회의의 대화가 표면적으로 흩어져 있었지만 실제로는 에이전트에게 큰 작업을 넘겨주는 한 가지 중심으로 진행되었다는 것입니다.

Kief Morris의 마무리는 가장 간단합니다. 여러 세션에서는 코드 검토, 생산 사고, 팀 업무 분담 및 모델 라우팅에 대해 논의했습니다. 서로 다른 얘기를 하는 것 같았지만 결론은 같았다. 사람들은 '단위작업’의 규모를 조정해왔다. 단위가 클수록 양도하기가 더 쉬워집니다. 단위가 클수록 돌아온 후 받아들이기가 더 어려워집니다. 모델이 이를 할 수 없는 것이 아니라 후속 확인 링크가 먼저 유지되지 못하는 것입니다.

이것이 하네스가 계속해서 언급되는 이유입니다. 컨텍스트 관리, 계산 센서, 속성 기반 테스트, 형식적 방법 등은 추가 도구처럼 들리지만 실제로는 작업 단위를 수집합니다. 어떤 사람들은 agents.md를 200줄 미만으로 제어하는데, 이는 형식의 깔끔함을 추구하기보다는 시스템이 정말 유용하고 실제로 확인할 수 있는 정보 부분만 수신하도록 강제하기 위함입니다. 컨텍스트가 너무 느슨합니다. 물론 에이전트가 실행될 수 있습니다. 그러나 실행 후에는 어떤 제약 조건을 삼켰는지 아무도 알 수 없습니다.

자체 호스팅으로 제어 화면이 향상됩니다.

자체 호스팅 모델에 대한 논의도 같은 점을 지적합니다. 토큰 가격이 비싸지고 규정 준수 요구 사항이 더욱 엄격해지고 데이터가 유출될 수 없게 되면 오픈 소스 모델과 로컬 모델이 자연스럽게 더 매력적이게 됩니다. 하지만 모델을 직접 가지고 다니면 GPU, 추론실, 라우팅, 롤백, 미세 조정, 모델 선택 등의 문제도 발생합니다. 이는 모델 기능 자체는 아니지만 시스템이 궁극적으로 안정적인지 여부를 결정합니다.

이러한 비용은 종종 과소평가됩니다. 많은 팀이 처음에는 "모델이 더 강한지"에 집중했지만 나중에 실제로 시간을 소비하는 것은 여러 모델 간의 작업 단위를 안정적으로 전송하는 것임을 발견했습니다. 언제 대형 모델을 사용할 것인지, 언제 가벼운 모델을 사용할 것인지, 언제 단순히 로컬 모델을 사용할 것인지는 언어적 선호도가 아니라 전환과 은폐에 사용할 수 있는 제어 표면의 레이어에 따라 달라집니다. 이러한 계층이 없으면 자체 호스팅은 "주도권을 행사하는 것"에서 "복잡한 운영 및 유지 관리를 직접 떠맡는 것"으로 전락하게 됩니다.

Simon Willison은 더 강력한 모델이 작업을 수행하기 위해 더 작은 모델을 선택하도록 하는 것에 대해 언급했습니다. 이 아이디어는 컨트롤 플레인이 수행하는 작업과도 매우 유사합니다. 모델 자체는 팀의 비용 경계를 반드시 알 수는 없지만 시스템은 알고 있습니다. 모델을 브로커로 취급하고 이를 사용하여 작업을 할당하는 것이 포괄적 전달을 위한 단일 모델을 맹목적으로 추구하는 것보다 실제 전달에 더 가깝습니다.

수락 및 목표는 아웃소싱할 수 없습니다.

Sam Ruby의 "Bring me a Rock"은 또 다른 문제를 조명했습니다. 모델에 작업을 제공하는 것은 실행자를 추가하는 것과 동일합니다. 책임은 사라지지 않습니다. 관리자는 탐색을 위해 LLM을 사용할 수 있으며 먼저 여러 가지 후보 솔루션을 내놓을 수 있지만 최종 승인 기준은 여전히 ​​사람의 손에 달려 있습니다. 숨겨진 목표가 가장 골치 아픈 일이다. 권한, 개인 정보 보호, 파괴적인 작업 및 컨텍스트 유출은 원래 요구 사항에 포함되지 않는 경우가 많습니다.

따라서 적합성 테스트는 사양보다 더 유용한 경우가 많습니다. 사양은 "필요한 것"을 설명하는 데 적합하고 테스트는 "일어날 수 없는 것"을 노출하는 데 더 좋습니다. 이는 에이전트 시스템에서 특히 그렇습니다. 모델은 명시적인 목표를 매우 잘 보완할 수 있지만 암묵적인 경계는 더 엄격한 검증을 통해 검증해야 합니다. 수락 조건이 모호한 설명으로 남아 있는 한 에이전트가 더 많은 작업을 수행할수록 시스템은 확률에 베팅하는 것처럼 보일 것입니다.

따라서 예전에는 매우 인간과 유사한 작업이었던 코드 검토, 사고 처리 및 작업 할당이 이제 다른 형태를 취하기 시작했습니다. 관리자는 모델을 직접 사용합니다. 표면적으로는 효율성이 향상되는 것처럼 보이지만, 실제로는 관리 방식에서 목표 관리로 관리 방식이 바뀌고 있습니다. 목표가 명확하게 작성되면 모델이 작동할 기회를 갖게 됩니다. 목표가 불분명할 경우 모델은 다른 사람들의 모호함을 증폭시킬 뿐입니다.

경험치와 독해력은 여전히 향상되고 있습니다

Dan Davies가 언급한 상호 작용 전문성과 기여 전문성도 이러한 변화와 매우 관련이 있습니다. 모델은 많은 자료를 읽고 적절한 판단을 내릴 수 있지만 시스템이 안정적이려면 사양을 읽고 결과를 보고 무엇이 잘못되었는지 알 수 있는 사람이 여전히 필요합니다. 여기서 핵심은 사람들이 누가 더 똑똑한지 모델과 경쟁해야 한다는 것이 아니라 사람들이 경계를 정의하는 위치에 계속 서 있어야 한다는 것입니다.

소프트웨어 제공과 관련하여 이 문제는 더욱 간단합니다. 에이전트가 인계받은 후 인간 작업은 수동 실행보다는 작업 분할, 경계 정의, 수용 설계 및 예외 처리에 더 많이 사용됩니다. 작업을 전달할 수 있는지 여부는 후속 컨텍스트 관리, 모델 라우팅 및 도구 조정이 수행할 가치가 있는지 여부를 명확하게 결정합니다. 단위가 명확하지 않으면 아무리 레이어가 많아도 문제가 뒤로 밀려날 뿐입니다.

지난 며칠 동안 이 단편들을 읽은 후, 내 마음에 남는 것은 특정 모델명이나 새로운 프레임워크가 아니라 더 간단한 판단입니다. 에이전트 시스템이 가장 먼저 강화해야 할 것은 모델 기능이 아니라 작업 단위입니다. 단위가 더 작고 승인이 더 엄격하며 권한이 더 엄격하면 시스템은 제어 가능한 범위 내에서 복잡성을 유지할 수 있는 기회를 갖게 됩니다.