코드베이스 인덱싱이 AI 지원 코딩에 실제로 차이를 만드는가?

GosuCoder 구독자 9,180명

요약

이 영상은 다양한 AI 코드 에이전트들이 코드베이스를 어떻게 탐색하고 검색하는지 비교하고, 코드베이스 인덱싱이 실제로 성능·비용·속도에 어떤 영향을 주는지 살펴본다. 토큰 기반 블라인드 청킹과 AST(추상 구문 트리) 기반 청킹(AFT)의 차이를 설명하고, Cloud Code, Root Code, Klein, Augment Code 등 주요 도구의 접근 방식을 정리한다. 두 가지 실제 테스트(모호한 질문·함수 흐름 분석)를 통해 인덱싱 유무가 속도와 비용에 미치는 효과를 분석한다. 결론적으로, 특히 문맥이 부족한 경우 인덱싱이 작업 효율과 비용 절감에 큰 가치를 제공하며, 최적의 인덱싱 방식을 고민할 필요가 있음을 강조한다.

주요 키워드

코드베이스 인덱싱 AST(추상 구문 트리) Retrieval Augmented Generation (RAG) 임베딩(embeddings) 세만틱 검색 블라인드 청킹 리플 루프 Augment Code 도움말 최적화

하이라이트

🔑 AST 기반 청킹(AFT)은 코드 논리를 유지하며 주석·공백을 제거해 의미 단위로 묶음으로써 검색 품질을 크게 높인다.
⚡️ Cloud Code(Claude)는 upfront 인덱싱 대신 CLAUDE.md 코드 맵 파일을 활용해 탐색 시작 위치를 빠르게 파악한다.
🌟 Root Code는 텍스트 임베딩과 AST 기반 세만틱 검색을 결합해 스마트한 코드베이스 인덱싱을 제공한다.
🚀 Klein은 인메모리 AST 트리(RAG)로 즉시 청킹·검색하지만, 장기 인덱스를 따로 저장하지 않는다.
📌 Augment Code는 벡터 인덱싱과 맞춤 모델을 이용해 비용·속도·정확도 면에서 압도적인 성능을 기록했다.
💡 코드베이스 인덱싱은 AI가 매번 미지의 상태에서 출발하지 않고 ‘알고 있는’ 상태로 만들어 주어 즉시 적절한 파일로 안내한다.
⚖️ 테스트 결과, 일반적 검색 질문에는 RAG 기반 도구도 충분하지만, 문맥이 부족하거나 희귀 질문에서는 인덱싱이 비용과 시간을 크게 절감했다.
🔍 용어 혼용에 주의해야 한다. Klein도 RAG 방식으로 코드 청킹·검색을 수행하지만, 이를 ‘인덱싱이 없다’고만 표현하면 오해를 부른다.

용어 설명

코드베이스 인덱싱

코드 파일 전체를 논리적 단위로 나누고 벡터 임베딩 등으로 색인하여 빠르고 정확한 검색을 가능하게 하는 기법

AST(추상 구문 트리)

소스코드를 구문 구조별로 나누어 트리 형태로 표현한 자료 구조. 불필요한 주석·공백을 제거하고 논리 단위로 청킹할 때 사용한다.

RAG(Retrieval Augmented Generation)

검색(Retrieval)된 외부 지식을 언어 모델 생성 과정에 통합해 응답 정확도를 높이는 방식

임베딩(embeddings)

단어나 코드 조각을 고정 길이 벡터로 변환하여 의미론적 유사도를 계산할 때 사용하는 표현

세만틱 검색(semantic search)

키워드 매칭이 아닌 벡터 임베딩 유사도 기반으로 문맥과 의미를 고려해 검색하는 방식

블라인드 청킹(blind chunking)

토큰 수나 문자 수 기준으로 코드 조각을 임의 분할해 색인·검색하는 가장 단순한 청킹 방법

AFT(AST 기반 청킹)

AST 노드를 기준으로 코드 논리 단위(함수·조건문 등)별로 분할해 인덱싱·검색하는 고급 청킹 기법

리플 루프(ripple loop)

검색 결과를 읽고 평가한 뒤 다음 검색 위치를 순차적으로 좁혀가는 반복 탐색 루프

도움말 최적화(helpfulness optimization)

단순 문맥 유사성 대신 개발자가 실제로 필요한 정보를 우선 제공하도록 모델을 맞추는 접근

코드베이스 인덱싱의 논쟁점을 제기한 Nick Balman 글을 계기로 AI 에이전트별 검색 방식을 비교하고, 가격·속도·정확도를 테스트해 실제 차이를 검증하려는 영상의 배경과 구조를 설명한다.

[00:00] 발표자가 코드베이스 인덱싱이 예상보다 논란이 되는 주제임을 깨달았다고 언급하며, 닉 발만의 블로그 포스트를 소개합니다. 클라인이 코드베이스를 인덱싱하지 않는 이유와 그것이 좋다는 주장에 대해 이야기합니다.

[00:18] 오그먼트 코드가 코드베이스 컨텍스트 때문에 자신이 가장 좋아하는 에이전트 중 하나라고 설명합니다. 빠른 속도와 뛰어난 질문 답변 능력을 강조하며, 영상에서 다룰 두 가지 주제를 제시합니다.

[00:32] 여러 AI 코딩 에이전트들의 접근 방식 차이점과 자신이 수행한 테스트 결과를 보여주겠다고 합니다. Rue 코드, 클라인, 오그먼트 코드에서 동일한 쿼리를 실행하여 가격, 시간, 정확도를 비교했다고 설명합니다.

코드를 일정 토큰 수로 무작위 분할하는 블라인드 청킹과 AST를 활용해 논리 단위로 묶는 AFT 기반 청킹을 비교한다. AFT는 주석·공백을 제거하고 함수·조건문 단위로 그룹핑해 검색 효율을 높인다.

[00:56] 닉 발만의 글에 완전히 동의하지 않는다고 밝히며, 클라인의 코드베이스 탐색 구현 방식을 자세히 연구했다고 합니다. 클라인도 여전히 RAG를 사용하지만 인덱싱은 사용하지 않는다는 점을 지적합니다.

[01:19] 글에서 '코드는 청크 단위로 생각하지 않는다'는 주장에 대해 의문을 제기합니다. 청크의 정의에 대해 설명하며, 단순한 토큰 수 기반 방식부터 논리적인 코드 그룹까지 다양한 접근법이 있다고 설명합니다.

[01:43] AST(추상 구문 트리)의 개념을 소개하며, 이것이 코드를 논리적으로 그룹화하는 메커니즘이라고 설명합니다. AST가 주석, 공백, 불필요한 괄호를 제거하고 트리 형식으로 코드를 구조화한다고 설명합니다.

