Part 2: Conviction 포트폴리오 스포트라이트 - Langchain & Seek.ai

Introduction

• 1) Conviction이 투자한 모든 회사들의 Co-Founder 적어도 1명은 AI 엔지니어 출신입니다. 모두 leading AI/ML 업체나 교육기관에서 AI 리서치와 개발 경험이 있으신 분들입니다.

• 2) 각 회사의 비전을 보면 현재 기술 수준을 UI로 Wrapping해서 빠르게 Product-to-Market을 시도하는 것 보다 특정 버티컬 내 AI 기술을 연구개발하고 적극적으로 프로덕트에 반영하고 있는 것으로 보입니다. Conviction은 “연구”와 “비즈니스”의 교차로에 있는 팀을 선호하는 것 같습니다.

• 3) 인프라 레이어(BaseTen, LangChain) 외 회사들은 모두 자체 AI 모델을 개발하고 있습니다. AI-native 어플리케이션이 진입장벽을 구축하려면 자체 모델을 만들 수 밖에 없는 것일까요?

시사점

• 나이와 무관하게 창업자의 비전과 패기를 보던 것과 달리 AI에 투자하는 VC들에겐 창업자가 발표한 논문, 글로벌 AI 업체에서의 경력, AI 프로젝트 호응도(Github 별 수) 등이 중요시 되는 것 같습니다. (적어도 AI 산업 내에선) 창업자 평균 나이가 많이 올라갔을 것 같습니다.
• 인프라, B2B 솔루션 등 버티컬 내 창업 진입장벽은 높을 것으로 생각되나 이 툴들을 잘 활용하여 만든 고부가가치 AI 어플리케이션(B2C)은 젊은 세대에서 나올 것이라고 생각하고 있습니다.

• 추가로 궁금한 사항들: AI-native 어플리케이션을 만들려면 꼭 AI 엔지니어가 있어야 할까요? 시행착오를 통해 빠른 learning curve를 탈 수 있는 과목인가요? 많은 B2B AI 솔루션들이 표방하는 것처럼 진정한 “AI 개발 민주화”는 언제 올까요? 무엇이 bottleneck이며 그게 해결되면 AI 어플리케이션의 변곡점이 될 수 있을까요?

Langchain

개요

• LangChain은 언어 모델 기반 어플리케이션을 개발하기 위한 프레임워크입니다. 비개발자로써 이해하기 매우 어려웠는데요… 모두의AI 유튜브 채널의 Kane님을 많이 인용하고 참고하였습니다. 실습도 같이 보여주시니 Langchain에 대해 좋은 공부 영상이니 참고하시기 바랍니다!

• Langchain은 내가 개발하고 싶은 LLM 어플리케이션 내 아래 기능 탑재를 도와줍니다:
• 데이터 연결: LLM에게 내가 원하는 데이터 소스(벡터DB)나 컨텍스트(프롬프트, 퓨샷 예시 등)과 연결
• 에이전트 기능: 구체적인 툴이나 방법을 제시하지 않더라도 알아서 다양한 환경과 상호 작용할 수 있는 기능 (reasoning capability) 제공

Breakdown

• Langchain을 쉽게 설명하자면 말 그대로 “Lang”uage Model의 “chain” 역할을 해주는 코드 패키지입니다.

• 일반 사용자들의 니즈는 대부분 ChatGPT로 해소할 수 있습니다. 하지만, 앞서 LLM 핵심 정리에서 알아 봤듯이 엔터프라이즈 use case는 ChatGPT가 주는 기능보다 더 높은 커스터마이징을 요구합니다. 그래서 (OpenAI, Anthropic, 오픈소스 등) API를 호출해서 각자만의 어플리케이션을 만들죠.

• 어플리케이션을 구축할 때 가장 중요한 작업 예시로는 데이터 연결이 있습니다. 사용자는 단순히 pre-training 및 fine-tuning 단계에서 학습된 데이터 기반의 답변이 아니라 내 자체 데이터 기반으로 답변을 원하죠. LLM을 standalone으로 사용하는 것이 아니라 내가 원하는 아웃풋을 낼 수 있도록 다양한 에이전트 및 기능과 연결하는 작업이 매우 중요합니다.

