서론

안녕하세요. 그랜드투(grand2)에서 개발·운영·유지보수를 담당하고 있는 엔지니어 이와타입니다.

오늘은 2026년 7월 30일에 개최된 Google Cloud Next Tokyo의 Day1에 참가했기에, 당일 들었던 세션을 시간 순서대로 정리한 참가 리포트를 작성해 보았습니다.

저 자신의 관점에서 각 세션의 기술적인 배움과, 앞으로의 AI 시대에 현장에서 어떻게 행동해야 하는가라는 점에 초점을 맞추어 정리했습니다.

12:00 「SRE는 AI에게 무엇을 맡겨야 하는가 (PLAID × Datadog)」

스피커: 요코오 코스케 씨 (Datadog Japan), 하카마다 루이 씨 (PLAID), 오카모토 야스노리 씨 (PLAID)

애플리케이션의 품질 관리와 SRE의 역할, 그리고 Datadog의 활용 사례에 대한 이야기였습니다. 특히 눈길을 끈 것은 퍼포먼스 알람(Performance Alert) 발생 시의 대응 플로우가 매우 세밀하게 정형화되어 있다는 점입니다.

스트레스 테스트부터 어세스먼트(Assessment), 알람 발보, 그리고 대응에 이르기까지의 플로우가 명확하게 맵(Map)화되어 있으며, 그 안에서 AI 에이전트(SRE Agent)가 담당하는 영역이 붉은 글씨로 명확하게 정의되어 있었습니다. 이상 계통 알람이 발생한 후 해결될 때까지의 소요 시간이 극적으로 단축되고 있다는 데이터도 제시되어, 매우 높은 문제 해결 성능을 자랑하고 있음을 알 수 있습니다.

또한, 모든 것을 기성품 AI에 맡기는 것이 아니라, 자주 발생하는 정형적인 조사는 '자작 에이전트'를 사용하고, 복잡한 조사에는 '기성품 (Bits Investigation)'을 투입하는 등, 「COST」와 「CONTEXT」라는 2개의 축을 통한 구분법은 내일부터라도 참고할 수 있는 실천적인 판단 기준이었습니다.

💡 AI가 저지른 「오진」과, 그것을 막은 『MD 파일』

세션 중에는 Datadog의 자율형 AI인 「Bits Investigation」을 그대로 실행했을 때 발생했던, **가슴 철렁한 「실수 사례」**가 폭로되었습니다.

어느 날, API 에러 증가 알람을 계기로 Bits에게 장애 원인 조사(RCA, Root Cause Analysis)를 실행하게 했습니다. 에러 로그를 통해 「데이터베이스 타임아웃」이 일어나고 있다는 사실 자체는 Bits도 정확히 찾아냈지만, 그 이후의 판단을 그만 틀리고 말았습니다.

API 서버는 아시아(APAC) 리전에서 동작하고 있었던 반면, Bits는 무려 US(미국) 리전에 있는 데이터베이스의 메트릭(Metrics)을 조사하러 가버린 것입니다. 게다가 그 US 데이터베이스는 운영 환경의 **「애널리틱스 노드(분석용 데이터베이스)」**였으며, 확실히 레이턴시(Latency)는 악화되어 에러도 발생하고 있었지만, 실제 프로덕트에는 아무런 영향이 없는(무시해도 되는) 것이었습니다. 결과적으로 Bits는 전혀 엉뚱한 RCA(근본 원인 분석)를 내놓게 되어 대규모 오진이 되고 말았습니다.

🛠️ 해결책은 「컨텍스트를 Markdown으로 주입하는 것」

이 오진을 방지한 접근 방식은 매우 심플하면서도 실천적이었습니다.

개발자가 가지고 있는 「시스템 특유의 컨텍스트(지식)」를 인스트럭션(Instruction)용 **Markdown 파일(MD 파일)**로서 Bits에 읽히게 한 것입니다.

구체적으로 기술한 내용은 다음과 같습니다:

