다른 사람이 실제로 써야 에이전트도 제품이에요

AI를 쓰는 사람과 제품을 만드는 사람

AI에게 부탁해서 웹사이트를 만들거나, 필요한 정보를 찾거나, 문서를 정리하는 일은 흔해졌어요. 그런데 자신이 만든 에이전트나 스킬을 다른 사람에게 건네고, 그 사람이 실제 업무에서 계속 쓰게 만드는 사람은 아직 드물어요. 저는 이 차이에 주목하고 싶어요.

조슈아 밀러는 WIRED 인터뷰에서 기술업계 밖에서는 에이전트를 쓴다는 이야기를 듣기 어렵다고 말했어요. 그가 강조한 것은 소비자가 원하는 제품을 만들어야 한다는 점이었어요.

저는 밀러의 문제 제기를 이렇게 받아들였어요. 누군가 실제로 사용하기 전까지는, 기술이 작동한다는 것만으로 제품을 만들었다고 말하기 어려워요. AI로 무언가를 만들기 쉬워진 만큼, 만든 뒤에 누가 쓰는지까지 봐야 한다는 뜻이에요.

내가 쓰던 스킬을 동료에게 건네면

여기서 에이전트는 AI가 필요한 도구를 사용하며 여러 단계의 일을 수행하는 방식을 말해요. 스킬은 AI가 특정 업무를 할 때 참고할 절차와 자료를 묶어둔 것이고요. 대화창에서도 에이전트를 쓸 수 있어요. 화면의 모양보다 중요한 차이는, 내가 원하는 결과를 얻는 데서 그치는지 다른 사람도 그 기능을 쓸 수 있게 만드는지에 있어요.

회의록으로 주간 보고서를 작성하는 스킬을 만들었다고 해볼게요. 내가 쓸 때는 꽤 잘돼요. 어떤 회의록을 넣어야 하는지 알고, 팀에서 쓰는 약어도 이해하고, 결과가 이상하면 지시를 고칠 수 있으니까요. 빠진 내용은 직접 채우면 되고요.

그 스킬을 동료에게 건네면 그동안 내가 알아서 처리하던 부분이 드러나요. 동료는 어떤 파일을 넣어야 할지부터 모를 수 있어요. 다른 형식의 회의록을 넣었더니 보고서에서 필요한 항목이 빠질 수도 있고요. 그때마다 만든 사람에게 사용법을 물어봐야 한다면, 다음 주에도 이 스킬을 쓸 이유가 줄어들어요.

동료가 계속 쓰게 하려면 입력할 자료와 실행 방법이 분명해야 해요. 어떤 결과가 나오는지 미리 알 수 있어야 하고, 정보가 부족할 때는 부족하다고 알려줘야 해요. 결과를 수정하거나 다시 실행하는 방법도 필요해요. 만드는 사람이 옆에서 설명하며 시연할 때는 지나칠 수 있는 문제들이에요.

AI가 보고서를 한 번 만들어줬다는 사실만으로는 이런 조건을 확인할 수 없어요. 다른 사람이 자기 자료로 사용해보고, 다음 업무에서도 다시 찾는지까지 봐야 해요.

사용자가 할 일을 먼저 정해야 해요

“무엇이든 대신 해주는 에이전트”라는 설명을 들으면, 사용자는 자신이 무슨 일을 맡길 수 있을지부터 생각해야 해요. 반면 “매주 회의록을 넣으면 우리 팀 양식의 주간 보고서를 만든다”고 설명하면 언제 쓸 도구인지 알 수 있어요. 그 일을 자주 하는 사람에게 사용을 제안할 수도 있고요.

밀러가 소개한 Dia의 아침 브리핑도 이런 관점에서 볼 수 있어요. 사용자는 캘린더와 메일에서 정리한 오늘 할 일을 봐요. 그 뒤에 어떤 에이전트가 있는지 알 필요는 없고요.

물론 용도가 분명해도 실제 업무에 맞지 않으면 쓰지 않아요. 보고서 형식이 팀의 방식과 다르거나, 매번 입력 자료를 준비하는 데 시간이 오래 걸리면 사용이 끊길 수 있어요. 그래서 배포한 뒤에도 어디서 막히는지 보고 고쳐야 해요. 에이전트나 스킬을 개발하는 일에는 이 과정까지 포함돼야 한다고 봐요.