• 데이터 연결 외 프롬프트 템플릿, 답변문을 커스터마이징 해주는 Output Parsers, 사용자의 목적을 이해하고 업무를 해당 기능으로 delegate하는 에이전트 등이 있습니다.

• 단순히 GPT-4 API만 끌어와서 사용하면 되는 줄 알았는데, 원하는 아웃풋을 섬세하게 조율하기 위해선 생각보다 많은 기능을 붙여야 합니다. 백엔드 개발자 입장에선 악몽이죠.

• Langchain은 개발자들이 위 기능을 코드에 쉽게 구현하고 연결할 수 있도록 “out-of-the-box” 코드 패키지를 제공합니다. LLM 어플리케이션을 개발하는 사람들은 바퀴를 재발명(reinvent the wheel)할 필요 없이 필요한 Langchain 모듈을 코드베이스에 import만 하면 됩니다.

PDF 챗봇 구축 예시

• PDF 챗봇을 예시로 하여 Langchain이 어떻게 구동 되는지 알아보겠습니다.

• 먼저 어플리케이션의 목적에 맞춰 아웃풋을 내놓을 수 있도록 프롬프트 템플릿을 준비합니다. 프롬프트 템플릿을 사용하면 유저가 매번 일일이 프롬프트를 작성할 필요가 없고 개발자가 의도한 방향대로 LLM을 넛지할 수 있습니다.

• 그 다음, 유저가 PDF 파일을 업로드할 수 있는 PyPDFLoader를 사용합니다. 해당 모듈은 페이지 컨텐츠와 메타데이터를 Retrieval Augmented Generation(RAG) 전용 객체로 불러들입니다.

• AI모델들은 토큰 한계가 있습니다. 한 번에 다 때려 넣을 수 없기 때문에 Langchain의 Text Splitter 모듈을 사용하여 긴 문서를 “chunk”로 쪼개는 과정을 거칩니다.

• 이렇게 쪼개진 텍스트 청크는 OpenAI의 Ada-002, Cohere의 Embed v3, 오픈소스 등의 임베딩 모델을 활용하여 벡터화를 진행합니다.

• 벡터로 변환된 데이터를 벡터DB에 저장합니다.

• 이제 사용자가 질문을 던지면 개발자가 설정한 Retrieval 방식에 따라 벡터DB에 적합한 “relevant text”를 찾고 아웃풋을 내놓습니다.
• 아래 사용된 모듈은 “Map re-rank documents chain”입니다. AI가 관련된 텍스트 청크를 모두 벡터DB에서 “retrieve”하고 각 청크에 대해 LLM에서 아웃풋을 출력한 다음 아웃풋의 점수를 매기고 최고 점수의 답변을 유저에게 출력합니다. 이 외 여러가지 모듈들이 있습니다. 개발자는 본인 use case에 맞게 모듈을 사용하면 됩니다.

시사점

• Langchain의 극히 일부 기능들을 예시로 사용하여 AI 어플리케이션 개발에 Langchain 모듈들이 어떻게 사용되는지 알아봤습니다.

• 개발자는 아니지만… 이 모든 프로세스를 공부해오면서 생각난 몇 가지를 정리해봤습니다:

• 1) 이 각각 개발 프로세스에서 하는 사소한 결정들이 아웃풋에 큰 영향을 끼칠 수 있습니다. 각 모듈들을 빠른 속도로 바꿔가면서 아웃풋을 실험할 수 있는 자동화 툴에 기회가 있지 않을까?
• 예를 들어, Text Splitter 단계에서 어떤 방식으로 청크를 나눌지, 각 청크가 context를 잃지 않게 만들기 위해 어떤 방식으로 보완할지 (예. chunk_overlap 모듈) 등이 중요한 결정사항입니다. 또, 데이터 형식(금융 데이터 vs. 소설책)에 따라 다른 방법으로 split을 해야 하지 않을까 싶습니다. 사람이 각 모듈 체인지에 대한 아웃풋 퀄리티를 테스트 하는 것이 아니라 자동화가 가능하다면?

