00:00:00[음악 재생]
00:00:02안녕하세요, 제 이름은 마리오입니다.
00:00:04저는 아놀드 슈워제네거의 고향에서 왔는데요,
00:00:06아마 아직 눈치채지 못하셨을 겁니다
00:00:09제 영어가 아주 훌륭하기 때문이죠.
00:00:12본론에 앞서 말씀드리고 싶은 게 있는데,
00:00:13오늘 하루 종일 네 살짜리 아이를 데리고
00:00:16런던 전역을 뛰어다녔습니다.
00:00:17공룡도 보고, 미라 구경에 난도스도 갔고,
00:00:24벌써 잊어버린 것들도 많네요.
00:00:26지금 정말, 정말 피곤합니다.
00:00:28혹시 제 말이 이해가 안 가신다면,
00:00:31그냥 손을 들고 "할아버지, 일어나세요"라고 해주세요.
00:00:36제가 여기 온 이유는 사실 다른 사람 때문입니다,
00:00:39오늘 이곳 콕니빌에 와 있는 분이죠.
00:00:40그를 '슈테터 파인버거'라고 부릅시다.
00:00:442025년 4월쯤이었던 것 같아요,
00:00:53그가 저와 아르민 로네샤에게 말했죠. 아르민은
00:00:58Flask와 Sentry로 유명한 친구인데, "이봐, 코딩 에이전트들 말이야,
00:01:02이제 진짜 제대로 작동하더라고"라고요.
00:01:04전 "아, 헛소리 좀 하지 마"라고 했죠.
00:01:06죄송합니다, 비속어를 좀 섞어서 썼네요.
00:01:09전혀 그럴 리 없다고 생각했죠.
00:01:10그런데 한 달 뒤, 저희는 아파트에 모여 24시간 동안
00:01:13밤을 새우며 '클랭커(clankers)'와 '바이브 코드',
00:01:19그리고 '바이브 슬롭'에 푹 빠져버렸습니다.
00:01:21그 이후로 저희 중 누구도
00:01:23거의 잠을 자지 못하고 있습니다.
00:01:27우리는 엄청나게 많은 것들을 만들었지만,
00:01:32대부분은 실제로 쓰지도 않았습니다. 그게 2025년과
00:01:3626년의 새로운 트렌드니까요.
00:01:37우리는 정말 많이 만들지만, 정작 우리가
00:01:39실제로 사용하는 건 별로 없습니다.
00:01:40정말 많은 것들을 써 내려갔죠.
00:01:42결국 저는 이런 생각을 하게 됐습니다.
00:01:46"난 기존의 코딩 에이전트나 하네스들이 다 마음에 안 들어.
00:01:50직접 만드는 게 얼마나 어렵겠어?"
00:01:53피터는 "난 그냥 무언가를 만들고 싶어.
00:01:56아무도 모를 수도 있겠지만,
00:01:58개인 비서 같은 걸 만들 거야,
00:02:01내가 항상 갖고 싶었던 거니까"라고 했죠.
00:02:03그의 이야기가 어떻게 됐는지는 다들 아실 겁니다.
00:02:05그래서 오늘은 훨씬 덜 인상적인 제 이야기를 들려드리려 합니다.
00:02:08하지만 업계에서 말하는 몇 가지 배운 점들을
00:02:11전달해 드리고 싶습니다. 지난 몇 달 동안
00:02:16제가 수집할 수 있었던 것들이죠.
00:02:17자, 파이(Pi)입니다.
00:02:19태초에 클라우드 코드(Cloud Code)가 있었습니다.
00:02:21사실 처음에는 ChatGPT에서 복사해서 붙여넣기였죠.
00:02:252023년 초반엔 우리 모두가 그랬습니다.
00:02:27그다음엔... 오리지널 깃허브 코파일럿을 기억하시나요?
00:02:32네, 실제로 여기 엔지니어분이 얼마나 계시죠?
00:02:35커서(Cursor)나 클라우드 코드 같은
00:02:37오픈--
00:02:39[들리지 않음]
00:02:40네.
00:02:43Codex CLI?
00:02:45커서?
00:02:48오픈...
00:02:48[들리지 않음]
00:02:49네.
00:02:50오픈 코드?
00:02:50안티 그래비티(Anti-gravity).
00:02:51오, 많지 않네요.
00:02:52이거 쓰시는 분 계신가요?
00:02:55마음에 드네요.
00:02:56나중에 맥주나 한잔하죠.
00:02:58어쨌든, 이것이 기본적으로 2025년과
00:03:03그 이전에 일어났던 일들입니다.
00:03:04ChatGPT에서 복사해서 붙여넣기로 시작했죠.
00:03:06대부분 고장 나 있었고,
00:03:07쓰기 귀찮은 단일 함수들이 대부분이었습니다.
00:03:10그다음 VS Code 안에 깃허브 코파일럿이 들어왔고,
00:03:13그저 탭, 탭, 탭만 누르면 행복해졌죠.
00:03:15가끔은 됐지만, 대부분은 안 됐습니다.
00:03:17가끔은 GPL 코드를 그대로 읊어주기도 했는데,
00:03:22존 카맥의 '빠른 역제곱근' 같은
00:03:25코드들 말이죠. 아주 재미있었습니다.
00:03:29그리고 에이더(Aider)가 있었습니다.
00:03:30에이더 기억하시는 분 계신가요?
00:03:31네.
00:03:32나이가 좀 있으시군요.
00:03:33반갑습니다.
00:03:33네.
00:03:37흰머리가 있으신 걸 보니
00:03:37당연히 에이더를 아시겠군요.
00:03:41AutoGPT도 있었죠.
00:03:43아마 많이는 모르실 텐데.
00:03:44네, 알겠습니다.
00:03:45저분은 다 아시네요.
00:03:48네, 2025년 2월이나 3월쯤이었을 거예요.
00:03:51제 기억으론 11월에 출시됐는데,
00:03:52정확히는 2024년에 베타로 나왔죠.
00:03:55하지만 실제로 널리 쓰이기 시작한 건, 다시 말씀해 주시겠어요?
00:03:592월부터라고요.
00:04:01네, 2025년 2월이나 3월쯤이었죠.
00:04:03전 그걸 보고 "너무 좋다, 환상적이다"라고 생각했습니다.
00:04:05정말 멋졌죠.
00:04:06클라우드 팀도 정말 훌륭했습니다.
00:04:07소셜 미디어에서도 활동적이고,
00:04:08다들 아주 좋은 분들이고 재능 있는 분들이었죠.
00:04:13그들이 기본적으로 전체 장르를 만들어냈습니다.
00:04:15에이더나 AutoGPT 같은 전구체들이 있었지만,
00:04:18아무도 이 정도는 아니었습니다.
00:04:20이것은 기본적으로 '에이전틱 검색'에 관한 것이었습니다.
00:04:22커서가 코드베이스를 파고들어
00:04:25AST를 구성하고 인덱싱하는 방식 대신,
00:04:29가끔은 그게 잘 안 되기도 하는데,
00:04:31그들은 그냥 이렇게 말했습니다.
00:04:33"우리는 강화 학습을 통해 모델이
00:04:35파일 도구와 배시(bash) 도구를 사용하도록 학습시켰습니다."
00:04:37즉석에서 코드베이스를 탐색하고 코드를 이해하는 데
00:04:41필요한 부분을 찾아낸 다음 코드를 수정하는 방식이죠.
00:04:44이게 너무 잘 작동해서, 맞아요,
00:04:46우리는 잠을 자지 않게 되었습니다. 갑자기
00:04:48손으로 쓸 때보다 훨씬 더 많은 코드를 생성할 수 있게 됐으니까요.
00:04:52그 당시에는 단순하고 예측 가능했으며
00:04:54제 워크플로우에도 완벽하게 맞았습니다.
00:04:57괜찮았죠.
00:04:58하지만 그들은 우리 대부분이
00:05:05빠지게 되는 함정에 빠지고 말았습니다.
00:05:06클랭커들이 코드를 아주 많이 쓸 수 있으니,
00:05:08상상할 수 있는 모든 기능을 그냥 다 쓰게 하면 어떨까? 하는 거죠.
00:05:11그거 정말 좋지 않나요?
00:05:11이 기능도 추가하고, 저 기능도 넣고,
00:05:12이것도 넣고, 저것도 넣고.
00:05:14그러다 보면 결국 호머 심슨의...
00:05:15이걸 뭐라고 부르는지 모르겠네요.
00:05:18전 우주선이라고 부릅니다.
00:05:20클라우드 코드는 이제 우주선이 되었습니다.
00:05:21기능이 너무 많아서 실제로 사용하는 건
00:05:23제공하는 기능의 5% 정도일 겁니다.
00:05:26전체 기능의 10% 정도만 알고 계실 거고요.
00:05:28나머지 90%는
00:05:30AI와 에이전트의 '암흑 물질' 같은 겁니다.
00:05:33그게 실제로 뭘 하는지 아무도 모르죠.
00:05:36저는 개인적으로 이게 별로 도움이 안 된다고 생각합니다.
00:05:37왜냐하면 에이전트가 무엇을 하고 있는지
00:05:40어느 정도는 알아야 한다고 생각하기 때문입니다.
00:05:43이분은 어느 정도 동의하지 않으실 수도 있겠네요.
00:05:45우리는 지금 TESOL에 와 있고, 그들도
00:05:49컨텍스트 관리나 컨텍스트 엔지니어링을
00:05:51좋아하니까요.
00:05:54결국 저는 클라우드 코드가
00:05:55설명할 수 없는 엄청난 깜빡임 현상 같은 것 말이죠.
00:05:58사실 저는 왜 이런 일이 발생하는지 설명할 수 있고 이유도 알지만,
00:06:01그들은 여전히 고치지 않고 있습니다.
00:06:04여기 타릭이 있네요.
00:06:06그는 정말 훌륭한 친구죠.
00:06:09사실 전 왜 그런지 설명할 수 있고 이유도 알지만,
00:06:10그들은 여전히 고치지 않았습니다.
00:06:13여기 타리크(Tarik)가 있네요.
00:06:15그는 정말 훌륭한 사람입니다. 좋아해요.
00:06:16주로 트위터에서 활동하는 DevRel 담당자인데 정말 대단하죠.
00:06:16하지만 가끔 의문스러운 말을 하기도 합니다.
00:06:17"우리 터미널 UI는 이제 게임 엔진입니다" 같은 말이죠.
00:06:21자, 아시겠지만 전 게임 개발 배경이 있습니다.
00:06:24그게 제 본업이었죠.
00:06:27그런데 이런 글을 읽으면,
00:06:30조금 마음이 아픕니다.
00:06:31그건 그냥 터미널 UI일 뿐이니까요.
00:06:32게임 엔진이 아닙니다.
00:06:34제 말을 믿으세요.
00:06:37그게 게임 엔진이라고 생각하는 유일한 이유는
00:06:38터미널 인터페이스에 리액트(React)를 쓰고 있고,
00:06:39전체 UI 그래프를 다시 배치하는 데
00:06:4112밀리초 정도 걸리기 때문이겠죠.
00:06:44그냥 그러지 마세요.
00:06:45그건 게임 엔진이 아니에요, 아시겠죠?
00:06:49고스티(Ghosty)를 만들고 있는 미첼은
00:06:51"이봐, 그건 좀 무례한데"라고 했죠.
00:06:54고스티나 다른 터미널 탓을 하지 마세요.
00:06:56당신들 코드가 쓰레기인 겁니다.
00:06:59터미널은 초당 수백 프레임으로,
00:07:02프레임당 밀리초 미만으로 렌더링할 수 있습니다.
00:07:04그러니 그러지 마세요, 그렇죠?
00:07:05결국 그들은 깜빡임을 고치긴 했습니다.
00:07:09하지만 그러고 나니 다른 일이 터졌죠.
00:07:12그들은 완전히 바이브 코딩에 굴복한 것 같았습니다.
00:07:15클라우드 코드를 쓸 때마다 매일 그걸 느낄 수 있습니다.
00:07:16다시 말씀드리지만, 그들의 노력과
00:07:20개인적으로 저는 그저 나이가 좀 있고
00:07:23예측 가능하고 단순한 도구를 좋아하는 사람일 뿐입니다.
00:07:27그래서 이건 더 이상 제 워크플로우와 필요에 맞지 않았죠.
00:07:28네, 그렇습니다.
00:07:30또한, 그들은 백그라운드에서 많은 일을 하며
00:07:32사용자의 컨텍스트를 조작합니다.
00:07:34저는 2025년 여름에 몇 가지 도구를 만들었는데,
00:07:37Cloud Code에서 백엔드로 보내는
00:07:41요청을 가로채서
00:07:42어떤 종류의 소소한 추가 텍스트가
00:07:44사용자 몰래 컨텍스트에 주입되는지 확인하기 위해서였죠.
00:07:46그 모든 것들이 매우 해로웠고
00:07:50또한 항상 변했습니다.
00:07:52거의 매일 또는 이틀마다 말이죠.
00:07:55그 모든 것들은 매우 해로웠고
00:07:58항상 바뀌었습니다.
00:08:00매일 혹은 이틀마다 새로운 릴리스가 나왔고
00:08:01어느 시점에 무엇이 주입되는지가 바뀌어서,
00:08:04기존 워크플로우를 엉망으로 만들었죠.
00:08:06어떤 내용이 삽입되는지가 바뀌는
00:08:08새로운 릴리스가 나왔고, 이는 기본적으로
00:08:11기존 워크플로를 망가뜨리곤 했습니다.
00:08:13전혀 안정적인 도구가 아니었죠.
00:08:14이제는 그들의 입장도 이해가 갑니다.
00:08:16그들은 실험을 해야 하니까요.
00:08:17게다가 사용자 기반도 엄청나게 큽니다.
00:08:18사용자 기반이 그렇게 크면
00:08:19실험하기가 정말 어렵습니다.
00:08:21하지만 그들은 상관하지 않았고,
00:08:23우리 모두가 고통을 겪어야 했습니다.
00:08:25이 새로운 도구를 사용하면서
00:08:27예측 가능한 워크플로를 만들려고 노력하는데,
00:08:31도구 업체가 보이지 않는 곳에서
00:08:35아주 사소한 것을 바꾸면 LLM이
00:08:36기존 워크플로에서 오작동을 일으킵니다.
00:08:38이건 지속 가능하지 않습니다.
00:08:39저는 그 부분에 대한 제어권이 필요합니다.
00:08:40그들이 안정적인 무언가를 제공할 거라 믿을 수 없죠.
00:08:46그래서 UI 디자인의 결과로,
00:08:52가시성을 줄여야 한다고 생각하는 것 같습니다.
00:08:54개인적으로 저는 그걸 별로 좋아하지 않습니다.
00:08:56하지만 그건 개인적인 취향일 뿐이죠.
00:08:57대부분의 사람들은 Cloud Code가
00:08:58제공하는 정보의 양에
00:09:00만족할 것이라는 점을 이해합니다.
00:09:03모델 선택지는 당연히 전혀 없습니다.
00:09:06말하자면 Anthropic의 네이티브 도구이니까요.
00:09:09그게 단점은 아닙니다. Claude 모델은—
00:09:12저는 좋아하거든요.
00:09:13정말 훌륭합니다.
00:09:15그리고 확장성도 거의 제로에 가깝습니다.
00:09:17웃기게 들릴 수도 있겠네요, 그들에게는
00:09:19이런 전체적인 훅 시스템 같은 게 있으니까요.
00:09:21하지만 Pi가 허용하는 것과 비교하면
00:09:25그렇게 깊게 통합되어 있지 않습니다.
00:09:28또한 기본적으로 훅 이벤트가 시작될 때
00:09:32프로세스를 실행하는 방식인데, 이는
00:09:36프로세스를 반복해서 시작해야 하므로 비용이 많이 듭니다.
00:09:40그래서 결국 Cloud Code에 흥미를 잃었습니다.
00:09:42그게 끔찍해서가 아니라,
00:09:44단지 저에게 맞지 않게 되었을 뿐입니다.
00:09:47그 기간 동안 훨씬 더 많은 사람에게는 잘 맞게 되었죠.
00:09:50분명 그들은 잘하고 있지만, 저를 위한 건 아닙니다.
00:09:54제가 나이가 들었으니까요.
00:09:56그래서 다른 옵션들을 찾아보았습니다.
00:09:59우선 Codex CLI가 있는데, 정말 별로였습니다.
00:10:01처음에는 사용자 인터페이스와 모델 모두 그랬지만,
00:10:05적어도 모델 측면에서는 변화가 있었습니다.
00:10:08Codex는 이제 꽤나 괜찮아졌습니다.
00:10:10다음으로 AMP가 있습니다.
00:10:12그 팀원들은 예전에 Sourcegraph에서 일했었습니다.
00:10:15Sourcegraph에서 독립해서 나온 팀이죠.
00:10:20그리고 정말 실력 있는 엔지니어들입니다.
00:10:21그들은 기능을 추가하는 대신 오히려 빼버리는
00:10:25상업용 코딩 하네스를 구축해 냈습니다.
00:10:28그들의 선택 대부분은 저에게 큰 공감이 됩니다.
00:10:33상업용 코딩 하네스를 찾고 계신다면,
00:10:36AMP를 꼭 추천하고 싶습니다. 정말 훌륭하거든요.
00:10:39Factory Troye도 비슷한 느낌인데 역시 좋습니다.
00:10:44다만 AMP만큼 실험적이지는 않습니다.
00:10:47그리고 많은 사람이 사용하는 오픈 소스
00:10:50코딩 하네스인 OpenCode가 있습니다.
00:10:53저는 오픈 소스 경력이 꽤 됩니다.
00:10:55오픈 소스 분야에 몸담은 지 17년이나 되었죠.
00:11:00크고 작은 오픈 소스 프로젝트들을 관리해 왔습니다.
00:11:04그래서 오픈 소스는 저에게 매우 소중합니다.
00:11:05그래서 OpenCode를 한 번 써보자고 생각했습니다.
00:11:08저와 성향이 잘 맞으니까요.
00:11:12AMP와 더불어 이 분야에서 가장 현실적이고
00:11:15실용적인 팀 중 하나를 보유하고 있습니다.
00:11:16아마 쓰지도 않을 기능들로
00:11:18과대광고를 하지 않습니다.
00:11:20그들은 매우 안정적인
00:11:23핵심 경로를 보존하려고 노력합니다.
00:11:26또한 코딩 에이전트가 직업으로서의
00:11:27우리에게 어떤 의미인지에 대해
00:11:29훌륭한 생각을 가지고 있고, 저도 그에 공감합니다.
00:11:32OpenCode의 문제는 컨텍스트를 관리하는 능력이
00:11:37그리 뛰어나지 않다는 점입니다.
00:11:38예를 들어, 매 턴마다 sessionCompaction.prune을 호출하는데,
00:11:44이 기능은 다음과 같은 일을 합니다.
00:11:46마지막 40,000 토큰 이전의 모든 결과를 잘라냅니다.
00:11:52자, 프롬프트 캐싱이 뭔지 아시는 분 계신가요?
00:11:56이것이 여러분의 프롬프트 캐시에 어떤 영향을 줄까요?
00:11:58OpenCode와 Anthropic 사이에는 흥미로운 역사가 있습니다.
00:12:05결국 Anthropic은 제 생각에 당연하게도
00:12:11"이보게들, 그런 식으로는 안 되네"라고 말했습니다.
00:12:14이에 대해 공식적으로 알려진 바는 없지만,
00:12:17Tarek이 여기서 설명해 줍니다.
00:12:19체육관에 와서 제대로 행동하지 않고
00:12:22인프라를 남용하면 쫓겨나게 되는 법이죠.
00:12:25제 생각에는—
00:12:27물론 증거는 없습니다만,
00:12:28그것이 Anthropic과 OpenCode 사이에
00:12:30적대감이 생긴 이유라고 생각합니다.
00:12:33저는 전적으로 동의하며, 적어도
00:12:36Anthropic이 명백히 옳다고 생각합니다.
00:12:39인프라를 건드리지 마세요.
00:12:42또한 다른 기능들도 있는데, OpenCode는
00:12:44OpenCode는 언어 서버 프로토콜인 LSP 지원 기능을
00:12:46기본으로 탑재하고 있습니다.
00:12:48컨텍스트 엔지니어링 이야기로 돌아와서,
00:12:51에이전트에게 여러 개의 파일을
00:12:53수정하는 작업을 맡겼다고 가정해 봅시다.
00:12:55실제로는 어떤 일이 벌어질까요?
00:12:57에이전트는 여러 파일에 대해
00:13:02차례대로 일련의 수정을 가할 것입니다.
00:13:03예를 들어 10번의 수정 중 첫 번째 수정을 마친 후,
00:13:09코드가 제대로 컴파일될 확률이 얼마나 될까요?
00:13:12코드를 한 줄씩 수정해 나간다면,
00:13:15다시 안정화되어 깔끔하게 컴파일되기까지
00:13:17얼마나 걸릴까요?
00:13:19안 됩니다. 컴파일되지 않죠.
00:13:20첫 번째 수정 후에도, 아마 두 번째 수정
00:13:22이후에도 컴파일은 되지 않을 겁니다.
00:13:24그런데 이때 LSP 서버에게 물어본다고 칩시다.
00:13:28"이 파일에서 방금 한 줄 고쳤는데,
00:13:30어디 망가진 데 있어?"
00:13:31그러면 LSP 서버는 "네, 완전히 망가졌네요"라고 답하겠죠.
00:13:34이 기능이 하는 일은 도구 호출 직후에
00:13:36이러한 오류를 일종의 피드백으로서
00:13:39모델에 직접 주입하는 것입니다.
00:13:43"방금 네가 한 건 틀렸어"라고요.
00:13:45그럼 모델은 "뭐라고?"라며 당황할 겁니다.
00:13:47"수정이 아직 다 끝난 게 아니라고.
00:13:49왜 벌써 이런 말을 하는 거야?
00:13:50당연히 아직은 틀린 상태지."
00:13:51하지만 이런 일이 반복되면 모델은 그냥 포기해 버리고,
00:13:54결국 아주 좋지 않은 결과로 이어집니다.
00:13:58그래서 전 LSP 방식의 팬이 아닙니다.
00:13:59그걸 활성화해 두는 건 아주 끔찍한 생각이라고 봐요.
00:14:02린팅이나 타입 체크 등을
00:14:03수행해야 하는 자연스러운
00:14:06동기화 시점이 따로 있습니다.
00:14:07그건 바로 에이전트 스스로 작업이 끝났다고 판단할 때뿐입니다.
00:14:10이 부분은 최근에 변경되었습니다.
00:14:14OpenCode의 단일 세션에서는 모든 메시지가
00:14:20각각의 JSON 파일이 됩니다.
00:14:22메시지 하나하나가 디스크 상에 개별 JSON 파일로 저장되죠.
00:14:26이는 전체적인 아키텍처 설계에
00:14:29심도 있는 고민이 부족했음을 시사합니다.
00:14:31그 부분에서 신뢰를 잃으면,
00:14:33저는 더 이상 그 도구를 쓰고 싶지 않아집니다.
00:14:35다시 말씀드리지만, 팀 자체는 정말 훌륭하다고 생각합니다.
00:14:37반복 작업을 엄청나게 빠르게 수행해서
00:14:39많은 사람에게 유용한 것을 만들어낸 건
00:14:42분명한 사실이니까요.
00:14:43다만 저라면 하지 않았을 결정들이 있었고,
00:14:46그게 제가 직접 도구를 만들기로 결심한 이유입니다.
00:14:50이런 점도 있었습니다.
00:14:51OpenCode는 기본적으로 서버와 함께 제공됩니다.
00:14:54핵심 아키텍처가 서버를 기반으로 하고 있고,
00:14:56클라이언트들이 거기에 연결하는 방식이죠.
00:14:57터미널 사용자 인터페이스(TUI)도 그 클라이언트 중 하나고요.
00:15:00데스크톱 인터페이스도 있는 것으로 압니다.
00:15:01그런데 잘 모르겠네요.
00:15:03결국 원격 코드 실행(RCE)이 기본적으로 포함된
00:15:05보안 취약점이 있는 것으로 드러났습니다.
00:15:09자신의 서버 인프라나 서버 아키텍처에
00:15:12그렇게 자부심이 있다면,
00:15:15보안에 대해서도 충분히 고려한
00:15:18성숙한 엔지니어일 것이라 기대하기 마련인데,
00:15:20보아하니 그렇지 않았던 것 같습니다.
00:15:21게다가 이 문제는 오랫동안 방치되어 있었습니다.
00:15:23누구를 비난하려는 건 아닙니다.
00:15:25전례 없는 속도로 돌아가는
00:15:27이 업계에서 일하다 보면
00:15:31충분히 일어날 수 있는 일들이죠.
00:15:33단지 그런 문제가 있다면 전 그 도구를 쓰고 싶지 않을 뿐입니다.
00:15:36이상이 기존 코딩 도구들에 대한
00:15:42저의 관찰 내용이었습니다.
00:15:42AMP나 Droid도 사용해 볼 수 있었겠지만,
00:15:45마찬가지로 제어권이 없었습니다.
00:15:47AMP의 경우, 어떤 모델을 사용할지도 그들이 결정하며
00:15:50각 작업당 단 하나의 모델만 사용할 수 있습니다.
00:15:53그건 제 스타일이 아니죠.
00:15:55Droid는 조금 더 개방적이라고 생각합니다만,
00:15:58제가 테스트해 보았을 당시에는
00:16:00딱히...
00:16:02클라우드 코드에 비해 큰 장점을 느끼지 못했습니다.
00:16:07그러다 완전히 다른 이유로 벤치마크를 살펴보다가
00:16:10Terminal Bench를 발견했습니다.
00:16:12Terminal Bench가 뭔지 아시는 분 계신가요?
00:16:15기본적으로 이건 코딩 또는 에이전트 평가용
00:16:20테스트 환경인데, 컴퓨터 사용 및 프로그래밍 관련...
00:16:24죄송합니다, 네 살짜리 아이를 키우느라 좀 피곤하네요.
00:16:24아무튼,
00:16:31에이전트나 에이전트 내부의 LLM이 수행해야 하는
00:16:35수많은 컴퓨터 사용 및 코딩 관련 작업들이 포함되어 있습니다.
00:16:39그 수가 약 82개 정도 되는 것 같더군요.
00:16:40분야도 매우 다양합니다.
00:16:43윈도우 설정 복구부터
00:16:44몬테카를로 시뮬레이션 코드 작성까지 아우르죠.
00:16:48그리고 리더보드도 운영하고 있습니다.
00:16:51그 리더보드에서는 코딩 에이전트 프레임워크와
00:16:52모델의 조합별 성적을 볼 수 있습니다.
00:16:54그들은 'Terminus'라는 자체 코딩 에이전트도 보유하고 있는데,
00:16:57정말 훌륭하다고 생각합니다.
00:17:03벤치마크에서 최고 수준의 성능을 보여주는 프레임워크 중 하나거든요.
00:17:06벤치마크에서 가장 성능이 좋은 하네스 중 하나이기 때문입니다.
00:17:09잠시 후에 살펴보겠습니다.
00:17:11정확히 어떤 역할을 할까요?
00:17:12모델이 받는 것은 오직 TMUX 세션뿐입니다.
00:17:17모델이 할 수 있는 일은 키 입력을 보내고
00:17:19출력되는 VT 코드 시퀀스를 읽어오는 것뿐이죠.
00:17:23이것은 모델이 컴퓨터와 상호작용할 수 있는
00:17:27가장 작고 최소화된 인터페이스라고 할 수 있습니다.
00:17:31그리고 이것은 전체 리더보드에서 최상위권의 성능을 보여줍니다.
00:17:36그렇다면 이것이 기존 코딩 에이전트 하네스에 대해 무엇을 말해줄까요?
00:17:39모델이 제대로 성능을 발휘하기 위해
00:17:41이 모든 기능이 정말 필요한 것일까요?
00:17:43개인적으로 이것은 단지 모델의 성능이
00:17:48좋다는 것만을 의미하지 않습니다.
00:17:49사용자이자 인간인 저에게 있어,
00:17:51에이전트 모델과 상호작용하는 방식에 관한 문제이기도 합니다.
00:17:54Terminus가 제가 원하는 사용자 경험이나
00:17:58개발자 경험은 분명히 아닙니다.
00:18:00하지만 코딩 하네스들이 가진 이 모든 기능들이
00:18:03에이전트로부터 좋은 결과를 얻어내는 데
00:18:08필수적이지 않을 수도 있다는 점을 시사합니다.
00:18:10파일 도구도, 서브 에이전트도, 웹 검색도 아무것도 없이 말이죠.
00:18:13이러한 발견들을 바탕으로 두 가지 논제를 세웠습니다.
00:18:16우리는 지금 이것저것 시도하며 알아가는 단계에 있습니다.
00:18:18완벽한 코딩 에이전트나 완벽한 코딩 하네스가
00:18:21어떤 모습이어야 하는지 아무도 모릅니다.
00:18:23미니멀리즘과 거대한 에이전트 군단 활용,
00:18:27통제 없는 완전한 자율성 등 모든 방식을
00:18:30시도해 보고 있는 중입니다.
00:18:31아직 결론이 나지 않았다고 생각합니다.
00:18:33이것이 이상적으로 어떤 모습이어야 하는지,
00:18:35무엇이 업계 표준이 될 것인지에 대한
00:18:37답을 아직 얻지 못했습니다.
00:18:38그리고 두 번째는 코딩 에이전트를
00:18:40더 잘 실험해 볼 수 있는 방법이 필요하다는 것입니다.
00:18:42즉, 에이전트가 스스로를 수정하고
00:18:47유연하게 변화할 수 있어야 합니다.
00:18:48그래야 우리가 아이디어를 빠르게 실험하고
00:18:50그것이 업계 표준이나 우리 모두가 채택할
00:18:53새로운 워크플로우가 될 수 있을지 확인할 수 있습니다.
00:18:58기본적인 아이디어는 이렇습니다.
00:18:59매우 간단합니다. 대단한 기술은 아니죠.
00:19:01모든 것을 걷어내고 확장 가능한 최소한의 코어만 구축하는 것입니다.
00:19:05약간의 편의 기능은 들어있습니다.
00:19:06아무것도 없는 빈 도화지는 아니니까요.
00:19:09그것이 바로 'Py'입니다.
00:19:10일반적인 모토는 당신이 에이전트에 맞추는 대신
00:19:13에이전트를 당신의 필요에 맞게 조정하는 것입니다.
00:19:16여기에는 네 가지 패키지가 포함됩니다. 먼저 AI 패키지는
00:19:21서로 다른 전송 프로토콜을 사용하는 여러 제공업체들을
00:19:24단순하게 추상화한 것입니다.
00:19:27덕분에 모든 제공업체와 대화하기 매우 쉽고
00:19:29동일한 컨텍스트나 세션 내에서 업체 전환이 가능합니다.
00:19:34에이전트 코어는 도구 호출, 검증 등이 포함된
00:19:36일반화된 에이전트 루프입니다.
00:19:38기타 여러 기능과 스트리밍도 지원하죠.
00:19:39그리고 터미널 사용자 인터페이스(TUI)가 있는데,
00:19:42약 600줄의 코드로 이루어져 있으며 정말 잘 작동합니다.
00:19:47놀랍게도 '클랭커(AI)'가 작성한 것이 아니기 때문이죠.
00:19:51마지막으로 코딩 에이전트 자체입니다. 이것은
00:19:54헤들리스 모드에서 사용할 수 있는 SDK이기도 하고
00:19:57전체 TUI를 갖춘 코딩 에이전트이기도 합니다.
00:20:02이것이 시스템 프롬프트의 전부입니다.
00:20:05다른 코딩 에이전트들의 시스템 프롬프트와 비교했을 때
00:20:08더 이상 추가된 것은 없습니다.
00:20:10토큰 단위로 봐도 그렇습니다.
00:20:13최신 모델들은 코딩 에이전트가 무엇인지 알도록
00:20:16강력하게 강화 학습(RL)되어 있습니다.
00:20:18그런데 왜 모델에게 코딩 에이전트라는 사실과
00:20:21코딩 작업을 어떻게 해야 하는지 계속 반복해서 설명하나요?
00:20:27기본적으로 'YOLO(한 번뿐인 인생)' 모드인 이유는 무엇일까요?
00:20:30현재 대부분의 코딩 에이전트 하네스에는 두 가지 모드가 있습니다.
00:20:33에이전트가 원하는 대로 무엇이든 할 수 있거나,
00:20:36에이전트가 사용자에게 매번
00:20:40"정말로 이 파일을 삭제하시겠습니까?"
00:20:41"정말로 이 디렉토리의 파일을 나열하시겠습니까?" 등을 묻는 식이죠.
00:20:44다양한 단계의 절충안들이 있지만
00:20:44결국 핵심은 사용자가 에이전트의 동작을
00:20:47일일이 승인해야 한다는 점입니다.
00:20:49그래야 안전하다고 느끼니까요.
00:20:52하지만 저는 이것이 잘못되었다고 생각합니다. 피로감을 유발하기 때문이죠.
00:20:53사람들은 결국 이 기능을 완전히 꺼버리거나(YOLO 모드),
00:20:55내용을 읽지도 않고 그냥 엔터만 치게 될 것입니다.
00:20:58그래서 이것은 해결책이 아니라고 봅니다.
00:21:01데이터 유출이나 프롬프트 인젝션이 걱정된다면
00:21:02컨테이너화도 완벽한 해결책은 아닙니다.
00:21:04하지만 제 생각에 그것이
00:21:06가장 최선의 기반이라고 생각합니다.
00:21:07승인 대화창 같은 가드레일보다는 말이죠.
00:21:10이 에이전트는 파일 읽기, 쓰기, 수정,
00:21:14그리고 Bash, 단 네 가지 도구만 가집니다.
00:21:17Bash만 있으면 충분합니다.
00:21:19무엇이 빠졌을까요?
00:21:21MCP도, 서브 에이전트도, 계획 기능도, 배경 작업도,
00:21:22내장된 할 일 목록도 없습니다.
00:21:23대신 이렇게 할 수 있습니다.
00:21:25MCP 대신 CLI 도구와 기술을 조합하거나,
00:21:26잠시 후에 보게 될 확장을 구축하면 됩니다.
00:21:28서브 에이전트가 없는 이유는 무엇일까요?
00:21:30관찰이 불가능하기 때문입니다.
00:21:34대신 tmux를 사용해 에이전트를 다시 실행하세요.
00:21:35그러면 에이전트의 모든 입출력을 완벽하게 제어할 수 있고
00:21:36서브 에이전트에서 일어나는 모든 일을 볼 수 있습니다.
00:21:41흥미롭게도 현재 'Code Spawn'의 팀 모드도
00:21:44기본적으로 정확히 이 방식을 사용합니다.
00:21:48계획 모드가 없다면 'plan.md' 파일을 작성하세요.
00:21:50터미널 뷰포트에도 잘 맞지 않는 어설픈 UI 대신
00:21:55영구적인 결과물을 가질 수 있습니다.
00:21:57그리고 이를 여러 세션에 걸쳐 재사용할 수 있죠.
00:21:59배경 Bash 작업은 필요 없습니다. 우리에겐 tmux가 있으니까요.
00:22:02결국 같은 원리입니다.
00:22:04내장된 할 일 목록 대신 'todo.md'를 쓰세요.
00:22:07마찬가지입니다.
00:22:09아니면 이 모든 것을 당신이 원하는 방식으로 직접 만드세요.
00:22:11Py는 뛰어난 확장성을 통해 이를 가능하게 합니다.
00:22:13도구를 커스텀하게 확장할 수 있습니다.
00:22:14당신이 정의한 도구를 LLM에게 줄 수 있죠.
00:22:17오픈 코드를 포크하지 않는 한 현재 다른 어떤
00:22:21코딩 에이전트 하네스도 이런 기능을 제공하지 않습니다.
00:22:22여기서는 포크할 필요가 없습니다.
00:22:26그저 간단한 TypeScript 파일을 작성하기만 하면
00:22:28자동으로 로드됩니다.
00:22:31커스텀 UI도 작성할 수 있습니다.
00:22:32기술(Skills)은 당연히 프롬프트 템플릿과 테마에 포함됩니다.
00:22:34이 모든 것을 하나로 묶어 npm이나 Git에 올리고
00:22:37명령어 하나로 설치할 수 있는데, 이는 매우 편리합니다.
00:22:39그리고 모든 것이 핫 리로드를 지원합니다.
00:22:43저는 프로젝트 내부에서 특정 프로젝트나 작업에 특화된
00:22:46저만의 Py 확장 기능을 개발합니다.
00:22:49에이전트가 확장 기능을 수정하면 저는 그냥 리로드만 합니다.
00:22:51그러면 실행 중인 모든 코드가 즉시 업데이트되는데,
00:22:53정말 훌륭한 기능이죠.
00:22:59실제로는 커스텀 압축(Compaction) 작업도 가능합니다.
00:23:05현재 모든 압축 구현 방식들이 좋지 않기 때문에,
00:23:10사람들이 더 많이 실험해 봐야 할 부분이라고 생각합니다.
00:23:11권한 게이트도 50줄의 코드로 쉽게 구현할 수 있으며
00:23:14다른 에이전트 하네스들이 하는 기능들을 포함할 수 있습니다.
00:23:16커스텀 제공업체를 사용하거나 자체 호스팅 모델의 프록시를 등록하세요.
00:23:19제가 대신 해줄 필요는 없습니다.
00:23:21당신이 직접 할 수 있고, 당신의 '클랭커'가 대신 해줄 수도 있습니다.
00:23:23또는 내장된 도구를 덮어쓰는 것도 가능합니다.
00:23:24읽기, 쓰기, 수정, Bash 작동 방식을 수정해 보세요.
00:23:27저는 원격 머신에서 SSH를 통해 작동하는
00:23:31읽기, 쓰기, 수정, Bash 버전을 가지고 있습니다.
00:23:32구현하는 데 5분밖에 안 걸렸지만 아주 잘 작동합니다.
00:23:33전체 TUI 접근 권한이 있으므로 코딩 에이전트 내에서
00:23:37완전한 커스텀 UI를 작성할 수도 있습니다.
00:23:38'Cloud Code Shipped' 기능은 어떤 분이 Py를 사용하여
00:23:41더 많은 기능을 담아 5분 만에 복제해냈습니다.
00:23:42'PyMessenger'는 정확히 무엇을 하는지 모르겠지만
00:23:43여러 Py 에이전트가 소통하는 채팅방 같은 것 같더군요.
00:23:47커스텀 UI도 갖추고 있습니다.
00:23:51그들이 무엇을 하는지 볼 수 있는데, 네, 그냥 잘 작동합니다.
00:23:54심심하다면 'PyMess'로 에이전트가 실행되는 동안
00:23:58그들이 무엇을 하는지 볼 수 있는데, 네, 그냥 잘 작동합니다.
00:24:02아니면 PyMess로, 지루할 때 그냥 게임을
00:24:05에이전트가 돌아가는 동안 하셔도 되고요, 그렇죠?
00:24:07그렇게 하실 수 있습니다.
00:24:10또는 PyAnnotate로, 현재 작업 중인
00:24:13웹사이트를 열어서 프런트엔드에서 요소를 주석 달고,
00:24:18에이전트에게 직접 인라인으로 피드백을 줄 수도 있습니다.
00:24:23그걸 다시 컨텍스트에 넣어서, 에이전트가 수정하게 하는 거죠.
00:24:24아니면 제가 사용하는 File Switch It도 있습니다.
00:24:25IDE나 에디터로 화면을 전환하고 싶지 않을 때가 있거든요.
00:24:28그저 수정된 파일을 빠르게 확인하고 싶을 뿐이니까요.
00:24:31이 모든 것이 확장 기능입니다.
00:24:35내장된 기능은 하나도 없으며, 사람들이 직접
00:24:39자신이 원하는 방식대로 구축하는 데 보통
00:24:42몇 분에서 오후 한나절 정도밖에 걸리지 않습니다.
00:24:43PyWavic도 있는데, 이건 정확히 뭘 하는 건지 모르겠네요.
00:24:46Py는 트리 구조도 함께 제공합니다.
00:24:48그 부분은 설명하지 않을게요.
00:24:50그냥 py.dev를 확인해 보세요.
00:24:52여러분의 세션은 선형적인 채팅 목록이 아니라 트리 구조입니다.
00:24:56그래서 기본적으로 몇몇 에이전트들을...
00:25:00에이전트, 기술, 완벽한 비용 추적 기능을 갖췄습니다.
00:25:01많은 하네스들이 비용 추적을 지원하지 않습니다.
00:25:03오픈 코드도 제대로 하지 못하죠.
00:25:04HTML 내보내기, JSON 형식, 헤들리스 JSON 스트림 등등.
00:25:07이게 실제로 작동하냐고요? 'Terminal Bench'를 보시죠.
00:25:09여기 화면을 좀 확대해 보겠습니다.
00:25:11안 되네요. 정말 놀랍군요.
00:25:14Claude Opus 4.5를 사용한 Terminus 2 바로 뒤에 Py가 있습니다.
00:25:19Py에 압축 기능조차 없었던 작년 10월의 결과입니다.
00:25:22데모 시간은 건너뛰겠습니다. 오픈 소스를 망치고 있는
00:25:24'클랭커'들에 맞서야 하니까요.
00:25:26만약 이 친구의 프로젝트와 관련이 있다면,
00:25:29OpenClaw에서 수백 명의 사람들이 몰려와
00:25:33여러분의 저장소에 '클랭커' 쓰레기를 퍼부을 것입니다.
00:25:34그래서 몇 가지 대책을 세워야 했습니다.
00:25:35'OSS 휴가'라는 걸 만들었죠.
00:25:36몇 주 동안 이슈와 PR을 닫아두고
00:25:37혼자서 작업을 진행하는 것입니다.
00:25:38중요한 내용이라면 나중에 어쨌든 다시 보고되거나
00:25:45Discord에 올라올 테니까요.
00:25:49그리고 저장소에 마크다운 파일을 두는
00:25:51커스텀 액세스 체계도 구현했습니다.
00:25:54해당 마크다운 파일에 계정 이름이 없는 사람이
00:25:56PR을 열면 자동으로 닫히도록 설정했습니다.
00:26:02저는 신경 쓰지 않습니다.
00:26:06먼저 이슈를 통해 사람의 목소리로 자신을 소개하세요.
00:26:09너무 길지 않게 이슈를 작성하세요.
00:26:11길어지면 아마도 '클랭커'일 확률이 높으니까요.
00:26:14그렇게 하면 기꺼이 승인해 드릴 것입니다.
00:26:16그러면 파일에 이름이 등록되고
00:26:20저장소에 PR을 제출할 수 있게 됩니다.
00:26:21제가 요구하는 건 오직 사람인지 확인하는 것뿐입니다.
00:26:26Ghosty의 Mitchell이 이걸 보고 'Vouch'라는 프로젝트를 만들었는데,
00:26:28여러분의 오픈 소스 저장소에 더 쉽게 적용할 수 있습니다.
00:26:32그것이 바로 Py입니다.
00:26:34이제 직접 시도해 보세요.
00:26:35제 발표는 여기까지입니다.
00:26:39[박수]
00:26:42[음악 연주]