Skip to content

필사 모드: Go Ecosystem 2026 Complete Guide - Go 1.24/1.25, Echo · Gin · Fiber · Chi · sqlc · pgx · ent · Cobra · Bubble Tea · Buf · Connect-RPC · PGO Deep Dive

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Introduction — In May 2026, Go Is the Default for Backends in Korea and Japan

Back in 2020, backend stacks in Korea and Japan were divided between Spring Boot (Java/Kotlin), Node.js, and some Python (FastAPI/Django). As of May 2026, the landscape has clearly shifted. Toss has migrated most of its core payment and authentication services to Go, and Naver has moved the hot path of its gateway and search infrastructure to Go. In Japan, Mercari runs over 100 microservices in Go, and ZOZO and CyberAgent CAGroup have adopted Go as the default language for new services.

The reasons Go ended up in this position are simple. A single microservice binary fits in tens of MB, cold start is effectively zero, p99 latency is stable, and 90% of typical backend work can be done with just the standard library. On top of that, the new features in Go 1.24 and 1.25 have pushed developer productivity another step forward in 2026. This article is not a "Go intro" — it honestly maps what goes where in production today in Korea and Japan.

Go 1.24 and 1.25 — New Features That Became the 2026 Standard

Go 1.24 (February 2025) and 1.25 (August 2025) mark a major turning point in the language itself. Here are the key changes.

- **`iter.Seq[T]` and `iter.Seq2[K, V]`**: Standard iterator types. for-range can now take a function.

- **range-over-func**: User-defined iteration via `for x := range myFunc { ... }`.

- **Swiss-table maps**: The runtime map implementation has been replaced with Abseil's Swiss table. On average -20% memory, +30% lookup throughput.

- **GOEXPERIMENT=newinliner**: The new inliner is enabled by default in 1.25. Function call overhead drops 5–8% on average.

- **PGO mainstream**: Profile-Guided Optimization is now a first-class citizen of the build pipeline. `go build -pgo=auto`.

- **Weak pointers**: `weak.Pointer[T]` lets you build caches and memoization structures that play well with the GC.

- **`encoding/json/v2` (experimental)**: Lands behind a GOEXPERIMENT flag in 1.25. 30–50% faster than v1 with a much cleaner option model.

- **`log/slog` standardization**: The structured logging package introduced in 1.21 is effectively the default for every library now.

The change with the biggest day-to-day impact is range-over-func. Libraries can now return iterators like this.

package paginate

func All[T any](pages [][]T) iter.Seq[T] {

return func(yield func(T) bool) {

for _, page := range pages {

for _, item := range page {

if !yield(item) {

return

}

}

}

}

}

// Caller side

// for item := range paginate.All(pages) { ... }

Flows that used to be handled through channels or callbacks now express cleanly as standardized iterators.

Generics Maturity — Actual Usage Patterns in 2026

Generics were added in Go 1.18, but only in 2026 did they really settle into the library ecosystem. The flagship examples are `samber/lo` (functional helpers) and `samber/do` (DI container). The standard library also cemented generic helpers in the `slices`, `maps`, and `cmp` packages.

package main

"cmp"

"fmt"

"slices"

"github.com/samber/lo"

)

type User struct {

ID int

Name string

Score int

}

func main() {

users := []User{

{1, "Alice", 80},

{2, "Bob", 95},

{3, "Carol", 70},

}

// slices.SortFunc takes a generic comparison function

slices.SortFunc(users, func(a, b User) int {

return cmp.Compare(b.Score, a.Score)

})

// lo.Map is a generic transform

names := lo.Map(users, func(u User, _ int) string { return u.Name })

fmt.Println(names)

}

The key insight: generics are not the answer to everything. Use them only where clear type safety pays off (collection transforms, DI, option patterns, result types). Indiscriminate generics hurt compile times and readability.

The Five Web Framework Powers — Echo, Gin, Fiber, Chi, Kratos

As of May 2026, the Go web framework market is split across five tools.

- **Gin**: The oldest de facto standard. Highly flexible with a large middleware ecosystem.

- **Echo**: Roughly equal to Gin. Slightly cleaner API and stronger built-in middleware.

- **Fiber**: Built on fasthttp. Express-style API. Wins on simple routing benchmarks.

- **Chi**: Standard `net/http` compatible. Minimal and library-like. Toss adopted it for core services.

- **Kratos**: A full-stack microservice framework from Bilibili. Built-in gRPC + Wire DI.

A typical Echo handler looks like this.

package main

"log/slog"

