AI 에이전트 워크플로우를 '똑똑하게' 만들려는 시도를 멈췄을 때 더 유용해진 사례가 있나요?

나한테 유용했던 건 원래 자율성이 너무 높았던 연구 워크플로우였음. 이걸 4단계의 결정론적 과정으로 좁혔지: 제한된 세트 가져오기, 모든 항목 분류하기, 추가만 가능한 원장 작성하기, 그리고 최대 5개의 답변 초안 작성하기. 에이전트는 게시를 할 수 없도록 명시적으로 설정함.

그렇게 하니까 모델이 가치를 더하는 부분인 '판단과 글쓰기'는 유지하면서, '똑똑한' 실패 유형들을 완전히 제거할 수 있었음.

핵심은 게시하는 건 추론 작업이 아니라 권한의 경계라는 걸 결정하는 거였음. 에이전트는 준비를 할 수 있지만...

고객 지원 분류 작업은 단순하게 유지하는 편임. AI가 메시지를 읽고 문제와 핵심 세부 사항을 뽑아내게 한 다음, 명확한 규칙을 사용해서 라우팅하는 거지.

'이중 결제됐으니 환불해줘' 같은 건 에이전트가 독자적으로 환불을 결정하게 할 게 아니라, 맥락을 포함한 결제 티켓이 필요함.

개선이라고 부르기 전에, 인간의 검토를 포함한 전체 처리 시간과 잘못 분류된 티켓 수를 비교해봐야 함. 단계를 제거하는 건 그 일을 다른 사람에게 떠넘기는 게 아니라, 업무 자체를 줄여줄 때만 도움이 됨.

에이전트가 모든 걸 처리하게 두는 대신, FAQ나 주문 상태 확인 정도로 제한하면 훨씬 더 안정적으로 만들 수 있음. 복잡한 문제는 바로 사람한테 넘기면 되고.

우리한테 가장 도움 됐던 건 지루할 정도로 단순한 '타임 게이트(time gate)'였음. 마지막 작업이 10분도 안 됐으면 게시 단계를 거부하게 설정함. 우리 로그가 아니라 실제 계정 피드에서 읽어오는 방식임. 프로세스 두 개가 동시에 돌면서 둘 다 자기가 유일한 프로세스라고 착각할 수 있는데, 벽시계 시간 기준으로 게이트를 걸어두면 이걸 잡아낼 수 있음. 중복 작업인지 진짜 두 번째 작업인지는 구분 못 하지만, 시간 하나는 확실하게 체크하니까.

이건 캔 따개만 필요한 사람한테 맥가이버 칼을 쥐여주는 거랑 같아. 칼날을 계속 추가하다 보니(풍자 감지, 뉘앙스 파악, 자율성 등) 정작 그 사람은 캔 따개가 어디 있는지 찾지도 못하게 된 거지.

확실한 동작 하나로 고정하고 마지막 단계에 사람을 배치하니까, '똑똑함'을 측정하는 게 아니라 '완료'를 측정하게 되더라.

'더 똑똑하게 만들자'며 리팩토링을 너무 많이 해본 입장에서 솔직히 말하자면, 에이전트를 해고하고 사람의 승인 단계가 포함된 단순 스크립트만 남겼을 때 워크플로우가 훨씬 나아졌어.

검색, 요약, 점수 매기기 등 온갖 기능을 다 넣은 리서치 요약 에이전트를 썼었는데, 꽤 똑똑해 보였지. 그러다 동료가 에이전트가 '요약'했다는 논문 하나를 전달해달라고 해서 확인해보니, 그 논문은 존재하지도 않았어. 에이전트가 아주 그럴듯한 인용구를 환각(hallucination)으로 만들어낸 거였고, 난 2주 동안이나 링크를 클릭해보지도 않은 채 결과물만 훑어보고 있었던 거지.

툴 개수를 줄인 게 어떤 프롬프트 수정보다 효과가 컸어. 모델이 기능이 조금이라도 겹치는 여러 툴 중에서 선택해야 하는 상황이 되면, 잘못된 툴을 고르는 빈도가 훨씬 높아져. 해결책은 더 좋은 프롬프트가 아니라, 툴 개수를 줄이고 각 툴의 설명을 더 엄격하고 겹치지 않게 다듬으며 입력 스키마를 작게 만드는 거야.

Codex가 스킬 기능을 지원하기 시작했을 때, 계획 수립 전용 스킬을 직접 만들기 시작했고 그 이후로 계속 쓰고 있어.

Plan Mode는 에이전트가 스스로 조사할 수 있는 것까지 자꾸 나한테 물어봐서 너무 번거롭더라고. 나는 AI가 엔지니어처럼 문제를 생각하길 원했어. 실제 필요한 게 뭔지 명확히 하고, 가정을 검증하고, 범위를 정의하고, 관련 프로젝트 맥락을 조사한 뒤, 설계를 개발하고 작업을 세분화하는 식으로 필요한 모든 단계를 거치는 거지. 각 단계가 쌓이면서…

난 잘못된 행동으로 인한 비용을 기준으로 변화를 측정해. 그게 워크플로우가 더 안전해졌는지를 보여주는 지표니까.

에이전트가 스스로 숙제를 채점하게 두지 마라.