15장. 에이전트는 언제 필요하고 언제 과한가

에이전트라는 말이 커질수록 판단은 더 흐려진다

LLM 서비스를 만들다 보면 어느 순간 이런 유혹이 찾아옵니다. 요약도 했고, 분류도 했고, 검색도 붙였고, 외부 API도 연결했다면 이제 슬슬 "에이전트"를 만들어야 할 것 같다는 유혹입니다. 이름부터 멋집니다. 뭔가 스스로 생각하고, 알아서 도구를 고르고, 문제를 끝까지 해결해 줄 것 같습니다.

하지만 실무에서는 이 지점이 아주 위험합니다. 에이전트는 종종 가장 진보한 선택처럼 보이지만, 잘못 고르면 가장 비싸고 가장 느리고 가장 디버깅하기 어려운 구조가 됩니다. 쉽게 말해, 만능 칼처럼 보이지만 손잡이도 무겁고 날도 예민해서 아무 일에나 꺼내 들면 손부터 베기 쉽습니다.

이번 장의 핵심은 단순합니다. 에이전트는 만능 답이 아니다. 어떤 문제에서는 정말 강력하지만, 많은 문제에서는 정해진 워크플로보다 못합니다. 중요한 것은 "에이전트를 쓸 수 있는가"가 아니라 "에이전트를 써야 하는가"입니다.

먼저 구분하자: 기능, 워크플로, 에이전트는 다르다

실무에서 가장 흔한 오해는 툴 호출이 들어가면 곧바로 에이전트라고 생각하는 것입니다. 하지만 이 셋은 분명히 다릅니다.

첫째는 단일 기능입니다. 사용자가 문장을 넣으면 모델이 요약하거나 재작성하거나 분류해서 돌려주는 구조입니다. 입력과 출력이 비교적 분명하고, 중간 단계도 거의 없습니다.

둘째는 정해진 워크플로입니다. 예를 들어 사용자 요청을 받으면 먼저 주문 정보를 조회하고, 그다음 정책을 확인하고, 마지막에 답변을 생성하는 식입니다. 여기서는 단계가 여러 개일 수 있지만, 순서와 규칙이 개발자 코드에 고정되어 있습니다.

셋째가 에이전트입니다. 에이전트는 보통 모델이 현재 상태를 보고 다음 행동을 스스로 고르는 반복 구조를 가리킵니다. 어떤 도구를 쓸지, 몇 번 더 조회할지, 지금 정보가 충분한지, 추가 질문을 할지 같은 결정을 모델이 루프 안에서 계속 내립니다.

같은 툴 호출이라도 성격은 전혀 다를 수 있습니다. get_order_status를 한 번 호출하는 챗봇은 에이전트가 아닐 수 있습니다. 반면 사용자의 모호한 요청을 받고 여러 시스템을 오가며 필요한 정보를 찾고, 중간 결과를 보고 계획을 바꾸고, 마지막에 작업 완료까지 이어지는 구조는 에이전트에 가깝습니다.

이 차이를 구분하지 못하면 설계가 자꾸 과장됩니다. 사실은 단순한 워크플로면 충분한데, "AI가 알아서 하게 하자"는 마음으로 루프를 열어 버리기 쉽기 때문입니다.

에이전트의 본질은 똑똑함이 아니라 불확실성 처리다

에이전트가 필요한 순간은 대개 모델이 더 똑똑해서가 아닙니다. 문제의 경로가 미리 고정되지 않았기 때문입니다.

정해진 워크플로가 강한 이유는 명확합니다. 단계가 보이고, 실패 지점이 보이고, 테스트 범위도 잡힙니다. 반대로 에이전트가 필요한 문제는 시작할 때부터 경로가 흐릿합니다. 어디서 정보를 찾아야 할지 매번 다르고, 한 번 찾아본 뒤에야 다음 질문이 생기고, 중간 결과에 따라 전략을 바꿔야 합니다.

예를 들어 장애 분석 보조 기능을 생각해 봅시다. 사용자가 "오늘 새벽 결제 실패율이 왜 올랐는지 조사해 줘"라고 말하면, 정답으로 가는 길은 항상 같지 않습니다. 배포 이력을 봐야 할 수도 있고, 특정 결제사 상태를 확인해야 할 수도 있고, 에러 로그를 먼저 보는 편이 맞을 수도 있습니다. 어떤 경우에는 최근 설정 변경이 원인이고, 어떤 경우에는 외부 API 지연이 원인입니다. 이때는 처음부터 순서를 고정한 워크플로보다, 관찰 결과에 따라 다음 행동을 바꾸는 구조가 더 잘 맞습니다.

