AI 콘텐츠 생성기는 독립적인 에이전트로 만들어야 할까, 아니면 단순 도구 호출로 처리해야 할까?

상황에 따라 다르지. 얻는 품질이 좋다면 그냥 둬. 아니면 에이전트를 만들어. 하지만 에이전트는 유지보수가 필요하니까 스스로 물어봐야 해: "그럴 가치가 있는가?"

도구 호출이 답이야. 더 나아가서, 결과물을 만드는 건 메모리가 아예 없어야 한다고 생각해. 생성기가 이전 실행을 기억하는 순간, 출력물이 어때야 하는지에 대해 각기 다른 의견을 가진 두 주체가 생기는 거고, 그 불일치는 아무도 추적할 수 없는 드리프트로 나타나거든. 내가 만든 트레이딩 도구의 초안 작성 단계에서도 똑같이 분리했어. 모델은 초안을 쓰고, 멍청한 엔진이 점수를 매기는데, 둘은 절대 상태를 공유하지 않아.

난 도구 패키지를 만들면서 실험 중이야. 도구의 올바른 사용법이나 그게 어떤 프로젝트를 위한 건지에 대한 맥락을 함께 패키징하는 거지. LLM이 지어낼 여지를 줄이고, 픽스처와 계약을 활용하는 방식이야. 물론 규모에 따라 다르겠지. DB가 있는 도구는 확장성에 한계가 있으니까. 어떤 도구는 활성 하드웨어인 내 노트북에서 프로젝트 주변으로 유지하는 게 낫더라고. 특히 어셈블리나 에뮬레이션처럼 지식이 계속 쌓이는 경우엔 더 그래. 주소가 항상 보이는 대로가 아니거나, 다른 변수 스위치에 의존하는 경우 말이야. 예를 들어 '링크의 모험'에서 마법 거울을 시작 상자에 넣었을 때, 아이템은 있었지만 조건 스위치 포인터가 활성화되지 않아서 사용할 수 없었거든. 이런 경우엔 도구를 패키징하는 것과 반대로, 에뮬레이터 주변에 도구를 구축해서 SQLite와 함께 확장하고 학습할 공간을 줘야 해. 그냥 내 경험담이야.

내가 실제로 하는 걸 뭐라고 불러야 할지 모르겠어. 코덱스나 작업 에이전트를 쓰는 건 아니거든. MPC가 백엔드 하니스를 호출하고, 프로젝트에서 사용 가능한 도구들과 구글 공유 드라이브를 통해 여러 프로젝트에서 공통으로 사용할 수 있는 일반 지식으로 추론하는 방식이야. 지속 가능한 것들 말이지. 전부 그냥 채팅에서 나온 것들이야.

도구 호출이지. 나한테 결정적인 이유는 신뢰성보다 비용이었어. 도구는 한 번의 요청이니까 실행 전에 대략적인 비용을 알 수 있거든. 일단 한 단계가 독립적인 에이전트가 되면 스스로 몇 번의 턴을 돌지 결정해버리니까, 같은 입력이라도 운이 나쁘면 비용이 몇 배로 나올 수 있고 로그에는 왜 그런지 이유도 안 나와. 그런 식으로 결과물 가격을 책정하긴 어렵지.

나도 도구 호출파야. 나만의 루프를 주는 유일한 경우는 스스로 출력을 보고 수정해야 할 때인데, 그것조차 사실 검사기를 덧붙인 재시도일 뿐이지.

Gamma를 도구로 쓰는 게 맞는 듯. 오케스트레이터가 명확한 입력을 주고 결과물을 확인하면 되니까. 만약 생성 과정에서 중간 결과물을 검토하고, 다른 행동을 선택하고, 여러 번 시도해야 한다면 그때는 하위 에이전트를 고려해볼 것 같음. 별도의 컨텍스트를 쓰면 그런 시도들이 오케스트레이터의 대화 내용에 섞이지 않게 할 수 있으니까.

난 생성기 프로세스의 각 단계를 사실상 툴 콜로 처리하고 있고, 그걸 실행하는 트리거도 사실상 툴 콜이야. 뉴스 스캔, 주제 검색, 기사 작성 같은 각각의 작업이 고용 가능한 업무 단위라서 재조합이 가능하거든(뉴스레터, 뉴스 스윕, 특정 주제 집중 등).

각 조각은 기능 수행에 필요한 메모리와 LLM 호출을 가져. 보통은 그래.

솔직히 단순할수록 좋아. 모든 걸 '추론 에이전트'로 만들면 의도만 흐려지고 토큰 비용만 더 많이 나오더라고. 난 생성 기능을 타입이 지정된 툴로 취급하는 '로직 기반 오케스트레이터'를 선호해. 이런 '관료적 계층'을 어떻게 매핑하는지에 대한 로직 브리프가 있는데, 원하면 DM 줘.