[02:14] 자신의 초기 구현 경험을 바탕으로 무작정 청크화하는 방식의 문제점을 설명합니다. 512 토큰마다 청크화하면 논리적 단위를 무시하고 이상한 경계에서 분할될 수 있다는 구체적인 예시를 제공합니다.

[02:41] AST 구현에서 인덱서와 검색이 훨씬 더 효과적으로 작동할 수 있다고 설명합니다. AST를 함수, if문, 이진 표현식 등의 구문적 구조에 대응하는 노드들로 이해할 수 있다고 하며, 각 AI 코딩 에이전트의 실제 구현 방식을 살펴보겠다고 마무리합니다.

Cloud Code(Claude)는 CLAUDE.md 코드 맵으로 시작점을 잡고, Root Code는 텍스트+AST 임베딩을 통합. Klein은 인메모리 AST 검색, Augment Code는 벡터 인덱싱과 맞춤 모델을, Sourcegraph·Cursor·warp.dev는 각기 다른 하이브리드 방식을 채택한다.

[03:16] 클라우드 코드는 사전 인덱싱을 하지 않지만 클라우드.MD 파일을 통해 코드베이스의 지도 역할을 하는 코드 맵을 생성하고 유지하며, 이를 통해 검색 시작점을 파악할 수 있습니다.

[03:47] 루트 코드는 최근 코드베이스 인덱싱을 출시했으며, 텍스트 임베딩과 시맨틱 검색을 사용하면서 AST 기반 임베딩도 활용해 스마트한 청킹을 구현하여 품질 차이를 만들어냅니다.

[04:09] 루트 코드는 잘 구축된 코드베이스 인덱싱과 리플 루프를 모두 가지고 있어 파일 검색, 읽기, 평가를 연속적으로 수행할 수 있으며, 시맨틱 검색은 이러한 리플 루프의 시작점을 파악하는 데 도움을 줍니다.

[04:31] 클라인의 경우 소스 코드를 조사한 결과, GitHub에서 클라인의 코드 검색이 트리 시터 라이브러리를 통한 추상 구문 트리를 사용해 구현된다는 것을 발견했습니다.

[04:55] 파일을 AST로 파싱하고 관련 코드 요소를 추출하는 주요 로직이 tree-sitter/index.ts에 있으며, parse_file 함수가 파일 내용을 AST로 파싱하고 언어별 쿼리를 적용합니다.

[05:16] 가장 높은 수준에서 보면 클라인은 기본적으로 루 코드가 하는 일을 하지만 인덱스를 사용하지 않으며, 여전히 RAG(검색 증강 생성)이지만 단지 벡터 검색과 인덱싱이 아닐 뿐입니다.

[05:41] 용어가 혼재되어 있다고 느끼며, 이 글의 용어 사용이 부정확하다고 지적하면서도 정확성을 위해 피드백을 요청합니다.

[06:03] 클라인의 방식도 여전히 검색과 RAG이며, 단지 벡터 검색을 하지 않고 인덱스를 구축하지 않을 뿐이고, 임시적인 AST나 인메모리 트리를 적시에 생성하고 버리는 방식을 사용한다고 설명합니다.

[06:30] 두 접근 방식의 핵심 차이점을 설명합니다. 한쪽은 인덱스를 로컬에 저장하고 보관하는 반면, Klein은 인덱스를 저장하지 않지만 여전히 트리를 구축하고 청킹하여 검색합니다.

[06:51] Augment Code는 블랙박스 형태의 비공개 툴로 구현 방식 파악이 어렵지만, 개인적으로 사용해본 것 중 최고의 성능을 보여줍니다. 벡터 인덱싱과 RAG를 사용하며 재인덱싱 속도가 매우 빠릅니다.

[07:22] Augment Code는 표면적 유사성보다 '도움이 되는 것'에 최적화되어 있다고 합니다. 이는 Root Code의 의미 검색 방식과 차별화되는 흥미로운 접근법으로, 프로그래머에게 제공되는 품질에 초점을 맞춥니다.

[08:11] Sourcegraph Cody는 기업에서 널리 사용되는 툴로, 전통적인 코드 검색 방식을 사용합니다. 하이브리드 RAG 형태로 벡터 임베딩뿐만 아니라 심볼릭 코드 검색과 코드 그래프를 활용하는 강력한 도구입니다.

[08:56] Cursor는 완전한 벡터 임베딩과 RAG를 사용하며, 어웨어 청킹 기능도 제공합니다. 보안을 위해 클라우드에는 임베딩과 메타데이터만 저장하고, 실제 코드는 클라이언트에서 읽어오는 방식을 사용합니다.

[09:29] 코드베이스 인덱싱에서 AST 기반 청킹과 warp.dev의 구현 방식을 설명합니다. AST 기반 청킹은 무작위 토큰이 아닌 코드의 논리적 부분을 기반으로 하며, warp.dev는 클라우드 동기화를 통한 전통적인 RAG 방식을 사용합니다.

[10:11] 인간이 새로운 코드베이스에서 작업하는 방식을 설명합니다. 새 직장에서 알 수 없는 코드베이스를 탐색할 때는 관련 용어를 검색하고, 읽고, 클릭하며 점진적으로 필요한 부분을 찾아가는 과정을 거칩니다.

개발자가 낯선 코드베이스에서 검색·클릭·읽기 과정을 거쳐 목표 파일을 찾아가듯, AI도 인덱싱 없이 매번 미지의 상태에서 시작한다. 인덱싱은 이 간극을 줄여 즉시 적절한 파일에 도달하도록 돕는다.

[10:55] 숙련된 개발자가 친숙한 코드베이스에서 작업하는 방식을 대조적으로 설명합니다. VS Code에서 Ctrl+P로 직접 파일을 열고, 함수 이름을 기억해서 바로 이동하여 코드베이스 탐색 없이 즉시 작업을 시작할 수 있습니다.

[11:19] AI의 코드베이스 인식 한계와 코드베이스 인덱싱의 필요성을 설명합니다. AI는 첫 쿼리나 컨텍스트 제공 전까지 코드베이스를 전혀 모르는 상태이므로, 알려지지 않은 상태에서 알려진 상태로의 격차를 해소하는 것이 핵심입니다.

[11:49] 코드베이스 인덱싱을 통해 검색과 탐색 단계를 건너뛰고 바로 코드 작성 단계로 이동하는 것이 목표라고 설명합니다. 의미적 검색을 통해 중요도 기반의 가중치가 적용된 결과를 제공하는 방식으로 이를 달성할 수 있습니다.

[12:25] 코드베이스 인덱싱에서는 중요도에 따라 가중치가 적용된 검색 결과를 반환하고, 이를 반복적으로 읽고 평가하는 Ripple 루프 방식을 사용한다.

