[Devfest Songdo 2023] 송도에서 열린 개발자들의 축제 후기

Devfest Songdo 2023
송도에서 열린 개발자들의 축제 후기

 

 

Devfest Songdo 2023 | Festa!

 

지난 12월 10일, 송도에서 열린 GDG devfest에 다녀왔다. 안드로이드, 플러터, 머신러닝, 백엔드, 프론트엔드, 개발자 커리어 전반을 다루는 등 다양한 주제의 세션이 가득했다. 듣고 싶었던 발표는 많았지만 겹치는 세션도 있고, 집과 거리도 멀어서 3가지 세션만 듣게 되었다. 이번 포스트에서는 행사장을 둘러보며 들었던 생각, 각 발표 세션 별 내용과 느낀점을 담았다. 

 

✍️ 행사장 둘러보기
👩🏻‍💻 발표 세션 1 - 구글 엔지니어의 개발 및 협업방식 | 구글 코리아 신지민
🎮 발표 세션 2 - Flutter로 게임 만들기, 그리고 ML 한 스푼 | 강환석 
🖥 발표 세션 3 - Rendering Patterns 같이보기 | 요기요 임성호
💙 마치며

 

 

 

 

행사장 둘러보기

송도 컨벤시아

 

GDG 송도에서 데브 페스트를 주최한다는 소식을 들었다. GDG는 Google Developers Group라는 개발자 커뮤니티다. 오프라인 행사는 언제나 즐겁고, 열정 넘치는 사람들을 보면서 동기부여도 충전되기 때문에, 이번에도 티켓을 구매했다. 행사 장소인 송도 컨벤시아까지는 거리가 좀 있었다. 대중교통을 두 번 갈아타야해서 왕복 4시간 정도가 걸렸다. 주말이라 지하철에서도 서서 갔다. 예정보다 늦게 도착하게 되어서 급하게 점심을 먹었다. 3시에 하는 세션을 꼭 보고 싶었기 때문이다. 

 

devfest 포토월

 

행사장 지도

 

다행히 2시 반 전후로 행사장에 도착해 체크인을 했다. 사람이 별로 없다고 생각했는데 세션이 한창 진행 중이어서 그래보였던 거고, 호실마다 발표를 들으러 온 분들이 가득했다. 스폰서 부스도 몇 개 있었지만 세션 듣느라 바빠서 제대로 둘러보진 못했다. 

 

고퍼 쿠션과 행사장 안내 배너

 

내가 좋아하는 고퍼 캐릭터의 쿠션도 팔았다.(인프콘에 고퍼 티셔츠 입고간 사람) 분명 페스타에서 15개밖에 안 남아서 선착순 한정 판매라고 적혀있는걸 봤는데, 3시 이후로도 재고가 남아있었던 것 같은..? 작은 인형이나 스티커나 뱃지였으면 샀을텐데 커다란 쿠션은 필요가 없었다😂 내가 스타트업 대표였다면 사무실에 갖다두려고 샀을지도 모르겠다. 핑크 친구는 이름이 뭐지? 고퍼 여자친구일까? 

 

기념 티셔츠와 스티커

 

아쉬웠던 점이 있다면, 티켓을 신청할 때 제출한 티셔츠 사이즈를 현장에선 받지 못했다는 것... 그게 정확한 수요 조사는 아니었던 걸까? 🥲 늦게 와서 재고가 없었던 것일 수도 있다. 두 단계나 높은 사이즈를 받았다. 그래도 큼직하게 입으면 못 입을 것도 없긴 하다. 개발 관련 스티커도 여러개 주워왔다. 

 

 

 

 

구글 엔지니어의 개발 및 협업방식 | 구글 코리아 신지민

이 호실이 메인이었는지 규모도 컸고 발표를 들으러 온 사람도 많았다. 신의 직장이라는 구글, 그곳의 개발자들은 어떻게 일하는지 들을 수 있었다. 발표 세션 중 가장 듣고 싶었던 주제였기 때문에 내용을 자세히 적어본다. 

 