• 우리 시스템은 **「멀티 리전 구성」**으로 동작하고 있다는 점
• 리전을 식별하기 위한 독자적인 「명명 규칙·태그」 규칙
• 운영 데이터베이스 안에는 프로덕트 영향이 없는 **「분석용 데이터베이스」**가 공존하고 있다는 컨텍스트
• 메트릭의 상관관계(에러와 레이턴시의 동시 발생 등)만으로 멋대로 판단하지 말고, 서비스 카탈로그나 서비스 맵의 **「의존 관계 (Dependency)」**를 베이스로 조사할 것

이러한 내용들을 추가한 결과, 다음번부터는 Bits가 완벽하게 올바른 RCA를 실행할 수 있게 되었습니다.

「AI는 알아서 시스템을 이해해주지 않는다. 그렇기에 우리가 가진 지식을 MD나 서비스 카탈로그에 집약하여, AI가 참조할 수 있는 **컨텍스트 플랫폼(Context Platform)**으로 키워나갈 필요가 있다」라는 메시지는 개발·운영에 종사하는 사람으로서 깊이 와닿았습니다.

14:00 「메르카리의 글로벌 앱에서 도전한 AlloyDB 운용」

스피커: 하타나카 유사쿠 씨 (주식회사 메르카리)

Pub/Sub의 Retry Storm에 의한 커넥션 고갈을 계기로, AlloyDB의 Managed Connection Pooling (MCnP)을 도입한 실천 사례입니다.

MCnP의 활성화나 단계적 이행 과정에서 IAM 인증의 지원 상황이나 Pooler 수의 차이 등으로 인한 장벽에 부딪히기도 했지만, Direct 연결을 활용해 여러 대의 Pooler를 이용하면서 모듈별로 단계적인 이행을 실현했다는 고군분투하는 프로세스가 소개되었습니다.

이행 후에도 모니터링을 하며 커넥션 수의 적절한 튜닝을 지속하고 있었으며, Before/After 슬라이드 그래프에서는 커넥션 수가 들쭉날쭉한 상태에서 깨끗하게 안정된 플랫(Flat)한 라인으로 변화한 것을 한눈에 확인할 수 있었습니다.

음성 없이도, "Managed는 통째로 맡겨두는 것이 아니다", "도입하고 끝나는 것이 아니다"라는 매니지드 서비스(Managed Service)를 운용하는 데 있어 본질적인 배움을 얻을 수 있었습니다. 또한, 증가하는 읽기(Read) 부하에 대처하기 위해 자체 구현한 라우팅 기능이 포함된 클라이언트**(sqlc의 DBTX 인터페이스를 충족하는 것)**나, 버퍼 풀(캐시)이 채워지지 않은 신규 Read Pool을 본방 투입하기 전에 미러링(mirroring)으로 쿼리를 흘려보내

워밍업(Warm-up) 시키는 궁리 등, 즉시 활용할 수 있는 실천적인 데이터베이스 운용 지견이 응축되어 있었습니다.

16:00 「AI 에이전트 시대의 「분업 설계」 (오이카와 타쿠야 씨 × Google)」

스피커: 오이카와 타쿠야 씨(Tably 주식회사), 테츠오 슈헤이 씨(주식회사 혼다 기술연구소), 시미즈 타카유키 씨(Google Cloud)

기술적인 딥 다이브(Deep Dive) 이후에는 조직이나 컬처(Culture)에 가까운 세션이었습니다. 여기서 제시된, AI가 24시간 체제로 대량 생성한 코드를 인간이 감사하는 부담을 가리키는 **「검증세(Verification Tax)」**나, 책임의 소재가 모호해지는 **「책임의 스펀지화」**에 대한 이야기는 매우 공감할 수 있는 내용이었습니다.

세션을 들으면서 제 머릿속에서도 다음과 같은 의문이나 생각이 떠올랐습니다.

