About infodrip

These days I work in infrastructure and platform engineering. I started out as a developer. I wrote code, then drew application architectures, then designed whole systems, then laid down DevOps pipelines, and now I sit in the seat that keeps the platform from falling over. I did a stint in consulting too. The job title kept changing but the work never really did: take what the business wants and stand it up in technology.

Most of that time has been in heavily regulated enterprise IT. High-traffic systems, architecture migrations, container platforms, cloud transitions. Building things, running them, moving them, and cleaning up after them — on repeat.

I am also someone who thinks too much. Even while employed I have never let go of the idea of running my own business, and raising two daughters means doing the arithmetic on money, housing, and education every single day. When someone describes a business to me, I see the system diagram before I see the pitch — profit and loss and architecture are the same language in my head. Keeping all of it in my head just meant losing it, so I started writing it down. This blog is that record.

Writing it down revealed a habit. I look at structure before surface. Far too often a conversation about technology turns out to be a conversation about money, and a conversation about money turns out to be one about organizations and accountability. That is why the posts tend to drift in that direction.

So most pieces here follow the same order. Technology → structure → operations → judgment. Not just what a technology is, but what structure it sits on, what changes once it goes into production, and therefore what you should actually choose. The subject can be Kubernetes or real estate or an org chart; the order stays the same. Technology you can learn. Judgment stays hard.

Why I write

Searching for material in the middle of real work, I kept finding one of two things: documentation that only covers how to operate the tool, or strategy decks with nothing you can hold onto. What I needed was in between. If we adopt this, who runs it? When it breaks at 3am, where does accountability land? When and where does the cost actually show up? That kind of judgment rarely survives in writing. Everyone goes through it, everyone passes it along verbally, and then everyone forgets.

So I decided to start with what I went through myself. That is why the mistakes outnumber the good calls here. The mistakes are the more accurate record.

What I write about

Two broad tracks. Posts about real estate and running the numbers on money live together under Notes.

How these are written

The raw material is either something I ran myself, or primary sources — official documentation and actual output. Anything that starts from work gets stripped of identifying detail and generalized before it goes up. I have a day job, so I run this anonymously.

I use AI tools. They are genuinely useful for drafting, tightening sentences, and translating — the English edition of this blog was made that way. I am not hiding it. But what to write, how far a claim actually holds, and what conclusion to draw are mine, and so is the responsibility. The tool does not write the posts; I write them with the tool.

When a post carries affiliate links or ads, it says so. Anything about advisory or review work is set out on the Advisory (in Korean) page.

Where this is going

At work my job is to keep the platform running, but the part I actually enjoy sits a little earlier than that — the moment the picture comes together of what a business could do with technology. Having gone around the full loop from development to architecture to infrastructure to operations, laying out the technical options and then narrowing them down in business language is the most interesting work there is, for me.

So the direction is settled. Owning the whole of the technology at a small organization. That might be my own company, or it might be CTO at an organization I believe in. Being the engine of something small suits me better than being a component of something large. This blog is part of the run-up. Leaving the reasoning behind each judgment on the page is, after all, what a technical leader does every day.

I am not looking to move right now. But this kind of conversation is always welcome: a team standing up its engineering organization for the first time, a team whose systems have grown more complex than its headcount, or a seat that needs someone to translate technical decisions into business language. That last one is exactly what I do here every week. If something comes to mind, get in touch (in Korean). I run this anonymously, so anything that needs mutual verification we can work out once a conversation has started.

This site

A Next.js static site running on Cloudflare Pages. Every post is plain static HTML, so it reads fine with JavaScript off. Crawling for AI training is declined in robots.txt. I built it and I run it myself, which seemed like the operating model that best matched what the blog is about.

Contact

Thoughts on a post, corrections, collaboration — all through the contact page (in Korean). Conversations about building something together are especially welcome. Replies may be slow, but I read everything. Policy documents are at Privacy Policy (in Korean) and Disclaimer (in Korean).

Every post here is translated from the Korean original. If a sentence reads oddly, the Korean version is the one that counts — read this page in Korean.