• 2) 어떻게 아키텍처 구조를 만드느냐에 따라 아웃풋 정확도와 비용/속도 trade-off가 있습니다. 더 정확한 아웃풋을 위해선 모델을 몇 번 돌려야 하고 속도도 느려집니다. 타겟 고객군에게 어떤 사항이 중요한지 잘 파악해야겠네요.

• 3) 만약 스타트업 주요 전략이 자체 AI 모델을 개발하는 것이라면 지금으로썬 이 모든 프로세스를 아우를 수 있는 AI 엔지니어 co-founder가 확실히 큰 강점으로 보입니다.

• 4) 그냥 드는 생각이지만… 저희는 현재 AI 모델에 적합하지 않는 (즉, 사람이 쉽게 읽히도록 작성된) Unstructured Data를 참신한 방법으로 LLM에 구겨 넣고 있습니다. 이 방법은 매우 비효율적이라고 생각됩니다. 향후엔 문서를 사람이 읽는 것이 아니라 AI가 대신 읽어주는 시대가 온다면 사람보다 AI모델이 쉽게 소화할 수 있도록 “데이터”를 작성하는 방향으로 가지 않을까… 싶습니다.

수익모델

• Langchain은 누구나 기여할 수 있는 오픈소스 프레임워크입니다. 누구나 공짜로 사용할 수 있고 기존 기능들을 갑자기 과금화 할 수도 없는 상황입니다. 지금으로썬 수익모델이 매우 불명확합니다. 그럼에도 불구하고 기대해볼 만한 회사인 것 같습니다.

• (개발자가 아니지만) 한 번 사용하면 Langchain 프레임워크는 마약과 같을 것 같습니다. 모두의AI 채널 Kane님의 실습을 보면 엄청난 백엔드 코딩이 필요한 것들을 Langchain을 활용하여 얼마나 쉽게 기능을 구현하고 연결할 수 있는지 직감할 수 있습니다. 게다가 공짜이며 커뮤니티가 계속 기능을 확장해나가니… 개발자 입장에선 팬이 안됄 수 없습니다.

• 명확한 가치제안으로 많은 LLM 어플리케이션 개발자들을 프레임워크에 온보딩 했습니다. 여기서 3가지 방법으로 수익창출을 이뤄낼 수 있지 않을까 싶습니다:

• 1) Open-Source Playbook: Docker, Confluent, Red Hat 모두 오픈소스 기반 업체이죠. 모두 오픈소스 소프트웨어 위에 엔터프라이즈향 기능(클라우드, 대시보드 등)과 서비스(CS, 컨설팅 등)를 프로덕트로 패키징하여 수익을 내고 있습니다. Langchain 또한 Enterprise SaaS 프로덕트를 출시할 가능성이 큽니다.

• 2) No-code AI application builder: Langchain 프로덕트 특성 상 오히려 저와 같은 비개발자를 위한 노코드 SaaS 개발도 가능하지 않을까 싶습니다. Drag-and-drop 방식으로 LLM 어플리케이션을 만들 수 있다면 저도 제 컴퓨터에 개인 LLM을 만들기 위해 지불용의가 있습니다.

• 3) Co-sales: Langchain framework 내에 다양한 모델들과 벡터DB들이 연동되어 있습니다. 모두 각각 개발자와 그의 workload를 온보딩하고 싶어하는 업체죠. Langchain 내에서 특정 모델이나 벡터DB를 활용하면 Langchain에게 분명히 어느 정도의 고객 온보딩 지분이 있습니다. 매출(API 콜, 스토리지/Query 크레딧 등)의 일정 부분을 충분히 뜯어갈 수 있는 위치가 아닐까요?

Seek.AI

개요

• 저희가 세일즈 팀의 AE(Account Executive)라고 가정해보죠. 내일 잠재 구매자와 미팅이 잡혀있습니다. 세일즈를 성공적으로 성사 시키기 위해선 우리 프로덕트가 고객에게 어떤 밸류를 제공할 수 있는지, 수치적으로 설명해야 하죠.

• AE로써 우리는 아래와 같은 데이터가 필요할 것입니다:
• 잠재 구매자 산업 내 우리 프로덕트를 사용하는 고객이 몇 명인지
• 잠재 구매자와 유사한 기업들은 우리 프로덕트의 어떤 기능을 자주 사용하는지
• 유사 업체들이 우리 프로덕트를 사용하며 받은 수치적 밸류(비용 절감, 매출 전환, 시간 효율화 등)

