Ibis는 모든 쿼리 엔진에서 실행되는 Python 데이터프레임 API를 정의합니다. 현재 20개 이상의 백엔드가 있는 모든 백엔드 데이터 플랫폼의 프런트엔드입니다. 이를 통해 Ibis는 연결된 백엔드만큼 뛰어난 성능을 일관된 사용자 경험과 함께 제공할 수 있습니다.

https://ibis-project.org/why

Ibis defines a Python dataframe API that executes on any query engine – the frontend for any backend data platform, with 20+ backends today. This allows Ibis to have excellent performance – as good as the backend it is connected to – with a consistent user experience.

What is Ibis?

Ibis is the portable Python dataframe library.

We can demonstrate this with a simple example on a few local query engines:

import ibis

ibis.options.interactive = True

1con = ibis.connect("duckdb://")

t = con.read_parquet("penguins.parquet")
t.limit(3)

┏━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━┓
┃ species ┃ island    ┃ bill_length_mm ┃ bill_depth_mm ┃ flipper_length_mm ┃ body_mass_g ┃ sex    ┃ year  ┃
┡━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━┩
│ string  │ string    │ float64        │ float64       │ int64             │ int64       │ string │ int64 │
├─────────┼───────────┼────────────────┼───────────────┼───────────────────┼─────────────┼────────┼───────┤
│ Adelie  │ Torgersen │           39.1 │          18.7 │               181 │        3750 │ male   │  2007 │
│ Adelie  │ Torgersen │           39.5 │          17.4 │               186 │        3800 │ female │  2007 │
│ Adelie  │ Torgersen │           40.3 │          18.0 │               195 │        3250 │ female │  2007 │
└─────────┴───────────┴────────────────┴───────────────┴───────────────────┴─────────────┴────────┴───────┘

t.group_by(["species", "island"]).agg(count=t.count()).order_by("count")

┏━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┓
┃ species   ┃ island    ┃ count ┃
┡━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━┩
│ string    │ string    │ int64 │
├───────────┼───────────┼───────┤
│ Adelie    │ Biscoe    │    44 │
│ Adelie    │ Torgersen │    52 │
│ Adelie    │ Dream     │    56 │
│ Chinstrap │ Dream     │    68 │
│ Gentoo    │ Biscoe    │   124 │
└───────────┴───────────┴───────┘

Who is Ibis for?

Ibis is for data engineers, data analysts, and data scientists (or any title that needs to work with data!) to use directly with their data platform(s) of choice. It also has benefits for data platforms, organizations, and library developers.

Ibis for practitioners

You can use Ibis at any stage of your data workflow, no matter your role.

Data engineers can use Ibis to:

• write and maintain complex ETL/ELT jobs
• replace fragile SQL string pipelines with a robust Python API
• replace PySpark with a more Pythonic API that supports Spark and many other backends

Data analysts can use Ibis to:

• use Ibis interactive mode for rapid exploration
• perform rapid exploratory data analysis using interactive mode
• create end-to-end analytics workflows
• work in a general-purpose, yet easy to learn, programming language without the need for formatting SQL strings

Data scientists can use Ibis to:

• extract a sample of data for local iteration with a fast local backend
• prototype with the same API that will be used in production
• preprocess and feature engineer data before training a machine learning model

Ibis for data platforms

Data platforms can use Ibis to quickly bring a fully-featured Python dataframe library with minimal effort to their platform. In addition to a great Python dataframe experience for their users, they also get integrations into the broader Python and ML ecosystem.

Often, data platforms evolve to support Python in some sequence like:

1. Develop a fast query engine with a SQL frontend
2. Gain popularity and need to support Python for data science and ML use cases
3. Develop a bespoke pandas or PySpark-like dataframe library and ML integrations

This third step is where Ibis comes in. Instead of spending a lot of time and money developing a bespoke Python dataframe library, you can create an Ibis backend for your data platform in as little as four hours for an experienced Ibis developer or, more typically, on the order of one or two months for a new contributor.

Ibis for organizations

Organizations can use Ibis to standardize the interface for SQL and Python data practitioners. It also allows organizations to:

• transfer data between systems
• transform, analyze, and prepare data where it lives
• benchmark your workload(s) across data systems using the same code
• mix SQL and Python code seamlessly, with all the benefits of a general-purpose programming language, type checking, and expression validation