[12:41] 화자는 이런 반복적 검색 방식이 코드베이스 인덱스 버전보다 더 비용이 많이 들 것이라는 이론을 가지고 있었고, 이를 검증하기 위해 테스트를 설계했다.

모호한 질문과 함수 호출 흐름 분석 테스트를 통해 Root Code, Klein, Augment Code의 비용·속도·정확도를 비교했다. 모든 도구가 정확했으나, 문맥이 부족할수록 인덱싱 도구가 비용과 시간을 크게 절감했다.

[12:49] 테스트 환경은 100MB 크기의 코드베이스에 2500개 파일로 구성되었고, 라이브러리나 git ignore 파일들은 제외했으며, 모든 테스트에서 Claude Sonnet 모델을 사용했다.

[13:30] 첫 번째 테스트로 모호하지만 답할 수 있는 질문을 선택했고, 1년 전이라면 이런 질문에 정확히 답하는 AI 도구를 찾기 어려웠을 것이라고 언급했다.

[13:48] 세 가지 도구 모두 정확한 답을 제공했지만, 시간과 비용에서 차이가 있었다. Root Code는 20센트, Klein은 15센트, Augment Code는 약 12센트의 비용이 발생했다.

[14:19] Root Code에서 비효율성을 발견했는데, 코드베이스 검색으로 좋은 결과를 찾았음에도 불구하고 추가 API 호출을 하여 불필요한 비용이 발생했다.

[14:48] Klein은 계획과 실행 모드만 있어서 Root Code의 작업 내 오버헤드가 없었고, 결과적으로 비용과 속도가 거의 동일했지만 Augment Code가 훨씬 빨랐다.

[15:21] Augment Code는 에이전트 모드에서 테스트했으며, 필요한 도구들을 제공하면서도 코드 작성은 하지 않도록 설정하여 순수하게 질문 답변 성능을 평가했다.

[15:32] AI 코딩 도구들의 성능 비교에서 어그먼트 코드가 속도와 정확성 면에서 우수한 결과를 보였습니다. 특히 구체적인 질문에 대해 다른 도구들보다 빠르고 정확하게 답변했습니다.

[15:57] 각 도구들의 답변 방식을 분석한 결과, 클라인과 루트 코드는 추가 정보를 제공하는 경향이 있는 반면, 어그먼트 코드는 질문에 직접적으로 답변하며 토큰 사용량이 적었습니다.

[16:47] 두 번째 테스트에서는 사용자가 새 채팅을 시작할 때의 함수 호출과 데이터 흐름에 대해 질문했습니다. 이는 검색하기 어려운 복잡한 질문으로, 모든 도구가 놀랍게도 완벽하게 답변했습니다.

[17:32] 복잡한 질문에 대한 성능 결과: 루트 코드는 28센트로 훌륭한 요약을 제공했고, 클라인은 45센트로 가장 비쌌지만 역시 좋은 요약을 했으며, 어그먼트 코드는 12센트로 가장 빠르고 정확했습니다.

[18:12] 결론적으로 맥락이 적고 검색이 어려운 질문에서는 코드베이스 검색 기능이 훨씬 효과적으로 작동하며, 비용과 속도 면에서 상당한 차이를 만들어낸다는 것을 확인했습니다.

일반 검색에는 RAG 기반 도구도 무난하지만, 희귀·추상적 질문에는 코드베이스 인덱싱이 유의미한 성능 향상을 제공한다. Augment Code 수준의 최적화 솔루션 부재를 지적하며, AI 에이전트 개발 시 인덱싱 방안을 고도화할 필요를 강조한다.

[18:46] 코드베이스 인덱싱의 효과는 질문의 유형에 따라 달라진다. 검색하기 쉬운 질문이라면 Klein도 충분하지만, 모호하고 맥락이 적은 질문에서는 인덱싱이 매우 유용하다.

[19:22] Augment Code는 답변 속도와 품질 면에서 압도적으로 뛰어나다. 수십 번의 테스트에서 거의 모든 경우에 승리했고, 더 적은 토큰으로 더 빠른 결과를 제공한다.

[20:05] AST 기반 청킹을 통한 코드베이스 인덱싱은 상당한 가치를 제공한다. 하지만 현재 Augment Code 수준의 오픈소스 솔루션은 존재하지 않는다.

[20:35] 무작정 토큰 청킹은 문제가 있지만, 적절한 청킹 방식은 성능을 크게 개선한다. 코드베이스를 인덱싱하지 말라는 주장보다는 최적의 인덱싱 방법을 고려해야 한다.

[21:31] 코드베이스가 커질수록 시간과 토큰 비용이 중요한 문제가 된다. 빠른 파일 접근은 시간과 비용을 절약한다. Klein도 기술적으로는 검색과 RAG를 사용하므로 정의를 명확히 해야 한다.

[00:00] 코드베이스 인덱싱이 이렇게

[00:02] 논란이 되는 주제인지 몰랐어요

[00:05] 이 글, 이 블로그 포스트를 보기 전까지는요

[00:08] 닉 발만이 작성한 클라인이 왜

[00:11] 코드베이스를 인덱싱하지 않으며

[00:14] 그것이 왜 좋은지에 대한 글이에요. 알다시피

[00:18] 오그먼트 코드는 제가 가장 좋아하는

[00:20] 에이전트 중 하나인데, 그 이유는 코드베이스 컨텍스트 때문입니다

[00:23] 대화할 수 있고, 엄청나게 빠르고

[00:26] 질문에 답하는 능력이 뛰어납니다

[00:27] 그래서 이 영상에서 몇 가지를 다뤄보려고 합니다

[00:29] 하나는 이런 에이전트들이

[00:32] 실제로 사용하는 접근 방식의 차이점들입니다

[00:34] 그리고 두 번째로는

[00:36] 제가 수행한 몇 가지 테스트를

[00:37] 보여드리고 싶습니다. 매우 유사한 쿼리나

[00:39] 동일한 쿼리를 다른 AI 코딩 에이전트들에서

[00:41] 실행했습니다. 예를 들어

[00:44] Rue 코드에서 실행했고, 클라인에서도 실행했고

[00:47] 오그먼트 코드에서도 실행했습니다. 가격도 비교하고

[00:50] 시간도 비교하고 정확도도 비교했습니다

[00:52] 하지만 조금 뒤로 돌아가서

[00:56] 이 글에 대해 제가 완전히

[00:58] 동의하지 않는 부분들이 있습니다

[01:01] 클라인이 실제로 어떻게

[01:03] 코드베이스 탐색을 구현하는지에 대한

[01:05] 세부사항을 파고들면

