6부 31장. 에이전트를 잘 쓰기 위한 사고방식

앞 장들에서 우리는 에이전트가 무엇인지, 챗봇과 무엇이 다른지, 어떤 에이전트는 도구를 쓰고 어떤 에이전트는 계획하고 실행까지 이어 간다는 점을 살펴봤다. 또 하나의 에이전트로 일할 때와 여러 에이전트가 역할을 나눌 때의 차이도 봤다.

이제 중요한 질문이 남는다.

그렇다면 에이전트를 어떻게 바라봐야 잘 쓸 수 있을까?

이 질문은 생각보다 중요하다. 많은 실패가 기술 부족 때문이 아니라 기대치 설정 실패에서 시작되기 때문이다. 사람들은 에이전트를 처음 만났을 때 흔히 두 가지 극단으로 간다. 하나는 "이제 알아서 다 해 주겠지"라는 과한 기대다. 다른 하나는 "실수하네, 역시 별거 아니군"이라는 너무 빠른 실망이다.

둘 다 정확하지 않다. 에이전트는 만능 대행자도 아니고, 쓸모없는 장난감도 아니다. 더 정확한 표현은 이것이다.

에이전트는 제한된 자율성을 가진 작업 시스템이다.

이 관점을 받아들이는 순간부터 활용 방식이 달라진다. 무엇을 맡기고, 어디까지 자동화하고, 어디서 확인하고, 어떻게 실패를 줄일지를 훨씬 현실적으로 생각하게 되기 때문이다.

에이전트를 사람처럼 기대하면 오히려 실패한다

에이전트를 잘 못 쓰는 가장 흔한 이유는 기술적인 세팅이 아니라, 머릿속 모델이 잘못되어 있기 때문이다.

사람은 "유능한 비서"나 "똑똑한 동료" 같은 비유를 듣는 순간, 에이전트가 상황을 넓게 이해하고, 빠진 맥락을 눈치채고, 위험한 행동은 알아서 피하고, 애매하면 적당히 상식적으로 판단할 것이라고 기대한다. 하지만 실제 에이전트는 그렇게 움직이지 않는 경우가 많다.

에이전트는 문맥 안에서 꽤 그럴듯하게 행동할 수 있다. 도구도 쓸 수 있고, 계획도 세울 수 있고, 실행도 이어 갈 수 있다. 하지만 여전히 목표 해석이 어긋날 수 있고, 잘못된 전제를 끝까지 끌고 갈 수 있고, 형식은 훌륭한데 내용은 빈약한 결과를 낼 수도 있다.

문제는 이 실수가 특별한 예외가 아니라는 점이다. 오히려 어느 정도는 기본값에 가깝다.

그래서 에이전트를 사람처럼 믿는 태도는 위험하다. 사람은 어긋난 맥락을 눈치채며 바로잡는 능력이 있지만, 에이전트는 틀린 방향을 매우 성실하게 밀어붙일 때가 있다. 열심히 일한다고 해서 항상 잘 일하는 것은 아니다. 이 점을 먼저 인정해야 한다.

만능 대행자가 아니라 제한된 자율성을 가진 시스템

에이전트를 잘 쓰는 사람은 에이전트를 "똑똑한 존재"보다 "설계된 작업 흐름"으로 본다.

이 말은 에이전트의 능력을 낮게 보라는 뜻이 아니다. 오히려 더 정확하게 보라는 뜻이다. 에이전트는 어떤 범위에서는 놀랄 만큼 유용하다. 정해진 문서를 읽고 요약하는 일, 자료를 비교해 표로 정리하는 일, 특정 형식에 맞춰 초안을 만드는 일, 테스트를 돌리고 결과를 분류하는 일처럼 경계가 비교적 분명한 작업에서는 매우 강하다.

반면 목표가 흐리거나, 성공 기준이 애매하거나, 책임이 큰 결정을 포함하거나, 예상 밖의 상황이 자주 나오는 일에서는 쉽게 흔들린다.

즉, 에이전트는 "아무 일이나 맡길 수 있는 존재"가 아니라 "조건이 맞을 때 강하게 작동하는 시스템"이다. 이 관점을 가지면 실망도 줄고, 성과는 오히려 더 좋아진다. 기대를 낮춰서가 아니라, 기대를 정확하게 맞추기 때문이다.

첫 번째 사고방식: 맡길 일을 먼저 고르고, 에이전트를 고르라

