AI 에이전트, 하나에 다 맡길까 여러 개로 나눌까: 1인 기업이 슬랙에서 AI와 일하는 방법

요즘 SNS에서 "1인 기업, 슬랙으로 AI 직원 100명을 채용했습니다." 같은 콘텐츠가 심심찮게 보인다. 그런 글을 보다 보면 자연스럽게 이런 질문이 생긴다. 범용 에이전트 하나로 다 처리하면 되지, 파트마다 담당 AI를 100개로 나눠 굴릴 필요가 있나..? 다 잘하는 슈퍼 에이전트 하나에게 다 요청하면 되지 않나 싶어진다.

이 글은 그 고민을 논리별로 하나씩 떼어서 정리한 글이다. 최대한 쉽게, 세부 개념까지 짚어 보려고 했다. 사실 내가 먼저 자세히, 쉽게 이해해 보고 싶어서 정리했다. 누군가에게도 도움이 되겠지 하는 마음으로..!

일단 기본 용어부터 정리하고 시작하자!

에이전트는 지침과 기억을 따로 갖고 일하는 AI 한 명이다. 챗봇 창 하나, 봇 하나, 딱 그 정도 느낌. 정해진 담당 없이 이것저것 다 받는 에이전트를 범용 에이전트라고 부른다. 블로그면 블로그, 광고면 광고처럼 한 가지 일만 맡는 에이전트를 특화 에이전트라고 부른다.

모델은 그 밑에 깔린 AI 두뇌 자체다. GPT(챗GPT 안의 두뇌), 제미나이, 클로드 같은 것. 에이전트가 직원이면 모델은 그 직원의 타고난 머리다. 에이전트가 둘이어도 같은 모델(두뇌)을 쓸 수 있다. 반대로 하나는 클로드 모델(클로드 두뇌), 하나는 제미나이 모델(제미나이 두뇌)일 수도 있다.

스킬은 특정 일을 하는 방법을 적어 둔 설명서다. 모델이 타고난 머리라면, 스킬은 그 머리에 쥐여 주는 업무 매뉴얼. "블로그 글은 이 순서로 쓴다", "광고 보고서는 이 표로 만든다" 같은 것이다. 에이전트는 자기한테 주어진 스킬을 꺼내 읽고 그대로 일한다. 모델은 내가 바꾸기 어렵지만, 스킬은 문서라서 언제든 고치거나 더할 수 있다. 같은 모델을 쓰는 에이전트 둘이 서로 다른 일을 하게 되는 건, 이 스킬과 지침이 다르기 때문이다.

에이전트 하나에 다 맡기는 함정, 스킬이 많다고 다 잘하는 건 아니다

AI 에이전트 하나가 모든 스킬을 다 갖고 있다고 해서, 모든 일을 잘하는 건 아니다.

AI는 일할 때 지침과 자료를 한 번에 머리에 펼쳐 놓고 보는데, 그 양이 정해져 있다. 필요하면 언제든 꺼내서 찾아볼 수 있는, 오래 남는 "기억"과는 다른 얘기다. 비유하자면 기억은 언제든 가서 꺼내 보는 서랍이다. 지금 보는 지침과 자료는 앉은 자리에서 한 번에 펼칠 수 있는 양이 정해진 책상이고.

그 책상에 블로그 규칙, 광고 규칙, 보고서 규칙, 고객 응대 규칙을 전부 상시로 올려 두고 쓰면, 지침끼리 서로 간섭하기 시작한다. 간섭은 "자주 쓰느냐"와 상관이 없다. 서로 부딪히는 규칙이 한 책상에 같이 있으면, 그 순간 생긴다. 블로그에서는 "쉽게 풀어 써"라고 했고 보고서에서는 "숫자만 짧게"라고 했다고 치자. 둘이 한 머리에 같이 들어가 있으면 블로그 글에 갑자기 숫자표가 끼고, 보고서는 수다스러워진다... 1년에 한 번 쓰는 규칙이라도 똑같다.

여기서 제일 강한 반론이 하나 나온다. 필요한 스킬만 그때그때 불러오게 하면 에이전트 하나에 다 맡겨도 규칙이 안 부딪힌다는 것. 맞는 말이다. 일할 때 그 일에 필요한 설명서만 책상에 올리고 나머지는 서랍에 두게 짜면, 일하는 중의 간섭은 많이 줄어들고, 요즘은 그렇게 짜는 게 보통이다. 그래도 남는 문제가 세 개 있다. 첫 번째는 고칠 때의 간섭. 공통 지침 한 줄을 고치면, 그 에이전트가 하는 모든 일에 영향이 간다. 두 번째는 무엇 덕분에 좋아졌는지 가려내기. 한 에이전트가 열 가지 일을 하면 이번 주 성과가 어느 수정 덕인지 섞여 버린다. 세 번째는 직무마다 다른 채점표. 한 명에게 채점표 열 장을 들려 주면, 결국 평균으로 자란다. 그러니까 특화의 이득은 "일을 시킬 때"보다 "키울 때" 크다. 아래 소제목들은 대부분 이 "키울 때" 얘기다.

