좋은 사용자는 에이전트에게 일을 잘 시키는 사람이다. 하지만 좋은 설계자는 한 걸음 더 들어간다. 무엇을 시킬까보다 먼저 왜 이 일을 에이전트에게 맡겨야 하는가를 묻는다. 이 순서가 바뀌면, 데모는 멋지지만 현장에서는 잘 안 쓰이는 시스템이 만들어지기 쉽다.
사용자 관점에서는 결과가 먼저 보인다. 답변이 빠른지, 말투가 자연스러운지, 원하는 일을 대신 해주는지가 중요하다. 반면 만드는 사람의 관점에서는 보이지 않는 것이 먼저 중요해진다. 목표는 무엇인지, 실패는 무엇인지, 어디까지 자동화할지, 사람은 언제 개입해야 하는지, 비용은 감당 가능한지 같은 질문들이다. 결국 설계란 똑똑한 답변을 만드는 일이 아니라, 예측 가능한 행동을 하는 시스템을 만드는 일에 가깝다.
이미지 출처: Sanket Mishra on Pexels
좋은 사용자가 좋은 설계자가 되려면
에이전트를 잘 쓰던 사람이 처음 제품을 만들기 시작하면 자주 빠지는 함정이 있다. 자신이 경험한 "와, 이거 된다"의 순간을 그대로 제품 요구사항으로 착각하는 것이다. 예를 들어 프롬프트 몇 줄로 회의 요약이 잘 나왔다고 해서, 곧바로 "회의를 알아서 정리하고 할 일을 배정하는 에이전트"를 만들고 싶어진다. 하지만 여기에는 아주 큰 건너뛰기가 숨어 있다.
사용자는 한 번의 상호작용을 본다. 설계자는 상호작용 뒤에 있는 전체 흐름을 봐야 한다. 이 요청은 어디서 시작되는가, 어떤 데이터를 읽는가, 잘못 이해하면 어떤 피해가 생기는가, 누가 결과를 검토하는가, 다음 단계로 어떻게 연결되는가를 함께 봐야 한다. 같은 "회의 요약"이라도 개인 메모 정리와 팀 업무 배정은 전혀 다른 제품이다. 전자는 편의 기능에 가깝고, 후자는 책임과 권한이 얽힌 운영 시스템에 가깝다.
그래서 관점을 바꾸는 첫 번째 신호는 이것이다. 프롬프트를 다듬는 사람에서, 요구사항을 정의하는 사람으로 이동하는 것. 이때부터 에이전트는 대화 상대가 아니라 하나의 제품 구성요소가 된다.
먼저 묻자, 왜 이 문제를 에이전트로 풀어야 할까
에이전트를 만들고 싶을 때 가장 먼저 해야 할 일은, 사실 에이전트를 만드는 것이 아니다. 오히려 반대로 물어야 한다. "이 문제는 정말 에이전트가 필요한가?" 많은 팀이 이 질문을 건너뛴 채 바로 프롬프트, 프레임워크, 멀티에이전트 구조로 들어간다. 그러면 복잡도는 커지는데 가치가 늘지 않는 일이 흔하다.12
실전에서 선택지는 대개 하나가 아니다. 어떤 문제는 단순한 모델 호출만으로 충분하다. 분류, 요약, 번역처럼 한 번에 끝나는 작업이 그렇다. 어떤 문제는 에이전트가 아니라 결정적인 워크플로, 즉 순서가 정해진 파이프라인이 더 낫다. 반대로 사용자의 요청이 다양하고, 상황에 따라 다른 도구를 골라 써야 하며, 중간 결과를 보고 다시 판단해야 한다면 그때 단일 에이전트가 빛난다. 여러 전문 영역이 섞이고 도구 수가 많아져 한 에이전트가 버거워질 때에야 멀티에이전트를 고려할 이유가 생긴다.234
이 차이는 식당에 비유하면 이해하기 쉽다. 컵라면을 먹으려는데 주방 전체를 설계할 필요는 없다. 반대로 손님이 메뉴를 바꾸고, 재료 재고를 확인하고, 알레르기 정보를 반영해야 한다면 단순한 레시피 카드만으로는 부족하다. 문제의 성격이 복잡해질수록 조리 시스템도 달라져야 한다. 에이전트 설계도 똑같다.
따라서 설계자는 기술보다 먼저 문제를 본다. 열린 문제인가, 여러 단계를 거치는가, 외부 도구가 필요한가, 중간에 확인과 수정이 필요한가. 이 질문들에 대한 답이 쌓여야 비로소 "에이전트가 맞다"는 결론에 도달할 수 있다.14
에이전트가 잘 맞는 문제와 잘 안 맞는 문제
에이전트가 잘 맞는 문제에는 공통점이 있다. 먼저 한 번의 응답으로 끝나지 않는다. 목표를 달성하려면 정보를 모으고, 계획을 세우고, 행동하고, 결과를 보고 다시 조정해야 한다. 또 필요한 정보가 처음부터 다 주어지지 않는 경우가 많다. 누락된 정보를 물어보거나, 문서와 시스템을 뒤져 맥락을 채워야 한다. 여기에 외부 도구 사용까지 얹히면 에이전트의 장점이 살아난다.45
반대로 에이전트가 잘 안 맞는 문제도 분명하다. 입력과 출력이 거의 고정되어 있고, 정해진 규칙으로 안정적으로 처리할 수 있는 일이다. 예를 들어 사내 공지 형식을 맞춰 PDF로 내보내는 일, 미리 정한 카테고리로 문의를 분류하는 일, 정해진 양식의 데이터를 검증하는 일은 굳이 자율적인 판단 구조를 넣지 않아도 된다. 이런 문제에 에이전트를 넣으면 유연성보다 변동성만 늘어난다.
여기서 특히 조심할 점이 하나 있다. 많은 팀이 "복잡해 보이면 멀티에이전트"라고 생각하지만, 실제로는 그렇지 않다. 최근 연구들은 병렬로 나눌 수 있는 문제에서는 여러 에이전트가 도움이 될 수 있지만, 순차적인 추론이 중요한 문제에서는 오히려 성능이 떨어질 수 있다고 보여준다.5 에이전트 수를 늘리는 것은 팀원을 늘리는 것과 비슷하다. 잘 나뉘는 일에서는 빨라지지만, 한 사람이 머리속에서 끝까지 이어서 생각해야 하는 일에서는 회의만 늘어난다.
결국 중요한 것은 "에이전트가 멋져 보이는가"가 아니라 "이 문제의 구조와 맞는가"다.
요구사항은 기능 목록보다 먼저 온다
좋은 설계는 기능 목록으로 시작하지 않는다. "검색도 하고, 메일도 보내고, 슬랙도 연결하고, 문서도 쓰게 하자"는 식의 출발은 대개 위험하다. 에이전트는 기능이 많을수록 좋아지는 제품이 아니라, 책임이 선명할수록 좋아지는 제품이기 때문이다.
설계를 시작할 때는 다섯 가지를 먼저 적어보는 편이 좋다.
목표: 사용자가 진짜 끝내고 싶은 일이 무엇인가. 단순 정보 획득인지, 의사결정 보조인지, 실제 실행까지 포함하는지.
입력과 맥락: 에이전트가 어떤 데이터로 출발하는가. 무엇이 항상 주어지고, 무엇은 중간에 물어봐야 하는가.
행동과 권한: 읽기만 하는가, 초안만 만드는가, 아니면 실제로 수정·발송·실행까지 하는가.
제약 조건: 허용 가능한 지연 시간, 비용, 보안 수준, 규정 준수, 오류 허용 범위는 어느 정도인가.
종료 조건: 언제 성공으로 보고 멈출 것인가. 언제 사람에게 넘길 것인가.
이 다섯 가지를 써보면 놀랍게도 많은 아이디어가 처음부터 걸러진다. "알아서 다 해주는 출장 준비 에이전트" 같은 아이디어도 풀어보면 사실 여러 문제의 묶음이라는 것이 보인다. 항공권 비교는 검색 문제이고, 일정 확정은 승인 문제이며, 비용 처리는 정책 문제이고, 예약 실행은 권한 문제다. 한 문장으로는 하나의 제품 같지만, 설계 관점에서는 서로 다른 책임을 가진 기능 덩어리들이다.
실무 문서에서도 이런 구조가 중요하게 다뤄진다. 예를 들어 요구사항 수집을 돕는 에이전트를 설계할 때는 목표, 비목표, 사용자 스토리, 성공 지표, 통합 대상, 보안 고려사항을 먼저 정리해야 한다는 식으로 제품 문서를 세운다.8 에이전트는 특히 "무엇을 하지 않을 것인가"까지 써두는 것이 중요하다. 비목표가 없는 에이전트는 자꾸 옆길로 샌다.
성공 기준은 "똑똑해 보임"이 아니다
에이전트는 데모에서 쉽게 사람을 설레게 한다. 그런데 설레는 시스템과 운영 가능한 시스템은 다르다. 설계자에게 필요한 질문은 "이 에이전트가 똑똑해 보이는가?"가 아니라 "어떤 상태를 성공이라고 부를 것인가?"다.6
이 성공 기준은 최소한 세 층으로 나누어 생각하는 편이 좋다.
결과 기준: 실제 목표를 달성했는가. 예를 들어 회의 일정을 잡는 에이전트라면 날짜, 시간, 참석자, 설명이 모두 맞아야 한다.
과정 기준: 올바른 도구를 올바른 방식으로 썼는가. 필요한 확인을 했는가. 불필요한 반복이나 루프에 빠지지 않았는가.
운영 기준: 응답 시간이 너무 길지 않은가. 비용이 과도하지 않은가. 실패했을 때 사용자에게 이해 가능한 방식으로 알리는가.67
이 구분이 중요한 이유는, 최종 답만 보면 가려지는 실패가 많기 때문이다. 우연히 정답을 맞혔지만 잘못된 도구를 썼을 수도 있고, 한 번 성공했지만 열 번 중 여섯 번은 실패할 수도 있다. 반대로 최종 결과는 아쉽더라도 어디에서 흔들렸는지 알 수 있으면 빠르게 개선할 수 있다. 에이전트 평가는 단순한 정답률보다 더 넓어야 한다는 말이 바로 여기서 나온다.7
실무적으로는 숫자로 써보는 것이 가장 좋다. 예를 들어 "초안 작성 만족도 향상" 대신 "첫 초안 채택률 60% 이상", "작업 완료율 85% 이상", "도구 호출 인자 오류 5% 이하", "P90 응답 시간 8초 이하", "위험 행동은 100% 승인 후 실행"처럼 적는다. 숫자가 들어가면 논쟁이 줄고, 개선 우선순위가 보인다.
재미있는 점은 좋은 성공 기준이 개발보다 먼저 온다는 것이다. 성공이 무엇인지 모른 채 만드는 에이전트는 방향 없이 달리는 러닝머신과 비슷하다. 열심히 움직이는데 앞으로 가지 못한다.
제품 관점이 빠지면 에이전트는 금방 불편해진다
초기 설계에서 가장 많이 놓치는 것이 제품 관점이다. 많은 팀이 에이전트를 "답변을 잘하는 모델"로만 생각한다. 하지만 사용자는 답변만 경험하지 않는다. 시작하는 순간, 기다리는 시간, 중간 상태, 검토 방식, 실패 이후의 복구까지 모두 제품 경험으로 느낀다.
예를 들어 요구사항 수집 에이전트를 만든다고 해보자. 이 에이전트의 가치는 단지 PRD 초안을 써주는 데 있지 않다. 기존 도구 안에서 시작할 수 있는지, 애매한 요구를 발견했을 때 누구에게 질문을 던지는지, 이해관계자 피드백을 어떻게 모으는지, 최신 문서를 어디서 볼 수 있는지, 변경 사실을 어떤 방식으로 알려주는지까지 포함해야 비로소 쓸모 있는 제품이 된다.8
즉, 에이전트의 UX는 채팅창 안에만 있지 않다. 오히려 다음과 같은 제품 질문이 더 중요할 때가 많다.
사용자는 어디서 에이전트를 호출하는가.
에이전트는 지금 무엇을 하고 있는지 보여주는가.
사용자는 중간 결과를 수정하거나 방향을 바꿀 수 있는가.
모호하거나 위험한 단계에서 사람 검토가 자연스럽게 붙는가.
실패했을 때 처음부터 다시 하지 않고 이어서 고칠 수 있는가.
이런 제품 관점이 빠지면 에이전트는 종종 "한 번은 신기한데 일상적으로는 불편한 기능"이 된다. 마치 말을 아주 잘하는 인턴인데, 진행 상황은 안 보이고, 중간 산출물도 안 남기고, 틀리면 처음부터 다시 시켜야 하는 느낌이다. 처음 며칠은 재밌지만 곧 피곤해진다.
좋은 에이전트 제품은 답을 던지는 대신 일의 흐름을 설계한다.
작게 실험하고, 빨리 비교하라
만드는 사람의 관점으로 전환했다면, 이제 중요한 것은 거대한 청사진보다 작은 실험이다. 에이전트는 종이 위에서만 보면 뭐든 그럴듯해 보인다. 그래서 실제 선택은 짧은 프로토타입으로 검증하는 편이 훨씬 낫다.2
실전에서는 보통 두 가지를 비교하면 충분하다. 첫째, 기성 SaaS 에이전트나 로우코드 도구로도 목적을 달성할 수 있는가. 둘째, 단일 에이전트면 충분한가, 아니면 정말 여러 전문 에이전트가 필요한가. Microsoft의 가이드도 이 두 질문을 먼저 검증하라고 권한다. 1~2주짜리 시간 제한 실험을 돌려 기능 적합성, 개발 속도, 통합 복잡도, 보안 충족 여부를 비교하는 방식이다.2
이 접근이 좋은 이유는 멋진 아키텍처를 향한 욕심을 눌러주기 때문이다. 처음부터 "우리도 오케스트레이터, 서브에이전트, 메모리 레이어, 평가 파이프라인까지 한 번에"라고 시작하면, 대개 학습비만 비싸진다. 반대로 작은 실험은 냉정하다. 정말 쓸모가 있는지, 누가 실제로 좋아하는지, 어디서 실패하는지가 빨리 보인다.
설계자의 자신감은 거대한 구조도에서 나오지 않는다. 작은 실험을 통해 문제와 해법이 맞는다는 증거를 모으는 것에서 나온다.
흔한 설계 실수
이 시점에서 자주 나오는 실수를 미리 보면 도움이 된다.
에이전트가 아니어도 될 문제를 에이전트로 푸는 것: 단순 규칙이나 파이프라인이면 충분한데, 자율성을 얹어 복잡도만 높인다.
목표는 있는데 비목표가 없는 것: 어디까지 할지보다 무엇을 하지 않을지가 더 중요할 때가 많다.
성공 기준 없이 데모 감각만 믿는 것: "잘 되는 것 같다"는 말은 운영에서 거의 도움이 되지 않는다.67
너무 이른 멀티에이전트화: 도구가 많고 문제가 커 보인다는 이유만으로 여러 에이전트를 도입하지만, 실제로는 조정 비용이 더 커진다.5
사람 개입 지점을 설계하지 않는 것: 모든 것을 자동화하려다 중요한 순간에 책임과 승인이 사라진다.
제품보다 기술을 먼저 고르는 것: 프레임워크와 모델 선택이 사용 경험보다 앞서면, 나중에 왜 아무도 안 쓰는지 이해하기 어려워진다.
이 실수들의 공통점은 하나다. 전부 "만들 수 있는가"에만 집중하고 "운영할 수 있는가"를 늦게 본다는 점이다. 에이전트는 만들기보다 굴리는 것이 더 어렵다.
한 가지 예시: 요구사항 수집 에이전트를 다시 설계해보기
이제 구체적인 예를 하나 보자. 누군가 이렇게 말한다고 해보자.
"회의 내용을 알아서 정리해서 PRD와 티켓까지 만들어주는 에이전트를 만들고 싶어요."
좋은 출발 같지만, 설계자 관점에서는 아직 너무 넓다. 여기서 먼저 바꿔야 할 것은 기능이 아니라 질문이다.
먼저 목표를 다시 쓴다. "프로젝트 초기에 흩어진 정보 때문에 생기는 누락과 모호성을 줄이고, 요구사항 문서 초안 작성 시간을 줄인다." 이렇게 바꾸면 왜 이 문제가 중요한지가 보인다. 다음으로 비목표를 쓴다. "사람의 초기 분석을 완전히 대체하지 않는다. 전체 프로젝트 관리 도구가 되지는 않는다." 이런 문장이 들어가면 시스템의 경계가 생긴다.8
그다음 성공 기준을 붙인다. 예를 들어 문서 초안 작성 시간 30% 단축, 요구사항 문서의 모호성 감소, 이해관계자 만족도 향상처럼 말이다.8 여기서 한 걸음 더 나아가면, 작업 완료율, 모호성 탐지 정확도, 재질문 성공률, 문서 반영 속도 같은 운영 지표도 붙일 수 있다.7
이제야 설계 선택이 가능해진다. 만약 일의 핵심이 문서 정리와 질문 생성 정도라면 단일 에이전트에 도구 몇 개를 붙인 구조로 시작할 수 있다. 그러나 기존 문서 분석, 코드베이스 확인, 이해관계자 인터뷰 정리, 피드백 통합이 서로 다른 전문성을 요구한다면 다중 역할 구조가 유리할 수 있다. 실제 연구와 사례에서도 제품 오너, 개발자, QA, 관리자처럼 서로 다른 관점을 가진 에이전트가 사용자 스토리 생성과 품질 점검, 우선순위화를 나눠 맡는 구조가 제시된다.89
중요한 점은 멀티에이전트가 멋져 보여서가 아니라, 책임 분리가 실제 가치로 이어질 때만 써야 한다는 것이다. 설계자는 구조를 사랑하면 안 되고, 문제에 맞는 구조를 선택해야 한다.
결국 설계는 자율성의 범위를 정하는 일
사용자에서 설계자로 넘어간다는 것은, 에이전트를 더 깊이 이해하게 된다는 뜻이기도 하지만 그보다 더 중요하게는 덜 환상적으로 보게 된다는 뜻이기도 하다. 에이전트는 만능 조수가 아니다. 잘 정의된 목표, 적절한 권한, 분명한 성공 기준, 좋은 제품 경험, 현실적인 운영 조건 안에서만 좋은 동료가 된다.
그래서 실패를 줄이는 가장 좋은 방법은 처음부터 "무엇을 만들까?"에 취하지 않는 것이다. 대신 이렇게 묻는 편이 낫다.
이 문제는 정말 에이전트가 필요한가. 성공은 무엇으로 측정할 것인가. 사람은 어디서 개입해야 하는가. 이 시스템은 결과만이 아니라 과정까지 믿을 수 있는가.
이 질문들에 답할 수 있다면, 그때부터는 비로소 설계가 시작된다. 그리고 그 설계 위에서야 모델, 프롬프트, 도구, 메모리 같은 핵심 부품도 제자리를 찾는다.
참고
1A practical guide to building agents - OpenAI
2Technology plan for AI agents
5Towards a science of scaling agent systems: When and why agent systems work
6Setting Goals and Success Criteria: How to Define What Success Means for Your AI Agent
7Agent Evaluation: How to Test and Measure Agentic AI Performance
8Requirements Gathering Automation with AI Agents
9AI based Multiagent Approach for Requirements Elicitation and Analysis
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.