당신의 에이전트가 요청보다 과도하게 기능을 추가하는 이유 (그리고 이를 멈추게 하는 3가지 프롬프트)
요약
AI 에이전트는 사용자의 단순한 요구사항에도 불구하고 과도하게 복잡하고 많은 기능을 추가하는 경향이 있습니다. 이는 마치 컨설턴트처럼 옵션의 완전성을 높게 평가하도록 훈련되었기 때문입니다. 핵심은 명확하고 구체적인 프롬프트를 통해 에이전트가 불필요한 기능 확장을 멈추도록 제어하는 것입니다.
핵심 포인트
- 에이전트는 단순 요청에도 과잉 설계 경향을 보인다.
- 명확하게 범위를 제한하는 것이 중요하다.
- 단순히 '간결하게'와 같은 지시어가 효과적이다.
요구사항은 여덟 단어에 불과했다
월요일 아침. 저는 발신 대기 목록을 열었습니다: 보류 중인 초안 647개, 전송된 메일 672개. 아무도 '전송' 버튼을 누르지 않습니다. 첫 접촉 메일은 파이프라인으로 준비되어 잠자고 있는데, 마지막 단계가 인간의 개입을 가정하기 때문입니다. 저는 이 인간에게 시간이 있을 것이라고 믿는 것을 그만두었습니다. 그래서 '자동 전송 기능을 구현하라'고 결정했습니다.
답변이 몇 초 만에 도착했습니다. 자동화 수준 3단계. 채널 4개. 위험 단계 3가지. 모든 것이 완벽했고, 절반나절 아키텍처 워크숍의 주제가 될 수 있을 것 같았습니다. 저는 워크숍을 요청한 적이 없습니다. 폴린이 뒤로 와서 한번 살펴보고 아무 말도 하지 않았습니다.
시간차를 둔 세 번의 수정 지시
첫 번째 수정 지시: 간결하게, '너무 이상해, 단순화하자.' 에이전트는 두 가지 축을 포기하고 네 개의 잔여 레이어를 유지하며, 3주에 걸친 점진적 워밍업(warm-up), 재사용 방지용 결정론적 해시(hash déterministe anti-rejeu)를 도입하고, 설정 테이블은 데이터베이스에 두고, '1단계는 수동으로 진행한 후, 측정 기간 2주 후에 검증하는 자동화된 2단계'를 추가했습니다. 목표는 여전히 동일합니다. 인간의 클릭 없이 메일이 발송되는 것입니다. 하지만 과정은 그만큼 길어졌습니다.
두 번째 수정 지시: 더 단호하게, '단순히, 가드레일(garde-fous) 3개와 일격 정지 스위치(kill-switch)만 있으면 돼, 하루 만에 끝내자.' 에이전트는 재아키텍처를 하고, 목표 기한인 '하루'를 수용하며, 세 개의 가드레일을 유지했습니다. 하지만 그 과정에서 자신이 '업계 표준'이라고 부르는 프로테스(prothèses) 3가지를 추가했습니다: 실시간 대시보드, 지수 백오프 재시도(retry exponentiel), 새 테이블에 구조화된 감사 로그(audit log structuré). 이 각각은 개별적으로 정당화될 수 있었지만, 그 누구도 요구한 적이 없었습니다.
세 번째 수정 지시: 더욱 짧게: '왜 이걸 추가하는지 모르겠어.' 이전에는 결코 들어본 적 없는, 거의 민망해 보이는 오프닝 문장이었습니다. '맞아요, 제가 불필요하게 기능을 과잉 설계하고 있었네요.' 그리고 원래 도착했어야 할 버전이었습니다. 초안 저장을 처리하고, 세 가지 조건을 확인한 후, 전송 엔진을 호출하는 기능이었습니다.
// lib/email-outbox.ts — generateFirstContactDraft (commit 3756e63)
if (!EMAIL_REGEX.test(input.email)) {
return { success: false, error: 'email_invalide' }
...
대화의 비용
첫 번째 차례에 저는 함수를 원했지만, 에이전트는 플랫폼을 제안했습니다. 두 번째 차례에는 하루 분량의 코드를 원했지만, 그것은 분기(quarter) 배포 계획을 제시했습니다. 세 번째 차례에는 15줄만 원했지만, 관측 가능성(observability) 메커니즘 세 가지를 제안했습니다. 기능 자체는 목표했던 '하루'를 지켰지만, 그 하루는 불균형한 두 부분으로 나뉘었습니다. 한 시간 반의 재조정과 여섯 시간 분량의 깔끔한 코드가 필요했죠.
에이전트는 복잡하게 만들고 싶지 않았습니다. 그리고 저는 이 말을 비꼬지 않고 쓰고 있습니다. 에이전트에게는 옵션의 완전성을 높게 평가하는 훈련 과정(training)이 있습니다. 사람이 컨설턴트에게 '내 발송을 자동화해 줘'라고 요청할 때, 유능한 컨설턴트는 15줄짜리 함수로 답하지 않고 의사결정 매트릭스(decision grid)로 답합니다. 에이전트는 수백만 토큰에 걸쳐 이 자세를 배웠고, 아키텍처 질문과 비슷하게 보이는 모든 요청에 완벽하게 적용하고 있습니다.
나의 기준
단순한 요청에 세 번의 재조정은 하나의 신호입니다. 초기 요청 자체가 너무 모호했거나, 아니면 우리가 '함수(function)' 모드였는데 에이전트가 '플랫폼(platform)' 모드로 전환되었기 때문일 수 있습니다. 세 번을 넘어서면, 그 비용은 더 이상 하루 안에 감당할 수 없습니다.
해결책 후보는 한 문장으로 요약되며, 프롬프트 상단에 삽입할 수 있습니다: '최소 버전(minimal version)을 15줄로 제안하세요. 매트릭스는 안 됩니다. 단계 구분도 안 됩니다. 확장 기능은 그 아래에 배치하세요.' 이 기준은 첫 주를 지켰습니다. 다음 에피소드에서 한 달 동안 유지될지 말씀드리겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기