DevToKKi – 구조가 헷갈릴 때: sub-agent, skill, harness를 구분하게 된 과정

Ai: 왜 나는 프로젝트별 계층형 sub-agent를 떠올렸을까

Thu, 23 Apr 2026 00:00:00 +0900

참고 자료

이 글의 출발점은 sub-agent의 정의가 아니었다. 훨씬 먼저 떠오른 건 실무적인 질문이었다. 여러 저장소로 나뉜 시스템을 운영하면서, 프로젝트별 에이전트를 두고 그 아래에 기술 담당 agent를 붙이면 일의 흐름을 더 잘 정리할 수 있지 않을까 하는 궁금증이 먼저 생겼다.

처음에는 꽤 단순하게 생각했다. 수집 서비스, 동기화 또는 색인 서비스, 가공 서비스, 규칙 매핑 서비스, 조회 서비스 같은 프로젝트를 각각 하나의 sub-agent로 두고, 그 안에 애플리케이션 구현, 데이터 저장소, 메시지 처리, 운영 배포 같은 기술 담당 agent를 하위에 배치하면 되는 줄 알았다.

겉으로 보기에는 이 구조가 그럴듯하다. 저장소가 이미 분리되어 있고, 기술 스택도 반복되기 때문이다. 더구나 각 프로젝트 안에서 자주 마주치는 문제도 대체로 비슷해 보인다. 그래서 처음에는 “프로젝트 단위 리드 아래에 기술 담당 agent를 붙이는 구조”가 자연스럽다고 느껴졌다.

하지만 이 생각은 금방 한계에 부딪혔다. 프로젝트 축과 기술 축을 동시에 계층으로 만들기 시작하면, 누가 최종 책임자인지와 어떤 변경이 어디서 결정되어야 하는지가 흐려지기 때문이다.

예를 들어 이런 질문이 바로 생긴다.

기술 담당 agent는 상시 하위 조직이어야 하는가
아니면 프로젝트 리드가 필요할 때 호출하는 보조 역할이어야 하는가
데이터 계약 변경은 기술 판단인가, 프로젝트 소유권 판단인가

이 질문들이 중요했던 이유는, 구조를 많이 두는 것과 구조를 잘 나누는 것이 전혀 다르기 때문이다. 계층형 sub-agent를 떠올린 것 자체는 자연스러운 반응이지만, 그 구조가 실제 운영을 단순하게 만들지, 아니면 책임 경계를 더 흐리게 만들지는 별개의 문제였다.

여기까지 정리하고 나니 적어도 하나는 분명해졌다. 처음 떠올린 계층형 구조가 막혔던 이유는 에이전트 수가 부족해서가 아니라, 누가 실행자이고 누가 소유자인지가 흐려졌기 때문이다.

결국 초반에 필요했던 건 더 많은 역할 이름이 아니라, 역할을 나누는 기준이었다. 구조를 세분화하기 전에 소유권과 호출 시점을 먼저 정리해야 다음 질문으로 넘어갈 수 있었다.

결국 또 다른 질문이 떠올랐다.

sub-agent는 책임 단위인가, 실행 단위인가

이어서 읽기

Ai: sub-agent와 skill은 무엇이 달랐을까

Thu, 23 Apr 2026 00:00:00 +0900

참고 자료

앞 글에서는 왜 프로젝트별 계층형 sub-agent 구조를 먼저 떠올리게 됐는지, 그리고 그 구조가 어디에서 막히기 시작했는지를 정리했다. 핵심은 단순했다. 문제가 구조의 수가 아니라 실행자와 소유자를 어떻게 구분할 것인가에 있었다.

그 질문에 답하려고 보니 가장 먼저 정리해야 했던 건 sub-agent의 역할이었다. sub-agent는 메인 에이전트가 위임하는 하위 실행 단위다. 핵심은 전체 책임을 넘기는 것이 아니라 범위를 좁혀 맡기는 것이다.