특화 에이전트가 이기는 진짜 이유는 "전문가라서"가 아니다

보통은 "특화 에이전트가 그 분야 전문가니까 더 잘한다"라고 설명한다. 그것도 맞다. 하지만 앞 소제목 끝에서 짧게 말한 두 가지, 고칠 때 번지지 않는 것과 효과를 가려낼 수 있는 것이 사실 더 큰 이유다.

이 차이를 보려면 AI 에이전트의 "성장"이 뭔지부터 정해야 한다. 모델, 그러니까 타고난 머리 자체를 다시 학습시키는 길도 있긴 한데, 1인 사업자가 매주 할 일은 아니다. 우리가 하는 성장은 복잡한 프로그래밍이 아니라 문서 수정에 가깝다. 일하는 규칙인 지침을 손보고, 설명서인 스킬을 더해 주고, 서랍에 해당하는 기억에 남길 걸 넣어 두고, 무엇으로 채점할지를 바꾸는 일.

그렇게 보면 에이전트 하나에 다 맡겼을 때 무슨 일이 벌어지는지가 보인다. 블로그 글을 짧게 하려고 공통 지침의 "길이" 규칙을 고쳤다고 치자. 공통 지침은 그 에이전트가 하는 모든 일이 함께 읽는 지침이다. 그러면 광고 문구까지 짧아진다. 일할 때 필요한 설명서만 책상에 꺼내 쓰더라도, 공통 지침은 늘 책상 위에 있는 문서다. 그래서 한 줄을 고치면 모든 일로 번진다. 거기에 한 주 동안 광고 규칙과 공통 지침을 같이 고쳤다고 해 보자. 광고 성과가 좋아져도, 그게 광고 규칙 덕인지 공통 지침이 번진 덕인지 가려내기가 훨씬 어려워진다... 한 번에 하나씩만 고치면 되긴 한다. 그러면 고치는 속도가 확 느려지고...

사람 회사로 치면 이렇다. 사장이 "글 좀 짧게 써"라고 한마디 했다. 모든 일을 혼자 맡은 직원 한 명은 광고 문구도, 고객 답장도, 보고서도 다 짧게 써 버린다. 사장은 블로그만 말했는데! 여러 에이전트로 나눠 두면 이런 일이 구조적으로 안 생긴다. 블로그 담당에게 한 말은 블로그 담당만 듣기 때문이다. 전문가 간판 때문만이 아니라, 나눠 놓으니까 규칙이 저절로 지켜지는 것. 특화 에이전트가 좋은 진짜 이유...

여러 에이전트는 성장하는 방식이 직무마다 달라야 한다

이게 내가 제일 하고 싶은 말이다. 전문성마다 성장하는 방향이 달라야 하고, 성장하는 방식도 달라야 한다. 그런데 에이전트 하나가 모든 일을 맡으면, 성장하는 방식이 비슷하게 갈 확률이 높다. 한 머리가 모든 피드백을 받는다. 그러니 결국 "전반적으로 조금씩 나아지는" 한 가지 방식으로 모이기 쉽다.

사람 회사로 비유해 보면 이렇다. 영업 팀은 성사된 계약 수로 큰다. 디자인 팀은 고객이 고른 안의 비율로 크고, 회계 팀은 틀린 숫자가 몇 개였는지로 큰다. 같은 "성장"이라는 말을 써도 크는 길이 완전히 다르다. 그걸 한 사람에게 전부 시키면, 그 사람은 그냥 "열심히 하는 사람"으로 자란다. 어느 쪽으로도 뾰족해지지 않는다. 에이전트 하나에 다 맡기는 게 딱 이 그림이다.

