Google I/O Extended Incheon 2025 후기

 

작년에도 참가했던 컨퍼런스에 올해도 참석하게 됐다.

2024.07.28 - [일상/대외활동] - I/O Extended 2024 Incheon 참가 요약 및 후기

 

올해는 좀 쉬어갈까 했는데, 발표자분이 초대해줌 + 오랜만에 지인들도 볼겸 참가하게 됐다. 컨퍼런스를 갈 때마다 보고싶은게 서로 다른 세션에 흩어져 있어서, 왔다갔다하는게 피곤해서 이번엔 Tech 세션에서 쭉 듣기로 했다.

 

가장 많이 도움될만한 세션 1번과 6번일 것 같고, 2,4번도 재밌을 것 같다. 3,5번은 사실 큰 도움이 될 것 같진 않지만, 한번쯤 들어볼만하지 않을까? 란 기대를 하고 있다.

 

1. SnowFlake, 분산서버에서 고유 ID를 생성하는 방법

대상 : 백엔드 5년차 이상의 RDB 테이블 설계 경험(PK와 인덱스에 대한 고민), 연관 테이블 설계  대량의 insert 경험이 있으면 듣기 좋다.

 

일반적인 ID 생성 방법은 무조건 고유하지 않다. 트랜잭션 혹은 중복체크가 필요한데, 복합키들은 키 복잡도를 증가시킨다.

게임 서버 개발에서 복합키를 사용함 : 단일 객체의 인덱스 크기 증가, 인덱스 삽입, 대용량 DB에 부적합, 단일 키 기반으로 변경

대량 작업이 필요한 툴에서 자동증가 사용 : 연관 테이블을 느려니 ID 마다 트랜잭션 발생, 심각한 성능 저하, SnowFlake 알고리즘 기반으로 키변경 후 Bulk Insert

 

SnowFlake 알고리즘 : 트위터에서 개바뢴 ID 생성 알고리즘, 64비트 정수로 중복없는 고유한 갑슬 생성할 수 있음 Bit 이동을 통해 시간 +발행자정보 + 순번 정보를 조합 - 굉장히 유명한 알고리즘

 

 

위와같이 사용하면....

1. 데이터베이스는 한 곳일 때, 분산 서버에서 동일한 키를 생성하지 않게 된다.

2. 데이터베이스가 여러개 일때 하나로 통합해도 ID가 중복되지 않는다.

 

주의할 점

1. 매직넘버를 사용하는 경우 : 1970년 부터 사용한 거라 55년이 날아간 상황, 그냥 사용하면 15년정도의 제한을 가짐. 시작 시간(1970년 -> 현재)을 뒤로 미루는걸 매직넘버를 쓴다고 함

 

2. 글로벌 서비스를 목표로 한다면, 서버 타임존으로 인한 문제가 발생한다.

로컬 시간을 기준으로 하면 서버 시간에 따라 ID값이 중구난방으로 생성해서 기준이 모호해짐

통일된 타임존을 기준으로 ID를 생성한다면 CreateTime을 추가 컬럼없이 관리 가능

 

3. 동시성 제어가 반드시 필요

서버 성능을 고성능화 하기 위해선 병렬처리가 필수 -> 이에 따른 동시성 이슈로 동일한 PK가 생성된 확률이 존재

Mutex 등의 Lock 관리를 통해 동시성 제어가 필수(모두 분산락을 만들어야할까? 결국 AtomicInteger 같은 쓰레드 안전한 변수를 써야하는걸까?)

 

4. 중복된 값을 만들지 않기 위해 생성 서비스의 단일화

1개의 서비스에서 ID 생성 인스턴스를 단일로 관리, 생성된 1개의 ID는 어떠한 경우에도 중복되지 않음을 의미, 실수로 다른 테이블에 조회하더라도 유니크하기 때문에 조회되지 않음. 다른 데이터가 잘못 연결되는 실수를 방지

PK가 다 똑같이 생긴 것 처럼 보임(숫자가 조금씩 달라서) 어디서 쓰는지 찾기 너무 힘드니 주의해야함

 

응용과 주의해야할 점

적은 데이터로 긴 기간을 바라보는 경우, 서버 갯수가 늘어나지 않을게 명확한 경우, 1ms에 생성되는 데이터의 수가 많지 않은 경우

다른 비트를 줄이고 기간을 줄이거나 늘이는 식으로 현재 서비스에 맞춰서 유동적으로 사용하면 좋다.

