Hashicorp 창립자는 로컬 모델이 '아직 충분히 좋지 않다'고 생각함

와, 정말 흥미로운 아이디어네. 어떻게 설정하는지 간단히 알려줄 수 있어?

Claude Code의 경우, opencode CLI를 언제 어떻게 호출하는 게 적절한지에 대한 스킬을 설정해 둠. 별도의 워크플로우에서는 GPT가 opencode 내에서 서브 에이전트를 사용해 비슷한 작업을 수행하게 함. opencode에서 Anthropic 구독을 안전하게 쓸 수 있다면 Claude Code는 바로 버릴 거임. 탐색 같은 저강도 작업에는 Qwen을 쓰도록 유도하고, 고강도 사고가 필요한 작업은 클라우드 모델에 맡김.

어떤 하네스를 쓰느냐에 따라 다름. 기술적으로는 다 가능하지만, 요즘 나오는 것들은 제대로 구현된 게 많고, 사실 이게 아주 새로운 것도 아님. 기본적으로 Mixture of Agents 같은 거임. 핵심은 메인 모델을 똑똑한 범용 모델로 두고, 얘가 서브 에이전트들한테 일을 시키는 구조임. 서브 에이전트들은 각자 작업에 맞는 모델을 돌리고, 실질적인 작업은 얘네가 다 함. API를 써야 하면서도 일부 모델은 직접 돌리고 싶을 때 가장 효율적인 방법이지...

5만 줄은 미친 듯이 많은 양은 아니라서 굳이 쪼갤 필요는 없다고 봄. 큰 프로젝트라도 모놀리스 구조인 경우가 많지만 결국 섹션이 나뉘어 있고, 에이전트가 모든 걸 메모리에 들고 있을 필요 없이 기능과 아키텍처에 대한 상위 수준 문서만 있으면 됨.

우리가 약간 다른 이야기를 하는 것 같기도 한데(누가 알겠어), 제대로 리팩토링된 코드는 Gemma 12b 같은 훨씬 작은 모델로도 처리할 수 있는 작은 파일 세트에 패치를 적용하게 해 줌.

Gemma 12B가 코드베이스 패치 짜기에 충분하다고 느끼는 거 보면(심지어 모델 쓰려고 리팩토링까지 한 거 같은데?), 우리가 지금 서로 완전히 다른 얘기를 하고 있는 게 확실함.

코드베이스 전체를 다 올릴 필요는 없지만, 모듈 전체를 단일 context window에서 처리할 수 있으면 모델한테 가장 많은 맥락과 유연성을 줄 수 있어. 더 작은 덩어리로 나누면 더 작은 윈도우를 가진 에이전트 여러 개를 돌릴 수 있거든(로컬에서 256k 하나 대신 32-64k 여러 개). 병렬 처리가 쉬워지고 merge conflict나 복잡한 순서 꼬임도 줄어들지. 나 FAANG 출신인데, 우리는 코드 Agent 친화적으로 만들려고 스프린트 두 번을 통째로 썼어. 그게 딱 두 가지를 의미했지. 1. 각 프로젝트에 agents.md 추가하기, 2. refa ...