많은 사람은 먼저 도구를 고른다. 그리고 나서 "이걸 어디에 쓸 수 있을까?"를 생각한다. 하지만 실전에서는 순서가 반대인 편이 낫다.

먼저 해야 할 일을 본다. 그 일의 구조를 본다. 어떤 입력이 필요한지, 어디에서 자주 실수하는지, 결과가 어떻게 검증되는지 본다. 그다음에 그 작업에 맞는 에이전트를 붙인다.

예를 들어 "시장 조사 보고서 작성"이라고 한 덩어리로 보면 에이전트에게 너무 큰 일을 던지는 셈이 된다. 하지만 이것을 자료 수집, 비교 기준 정리, 초안 작성, 사실 확인, 형식 편집으로 나누면 이야기가 달라진다. 어떤 단계는 에이전트가 아주 잘할 수 있고, 어떤 단계는 사람 검토가 꼭 필요하다는 것이 보이기 시작한다.

에이전트를 잘 쓰는 사람은 "AI에게 무엇을 시킬까?"보다 "이 작업에서 어디를 분리하면 안정적으로 맡길 수 있을까?"를 먼저 생각한다.

두 번째 사고방식: 목표보다 경계를 먼저 정하라

초보자는 에이전트에게 목표를 길게 설명하는 데 집중한다. 물론 목표는 중요하다. 하지만 그보다 더 중요한 것이 있다. 바로 경계다.

에이전트에게 필요한 것은 "무엇을 하라"뿐 아니라 "무엇을 하지 말라"이기도 하다. 어디까지 자동으로 진행해도 되는지, 어떤 경우에는 멈춰야 하는지, 어떤 행동은 반드시 확인을 받아야 하는지가 분명해야 한다.

예를 들어 "고객 문의를 분류하고 초안 답변을 작성해 줘"와 "고객에게 답장을 직접 보내 줘"는 전혀 다른 수준의 권한을 의미한다. "코드 수정안을 만들어 줘"와 "바로 운영 서버에 반영해 줘"도 마찬가지다.

에이전트 활용이 실패하는 이유는 종종 성능 부족이 아니라 경계 부재다. 할 수 있는 것과 해도 되는 것을 구분하지 않으면, 작은 자동화가 큰 사고로 이어진다.

에이전트를 설계할 때는 늘 이런 질문이 필요하다.

• 어디까지 스스로 진행해도 되는가

• 어떤 조건에서는 멈추고 물어야 하는가

• 무엇은 제안만 하고 무엇은 실행할 수 있는가

• 잘못되었을 때 되돌릴 수 있는가

이 질문에 답하지 못했다면, 아직 에이전트를 쓸 준비가 덜 된 것이다.

세 번째 사고방식: 큰 일을 한 번에 맡기지 말고, 통과 가능한 단계로 쪼개라

에이전트는 긴 일을 한 번에 맡길수록 멋지게 실패할 가능성이 커진다. 시작은 그럴듯한데 중간에 전제가 틀어지고, 마지막 결과만 보면 무엇이 잘못되었는지 찾기 어려워진다.

그래서 중요한 것은 에이전트에게 큰일을 맡기지 않는 것이 아니라, 큰일을 작은 통과 지점들로 나누는 것이다.

예를 들어 "다음 주 발표 자료를 준비해 줘"라고 한 번에 맡기기보다, 먼저 발표 목적과 청중을 정리하게 한다. 그다음 핵심 메시지 세 개를 뽑게 한다. 그다음 장표 목차를 잡게 한다. 그다음 슬라이드 초안을 만들게 한다. 마지막에 표현을 다듬게 한다.

이렇게 하면 에이전트가 매 단계에서 무엇을 하고 있는지 보인다. 방향이 틀렸을 때도 초반에 잡아낼 수 있다. 결국 품질은 마지막 명령의 화려함보다 중간 단계의 설계에서 갈린다.

네 번째 사고방식: 좋은 에이전트는 한 번 잘하는 시스템이 아니라, 반복해도 덜 흔들리는 시스템이다

데모는 누구나 멋지게 만들 수 있다. 우연히 잘 나온 한 번의 결과를 보여 주는 것은 어렵지 않다. 하지만 실무는 다르다. 내일도 비슷하게 작동해야 하고, 입력이 조금 달라져도 무너지지 않아야 하며, 다른 사람이 써도 어느 정도 비슷한 품질이 나와야 한다.

