왜 프로젝트 조직도보다 릴리즈 체인이 더 중요했을까
Categories:
참고 자료
앞 글에서는 sub-agent와 skill을 구분한 뒤에도, 그 구조가 실제로 도움이 되는지 보려면 harness가 따로 필요하다는 점을 정리했다. 그렇게 보고 나니 질문도 다시 바뀌었다. 이제 중요한 건 에이전트 구조를 어떻게 그릴지가 아니라, 실제 변경이 어떤 단위로 흘러가는지를 먼저 보는 일이었다.
여러 저장소가 하나의 데이터 파이프라인으로 연결돼 있다면, 에이전트 운영은 프로젝트 트리보다 릴리즈 체인 기준으로 보는 편이 낫다.
예를 들어 다음 같은 기능을 생각해보자.
- 새 데이터 유형 수집
- 적재 스키마 확장
- 가공 단계 이벤트 처리 반영
- 조회 인터페이스 노출
이 경우 실행 순서는 대체로 이렇게 흘러간다.
- 릴리즈 영향 범위 분해
- 데이터 계약 확정
- 수집과 적재 구현
- 가공과 이벤트 처리 구현
- 조회와 외부 제공 인터페이스 반영
- 테스트와 리뷰
- 최종 통합과 배포 순서 판단
이 흐름에서 중요한 건 다음 세 가지다.
프로젝트 = 책임 단위기술 = 지원 단위릴리즈 체인 = 실행 단위
즉 프로젝트 리드는 항상 소유자이고, 구현, 데이터 저장소, 메시지 처리, 운영 배포를 맡는 기술 담당 agent는 필요할 때만 붙는 보조 역할이다. 에이전트를 프로젝트별 고정 조직처럼 상시 배치하는 것보다, 변경 경로에 맞춰 필요한 리드와 agent를 조합하는 편이 더 현실적이다.
이제 보니 내가 만들고 싶었던 건 프로젝트별 하위 조직도가 아니라, 여러 저장소를 가로지르는 변경을 안전하게 흘려보내는 방식이었다.
결국 기준은 조직도가 아니라 흐름이었다. 어떤 변경이 먼저 생기고, 그 변경이 어떤 계약을 건드리며, 그다음 단계에 무엇을 요구하는지를 따라가다 보면 필요한 리드와 agent도 그때 정해졌다. 반대로 프로젝트별 계층을 먼저 그려두면 구조는 있어 보여도, 실제 릴리즈가 움직이는 순서와 책임 경계는 오히려 흐려졌다.
그래서 내게 남은 결론은 단순하다. 에이전트 구조는 먼저 설계하는 대상이라기보다, 변경 흐름 위에 얹는 운영 장치에 가깝다. 프로젝트별 하위 조직도를 먼저 세우기보다 릴리즈가 실제로 지나가는 경로를 먼저 붙잡아야 한다. 그 뒤에야 누가 소유하고, 어떤 agent가 필요하며, 어디에서 검증해야 하는지가 자연스럽게 정리된다.