Ibis for library developers

Python developers creating libraries can use Ibis to:

• instantly support 20+ data backends
• instantly support pandas, PyArrow, and Polars objects
• read and write from all common file formats (depending on the backend)
• trace column-level lineage through Ibis expressions
• compile Ibis expressions to SQL or Substrait
• perform cross-dialect SQL transpilation (powered by SQLGlot)

How does Ibis work?

Most Python dataframes are tightly coupled to their execution engine. And many databases only support SQL, with no Python API. Ibis solves this problem by providing a common API for data manipulation in Python, and compiling that API into the backend’s native language. This means you can learn a single API and use it across any supported backend (execution engine).

Ibis broadly supports two types of backend:

1. SQL-generating backends
2. DataFrame-generating backends

 

 

 

 

As you can see, most backends generate SQL. Ibis uses SQLGlot to transform Ibis expressions into SQL strings. You can also use the .sql() methods to mix in SQL strings, compiling them to Ibis expressions.

While portability with Ibis isn’t perfect, commonalities across backends and SQL dialects combined with years of engineering effort produce a full-featured and robust framework for data manipulation in Python.

In the long-term, we aim for a standard query plan Intermediate Representation (IR) like Substrait to simplify this further.

Python + SQL: better together

For most backends, Ibis works by compiling Python expressions into SQL:

g = t.group_by(["species", "island"]).agg(count=t.count()).order_by("count")
ibis.to_sql(g)

SELECT
  *
FROM (
  SELECT
    `t0`.`species`,
    `t0`.`island`,
    COUNT(*) AS `count`
  FROM `ibis_read_parquet_pp72u4gfkjcdpeqcawnpbt6sqq` AS `t0`
  GROUP BY
    1,
    2
) AS `t1`
ORDER BY
  `t1`.`count` ASC NULLS LAST

You can mix and match Python and SQL code:

sql = """
SELECT
  species,
  island,
  COUNT(*) AS count
FROM penguins
GROUP BY species, island
""".strip()

con = ibis.connect("duckdb://")
t = con.read_parquet("penguins.parquet")
g = t.alias("penguins").sql(sql)
g

┏━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┓
┃ species   ┃ island    ┃ count ┃
┡━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━┩
│ string    │ string    │ int64 │
├───────────┼───────────┼───────┤
│ Adelie    │ Torgersen │    52 │
│ Adelie    │ Biscoe    │    44 │
│ Adelie    │ Dream     │    56 │
│ Gentoo    │ Biscoe    │   124 │
│ Chinstrap │ Dream     │    68 │
└───────────┴───────────┴───────┘

g.order_by("count")

┏━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┓
┃ species   ┃ island    ┃ count ┃
┡━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━┩
│ string    │ string    │ int64 │
├───────────┼───────────┼───────┤
│ Adelie    │ Biscoe    │    44 │
│ Adelie    │ Torgersen │    52 │
│ Adelie    │ Dream     │    56 │
│ Chinstrap │ Dream     │    68 │
│ Gentoo    │ Biscoe    │   124 │
└───────────┴───────────┴───────┘

This allows you to combine the flexibility of Python with the scale and performance of modern SQL.

Scaling up and out

Out of the box, Ibis offers a great local experience for working with many file formats. You can scale up with DuckDB (the default backend) or choose from other great options like Polars and DataFusion to work locally with large datasets. Once you hit scaling issues on a local machine, you can continue scaling up with a larger machine in the cloud using the same backend and same code.

If you hit scaling issues on a large single-node machine, you can switch to a distributed backend like PySpark, BigQuery, or Trino by simply changing your connection string.

Stream-batch unification

As of Ibis 8.0, the first stream processing backends have been added. Since these systems tend to support SQL, we can with minimal changes to Ibis support both batch and streaming workloads with a single API. We aim to further unify the batch and streaming paradigms going forward.

Ecosystem

Ibis is part of a larger ecosystem of Python data tools. It is designed to work well with other tools in this ecosystem, and we continue to make it easier to use Ibis with other tools over time.

Ibis already works with other Python dataframes like:

• pandas
• Dask
• Polars

Ibis already works well with visualization libraries like:

• matplotlib
• seaborn
• Plotly
• Vega-Altair
• plotnine

Ibis already works well with dashboarding libraries like:

