2025-06-25-TIL
Today I Learned
주식 시세를 다루는 사이드 프로젝트의 설계를 시작했다. 아직은 무엇을 만들지 정리하는 단계라서, 오늘은 멘토링에서 받은 질문들을 정리하는 데 시간을 더 썼다. 질문은 대부분 “그 기술을 왜 골랐고, 내부는 어떻게 생겼는가”였다. 하나씩 공식 문서로 다시 확인했다.
GraphQL을 쓰면 생기는 문제
GraphQL은 클라이언트가 필요한 필드만 골라서 요청할 수 있다. 대신 서버 쪽에서는 필드마다 리졸버가 따로 돌기 때문에 N+1 문제가 생기기 쉽다. 친구 목록을 한 번 가져온 뒤, 친구 N명 각각의 하위 필드를 채우려고 N번 더 조회하는 식이다. GraphQL 공식 문서는 짧은 시간 동안 모은 요청을 한 번에 보내는 배치 방식, 예를 들어 DataLoader를 일반적인 해법으로 소개한다.
캐싱도 REST보다 어렵다. GraphQL over HTTP 명세를 따르는 구현은 기본적으로 POST를 지원하고, 쿼리에 한해 GET을 지원할 수도 있다. GET이어야 HTTP 캐시나 CDN을 쓰기 쉬운데, 쿼리가 길면 URL 길이 제한에 걸린다. 그래서 쿼리를 해시로 바꿔 보내는 persisted query를 함께 쓴다.
MongoDB의 WiredTiger
MongoDB는 기본 스토리지 엔진으로 WiredTiger를 쓴다(MongoDB 문서). 멘토링에서는 LSM 트리 이야기가 같이 나왔는데, WiredTiger의 테이블은 기본적으로 B-Tree로 표현된다. WiredTiger 아키텍처 문서도 테이블을 B-Tree 자료구조로 나타낸다고 설명한다. 쓰기가 많은 워크로드에서 LSM과 B-Tree가 어떻게 다른지는 따로 정리해 볼 주제로 남겨 둔다.
MySQL InnoDB의 B+Tree
InnoDB 인덱스는 공간 인덱스를 빼면 모두 B-Tree 자료구조이고, 인덱스 레코드는 리프 페이지에 저장된다. 기본 페이지 크기는 16KB다(MySQL 8.0 문서). 멘토링에서는 B+Tree라고 불렀는데, 문서는 B-Tree라는 이름을 쓴다. MySQL 용어집은 이 이름이 인덱스 설계의 큰 분류를 가리킬 뿐이고, MySQL 스토리지 엔진의 구조는 고전적인 B-Tree에 없는 개선이 들어간 변형으로 보면 된다고 설명한다. 정렬된 상태가 유지되기 때문에 같음 비교뿐 아니라 BETWEEN 같은 범위 조건도 빠르게 찾는다.
AWS Aurora
Aurora는 데이터를 클러스터 볼륨이라는 공유 스토리지에 둔다. 클러스터 볼륨은 한 리전의 가용 영역 세 곳에 데이터 사본을 나눠 저장한다(Aurora 스토리지 문서). 스토리지가 DB 인스턴스와 분리돼 있어서 인스턴스를 추가할 때 테이블 데이터를 복사하지 않고, 이미 있는 볼륨에 연결하기만 한다. 그래서 인스턴스를 빨리 늘릴 수 있고, 인스턴스를 지워도 데이터는 클러스터에 남는다.
AI 키워드: Gemini CLI
오늘 Google이 터미널에서 쓰는 오픈 소스 AI 에이전트인 Gemini CLI를 공개했다. 코드 설명, 기능 구현, 디버깅, 명령 실행을 자연어로 요청하는 도구다. 정리하면 다음과 같다.
- Apache 2.0 라이선스로 공개했다.
- Gemini 2.5 Pro를 쓰고, 컨텍스트 창은 100만 토큰이다.
- MCP(Model Context Protocol)를 기본으로 지원해서 외부 도구를 붙일 수 있다.
- 프리뷰 기간에는 개인 Google 계정으로 분당 60회, 하루 1,000회까지 무료다.
Claude Code와 같은 “터미널 안의 코딩 에이전트” 계열이 하나 더 늘어난 셈이다. 오픈 소스라서 에이전트가 도구를 어떻게 부르는지 코드로 직접 볼 수 있다는 점이 다르다.
댓글
아직 댓글이 없습니다