이 구분이 중요했던 이유는, 처음 상상한 구조가 프로젝트 리드 = 하위 조직 관리자에 가까웠기 때문이다. 하지만 실무적으로 더 중요한 건 하위 조직도가 아니라 소유권이었다. 누가 최종 결정을 내리고, 누가 결과를 통합하며, 누가 테스트와 롤백 리스크를 책임지는지가 먼저 정리되어야 했다.

여기서 한 단계 더 나아가면 skill의 역할도 선명해진다. skill은 에이전트가 어떤 기준과 절차로 일할지를 정리한 운영 매뉴얼에 가깝다.

즉:

sub-agent는 실행자
skill은 실행 기준서

이 차이는 특히 리뷰와 설계 판단에서 크게 드러난다. 범용 리뷰어는 correctness나 missing tests는 잘 볼 수 있지만, 데이터 계약, 재처리 의미 보존, 외부 제공 인터페이스 호환성, 조회 비용 같은 우선순위를 무엇으로 둘지는 별도의 기준이 필요하다.

이 정리를 하고 나니 프로젝트 아래에 기술 담당 agent를 상시 트리처럼 배치하는 생각도 다시 보였다. 특정 역할 agent를 두는 것 자체가 핵심이 아니라, 그 agent가 어떤 기준으로 동작하고 어느 단계에서 호출되는지가 더 중요했던 것이다.

결국 좋은 운영은 sub-agent로 역할을 나누고 skill로 판단 기준을 통일하는 구조가 된다. 실행자만 있고 기준이 없으면 결과가 흔들리고, 기준만 있고 실행자가 없으면 실제 작업으로 연결되지 않는다.

이 구분이 생기고 나서야 역할을 더 늘릴지 줄일지 판단할 수 있게 됐다. 실행자와 기준서를 같은 층위로 두면 구조가 늘어날수록 오히려 설명이 어려워진다는 점도 함께 드러났다.

여기까지 오면 또 하나가 분명해진다. sub-agent와 skill을 구분하면 역할과 기준은 정리되지만, 그 구조가 실제로 잘 작동하는지는 아직 설명되지 않는다.

정리하고 나니 다른 문제가 바로 따라왔다.

누가 일하는가와 어떤 기준으로 일하는가는 구분할 수 있다
그렇다면 그 구분이 실제로 도움이 되는지는 무엇으로 확인할 것인가

이어서 읽기

Ai: 왜 harness engineering은 따로 봐야 했을까

Thu, 23 Apr 2026 00:00:00 +0900

참고 자료

앞 글에서는 sub-agent를 실행자, skill을 기준서로 구분해야 구조가 선명해진다는 점을 정리했다. 하지만 그렇게 역할과 기준을 나눴다고 해서, 그 구조가 실제로 도움이 되는지는 아직 알 수 없다.

바로 그 지점에서 harness가 등장한다. sub-agent를 실행자로 보고, skill을 기준서로 구분하고 나면 구조가 훨씬 선명해진다. 하지만 그걸로 끝나지는 않는다. 구조를 잘 나눈 것과, 그 구조가 실제로 잘 작동하는지는 또 다른 문제이기 때문이다.

여기서 필요해지는 개념이 harness engineering이다. harness engineering은 에이전트를 반복 가능하게 실행하고 검증하는 틀을 만드는 일이다.

쉽게 말하면 다음을 일관되게 정의하는 작업이다.

어떤 입력으로 실행할지
어떤 절차를 따를지
어떤 결과를 남길지
어떻게 성공과 실패를 판단할지

이 개념이 중요했던 이유는, 처음에는 “구조만 잘 나누면 되는 것 아닌가”라고 생각했기 때문이다. 하지만 실제로는 로그, 파일 소유권, 중복 작업 여부, 상위 에이전트의 검증 책임 같은 것들이 함께 관리되지 않으면, 계층형 구조가 도움이 되는지 아니면 복잡도만 늘어났는지 판단하기 어렵다.

이 지점에서 skill과 harness를 섞으면 안 된다는 것도 선명해졌다.

skill은 어떻게 일할지에 대한 기준
harness는 그 기준이 실제로 잘 작동하는지 비교하고 검증하는 구조

이 둘은 비슷해 보여도 목적이 다르다. 하나는 작업 방식이고, 다른 하나는 평가 구조다.