즉, 에이전트의 본질은 "스스로 생각하는 AI"라는 멋진 이미지가 아니라, 경로를 미리 완전히 못 박을 수 없는 문제를 다루는 방식에 있습니다.

이런 문제에는 에이전트가 꽤 잘 맞는다

에이전트가 유효한 문제에는 공통점이 있습니다. 길이 하나가 아니라 여러 갈래이고, 중간에 무엇을 보느냐에 따라 다음 행동이 달라지며, 한 번의 답변보다 탐색과 점검 과정 자체가 중요합니다.

다음과 같은 조건이 겹치면 에이전트형 설계가 힘을 발휘할 가능성이 큽니다.

• 어떤 도구를 먼저 써야 할지 요청마다 달라진다.

• 한 번 조회한 결과를 보고 추가 조회나 다른 접근이 필요해진다.

• 작업 성공에 필요한 정보가 여러 시스템에 흩어져 있다.

• 사용자 요청이 모호해서 중간에 확인 질문이나 계획 수정이 필요하다.

• 정답보다 탐색 과정과 근거 수집이 더 중요하다.

이런 문제에서는 개발자가 모든 분기를 미리 코드로 적으려 하면 오히려 더 복잡해집니다. 경우의 수가 너무 많기 때문입니다.

대표적인 예를 몇 가지 들어 보겠습니다.

첫 번째는 운영·장애 분석 코파일럿입니다. 로그, 메트릭, 배포 기록, 런북, 최근 알림 이력을 오가며 원인 후보를 좁혀 가는 작업은 탐색형입니다. 한 번 조회한 정보가 다음 조회 대상을 바꾸므로 에이전트 루프가 어울립니다.

두 번째는 복잡한 리서치 보조입니다. 예를 들어 영업 담당자가 "이 고객사에 맞는 제안 포인트를 정리해 줘"라고 했을 때, 회사 정보, 최근 뉴스, 기존 CRM 기록, 경쟁사 비교 자료를 오가며 필요한 근거를 모아야 할 수 있습니다. 어떤 정보를 더 찾을지는 중간 결과에 따라 달라집니다.

세 번째는 다단계 문서 검토입니다. 보험 청구, 법무 검토, 규정 준수 확인처럼 여러 문서를 대조하며 빠진 항목을 찾고, 불일치가 있으면 추가 자료를 요청하는 작업은 한 번에 끝나지 않는 경우가 많습니다.

이런 문제에서는 "한 번 묻고 한 번 답하는 기능"보다 "관찰하고, 판단하고, 다시 행동하는 구조"가 더 자연스럽습니다.

하지만 대부분의 기능은 에이전트가 없어도 된다

반대로 말하면, 많은 LLM 기능은 에이전트를 전혀 필요로 하지 않습니다. 오히려 에이전트를 붙이는 순간 불안정해집니다.

예를 들어 요약, 재작성, 제목 생성, 태그 추천, 문의 분류, 감성 분석, 문서에서 특정 필드 추출 같은 작업은 본질적으로 입력과 출력이 비교적 명확합니다. 물론 모델 품질 차이는 있겠지만, 경로가 매번 달라지는 문제는 아닙니다. 이런 작업에 에이전트 루프를 넣으면 얻는 이익보다 잃는 것이 더 많습니다.

사용자가 리뷰 100개를 넣었을 때 핵심 불만을 요약하는 기능을 만든다고 해봅시다. 여기서 필요한 것은 좋은 요약이지, 요약하기 전에 세 번 검색하고 두 번 자기 점검하는 자율 루프가 아닙니다. 문의를 billing인지 bug인지 분류하는 작업도 마찬가지입니다. 정해진 스키마로 분류하면 끝날 일을 굳이 에이전트로 만들 필요는 없습니다.

외부 API가 들어가더라도 여전히 에이전트가 과할 수 있습니다. 예를 들어 "주문 번호를 받아 배송 상태를 조회하고 결과를 보여 준다"는 기능은 툴 호출이 필요할 수 있지만, 경로가 정해져 있습니다. 이건 에이전트보다 그냥 잘 만든 워크플로가 더 낫습니다.

