golang 스터디 + 프로젝트 회고

서론

클클 시즌 2 스터디로 진행했던 golang 스터디에 대한 회고를 남겨보려 한다.

스터디 개요

• 5월 12일부터 7월 2일까지 약 8주간 스터디를 진행했다.
• 스터디원 2명씩 팀을 이뤄서 팀 별로 각자 golang 언어 기초를 공부하고, 주제를 설정해 프로젝트를 진행했다.
• 스터디원들은 대부분 golang에 대해 잘 모르는 상태로 스터디를 시작했다.
• 스터디는 팀 별로 자율적으로 진행되었다. 스터디에서 매주마다 해야 하는 과제나 제약은 없었다. 팀 별로 각자의 페이스에 맞춰 알아서 진행하고 진행 상황만 2주에 한 번 있는 스터디 모임에서 간략하게 설명했다.
• 스터디의 최종 목표는 7월 2일까지 go와 관련된 주제의 프로젝트를 완성하는 것이었다. 주제도 자율 주제로 팀별로 하고 싶은 것으로 설정했다.

역할 및 프로젝트 구조

• 나는 gRPC 클라이언트와 프론트 부분을 맡아서 진행했다.
  • go로 gRPC 클라이언트 로직을 작성했다.
  • 프론트에서는 wails 프레임워크를 사용했으며 react를 사용해 UI를 구성했다.
• 자세한 프로젝트 로직, 구조는 프로젝트 깃허브 링크를 참고하면 된다.

프로젝트 진행

팀 결성 및 주제 선정

• 우리 팀은 gRPC 기반 채팅 시스템 구현으로 주제를 결정했다.
• 나는 채팅 시스템 개발 경험이 없다. 또한 gRPC는 처음 들어봤고 golang은 아무것도 모르는 상태였다.
• 그러다보니 프로젝트 초반에는 잘할 수 있을까 좀 걱정이 됐다.

프로젝트 초반

• 초반에는 golang 기초를 익히는 것부터 시작했다.
• 아래의 두 자료를 보고 기초를 익혔다.
  • 예제로 배우는 go 프로그래밍
  • 가장 빨리 만나는 go 언어 → 이 자료가 기초를 익히기에 정말 좋았다.
• 이후 gRPC 기초를 공부했다.
  • gRPC, protobuf 공식 사이트의 docs를 읽으면서 기초적인 개념을 숙지했다.
• 프로젝트의 기초적인 설계를 구성하고, 역할분담을 했다.
  • 우리 팀은 kafka + gRPC 조합으로 아키텍처를 구성했다.
  • 나는 gRPC 클라이언트와 배포 부분을 맡기로 했고, 팀원 분이 gRPC 서버와 kafka 프로듀서-컨슈머 부분을 맡기로 역할을 나눴다.

프로젝트 중반

• gRPC 학습 속도가 더디고, 기말고사가 얼마 남지 않아 프로젝트를 많이 진행하지 못했다.
  • gRPC는 개념이 생소해서 이해가 어려웠고, 이로 인해 학습 속도가 느려졌다.
  • 특히 REST API와 JSON에 익숙해져 있는 입장에서 gRPC와 protobuf는 낯설게 느껴졌다.
• 우리 팀은 아직 기초적인 설계 정도까지만 진행했는데, 다른 팀은 이미 개발에 들어가서 많이 불안했었다.
• 그럼에도 기말고사 일정이 촉박해 어쩔 수 없이 프로젝트는 종강 후로 미루었다.

프로젝트 후반

• 기말고사가 끝나고 종강한 이후부터 계속 프로젝트 작업을 진행했다.
• 먼저, 프로젝트의 설계를 강화하는 시간을 가졌다. 내가 gRPC 클라이언트, kafka의 사용 등에 대해 제대로 이해하지 못한 것 같아 이 부분부터 완전히 짚고 넘어가기로 했다.
• 해당 부분을 완벽히 이해한 후 클라이언트의 로직과 서버 로직을 정리하고 proto 코드를 작성해 개발을 시작했다.
• gRPC 클라이언트에 대해 이해하는 과정에서 웹 브라우저가 gRPC 클라이언트로 동작할 수 없으며, gRPC-web을 사용해도 양방향 스트리밍을 사용할 수 없다는 걸 알았다. 따라서 아예 방향을 바꿔 데스크탑 애플리케이션 방식으로 개발을 진행했다.
• 이때 데스크탑 애플리케이션 개발을 위해 wails 프레임워크를 사용했고, react를 함께 사용해서 간단하게 UI를 개발했다.

프로젝트 마무리

• docker compose로 gRPC 서버 컨테이너를 EC2에 띄우고 데스크탑 애플리케이션을 사용해 테스트를 진행했다.
  • 양방향 스트리밍이 잘 동작해서 서버로 요청이 적절하게 가고, kafka에서 메시지가 잘 처리되고 있는 것을 확인했다.
  • 우분투 vm을 여러 대 띄워 해당 vm에서 데스크탑 애플리케이션을 실행했다. 여러 사용자가 한 채팅방에 참여할 수 있고 메시지가 올바르게 가는지 확인하기 위해 진행했다.
  • 여러 사용자가 다른 사용자가 생성한 채팅방에 접속해 채팅이 가능하고, 메시지 로직이 꼬이지 않고 적절하게 출력되는 것을 확인했다.
  • 모든 기능이 정상 동작함을 확인했다.
• 무사히 스터디 종료일까지 프로젝트를 완성했다!
  
  

설계 중 착각과 질문