• Streamlit
• Dash
• Quarto dashboards
• Shiny

Ibis already works well with machine learning libraries like:

• scikit-learn
• XGBoost
• LightGBM
• PyTorch

Supported backends

You can install Ibis and a supported backend with pip, conda, mamba, or pixi.

pip install 'ibis-framework[bigquery]'

See the backend support matrix for details on operations supported. Open a feature request if you’d like to see support for an operation in a given backend. If the backend supports it, we’ll do our best to add it quickly!

Community

Community discussions primarily take place on GitHub and Zulip.

Getting started

If you’re interested in trying Ibis we recommend the getting started tutorial.

[DataBase] Postgres를 검색엔진으로 활용하기  

https://anyblockers.com/posts/postgres-as-a-search-engine

• 
  Postgres 내에서 시맨틱, 전문, 퍼지 검색을 모두 갖춘 하이브리드 검색 엔진을 구축할 수 있음
• 검색은 많은 앱에서 중요한 부분이지만 제대로 구현하기 쉽지 않음. 특히 RAG 파이프라인에서는 검색 품질이 전체 프로세스의 성패를 좌우할 수 있음
• 의미론적(Semantic) 검색이 트렌디하지만, 전통적인 어휘 기반 검색은 여전히 검색의 중추임
• 의미론적 기술은 결과를 개선할 수 있지만, 견고한 텍스트 기반 검색의 기반 위에서 가장 잘 작동함

Postgres를 활용한 검색 엔진 구현하기

• 세 가지 기술을 결합:
  • tsvector를 사용한 전체 텍스트 검색
  • pgvector를 사용한 의미론적 검색
  • pg_trgm을 사용한 퍼지 매칭
• 이 접근 방식은 모든 상황에서 절대적으로 최고는 아닐 수 있지만, 별도의 검색 서비스를 구축하는 것에 대한 훌륭한 대안임
• 기존 Postgres 데이터베이스 내에서 구현하고 확장할 수 있는 견고한 출발점
• Postgres를 모든 것에 사용해야 하는 이유 : 그냥 Postgres를 모든 곳에 사용하세요, PostgreSQL로 충분하다, 그냥 Postgres 쓰세요

FTS와 의미론적 검색 구현

• Supabase에 하이브리드 검색 구현에 대한 훌륭한 문서가 있으므로, 이를 시작점으로 삼을 것임
• 가이드에 따라 GIN 인덱스를 사용하여 FTS를 구현하고, pgvector(bi-encoder dense retrieval이라고도 함)를 사용하여 의미론적 검색을 구현함
• 개인적인 경험으로는 1536차원의 임베딩을 선택하는 것이 훨씬 더 나은 결과를 얻을 수 있음
• Supabase 함수를 CTE와 쿼리로 대체하고, 매개변수 앞에 $를 붙임.
• 여기서는 RRF(Reciprocal Ranked Fusion)를 사용하여 결과를 병합함
• 이 방법은 여러 목록에서 높은 순위를 차지하는 항목이 최종 목록에서 높은 순위를 부여받도록 보장함
• 또한 일부 목록에서는 높은 순위지만 다른 목록에서는 낮은 순위인 항목이 최종 목록에서 높은 순위를 부여받지 않도록 보장함
• 순위를 분모에 넣어 점수를 계산하면 순위가 낮은 레코드에 불이익을 줄 수 있음
• 주목할 만한 사항
  • $rrf_k: 첫 번째 순위 항목의 점수가 극단적으로 높아지는 것을 방지하기 위해(순위로 나누기 때문에), 분모에 k 상수를 추가하여 점수를 평활화하는 경우가 많음
  • $ _weight: 각 방법에 가중치를 할당할 수 있음. 이는 결과를 조정할 때 매우 유용함

퍼지 검색 구현하기

• 이전까지의 방법으로도 많은 부분을 해결할 수 있지만, 명명된 엔티티에서 오타가 있을 경우 즉각적인 이슈가 발생할 수 있음
• 의미론적 검색은 유사성을 포착하여 이러한 이슈 중 일부를 제거하지만, 이름, 약어 및 의미론적으로 유사하지 않은 기타 텍스트에 대해서는 어려움을 겪음
• 이를 완화하기 위해 pg_trgm 확장을 도입하여 퍼지 검색을 허용
  • 트라이그램으로 작동함. 트라이그램은 단어를 3자 시퀀스로 분해하기 때문에 퍼지 검색에 유용
  • 이를 통해 오타나 약간의 변형이 포함되어 있더라도 유사한 단어를 매칭할 수 있음
  • 예를 들어 "hello"와 "helo"는 많은 트라이그램을 공유하므로 퍼지 검색에서 더 쉽게 매칭될 수 있음