틀에 박혀서 사용할 필요 없음

 

- PK의 이해

PK는 클러스터드 인덱스로 유일한 값이고 물리적으로 정렬, 물리적 정렬이니 순차적인 증가에 적합. 자동으로 인덱스가 생성됨

DB 관점에서 PK를 사용해야 하는 이유 : 복합키의 단일키 변환 등의 장점이 있다.

PK를 ID 생성기로 만들면 얻을 수 있는 장점 : 유일한 값과 순차증가. BigInt 단일 값으로 인덱스 생성에 적합. timestamp 기반으로 기간 조회시 매우 유리함

 

UUID와 GUID와의 차이

문자열 기반의 난수 채번 방식으로 크기가 크고, 인덱스 캐시 성능이 저하됨

순차 생성이 아닌 난수 채번으로 삽입 순서가 비순차적이므로 인덱스 재정렬 발생

서버 머신 기준으로 난수 채번이므로 중복이 발생할 수 밖에 없음

UUIDv7등 최신 채번 방식을 선택한다면 timestamp 기반으로 사실상 크게 다를건 없음

 

Auto Increment와의 차이

DB 기준으로 자동 채번, DB 기준이므로 무조건 DB 통신이 필수(성능 저하)

동일한 채번 기준을 가지므로, 분산서버에 적합하지 않음(2개 이상의 DB 사용 시 도일 채번 문제)

단일 row 기준 채번이므로 대량 작업 부적합(Insert 후 채번된 ID를 SELECT 해야만 연관 작업 가능, 세번의 강제 트랜잭션 발생)

 

1. 이벤트로 대규모 아이템 지급 시

2. item 테이블에 넣을 데이터 생성 후 BulkInsert

3. item_option, item_log 등 연관 데이터 BulkInsert

 

만약 ID를 AutoIncrement 한다면, 단일 insert 후 채번된 값을 기준으로 연관 테이블에 넣어야 하므로 더 많은 트랜잭션으로 성능 저하 발생함.

 

옛날에 Bulk Insert를 DB에서 지원하지 않아서 수만, 수십만건을 넣는데 오래걸렸지만(10분 이상) 요즘은 대부분 지원을해서 금방 끝남(3분이내)

 

결론

1. SnowFlake는 시간이 포함되는 고유한 ID를 생성하는 알고리즘이다.

2. 부호 1비트를 제외한 63비트의 값을 나누어 정보를 분리하여 저장한다.

3. 다중 서버가 1개의 DB를 이용하는 경우, 다중서버가 다중 DB를 저장하는 경우 모두 적합하게 사용 가능하다.

4. 순차 증가하므로 단이 PK 생성에 적합하다.

 

스노우플레이크 ID 생성기는 여러 책에서도 소개를 많이 해준 꽤 널리 알려진 기술인데, 이걸 실무에 적용했을 때에 대한 이야기는 많이 들어보지 못했다. 특히 타임스탬프의 시작시간이 1970년으로 픽스되어있기 때문에 매직넘버를 쓸 수 밖에 없다는 것과 분산 서버에서 일어나는 일들은 다음에 키와 관련된 내용을 도입하게 됐을 때 많은 도움이 될 것 같은 내용들이었다. PK 생성에 대한 고민을 한번이라도 해본 사람들에게는 많은 도움이 될 세션이었다.

 

대규모 트래픽을 처리하는 프론트 개발자의 전략

festa가 당근으로 팔림 : 티켓팅 플랫폼을 만들었음(티켓 타코) 

 

수량 처리 - 오버부킹 방지 정합성 보장

순간 트래픽 - 로그인/회원 가입, 이벤트/주문 조회

 

기술 스택 : Next.js + Vercel + Supabase

Firebase가 기능이 너무 많아져서 사용하기 불편해짐... 대체제로 나온 백엔드 집중 솔루션 Supabase

 

중간 저장소를 활용해 서버로 가는 요청 횟수를 줄여야 한다 : 비용적으로든 성능적으로든 필요

- 중간 저장소를 프론트에 두면 브라우저나 탭을 끄면 캐시 데이터가 사라진다: 리액트 쿼리, Context API. 사용자가 본인의 브라우저에서 캐시를 사용하게 됨

- 중간 저장소를 서버에 두면 다양한 스택 사용 가능 : CDN, Redis, Spring 로컬캐시 등, 브라우저를 껐다 켜도 캐시 데이터가 남아있게 해줌. 여러명의 사용자가 여러번의 세션에서 캐시 사용

 

