Skip to content
Published on

Korean Dev Blog Curation 1 — Backend and Infrastructure, 14 Posts I Opened and Checked

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

This Series Is an Editorial Pick, Not a Ranking

This is the first of a six-part series introducing developer writing worth reading in Korean.

Let me state the selection method first. I found candidates by searching and then opened each post directly to check it, keeping the ones whose explanations were concrete and reproducible. My standard for a reproducible explanation is simple. The symptom, the cause, and the evidence are each written down separately, and a reader can run the same check in their own environment. Conversely, if a post has only a conclusion and none of the observations that led to it, I left it out no matter how correct it was.

There is no ranking here. I did not measure views, popularity, or influence. I have no way to access those numbers and I am not going to pretend otherwise. This list is an editorial pick. If someone else had chosen against the same criteria, about half the entries would be different.

I gave priority to personal blogs — Tistory, velog, personal domains, GitHub Pages, in that order. Corporate engineering blogs were included only when they were the definitive writeup for a topic. One entry here, from Woowacourse's Tecoble, qualifies on that basis.

One more note, and an important one for readers outside Korea: every linked post is written in Korean. You will need Korean to read them. Machine translation handles most of these reasonably well, but the code and command output that carry the argument are language-independent anyway.

All links were opened and checked directly on 2026-08-12. Personal blog posts can disappear or change addresses.

Service Mesh and Proxies — Handling the Path Traffic Takes as Configuration

When you strip retries and timeouts out of application code, that logic does not vanish; it moves into the proxy. Surprisingly few people know what it looks like once it gets there.

Istio Sidecar로 서비스 구성 범위 좁히기

  • Blog · Author: Outsider's Dev Story
  • One-line summary: How to narrow the set of services a workload can see using Istio's Sidecar resource, and why you would want to.
  • Read this if: Your cluster has grown to the point where sidecar proxy memory and config propagation have become a burden.

The first thing this post does well is clear up a naming collision before going anywhere else. Istio's Sidecar is a CRD name, not the sidecar pattern itself, and mixing the two makes the documentation unreadable. It then covers how the xDS protocol is split up, and explains configuration scoping on top of that foundation. A concrete example — a frontend service that has no business knowing about certain namespaces — means you finish the post able to judge what you can safely delete from your own cluster. The concept and the hands-on work run as one thread rather than being split apart, which also helps.

Istio ServiceEntry로 외부 서비스 등록하기

  • Blog · Author: Outsider's Dev Story
  • One-line summary: Registering external APIs outside the mesh via ServiceEntry so they fall under in-mesh policy and observability.
  • Read this if: You call an external payment or map API and that one call is your observability blind spot.

The post starts with the setting that decides how outbound traffic is handled at all — block everything, allow everything, or allow only what is registered. That choice determines how hard your next outage will be to investigate. Rather than just listing the options, the post attaches the situation each one is reasonable for. The core of it is the point that once you register a service entry, circuit breaking, logging, and metrics start applying to external calls too. Read alongside the Sidecar post above, it completes the picture of where the mesh boundary actually sits.

Istio External Authorization의 로컬리티 로드 밸런싱 확인하기

  • Blog · Author: Outsider's Dev Story
  • One-line summary: Verifying in a Kind cluster whether locality-based load balancing still applies once an external authorization service is attached.
  • Read this if: You want to build the habit of reproducing documented behavior before trusting it.

The value here is in the method more than the conclusion. Spinning up a Kind cluster when a question comes up, pulling out the Envoy cluster configuration, and checking traffic distribution metrics is itself a procedure worth learning. The author confirms that locality load balancing does apply — but if it had not, this would still be a good post, because the verification process is written down reproducibly. If you have asked who in your organization should be doing this kind of checking after adopting a service mesh, this post shows you the shape of the answer.

