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감사합니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video