[01:07] 이해하기 위해 꽤 많은 시간을

[01:08] 투자해서 파헤쳐봤는데

[01:10] 보게 될 것은 그들도 여전히

[01:13] RAG를 사용한다는 것입니다. 단지 인덱싱을

[01:16] 사용하지 않을 뿐이죠. 그래서

[01:19] 그들이 글에서 언급하는 것 중 하나가

[01:21] 코드는 청크 단위로 생각하지 않는다는 것입니다

[01:24] 그래서 제 질문은 청크가 무엇인가요?

[01:26] 가장 단순한, 가장 무식한

[01:28] 구축 방식은 그냥 토큰 수입니다

[01:30] 512 토큰, 256 토큰

[01:33] 1024 토큰, 뭐든지 간에. 또는

[01:37] 논리적인 코드 그룹이 될 수도 있습니다

[01:39] 함수가 될 수도 있고, 코드가 어떻게

[01:41] 함께 그룹화되어야 하는지가 될 수도 있습니다

[01:43] 그리고 바로 여기서 AST가 등장합니다

[01:47] 이것은 실제로 추상 트리를

[01:49] 구축하는 메커니즘입니다

[01:52] 그리고 이것이 추상적인 이유는 모든 주석을

[01:54] 제거하기 때문입니다. 모든 공백을 제거하고

[01:56] 심지어 불필요한 괄호 같은

[01:58] 것들까지 제거할 수도 있습니다

[02:01] 그리고 코드를 트리 형식으로

[02:04] 함께 그룹화해서

[02:06] 논리적이고 읽기 쉬운 방식으로 청크화할 수 있게 합니다

[02:10] 그래서 제 초기 구현에서 발견한 것은

[02:14] 무작정 청크화할 때

[02:16] 전통적으로, 알다시피, 가장 무식한 방법인

[02:20] 512 문자나 토큰마다

[02:22] 그냥 청크화하면

[02:26] 이상한 경계에서 끝날 수 있다는 것입니다

[02:28] 아주 간단한 함수에서

[02:30] sum equals a plus b * 2 같은 경우에

[02:32] 이상한 지점에서 청크화가

[02:35] 일어날 수 있는데, 실제 구현에서는

[02:38] 함께 그룹화됩니다. 그래서 인덱서가

[02:41] 훨씬 더 잘 작동할 수 있습니다. 검색이

[02:44] AST 구현에서 훨씬 더 잘

[02:46] 작동할 수 있습니다

[02:48] 그래서 이것을 좀 더 자세히 파고들면

[02:51] AST를 함수, if 문, 이진 표현식

[02:54] 같은 구문적 구조에 대응하는

[02:58] 노드들로 생각할 수 있습니다

[03:01] 등등 말이죠. 그래서

[03:04] 이것을 염두에 두고, 이제

[03:07] 각각의 AI 코딩 에이전트들이

[03:09] 실제로 어떻게 하는지 살펴보고 생각해봅시다

[03:13] 그래서 클라우드 코드는

[03:16] 사전에 인덱싱을 하지 않지만,

[03:19] 클라우드.MD 파일을 가지고 있어서

[03:22] 생성하고 최신 상태로 유지할 수 있습니다.

[03:25] 슬래시넷으로 생성하죠.

[03:27] 코드베이스의 지도 같은 거예요.

[03:29] 바로 코드 맵이죠. 이런

[03:31] 코드 맵이 정말 도움이 되는데,

[03:33] 루트 클라우드 코드가 실제로

[03:36] 이걸 읽고 어디서부터 찾기 시작할지

[03:38] 알 수 있거든요. 이게 바로 이런 타입의

[03:41] 검색의 핵심인데, 바로

[03:43] 올바른 위치에서 검색을 시작하는 방법이죠.

[03:46] 루트 코드는 최근에 코드베이스 인덱싱을

[03:49] 출시했습니다. 텍스트 임베딩과 시맨틱

[03:52] 검색을 사용하지만 AST 기반

[03:54] 임베딩도 가지고 있어요. 즉,

[03:56] 스마트하게 청킹한다는 뜻입니다.

[03:58] 맹목적으로 청킹하지 않아요.

[04:00] 이는 맹목적 청크 구현과

[04:02] AST 기반 구현 사이에

[04:05] 품질적으로 큰 차이를 만듭니다.

[04:08] 제 생각에는 두 세계의

[04:09] 장점을 모두 활용하는 방식이에요.

[04:12] 정말 잘 구축된 코드베이스 인덱싱을

[04:14] 가지고 있으면서 동시에

[04:17] 정말 좋은 코드베이스 리플 루프도

[04:19] 가지고 있어서, 실제로 파일을 검색하고

[04:21] 읽고, 평가하고, 계속 진행할 수 있죠.

[04:23] 그리고 시맨틱 검색이 여기서

[04:26] 실제로 해주는 일은 그 리플 루프를

[04:29] 어디서 시작할지 파악하는 것입니다.

[04:31] 반면 클라인은 소스 코드를

[04:32] 좀 파헤쳐봐야 했어요.

[04:35] 파헤쳐보다가 GitHub에서 이 글과

[04:39] 질문을 발견했는데, 그들이 말하길

[04:42] 클라인의 코드 검색은

[04:46] 트리 시터 라이브러리를 통한 추상 구문 트리를

[04:49] 사용해서 구현된다고 했어요. 이는

[04:53] 루 코드가 임베딩에 사용하는 것과

[04:55] 다르지 않습니다.

[04:58] 파일을 AST로 파싱하고 관련 코드 요소를

[05:02] 추출하는 주요 로직은

[05:06] 그들의 tree-sitter/index.ts에 있어요.

[05:08] 파일의 parse_file 함수가

[05:11] 파일 내용을 AST로 파싱하고

[05:15] 언어별 쿼리를 적용합니다.

[05:16] 가장 높은 수준에서 생각해보면

[05:20] 클라인은 기본적으로 루 코드가 하는 일을

[05:25] 하고 있지만

[05:27] 인덱스를 사용하지 않아요. 그래서

[05:29] 제가 이것에 대해 문제를 느끼는 건

[05:33] 여전히 RAG라는 점이에요. 검색과 RAG죠.

[05:37] 단지 벡터 검색과 인덱싱이

[05:38] 아닐 뿐이에요. 여기서 용어들이

[05:41] 매우 혼재되어 있다고 느껴져서

[05:42] 여기서 명확히 하고 싶은 점은

[05:45] 용어가 잘못되었다는 것입니다.

[05:47] 이 글이 그런 면에서

[05:49] 적중하지 못했다고 생각해요.

[05:51] 지나치게 비판적이려는 건 아니지만

[05:53] 실제 정확성 관점에서