"net/http"

"os"

"github.com/labstack/echo/v4"

"github.com/labstack/echo/v4/middleware"

)

type CreateUserReq struct {

Email string `json:"email" validate:"required,email"`

Name string `json:"name" validate:"required,min=2"`

}

func main() {

logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

e := echo.New()

e.Use(middleware.Recover())

e.Use(middleware.RequestID())

e.Use(middleware.Logger())

e.POST("/users", func(c echo.Context) error {

var req CreateUserReq

if err := c.Bind(&req); err != nil {

return c.JSON(http.StatusBadRequest, map[string]string{"error": err.Error()})

}

logger.Info("user.created", "email", req.Email)

return c.JSON(http.StatusCreated, map[string]any{"email": req.Email})

})

e.Logger.Fatal(e.Start(":8080"))

}

The differences from Gin are mostly stylistic. Both use httprouter-family routers, middleware chains, and similar JSON binding. For a new project, picking either is fine — go with whichever your team already knows.

Chi and Standard net/http — The "No Framework" Trend

After Go 1.22 strengthened `http.ServeMux` (method patterns, wildcards) in 2024, the "skip the framework, use the standard library" trend grew stronger again. Chi is the poster child. It follows the standard `net/http` interface but provides routing, middleware, sub-routers, and URL parameters.

package main

"encoding/json"

"net/http"

"github.com/go-chi/chi/v5"

"github.com/go-chi/chi/v5/middleware"

)

func main() {

r := chi.NewRouter()

r.Use(middleware.RequestID)

r.Use(middleware.RealIP)

r.Use(middleware.Recoverer)

r.Route("/v1", func(r chi.Router) {

r.Get("/users/{id}", func(w http.ResponseWriter, r *http.Request) {

id := chi.URLParam(r, "id")

_ = json.NewEncoder(w).Encode(map[string]string{"id": id})

})

})

http.ListenAndServe(":8080", r)

}

Toss is reported to use a mix of Echo and Chi in its core payment backend — Chi for new services, Echo retained on legacy ones.

Fiber — Speed First, Half-Way Standard Compatibility

Because Fiber sits on top of fasthttp, it benchmarks 20–40% faster than Echo/Gin on simple routing and JSON response paths. The catch: it does not share the standard `net/http` interface, so it does not plug into the standard middleware ecosystem directly. The trade-off is clear.

| Aspect | Fiber | Echo/Gin | Chi |

| --- | --- | --- | --- |

| Base | fasthttp | net/http | net/http |

| Simple RPS | Fastest | Mid | Mid |

| Standard middleware | Limited | Compatible | Fully compatible |

| HTTP/2, h2c | Limited | Yes | Yes |

| Use cases | API gateways, proxies | General microservices | "Frameworkless" services |

sqlc — Compile-Time Type-Safe SQL

Rather than ORMs, the 2026 default is "write SQL directly and generate type-safe functions from it." sqlc is the leading example. You write queries in `.sql` files and the sqlc CLI generates Go functions and structs.

-- queries.sql

-- name: GetUser :one

SELECT id, email, name, created_at FROM users WHERE id = $1;

-- name: ListUsers :many

SELECT id, email, name FROM users ORDER BY created_at DESC LIMIT $1 OFFSET $2;

-- name: CreateUser :one

INSERT INTO users (email, name) VALUES ($1, $2) RETURNING id, email, name, created_at;

Running `sqlc generate` against this file produces Go like the following (abbreviated).

type User struct {

ID int64

Email string

Name string

CreatedAt time.Time

}

func (q *Queries) GetUser(ctx context.Context, id int64) (User, error)

func (q *Queries) ListUsers(ctx context.Context, limit, offset int32) ([]User, error)

func (q *Queries) CreateUser(ctx context.Context, email, name string) (User, error)

Type-safe, SQL-as-written, zero runtime reflection. 80% of new projects in Korea and Japan now adopt sqlc.

pgx — The Default Driver for PostgreSQL

When using PostgreSQL, the default is now `jackc/pgx` instead of the generic `database/sql` driver. The reason: pgx speaks the PostgreSQL wire protocol directly, which gives it better performance and richer features (LISTEN/NOTIFY, COPY, array types, timezone handling).

package main

"context"

"log/slog"

"os"

"github.com/jackc/pgx/v5/pgxpool"

)