핵심은 이것입니다. 툴이 있다는 사실이 에이전트를 정당화하지 않는다. 중요한 것은 툴의 개수가 아니라 경로의 불확실성입니다.

에이전트가 과해지는 전형적인 순간

실무에서는 아래 상황에서 특히 에이전트가 오버엔지니어링이 되기 쉽습니다.

첫째, 문제를 이미 규칙 기반 흐름으로 충분히 풀 수 있을 때입니다. 단계가 명확하고 예외도 관리 가능하다면, 굳이 모델에게 다음 행동 결정을 맡길 이유가 없습니다.

둘째, 응답 시간이 중요한 기능일 때입니다. 에이전트는 보통 여러 번 생각하고, 여러 번 호출하고, 중간 검증도 거칩니다. 사용자가 버튼을 눌렀을 때 1초 안에 결과가 나와야 하는 화면에는 맞지 않는 경우가 많습니다.

셋째, 대량 트래픽을 저렴하게 처리해야 할 때입니다. 단순 분류 작업 수십만 건을 에이전트 루프로 돌리면 비용이 눈덩이처럼 불어납니다. 이런 경우에는 작은 모델, 고정 프롬프트, 배치 처리, 규칙 기반 전처리가 훨씬 실용적입니다.

넷째, 실패 비용이 큰 쓰기 작업일 때입니다. 환불, 예약 취소, 권한 변경, 메일 발송, 계약 생성처럼 실제 상태를 바꾸는 작업은 한 번 잘못 실행되면 되돌리기 어렵습니다. 에이전트가 이 영역까지 자유롭게 돌아다니게 두면 위험이 커집니다.

다섯째, 성공 기준이 모호한데도 자동 실행을 하려 할 때입니다. 에이전트는 목표가 흐리면 쉽게 헤맵니다. "알아서 잘 처리해 줘"는 사람에게도 어려운 지시인데, 모델에게는 더 어렵습니다.

이런 상황에서는 자율성을 줄이고, 경계를 더 분명하게 잡는 편이 거의 항상 낫습니다.

좋은 설계는 항상 사다리처럼 올라간다

에이전트가 필요한지 헷갈릴 때는 "지금 당장 자율성을 얼마나 줘야 하는가"를 묻기보다, 한 단계씩 올라가는 편이 좋습니다.

보통은 다음 순서가 가장 안전합니다.

• 먼저 단일 기능으로 문제를 검증한다.

• 그다음 구조화 출력으로 결과를 안정시킨다.

• 필요하면 정해진 워크플로에 툴 호출을 넣는다.

• 그래도 분기 수가 너무 많을 때만 제한된 에이전트 루프를 도입한다.

• 마지막으로 정말 필요할 때만 더 넓은 자율성을 준다.

이 순서가 중요한 이유는 간단합니다. 많은 팀이 사실 세 번째 단계에서 이미 충분한데, 네 번째와 다섯 번째를 너무 빨리 꿈꾸기 때문입니다.

예를 들어 고객 지원 자동화를 만든다면, 처음부터 "고객 문제를 알아서 해결하는 에이전트"를 만들 필요는 없습니다. 먼저 문의를 분류하고, 관련 주문을 조회하고, 답변 초안을 만들고, 특정 조건에서만 상담사에게 넘기는 정해진 흐름부터 만들어 보세요. 이 구조로도 대부분의 가치는 이미 나옵니다. 그다음 실제 로그를 보며, 정말 매번 경로가 달라지는 구간이 있는지 확인하는 것이 맞습니다.

에이전트는 출발점이 아니라 대개 후반부 최적화 수단에 가깝습니다.

판단 기준 1: 경로를 미리 그릴 수 있는가

에이전트 도입 여부를 판단하는 가장 좋은 질문은 이것입니다.

이 문제의 해결 경로를 개발자가 미리 꽤 정확하게 그릴 수 있는가?

만약 "대체로 그렇다"라면, 에이전트보다 워크플로가 낫습니다. 사용자가 환불을 요청하면 주문 조회, 정책 확인, 확인 메시지, 환불 요청 생성이라는 순서를 거의 항상 밟는다면, 이건 이미 경로가 보이는 문제입니다.

반대로 "아니다, 매번 어디서부터 봐야 할지가 다르다"라면 에이전트 후보가 됩니다. 장애 조사, 다중 문서 비교, 리서치 보조처럼 시작점은 같아도 전개가 매번 달라지는 문제는 루프가 잘 맞습니다.