• 코딩 비용이 낮아진 만큼, 다른 곳에서 비용(검증이나 리뷰 등)이 발생할 가능성은 없는가?
• 10년 후, 20년 후에도 「제대로 사용할 수 있는(유지보수 및 운용 가능한) 시스템임」이 보장되는가. 보이지 않는 부채 비용이 있는 것은 아닌가?
• AI 도입으로 인해 직종은 몇 개월 단위로 계속 변해간다. 하지만 최종적인 판단은 역시 인간이 해야 한다.
• 4가지 축이 있다고 할 때, 개별 멤버가 자신의 의견을 가질 수 있는지, 그리고 그 의견을 말할 수 있는 환경(심리적 안전성, HRT: 겸손·존중·신뢰, 철저한 의견 교환)이 마련되어 있는지가 중요하다.
• 함께 등단하셨던 테츠오 씨가 말씀하신 "자동차 업계라면 OEM이 아웃컴(Outcome, 성과)을 만들어내지 않으면 성립되지 않는다"라는 말. 자동차에서도 소프트웨어 개발의 품질이나 팀의 아웃컴이 업계 전체에 큰 영향을 미친다는 점을 깊이 생각하게 되었습니다.

AI가 에이전트로서 개발 프로세스에 합류하는 시대이기에, 결론적으로 심플하게

「팀을 소중히 하자」

라고 강하게 느꼈습니다. AI를 "결정자"가 아니라, 철저하게 논의를 나누기 위한 "인풋(Input) 중 하나"로 파악하고, 팀으로서의 신뢰 관계(HRT)를 높이는 것이야말로 앞으로의 소프트웨어 엔지니어링에서 살아남는 열쇠라고 확신했습니다.

17:00 「TimeTree의 Spanner 사례 소개 〜 DynamoDB로부터의 이행과 전문 검색 〜」

스피커: 카나이 에이키 씨(주식회사 TimeTree), 이시모리 칸타 씨(주식회사 TimeTree), 코자사 쇼타 씨(주식회사 TimeTree)

프라이빗 공유 캘린더로서 개인적으로도 큰 도움을 받고 있는 「TimeTree」의 세션입니다. 연락하지 않아도 그룹별로 상대방의 일정을 자동으로 알 수 있어, 놀이 일정 조정 등에 매우 유용하게 쓰이는 훌륭한 앱입니다.

세션은 인프라, 백엔드, 퍼포먼스 개선의 3부 구성으로 매우 알기 쉽게 정리되어 있었습니다.

AWS의 DynamoDB에서 Google Cloud의 Cloud Spanner로 약 400만 건의 대규모 데이터를 이행하는 프로젝트인데, **초실전적인 「3가지 함정과 트러블슈팅(Troubleshoot)」**이 이야기되었습니다.

⚠️ 함정 ①: 데이터 중복으로 건수가 맞지 않는다! 멋대로 덮어쓰기 되는 upsert의 함정

배치 잡(Batch Job, AWS S3에서 GCS를 경유하여 Spanner로 과거의 기존 데이터를 일괄 쓰기) 시, 당초에는 쓰기에 InsertOrUpdate (upsert)

뮤테이션(Mutation)을 사용하고 있었습니다.

하지만 DynamoDB의 파티션 키(Partition Key)가 「날짜」였기 때문에, 날짜를 넘나드는 동일한 UUID의 중복 데이터가 생성되는 케이스가 발생했습니다. InsertOrUpdate를 사용하면 에러를 전혀 내뱉지 않고 기존 데이터를 마음대로 최신 데이터로 덮어써 버리기 때문에, "데이터 이관은 에러 없이 완료되었는데, 왜인지 구 DB와 신 DB의 데이터 건수가 전혀 맞지 않는다"라는 공포스러운 현상이 일어났습니다.

【해결책】: 쓰기 작업을 Insert 뮤테이션(Mutation)으로 변경하여, 중복 시 확실하게 에러(고유 제약 조건 위반)를 검출하도록 했습니다. 그 후, Report Failure Mode를 설정함으로써 에러가 발생하더라도 파이프라인 전체의 처리는 중단하지 않고, 중복된 데이터만 에러 로그로 분리하여 안전하게 이관을 완료했습니다.