func main() {

logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

cfg, err := pgxpool.ParseConfig(os.Getenv("DATABASE_URL"))

if err != nil {

logger.Error("config.parse", "err", err)

os.Exit(1)

}

cfg.MaxConns = 20

pool, err := pgxpool.NewWithConfig(context.Background(), cfg)

if err != nil {

logger.Error("pool.create", "err", err)

os.Exit(1)

}

defer pool.Close()

var version string

if err := pool.QueryRow(context.Background(), "SELECT version()").Scan(&version); err != nil {

logger.Error("query", "err", err)

os.Exit(1)

}

logger.Info("connected", "version", version)

}

sqlc has pgx as a first-class backend, so "sqlc + pgx" is the 2026 PostgreSQL standard combination.

ent — Meta's Graph-Friendly ORM

ent, created at Facebook (Meta), defines schemas in Go code and treats your data as a graph. The schema file generates migrations and a client API together.

// schema/user.go

package schema

"entgo.io/ent"

"entgo.io/ent/schema/edge"

"entgo.io/ent/schema/field"

)

type User struct{ ent.Schema }

func (User) Fields() []ent.Field {

return []ent.Field{

field.String("email").Unique(),

field.String("name"),

}

}

func (User) Edges() []ent.Edge {

return []ent.Edge{

edge.To("posts", Post.Type),

}

}

Treating relationships between entities (edges) as first-class is what distinguishes ent from GORM/bun. Mercari has standardized on ent for some services.

ORM Comparison — sqlc · ent · gorm · bun · sqlboiler

A summary table of where each tool sits.

| Tool | Model | Code generation | Migrations | Character |

| --- | --- | --- | --- | --- |

| sqlc | SQL-first, code gen | Required | Separate (atlas/goose) | "Type-safe SQL" |

| ent | Schema-as-code, code gen | Required | Built-in + atlas | Graph model |

| gorm | Runtime reflection | None | Auto-migrate | Rails-style |

| bun | Builder pattern | None | Separate | Lightweight builder |

| sqlboiler | DB-first code gen | Required (DB→code) | Separate | Existing DB first |

For new projects, choose sqlc or ent. Teams migrating from Rails/Django generally find gorm easier to adopt.

gRPC, Connect-RPC, Twirp — Three Schools of RPC

gRPC is still the de facto standard for inter-service communication, but Connect-RPC from Buf has been rapidly gaining share since 2024. Here is how the three compare.

| Aspect | gRPC | Connect-RPC | Twirp |

| --- | --- | --- | --- |

| Wire protocol | HTTP/2 + binary | HTTP/1.1, HTTP/2, gRPC, gRPC-Web | HTTP/1.1 + JSON or Protobuf |

| Browser compatibility | Needs gRPC-Web | Native | Native |

| Streaming | Full bidirectional | Client/server streams | One-way only |

| Code generation | protoc + protoc-gen-go-grpc | buf + protoc-gen-connect-go | twirp plugin |

| Fits | Internal microservices | Internal + external | Internal, simple |

Connect-RPC's killer feature is exposing a gRPC server and an HTTP/1.1 JSON API from the same proto. The browser can call it directly, and you only write the server side once.

Buf CLI — The Standard for Protobuf Workflows

Buf is a much better protobuf toolchain than protoc. `buf.gen.yaml` handles code generation, `buf lint` enforces style, and `buf breaking` checks compatibility.

version: v2

managed:

enabled: true

plugins:

- remote: buf.build/protocolbuffers/go

out: gen

opt: paths=source_relative

- remote: buf.build/connectrpc/go

out: gen

opt: paths=source_relative

This single file replaces the entire protoc-options inferno. In CI you typically run `buf lint` and `buf breaking --against '.git#branch=main'` to automatically verify backwards compatibility on every API change.

log/slog Standardization — The Endgame of Structured Logging

Until 2021, Go logging was a battleground split between `log`, `logrus`, `zerolog`, and `zap`. As of 2026, `log/slog`, introduced into the standard library in 2023, is effectively the default for every library.

package main

"context"

"log/slog"

"os"

)

func main() {

logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{

Level: slog.LevelInfo,

}))

slog.SetDefault(logger)

ctx := context.Background()

slog.InfoContext(ctx, "service.start",

"version", "1.2.3",

"port", 8080,

)

}

Because the handler interface is now standardized, adapters like `slog-go-zap`, `slog-zerolog`, and `slog-otel` let you keep existing logging backends. Teams on zap are gradually moving their code to the slog interface.

OpenTelemetry Go — The Default for Distributed Tracing

