Skip to content
Go back
🔄 회고

Scrumble Tech Retro - 0. Intro (Why Golang?)

by Tony Cho
4 min read 한국어 원문 보기

TL;DR

An intro to the Scrumble tech retrospective series. I walk through the reasoning behind the Golang plus Next.js stack, the parts where vibe coding paid off and the parts where it didn't, and a roadmap for the backend, frontend, and LLM chapters coming next so readers know what to expect and in what order.

Intro

Why Golang

Everyone has a primary language, and mine is Golang. It doesn’t carry that image in the Korean dev scene, but overseas it’s known as a fairly boring language. There’s a reason for that: the language really is simple. Most Korean backend developers have Java as their primary, and next to Java, Golang is stripped to the bone.

That’s why Golang has no “canonical” full-stack web framework (think Spring Boot, Rails, Django) and no “canonical” ORM (think JPA, Active Record, Django ORM). It’s not unusual to find shops that skip the web framework entirely and code straight against net/http. The language is simple enough that it ends up being handy for small microservices. On the language-feature side, there’s no constant immutability the way functional languages have it (you can’t declare a “reference-immutable” variable like TS const or Kotlin val. Go’s const is a compile-time constant only, so most code uses regular var). And error handling has no try/catch; you return the error explicitly alongside the result, usually as a tuple.

I’ve made this sound complicated, but if you followed along you can see the point: it really is that simple… So I get why people overseas call it boring. It isn’t a fun language to write, exactly.

For fast bootstrapping there’s a whole field of solid scripting languages (Node.js, Python, Ruby), and for performance and stability Korea is basically the so-called Republic of Java (Korea is dominated by Java in enterprise development), so most teams reach for Java. Still, Golang has a nice middle ground: you can code as lightly as a script, you get static typing from a compiled language, performance is genuinely good, and the goroutine-driven concurrency story makes real-time work and live-service operations a lot easier downstream. Even in Korea you see it picked up by larger, traffic-heavy companies in cloud-native, data infra, microservices, and DevOps tooling. Sure, a team like Daangn (Karrot) running ten-million-plus chat messages a day (Daangn is Korea’s largest local marketplace app) on Go isn’t exactly relatable for shops like ours. But I still think it’s a great language for a solo dev. It’s light, it’s nice to live with.

(I actually got into Golang in early 2021 after this video sold me on it: Daangn Engineering Adopts Go | Daangn Tech.)

I went Rails (Ruby) → Django (Python) → Golang, then spent my last job in Node.js (TS), and when I started over I came right back to Golang as if it were obvious. There’s more I could say about why it’s good for a team and so on, but this is getting long, so I’ll move on.

Next.js

The frontend was the comfort-food pick, the opposite of the backend. I went with Next.js (TS), Tailwind CSS (which always saves me because I’m bad at CSS), and TanStack Query (a.k.a. React Query). I once chased GraphQL as my aspirational stack, but my last job made it painfully clear how shaky my GraphQL fluency actually was, so I bailed. At my last job we had a frontend lead who was a GraphQL master, but going solo I just picked what was easy for me to use and reason about. And, as I’ll get to later, leaning on React Query the way I did turned out to be a real mistake.

Since it’s the default, there’s no real “why”. I’d done React before, it was the obvious choice for full-stack work in older projects like <DataColon Dev Retro> - 1. Intro, and nobody is going to push back on it. The thing is, in the era of AI vibe coding I spent a lot of this stretch wondering whether React and Hooks are really the right call beyond “the docs and the community are huge.”

Order

Here’s how the series will run. I’m going to dig into the actual stack across the domains I built, and along the way I’ll write down the decisions I made and the things I wrestled with. As it happens, the order I built things in lines up almost exactly with the calendar.


FAQ

Why did you pick Golang?
It lets you write code as lightly as a script while keeping the static typing and performance of a compiled language. Goroutines make real-time work and runtime operations easier, and big Korean shops like Daangn (Karrot) have already proven it in production.
Why is Golang called 'boring' overseas?
Because the language is simple. Compared to Java it's stripped to the bone, and there's no canonical full-stack framework or ORM. No constant immutability the way functional languages have it, and instead of try/catch you have to return errors explicitly as a tuple alongside the result.
Why Next.js for the frontend?
It's the comfort-food pick. I've worked in React, it's the no-brainer choice when I'm doing full-stack solo, and the ecosystem is huge. That said, in the era of AI vibe coding I started questioning whether React and Hooks are really the best fit anymore.
Tony Cho profile image

About the author

Tony Cho

Indie Hacker, Product Engineer, and Writer

제품을 만들고 회고를 남기는 개발자. AI 코딩, 에이전트 워크플로우, 스타트업 제품 개발, 팀 빌딩과 리더십에 대해 쓴다.


Share this post on:

반응

If you've read this far, leave a note. Reactions, pushback, questions — all welcome.

댓글

댓글을 불러오는 중...


댓글 남기기

이메일은 공개되지 않습니다

Legacy comments (Giscus)


Previous Post
Scrumble Tech Retro - 1. Backend (Golang, DDD, Entgo, Event, Centrifugo)
Next Post
Scrumble Project Retrospective (June–August 2025)