그래서 에이전트를 평가할 때는 "이번에 잘했는가?"보다 "반복해서 써도 괜찮은가?"를 봐야 한다.

한 번은 훌륭한 보고서를 만들었는데, 다음번에는 기준이 바뀌고, 그다음에는 형식이 흔들리고, 또 다른 날에는 핵심 항목을 빠뜨린다면 그것은 아직 믿고 맡길 시스템이 아니다. 재미있는 장난감일 수는 있어도 작업 기반은 되기 어렵다.

에이전트를 잘 쓰는 사고방식은 항상 재현성을 중요하게 여긴다. 입력이 바뀌면 어디까지 달라지는지, 실패는 어떤 패턴으로 나타나는지, 무엇을 넣어야 안정적으로 작동하는지 보는 습관이 필요하다.

다섯 번째 사고방식: 결과만 보지 말고 중간 흔적을 보라

에이전트가 낸 최종 결과만 보고 판단하면 늦을 때가 많다. 특히 실행이 들어가는 시스템일수록 더 그렇다. 결과가 나오기까지 어떤 파일을 읽었는지, 어떤 계획을 세웠는지, 어떤 근거를 썼는지, 어디서 자신 없는 상태였는지를 볼 수 있어야 한다.

사람도 일을 맡기면 과정이 궁금하다. 에이전트라고 다를 이유가 없다.

오히려 에이전트는 과정을 더 봐야 한다. 그 이유는 단순하다. 그럴듯한 결과가 엉뚱한 경로에서 나왔을 수도 있기 때문이다. 우연히 맞은 답은 다음번에도 맞는다는 보장이 없다.

예를 들어 리서치 에이전트가 경쟁사 비교표를 만들어 왔다고 하자. 표만 보면 멀쩡해 보일 수 있다. 하지만 실제로는 오래된 자료를 썼는지, 서로 기준이 다른 수치를 한 표에 섞었는지, 확인되지 않은 추정을 사실처럼 썼는지는 중간 흔적을 봐야 드러난다.

에이전트를 잘 쓰는 사람은 최종 산출물뿐 아니라 중간 산출물도 챙긴다. 계획, 근거, 사용한 자료, 판단 보류 지점 같은 흔적이 쌓일수록 시스템은 더 믿을 만해진다.

여섯 번째 사고방식: 실패를 예외로 보지 말고 기본 조건으로 받아들여라

에이전트를 쓰다 보면 많은 사람이 이렇게 생각한다.

"한두 번 실수했으니 조금만 더 다듬으면 완벽해지겠지."

하지만 실전에서는 완벽보다 관리 가능한 실패가 더 중요하다. 에이전트는 실수할 수 있다. 문제는 실수 자체가 아니라, 그 실수가 어디서 드러나고 어떻게 막히며 얼마나 빨리 복구되는가다.

이 점에서 좋은 사고방식은 낙관이 아니라 대비다. 에이전트가 잘못된 전제로 움직일 수 있다고 가정하고, 중간 확인 지점을 넣고, 취소 가능한 작업부터 맡기고, 되돌릴 수 없는 실행은 승인 단계 뒤로 미루는 식으로 설계해야 한다.

실패를 없애려는 태도보다 실패를 가두려는 태도가 더 현실적이다. 그리고 대개 더 안전하다.

일곱 번째 사고방식: 자율성은 한 번에 주는 것이 아니라 단계적으로 늘려야 한다

에이전트를 처음 붙일 때 가장 위험한 순간은 "생각보다 잘하네?" 하고 갑자기 너무 많은 권한을 주는 때다. 초안 작성이 잘 되었다고 곧바로 발송까지 맡기고, 테스트 실행이 잘 되었다고 곧바로 배포까지 맡기면 사고가 난다.

자율성은 실험적으로 늘려야 한다. 먼저 읽기만 하게 한다. 그다음 정리와 제안까지 맡긴다. 그다음 제한된 실행을 맡긴다. 마지막으로 승인 기반 자동화로 확장한다.

이 순서는 느려 보이지만 실제로는 더 빠르다. 초반에 작은 실패를 통해 시스템의 약점을 배우고, 어떤 지점에서 사람이 개입해야 하는지 알게 되기 때문이다. 반대로 처음부터 큰 권한을 주면 한 번의 큰 사고로 전체 도입이 중단될 수도 있다.