<구글 엔지니어의 개발 및 협업방식> 세션

 

📌 키 포인트
1. 구글 개발자는 Planning - Delivery - Retrospective 사이클로 일한다. 
2. OKR을 이용해 목표를 정하고, OKR 달성 스코어는 평가 지표가 된다.
3. 글로벌 회사로서 시차를 극복하기 위한 다양한 방법을 시도하고 있다.

 

Planning

구글러들은 계획을 중요하게 여긴다. 계획을 짜는데 시간을 많이 쏟으며, 공들인다. OKR을 이용해서 플래닝을 한다. OKR이란 목표(Objective)와 핵심 결과(Key Result)의 약자로, 측정 가능한 팀 목표를 설정하고 추적하는 데 도움이 되는 목표 설정 방법론이다. 

 

다양한 레벨에서, 그리고 다양한 방식으로 계획을 세운다. 팀 레벨과 개인 레벨에서 플래닝을 하며, 탑-다운, 바텀-업 방식 둘 다 이용한다. 팀적으로 브레인스토밍을 많이 하는데 이 과정에서 나온 아이디어는 많이 수용된다. 무엇이든 개발해서 발표하는 데모 데이(demo day)도 열린다. 

 

개인 레벨의 OKR 플래닝은 다음과 같다. 레벨에 따라 기대되는 목표(Goal)가 있으며, 각 레벨마다 역할(Role)이 상세하게 나눠져 있다. 팀에서 본인이 어떤 일을 할 수 있을지 매니저와 의논해 정한다. 무엇을 하는지 알아야 방향성 있게 나아갈 수 있으며, 계획을 세우는 것은 지키지 못했을 때 비난하기 위함이 아니라 무엇이 부족했는지 체크하기 위함이다. 플래닝은 연초에 이루어진다. 

 

 

Delivery

구글의 장점이자 단점은 team distributuon이 되어있지 않다는 것이다. 글로벌로 돌아가는 서비스를 어느 곳에서나 만든다. 이것이 장점인 이유는 '한국에서 일하지만 글로벌 기여한다는 보람'이 있기 때문이고, 단점인 이유는 '시차로 인한 소통의 어려움'이 있기 때문이다. 소통의 문제를 극복하기 위해 실천하는 방법은 여러가지가 있는데, 다음 슬라이드에 담겨 있다. 

 

구글러가 팀원과 협업하는 방법

 

우선 미팅이 굉장히 많다. 아침 7시부터 2시간 정도씩 미팅을 진행한다. 자고 일어나면 밤새 쌓인 메일이 가득하다. 구글러들이 이렇게 커뮤니케이션을 중요하게 생각하는 이유는 다른 팀이 무엇을 하는지 아는 것이 중요하기 때문이다. 서로 다른 나라에 있는 만큼, 소통이 미흡하면 다른 팀과 일이 겹칠 수가 있다. design doc을 많이 사용해서 팀원이 휴가를 가더라도, 새로운 사람이 오더라도 원활하게 일할 수 있는 환경을 조성한다.

 

구글러들끼리의 스택 오버플로우같은 채널이 있어서 궁금한 것이 생기면 언제든 질문할 수 있다. 바쁜 와중에도 정성스럽게 답변을 달아주는 문화가 형성되어 있다. 코드를 공유해서 다른 팀의 모든 코드를 볼 수 있다. 누가, 언제 작성했는지 히스토리 조회도 모두 가능하다. 이로써 서로의 일을 잘 이해할 수 있다. 심지어는 다른 팀의 OKR까지도 조회할 수 있다. 소통과 공유를 매우 중요시하고, 서로에게 관심을 가지고 있는 모습이다. 

 

코드를 작성할 때는 본인만의 스타일로 작성하는 것이 아니라, 정해진 코드 스타일이 있어서 이를 지키도록 철저하게 관리한다. 코드별, 디렉토리별 오너십이 있어서 아무리 매니저라도 마음대로 코드를 고칠 수 없다. 코드 리뷰가 오래 걸리긴 하지만, 모두가 이해하고 따라갈 수 있는 코드를 만들기 위한 노력이다.

 