⚠️ 함정 ②: 스트리밍 엔진이 OFF! 워커 메모리 폭사 사건

데이터 이관 중에도 사용자의 쓰기(서브 데이터)를 Pub/Sub을 통해 실시간 동기화하기 위해 스트리밍 잡(Streaming Job)을 실행하고 있었습니다.

그런데 잡을 시작할 때, Terraform의 기본 설정 그대로 **"스트리밍 엔진을 OFF"**로 한 상태에서, 게다가 「N1」이라는 매우 작은 워커 머신(Worker Machine)을 사용하고 말았습니다.

스트리밍 엔진이 OFF 상태이면, Dataflow의 윈도우 처리(중복 제거 및 정렬)를 위한 방대한 스테이트 데이터(State Data, 상태 데이터)를 모두 워커 컨테이너의 로컬 메모리에 계속 유지하게 됩니다. 결과적으로, 처음 수백 개의 메시지를 처리한 단계에서 워커의 메모리가 고갈(OOM)되어 완전히 프리즈(Freeze) 되어버렸습니다.

【해결책】: 스트리밍 엔진을 활성화했습니다. 이를 통해 스테이트 관리 및 윈도우 집계 처리가 Dataflow 측의 서비스 백엔드로 오프로드(Offload)되어, 워커 컨테이너는 "데이터 가공 및 쓰기"에만 전념할 수 있게 되었습니다. 메모리를 압박하지 않게 됨에 따라, 매우 가벼운 최소 클래스의 머신으로도 전혀 흔들림 없이 초안정적으로 동작하는 환경이 완성되었습니다.

⚠️ 함정 ③: 전문 검색(Full-text Search) 출시 직후, 특정 쿼리가 "6초 대기"로 급격히 느려짐!

TimeTree는 Spanner 단독으로 「전문 검색 기능(공개 캘린더의 텍스트 검색)」을 도입했는데, 프로덕션 출시 직후 특정 키워드를 검색하면 쿼리 응답에 6초 이상 걸리는 심각한 성능 저하가 발생했습니다.

원인은 Spanner의 서치 인덱스(Search Index) 설계에서 「Order By」 설정이 누락되었던 것이었습니다.

Spanner의 서치 인덱스는 일반적인 인덱스와 사양이 달라, 인덱스 측에 미리 정렬 순서(최신순 등)를 지정해 두지 않으면 쿼리 측에서 ORDER BY를 작성하더라도, "검색 키워드에 걸린 전체 건수(수만~수십만 건)를 메모리 상에서 암묵적으로 정렬하는" 최악의 스캔 처리가 실행되어 버립니다.

【해결책】: 서치 인덱스 정의에 Order By를 추가하여 최신 일시만을 반환하도록 설정했습니다. 하지만 여기서도 Spanner 특유의 제약에 부딪힙니다.

• 타임스탬프(Timestamp) 타입은 Order By로 지정할 수 없는 사양: 캘린더의 일시는 타임스탬프 타입이지만 직접 지정할 수 없기 때문에, INT64 타입(Unix 시간 등)으로 변환한 컬럼을 스키마에 추가하고 그것을 Order By로 지정함으로써 회피했습니다.
• Order By와 STORING의 공존 불가: 검색에 사용하는 STORING 컬럼과 Order By로 지정한 컬럼은 동일한 인덱스 내에 공존할 수 없다는 제한이 있기 때문에, STORING에서 제외하고 Order By를 우선시하는 설계로 변경했습니다.

이 처절한 튜닝 결과, 쿼리 응답 속도는 무려 "6초 ➔ 400밀리초"로 15배 이상의 압도적인 고속화를 달성했습니다!

18:00 「DevNight - 개발자를 위해! Google AI를 체험하자!」

