AI-Native 회사 만들기

• 2020년대 초반에는 생성 AI에 많은 관심이 집중되었음
  • 생성 AI 도구가 우리를 어떻게 형성할 것인지, 작문, 코딩, 애니메이션, 정보 소비 방식에 어떤 영향을 미칠 것인지에 대한 논의가 주를 이루었음
  • 그러나 우리 도구의 형태에 대해서는 그다지 많은 언급이 없었음
• 1960년대 후반, 정보 시스템은 방대한 양의 데이터로 인해 관련 정보를 검색하는 과정이 점점 더 비용이 많이 드는 문제에 직면함
• 1980년대와 90년대에는 관계형 데이터베이스가 지배적인 솔루션이 되었음
  • 직관적인 인덱싱을 제공하고 쿼리 효율성을 보장했음
  • 관계형 데이터베이스는 데이터를 구조화된 관계를 가진 테이블 모음으로 표현할 수 있게 해주었음
  • SQL과 같은 쿼리 언어를 통해 더 빠른 데이터 검색을 가능하게 했음
• 데이터베이스 아키텍처가 진화하는 과정에서, IBM, Oracle, Sun Microsystems, MongoDB 등 특정 기업들이 각 신흥 시장에서 입지를 굳혔음
• Oracle이 관계형 데이터베이스 세계를 주도했지만, 사람들이 정보를 저장하고 액세스하는 방식은 계속 변화해 왔음
  • 새로운 작업이 있을 때마다 사람들은 이를 관리할 새로운 아키텍처를 고안해냈음
• 최근 데이터베이스의 진화는 비정형 데이터를 처리할 필요성에서 비롯되었음
  • 지난 50년 이상 스키마는 주로 구조화된 데이터 관계를 중심으로 구성되었음
  • 그러나 점점 더 많은 사람들이 데이터 모호성을 훨씬 더 잘 처리할 수 있는 도구를 필요로 하게 되었음
  • 이에 벡터 데이터베이스가 등장했음
• GPT와 같은 트랜스포머 기반 대규모 언어 모델(LLM)은 텍스트의 장기 의존성을 포착할 수 있음
  • 그러나 장문 이해력을 유지하는 것은 계산적으로 비용이 많이 들 수 있음
  • 벡터 데이터베이스는 이러한 모델의 컨텍스트 창을 확장할 수 있음
• 벡터 데이터베이스가 AI 사용 사례에서 강력할 수 있지만, 여전히 입력과 출력에 의해 작동되는 멍청한 인프라임
  • 데이터를 이해하거나 해석할 수 있는 능력이 부족함
  • 단순히 지시받은 대로 데이터를 저장하고 검색하는 저장소 역할만 할 뿐, 본질적인 지능이나 상황 인식은 없음
• 2020년 GPT-3 출시로 AI가 기업 제품의 부록이 아니라 핵심으로 점점 더 많이 사용될 수 있게 되었음
  • 트랜스포머 아키텍처, 데이터 량 증가, 성능 향상 등으로 AI 기반 제품 개발의 토대가 마련되었음
• AI-Native(AI 기반) 기업이 증가하고 규모가 커짐에 따라, AI 기반 사용 사례를 지원하는 도구의 필요성도 높아짐
  • 첫 번째 물결의 AI 핵심 기업들은 주로 기존 모델을 사용한 추론에 초점을 맞추었음
• 그러나 성능이 향상된 모델(특히 쉽게 접근할 수 있는 오픈 소스 모델)로 인해 기업은 AI 기반 비즈니스로서의 역량을 더 깊이 구축할 수 있게 되었음
  • 이러한 확장성은 AI 기반 기술 스택이 어떤 모습일 수 있는지에 대한 기회의 세계를 열어주고 있음

우리를 만드는 도구들 (The Tools that Shape Us)

• 1967년, 마셜 맥루한의 친구인 John M. Culkin은 "우리는 도구를 만들고 그 후에 도구가 우리를 만든다"고 말했음
  • 기술을 만드는 것도 다르지 않음
  • 우리가 소프트웨어를 만드는 데 사용하는 인프라는 우리의 구축 요구 사항에 맞게 끊임없이 진화해 왔고, 그 후 우리의 구축은 우리가 마련한 인프라에 의해 형성됨
