반복 작업의 발판으로서의 에이전트

보안 취약점 패치처럼 반복되지만 예외가 많은 작업은, 처음에는 에이전트로 프로토타입을 만들고 나중에 코드 중심 워크플로로 옮겨가는 편이 효과적이다.

한 사례로, Dependabot 웹훅을 내부 agent framework에 넣고, 우선순위가 높은 이슈만 걸러 Slack으로 보내려 했다. 이후 GPT 4.1에서 GPT 5.4 high reasoning으로 업그레이드하면서, 에이전트가 Github MCP를 사용해 Codeowners 파일, 최근 커밋 같은 단서를 바탕으로 적절한 담당자를 찾는 일은 꽤 잘하게 됐다.

하지만 critical만 보내야 하는 제약은 끝내 안정적으로 지키지 못했다. 반복적으로 CRITICAL: you must...를 넣어도 high나 가끔 medium까지 섞였고, 사람에게 알림을 보내는 수준의 근사치는 충분하지 않았다.

해결책은 에이전트가 아니라 흐름 제어를 코드가 맡는 구조였다.

• 웹훅 수신 후 스크립트가 severity와 액션을 추출
• low priority 또는 비실행 항목은 먼저 제거
• 코드가 리포지토리별 이슈 묶음을 패키징
• 각 묶음을 에이전트에 넘겨 담당 팀이나 사람을 식별
• 두 번째 에이전트가 Slack 메시지 형식으로 정리

이렇게 바꾸자 동작은 100% 안정적이 되었고, 내부 ownership skill과 Github MCP는 여전히 유지할 수 있었다. 덕분에 더 공격적으로 롤아웃할 수 있게 됐다.

같은 패턴은 이후 주간 후속 알림에도 적용됐고, 다음 단계는 취약점 수정 자체까지 자동화하는 것이다. 목표는 사람이 개입하는 지점을 점점 줄여, 최종적으로는 변경 검토만 인간이 하고 자동 배포까지 이어지는 구조로 가는 것이다.

핵심 패턴은 세 가지다.

• 먼저 에이전트로 프로토타입을 만들어 작업의 난점을 파악한다
• 그다음 제어 로직을 코드로 옮겨 결정론적 부분을 늘린다
• 마지막에는 모호한 판단이 필요한 지점, 예를 들면 코드 오너 식별처럼 에이전트가 강한 부분만 남긴다

이 방식은 더 빠르고, 더 싸고, 더 유지보수하기 쉽다. 최근 실행 로그, 프롬프트, 짧은 지침만 있으면 몇 분 안에 Codex나 Claude로 대체 구현을 만들 수 있을 만큼 전환 비용도 낮다.