API 응답 헤더에 Cache Control 추가. Cache Control의 어려움

캐시를 저장하는 곳과 정책을 결정하는 곳이 다르다 코드의 흐름이 직관적이지 않다.

데이터를 요청하는 곳은 FE인데, 캐시 정책을 결정하고 응답을 내려주는 곳은 서버다. 사용하는 곳과 정의하는 곳이 다름

그리고 호출부에 따라 저장 방법이 다르다

 

Cache Control 옵션?

브라우저 - 브라우저 로컬 캐시, next.js - 무시, Vercel,CF - CDN, Spring - 무시

브라우저 -> Vercel -> Origin에서 Cache-Control 반환 : Vercel을 사용한다면 자동으로 설정됨

 

브라우저에서는 리액트 쿼리, 컨텍스트

서버에서는 next.js + revalidate

버셀은 CDN Cache Control

 

API 단위로 캐싱: 캐시가 필요한 API와 필요하지 않은 API를 분리

 

이벤트 페이지에서 필요한 정보 : 이벤트 내용, 티켓 수량. 호출 수를 줄이기 위해 하나의 API로 구성하고 캐싱 -> 실시간 수량이 중요한 티켓 정보는 캐시가 되면 안된다. 이벤트 내용과 같은 static한 정보만 API만 캐시 사용. 실시간 티켓 수량과 같은 매번 변하는 값은 캐시 미사용

 

저장소에 데이터가 없으면 Origin(서버)에 요청하는 방식. write가 서버에 반영되면 캐시에 데이터를 업데이트 하는 식으로 구성

 

API 호출 위치

API 호출 위치와 방법에 따라 서버의 부담이 다르다. Next.js의 SSR, API Route는 Next.js 서버(vercel) 부담됨

API는 기본적으로 Client Componet에서 호출, 네트워크 부담을 요금 없는 사용자 기기에 위임

언제 Server Componet를 사용할까? SEO 중요, Next Cache 사용(이벤트, 주문). 렌더링 시점 데이터 보장(사용자 정보)

 

Supabase SDK

서버를 거치지 않고, 바로 DB와 커넥션해서 네트워크 비용을 아끼자

 

Edge Function(서버리스 API, AWS Lambda, Firebase Cloud Function)

클라이언트에서 API를 거쳐 Supabase API를 사용한다. 왜? 여러가지 장점이 있으니까

Admin 권한, 데이터 수정. 참가자(타 사용자) 조회와 같은 마스터키가 필요한 정보를 다루게 할 수 잇게 하려면 필요.

로직 분리, 제품 유연성과 백엔드 팀 생산성을 위해 역할 구분

 

Database Function : SQL을 직접 사용하는 Function

트랜잭션 보장, 데이터베이스 1회 연결로 다중 쿼리 수행(Spring의 Transactional 어노테이션과 같은 역할)

동시 업데이트를 해야하는 경우에 필요함. 만약 실패했을 때 한번에 롤백이 되야하기 때문인데, supabase sdk에서는 이걸 제공하질 않음. Edge Function을 거치지 않고 호출하면 보안 문제가 생길 수 있으니 조심해야함

 

클라이언트 API 서버 데이터베이스 모든 단계를 거치면 비용이 발생함, 정규화와 인덱스로 비용을 줄일 수 있다.

정규화 vs 비정규화 : 공간 vs 성능. 어떤 컬럼으로 얼마나 자주 조회하느냐에 따라 다르게 설계해야 한다. 

DB 인덱스 : 유니크 컬럼은 자동으로 생성된다(PK, 유니크, 복합키). 외래키는 자동으로 생성되지 않음. status 컬럼은 무조건 추가하자. 유니크 하지 않은 외래키는 status와 함께 인덱스 지정), Not을 쓰지 않아야함(인덱스를 안탈 가능성이 높다).

 

인덱스 사용 통계를 볼 수 있는데 많이 사용되지 않는 인덱스 분석 후 삭제하자(공간 차지함), Slow Query도 볼 수 있다.

 

또다른 전략들

스케일 아웃보다 스케일 업이 좋은 전략이 될 수 있다. 빌드 때 미리 생성하는 Static Site Generation, 빌드때 미리 생성하고 일정간격으로 최신화, 대기열(넷퍼넬, CF WatitingRoom)

 

부하 테스트 하기 

간단 명령어로 하거나, k6 스크립트로 만들 수 있다.

 