이렇게 다양한 방식으로 전 세계 각지에서 시차를 극복하며 일하는 구글 개발자들의 노력을 볼 수 있었다. 

 

 

Retrospective

남을 잘 도와주는 구글러, 그들은 어떻게 이런 문화를 정착시켰을까? 그것은 리워딩의 중요성을 알고, 적절한 보상을 제공하기 때문이다. OKR을 몇 퍼센트 달성시켰는지 스코어에 따라 비난(blame)하려는 것이 아니다. 스코어를 가지고 매년마다 연말 평가(annual assessment)를 한다. 이에 따라 연봉이 높아지기도, 승진을 할 수 있기도 하다.

 

연말 평가는 여러 사람들을 거치며, 각 레벨에 맞게 평가된다. 레벨 2에게는 레벨 2에게 기대되는 골이 있으며, 해당 레벨의 기준에 따라 평가된다. 이런 평가가 여러 사람을 거치며 회사의 위로 올라가고 인정받으면, 최종적으로 보상이 주어진다. 이런 체계적인 방식으로 구글 개발자들은 서로 돕는 문화를 만들 수 있었다. 

 

 

느낀점

발표 세션은 동영상 강의 2배속을 해놓은 것처럼 빠르게 지나갔다. 실제로 말이 빠르셨고, 놓치지 않기 위해 바짝 집중해야 했다. 30분 발표를 들었을 뿐인데 엄청난 파도가 휩쓸고 간 것 같았다. 저렇게 일하니까 최고의 회사구나, 저런 사람들이 모여있으니 그런 결과물이 나오는구나 싶었다. 여담이지만 나의 친오빠도 구글러인데 이렇게 굉장하게 일하고 있었다고..?😂 하긴 캘린더를 보니 미팅이 많긴 했다... '나는 저런 환경이 주어지면 저렇게 일할 수 있을까?' 그런 생각도 들었다. 

 

OKR은 예전 회사에서 시도해본 적 있다. 하지만 내부적으로 잘 수용되지 않아서 흐지부지 끝났다. 계획만 세우고 보상이 없으니 구성원의 공감을 얻기 힘들었고, 동기부여도 떨어졌다. 혹시 계획을 달성하지 못했다고 비난받진 않을까 몸 사리게 되기도 했다. 이를 체계적으로 적용해서 서로 돕는 기업 문화를 만들고, 구성원들에게 공감을 얻어낸 구글이 새삼 대단하다. 

 

 

 

 

Flutter로 게임 만들기, 그리고 ML 한 스푼 | 강환석 

게임 만들기에 관심이 있고, 흥미로운 주제라 선택했다. Flutter에 대해 전혀 모르지만 교양 수업 느낌으로 들어보았다. 발표의 포인트와 재미있었던 부분을 남겨본다. 

 

※ 나는 Flutter, ML에 문외한이므로 잘못 적은 내용이 있을 수 있다.

 

<Flutter로 게임 만들기, 그리고 ML 한 스푼> 세션

 

플레임(Flame)은 플러터 기반 게임 엔진이다. 플러터는 위젯 단위로, 플레임은 컴포넌트 단위로 구성된다. 매번 디자이너와 같이 작업하는 것은 아니기 때문에 게임 개발은 에셋과의 전쟁이다. 이 때는 무료 스프라이트를 이용할 수 있다. 

Flame은 물리 엔진이 아니라 구현할 때 힘든 점이 있다. 물리 엔진이 필요하면 Forge2D를 사용하자. 현실 세계의 마찰력, 반발력, 중력 등을 구현할 수 있다. 

 

플레임은 <구글 공룡 게임> 같이 현실 세계의 물리학이 필요없는 경우에 사용한다.

 

물리 엔진이 필요한 게임의 예시는 이렇다.

 

강화 학습(Reinforcement Learning)은 머신 러닝의 한 종류로, 게임을 만들 때 많이 사용된다. 발표에서 예시로 보여주신 영상을 함께 첨부한다. 3년에 걸쳐 강화 학습을 진행한 레이싱 게임 영상이다.

 

