도식화된(Schematic) 비즈니스의 종말?

많은 소프트웨어 비즈니스들이 도식화된(schematic) 작업을 수행합니다: 그들은 사용자가 크고 다루기 어려우며 계속 진화하는 데이터 집합을 다루도록 도와주고, 그 데이터에 어떤 형태의 스키마나 분류 체계를 적용하여 이를 관리 가능하고 유용하게 만듭니다. 지난 20년 동안, 이러한 비즈니스 중 다수가 엄청난 성공을 거두었으며, 수천억 달러의 가치로 평가되었습니다. 이러한 비즈니스들은 다양한 형태와 맛을 가지고 있습니다. 예를 들어:

• CRM은 이메일 및 전화 통화와 같은 비정형 데이터를 받아 이를 스키마 인터페이스로 전환합니다: 연락처를 그룹화, 필터링, 정렬 및 조치할 수 있게 합니다.
• 비즈니스 인텔리전스 도구는 애플리케이션 데이터베이스 또는 Google Analytics와 같은 구조화된 데이터를 받아 이를 위한 새로운 시각적 인터페이스를 제공합니다.
• 특수 목적 OCR 도구는 원시 문서를 받아 주요 데이터를 추출하고, 이를 API를 통해 노출하여 다시 비정형 데이터를 구조화된 데이터로 변환합니다.

이것은 매우 광범위한 범주입니다. 기본적으로 모든 종류의 데이터 변환 작업을 포함하며, 이는 모든 종류의 관리 시스템, 문서 파싱 도구, 데이터 시각화 소프트웨어 등에 공통적으로 적용됩니다. 이 산업은 성공적이었습니다. 왜냐하면 데이터 변환이 (1) 역사적으로 까다롭고 노동 집약적이며 많은 엣지 케이스를 방어해야 했고 (2) 일반적으로 비즈니스의 깊은 곳에 통합되어 있기 때문입니다: 일단 Salesforce를 설치하면 다시 제거하지 않기 때문입니다.

따라서, 두 년 전만 해도 미친 것처럼 보였을 질문이 있습니다:

데이터 변환이 더 이상 가치가 없어지면 어떻게 될까요?

저는 두 가지 예를 들어 설명하겠습니다.

문서와 API

역사적으로 많은 비즈니스들이 이렇게 상호작용해 왔습니다:

그리고 오랜 기간 동안 엔지니어들의 대답은: 이 비즈니스들은 API가 필요하다는 것이었습니다. 직원들이 문서를 주고받는 대신, 시스템들이 직접 서로 대화해야 한다는 것이었습니다. 많은 훌륭한 회사들이 이 제안에 기반하여 설립되었습니다.

하지만 OCR이 매우 잘 작동하는 세계에서는 더 이상 큰 문제가 아닐 수 있습니다. 누군가 나에게 유용한 데이터를 포함한 문서를 이메일로 보낸다고 가정해 봅시다. 나는 그 문서를 텍스트를 추출하는 애플리케이션에 전달하고, LLM이 관련 데이터를 추출하며, 그 데이터를 내 데이터베이스 스키마에 맞추도록 지시할 수 있습니다. 데이터가 이메일로 온 문서인지 API로 온 것인지 실질적으로 중요하지 않게 됩니다. 데이터베이스에 어느 쪽이든 간에 쉽게 들어가게 되며, 두 회사가 API 스키마에 동의하고 유지보수가 필요한 상호운용성 레이어를 구축하는 데 몇 개월을 소비할 필요가 없어집니다.

Salesforce

작은 팀이 있고, 만 명의 고객과 그 고객들과 주고받은 수십만 개의 이메일이 있다고 가정해 봅시다. 모든 것을 추적하기 위한 전통적인 솔루션은 Salesforce와 같은 CRM입니다.

하지만 수십만 개의 이메일은 실제로 많은 데이터가 아닙니다. 모든 이메일을 데이터베이스에 넣고, 임베딩을 계산한 다음, RAG를 실행할 수 있습니다. 이것은 어려운 일이 아니며, LLM은 그 후에 데이터셋을 쿼리할 수 있게 해줍니다:

• Bryce가 Fisher Account와의 거래에서 어디에 있는지?
• Van Patten과 어떻게 진행 중이며, 후속 조치가 필요한지?
• McDermott와 마지막으로 무엇을 이야기했는지?
• 지난달에 내가 이야기한 계정과 이번 달에 이야기하지 않은 계정을 모두 나열해 주세요.

이 기능은 Salesforce가 제공하는 것과 유사합니다. "지난 6개월 동안 이야기하지 않은 모든 고객에게 후속 이메일을 보내세요"와 같은 프롬프트를 처리하는 기본 자동화를 추가하는 것은 쉽습니다. 수개월 동안 구축하고 유지 관리해야 하는 비용이 많이 드는 Salesforce 구현을 할 것인가, 아니면 전자의 선택을 할 것인가? 저는 후자를 선호합니다.

