코딩부터 지식 노동 에이전트까지 — Karan Vaidya, Composio

AAI Engineer
Computing/SoftwareInternet Technology

Transcript

00:00:00안녕하세요 여러분, 컴포시오의 공동 창립자이자 CTO인 카란 베디아입니다.
00:00:19오늘날 대부분의 에이전트 툴 호출은
00:00:21여전히 특정 분야에 집중되어 있습니다.
00:00:23굳이 말하지 않아도 다들 아시겠지만, 바로 소프트웨어 공학입니다.
00:00:26다른 모든 종류의 업무는 한참 뒤처져 있죠.
00:00:29인공지능 모델이 계속해서 좋아진다면,
00:00:32왜 우리는 여전히 코딩 에이전트에만 머물러 있을까요?
00:00:35이것이 바로 제가 이 자리에서 답하고자 하는 수조 원짜리 질문입니다.
00:00:433년 전만 해도 코딩 에이전트는 단순한 자동 완성에 불과했습니다.
00:00:47오늘날 소프트웨어 공학은 완전 자율화되었죠.
00:00:50우리는 탭 키를 연달아 누르던 시절에서 이제 클로드에게 맡기는 시대로 넘어왔습니다.
00:00:56정말 마법 같은 일입니다.
00:00:59그리고 왜 코딩 분야에서는 이런 변화가 그토록 빠르게 일어났을까요?
00:01:04대부분은 모델 덕분이라고 생각할 겁니다.
00:01:06맞습니다. 지난 2~3년 동안 모델 성능이 엄청나게 좋아졌고, 클로드 코드, 코덱스, 커서 같은 하니스도 발전했습니다.
00:01:13클로드 코드, 코덱스, 커서 같은 하니스도 발전했죠.
00:01:17하지만 그것들만으로는 충분하지 않았을 겁니다.
00:01:20이게 가능했던 이유는 코딩을 둘러싼 모든 인프라와 시스템이 문자 그대로 에이전트를 위해 만들어졌기 때문입니다.
00:01:26에이전트를 위해 만들어졌기 때문입니다.
00:01:27코딩에는 에이전트에 필요한 지원 체계가 이미 갖춰져 있었던 거죠.
00:01:31저장소, 커밋 이력, 테스트, CI/CD, 코드 리뷰, 린터, 그리고 문제가 생기면 되돌릴 수 있는 롤백 기능까지 있습니다.
00:01:39문제가 생기면 되돌릴 수 있는 기능 말입니다.
00:01:39결국 에이전트와 코드 주변 시스템을 신뢰하게 만드는 바로 그런 요소들입니다.
00:01:45이제 우리는 이렇게 훌륭한 에이전트들을 고객 지원, 재무, 영업 등 온갖 다른 분야로 확장하고 있습니다.
00:01:54하지만 코딩에서 엄청난 성과를 거두었던 에이전트들이 다른 분야에서는 맹구처럼 일하고 있습니다.
00:02:00코딩을 받쳐주던 인프라가 다른 분야에는 아예 존재하지 않기 때문입니다.
00:02:04그렇다면 코딩 에이전트와 지식 노동 에이전트 사이의 간극을 어떻게 메워야 할까요?
00:02:11우리는 핵심적인 6가지 프러미티브가 필요하다고 생각합니다. 코딩에는 이 6가지가 전부 있었지만, 지식 노동에는 단 하나도 없습니다.
00:02:19단 하나도 없습니다.
00:02:20그리고 그것이 바로 우리가 구축해야 할 대상입니다.
00:02:24첫 번째는 중앙화입니다.
00:02:26코딩 에이전트가 그토록 훌륭하게 작동했던 이유는 부분적으로 진실의 원천에 아주 가까이 있었기 때문입니다.
00:02:34무엇을, 왜, 그리고 어떻게 해야 하는지 알고 있었죠.
00:02:37저장소와 코드형 인프라를 제공하고, 피드백 루프를 닫아주면 모델이 알아서 능력을 발휘합니다.
00:02:43알아서 능력을 발휘하죠.
00:02:44에이전트는 코드베이스라는 단일한 장소에서 필요한 모든 것을 가진 채로 시작합니다.
00:02:51이것이 바로 오늘날 지식 노동에 턱없이 부족한 부분입니다.
00:02:55예를 들어, 하나의 거래 건이 5개의 서로 다른 플랫폼에 흩어져 있습니다.
00:03:00기록은 세일즈포스에, 문서는 노션에, 이메일은 지메일에, 대화는 슬랙에, 지원 내역은 젠데스크에 있죠.
00:03:05지원은 젠데스크에 분산되어 있습니다.
00:03:09모든 정보를 얻을 수 있는 단 하나의 진실의 원천이나 통합된 장소가 없습니다.
00:03:14코딩은 따로 분리되어 있지만, 각 앱마다 저마다의 로그인이 필요합니다.
00:03:18지식 노동 에이전트가 무언가를 시작하기도 전에, 직접 모든 실마리를 찾아 연결해야 합니다.
00:03:23직접 실마리를 모아 엮어야 하죠.
00:03:27하지만 이것은 코딩 에이전트가 처음 출발했던 기본 지점조차 되지 못합니다.
00:03:30코딩은 이미 모든 걸 다 갖추고 있었으니까요.
00:03:32그러니 어떻게 지식 노동 에이전트가 코딩 에이전트와 동일한 수준의 업무를 해내기를 기대할 수 있겠습니까?
00:03:39그래서 우리가 가장 먼저 구축하는 것은 빠져 있던 중심축입니다.
00:03:42모든 앱, 모든 연결, 모든 로그인이 존재하는 단 하나의 장소 말입니다.
00:03:46그래야 에이전트가 이들을 전부 꿰매는 고생을 할 필요가 없습니다.
00:03:51모든 것을 한곳에서 찾을 수 있게 되니까요.
00:03:55코딩 에이전트가 처음부터 가진 기준점을 그들도 얻게 됩니다. 즉 레포지토리와
00:03:59모든 스택에 걸친 정보가 한곳에 있는 거죠.
00:04:02그것이 바로 출발점이 되는 토대이며, 에이전트에게 적절한 쓰기 권한을 부여할 수 있습니다.
00:04:09에이전트에게 다음에 필요한 것은 역사에 대한 감각, 즉 과거를 되돌아볼 수 있는 능력입니다.
00:04:16코드에서는 이걸 공짜로 얻습니다.
00:04:18깃(Git)은 들어온 모든 내용과 이루어진 모든 변경 사항의 기록을 보관하니까요.
00:04:23따라서 에이전트는 언제든 과거를 돌아보며 특정 변경이 어떻게 이루어졌는지 확인할 수 있습니다.
00:04:27왜 무언가가 작동했는지, 왜 작동하지 않았는지 말이죠.
00:04:31우리가 실제로 에이전트에게 시키는 일의 종류를 한번 생각해 보세요.
00:04:34과거에 어떤 오류 때문에 변경 사항을 되돌려야 했는데, 그 작업이 꽤 까다로웠습니다.
00:04:40그걸 살펴보고 다시 복구해 줄 수 있나요?
00:04:43에이전트는 기록을 쭉 읽고 그것을 되살려 작업을 수행합니다.
00:04:46이 기록은 오직 에이전트만을 위한 것이 아닙니다.
00:04:49에이전트가 무엇을 하고 있는지 여러분이 기록을 관리하기 위한 것이기도 합니다.
00:04:53에이전트가 무엇을 하고 있는지, 어디서 삽질을 하고 있는지, 어디서 성공적인 결과를 내고 있는지 볼 수 있죠.
00:04:58에이전트의 말만 맹신하는 대신, 해당 앱들에 직접 들어가 그것이 무엇을 했는지 확인할 수 있습니다.
00:05:04무엇을 했는지 직접 볼 수 있죠.
00:05:09이제 지식 노동에 대해 똑같은 질문을 던져보세요.
00:05:12CRM이 지금과 같은 상태가 되도록 만든 원인은 무엇인가요?
00:05:16내 동료는 어떻게 계약 성사로 이어진 그 놀라운 메일을 작성했을까요?
00:05:22지원 문제를 에스컬레이션하거나 심지어 해결하는 실제 프로세스는 무엇인가요?
00:05:27그 답들은 수백 개의 앱에 산재해 있으며, 그중 어느 곳도 기록을 보관하지 않습니다.
00:05:31그래서 에이전트에게는 기억력이 없습니다.
00:05:33거의 매번 빈 상태에서 시작하죠.
00:05:36전에 무엇을 시도했고 무엇이 통했고 무엇이 안 통했는지 전혀 모릅니다.
00:05:40그리고 여러분 역시 살펴볼 수 있는 게 아무것도 없습니다.
00:05:44에이전트가 실행을 마치면 성공적으로 끝냈다고 말할 뿐입니다.
00:05:47실제로 성공적으로 해냈는지 알 수가 없죠.
00:05:49이게 맞는지 틀렸는지 알 방법이 없습니다.
00:05:52바로 그것, 즉 업무의 기록이 빠져 있는 것입니다.
00:05:56이제 모든 것이 단 한 곳을 통해 실행되기 때문에, 즉 중앙화가 이루어졌기 때문에
00:06:02그 위에 레이어, 즉 기록 레이어를 구축할 수 있습니다.
00:06:06에이전트가 취하는 모든 단일 행동은 다른 모든 앱에 걸쳐 로깅될 수 있습니다.
00:06:12어떤 것을 건드렸고, 어떤 것을 건너뛰었으며, 무엇이 통했고 무엇이 안 통했는지 말이죠.
00:06:17이를 통해 첫째, 에이전트는 기억력을 갖추게 됩니다.
00:06:20과거에 유사한 작업이 어떻게 처리되었는지, 무엇이 성공적이었는지 되돌아보고 다시 그대로 재현할 수 있습니다.
00:06:28매번 빈 상태로 시작하지 않는 것이죠.
00:06:31둘째, 신뢰를 얻게 됩니다.
00:06:33에이전트가 정확히 무엇을 하고 있는지 마침내 볼 수 있습니다.
00:06:36따라서 에이전트가 알아서 잘해주기를 바라기만 하는 대신, 직접 돌아보고 확인하며 잘못된 행동을 바로잡을 수 있습니다.
00:06:44에이전트가 올바른 일들을 점점 더 많이 하는 것을 목격함에 따라, 신뢰가 쌓이고 더 많은 업무를 오프로드하게 될 것입니다.
00:06:50에이전트에게 다음에 필요한 것은 컨텍스트입니다.
00:06:53생각해보면 컨텍스트에는 실제로 두 가지 종류가 있습니다.
00:06:57첫째는 플랫폼의 형태, 즉 아키텍처입니다.
00:07:01항목들이 서로 어떻게 유입되는지, 어떻게 묶여 있는지, 데이터 흐름은 어떠한지 말입니다.
00:07:05시니어 엔지니어가 머릿속에 품고 있고, 주니어 엔지니어는 개발하는 데 아마 3개월쯤 걸리는 지도 같은 것이죠.
00:07:12두 번째는 스타일입니다.
00:07:13이것은 무엇이 객관적으로 맞느냐의 문제가 아니라, 우리 회사에서 '잘된 것'이란 어떤 모습인가에 가깝습니다.
00:07:19업무를 처리하는 방식, 린터, 타입 체크 같은 것들 말입니다.
00:07:24어쩌면 다른 사람은 아무도 안 쓸 법한 타입스크립트 데코레이터를 여러분은 쓸 수도 있죠.
00:07:29이런 내용은 플레이북 같은 곳에 정확히 적혀 있지 않습니다.
00:07:32오히려 여러분의 코드베이스에 담겨 있죠.
00:07:34코드베이스 전체에 다 녹아 있습니다.
00:07:35따라서 에이전트는 직접 가서 살펴보고 사양, 여러분이 선호하는 방식, 린터, 포맷터 등을 파악할 수 있습니다.
00:07:45이제 지식 노동으로 넘어가 보죠, 똑같습니다.
00:07:48고객을 위한 문서를 작성하고 있다고 해봅시다.
00:07:50시작조차 하려면, 데이터베이스를 열어 사용량을 끌어오고, 실제로 어떻게 기능을 사용해 왔는지 사후적으로 확인해야 합니다.
00:07:58그리고 세일즈포스에서 거래 세부 정보를 살펴봐야 하죠.
00:08:01그래야 비로소 문서의 첫 줄이라도 쓰기 시작할 수 있습니다.
00:08:05그 해답은 그 도구들 중 단 한 곳에만 고립되어 있지 않습니다.
00:08:09내가 이 문서를 쓸 수 있는 이유는 내 머릿속에서 이 모든 도구들의 실마리를 하나의 컨텍스트로 엮어내고 있기 때문입니다.
00:08:15따라서 기록과 컨텍스트를 결합하는 것, 그것이 바로 조직이 일하는 방식을 매핑하는 방법입니다.
00:08:21그리고 그 부분은 에이전트가 쉽게 이용할 수 있는 형태로 존재하지 않죠.
00:08:26중앙화와 로깅을 수행하면서 우리가 방금 구축한 이 기록 레이어는, 에이전트에게 기억력을 부여하고 에이전트의 행동을 검증할 수 있게 해줄 뿐만 아니라
00:08:36또 하나의 흥미로운 일을 해냅니다.
00:08:38모든 에이전트가 하는 일을 충분히 로깅하면, 패턴이 보이기 시작합니다.
00:08:42조직이 어떻게 돌아가는지 보이기 시작하고, 조직이 일해 온 방식의 일종의 정수인 스킬을 형성하기 시작합니다.
00:08:51어떤 접근법이 통하고 어떤 것이 안 통하는지, 과거에 무엇이 실패로 이어졌는지 등이요.
00:08:57기록은 더 이상 단순히 무슨 일이 일어났는가에 대한 역사에 그치지 않습니다.
00:09:01우리 회사가 운영되는 방식을 보여주는 그림입니다.
00:09:03그리고 이것은 실제로 세 가지 서로 다른 수준에서 작동합니다.
00:09:06모든 사람에게 적용되는, 도구가 일반적으로 작동하는 방식.
00:09:09회사가 일을 처리하는 방식, 그리고 여러분이 선호하는 일 처리 방식 말이죠.
00:09:13여러분에게 '잘된 것'이란 어떤 모습인가 하는 점입니다.
00:09:15바로 그것이 지식 노동 에이전트에게 빠져 있던 컨텍스트였습니다.
00:09:19업무가 실제로 어떻게 완수되는가 하는 점이죠.
00:09:21일종의 실전 플레이북인 셈입니다.
00:09:23그리고 회사와 개별 사용자의 선호도이기도 합니다.
00:09:27이제 에이전트는 이를 조회할 수 있으며, 회사가 어떻게 운영되는지 더 이상 짐작할 필요가 없어집니다.
00:09:34코딩 에이전트가 그토록 잘 작동하는 또 다른 이유가 있습니다.
00:09:37스스로 테스트를 거치죠.
00:09:38작업을 검증합니다.
00:09:40검증 단계입니다.
00:09:41에이전트가 코드를 작성하는 순간, 일련의 검증 작업들이 뒤따릅니다.
00:09:44단위 테스트는 사소한 실수를 잡아낼 수 있죠.
00:09:47통합 테스트는 세 단계 떨어진 컴포넌트에만 영향을 미치는 문제를 잡아냅니다.
00:09:52조금이라도 잘못된 부분이 있다면 타입 시스템 자체가 작동하지 않고 실행되지 않을 것입니다.
00:09:57컴파일조차 되지 않죠.
00:10:00그 위에는 소프트웨어 검증 도구들이 자리 잡고 있습니다.
00:10:02린터, 포매터, bugbot.md, 리뷰 스킬 등이 있죠.
00:10:06이러한 도구들은 코드가 팀의 표준 및 선호하는 방식을 확실히 따르도록 보장합니다.
00:10:12사람 손을 거칠 필요도 없죠.
00:10:14에이전트가 스스로 루프를 완성하여 표준을 준수하고 코드가 실행되도록 만듭니다.
00:10:21자, 생각해 보세요. 예전에 제가 채용 아웃리치에 제 오픈 클로(open claw)를 적용해 본 적이 있습니다.
00:10:28후보자들에게 대량 이메일을 보내는 거였죠.
00:10:30실행되었습니다.
00:10:31엄청나게 많은 이메일을 보냈어요.
00:10:34여기 계신 분들 중에도 제 오픈 클로로부터 이메일을 받으신 분이 있을지도 모릅니다.
00:10:37정말 제가 시킨 그대로 정확히 수행했죠.
00:10:40그리고 동시에 대참사였습니다.
00:10:42제 이름이 박힌 채 트위터 박스에 오르내리는 그런 참사 말입니다.
00:10:46네, 아마 저기에 엿 먹으라는 식의 웹이 보일 겁니다.
00:10:51그 일이 일어났을 때 기분이 그리 좋진 않았죠.
00:10:54자, 여기서 핵심은 이겁니다.
00:10:55앞 슬라이드에서 언급한 모든 검증은 전부 통과했을 거라는 점입니다.
00:10:58이메일은 유효했어요.
00:11:00주소도 실제 주소였고요.
00:11:00실제로 글을 올린 실제 사람들에게 전달되었습니다.
00:11:04하지만 진정으로 중요한 게 무엇인지 질문을 던지는 테스트는 세상 어디에도 없었습니다.
00:11:10애초에 이 메일이 보내져야만 했던 것인가?
00:11:13그것이 바로 격차입니다.
00:11:14코드에서는 이러한 테스트들이 무엇이 옳고 그른지 알려주지만,
00:11:17여기서는 인터넷이 제가 틀렸다고 말해주었죠.
00:11:21그래서 우리는 누락된 검증 장치들을 구축합니다.
00:11:24위의 스레드에서 발생한 문제는 아웃리치 내용 자체가 틀렸다는 게 아니었습니다.
00:11:28제가 알기도 전에 발송되어 버렸다는 점이었죠.
00:11:31따라서 해결책은 간단합니다.
00:11:33실제가 되기 전에 미리 잡아내는 것입니다.
00:11:35이를 위해 우리는 두 가지 방법을 활용합니다.
00:11:37첫째, 에이전트가 무언가를 보내기 전에, 제가 이전에 보냈던 초안 이메일들과 비교하여 제 스타일에 맞는지, 제가 좋아하는 품질 기준을 충족하는지 확인합니다.
00:11:47둘째, 실제 환경에서 파괴적인 작업을 수행하기 전에 실제 도구를 모방하는 샌드박스를 제공하여 에이전트가 이 샌드박스 위에서 작업을 수행하도록 합니다.
00:11:59따라서 영향 반경이 현실 세계를 타격하는 대신 샌드박스를 거치게 되고, 에이전트가 실제 작업을 수행하기 전에 제가 검토할 수 있습니다.
00:12:07이 두 가지를 결합하면 지식 노동에는 결코 없었던 기능을 얻게 됩니다.
00:12:11현실화되기 전에 에이전트가 스스로 자신의 작업을 검토할 수 있는 방법 말입니다.
00:12:16마침내 사용자가 기다려주기를 멈추지 않고도 스스로 루프를 닫을 수 있게 되며, 이 모든 과정을 통해 제가 올리는 트윗 폭탄에 시달리지 않으면서도 에이전트의 행동을 신뢰할 수 있게 됩니다.
00:12:29다음으로 에이전트에게 필요한 것은 거버넌스입니다.
00:12:32신뢰를 구축한다는 것은 에이전트가 할 수 있는 일을 통제하고 에이전트 주위에 올바른 벽을 세우는 것입니다.
00:12:39코드의 경우, 이 문제는 대부분 해결되었으며 여러 계층으로 이루어져 있습니다.
00:12:44에이전트는 자신의 브랜치에서는 무엇이든 할 수 있지만, 메인 브랜치에는 병합할 수 없습니다.
00:12:49메인 병합 과정 사이에는 인간 리뷰어가 자리 잡고 있죠.
00:12:52중요한 파일에는 코드 소유자가 지정되어 있어, 에이전트가 그중 하나를 건드릴 때마다 적절한 사람들이 관여하게 됩니다.
00:12:58우리는 에이전트를 이용해 미리보기 배포에만 코드를 반영하고 프로덕션 배포에는 절대 손대지 못하게 함으로써 그곳을 통제합니다.
00:13:04거버넌스는 단일 게이트가 아니라 여러 개의 게이트로 이루어져 있으며, 각 게이트는 노출되는 영향 반경에 따라 다양한 크기를 가집니다.
00:13:12안전한 부분에서는 에이전트의 속도를 늦추지 않고, 단지 프로덕션을 망가뜨리는 것만 방지하죠.
00:13:19그리고 이러한 통제선이 엄격할수록 에이전트를 더 많이 신뢰하고 마음껏 일하게 둘 수 있습니다.
00:13:25이 사건 아마 다들 보셨을 겁니다.
00:13:27메타 슈퍼 인텔리전스 랩의 정렬(Alignment) 이사가 자신의 이메일에 에이전트를 연동했는데, 에이전트가 이메일을 대량으로 삭제하며 엉망으로 만들었죠.
00:13:36그녀가 멈추라고 말했음에도 계속 진행되었고, 결국 물리적 머신으로 달려가서 멈춰야 했지만 이미 200개의 이메일이 사라진 뒤였습니다.
00:13:45그녀는 사전에 프롬프트로 그러한 경우에는 반드시 확인하라고 지시했지만, 그것은 단지 프롬프트였을 뿐이며 문맥이 길어지면서 압축되어 날아가 버렸을 겁니다.
00:13:53오직 AI 정렬만이 유일한 업무인 사람조차 에이전트에게 올바른 프롬프트를 작성하지 못한다면, 우리 중 그 누구도 해내지 못할 것입니다.
00:14:03이것이 바로 이러한 에이전트를 신뢰하기 어려운 진짜 이유입니다. 코딩 에이전트보다 못해서가 아니라, 주변에 벽이 없기 때문입니다.
00:14:12코드의 경우, 우리가 앞서 개발하는 동안 이미 시스템 내부에 벽이 구축되어 있었습니다.
00:14:17지식 노동에도 여기저기 조각들이 존재하긴 합니다.
00:14:20예를 들어, 지메일에는 권한 범위(scope)가 있죠.
00:14:21세일즈포스에는 권한 레벨이 있습니다.
00:14:23하지만 너무 이리저리 흩어져 있어서 진정한 통제를 갖추기가 매우 어렵고, 대다수는 프롬프트를 통해 이를 해결하곤 합니다.
00:14:32그리고 프롬프트는 취약합니다.
00:14:34에이전트는 그 허점을 찾아낼 것입니다.
00:14:36내용들은 압축되어 사라지겠죠.
00:14:38그리고 규모가 커지면 이러한 울타리 중 하나가 무너지고, 여러분 역시 중요한 이메일 200개가 사라지는 똑같은 상황에 처하게 될 겁니다.
00:14:47그렇다면 무엇이 진정으로 이를 막을 수 있을까요? 더 나은 지시사항이 아니라, 에이전트가 그 벽의 존재를 잊어버리더라도 절대 넘을 수 없는 벽이 필요합니다.
00:15:00그래서 우리는 두 개의 계층으로 이러한 벽을 구축합니다.
00:15:03첫 번째 계층은 에이전트가 무엇에 도달할 수 있는지, 무엇에 접근할 수 있는지에 대한 결정론적 통제입니다.
00:15:09채용 에이전트는 아마 이메일을 읽기만 할 수 있을 것입니다.
00:15:13지원 에이전트는 이메일 초안을 생성할 수는 있지만 실제로 보낼 수는 없습니다.
00:15:17경계는 이들 에이전트의 바깥쪽에 존재합니다.
00:15:19에이전트가 이에 대해 이의를 제기하거나, 잊어버리거나, 압축해 버릴 수 없죠.
00:15:24기존 지시사항이 실패했던 이유는 그것이 프롬프트 내 에이전트의 메모리에 살고 있었기 때문입니다.
00:15:28이 방식은 그렇지 않습니다.
00:15:30하지만 접근 권한만으로는 그녀를 구하지 못했을 것입니다. 그녀가 실제로 이메일 에이전트를 만들고 있었기 때문이죠.
00:15:36따라서 그 이메일에 대한 접근 권한은 분명히 필요했습니다.
00:15:39우리가 하는 또 다른 일은 정책을 제공하는 것입니다. 즉, 그러한 접근 권한을 가진 상태에서도 에이전트가 할 수 있는 일에 대해 자연어 정책을 정의할 수 있습니다.
00:15:49예를 들어 내 허락 없이 10개 이상의 이메일을 절대 삭제하지 말 것 같은 규칙들이죠.
00:15:53특정 도메인 외부로는 절대 이메일을 보내지 말 것.
00:15:56이러한 접근 권한이 주어진 상태에서도 행동을 제어하는 규칙들입니다.
00:16:00따라서 이 두 가지 요소 사이에서, 한 계층은 에이전트의 접근 범위를 통제하고 다른 계층은 그 접근 범위 내에서 할 수 있는 행동을 제어합니다.
00:16:09이 둘이 합쳐져 비로소 에이전트를 위한 진정한 거버넌스가 완성됩니다.
00:16:11에이전트에게 잘 행동해 달라고 애원하는 것이 아니라, 무엇을 할 수 있는지 강제하는 것이죠.
00:16:17마지막 기둥은 바로 가역성(reversibility)입니다.
00:16:20그리고 이것은 문제가 잘못되었을 때 도달하게 되는 지점입니다.
00:16:25내가 이걸 되돌릴 수 있는가?
00:16:27코드에서는 거의 항상 가능합니다.
00:16:30모든 변경 사항이 기록되니까요.
00:16:32이전 상태로 되돌릴 수 있습니다.
00:16:33마지막 커밋을 git revert하거나, 프로덕션을 고장 낸 커밋을 git bisect로 찾아내어 되돌릴 수 있죠.
00:16:41물론 이게 다 좋다는 뜻은 아닙니다.
00:16:44그렇다고 포장할 생각은 없습니다.
00:16:45프로덕션에 무언가가 들어가서 고장 난다면 언제나 최악이니까요.
00:16:48하지만 여전히 영구적인 것은 아닙니다.
00:16:50여전히 거기서 되돌아올 수 있죠.
00:16:51그리고 그것이 바로 에이전트가 마음껏 일하고 마법 같은 결과물을 만들도록 둘 수 있는 자신감을 줍니다.
00:16:57에이전트가 무언가를 망가뜨리더라도 되돌아갈 길이 있으니까요.
00:17:03반면 지식 노동에는 되돌리기 버튼이 없습니다.
00:17:05사용자의 받은편지함 같은 경우를 생각해 보세요.
00:17:07그 200개의 이메일은 사라졌습니다.
00:17:09흔적도 없이 소멸했죠.
00:17:10참고로 그게 평소의 일반적인 경우입니다.
00:17:12최악의 재난 케이스는 이미 발송되어 버린 이메일이며, 이는 되돌릴 수 없습니다.
00:17:15이미 송금되어 버린 자금이라 그 돈을 다시 찾아올 수도 없죠.
00:17:18삭제된 레코드는 영원히 사라집니다.
00:17:20사실 지식 노동에서의 대부분의 작업에는 되돌리기 버튼이 없습니다.
00:17:24그리고 그것이 모든 방정식을 바꿔놓죠.
00:17:27그것이 영향 반경을 변화시킵니다.
00:17:29코드의 경우, 일이 일어난 후에 에이전트를 신뢰할 수 있습니다.
00:17:31그냥 실행하게 두세요.
00:17:32결과를 확인합니다.
00:17:33틀렸다면 되돌리면 됩니다.
00:17:34여기서는 다시 돌아올 방법이 없습니다.
00:17:36여러분에게 남은 유일한 방법은 에이전트가 행동하기 전에 미리 신뢰하는 것뿐입니다.
00:17:40바로 이 점 때문에 코딩 에이전트에서는 결코 느낄 수 없었던 위험함이 지식 노동 에이전트에서 느껴지는 것입니다.
00:17:44에이전트가 자주 실패해서가 아닙니다.
00:17:46여기서는 실패가 영원히 지속되기 때문입니다.
00:17:49그러므로 애초에 완전히 사전 승인을 하거나 아예 행동하지 못하게 막아야 하죠.
00:17:55솔직히 말씀드리겠습니다.
00:17:56지식 노동에서 가역성을 재현하는 것은 가장 어려운 일입니다.
00:17:59코드에 존재하는 방식의 진정한 되돌리기는 지식 노동의 모든 시나리오에서는 아마 존재하지 않을 것입니다.
00:18:04하지만 되돌리기가 가능한 일부 시나리오들이 존재하며, 우리는 그것들을 활용합니다.
00:18:09가령 라벨을 추가했다고 해봅시다.
00:18:11나중에 그 라벨을 다시 제거할 수 있죠.
00:18:14하지만 받은편지함에서 이메일을 영구적으로 지워버리는 강제 삭제처럼 아예 되돌릴 수 없는 작업들의 경우,
00:18:21우리는 다시 한번 에이전트가 샌드박스 안에서 먼저 작업을 수행할 수 있는 환경을 제공하고
00:18:25사용자가 이를 검토한 뒤에야 실제 프로덕션 환경에 반영되도록 합니다.
00:18:30어떤 것도 현실 세계를 바로 건드리지 않죠.
00:18:31그게 바로 패러다임의 전환입니다.
00:18:32코드에서는 실수가 발생한 후에 그 실수를 되돌릴 수 있습니다.
00:18:35여기서는 실수가 일어나기 전에 미리 잡아냅니다.
00:18:37타이밍은 다르지만 결과는 같습니다.
00:18:39실수가 고착화되지 않죠.
00:18:41다시 그녀의 사례를 생각해 보죠.
00:18:42우리가 되돌릴 수 있는 작업들은 되돌리기 버튼을 제공할 것입니다.
00:18:45되돌릴 수 없는 작업의 경우, 에이전트가 먼저 샌드박스에서 작업을 수행하고
00:18:48그녀는 '1,200개의 이메일이 삭제될 예정입니다' 같은 알림을 받게 됩니다.
00:18:52정말 진행하시겠습니까?
00:18:54아직 실행된 게 아니죠.
00:18:57하지만 우리가 처리하는 수십억 건의 작업 속에서
00:19:00우리는 어떤 작업이 되돌릴 수 있고 어떤 작업이 되돌릴 수 없는지 그 과정에서 학습하며
00:19:04그에 맞춰 샌드박스를 준비하고 있습니다.
00:19:09오늘 딱 한 가지만 기억해야 한다면 이것만 가져가십시오.
00:19:11지난 2년 동안은 모델이 병목 현상(bottleneck)이었습니다.
00:19:14그래서 모두가 더 뛰어난 모델을 향해 경쟁했죠.
00:19:17이제 모델들은 소프트웨어 엔지니어링이 100% 자율적으로 이루어질 수 있을 만큼 충분히 발전했습니다.
00:19:23하지만 이제는 그 외의 모든 것들이 병목 현상이 되었습니다.
00:19:26코드를 작성하는 바로 그 모델이 채용, 영업 및 기타 지식 노동 업무도 수행할 수 있습니다.
00:19:36하지만 지금 당장 그것은 눈이 먼 상태로 일하고 있습니다.
00:19:39기록도, 맥락도, 검증할 방법도, 안전장치도, 되돌리기 기능도 없죠.
00:19:44그래서 병목 구간이 이동했습니다.
00:19:48이제 그것은 아무도 아직 구축하지 않은 인프라의 문제이며, 그것이 바로 우리 콤포시오(Composio)가 구축하고 있는 것입니다.
00:19:54네, 우리는 총 수십억 건의 도구 호출을 지원하고 있으며 매월 3억 건의 도구 호출이 이루어지고 있습니다.
00:20:02만약 여러분이 에이전트를 구축하고 있다면, 콤포시오를 연동해 지식 노동에서 마법이 일어나는 것을 직접 확인해 보십시오.
00:20:08그리고 AI 에이전트의 기반이 되는 미래를 함께 만들고 싶다면 제게 와주시기 바랍니다.
00:20:13우리는 확실히 채용 중이며, 앞으로 해야 할 일이 정말 많습니다.
00:20:17모델은 계속해서 더 좋아질 것입니다.
00:20:19병목 현상은 모델이 아닐 것입니다.
00:20:21바로 그 주변의 것들이 될 테니까요.
00:20:22감사합니다.