스피커: 슈 셸리(Google), 데이비드 맥러플린(Google), 반다리 하렌드라(Google Cloud), 타나베 유키(CureApp 주식회사), 지 주연(Google DeepMind), 다나카 요이치로(Tably 주식회사)

정말 살짝만 보고 가려 했으나, 마지막까지 너무나 흥미로워 빠져들고 만 DevNight.

음성으로는 Google Cloud Next만의 최신 AI 아키텍처부터, 내일부터 바로 시도해 볼 수 있는 흥미로운 로컬 AI 해킹, 모던 프론트엔드(Modern Frontend) 개발에 이르기까지, 소름 돋을 정도로 놀라운 기술 에피소드가 가득했습니다.

💡 에이전트 개발을 가속화하는 4가지 기술

1️⃣ Google Agent Platform의 방어벽 「Model Armor (모델 아머)」

자율형 에이전트(비결정적으로 동작하는 AI)를 운영 환경(Production)에서 운용할 때 가장 큰 우려는 보안과 안전성입니다.

이를 해결하기 위해 Google이 데모와 함께 발표한 것이 바로 **「Model Armor」**라는 게이트웨이(Gateway) 시스템이었습니다.

AI에 악의적인 프롬프트를 보내 시스템의 내부 규칙을 폭로하게 만드는 「프롬프트 인젝션 (Prompt Injection)」이나 괴롭힘 표현, 나아가 사용자가 실수로 입력한 신용카드 정보나 PII(개인정보)와 같은 「기밀 데이터」를 에이전트에 도달하기 전(게이트웨이 계층)에서 감지하여 즉시 「403 에러」로 차단하는 메커니즘이 소개되었습니다. 에이전트를 실무 환경에서 운용하기 위한 「방패」가 매니지드(Managed) 형태로 준비되어 있다는 점은 압도적인 안심을 줍니다.

2️⃣ Firebase × AI: AI Logic와 App Check의 보안 철칙

Firebase의 전문 지식을 AI에 주입하는 「Firebase Skills/MCP」를 사용하여, 로컬호스트(Localhost) 상의 에뮬레이터 환경에서 AI에게 함수(Function) 로그 등을 읽히며 디버깅 개발을 하는 미래형 개발 방식이 소개되었습니다.

또한, 서버 사이드에서 AI를 호출하는 「Genkit」에 대해, 프론트엔드(모바일·웹 앱)에서 서버를 거치지 않고 Gemini API를 직접 호출하는 「AI Logic」의 설계 차이점이 설명되었습니다.

여기서 매우 중요하다고 느낀 점은, AI Logic은 간편한 반면 API 키나 쿼리 소비의 부정 사용(DDoS나 악의적인 과금 소비) 리스크에 노출된다는 점입니다. 따라서 인증되지 않은 부정 클라이언트의 요청을 네트워크 입구에서 차단하는 **「App Check (앱 체크)」**와의 조합이 보안상의 **「절대적인 필수 구성 (Best Practice)」**임이 강조되었습니다.

3️⃣ Gemma (로컬 LLM)의 자율성과 「스시 3D 프린터」 비유

「기업의 거대한 3D 프린터가 클라우드의 Gemini라면, 누구나 가정에서 사용할 수 있는 작은 프린터가 오픈 소스인 Gemma이다」라는 독특한 비유로 시작된 로컬 LLM 해설.

「스시를 주세요」라고 출력을 요청했을 때, 재료 지시를 잊어 참치나 연어가 무작위로 나와버리는 것이 AI의 비결정적 동작입니다. 만약 「빵」, 「고기」, 「토마토」를 각각 따로 출력한 뒤, 스스로 햄버거로 조립해서 먹는 것처럼, 도구(Tool)와 책임을 나누어 조합하는 것이 에이전트를 제어하는 현명한 설계 방법이라는 설명은 무릎을 탁 치게 만들었습니다.