• 원하는 열에 대해 새 인덱스를 생성하고, 그 후 전체 검색 쿼리에 추가
• pg_trgm 확장은 % 연산자를 노출하여 유사도가 pg_trgm.similarity_threshold(기본값은 0.3)보다 큰 텍스트를 필터링함
• 유용한 다른 여러 연산자도 있음.

전문 검색 튜닝하기

• tsvector 가중치 조정하기 :실제 문서에는 제목뿐만 아니라 내용도 포함됨
• 열이 여러 개 있어도 임베딩 열은 하나만 유지함
• 개인적으로 여러 임베딩을 유지하는 것보다 title과 body를 같은 임베딩에 유지하는 것이 성능에 큰 차이가 없다는 것을 발견함
• 결국 title은 본문의 간단한 표현이어야 함. 필요에 따라 이를 실험해 보는 것이 좋음
• title은 짧고 키워드가 풍부할 것으로 예상되는 반면, body는 더 길고 더 많은 세부 정보를 포함할 것임
• 따라서 전체 텍스트 검색 열이 서로 어떻게 가중치를 부여하는지 조정해야 함
• 문서에서 단어가 있는 위치나 중요도에 따라 우선순위를 부여할 수 있음
  • A-weight: 가장 중요(예: 제목, 헤더). 기본값 1.0
  • B-weight: 중요(예: 문서 시작 부분, 요약). 기본값 0.4
  • C-weight: 표준 중요도(예: 본문 텍스트). 기본값 0.2
  • D-weight: 가장 덜 중요(예: 각주, 주석). 기본값 0.1
• 문서 구조와 애플리케이션 요구사항에 따라 가중치를 조정하여 관련성을 미세 조정함
• 제목에 더 많은 가중치를 부여하는 이유
  • 제목은 일반적으로 문서의 주요 주제를 간결하게 표현하기 때문
  • 사용자는 검색할 때 먼저 제목을 훑어보는 경향이 있으므로 제목의 키워드 일치는 일반적으로 본문 텍스트의 일치보다 사용자의 의도와 더 관련이 있음

길이에 따른 조정

• ts_rank_cd 문서를 읽어보면 정규화 매개변수가 있다는 것을 알 수 있음.
  • 두 랭킹 함수 모두 문서의 길이가 순위에 어떤 영향을 미쳐야 하는지 여부를 지정하는 정수 normalization 옵션을 사용함. 정수 옵션은 여러 동작을 제어하므로 비트 마스크임: |를 사용하여 하나 이상의 동작을 지정할 수 있음(예: 2|4).
• 이러한 다양한 옵션을 사용하여 다음을 수행 가능
  • 문서 길이 편향 조정
  • 다양한 문서 집합에서 관련성 균형 조정
  • 일관된 표현을 위해 랭킹 결과 조정
• 제목에는 0(정규화 없음), 본문에는 1(로그 문서 길이)을 설정하면 좋은 결과를 얻을 수 있음
• 다시 말하지만, 사용 사례에 가장 적합한 옵션을 찾기 위해 다양한 옵션을 실험해 보는 것이 좋음

크로스 인코더를 사용한 재랭킹

• 많은 검색 시스템은 두 단계로 구성됨
• 즉, 양방향 인코더를 사용하여 초기 N개의 결과를 검색한 다음, 크로스 인코더를 사용하여 이러한 결과를 검색 쿼리와 비교하여 순위를 매김
  • 양방향 인코더(bi-encoder) : 빠르기 때문에 많은 수의 문서를 검색하는 데 좋음
  • 크로스 인코더(cross-encoder)
    • 더 느리지만 성능이 더 좋아 검색된 결과의 순위를 다시 매기는 데 좋음
    • 쿼리와 문서를 함께 처리하여 둘 사이의 관계에 대한 더 미묘한 이해를 가능하게 함
    • 이는 계산 시간과 확장성을 희생하면서 더 나은 랭킹 정확도를 제공함