강화 학습을 이용한 게임 만들기 예시

 

저 수많은 시도를 보고 있자니, 언제 성공할지도 모르면서 끝없이 도전하는 미니카의 모습이 참 멋지다... 

 

 

느낀점

발표자분께서 게임을 직접 개발해본 분이 계시냐고 질문했는데, 아무도 손을 들지 않았다. 아마 나처럼 게임 개발에 로망이 있는 사람들이 발표를 들으러 온 것이 아닐까? 사실 어렵고 이해가 안 되는 내용도 많아서 집중력이 흐려질 때도 있었는데, 게임의 작동 원리나 학습시키는 로직을 듣게 되어 재미있었다. 오픈소스에 기여하고 싶으면 무조건 플레임이라고 말씀하셔서 조용한 발표장이 웃음으로 가득 찼다. 공식문서가 업데이트 되지 않거나 잘못 적혀있는 경우도 있고, 코드도 난잡해서 리팩토링 가능한 부분이 많다고 한다. 이 글을 읽는 분들도 플레임을 노리면 오픈소스에 기여할 기회가 있을지도?

 

 

참고 레퍼런스 

https://github.com/flame-engine/flame

GitHub - flame-engine/flame: A Flutter based game engine.

https://github.com/flame-engine/forge2d

GitHub - flame-engine/forge2d: A Dart port of Box2D

 

 

 

 

Rendering Patterns 같이보기 | 요기요 임성호

프론트엔드 관련한 발표는 애초에 갯수가 적었기 때문에 선택지가 많지 않았다. 그 중 평소 관심있는 주제인 렌더링 패턴에 대한 세션을 들어보았다. 발표자분께서 이번 세션은 초심자 난이도라고 말씀하셨는데, Q&A 시간에 나온 질문을 보면 나와 비슷한 취준생이나 주니어 개발자분들이 아니었을지 추측해본다. 

 

<Rendering Patterns 같이보기> 세션

 

렌더링 패턴의 흐름과 종류를 살펴보고, CSR 이전의 페이지 구현에서부터 SPA, SSR, CSR 까지의 개념을 알아보았다. 

 

렌더링 패턴을 선택하는 이유에는 3가지가 있다. 웹 바이탈, DX(Developer Experience), 퍼포먼스가 그 이유다. 

 

웹 바이탈(Web Vital)은 웹에서 사용자 경험을 제공하는 데 필요한 품질 신호에 대해, 구글의 측정 기준을 나타낸 것이다. 여기에는 LCP, FID, CLS가 있으며, 사이트 성능에 영향을 미친다. 이 세 가지 지표는 구글 검색 엔진에서 우수한 페이지 경험을 제공하는데 중요한 역할을 한다. 빌드 타임을 줄이는 것만으로도 개발자 경험(DX)에 영향을 미치며, 인프라 부담을 낮출 수 있다. 제품을 효율적으로 만들고, 사용자에게 더 좋은 경험을 제공하기 위해서는 퍼포먼스가 중요하다.

 

CSR 이전에는 멀티 페이지 어플리케이션(MPA) 방식으로 페이지를 구현했다. 과거에는 서버와 프론트엔드가 독립적으로 분리되어 있지 않았다. 대신 서버에서 HTML을 생성하고, 프레임워크의 템플릿 언어를 사용해서 동적으로 웹 페이지를 개발했다. 이 때 JSP, Django 등의 기술을 이용했다. 멀티 페이지 어플리케이션의 단점은 사용자가 무언가를 제출(submit)하거나, 페이지를 이동할 때마다 새로운 HTML 페이지를 다운로드 받아와야 했기 때문에, 이 과정에서 흰 페이지를 유저에게 보여줘야만 했다.

 