Key Takeaway

코딩 에이전트와 달리 지식 노동 에이전트는 중앙화, 기록, 컨텍스트, 검증, 거버넌스, 가역성이라는 6가지 인프라 프리미티브가 없어 병목 현상을 겪는다.

Highlights

  • 소프트웨어 공학 에이전트는 저장소, 테스트, CI/CD, 롤백 같은 인프라 덕분에 완전 자율화에 성공했다.

  • 지식 노동 분야에서는 세일즈포스, 노션, 지메일, 슬랙, 젠데스크 등 플랫폼 간 데이터가 파편화되어 진실의 원천이 부재하다.

  • 컴포시오는 매월 3억 건의 도구 호출을 지원하며 총 수십억 건의 호출을 처리하고 있다.

  • 메타 슈퍼 인텔리전스 랩의 정렬 이사가 에이전트 연동으로 이메일 200개를 대량 삭제하는 사고가 발생했다.

  • 지식 노동 에이전트의 위험성은 실패가 영원히 지속되며 되돌리기 버튼이 존재하지 않는다는 점에 있다.

  • 모델은 이미 충분히 발전했으며 현재 에이전트 확장의 주된 병목 현상은 주변 인프라의 부재이다.

Timeline

코딩 에이전트와 지식 노동 에이전트의 격차

  • 코딩 에이전트는 지난 2~3년 동안 모델 성능 향상과 전용 하니스 발전에 힘입어 완전 자율화되었다.
  • 코딩 분야의 성공은 모델 성능뿐만 아니라 저장소, 커밋 이력, 테스트, CI/CD, 롤백 같은 지원 체계가 구축되어 있었기 때문이다.
  • 동일한 에이전트를 고객 지원이나 재무, 영업 같은 지식 노동 분야에 적용하면 인프라 부재로 인해 정상적으로 작동하지 않는다.