• 이를 수행하기 위한 다양한 도구들이 있음
• 가장 좋은 것 중 하나는 Cohere의 Rerank임
• 또 다른 방법은 OpenAI의 GPT를 사용하여 자체적으로 구축하는 것임
• 크로스 인코더는 쿼리와 문서 간의 관계를 더 잘 이해할 수 있도록 하여 검색 결과의 정확도를 높일 수 있음
• 그러나 계산 비용이 크기 때문에 확장성 면에서는 제한이 있음
• 따라서 초기 검색에는 양방향 인코더를 사용하고, 검색된 소수의 문서에 대해서만 크로스 인코더를 적용하는 두 단계 접근 방식이 효과적임

언제 대안 솔루션을 찾아야 할까

• PostgreSQL은 많은 검색 시나리오에 적합한 선택이지만 한계가 없는 것은 아님
• BM25와 같은 고급 알고리듬의 부재는 다양한 문서 길이를 처리할 때 느껴질 수 있음
• PostgreSQL의 전체 텍스트 검색은 TF-IDF에 의존하므로 매우 긴 문서와 대규모 컬렉션의 희귀 용어에 어려움을 겪을 수 있음
• 대안 솔루션을 찾기 전에 반드시 측정해 보아야 함. 그럴 가치가 없을 수도 있음

결론

• 이 글에서는 기본적인 전체 텍스트 검색부터 퍼지 매칭, 의미론적 검색, 결과 부스팅과 같은 고급 기술까지 많은 내용을 다루었음
• Postgres의 강력한 기능을 활용하여 특정 요구사항에 맞춘 강력하고 유연한 검색 엔진을 만들 수 있음
• Postgres는 검색을 위해 가장 먼저 떠오르는 도구는 아니지만 정말 멀리 갈 수 있게 해줌
• 훌륭한 검색 경험을 위한 핵심
  • 지속적인 반복과 미세 조정
  • 논의한 디버깅 기법을 사용하여 검색 성능을 이해하고, 사용자 피드백과 행동을 기반으로 가중치와 매개변수를 조정하는 것을 두려워하지 말아야 함
• PostgreSQL은 고급 검색 기능이 부족할 수 있지만, 대부분의 경우 충분히 강력한 검색 엔진을 구축할 수 있음
• 대안 솔루션을 찾기 전에 먼저 Postgres의 기능을 최대한 활용하고 성능을 측정해 보는 것이 좋고, 그래도 부족하다면 그때 다른 솔루션을 고려해 볼 수 있음

https://news.hada.io/topic?id=16468&utm_source=weekly&utm_medium=email&utm_campaign=202436

오픈AI는 챗GPT(ChatGPT)의 주간 활성 사용자가 2억 명을 돌파했다고 밝혔다. 이는 지난해보다 두 배 증가한 수준이다.

39일 악시오스에 따르면, 포춘 500대 기업 중 92%가 오픈AI 제품을 사용하고 있다. 또 GPT-4o 미니(mini)가 올 7월에 출시된 이후 자동화 API 사용량이 두 배 증가했다.

샘 올트먼 오픈AI 최고경영책임자(CEO)는 “사람들이 우리의 도구를 이제 일상적으로 사용하고 있으며, 이는 의료 및 교육과 같은 분야에서 실질적인 변화를 가져오고 있다”며 “일상적인 업무 지원부터 어려운 문제 해결, 창의성 발현까지 다양한 영역에서 도움을 주고 있다”고 말했다.

오픈AI는 생성형 AI 챗봇 시장에서 선두 자리를 유지하고 있다. 하지만 테크 기업들이 점유율을 높이고자, 서비스를 업데이트하면서 경쟁 격화에 노출된 상태다.

이날 메타(Meta)는 오픈 소스 라마(Llama) 모델의 도입이 급격히 증가했다고 밝혔다. 라마(Llama) 3.1 출시 이후 올해 5월과 7월 사이 주요 클라우드 서비스 제공업체에서의 사용량이 두 배 증가했다는 것이 회사측 설명이다.

마이크로소프트, 구글, 오픈AI, 메타 간 사용자 확보 경쟁은 더욱 치열해질 전망이다.

https://www.mk.co.kr/news/it/11105925

Classic ASP에서 GUID 생성 방법

