#opencode-omo-series

에이전트를 많이 만든다고 작업이 자동으로 잘 굴러가지는 않는다. 오히려 역할이 겹치고, 권한이 과하게 열리고, 어느 순간부터는 사람이 에이전트들을 관리하느라 더 바빠지는 일이 생긴다. OpenCode와 OMO(Oh My OpenAgent)를 함께 쓸 때 필요한 것은 더 많은 프롬프트가…

테스트 하네스가 테스트 대상을 외부로부터 감싸고 실행 환경을 제어하듯, 에이전트 오케스트레이션 시스템 역시 견고한 하네스가 필요하다. 하네스 없이 개별 에이전트만 늘려가는 방식은 위험하다. 어떤 에이전트가 어떤 권한으로 무엇을 실행했는지 추적이 되지 않을뿐더러, 에이전트의 작은 실수가…

에이전트 하나에게 탐색, 구현, 리뷰를 모두 시키면 일단 코드는 나온다. 하지만 그 코드가 정말 요구사항에 맞는지, 아키텍처를 해치지는 않는지 확인하는 주체가 사라진다. 구현자와 리뷰어가 같은 에이전트라면, 그 리뷰어는 필연적으로 자기 코드가 맞다고 생각하는 확증 편향에 빠지기 때문이다…

OMO는 OpenCode의 대체재가 아니다. OpenCode가 제공하는 에이전트, 커맨드, 스킬, 권한 시스템이라는 물리적 토대 위에 Sisyphus 중심의 오케스트레이션 레이어를 얹는 플러그인이다. 따라서 OMO를 활성화하더라도 기존에 구축한 .opencode/ 하위의 모든 설정 체계…

프롬프트에 “수정하지 마라”고 써도 에이전트는 수정할 수 있다. edit: allow가 열려 있으면 텍스트 지시는 의도일 뿐이고, 실행은 permission 설정이 결정하기 때문이다. 프롬프트는 에이전트를 설득하는 과정이지만, permission은 에이전트가 넘지 못하는 물리적인 경계다…

에이전트 파일의 역할은 단순히 프롬프트를 저장하는 것에 그치지 않는다. 특정 모델, 실행 권한, 온도, 그리고 출력 형식까지 하나의 패키지로 묶어 고정하는 것이 핵심이다. 이를 통해 에이전트를 어디서 호출하든 일관된 성격과 능력을 갖춘 전문가가 나오게 만들 수 있다. OpenCode에서…

커스텀 에이전트 파일을 처음 만드는 사람 대부분은 파일을 만들고 나서야 더 적합한 선택지가 있었다는 사실을 알게 된다. command 하나면 충분했던 작업이 거대한 에이전트가 되어 있고, 에이전트 파일이 늘어날수록 어떤 도구를 언제 호출해야 하는지 모호해지기 때문이다. 결과적으로 시스템…