Writing

2026.10.20 Why Do I Have to Pay to Distribute Software I Built Myself? A program that runs perfectly well on my computer can be treated as dangerous on someone else's. Not because the code is broken or contains anything malicious, but simply because nobody can verify who made it. How does an operating system work out where a program came from, and how is a user supposed to decide whether to trust it? Last year I released my first iOS app under my own name, which meant paying Apple a developer program fee of more than 100,000 won a year (Apple's list price is $99). Later I built a macOS desktop app and tried to put it on the Mac App Store, but I was stopped at the upload step in Xcode, before the app ever reached review. Those two experiences taught me that building software and getting it into a state where other people can actually use it are entirely different problems. Distribution Begins Only After You Pay I had worked on mobile apps at a company, so I already knew that shipping an app required certificates. But I had always worked under the company's developer account. It wasn't until I went freelance that I learned what it takes to release an app under my own name: you enroll in the developer program yourself and pay more than 100,000 won every year. Apple gives away Xcode and its other development tools, and a free account lets you build and test apps on your own devices to a degree. To distribute through the App Store, though, you need a paid developer account. Paying didn't settle everything, either. Certificates, provisioning profiles, and code signing settings were all tangled together, and I spent a good deal of time working through certificate errors. A web service, by contrast, is open to anyone once you deploy your code to a server and point a domain at it. Of course the web needs HTTPS certificates and server costs too, but at least you don't have to register with an operating system vendor and pay them before you can publish your own website. Mobile apps were different. Finishing the program didn't mean I could simply put it on other people's devices. Tiskofy, Which Only Runs on My MacBook After that I built a macOS desktop app called Tiskofy. The name doesn't mean anything. I strung some letters together, and I privately pronounce it “Tiseukopi.” You enter a YouTube URL, and it extracts the video or audio and saves it locally. I built it with the Tauri framework, using React for the interface and Rust for the native operating system features. I knew Rust reasonably well, which is partly why I chose Tauri, and it was my first time using it. What interested me was that I could build the interface with familiar web code and still reach file system and operating system features that a browser can't easily touch. Development itself went fairly smoothly. The app ran just as I intended on my MacBook, and I still use it whenever I need it. The catch was that it looked like I would be the only person who could ever use it. The App That Couldn't Even Clear the Xcode Upload I was ambitious about it. I even had AI help me make an app icon, and I wanted to list Tiskofy properly on the Mac App Store. But it never got far enough to be rejected. App Review wasn't the problem; I couldn't get past the step where Xcode uploads the build for review. I don't remember the exact error. I recall it having something to do with the FFmpeg-related binaries I had bundled to process video and audio, but without the error logs I can't say for sure what the cause was. It could have been a signing problem with an executable inside the app, or a conflict with some other build setting. Reading the documentation again now, I see that apps distributed through the App Store have to meet a number of requirements, including code signing and App Sandbox, and that an app bundling separate executables needs those files' signatures and the bundle structure to be correct as well. At the time I tried to fix the errors without really understanding any of this. I remember certificate-related errors coming back no matter what I changed, but it was a year ago and the details are hazy. In any case, Tiskofy never made it onto the App Store. It runs without any trouble on my own computer, so why does handing it to someone else require so many checks? What Does Code Signing Prove? To answer that, I first had to understand what code signing is. Code signing attaches a digital signature to software so that the signer's identity and the program's integrity can be verified. It relies on public-key cryptography. A developer has a matched pair of keys, a private key and a public key: the private key creates signatures, and the public key verifies them. When you sign a program, its data is first run through a hash function, which turns input of any size into a fixed-length value; change the input even slightly and you will generally get a completely different result. The developer uses the private key to create a digital signature from that hash, and the user's computer uses the public key to check that the program's contents still match what was signed. That is how it is possible to tell whether someone has modified an executable after it was signed. That leaves one problem. Anyone can generate a key pair, so someone writing malware can sign their program just as easily. A valid signature by itself doesn't tell you whether the signer deserves your trust. Certificate Authorities (CAs) fill that gap. A CA verifies an applicant's identity through a defined process and issues a digital certificate that binds that identity to the applicant's public key, and the operating system checks whether a certificate chains back to a CA it trusts. Code signing, in other words, isn't just attaching a name tag to a program. It is a way of building a chain of trust, so that the system can tell who signed the software and whether it has changed since. A signature is not a safety guarantee, though. Malicious software can carry a valid certificate too. A signature is not a certificate of harmlessness; it is a way to confirm the signer's verifiable identity and the program's integrity. Notarization and Gatekeeper on macOS Beyond code signing, macOS has a process called notarization. Put simply, it is Apple's automated check of software that a developer submits, looking for known malicious content and code signing problems. If the software passes, Apple issues a notarization ticket. Gatekeeper, the macOS security feature, checks things like the code signature and notarization status when you first open a program downloaded from the internet, and a program that fails the required checks may trigger a warning or be blocked from launching. If code signing tells you who signed a program and that it hasn't changed since, notarization tells you that Apple has run an automated security check on it. It also matters whether you distribute through the Mac App Store or hand out an installer yourself, because the requirements differ. Apps listed on the Mac App Store go through Apple's submission and review process and don't need a separate Developer ID notarization. Apps distributed outside the store are generally signed with a Developer ID certificate and notarized so that Gatekeeper will trust them. A common format for direct distribution on the Mac is the DMG, a disk image that users open before dragging the app inside it to their Applications folder. But building a DMG and getting the app inside it through the security checks are separate matters. Things get more complicated when an app contains executables of its own. A program like Tiskofy that relies on an external tool such as FFmpeg may need to sign not only the app itself but also the executables embedded in it. For notarization outside the App Store, the app must also enable a security feature called Hardened Runtime, which makes attacks such as injecting code or tampering with memory while the program is running harder to pull off. So it isn't enough to show who made the program; it also has to meet a set of conditions that protect it while it runs. Builds for the App Store have their own requirements covering the signing of embedded executable code, App Sandbox, and bundle structure. Since I have no error records from that time, I can't tell which rule Tiskofy actually failed to meet. What looked like a single program during development turned out, at distribution time, to be a set of executables and settings that each have to be verified. Windows EXE Files Aren't So Different Windows applications use a similar security model. I haven't distributed a Windows program myself, so this part is based on Microsoft's official documentation. If you've downloaded an unfamiliar EXE file from the internet, you may have seen a “Windows protected your PC” warning. It comes from a security feature called Microsoft Defender SmartScreen. As I understand it, the warning doesn't necessarily mean the program is malicious; it can also appear for programs that are unsigned or haven't yet built up enough reputation. Traditionally, signing an executable on Windows has meant getting a code signing certificate from a certificate authority. The two best-known types are the Organization Validation (OV) certificate, which verifies an organization's identity, and the Extended Validation (EV) certificate, which involves a stricter identity check. These certificates use the same public-key trust model as the HTTPS certificates on websites, but for a different purpose: an HTTPS certificate verifies a server's identity and protects traffic between the browser and the server, while a code signing certificate verifies who signed an executable and that it is intact. You don't always have to buy a commercial certificate to distribute a Windows program, though. If you submit an app to the Microsoft Store as an MSIX package, Microsoft signs the validated package itself, so the developer doesn't need a commercial code signing certificate. Submitting an MSI or EXE installer to the Store requires you to sign it yourself with a trusted certificate. And if you distribute an EXE from your own website, signing isn't strictly required, legally or technically, but an unsigned program is much more likely to trigger SmartScreen warnings, which puts it at a disadvantage with ordinary users. Even a valid certificate doesn't guarantee that the warning will disappear. SmartScreen weighs several signals, such as how widely a program is used and whether security problems have been found in it before. A newly released program can therefore still trigger a warning, even if it was built safely, simply because there isn't enough information yet to judge it. EV certificates used to be promoted as a way to avoid the warning immediately, but according to Microsoft's documentation they no longer guarantee that. On both Windows and macOS, in the end, there are extra steps between building a program and distributing it in a form people can trust. So Why Does It Cost Money? This is what puzzled me most when I first joined Apple's developer program. The development tools are free, so why does handing the result to someone else cost extra? Running a certificate-based trust system must cost real money. A CA has to verify applicants' identities, operate systems that let anyone check whether a certificate is still valid, and keep a way to revoke certificates and stop trusting them when a private key leaks or a certificate is abused. Still, not every fee paid to distribute software is the same kind of fee. Apple's annual fee is closer to the cost of access to App Store distribution and a range of developer services than the price of a single certificate. A commercial code signing certificate on Windows, by contrast, is more clearly payment for identity verification and for issuing and managing the certificate. In addition to selling certificates, Microsoft offers a cloud-based code signing service called Azure Artifact Signing (previously Trusted Signing). According to Microsoft's documentation, the basic plan starts at $9.99 a month. But a low price doesn't mean anyone can use it. As of October 2026, individual developers can use the service only in the United States and Canada, so an individual developer in South Korea can't simply sign up and may have to consider a certificate from another certificate authority to sign software for direct distribution. An expensive certificate isn't mandatory on every operating system or for every distribution method. Still, an individual developer who wants to offer an installer from their own website runs into identity verification, code signing, and platform-specific security policies. I fully understand the need to protect users from malicious software. A program from an unknown source that can read or modify files on a user's computer and launch other programs is dangerous. But the burden of getting through these procedures is very different for an individual who has just built a first program and for a company that has been shipping software for years. And buying a certificate and signing a program doesn't earn software trust automatically, either. Proving who you are and building software that people can actually trust are separate problems. The Barrier AI Lowered, and the One It Didn't With advances in AI, many more people now build programs through so-called vibe coding. Even someone without much development experience can describe the feature they want in plain language, tweak the code the AI writes, and end up with a program that really works. I think desktop applications are an especially good tool for solving the big and small problems of everyday life. They can run without a server, they can process data right on the user's computer instead of sending it elsewhere, and they can use file system and operating system features. Batch-converting files, automating repetitive chores, and tidying data in a particular format are typical examples. Writing such programs used to take considerable development knowledge, but with AI's help they can now be built with far less time and effort. But trying to distribute or sell what you've built starts a very different set of problems. AI can do much of the work of packaging a program as an EXE or a DMG, and it can write the commands for code signing or fix build settings. Registering a developer account, getting your identity verified, and qualifying for the certificates and signing services you need won't be solved by writing code well, though. The code AI can write for you and the procedures in which a real person or organization proves who they are are separate problems. Add operating-system-specific build environments, CPU architectures, bundled binaries, automatic updates, license management, and payment systems, and you start to see how many steps lie between making a personal tool and selling a software product. I ran into that gap with Tiskofy. AI helped me a great deal in building the program, but I never solved the problems that came up when I tried to distribute it. Looking back, what I had finished was a working program, not a product ready to ship. As AI brings more people into building software, I suspect more of them will meet this problem for the first time. The Freedom to Build and the Responsibility to Distribute Of course, even if I had solved the Xcode upload problem, I can't say Tiskofy would have been accepted onto the App Store. An app that extracts video or audio from YouTube can raise copyright or platform terms-of-service questions depending on how it is used, and it would also have to be checked against App Review guidelines. The wall I hit back then was only one of several gates on the way to distribution. I believe code signing and notarization are essential. A program that runs on a user's computer can reach operating system features far more widely than a website can, and letting executables of unknown origin run with no verification at all carries real risk. But who should operate that system of trust, by what standards it decides which programs to trust, and who should bear the cost are separate questions worth thinking about. The web also depends on browser security policies and the certificate authorities' chain of trust, so it is not a lawless space either, but publishing a website and distributing a binary that will run on someone's own computer involve different kinds of verification and responsibility. With AI lowering the barrier to software development, I expect more people who aren't professional developers to try to sell programs they built to solve their own problems. In that process, understanding distribution, security, and systems of trust will matter as much as the ability to write code. Making a program easier to build has not made it any easier to hand to someone else. Tiskofy is still installed on my MacBook. I never listed it on the App Store and never sold it to anyone, but it does what I need it to. At first I assumed that finishing a program meant I could give it to anyone. But distributing software turned out to be more than handing over a finished file. It meant thinking about where the file came from, who is responsible for it, and what reason users have to trust it. AI has lowered the barrier of time and technical skill needed to make a program, but it doesn't take responsibility for the program you make. Finishing a program and turning it into a product that other people can trust and use remain two different problems.   References Apple Developer, 「Become a member」 Apple Developer Documentation, 「Notarizing macOS software before distribution」 Apple Developer, 「Distributing software on macOS」 Microsoft Learn, 「Code signing options for Windows app developers」 Microsoft Learn, 「SmartScreen reputation for Windows app developers」 Tauri, 「macOS Code Signing」 Development/Engineering 2026.10.13 Bringing the Cloud Back to Earth: The Internet Is Buildings, Electricity, and 0s and 1s I used to work at a company that built on-premises software in Rust. “On-premises” means installing and running software in a self-managed server environment that the customer controls directly, rather than in a cloud provider’s environment. It was at that company that I first saw a dedicated server room inside an office. Until then, a server had been an abstract thing to me, something that existed only on my monitor as an IP address or a login. I already knew, in my head, that beneath all software, however abstract, there is a physical computer. But it was in that server room, I think, that the fact finally became real to me, seen with my own eyes. These days I’m working as an on-site freelancer, moving a service that was delivered from the cloud onto a local, on-premises setup. Things that used to take a few clicks in the cloud console now have to be put together one by one, and the physical layer I had always waved off with a “surely it’s there somewhere” is rising back into view. Beneath the Cloud, There Is a Building In 2006, Amazon launched S3 for storage and EC2 for virtual servers, and the “cloud” services we use so casually today began to spread in earnest. Hosting services that let you rent servers existed before that, but the model of provisioning servers and storage through code, when you need them, and paying only for what you use took off from this point. You no longer had to buy hardware, find a place to put it, and run a connection to it. With an account and a payment method, getting a server became far easier. The origin of the name “cloud” is also interesting. From what I’ve read, it comes from an old convention in network diagrams, where a part of the network whose inner workings didn’t need to be drawn out, such as the internet, was sketched as a cloud. The cloud was never a sign that nothing was there. It meant: you don’t need to look inside here. But just because something has been erased from the diagram doesn’t mean the physical things that make it possible have disappeared. The cloud is, in the end, renting servers that sit in someone else’s data center. Whether you’re on-premises or in the cloud, a server physically sits somewhere. What differs is whose building it is, who pays the electric bill and deals with the failed disk, and how you secure more resources and scale up when you need them. What Became Visible Again When I Moved From the Cloud to On-Premises What struck me most about this work was the difference in what you are directly responsible for. Cloud providers describe this relationship with something called the shared responsibility model: the provider manages the building, the power, and the hardware, while the operating system, applications, data, and configuration on top are split between provider and customer depending on which service you use. Moving on-premises, a large share of that responsibility comes back inside the organization. Someone has to replace the disks, take the backups, manage the network equipment, and apply the security patches. The part that hits hardest in a migration is managed services. In the cloud, it’s common to consume databases, object storage, message queues, load balancers, and authentication as services. When you move on-premises, you have to decide anew how to keep providing what those services used to do. You might replace them with open-source software you install yourself or with commercial products, or you might change the architecture to merge some functions or drop them altogether. You only see how much was sitting behind a single checkbox once the checkbox is gone. The more deeply a system leans on one provider’s proprietary services, the harder it is to move, and that is the point where the phrase “vendor lock-in” stops being abstract. Whichever way you go, you need space for the servers, electricity, cooling, and a network. The cloud isn’t a technology that removes that burden so much as a service that hands it to someone else and makes it invisible. So where does that responsibility end up in the cloud? What Does a Data Center Actually Do? The time I heard the words “data center” most loudly in the news, as I remember it, was in October 2022, when a fire at a data center in Pangyo, near Seoul, took Kakao’s services offline for a long time. It wasn’t only KakaoTalk, the messaging app that much of South Korea uses every day. Taxi hailing and payments went down at the same moment, and it made plain how many seemingly separate services had been depending on one building all along. Looking into it again, I found that the fire reportedly started in the batteries, and that afterward the question of whether the company had enough redundancy and recovery systems in place became an issue too, not just the fire itself. A data center is a building that gathers servers, meaning computers, in shelf-like frames called racks, stacked layer upon layer, and provides everything needed to keep those machines running around the clock. First, there is electricity. Layers of backup keep the servers up if the grid fails: uninterruptible power supplies (UPS) and batteries, then backup generators to take over after them. Much of the power a server consumes ends up as heat, so the cooling equipment that carries that heat away needs a great deal of power as well. Telecom lines come in along multiple routes, and there are fire suppression systems, access controls, and security guards. To keep things running reliably, power, cooling, and network connections are often made redundant, designed so that if one piece of equipment fails, another picks up its role immediately. Cloud providers operate physically separate availability zones to limit the impact of failures. An availability zone consists of one or more data centers, and if you design a service to be spread across several availability zones, you are more likely to be able to keep it running even when one facility goes down. The server room I first saw at that company was a very small version of a data center. It’s a rare experience at a startup, but plenty of places that need to keep their data inside their own buildings, such as banks, hospitals, factories, and public agencies, build and run their own server rooms, even if they are nowhere near data-center scale. At the other end, the large data centers run by cloud providers hold thousands or tens of thousands of servers, and I’ve read that the biggest campuses are planned to draw as much power as a city. The scale differs, but what’s needed is the same: machines, electricity coming in, heat going out and being cooled, and lines to connect to the outside. A cloud price list ultimately includes the cost of keeping all of this running day and night. The Smallest Server Room Is on My Desk If a data center is the biggest home a server can have, the smallest one is on my desk. Developers often talk about spinning up a server locally. To spin up a server here means to run a program that receives requests, processes them, and sends back responses (serving), and “local” means that program is running on the computer in front of me. The moment I run a server program, my computer’s CPU, memory, disk, and electricity are used just as they are. Opening localhost in a browser isn’t a trip out to somewhere on the internet. It’s my computer talking to itself, which is why that address is called the loopback address. If I shut down my laptop, the server stops with it. Unlike a data center, which is built to run around the clock, my laptop was never meant to play that role. Seen this way, a development server running locally, an on-premises server run by an organization, and a server running in the cloud all work on the same principle: a program that receives and handles requests is running on a computer somewhere. What differs is where that computer is, who manages it, and how it connects to the outside world. Moving a service from the cloud to on-premises is, in the end, bringing a program that ran on a cloud provider’s infrastructure into a server environment the organization controls. The scale and the way it’s operated differ, but running a server program on a computer is the same principle as spinning up a local server on a laptop. And yet, even having come down this far, the word “server” still remains something of a black box. Beneath the 0s and 1s Are Electricity and Light Going one level deeper into the server, the CPU holds billions of transistors, and a transistor is a tiny switch operated by electricity. People often explain 0 and 1 as electricity being connected or cut off, but what a computer actually handles are two electrical states that a circuit can tell apart, such as a high voltage and a low voltage. Memory works the same way. The main memory, DRAM, stores information as charge held in tiny capacitors. Because the charge leaks away little by little, it has to be refreshed periodically even while the power is on, and when the power is cut, the information is lost. SSDs rely on the electrical properties of charge stored in flash memory cells, and hard drives record data using the magnetic state of a magnetic material. Even information that looks formless on a screen, like a line of chat or a single photo, always exists inside a server as the state of some physical material. Then there is “wireless internet.” The term is so widespread that it’s easy to assume the internet really is wireless, but Wi-Fi only connects your device to the router. Behind the router, in a typical home with a wired connection, an Ethernet cable runs to the building’s telecom room, and from there fiber-optic cable runs through the ground. In fiber-optic cable, data is carried not by electrical signals but by changes in light, and that light is converted back into an electrical signal at the destination equipment. In the end, the road out to the rest of the world is also a matter of sending electrical and optical signals along a wire. Communication between continents is mostly carried by submarine cables laid on the seabed. You might expect satellites to link the continents, but from what I’ve read, the overwhelming majority of international data traffic passes through submarine fiber-optic cables, and there are landing stations on the Korean Peninsula where those cables come ashore. Whenever I remember that a single line of text has to travel along cables on the ocean floor to cross the sea, I think about how many physical facts the word “internet” covers up. Closing Thoughts Moving a service from the cloud to on-premises means facing, one by one, these layers that used to be out of sight. Setting up by hand what used to take a few clicks in a console shows me how much equipment and how many people it takes for even a single app to open. Whatever architecture I choose from here on, I plan to start by checking which building, which machines, and whose electricity a service is running on. These days, a single message on my screen no longer feels entirely weightless. Behind that one line are the building where the server sits, cooling units that run through the night, charge inside chips, and optical fibers beneath the sea, along with the facilities and people who make and supply the electricity. Perhaps one of the greatest things the cloud has done is let us stop thinking about all of this every time. But what has become invisible has not gone away. Development/Engineering 2026.10.12 Should You Still Use a Blogging Engine That's Over 20 Years Old? When you set out to build a new blog, WordPress is the first tool people mention, and also the first one they call outdated. Still the Most Common Tool Around According to W3Techs's October 2026 survey, WordPress runs on about 40% of the websites it tracks. Among sites whose content management system (CMS) can be identified, the share rises to about 59%. For software that launched in 2003 to hold that kind of share twenty years later is remarkable in its own right. Popular tools come with the advantages of being popular, and as a developer I sometimes feel that an ecosystem this large is a feature in itself. When you hit a problem and search for it, someone has usually hit it before you and written up a fix. Nearly every hosting provider supports installing it. Plenty of people build themes and plugins, so you can pull in the functionality you need instead of building it from scratch. Those things add up and shape how usable a tool really is. Of course, popularity isn't proof of quality, and being widely used doesn't automatically make a tool good. So I'm going to narrow the scope to a single use case, blogging, and look at what WordPress offers compared with other blogging platforms and website-building frameworks. (Online stores and large media sites can wait for another day.) Born as a Blogging Tool WordPress began in 2003 as a fork of b2/cafelog, an existing blogging program, created by Matt Mullenweg and Mike Little. The fact that it was built for blogging from day one is a useful clue to how it works today. Posts and pages are separate things. Posts carry categories and tags. The newest entries stack at the top by default, every post gets its own permanent URL (a permalink), and RSS feeds and comments are built in. (Comments can be switched on or off in the settings.) A general-purpose site builder with a blog menu bolted on and a tool designed around writing from the start can share the same feature list and still feel completely different to use. As your archive grows to dozens or hundreds of posts, the value of that basic structure only becomes clearer. WordPress is used for plenty of non-blog projects now, but at its core it is still built around the post. In December 2018, WordPress 5.0 made Gutenberg, a block editor, the default. Paragraphs, headings, images, quotes, code, tables, and embeds are each a block; you can drag blocks to reorder them and save layouts you use often as patterns. Gutenberg drew plenty of complaints when it first arrived, but after several rounds of improvement, writing and laying out a post feels much more natural today. It still isn't the simplest editor for everyone. If you're used to writing in Markdown, a block editor can feel clunky. WordPress's real strength isn't the editor alone. It's that writing, placing images and tables, polishing a draft, and scheduling it for publication all happen in one environment. A blog doesn't need one pair of hands for writing and another for running the site, and I think that matters more than it sounds. Auto-save, revision history, and automatic image resizing come built in too. Depending on your server and network, not every piece of work is guaranteed to be preserved, but these features take a lot of everyday worry out of writing. Block editing and scheduled publishing aren't unique to WordPress, and plenty of other tools can do them just as well. What matters is that you don't have to build any of it yourself: it works from the moment you install it. Put simply, it's closer to installing a tool so you can write than to starting a development project so you can have a blog. You Decide Where Your Writing Lives WordPress is open-source software released under the GPL. WordPress.org is the project site where you download it, and installing and running it yourself is what people call self-hosting. The same software, run for you by Automattic, is offered under a separate name, WordPress.com. (The official Learn WordPress lesson explains the difference.) When you self-host, you choose the hosting provider, the domain, and how your data is managed, and you can access, back up, and export your posts, images, and database directly. That is what I mean by deciding where your writing lives. Platform-run services like Tistory and Naver Blog, the two big blogging platforms in Korea, have a real advantage in convenience: you don't need any development knowledge to use them. But when policies change or the service starts to wobble, the home of your writing can wobble with it. If you plan to keep a blog going for years, this is the difference that weighs the most. Services do shut down, and it has happened in Korea too. Egloos, a blogging service that launched in 2003, closed on June 16, 2023. Its users had to back up their posts and data and find a new home within a set period; as far as I can tell, they were given roughly six months of backup access after the closure. A WordPress site on your own domain can keep its existing post URLs even if you change hosting providers. If you manage your URL structure and search-engine settings carefully during the move, links from other sites keep working. (That said, search rankings aren't guaranteed. Response time, crawl settings, canonical URLs, and internal links can all change during a server move, and your search results can shift with them.) Since services like Tistory let you connect a custom domain too, the point isn't simply whether you can use your own domain. It's whether you can decide what software runs at that address and how your data is managed. If you want your posts to open at the same address ten years from now, who owns that address matters more than you might think. Of course, having direct control of your data doesn't mean you can move it to another system whenever you like. Control, meaning the ability to access, back up, and edit your data, and portability, meaning how easily you can actually move when you want to switch tools, are separate matters. If a plugin stores its data in its own database tables, or a page builder saves content in a proprietary format, you can end up locked in even within WordPress. WordPress is strong on the first; the second depends on which themes and plugins you choose. Still, the fact that the site owner has the power to back up and attempt a migration is an important difference. Naver Blog does have things WordPress can't match. Readers find you through Naver's neighbor connections and search, you don't have to think about servers or security, and you can sign up and start writing right away. But that convenience comes at the price of some autonomy over your address and your data. If you plan to run a blog for a long time, and especially if you want to build a personal brand or expertise on the writing you accumulate, I think that tradeoff deserves serious weight. Growing Only as Much as You Need The official plugin directory alone lists tens of thousands of plugins. There's Yoast SEO and Rank Math for search optimization, caching plugins for speed, and plugins for backups, security, image compression, multilingual sites, and newsletter integration. Most of the features you'd want have already been built by someone. When you switch themes, your posts and pages stay in place, so design and content are fairly independent of each other. Of course, menu positions, widgets, templates, theme-specific shortcodes, and anything built with a page builder don't carry over automatically, so the longer you've customized a site, the more a theme change costs. Since WordPress 5.9 in 2022, if you use a block theme, the Site Editor lets you change headers, footers, and page templates without writing any code. Developers can extend things with child themes and hooks while still building on the existing structure. The middle ground between tools where you build everything yourself and tools where you stay inside a fixed template is, to me, the most practical thing about WordPress. RSS feeds come built in, so readers can subscribe with a feed reader, and you can change the permalink structure to put a readable slug in your post URLs. Since WordPress 5.5, XML sitemaps are provided by core, so you don't strictly need an SEO plugin to generate one. Plugins like Yoast SEO and Rank Math come in when you want to set a meta description for each post and manage what you tell search engines in finer detail. None of this guarantees search traffic, of course. A rich set of SEO features isn't the same as a site that is well optimized by default, either: a badly built theme, an overgrown set of category and tag pages, duplicate content, and slow plugins can all hurt your visibility. Still, there are plenty of themes and tools that output HTML search engines can read easily, and that's a real advantage. Social platforms change their algorithms and reach swings up and down with them. Against that backdrop, I expect it to matter more and more to have a built-in subscription channel like RSS that doesn't depend on any platform's recommendation algorithm, and a structure you can extend with an email newsletter when you need one. Other platforms handle extensibility differently. As far as I know, Tistory lets you edit a skin's HTML and CSS, which is quite flexible, but you can't touch server-side code or the database, and Naver Blog restricts external scripts and keeps ad revenue inside Naver's own ad service. Because you choose the server environment with WordPress, you can add a newsletter signup form, members-only posts, custom post types that group different kinds of content such as serials or book reviews, structured data for search engines, and 301 redirects that point old URLs to new ones, all through plugins or code. Whether to run ads, charge for subscriptions, or leave the page clean is also up to the person running the blog. When a Blog Becomes More Than a Blog You don't need many of these features to start a blog. Most of what I've described above becomes necessary only once the blog grows, for instance when a personal blog turns into a publication or content service that several people write for. WordPress ships with five user roles (Administrator, Editor, Author, Contributor, and Subscriber), so a workflow in which a contributor writes a post and an editor reviews it before publishing works with the default permissions alone. A full editorial workflow, with review requests, stage-by-stage notifications, and an approval history, doesn't come built in, though, and needs a plugin or a separate tool. The REST API got its foundation in version 4.4, and version 4.7 brought content endpoints for posts, comments, and users into core. That makes a headless setup possible: WordPress as the back end for managing posts, with a front end built in a framework like Next.js. What Does "Old" Really Mean? There are reasons people call WordPress outdated. It has an old architecture built around PHP and a relational database. Its ecosystem is one in which countless plugins each extend functionality in their own way. The admin screen carries traces of different eras, and settings look different from one plugin to the next. Next to tools designed from the start for a modern development environment, parts of WordPress do feel clunky. "Old" describes time; "outdated" is a judgment about present usefulness. The two don't have to mean the same thing. Using PHP or a relational database is not, in itself, evidence of obsolete technology. The real question is when an old structure becomes technical debt and when it's a stable asset. Thanks to long-maintained backward compatibility, posts written years ago still open today, and you can still search up solutions that have piled up over the years. The age of old software is both technical debt and an asset. The flip side of being usable for a long time is having to keep managing old decisions. A plugin you installed years ago stops getting updates. Past customizations keep you from upgrading PHP. You want to replace a plugin, but your existing posts are tied to its format and can't easily be cleaned up. Using old software means getting backward compatibility as an asset while also accepting responsibility for maintaining it. Whether that asset is worth the present inconvenience depends, I think, on how you run your blog. Maintenance Comes With the Territory Of course, a self-hosted WordPress site comes with maintenance. If you put off updates to core, themes, and plugins, vulnerabilities open up, and plugin vulnerabilities are often cited as a major route for security breaches. You also have to deal with backups, caching, HTTPS, and hosting costs, and as you add plugins one by one, the site can get heavier or start to conflict with itself. That WordPress is free software doesn't mean running a blog is free. Count the domain and hosting fees, the subscriptions for paid themes and plugins, the time you spend on updates and backups, and the responsibility for fixing problems yourself, and the real cost ends up well above the monthly hosting bill. Choosing managed hosting or keeping only the plugins you truly need eases the burden considerably, but the time that choice takes is also part of what it costs to use WordPress, and the responsibility that comes with it falls on the site's owner. If you publish only occasionally and don't need an admin screen, building a static site with something like Hugo, Jekyll, or Astro can reduce your operating burden, since serving only static files leaves less dynamic runtime to manage on a public server. That doesn't make security concerns disappear, though. Build tool dependencies, deployment accounts, external services, and automated deployment pipelines still need protecting. So Who Is WordPress Right For? In the end, what most people want to know is less whether WordPress is a good tool than whether it suits their situation. If you want to connect with Korean readers without fiddling with settings, Naver Blog is the quickest route. If you want to publish easily without running a server, a hosted service like Tistory is comfortable. If you want to run a blog for the long haul with your own domain and content structure, self-hosted WordPress fits. If you're comfortable with development and want a fast, simple, writing-focused site, a static site generator such as Hugo or Astro is the better match. And if you plan to grow from writing into a membership site or a broader content service, WordPress or another extensible CMS is a candidate. Whichever you choose, I think the deciding factor isn't what's fashionable but how long you'll run this blog and how far you intend to grow it. WordPress remains a reasonable choice when the blog is one you'll keep running for years, under your own address, and grow as you need. The Best Tools Stay Behind the Writing The reason WordPress is still worth recommending isn't that it's old yet somehow still good. It's that what has accumulated over its long life is still useful. An old structure becomes a burden when you have to respond to new requirements or untangle past dependencies, but it becomes an asset when you keep drawing on the posts you've accumulated, the working habits you know, and a rich set of extensions. Static sites, platform blogs, and headless setups each have their place. Among them, WordPress remains an option you can start as a blog, expand when you need to, and keep running for a long time. What matters in the end is less which tool is newest and most convenient right now than which structure you entrust the coming years of accumulating posts to. For a tool meant for blogging, I think the most important quality is that it can endure that time. Sources W3Techs, WordPress usage statistics WordPress Learn, the difference between WordPress.org and WordPress.com Make WordPress Core, XML sitemaps in WordPress 5.5 WordPress.org documentation, the Site Editor (requires a block theme) WordPress Developer Resources, REST API Handbook News1, report on the Egloos shutdown (in Korean) WebSight Design, the WordPress and WP Engine dispute (2026-06-30) Development/Engineering 2026.10.01 Meeting React Again, Outside the Browser A frontend developer on the factory floor discovers that React’s original question, how to keep a screen in sync with constantly changing state, fits device screens better than it fits web documents. Development/Engineering 2026.09.28 The Story of a React Developer Who Wanted to Leave React A longtime React developer’s notes on how React became the web’s default, what that cost in complexity, and what WordPress and PHP taught about choosing tools to fit the problem. Development/Engineering