AI 에이전트를 하나로 만들지 않고 작업 유형별 체인으로 나눈 이유
안녕하세요.
최근 AI 에이전트를 개발 워크플로우에 붙여보면서 느낀 점을 정리해봤습니다.
처음에는 “코드를 더 빨리 작성하게 하는 것”에 관심이 있었는데,
막상 써보니 더 큰 문제는 따로 있었습니다.
- 이 버그, 예전에 비슷한 거 봤던 것 같은데?
- 그때 어떤 로그부터 확인했더라?
- 비슷한 성능 문제를 지난번엔 어떻게 해결했지?
이런 개발 경험이 매번 개인의 기억에 의존하고,
다음 작업에 잘 이어지지 않는다는 점이었습니다.
그래서 AI 에이전트를 하나의 만능 도구로 만들기보다,
FIX / PERF / FEAT / REFACTOR처럼 작업 유형별로 체인을 나눠봤습니다.
대략적인 흐름은 이렇습니다.
Jira 이슈 확인
→ 작업 유형 분류
→ 과거 work_history 조회
→ 반복 패턴 확인
→ 작업 유형에 맞는 에이전트 실행
→ PR 생성
→ 작업 기록 갱신
핵심은 AI가 코드를 대신 짜는 것보다,
과거 작업 경험을 다음 작업의 컨텍스트로 재사용하게 만드는 것이었습니다.
물론 한계도 있었습니다.
명세를 벗어나거나, 토큰 사용량이 커지거나,
에이전트가 왜 그런 판단을 했는지 추적하기 어려운 경우도 있었습니다.
그래도 “AI 에이전트를 팀의 작업 기억처럼 쓸 수 있을까?”라는 관점에서는 꽤 의미 있는 실험이었습니다.
글로 정리해봤습니다.
비슷하게 AI 에이전트를 개발 워크플로우에 붙여보신 분들이 있다면,
어떤 방식으로 컨텍스트나 작업 기록을 관리하고 계신지도 궁금합니다.