[05:55] 이런 것들에 대해 이야기하는 게

[05:57] 중요합니다. 제가 틀린 부분이 있다면

[05:58] 아래 댓글로 알려주세요.

[06:00] 최대한 정확하게 하고 싶거든요.

[06:03] 여전히 검색이고

[06:04] 여전히 RAG입니다.

[06:07] 단지 벡터 검색을 하지 않고

[06:10] 인덱스를 구축하지 않을 뿐이에요.

[06:12] 정말로 생각해보면 임시적인 AST 같은

[06:14] 거예요. 인메모리 트리 같은 건데

[06:18] 기본적으로 생성되고

[06:21] 버려지는 거죠. 적시에 필요한 걸

[06:24] 그 시점에 생성하는 방식이에요.

[06:25] 여전히 검색과 RAG를 사용하고

[06:28] 이건 중요한 부분이라고 생각합니다.

[06:30] 주목해야 할 차이점은

[06:33] 이 두 접근 방식 간의 차이점인데, 우리는

[06:35] 인덱스를 로컬에 저장하고 보관하는 반면

[06:41] Klein에서는 인덱스를 저장하지 않지만

[06:43] 여전히 트리를 구축합니다.

[06:45] 여전히 청킹하고 검색하죠.

[06:47] 이해가 되시나요?

[06:48] 그럼 좋겠네요. 이제 Augment Code는

[06:51] 좀 까다롭습니다.

[06:52] 이런 블랙박스 형태의 모든) 툴들처럼

[06:56] 회사에서 통제하는

[06:58] 오픈소스가 아닌 경우

[07:01] 구현 방식을 파악하기가 훨씬 어렵습니다.

[07:03] 하지만 Augment Code는 제가 개인적으로 사용해본 것 중

[07:05] 단연 최고입니다.

[07:08] 이런 것들 중 많은 부분이 제 추론이죠.

[07:10] 벡터 인덱싱을 사용한다고 생각하고

[07:12] 여기서 RAG 구현을 사용한다고 생각하지만

[07:14] 속도가 얼마나 빠른지 보면

[07:16] 고도로 최적화되어 있다는 것도 알 수 있습니다.

[07:18] 재인덱싱이 엄청나게 빠르거든요.

[07:21]

[07:22] 추측하건대 의미 검색을 사용할 것 같지만

[07:25] 뒤에서 커스텀 모델들을 사용한다고 생각합니다.

[07:27] 실제로 그들이 말한 인용구를 찾았는데

[07:30] 그들은 표면적 유사성보다

[07:32] 도움이 되는 것에 최적화되어 있다고 했습니다.

[07:35] 그러니까

[07:38] Augment Code와 Root Code의 차이점을

[07:39] 생각해보면 이것은

[07:42] 그들이 말하는 표면적 유사성이나

[07:44] 의미 검색에 정말 초점을 맞추고 있는 반면

[07:47] Augment Code는

[07:49] 도움이 되는 것에 초점을 맞추고 있다는 것입니다.

[07:52] 이것은 꽤 흥미로운 사고방식이죠.

[07:54] 만약 정말로

[07:55] 코드베이스를 검색하는 새로운 모델을 구축하려고 한다면

[07:59] 도움이 되는 것을 어떻게 정량화할지 모르겠지만

[08:01] 표면적 유사성에 초점을 맞추지 않고

[08:04] 프로그래머에게 제공되는 품질에

[08:07] 초점을 맞추는 것이 훨씬 더 합리적입니다.

[08:09] 검색하는 사람에게 말이죠.

[08:11] 이제 Sourcegraph Cody는

[08:13] 실제로 기업에서 정말 많이 사용되는 툴입니다.

[08:15] 사실 제가 이전에 다녔던 회사에서

[08:18] 실제로 Sourcegraph Cody를 사용했습니다.

[08:19] 지금은 좀 변했습니다.

[08:23] 그래서 제 지식이 구식일 수 있지만

[08:25] 제가 이해한 바로는

[08:28] 좀 더 전통적인 코드 검색 방식입니다.

[08:31] 하이브리드 RAG 같은 것이죠.

[08:32] 코드베이스의 인덱스가 있지만

[08:35] 단순한 벡터 임베딩 인덱스가 아닙니다.

[08:38] 그들은 이것을 심볼릭 코드 검색이라고 부르고

[08:40] 코드 그래프라고 합니다.

[08:42] 그래서 그들이 단지 다른 방식으로

[08:44] Augment Code가 하는 것과 비슷한 것을

[08:46] 설명한다고 생각합니다.

[08:48] 커스텀 모델이 있는지는 모르겠습니다.

[08:49] 그에 대한 정보를 찾을 수 없었거든요.

[08:51] 하지만 Sourcegraph Cody는

[08:54] 실제로 정말 강력한 도구입니다.

[08:56] 이제 Cursor는 완전한 벡터 임베딩을 사용합니다.

[09:00] RAG를 사용하지만

[09:03] 제가 찾을 수 있는 모든 문서에서

[09:06] 어웨어 청킹도 사용합니다.

[09:08] 코드베이스 같은 것을 할 때

[09:11] 쿼리를 임베딩하고 그 벡터로 검색합니다.

[09:13] 제가 알 수 있는 바로는 클라우드에

[09:17] 원시 코드를 저장하지 않습니다.

[09:18] 임베딩만 저장하고

[09:20] 파일 경로나 라인 번호 같은 것들만 저장한 다음

[09:22] 코드는 클라이언트 측에서 읽습니다.

[09:25] 그래서 보안 우려를 최소화합니다.

[09:28] 제가 찾은 정보가 맞다면 말이죠.

[09:29] 찾은 정보가 정확했습니다. 이제 AST 기반

[09:32] 청킹에 대해 다시 이야기해보죠. 우리가 조금

[09:34] 언급했던 부분인데요. 실제로는

[09:36] 단순한 무작위 토큰 개수가 아니라

[09:39] 코드의 논리적 부분을 기반으로

[09:40] 청킹을 수행합니다. 그리고 warp.dev도

[09:43] 코드베이스 인덱싱을 지원합니다. 그런데

[09:47] 정확한 구현 방식에 대한 문서를

[09:50] 많이 찾을 수 없었는데, 클라우드에

[09:52] 동기화하는 방식입니다. 아마도 전통적인

[09:56] RAG 방식의 인덱스 구축과

[10:00] 유사할 것 같습니다. 특별히

[10:03] 다른 동작을 보지는 못했고,

[10:05] 그냥 아마도 예를 들어

[10:07] Cursor에서 볼 수 있는 것과

[10:10] 유사한 구현일 것 같습니다.

[10:11] 이제 인간이 실제로 코드베이스를

[10:14] 어떻게 생각하는지 살펴보죠.