소프트웨어 공학 분야는 에이전트가 신뢰하고 실행할 수 있는 시스템이 이미 마련되어 있었다. 반면 지식 노동 영역에는 그러한 토대가 전혀 존재하지 않으며, 이것이 두 분야 간의 거대한 간극을 만든다. 에이전트의 성능이 향상되었음에도 지식 노동에서 여전히 맹구처럼 작동하는 이유가 바로 여기에 있다.

첫 번째 프리미티브: 중앙화와 기록 레이어

  • 지식 노동 데이터는 세일즈포스, 노션, 지메일, 슬랙, 젠데스크 등 수많은 플랫폼에 분산되어 있다.
  • 모든 앱, 연결, 로그인을 통합하는 중앙화된 중심축이 있어야 에이전트가 실마리를 직접 엮는 고생을 피할 수 있다.
  • 깃(Git)처럼 모든 변경 사항을 기록하는 로깅 레이어가 결합되어야 에이전트가 기억력을 갖고 행동을 검증할 수 있다.

코딩 에이전트는 코드베이스라는 단일한 진실의 원천에서 출발한다. 지식 노동 에이전트 역시 모든 도구와 로그인이 모이는 중앙화된 토대와 과거의 변경 기록을 추적할 수 있는 기록 레이어가 필수적이다. 이를 통해 에이전트는 매번 빈 상태에서 시작하는 대신 과거의 성공 사례를 재현하고 신뢰를 쌓을 수 있다.

