28개 케이스에서 planning이 멈춘다
나는 QA Agent planning 파이프라인을 갈아없은 날이었다.
케이스가 많아지면 planning이 멈추는 문제를 3단계로 쪼개서 해결했다.
그리고 스킬이 특정 도메인에 종속되지 않게 만들어서, 환경을 옮겨도 지식이 따라가게 만들었다.
문제는 명확했다.
케이스 28개를 한 번에 planning하면 멈췄다.
planning은 8단계 파이프라인의 세 번째 단계다.
이 단계가 멈추면 뒤에 아무것도 못 돌린다.
원인은 단일 LLM 호출이 감당하지 못하는 거였다.
케이스 28개를 한 번에 받아서 전체 계획을 세우려니까, LLM이 압도되거나 타임아웃이 났다.
한 번의 호출로 전부 하려니까 한계에 부딪힌 거다.
3단계로 쪼개기
해결은 planning을 세 단계로 나누는 거다.
1단계: 뼈대
첫 번째 단계에서는 뼈대만 만든다.
전체 구조를 잡는 거다.
고수준 계획을 세우는 싼 호출 하나로 끝난다.
빠르고 가볍다.
2단계: 그룹별 병렬 상세
두 번째 단계에서는 그룹별로 상세 계획을 세운다.
이때 하위 에이전트들이 병렬로 돈다.
각 그룹마다 작은 호출로 처리한다.
한 번에 28개를 감당하는 게 아니라, 그룹 단위로 쪼개서 각자 작은 계획을 세우는 거다.
병렬로 돌리니까 전체 시간도 줄고 각 호출은 작으니까
안정적이다.
멈출 일이 없다.
3단계: 조립
세 번째 단계에서는 그룹별 계획을 하나로 합친다.
최종 실행 계획 스키마로 조립하는 거다.
이렇게 세 단계로 나누니까 28개 케이스에서 멈추는 문제가 사라졌다.
분할 정복이다.
한 번에 전부 처리하려고 하지 말고 쪼개서 각자 처리하고 합치는 거다.
옛날 코드는 완전히 제거
여기서 중요한 결정을 하나 더 했다.
단일 모드 코드를 완전히 지웠다.
폴백으로 옛날 단일 planning을 남겨두지 않았다.
폴백을 남겨두면 나중에 누군가 그 경로로 빠져서 같은 문제를 다시 만난다.
그러니까 아예 없애버리는 게 낫다.
멈추는 경로 자체를 없앤 거다.
스킬 도메인 독립화
planning 외에 스킬 시스템도 손봤다.
이게 두 번째로 큰 변화였다.
문제는 스킬이 특정 도메인에 묶여 있었다는 거다.
예를 들어 관리자 로그인 스킬이 “admin.example.com-login”처럼 특정 URL 기반으로 이름이 붙어 있었다.
그러니까 알파 환경에서 학습한 스킬을 운영 환경에서 쓸 수가 없었다.
URL이 다르니까. 그래서 스킬을 도메인 독립적으로 만들었다.
하드코딩된 도메인을 플레이스홀더로 바꿨다.
URL 대신 행동 기반으로 이름을 바꿨다.
“admin.example.com-login”이 아니라 “admin-login”으로. 그러니까
이제 스킬이 “어떻게 관리자로 로그인하는가”라는 행동 지식이 됐다.
특정 주소가 아니라. 환경을 옮겨도 스킬이 따라간다.
알파에서 학습한 걸 운영에서 쓸 수 있다.
스킬 24개를 21개로 합치면서 정리했다.
중복된 것도 있었고 도메인 종속 버전이 여러 개 있었다.
행동 기반으로 통합하니까 자연스럽게 줄었다.
Planner 프롬프트 인라인화
세 번째는 Planner 프롬프트를 파일 경로 참조에서 인라인으로 바꾼 거다.
그 전까지는 프롬프트에서 “이 파일을 읽어라”라고 파일 경로를 참조했다.
근데 LLM 에이전트는 파일을 읽으라는 지시를 안 지킬 때가 있다.
건너뛰거나, 잘못 읽거나, 없는 내용을 지어내기도 한다.
그래서 파일 내용을 프롬프트 안에 직접 끼워 넣었다.
“이 파일을 읽어라”가 아니라, 파일 내용 자체를 프롬프트에 넣는 거다.
그러니까 Planner가 반드시 그 내용을 보게 된다.
읽으려다
빠뜨리는 일이 없다.
토큰 비용 가시화
마지막으로 토큰 비용 표시를 개선했다.
탐색 서브에이전트가 쓰는 토큰이 비용 보고서에 빠져 있었다.
탐색 에이전트는 planning 단계에서 브라우저를 탐색한다.
실제 토큰을 쓴다.
근데 이게 비용에서 빠져 있으니까 planning 비용이 실제보다 낮게 나왔다.
최적화하려면 정확하게 봐야 하는데, 안 보이니까 할 수가 없었다.
탐색 에이전트 토큰을 비용 보고서에 포함시키고 표시도 맨 위로 올렸다.
이제 planning이 실제로 얼마나 드는지 보인다.
마무리
이날 핵심은 케이스가 많아져도 planning이 멈추지 않게 만든 거다.
3단계로 쪼개서 분할 정복으로 풀었다.
한 번에 전부 하려다
압도되는 문제를, 작게 쪼개서 각자 처리하고 합치는 방식으로 해결했다.
그리고 스킬을 도메인 독립적으로 만든 것도 중요했다.
학습한 지식이 환경에 묶이지 않으니까, 알파에서 학습한 걸 운영에서 바로 쓸 수 있다.
스킬 라이브러리가 진짜 재사용 가능한 자산이 됐다.
이 두 가지 결정 모두 “이식성”에 대한 것이었다.
planning은 케이스 수에 이식 가능하게, 스킬은 환경에 이식 가능하게. 규모가 커져도, 환경이 바뀌어도 깨지지 않는 구조를 만든 거다.