Classic ASP에서 브라우저에 접속한 사용자의 고유한 키 값을 생성하기 위해 주로 사용하는 방법은 **GUID(Globally Unique Identifier)**를 생성하는 것입니다. GUID는 전 세계에서 유일한 값을 가지도록 설계된 128비트 값으로, 사용자의 고유 세션이나 식별자를 만들 때 유용합니다.

Classic ASP에서 GUID 생성 방법

ASP에서 GUID를 생성하는 가장 쉬운 방법은 Scriptlet.TypeLib을 사용하여 GUID를 만드는 것입니다. 다음은 Classic ASP에서 GUID를 생성하여 고유 키를 얻는 코드입니다.

<%
Function GenerateGUID()
    Dim objTypeLib
    Set objTypeLib = CreateObject("Scriptlet.TypeLib")
    GenerateGUID = objTypeLib.Guid
    Set objTypeLib = Nothing
End Function

' 생성된 GUID 호출 예제
Dim uniqueKey
uniqueKey = GenerateGUID()

' 브라우저에 출력
Response.Write "Generated Unique Key: " & uniqueKey
%>

설명

1. CreateObject("Scriptlet.TypeLib"): Scriptlet.TypeLib 객체는 GUID를 생성할 수 있는 COM(Component Object Model) 객체입니다.
2. GenerateGUID = objTypeLib.Guid: .Guid 속성을 호출하면 GUID 값을 반환합니다. 이 값은 일반적으로 { }로 감싸진 문자열로 출력됩니다.
3. 고유한 키 사용: 생성된 uniqueKey를 쿠키, 세션 변수 등에 저장하여 사용자 식별 등에 사용할 수 있습니다.

고유 키 생성 방법의 활용

• 세션 관리: 로그인 세션 관리에 활용할 수 있습니다.
• 추적 및 분석: 방문자를 추적하거나 분석할 때 유용합니다.
• 데이터베이스 키: 사용자별 고유한 데이터베이스 키로 사용할 수 있습니다.

이 방법을 사용하면 Classic ASP에서 손쉽게 고유한 키 값을 생성하여 사용할 수 있습니다.

월가는 특정 종류의 승자를 선호한다. 이는 단기 수익과 영업 이익이 추정치를 뛰어넘는, 최상의 분기별 재무 보고서를 발표할 수 있는 승자를 의미한다.

월가는 장기적인 관점, 특히 초장기적인 관점에는 거의 신경 쓰지 않는 듯하다. 기업 경영진이 몇 년 후 급성장할 기술을 지배하기 위해 신중하게 장기 계획을 세울 때보다 분기별 실적이 급상승할 때 주가가 급등할 가능성은 훨씬 더 높다.

이것이 7월 말 마이크로소프트의 실적 발표에 대한 주식 시장의 반응이 주는 교훈이다. 투자자들에게 중요한 소식은 무엇이었을까? 마이크로소프트의 클라우드 기반 애저(Azure) 비즈니스가 해당 분기에 “단지” 30% 성장해 회사가 예상했던 31%보다 1% 낮았다는 점이다.

다음 날 트레이더들은 마이크로소프트를 ‘처벌’했다. 전체 시장이 상승세(예를 들어 S&P 지수는 86% 증가)인 와중에 회사의 주가는 4% 이상 하락했다. 이는 마이크로소프트가 분기 매출 15%, 순이익 10%가 증가했다고 발표한 뒤에 일어난 일이다.

마이크로소프트의 AI 장기 투자에 무심한 월가
실적 발표에서 나온 훨씬 더 중요한 소식은 마이크로소프트가 AI에 올인하고 있으며 수년간 수익을 내지 못할 수도 있는 장기 인프라에 막대한 비용을 지출하고 있다는 점이었다. 하지만 주가를 기준으로 볼 때 이 소식이 월가에서는 중요하지 않은 것처럼 보였다.

마이크로소프트 CFO인 에이미 후드는 애널리스트들과의 통화에서 190억 달러의 자본 지출이 거의 모두 AI 및 클라우드와 관련이 있다고 말했다. 지출의 절반은 인프라 관련 비용, 특히 AI용 대규모 컴퓨팅 성능에 필요한 데이터센터를 구축하는 데 사용됐다. 이는 AI 붐이 본격화되기 전인 2년 전보다 2배 이상 증가한 수치다.