완전 프론트엔드 기술일 줄 알고 그렇게 기대하지 않고 들었는데, 완전히 풀스택 개발에 대한 이야기라 너무 재미있게 들었다. 정확히는 티켓 타코 서비스를 개발하면서 일어난 스파이크 트래픽에 대한 대응법들을 정리해주신 것 같은데, 생각보다 데이터베이스 요소와 백엔드 인프라 요소가 많이 붙어서 FE 개발자가 듣기엔 조금 재미없고 지겨운 내용이 됐을 것 같다. 그러나 DB 쪽과 캐시 쪽의 비용절감을 위한 실용적인 부분이 많았어서 정말 재미있었다.

 

Understanding Kotlin Multiplatform

KMP(Kotlin Multiplatform) : 안정적인 프레임워크인가? 널리 사용되는 프레임워크인가?

- Google Docs의 ios 환경, Duolingo ios 환경 개발. - ios에서 빠른 개발을 위해서... 쓰는 것 처럼 보임

 

네이티브 기능의 성능 저하 없이 그대로 사용 가능(VM 계층이 없음)하고, 점진적인 마이그레이션 가능. 코드 재사용성과 사용자 경험의 일관성을 줄 수 있다.

 

안드로이드 팀이 밀어주고 있음. 왜 밀어주나?

- 사용자에게 좋은 경험을 제공해 줄 수 잇어야함. 프레임워크를 활용한 앱들이 시장에서 좋은 결과를 보여줘야 함. 전문가가 있어야함(기존 전문가들이 활용할 수 있어야함)

 

코틀린에 대한 이야기라기 보다는 네이티브 프레임 워크에 대한 이야기였다(기대한 내용과는 전혀 다른...) Jetbrain에서 안드로이드 개발은 이제 코틀린으로 많이 넘어왓으니 IOS 개발도 지원하려고 밀고 있는 플랫폼인 것 같다. 현재 많이 사용하고 있나? 는 그렇지 않은 것 같지만 점차 점유율을 늘려가는 중인 것 같은데, 구현 레벨로 내려갔을 때부턴 너무 네이티브라서 나에게 도움될만한 내용이 많지 않았다. 필요한 사람이 너무 극소수일 것 같은 발표였음.

 

게임 서버는 어떻게 만들고, 무엇을 만들까?

- 한국의 메인 스트림 게임은 플랫폼 상관 없이 온라인 게임. 아직은 주 과금 시스템 F2P(Free to Play 부분유료화)

 

게임 장르에 따른 게임 서버의 특징

- 온라인 보드 게임: 높지 않은 성능 요구, 규모가 작음, 하나의 서버에서 모든 것을 다함. 분산 x, 룰만 다른 경우가 많아서 찍어냄

- 캐주얼 게임 : 중간 크기

- MMORPG 게임 : 한국의 주류 게임, TCP 프로토콜 사용, 분산 서버, 3D 환경의 경우 지형 처리 및 NPC의 길 찾기 중요

- 수집형 혹은 모바일 게임(비 실시간 통신 게임) : 매출 기준으로 봤을 때는 높은 순위는 수집형RPG와 MMO RPG

 

어떤 기술을 사용하나?

C++와 같은 학습 기간이 길고 난이도가 높은 언어 기반의 개발

상용 엔진을 사용 : 유니티와 언리얼, 멀티플랫폼을 지원(모바일의 큰 영향). 다양한 모바일 기기에 대한 호환성. 

자체 엔진을 사용하게 된다면 멀티 플랫폼을 지원하기 위한 추가 개발도 필요해서 어려움이 있다.

개발 모집 요강을 보면 어떤 기술 스택을 사용하는 지를 알 수 있다

 

예전 방식 : Socket 방식의 게임서버 /  Widnows + C++ + MS SQL Server

API 게임 서버 : 웹 서버 방식의 게임 서버 / 오픈소스 프레임워크, statelses, 실시간 보다 개발 용이, 컨텐츠 중심

 

초창기 게임 서버 OS는 PC 게임이라 Windows가 90% 였으나, 지금은 Linux 사용이 늘어나고 있다. API 방식의 게임서버를 만들다 보니 비용절감 등의 이유로 Linux를 사용하고 Docker, Redis 등이 필요해지면서 자연스럽게 전환. 모바일 게임이 많아지면서 어쩔 수 없었다. 그러나 아직도 Windows 서버가 절대적으로 많다.

 

DB는 MySqL이 90%정도 Postgre, Redis, Oracle, mongoDB 등. 대부분의 비용문제로 전환을 한다.

 