에이전트를 잘 쓰는 사람은 능력보다 권한을 더 조심스럽게 늘린다.

여덟 번째 사고방식: 에이전트의 장점은 '대신 생각'이 아니라 '작업 부담 분산'에 있다

에이전트를 잘못 이해하면 사람의 판단을 통째로 넘기려 한다. 하지만 실제로 에이전트가 가장 큰 도움을 주는 지점은 "생각을 완전히 대신하는 것"보다 "생각할 수 있게 부담을 덜어 주는 것"에 있다.

예를 들어 회의 후속 작업을 생각해 보자. 에이전트는 회의록을 정리하고, 액션 아이템을 추출하고, 담당자별 할 일을 정리하고, 후속 이메일 초안을 만들 수 있다. 이때 사람은 정말 중요한 판단, 즉 우선순위 조정과 민감한 표현 확인, 이해관계 조율에 집중할 수 있다.

이 구조가 좋다. 에이전트는 작업 부담을 줄이고, 사람은 책임 있는 판단에 집중한다. 반대로 판단까지 모두 넘기려 하면, 겉보기 효율은 올라가도 실제 신뢰도는 떨어진다.

즉, 에이전트의 핵심 가치는 "나 대신 전부 하기"보다 "내가 더 중요한 일에 집중하게 만들기"에 있다.

아홉 번째 사고방식: 잘 쓰는 사람은 늘 '검증 비용'을 함께 계산한다

자동화는 공짜가 아니다. 에이전트가 결과를 빠르게 만들어도, 그 결과를 확인하는 비용이 너무 크면 이득이 줄어든다.

예를 들어 에이전트가 10분 만에 계약서 요약을 만들었다고 하자. 하지만 사람이 그것을 믿지 못해 원문을 40분 동안 다시 읽어야 한다면, 그 자동화는 아직 완성도가 낮다. 반면 회의록 요약처럼 오류의 비용이 비교적 작고 사람이 빠르게 눈으로 확인할 수 있는 작업은 훨씬 쉽게 자동화 가치가 나온다.

그래서 에이전트를 붙일 때는 늘 이런 계산이 필요하다. "생성 비용"만이 아니라 "검증 비용"까지 포함해서 봐야 한다. 생성은 빠르지만 검증이 어려운 작업은 아직 완전 자동화보다 보조 역할이 더 적합할 수 있다.

잘 쓰는 사람은 에이전트가 낸 결과의 화려함보다, 그것을 확인하고 운영하는 전체 비용을 본다.

실전에서 바로 쓰는 판단 기준

에이전트를 실제 업무에 붙이기 전에, 다음 기준으로 한번 점검해 보면 좋다.

• 목표가 비교적 분명한가

• 입력 자료가 정리되어 있는가

• 성공 기준을 말로 설명할 수 있는가

• 중간 산출물을 확인할 수 있는가

• 실수해도 되돌릴 수 있는가

• 사람이 마지막 판단을 내릴 지점이 보이는가

이 여섯 가지 중 몇 개가 비어 있다면, 에이전트가 일을 못해서가 아니라 작업 설계가 덜 되어 있어서 실패할 가능성이 크다.

예시 1: 잘못된 사고방식과 올바른 사고방식의 차이

마케팅 팀이 신규 캠페인 기획안을 준비한다고 해 보자.

잘못된 접근은 이렇다. "에이전트야, 요즘 트렌드를 조사하고 우리 제품에 맞는 캠페인을 기획해서 실행 계획까지 다 만들어 줘." 이 요청은 겉보기에는 멋있지만 실제로는 너무 많은 판단을 한 번에 묶어 놓은 상태다. 트렌드의 범위도 모호하고, 캠페인의 목적도 애매하고, 성공 기준도 불분명하다. 이런 요청은 운이 좋으면 괜찮은 초안을 주지만, 대개는 그럴듯한 일반론으로 흐르기 쉽다.

올바른 접근은 다르다. 먼저 최근 3개월 경쟁사 캠페인을 채널별로 정리하게 한다. 그다음 우리 제품의 핵심 메시지 후보를 세 가지로 압축하게 한다. 그다음 타깃별 메시지 차이를 비교하게 한다. 마지막으로 그 결과를 바탕으로 캠페인 초안을 만들게 한다.