여기에 조건이 하나 붙는다. 직무별로 여러 에이전트로 나눈다고, 자동으로 다르게 크는 건 아니다. 실제로 다르게 크려면 "무엇으로 채점하느냐"가 달라야 한다. 그 에이전트가 잘했는지를 재는 채점표 말이다. 예를 들어 블로그 담당은 조회수와 문의로 이어진 비율로 채점한다. 광고 담당은 문의 1건을 받는 데 든 비용으로. 보고서 담당은 같은 지적을 두 번 받는 비율로. 채점 기준이 같으면 나눠 놔도 결국 같은 방향으로 크니까, 특화 에이전트를 나눌 때는 채점표도 같이 따로 써야 한다.

여러 에이전트를 나누는 단위는 "직무"가 아니라 "결과물"이다

채점표를 따로 쓴다고 하면, 다음 질문은 어떤 단위로 나누느냐다. 많이들 "기획 봇, 작성 봇, SEO 봇, 발행 봇"처럼 공정별로 네 명을 만든다. 공장 라인처럼 글 한 편이 네 에이전트를 차례로 거치는 방식이다. (SEO는 검색에 잘 걸리게 글을 다듬는 일이다.) 이 방식에도 장점이 있다. 단계마다 검사를 둘 수 있고, 글이 망했을 때 어느 단계에서 틀렸는지 짚어낼 수 있다.

문제는 넘길 때마다 맥락이 샌다는 것. 기획 봇은 "이 글은 초보 사장님한테 겁 빼 주는 글"이라고 생각했는데, 작성 봇한테 넘어가면서 그 의도가 흐려지기 쉽다. SEO 봇은 키워드만 보고, 발행 봇은 형식만 본다. 그리고 책임자가 사라진다. 글이 망하면 누구 탓인지 넷이 서로 쳐다본다...

그래서 나는 책임을 결과물 단위로 한 명에게 지우고, 그 안에 단계별 검사를 둔다. "블로그 글 한 편"이 결과물이라고 하자. 그러면 블로그 담당 특화 에이전트 한 명이 기획, 작성, SEO, 발행을 전부 한다. 대신 그 한 명이 단계마다 체크리스트를 거친다. 기획이 끝나면 기획 검사(대상 독자를 적었는가 같은 항목). 본문이 끝나면 본문 검사를 하는 식. "광고 집행 한 주"가 결과물이면? 광고 담당 한 명이 소재부터 예산 조정까지 다 한다. 그러면 공정 분할의 장점, 어디서 틀렸는지 보이는 건 가져간다. 단점인 맥락이 새고 책임자가 없어지는 건 버릴 수 있고.

여기서 말하는 단계별 검사는 오탈자, 형식, 링크처럼 맞는지 틀리는지가 분명한 품질 확인이다. 이건 일하는 에이전트가 스스로 해도 된다. "이 에이전트가 정말 나아졌는가"를 판정하는 건 다른 얘기다. 그건 뒤에서 말할 바깥 감사자, 그러니까 그 일에 손대지 않은 다른 회사 모델이 한다.

특화 에이전트는 시험지가 있는 곳에서만 이긴다

그렇다고 모든 일을 특화 에이전트로 쪼개면 또 안 된다. 특화 에이전트는 "매주 일감이 있고, 채점표가 있는 일"에서만 이긴다. 매주 풀 문제와 채점 기준, 그러니까 시험지가 있어야 한다는 말이다.

이유는 단순하다. 자라려면 배울 거리가 있어야 한다. 블로그는 매주 두세 편 나가니까 매주 피드백이 쌓이고, 매주 지침이 조금씩 고쳐진다. 이건 자란다! 하지만 "1년에 두 번 하는 세금 신고 정리"를 특화 에이전트로 만들면, 1년에 두 번 배우는 것이다. 연습할 판이 1년에 두 번밖에 없으니 늘 수가 없다. 거의 안 자란다.

그래서 반은 맞는 말이다. 슬랙에 AI 직원 100명을 두는 게 의미 없다는 말. 100명이면 각자 배울 거리가 모자라서 거의 안 자란다. 매주 일이 있는 자리를 세어 보면 몇 개 안 된다. 가끔 하는 일은 범용 에이전트가 맡으면 된다. 범용은 어차피 넓게 아는 쪽으로 쓰는 것이다. 가끔 쓰는 지침은 스킬, 그러니까 설명서로 만들어서 범용에게 쥐여 주면 된다. 이때는 서로 부딪히는 규칙이 책상에 같이 올라가지 않게만 조심하면 되고.

물론 "채점표 두세 개 만들고 관리하는 게 1인 기업한테는 더 일 아닌가"라는 반론도 꽤 아프다. 그래서 특화 자리를 매주 일감이 있는 두세 개로 묶어 두는 것이다. 채점표 두세 장을 유지하는 건 할 만하다. 100장은 못 한다.