[10:16] 새로운 직장에 들어가서 첫 번째로

[10:18] 해야 할 일이 '이 티켓을

[10:20] 한번 봐보세요'라고 하는 상황을

[10:22] 생각해보세요. 온보딩이 끝나고

[10:23] 할 일이 생겼을 때, 여러분은

[10:26] 알 수 없는 코드베이스에서

[10:27] 작업해야 합니다. 그래서 올바른

[10:29] 경로로 안내해줄 수 있는

[10:32] 용어들을 검색하기 시작합니다.

[10:35] 읽기 시작하고, 클릭하고, 운이 좋으면

[10:37] 필요한 곳을 일찍 찾을 수도 있고

[10:39] 아니면 탐색하는 데 시간이

[10:41] 좀 걸릴 수도 있습니다.

[10:42] 때로는 코드베이스가 정말

[10:44] 거대할 수 있습니다. 저도

[10:45] 엄청나게 큰 프로젝트들에서 일해본

[10:48] 경험이 있습니다. 더 읽고, 더 클릭하고,

[10:50] 더 검색하다 보면 결국 실제로

[10:51] 코드를 작성할 수 있는 부분에 도달하게 됩니다. 지금 저는 운 좋게도

[10:55] 제가 매우 잘 알고 있는

[10:58] 코드베이스에서 작업하고 있습니다.

[10:59] 그래서 보통은 어떤 파일로

[11:01] 가야 하는지 알고 있습니다. VS Code에서

[11:03] Ctrl+P를 누르고 파일을 열고, F로

[11:05] 이동해서 찾고 싶은 라인으로 가거나

[11:09] 함수 이름을 대략 기억해서

[11:10] 그쪽으로 이동한 다음 기본적으로

[11:12] 코드를 읽기 시작하고 작성합니다.

[11:14] 코드베이스를 거의 탐색할

[11:16] 필요가 없습니다. 코드베이스 인덱싱에 대한

[11:19] 제 이론은 기본적으로 이 격차를

[11:23] 해소하는 것입니다. AI에 대해

[11:25] 생각해보면, 사실상 모든 지식이

[11:28] 알려지지 않은 상태입니다. AI는

[11:31] 첫 번째 쿼리를 보내고 컨텍스트를

[11:33] 제공하거나 Claude의 경우

[11:35] claude.md 파일을 통해 제공하기 전까지는

[11:38] 여러분의 코드베이스에 대해

[11:40] 아무것도 모릅니다. 즉, 그 코드베이스는

[11:42] AI가 무언가를 할 때마다

[11:43] 매번 알려지지 않은 상태입니다. 그렇다면

[11:46] 알려지지 않은 상태와 알려진 상태 사이의

[11:49] 격차를 어떻게 해소할까요? 제 머릿속의

[11:52] 아이디어이자 제가 Augment Code를

[11:54] 좋아하는 이유는 결과를 읽거나 스캔하거나

[11:58] 검색해서 찾아다니지 않고도

[12:01] 가능한 한 빨리 코드를 작성하는

[12:02] 부분에 도달하는 방법입니다.

[12:04] 그 이유는 알고 있는 코드베이스에서는

[12:07] 바로 파일로 이동하기 때문입니다.

[12:09] 그렇다면 어떻게 할까요? 제 생각과

[12:11] 이론으로는 코드베이스 인덱싱이

[12:14] 그 방법입니다. 코드베이스 인덱싱에 대해

[12:18] 생각해보면, 기본적으로 어떤 종류의

[12:21] 검색, 의미적 검색을 수행하게 되고

[12:23] 중요도의 가능성에 기반해서

[12:25] 가중치가 적용된 결과를 반환할 거예요

[12:27] 중요도의 가능성에 따라 가중치가 매겨진

[12:28] 결과들을 말이죠. 그러면 그걸 읽을 수 있어요.

[12:31] 이제 Ripple 루프의 경우 기본적으로

[12:34] 읽기-평가-출력 루프를 실행하게 되죠.

[12:36] 계속해서 반복적으로

[12:38] 같은 작업을 수행하면서

[12:39] 필요한 위치를 찾을 때까지 말이에요.

[12:41] 그래서 제 이론은 항상 이것이

[12:44] 코드베이스 인덱스 버전보다 더 비용이 많이 들 것이라는 거였어요.

[12:47] 이제 제가 하고 싶었던 테스트는

[12:49] 몇 가지 간단한 테스트를 구성하는 것이었어요.

[12:51] 너무 많이 들어가고 싶지는 않아요. 약 10개를 했지만

[12:54] 여기서는 몇 개만 얘기할 거예요

[12:56] 왜냐하면 각 접근 방식의

[12:57] 장단점에 대해 얘기할 예정이거든요.

[12:59] 제가 테스트하는 코드베이스는

[13:01] 엄청 크지는 않아요. 약 100메가바이트의 코드예요.

[13:03] 이것은 라이브러리나

[13:06] 그런 것들은 보지 않고 있어요.

[13:08] git ignore 항목들도

[13:10] 전혀 보지 않고 있어요.

[13:12] 약 2500개의 코드 파일이에요.

[13:14] 그리고 저는 클라우드 코드가 아닌

[13:16] Claude Sonnet을 사용하고 있어요.

[13:19] 거기 오타가 있네요. 그래서 저는

[13:21] Claude Sonnet을 모델로 사용하고 있어요

[13:23] 아래의 각각에서

[13:25] Augment Code도 동일한 모델을 사용한다고 가정하고요.

[13:27] 첫 번째 테스트에서는 모호한 질문을 하고 싶었어요

[13:30] 하지만 답할 수 있는 질문이어야 했죠.

[13:34] 1년 전으로 돌아가면

[13:36] 이 질문에 답할 수 있고 정확한

[13:39] AI 도구를 찾았다면

[13:42] 그때는 정말 놀랐을 거예요.

[13:45] 실제로는 세 가지 모두

[13:48] 정확하게 답했어요.

[13:50] 차이점은 시간과 비용에 있죠.

[13:54] 그리고 제가 말하고 싶은 것 중 하나는

[13:58] Root Code에서 질문 모드를 사용했고

[13:59] 비용이 20센트가 나왔어요.

[14:02] Klein은 15센트였고

[14:05] Augment Code는 약 12센트였어요

[14:08] 왜냐하면 제가

[14:10] 월 50달러를 지불한다면 추정해보면

[14:13] 호출당 약 12센트가 될 거거든요.

[14:16] 잠깐 다시 돌아가서 얘기하면

[14:19] Root Code에 일부 비효율성이 있다고 생각해요

[14:22] 특히 제가 이 메시지에서

[14:24] 위로 스크롤하면 실제로