여기서 중요한 것은 화려함이 아니라 예측 가능성입니다. 예측 가능한 문제를 굳이 예측 불가능한 구조로 바꾸지 않는 것이 좋은 설계입니다.

판단 기준 2: 중간 결과가 다음 행동을 바꾸는가

에이전트가 빛나는 또 하나의 순간은 중간 관찰이 다음 행동을 바꾸는 경우입니다.

예를 들어 에러 로그를 봤더니 특정 결제사에서만 실패율이 높다면, 다음에는 해당 결제사의 상태 페이지나 최근 배포를 봐야 합니다. 반대로 모든 결제사에서 고르게 실패율이 올랐다면, 공통 인증 레이어나 데이터베이스 연결 문제를 먼저 살펴봐야 할 수 있습니다. 처음에는 같은 질문으로 시작했지만, 중간 관찰이 전혀 다른 다음 행동을 부릅니다.

이런 구조라면 에이전트가 의미가 있습니다. 하지만 어떤 결과가 나오든 항상 같은 다음 단계로 가는 작업이라면 자율 루프의 이점이 거의 없습니다.

쉽게 말해, 중간 결과가 그냥 참고 자료인지, 아니면 실제로 다음 행동을 바꾸는 신호인지를 구분하면 됩니다.

판단 기준 3: 실패를 감당할 수 있는가

에이전트는 멋져 보이지만 실패 모드도 다채롭습니다. 같은 목표를 향해 돌아가다 엉뚱한 도구를 고를 수 있고, 너무 많은 단계를 쓰며 시간을 낭비할 수 있고, 중간에 그럴듯한 오판을 쌓아 갈 수도 있습니다.

그래서 에이전트를 쓸 때는 "성공 가능성"만 보면 안 됩니다. 실패했을 때 얼마나 아픈가를 먼저 봐야 합니다.

읽기 중심 작업, 초안 작성, 조사 보조, 추천안 제시처럼 실패해도 사람이 검토하고 고칠 수 있는 영역은 상대적으로 안전합니다. 반면 잘못 실행되면 금전, 권한, 고객 커뮤니케이션에 직접 영향을 주는 영역은 훨씬 보수적으로 접근해야 합니다.

특히 다음 세 가지가 함께 있으면 자율성을 크게 줄이는 편이 좋습니다.

• 상태 변경이 발생한다.

• 되돌리기 어렵다.

• 사용자가 즉시 피해를 체감한다.

이런 작업은 에이전트가 계획을 세우더라도 마지막 실행은 별도 승인 단계나 고정 워크플로가 맡는 편이 안전합니다.

판단 기준 4: 평가와 디버깅이 가능한가

에이전트는 답 하나만 평가하면 끝나는 구조가 아닙니다. 어떤 도구를 왜 골랐는지, 몇 단계 만에 멈췄는지, 중간 판단이 어디서 빗나갔는지까지 봐야 합니다.

여기서 많은 팀이 무너집니다. 데모에서는 "오, 여러 도구를 알아서 쓰네"가 멋져 보이지만, 운영에서는 "왜 여기서 이 도구를 골랐지?"가 매일 문제로 돌아옵니다.

따라서 에이전트를 쓸 수 있으려면 최소한 이런 질문에 답할 수 있어야 합니다.

• 성공이 무엇인지 명확한가

• 몇 단계 이상 돌면 실패로 볼지 정해져 있는가

• 어떤 도구 선택이 좋았고 나빴는지 기록할 수 있는가

• 중간 결과와 최종 결과를 따로 평가할 수 있는가

• 실패 시 사람이나 더 단순한 흐름으로 넘길 수 있는가

이 기준이 없다면, 에이전트는 똑똑한 자동화가 아니라 관찰하기 어려운 랜덤 시스템이 되기 쉽습니다.

실전 예시: 이건 에이전트가 어울린다

하나의 좋은 예로 SaaS 운영팀을 위한 장애 분석 보조 기능을 생각해 봅시다.

운영자가 "오늘 오전 체크아웃 전환율 급락 원인 찾아줘"라고 입력합니다. 이 요청은 단순 요약과 다릅니다. 전환율 대시보드 확인, 최근 배포 이력 조회, 에러 로그 검색, 결제사 상태 확인, 관련 런북 검색이 모두 후보가 됩니다. 그런데 어느 순서가 맞는지는 처음부터 알 수 없습니다.