For distributed tracing, the OpenTelemetry Go SDK is effectively the standard. It covers HTTP and gRPC middleware, DB client instrumentation, and slog handler integration — a full stack. Toss and Mercari both push to an OTLP collector and store in Tempo or Honeycomb.

The core pattern is (1) propagate trace spans through `context.Context`, (2) start spans with `otel.Tracer("name").Start(ctx, "op")`, (3) wrap HTTP servers with `otelhttp.NewHandler` for automatic instrumentation, and (4) attach trace_id/span_id automatically to slog output.

Context Propagation and Error Wrapping — The Heart of Idiomatic Go

With `errors.Join` added in Go 1.20, the error-handling model finally feels complete. Idiomatic 2026 code follows these four rules.

1. Every external call takes `ctx context.Context` as its first argument.

2. Wrap errors with `fmt.Errorf("...: %w", err)`.

3. Use `errors.Is` for branch checks, `errors.As` for type checks.

4. Combine multiple errors with `errors.Join`.

Linters such as `errcheck`, `revive`, and `errorlint` catch violations of these rules immediately.

Cobra and fang — The De Facto CLI Standard

Roughly 80% of Go CLI tools are built on spf13/cobra. kubectl, helm, hugo, and the docker CLI are all cobra-based. `charmbracelet/fang`, released in 2025, layers prettier help text and colors on top of cobra.

package main

"fmt"

"github.com/spf13/cobra"

)

func main() {

var name string

root := &cobra.Command{

Use: "hello",

Short: "Say hello",

Run: func(cmd *cobra.Command, args []string) {

fmt.Printf("Hello, %s!\n", name)

},

}

root.Flags().StringVarP(&name, "name", "n", "world", "name to greet")

root.Execute()

}

Alternatives include `urfave/cli` (lighter) and `alecthomas/kong` (struct-tag-based). For projects that truly want to start lean, kong is appealing.

The Charm Ecosystem — Bubble Tea, Lipgloss, Glow, Soft Serve

The TUI toolkit from `charmbracelet` has become the standard for terminal UX in 2026. Bubble Tea is a TUI framework implementing the Elm architecture (Model–Update–View) in Go.

package main

"fmt"

"os"

tea "github.com/charmbracelet/bubbletea"

)

type model struct{ count int }

func (m model) Init() tea.Cmd { return nil }

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {

switch msg := msg.(type) {

case tea.KeyMsg:

switch msg.String() {

case "q", "ctrl+c":

return m, tea.Quit

case "+":

m.count++

case "-":

m.count--

}

}

return m, nil

}

func (m model) View() string { return fmt.Sprintf("count: %d (+/- to change, q to quit)\n", m.count) }

func main() {

if _, err := tea.NewProgram(model{}).Run(); err != nil {

fmt.Println(err)

os.Exit(1)

}

}

In the same family, Lipgloss handles styling (colors, boxes), Glow renders Markdown, and Soft Serve is a self-hosted Git server. These are the first picks when building internal tools.

DI Containers — wire, fx, do, do-rc

For larger Go applications, a DI container becomes near-mandatory. Here is how the four compare.

| Tool | Approach | Compile-time | Runtime lifecycle | Fits |

| --- | --- | --- | --- | --- |

| google/wire | Code generation | Yes | No | "Automated manual DI" |

| uber-go/fx | Runtime reflection | No | Yes (Start/Stop) | Full-stack apps |

| samber/do | Generics + runtime | No | Partial | Lightweight |

| samber/do-rc | Successor to do, simpler | No | Partial | Lightweight |

Kratos and Buffalo default to recommending wire, Toss standardizes on fx, and Mercari also uses fx as part of its microservice skeleton.

DB Migrations — atlas, golang-migrate, goose, dbmate

For schema migrations, pick one of four tools.

- **golang-migrate**: Oldest standard. File-based (`up.sql`, `down.sql`).

- **goose**: Supports Go-coded migrations too. Lightweight.

- **dbmate**: Language-agnostic. Works as a pure CLI.

- **atlas**: Declarative HCL/SQL schema model. Define schema declaratively and atlas computes the migration diff. Very friendly with ent.

New projects often adopt atlas; teams with existing assets typically keep golang-migrate.

HTTP Clients — resty, req, go-retryablehttp

The standard `net/http` is more than enough as a client, but for external API calls tangled with retries, timeouts, auth, and tracing, helper libraries are convenient.

- **go-resty/resty**: Most popular full-featured client. Chain-style API.

- **imroc/req**: Similar to resty. Excellent debug logging.

- **hashicorp/go-retryablehttp**: A retry decorator on top of the standard HTTP client.

