Transcript
00:00:00그를 아실 겁니다. 긴 포니테일, 타원형 안경, 버전 관리 시스템보다 오래 회사에 있었죠.
00:00:0650줄짜리 코드를 보여주면, 쓱 훑어보고 아무 말 없이 한 줄로 바꿔버리는 사람 말입니다.
00:00:11그게 바로 '포니테일(Ponytail)'이라는 새로운 라이브러리에 대한 거창한 설명인데, 제 생각엔 좀
00:00:17공감이 갑니다. 우리 모두 저런 설명을 완벽하게 충족하는 10배 뛰어난 개발자를 알고 있으니까요. 하지만 포니테일은
00:00:23사실 정말 멋진 도구입니다. AI 코딩 에이전트가 사무실에서 가장 게으른 시니어 개발자처럼 생각하게 만들거든요.
00:00:29그리고 그건 사실 칭찬입니다. 그래서 이번 영상에서는 포니테일을 살펴보고,
00:00:35어떻게 작동하는지 확인하고, 몇 가지 재미있는 데모를 실행해서 이 녀석이 진짜 쓸만한지 알아보겠습니다.
00:00:41정말 재미있을 겁니다. 바로 시작해 보죠.
00:00:48포니테일의 미션은 간단합니다. 모든 것을 아주 간결하게 유지하고, AI 에이전트가 보통 만들어내는 거품을 제거하며,
00:00:55문제에 대해 가능한 한 가장 군더더기 없는 해결책을 찾아내려고 노력하는 것입니다.
00:01:00AI 코딩 에이전트가 말을 적게 하도록 만들어 토큰 사용량을 줄여주던 라이브러리인 '케이브맨(Caveman)'과 비슷한데요,
00:01:06제임스가 아주 잘 다뤘던 영상이 여기 있습니다. 그래서 핵심 아이디어는
00:01:12YAGNI 원칙을 수용하는 것입니다. 'You Ain't Gonna Need It(그건 필요 없을 거야)'의 약자죠. 90년대부터 내려온
00:01:18소프트웨어 공학 사상입니다. 핵심은 실제로 필요하기 전까지는 만들지 말라는 겁니다.
00:01:25추상화 계층을 추가하지 말고, 라이브러리를 설치하지 말고, 클래스를 작성하지 마세요.
00:01:31그것 없이 문제를 해결할 수 있다면 그냥 없이 해결하세요. 포니테일은 에이전트가 무엇이든 작성하기 전에
00:01:37올라가야 할 의사결정 사다리를 제공함으로써 이 원칙을 에이전트에 직접 내장합니다. 이게 정말 존재해야 하나?
00:01:43표준 라이브러리로 처리할 수 있나? 네이티브 플랫폼 기능이 있나? 이미 설치된 의존성 중에 이 작업을 수행하는 것이 있나?
00:01:50한 줄 코드로 가능한가? 이 모든 질문에 대한 답이 '아니오'일 때만 실제로 새로운 코드를 작성합니다.
00:01:57그때조차도, 작동하는 데 필요한 최소한으로 유지합니다.
00:02:04그리고 그들의 예시,
00:02:05특히 모달 대화 상자 예시를 보면 이 방법론을 명확하게 알 수 있습니다. 일반적인 에이전트는 삭제 확인을 위한 모달 대화 상자를
00:02:11추가해달라는 요청을 받으면 즉시 React Dialog 같은 Radix UI 라이브러리를 설치하려고 달려듭니다.
00:02:18그리고 의존성을 추가하고, 포털, 오버레이, 루트, 트리거, 컨텐츠 래퍼까지 다 가져와서
00:02:25버튼 두 개 있는 상자 하나 보여주려고 하겠죠. 하지만 포니테일은 이걸 보고 이렇게 말합니다. '브라우저에 이미 dialog 요소가 있잖아.'
00:02:34이건 자동으로 포커스를 가두고, Esc 키로 닫히고, CSS 선택자 하나로 배경을 렌더링하지.
00:02:41게다가 2022년부터 모든 주요 브라우저에서 지원되거든. 그래서 NPM 패키지로 30줄을 쓰는 대신,
00:02:49여덟 줄의 코드와 제로 의존성으로 해결합니다. 그리고 바로 이 작은 포니테일 주석이
00:02:58무엇을 생략했고 왜 그렇게 했는지 정확히 알려줍니다. 그래서 언젠가 Radix 버전이나 더 화려한 것으로
00:03:04업그레이드하기로 결정한다면 어디를 고쳐야 할지, 어디가 미뤄졌는지 알 수 있죠.
00:03:11그러니 게으르긴 해도 무책임한 건 아닙니다. 이런 게으름을 포용함으로써 포니테일은
00:03:16비용을 47%에서 77%까지 줄일 수 있다고 주장합니다. 그들은 실제로 이 주장을 뒷받침하는 벤치마크 결과를 제공합니다.
00:03:22세 가지 방법을 사용합니다: 기술 없음, 케이브맨 사용, 그리고 포니테일 사용. 그리고 세 가지 모델과 다섯 가지 일상적인 작업.
00:03:29셀당 10번씩 실행하고 각 결과의 중앙값을 구합니다. 그리고 결정적으로 정확성도 검사합니다.
00:03:36코드 라인 수만 적고 작동하지 않는 한 줄짜리 코드는 정확성 테스트에서 실패할 겁니다. 그러니까 그냥 '작게 쓰는 것'만이 아니라,
00:03:43실제로 작동해야 한다는 거죠. 그리고 흥미로운 주의사항도 있습니다.
00:03:50비용은 매번 기술을 다시 전송하는 단일 샷 호출을 기준으로 합니다. 즉,
00:03:56벤치마크는 각 테스트마다 새로운 API 호출을 보내는 방식으로 작동합니다. 그리고 매번 그렇게 할 때마다,
00:04:03전체 포니테일 규칙 세트를 프롬프트에 포함합니다. 즉, 벤치마크에서는 포니테일이 테스트마다 자신의 지시사항을 보내는 비용만큼 페널티를 받는 셈입니다.
00:04:10실제 생활에서는 그 지시사항에 대한 비용을 세션당 대략 한 번 정도 지불합니다. 그 이후에는 캐싱되니까요.
00:04:16즉, 47~77% 더 저렴하다는 수치는 실제로는 저평가된 것입니다. 여러 프롬프트에 걸쳐 진행되는 실제 작업 세션에서는
00:04:22지시사항 주입 비용이 전체 대화에 분산되기 때문에 비용 효율은 훨씬 더 커집니다.
00:04:29그럼에도 불구하고 타당한 비판이 하나 있습니다. 콜린 에버하트가 최근 게시한 블로그 글에 따르면,
00:04:36포니테일을 'YAGNI 원칙을 따르라'는 세 단어로 바꾸기만 해도 그 결과가
00:04:42포니테일의 벤치마크 점수와 거의 완벽하게 일치한다고 지적했습니다. 그리고 일곱 단어로 늘려서
00:04:48'YAGNI 원칙과 한 줄 해결책을 따르라'고 하면 실제로 벤치마크 점수를 능가하기도 했습니다.
00:04:55그렇다면 포니테일은 마법일까요, 아니면 그저 잘 포장된 프롬프트일까요? 솔직히 타당한 질문입니다.
00:05:03하지만 저는 그 '포장'이 곧 제품이라고 주장하고 싶습니다. 명령어, 감사 도구, 그리고 그 위에 깊이 있는 레저(ledger)를 통해
00:05:11올바른 규칙들을 여러 에이전트에 자동으로 주입받으니까요. 게다가 포니테일에는 다른 멋진 기능들도 있습니다.
00:05:18시스템 프롬프트에 YAGNI를 따르라고 넣는 것만으로는 포니테일의 감사 기능이나 리뷰 기능을 얻을 수는 없거든요. 이제 간단한 예제로 테스트해 봅시다.
00:05:25여기 Cloud Code 인스턴스 두 개를 열어두었습니다. 하나에는 로컬 범위에만
00:05:31포니테일 플러그인을 설치할 것이고, 다른 하나는 플러그인이 활성화되지 않은 간단한 기본 Cloud Code 인스턴스로 둘 겁니다.
00:05:37두 곳에 모두 사용자 위치를 감지하고 현재 날씨와 기타 기능을 보여주는 날씨 대시보드 앱을 만들라는 같은 프롬프트를 줄 겁니다.
00:05:44그리고 포니테일 버전에서는 가끔 자동으로 기술을 인식하지 못할 때가 있어서
00:05:49포니테일 기술을 사용하라고 추가 요청하는 것 외에는 똑같이 실행할 겁니다.
00:05:56잠시 후, 포니테일 버전은 벌써 1분도 안 돼서 작업을 끝냈고,
00:06:02기본 버전은 아직 처리 중입니다. 또한 무엇을 빌드했는지, 최대 효율을 위해 포니테일이
00:06:08무엇을 하지 않기로 결정했는지 아주 간결한 개요를 볼 수 있습니다.
00:06:12여기 보이는 것처럼, 모든 것을 단일 HTML 파일에 넣기로 선택했네요.
00:06:18한편 기본 창에서는 작업이 2분 30초 만에 끝났습니다. 벌써 이 버전이 훨씬 더
00:06:25비대하다는 것을 알 수 있습니다. 세 개의 별도 파일로 구성되어 있고 파이썬 서버를 사용해 실행되죠.
00:06:34이 결과가 나쁘다는 건 절대 아니지만, 첫 번째 버전보다 훨씬 더 과도하게 설계되었습니다.
00:06:41이제 어떻게 작동하는지 한번 보죠. 먼저 포니테일 없는 버전입니다.
00:06:48앱은 멋지고 UI도 예쁘고 API도 예상대로 정보를 잘 가져오지만,
00:06:54제가 요청한 대로 자동으로 위치를 감지하지 않은 점은 꽤 실망스럽네요.
00:07:00대신 런던을 기본 첫 결과로 보여주고 있습니다. 하지만 포니테일 버전으로 넘어가 보면,
00:07:07열자마자 현재 위치를 가져오겠냐고 묻고, 그 위치에 맞는 날씨를 출력하는 걸 분명히 볼 수 있습니다.
00:07:12UI는 조금 덜 화려하고 앱은 더 기초적일지 몰라도, 기본 버전보다 훨씬 더 정확하게 지시를 따랐다는 게,
00:07:19솔직히 꽤 놀랍습니다.
00:07:25마지막으로 사용량을 살펴보겠습니다. 보시다시피 포니테일이 포함된 버전은
00:07:33기본 버전보다 50% 더 저렴했습니다. 코드 라인 수도 훨씬 적었고요.
00:07:39그리고 방금 보셨다시피 기능 면에서도 기본 버전보다 더 좋았습니다.
00:07:45결국 포니테일이 예상대로 잘 작동하며 더 간결한 코드를 만들어낸다는 점이 증명된 거죠.
00:07:52이 테스트가 아주 성공적이었기에 더 재미있는 것을 해보기로 했습니다.
00:07:58케이브맨과 포니테일을 최대 효율을 위해 조합하면 어떨까요? 어떤 결과가 나올까요?
00:08:04이번에는 새로운 디렉토리에 두 플러그인을 모두 활성화하고 똑같은 프롬프트를 다시 실행했습니다.
00:08:09역시나 이번에도 1분도 안 되어 작업이 완료되었고 결과물은 꽤 비슷했습니다.
00:08:17기능도 모두 똑같았죠. 제대로 작동한 겁니다.
00:08:22하지만 결과물을 보면 포니테일 버전과 큰 차이가 없었고, 케이브맨과 포니테일
00:08:28조합은 단독 포니테일 버전보다 오히려 조금 더 비쌌습니다.
00:08:32그러니 두 개를 조합한다고 해서 별다른 큰 개선은 없는 셈입니다.
00:08:37그냥 케이브맨만 사용하거나, 아니면 포니테일을 선택하는 편이 더 좋습니다.
00:08:44포니테일이 케이브맨보다 더 낫다는 벤치마크 결과를 믿는다면 말이죠.
00:08:49자, 여기까지가 포니테일의 핵심입니다.
00:08:54저는 개인적으로 Claude가 포니테일 기술을 사용해 거품을 줄이면서도
00:08:58품질은 유지하며 긍정적인 결과물을 만들어낸 것에 정말 감명받았습니다.
00:09:02우리가 하는 코딩 해결책들이 아마 과도하게 설계된 것이 많고,
00:09:07올바르게만 사용한다면 때로는 적게 하는 게 더 좋다는 걸 보여주는 것 같네요.
00:09:13그래서 저는 확실히 제 Claude Code 설정에 포니테일 플러그인을 유지하고
00:09:19앞으로의 프로젝트에서도 계속 사용할 것 같습니다.
00:09:23여러분은 포니테일에 대해 어떻게 생각하시나요? 사용해 보셨나요?
00:09:29사용해 보실 건가요? 아래 댓글란에 알려주세요.
00:09:31그리고 이런 기술적인 분석 영상이 마음에 드셨다면,
00:09:34영상 아래에 있는 좋아요 버튼을 눌러서 알려주세요.
00:09:37그리고 저희 채널 구독도 잊지 마시고요.
00:09:40BetterStack의 Andrus였고, 저는 다음 영상에서 뵙겠습니다.
00:09:44그리고 저희 채널 구독도 잊지 마세요.
00:09:47BetterStack의 Andrus였고요, 다음 영상에서 뵙겠습니다.