네트워크는 초당 통신횟수, 지연 시간이 중요, 게임에 따라 달라지고, 장르가 같더라도 어떤 게임이냐에 따라 사용 방법이 달라짐.

 

특히 실시간 통신을 하는 게임인데 지연 시간이 짧아야 하는 경우 구현 난이도가 높아짐. 글로벌 서비스가 불가능할 수도 있음. 지역에 따라 서버를 분리하는 케이스도 많다.

 

로그 : fluentd - S3 등. ELK 스택, 빅쿼리, 프로메테우스로 수집 - Grafana로 모니터링.

형상관리는 서브버전도 많이 쓴다. 클라이언트 쪽에선 그래픽 리소스들이 많이들어가서 Git을 쓰기 어려운 점이 있음.

k8s? 데디케이티드 서버가 필요한 경우(배틀그라운드)엔 필요하지만, 실시간 RPG 같은 경우는 k8s를 사용하기 어려움. 서버를 늘리고 줄이는 경우가 적기 때문..

 

게임 콘텐츠만으로는 온라인 서비스는 불가능. 보이지 않는 많은 부분을 만들어야 게임 서비스가 가능하다. 게임의 규모가 커질수록 보안과 공격을 조심해야한다.

 

API 서버를 이용한 게임 개발을 하셨던 건지 그렇게 특별하지 않은 기술 소개와 서버 개발 소개였다.. 어떻게가 너무 없었던 세션이라 기록할 만한 내용도 많지 않았다. 어떻게 만들까?라기 보다는 어떤걸 쓸까? 여서 이부분이 아쉬웠음. C레벨 분들이 가끔씩 발표하러 오시는 세션에서 세부적인 문제에 대한 이야기를 하기 보다는 개괄적인 이야기를 하시는 경우가 많은데, 이번 세션이 그렇게 진행됐다. 

 

작은 스타트업에서 디자인 시스템 운영하기

 

디자인 시스템이란?

서비스의 목적에 맞게끔 일관되게 구성된 일련의 패턴과 공유된 규칙 언어

 

디자인 시스템 도입을 주저하는 이유: 자원이 제한된 소규모 스타트업은 투입 시간 대비 즉각적인 생산성을 기대할 수 없기 때문

소수의 인원: 디자이너 1명, 풀스택 개발자 3명에서 15+개의 서비스 개발/운영

 

서비스 내 UI 일관성이 지속적으로 떨어짐: 서비스별 UI 불일치, 중복 멈포넌트 개발, 비효율적인 QA

- UI 일관성 확보/개발 생산성 향상/ QA 시간 단축 및 협업 개선을 위해 디자인 시스템 도입

- 처음부터 만들까? 오픈소스를 쓸까?  학습 난이도 등, 커스터마징 이유로 처음부터 만들기로 함

- 모노레포, 스토리북, 크로마틱, 체인지셋 이용해 보안 및 버전관리를 함

 

우리회사에서도 디자인 시스템 도입하면서 여러가지 일이 있었던 것 같은데, 아예 자체 개발을 했다고하니 많은 어려움이 있었을 것 같다.(우린 Figma를 씀) 잘 모르는 내용이라 어려움이 잘 와닿지 않아서 아쉬웠음

 

당신의 테스트는 더 빠르고, 더 효율적이어야 한다.

실무와 관련된 발표

 

어느날 빌드가 멈췄다

1. 테스트가 240 -> 1800개로 늘어남. 간헐적으로 CI가 실패했는데 그때마다 test heapsize를 증가시켜 해결

2. 어느날 1800개를 돌파하고 어느날 CI가 완전히 멈춤

3. 그러나 github actions runner memory 스펙 임계 도달

5. 근본적인 해결을 해야하만 하는 상황

 

좋은 테스트는 뭐라고 생각하세요?

-고객의 핵심 요구사항을 가능한 모두 검증, 단순 명료(명확한 입출력), 매우 빨리해야함, 자동화

- 프로그램이 문제없이 동작함을 설명할 수 있어야 함

 

제품이 테스트하기 어렵다면, 제품의 품질이 나쁘지 않은지를 의심해야 한다.

- 입력/출력이 불분명. 입력을 통해 결과를 예측할 수 없음(return이 void 혹은 unit과 같이 불분명함)

- 평범한 레퍼런스 테스트 기술을 사용할 수 없음

- 결과가 너무 느리게 나옴, 자동화하기 어려움

 