• 2020년대 초반에는 생성 AI에 많은 관심이 집중되었음
  • 특히 생성되는 텍스트나 코드, 렌더링되는 이미지, 제작되는 딥페이크, 합성되는 음악 등 결과물에 초점이 맞춰졌음
  • 이러한 도구가 우리를 어떻게 형성할 것인지, 작문, 코딩, 애니메이션, 정보 소비 방식에 어떤 영향을 미칠 것인지에 대한 논의가 주를 이루었음
  • 사람들은 개방형 및 독점 대규모 언어 모델의 비교 성능, 환각의 위험성, 플랫폼 대 기능 논쟁, 기존 기업 대 스타트업 논쟁 등을 토론함
• 그러나 우리 도구의 형태에 대해서는 그다지 많은 언급이 없었음
  • 근본적으로, 우리가 기술을 구축하는 방식은 그 구축을 위해 마련한 인프라에 의해 형성되어 왔음
  • SaaS의 보급은 인터넷에 의해 가속화되었고, 스마트폰의 보편화로 모바일 개발이 가능해졌으며, 클라우드 컴퓨팅에 의해 애플리케이션 세대의 확장성이 촉진되었음
• 애플리케이션에서 AI의 보편성은 컴퓨팅, 모델 기능, 비즈니스 사용 사례 내에서 해당 모델의 조율에 따라 달라짐
  • 이 글에서는 조율 요소에 초점을 맞출 것임
  • 모든 AI 사용 사례를 조율하는 데 있어 핵심 요소 중 하나는 기업의 데이터베이스임
  • 데이터가 저장되고 조작되며 호출되는 위치는 퍼즐의 중요한 부분임
  • 그러나 보여주겠지만, 데이터베이스의 역사는 대체로 멍청한 인프라의 역사였음
  • AI의 유용성을 극대화하려면 데이터베이스를 생성 방정식의 일부가 되도록 제작해야 할 것임

데이터의 기반 (A Base For Data)

• 1959년 5월, CODASYL(데이터 시스템 언어 회의)이 처음으로 소집되어 "비즈니스 애플리케이션을 구축하기 위한 범용 언어"를 구축하고자 했음
  • 1960년대 후반, 정보 시스템은 방대한 양의 데이터로 인해 관련 정보를 검색하는 과정이 점점 더 비용이 많이 드는 문제에 직면했음
• 메인프레임 컴퓨터의 사용은 일반적으로 애플리케이션 유지보수, 패치, 성능 유지에 필요한 업그레이드 비용 등으로 인해 메인프레임 활용도가 높아짐에 따라 MIPS(초당 수백만 가지 명령) 비용 증가로 이어졌음
  • 데이터베이스 관리의 복잡성, 경직된 계층 구조, 복잡한 탐색 구조 매핑 등으로 인해 기업은 종종 선택한 정보에 액세스하기 위해 기술 전문 지식을 필요로 했고, 심지어 일부 개발자는 관련 정보에 액세스하기 위해 전체 프로그램을 작성해야 했음
• 1970년 E.F Codd는 "대규모 공유 뱅크를 위한 관계형 모델"을 발표하면서, 테이블이 공유 특성(즉, 고유 레코드를 식별하는 기본 키와 테이블 간 관계를 설정하는 외래 키)에 의해 연결될 수 있는 모델을 제안했음
  • 이로 인해 단일 쿼리로 이질적인 테이블에서 데이터를 검색할 수 있게 되었음
  • Codd의 관계형 데이터베이스는 데이터 항목 간의 관계를 기반으로 하여 데이터 조작과 사용의 유연성을 가능하게 했음
• 1973년 IBM 산호세 연구소의 프로그래머 그룹이 System R 프로젝트에 착수하여, 관계형 데이터베이스 시스템이 프로덕션 사용에 필요한 완전한 기능을 통합하면서도 여전히 높은 성능을 발휘할 수 있음을 입증했음
  • 이 팀은 데이터베이스 효율성을 위한 비용 기반 최적화 프로그램을 개발했고, System R에서 파생된 개발은 나중에 IBM의 첫 번째 관계형 데이터베이스 제품인 SQL/DS의 출시로 이어졌음
• 1980년대와 90년대에는 관계형 데이터베이스가 지배적인 데이터베이스 솔루션이 되었음
  • 직관적인 인덱싱을 제공하고 쿼리 효율성을 보장했음
  • 관계형 데이터베이스는 데이터를 구조화된 관계를 가진 테이블 모음으로 표현할 수 있게 해주었음
  • SQL과 같은 쿼리 언어를 통해 더 빠른 데이터 검색을 가능하게 했음