피드백은 내가 주고, 디벨롭은 특화 에이전트가 스스로 한다

여기서부터는 내가 특화 에이전트들을 이렇게 굴리고 있고, 앞으로도 이렇게 가려는 방식이다.

피드백은 내가 준다. "이 글은 너무 길어", "이 광고는 문의 단가가 비싸" 같은 말이다. 그러면 에이전트는 그걸 받아서 주기적으로 스스로 디벨롭한다. 디벨롭은 더 나아지게 다듬는 걸 말한다. 여기에는 순서가 있다. 먼저 자기 설명서인 스킬과 지침에 뭘 고칠지 안을 만들고, 기록을 남긴다. 같은 지적이 줄었는지는 에이전트가 아니라 내 지적 기록으로 센다. 줄어든 게 확인돼야 굳힌다. 시험 없이 바로 굳히는 건 없다. 사람 직원이 피드백을 받고 자기 노트에 적어서 다음엔 안 틀리는 것과 같은 그림이다.

그렇다고 "스스로 고친다"를 그냥 풀어 두면 안 된다. 여기 위험이 하나 있다. 에이전트가 지침을 계속 덧붙이면 얼마 안 가 지침이 뚱뚱해지고, 앞뒤가 안 맞는 조항이 쌓인다. 예전 지침과 새 지침이 싸운다. 그래서 나는 세 가지를 같이 걸어 두려고 한다.

1. 고친 내용은 버전으로 남긴다. 언제 뭘 왜 바꿨는지가 남아야 되돌릴 수 있다.
2. 바뀐 뒤에 효과를 잰다. 기준은 "같은 지적을 두 번 받는 비율"이다. 내가 남긴 지난달 지적 목록을 놓고, 이번 달 결과물에 같은 지적이 또 나왔는지 센다. 세는 건 내 기록이고, 가끔은 뒤에서 말할 바깥 감사자가 판정한다.
3. 효과가 없으면 되돌린다. 되돌려도 안 되면 성장 방식째 바꾼다. 그 얘기는 바로 다음에 한다.

고치고, 재고, 안 되면 되돌리는 것까지 한 세트로 묶은 "스스로 고친다". "마음대로 고친다"와는 거리가 먼 얘기.

같은 피드백이 계속 돌아오면 특화 에이전트의 성장 방식을 바꾼다

세 번째 장치, 되돌려도 안 될 때의 얘기다. 여러 번 반복해도 디벨롭이 안 되고 같은 피드백이 계속 돌아온다면, 나는 그 에이전트 탓을 하지 않는다. "성장하는 방식" 자체가 잘못됐다고 본다. 피드백을 받아서 자기 지침으로 옮겨 적는 순서, 그 구조가 틀렸다는 뜻이다.

에이전트가 자기 지침을 고치도록 짜 둔 "기본 지시" 자체가 잘못됐다고 치자. 그러면 그 에이전트한테 "고쳐"라고 백 번 해도 같은 식으로 고친다. 물론 모델, 그러니까 타고난 머리 자체의 한계일 수도 있다. 지시를 끝까지 못 따라가거나 긴 지침 중간을 흘리는 건 모델 탓인 경우가 있어서, 그건 먼저 걸러 본다. 그게 아니면 성장하는 방식 자체를 고친 새 에이전트로 교체한다. 내가 바깥에서 그 순서부터 다시 짜서 새로 들이는 것이다. 그러니 새로 오는 에이전트는 자라는 방식부터 바뀌어서 온다.

교체할 때 조심할 게 하나 있다. 이름만 바꾸고 똑같은 지침을 복사해 오면 안 된다. 그건 그냥 같은 애를 다시 부른 셈이다. 사람을 자르는 게 아니니까 감정적으로는 쉽다. 그래서 더더욱 "뭘 바꿨는지"를 적어 두고 교체해야 한다.

여러 에이전트 중 하나가 배운 걸 모두가 알 필요는 없다

여러 에이전트를 굴릴 때 흔히 하는 게 "공통 지침"을 하나 만들어 두고 뭐든 거기에 쌓는 것이다. 나는 반대다. 에이전트 하나가 배우면 모두가 알 필요는 없다. 앞에서 본 대로 공통 지침은 모든 에이전트가 같이 읽는 문서다. 거기에 쌓을수록 고칠 때 번지는 문제가 다시 생긴다. 진짜 회사처럼, 내가 "이건 전사 피드백이야"라고 명시한 것만 모두가 배운다. 예를 들어 "우리 글에는 고객 이름 절대 안 쓴다" 같은 것. 그 판단은 자동으로 맡기지 않고 내가 한다.

