왜 나는 프로젝트별 계층형 sub-agent를 떠올렸을까
Categories:
참고 자료
이 글의 출발점은 sub-agent의 정의가 아니었다. 훨씬 먼저 떠오른 건 실무적인 질문이었다. 여러 저장소로 나뉜 시스템을 운영하면서, 프로젝트별 에이전트를 두고 그 아래에 기술 담당 agent를 붙이면 일의 흐름을 더 잘 정리할 수 있지 않을까 하는 궁금증이 먼저 생겼다.
처음에는 꽤 단순하게 생각했다. 수집 서비스, 동기화 또는 색인 서비스, 가공 서비스, 규칙 매핑 서비스, 조회 서비스 같은 프로젝트를 각각 하나의 sub-agent로 두고, 그 안에 애플리케이션 구현, 데이터 저장소, 메시지 처리, 운영 배포 같은 기술 담당 agent를 하위에 배치하면 되는 줄 알았다.
겉으로 보기에는 이 구조가 그럴듯하다. 저장소가 이미 분리되어 있고, 기술 스택도 반복되기 때문이다. 더구나 각 프로젝트 안에서 자주 마주치는 문제도 대체로 비슷해 보인다. 그래서 처음에는 “프로젝트 단위 리드 아래에 기술 담당 agent를 붙이는 구조”가 자연스럽다고 느껴졌다.
하지만 이 생각은 금방 한계에 부딪혔다. 프로젝트 축과 기술 축을 동시에 계층으로 만들기 시작하면, 누가 최종 책임자인지와 어떤 변경이 어디서 결정되어야 하는지가 흐려지기 때문이다.
예를 들어 이런 질문이 바로 생긴다.
- 기술 담당 agent는 상시 하위 조직이어야 하는가
- 아니면 프로젝트 리드가 필요할 때 호출하는 보조 역할이어야 하는가
- 데이터 계약 변경은 기술 판단인가, 프로젝트 소유권 판단인가
이 질문들이 중요했던 이유는, 구조를 많이 두는 것과 구조를 잘 나누는 것이 전혀 다르기 때문이다. 계층형 sub-agent를 떠올린 것 자체는 자연스러운 반응이지만, 그 구조가 실제 운영을 단순하게 만들지, 아니면 책임 경계를 더 흐리게 만들지는 별개의 문제였다.
여기까지 정리하고 나니 적어도 하나는 분명해졌다. 처음 떠올린 계층형 구조가 막혔던 이유는 에이전트 수가 부족해서가 아니라, 누가 실행자이고 누가 소유자인지가 흐려졌기 때문이다.
결국 초반에 필요했던 건 더 많은 역할 이름이 아니라, 역할을 나누는 기준이었다. 구조를 세분화하기 전에 소유권과 호출 시점을 먼저 정리해야 다음 질문으로 넘어갈 수 있었다.
결국 또 다른 질문이 떠올랐다.
sub-agent는 책임 단위인가, 실행 단위인가