GDSC

저는 Google Developer Student Clubs(이하 GDSC) 22-23 Member 활동에 이어 23-24 Core로 활동하면서 GDSC의 큰 활동인 Solution Challenge에 다시 한번 참여하게 되었어요.

작년 회고를 다시 한번 읽어보면서 놓친 부분은 없는지 돌아보고 이번 활동에 대한 회고를 해보려고 해요.

Solution Challenge

UN은 2015년에 17가지 지속 가능한 발전 목표를 세우고 2030년까지 이를 달성하기 위한 목표를 세웠습니다. 193개 UN 모든 회원국이 빈곤을 퇴치하고 번영을 보장하며 지구를 보호하기 위한 17가지 목표에 동의했어요.

Solution Challenge의 목표는 Google 기술을 사용한 17가지 지속 가능한 개발 목표 중 하나 이상을 달성하는 데 기여하는 프로젝트를 만드는 것이에요

작년 회고

작년에 회고하면서 아쉬웠던 부분이에요. 간단하게 정리해 보면 다음과 같아요.

언어나 기술, 도구 등 해본 것만 한다면, 무엇이 더 좋은 선택인지 비교할 수 없기에 성장할 수 없다.
새로운 도구를 공부하고 적용하는 시간을 무시할 순 없지만, 더 나은 결과물을 위해 필요한 과정이다.
다음에는 더 나은 결과물(코드, 시간 등)을 위해 도입하고 비교하는 시간을 가져보려고 한다.

프로젝트 소개

Goal 3. Good Health and Well-Being

우리 팀은 17가지 목표 중에서 3번 건강과 웰빙을 주제로 선택했습니다. 건강과 웰빙을 선택한 이유는 사람들이 건강한 몸이나 체력을 가지는 것이 여러 문제를 해결할 수 있는 뿌리가 될 것 같다고 생각했기 때문이에요!

BARO!

우리 팀은 BARO(바로)를 제출했어요!

BARO는 '똑바른', '올바른'을 의미하는 우리말에서 따온 것으로 바르게 정렬된 자세를 유지한다는 의미를 담고 있으며, 이름에 걸맞게 사용자가 올바른 자세를 유지할 수 있도록 도와주는 어플리케이션이에요.

Pose Estimation을 활용해 사용자의 자세를 측정하고 분석해 올바른 자세를 유지할 수 있도록 도와줘요.

우리의 목표는 사용자가 올바른 자세를 유지할 수 있도록 도와줌으로써, 척추 및 목 통증과 같은 문제를 감지하고 완화하는 것이에요. 사용자의 전반적인 건강과 생산성에 기여하며, 특히 앉은 자세로 장시간 작업하는 사람들에게는 올바른 자세를 유지하도록 기여해요.

BARO 아키텍처

주황색은 Backend, 파란색은 App 그리고 빨간색은 AI 파트가 담당했어요.

팀 구성

모두 같은 챕터에 소속되어 있고, 파트는 각각 Backend, App, AI, PM으로 구성되어 있어요.

새로운 학습에 대한 마음가짐

새로운 언어나 기술, 도구 등을 배워서 더 나은 결과물을 얻을 수 있다면 필요한 과정이라고 생각했어요. 하지만 좀 흐릿하게 생각해 보면 "공부를 하면 서울대에 갈 수 있다"처럼 막연하게 들리기도 했어요. 그래서 저는 더 나은 결과물 같은 당연한 이유가 아닌 자신만의 이유가 있으면 새로운 학습을 시작할 때 도움이 될 것 같다고 생각했어요.

이번 Solution Challenge에 참여하면서 저는 당연한 이유 한 가지와 저만의 이유 두 가지를 떠올렸어요. 당연한 이유는 더 나은 결과물! 저만의 이유는 Solution Challenge 평가 요소의 Google 기술 사용 관련 항목과 무엇이 더 좋은지 비교할 수 있는 기회를 가질 수 있다는 점이었어요.

덕분에 새로운 학습을 할 때 막연한 두려움이 약간 줄어듬과 동시에 해야만 하고 난 할 수 있다는 자신감을 얻은 것 같아요.

go 언어

먼저 배웠던 것은 go 언어였어요. go 언어를 알게 된 이유는 일단 Google에서 발표하고 지원하는 언어였기 때문이에요. 추가로 팀에 AI 파트 팀원이 있어서 개발하다가 성능 이슈가 발생할 수도 있겠다는 생각이 들었는데 강력한 퍼포먼스를 가진 go 언어의 매력에 빠져 서버 개발 언어로 선택하고 학습하게 되었어요. Spring Boot에 비해 레퍼런스가 부족해서 힘들었지만, go 언어를 사용하는 기업의 아티클이나 공식 문서를 읽는 과정에서 go 언어뿐 아니라 각 기업의 개발 문화에 대한 부분도 알게 된 것 같아요.

CI/CD

새로운 언어를 배워서 만들기 때문에 시간이 촉박할 수 있다는 생각이 들었어요. 이전 프로젝트들을 해보면서 가장 효율적으로 시간을 줄일 수 있는 구간이 빌드 및 테스트 구간과 새로운 부분을 반영하여 배포하는 구간이었어요. 마침 선물로 받았던 그림으로 배우는 구글 클라우드 101 책이 떠올라서 읽어보면서 Google Cloud Platform에서 제공하는 지속적 통합 배포 기능에 대해 알게 되었고, 학습하여 프로젝트에 적용했어요.

