에이전트를 팀 워크플로우에 넣었다. 그런데 실제로 팀 생산성이 올라갔는가? 많은 팀이 이 질문에 명확하게 대답하지 못한다. 에이전트를 '실행'하는 것과 에이전트를 '잘 운영'하는 것은 전혀 다른 문제이기 때문이다. 최근 두 가지 사례가 이 차이를 구체적으로 드러냈다.
피드백이 구조화되지 않으면 에이전트는 멈춘다
dev.to에 올라온 Pincushion 사례는 디자인 피드백에서 머지된 PR까지 이어지는 에이전트 워크플로우를 다룬다. 핵심은 단순하다. 디자이너가 "모바일에서 카드가 답답하게 느껴진다"고 Slack에 남기면, 에이전트는 아무것도 할 수 없다. 반면 라이브 앱 위에 핀을 꽂고 DOM 셀렉터, 스크린샷, 뷰포트, 페이지 URL, 스레드가 함께 패키징되면, Cursor나 Claude Code 같은 에이전트가 소스를 grep하고 브랜치에서 수정해 PR을 올리는 루프가 닫힌다.
이게 흥미로운 이유는 기술적 난이도 때문이 아니다. MCP는 여기서 그냥 전송 레이어다. 진짜 문제는 피드백의 형태였다. 사람 간의 협업은 약간의 모호함을 인간이 추론으로 채워왔다. 느리지만 작동한다. 에이전트 루프는 그 추론을 못 한다. 어느 페이지, 어느 엘리먼트, 어느 뷰포트인지 명확하지 않으면 에이전트는 시작도 못 하거나, 더 나쁘게는 엉뚱한 곳을 수정한다. 피드백이 구조화된 컨텍스트로 캡처되는 시점이 곧 에이전트 워크플로우의 시작점이다. 이 레이어를 설계하지 않으면 에이전트 도입은 반쪽짜리다.
규칙이 많다고 에이전트가 잘 작동하지 않는다
두 번째 사례는 에이전트 거버넌스 규칙을 15개에서 9개로 줄인 경험이다. 같은 dev.to 글에서 저자는 처음에 조회수(hit rate)가 낮은 규칙을 자동으로 퇴역시키려 했다. 논리적으로 보인다. 안 쓰이는 규칙은 컨텍스트 예산만 잡아먹는 노이즈니까. 그런데 스크립트 하나가 계획을 멈췄다. 실제로 '발동되지 않은' 규칙이 아니라 '탐지기 자체가 고장난' 규칙이 29개였다. 규칙이 죽은 게 아니라 눈을 감고 있었던 거다.
이 사례는 에이전트 운영의 세 가지 함정을 드러낸다. 첫째, 탐지기 건강 상태를 확인하지 않으면 hit rate는 신뢰할 수 없는 신호다. 둘째, 되돌릴 수 없는 작업을 지키는 규칙—프로덕션 데이터 삭제 금지, 실제 이메일 발송 금지—은 발동 빈도와 무관하게 퇴역시켜선 안 된다. 오류의 비용이 비대칭이기 때문이다. 셋째, 규칙의 트리거가 엔티티 기반이면 비즈니스 제약 조건이 바뀌어도 규칙은 그대로 남아 오탐이나 미탐을 낸다. 규칙을 줄이는 것이 목표가 아니라, 신뢰할 수 있는 규칙만 남기는 것이 목표다.
두 사례가 함께 가리키는 것
표면적으로 두 사례는 달라 보인다. 하나는 UI 피드백 자동화, 다른 하나는 거버넌스 규칙 최적화다. 그런데 둘 다 같은 문제를 다루고 있다. 에이전트에게 들어오는 입력의 품질과 에이전트를 통제하는 규칙의 신뢰도. 이 두 축이 무너지면 에이전트를 실행하는 것 자체가 의미 없어진다.
팀 리빌딩 관점에서 이건 꽤 중요한 순서의 문제다. 에이전트 도입 초기에 많은 팀이 '어떤 작업을 에이전트에게 맡길까'를 먼저 고민한다. 틀린 질문은 아니지만 충분하지 않다. 더 선행해야 할 질문은 '에이전트가 실제로 작동할 수 있는 입력 구조가 설계되어 있는가'와 '에이전트를 통제하는 규칙이 지금도 유효한가'다. 이 두 질문에 답을 못 하는 상태에서 에이전트를 더 많이 돌리면, 더 빠르게 잘못된 방향으로 달려간다.
운영 품질을 설계한다는 것의 의미
실용적으로 정리하면 이렇다. 에이전트 워크플로우를 설계할 때 세 가지를 동시에 점검해야 한다.
첫째, 입력 구조화 레이어. 에이전트가 받는 피드백, 지시, 컨텍스트가 에이전트가 실행 가능한 형태인가. Pincushion 사례처럼 사람이 남기는 코멘트가 구조화된 패킷으로 변환되는 지점을 명확히 설계해야 한다. 이 레이어 없이 에이전트에게 자연어 Slack 메시지를 던지는 건 사람한테 "알아서 해"라고 말하는 것보다 나쁘다.
둘째, 거버넌스 규칙의 주기적 감사. 규칙이 살아 있는지, 탐지기가 제대로 작동하는지, 보호하는 작업이 여전히 고위험인지. 이걸 체계적으로 점검하지 않으면 규칙 시스템은 조용히 썩는다. 그리고 가장 중요한 순간에 눈 감은 탐지기가 문제를 통과시킨다.
셋째, 인간 검토 게이트의 위치. 모든 피드백이 코드가 되어서는 안 되고, 모든 에이전트 결정이 자동으로 실행되어서는 안 된다. Pincushion 사례에서 팀이 승인한 피드백만 에이전트가 가져가는 구조는 단순해 보이지만 핵심이다. 에이전트가 건드려야 할 것과 사람이 계속 논의해야 할 것을 구분하는 게이트가 없으면 자동화는 통제 불능으로 간다.
에이전트 운영은 한 번 설정하고 끝나는 게 아니다. 입력 품질은 팀의 피드백 문화가 바뀌면 같이 바뀌고, 거버넌스 규칙은 비즈니스 맥락이 바뀌면 같이 낡는다. AI-First 팀이 진짜로 해야 할 일은 에이전트를 더 많이 실행하는 것이 아니라, 에이전트가 잘 작동할 수 있는 환경을 지속적으로 관리하는 것이다. 그게 운영 품질이고, 그게 실제로 팀 생산성에 임팩트를 주는 지점이다.