Thoughtworks가 Technology Radar 35호를 공개했습니다. 도구·기법·플랫폼·언어·프레임워크를 Adopt, Trial, Assess, Caution 네 단계로 나눠 평가하는 반기 보고서입니다.
이번 호의 중심은 AI 에이전트를 둘러싼 환경입니다. 모델 성능이 아니라 에이전트가 돌아가는 하네스를 어떻게 만들고 유지하는지가 주제로 올라왔습니다.
레이더는 권고 단계를 분명히 적어 둡니다. Adopt는 적극 도입, Trial은 검증됐지만 아직 Adopt만큼은 아닌 것, Assess는 지켜볼 것, Caution은 대안을 찾거나 피할 것입니다.
함께 붙은 진단은 무조건 프런티어 모델을 고르던 단계가 끝났다는 것입니다. 오픈웨이트 모델과 모델 라우팅이 설계 선택지로 들어왔습니다.
하네스 엔지니어링, 하나의 분야가 되다
하네스는 에이전트 주변의 모든 것을 가리킵니다. 메모리, 컨텍스트, 피드백 루프, 가드레일이 여기 들어갑니다.
레이더는 하네스 엔지니어링을 개별 항목 하나가 아니라 테마로 올렸습니다. 여러 기법과 기술을 잇는 개념이라서입니다.
플러그인 생태계도 붙었습니다. Agent Plugins, 에이전트 플러그인 마켓플레이스, Agent Package Manager가 이번 호에 함께 등장합니다.
하네스는 한 번 만들고 끝나는 설정이 아니라 계속 관리하는 자산이라고 레이더는 봅니다. 품질 평가, 스스로 개선하는 하네스, 피드백 플라이휠이 같이 언급됩니다.
전망은 platform engineering과 겹칩니다. 기업용 하네스가 별도 제품으로 나올 수 있다는 이야기입니다.
프런티어 모델을 기본값으로 두지 않는다
1년 전만 해도 오픈웨이트 모델과 프런티어 모델의 차이는 컸습니다. 지금은 많은 작업에서 그 차이가 줄었다고 평가합니다.
비용만이 이유가 아닙니다. 오픈웨이트 모델은 퍼블릭 클라우드, 네오클라우드, 자체 하드웨어 어디서든 돌릴 수 있습니다. 소스 코드와 프롬프트를 사내에 두는 선택지가 생깁니다.
코딩 에이전트 작업에서는 GLM 계열이 실질적인 대안으로 올라왔고, 로컬 코딩 모델도 늘었습니다.
프런티어 LLM만이 답도 아니라고 봅니다. 구조화 데이터를 위한 파운데이션 모델, Jev 같은 결정 모델이 함께 언급됩니다.
모델 라우팅이 설계 결정으로 떠올랐습니다. 모든 요청을 프런티어 모델로 보내는 기본값을 경계하라고 조언합니다.
선택지가 늘면 책임도 늘어납니다. 어떤 작업에 어느 모델을 쓸지 팀이 직접 정하고 근거를 남겨야 합니다.
에이전트를 더 많이 굴리기
지난 호가 코딩 에이전트 도입이었다면, 이번 호는 여러 세션을 동시에 돌리는 운영입니다. 개발자가 세션 여러 개를 띄워 각각을 조종하는 방식이 가장 흔합니다.
Claude Squad, T3 Code, Orca, Paseo, Herdr 같은 도구가 병렬 세션을 관리합니다. 대부분 답을 기다리는 세션을 위로 올리는 주의 인박스를 갖습니다. Paseo는 휴대폰에서 세션 상태를 봅니다.
git worktree로 세션마다 작업 사본을 나누지만, 반쯤 병합된 브랜치가 엉키는 부작용이 남습니다.
한 세션 안에서는 서브에이전트가 좁은 작업을 맡습니다. 탐색과 재시도를 본 컨텍스트 밖으로 밀어내는 방식입니다.
밤새 돌리는 무인 빌드나 에이전트 떼로 넘어가는 흐름도 소개됩니다. 다만 Thoughtworks 내부에서는 직접 통제하는 병렬 세션이 현실적인 출발점이라고 봅니다.
병목은 리뷰로 옮겨간다
세션이 늘면 사람의 주의와 리뷰 능력이 병목이 됩니다. 리뷰가 못 따라가면 검토하는 척하는 절차로 전락합니다.
코드는 리뷰보다 빨리 쌓이고, 그다음에는 배포 파이프라인이 막힙니다. 레이더는 세션을 늘리기 전에 리뷰와 배포가 감당할 양을 먼저 계산하라고 합니다.
AgentsView는 지난 세션을 다시 보고, Hunk는 에이전트가 만든 변경을 검토합니다. 팀 단위로 세션을 공유하는 Entire CLI도 초기 사례로 나옵니다.
앞으로는 여러 엔지니어의 에이전트 작업을 묶는 도구가 더 나올 것이라고 봅니다.
AI 팩토리라는 인프라
토큰 경제는 결국 인프라 경제라는 진단도 들어갑니다. 모델 가격만이 아니라 모델 선택, 라우팅, 배칭, 데이터 이동이 비용을 만듭니다.
쿠버네티스가 그 기반으로 지목됩니다. KServe와 KAITO는 모델 서빙과 가속기 인식 스케줄링을, llm-d는 분산 추론을, LiteLLM은 모델과 공급자 라우팅을 맡습니다.
저장과 네트워크 계층도 함께 나옵니다. VAST DataStore는 가속기 위주의 워크로드가 요구하는 고처리량 스토리지를, Netris는 소프트웨어 정의 네트워크를 다룹니다.
모델, GPU, 추론 엔진, 스토리지, 네트워크를 하나의 플랫폼 계층에서 프로그램 가능한 자원으로 다루는 쪽으로 이동 중이라는 정리입니다.
결론은 순서입니다. 모델을 작업별로 고르고, 하네스에 주인을 정하고, 리뷰 용량을 먼저 재는 것입니다. 이 순서를 건너뛰면 에이전트를 늘릴수록 검토 비용만 커집니다.
컨텍스트를 얼마나 넣고 무엇을 버릴지가 결과 품질을 좌우합니다. 메모리를 제품 기능으로 보는 시각이 여기서 나옵니다.
가드레일도 설정 파일 한 장으로 끝나지 않습니다. 어떤 도구를 허용하고 어떤 호출을 막을지 계속 고쳐야 합니다.
자체 하드웨어에서 돌린다는 선택은 보안 요구가 강한 조직에서 특히 중요합니다. 코드와 프롬프트가 외부로 나가지 않기 때문입니다.
세션을 여러 개 띄우면 전환 비용이 생깁니다. 주의 인박스가 도구마다 붙는 이유입니다.
배포 쪽도 같은 압력을 받습니다. 경로별로 작업이 어디서 밀리는지 표시해 두면 어느 지점을 늘려야 하는지 보입니다.
이 계층이 굳으면 모델을 바꾸는 일이 코드 수정이 아니라 라우팅 설정 변경이 됩니다.
레이더는 반기마다 갱신됩니다. 항목 이름보다 링이 어느 방향으로 움직이는지를 보는 편이 오래 쓸 만합니다.
하네스 품질을 재는 일은 생각보다 어렵습니다. 같은 작업을 반복해 성공률이 오르는지 보는 방법이 현실적입니다.
에이전트를 오래 돌리는 작업은 실패 비용이 큽니다. 무인 빌드를 쓰려면 되돌리기 쉬운 작업부터 골라야 합니다.
인프라를 직접 고르는 팀이라면 라우팅 계층부터 정리하는 편이 낫습니다. 모델을 바꿀 때 손대는 곳이 줄어듭니다.
링 표기를 확인하고 읽으면 지금 도입할 것과 지켜볼 것이 나뉩니다.
에이전트 도구는 바뀌는 속도가 빠릅니다. 도구 이름을 외우기보다 필요한 기능 묶음을 정해 두는 편이 낫습니다.
원문은 사분면별 인터랙티브 화면과 PDF로 함께 제공됩니다. 관심 영역부터 골라 읽을 수 있습니다. 항목 설명은 짧지만 링과 사분면이 함께 붙어 있습니다.
MSI 지포스 RTX 5070 Ti 게이밍 트리오 OC D7 16GB 트라이프로져4
로켓배송으로 바로 받기이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
