거창한 RAG 대신 확실한 grep

1인 사업 초기에는 RAG보다 grep이 낫습니다

AI 시대의 트렌드 키워드들이 있습니다. RAGRetrieval Augmented Generation​, ADRArchitecture Decision Record​, 벡터 DB, MCP, 에이전트 워크플로. 컨퍼런스에서 다루고, 뉴스레터에서 추천하고, 빅테크가 자랑합니다. 1인 개발자, 1인 사업자가 AI 워크플로를 세팅한다고 하면 자연스럽게 이런 키워드들로 손이 갑니다.

그런데 지금 막 시작한 사람에게 이게 정말 필요한가. 결론부터 말하면, 대부분의 경우 grep으로 충분합니다.

grep이 뭔가요

grep은 텍스트 파일에서 특정 단어나 패턴을 찾아주는 가장 기본적인 명령어입니다. 1973년에 만들어진 도구입니다. 50년 넘게 거의 모든 운영체제에 깔려 있습니다. 추가 설치 없이, 별도 인프라 없이, 그냥 폴더에서 바로 씁니다.

grep -r "사업 매출 전략" ~/projects/

이 한 줄이 모든 파일을 뒤져서 해당 문구가 들어간 곳을 보여줍니다. 임베딩도, 벡터 DB도, 청킹도 필요 없습니다. AI 시대에 가장 트렌디하지 않은 도구지만, 가장 빠르게 작동합니다.

클로드 코드, 커서, 깃허브 코파일럿 같은 AI 도구도 내부적으로 grep과 비슷한 텍스트 검색을 가장 먼저 씁니다. 정확한 키워드로 찾을 수 있는 건 굳이 임베딩으로 의미 검색을 할 필요가 없기 때문입니다.

RAG가 과잉 투자가 되는 세 가지 이유

자료의 절대량이 부족합니다.

RAG의 가치는 자료가 너무 많아서 사람이 찾기 어려울 때 나옵니다. 위키 페이지 5,000개, 고객 문의 10만 건, 사내 매뉴얼 PDF 수백 개. 이런 규모에서는 키워드 검색의 한계가 분명합니다. "환불 정책에 대한 고객 응대 톤"을 찾으려면 단순 키워드로는 안 됩니다.

1인 사업 초기의 자료는 그렇지 않습니다. 100~300개 정도의 문서. 대부분 본인이 쓴 것이고, 본인이 어디에 뒀는지 대략 기억합니다. 이 규모에서 RAG를 까는 건, 책 100권 있는 집에 도서관 사서를 고용하는 것과 같습니다.

구축 비용이 진척을 갉아먹습니다.

RAG 구축은 기술적으로 복잡합니다. 임베딩 모델 선택, 청킹 전략(어떤 단위로 자를 것인가), 벡터 DB 설정(파인콘? 큐드런트? 슈퍼베이스 벡터?), 재순위화(Re-ranking) 적용 여부, 검색 결과의 컨텍스트 윈도우 관리. 각 단계마다 의사결정이 필요하고, 시행착오가 따릅니다.

1인 사업자에게 1~2주는 막대한 시간입니다. 그 1~2주에 MVP를 다듬거나, 첫 고객을 만나거나, 마케팅 콘텐츠를 만들 수 있습니다. RAG가 없어서 사업이 안 되는 게 아닙니다. 제품과 고객이 없어서 사업이 안 됩니다.

단순한 폴더 구조와 ADR-0001 한 장이면 grep과 차이가 없습니다.

거버넌스를 정교하게 만들겠다고 ADR을 여러 개 쓰고, 폴더 구조를 5단계로 나누고, 메타데이터 규칙을 정해도, 막상 검색은 grep으로 합니다. 정교한 분류 체계가 검색 속도를 못 따라잡는 겁니다.

이 사실을 인정하면 마음이 편해집니다. 거버넌스의 첫 단계인 폴더 구조만 채택된 상태가, 어차피 grep과 다를 게 없습니다. 그러면 그냥 그 상태에서 grep으로 시작하면 됩니다.

자료량에 따른 검색 도구 선택법

단계별 검색 인프라

자료의 양과 검색의 어려움에 따라 단계를 나누면 이렇습니다.

대부분의 1인 사업자는 첫 1년 동안 1~2단계를 벗어나지 않습니다. 4~5단계는 그때 가서 결정해도 늦지 않습니다.

거버넌스를 단순화하는 것에 대한 죄책감

1인 사업자가 자주 빠지는 함정이 있습니다. "제대로 하고 있나?"라는 불안 때문에 인프라를 과하게 갖추는 것입니다.

ADR을 안 쓰면 기록이 안 남을 것 같고, RAG가 없으면 자료가 흩어질 것 같고, 노션 데이터베이스를 정교하게 안 짜면 나중에 후회할 것 같습니다. 이 불안은 진짜입니다. 하지만 이 불안이 실제 리스크보다 큰 경우가 많습니다.