Cloud Build를 통해 GitHub Repository의 특정 브랜치가 변경됨을 감지하고 해당 Repository에 포함된 Dockerfile을 통해 Docker 이미지를 빌드해요. 빌드된 이미지는 Artifact Registry에 저장되고, 이 이미지를 완전관리형 서버리스 서비스인 Cloud Run을 통해 컨테이너가 배포되도록 설정했어요.

실행하지 않을 때는 요금이 부과되지 않았고 빌드 및 테스트, 배포 구간에서 시간을 줄일 수 있었어요. 덕분에 새로운 학습 또는 비즈니스 로직 및 코드에 더욱 집중할 수 있게 되었어요.

gRPC

gRPC는 Google에서 개발한 오픈 소스 RPC (Remote Procedure Call) 프레임워크로, 프로토콜 버퍼(Protocol Buffers)를 기반으로 구성되어 있어요. RPC는 클라이언트와 서버 간의 통신을 가능하게 하는 기술로, 원격에 있는 프로시저나 함수를 로컬에서 호출하는 것처럼 사용할 수 있어요.

우리 프로젝트에서 일정 기능은 gRPC를 통해 사용할 수 있도록 개발했어요. 개발 언어, 도구와 같이 눈에 잘 보이는 부분만 신경 썼었는데, 프로토콜도 상황에 맞게 선택할 수 있다는 사실을 깨달았어요. 실제 체감되는 속도 변화는 없었지만, 프로토콜 버퍼를 사용해 서비스와 메시지를 명확하게 정의하는 과정에서 코드의 가독성을 높이고 유지 관리가 쉽다는 느낌을 받았어요.

하지만 프로젝트에 바로 gRPC를 도입하진 못했어요. gRPC를 도입하려면 저뿐만 아니라 다른 파트 멤버의 동의도 필요하기 때문이에요. 잘 작동하고 익숙한 방식 대신 사용할 만한 이유가 있어야 했어요. 그래서 저는 플러터를 간단하게 학습하여 실제 gRPC로 서버와 통신하는 모습을 보여주며 크게 어렵지 않다는 것을 보여주고, 장점들을 설명하며 팀원들의 동의를 구했어요. 덕분에 일정 기능은 gRPC 기반으로 동작하도록 개발했어요.

새로운 학습을 시작할 때 혼자서 하는 경우도 있지만, 이처럼 팀원이 함께 학습하여 적용해야 할 때도 있음을 깨달았고, 원활한 소통이 더욱 중요하다는 것을 느꼈어요. 함께 성장한다는 느낌을 받는 것도 팀 전체에 좋은 영향을 끼친 것 같아요.

아쉬운 점

이번 프로젝트를 진행하면서 많은 것을 배웠지만 여전히 부족하고 아쉬운 부분이 있어요. 그 부분에 대해서 말해보려고 해요.

Top 100

아쉽게도(?) Top 100에 선정되지 못했어요. Google 기술도 꽤 활용했고, AI 기술도 사용해서 조금 기대하고 있었어요. 감히 선정되지 못한 이유를 생각해보면, 우리의 솔루션이 더 많은 사람들에게 도움을 주지 못했던 부분인 것 같아요. 앉아서 공부하거나, 작업하는 사람들을 대상으로 솔루션을 제공했기 때문에 더 많은 사람들에게 도움을 줄 수 있는 솔루션들이 선정된 것 같아요.

go 언어

앞서 말했듯이 go 언어로 backend 개발을 했어요. go의 기본 라이선스는 BSD(무료 사용, 수정 및 배포를 허용하는 오픈 소스)에요. BSD 소프트웨어는 소스 코드 공개의 의무가 없으며 상업적 이용에도 제한받지 않아요. 기업에서 go를 사용하더라도 공개하지 않아도 되고, 그렇다보니 완성도 있는 레퍼런스를 찾기 어려웠던 것 같아요. 저는 주로 공식 문서나 go를 사용하는 기업의 아티클을 찾아보게 되었어요.

Spring Boot보다 자유도가 높은데 레퍼런스가 부족해서 저도 모르게 Spring Boot가 주로 쓰는 형식으로 코드를 작성한 것 같아요. 그렇게 작성해도 원하는 동작을 보여주지만, go스럽게 사용하려면 어떻게 해야할지 감을 잡기 어려웠던 것 같아요. 아직도 부족한 부분이라고 생각해요.

추가로 BARO 프로젝트의 서버가 꼭 go여야 하는가에 대해 고민해 봤는데, 그렇지 않다고 생각했어요. Solution Challenge였기 때문에, 새로운 도전의 개념 등의 이유로 선택했던 것 같아요. 앞으로도 이런 고민들을 통해 항상 더 나은 선택을 할 수 있게 노력하려고 해요.

마무리

두 번이나 참여한 Solution Challenge여서 더 아쉽지만, 나 자신과 우리 팀이 함께 많은 것을 배우고 성장한 것 같아서 좋은 기억으로 남을 것 같아요. 앞으로도 항상 이유를 찾고 비교하며 이처럼 좋았던 부분은 다시 한번 기억하고 아쉬운 부분은 보완하여 더 나은 개발자가 되기 위해 노력하려고 해요.

감사합니다.