• 관계형 데이터베이스는 단일 머신에서 실행된다는 가정 하에 구축되었음
  • 그러나 1990년대와 2000년대의 인터넷 대량 채택으로 인해 데이터가 엄청나게 유입되어 단일 컴퓨터가 감당하기에는 너무 무거운 워크로드가 발생했음
  • 전통적인 SQL 데이터베이스는 단일 서버에서 실행되도록 설계되었고, 사용자가 저장 용량에 맞게 물리적 하드웨어를 늘려야 했는데, 이는 더 큰 워크로드를 운영하는 기업에게 매우 비용이 많이 드는 것으로 판명되었음
• 2010년대에는 OLTP(온라인 트랜잭션 처리)에 대한 데이터와 사용자가 기하급수적으로 증가하여, 분산 데이터베이스, 데이터 웨어하우스, OLAP(온라인 분석 처리)의 광범위한 증가로 이어졌음
• 관계형 데이터베이스와 SQL은 더 이상 필요한 애플리케이션 규모와 복잡성에 적합하지 않았고, NoSQL 데이터베이스는 성능을 높이는 수단으로 등장했음(ACID 기능 희생)
  • 관계형 데이터베이스는 구조화된 데이터를 저장하고 조작할 수 있었지만, 조인의 오버헤드를 처리하고 CRUD 작업 비용을 고려할 때 데이터 간의 관계를 유지하는 것이 어려웠음
  • 관계형 데이터베이스는 논리적이거나 이산적인 요구 사항이 있는 관계형 데이터를 처리하는 데 적합했지만 일반적으로 관계형 구조를 위해 특별히 구축된 레거시 시스템에 맞춰져 있었음
  • NoSQL은 비정형 빅데이터를 처리하는 수단으로 등장하여 비관계형 접근 방식을 통해 개발자에게 데이터 영속성을 제공했음
  • SQL을 기본 쿼리 언어로 사용하는 대신 NoSQL은 API를 통해 액세스를 제공하여 더 높은 확장성, 분산 컴퓨팅, 비용 절감, 스키마 유연성을 보장함
  • NoSQL 데이터베이스는 수평적으로 확장할 수 있는 효율적인 아키텍처로 작동하므로 저장 또는 컴퓨팅 용량을 늘리려면 더 많은 서버나 클라우드 인스턴스만 있으면 됨
  • 비정형 데이터의 더 빠른 처리나 분석을 위한 데이터 워크로드를 가진 기업의 경우 NoSQL 데이터베이스가 선호되었음

OG 데이터베이스 전쟁

• 데이터베이스 아키텍처가 진화하는 과정에서, 특정 기업들이 각 신흥 시장에서 입지를 굳혔음
  • IBM이 System R을 출시한 직후, 33세의 Larry Ellison은 Codd의 관계형 데이터베이스에 관한 동일한 논문을 읽었음
  • Ellison과 두 공동 창업자는 System R과 호환되는 회사를 설립하려 했지만 IBM은 그것을 매우 어렵게 만들었음
  • 결과적으로 이 삼인방은 새로운 주력 데이터베이스 제품인 Oracle Databases를 중심으로 사업을 구축했음
  • 그 이후로 Oracle의 데이터베이스는 선두 제품이 되었고, 2024년 5월 현재 시장 점유율은 약 28.7%임
• Oracle의 1986년 IPO 직전 몇 년 동안 또 다른 회사가 데이터베이스 분야에 진출했음
  • Sun Microsystems는 1982년에 다양한 컴퓨터 구성 요소를 판매하면서 시작했지만 Java 프로그래밍 언어, Network File System 등의 기여로 유명해졌음
  • 중요한 것은 2008년 Sun Microsystems가 MySQL이라는 오픈 소스 데이터베이스 관리 시스템을 인수했다는 점임
  • 불과 2년 후 Oracle은 Sun Microsystems(MySQL 포함)를 인수했음
  • 거의 15년이 지난 2024년 5월 현재 선도적인 데이터베이스는 Oracle(시장 점유율 28.7%)과 MySQL(약 17.3%)임