진짜 리스크는 인프라 부재가 아니라, 인프라 구축에 시간을 다 쓰고 정작 사업이 진척되지 않는 것입니다. 잘 정리된 ADR 50개와 정교한 RAG를 갖춘 채로 망한 1인 사업이, 엉성한 폴더와 grep만으로 매출 1억을 만든 사업보다 많을 겁니다.

이 죄책감을 끄는 가장 좋은 방법은 점검 기준을 미리 정해두는 것입니다.

한 달 후 점검 기준

거버넌스를 단순화하면서 안심하려면, 다시 검토할 시점을 미리 박아두면 됩니다. 한 달 후, 다음 항목들을 점검합니다.

자료의 양. 마지막 한 달간 새로 추가된 문서가 몇 개인가. 누적 문서가 몇 개인가. 500개를 넘으면 노션 검색이나 데스크톱 검색 도구 도입을 검토합니다.

검색의 실패 케이스. grep으로 못 찾은 자료가 구체적으로 몇 건 있었나. 그 자료들의 공통점은 무엇인가. 키워드는 다르지만 의미가 비슷한 자료를 찾으려다 실패한 경우가 많다면, 그때 RAG를 진지하게 검토합니다.

검색에 쓴 시간. 자료를 찾는 데 누적으로 몇 시간을 썼나. 한 달에 5시간 이상이면 인프라 부족이고, 그 미만이면 grep으로 충분한 단계입니다.

가장 중요한 질문. 인프라를 안 갖춰서 사업 진척이 막힌 일이 있었나. 없다면 현재의 단순한 거버넌스가 정답입니다. 있다면 그 구체적인 사례를 기준으로 다음 단계를 설계합니다.

이 네 가지를 한 달 후에 점검하기로 미리 정해두면, 지금 단순화하는 것이 무책임이 아니라 의도된 선택이 됩니다.

ADR-0008은 그때 쓰면 됩니다

3개월 후, 자료가 충분히 쌓이고 grep으로 못 찾는 케이스가 구체적으로 5~10건 누적되면, 그때 ADR-0008을 작성하면서 RAG 도입을 결정하면 됩니다. 그 시점에는 어떤 임베딩 모델을 쓸지, 어떤 청킹 전략을 쓸지, 어떤 벡터 DB를 쓸지에 대한 결정에 구체적인 근거가 있습니다.

지금 결정하면 추측에 기반한 결정이 됩니다. 3개월 후에 결정하면 데이터에 기반한 결정이 됩니다. 같은 시간을 쓰더라도, 후자의 결정이 훨씬 정확합니다.

1인 사업에 맞는 도구 선택법

1인 사업의 시간 윤리

큰 조직과 1인 사업의 가장 큰 차이는 시간의 가치입니다. 100명짜리 팀에서 한 명이 RAG 구축에 2주를 쓰면, 나머지 99명이 일하면서 손실이 분산됩니다. 1인 사업에서 2주를 쓰면, 그 2주 동안 사업 전체가 멈춥니다.

이 시간 구조 때문에 1인 사업의 의사결정 원칙은 큰 조직과 달라야 합니다.

큰 조직: "옳은 인프라를 미리 갖춘다."
1인 사업: "지금 시점에 충분한 도구를 쓴다."

큰 조직: "확장성을 고려해서 설계한다."
1인 사업: "병목이 생기면 그때 바꾼다."

큰 조직: "ADR 같은 기록 체계로 의사결정의 흔적을 남긴다."
1인 사업: "기록이 필요한 결정만 기록한다. 대부분은 머릿속에 있다."

이 차이를 인정하지 않으면, 큰 조직의 베스트 프랙티스가 1인 사업의 발목을 잡습니다.

트렌드를 따라가지 않는 용기

AI 시대에 새로운 키워드들이 매주 나옵니다. RAG, ADR, MCP, 에이전트, 워크플로, 멀티모달 파이프라인. 이걸 다 따라가는 건 학습으로는 좋지만, 사업으로는 독입니다.

1인 사업자에게 필요한 건 트렌드 키워드가 아니라, 지금 자기 단계에 맞는 도구입니다. 자료가 200개라면 grep이 답입니다. 자료가 5,000개가 됐을 때 RAG가 답이 됩니다. 그 사이의 어딘가에 노션 검색과 데스크톱 검색이 있습니다.

가장 트렌디하지 않은 도구가, 지금 단계에서는 가장 합리적인 선택일 수 있습니다. 50년 된 grep이 2026년의 1인 사업자에게 줄 수 있는 답이 있다는 것. 이게 도구 선택에서 트렌드보다 맥락이 중요한 이유입니다.

3개월 후, grep이 정말 못 따라가는 순간이 오면, 그때 RAG를 도입하면 됩니다. 그때까지는 grep으로도 충분합니다. 그리고 그 충분함 위에 사업의 진짜 진척을 쌓는 것이 1인 사업자의 일입니다.