만약 테스트가 없다면 당신의 코드가 고객의 요구사항대로 만들어졌음을 고객에게 무엇으로 설명할 것인가?

 

단위테스트 : 테스트의 시작(과 끝)

- 단위 기능 하나를 테스트 하는 것

- 가장 빠름. 문제가 있는 부분을 좁게 특정

- 제품 빌드, 패키징, 배포하지 않고 실행 가능, 수시로 반복적으로 사용중인 제품에 영향을 미치지 않고 테스트

- 고객에게 제품을 보증할 수 있는 가장 전문적인 방법

 

테스트가 나의 발목을 잡을 때

해야하는걸 알지만 미루고 미뤘다가 나중에 돌이킬 수 없는 문제로 돌아오는 빚 : 기술부채 

- 3년전에 배포한 기술에 영향이 없겠죠?

 

실무에서 테스트 문제를 분석하는 방법

- 해결책이 효과적이라는 것이라는 설득이 필요함.. 근거가 필요

 

요령 1. 모든 스프링부트 프로젝트 코드를 @SpringBootTest로 테스트하지 마세요.

- 빠른 테스트를 하기엔 적합하지 않은 테스트. 서비스레이어는 단위테스트로 가는게 좋다.

- 서비스레이어에서는 스프링 컨텍스트를 유지하기 위해서 공통화된 테스트 클래스를 쓸 필요가 없다.

- 테스트 프로파일링을 하면, 테스트가 사용한 메모리나 CPU 사용량을 확인 할 수 있다.

 

요령 2. @SpringBootTest(classes = ...)를 똑똑하게 사용하면 속도가 빨라집니다.

- 자동 설정이 모두 꺼짐. 원하는 것만 가져오게 된다.

 

요령 3. mock을 적극적으로 사용해서 의존성을 끊으세요.

요령 4. mock과 fixture를 구분해주세요.

- mock은 행위를 검증하기 위한 것. fixture는 테스트용 가짜데이터를 입력

 

요령 5. 모호한 입력을 피해주세요.

요령 6. 직접 테스트를 작성하지 않아도 되는 영역을 정해보세요.

- Entity 클래스는 테스트하지 않음.

요령 7. MockMvc Test는 더 빠를 수 있음

- 자동설정 되는부분들을 만들어서 쓰면, 빠를 수 있음. StandaloneSetUp으로 하면 빠르게 할 수 있다.

 

요령 8. @MockBean을 사용할수록, 테스트는 느려집니다.

요령 9. @MockBean, @Autowired 의존성을 모아서 통합 작성하는 것은 오히려 테스트를 어렵게 합니다.

요령 10. 슬라이스 테스트가 되지 않는다면, 되게 만들어보세요.

요령 11. 자바와 프레임워크 버전을 최신으로 올려보세요.

- 자바 버전만 올려도 부트의 속도가 빨라지는 경우가 많다.

요령 12. 프로파일링과 디버깅을 두려워하지마세요.

 

무조건 들어야지라고 생각했던 세션이었고, 가장 많은 도움을 얻은 세션이다. 나는 선임자 없이 테스트 파이프라인을 짰었고, 통합테스트 - 단위 테스트를 어디까지 짜야하나? 모킹 수준은 어디까지해야하나? 등에 대한 고민을 정말 많이했었다. 이 과정에서 나름대로 테스트를 어떻게 해야겠다는 정의는 내렸었는데, 여러가지 팁을 듣고보니 더 좋게 개선할 수 있을 것 같다는 생각이 들었다. 아쉬운점은 더 많은 팁들을 전수 받을 수 있었을 것 같은데, 강의 시간이 모자랐다.

 

마치며

사실 두번째 세션에 초대해주신 분의 발표를 들으러 가려고했는데, 사람이 너무 많아서 입구 컷을 당해버렸다. 그렇게 듣게된 두번째 세션이 개인적으론 가장 재밌게 들었던 세션이라는게 아이러니하다. 

 

작년에도 그랬었는데, 유료 컨퍼런스인데도 보편적인 이야기가 너무 많았고 분야가 너무 애매하게 나뉘어져 있어서 테크 세션에서 계속 이동할 수 밖에 없게 구성되어 있었다.

 

그래도 작년보다는 잘 정리된 느낌이었고, 세션들도 재미있게 들었다. 특히 티켓타코 개발기와 테스트 세션은 다른 컨퍼런스에 다시 참석 하신다면 더 길게 들어보고 싶다.