[Envoy 이해하기] Circuit_Breaker (outlier_detection)

  • Blog · Author: 사바라다는 차곡차곡
  • One-line summary: How Envoy implements circuit breaking through outlier detection, demonstrated by standing up a failing backend and watching it get removed.
  • Read this if: You have only used circuit breakers as a library and want to know what they look like in the proxy layer.

Plenty of posts explain circuit breakers, but most stop at a state diagram. This one builds the thing and observes how many consecutive errors it takes before an instance drops out of the load balancer pool. Because a test scenario is included, the meaning of each configuration value comes from observed behavior rather than from documentation prose. It also brings out naturally how application-level and proxy-level circuit breakers solve different problems.

[proxy] Envoy 이해하기 - Routing

  • Blog · Author: 사바라다는 차곡차곡
  • One-line summary: Envoy's four routing approaches — by path, weight, host, and header — with configuration examples for each.
  • Read this if: You want to handle canary deploys or A/B tests purely through proxy configuration.

The mapping is made explicit: weighted routing for gradual rollouts, header routing for A/B tests. That turns a feature list into a list of places to use them. Each of the four comes with a configuration example and test results, so it is easy to copy and start from. It belongs to the same series as the circuit breaker post above, so terminology stays stable when you read them back to back. If you are running Istio, these are the settings underneath it, which makes this practical rather than academic.

Runtime and Observability — Seeing Inside a Process from Outside

You can design the infrastructure perfectly and still be unable to investigate anything if you do not know what happens inside the process. This section covers that interior.

[Server] 프로메테우스와 푸시 게이트웨이의 한계(Prometheus and limits of Push Gateway)

  • Blog · Author: MangKyu's Diary (망나니개발자)
  • One-line summary: Pull versus push metric collection in Prometheus, then the internal architecture of PushGateway and the limits that follow from it.
  • Read this if: You started adopting PushGateway for batch job metrics and then hesitated.

What makes this post uncommon is that it covers limits rather than usage. It goes down to single-threaded processing, a global mutex, and the memory behavior when short-lived labels accumulate, explaining structurally why PushGateway is not a general solution. For someone who has to make an adoption decision, that is far more useful than a feature tour. Once you understand why pull is the default, your judgment across the whole observability design shifts.

JVM 메모리 구조와 GC

  • Blog · Author: 기계인간 John Grib
  • One-line summary: Why generational memory layout looks the way it does, starting from the weak generational hypothesis, then comparing serial, parallel, and concurrent collectors.
  • Read this if: You have pasted GC flags found through search but cannot explain why those flags.

The virtue of this post is its ordering. It shows the structure first and then explains the hypothesis that structure rests on, so the differences between collectors read as different answers to the same problem rather than an arbitrary list. Dense references to the official Oracle documentation leave a path open if you want to go deeper. Written in 2019 and updated in 2022, it does not reach the newest collectors, but it is still more than adequate for building the foundation. The wiki format also makes it easy to read just the section you need.

[JVM] 클래스 패스 섀도잉(Classpath Shadowing)이란?

  • Blog · Author: MangKyu's Diary (망나니개발자)
  • One-line summary: What the class loader picks when several copies of the same class name sit on the classpath, and what goes wrong as a result.
  • Read this if: You have bumped a library version and then hit strange exceptions only at runtime.

A large share of what gets lumped together as dependency hell comes out of the single rule this post explains: the class loader locks in the first match it finds. Knowing that one sentence is the difference between an investigation measured in minutes and one measured in hours. Because it walks the bootstrap, platform, and application loader hierarchy, you also get a place to look for where the collision happened. It is a conceptual post, but the kind you can pull out at work immediately.

[Kafka] 카프카 파티션 증설 시 컨슈머의 auto.offset.reset 설정 주의사항

  • Blog · Author: MangKyu's Diary (망나니개발자)
  • One-line summary: How the consumer's offset reset setting can cause message loss the moment you add partitions, explained with diagrams.
  • Read this if: You plan to add partitions for throughput and want to do it without downtime.

