<div id="readability-page-1" class="page"><article id="article"> <h2 id="들어가며">들어가며</h2>
<h2 id="why-golang">Why Golang</h2>
<p>다들 각자 Primary Language 가 있듯이 나에게 Primary 는 Golang 이다. 한국 개발씬에서는 그런 이미지가 아닌데 해외에서는 꽤나 Boring 한 이미지가 있는 언어이다. 그도 그럴듯이 언어가 꽤 단순하다. 특히 우리나라 백엔드 개발자들 대부분의 Primary 가 Java 인데, Java에 비하면 한없이 단촐한 언어이다.</p>
<p>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 해야한다.</p>
<p>얘기를 좀 복잡하게 했지만 이해한 사람은 알겠지만, 그만큼 단순하다. 그래서 해외에서는 Boring 이라고 하는 것도 이해한다. 코딩이 재밌는 언어는 아니니까.</p>
<p>그리고 부트스트래핑을 빨리하기에는 좋은 스크립트 언어(like nodejs, python, ruby)가 즐비해있고 성능과 안정성을 가져가기에는 우리나라는 자바 공화국이기 때문에 대부분 자바를 많이 쓰는 것 같다. 하지만 스크립트 처럼 가볍게 코딩할 수 있고, 컴파일 언어로 정적 타이핑을 가져가면서 성능은 꽤 좋은 또 장점을 두루두루 가지고 있는 언어이고 무엇보다 goroutine 등으로 대표되는 실시간 처리와 성능 면에서 이점이 추후 온서비스에서 운영을 하기에도 굉장히 수월하다. 우리나라에서도 규모나 트래픽이 있는 꽤 큰 회사에서 클라우드 네이티브, 데이터 인프라, 마이크로 서비스, DevOps 도구 영역 등에서 꽤 쓰이는 것을 볼 수 있다. 당근마켓 같은 팀에서 천만이 넘는 채팅 트래픽을 Golang 를 기반으로 한 시스템으로 운영한다 같은 얘기는 우리 같은 구멍 가게들에게는 크게 와닿지 않겠지만, 개인이 쓰기에도 가볍고 좋은 언어라고 생각한다.</p>
<p>(나는 21년도 초에 사실 <a href="https://www.youtube.com/watch?v=mLIthm96u2Q">당근마켓 개발팀 Go언어를 도입하다 | 당근테크</a> 이 영상에 영업당해서 Golang 을 시작했다..)
Rails(Ruby) -&gt; Django(Python) 이었다가 Golang을 시작했고, 지난 회사에서는 계속 nodejs(ts)를 사용했지만 당연한듯이 다시 Golang 으로 돌아왔다. 팀에서 쓰기 좋다던가 등등 여러 장점이 있지만.. 길어지는 것 같아서 다음으로 넘어간다.</p>
<ul>
<li>Rust는 나의 추구미인데 제대로된 프로젝트에서는 한번도 써본 경험이 없다..</li>
<li><a href="https://sinwoobang.notion.site/Vibe-Coding-Go-2656746440e2809baa8ceb5f326cfb37">왜 Vibe Coding에서 Go가 편한가</a> 라는 글도 있으니 참고</li>
</ul>
<h2 id="nextjs">Nextjs</h2>
<p>백엔드와 달리 프론트는 국밥 픽을 했다. Nextjs(TS)를 사용하였고, css를 잘 못하는 나에게 항상 구원이 되는 Tailwindcss, 그리고 한때 graphql 을 쫓았지만(추구미..?) 나의 gql 이해도가 굉장히 떨어진다는 걸 지난 회사에서 크게 깨닫고 Tanstack Query (a.k.a react query)를 사용하였다. 지난 회사야 gql 마스터 프론트엔드 팀장님이 계셨지만 나혼자서 하니 그냥 내가 쓰기 쉽고 이해하기 쉬운걸로 택했다. 그리고 후술하겠지만 react query 를 그렇게 판단한건 나의 큰 실수였다..</p>
<p>국밥 픽이다 보니 Why 가 딱히 없다. React 를 하긴 했었고 예전에 쓰다만 <a href="/posts/2020-03-datacolon-retro-intro">&lt;DataColon 개발 후기&gt; - 1. 들어가며</a> 같은 프로젝트에서도 풀스택을 할때는 고민없이 선택한 스택이고, 아무도 반문을 제기하지는 않을 것 같다.
다만, 대 바이브 코딩 시대에 정말 React/Hook 이 좋은 선택인지는 자료가 풍부하다는 것 외에 많은 고민을 하게된 기간이었다.</p>
<h2 id="순서">순서</h2>
<p>글은 다음과 같이 진행할 예정이다. 프로젝트에서 실제 개발한 도메인들을 바탕으로 디테일한 스택들을 파보고 내가 거기서 내렸던 의사결정, 고민 사항들을 적어보겠다. 의외로 프로젝트를 하는 순서가 실제 시간 순이랑도 거의 일치할 것 같다.</p>
<ul>
<li><a href="/posts/2025-09-scrumble-tech-retro-backend">Scrumble 기술 회고 (부제 - 풀스택 개발과 바이브 코딩의 실패. Golang 과 Nextjs) - 1. 백엔드</a>
<ul>
<li>프로젝트 기본 기술 스택</li>
<li>아키텍처</li>
<li>테스트</li>
<li>실시간 처리</li>
<li>기타</li>
</ul>
</li>
<li>프론트엔드 (2편에서 계속)
<ul>
<li>프로젝트 기본 기술 스택</li>
<li>아키텍처</li>
<li>실시간 처리</li>
<li>기타</li>
</ul>
</li>
</ul>
<hr> </article></div>

flowkater's data;

flowkater

Scrumble 기술 회고 시리즈의 서문으로, Golang·Next.js 조합을 선택한 배경과 바이브 코딩이 준 도움과 한계, 이후 편에서 다룰 백엔드·프런트엔드·LLM 챕터를 어떻게 이어갈지 로드맵을 제시하는 방향 소개 글이다. 독자가 무엇을 기대하면 좋을지와 읽는 순서를 명확히 안내하고, 시리즈를 쓰게 된 계기와 앞으로 공개할 도구들도 미리 소개하며 커뮤니티 피드백을 요청한다.

Scrumble 기술 회고 (부제 - 풀스택 개발과 바이브 코딩의 실패. Golang 과 Nextjs) - 0. 들어가며

댓글