나아가 단어를 다차원 벡터로 변환하는 **「Embedding (임베딩)」**의 메커니즘을 친절하게 해설했습니다. 인터넷상의 무수한 텍스트를 학습한 결과, 「사과 (Apple)」와 「iPhone」이 전혀 프로그래밍하지 않았음에도 벡터 공간상에서 자연스럽게 가까운 위치에 매핑되는 히트맵 클러스터(Heatmap Cluster) 데모가 매우 이해하기 쉬웠습니다.

LM Studio나 Ollama를 사용하여, 비행기 안과 같은 **「완전한 오프라인 환경」**에서도 NPC AI 에이전트가 도구(열쇠나 스위치)의 위치를 스스로 찾아내어 장치를 풀고 문을 열고 나가는 자율형 게임 데모는 로컬 LLM의 무한한 가능성을 느끼게 해주었습니다.

4️⃣ Stitch × AntiGravity 2.0: View Transitions API와 Built-in AI의 경이로움

프론트엔드 파트에서는 과거의 「입체적인 버튼, 여백 제로, 충돌하는 색상, 모든 모서리가 직각인」 촌스러운 업무용 화면에서, 순식간에 세련된 모던 UI로 리팩토링하는 프로세스가 AI 디자인 도구인 「Stitch」와 「AntiGravity 2.0」을 통해 데모되었습니다. 불과 몇 분간의 미팅 중에 움직임이 포함된 고퀄리티 목업(Mockup)이 완성되는 속도감입니다.

특히 기술적으로 흥분되었던 점은 다음과 같은 최신 웹 표준 기술의 활용이었습니다:

• View Transitions API: 목록 화면에서 클릭한 리스트 요소가 상세 화면을 열 때 '심리스(Seamless)하게 쑥 커지면서 그대로 상세 뷰로 모핑(Morphing)되는' 듯한, OS 네이티브 앱과 착각할 정도의 부드러운 애니메이션을 아주 적은 CSS/JS만으로 구현하는 최신 API.
• Built-in AI (Gemini Nano): 브라우저(Chrome)에 표준으로 내장된 로컬 AI 모델. Web 앱에 업로드된 영수증 이미지를 서버로의 API 요청을 일절 거치지 않고 (API 과금 완전 제로, 또한 초저지연(Ultra-low latency)으로 프라이버시도 안전하게) 디바이스 상의 CPU만으로 OCR 처리(문자 읽기)를 완결시키는 데모에는, 행사장 전체가 정적에 휩싸일 정도의 충격이 일었습니다.

전체를 관통하는 배움

하루 종일, **"AI로 개발이 편해지는 만큼, 인간이 고려해야 할 아키텍처(Architecture)나 컨텍스트(Context) 설계가 늘어난다"**는 것을 강하게 실감한 하루였습니다.

매니지드 서비스(AlloyDB의 MCnP나 Spanner)도, 생성형 AI(Datadog Bits나 각종 Agent)도, 결코 "통째로 맡겨두면" 끝나는 마법의 도구가 아닙니다.

"무엇이 배후에서 어떻게 움직이고 있으며, 무엇이 나의 컨트롤 영역인가"라는 메커니즘을 올바르게 이해하고, 메트릭(Metrics)을 관측하며 끊임없이 튜닝(Tuning)해 나가야 합니다.

그리고 기술이 몇 시간, 몇 달 단위로 격변하는 AI 시대이기에 더욱, 최종적인 "설계와 판단"을 내리는 인간 엔지니어의 가치와, 철저하게 본질적인 의견을 나눌 수 있는 "신뢰할 수 있는 팀(HRT)"의 기초 역량이 지금 가장 시험받고 있다고 확신했습니다.

보너스

12:00~ 런치 타임, 18:00~ DevNight에서는 맛있는 음식이 나왔습니다! 🍴

(내년에 참가하실 초보자분들께: 음성용 수신기(Receiver)와 이어폰은 세션을 예약했더라도 수량이 한정되어 있습니다. 늦지 않게 줄을 서서 빌려두세요! 그러지 않으면 무음 상태로 확대 사진을 연신 찍어대야 하는 상황이 발생합니다! ㅎㅎ)

Discussion