• Oracle이 관계형 데이터베이스 세계를 주도했지만, 사람들이 정보를 저장하고 액세스하는 방식은 계속 변화해 왔음
  • 새로운 작업이 있을 때마다 사람들은 이를 관리할 새로운 아키텍처를 고안해냈음
  • MongoDB(2007), Databricks(2013) 등의 문서 저장소부터 InfluxDB(2013), Prometheus(2012) 등의 시계열 데이터베이스, Neo4j(2007), Cosmos(2017) 등의 그래프 데이터베이스에 이르기까지 전문화된 데이터베이스 목록은 계속 늘어나고 있음
  • 관계형 데이터베이스의 인기가 꾸준히 감소함에 따라 이러한 새로운 틈새 니즈에 대해 다양한 솔루션이 등장했음
• 데이터베이스의 최신 진화는 비정형 데이터를 처리할 필요성에서 비롯되었음
  • 지난 50년 이상 스키마는 주로 구조화된 데이터 관계를 중심으로 구성되었음
  • 그러나 점점 더 많은 사람들이 데이터 모호성을 훨씬 더 잘 처리할 수 있는 도구를 필요로 하게 되었음
  • 이에 벡터 데이터베이스가 등장

벡터 데이터베이스의 부상

• 대규모 언어 모델(LLM)과 생성 AI의 광범위한 확산으로 벡터 데이터베이스는 비정형 멀티모달 데이터를 처리할 수 있는 도구로 부상했음
  • 기존의 관계형 데이터베이스(Postgres, MySQL)가 구조화된 스키마에 가장 적합한 반면, 벡터 데이터베이스는 벡터 임베딩(언어 모델의 가중치에 상대적인 의미를 포함하는 데이터의 수치 표현)을 저장하고 쿼리하는 데 적합함
  • 관계형 데이터베이스에서 일반적으로 사용되는 행과 열 대신 벡터 데이터베이스는 데이터를 다차원 공간의 점으로 표현하여 정확한 값이 아닌 유사성에 기반하여 데이터를 매칭함
• 임베딩 모델에 따라 데이터는 서로 다른 벡터 공간과 다양한 차원으로 표현될 수 있음
  • 벡터 임베딩은 데이터 포인트의 의미를 포착하여 벡터 데이터베이스에서 가장 가까운 객체를 검색하여 유사한 객체를 검색할 수 있게 함
• 예를 들어 Word2Vec은 단어를 벡터에 매핑하여 의미, 의미적 유사성, 다른 텍스트와의 맥락적 관계를 포착하는 데 도움을 줌
  • 이 알고리듬은 얕은 신경망을 사용하여 더 넓은 텍스트 말뭉치에서 특정 단어의 의미를 유도하고 로지스틱 회귀를 통해 동의어를 식별함
  • 특이값 분해(SVD)와 주성분 분석(PCA) 등 심층 신경망에 의존하지 않고 임베딩을 추출하는 데 도움이 되는 방법도 있음
• 거리 메트릭은 벡터 공간에서 점 사이의 상대적 "거리"를 결정하는 데 도움이 되며, 일반적인 방법으로는 유클리드 거리, 맨해튼 거리, 코사인 거리, 자카드 유사도 등이 있음
  • K-최근접 이웃(KNN)과 근사 최근접 이웃(ANN)은 이미지, 비디오 또는 기타 멀티모달 입력에 대한 유사성 검색을 단순화하여 실행 시간을 개선하는 데 도움이 됨
• Weaviate, Chroma, Qdrant, Pinecone 등의 벡터 전용 데이터베이스는 개발자가 대규모 데이터, 특히 비정형 입력에 대한 검색을 용이하게 하는 측면에서 다루는 데 도움이 됨
  • 기존의 관계형 데이터베이스나 NoSQL 데이터베이스와 달리 벡터 데이터베이스는 벡터 임베딩을 처리하도록 특별히 설계되었음
  • 기존 데이터베이스는 데이터를 스칼라로 저장하는 반면, 벡터 데이터베이스는 벡터만 저장하고 양자화 및 클러스터링과 같은 인덱싱 기술을 활용하여 검색 작업을 최적화함
• GPT와 같은 트랜스포머 기반 LLM은 텍스트의 장기 의존성을 포착할 수 있음
  • 그러나 장문 이해력을 유지하는 것은 계산적으로 비용이 많이 들 수 있음
  • 최신 LLM은 입력에 걸친 토큰 쌍의 전역 의존성을 포착할 수 있지만, 시간과 공간 복잡성으로 인해 계산 자원 문제가 발생하여 학습 중 입력 텍스트 길이와 추론 중 효과적인 컨텍스트 창이 제한됨
