Transcript
00:00:00세 명의 AI 에이전트에게 동일한 레포를 주었더니, 그들이 함께 회사를 차렸습니다. 한 명은
00:00:06기능을 구현하려 했고, 한 명은 아키텍처를 재작성했으며, 한 명은 모든 티켓을 열고 처리했죠.
00:00:12체계가 없다면 모든 멀티 에이전트 설정은 서서히 혼란에 빠지고 막대한 비용을 발생시킵니다.
00:00:17이것은 페이퍼클립(Paperclip)이며, 그 문제를 해결하려 합니다. 명령 하나로 AI 에이전트를 위한
00:00:22조직도, 티켓, 예산, 감사 로그, 심지어 하트비트까지 포함된 로컬 컨트롤 플레인을 제공합니다.
00:00:27이미 GitHub에서 별 64,000개를 돌파했습니다.
00:00:30몇 분 만에 몇 명의 AI 에이전트로 우리만의 회사를 세워봅시다.
00:00:33자, 에이전트들의 특징은 이렇습니다. 단일 에이전트는 훌륭해 보이죠. 작업을 주면 코드를 작성합니다.
00:00:44잘했습니다. 그런데 두 번째 에이전트, 어쩌면 세 번째 에이전트까지 추가하면 어떻게 될까요?
00:00:51갑자기 그것은 그냥 '관리 업무'가 되어버립니다. 누가 작업을 소유하는가? 그것이 문제입니다.
00:00:57누가 목표를 기억하고 있으며, 에이전트가 잘못된 일을 시작할 때 누가 멈추게 할까요?
00:01:03그것이 페이퍼클립이 해결하려는 문제입니다. 가공되지 않은 에이전트가 혼자 일하는 것은 좋지 않습니다.
00:01:08유용하긴 하지만 조정하기가 어렵죠. 페이퍼클립은 그들을 팀으로, 여기서는 '회사'로 만듭니다.
00:01:13우리는 회사의 목표를 정의합니다. 조직도를 만들죠. CEO, CTO,
00:01:20두 명의 엔지니어, 그리고 리서치 에이전트가 있을 수 있습니다. 그 후 페이퍼클립은 티켓, 하트비트,
00:01:27예산, 승인, 추적성을 통해 작업을 조정합니다. 우리는 작업과 할당자, 실제
00:01:33지출 비용, 그리고 최종 목표와의 연결 여부를 확인할 수 있습니다. 덜 즉흥적인 오케스트레이션이죠?
00:01:39실제로 라이브로 확인해 봅시다. 워크플로우 속도를 높여주는 코딩 도구를 좋아하신다면
00:01:43꼭 구독해 주세요. 영상은 계속 올라옵니다. 자, 이제 이걸 보세요. 깨끗한 터미널에서
00:01:49NPX Paperclip AI onboard를 실행하겠습니다. 로컬 설정이 시작됩니다. 잠시 후,
00:01:56페이퍼클립 대시보드가 실행됩니다. 로컬 서비스와 Postgres, 그리고
00:02:03인증(Auth)이 함께 제공됩니다. 이것이 새 회사를 만들 수 있는 UI입니다. 저는
00:02:09새 회사를 만들고 'dev tools company'라고 부르겠습니다. 여러분이 만들려는 건 무엇이든 가능합니다.
00:02:14목표는 간단하게 설정하겠습니다. 이번 주 안에 URL 단축기 MVP를 구축하고 배포하는 것입니다.
00:02:20이제 CTO 에이전트를 추가할 수 있습니다. 그다음 어댑터를 통해 두 명의 엔지니어를 추가합니다.
00:02:28엔지니어 한 명은 백엔드를, 다른 한 명은 프런트엔드와 테스트 커버리지를 담당합니다. 자,
00:02:34시작하기 전에 예산을 설정하겠습니다. 이 부분이 정말 중요한데, 왜냐하면 목표는
00:02:39에이전트가 내 API를 마음대로 써서 요금 폭탄을 맞지 않게 하는 것이기 때문입니다. 바로 '제어된 자율성'이죠.
00:02:46또한 코드가 출력될 작업 디렉토리 경로도 설정해야 합니다. 여기서 설정해 주겠습니다.
00:02:50이제 하트비트를 누르고 시작할 수 있습니다. 보드를 한번 지켜보죠. 에이전트들이
00:02:57하트비트가 발생하면 에이전트들이 깨어납니다. CTO가 목표를 티켓 단위로 쪼개면, 여기 엔지니어들이 작업을 할당받죠.
00:03:05보시는 것처럼 위임, 티켓, 계보, 상태 변경, 예산 카운터 등이 모두 하나로
00:03:10연결되어 있습니다. 이제 첫 번째 구현 작업이 이미 코드 커밋을 향해 나아가고 있습니다.
00:03:15실행하는 데 꽤 시간이 걸렸지만, 이 모든 에이전트가 함께 작동한다는 점을
00:03:19생각하면 이해가 갑니다. 하지만 더 크게 확장하려 한다면 아주 빠른 편은 아니죠.
00:03:24이것은 더 이상 채팅창에 앉아 있는 에이전트 한 명이 아닙니다. 우리가 만든 CEO, CTO,
00:03:30엔지니어들로 구성되어 돌아가는 작은 회사입니다. 여기서 사람들이 혼란스러워하는 부분이 있습니다.
00:03:37언뜻 보면 페이퍼클립이 또 다른 에이전트 프레임워크나 CrewAI, AutoGen,
00:03:43LangGraph 스타일의 워크플로우처럼 들릴 수 있습니다. 하지만 그게 핵심이 아닙니다. 그런 도구들은
00:03:49워크플로우를 원할 때 좋죠. 예를 들어 조사자, 기획자, 작가,
00:03:55검토자 순으로 일하게 하는 것 말이죠. 물론 유용합니다. 하지만 페이퍼클립은 그보다 한 단계
00:04:01더 높은 곳을 지향합니다. 단순히 작업자들만이 아니라, 조직도 내에서 작업자들을 둘러싸고
00:04:07구축을 돕는 회사 그 자체입니다. 이렇게 생각해 보세요.
00:04:13단일 에이전트는 직원일 뿐이고, 워크플로우는 체크리스트와 같습니다. 페이퍼클립은 관리자이며,
00:04:20조직도, 티켓 보드, 예산 시스템, 감사 로그입니다. 관리자로서의 페이퍼클립이죠.
00:04:25이제 스스로 질문이 생길 겁니다. 에이전트가 코드를 쓸 수 있나? 네,
00:04:30이미 알고 있죠. 그것이 이 도구의 목적이니까요. 하지만 더 어려운 질문은 이것입니다.
00:04:36올바른 작업을 수행할 수 있는가? 멈춰야 할 때 멈출 수 있는가? 업무를 명확하게 인계할 수 있는가?
00:04:43여기서 무슨 일이 일어나고 있는지 검사할 수 있는가? 짧게 대답하자면, 네 가능합니다.
00:04:49페이퍼클립은 상태, 하트비트, 예산, 계층 구조, 로그를 제공합니다. 또한 이식 가능한
00:04:55템플릿과 채팅창보다는 Jira나 Linear 같은 느낌의 대시보드를 제공합니다.
00:05:02한 명의 에이전트에게 프롬프트를 주는 게 아니라 이 미니 조직을 제어하는 것이죠. 우리 중 대다수는
00:05:07여전히 터미널과 설정 사이를 오갑니다. Claude Code를 위한 터미널, Cursor를 위한 탭,
00:05:13리서치용 에이전트 하나, GitHub 이슈용 스크립트 하나까지, 온갖 창을 오가며 작업하죠.
00:05:18페이퍼클립은 그 모든 것에 공유된 운영 모델을 부여합니다. 이제 우리에게
00:05:24정신적 모델이 바뀝니다. “이 기능을 만들어 줘”라고 말하는 대신,
00:05:30실제로는 이렇게 말하게 됩니다. “이 회사의 목표는 이 제품을 배포하는 것이다.
00:05:35회사의 규칙은 이것이고, 조직도와 예산은 이렇다. 승인이 필요한 건 이것이다. 이제 시작하라.”
00:05:41솔직히 말씀드리면, 이런 구조는 정말 좋습니다. 티켓, 계보, 위임 같은 것들 말이죠.
00:05:46덕분에 멀티 에이전트 작업을 추론하기가 훨씬 쉬워집니다. 에이전트가 무언가 해냈을 때
00:05:52칭찬만 하는 게 아니라, 누가 그 작업을 할당했고 왜 존재하는지, 코드 어디에 맞는지 볼 수 있죠.
00:05:58예산을 설정할 수 있다는 것도 매우 큽니다. 많은 에이전트 도구는 비용을 나중에 확인하는
00:06:05것처럼 취급하죠. 하지만 페이퍼클립은 비용을 제어 루프의 일부로 만듭니다.
00:06:12실행 전에 예산을 설정합니다. 셀프 호스팅이 가능하고 오픈 소스라는 점도 큰 장점입니다.
00:06:17직접 실행하고, 검사하고, 수정하며 이미 사용 중인 에이전트와 연결할 수 있습니다.
00:06:22하지만 동시에, 페이퍼클립을 강력하게 만드는 이 구조가 짜증날 수도 있습니다.
00:06:27규칙이 엉망이면 에이전트들이 말도 안 되는 티켓들을 생성할 수 있습니다.
00:06:32저는 간단한 URL 단축기를 원했는데, CTO 에이전트가 제가 원치도 않는 전혀 다른 계획을 세울 수 있죠.
00:06:39토큰 소모도 무시할 수 없습니다. 그래서 예산을 두어 통제하는 것이지만,
00:06:45성의 없는 프롬프트나 모호한 규칙 정의까지 해결해 주지는 않습니다.
00:06:52그리고 여러분, 'skills.md' 파일이 부실하면 회사는 혼란에 빠진 스타트업처럼 돌아갑니다.
00:06:59따라서 'skills.md'가 탄탄해야 합니다. 마지막으로 솔직히 말씀드리면,
00:07:03단순한 스크립트를 짜는 거라면 이건 완전히 과합니다. 저는 그냥 테스트해 보고 싶었을 뿐이죠.
00:07:08이 프로젝트에는 필요 없었습니다. 에이전트 한 명이 파일을 요약하거나 버그를 수정하길 원한다면
00:07:13이 도구는 필요 없습니다. 이것은 훨씬 더 많은 에이전트들이 함께
00:07:18협업하도록 구축하기 위한 것입니다. 충분히 가치 있는 도구지만, 모든 상황에 맞는 건 아닙니다.
00:07:23이런 코딩 도구와 팁이 즐거우셨다면 꼭 구독해 주세요. 다음 영상에서 뵙겠습니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video