두 번째 프리미티브: 컨텍스트와 플레이북

  • 컨텍스트는 플랫폼의 아키텍처 형태와 회사별 업무 처리 방식이라는 두 가지 요소를 포함한다.
  • 코드베이스에는 린터, 포맷터, 선호하는 방식 등 회사의 표준이 자연스럽게 녹아들어 있다.
  • 지식 노동의 분산된 데이터 속에서 업무가 완수되는 실전 플레이북과 개별 사용자의 선호도를 에이전트에게 제공해야 한다.

시니어 엔지니어의 머릿속에 있는 시스템 지도와 회사 고유의 일 처리 방식은 코드베이스 전체에 담겨 있다. 지식 노동 에이전트 역시 단순한 데이터 접근을 넘어 회사가 일해 온 방식과 개별 사용자의 선호도를 반영하는 컨텍스트를 조회할 수 있어야 기업 운영 방식을 온전히 이해할 수 있다.

세 번째 프리미티브: 검증과 샌드박스

  • 소프트웨어 코드는 단위 테스트, 통합 테스트, 타입 시스템, 린터 등을 통해 스스로 검증 루프를 완성한다.
  • 채용 아웃리치에 에이전트를 무작정 적용했을 때 실제 메일은 유효했으나 대참사로 이어진 사례가 존재한다.
  • 실제 환경에 타격을 주기 전에 샌드박스 환경에서 에이전트의 작업을 수행하고 사용자가 검토할 수 있는 검증 장치가 필요하다.