• 다차원 사례의 경우 상대적 위치 인코딩이 구현하기 어려우며, 상대적 위치를 인코딩하는 대부분의 접근 방식은 추론 중 성능 저하에 기여하는 강력한 위치 임베딩 메커니즘을 필요로 함
  • 텍스트 길이가 증가할 때도 벡터 데이터베이스는 모델의 장기 메모리 역할을 하는 데 중요할 수 있음
  • 벡터 데이터베이스를 사용하면 전체 문장 컨텍스트가 정확한 결과 생성에 필요할 수 있는 텍스트 완성이나 요약과 같은 작업을 간소화할 수 있음
• 벡터 데이터베이스는 검색 증강 생성(RAG)을 지원할 수 있는데, 여기서 벡터 데이터베이스는 원래 쿼리와 함께 추가 컨텍스트를 포함하여 LLM에 전달되는 프롬프트를 향상시키는 데 사용될 수 있음
  • LLM은 종종 자기 감독 학습 모델에 의존하므로 특정 지식이나 더 높은 정확도 임계값이 필요한 도메인별 작업에 어려움을 겪는 경우가 많음
  • RAG는 문제의 쿼리에 대한 컨텍스트 부족으로 인해 발생할 수 있는 환각을 완화하면서 응답이 어떻게 도출되는지 확인, 추적 또는 설명하는 데 도움이 될 수 있음
• 개발자는 지식 그래프와 벡터 검색을 결합하여 LLM을 학습한 데이터를 넘어서도록 확장할 수 있음
  • Microsoft Research의 GraphRAG와 같은 도구는 프라이빗 데이터 세트에 대한 검색을 수행할 때 프롬프트 증강을 용이하게 함
  • 기본 RAG는 종종 큰 데이터 컬렉션에 대한 요약된 의미 개념을 전체적으로 이해하는 데 어려움을 겪으므로 LlamaIndex 및 GraphRAG와 같은 도구는 프라이빗 데이터 세트를 기반으로 지식 그래프를 구성함
• 개발자는 특정 요구 사항이나 사용 사례에 따라 RAG보다 지식 그래프를 사용하는 것이 좋을 수 있음
  • 벡터 데이터베이스는 유사성 검색에 적합하고 문서나 이미지 검색, 추천 생성에 가장 적합한 반면, 지식 그래프는 추론에 적합함(특히 데이터 수집, 상호 연결된 관계와 함께 엔터티 추출, 해당 관계 순회할 때 유용함)
• 실시간 또는 준실시간 데이터 처리가 필요한 애플리케이션의 경우 더 낮은 지연 쿼리로 인해 벡터 데이터베이스가 선호될 수 있음
• 임베딩을 수집하고 저장함으로써 벡터 데이터베이스는 유사성 검색의 더 빠른 검색을 용이하게 하여 입력된 프롬프트를 유사한 임베딩과 일치시킴
• 유사성 랭킹은 추천 시스템, 의미 검색, 이미지 인식 및 기타 자연어 처리 애플리케이션에 이르는 다양한 기계 학습 작업을 지원하는 데 도움이 됨
• 벡터 데이터베이스는 벡터 임베딩의 효율적인 저장 및 검색을 가능하게 함으로써 LLM의 성능을 향상시키는 데 중요한 역할을 함
  • 이를 통해 대규모로 자연어를 자동으로 이해할 수 있음
• 그러나 벡터 임베딩은 N+1 혁신을 나타냄
  • 관계형 또는 시계열 데이터와 같은 이전의 데이터 형식임
• 레거시 데이터베이스 공급업체는 MongoDB의 Atlas Vector Search, SingleStore의 벡터 데이터베이스, Neo4J의 벡터 검색 인덱스와 같은 벡터 기능을 출시하기 시작했음
• 벡터 데이터베이스가 AI 사용 사례에서 강력할 수 있지만, 여전히 입력과 출력에 의해 작동되는 멍청한 인프라임
  • 데이터를 이해하거나 해석할 수 있는 능력이 부족함
  • 단순히 지시받은 대로 데이터를 저장하고 검색하는 저장소 역할만 할 뿐, 본질적인 지능이나 상황 인식은 없음