이에 대해 뉴욕타임스는 “수익 보고서는 마이크로소프트가 데이터센터를 구축하고 AI 기술을 구동하는 고가의 칩을 구입하는 데 막대한 비용을 지출하고 있음을 보여준다. 회사의 자본 지출은 나델라가 최고 경영진에게 AI 투자를 독려한 2022년 말부터 매 분기 증가했다”라고 설명했다.

이 정도의 지출 규모는 마이크로소프트가 AI 시장을 계속 장악하고 향후 수십억 달러의 수익을 거두기 위해 반드시 필요할 터지만 월가를 성가시게 했다. 특히 후드가 대규모 지출이 “향후 15년과 그 이후에도 수익 창출을 지원할 것”이라고 설명했을 때 투자자들을 겁을 먹었을 가능성이 높다.

월가에서 15년은 15억 년처럼 느껴질 수 있으며, 이들은 향후 10년 후의 ‘먼 미래’가 아니라 지금 당장, 그리고 단기적인 성과를 원한다.

마이크로소프트의 대대적인 AI 베팅은 옳은 선택일까?
금융 시장이 수년간 수익을 내지 못할 기술에 거액을 투자하는 기업을 경계하는 데에는 그만한 이유가 있다. 기술은 빠르게 변하고, 기업이 ‘넥스트 빅 씽’을 추구하는 과정에는 변덕이 있을 수 있다. 오늘 확실한 기회처럼 보이는 것이 내일은 실패로 바뀔 수 있다. 가상 현실에 대한 과대 광고만 봐도 알 수 있다. 가상 현실에 대한 성과는 그 어느 때보다 찾기 어렵고 어쩌면 영원히 오지 않을 가능성도 있다.

하지만 AI에서는 그런 일이 일어나진 않을 것이다. 베팅이 클수록 더 큰 보상을 얻을 가능성이 높다. 가상 현실은 실제로 큰 수익을 창출한 적이 없지만, AI는 이미 그랬다. 게다가 아직 초기 단계다.

실제로 지난 분기에 마이크로소프트의 수익은 AI 서비스에 대한 수요를 따라잡지 못해 타격을 입었다. CEO 사티아 나델라와 후드는 실적 발표에서 데이터센터에 공급 역량이 충분했다면 해당 분기에 더 많은 AI 서비스를 판매할 수 있었을 것이라고 말했다.

마이크로소프트의 투자자 관계 책임자인 브렛 아이버슨은 뉴욕타임스에 “용량이 확보되는 즉시 판매되고 있다”라고 밝혔다.

AI 서비스에 대한 마이크로소프트의 수요 제약은 올해 남은 기간 동안 지속될 전망이다. 하지만 후드는 새로운 투자 덕에 2025년부터 성과를 거두기 시작할 것이라고 언급했다. 후드는 AI 수요에 힘입어 2025 회계연도 1분기에 클라우드 매출이 28%~29% 성장할 것으로 예상했다.

그리고 이는 시작에 불과할 수 있다.

새로운 ‘세대의 것(generational thing)’의 부상
나델라는 “일단 사용되기 시작하면 이는 ‘세대의 것’이 된다”라고 말하며, 코파일럿 생성형 AI가 “이전 세대에 출시된 그 어떤 소프트웨어보다 빠른 속도로 성장하고 있다”라고 언급했다. 

필자는 일반적으로 신기술을 둘러싼 과대 광고에 꽤 냉소적인 편이다. 기술 기업 CEO들이 천상의 결과를 약속한 뒤 실현 가능한 결과조차 내놓지 못하는 경우가 많기 때문이다.

하지만 이번에는 다른 듯하다. 마이크로소프트 365용 코파일럿을 검토해 본 결과, 가끔 환각을 일으키는 등 몇 가지 문제는 있지만 실제 결과를 제공하는 견고한 제품이었다. 수요는 계속 증가할 가능성이 높다.

다른 많은 생성형 AI 및 AI 기술도 마찬가지다. 이를 위한 인프라를 구축 중인 마이크로소프트의 AI 베팅은 천문학적인 규모이지만, 사실 몇 년 동안은 성과를 거두지 못할 수도 있다. 그러나 결국 승자 중 한 명이 될 것이라는 점에는 의심의 여지가 없다.

큰 베팅은 결국 큰 승리를 의미하는 것이기도 하다. https://www.ciokorea.com/news/348821