이 상황에서 에이전트는 다음처럼 움직일 수 있습니다. 먼저 전환율 하락 구간을 확인하고, 같은 시간대 에러 로그를 보고, 특정 엔드포인트 오류가 급증했다면 최근 배포 이력을 다시 확인하고, 외부 결제사 문제 징후가 있으면 상태 페이지를 조회합니다. 그리고 마지막에는 "가장 가능성이 높은 원인", "근거", "추가 확인 필요 사항"을 정리해 줍니다.

여기서는 자율성이 실제 가치로 이어집니다. 정해진 한 줄짜리 흐름보다, 상황에 따라 조사 방향을 바꾸는 능력이 중요하기 때문입니다.

물론 이 경우에도 에이전트가 직접 배포를 롤백하게 둘 필요는 없습니다. 진단과 제안은 자율적으로 하되, 실제 조치는 사람 승인이나 별도 운영 워크플로가 맡는 편이 맞습니다.

실전 예시: 이건 에이전트가 과하다

반대로 고객 문의 자동 라우팅을 생각해 봅시다. 사용자의 메시지를 보고 결제, 계정, 버그, 기능 요청 중 어디로 보낼지 정하고, 초안 답변을 만드는 기능입니다.

겉으로 보기에는 에이전트처럼 만들 수도 있습니다. 먼저 의도를 추론하고, 필요한 경우 주문 조회를 하고, 정책을 읽고, 다시 카테고리를 바꾸고, 마지막에 티켓을 생성하는 식입니다. 하지만 대부분의 팀에게 이건 과합니다.

실제로는 이렇게 풀면 충분한 경우가 많습니다. 먼저 구조화된 분류를 수행하고, 카테고리에 따라 필요한 데이터 조회를 정해진 순서로 하고, 특정 조건에서만 사람 검토로 넘기면 됩니다. 경로가 대체로 예측 가능하기 때문입니다.

이 기능을 굳이 에이전트로 만들면 어떤 일이 벌어질까요. 단계 수가 늘고, 비용이 커지고, 응답 시간이 길어지고, 같은 문의에도 매번 다른 경로를 타게 됩니다. 운영자는 "왜 어떤 건 바로 분류되고 어떤 건 두 번 조회하다 끝났지?"를 추적해야 합니다. 즉, 문제보다 구조가 더 복잡해집니다.

이럴 때는 덜 자율적이지만 더 안정적인 워크플로가 정답입니다.

가장 흔한 안티패턴: 문제는 작은데 자율성은 크다

에이전트 도입이 실패하는 가장 흔한 이유는 단순합니다. 문제 크기보다 자율성을 너무 크게 주기 때문입니다.

대표적인 안티패턴은 이렇습니다.

• 한 번의 조회로 끝날 작업에 다단계 루프를 연다.

• 성공 기준이 모호한데 "알아서 해결"을 목표로 둔다.

• 쓰기 도구를 읽기 도구처럼 자유롭게 풀어 둔다.

• 도구 수를 늘리는 것을 성능 향상으로 착각한다.

• 실패 시 사람 개입 경로 없이 자동 실행만 믿는다.

• 비용 한도와 단계 제한 없이 에이전트를 돌린다.

특히 "툴을 많이 붙일수록 똑똑해진다"는 생각은 위험합니다. 툴이 늘어날수록 선택 오류 가능성도 커지고, 잘못된 경로로 멀리 달려갈 여지도 커집니다. 많이 아는 것과 잘 선택하는 것은 다른 문제입니다.

에이전트를 써야 한다면 좁고 단단하게 시작하라

정말 에이전트가 필요한 문제라면, 그때도 처음부터 넓게 열지 않는 것이 중요합니다. 실무에서는 "작은 자유"가 "큰 자유"보다 훨씬 오래 갑니다.

좋은 출발점은 좁은 목표와 제한된 도구입니다. 예를 들어 "장애 원인 후보를 세 가지 이하로 좁혀라", "문서 누락 여부만 판정하라", "읽기 전용 도구만 사용하라"처럼 경계를 작게 잡는 것입니다.

또 최소한 다음 장치는 두는 편이 좋습니다.

• 사용할 수 있는 도구를 allowlist로 제한한다.

• 읽기 도구와 쓰기 도구를 분리한다.