• Problem: 위와 같은 데이터는 Tableau, Looker Studio 등 비즈니스 인텔리전스(BI) 툴에서 찾거나 데이터베이스를 뜯어서 정답을 찾아내야 합니다. 주로 세일즈 팀의 AE는 데이터베이스를 직접 다루고 Query할 수 없기 때문에 데이터 팀에게 요청을 하고 비효율이 발생하게 됩니다.
• 1) BI툴들은 세일즈 팀이 원하는 모든 수치를 정리 해 놓지 않습니다. 각 고객이 unique한 것 처럼 세일즈를 할 때도 unique한 메시지를 던져야 하죠. 그러기 위해선 회사 내 데이터를 유연하게 Query해야 할 니즈가 있습니다.
• 2) 현재 이 워크플로우는 파편화 되어 있습니다. 내가 찾고 싶은 데이터가 무엇인지, 목적이 무엇인지 AE는 명확하게 알고 있겠지만 데이터 팀은 내 할 일 바쁜데 계속 요청과 수정 요청만 들어와 짜증만 납니다. 결국 팀이 파편화 되어 있어 일을 처리하는데 있어 Time Lag가 있을 뿐더러 불필요한 Miscommunication으로 인한 비효율이 발생하게 됩니다.
• 결국 이 문제는 누구나 데이터베이스를 쉽게 다룰 수 없다는 점에서 시작합니다. 데이터베이스는 매우 복잡하고 Fragile 하기 때문에 전문가가 아니면 다루기가 어렵죠. AE가 한 다리를 거쳐 데이터베이스에 접근하는 방식이 아니라 직접 전문가처럼 Query하고 답을 얻어 낼 수 있으면 훨씬 더 좋겠죠.

• Solution: Seek.AI는 회사의 데이터베이스를 SQL 코드 방식이 아니라 회사 구성원 누구나 자연어로 쉽게 접근할 수 있는 AI 플랫폼을 제공합니다. 자연어 인터페이스에 원하는 데이터를 자연어로 입력하면 Gen AI가 알아서 코드로 “번역”하고 Query한 다음, 원하는 형식으로 데이터를 가져다 주죠.

Features

• 동사의 모델은 “Semantic Network” 아키텍처로 강화학습(reinforcement learning)과 In-Context Learning을 지원합니다. 사용자의 부서(세일즈, CS 등)나 목적에 따라 더 적합한 아웃풋을 내놓을 수 있도록 기능이 고도화 될 수 있겠네요!

• 사용하기 쉽도록 Slack, Teams, 메일 등 Integration으로 쉽게 접근이 가능합니다.

• 현재는 SQL 기반 데이터베이스를 전문적으로 다루는 것으로 보입니다. Snowflake과 파트너하여 서비스 제공 하고 있습니다. 나중에 NoSQL 데이터베이스(MongoDB)까지 확대 지원하면 재밌겠네요!

• 해당 파트너십은 Snowflake Summit 2023년에 공개된 바 있습니다. Sarah Guo는 Snowflake 대표 Frank Slootman과 키노트를 같이 진행했었죠. Seek와 Snowflake 파트너십에 Sarah Guo의 역할이 있지 않았을까요? 미래에 Snowflake의 인수도 기대해볼 만 하겠습니다.

Risk

• Seek를 보면서 가장 먼저 떠오른 리스크 사항은 데이터 프라이버시 문제입니다. 클라우드 마이그레이션을 하는데도 그렇게 오래 걸렸는데 어떻게 엔터프라이즈 고객을 설득할 수 있을까요?

• Snowflake와 협업으로 1) 적정 세일즈 타겟 고객군(클라우드 활용 여부, 데이터 양 등)이 모여 있는 곳으로 GTM을 시작하여 리스크를 최소화하고, 2) Snowflake의 컨테이너 서비스를 활용하여 데이터 컴플라이언스 이슈를 제거할 수 있죠.

• 데이터 보안 이슈도 있습니다. 데이터 웨어하우스 내 모든 데이터를 모든 임직원에게 공개할 필요는 없죠. 특히 민감한 데이터면 외부유출 이슈도 있을 수 있습니다.