When you want low-level control, the standard `net/http` plus go-retryablehttp is the answer; for fast development, resty is the right choice.

Testing — testify, gomega, gomock, mockery

Go tests use the standard `testing` package by default, but assertions and mocks almost always come from libraries.

- **stretchr/testify**: A bundle of `assert`, `require`, and `mock`. Effectively standard.

- **onsi/gomega**: BDD style. Paired with Ginkgo.

- **go.uber.org/mock (formerly golang/mock)**: Interface-based mock generation. Generated via mockery.

- **vektra/mockery**: Auto-generates mock code. Wired into CI.

For golden file tests, `gotestyourself/gotest.tools` or a small in-house helper is the common pattern. They are effective at tracking output changes.

Benchmarks and PGO — `go test -bench` and `benchstat`

Performance measurement uses `go test -bench`, and result comparison uses `benchstat`.

First measurement

go test -bench=. -count=10 -benchmem ./pkg/parser > old.txt

After code change, second measurement

go test -bench=. -count=10 -benchmem ./pkg/parser > new.txt

Statistical comparison

benchstat old.txt new.txt

benchstat reports not just the mean but also t-test based statistical significance, so you can answer "did my change actually make things faster?" objectively.

PGO (Profile-Guided Optimization) — Free 5–15% Average Improvement

PGO went GA in Go 1.21 and by 2026 has become a standard build step for major services. Take a pprof CPU profile from production traffic, feed it into the build, and the compiler inlines and orders hot paths more aggressively.

Collect a 30s profile from production

curl -o cpu.pprof "http://prod.internal:6060/debug/pprof/profile?seconds=30"

mv cpu.pprof default.pgo

PGO is auto-applied when default.pgo sits in the same directory

go build -pgo=auto ./...

Toss has reported in internal benchmarks an 8–12% throughput improvement and 6% p99 latency drop on its payment router service. Mercari has confirmed similar 7% gains on some services. Essentially free performance.

Goroutine Patterns — Pool, sync.Pool, sync.OnceFunc

Handling large amounts of concurrency follows three standard patterns.

1. **Worker pools**: Either the `panjf2000/ants` library or a hand-rolled channel-based pool.

2. **sync.Pool**: Reuse short-lived objects (buffers, parser state) to relieve GC pressure.

3. **sync.OnceFunc, OnceValue, OnceValues** (1.21+): Standard idiom for lazy initialization.

For IO-bound work, just spawning goroutines is usually fine. Pools only matter when you are CPU-bound or constrained by external resources (DB connections, HTTP clients).

Wails — Desktop Apps in Go

Wails combines a Go backend with a webview frontend to build desktop apps. You can think of it as Electron with Go: much smaller bundles (10–20 MB on average) and less memory usage. v3 went GA in 2025. It is a popular pick for internal tools and developer-oriented desktop apps (GUI Git clients, k8s dashboards, log viewers).

Hugo — The Fastest Static Site Generator, Built in Go

Hugo is the pride of the Go ecosystem. It builds even 10k-page sites in seconds. In 2026 it is back in the spotlight as part of strategies to improve LCP and Core Web Vitals. A large share of tech blogs in Korea and Japan run on Hugo + GitHub Pages or Vercel static hosting.

Korean Adoption — Toss, Naver, Coupang, Kakao

- **Toss**: Many core payment, authentication, and money-transfer services run on Go. The standard stack is Echo + Chi + sqlc + pgx + fx + Connect-RPC. Toss has officially adopted Go 1.24 PGO.

- **Naver**: Parts of the gateway and search infrastructure run on Go. Their fasthttp-based gateway case is publicly documented.

- **Coupang**: Some microservices have moved to Go, especially asynchronous worker tiers.

- **Kakao**: Kakao Enterprise builds many internal tools in Go. Cobra + Bubble Tea based CLI tools are standard.

The talks given at Toss's SLASH conference are among the most detailed Korean-language references for Go adoption.

Japanese Adoption — Mercari, ZOZO, CyberAgent, Cybozu

- **Mercari**: Over 100 microservices in Go. Built on gRPC + Connect-RPC, ent, and fx.

- **ZOZO**: Core paths of search and recommendation services run on Go. Standardized on sqlc + pgx.

- **CyberAgent CAGroup**: The default language for new advertising and gaming services. Includes parts of the AbemaTV backend.

- **Cybozu**: New services around the kintone backend are being built in Go. Strong adoption of Connect-RPC.

