[GDG] I/O Extended 2024 Incheon - 후기
이번 행사는 발표자로 참여하였지만 발표 시간까지 기다리면서 일부 세션들을 들을 수 있는 기회가 있었다. (발표했던 내용은 따로 포스트로 정리해볼 예정)
다들 재밌는 주제로 많이 발표해주신 것 같다.
아래 정리한 두 발표의 내용도 새롭거나 중요하다고 느낀 부분들만 메모 수준으로 정리한 것이고 실제 내용은 더 많은 알찬 내용들을 담고 있었다.
이 외에도 예성님께서 발표하신 “어쩌다보니 Python 컨트리뷰터가 되었던 건에 대하여” 라는 발표와 인제님께서 발표하신 “100명의 개발자분들을 도와 100개 넘는 오픈소스 PR을 함께 만들고 세상을 바꾼 이야기” 라는 발표도 재밌게 들었다.
다른 발표들도 재밌어 보였는데, 시간이 겹치다보니 듣지 못한 발표가 너무 많아서 아쉬웠다.
Semantic Kernel로 내 기분 맞춤형 Spotify 플레이리스트 만들어보기 - 유저스틴님
Semantic Kernel : microsoft llm 통함 프레임워크 (like langchain), 최신 AI 모델 오케스트레이션, 다양한 언어를 제공하는 것이 장점.
Spotify api 에서는 음악에 대한 정보를 수치로 제공해주는데 그 정보들(danceability, valence …)을 이용해서 llm과 통합을 진행하셨다.
발표 내용을 쭉 들었을 때 Microsoft 의 방향은 멀티 플랫폼을 제공하려고 하는건가? 라는 생각이 들었다. 멀티 플랫폼을 지원해주시는 것은 개발자 입장에서 감사한 일이다.
Plan
중간에 Semantic Kernel의 plan 기능에 대해서도 소개해 주셨는데 “llm 자동사냥” 으로 비유하여 설명해주셨다. (찾아보니깐 langchain에는 있는 기능으로 보이는데 아쉽게도 내가 발표를 준비했던 spring ai 에는 없는 기능이였다. 아마 비교적 얼마되지 않은 라이브러리다 보니 만들어지지 못한 것 같다.)
이 기능이 개인적으로 정말 재밌었는데 plan 기능에 대해서 간단하게 설명하자면 사용자가 하고싶은 일에 최종적으로 도달할 수 있도록 LLM이 계획을 작성하고 그 계획에 따라서 실행을 해주는 것이다.
좋긴 하지만 planning에 비용이 계속 들기 때문에, 가이드 정도로 생각하고, plan이 잘 동작하면 그 plan 을 직접 코드로 구현하는 것이 좋다고 안내 해주셨다.
plan 에 대한 문서들
how to make slow my query. 왜 내가 만든 쿼리는 항상 느릴까? - 강성욱님
* 시작하기에 앞서 아래 내용들은 케이스에 따라 다르다는 것을 강조해주셨다.
DB 자체의 성능을 측정할 줄 알아야 함.
쿼리 읽는 법 (순서)
- from
- where
- on
- select
- etc…
쿼리를 분석하는 방법
- 테이블 정보 수집
- 인덱스 확인
- where, on
- select
- 제약 조건 확인
- 컬럼의 속성 확인 (길이)
- 인덱스 확인
클러스터 인덱스, 논 클러스터 인덱스
클러스터를 먼저 만들고 논 클러스터를 만들어야 한다. 아니면 다시 데이터를 재정렬 해야함.
사례
- 컬럼의 순서는 중요하지 않다.
- 반드시 필요한 컬럼만 조회한다.
- Lookup을 최소화 해야한다.
- 랜덤 액세스를 많이 발생시킨다.
- 복합 인덱스는 선행 컬럼에 따라 성능 차이가 큼
- 스키마를 통일 시키기
- 부정조건 피하기 (not in, !=, <> 등)
- 존재 유무를 확인할때는 exists 사용. limit 1 같은것 보다 빠름
- union 대신 union all 을 쓰면 더 빠를 수 있다. (union 은 중복 제거 과정이 들어간다.)
- 조인할 때 데이터를 작게 만들어서 점점 키워나가기
- select에서 function 을 호출하면 건별로 호출되니 느려지기 쉽다.
- 서브쿼리는 스칼라 서브쿼리는 성능에 문제를 발생시킬 수 있다. (함수처럼 row 수 만큼 동작)
인덱스 선정 전략
lookup 을 줄이자.