• 최신 AI 기반 애플리케이션의 경우 이것만으로는 충분하지 않을 것임
  • 기업은 점점 더 AI 모델을 핵심으로 구축하고 있음
  • 따라서 애플리케이션이 점점 더 지능적인 기능을 보여주려면 인프라에서도 동일한 지능적인 기능이 필요할 것임

1세대 AI-Native 회사들

• 1956년 다트머스 대학에서 학계가 처음으로 인공지능을 연구하기 시작한 이래로 실용적인 사용 사례가 이 분야를 발전시켜 왔음
  • 예를 들어 1960년대 후반 Joseph Weizenbaum은 ELIZA라는 컴퓨터 프로그램을 만들었는데, 패턴 매칭을 통해 대화를 시뮬레이션하는 단순한 접근 방식이 초보적인 치료와 유사한 대화에 사용되었음(최초의 챗봇)
• 비즈니스 사용 사례에서 AI를 활용한 대부분의 역사에서 AI의 개선은 점진적이었음
• AI라는 용어가 유행하기 전에는 동일한 기술을 지칭하기 위해 기계 학습이라는 용어가 더 자주 사용되었음
  • 즉, "데이터에서 학습하고 보이지 않는 데이터로 일반화할 수 있는 통계 알고리즘으로, 명시적인 지침 없이 작업을 수행할 수 있음"
• 대중의 인식 측면에서 AI는 2022년 11월 30일 OpenAI가 ChatGPT를 출시하면서 변곡점에 도달했지만, 기술적 관점에서 전환점은 그 훨씬 이전에 일어났음
• 2017년 11월, 국제 규제 기구인 금융안정위원회(FSB)는 기계 학습이 금융 서비스에 미치는 영향에 대한 개요를 작성했음
  • 금융 서비스 기업은 점점 더 "신용 품질 평가"와 같은 작업을 수행하기 위해 기계 학습을 사용하여 "더 효율적인 금융 시스템에 기여"할 수 있었음
  • 즉, 효율성을 높일 수 있지만 실존적 필수 요소를 구성하지는 않았음
• 한편 기계 학습은 점점 더 좋아졌고, 2018년 5월 OpenAI는 대규모 모델 학습에 필요한 컴퓨팅 역사에 대한 연구를 발표했는데, 2012년 이후 3.4개월마다 두 배씩 증가하여 컴퓨팅이 30만 배 증가했음을 보여주었음
• 그 다음 달인 2018년 6월, OpenAI는 GPT 모델의 첫 소개를 발표했음
• 두 진영 사이에 논쟁이 형성되고 있었음
  • 한편으로는 점점 더 큰 모델의 지속적인 성장이 수확 체감의 법칙을 가질 것이라고 믿는 사람들이 많았음
  • OpenAI가 속한 다른 진영은 규모가 커질수록 성능이 계속 향상될 것이라고 믿었음
• 2020년 1월, OpenAI 연구원이자 존스 홉킨스 대학 교수인 Jared Kaplan은 다른 사람들과 함께 "신경망 언어 모델의 스케일링 법칙"을 발표했는데, 여기에는 다음과 같이 명시되어 있음:
  • "모델 크기, 데이터 및 컴퓨팅을 적절하게 확장함에 따라 언어 모델링 성능이 원활하고 예측 가능하게 향상됩니다. 우리는 더 큰 언어 모델이 현재 모델보다 성능이 더 좋고 샘플 효율성이 더 높을 것으로 기대합니다."
• 2020년 5월, OpenAI는 GPT-3에 관한 "언어 모델은 Few-Shot 학습자"라는 논문을 발표했는데, 이는 컴퓨팅 증가에 따른 성능의 매끄러운 확장을 보여주었음
• 또한 OpenAI는 규모를 늘리면 일반화 가능성도 향상된다는 것을 발견했으며, "대규모 언어 모델의 스케일링은 작업에 구애받지 않는 few-shot 성능을 크게 향상시켜 때로는 이전의 최첨단 파인튜닝 접근 방식과 경쟁력을 갖출 수 있다"고 주장했음
• 프리랜서 연구원인 Gwern Branwen은 블로그 게시물에서 스케일링 가설을 고안했고, 다음과 같이 말했음:
  • "2020년 5월 OpenAI에서 발표한 GPT-3는 지금까지 훈련된 신경망 중 가장 크며, 한 자릿수 이상 큽니다... 많은 사람들(저 자신 포함)의 예상과 달리, 이러한 엄청난 규모의 증가는 OpenAI에서 예측한 대로 규모의 이점이 계속 나타났으며 많은 사람들이 예상했던 수확 체감이나 마이너스 수익에 부딪히지 않았습니다."