[14:28] 코드베이스 검색을 했다는 걸 볼 수 있어요.

[14:30] 실제로 인덱스를 활용했어요.

[14:32] 좋은 결과를 찾았고, 그다음에

[14:35] 또 다른 검색을 했고 실제로

[14:38] 위쪽에서 답을 찾았는데

[14:40] 하지만 또 다른 API 비용을 지불했어요

[14:42] 실제로 작업을 수행하고

[14:46] 이 녹색 텍스트를 표시하기 위해서요

[14:48] Klein의 경우 계획과 실행 모드만 있고

[14:51] 저는 계획 모드에서 이걸 했어요

[14:54] 그래서 Root Code가 가진

[14:57] 작업 내 오버헤드가 없었어요.

[14:59] 조금 돌아가서 보면 비용은

[15:02] 거의 동일했어요. 이건 저를 놀라게 했죠.

[15:04] 속도 면에서도 거의 동일했어요.

[15:07] 결국 둘 다 매우 정확했고

[15:09] 답변이 매우 유사하다는 걸 볼 수 있어요

[15:12] 하지만 Augment Code는

[15:13] 훨씬 빨랐어요. 마치 한 단계 차이나게 빨랐죠.

[15:16] 기본적으로, 그리고 저는 에이전트 모드에서 이걸 했어요

[15:21] 필요한 도구들을 제공하고 싶었거든요

[15:24] 그리고 코드를 작성하지 말라고 했고

[15:26] 그다음에 질문을 제공했어요

[15:29] 코드를 작성하지 말라고 했고

[15:31] 그다음에 질문을 제공했어요

[15:32] 질문을 했습니다.

[15:34] 그리고 정말 놀랍도록 빠르고

[15:36] 실제로 질문에 답했다고 말할 수 있습니다.

[15:39] 다른 도구들만큼 완전하지는 않았지만요.

[15:43] 질문에 정확하게 답했습니다.

[15:46] 저는 세그먼트가 무엇인지 말해달라고 하지 않았어요.

[15:49] 초기 시작 세그먼트를 어디서 생성하는지 물었습니다.

[15:53] 로열티 세그먼트가 아니라요.

[15:55] 로열티 세그먼트.

[15:57] 그것들이 무엇인지, 무엇을 하는지,

[16:00] 어떻게 작동하는지 묻지 않았어요. 클라인과

[16:02] 루트 코드는 저에게 그

[16:04] 정보를 제공하기로 결정했습니다. 반면 어그먼트 코드는 정말로

[16:07] 여기서 일어나는 곳으로 들어갔어요.

[16:09] 트리거 포인트들이 여기 있고 그리고

[16:12] 실제로 거기에 코드의 일부

[16:13] 요약이 있었지만, 그렇게 자세히

[16:15] 들어가지는 않았어요. 그래서 토큰 사용량이

[16:17] 훨씬 낮았습니다. 하지만 저는

[16:21] 클라인과 루트 코드 둘 다 저에게 좀 더

[16:23] 많은 정보를 주었다는 점이 좋았어요. 하지만 이 경우에는

[16:26] 무승부라고 하겠습니다. 속도는, 둘 다 시간을 재봤는데

[16:29] 둘 다 동일한 시간이었어요.

[16:31] 몇 초 차이로요.

[16:33] 루트 코드가 실제로 약간

[16:35] 클라인보다 먼저 도달했다고 생각해요. 음 또는

[16:38] 그 반대였을 수도 있고, 기억이 안 나요. 그리고 둘 다

[16:40] 매우 정확했습니다. 그리고 물론

[16:42] 어그먼트 코드가 이것에서 꽤

[16:44] 압도적으로 승리했어요. 이제 두 번째 테스트로

[16:47] 이것은 제가 또한 매우

[16:50] 관심이 있었던 것입니다.

[16:52] 사용자가 새로운 채팅을 시작할 때

[16:53] 호출되는 모든

[16:55] 함수들과 데이터가 어떻게

[16:56] 사용자에게 다시 돌아가는지 안내해 주실 수 있나요? 여기서

[16:58] 검색 용어들을 생각해보세요. 채팅,

[17:02] 아마도

[17:04] 뭐? 사용자. 아니요, 그것도 좋지 않아요. 데이터.

[17:07] 정말로, 여기서 검색할 수 있는 게

[17:08] 별로 없어요. 그래서 어느 정도

[17:11] 맥락을 수집해서 이해해야 합니다

[17:15] 이 특정한 것이 어떻게

[17:17] 작동하는지의 흐름을요. 그리고 이것도 1년 전으로 돌아간다면

[17:21] 저는 이 에이전트들 중 어느 것이라도

[17:23] 실제로 그것에 답할 수 있다면 깜짝 놀랐을 것입니다.

[17:25] 그리고 사실은

[17:27] 세 개 모두 그것에

[17:29] 완벽하게 답했다는 것입니다. 다시, 이제 루트 코드가

[17:32] 답했어요. 그리고 저는 이 테스트들을

[17:34] 여러 번 실행했고 각각에 대해 대충

[17:37] 중간 수준의 것을 선택했습니다. 그래서

[17:39] 루트 코드는 결국 28센트로

[17:41] 답했고 어떻게 흘러가는지에 대한 훌륭한 요약이었어요.

[17:45] 정말 훌륭했습니다.

[17:47] 클라인은 확실히 3위였어요.

[17:51] 가장 느렸어요. 45센트가 들었고

[17:55] 하지만 다시 말하지만 핵심적인 요약은

[17:59] 역시 훌륭했습니다. 그리고 어그먼트 코드도

[18:03] 매우 매우 정확하고, 매우 매우 빨랐어요.

[18:06] 다시 1위였죠. 비용도 1위

[18:09] 다시 12센트로 정확했어요. 그래서 이

[18:12] 특정한 경우에, 이런 질문들에서

[18:15] 매우 적은 맥락으로, 매우 적은

[18:17] 검색으로, 실제로 검색될 수 있는 것이 매우 적을 때

[18:20] 코드베이스 검색 기능이

[18:24] 실제로 이 특정한 경우에 훨씬 더 잘 작동한다는 것이 명확했습니다

[18:27] 실제로

[18:29] 뭐냐면 3분의 2 비용이거나

[18:31] 수학을 해봐야겠지만

[18:33] 가격과 속도에서 충분히 상당한 차이가 있어서

[18:35] 실제로 차이를 만든다는 것입니다.

[18:38] 그래서 몇 가지 테스트를 더 한 후 이 모든 것에 대한 저의 결론은

[18:41] 정말로

[18:43] 그것이 실제로

[18:46] 질문의 유형에 따라 다르다고 생각합니다.