작게 시작할 때도 원리는 같다. 고정된 작업 몇 개와 최소 로그만 있어도 충분하다. 중요한 건 처음부터 거대한 플랫폼을 만드는 것이 아니라 반복 실행 + 결과 저장 + 간단한 점수화를 가능하게 만드는 것이다.

이렇게 보고 나면 하네스는 부가 기능이 아니라 운영 기준의 일부가 된다. 특히 여러 번 같은 구조를 시험해보려면, 비교 가능한 기록을 남기는 장치가 먼저 있어야 한다.

여기까지 정리하면 관점이 한 번 더 바뀐다. 질문은 더 이상 “어떤 에이전트를 둘까”가 아니다. 이제는 “이 구조를 실제 변경 흐름 위에 올려놓으면 어떻게 움직여야 하는가”가 더 중요해진다.

그다음부터는 질문이 조금 달라졌다.

구조를 나누는 것과 구조를 검증하는 것은 다른 문제다
그렇다면 실제 운영 단위는 조직도가 아니라 무엇을 기준으로 잡아야 하는가

이어서 읽기

Ai: 왜 프로젝트 조직도보다 릴리즈 체인이 더 중요했을까

Thu, 23 Apr 2026 00:00:00 +0900

참고 자료

앞 글에서는 sub-agent와 skill을 구분한 뒤에도, 그 구조가 실제로 도움이 되는지 보려면 harness가 따로 필요하다는 점을 정리했다. 그렇게 보고 나니 질문도 다시 바뀌었다. 이제 중요한 건 에이전트 구조를 어떻게 그릴지가 아니라, 실제 변경이 어떤 단위로 흘러가는지를 먼저 보는 일이었다.

여러 저장소가 하나의 데이터 파이프라인으로 연결돼 있다면, 에이전트 운영은 프로젝트 트리보다 릴리즈 체인 기준으로 보는 편이 낫다.

예를 들어 다음 같은 기능을 생각해보자.

새 데이터 유형 수집
적재 스키마 확장
가공 단계 이벤트 처리 반영
조회 인터페이스 노출

이 경우 실행 순서는 대체로 이렇게 흘러간다.

릴리즈 영향 범위 분해
데이터 계약 확정
수집과 적재 구현
가공과 이벤트 처리 구현
조회와 외부 제공 인터페이스 반영
테스트와 리뷰
최종 통합과 배포 순서 판단

이 흐름에서 중요한 건 다음 세 가지다.

프로젝트 = 책임 단위
기술 = 지원 단위
릴리즈 체인 = 실행 단위

즉 프로젝트 리드는 항상 소유자이고, 구현, 데이터 저장소, 메시지 처리, 운영 배포를 맡는 기술 담당 agent는 필요할 때만 붙는 보조 역할이다. 에이전트를 프로젝트별 고정 조직처럼 상시 배치하는 것보다, 변경 경로에 맞춰 필요한 리드와 agent를 조합하는 편이 더 현실적이다.

이제 보니 내가 만들고 싶었던 건 프로젝트별 하위 조직도가 아니라, 여러 저장소를 가로지르는 변경을 안전하게 흘려보내는 방식이었다.

결국 기준은 조직도가 아니라 흐름이었다. 어떤 변경이 먼저 생기고, 그 변경이 어떤 계약을 건드리며, 그다음 단계에 무엇을 요구하는지를 따라가다 보면 필요한 리드와 agent도 그때 정해졌다. 반대로 프로젝트별 계층을 먼저 그려두면 구조는 있어 보여도, 실제 릴리즈가 움직이는 순서와 책임 경계는 오히려 흐려졌다.

그래서 내게 남은 결론은 단순하다. 에이전트 구조는 먼저 설계하는 대상이라기보다, 변경 흐름 위에 얹는 운영 장치에 가깝다. 프로젝트별 하위 조직도를 먼저 세우기보다 릴리즈가 실제로 지나가는 경로를 먼저 붙잡아야 한다. 그 뒤에야 누가 소유하고, 어떤 agent가 필요하며, 어디에서 검증해야 하는지가 자연스럽게 정리된다.