공격

세 가지 요소가 결합됩니다:

• 대형 언어 모델은 데이터 변환에 매우 능숙합니다;
• 계속 개선되는 데이터 저장 기술과 계산 비용의 하락으로 인해 임의의 데이터 변환을 실시간으로 실행하는 것이 가능해졌습니다;
• 비즈니스 데이터는 증가하고 있지만 느리게 증가하고 있습니다: 문서, 이메일, 스프레드 시트 등은 그다지 크지 않습니다.

머지않아 비즈니스는 (1) 매우 정밀한 전통적 인터페이스로 데이터를 조직할 수 있는 스키마 소프트웨어 또는 (2) 필요에 따라 데이터를 조직하고 인터페이스할 수 있는 LLM 애플리케이션 중에서 선택할 수 있는 옵션을 갖게 될 것입니다. 가까운 미래에는 스키마 소프트웨어가 LLM 애플리케이션보다 정밀성에서 우위를 가질 수 있지만, 시간이 지남에 따라 LLM 애플리케이션이 사용자 요구에 따라 정확한 변환을 수행하는 데 더욱 능숙해질 것으로 예상됩니다.

LLM의 장점

LLM 접근 방식에는 큰 장점이 있습니다: 훨씬 더 유연하여 설정하고 유지 관리하기가 귀찮지 않습니다.

예를 들어: 대부분의 회사는 대시보드 지옥에 있습니다. 그들은 비즈니스 데이터를 제공하는 다양한 내부 대시보드를 가지고 있습니다. 대부분의 직원들은 이러한 대시보드 중 두 개 정도만 친숙하며, 데이터 기반 답변을 찾으려고 할 때는 완전히 길을 잃습니다. 그들은 데이터 팀에게 질문을 해야 하고, 데이터 팀은 티켓을 작성하고, 결국 직원이 찾지 못할 어떤 뷰를 반환합니다. 이러한 대시보드 소프트웨어(Looker, Tableau, Sigma 등)는 최소 $10,000의 연간 비용이 들 뿐만 아니라, 이를 유지 관리하고 정규 직원들이 그들로부터 답을 얻을 수 있도록 도와야 하기 때문에 총 비용은 쉽게 연간 6자릿수 이상으로 빠르게 상승합니다.

하지만 경쟁이 다가오고 있습니다! 현재 많은 스타트업들이 LLM을 사용하여 정확히 이 문제를 공격하려고 합니다: 그들은 회사가 데이터베이스 및 기타 데이터 소스에 연결할 수 있도록 하고, 사용자가 자연어로 질문할 수 있도록 합니다. 그 이면에서, LLM 기반 애플리케이션은 실시간으로 스키마를 이해하고, 적절한 쿼리를 설계하며, 출력을 반환합니다. 이것은 현재의 비즈니스 인텔리전스 도구들이 제공하지 않는 방식으로 접근 가능하고 유용합니다.

나의 관점

여러 해 전, 나는 다양한 소스로부터 사용자 데이터를 처리하고 조정해야 하는 회사에서 일한 적이 있습니다. 일부 데이터는 서로 충돌하기도 했습니다. 나의 신입 엔지니어 본능은 우리가 기대할 수 있는 모든 것에 대해 정밀한 스키마를 신중하게 설계하고, 어떤 데이터를 우선하여 유지할지에 대한 신중히 생각된 규칙을 정의하는 것이었습니다.

더 경력이 많은 엔지니어들은 다른 길을 제안했습니다: 그들은 우리가 마주할 수 있는 모든 이상한 데이터 스키마를 예측하는 것이 너무 어렵다고 생각했으며, 따라서 모든 데이터를 쉽게 수용할 수 있는 하나의 단순하고 관대 한 스키마를 설계한 다음, 빠른 조화 알고리즘을 실행하여 쿼리에 대한 응답으로 최고의 데이터를 선택하는 데 모든 노력을 기울였습니다.

저는 종종 조화(harmonization)를 생각합니다. 이는 실용적인 엔지니어링을 위한 전형적인 '완벽을 좋은 것의 적으로 만들지 말라'는 클래식 중 하나였습니다: 특수한 경우에만 사용되는 깨지기 쉬운 시스템을 구축하는 대신, 유지 관리가 쉽고 대부분의 경우 잘 작동하며, 시간이 지남에 따라 성능을 조정할 수 있는 것을 구축하십시오. 초기에는 완벽한 정확성을 가질 수 없지만 대부분의 응용 프로그램에서는 완벽한 정확성이 필요하지 않으며, 그 타협이 가치가 있습니다.

나는 많은 소프트웨어 비즈니스가 유용하지만 깨지기 쉬운 특수한 시스템을 구성하여 데이터를 스키마화하고 있으며, 곧 LLM 애플리케이션이 데이터 상단에 단순히 앉아 실시간으로 조화를 이루는 것으로 대체될 것이라고 생각합니다.