• Branwen이 느낀 그 놀라움은 풍경의 변화였음
• AI는 회사 제품의 부록이 아니라 점점 더 핵심으로 사용될 수 있었음
• 트랜스포머 아키텍처, 증가된 데이터 량, 향상된 성능 수준 등 모두가 AI 기반 제품 개발의 토대를 마련했음
• GPT-3가 출시된 직후인 2020년 5월, Writer와 Jasper와 같은 회사는 AI 모델을 사업의 중심에 둔 카피라이팅 제품을 만들었음
• Harvey와 EvenUp과 같은 회사는 AI를 중심으로 법률 기술을 구축했음
• DeepScribe와 Freed와 같은 회사는 AI를 중심으로 의료 전사를 구축했음
• 그러나 과거에 새로운 사례가 데이터베이스 진화를 초래했던 것처럼, AI 기반 제품의 탄생은 각 회사의 기술 스택 뒤에 있는 인프라가 변화하고 적응해야 함을 의미했음

AI-Native Database

• AI 기반 기업이 증가하고 규모가 커짐에 따라, AI 기반 사용 사례를 지원하는 도구의 필요성도 높아짐
• 첫 번째 물결의 AI 핵심 기업들은 주로 기존 모델을 사용한 추론에 초점을 맞추었음
  • 애플리케이션과 카피라이팅, 의료 전사 등을 위한 목적별 워크플로우 도구를 갖추고 있음
  • 제품의 핵심은 모델에서 생성된 텍스트나 생성된 이미지와 같은 출력임
• 2023년 11월 OpenAI의 DevDay 이후 "OpenAI가 내 스타트업을 망쳤다"는 밈이 퍼지기 시작했음
  • 특정 전문 GPT나 AI 에이전트는 기존 모델의 추론에 초점을 맞추었기 때문에 이러한 초기 AI 기반 스타트업의 역할을 맡는 것처럼 보였음
  • OpenAI는 우연히 모델과 애플리케이션 모두의 공급자가 되었음
• 모델 기능을 중심으로 한 혁신이 너무 빠르게 진행되어 스타트업에 위협이 되는 것처럼 느껴지기 시작했음
• 그러나 반대로, 성능이 향상된 모델(특히 쉽게 접근할 수 있는 오픈 소스 모델)로 인해 기업은 AI 기반 비즈니스로서의 역량을 더 깊이 구축할 수 있게 되었음
• AI 기반 기술 스택을 구축하는 것은 모델 주변에 구성 요소를 추가하는 것 이상임
  • 예를 들어 AI를 위해 특별히 제작된 데이터베이스는 어떤 모습일까?
  • 추론이 중요한 출력인 경우 AI 기반 데이터베이스는 단순히 데이터를 저장하고 검색하는 것이 아니라 저장 중인 데이터로 수행할 작업에 대한 상황별 지침을 취할 수 있어야 함
• 한 가지 예는 전자상거래를 위한 제품 설명 개인화일 수 있음
  • 벡터 데이터베이스는 제품 SKU와 설명에 대한 벡터 임베딩을 저장할 뿐만 아니라 사용자 페르소나에 대한 임베딩도 저장할 수 있음
  • 데이터베이스의 이러한 모든 상황별 데이터를 사용하여 인프라는 제품 설명에 대한 쿼리가 관련 사용자 페르소나에 대한 쿼리도 트리거한 다음 해당 관련 사용자 페르소나를 기반으로 제품 설명을 작성하는 생성 피드백 루프를 활용할 수 있음
• 마찬가지로 언어는 생성 피드백 루프로 사용될 수 있음
  • 예를 들어 사용자는 다양한 언어로 제품 설명을 생성하려고 할 수 있음
  • 사용자에게 맞춤화될 뿐만 아니라 사용자가 선택한 언어로 번역된 제품 설명을 생성할 수 있음
  • 이러한 유형의 지침은 생성 AI와 같은 사용 사례가 점점 더 애플리케이션의 중심 기능이 되기 때문에 데이터베이스에 직접 내장될 수 있음