코드 작성 과정에는 실수를 즉시 잡아내는 수많은 검증 도구가 존재한다. 하지만 지식 노동 영역에서는 발송된 이메일이나 삭제된 데이터가 올바른 판단을 거쳤는지 검증하는 시스템이 없다. 따라서 실제 도구를 모방하는 샌드박스와 초안 비교 방식을 결합하여 현실화되기 전에 실수를 미리 잡아내야 한다.

네 번째와 다섯 번째 프리미티브: 거버넌스와 가역성

  • 코드 영역은 브랜치 분리, 메인 병합 리뷰어, 코드 소유자 지정 등 다중 게이트로 거버넌스가 확립되어 있다.
  • 메타 슈퍼 인텔리전스 랩 사례처럼 프롬프트만으로는 에이전트의 대량 이메일 삭제 같은 파괴적 행동을 막을 수 없다.
  • 코드와 달리 지식 노동의 작업은 영구적이고 되돌릴 수 없는 경우가 많으므로 사전 샌드박스와 엄격한 접근 권한 제어가 필수적이다.

소프트웨어 공학은 깃 리버트(git revert) 등을 통해 실수가 발생한 후에도 되돌릴 수 있는 가역성이 보장되므로 에이전트를 마음껏 실행할 수 있다. 반면 지식 노동에서는 삭제된 이메일이나 송금된 자금을 되돌릴 수 없는 경우가 많다. 따라서 결정론적 접근 통제와 자연어 정책 제어를 결합한 거버넌스를 통해 애초에 위험한 행동을 차단해야 한다.

결론 및 병목 현상의 이동

  • 지난 2년 동안 AI 에이전트의 병목 현상은 더 뛰어난 성능을 내는 모델 그 자체였다.
  • 현재 모델들은 소프트웨어 공학을 100% 자율화할 만큼 충분히 발전했으며 병목은 주변 인프라로 이동했다.
  • 콤포시오는 매월 3억 건의 도구 호출을 지원하며 지식 노동 에이전트 인프라를 구축하고 있다.

모델 성능 경쟁의 시대를 지나 이제 진짜 과제는 에이전트 주변에 기록, 컨텍스트, 검증, 거버넌스, 가역성 인프라를 구축하는 것이다. 모델은 이미 준비되어 있으나 인프라가 없는 에이전트는 눈이 먼 상태로 일하는 것과 같다. 콤포시오는 이러한 인프라를 제공하여 지식 노동 영역에서도 에이전트의 마법이 일어나도록 지원한다.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video