GCP 기반 GraphDB, 뭘 선택해야 할까? – Spanner Graph와 BigQuery Graph를 같은 데이터, 같은 GQL로 비교해 보기
안녕하세요. GS Neotek 김민형 입니다.GCP에서 그래프 데이터베이스를 쓰려면 Spanner Graph와 BigQuery Graph 두 가지 선택지가 있습니다.둘은 같은 CREATE PROPERTY GRAPH 문법과 ISO 표준 GQL을 쓰기 때문에 겉보기에는 거의 같지만, 저장 구조와 실행 엔진이 달라 잘하는 일이 정반대입니다.이번 글에서는 두 서비스의 차이를 저장 구조와 실행 방식으로 설명하고, 같은 데이터와 같은 GQL로 실측한 결과를 바탕으로 어떤 상황에 무엇을 선택해야 하는지 정리합니다.GraphRAG에...
GCP Hub & Spoke에서 FortiGate로 Spoke 간 통신 중앙 통제하기 – 피어링 구조를 바꾸지 않고 동서 트래픽 검사하기
안녕하세요. GS Neotek 정만성 입니다.GCP에서 업무별로 프로젝트를 나누다 보면, 프로젝트(Spoke) 사이의 통신을 한곳에서 통제하고 기록해야 하는 요구가 자주 생깁니다.이번 글에서는 Hub & Spoke 구조에서 FortiGate HA를 중앙 검사 지점으로 두고, Spoke 간 통신과 인터넷으로 나가는 트래픽을 모두 FortiGate로 통과시킨 구성을 정리했습니다.실제로 구축하고 검증한 내용을 바탕으로, IP와 이름은 예시값으로 바꿨습니다. 한눈에 보기 항목내용목표1. Spoke끼리 직접 통신하지 못하게 하고 FortiGate를 반드시...
Agent Platform Model Monitoring Dashboard 구축 – Cloud Monitoring으로 여러 프로젝트의 Gemini 트래픽, 이상치, 에러, Batch 작업까지 한 화면에서 보기
안녕하세요. GS Neotek 김민형 입니다.Vertex AI(Agent Platform)에서 지원되는 Gemini 같은 모델을 여러 프로젝트에서 쓰다 보면, 사용량과 성능, 안정성을 한 곳에서 보고 싶어집니다.이번 글에서는 Cloud Monitoring 커스텀 대시보드로 모델별, 프로젝트별 트래픽부터 누적 사용량, 사용량 이상치, 에러와 지연, Batch 작업까지 쉽게 모니터링할 수 있는 대시보드를 구축하는 방법을 소개합니다.글에 나오는 설정값과 쿼리는 실제로 운영 중인 대시보드 JSON에서 가져온 것이라 그대로 적용해 보실...
Gemini 3.8 Flash vs Gemini 4 Argon, 같은 프롬프트로 3D 퍼즐 게임 만들기 비교 – 광고 속 “프롬프트 하나”는 어디까지 될까
안녕하세요. GS Neotek 정만성 입니다.Google이 Gemini 3.8 Flash를 공개하면서 “간단한 프롬프트 하나로 3D 퍼즐 게임을 만들었다”는 데모를 보여 줬습니다.그리고 얼마 전 상위 모델인 Gemini 4 Argon이 정식 출시됐습니다.벤치마크 점수만으로는 두 모델의 차이가 잘 와닿지 않아서, 같은 프롬프트로 실제 게임을 만들게 하고 직접 플레이해 비교해 봤습니다. 한눈에 보기 항목Gemini 3.8 FlashGemini 4 Argon퍼즐 진행1. trial1: 발판을 밟아도 반응 없음2. trial2:...
2주 만의 신모델, Gemini 4 Carbon – 보안·신뢰성·가격 정리
안녕하세요. GS Neotek 안지현입니다.Google이 10월 28일(미국 시간) 새 프런티어 모델 Gemini 4 Carbon을 발표했습니다.Gemini 4 Argon이 개발자와 기업에 일반 공개된 지 약 2주 만입니다. Argon의 발전 과정과 벤치마크는 권용민님의 Gemini 4 Argon 살펴보기 글에 잘 정리되어 있습니다.이 글은 그 연장선에서 Argon과 비교해 Carbon에서 무엇이 달라졌는지에 집중합니다. 이 글은 2026년 10월 29일 확인한 Google 공식 발표를 바탕으로 작성했습니다.Carbon은 아직 일반...
AlloyDB에서 BigQuery 바로 조회하기 – 레이크하우스 페더레이션 실시간 조회와 동기화 실측 비교
안녕하세요. GS Neotek 안지현입니다.실측 결과를 먼저 요약하면 다음과 같습니다. 실시간 조회(외부 테이블)는 푸시다운 여부와 관계없이 호출마다 1.2~1.5초(중앙값 1,258~1,476ms)가 걸렸습니다. 동기화한 로컬 테이블 JOIN은 174ms(서버 실행 3.7ms)로 실시간 조회보다 약 8배 빨랐습니다.응답 시간은 한국 로컬 PC에서 측정해 왕복 지연 약 169ms가 포함된 값입니다. 18만 행 규모에서는 푸시다운 유무에 따른 응답 시간과 BigQuery 처리량(4.75MB) 차이가 거의 없었습니다. 서비스 DB는 AlloyDB에, 몇...
최신 댓글