• 사용 사례에 맞게 인프라를 발전시키는 것은 새로운 일이 아님
  • 원래 개발자는 JavaScript를 사용하여 브라우저에서 애플리케이션을 구축하여 웹사이트를 대화형으로 동적으로 만들었음
  • 그러나 개발자가 이를 백엔드로 가져올 수 있다는 것을 깨달으면서 node.js가 탄생했음
  • 그 다음 개발자가 더 많은 모바일 애플리케이션을 만들기 시작하면서 보다 동적이고 반응적이며 데이터 기반의 애플리케이션을 가능하게 하는 JSON(JavaScript Object Notation)이 등장했음
  • MongoDB는 진화하는 인프라 요구 사항을 해결하기 위해 등장한 회사로서 이러한 물결에 완벽하게 적합했음
• AI로 역사가 반복되고 있음
  • 요구 사항이 변경됨에 따라 인프라는 이러한 요구 사항을 충족하기 위해 발전해야 함
  • 가장 큰 질문은 사람들이 어떤 종류의 회사를 구축하고 싶어 하는지, 그리고 어떤 종류의 인프라가 그러한 회사에 가장 적합한지가 될 것임
  • Bob이 Matthew Lynley와의 인터뷰에서 말한 바와 같이:
    • "저는 미래의 모든 애플리케이션에 AI가 포함될 것이라고 강력히 믿습니다. 일부 애플리케이션에는 AI가 뿌려질 것이고, 일부는 애플리케이션의 중심에 AI가 있을 것입니다. AI를 빼면 더 이상 존재하지 않습니다. 웹 앱을 구축하고 그 위에 AI를 뿌리고 싶다면 MongoDB를 사용하세요. 특히 이미 사용 중이라면... AI가 애플리케이션의 핵심인 AI 기반 애플리케이션을 구축하고 싶다면 Weaviate를 고려해야 할 때입니다."
• 앞으로 기업은 AI를 부록으로 제품을 구축할 것인지, 아니면 Bob이 말한 것처럼 "sprinkle"로 구축할 것인지, 아니면 제품의 핵심이 될 것인지 결정할 것임

AI-Native 기술 스택

• AI를 제품의 핵심 구성 요소로 구축하고자 하는 기업의 경우 기존 인프라로는 적절하지 않을 가능성이 높음
  • 레거시 도구를 사용하면 데이터 저장, 정리 및 실행은 한 사일로에서 구축되고 자동화는 다른 사일로에서 구축됨
  • 이러한 접근 방식의 단점은 제품을 더 잘 알리고 개선할 수 있는 생성 피드백 루프와 같은 것에서 컨텍스트가 손실된다는 것임
• "AI 인접" 스택에서 오는 기업의 경우 특정 모델의 추론은 종종 컨텍스트 창으로 제한됨
  • 일부는 주어진 컨텍스트 창의 용량이 증가하면 벡터 데이터베이스를 대체할 수 있다고 믿음
  • 그러나 벡터 데이터베이스가 컨텍스트 창을 대체하도록 진화할 수 있는 반대 상황이 사실일 가능성이 높음
  • 벡터 임베딩은 생성 모델에 매우 중요하며, 생성 결과를 위한 인프라는 벡터 임베딩을 1등 시민으로 취급해야 함
• 단순히 컨텍스트 창의 크기를 늘리는 대신 벡터 데이터베이스를 모델에 짜 넣어 컨텍스트 창의 맥락적 이해와 데이터베이스의 신뢰성 및 확장성을 제공할 수 있음
  • 특히 모델이 범용적일수록 특정 작업에 맞게 제작될 가능성이 줄어듦
  • AI 기반 벡터 데이터베이스는 보다 구체적인 기능을 가능하게 할 것임
• GPT-4와 같은 범용 모델은 지식을 의도적으로 일반화하도록 구축되었음
  • 제품이 약간의 간단한 파인튜닝에 의존하는 경우 기본 모델은 해당 비즈니스의 고유하게 가치 있는 부분이 되지 않을 것임
  • AI 기반 제품을 구축하는 것은 모델을 활용하는 것 외에도 보다 긴밀하게 연결된 스택을 중심으로 제품을 구축하는 것을 수반할 것임
  • 이 스택은 데이터베이스의 규모와 모델의 기능을 제공하여 더 유능한 제품을 만들어 낼 것임

[savvykang]

벡터 임베딩 생성이랑 벡터DB 사용 사례가 더 많이 나와서 표준 워크플로우가 나왔으면 좋겠습니다 한 1년 정도 기다리면 되려나요