들어가며

Why Golang

다들 각자 Primary Language 가 있듯이 나에게 Primary 는 Golang 이다. 한국 개발씬에서는 그런 이미지가 아닌데 해외에서는 꽤나 Boring 한 이미지가 있는 언어이다. 그도 그럴듯이 언어가 꽤 단순하다. 특히 우리나라 백엔드 개발자들 대부분의 Primary 가 Java 인데, Java에 비하면 한없이 단촐한 언어이다.

Golang 은 그래서 “대표적인” 웹 풀-프레임워크(like Spring Boot, Rails, Django)도 없고 “대표적인” ORM (like JPA, Active Record, Django ORM)도 없다. 딱히 웹프레임워크를 안쓰고 net/http 만 가지고 코딩하는 곳도 심심치 않게 보인다. 그만큼 Golang 이 간단하기도 해서 간단 간단한 마이크로 서버를 만들때 유용하게 쓰이는 것도 같다. 또 언어적인 특성 중에 함수형 언어 맹키로 상수 불변성 따위가 없고 (TS의 const/Kotlin val 처럼 “참조 불변” 변수를 선언할 수 없음. Golang의 const 는 컴파일 타임 상수임. 그래서 대부분 변수를 사용하여 코딩) 에러 반환은 try, catch 가 없고 error 를 명시적으로 결과와 함께 보통 tuple-return 해야한다.

얘기를 좀 복잡하게 했지만 이해한 사람은 알겠지만, 그만큼 단순하다. 그래서 해외에서는 Boring 이라고 하는 것도 이해한다. 코딩이 재밌는 언어는 아니니까.

그리고 부트스트래핑을 빨리하기에는 좋은 스크립트 언어(like nodejs, python, ruby)가 즐비해있고 성능과 안정성을 가져가기에는 우리나라는 자바 공화국이기 때문에 대부분 자바를 많이 쓰는 것 같다. 하지만 스크립트 처럼 가볍게 코딩할 수 있고, 컴파일 언어로 정적 타이핑을 가져가면서 성능은 꽤 좋은 또 장점을 두루두루 가지고 있는 언어이고 무엇보다 goroutine 등으로 대표되는 실시간 처리와 성능 면에서 이점이 추후 온서비스에서 운영을 하기에도 굉장히 수월하다. 우리나라에서도 규모나 트래픽이 있는 꽤 큰 회사에서 클라우드 네이티브, 데이터 인프라, 마이크로 서비스, DevOps 도구 영역 등에서 꽤 쓰이는 것을 볼 수 있다. 당근마켓 같은 팀에서 천만이 넘는 채팅 트래픽을 Golang 를 기반으로 한 시스템으로 운영한다 같은 얘기는 우리 같은 구멍 가게들에게는 크게 와닿지 않겠지만, 개인이 쓰기에도 가볍고 좋은 언어라고 생각한다.

(나는 21년도 초에 사실 당근마켓 개발팀 Go언어를 도입하다 | 당근테크 이 영상에 영업당해서 Golang 을 시작했다..) Rails(Ruby) -> Django(Python) 이었다가 Golang을 시작했고, 지난 회사에서는 계속 nodejs(ts)를 사용했지만 당연한듯이 다시 Golang 으로 돌아왔다. 팀에서 쓰기 좋다던가 등등 여러 장점이 있지만.. 길어지는 것 같아서 다음으로 넘어간다.

• Rust는 나의 추구미인데 제대로된 프로젝트에서는 한번도 써본 경험이 없다..
• 왜 Vibe Coding에서 Go가 편한가 라는 글도 있으니 참고

Nextjs

백엔드와 달리 프론트는 국밥 픽을 했다. Nextjs(TS)를 사용하였고, css를 잘 못하는 나에게 항상 구원이 되는 Tailwindcss, 그리고 한때 graphql 을 쫓았지만(추구미..?) 나의 gql 이해도가 굉장히 떨어진다는 걸 지난 회사에서 크게 깨닫고 Tanstack Query (a.k.a react query)를 사용하였다. 지난 회사야 gql 마스터 프론트엔드 팀장님이 계셨지만 나혼자서 하니 그냥 내가 쓰기 쉽고 이해하기 쉬운걸로 택했다. 그리고 후술하겠지만 react query 를 그렇게 판단한건 나의 큰 실수였다..

국밥 픽이다 보니 Why 가 딱히 없다. React 를 하긴 했었고 예전에 쓰다만 <DataColon 개발 후기> - 1. 들어가며 같은 프로젝트에서도 풀스택을 할때는 고민없이 선택한 스택이고, 아무도 반문을 제기하지는 않을 것 같다. 다만, 대 바이브 코딩 시대에 정말 React/Hook 이 좋은 선택인지는 자료가 풍부하다는 것 외에 많은 고민을 하게된 기간이었다.

순서

글은 다음과 같이 진행할 예정이다. 프로젝트에서 실제 개발한 도메인들을 바탕으로 디테일한 스택들을 파보고 내가 거기서 내렸던 의사결정, 고민 사항들을 적어보겠다. 의외로 프로젝트를 하는 순서가 실제 시간 순이랑도 거의 일치할 것 같다.

• Scrumble 기술 회고 (부제 - 풀스택 개발과 바이브 코딩의 실패. Golang 과 Nextjs) - 1. 백엔드
  • 프로젝트 기본 기술 스택
  • 아키텍처
  • 테스트
  • 실시간 처리
  • 기타
• 프론트엔드 (2편에서 계속)
  • 프로젝트 기본 기술 스택
  • 아키텍처
  • 실시간 처리
  • 기타