여러 에이전트에 남는 한계 두 가지, 다른 회사 모델이 바깥에서 감사한다

여기까지 하고 나서도 두 가지가 남는다.

하나는 100명이 결국 같은 두뇌라는 것. 직무별로 나눠 놔도 밑에 깔린 모델은 보통 하나라서, 약점도 똑같이 공유한다. 어떤 종류의 사실 오류에 약하다거나, 듣기 좋은 말로 맞춰 주는 버릇이 있다거나. 그런 게 100명에게 똑같이 있다.

또 하나는 "성장 방식을 고치는 쪽도 채점을 받아야 한다"는 것이다. 일한 사람이 스스로 채점하면 안 된다. 오탈자 같은 품질 확인은 스스로 해도 되지만, "나아졌는가"라는 성장 판정은 다른 문제다. 에이전트가 자기 지침을 고치고 "좋아졌다"고 하는 것. 내가 성장 방식을 새로 짜 놓고 "이번 애는 낫다"고 하는 것. 둘 다 결국 자기가 한 일을 자기가 채점하는 거다.

이 둘을 위해 내가 쓰는 방법은, 다른 회사의 다른 모델을 "바깥 감사자"로 두는 것이다. 나는 지금 제미나이 유료 버전을 쓰고 있는데, 이렇게 간헐적이고 외부 관점이 필요한 일에 그걸 쓴다.

첫 번째 한계는 이걸로 반만 풀린다. 다른 회사 모델도 비슷한 데이터로 비슷하게 배워서, 사실을 지어내거나 듣기 좋게 맞춰 주는 약점은 상당 부분 같이 갖고 있다. 다른 두뇌라고 약점이 자동으로 상쇄되는 건 아니다. 얻는 건 "일부 다른 시각" 정도. 우리 모델이 당연하게 넘긴 걸 저쪽이 걸어 주는 경우가 있는 정도다. 두 번째 한계는 제대로 풀린다! 일한 쪽도, 성장 방식을 짠 쪽도 아니니까 자기 작품을 자기가 편드는 일이 없어진다. 내가 감사자를 두는 진짜 이유는 이거다. 어느 정도 큰 회사가 1년에 한 번 바깥 회계사에게 감사를 받는 것과 같다. 회계사가 우리보다 똑똑해서가 아니라, 그 장부를 쓴 사람이 아니라서 믿는 거다.

감사자는 매일 쓰는 일꾼이 아니라 가끔 부르는 감사다. 두 모델을 둘 다 일꾼으로 쓰면 그냥 비용이 두 배가 되고, 둘이 쓴 글이 섞여서 더 헷갈린다. 그리고 조건이 하나 더 있다. 감사자에게도 취향을 묻지 않는다. "지난주 지적받은 오류가 이번 원고에 또 나왔는가"처럼 O/X로 확인되는 기준을 준다. 안 그러면 "나는 이게 좋은데" "나는 저게 좋은데" 하는 두 모델의 의견 싸움이 된다. 감사 모델에게도 긴 글을 좋게 보는 식의 자기 버릇이 있으니까.

그래서 내 답은, 슬랙에 범용 하나와 특화 두세 개다

범용 에이전트 하나에 특화 에이전트 여럿. 특화는 결과물 단위로 나누고, 매주 일감과 채점표가 있는 두세 자리에만 둔다. 그 안에 단계별 검사는 둔다. 피드백은 내가 준다. 에이전트는 받아서 스스로 디벨롭하되, 버전으로 남기고 효과를 잰다. 같은 피드백이 반복되면 성장 방식을 고친 새 에이전트로 교체한다. 배움은 기본적으로 각자 것이고, 내가 "전사 피드백"이라고 한 것만 모두가 배운다. 그리고 다른 회사 모델을 가끔 부르는 바깥 감사자로 둔다. 다른 시각도 조금 얻지만, 진짜 노리는 건 일한 쪽이 채점하지 않게 하는 것이다.

판단 기준은 "내 시간 1시간당 끝낸 결과물이 몇 개냐"다. 슬랙에 AI 직원이 100명인데 내가 하루 종일 그들 사이 중계만 하고 있다면, 그건 회사가 아니라 그냥 바쁜 상태다. 반대로 에이전트가 네 개인데 내가 판단만 하고 나머지는 알아서 끝나 있다면, 그게 회사다!

지금 슬랙에 붙여 둔 봇은 몇 개인가..? 그중에 매주 일감이 있고 채점표가 있는 봇은 몇 개인가.