사용자가 많거나 유료여야만 한다는 뜻은 아니에요. 팀원 몇 명이 매주 쓰는 내부 도구나, 다른 사람이 자기 업무에 가져다 쓰는 무료 스킬도 실제 사용자를 가진 제품이 될 수 있어요. 설치 수나 공개했다는 사실만으로는 알 수 없는 부분이에요.

오스왈드의 시선

저는 이걸 GTM, 즉 제품을 고객에게 알리고 실제 사용으로 이어지게 만드는 전략의 문제로 봐요.

GTM 전략을 짜면서 반복해서 마주친 실패 패턴이 하나 있어요. 만드는 쪽에서 쓰는 기술 용어를 그대로 고객에게 내미는 거예요. 제품 설명에 내부 기술 용어를 쓰면, 고객이 그 기술을 먼저 이해해야 제품을 고를 수 있게 돼요.

“에이전트와 스킬을 개발했다”는 설명도 마찬가지예요. 개발한 사람에게는 어떤 기능을 구현했는지가 큰 성과일 수 있어요. 하지만 고객에게는 자기 일 중 무엇을 맡길 수 있고, 사용하면 무엇이 나아지는지가 먼저예요. 개발을 끝낸 뒤에도 사용자를 정하고, 그 사람의 업무에 맞추고, 계속 쓸 이유를 만드는 일이 남아 있어요.

제가 도입 검토를 도울 때 넣는 질문 중에는 “이 에이전트가 틀렸을 때, 누가 언제 알아채나요?”도 있어요.

이 질문 역시 실제로 사용할 수 있는지 확인하기 위한 것이에요. 결과를 사람이 검토하더라도 전체 작업 시간이 줄고 품질이 좋아진다면 쓸 이유가 있어요. 반대로 매번 오류를 고치느라 더 오래 걸린다면 사용자는 원래 하던 방식으로 돌아갈 수 있겠죠. 검토에 드는 시간까지 포함해서 어떤 도움이 되는지 봐야 해요.

그래서 저는 에이전트의 기능을 설명하는 것만으로 도입이 끝났다고 보지 않아요. 실제로 쓸 사람에게 전달하고, 그 사람의 업무에서 도움이 되는지 확인하는 데까지 가야 해요. AI와 대화해 내가 쓸 결과물을 얻는 경험만으로는 이 과정을 대신할 수 없어요.

마치며

AI 덕분에 무언가를 만들어볼 수 있는 사람은 늘었어요. 그중 일부는 자신이 반복해서 할 일을 에이전트나 스킬로 만들어요. 여기서 다른 사람도 쓸 수 있도록 다듬고, 실제 사용으로 이어지게 하는 단계가 남아 있어요.

이 글에서 말하는 격차는 그 단계에 있어요. 기술적으로 구현한 기능이 있는지와, 누군가 그 기능을 필요로 해서 사용하는지는 별도로 확인해야 해요. 저는 후자까지 해내는 것을 제품을 만드는 일이라고 생각해요.

💬 직접 만든 에이전트나 스킬을 다른 사람에게 건네본 적이 있나요? 그 사람이 계속 썼는지, 쓰다 말았다면 어디서 막혔는지 들려주세요.

---

📨 에이전트나 스킬을 만들어 다른 사람에게 제공하려는 분이 있다면 이 글을 전달해 주세요.

---

참고자료 & 더 읽기

• Why Normal People Aren’t Using AI Agents — WIRED: 밀러의 제품 관점을 설명한 인터뷰예요.
• Building effective agents — Anthropic: 에이전트의 작동 방식과 실제 업무에 적용할 때 고려할 점을 설명해요. 대화창도 에이전트의 사용 방식이 될 수 있어요.
• Agent Skills 공식 문서: 스킬에 들어가는 지침·자료·실행 파일과 에이전트가 이를 사용하는 방식을 설명해요.

필자 안광섭 (오스왈드)은 세종대학교 겸임교수, INLEVEL9 전략 컨설턴트입니다. 경력, 연구, 저서와 최신 활동은 저자 소개에서 계속 갱신합니다. 최근 소식 · 2026년 8월: 2026 세종도서 교양부문 우수도서 선정.