• (확실히 모르지만) 엔터프라이즈 입장에선 왠지 이런 사항을 컨트롤하기 위해 Workflow 내 데이터 엔지니어들이 한 번 가공/확인을 하는 역할이 필수적일 수도 있습니다. 예상했던 것과 다르게 워크플로우 특성으로 인해 기업 운영자 측에서 반대가 나올 수도 있죠. 하지만 분명히 CISO, 컴플라이언스 팀 등과 많은 인터뷰를 통해 시장니즈를 확인했을 것으로 생각합니다.

• Seek는 Pricing을 어떻게 할까요? Snowflake와 유사하게 Usage-based로 Query를 할 때 마다 과금이 이루어질 것 같습니다. 사용자들이 Snowflake를 사용할 때 마다 Snowflake와 AWS 비용까지 지불하면서 거기다가 추가 서비스를 지불할 때 WTP(Willingness to Pay)가 얼마일까요?

Conclusion

• 분량 조절과 컨셉 개연성 모두 실패한 블로그 포스트였습니다😥. 포트폴리오 업체 모두 커버하려다 보니 원하는 만큼 리서치가 원활하지 않았던 것 같습니다.

• 애초엔 Conviction의 포트폴리오를 쭉 살펴보고 AI 산업 내 “스마트 자본”은 어떻게 움직이는지, 전체적인 투자 Thesis 및 합당성에 대해 작성해보고 싶었지만… 각 포트폴리오 내용에 너무 매몰 되면서 애초에 생각했던 논리 전개와 많이 벗어난 것 같습니다. 앞으론 아래와 같은 방식으로 더 높은 퀄리티의 블로그를 작성하고자 합니다:
• 블로그 아웃라인 및 Brainstorming을 리서치와 같이 병행하기
• 리서치 시간을 줄이기 위해 재밌는 내용의 문서들을 평소에 잘 정리하기
• 마감시간 압박 줄이기 (2개 쓸 바에야 하나의 높은 퀄리티 블로그가 낫다)

• 다음부턴 높은 퀄리티의 블로그 포스트를 공유 드릴 수 있도록 점차 개선해 나가도록 하겠습니다😅.

• Wrapping up 하면서 앞으로 미래 AI 스타트업 지형을 볼 때 중요할 질문들을 정리했습니다:
• AI 엔지니어가 필수적인가? 단기적으론 AI 연구+프로덕트 팀이 성공할까?
• 높은 가치의 AI 어플리케이션 회사가 되는 방법은 자체 AI 모델을 개발할 수 밖에 없을까? 자체 AI 모델 개발 없이 경쟁력을 갖출 수 있는 방법이 있을까? 장기적으로 Moat가 구축이 가능한가? Jenni.ai는 자체 AI 모델 개발을 프로덕트 로드맵으로 고려하고 있을까?
• AI B2C 어플리케이션 폭발은 언제 올까? 높은 네트워크 효과, 리텐션, engagement 등 보이는 AI 어플리케이션을 만드는데 어떤 bottleneck/문제(model commoditization, 기능 추가 어려움 등)가 있는가?
• AI 어플리케이션을 구축하는데 있어 아키텍처를 어떻게 짜느냐에 따라 아웃풋 퀄리티가 좌지우지 됩니다. 미래엔 몇 가지의 “best-practice”로 정리 될까요, 아님 지금처럼 Trial & Error 방식으로 어플리케이션을 개선해나가는 방법이 유지될까요?
• 오픈소스 AI 모델과 Framework 회사들은 어떤 방식으로 수익화를 이뤄낼까?
• Enterprise AI 어플리케이션은 엔터프라이즈 데이터 프라이버시 문제를 어떻게 풀어나갈까?

• 언제나 말씀 드리듯이 의견, 질문, 피드백이 있으시면 편하게 메일이나 아래 LinkedIn으로 연락 부탁 드립니다 (커피챗도 좋습니다!☕). 특히, (지금이나 미래에) AI 관련하여 창업을 생각하고 계신 분들과 가볍게 편한 자리로 만나 뵙고 싶습니다😄.