• 최대 단계 수와 최대 토큰 예산을 둔다.

• 각 단계의 판단과 도구 선택 이유를 로그로 남긴다.

• 실패하면 사람 검토나 고정 워크플로로 폴백한다.

이 장치들은 에이전트의 자율성을 깎아 먹는 것처럼 보일 수 있습니다. 하지만 실제로는 반대입니다. 이런 경계가 있어야만 자율성을 안전하게 쓸 수 있습니다.

서비스 관점에서 에이전트의 진짜 비용

에이전트가 비싼 이유는 단순히 API 호출 수가 많아서만이 아닙니다. 운영 비용 전체가 올라가기 때문입니다.

먼저 지연 시간이 늘어납니다. 한 번의 응답이면 끝날 일을 여러 단계로 나누면, 사용자 체감 속도는 금방 나빠집니다. 그다음 토큰 비용이 커집니다. 중간 상태를 다시 넣고, 도구 결과를 읽고, 계획을 수정할수록 문맥도 길어집니다.

하지만 더 큰 문제는 관측과 유지보수입니다. 왜 실패했는지 보려면 각 단계의 프롬프트, 도구 결과, 중간 판단을 모두 들여다봐야 합니다. 고정 워크플로에서는 한 줄 로그로 끝나던 문제도, 에이전트에서는 작은 사건 기록처럼 추적해야 합니다.

거기에 제품 비용도 있습니다. 사용자는 항상 자율성을 원하는 것이 아닙니다. 많은 경우 사용자는 "알아서 많이 생각하는 AI"보다 "빨리, 안정적으로, 예측 가능하게 동작하는 기능"을 더 좋아합니다. 운영팀도 마찬가지입니다. 화려한 자율성보다 재현 가능한 실패를 더 사랑합니다.

결국 에이전트의 가격표에는 토큰만 적혀 있는 것이 아닙니다. 지연 시간, 디버깅 시간, 운영 긴장도, 승인 절차, 테스트 복잡도까지 다 함께 붙어 있습니다.

이렇게 판단하면 크게 틀리지 않는다

실무에서 빠르게 판단하려면 다섯 가지 질문으로 충분합니다.

첫째, 경로를 미리 설계할 수 있는가. 가능하다면 워크플로가 우선입니다.

둘째, 중간 관찰이 다음 행동을 자주 바꾸는가. 그렇다면 에이전트 후보입니다.

셋째, 실패해도 사람이 검토하고 되돌릴 수 있는가. 그렇지 않다면 자율성을 낮춰야 합니다.

넷째, 단계별 평가와 로그가 가능한가. 불가능하다면 아직 운영할 준비가 안 된 것입니다.

다섯째, 에이전트가 추가하는 복잡성이 실제 사용자 가치보다 큰가 작은가. 이 질문에서 머뭇거리면, 대개는 아직 이릅니다.

한 문장으로 줄이면 이렇습니다. 경로가 불확실하고, 탐색이 핵심이며, 실패를 통제할 수 있을 때만 에이전트를 써라. 그 외에는 정해진 워크플로가 더 좋은 엔지니어링입니다.

정리

에이전트는 LLM 서비스의 최종 진화형이 아닙니다. 어떤 문제에는 강력한 해법이지만, 많은 문제에는 지나치게 무거운 선택입니다.

이번 장에서 기억해야 할 기준은 분명합니다. 에이전트가 필요한 문제는 경로가 매번 달라지고, 중간 관찰이 다음 행동을 바꾸며, 탐색 자체가 가치인 문제입니다. 반대로 요약, 분류, 추출, 고정된 조회-응답 흐름처럼 입력과 출력이 명확한 기능은 정해진 워크플로가 더 싸고, 더 빠르고, 더 안정적입니다.

무엇보다 중요한 점은 이것입니다. 에이전트는 잘 쓰면 유연한 문제 해결기지만, 잘못 쓰면 가장 비싸고 가장 불안정한 선택이 된다. 그래서 실전에서는 언제나 작은 자동화에서 시작해, 정말 필요한 곳에만 자율성을 열어 주는 편이 이깁니다.

서비스를 오래 운영하는 팀은 대개 같은 결론에 도달합니다. 똑똑해 보이는 구조보다, 경계가 분명한 구조가 더 오래 갑니다. 그리고 에이전트는 그 경계가 충분히 설계된 뒤에야 비로소 제값을 합니다.