The conclusion is that leaving the default in place can discard messages that arrive mid-expansion, and the path to that conclusion is drawn out step by step. Adding partitions is an irreversible operation in Kafka, which makes reading this beforehand worth the time on its own. Posts that show the exact route from one configuration value to data loss are rarer than you would expect. The cautions are written up in a form you could quote directly into a change plan.

Server and Network Fundamentals — The Parts That Last

Tools change; the material in this section mostly does not. That is why posts from several years ago still hold.

리눅스 서버 60초안에 상황파악하기

  • Blog · Author: Luavis' Dev Story
  • One-line summary: An adaptation of Netflix's sixty-second checklist, grouping about ten commands under the USE method.
  • Read this if: You get onto a slow server and lose time every single time deciding what to type first.

In front of a slow server, what you need is an order of operations more than deep knowledge. This post supplies that order and organizes what each command tells you along the axes of utilization, saturation, and errors. It is from 2017, but the commands it covers are fundamental enough that it still holds up unchanged. It is the kind of thing worth pinning as the first page of an incident response document.

[Linux] top 명령어로 서버의 상태 파악하기

  • Blog · Author: 사바라다는 차곡차곡
  • One-line summary: The output of top, split into the summary and process areas and interpreted field by field, down to the interactive keys.
  • Read this if: You run top daily but still do not know exactly what a couple of the numbers at the top mean.

If the previous post gives you the order, this one fills in its last slot. It covers how to read load average, the CPU state fields, and the memory display, then goes on to interactive operations like sorting, filtering, and toggling thread view. Knowing this much visibly changes how much information you extract from a single top screen. Using a basic tool to its end is often better than learning one more new tool.

[Network] HTTP Keep-Alive VS TCP Keep-Alive 제대로 알기

  • Blog · Author: 사바라다는 차곡차곡
  • One-line summary: Two concepts that get confused because they share a name, separated by layer and purpose, then confirmed with headers, kernel settings, and packet captures.
  • Read this if: You have investigated dropped connections and been unsure which of the two settings to touch.

The two features share only a name; their layer and their purpose both differ. The post establishes the distinction first — the HTTP one exists to send multiple requests over one connection, the TCP one is the operating system periodically confirming the connection is alive. On top of that it layers Linux kernel parameters and Wireshark captures so the explanation does not stay verbal. Without this distinction in place, investigating a connection pool problem can mean hours spent on the wrong setting.

[Server] CLI를 위한 2가지 인증 방식, Authorization Code Flow와 Device Authorization Flow

  • Blog · Author: MangKyu's Diary (망나니개발자)
  • One-line summary: Two OAuth flows usable from a CLI, compared, with the reasoning for why the latter is recommended in headless environments.
  • Read this if: You need to add login to an internal tool that also has to work on a server with no browser.

Because it starts from concrete constraints — port binding and dependence on a local browser — the difference between the two flows reads as a selection criterion rather than theory. It also covers why PKCE is needed, with the attack scenario attached. Sequence diagrams make it easy to hold the whole flow in your head before implementing. With internal CLI tooling proliferating lately, the topic has a high practical hit rate.

로컬에서도 프로덕션과 유사한 환경에서 테스트할 수 없을까? : Testcontainers 도입기

  • Blog · Author: Tecoble (Woowacourse) · 5기_리오
  • One-line summary: A step-by-step record of closing the gap between H2 in local tests and MySQL in production.
  • Read this if: You have lost trust in a test suite that passes locally and breaks on deploy.

I included this despite it being a company-affiliated blog because, among Korean-language accounts of adopting this, it keeps the most honest record of its intermediate steps. The team did not jump straight to Testcontainers; they went through a phase of splitting migration files, and why that phase fell short is written down. A post that leaves this kind of trajectory is easier to transfer to your own situation than one that only states the conclusion. The cost of requiring Docker is mentioned too, so the information you need for the decision does not lean one way.

Related Posts and Tools on This Blog

Other Posts in This Series

Discuss on Twitter • View on GitHub