싱글 페이지 어플리케이션(SPA)은 서버에서 페이지를 새로 불러오지 않고도 동적으로 화면을 다시 그릴 수 있는 웹 사이트를 말한다. 특히 React가 등장하면서, SPA를 쉽게 만들 수 있는 라이브러리로 소개되었다. 클라이언트 사이드 렌더링(CSR) 방식은 초기에 빈 화면을 보여주다가 JS, CSS 파일 등을 다운받고 실행한 뒤 화면이 렌더링된다. 페이지를 매번 새로고침하지 않아도 되기 때문에 애플리케이션과 즉각적인 인터렉션이 가능하다. 그렇지만 자바스크립트 파일을 읽어오는 시간이 필요하다. 앱의 사이즈가 커질수록 JS 파일의 용량이 증가하고, 결국 파일 다운로드 시간이 오래 걸린다는 단점이 있다. 이런 문제 때문에 다시 서버 사이드 렌더링(SSR)이 조명을 받았다. 서버에서 HTML을 내려주면 클라이언트에서 생명력을 주입해 사용하는 개념이다. SSR을 이용하는 프레임워크로는 Next.js와 Remix 등이 있다. 

 

사이트와 애플리케이션의 차이는 무엇일까? 사이트는 주로 HTML로 표현되는 문서로 이루어져 있다. 애플리케이션은 운영 체제 위에서 실행되는 소프트웨어를 말한다. 사용자가 무언가를 직접 사용하고 응용할 수 있다. 그렇기 때문에 SSR 방식으로 생성한 경우 사이트, CSR 방식으로 생성한 경우 애플리케이션이라고 한다. 

 

어디에나 잘 맞는 완벽한 렌더링 패턴이 있다기보다는, 사이트 성격과 상황에 맞는 렌더링 패턴을 찾는 것이 중요하다. 

 

 

느낀점

나는 리액트를 이용한 SPA 구현을 위주로 사용해봤기 때문에 MPA에 대해서는 잘 알지 못했다. 기술에 있어서 항상 미래지향적인 것만이 옳을까? 오늘 작성한 새로운 코드도 시간이 지나면 낡는다. 새로운 개발만큼 유지보수도 중요하므로 과거의 유산을 잘 알아두는 것 역시 중요하다. 렌더링 패턴의 흐름을 살펴보니 각 패턴의 장단점이 뚜렷하게 보이는 듯 했다. 기존의 방법에 어떤 문제가 있어서, 그것을 해결하기 위한 방법으로 새로운 방식이 나타나고 발전한다. 새로운 기술을 배울 때도 신기술의 등장 배경과 역사를 살펴보도록 해야겠다. 

 

 

참고 레퍼런스 

발표에서 참고 자료로 나왔던 사이트 링크를 첨부한다. 

 

https://web.dev/articles/rendering-on-the-web?hl=ko

웹에서 렌더링  |  Articles  |  web.dev

https://patterns-dev-kr.github.io/

Home

 

 

 

 

마치며

엄청난 높이의 포스코 타워

 

마지막 발표까지 다 듣고 가면 집에 늦게 도착할 것 같아서, 세션은 3개만 듣고 귀가했다. 중간에 우연히 건너 건너 아는 분과도 마주쳐서 인사를 나눴다. 글또 분들 중에도 몇 분 오셨던 걸로 아는데 아쉽게 만나뵙진 못했다. 오프라인 컨퍼런스는 세 번째 방문인데, 어찌저찌 갈수록 현장에서 대화 나누는 분들이 늘어가고 있다. 언젠간 다같이 모여 뒷풀이도 해보는 그런 미래를 꿈꿔본다. 

 

행사 덕분에 송도 구경도 했다. 건물 간의 간격이 넓고 빌딩 높이가 다들 굉장했다. 하늘에서 찍은 센트럴 파크 사진이 멋지던데, 나는 해가 졌을 때 잠깐 산책만 해봤다. 아이들도 많이 보였다. 송도가 아이 키우기에 좋은 환경인가보다. 오랜만에 사람 많은 서울에서 벗어나 한적하고 넓은 동네에 가게 되어 심신에 환기가 되었다. 역시, 오프라인 행사는 언제나 즐겁다.