_(1).jpeg&blockId=0e552736-74f0-4f5a-89e1-328d4931ca7c)
후기
25년 7월 26일, 인천 인하대 60주년 기념관에서 열리는 google IO Extended 행사에 다녀왔다. 여러 호실에서 동시에 진행되는 세션 중 마음에 드는 주제의 세션을 골라 듣는 형식이었다.
일반 티켓은 3만 5천 원, 학생 티켓은 2만 5천 원이어서 ‘꽤 큰 행사인가?’라는 생각을 했지만 부스는 만다리안 AI 하나밖에 없었고 주차 정산도 안되고 (5시간에 1만 7천 원) 네트워킹 세션도 없어서 아쉬웠다.
어떤 세션들은 유익하고 흥미로웠지만, 어떤 세션들은 발표 주제와 상관없는 이야기만 계속 하거나, 너무 뻔한 얘기만 하는 등 발표 내용이 전문적이지 않다는 생각이 들었다.
행사 스케일이나 퀄리티에 비해 가격이 너무 비쌌다는 생각이 들었다. 학생 한 명이랑 갔는데 학생인지 아닌지 티켓 확인도 안해서 이럴 거면 왜 굳이 일반 티켓이랑 학생 티켓이랑 나눠서 판 건지 의문이었다.
들으면서 괜찮았다고 생각했던 세션들을 정리해보았다.
Snowflake는 어떻게 고유 ID를 만들까? 분산 시스템을 위한 ID 설계 원리
대규모 트래픽을 처리하는 서비스에서 가장 먼저 마주하는 과제 중 하나는 고유 ID 생성 방식이다. 특히 수많은 서버에서 동시에 데이터를 처리해야 할 때, ID 충돌 없이 빠르게 Primary Key를 생성하려면 어떤 방식이 가장 좋을까?
이 세션은 이 문제를 Snowflake ID라는 해결책으로 접근했다. 트위터가 처음 도입한 이 방식은 단순히 “ID를 만드는 방법”을 넘어, 대규모 분산 시스템의 인프라 설계에 대한 통찰을 주었다.
Snowflake ID란 무엇인가?
Snowflake ID는 다음과 같은 비트 구조를 가진 64비트 정수형 값이다.
| 1bit sign | 41bit timestamp | n-bit machine ID | n-bit sequence |
Plain Text
복사
•
1bit sign: 음수와 양수를 구별하는 데 사용하며, 큰 용도는 없음.
•
41bit timestamp: UTC 기준 밀리초 단위 시간. 약 69년 간의 유효기간
•
Machine ID / Worker ID: 서버나 노드 구분
•
Sequence: 같은 시간 내에 생성된 ID의 중복을 막기 위한 카운터
이 구조는 ID 자체에 시간 정보가 들어 있어 정렬성과 유일성을 동시에 보장한다. 즉, 정렬된 ID를 보면 생성 시점을 유추할 수 있고, 동시에 빠른 검색에도 유리하다.
왜 UTC로 timestamp를 써야 할까?
로컬 시간을 기준으로 ID를 생성하면 서버마다 시차가 다르기 때문에 생성된 ID가 시간 순으로 정렬되지 않거나, 중복 충돌이 발생할 수 있다. UTC를 기준으로 하면 서버 간의 시간 기준을 통일할 수 있고, 추가적인 createdAt 컬럼 없이도 ID 자체로 생성 시점을 알 수 있다.
분산 서버에서 충돌이 없는 이유
Snowflake는 서버마다 고유한 Worker ID를 할당하여 ID 충돌을 방지한다.
•
단일 DB, 다중 서버: 서버 간 Worker ID가 다르기 때문에 중복 없음
•
다중 DB, 다중 서버: Worker ID는 사실상 "Server ID"로 사용되므로, 나중에 DB를 통합하더라도 ID 충돌이 발생하지 않는다
동시성 이슈와 락 처리
ID를 병렬로 생성하다 보면 이론적으로 동일한 밀리초에 같은 서버에서 두 개 이상의 ID가 생성될 수도 있다. 이를 방지하기 위해 보통 서버 내부적으로 mutex나 spinlock 등으로 동시성 제어를 수행한다. 특히 성능 테스트에서는 멀티스레드 환경에서 1만 건 insert를 하며 중복 여부를 체크해볼 수있다.
Auto Increment vs UUID vs Snowflake
방식 | 장점 | 단점 |
Auto Increment | 간단, DB 관리에 용이 | 단일 DB에 의존, 락 발생 |
UUID | 중복 가능성 낮음, 글로벌 서비스에 적합 | 길다(성능 저하), 정렬 불가, 인덱스 캐시 부하 |
Snowflake | 시간순 정렬 가능, 중복 없음, 분산에 적합 | 구조 복잡, 직접 구현 필요 |
UUID도 v7부터는 timestamp 기반으로 개선되고 있지만, 여전히 문자열이기 때문에 BigInt 기반의 Snowflake보다 인덱스 성능이 떨어질 수 있다.
왜 Snowflake는 대량 입력에 적합할까?
Snowflake는 단순히 유일한 ID만 만드는 것이 아니라 대량 처리 상황에서 병목을 최소화한다.
예를 들어 이벤트 보상 지급처럼 수만 건의 아이템 데이터를 생성해 item 테이블에 insert해야 하는 경우, ID 충돌 없이 빠르게 bulk insert가 가능하다. 물론 insert 시 한 번에 너무 많은 데이터를 밀어 넣으면 OOM(Out Of Memory)이 발생할 수 있으므로, 보통은 1,000~2,000건씩 나눠 처리한다.
연사자 분은 과거 1만 건 insert에 2분 걸리던 작업도 bulk insert로 나누면 1초 내로 끝난다고 경험을 공유해주셨다.
Clustered Index와 Snowflake의 궁합
MySQL 기준으로 Primary Key는 기본적으로 Clustered Index다. 즉, 레코드가 실제로 PK 값 기준으로 물리적으로 정렬되기 때문에 ID가 순차 증가하는 Snowflake와 궁합이 매우 좋다.
반면 UUID는 난수 기반으로 순차성이 없기 때문에 정렬과 인덱스 캐싱 측면에서 불리하다.
초기에 뭘 써야 할까?
초기에는 Auto Increment나 UUID로 간단하게 시작할 수도 있다. 그러나 서비스가 성장하여 멀티 서버 환경이나 대량 트랜잭션이 필요한 시점이 되면 ID 생성 방식을 Snowflake로 마이그레이션하게 되는 경우가 많다.
단, 마이그레이션을 하려면 기존 테이블과 모든 연관 테이블의 PK/FK를 전부 업데이트해야 하므로, 생각보다 복잡하다. 수일간 점검과 서비스 이관이 필요하기 때문에 처음부터 설계에 포함시키는 것이 바람직하다.
요약
•
Snowflake는 시간 + 서버 정보 + 시퀀스를 조합한 ID 생성 방식이다.
•
분산 서버 환경에서도 중복 없이 고유 ID를 만들 수 있다.
•
정렬성과 성능을 동시에 확보할 수 있으며, 대량 입력 작업에 적합하다.
•
초기 설계부터 Snowflake를 고려하는 것이 장기적으로 유리하다.
Gemma on device: Edge AI를 위한 경량 LLM 전략
Edge AI란 무엇인가?
Edge AI는 데이터를 중앙 서버로 전송하지 않고, 데이터가 발생하는 현장(디바이스 내)에서 AI 처리를 수행하는 방식이다. 로컬 메모리에서 직접 모델을 실행하므로 데이터 프라이버시 확보, 응답 지연 최소화, 그리고 예측 가능한 비용 구조를 구현할 수 있다.
“Your data, your rule”
Edge AI는 개인 데이터는 개인 규칙대로 다뤄진다는 철학을 기반으로 한다. 회사 서버나 클라우드에 민감한 데이터를 전송하지 않아도 되므로, 내부 감시나 외부 유출에 대한 우려 없이 작업할 수 있다. 공개된 가중치를 쓰는 모델(open weights model)을 활용하면 투명성을 확보하고 직접 미세 조정(fine‑tune)도 가능하다. AI의 행동과 구조를 개발자가 제어할 수 있다.
Gemma 3 개요
•
주요 특징:
◦
Transformer 디코더 베이스 구조 기반으로 설계됨
◦
128K 토큰의 긴 컨텍스트 지원으로 복잡한 입력을 처리 가능
◦
140개 이상 언어 지원 및 멀티모달(Image+Text+Video) 기능 제공: 단, 1B 모델은 텍스트 전용이다
◦
Quantization‑Aware Training(QAT) 기반으로 INT4 정도까지 경량화하여 27B 모델도 일반 GPU에서 실행 가능
•
Gemma 3 27B는 DeepSeek 671B와 유사한 성능을 내며, 단일 GPU(예: H100)에서 실행 가능
•
4B 모델도 Gemma 2 27B 모델과 유사한 성능 보유
Gemma 3n: 디바이스 특화 모델
2025년 6월 출시된 Gemma 3n은 E2B, E4B 등 Effective 파라미터 모델로 구현되며, 2~4 GB RAM 환경에서도 동작 가능하다. 텍스트·이미지·오디오·비디오를 모두 처리할 수 있는 멀티모달 모델로, 완전 오프라인 실행 가능하다. 프로그래밍 구조로는 Per‑Layer Embedding (PLE) 파라미터 캐싱, MatFormer 구조 등으로 설계되어 메모리와 계산 효율을 극대화한다. (gemma 3n 공식문서)
Demonstration & 실제 사용 경험
실습 데모에서 랩탑 또는 스마트폰 환경에서 Gemma 3, Gemma 3n을 실행하는 모습이 소개되었다. 특히 Gemma3 1B 모델은 529 MB 크기에 INT4 양자화 시, Android 디바이스에서 수 초 내 실행 가능하며 실행 속도는 약 2,585 tokens/sec 이상으로, 페이지 단위의 텍스트 예측도 1초 이내 가능하다. 실제로 브라우저에서 실행한 1B 모델은 아주 빠르게 텍스트를 처리했다.
반면, 4B 모델은 iPhone 데모에서 실행했는데 연사자분 설명으로는 이미지 설명 작업이 약 420초 걸렸다고 한다. 때문에 향후에는 백그라운드 비동기 처리 방식 개선이 필요함을 언급했다.
연사자분의 구글 가이드 팁
•
영어로 봐야 빠진 게 없음 (번역된 걸로 보면 빠진 게 있다고 한다.)
•
안드로이드를 먼저 봐야함. 안드로이드가 항상 먼저 피쳐가 추가되어있음.
요약
•
Edge AI는 저비용 구조, 지연시간 최소화, 데이터 프라이버시 보장 등 여러 장점을 가진다.
•
Gemma 3는 경량이지만 프론티어급 성능을 제공하며, 특히 Gemma 3n은 모바일 Edge에서 오디오/영상 분석까지 가능한 완전 멀티모달 모델이다. 하지만 속도는 느림…
•
하이브리드 아키텍처를 고려하되, 모델 사이즈와 UX(비동기 처리, 속도) 문제에 대한 전략적 고민이 필요하다.
사이드 프로젝트에 쓸 수 있을까 생각에 흥미롭게 들었지만 멀티 모달리티는 실행하는데 몇 분 단위로 시간이 걸리고, AI 모델을 사용자 디바이스에 다운받기 위해서는 어플 실행 후 사용자에게 2~4GB를 다운받게 해야하기 때문에 아직 상용화하기엔 어려워보인다.
코드
연사자 분이 공유해주셨던 코드를 공유한다.