[18:48] 만약 검색하기 쉽고, 찾기 쉬운 질문이라면

[18:51] 코드베이스에서 실제로 쉽게 찾을 수 있는 것이라면

[18:54] Klein은 완전히 괜찮습니다.

[18:56] 비교적 같은 속도로 수행하고

[18:59] 코드베이스 인덱싱이 꼭 필요하지는 않습니다.

[19:01] 하지만 조금 더 모호한 것을 하고 있다면

[19:04] 실제로 검색할 것들의 맥락이 거의 없는

[19:07] 아주 작은 맥락으로 무언가를 하고 있다면

[19:10] 코드베이스 인덱싱이 실제로 매우 잘 작동한다는 것을 발견할 것입니다.

[19:14] 그리고 또 다른 결론은

[19:15] Augment Code에는 뭔가 마법 같은 것이 있다는 것입니다.

[19:18] 이런 질문들에 답하는 방식과

[19:20] 그 속도가 정말 빠르다는 점이요.

[19:22] 제가 한 모든 테스트에서

[19:24] Augment Code가 이겼습니다.

[19:25] 아, 잠깐, 그건 취소하겠습니다.

[19:28] 제가 한 여러 테스트 중에서

[19:31] 한 번 Augment Code가 멈춘 적이 있었습니다.

[19:34] 그래서 중단하고 테스트를 다시 시작했는데

[19:35] 다른 둘이 먼저 끝났고

[19:36] Augment Code는 락업되거나 뭔가 문제가 생겼습니다.

[19:39] 하지만 제가 Augment Code로만 한

[19:41] 수십 번의 실행에서

[19:43] 모든 경우에서 이겼습니다.

[19:45] 압도적으로 빨랐고

[19:48] 이론적으로 더 저렴하고

[19:50] 전체적으로 훨씬 적은 토큰을 생성했습니다.

[19:52] 따라서 Augment Code 실행이 그렇게 비쌀 것 같지는 않습니다.

[19:56] 다시 주요 전제로 돌아가서

[19:58] 이런 논란이 있는 주제에 대해

[20:00] 저는 코드베이스 인덱싱이라는 결론에 도달했습니다.

[20:02] 특히 AST 타입 청킹을 사용하는 것이

[20:05] 실제로 많은 가치를 제공할 수 있다고 생각합니다.

[20:07] 하지만 동시에 오픈소스 솔루션이 없다는 점에 있습니다.

[20:10] Augment Code와 같은 수준의 솔루션이 없습니다.

[20:14] 그들의 것은 정말 놀랍습니다.

[20:17] 하지만 코드베이스를 인덱싱하지 않는 것이

[20:20] 좋은 일이라고 말할 수는 없다고 생각합니다.

[20:22] 왜냐하면 무작정 토큰 섹션을 가져와서

[20:24] 청킹하는 것이 좋지 않을 수도 있기 때문입니다.

[20:28] 맞습니다, 그것을 집어넣는 것 말이죠.

[20:30] 저는 그것에 동의할 수 있습니다.

[20:34] 하지만 청킹이 그것을 개선합니까?

[20:35] 상당히 개선합니다.

[20:38] Augment Code의 접근 방식은 어떨까요?

[20:40] 훨씬 더 상당히 개선합니다.

[20:43] 그래서 코드베이스를 인덱싱하지 말아야 한다는

[20:45] 입장이 완전히 좋다고 생각하지는 않습니다.

[20:47] 실제로 코드베이스를 최적으로 인덱싱하는 방법을

[20:50] 고려해야 한다고 말하고 싶습니다.

[20:53] 오늘 AI 에이전트를 구축한다면

[20:55] 다음 단계는 무엇일까요?

[20:58] AST 기반 청킹에서

[21:00] Augment Code가 하는 것과 같은 수준으로

[21:02] 어떻게 갈 수 있을까요?

[21:04] 도움이 되는 것을 우선시하는 곳으로 말이죠.

[21:07] 다시 말하지만, 그것이 어떻게 작동하는지

[21:08] 정확히 모르겠습니다.

[21:11] 앉아서 그런 것을 어떻게 설계할지

[21:13] 생각해봐야 하지만

[21:16] 코드베이스 인덱싱이 필요한

[21:18] 미래가 있다고 생각합니다.

[21:21] 코드베이스가 점점 커져간다고 상상해보세요.

[21:24] 사람들은 이런 인식을 구축하고 있습니다.

[21:25] 아, 그냥 읽고 검색하고

[21:26] 필요한 것은 무엇이든 할 수 있다고

[21:28] 컨텍스트가 너무 크기 때문에 말이죠.

[21:31] 하지만 두 가지 단점이 있습니다.

[21:34] 하나는 시간입니다.

[21:36] 시간은 돈이고, 다른 하나는

[21:38] 실제로 그것을 하기 위한

[21:40] 실제 토큰 비용입니다.

[21:42] 제 생각에는 파일에 더 빨리 도달할 수 있다면

[21:43] 시간을 절약하고, 이는 많은 돈을 절약합니다.

[21:45] 그리고 제가 말하고 싶은 다른 것은

[21:48] 말하는 방식에 조금 주의해야 한다는 것입니다.

[21:50] 왜냐하면 Klein은 기술적으로

[21:53] 검색과 RAG를 사용하고 있기 때문입니다.

[21:55] 단지 인덱싱을 사용하지 않을 뿐입니다.

[21:57] 그래서 그 포스트를 다시 생각해보거나

[22:00] 그 포스트를 업데이트해서

[22:02] 강조하거나 설명하는 것이 좋을 것 같습니다.

[22:04] 왜냐하면 그들이 그런 정의의 경계를

[22:06] 매우 명확하지 않게 밀어붙이는 것이

[22:08] 조금 위험하다고 생각하기 때문입니다.

[22:10] 대담한 입장을 취하는 것은 항상 감사하지만

[22:15] 이것은 제가 모든 에이전트를 살펴보는 관점에서

[22:17] 동의하기 어려운 입장 중 하나라고 생각합니다.

[22:19] 어쨌든, 충분히 길게 이야기한 것 같습니다.

[22:21] 이것이 도움이 되었기를 바라며

[22:24] 뭔가 배웠거나

[22:25] 제가 여기서 정리한 것을 감사하게 여긴다면

[22:27] 제 채널을 구독하거나

[22:30] 동영상에 좋아요를 눌러주시면

[22:31] 정말 감사하겠습니다.

[22:34] 어쨌든, 모두 좋은 하루 보내시기 바랍니다.

[22:36] 다음 시간까지

[22:38] 모두들 안녕히 계세요.

[22:40] 평화롭게.

[22:41]

[22:43]

[22:45]

[22:47]

[22:49]

[22:50]

[22:53]

[22:54]