• gRPC 클라이언트는 gRPC 서버와 함께 계속 실행되면서 요청을 listening 하고있는 것인가?
  • gRPC 클라이언트는 요청이 필요할 때만 서버로 연결하여 RPC를 호출한 후 종료된다.
  • gRPC 서버처럼 포트를 열어 계속 listening 하고있지 않다.
  • 해당 예제 코드에서 클라이언트를 run하는 것을 보고 착각했다.

• gRPC 클라이언트는 어디에 위치하는가?

  • REST api와 달리 gRPC가 특별한 구조를 가질 것이며, gRPC 클라이언트가 서버 내부 구조에 위치해야 한다고 오해했다.
  • 그러나 gRPC 클라이언트는 서버 내부에 위치할 필요가 없으며 브라우저, 데스크탑 애플리케이션 등으로 어디서나 실행될 수 있다.
  • Amazon EKS 클러스터에 gRPC 기반 애플리케이션을 배포하고 Application Load Balancer를 사용하여 액세스하기의 아키텍처를 보고 제대로 이해했다.
  • 단, 브라우저에서 gRPC를 사용하려면 gRPC-web 등의 별도의 라이브러리를 사용해야 한다.

• 웹 브라우저가 gRPC 클라이언트가 될 수 있을까?

  • 될 수 있다. 그러나 웹 브라우저에서 HTTP/2를 지원하지 않기 때문에 gRPC-web 등의 별도 라이브러리가 필요하다.
  • 하지만 gRPC-web은 HTTP/2의 고급 기능을 사용할 수 없어 클라이언트 스트리밍, 양방향 스트리밍을 지원하지 않는다.
  • 따라서 해당 프로젝트에서는 양방향 스트리밍이 핵심 기능이었기 때문에 gRPC-web을 사용하지 않았다.
  • 이에 대한 해결책으로 웹 브라우저를 사용하지 않고 데스크탑 애플리케이션을 사용하는 것으로 변경했으며, wails 프레임워크를 사용하게 되었다.

• gRPC는 일종의 소켓 프로그래밍인가?
  • gRPC가 연결을 생성하고 해당 연결을 통해 계속 메시지를 주고 받는 방식이 TCP 소켓 프로그래밍과 같다는 생각이 들어 의문이 생겼다.
  • gRPC는 소켓 프로그래밍을 추상화한 고수준 프로토콜로, TCP 소켓을 통해 이루어지는 통신이 맞다.
  • 추상화되었기 때문에 소켓 레벨에서 직접 프로그래밍하지 않는다.

• 왜 다대다 채팅 서비스에서 카프카를 사용하는가?
  • 카프카 이해도와 채팅 서비스 이해도가 낮아 든 의문이다. 다대다 채팅이 양방향 스트리밍만으로도 충분히 할 수 있지 않을까 착각했다.
  • 다대다 채팅 서비스에서는 요청이 어떤 서버로 가야할지, 응답이 어떤 클라이언트로 가야할지 요청과 응답을 중개하는 서버가 반드시 필요하기 때문이다.
  • 카프카는 메시지 브로커로써 해당 중개 서버 역할을 맡는데 적합한 서비스이기 때문에 사용했다.
    
    

소감

• 프로젝트를 성공적으로 완수해서 뿌듯하기도 하지만, 아쉬움도 많이 남았다.

아쉬움

• 프로젝트 설계를 꼼꼼하게 하자.
  • 본격적으로 개발을 들어가면서 온갖 문제가 다 발생했는데, 해당 문제들의 가장 큰 원인은 바로 잘못된 설계 때문이었다.
  • 주먹구구식으로 개발하는 데에는 한계가 많다. 설계가 꼼꼼하게 잘 되었으면 개발도 금방 진행된다. 설계 포인트도 잘 잡아야 한다.
  • 이번 프로젝트에서는 gRPC 사용에만 초점을 둬서 메시지 로직을 가볍게 생각하고 바로 개발을 진행했더니 메시지 관련 오류가 정말 많았다. 이때마다 설계 포인트를 잘못 잡았고 설계를 너무 가볍게 했음을 느꼈다.
• 기존 서비스들의 로직을 분석하고 진행하자.
  • 채팅 시스템 자체에 대한 이해도가 낮으니 개발이 더뎌지고 방향성을 자주 잃게 됐었다.
  • 다른 채팅 시스템은 어떻게 메시지 로직을 구현했고, 서버와는 어떻게 통신했는지를 분석하고 진행했다면 프로젝트의 완성도가 더 높았을 것 같다는 생각이 들었다.
  • 다음에 프로젝트를 진행한다면 기존의 상용 서비스들의 로직을 분석하고, 경량 서비스를 만들어보는 방향으로 진행하는 것이 좋을 것 같다.
• 바이브 코딩도 아는게 있어야 잘한다.
  • 아무것도 모르고 "이거 만들어줘"하고 프롬프트로 입력하는거는 정말 의미없는 행위임을 느낀다.
  • 내가 완벽하게 로직 구조를 이해하고 해당 이해를 바탕으로 프롬프트를 설계해서 AI에게 질의해야 하며 그래야 앞으로 로직 개선, 오류 해결 등이 가능해진다.
  • "이거 왜 안돼?" "이거 해줘" 등의 단순한 프롬프트는 최대한 지양하자.

즐거움

• 그럼에도 프로젝트를 진행하면서 너무 즐거웠다. 팀원분과 함께 협업하는 과정이 재미있었고, 내 부족함을 알아가는 과정도 좋았다.
• go 언어도 너무 좋았다. 단순한 문법과 빠르고 가벼운 구조가 마음에 든다. 앞으로도 계속 go 언어를 공부하고 사용할 것 같다.