Mercari's engineering blog (engineering.mercari.com) is the standard reference for running Go microservices in production.

Adoption Roadmap — From Zero to Production

A six-step roadmap for a new team adopting Go.

1. **Week 1**: Install Go 1.24, set up `gopls` and `golangci-lint`, read through "A Tour of Go" and "Effective Go".

2. **Week 2**: Build a small CLI with cobra. Use slog logging; choose between urfave/cli or cobra.

3. **Week 3**: Build a small REST API with Echo or Chi. Introduce sqlc + pgx.

4. **Week 4**: Write tests with testify and wire golangci-lint into CI.

5. **Month 2**: Start inter-service communication with Connect-RPC or gRPC, and introduce Buf.

6. **Month 3**: Add OpenTelemetry, integrate PGO into the build pipeline, and watch for regressions with benchstat.

Avoid jumping straight to a full-stack framework like Kratos at the start. Begin with the standard library plus a few lightweight libraries.

Anti-Patterns — Common Mistakes

Finally, a list of frequently observed anti-patterns.

1. Creating fresh `context.Background()` instances deep in the call stack instead of accepting and propagating one — always pass it through.

2. Using `panic` for ordinary error handling — reserve it for unrecoverable situations.

3. Unclear ownership of goroutine lifetimes — group them with `errgroup.Group`.

4. Wrapping every error as `fmt.Errorf("err: %v", err)` — use `%w` instead.

5. Reaching for a heavy framework when the standard library would already do.

Avoid just these five and the quality of your Go code immediately lands in the top tier.

Closing — May 2026, "Go Is the Default for Backends"

As of May 2026, Go is the default language for new backend services in Korea and Japan. Spring/Kotlin holds the legacy maintenance space, Node.js owns the frontend/BFF layer, Python sits on ML and data, and Go nearly monopolizes the "high-throughput, high-concurrency microservices" space in between.

The ecosystem itself is more stable than ever. sqlc + pgx + Echo/Chi + slog + Cobra + Buf + Connect-RPC + OpenTelemetry + atlas — this single combination covers practically every backend scenario. There is no good reason left to defer the technology decision for a new service.

References

- Go official site, [go.dev](https://go.dev)

- Go official blog, [go.dev/blog](https://go.dev/blog)

- Effective Go, [go.dev/doc/effective_go](https://go.dev/doc/effective_go)

- Echo framework, [echo.labstack.com](https://echo.labstack.com)

- Gin framework, [gin-gonic.com](https://gin-gonic.com)

- Fiber framework, [gofiber.io](https://gofiber.io)

- Chi router, [go-chi.io](https://go-chi.io)

- Kratos, [go-kratos.dev](https://go-kratos.dev)

- sqlc, [sqlc.dev](https://sqlc.dev)

- pgx, [github.com/jackc/pgx](https://github.com/jackc/pgx)

- ent, [entgo.io](https://entgo.io)

- GORM, [gorm.io](https://gorm.io)

- bun, [bun.uptrace.dev](https://bun.uptrace.dev)

- Cobra, [github.com/spf13/cobra](https://github.com/spf13/cobra)

- Bubble Tea, [github.com/charmbracelet/bubbletea](https://github.com/charmbracelet/bubbletea)

- Lipgloss, [github.com/charmbracelet/lipgloss](https://github.com/charmbracelet/lipgloss)

- Buf, [buf.build](https://buf.build)

- Connect-RPC, [connectrpc.com](https://connectrpc.com)

- Uber fx, [github.com/uber-go/fx](https://github.com/uber-go/fx)

- google/wire, [github.com/google/wire](https://github.com/google/wire)

- atlas migrations, [atlasgo.io](https://atlasgo.io)

- testify, [github.com/stretchr/testify](https://github.com/stretchr/testify)

- benchstat, [pkg.go.dev/golang.org/x/perf/cmd/benchstat](https://pkg.go.dev/golang.org/x/perf/cmd/benchstat)

- OpenTelemetry Go, [opentelemetry.io/docs/languages/go](https://opentelemetry.io/docs/languages/go)

- Wails, [wails.io](https://wails.io)

- Hugo, [gohugo.io](https://gohugo.io)

- Mercari engineering blog, [engineering.mercari.com](https://engineering.mercari.com)

- Toss SLASH conference, [toss.tech/slash](https://toss.tech/slash)

현재 단락 (1/387)

Back in 2020, backend stacks in Korea and Japan were divided between Spring Boot (Java/Kotlin), Node...

작성 글자: 0원문 글자: 21,963작성 단락: 0/387