차이는 분명하다. 뒤의 방식은 에이전트를 더 약하게 쓰는 것이 아니라, 더 안정적으로 쓰는 방식이다.

예시 2: 코드 작업에서의 사고방식

코드 작업에서도 같은 원리가 적용된다. "버그를 고쳐 줘"라고 막연하게 맡기면 에이전트는 관련 없는 파일까지 손대거나, 증상을 가리는 임시 처방을 내놓을 수 있다.

반면 "이 오류 로그를 바탕으로 원인 후보를 세 가지로 정리하고, 가장 가능성 높은 원인을 설명한 뒤, 수정안은 패치 형태로 제안하고, 테스트는 아직 실행하지 말라"처럼 경계를 분명히 하면 결과가 훨씬 좋아진다.

여기서 중요한 것은 프롬프트 문장 기술이 아니다. 사고방식이다. 곧바로 다 해결하게 하지 않고, 먼저 진단과 제안을 분리하고, 실행 권한을 뒤로 미루는 태도가 핵심이다.

예시 3: 개인 생산성에서의 사고방식

개인 업무에서도 에이전트는 유용하다. 하지만 여기서도 만능 비서처럼 다루면 실망하기 쉽다.

예를 들어 일정, 메모, 읽을 자료, 할 일이 뒤엉킨 상태에서 "이번 주를 최적화해 줘"라고 하면 듣기에는 멋있지만 실제로는 사용자 본인도 기준이 없는 경우가 많다. 에이전트가 만들어 준 계획은 보기 좋을 수 있어도, 실제 삶의 제약을 반영하지 못할 가능성이 크다.

더 현실적인 방식은 우선순위가 높은 세 가지 일만 고르게 하고, 이미 고정된 일정과 마감일을 먼저 넣고, 남는 시간에 들어갈 후보 작업을 배열하게 하는 것이다. 이렇게 해야 에이전트가 삶 전체를 대신 통제하려는 엉뚱한 방향으로 가지 않는다.

개인 생산성에서도 에이전트는 삶의 조종사가 아니라, 정리와 구조화를 돕는 보조 시스템에 가깝다.

결국 핵심은 기대를 조절하는 능력이다

에이전트를 잘 쓰는 사람과 잘 못 쓰는 사람의 차이는 의외로 복잡한 기술이 아니다. 더 정확하게 기대하는 사람이 더 잘 쓴다.

잘 못 쓰는 사람은 너무 많은 기대를 너무 빨리 건다. 한 번 잘하면 바로 더 큰 권한을 주고, 한 번 실패하면 곧바로 쓸모없다고 판단한다. 에이전트를 사람처럼 대하다가, 사람답지 않은 실수를 보면 크게 실망한다.

잘 쓰는 사람은 다르다. 에이전트가 어떤 종류의 작업에서 강한지, 어떤 조건에서 흔들리는지, 어디서 사람 검토가 필요한지 차분하게 본다. 만능성 대신 범위를 보고, 화려함 대신 재현성을 보고, 자동화 자체보다 운영 가능성을 본다.

이 태도가 생기면 실패율이 줄어든다. 에이전트가 갑자기 똑똑해져서가 아니라, 사용자가 더 정확하게 설계하게 되기 때문이다.

이 장의 정리

에이전트를 잘 쓰기 위한 첫 번째 조건은 에이전트를 과대평가하지 않는 것이다. 에이전트는 만능 대행자가 아니라, 제한된 자율성을 가진 작업 시스템이다.

그래서 중요한 것은 막연히 많이 맡기는 것이 아니라, 맡길 일을 고르고, 경계를 정하고, 단계를 나누고, 중간 흔적을 보고, 실패를 전제로 운영하는 것이다. 자율성은 한 번에 주는 것이 아니라 단계적으로 늘려야 하며, 결과의 화려함보다 반복 가능성과 검증 비용을 함께 봐야 한다.

결국 에이전트를 잘 쓰는 사람은 AI를 신비한 존재로 보지 않는다. 잘 설계하면 강력하지만, 통제 없이 풀어 놓으면 쉽게 흔들리는 시스템으로 본다. 바로 이 현실적인 시선이 에이전트 활용의 성패를 가른다.

다음 장에서는 이 문제를 더 직접적으로 다룬다. 에이전트에게 어디까지 맡길 수 있고, 어디서부터는 사람이 반드시 개입해야 하는지, 그 경계선을 구체적으로 살펴보자.