Evans Library

What Leaders Should Really Worry About Isn't Productivity

Fri, 12 Jun 2026 10:00:00 GMT

A honeymoon recently pulled me away from work for a few days, and with that bit of distance I found myself dwelling on a question I rarely get to take out from under the daily grind.

I’ve written several posts about developers in the age of AI. But looking back on them from the quiet landscapes of New Zealand, I noticed something they had in common: every one of them was a worry about the individual developer. How do I avoid being anesthetized by AI, how do I hold on to my own skills, and so on.

But I had never really thought about what happens to the organization those individuals belong to, or how the leader running that organization has to change.

So this post looks into that gap. Why the belief that using AI well makes you a capable developer is closer to an illusion; what happens when that illusion spreads beyond a single person to the scale of an organization; and what a leader should be paying attention to in the face of it.

The More You Lean on AI, the Thinner Your Ability to Verify Its Output Gets

Over three recent posts, I’ve written about what stance developers should take in the AI era and what abilities they should aim for. Read together, they show how my thinking has shifted.

Here’s how each one framed the problem:

Post	Saw it as	Conclusion
Who Are You, the One Writing Code Right Now?	A matter of will	Stay alert and the tool stays a tool
Only When the Tide Goes Out Do You See Who’s Been Swimming Naked	A matter of position	Rise from author to decision-maker
Developers Who Stopped Growing	A matter of structure	Even while using AI, deliberately design a structure that loads the brain

All three point to the same place. The ability to handle AI well and the ability to verify its output are not the same thing, and the more you lean on the tool, the quieter the latter fades — painlessly, like being put under anesthesia. So that ability isn’t preserved by staying alert, nor by changing the seat you sit in; it can only be held through a deliberate structure.

But all three shared one frame. Each was a story about “how do I protect myself, one person,” and whatever the answer was, it was something I did alone. Yet from the seat where you hire people and set the team’s direction and the bar for what gets merged, this anesthesia doesn’t end with one person’s judgment dulling. When it’s not one person but the whole organization that gets anesthetized together, what is the person leading it supposed to do?

Before heading toward an answer, I should first pin down why this anesthesia can’t be stopped by individual will. It comes not from one person, but from the nature of the tool.

AI Is Not an Abstraction but a Proxy

Underneath the belief that using AI well makes you capable lies an equation: the ability to use AI well is itself a developer’s competence. You use it well, so you make more; you make more, so you’re more capable.

This equation has fairly solid historical backing. We called someone a capable developer for handling React’s declarative UI well without tracking exactly how the browser repaints, and a good developer for handling data well through an ORM without writing a single line of SQL. Handing low-level labor to tools one layer at a time while people focus higher up on design and assembly — that’s how the profession of development has evolved all along. So the claim that I can hand implementation to AI and just make judgments from above looks, at a glance, like the next chapter of that evolution.

This Abstraction Has No Ladder Down

The problem is that AI is quite different in kind from those earlier abstractions. The tools so far were deterministic. The principles were clear and the same input produced the same output, so when something went wrong there was always a ladder to climb down and trace why. You could live without looking below it day to day, but you could always descend and check the causality directly when you needed to. The point isn’t whether you ride that ladder every day, but whether you can climb down when you have to.

But generative AI is probabilistic. The same request yields different code each time, and there’s no ladder to climb down to why that code came out the way it did. Even the people who built the model can’t clearly explain why it produces a given output — and that says it all.

Let me clear up one misunderstanding. This doesn’t mean you can’t read the generated code itself. Code AI spits out is as readable as the SQL an ORM generates — more readable, even. “No ladder” doesn’t mean you can’t read the output; it means there’s no ladder down to why the code was written that way. Under a deterministic tool there was at least a rule of causality to follow down, but for what a probabilistic proxy hands you, there’s no path for a person to retrace. Whatever process happened inside the AI, it never once passed through a human head.

And there’s a more decisive difference. The earlier abstractions lifted us up a layer. In handing DOM manipulation to React, we took hold of a new, higher layer of causality: component design. But AI doesn’t lift us up a layer. It sits down in the very layer where we were standing. If an abstraction was climbing one rung up the ladder, AI is seating a proxy in your spot. So there’s no new causality to grasp above, and the causality you used to hold quietly slips away. That’s why I call AI not an abstraction but a proxy.

So the real substance of “using AI well” is less about mastering deterministic rules to control the result, and more about picking the best one out of the many probabilistic outputs AI pours out. (In other words, however well you build the harness, it’s basically a game of luck.)

Who Holds Ownership of the Causality

Here the line between when using AI builds your ability and when it erodes it comes into view. The line is who holds ownership of the causality. Code we wrote ourselves leaves, in our heads, the causality of why we wrote it that way. Why this branch sits here, why we chose this data structure, which cases we gave up — all of it follows along naturally. But AI-written code has only the result; the causality leading to that result never passed through our heads.

Stacking up code with the causality missing is like signing, over and over, a contract written in a language you don’t know. There’s no problem at first, but the moment the clauses conflict, the signer has not a single line of defense. Reading and understanding is a completely different weapon, in an emergency, from holding the causality from the start. The more complex the system gets, the more a developer who has only stacked up signatures heads toward a state where they can’t touch a single line without AI.

Up to here, this is what the earlier posts covered. And as the April post showed, this anesthesia is a structural problem that individual will doesn’t easily stop. But suppose, generously, that one clear-headed person holds out by sheer will. The real problem is that this was never something that ends inside one person’s head.

AI Levels Plausibility, Not Skill

There’s a reason this anesthesia doesn’t stop at one person. Code with the causality missing happens to look perfectly fine on the surface. So that code piles up quietly inside the organization without anyone stopping it. And you don’t have to look far for the pattern — it lands on my desk every day.

As an interviewer these days, and as a reviewer poring over the PRs that come in daily, I see an enormous amount of AI-written code. And it makes me think AI is leveling developers’ skill into a kind of plausible uniformity.

Say you rate the surface-level completeness of code from 1 to 10. There used to be 1s and there used to be 10s. But lately the 1-to-4 range has all but vanished, and the floor feels leveled up to around a 5. What matters here is that what’s being leveled is not developers’ ability, but the surface level of the output.

In other words, what AI raised is not skill but the floor of “plausibility.” And this distinction matters because the problem doesn’t get solved by AI getting better. As models improve, the floor of plausibility just rises higher, and the more plausible the output looks, the harder it becomes to see that the causality inside is empty. So AI’s quality isn’t the variable this post is about. The better it gets, the more discreet the anesthesia becomes.

Code That Looks Fine from a Distance

In fact, looking closely at the PRs that come in daily, I occasionally spot ones whose quality is poor — and what they all have in common is that they look plausible from a distance.

The variable names are tidy and the structure looks reasonable, but dig in a little and you find duplicate functions carrying the same responsibility, blurry boundaries of responsibility, or piles of side-effect-laden code.

But there’s a faster tell than digging into the code: asking the person who wrote it. Surprisingly often, even for code they supposedly wrote themselves, a single “why did you do it this way here?” leaves them stuck, or rambling about something unrelated. The variable names and structure are tidy, but they can’t give the reason for the choice — and that’s the most honest evidence of code that looks fine on the surface with the causality missing. (As an interviewer, I run into this scene constantly.)

The real problem is that there just aren’t many people who can spot code with the causality missing. Whether in an interview or a review, pinpointing an empty causality takes a certain eye on the viewing side — and the ability to tell apart and produce well-structured code was rare even before the AI era. On top of that, in an age where code can be written in seconds, this ambiguous-quality code is piling up faster and faster.

Seen this way, those flimsy PRs coming in every day aren’t exceptions but signals. The reason they look flimsy to me is that I can still see the gap between ambiguity and good quality. What’s truly frightening is that when code of this quality starts being produced en masse inside an organization, and the developers who can read problems out of it keep dwindling, there’s still no clear way to control the situation.

I see this phenomenon as “the organization gradually being anesthetized by AI.”

The Anesthesia Spreads at the Scale of the Organization, Not the Individual

So if a leader wants to keep the organization from being anesthetized together, what should they look at first? The starting point is pulling apart two things we usually lump together.

What I want to propose is a distinction between productivity and cognitive ownership. Productivity is the amount of code and feature completeness produced per unit of time, and the better you use AI, the more explosively this number climbs.

Cognitive ownership is a different story. It’s the state of being able to trace and explain, from start to finish, why the code you’re handling had to be written the way it was. Not whose hands the code passed through, but in whose head its causality lives.

At the individual level, these two don’t move together. The more you delegate to AI, the higher productivity goes, but cognitive ownership of that code keeps thinning. And once you move this thinning to the scale of an organization, the picture gets far more brutal.

There used to be at least two layers of ownership on a single line of code. The author who wrote it held the causality, and the reviewer held it once more. Even if the author left the company, a copy of the causality remained in the reviewer’s head. So the causality and context of the code were held distributed across several heads, not concentrated in one.

Generation Takes a Second, Verification Stays the Same

But in the AI era, these two layers thin out fast. The most fundamental reason is that the cost of generating code and the cost of verifying it are asymmetric. AI’s marginal cost of producing code converges to nearly zero. A single line of prompt, and dozens or hundreds of lines pour out. But the cost of properly verifying that code doesn’t drop at all. The longer the code and the deeper the context, the more time and focus verification takes, unchanged.

On top of this comes the organization’s pressure for speed. Team productivity tends to be measured by the number of merged PRs and deployment frequency, not by how well the team holds the code.

So the person spending an hour verifying code that came out in a second looks like the slowest person on the org’s metrics. Next to the thrill of producing fast, the labor of verifying slowly starts to feel like an irrational act. Critical acceptance isn’t something willpower alone can sustain; it’s the kind of thing that slowly collapses under the economic pressure of time and efficiency.

And So Even Review Gets Handed to AI

The smoothest exit this pressure finds is handing even the review over to AI. Lately I keep getting asked, “if AI does the review too, doesn’t the review bottleneck disappear?” — and the question itself is a signal that verification is already seen as a cost to clear away fast. In practice, when a PR comes in, an AI review bot leaves a summary and some comments on its own, and a person skims that summary and leaves a one-line “LGTM” — a scene that’s getting more and more familiar.

But the review AI leaves only looks like verification; it isn’t. It too is just one more plausible output with the causality missing — no trace of anyone taking responsibility for judging right from wrong. Handing review to AI doesn’t solve the verification bottleneck; it’s closer to skipping the step of verification entirely.

The moment both writing and review become AI, the causality of that PR lives in no one’s head on the team. The author never held it, and the approver just stamped it. The organization ends up running a system that no one possesses. People often believe the principle of “I operate the code I built” guards against this. But that principle guaranteed ownership back when building meant understanding — and the moment AI does the building, that link snaps. A state where I operate it but the causality of that code isn’t in me, something that would have been a contradiction before, simply becomes possible. The approver who can’t verify — the one stamping a contract they can’t read — becomes not a single deviation but the organization’s default state.

Industries That Passed Through This Anesthesia First

This isn’t even something developers are the first to face. Aviation passed through this anesthesia decades earlier. In her 1983 paper Ironies of Automation, Lisanne Bainbridge pointed out that as automation advances, only the hardest exceptions are left to the human — while the very skill to handle those exceptions atrophies because of the automation. One of the causes cited in the investigation of the 2009 Air France 447 crash was that the crew couldn’t manage the manual control demanded the instant the autopilot disengaged. It wasn’t one person but the whole cockpit that went powerless at once — and these were people who used automation better than anyone, day to day.

And it’s not just aviation. Think about what happened to the maps in our heads once we handed wayfinding over to GPS. London taxi drivers who pass the test of memorizing the entire city’s streets have a larger hippocampus — the region in charge of spatial memory — than ordinary people, according to one study. Conversely, a follow-up study found that the more habitually someone relied on GPS, the more steeply their hippocampus-dependent spatial memory declined over time. A brain that has felt its way along the roads grows; a brain that only followed directions shrinks. The difference between the one who holds the causality and the one who only receives the result shows up even in the volume of the brain.

Medicine knows the same trap. A study analyzing hundreds of thousands of digital mammography reads in the US reported that attaching computer-aided detection (CAD) to flag lesions improved reading accuracy on no metric at all — and that among radiologists who had worked both ways, sensitivity was actually lower when using CAD. As the eye grows accustomed to what the tool points out, the human comes to miss what the tool missed too. That’s exactly the price you pay when you hand verification to a tool.

On top of this comes the cruelty of the time lag. Suppose a flaw in code AI wrote blows up as an incident six months later. If the team’s ownership has dulled enough over those six months, then at the very moment the problem hits, the ability to handle it may be nowhere in the organization. The ability to deal with the flaw shrinks faster than the flaw grows.

Taste Grows Only Inside Breakdown

What makes anesthesia uniquely frightening is that it arrives not as pain but wearing the face of comfort. So it’s worth looking once more at exactly what that comfort numbs. These days you hear it said of developers in the AI era that “what matters now is taste.” Hand implementation to AI, the saying goes, and a person only needs the eye to recognize what’s good. Half of that is right. In the work of picking the best one out of the pile of probabilistic outputs, that eye is becoming an ever more decisive variable. What I called cognitive ownership earlier is, in the end, just another name for this eye.

The question is where that taste comes from. People who talk about a taste economy mostly treat the eye as an innate sense, or as something cultivated by looking at lots of good output. But the eye that tells good code apart doesn’t come from reading lots of good code. It’s the result of something we wrote breaking, of stopping at the break and feeling out by hand why it broke, and of not writing it that way the next time — etched into the body across countless rounds.

There’s a famous example Heidegger gave, of hammering. A hammer that fits your hand recedes from awareness while it works smoothly — you forget it’s even a hammer — and only when the head comes loose and the nail spins does it surface before you as an object. We come face to face with a tool’s essence, and the causality beneath it, paradoxically when it breaks. That story holds for code too. The moments when the compile broke and you were stuck for ages not knowing why — those were the very forge where a sense of good and bad was hammered out.

So taste isn’t passed on as propositions. Memorizing a hundred rules like “reduce side effects” won’t give you the eye to recognize good design. That eye is closer to a kind of knowing tamed by getting burned firsthand across countless individual cases, not a list of rules.

What Aristotle set apart from book-learned knowledge and called “practical wisdom” is exactly this kind of thing. It grows only in a place where repeated practice has settled into habit. So a taste that has never once gone through implementation is a bit like claiming to know the destination of a road you’ve never walked. It may not be a contradiction in terms, but it’s at least a taste that doesn’t even know what it doesn’t know.

And right here is AI’s quiet trap. AI doesn’t remove the breakdown; it removes the experience of going through the breakdown. It fills in the spots where you’d get stuck on its own, and sutures the broken places before you even get to look at them.

It wears the face of convenience, but every moment smoothly filled in is, in fact, one forge — where taste could have grown — quietly closing. The real trap of anesthesia isn’t that it erases pain. It’s that along with the pain, it erases what could only grow through that pain. So there’s always one thing missing from the phrase “taste economy”: in a world where everyone holds the eye and no one gets broken at the bottom, where exactly is that eye supposed to grow anew?

Hiring Where the Apprenticeship Has Been Cut

From a leader’s standpoint, the place this anesthesia works most awkwardly is the hiring and development of new talent.

The forge from the previous section is what we’ve long called apprenticeship. A senior with good judgment doesn’t fall out of the sky one day; it’s a junior who fumbled writing a comma-inserting regex from a blank page and chased causality through the night to catch an incident who, in time, comes to stand in that seat. The time spent paying the price of verification was the very substance of apprenticeship.

When AI Lets You Skip the Apprenticeship

The problem is that AI lets you skip this whole path of apprenticeship. For a developer who’s had AI beside them since their first day, skipping verification isn’t a compromise made at some point; it’s the default given from the start. And judging by output alone, even a junior who skipped the apprenticeship produces plausible code fast enough with AI attached. As I said earlier, what AI levels is plausibility, not skill — so in terms of visible productivity, the difference barely shows.

Here the leader faces a nasty temptation. If the output is similar anyway, why bother eating the inefficiency of letting a junior feel their way along the bottom? Attaching AI to produce results fast is far more favorable to the quarterly metrics.

But once that choice stacks up over a quarter, then two, the very supply of people who can tell code apart dries up. The death of implementation ownership doesn’t show right away, then returns a generation later as the depletion of judgment ownership — and by then there may not even be anyone left to notice the depletion.

What makes this depletion fatal is that what ultimately determines a developer’s worth is the judgment of what’s right and what’s worth building. And that judgment, as we saw in the previous section, grows only in a place where you’ve felt out the bottom of implementation yourself.

Here a counterargument is possible. Even if you hand implementation entirely to AI, if a human stays deeply involved in the design decisions, won’t judgment grow on top of that? It’s a fair point — and in fact that’s the core of the prescription I’ll get to later.

Only, that involvement doesn’t happen on its own. With a plausible result one button-press away, deliberately stopping to ask yourself “why this design in particular?” runs straight against the economic pressure we saw earlier. So co-design — handing off the implementation but keeping the causality of the decisions in human hands — isn’t the default that happens if you leave things alone, but an exception you have to consciously design in. The moment delegation without involvement, delegation that hands off even the decisions, hardens into the default, the soil where judgment’s causality could grow is gone.

A seat where you have to choose between short-term productivity and the long-term supply of capability — that’s the leader’s seat. And this choice isn’t one an individual developer can solve by will; it’s the kind that’s only solved when an organization decides to deliberately bear the cost.

This Isn’t a Problem to Settle by Grumbling About Fundamentals

I don’t want to end this by chalking it up to a lament that individuals lack fundamentals. That’s not much different from the old lament aimed at the generation that didn’t learn assembly — and I’m a beneficiary of that very lament. Every time a tool climbed a layer, the baseline shifted, and good developers kept emerging above the shifted baseline all the same.

But as I noted, this time is different. The earlier abstractions only hid the causality; they didn’t erase it, so you could always climb back down the ladder and check it directly when you needed to.

On top of a probabilistic proxy like AI, though, that ladder doesn’t lay itself down on its own. The path to climb to the bottom and touch the causality directly simply doesn’t appear if you leave things alone. So this isn’t a question of who’s lazier or less talented. Whether capability grows or not is, increasingly, decided not by an individual’s will but by the structure they’re placed in. And the one in a position to decide whether to lay that ladder — the one AI carried off — back into the team, even artificially, is the leader.

The Prescription Has to Be Team Structure, Not Individual Resolve

The problem is that protecting ownership doesn’t run on resolve alone. As we saw, what makes people skip verification isn’t will but economic pressure — so the prescription, too, has to be built as a structure of action you can’t easily slip out of, not just a state of mind. And at the organizational scale, the one who can build that structure is the leader, not the individual developer.

The Inefficiency of Ownership Is an Insurance Premium

Before building the structure, though, there’s something to admit honestly. Protecting ownership is plainly inefficient. You’re having a person hold onto code that would take a second to generate, so on short-term metrics it almost always looks like a loss. An appeal of “it’s the right thing, so bear with it” won’t let that inefficiency hold out for long against economic pressure.

That’s why this cost has to be justified in the language of accounting, not morality. The inefficiency you spend on ownership isn’t a loss but an insurance premium.

Recall the time lag from earlier. A flaw AI planted doesn’t hand you the bill now; it comes back months later as an incident, all at once — and at the very moment when the ability to handle it has drained most from the organization. The cost of a single incident easily exceeds the sum of all the verification time you saved.

The speed of a quickly merged PR shows up clearly on the quarterly metrics, but the way that saved time swells into incident costs several times over later shows up on no metric at all. The leader’s job is to write that invisible bill into the ledger in advance. If you don’t account for the inefficiency of ownership as a premium to be paid rather than a luxury, the structures below will be the first line items cut in the race for speed.

Here someone might push back: the market runs on speed in the end, so if an organization that ships fast — anesthetized or not — wins, isn’t ownership an idle luxury? It’s a fair point, but a counterargument that leaves out two things.

First, that “winning” is mostly a victory on the quarterly metrics. The incident cost we saw earlier is just piling up behind, unrecorded on those metrics; it only looks like winning until the bill arrives.

Second, speed is a moat only while models are scarce. The moment everyone holds the same AI, generation speed levels out, and the remaining difference shifts to the power to tell the output apart and verify it. So ownership isn’t a nostalgia that resists the market, but the very ability the market will start pricing once speed becomes common. Slowing the anesthesia isn’t giving up efficiency; it’s closer to remaining one of the few who can still tell good from bad in a world where everyone got fast.

On top of all that, what I’m holding onto is less a list of rules to adopt right now than a few directions. Even the same direction will take quite different shapes from team to team.

A Human Holds the Final Responsibility for Verification

As we saw, handing review wholesale to AI isn’t a convenience but closer to an organization collectively setting down its cognitive ownership. So the first direction is to move the responsibility for verification off individual will and onto team structure — while tying the end of that responsibility firmly to a human. Under the pressure of an 11 p.m. crunch, the first thing to collapse is individual resolve, so you have to nail friction that makes verification impossible to skip into the procedure at every point.

For example, you nail it into the review rules that code whose causality can’t be explained doesn’t get merged, and have a person write “why it was written this way” in their own words in the PR description. Having a reviewer or leader occasionally pick a PR at random and ask out loud, “why did you leave this branch this way?” — building in that artificial pressure — is one way too. It also helps to shift the meaning of a one-line “LGTM” from a pass-stamp to a declaration of “I can explain this code.”

This direction has a clear limit, though. Reading and explaining after the fact is a weaker weapon than holding the causality from the start, and an AI that spits out plausible code in a second writes a plausible “why” in a second too. So if you stop at writing it down, you just get AI’s excuse layered one more time on top of AI’s code. The real purpose of this direction isn’t so much to grow ownership as to stop the worst case — code that can’t even be explained flowing straight through — and to create the moment the forgery gets caught: the moment when an explanation that read smoothly on paper stalls in the face of a follow-up question. Text can be forged, but that stall is hard to fake, and the eye that catches it is the leader’s discernment I’ll come to later.

Humans Hold the Design, and We Teach How to Hand It to AI

If verification is a net cast after the fact, design is grasping the causality beforehand. Even if you hand implementation to AI, the design decisions of what to build and why stay in human hands first. I said earlier that co-design is an exception that won’t happen if left alone — this direction is exactly the attempt to raise that exception up into the default.

Concretely, it’s a flow where a person first lays out the design, hands it over translated precisely into a spec down to the constraints and edge cases, and verifies what comes back against that same design. And this work of holding the design and handing it to AI precisely shouldn’t be left to individual instinct; it has to be treated as a capability the team researches and teaches together. Not the skill of writing good prompts, but the skill of getting the design in your head out into the open without leaving anything behind.

Choose the Strongholds You Won’t Give Up

Maintaining ownership across every area is impossible. So rather than trying to hold it all, it’s more realistic to deliberately set a few strongholds you’ll never let go of. That stronghold might be the core domain at the team’s center, or the area a human ultimately has to touch directly when an incident hits, or the area carrying the heaviest responsibility to explain to the outside.

In those chosen strongholds, at least, you value understanding slowly over producing fast. A team with strongholds and a team without differ in their very power to verify unfamiliar territory — because a sense of what good code is starts, in the end, from having seen the bottom somewhere.

Turn the Inefficiency into a Learning Path

The inefficiency of growing ownership is hard for an individual chased by quarterly metrics to choose on their own. So this is an experience that only comes about when the organization decides to bear it as a cost.

It looks like picking one small area and having someone climb to the bottom without AI, or — when their own code breaks — letting them feel out the causality themselves instead of being spoon-fed the answer, or deliberately putting a junior on the core domain you set earlier and giving up speed there alone.

Ritualizing a regular “tool-less time” with AI switched off is another way. Like deliberately loading the muscle, it’s about occasionally pushing a problem all the way through with hands and head alone. Only someone who knows in their body what ownership is can choose whether to protect it, and such a person is grown by team design, not individual will.

Measure Ownership, Not Just Speed

If everything so far was about process and people, the last is about metrics. The root of the problem this post traced was, in the end, that organizations measure only speed, which makes verification look irrational. If so, the most fundamental prescription is to change what gets measured. Next to merged-PR count and deployment frequency, you place a gauge showing how well the team holds its own code.

The share of code no one can explain, or how often explanations stall under random spot checks, could be such gauges. The time it takes to resolve an incident is also a signal — because an organization missing ownership takes longer to feel out the cause when a problem actually hits. But this number swings with the difficulty of each incident, so rather than nailing the absolute value as a KPI, it’s better to read the trend, and in the postmortem to ask, separately, whether the slow resolution was because the problem was genuinely hard or because no one held the causality of that code. If the latter keeps repeating, that itself is a signal the organization is being anesthetized.

There’s a caveat, of course. The moment any metric gets nailed down as a target for evaluation, people start chasing the number itself instead of the real goal the metric pointed at (Goodhart’s law). Put “explainability rate” up as a KPI and you get plausible explanations mass-produced to hit the number instead of real understanding — the same forgery we saw earlier, repeating on top of the metric. As the speed metric was, the ownership metric is no exception. So this is safer kept not as a KPI to optimize but as a gauge you glance at now and then to see whether the organization is dulling.

In that sense, deciding that in hiring and evaluation you’ll look at “can they explain the causality of what they produced” over “how fast can they produce with AI” is one move that works more powerfully than any gauge.

I should say in advance: the outward shape of these prescriptions resembles the ones I brought up in the April post while talking about individual growth. What changed is the subject. Back then it was the technique of one person protecting their own capability; now it’s the design of an organization keeping the supply of that capability from drying up. Even the same motion — preventing your own muscle loss alone versus managing the whole team’s muscle mass — carries a different weight.

The Approver Who Can’t Verify Might, in the End, Be Me

So far this post has widened its subject one notch at a time, from the individual to the organization. But follow that subject one notch further, and at the end a single person remains again. The leader who’s been told to build the structure — me. And right there, the most chilling picture in this post comes into view.

In my second post, I wrote that no matter how far AI advances, the human role of stamping the final approval won’t disappear. Because when something goes wrong with the code, someone is needed to take responsibility — and that judgment still holds. But overlay this post’s anesthesia onto it, and while the responsibility structure keeps the stamping seat in place, the anesthesia erases — selectively — only the ability to stamp. In the end, only approvers with feeble verification ability are left.

And thinking about who that approver would be doesn’t sit easy. The person holding the stamp in an organization is usually the one carrying the greatest responsibility, and the one carrying the greatest responsibility is usually the one furthest from the code — the leader.

A leader drifting away from the code isn’t, in itself, a problem AI created. The sense for telling code apart rusting as you focus only on managing is something that’s always happened. What changed is the support that propped up that rust.

As I said, a leader used to drift from the code while an author and a reviewer holding the causality lay underneath in two layers. Even if the leader rusted personally, the ownership distributed across the organization propped it up. But the moment writing is AI and review is AI, that prop is pulled out entirely. The leader’s rust no longer stays a personal problem; it becomes the default of an organization with nothing left to prop it up.

In other words, the person best positioned for the anesthesia to reach first and deepest may be the very one carrying the final responsibility for approval. The fact that someone like me — who barely writes code at the company — is the one holding the final approval stamp is exactly what turns chilling at this point. Because for an approver left with the seat but not the ability, responsibility becomes not a shield but a bill.

What a Leader Has to Protect Is Discernment

So the structures I described earlier are, before they’re a prescription for the team, also a prescription for the leader themselves. But what the leader has to do here isn’t verify every line of code directly. That’s neither possible, nor — demanding full verification from a leader already far from the code — would it yield anything but one more plausible stamp.

What a leader needs isn’t full verification but discernment. The sense to tell whether the causality the team wrote down is real or a plausible wrapping. That sense isn’t maintained by staring at metrics from a desk, so it only stays unrusted if you climb down to the bottom of the core domain yourself now and then. A leader going down to the bottom isn’t to take sole responsibility for that code, but to keep from losing the eye that notices the team’s explanations rotting. A leader who forces a standard on the team that they themselves can’t even tell apart only lays one more layer of authority on top of an anesthetized organization.

Closing

It’s been a long way around, but the illusion I wanted to break in this post is a single one: the belief that the ability to handle AI well is itself the road to becoming a capable developer. Handling ability and cognitive ownership aren’t the same axis; they’re closer to a relationship where one quietly gets shaved down while the other rises. And that shaving doesn’t end inside one person’s head — it spreads, emptying out the organization’s head wholesale.

So the question I posed in earlier posts has to move over a notch too. As an individual, it was enough to ask, “Can I still verify what I put out, and if I lose that ability, will I even notice I’ve lost it?” But from a leader’s seat the question changes: “Can our team verify what we put out? When that ability dries up across the organization, will I — the one holding the stamp — notice? And the ladder for the next generation to ever hold that ability, am I leaving it in place?”

Of course, none of this stops the anesthetic from circulating. Maybe there’s no such thing as an organization that stays un-anesthetized to the end. If so, what a leader can control isn’t whether the anesthesia happens but the speed at which it spreads — and keeping your team an organization that can tell good from bad a little longer than others becomes the one graspable goal. It doesn’t guarantee immunity, but it buys a reprieve.

Honestly, I don’t have a clean answer for what an organization should do beyond the critical point. But not building, with my own hands, a system that rolls along drunk on the anesthetic of efficiency while no one even knows what they don’t know — that’s about as far as the minimum resistance I, as a leader, can manage right now goes.

So today, again, I review the code AI wrote, ask the team for explanations, and now and then climb down to the bottom myself. Not because I know the answer, but because I hope the sense that it’s frightening to put out code you couldn’t verify stays, for me and for our team, the very last thing to go.

And with that, I’ll bring this post to a close.

리더가 정말 신경 써야 할 것은 생산성이 아니다

Fri, 12 Jun 2026 10:00:00 GMT

이번에 신혼여행으로 인해 간만에 일에서 한 발 물러나 며칠을 보내다 보니, 평소 업무에 파묻혀 좀처럼 꺼내보지 못하던 질문 하나를 오래 들여다보게 됐다.

필자는 그동안 AI 시대의 개발자를 두고 여러 편의 글을 써왔다. 그런데 뉴질랜드의 한적한 풍경 속에서 그 글들을 되짚어보니 공통점이 하나 보였다. 전부 개발자 개인으로서의 고민이었다는 점이다. 나 하나가 어떻게 AI에 마취되지 않을 것인가, 나 하나가 어떻게 역량을 지킬 것인가처럼 말이다.

하지만 정작 그런 개인들이 모여 있는 조직에는 어떤 변화가 일어날 것이며, 그 조직을 이끄는 리더는 또 어떻게 변해야 하는가는 한 번도 제대로 생각해보지 않았다.

그래서 이번 포스팅에서는 그 빈자리를 들여다보려 한다. AI를 잘 활용하면 유능한 개발자가 될 거라는 믿음이 왜 착각에 가까운지, 그 착각이 한 사람을 넘어 조직 단위로 번질 때 무슨 일이 벌어지는지, 그리고 그 앞에서 리더는 무엇을 신경 써야 하는지에 대한 이야기다.

AI에 기댈수록 출력을 검증하는 역량은 점점 옅어진다

필자는 최근 세 편의 글을 통해 AI 시대에 개발자들이 어떤 스탠스를 취해야하는지, 어떤 역량을 목표로 해야하는지에 대해서 적은 바가 있다. 이 글들을 보면 필자의 생각이 어떤 식으로 변화되어왔는지를 알 수 있다.

각 글에서 이 문제를 무엇의 문제로 봤는지 정리하면 이렇다.

포스팅	문제	결론
지금 프로그래밍을 하고 있는 당신은 누구인가	의지의 문제	정신만 똑바로 차리면 도구는 도구로 남는다
물이 빠지면 누가 발가벗고 수영했는지 드러난다	자리의 문제	작성자에서 의사결정권자로 올라서면 된다
더이상 성장하지 않는 개발자들	구조의 문제	AI를 쓰면서도 의도적으로 뇌에 부하를 거는 구조를 설계해야 한다

세 편이 가리키는 곳은 결국 하나다. AI를 잘 다루는 능력과 그 출력을 검증하는 능력은 같은 것이 아니며, 도구에 기댈수록 후자는 조용히 약해진다. 마치 마취 당하는 것처럼 아프지도 않게 말이다. 그래서 그 능력은 정신을 차린다고 지켜지지도, 서는 자리를 옮긴다고 지켜지지도 않고, 결국 의식적인 구조로만 지킬 수 있다.

그런데 이 셋에는 공통의 테두리가 있었다. 전부 “나 한 사람을 어떻게 지킬 것이냐”의 이야기, 결국 필자 혼자 하는 일이었다는 점이다. 그러나 사람을 뽑고 팀의 방향과 머지 기준을 세우는 자리에서 보면, 이 마취는 한 사람의 판단력이 무뎌지는 데서 끝나지 않는다. 한 사람이 아니라 조직이 함께 마취될 때, 그 조직을 이끄는 사람은 무엇을 해야 하는걸까?

답을 향해 가기 전에, 우선 이 마취가 왜 개인의 의지로는 막아지지 않는지부터 짚어야겠다. 그게 한 사람의 문제가 아니라 도구의 성질에서 오는 것이기 때문이다.

AI는 추상화가 아니라 대리인이다

AI를 잘 활용하면 유능해진다는 믿음의 바탕에는 하나의 등식이 깔려 있다. AI를 잘 활용하는 능력이 곧 개발자의 역량이라는 등식이다. 활용을 잘하니 더 많이 만들고, 더 많이 만드니 더 유능하다는 흐름이다.

이 등식은 역사적으로 꽤 든든한 근거를 가지고 있다. 우리는 브라우저가 화면을 어떻게 다시 그리는지 일일이 따지지 않아도 React로 선언형 UI를 잘 다루면 유능한 개발자라고 불렀고, SQL을 직접 한 줄도 쓰지 않아도 ORM으로 데이터를 잘 다루면 좋은 개발자라고 인정했다.

이처럼 저수준의 노동을 한 겹씩 도구에게 넘기고 사람은 더 높은 곳에서 설계와 조립에 집중하는 것, 이게 지금까지 개발이라는 직업이 진화해온 방식이었다. 그러니 AI에게 구현을 넘기고 우리는 더 위에서 판단만 하면 된다는 주장은 언뜻 보면 이 진화의 다음 장처럼 보인다.

이번 추상화에는 내려갈 사다리가 없다

문제는 AI가 그 앞선 추상화들과 결이 꽤 다르다는 것이다. 지금까지의 도구들은 결정론적이었다. 원리가 명확하고 같은 입력에는 같은 출력을 내도록 되어있어 무언가 잘못됐을 때 왜 그렇게 됐는지를 따라 내려갈 사다리가 늘 거기 있었다. 평소엔 그 아래를 안 보고 살아도 필요하면 언제든 내려가서 인과를 직접 확인할 수 있었다. 여기서의 핵심은 그 사다리를 매일 타느냐가 아니라, 필요할 때 타고 내려갈 수 있느냐다.

하지만 생성형 AI는 확률적이다. 같은 요청에도 매번 다른 코드가 나오고, 그 코드가 왜 그렇게 나왔는지를 따라 내려갈 사다리가 애초에 없다. 심지어 그 생성형 AI 모델을 만든 사람들도 왜 AI가 이런 출력을 내는지 명확하게 설명을 하지 못하니 말 다했다.

여기서 오해 하나는 짚고 가자. 생성된 코드 자체를 못 읽는다는 뜻이 아니다. AI가 뱉어낸 코드는 ORM이 만들어준 SQL을 들여다보듯, 그 자체로는 얼마든지 읽을 수 있다. 사다리가 없다는 건 산출물을 못 읽는다는 게 아니라, 그 코드가 “왜 그렇게 짜였는지”로 내려갈 사다리가 없다는 뜻이다. 결정론적 도구 아래에는 따라 내려갈 인과의 규칙이라도 있었지만, 확률적 대리인이 내놓은 결과에는 사람이 되짚어 내려갈 길이 없다. AI 안에 어떤 과정이 있었든, 그게 사람의 머리를 한 번도 통과하지 않았기 때문이다.

그리고 더 결정적인 차이가 하나 있다. 앞선 추상화들은 우리를 한 층 위로 올려보냈다. 직접 DOM을 만지던 일을 React에 넘긴 대신 우리는 컴포넌트 설계라는 더 높은 층의 인과를 새로 손에 쥐었다. 그런데 AI는 우리를 위층으로 올려보내지 않는다. 우리가 서 있던 바로 그 층에 대신 들어앉는다. 추상화가 사다리를 한 칸 올라서는 일이었다면, AI는 그 자리에 대리인을 앉히는 일이다. 그래서 위로 올라가 새로 쥘 인과도 없이, 원래 쥐고 있던 인과만 슬그머니 빠져나간다. 이게 필자가 AI를 추상화가 아니라 대리인이라 부르는 이유다.

그러니까 AI를 잘 활용한다는 말의 실체는 결정론적인 규칙을 익혀 결과를 통제한다는 게 아니라, AI가 쏟아낸 수많은 확률적 결과 중에서 가장 괜찮은 하나를 골라낸다는 것에 더 가까운 것이다. (즉, 아무리 하네스를 잘 쳐도 기본적으로는 운빨 게임이다)

인과의 소유권을 누가 쥐고 있는가

여기서 활용이 역량을 쌓아주는 경우와 갉아먹는 경우의 경계가 드러난다. 그 경계는 인과관계의 소유권을 누가 쥐고 있느냐다. 우리가 직접 짠 코드에는 왜 이렇게 짰는지에 대한 인과가 머릿속에 남는다. 이 분기를 왜 여기 뒀는지, 왜 이 자료구조를 골랐는지, 어떤 경우를 포기했는지가 자연스럽게 같이 따라온다. 반면 AI가 짠 코드에는 결과만 있고 그 결과에 이르기까지의 인과는 우리 머릿속을 거치지 않았다.

인과가 빠진 코드를 쌓아 올리는 건 모르는 언어로 쓰인 계약서에 매번 서명하는 일과 비슷하다. 당장은 아무 문제가 없으나 조항들이 서로 충돌하는 순간, 서명한 사람은 한 줄의 방어권도 갖지 못한다. 읽어서 이해하는 것과 처음부터 인과를 쥐고 있는 것은 위급할 때 전혀 다른 무기가 되기 때문이다. 시스템이 복잡해질수록, 그렇게 서명만 쌓아온 개발자는 AI 없이는 한 줄도 손대지 못하는 상태로 향한다.

여기까지는 사실 지난 글들에서 다룬 이야기다. 그리고 4월 글에서 봤듯, 이 마취는 개인의 의지로도 잘 막아지지 않는 구조의 문제다. 그런데 백번 양보해서 정신 똑바로 차린 한 사람이 의지로 버텨낸다고 치자. 진짜 문제는 이게 애초에 한 사람의 머릿속에서 끝나는 일이 아니라는 데 있다.

AI는 실력이 아니라 그럴싸함을 평준화한다

이 마취가 한 사람 선에서 멈추지 않는 데는 이유가 있다. 인과가 빠진 코드가 하필 겉보기에는 멀쩡하기 때문이다. 그래서 그런 코드는 누구의 제지도 받지 못한 채 조직 안에 슬그머니 쌓여간다. 그리고 그 양상은 멀리서 찾을 것도 없이, 매일 필자의 책상 위로 올라온다.

요즘 면접관으로, 또 매일 올라오는 PR을 들여다보는 리뷰어로서 AI가 작성한 정말 많은 코드를 보게 된다. 그러다보면 AI로 인해 개발자들의 실력이 그럴싸하게 평준화되고 있다는 생각이 든다.

예를 들어 코드의 겉보기 완성도를 1부터 10이라고 본다면, 예전에는 1짜리 코드도 있었고 10짜리 코드도 있었다. 그러나 요즘에는 1~4는 좀처럼 안 보이고 최저점이 5정도로 평준화된 느낌이랄까. 여기서 평준화되는 건 개발자의 역량이 아니라 산출물의 겉보기 수준이라는 점이 중요하다.

즉, AI가 끌어올린 건 실력이 아니라 “그럴싸함”의 바닥이다. 그리고 이 구분이 중요한 건, AI가 더 좋아진다고 해서 이 문제가 풀리는 게 아니기 때문이다. 모델이 발전하면 그럴싸함의 바닥은 더 높아질 뿐이고, 산출물이 더 그럴듯해질수록 그 안에 인과가 비어 있다는 사실은 오히려 더 안 보이게 된다. 즉 AI의 품질은 이 글이 말하는 문제의 변수가 아니다. 좋아지면 좋아질수록 마취는 더 은밀해진다.

멀리서 보면 그럴듯한 코드들

실제로 매일 올라오는 PR만 자세히 들여다봐도 간혹 퀄리티가 별로인 것들이 눈에 보이는데, 그 코드들의 공통점은 하나같이 멀리서 보면 그럴듯해 보인다는 것이다.

변수명도 멀끔하고 구조도 그럴싸한데, 조금만 들춰보면 같은 책임을 가진 함수를 중복으로 작성하거나 책임 분리의 경계가 명확하지 않거나 사이드 이펙트 덩어리인 코드를 남발하곤 한다.

그런데 코드를 들춰보는 것보다 더 빠른 단서가 하나 있다. 그 코드를 짠 사람에게 직접 물어보는 것이다. 자기가 짰다는 코드인데도 “여기는 왜 이렇게 하셨어요?” 한마디에 답이 막히거나 별 관계없는 이야기를 늘어놓는 경우가 생각보다 많다. 변수명도 구조도 멀끔한데 정작 그 선택의 이유를 대지 못하는 것, 이게 바로 겉모습만 멀쩡하고 인과는 빠져 있는 코드의 가장 정직한 증거다. (면접관으로 들어가면 이런 장면을 정말 자주 마주친다)

진짜 문제는 이렇게 인과가 빠진 코드를 알아볼 수 있는 사람 자체가 많지 않다는 데 있다. 면접이든 리뷰든, 빈 인과를 짚어내려면 결국 보는 쪽에 그만한 눈이 있어야 하는데, 애초에 좋은 구조의 코드를 분간하고 만들어내는 능력은 AI 시대 이전에도 드문 것이었다. 게다가 이제는 몇 초 안에 코드를 작성할 수 있는 시대이니 점점 더 빠르게 이런 애매한 퀄리티의 코드가 늘어나고 있다.

이 관점에서 보면 매일 올라오는 그 허술한 PR들은 예외가 아니라 신호다. 그게 필자의 눈에 허술해 보이는 건, 아직 필자가 애매함과 좋은 퀄리티, 그 간격을 볼 수 있기 때문이다. 정말로 무서운 건 이런 퀄리티의 코드가 조직 내에서 대량으로 작성되어 올라오기 시작했을 때, 그리고 그 코드에서 문제를 읽어낼 수 있는 개발자가 점점 줄어들었을 때, 그 상황을 명확하게 컨트롤할 수 있는 방법이 아직 모호하다는 것이다.

필자는 이 현상을 “조직이 점점 AI에 마취되고 있는 것”으로 바라보고 있다.

마취는 개인이 아니라 조직 단위로 번진다

그렇다면 조직이 함께 마취되는 걸 막으려면, 리더는 무엇부터 봐야 할까? 그 출발점은 평소 우리가 뭉뚱그려 쓰던 두 가지를 떼어놓고 보는 데 있다.

여기서 필자가 제안하고 싶은 것은 생산성과 인지적 점유권의 구분이다. 생산성은 단위 시간당 만들어내는 코드의 양과 기능의 완성도이고, AI를 잘 쓸수록 이 값은 거의 폭발적으로 올라간다.

인지적 점유권은 조금 다른 이야기다. 지금 다루는 코드가 왜 그렇게 작성되어야만 했는지, 그 논리적 궤적을 처음부터 끝까지 따라가며 설명할 수 있는 상태를 말한다. 코드가 누구의 손을 거쳤느냐가 아니라, 그 코드의 인과가 누구의 머릿속에 있느냐의 문제다.

개인 차원에서 이 둘은 같이 가지 않는다. AI에게 더 많이 위임할수록 생산성은 오르지만, 그 코드에 대한 인지적 점유권은 점점 희석된다. 이제 이 희석을 조직 단위로 옮겨보면 그림이 훨씬 더 살벌해진다.

예전에는 한 줄의 코드에 최소 두 겹의 점유권이 걸려 있었다. 그걸 짠 작성자가 인과를 쥐고 그걸 리뷰한 사람이 한 번 더 인과를 쥐었다. 작성자가 회사를 떠나도 리뷰어의 머릿속에 인과의 사본이 한 부 남아 있었던 셈이다. 그래서 코드에 대한 인과와 맥락은 개인이 아니라 여러 머릿속에 분산되어 점유되고 있었다.

생성은 1초, 검증은 그대로다

그런데 AI 시대에 이 두 겹은 빠르게 얇아진다. 가장 근본적인 이유는 코드를 생성하는 비용과 검증하는 비용이 비대칭이기 때문이다. AI가 코드를 만들어내는 한계비용은 거의 0에 수렴한다. 프롬프트 한 줄만 넣어도 코드는 수십, 수백 줄이 쏟아진다. 반면 그 코드를 제대로 검증하는 비용은 조금도 줄어들지 않는다. 코드가 길어지고 맥락이 깊어질수록 검증에 드는 시간과 집중은 그대로 늘어난다.

여기에 조직의 속도 압력이 얹힌다. 팀의 생산성은 머지된 PR의 수와 배포 빈도로 측정되기 쉽지, 그 코드를 팀이 얼마나 이해하고 있느냐로는 측정되지 않는다.

그래서 1초 만에 나온 코드를 1시간 동안 붙들고 검증하는 사람은 조직의 지표 위에서 가장 느린 사람으로 보인다. 빠르게 만들어내는 쾌감 옆에서, 느리게 검증하는 노동은 점점 비합리적인 행동처럼 느껴진다. 비판적 수용은 의지력만으로 버틸 수 있는 게 아니라, 시간과 효율이라는 경제적 압력 아래에서 서서히 무너지는 종류의 것이다.

그래서 검토마저 AI에게 넘어간다

이 압력이 찾아낸 가장 매끄러운 출구가 바로 검토마저 AI에게 떠넘기는 것이다. 요즘 “AI가 리뷰까지 해주면 리뷰 병목도 사라지는 것 아니냐”는 질문을 부쩍 자주 받는데, 이 질문 자체가 이미 검증을 빨리 치워야 할 비용으로 본다는 신호다. 실제로 PR이 올라오면 AI 리뷰 봇이 알아서 요약과 지적을 달아주고, 사람은 그 요약을 훑고 “LGTM” 한 줄을 남기는 풍경이 점점 익숙해지고 있다.

그러나 AI가 달아주는 리뷰는 검증처럼 보일 뿐 실제 검증이 아니다. 그것 역시 인과가 빠진 또 하나의 그럴싸한 산출물일 뿐, 누가 옳고 그름을 책임지고 판단한 흔적은 아니기 때문이다. 리뷰를 AI에게 넘기는 건 검증의 병목을 푼 게 아니라, 검증이라는 단계를 통째로 건너뛴 것에 가깝다.

그렇게 작성도 AI, 검토도 AI가 되는 순간, 그 PR의 인과는 팀의 어느 머릿속에도 들어 있지 않다. 작성자도 인과를 쥔 적이 없고 승인자도 도장만 찍었다. 조직은 자기가 운영하는 시스템을 아무도 점유하지 못한 채로 굴리게 된다.

흔히 “내가 만든 코드는 내가 운영한다”는 원칙이 이런 사태를 막아준다고들 믿는다. 하지만 그게 점유를 보장하던 건 만드는 일이 곧 이해하는 일이던 시절의 이야기고, 작성을 AI가 대신하는 순간 그 고리는 끊긴다. 운영은 내가 하는데 정작 그 코드의 인과는 나에게 없는, 예전이라면 모순이었을 상태가 그냥 가능해지는 것이다. 검증하지 못하는 승인자, 그러니까 읽지 못하는 계약서에 직인을 찍는 사람이 한 명의 일탈이 아니라 조직의 기본 상태가 되는 것이다.

이 마취를 먼저 통과한 산업들

사실 이건 개발자가 처음 겪는 문제도 아니다. 항공 업계는 이 마취를 수십 년 먼저 통과했다. 리잔 베인브리지(Lisanne Bainbridge)는 1983년 자동화의 아이러니라는 논문에서, 자동화가 진행될수록 사람에게는 가장 어려운 예외 상황만 남는데 정작 그 예외를 감당할 기량은 자동화 때문에 퇴화한다고 지적했다. 2009년 에어프랑스 447편 사고의 조사 보고서가 짚은 원인 중 하나도, 자동조종이 풀린 순간 요구된 수동 조종을 승무원들이 감당하지 못했다는 것이었다. 한 사람이 아니라 조종석 전체가 동시에 무력해졌고, 평소에 자동화를 누구보다 잘 활용하던 사람들이었는데도 그랬다.

항공만의 이야기도 아니다. 길 찾기를 GPS에 넘긴 뒤로 우리 머릿속의 지도가 어떻게 됐는지를 떠올려보면 된다. 도시 전체의 길을 통째로 외워야 하는 시험을 통과한 런던의 택시 기사들은 공간 기억을 맡는 해마가 일반인보다 크다는 연구가 있다. 반대로 습관적으로 GPS에 의존해온 사람일수록 시간이 지나며 해마에 기대는 공간 기억이 더 가파르게 나빠진다는 후속 연구도 나왔다. 길을 직접 더듬어본 뇌는 자라고, 안내만 따라간 뇌는 줄어든다. 인과를 쥔 자와 결과만 받은 자의 차이가 뇌의 부피로까지 드러나는 셈이다.

의료 현장도 같은 함정을 안다. 미국에서 수십만 건의 디지털 유방 촬영 판독을 분석한 연구는, 병변을 짚어주는 컴퓨터 보조 진단(CAD)을 붙였을 때 판독 정확도가 어떤 지표로도 나아지지 않았고, 오히려 두 방식을 모두 써본 판독의들 사이에서는 CAD를 쓸 때 민감도가 더 낮았다고 보고했다. 도구가 짚어준 것에 눈이 길드는 동안, 도구가 놓친 것을 사람도 함께 놓치게 되는 것이다. 검증을 도구에 넘길 때 치르는 대가가 바로 이것이다.

여기에 시간차의 잔인함이 겹친다. AI가 짜둔 코드의 결함이 6개월 뒤에 장애로 터졌다고 해보자. 그 6개월 동안 팀의 점유권이 충분히 무뎌졌다면, 정작 문제가 터진 순간엔 그걸 수습할 능력이 조직 어디에도 남아 있지 않을 수 있다. 결함이 자라는 속도보다 그걸 감당할 능력이 더 빨리 줄어드는 셈이다.

취향은 고장 속에서만 자란다

마취가 유독 무서운 건 그것이 고통이 아니라 편안함의 얼굴로 찾아오기 때문이다. 그렇다면 그 편안함이 정확히 무엇을 마취시키는지, 한 번 더 들여다볼 필요가 있다. 요즘 AI 시대의 개발자를 두고 “이제 중요한 건 취향(taste)“이라는 글을 읽은 적이 있다. 구현은 AI에게 맡기고 사람은 무엇이 좋은지를 알아보는 안목만 쥐면 된다는 것이다. 절반은 맞는 말이다. 확률적으로 쏟아지는 결과 더미에서 가장 나은 하나를 골라내는 일에서, 그 안목은 점점 더 결정적인 변수가 되고 있다. 앞에서 필자가 인지적 점유권이라 부른 것도 결국 이 안목의 다른 이름이다.

문제는 그 취향이 대체 어디서 오느냐다. 취향 경제를 말하는 사람들은 대개 안목을 타고난 감각이거나, 좋은 결과물을 많이 구경하면 길러지는 것쯤으로 여긴다. 그러나 무엇이 좋은 코드인지를 분간하는 눈은 좋은 코드를 많이 읽어서 생기지 않는다. 그건 우리가 짠 것이 깨지고, 그 깨진 자리에서 멈춰 서서 왜 깨졌는지를 손으로 더듬고, 다음엔 그렇게 짜지 않게 되는 과정이 수없이 몸에 새겨진 결과다.

하이데거가 망치를 예로 든 유명한 이야기가 있다. 손에 익은 망치는 매끄럽게 쓰이는 동안에는 망치라는 사실조차 잊힌 채 손에서 사라져 있다가, 머리가 빠져 못이 헛도는 순간에야 비로소 하나의 대상으로 눈앞에 떠오른다는 것이다. 우리가 도구의 본질과 그 아래 깔린 인과와 정면으로 마주하는 건 역설적으로 그것이 고장 났을 때다. 이 이야기는 코드 앞에서도 그대로 들어맞는다. 컴파일이 깨지고 원인을 몰라 한참을 막혀 있던 그런 순간들이야말로 무엇이 좋고 나쁜지에 대한 감각이 만들어지던 자리이자 일종의 대장간이었던 것이다.

그래서 취향은 명제로 전수되지 않는다. “사이드 이펙트를 줄여라” 같은 규칙을 몇백 개 외운다고 좋은 설계를 알아보는 눈이 저절로 생기지는 않는다. 그 눈은 규칙의 목록이 아니라 무수한 개별 사례에서 직접 데어보고 길들여진 종류의 앎에 더 가깝다.

아리스토텔레스가 책으로 배우는 지식과 따로 떼어 “실천적 지혜”라 불렀던 게 딱 이런 것이다. 그건 오직 반복된 실천이 습관으로 몸에 밴 자리에서만 자란다. 그러니 구현을 한 번도 거치지 않은 취향이라는 건, 한 번도 걸어본 적 없는 길의 목적지를 안다고 말하는 것과 비슷하다. 형용모순까지는 아니어도, 적어도 자기가 무엇을 모르는지조차 모르는 취향이다.

그리고 바로 여기에 AI의 조용한 함정이 있다. AI는 고장을 없애주는 게 아니라 고장을 겪는 경험을 없애준다. 막히는 자리를 알아서 메워주고 깨진 자리를 미처 들여다보기도 전에 봉합해준다.

편의의 얼굴을 하고 있지만, 그렇게 매끄럽게 메워진 매 순간이 사실은 취향이 자랄 수 있었던 대장간 하나가 닫히는 순간이다. 마취의 진짜 함정은 아픔을 지우는 데 있지 않다. 아픔과 함께, 그 아픔을 통해서만 자라던 것까지 같이 지운다는 데 있다. 그래서 취향 경제라는 말에는 늘 한 가지가 빠져 있다. 모두가 안목만 쥐고 아무도 바닥에서 깨지지 않는 세계에서, 정작 그 안목은 어디서 새로 자라느냐는 물음이다.

도제가 끊긴 자리에서 사람을 뽑는다는 것

리더의 입장에서 이 마취가 가장 곤란하게 작동하는 지점은 새로운 인재의 채용과 육성이다.

앞 절에서 말한 그 대장간을 우리는 오랫동안 도제라고 불러왔다. 좋은 판단력을 갖춘 시니어는 어느 날 갑자기 하늘에서 떨어지는 게 아니라, 콤마 찍는 정규식을 백지에서 짜보며 헤매고 한밤중에 인과를 더듬어 장애를 잡아본 주니어가 시간이 지나 그 자리에 서는 것이다. 검증의 고통을 치르는 그 시간이 곧 도제의 본체였다.

AI가 도제를 건너뛰게 할 때

문제는 AI가 이 도제의 경로를 통째로 건너뛰게 해준다는 데 있다. 신입 시절부터 AI가 옆에 있던 개발자에게 검증을 생략하는 건 어느 순간의 타협이 아니라 처음부터 주어진 기본값이다. 그리고 산출물만 놓고 보면, 그렇게 도제를 건너뛴 주니어도 AI를 붙여 그럴듯한 코드를 충분히 빠르게 뽑아낸다. 앞에서 말했듯 AI가 평준화하는 건 실력이 아니라 그럴듯함이니, 적어도 겉으로 드러나는 생산성에서는 차이가 잘 보이지 않는다.

여기서 리더는 꽤 고약한 유혹 앞에 선다. 어차피 산출물이 비슷하다면 굳이 비효율을 감수하며 주니어가 바닥을 더듬게 둘 이유가 있는가. AI를 붙여 빠르게 결과를 내게 하는 편이 분기 지표에는 훨씬 유리하다.

그러나 그 선택이 한 분기, 두 분기 쌓이면, 코드를 분간할 수 있는 사람의 공급 자체가 마른다. 구현 점유권의 죽음은 당장 표가 나지 않다가 한 세대쯤 시차를 두고 판단 점유권의 고갈로 돌아오고, 그때쯤이면 그 고갈을 알아챌 사람조차 남아 있지 않을 수 있다.

이 고갈이 치명적인 건, 개발자의 값을 끝내 결정하는 게 무엇이 옳고 무엇을 만들 가치가 있는지를 아는 판단이기 때문이다. 그리고 그 판단은, 앞 절에서 봤듯 구현의 바닥을 직접 더듬어본 자리에서만 자란다.

여기서 한 가지 반론이 가능하다. 구현을 통째로 AI에게 맡기더라도 그 과정에서 인간이 설계 결정에 깊이 개입한다면, 판단력은 그 위에서도 자라지 않겠느냐는 것이다. 맞는 말이고, 사실 그게 뒤에서 말할 처방의 핵심이기도 하다.

다만 그 개입은 저절로 일어나지 않는다. 버튼 한 번에 그럴싸한 결과가 나오는데 굳이 멈춰 서서 “왜 하필 이 설계인가”를 스스로 묻는 건, 앞에서 본 경제적 압력을 정면으로 거스르는 일이기 때문이다. 그래서 구현은 맡기되 결정의 인과만큼은 사람이 쥐는 공동 설계는, 가만히 두면 일어나는 기본값이 아니라 의식적으로 설계해 넣어야 하는 예외다. 개입이 빠진 위임이 기본값으로 굳는 순간, 판단의 인과가 자랄 토양은 사라진다.

단기 생산성과 장기 역량 공급 사이에서 선택해야 하는 자리, 그게 리더의 자리다. 그리고 이 선택은 개인 개발자가 의지로 풀 수 있는 게 아니라, 조직이 의도적으로 비용을 떠안기로 결정해야만 풀리는 종류의 것이다.

기본기 타령으로 끝낼 문제가 아니다

이걸 개개인의 기본기가 부족한 탓으로 돌리는 한탄으로 끝내고 싶지는 않다. 그건 어셈블리를 안 배운 세대를 향한 옛날의 한탄과 크게 다르지 않고, 필자 역시 그 한탄의 수혜자다. 도구가 한 겹씩 올라설 때마다 기준선은 늘 옮겨갔고, 옮겨간 기준선 위에서도 좋은 개발자는 언제나 나왔다.

다만 앞서 언급했듯 이번에는 다르다. 앞선 추상화들은 인과를 숨겼을 뿐 없애지는 않았기 때문에 필요하면 언제든 다시 사다리를 타고 내려가 그 인과를 직접 확인할 수 있었다.

그러나 AI라는 확률적인 대리인 위에서는 그 사다리가 저절로 깔리지 않는다. 바닥까지 내려가 인과를 직접 만져볼 길이, 가만히 두면 아예 생기지 않는 것이다. 그래서 이건 누가 더 게으르거나 자질이 부족하냐의 문제가 아니다. 이제 역량이 자라느냐 마느냐는 점점 개인의 의지가 아니라 그가 놓인 구조가 결정한다. 그리고 AI가 걷어가 버린 그 사다리를 팀 안에 인위적으로라도 다시 놓아줄지 말지를 정할 수 있는 자리에 있는 사람이 바로 리더다.

처방은 개인의 결심이 아니라 팀의 구조여야 한다

문제는 점유권을 지키는 일이 결심만으로는 되지 않는다는 점이다. 앞에서 봤듯 검증을 생략하게 만드는 건 의지가 아니라 경제적 압력이다. 그러니 처방도 마음가짐만 다져서는 안 되고, 쉽게 빠져나갈 수 없는 행동의 구조로 박아둬야 버틴다. 그리고 조직 단위에서 그 구조를 세울 수 있는 사람은 개별 개발자가 아니라 리더다.

점유권의 비효율은 보험료다

다만 구조를 세우기 전에 정직하게 짚을 게 있다. 점유권을 지키는 일은 분명한 비효율이다. 1초면 나올 코드를 굳이 사람이 붙들고 있는 것이니, 단기 지표 위에서는 거의 언제나 손해로 보인다. 그러니 “그래도 옳으니 감수하자”는 식의 호소만으로는, 이 비효율이 경제적 압력 앞에서 오래 버티지 못한다.

그래서 이 비용은 도덕이 아니라 회계의 언어로 정당화되어야 한다. 점유권에 들이는 비효율은 손실이 아니라 보험료다.

앞서 본 시간차를 떠올려보자. AI가 심어둔 결함은 지금 청구서를 내밀지 않고, 몇 달 뒤 장애가 되어 한꺼번에, 그것도 그걸 수습할 능력이 조직에서 가장 많이 빠져나간 시점에 돌아온다. 장애 한 번의 비용은 평소 검증에 들인 시간을 다 합한 것보다 크기 쉽다.

빠르게 머지한 PR의 속도는 분기 지표에 또렷이 잡히지만, 그렇게 아낀 시간이 나중에 몇 배의 장애 비용으로 불어나는 흐름은 어떤 지표에도 잡히지 않는다. 리더가 할 일은 그 보이지 않는 청구서를 미리 장부에 적어두는 것이다. 점유권의 비효율을 사치가 아니라 지불해야 할 보험료로 회계 처리하지 않으면, 아래의 구조들은 속도 경쟁 앞에서 가장 먼저 잘려나가는 비용 항목이 될 뿐이다.

여기서 누군가는 이렇게 받아칠 수 있다. 시장은 결국 속도로 굴러가는 곳인데, 마취된 채로라도 빠르게 내놓는 조직이 이긴다면 점유권 따위는 한가한 사치 아니냐고. 일리 있는 말이지만 두 가지를 빼먹은 반론이다.

첫째, 그 “이긴다”는 대개 분기 지표 위에서의 승리다. 앞서 본 장애 비용은 그 지표에 잡히지 않은 채 뒤에 쌓이고 있을 뿐, 청구서가 도착하기 전까지만 이긴 것처럼 보인다.

둘째, 속도가 해자가 되는 건 모델이 귀할 때뿐이다. 같은 AI를 누구나 쥐는 순간 생성 속도는 평준화되고, 남는 차이는 그 출력을 분간하고 검증하는 힘으로 옮겨간다. 그러니 점유권은 시장을 거스르는 향수가 아니라, 속도가 흔해진 다음에 시장이 값을 매기기 시작할 바로 그 능력이다. 마취를 늦추는 일은 효율을 포기하는 게 아니라, 모두가 빨라진 세계에서 끝까지 분간할 수 있는 소수로 남는 일에 가깝다.

그 위에서 필자가 붙들고 있는 건 당장 도입할 규칙 목록이라기보다 몇 가지 방향에 가깝다. 같은 방향이라도 팀마다 그 모습은 꽤 다르게 구현될 것이다.

검증의 최종 책임은 사람이 쥔다

앞에서 봤듯 검토를 AI에게 통째로 넘기는 건 편의가 아니라, 조직이 인지적 점유권을 집단으로 내려놓는 행위에 가깝다. 그러니 첫 번째 방향은 검증의 책임을 개인의 의지가 아니라 팀의 구조 위에 얹되, 그 책임의 끝만큼은 반드시 사람에게 묶어두는 것이다. 밤 11시 야근의 압박 앞에서 가장 먼저 무너지는 건 개인의 결심이라, 빠져나가기 어려운 절차 곳곳에 검증을 깜빡할 수 없게 만드는 마찰을 박아둬야 버틴다.

예컨대 인과를 설명하지 못하는 코드는 머지하지 않는다는 걸 리뷰 규칙으로 박아두고, PR 설명란에 “왜 이렇게 짰는지”를 사람이 자기 언어로 적게 한다. 리뷰어나 리더가 가끔 무작위로 PR을 짚어 “이 분기는 왜 이렇게 두셨어요”라고 구두로 묻는 인위적인 압력을 만들어두는 것도 한 방법이다. “LGTM” 한 줄도 통과 도장이 아니라 “이 코드를 내가 설명할 수 있다”는 인수 선언으로 그 의미를 바꿔두면 좋다.

다만 이 방향에는 한계가 분명하다. 사후에 읽어서 설명하는 건 처음부터 인과를 쥔 것보다 약한 무기고, 그럴싸한 코드를 1초 만에 뽑는 AI는 그럴싸한 “왜”도 1초 만에 적어준다. 그래서 글로 적게 하는 데서 멈추면 AI가 쓴 코드 위에 AI가 쓴 변명만 한 겹 더 얹힌다. 이 방향의 진짜 목적은 점유권을 길러내는 것보다, 설명조차 못 하는 코드가 그대로 흘러가는 최악을 막고 그 위조가 들통나는 순간을 만들어두는 데 있다. 글로는 매끄럽던 설명이 꼬리 질문 앞에서 막히는 그 순간 말이다. 텍스트는 위조해도 그 막힘은 위조하기 어렵고, 그걸 알아채는 눈이 뒤에서 말할 리더의 감별력이다.

설계는 사람이 쥐고, AI에게 넘기는 법을 가르친다

검증이 사후에 드리우는 그물이라면, 설계는 사전에 인과를 쥐는 일이다. 구현은 AI에게 맡기더라도 무엇을 왜 만드는지에 대한 설계 결정만큼은 사람이 먼저 쥐고 간다. 앞서 공동 설계가 가만히 두면 일어나지 않는 예외라고 했는데, 이 방향이 바로 그 예외를 기본값으로 끌어올리려는 시도다.

구체적으로는 AI에게 맡기기 전에 사람이 먼저 설계안을 세우고, 그 설계를 제약과 엣지 케이스까지 명세로 정확히 옮겨 전달하고, 돌아온 결과물을 다시 그 설계 기준으로 검증하는 흐름이다.

그리고 이 “설계를 쥐고 AI에게 정확히 넘기는” 일을 개인의 감각에 맡겨두지 말고, 팀이 함께 연구하고 가르쳐야 할 역량으로 다뤄야 한다. 프롬프트를 잘 치는 기술이 아니라 자기 머릿속 설계를 빠짐없이 밖으로 꺼내놓는 기술이다.

포기하지 않을 거점을 고른다

모든 영역에서 점유권을 유지하는 건 불가능하다. 그러니 다 쥐려 하기보다, 절대 놓지 않을 거점 몇 곳을 의도적으로 정해두는 쪽이 현실적이다. 팀의 중심이 되는 코어 도메인이 그 거점일 수도 있고, 장애가 터졌을 때 결국 사람이 직접 손대야 하는 영역일 수도 있고, 바깥에 설명할 책임이 가장 무거운 영역일 수도 있다.

그렇게 고른 거점에서만큼은 빠르게 뽑는 것보다 천천히 이해하는 것을 더 높이 산다. 거점이 있는 팀과 없는 팀은 낯선 영역을 검증하는 힘부터 다른데, 무엇이 좋은 코드인지에 대한 감각은 결국 어딘가에서 바닥을 본 경험에서 출발하기 때문이다.

비효율을 학습 경로로 만든다

점유권을 기르는 비효율은 분기 지표에 쫓기는 개인이 자발적으로 택하기 어렵다. 그래서 이건 조직이 비용으로 떠안기로 결정해야만 생기는 경험이다.

작은 영역 하나를 골라 AI 없이 바닥까지 내려가보게 하거나, 자기가 짠 코드가 깨졌을 때 답을 바로 떠먹여주는 대신 그 인과를 직접 더듬게 두거나, 앞서 정한 코어 도메인에 주니어를 일부러 붙여 거기서만큼은 속도를 포기하게 하는 식이다.

정기적으로 AI를 꺼두는 “도구 없는 시간”을 의례처럼 박아두는 것도 방법이다. 근육에 일부러 부하를 주듯, 가끔은 손과 머리로만 문제를 끝까지 밀고 가보게 하는 것이다. 점유권이 무엇인지 몸으로 아는 사람만이 그걸 지킬지 말지를 선택할 수 있고, 그런 사람은 개인의 의지가 아니라 팀의 설계로만 길러진다.

속도뿐 아니라 점유권도 측정한다

여기까지가 절차와 사람에 관한 이야기였다면, 마지막은 지표에 관한 것이다. 이 글이 짚은 문제의 뿌리는 결국 조직이 속도만 측정하기 때문에 검증이 비합리적으로 보인다는 데 있었다. 그렇다면 가장 근본적인 처방은 측정하는 대상 자체를 바꾸는 것이다. 머지된 PR 수와 배포 빈도 옆에, 팀이 자기 코드를 얼마나 점유하고 있는지를 보여주는 계기판을 나란히 두는 것이다.

설명하지 못하는 코드의 비율이나, 무작위 스팟 체크에서 설명이 막히는 빈도 같은 것이 그런 계기판이 될 수 있다. 장애를 수습하는 데 걸리는 시간도 하나의 신호다. 점유권이 빠진 조직일수록 막상 문제가 터졌을 때 원인을 더듬는 데 오래 걸리기 때문이다. 다만 이 값은 장애마다 난이도가 달라 들쭉날쭉하니, 절대치를 KPI로 박기보다 추세로 읽고, 포스트모템에서 “이번 수습이 더뎠던 게 문제가 어려워서였는지, 아무도 그 코드의 인과를 쥐고 있지 않아서였는지”를 갈라 묻는 편이 낫다. 후자가 반복된다면 그게 곧 조직이 마취되고 있다는 신호다.

물론 조심할 게 있다. 어떤 지표든 평가의 목표로 못 박는 순간 사람들은 그 지표가 가리키던 진짜 목표 대신 숫자 자체를 좇기 시작한다(굿하트의 법칙). 설명 가능 비율을 KPI로 걸면 진짜 이해 대신 그럴싸한 설명만 양산되는, 앞에서 본 그 가짜 증명이 지표 위에서 똑같이 반복되는 식이다. 그러니 점유권 지표도 최적화할 KPI가 아니라, 조직이 무뎌지고 있는지를 가끔 들여다보는 계기판으로만 두는 게 안전하다.

그런 점에서 채용과 평가의 기준에서 “AI로 얼마나 빨리 만들어내는가”보다 “자기가 내놓은 것의 인과를 설명할 수 있는가”를 보겠다고 정하는 것 하나가, 실은 어떤 계기판보다 강하게 작동한다.

미리 말해두면, 이 처방들의 겉모습은 4월 글에서 개인의 성장을 이야기하며 꺼냈던 것들과 비슷하다. 달라진 건 주어다. 그때는 한 사람이 자기 역량을 지키는 기술이었다면, 지금은 조직이 그 역량의 공급 자체를 마르지 않게 하는 설계다. 같은 동작이라도 혼자 근손실을 막는 운동과 팀 전체의 근육량을 관리하는 일은 무게가 다르다.

검증하지 못하는 승인자는 결국 나일 수 있다

지금까지 이 글은 주어를 개인에서 조직으로 한 칸씩 넓혀 왔다. 그런데 그 주어를 한 칸만 더 따라가면, 마지막에 다시 한 사람이 남는다. 그 구조를 세우라고 말해온 리더, 바로 필자 자신이다. 그리고 바로 거기서 이 글에서 가장 살벌한 그림이 떠오른다.

두 번째 글에서 필자는 AI가 아무리 발전해도 최종 승인 도장을 찍는 인간의 역할은 사라지지 않을 거라고 썼다. 코드에 문제가 생기면 책임질 사람이 필요하기 때문이고, 그 판단은 지금도 유효하다. 그런데 이번 글의 마취를 거기에 겹쳐보면, 책임 구조 때문에 도장을 찍는 자리는 없어지지 않는데, 마취는 그 도장을 찍을 능력만 골라서 지워간다. 그렇게 되면 종국에는 검증 능력이 빈약한 승인자만 남는다.

그리고 그 승인자가 누구일지 생각하면 마음이 편치 않다. 조직에서 도장을 쥔 사람은 대개 가장 큰 책임을 지고 있는 사람이고, 가장 큰 책임을 지는 사람은 대개 코드에서 가장 멀어진 사람, 바로 리더다.

사실 리더가 코드에서 멀어지는 것 자체는 AI가 만든 문제가 아니다. 매니징에만 집중하다 보면 코드를 분간하는 감각이 녹스는 건 예전부터 있던 일이다. 달라진 건 그 녹슮을 받쳐주던 받침대다.

앞서 말했듯 예전에는 리더가 코드에서 멀어져도 그 아래에 인과를 쥔 작성자와 리뷰어가 두 겹으로 깔려 있었다. 리더 개인이 녹슬어도 조직에 분산된 점유권이 그걸 받쳐준 셈이다. 그런데 작성도 AI, 검토도 AI가 되는 순간 그 받침대가 통째로 빠진다. 리더의 녹슮이 더 이상 개인의 문제로 머물지 않고, 받쳐줄 것이 없는 조직의 기본값이 되는 것이다.

즉 마취가 가장 먼저, 가장 깊이 도달하기 좋은 사람이 정작 최종 승인의 책임을 진 사람일 수 있다는 것이다. 회사에서 코드를 거의 짜지 않는 필자 같은 사람이 정작 최종 승인의 도장을 쥐고 있다는 사실이 바로 이 지점에서 서늘해진다. 능력 없이 자리만 남은 승인자에게 책임은 방패가 아니라 청구서가 되기 때문이다.

리더가 지켜야 하는 건 감별력이다

그래서 앞에서 말한 구조들은 사실 팀을 위한 처방이기 전에 리더 자신을 위한 처방이기도 하다. 다만 여기서 리더가 해야 하는 건 모든 코드를 직접 검증하는 게 아니다. 그건 가능하지도 않고, 이미 코드에서 멀어진 리더에게 전수 검증을 요구해봐야 또 하나의 그럴싸한 도장만 늘 뿐이다.

리더에게 필요한 건 전수 검증이 아니라 감별력이다. 팀이 적어낸 인과가 진짜인지 그럴듯한 포장인지를 가려낼 수 있을 정도의 감각 말이다. 그 감각은 책상에서 지표만 들여다봐서는 유지되지 않아서, 코어 도메인의 바닥에 가끔은 직접 내려가봐야 녹슬지 않는다. 리더가 바닥에 내려가는 건 그 코드를 혼자 책임지기 위해서가 아니라, 팀의 설명이 썩어가는 걸 알아챌 눈을 잃지 않기 위해서다. 자기가 가려낼 수조차 없는 기준을 팀에 강제하는 리더는, 마취된 조직 위에 한 겹의 권위를 더 얹을 뿐이다.

마치며

길게 돌아왔지만 필자가 이 글에서 깨고 싶었던 착각은 하나다. AI를 잘 다루는 능력이 곧 유능한 개발자가 되는 길이라는 믿음이다. 활용 능력과 인지적 점유권은 같은 축이 아니고, 오히려 한쪽이 오르는 동안 다른 쪽이 조용히 깎이는 관계에 더 가깝다. 그리고 그 깎임은 한 사람의 머릿속에서 끝나지 않고, 조직의 머릿속을 통째로 비워가며 번진다.

그래서 예전 글들에서 필자가 던졌던 질문도 한 칸 옮겨야 할 것 같다. 개인으로서는 “나는 아직 내가 내보내는 걸 검증할 수 있나, 그리고 그 능력을 잃었을 때 나는 그 사실을 알아챌 수 있나”를 물으면 됐다. 그런데 리더의 자리에서는 질문이 이렇게 바뀐다. “우리 팀은 우리가 내보내는 걸 검증할 수 있나. 그 능력이 조직에서 말라갈 때, 나는 도장을 쥔 사람으로서 그걸 알아챌 수 있나. 그리고 다음 세대가 그 능력을 가져볼 사다리를, 나는 남겨두고 있나.”

물론 이런다고 마취제가 도는 것 자체를 멈출 수는 없다. 끝까지 마취되지 않는 조직 같은 건 없을지도 모른다. 그렇다면 리더가 통제할 수 있는 건 마취 여부가 아니라 마취가 도는 속도뿐이고, 자기 팀을 남들보다 조금 더 오래 무엇이 좋고 나쁜지를 분간할 수 있는 조직으로 남기는 것이 그나마 손에 잡히는 목표가 된다. 그게 면역을 보장해주진 않아도 유예는 벌어준다.

솔직히 임계점 너머에서 조직이 무엇을 해야 하는지에 대해 필자는 깔끔한 답을 가지고 있지 않다. 다만 효율이라는 마취제에 취해, 아무도 무엇을 모르는지조차 모르는 채로 굴러가는 시스템을 내 손으로 만들지는 않는 것, 지금 리더로서 필자가 할 수 있는 최소한의 저항은 거기까지라고 생각한다.

그래서 필자는 오늘도 AI가 짜둔 코드를 검수하고, 팀에 설명을 요구하고, 가끔은 직접 바닥에 내려가본다. 답을 알아서가 아니라, 검증하지 못한 코드를 그대로 내보내는 일이 무섭다는 감각만큼은 나에게도 우리 팀에게도 가장 늦게까지 남아 있기를 바라기 때문이다.

이상으로 리더가 정말 신경 써야 할 것은 생산성이 아니다 포스팅을 마친다.

Tools Live On After Leaving Their Maker

Tue, 28 Apr 2026 00:00:00 GMT

In a previous post, I treated personal asset management as a kind of state management problem. Recently I wanted to manage that state better, so I started rebuilding the tools around it. This post is about the interface design questions that came up along the way.

Until then, I had been managing my assets with a combination of a Notion database and Google Apps Script. When I logged a transaction in Notion, GAS would pull exchange rates and stock prices to compute the current value. Looking back, it worked, but it was clearly too heavy a setup to live with long-term.

First, the input itself was too heavy. To leave behind a single fact like “I bought 15 shares of AAPL at $211 yesterday,” I had to open Notion, find the database, create a new row, and fill in several columns, basically jumping through hoops every time. Doing it once or twice is fine. But once those instances start to pile up, you eventually get tired of it and start putting it off.

Second, the operating cost was also too heavy. To answer a single question like “how did last March’s exchange rate movements affect my portfolio?”, I had to either build a new Notion view or attach another function to GAS. Each question essentially meant building one more tool. On top of that, GAS doesn’t really support webhooks, so triggering scripts from Notion was also a pain.

To cut down on this friction, this past weekend I moved the asset management setup over to a SQLite-based CLI plus an MCP server. Over two solid days of working through the weekend, I built around 50 MCP functions, plus a CLI for invoking them manually. I called the result Firma. I designed the CLI commands and MCP tools together from the start, because I felt every feature should work at a comparable level through both interfaces.

What was interesting is that building the two interfaces in parallel surfaced a strange thing. When I exposed the same function as a CLI command versus as an MCP tool, I expected them to behave similarly, but they actually played out quite differently. Same signature, same arguments, same return value. Even the message formats were nearly identical. The only thing that changed was whether the caller was a human or an LLM, and that difference turned out to be bigger than I thought.

This post is about that strange feeling. Wiring the same function up to both CLI and MCP brought to light an assumption I had quietly accepted in interface design. The reason MCP differs from RPC isn’t simply that it’s a new protocol. It’s that we have been treating function calls as the default for far too long.

Function Calls Are More Intimate Than We Think

There’s an assumption sitting underneath function calls that we usually don’t notice. It’s the assumption that the caller and the callee share a fair amount of context.

Take a moment to think about what happens when we call something like addTransaction(ticker, quantity, price). Just from the signature, we already have a rough sense of what it does. We trust that we more or less know why the author chose this shape, what side effects it has, what exceptions it might throw. Maybe not perfectly, but enough. Calling something without that understanding isn’t really a function call. It’s closer to guesswork.

The tools of the last few decades have evolved in the direction of strengthening this intimacy. Static type systems block you at compile time when you get an argument shape wrong. IDE autocomplete pulls back signatures you’ve forgotten. JSDoc and docstrings layer the author’s intent on top in plain text. RPC, gRPC, and GraphQL have moved toward stricter schemas, and they belong to the same lineage. The underlying assumption is always the same. The more the caller knows about the callee, the better the call.

I built my own CLI command for registering transactions on top of this same assumption. When the user types firma add txn, an interactive prompt asks for the ticker, then the type, then the shares and price one after another.

// In the CLI, this signature alone was enough
function addTransaction(input: {
  ticker: string;
  type: "buy" | "sell" | "deposit" | "dividend" | "tax";
  shares: number;
  price: number;
  date: string;
}): Promise<Transaction>

Here the user already knows what they want to do. The CLI just needs to capture that intent cleanly and hand it off to the function. The function name and argument types end up doing most of the work. I had taken this for granted for so long that I couldn’t even see it as an assumption. Not until I exposed the same function as an MCP tool.

What the Signature Doesn’t Say

The moment you expose the same function as an MCP tool, the caller shifts from human to LLM. And from that point on, all the things the signature wasn’t saying suddenly start surfacing as problems.

Me: "I bought 15 shares of AAPL yesterday"
LLM: Sure, I'll call the add_balance function.

Wait, where did that come from?

In Firma, alongside add_txn for recording transactions, there’s also add_balance for end-of-month asset snapshots, and add_flow for monthly income and expense entries.

Naturally, all the signatures are clear, and the argument types are strictly defined with zod schemas. Even so, the LLM kept getting confused about which tool to call. Running the same utterance through it a few times, it picked the wrong tool more often than I expected.

At first I thought maybe the LLM was just bad. But the longer I sat with it, the more I realized the problem was somewhere else. A signature explains what a function takes pretty well. What it barely explains is when it should be called. The name add_txn is just an identifier. It carries no notion of “use this tool when the user mentions a trade.”

A function name is more like a single line in a dictionary. Just as a word on its own can’t decide which sentence it belongs in, a signature on its own can’t decide which utterance should call it.

In the CLI, this wasn’t really an issue. The caller was a human, and the human had already typed firma add txn carrying the context “I’m about to record a transaction.” The responsibility for picking when to call sat in the caller’s head.

The LLM is different. To an LLM, the user’s utterance isn’t a finished command. It’s raw material from which intent has to be inferred. From a single word like “bought,” the LLM has to decide whether this is a buy transaction, a balance change, or a new cash flow. The only thing it has to lean on is how each tool describes itself.

Things only stabilized after I rewrote the description for add_txn. The actual production text has more operational detail attached, but for this post I’ll just paste the core of the change.

server.tool(
  "add_txn",
  `Records a single trade on a specific ticker: buy, sell, dividend received, or tax paid.
   Use this when the user mentions buying or selling stocks, receiving dividends, or paying taxes on a specific security.
   Do NOT use this for general cash deposits, salary, or expenses. Use add_flow for those.
   Do NOT use this for monthly asset snapshots. Use add_balance for those.`,
  schema,
  handler
)

What matters here is that the intent of the function migrated from the signature into the description. The signature still enforces the shape of arguments. But the meaning of the call is now decided much more by the description. The question of where to inscribe intent has shifted.

This shift happens because the caller doesn’t know the context. But when I sat with that for a while, I started to wonder. Is it really that strange for a caller not to know the context?

Tools Have Always Lived On Without Their Maker

Take a hammer for example. The person who first made the hammer surely had their own intent. Decisions about what weight is right, how long the handle should be, how the mass should be distributed. But the person who later picks the hammer up doesn’t know any of that background. They don’t need to know why the handle curves the way it does, or why the center of mass sits where it does. All they need is the intent to drive a nail.

And that’s enough. The moment a person sees a hammer, they catch the gist. Where to grip it, which side to swing, what kind of work the tool fits. They read it off the form. Tools, in this way, leave their maker and live their own lives. The user doesn’t need to know what was inside the maker’s head. They look at the form and guess whether it fits their intent. Most of the scenes in which we use tools actually look like this.

How a hammer gets used is decided by whoever is using it

This is a pretty interesting point. Whether the person holding the hammer drives a nail or breaks down a wall isn’t decided by the maker. It’s decided by the user. (They could even break a person rather than a wall…)

The blacksmith likely had a clear purpose in mind when shaping the hammer. But where that hammer actually gets swung is ultimately decided by the hand that holds it. Tools don’t just live on after leaving their maker. They live on past their maker’s intent.

Donald Norman’s concept of affordance points at this very thing. Affordance was originally coined by the psychologist James Gibson. It refers to what actions an object makes possible for a user. A chair affords sitting, a cup affords gripping, a handle affords turning. Norman pulled the concept into the language of design, narrowing it to “the property of an object’s form that suggests its own use.”

A well-designed door handle doesn’t need to spell out “grip here and pull.” The form alone should be enough to express how it should be used. The opposite is also true. Tools whose affordances are misaligned confuse their users at every turn.

Norman often points to doors that need to be pushed but have pulling-style handles. These mismatched doors are so common that the design world has even given them a nickname: Norman doors. The handle says “grip and pull,” while the actual action is “push.” A tool whose form lies to its user constantly offloads cognitive burden onto them.

The hammer is the same. Its curved handle and heavy head deliver “grip here and swing that way” at a near-unconscious level. A good tool hints at its use through its form before any documentation does.

From that angle, the description of an MCP function isn’t just documentation. To the LLM, it’s effectively the tool’s form. Just as a hammer’s handle says “grip here,” the description of a function says “call me when this kind of intent shows up.” A tool with a weak description is like a hammer with an awkward handle. It exists, but somehow your hand doesn’t reach for it.

I felt this most clearly when designing the read-side tools. At first I wanted to split them up cleanly along Single Responsibility lines. Tools with sharp roles like get_holdings, get_prices, get_pnl, calculate_value. From a function-design standpoint, it’s a pretty clean design.

But the picture changes when you put it next to a user asking “how’s my portfolio doing?” To answer that, the LLM has to chain four or five calls together. Each call might be correct, but the overall response gets slower, and there’s more room for things to slip in between. To a user asking with a single intent, you end up shoving too many small tools at them.

An early MCP design of mine actually ended up triggering a bunch of tools at once

So I ended up making show_portfolio into a slightly heavier tool. It returns holdings, average cost, current price, market value, and cumulative P&L all in a single call. get_brief goes further. It returns holdings, daily P&L, concentration, movers, news, earnings, macro indicators, and insights all at once. From a pure RPC standpoint, this can look like an overstuffed design.

But from a tool-using standpoint, this actually feels more natural. SRP is a principle that matters to the person making functions. Affordance is a principle that matters to the person using tools. If the caller is human, assembling small units works fine. If the caller is an LLM, a tool that touches the intent more directly is better. Which is better isn’t an absolute question. It depends on who the caller is.

The Direction of Trust Also Flips

In terms of shape, MCP actually sits inside the RPC family of protocols. Its messages use the JSON-RPC format, and its vocabulary of signatures and argument schemas is borrowed straight from the RPC era. That’s why I initially assumed RPC and MCP would end up flowing in similar ways.

But the more I looked at the two protocols, the more I saw a decisive point where they diverge. On top of the center of gravity moving from signature to description, the direction of trust flips along with it.

In RPC, the caller typically trusts the callee. For instance, if the signature says it returns Promise<Transaction>, the caller naturally trusts that promise and writes code accordingly. The callee, in turn, doesn’t have to particularly trust how the caller will invoke it. The type system and schemas enforce the shape on the caller’s behalf. Call it wrong and you get a compile error or a runtime error.

With MCP, the story shifts a little. The maker of the tool has to extend some trust to the caller. They have to expect that the LLM will actually read the function’s description, and that it will call the tool at an appropriate moment with appropriate arguments. The signature only enforces the shape of the arguments. The timing and meaning of the call still belong to the realm of inference.

This difference shows up more clearly in write-side tools. Firma’s add_txn actually writes to a SQLite database. If it gets called incorrectly, the asset records get corrupted right away. That fear pushed me to write the description like this at first.

"Records a transaction. Always confirm with the user before recording."

The result wasn’t great. The LLM asked “should I record it like this?” every single time, and I answered “yep” every single time. The whole point of a natural language interface basically vanished. Push too much responsibility back to the user, and the tool suddenly drags. It would be like a hammer asking “are you sure you want to drive this nail?” every time you picked it up.

So in the end, I rewrote the description like this.

"Record the transaction immediately when the user clearly states a trade.
 Do not ask for confirmation unless the data is ambiguous (missing date, etc).
 If you record incorrectly, the user can run delete_txn to undo."

Rules like “record immediately,” “only ask when ambiguous,” and “if it goes wrong, it can be reversed” aren’t really formal descriptions of the tool. They’re closer to operating principles handed to the caller. And for those guidelines to actually work, you have to expect the LLM to do at least some reasoning.

You don’t make requests of a function. You enforce it with types. With a reasoning caller, on the other hand, you have no real choice but to make requests. I think this is also why the descriptions of MCP functions keep growing into something that reads more like a behavior policy.

In a way, a signature is a declaration and a description is a request. A signature nails down “this function takes these arguments.” A description, on the other hand, asks “please call me when this kind of intent shows up.” One is enforcement, the other is persuasion. The language of persuasion has started entering tool design.

Maybe Function Calls Were the Special Case All Along

Coming back to the original question, the fact that a caller doesn’t know a function’s context isn’t actually that strange.

Humans have always used tools they didn’t make themselves. Bowls made by a potter, knives made by a blacksmith, chairs made by a carpenter. Even programs written by developers fall into this. Expecting users to always use a program the way you intended them to is something that consistently misses the mark.

Because tools leave their maker and pass into other hands like this, the user doesn’t know what was inside the maker’s head. That’s why looking at the form of a tool and using it from there is the more common scene.

In that case, the function call we’ve treated as the default for so long was actually a fairly special kind of relationship. A relationship where the caller and the author share a lot of context, and where type systems, IDEs, and documentation continuously reinforce that intimacy. Rather than treating function calls as the universal mode of tool use, it’s probably more natural to see them as one unusually intimate form of it.

Now that the caller is no longer human, there are two paths to take. One is to feed more and more context into the LLM to make it as intimate a caller as possible. The other is to close the distance from the tool’s side. Inscribing the tool’s intended use into its description, so that even a caller without all the context can still use it.

MCP leans toward the latter. It feels like a fairly natural choice. The first path eventually demands that the caller becomes more and more knowledgeable. The second path accepts that a caller can never know everything to begin with. And it fills that gap through tool design. Looking back, the way humans have made tools throughout history has always been closer to that second path.

This might be closer to a return than to anything new. Industrial design, architecture, and UX have all been standing in this spot for a long time. Programming was just unusually camped out at the intimate end of the spectrum.

Closing Thoughts

What kept me up the longest while building Firma this weekend wasn’t the code. It was the descriptions. I wrote somewhere around 30 CLI commands and 50 MCP tools, and despite the volume, the thing that ate up the most time was figuring out how each of these tools should describe itself.

A tool leaves its maker the moment it’s made. You have to design with that departure as a given. Instead of expecting the caller to know all the context, the tool itself has to express more of its own intent. What was interesting about working with MCP wasn’t so much the feeling of learning a new protocol. It was being reminded of how tools have always been used in the first place.

I’m not trying to say the era of function calls is over. But the fact that function calls were one form of interface that worked well only in fairly intimate conditions, rather than the universal default, is now much clearer to me. And designing interfaces outside that intimacy turns out to be more interesting than I expected.

Maybe we’re moving through a quiet shift in the way we design interfaces. From signature to description, from enforcement to persuasion, from assumed intimacy to acknowledged distance. The center of gravity is moving. Making tools may be standing once again at the threshold of returning to its original form.

도구는 만든 사람을 떠나서 살아간다

Tue, 28 Apr 2026 00:00:00 GMT

몇 달 전 포스팅에서 필자는 자산 관리를 일종의 상태 관리 문제로 풀어본 적이 있다. 그때 정리해둔 상태를 좀 더 잘 관리해보고 싶어서 도구를 다시 만들기 시작했는데, 그 과정에서 따라온 인터페이스 설계 관련 고민들을 한 번 풀어보려고 한다.

기존에 필자는 노션 데이터베이스와 Google Apps Script의 조합으로 자산을 관리하고 있었다. 트랜잭션을 노션에 기록하면 GAS가 환율과 시세를 가져와 평가금액을 계산하는 구조였는데, 돌아보면 동작은 했지만 오래 붙들고 가기에는 분명히 무거운 구조였다.

첫째, 입력 과정 자체가 너무 무거웠다. “어제 AAPL 15주를 211달러에 샀다”는 사실 하나를 남기려면 노션을 열고, 데이터베이스를 찾고, 새 행을 만들고, 여러 컬럼을 채우며 아주 난리 부르스를 춰야했다. 이게 한두 번은 할 만한데, 그런 한 번이 쌓이면 결국 귀찮아서 기록을 미루게 된다.

둘째, 운영 비용도 너무 무거웠다. “지난 3월 환율 변동이 내 포트폴리오에 어떤 영향을 줬지?” 같은 질문 하나를 풀려면 새 노션 뷰를 만들거나 GAS에 함수를 더 붙여야 했다. 질문 하나마다 도구를 하나 더 만드는 셈이었다. 심지어 GAS는 웹훅도 제대로 지원하지 않아서 노션에서 스크립트를 트리거하기도 어려웠다.

이 불편을 줄여보려고 이번 주말에 자산 관리 도구를 SQLite 기반의 CLI와 MCP 서버로 옮겼다. 주말 이틀 꼬박 새서 50개 정도의 MCP 함수, 그리고 이를 메뉴얼하게 호출하기 위한 CLI를 만들었고, 결과물에는 Firma라는 이름을 붙였다. CLI 커맨드와 MCP 툴은 처음부터 같이 설계했는데, 그건 필자가 모든 기능이 두 인터페이스에서 비슷한 수준으로 동작해야 한다고 봤기 때문이다.

그런데 흥미로운 점은 두 인터페이스를 같이 만들다보니 꽤 묘한 지점이 보였다는 것이다. 같은 함수를 CLI 커맨드로 노출했을 때와 MCP 툴로 노출했을 때, 분명히 비슷할 줄 알았는데 실제로는 다르게 굴러갔다. 시그니처도 같고, 인자도 같고, 반환값도 같았고 심지어 메시지 포맷도 거의 같았다. 바뀐 건 호출자가 인간인지 LLM인지뿐이었는데 그 차이가 생각보다 컸다.

이번 포스팅에서는 필자가 느꼈던 그 어색함 이야기를 해보려 한다. 같은 함수를 CLI와 MCP 양쪽에 붙여보니 인터페이스 설계에서 필자가 너무 당연하게 받아들였던 전제가 하나 보였다. MCP가 RPC와 다른 이유는 단지 프로토콜이 새로워서가 아니었다. 우리가 함수 호출이라는 행위를 너무 오래 기본값처럼 써왔기 때문이었다.

함수 호출은 생각보다 친밀한 행위다

함수 호출에는 평소 잘 의식하지 않는 가정이 하나 깔려 있다. 그건 바로 호출자와 호출 대상이 꽤 많은 맥락을 공유한다는 가정이다.

예를 들어 우리가 addTransaction(ticker, quantity, price) 같은 함수를 호출할 때를 생각해보면 쉽다. 우리는 함수의 시그니처만 보더라도 이 함수가 무슨 일을 하는지 어느 정도 알고 있다. 작성자가 왜 이런 시그니처를 잡았는지, 어떤 부작용이 있을지, 어떤 예외가 나올지를 아주 완벽하게는 아니어도 대체로 알고 있다고 믿는다. 그런 이해 없이 호출하는 건 함수 호출이라기보다 추측에 가깝다.

지난 몇십 년간의 도구들은 이런 친밀함을 더 강화하는 방향으로 발전해 왔다. 정적 타입 시스템은 인자 형식을 잘못 알았을 때 컴파일 단계에서 막아주고, IDE 자동완성은 잊고 있던 시그니처를 다시 꺼내준다. JSDoc과 docstring은 작성자의 의도를 텍스트로 보충한다. RPC, gRPC, GraphQL이 스키마를 점점 더 엄격하게 다뤄온 것도 같은 흐름 안에 있다. 호출자가 호출 대상을 더 많이 알수록 좋은 호출이 나온다는 가정이다.

필자도 이 전제 위에서 트랜잭션을 등록하는 CLI 커맨드를 만들었다. 사용자가 firma add txn을 입력하면 인터랙티브 프롬프트가 ticker를 묻고, type을 묻고, shares와 price를 차례로 묻는다.

// CLI에서는 이 시그니처만으로도 충분했다
function addTransaction(input: {
  ticker: string;
  type: "buy" | "sell" | "deposit" | "dividend" | "tax";
  shares: number;
  price: number;
  date: string;
}): Promise<Transaction>

여기서 사용자는 이미 자기가 뭘 하려는지 안다. CLI는 그 의도를 잘 입력받아 함수에 넘기기만 하면 된다. 그래서 함수 이름과 인자 타입만으로도 꽤 많은 것이 해결된다. 그동안 필자는 이걸 너무 자연스럽게 받아들여서, 이게 가정이라는 사실조차 잘 못 보고 있었다. MCP 툴로 같은 함수를 노출해보기 전까지는 그랬다.

시그니처가 말하지 않는 것

하지만 같은 함수를 MCP 툴로 노출하는 순간 함수의 호출자는 인간에서 LLM으로 바뀐다. 그리고 그때부터 시그니처가 말하지 않던 것들이 갑자기 문제로 튀어나왔다.

필자: "나 어제 AAPL 15주 샀당"
LLM: 네, add_balance 함수를 호출할게요.

갑자기 왜 급발진해...?

필자가 만든 Firma에는 트랜잭션을 등록하는 add_txn 말고도 월말 자산 스냅샷을 기록하는 add_balance, 월별 소득과 지출을 기록하는 add_flow가 있다.

당연히 시그니처는 다 명확하며 인자 타입도 zod 스키마로 엄격하게 정의해뒀다. 그래도 LLM은 어느 도구를 불러야 하는지 자주 헷갈렸다. 같은 발화로 몇 번 돌려보면 엉뚱한 도구를 부를 때가 꽤 있었다.

처음에는 그냥 LLM 모델이 구려서인가 싶었다. 그런데 한참 보고 있으면 문제가 다른 데 있다는 게 보인다. 시그니처는 함수가 무엇을 받는지는 잘 설명한다. 대신 언제 불려야 하는지는 거의 설명하지 못한다. add_txn이라는 이름은 식별자일 뿐이고, “사용자가 매매를 말했다면 이 도구를 써라” 같은 호출 시점은 담고 있지 않다.

함수의 이름은 사전의 한 줄에 가깝다. 단어 자체로는 어떤 문장 안에 놓일지 결정하지 못하는 것처럼 시그니처 자체로는 어떤 발화 위에서 호출되어야 할지 결정하지 못한다.

CLI에서는 그게 큰 문제가 아니었다. 함수 호출자가 인간이었고, 인간은 이미 “지금 내가 트랜잭션을 기록하려는 중이다”라는 맥락을 갖고 firma add txn을 입력하기 때문이다. 호출 시점을 고르는 책임이 호출자 머릿속에 있었다.

LLM은 다르다. LLM에게 사용자의 발화는 이미 정리된 명령이 아니라, 의도를 추론해야 하는 재료에 가깝다. “샀어”라는 한 단어만 보고 이것이 매수 트랜잭션인지, 재무상태 변화인지, 새로운 현금 흐름인지 결정해야 한다. 그때 LLM이 붙잡을 수 있는 건 도구가 스스로를 어떻게 설명하느냐다.

필자가 add_txn의 설명을 다시 쓴 뒤에야 호출이 꽤 안정됐다. 실제 운영 환경 문구에는 운영 디테일이 더 길게 따라붙지만, 이 글에서는 변화의 골자만 추려서 옮긴다.

server.tool(
  "add_txn",
  `Records a single trade on a specific ticker: buy, sell, dividend received, or tax paid.
   Use this when the user mentions buying or selling stocks, receiving dividends, or paying taxes on a specific security.
   Do NOT use this for general cash deposits, salary, or expenses. Use add_flow for those.
   Do NOT use this for monthly asset snapshots. Use add_balance for those.`,
  schema,
  handler
)

여기서 중요한 건 함수의 의도가 시그니처에서 함수의 설명 쪽으로 이동했다는 점이다. 시그니처는 여전히 인자의 형식을 강제한다. 그런데 호출의 의미는 설명이 훨씬 더 많이 결정한다. 어디에 의도를 새겨 넣어야 하는지가 바뀐 셈이다.

왜 이런 이동이 생기는 이유는 호출자가 맥락을 모르기 때문이다. 그런데 가만히 생각해 보면, 호출자가 맥락을 모른다는 게 그렇게 이상한 일인가 싶었다.

도구는 원래 만든 사람을 떠나서 살아간다

예를 들어 망치를 한번 떠올려보자. 망치라는 도구를 만든 사람은 분명히 자기 나름의 의도를 가지고 있다. 어느 정도 무게가 적당한지, 손잡이 길이는 얼마나 되어야 하는지, 무게 배분은 어떻게 해줘야 하는지 같은 판단 말이다. 그런데 그 망치를 나중에 쥐는 사람은 그런 배경을 모른다. 손잡이 곡선이 왜 그렇게 생겼는지, 무게 중심이 왜 거기에 있는지 알지 못해도 된다. 그에게 필요한 건 못을 박고 싶다는 의도 하나뿐이다.

그 정도면 충분하다. 사람은 망치를 보는 순간 대충 감을 잡는다. 어디를 잡아야 할지, 어떤 쪽으로 내려쳐야 할지, 이 도구가 어떤 종류의 일에 맞는지를 형태에서 읽어낸다. 도구는 그렇게 만든 사람을 떠나 제 나름대로 살아간다. 사용자는 만든 사람의 머릿속을 몰라도 된다. 대신 도구의 형태를 보고, 이게 자신의 의도와 맞을지 짐작한다. 사실 우리가 도구를 쓰는 대부분의 장면이 그렇다.

망치를 어떻게 쓸지는 망치를 쓰는 주체가 정하는 것이다

이건 제법 흥미로운 지점이다. 망치를 쥔 사람이 못을 박을지 벽을 부술지를 정하는 건 만든 사람이 아니라 쓰는 사람이다. (벽이 아니라 사람을 부술수도 있다…)

대장장이는 자기 머릿속에 명확한 용도를 두고 망치를 만들었겠지만, 그 망치가 실제로 어디에 휘둘려질지는 결국 망치를 쥔 손이 정한다. 도구는 만든 사람을 떠나서 살아갈 뿐 아니라, 만든 사람의 의도까지 넘어서며 살아간다.

도널드 노먼이 말한 어포던스라는 개념도 결국 이 지점을 가리킨다. 어포던스는 원래 심리학자 제임스 깁슨이 만든 개념으로, 사물이 사용자에게 어떤 행위를 가능하게 하는지를 뜻한다. 의자는 앉을 수 있게 하고, 컵은 쥘 수 있게 하고, 손잡이는 돌릴 수 있게 한다. 노먼은 이 개념을 디자인의 언어로 끌어와서 “사물의 형태가 사용 방법을 스스로 시사하는 성질”로 좁혀 썼다.

잘 설계된 문 손잡이는 “여기를 잡고 당기세요”라고 길게 설명하지 않아도 된다. 형태만으로도 어떻게 사용해야할지 표현할 수 있어야하는 것이다. 반대로 어포던스가 어긋난 도구는 사용자를 매번 헷갈리게 만든다.

노먼은 밀어야 열리는 문에 당기는 형태의 손잡이가 달린 사례를 자주 드는데, 이런 어긋난 문이 워낙 흔해서 디자인 업계에서는 아예 노먼 도어(Norman door)라는 별명이 붙었다. 손잡이는 “잡고 당기라”고 말하는데 실제 동작은 “밀어야” 한다. 형태가 거짓말을 하는 도구는 사용자에게 끊임없이 인지 부하를 떠넘긴다.

망치도 마찬가지다. 손잡이의 곡선과 두꺼운 머리는 “여기를 잡고 저쪽으로 휘둘러라”를 거의 무의식 수준에서 전달한다. 좋은 도구는 사용법을 문서보다 먼저 형태로 암시한다.

그 관점에서 보면 MCP 함수의 설명은 그냥 문서가 아니다. LLM에게는 사실상 도구의 형태에 가깝다. 망치 손잡이가 “여기를 잡으라”고 말하듯, 함수의 설명은 “이런 의도일 때 나를 불러라”고 말한다. 설명이 빈약한 도구는 손잡이가 어색한 망치와 비슷하다. 있기는 한데, 막상 손이 잘 가지 않는다.

이걸 체감한 건 필자가 read 계열 도구를 설계할 때였다. 처음에는 단일 책임 원칙을 따라 도구를 잘게 나누고 싶었다. get_holdings, get_prices, get_pnl, calculate_value처럼 역할이 뚜렷한 도구들이다. 함수 관점에서는 꽤 깔끔한 설계다.

그런데 사용자가 “내 포트폴리오 어때?”라고 묻는 상황을 놓고 보면 그림이 좀 달라진다. LLM은 그 질문에 답하려고 네다섯 번의 호출을 조합해야 한다. 호출 하나하나는 맞을지 몰라도 전체 응답은 느려지고, 중간에 어긋날 여지도 커진다. 사용자가 한 번의 의도로 묻는 질문에 너무 많은 작은 도구를 들이밀게 된다.

실제로 필자가 초반에 설계한 MCP를 보면 여러가지 도구를 한번에 불러오는 모습이었다

그래서 필자는 최종적으로 show_portfolio를 조금 무거운 도구로 잡았다. 보유 종목, 평균 매수가, 현재 가격, 평가금액, 누적 손익을 한 번에 반환한다. get_brief는 더 나아가 보유 종목, 일일 손익, 집중도, 급등락 종목, 뉴스, 실적, 거시 지표, 인사이트까지 한 번에 돌려준다. RPC만 놓고 보면 지나치게 뭉친 설계처럼 보일 수 있다.

그런데 도구의 관점에서는 오히려 이쪽이 자연스럽다. SRP는 함수를 만드는 사람에게 중요한 원칙이다. 어포던스는 도구를 쓰는 사람에게 중요한 원칙이다. 호출자가 인간이면 작은 단위를 조립해도 된다. 호출자가 LLM이면 의도에 더 직접 닿는 도구가 낫다. 어느 쪽이 더 좋은지는 절대적인 문제가 아니라, 누가 호출자인가에 따라 달라진다.

신뢰의 방향도 바뀐다

사실 MCP는 형태만 놓고 보면 RPC 계보 안에 있는 프로토콜이다. 메시지는 JSON-RPC 형식을 쓰고, 시그니처와 인자 스키마 같은 어휘도 RPC 시절의 것을 그대로 가져왔다. 그래서 필자도 처음에는 RPC와 MCP가 결국 비슷한 결로 굴러갈 거라고 짐작했다.

그런데 두 프로토콜을 들여다볼수록 결정적으로 갈라지는 지점이 따로 있었다. 시그니처에서 설명으로 무게중심이 옮겨가는 것에 더해, 신뢰의 방향까지 같이 뒤집힌다는 점이다.

RPC에서는 보통 호출자가 호출 대상을 신뢰한다. 예를 들어 시그니처가 Promise<Transaction>을 반환한다고 적혀 있으면, 호출자는 당연히 그 약속을 믿고 코드를 짠다. 호출 대상은 호출자가 어떻게 호출할지까지 굳이 신뢰하지 않아도 된다. 타입 시스템과 스키마가 형식을 강제해주기 때문이다. 잘못 부르면 컴파일이 깨지거나 런타임 에러가 난다.

MCP에서는 이야기가 조금 다르다. 도구를 만든 쪽이 호출자를 어느 정도 신뢰해야 한다. LLM이 함수의 설명을 제대로 읽고, 적절한 시점에, 적절한 인자로 도구를 부를 것이라고 기대해야 한다. 시그니처가 막아주는 건 인자의 형식까지다. 호출 타이밍과 의미는 여전히 추론의 영역에 남아 있다.

이 차이는 쓰기 도구에서 더 뚜렷하게 드러난다. Firma의 add_txn은 SQLite 데이터베이스에 실제로 기록하는 도구다. 이게 잘못 호출되어버리면 자산 기록이 바로 오염되기 때문에, 처음에는 필자도 무서워서 설명에 이렇게 적었다.

"Records a transaction. Always confirm with the user before recording."

결과는 썩 좋지 않았다. LLM은 매번 “이렇게 기록할까요?”라고 물었고, 그리고 필자는 매번 “ㅇㅋ”라고 답했다. 자연어 인터페이스의 장점이 거의 사라진 것이다. 책임을 너무 많이 사용자 쪽으로 밀어버리면 도구가 갑자기 굼떠진다. 망치를 들 때마다 “정말 이 못을 박을까요?”라고 묻는 셈이다.

그래서 결국 필자는 설명을 아래와 같이 다시 작성했다.

"Record the transaction immediately when the user clearly states a trade.
 Do not ask for confirmation unless the data is ambiguous (missing date, etc).
 If you record incorrectly, the user can run delete_txn to undo."

“즉시 기록하라”, “모호할 때만 물어라”, “잘못되면 되돌릴 수 있다” 같은 규칙은 도구를 형식적으로 설명하는 수준이 아니라 호출자에게 주는 운영 원칙에 가깝다. 그리고 이 지침이 먹히려면 결국 LLM이 어느 정도 추론할 것이라는 기대가 필요하다.

함수에는 부탁하지 않는다. 타입으로 강제한다. 반대로 추론하는 호출자에게는 어느 정도 부탁할 수밖에 없다. MCP 함수의 설명이 점점 행동 정책처럼 길어지는 이유도 여기에 있다고 생각한다.

어찌 보면 시그니처는 선언이고 설명은 부탁이다. 시그니처는 “이 함수는 이런 인자를 받는다”고 못 박는다. 반면 설명은 “이런 의도일 때 나를 불러주세요”라고 청한다. 한쪽은 강제이고 한쪽은 설득이다. 도구 설계에 설득의 언어가 들어오기 시작한 셈이다.

함수 호출이 오히려 특수한 경우였는지도 모른다

이쯤에서 처음 질문으로 돌아가보면, 호출자가 함수의 맥락을 모른다는 건 사실 그리 이상한 일이 아니다.

인간은 원래 자기가 만들지 않은 도구를 써왔다. 도공이 만든 그릇, 대장장이가 만든 칼, 목수가 만든 의자 모두 그렇다. 심지어 개발자가 만든 프로그램도 그렇다. 사용자가 항상 내가 원하는 대로 프로그램을 사용할 것이라고 기대하는 것은 항상 예측을 빗나간다.

이처럼 도구는 만든 사람을 떠나 다른 손으로 넘어가기 때문에 사용자는 만든 사람의 머릿속을 모른다. 그래서 도구의 형태를 보고 쓰는 것이 더 일반적인 장면인 것이다.

그렇다면 우리가 너무 오래 기본값처럼 여겨온 함수 호출은 오히려 꽤 특수한 관계였던 셈이다. 호출자와 작성자가 많은 맥락을 공유하고, 그 친밀함을 타입 시스템과 IDE와 문서가 계속 보강해주는 관계 말이다. 함수 호출이 원래부터 보편적인 도구 사용 방식이었다기보다, 유난히 친밀한 한 형태였다고 보는 편이 더 자연스러울지 모른다.

이제 호출자가 인간이 아니라면 선택지는 두 가지다. 하나는 LLM에게 더 많은 맥락을 집어넣어서 최대한 친밀한 호출자로 만드는 방법이다. 다른 하나는 도구 쪽에서 거리를 메우는 방법이다. 자기 사용 의도를 함수 설명에 새기고, 호출자가 모든 맥락을 알지 못해도 쓸 수 있게 만드는 방식이다.

MCP는 후자에 더 가깝다. 이건 꽤 자연스러운 선택처럼 느껴진다. 전자의 길은 결국 호출자를 계속 더 많이 아는 존재로 만들어야 한다. 반면 후자의 길은 호출자가 원래 다 알 수는 없다는 사실을 받아들인다. 그리고 그 간극을 도구 설계로 메운다. 돌아보면 인간이 도구를 만들어온 방식도 늘 그쪽에 가까웠다.

이건 어쩌면 회귀에 더 가깝다. 산업 디자인도, 건축도, UX도 이미 오래전부터 같은 자리에 서 있었다. 프로그래밍이 그동안 유난히 친밀한 한쪽 끝에 머물러 있었던 것뿐이다.

마치며

필자가 이번 주말에 Firma를 만들면서 가장 오래 붙잡고 있던 건 코드가 아니었다. 함수의 설명이었다. CLI 커맨드 30여 개와 MCP 도구 50여 개를 짰는데, 그 분량이 무색할 정도로 시간을 잡아먹은 건 결국 이 도구들이 스스로를 어떻게 설명할 것인가였다.

도구는 만들어지는 순간 만든 사람을 떠난다. 그 떠남을 전제로 설계해야 한다. 호출자가 모든 맥락을 알 거라고 기대하기보다, 도구 쪽에서 자신의 의도를 더 많이 드러내야 한다. MCP를 만지면서 흥미로웠던 건 새로운 프로토콜을 배운다는 느낌보다, 오히려 도구가 원래 어떤 식으로 쓰여왔는지를 다시 떠올리게 된다는 점이었다.

함수 호출의 시대가 끝난다고 말하고 싶은 건 아니다. 다만 함수 호출이 늘 보편적인 기본값이었다기보다, 꽤 친밀한 환경에서만 잘 작동하던 한 형태였다는 사실은 이제 더 또렷하게 보인다. 그리고 그 친밀함 바깥에서 인터페이스를 다시 설계하는 일은 생각보다 재미있다.

어쩌면 우리는 인터페이스를 설계하는 방식 자체가 조용히 바뀌고 있는 시기를 지나고 있는 게 아닐까. 시그니처에서 설명으로, 강제에서 설득으로, 친밀함의 가정에서 거리에 대한 인정으로 무게중심이 옮겨가고 있다. 도구를 만든다는 일이 다시 한 번 그 본래의 모습으로 돌아가는 길목에 서 있는 것인지도 모르겠다.

Developers Who Stopped Growing

Sat, 18 Apr 2026 11:29:24 GMT

The more you use AI, the harder it becomes to use AI well. That may sound counterintuitive, but I believe it’s true.

Everyone seems to be caught up in AI FOMO these days, working hard to get better at using AI. But before we get there, we need to ask what it actually means to “use AI well.”

Methodologies like agent orchestration or harness engineering are really just the tide — as tools improve, everyone catches up eventually. The real differentiator lies elsewhere. I think it’s the ability to judge whether AI’s output is good or bad, correct it when it goes in the wrong direction, and draw out better results. And ironically, that ability weakens the more we lean on AI.

There’s a saying: “Working for 10 years doesn’t give you 10 years of experience if you’re just repeating the same 1 year of experience 10 times.” It describes someone whose years stack up while their skills stay flat — where a 10-year developer and a 3-year developer are barely distinguishable in judgment.

This phenomenon existed long before AI arrived. But now that AI can take over the pain of writing code, falling into that loop of repeating the same one year of experience for a decade has become incomparably easier than before.

This AI dependency is a new version of an old problem: the developer who stops growing.

In a previous post, Only When the Tide Goes Out Do You See Who’s Been Swimming Naked, I argued that the core competencies required of developers won’t change much in the AI era.

In this post, I want to ask a more fundamental question: why does depending on AI actually make it harder to use AI well? And what does neuroscience have to say about this?

The Paradox: You Need to Know Code to Use AI Well

What does it look like in practice to judge the quality of AI’s output? Plenty of people can already tell AI “build me this.”

But far fewer can look at what AI produced and say specifically: “this structure is brittle to change,” “this interface has two responsibilities,” “this level of abstraction doesn’t fit the current complexity of the project.” And the ability to make those specific critiques and corrections is exactly what separates using AI well from being dragged along by it.

That ability comes from a sense of what “good code” looks like. The feeling a seasoned developer gets when looking at code — that vague “something feels off” — is formed through countless failures, debugging sessions, and refactors. It isn’t the kind of thing you can acquire purely through theory. It’s closer to intuition. This intuition only develops when a developer has personally suffered through bad structure, personally built good abstractions, and developed a feel for “this level is about right.”

This isn’t just about “humans still need to read code,” as I mentioned in the previous post. Even from the pure goal of using AI effectively, deep understanding of code is a non-negotiable prerequisite. Learning to use AI and learning code patterns aren’t competing alternatives — the latter is the foundation of the former. No matter how easy AI’s interface becomes, AI cannot grow your eye for judging the quality of its output.

To put it in one sentence: the developer who can best leverage AI is the developer who can evaluate code without AI. And if you only rely on AI, that evaluative judgment never develops.

Neuroscience shows this isn’t just intuition.

The Brain Doesn’t Remember What Comes Easy

To say you’ve truly “learned” something, it must be stored in long-term memory. If you understand it momentarily and forget it days later, that’s closer to consumption than learning.

Developers have probably had this experience: you read about a design pattern in a blog post, feel like you understood it completely — then a week later, when you run into a similar problem, you can’t remember a thing. Meanwhile, a pattern you struggled through and implemented yourself in a project stays vividly with you months later. This difference isn’t just individual variation; it stems from how the brain stores memories.

The process of forming long-term memory is a bit at odds with our intuition. Things we processed with difficulty and struggle tend to stick better than things we understood easily and smoothly.

UCLA cognitive psychologist Robert Bjork explained this with the concept of “desirable difficulties.” Bjork argued that when learning involves an appropriate level of challenge and resistance, short-term performance slows down — but long-term retention and transfer actually improve.

One of the key mechanisms Bjork identified is retrieval practice. Practicing actively recalling something is far more effective for long-term memory formation than re-reading the same material.

Roediger and Karpicke’s 2006 study shows this quantitatively.

The experiment split students into two groups. One group repeatedly read the same material; the other read it and then practiced recalling the content themselves. Five minutes after the test, the re-reading group scored higher. But when retested a week later, the retrieval practice group’s retention was about 50% higher.

What does this tell us? Passively receiving information and actively retrieving it may look similar in the short term, but they produce entirely different effects over time.

This difference is also confirmed at the level of brain activation. The group that actively recalled what they learned showed strengthened connectivity between the hippocampus and prefrontal cortex, and increased activation in the sensorimotor network and insular cortex.

The hippocampus is the key region for forming new memories, and the prefrontal cortex handles higher-order thinking and decision-making. When both regions activate simultaneously and communicate closely, it means the brain isn’t just storing information — it’s weaving it together with context.

The group that passively listened to lectures, by contrast, showed primarily activation of the connection between the hippocampus and the fusiform gyrus. The fusiform gyrus handles visual processing, particularly pattern recognition. In other words, a brain in passive learning mode is essentially watching information rather than processing it.

Put simply: the harder your brain works to take in and process something, the more durably it gets stored. Information received effortlessly disappears just as effortlessly.

One caveat: this doesn’t mean “harder is always better.” What Bjork emphasizes is desirable difficulty — challenges that are within reach of your current abilities. Too easy and there’s not enough load for it to stick; too hard and you’re just left with frustration. The most effective learning comes from solving appropriately difficult problems under your own power. Remember this point — we’ll come back to it when we talk about how to use AI.

The Generation Effect and the Illusion of Fluency

The “generation effect” from Slamecka and Graf’s classic 1978 study deserves mention here too. Participants were split into two groups. One group was shown complete word pairs — for example, “hot–cold” — as-is. The other group was given a prompt like “hot–co___” and had to complete the word themselves. The difference was just filling in a few letters, yet the results were quite different: the group that filled in those letters themselves showed meaningfully higher retention.

The neuroscience behind this difference makes it more interesting. When you generate information yourself, the brain’s semantic processing regions, retrieval pathways, and executive control areas all activate simultaneously. The more brain regions involved at once, the richer the memory encoding, and the more pathways available later for retrieval. Passively reading completed information, by contrast, mainly activates recognition networks — so the encoding is comparatively shallow.

There’s a trap to watch out for here: what cognitive psychology calls the “illusion of fluency.” The feeling that you can process information easily leads to the mistaken belief that you’ll remember it well.

Reading a well-written, clear piece feels like understanding — but actual retention isn’t as high as that feeling suggests. The re-reading group in Bjork’s study scoring better right after is the same phenomenon: feels like mastery in the moment, but it doesn’t last.

How the Ability to Judge Code Gets Built

The desirable difficulties and generation effect described above are general learning principles. To understand how they specifically operate in coding, we first need to look at what form coding judgment takes in the brain.

A significant part of what we call coding skill is procedural memory — memory of “how to do something.” Like riding a bike, playing an instrument, or typing: once embodied, it executes automatically without conscious recall.

In coding, procedural memory shows up as: the solution pattern that naturally surfaces when you see a certain type of problem; the gut feeling that “something’s off here” when reading code; the instinctive sense of where to draw the boundary when structuring a design; the eye that spots in an instant where refactoring is needed.

These are a completely different type of memory from the explicit knowledge you get from reading a textbook. Knowing how to list the SOLID principles and being able to detect a Single Responsibility violation the moment you see code — these are different types of knowledge handled by different brain regions.

Three Stages of Procedural Memory Formation

Anderson’s Adaptive Control of Thought model describes procedural memory formation in three stages.

The first is the cognitive stage. Everything is executed consciously, step by step. Think back to when you first learned to code — how you had to think through each part of a for loop: initial value, condition, increment. At this stage, a significant portion of working memory is consumed by this process.

The second is the associative stage. Individual procedures start to integrate. You can execute the for loop, array access, and conditional branching as a single flow. Mistakes decrease and recognition speeds up.

The third is the autonomous stage. Many things execute automatically, consuming almost no working memory. Just as a seasoned developer writing filtering logic doesn’t consciously think about for loop syntax, the pattern itself is auto-recognized as a single unit. A developer who reaches this stage doesn’t spend working memory on syntax or basic patterns — freeing that capacity for design judgment and structural thinking.

The critical point is that these stages only progress through repeated practice. Moving from the cognitive to the associative stage requires personally putting load on the brain by solving the same types of problems repeatedly. Moving from the associative to the autonomous stage requires even more repetition.

The brain’s basal ganglia and cerebellum play key roles in this process. The basal ganglia handles habit formation and procedural learning; the cerebellum aids in the refinement and automation of action.

Through repeated practice, the synaptic connections in these regions are continuously strengthened — a process called long-term potentiation. As these connections strengthen, execution of a given procedure becomes faster and more accurate, eventually happening automatically without conscious effort.

When this process advances far enough, neural efficiency emerges. An expert’s brain activates fewer regions to perform the same task than a novice’s — one of the most consistently confirmed findings in neuroscience research. Doing less while producing better results: that’s roughly the neurological reality behind the abstract concept we call intuition.

So the ability to make quick, sound judgments without conscious reasoning is the product of enormous repetition and struggle — and there are no shortcuts in this process.

This is similar to physical training. To build strength, an athlete has to load the muscle. Lift something appropriately heavy — not too light, not too heavy — and the muscle undergoes micro-damage and grows, until heavier weights become possible. The brain works the same way. Growth happens when you wrestle directly with the edges of your current ability.

Experts Can Pack More into a Single Chunk

Chunking is another essential concept when explaining expertise in neuroscience.

Human working memory is limited to about 3–4 chunks — and that limit is the same for novices and experts. The number of working memory slots can’t be expanded through training.

So where does the difference between an expert and a novice come from? The answer is that the amount of information that can fit in a single chunk differs.

Chase and Simon’s study of chess experts demonstrates this. Researchers showed master and novice chess players a plausible mid-game board position for 5 seconds, then had them recreate it from memory. Masters reconstructed far more piece positions accurately. That much could be explained by “better memory.”

But the decisive contrast experiment came when pieces were placed randomly: the difference in reconstruction ability between masters and novices nearly disappeared. What masters had memorized wasn’t individual piece positions — it was meaningful patterns. Recognizing something like “a typical Sicilian Defense middle-game setup” as a single chunk allowed the same 3–4 working memory slots to hold vastly more information.

The Sicilian Defense is a famous counter-opening responding to White's aggressive opening

The same mechanism operates in coding. A skilled developer doesn’t process a for loop, array access, and conditional branch as separate pieces of information. They compress it into a single chunk: “filtering pattern.” They see try-catch, error type branching, and logging as a single chunk: “error handling pattern.”

So when looking at the same code, there’s more working memory left over — and that surplus can go toward higher-level judgments: “Is this function’s scope of responsibility too wide?” “Is this dependency direction right?” These structural questions can receive cognitive resources.

How are these chunks formed? By writing code yourself, debugging, refactoring — repeatedly encountering the same patterns until the brain starts grouping them into a single unit. Recent research has confirmed that the prefrontal cortex and basal ganglia circuitry work together in this process.

Knowing a pattern and having a pattern embodied are different things. The former is explicit memory; the latter is procedural memory. You need the latter to quickly catch structural problems in a code review.

The difference between the two shows up starkly in real work. Someone who can answer “why does useEffect need a cleanup function?” with textbook perfection might still miss the problem when they see a component like this in a code review:

function useNotificationCount({ userId }: { userId: string }) {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(async () => {
      const notifications = await fetchNotifications(userId);
      setCount(notifications.unread);
    }, 5000);
  }, []);

  return count;
}

There are two problems here. Without clearInterval, the interval keeps running after the component unmounts. And with userId missing from the dependency array, the component keeps polling the previous user’s notifications even after userId changes.

They know as explicit knowledge that “useEffect should return a cleanup function and the dependency array must be filled correctly” — but the procedural memory that makes you reflexively sense “interval isn’t being cleaned up here” and “userId isn’t in deps” when you look at the code hasn’t formed. That intuition only develops in someone who has personally encountered a stale closure bug, debugged an interval still alive after unmount, and traced the cause.

To be clear, most studies cited here were conducted in general learning contexts, not coding specifically. There are limits to directly applying these findings to coding as a specialized cognitive activity. But desirable difficulties, the generation effect, and the principles of procedural memory formation are closer to general features of human cognition than domain-specific rules — and there’s currently no basis to treat coding as an exception.

AI Interferes with This Process

When you hand implementation to AI, you skip the process of personally thinking through and writing code. What variable to name it, what order to unpack this logic, how to define this function’s interface, where to handle errors. These small but recurring judgment calls are actually the core process of internalizing code patterns — and the moment AI takes over that process, the cognitive load on your brain drops sharply.

AI Takes Over the Essential Load Too

Reduced cognitive load isn’t inherently bad. According to cognitive load theory, what matters in learning is the type of load. Sweller divided cognitive load into three kinds: intrinsic load from the complexity of the task itself; extraneous load from poor learning design; and germane load, which directly supports schema building.

If what AI reduces is extraneous load — writing boilerplate, correcting syntax errors — it can actually help learning. But if AI also reduces germane load, the opportunity for the brain to build schemas disappears entirely.

The problem is that in practice, it’s hard to cleanly separate these two types of load. When you tell AI “implement this function,” AI doesn’t just write the boilerplate — it makes the design decisions for the core logic too: what data structure to use, what order to process things in, how to handle error cases. These judgments are exactly what constitutes germane load. Delegate all of this to AI and almost nothing is left for the brain.

From the procedural memory perspective: when AI handles implementation, less time is spent struggling through code directly in the cognitive stage — so the transition to the associative stage is delayed, and reaching the autonomous stage becomes harder.

The same applies to chunking. Without personally constructing and combining patterns, you can recognize individual patterns in the completed code you read, but you lack the experience of compressing them into your own chunks. It’s like reading chess theory books without ever playing a real game.

For junior developers in particular, this can be severe. When many patterns are still in the cognitive stage and AI lets you skip that stage entirely, you may be turning out results quickly on the surface while nothing in the way of procedural memory is forming inside.

AI writing code for you is close to the generation effect experiment’s condition of reading a completed word pair. The code is right in front of you, so it feels like you understood it. You can nod along, following the logic: “oh, so that’s how you do it.”

But because you didn’t generate it yourself, it doesn’t get deeply imprinted in memory. Next time you encounter a similar problem, you’re likely to hit “I know I’ve seen this somewhere but can’t remember” — the illusion of fluency at work again.

Of course, reading AI-generated code isn’t entirely passive. Parsing the intent and tracing the execution flow does require some cognitive effort.

But research has confirmed that the level of brain activation when reading code decreases as developers become more skilled — the phenomenon called neural efficiency, which means experts process code faster with fewer cognitive resources. Processing efficiently also means that much less cognitive load.

In other words, a skilled developer reading AI output doesn’t put nearly as much load on the brain as you might think.

And for a novice developer: even if reading code does generate load, that load is spent on understanding the code, which is qualitatively different from the load generated in the process of producing it. Reading alone may simply not generate enough load to embody a new pattern.

Some readers might wonder whether deeply analyzing and reviewing AI-generated code is sufficient learning on its own. There’s something to that.

But there’s a trap: what neuroscience identifies as the core of learning — prediction and feedback — is missing. When you write code yourself, you’re constantly predicting what comes next, receiving feedback on whether it works, and modifying synapses accordingly. Reading already-completed AI code, by contrast, is post-hoc interpretation with the prediction step removed.

It’s like solving a math problem with the answer key open beside you. You can follow the solution and understand it, but in an actual exam facing a blank page, the pen doesn’t move — because the circuit for recognition and the circuit for retrieval are different. The total accumulated pain of having decided the details yourself determines the density of the chunk.

The Friction Keeping You on the Growth Path Is Gone

Let’s step back and look at the bigger picture. The problem of stopped growth existed before AI. Let’s examine what “repeating one year of experience 10 times” actually looks like in practice.

The developer who only copies and pastes answers from Stack Overflow. The developer who knows their framework’s API but doesn’t know what’s happening underneath. The developer who’s been writing the same CRUD code for five years and only accumulating seniority. What these people have in common is that they didn’t put sufficient load on their brains.

When copied Stack Overflow code runs, they stop there. They don’t ask why it works, whether there was another approach, or what tradeoffs this pattern carries. Working only above the abstractions a framework provides means the chunks for the underlying mechanisms never form. Repeating the same code patterns does lead to the autonomous stage — but when the range of patterns you’ve automated is narrow, you’re helpless in front of a new problem.

The mechanism operating in all these cases is the same: avoid cognitive load, procedural memory doesn’t form, chunks don’t get built, growth stops. The path to stopped growth was already wide open before AI.

But AI has dramatically reduced the friction on that path. In the Stack Overflow era, you still had to search, compare multiple answers, and adapt them to your situation. That process imposed at least minimal cognitive load. Even relying on a framework, you had time to read the docs and work through examples.

AI, given the context, produces complete code immediately. No searching, no comparing, no adapting. The distance to “working code” has become nearly zero.

From a productivity perspective, this is a revolution. But from a learning perspective, it means fewer opportunities for the brain to be loaded. Before AI, even choosing the “easy path” involved some friction. AI has eliminated even that friction. Sliding into the path of stopped growth is now far easier than before.

This problem doesn’t spare you just because you’re senior. The shape of it is different, that’s all. It’s worse for junior developers, who haven’t yet formed sufficient procedural memory — AI letting you skip that formation process means building career years on top of a foundation of weak fundamentals.

It’s like asking someone still learning to drive to evaluate the decisions of a self-driving car. Someone who has never held the steering wheel will struggle to detect a self-driving mistake.

But seniors aren’t off the hook either. Technology keeps changing, and every time a new language, framework, or paradigm appears, you encounter new patterns your existing chunks can’t handle.

To embody these new patterns, you have to start again from the cognitive stage. Being senior doesn’t exempt you from that. Everyone is a beginner when learning something new.

The advantage of a senior is being able to form new chunks faster by connecting them to existing abstractions — “this is similar to the middleware pattern on the backend.” But even that connection is discovered by actually getting hands-on with the code, not automatically discovered by reading AI output.

Regardless of seniority, you need time to personally think through problems and touch code in the AI era. So how do you create that time while still using AI?

How to Load the Brain

The core principle for growth comes down to one thing: you have to load the brain.

Drafting your own design before handing anything to AI is an intentional application of the generation effect. Because you’ve already formed your own answer, you’re not passively consuming AI output — you’re comparing and evaluating. In the process of judging “what’s different from my design,” “is AI’s choice better or is mine,” the brain’s semantic processing and executive control regions activate simultaneously. The same mechanism shown in generation effect research.

Taking code review seriously works the same way. Waving it through with “it works, so pass” puts almost no load on the brain. But the moment you consciously ask “why this structure?” or “if we had to modify this code six months from now, where would the problem be?”, the brain starts actively using working memory. That it’s annoying and time-consuming is exactly the point — that annoyance is what Bjork called desirable difficulty.

Carving out time to actually write code yourself is irreplaceable from the perspective of procedural memory formation. As Anderson’s model shows, moving from the cognitive to the associative stage, and from the associative to the autonomous stage, requires repeated practice. Reading doesn’t trigger these transitions.

That’s why 30 minutes of struggling through code yourself leaves it more deeply ingrained in memory than code AI generated in 3 seconds. When you’re stuck and making no progress, asking AI for a hint is a valid strategy — but the key is getting only the minimum information, not the whole answer. Getting the answer handed to you versus working it out yourself from a hint puts entirely different loads on the brain.

This is precisely the point of desirable difficulty: too easy and no load is applied; too hard and only frustration remains. Use AI to lower the barrier to entry, while making the core judgment calls yourself — that’s how you maintain the right level of difficulty.

What all these practices have in common is that they’re all annoying. From a pure productivity standpoint, they’re inefficient. They feel like taking the long way around something AI could handle quickly.

Yes, it'll be annoying and stressful — but that kind of stress is necessary.
Great workout

The optimal strategies for production and learning are different. AI is an excellent tool for production, but limited as a tool for learning. And in the long run, what remains in the brain determines the quality of your code reviews, the accuracy of your design judgment, and — paradoxically — how well you can use AI.

When these exercises accumulate, they build an eye. An eye that, the moment it sees AI-generated code, senses what’s wrong and where a better choice could be made. That’s the concrete substance of the “ability to judge and correct output” I described at the start.

Pain Is Not a Choice — It’s a Condition

The concern in this post isn’t “AI is bad.” Developers whose growth stopped existed before AI, and they’ll exist without it.

The core point is a structural constraint built into how the brain works: avoid cognitive load, and growth stops. AI is simply a tool that has made that avoidance unprecedentedly easy.

I think this is a structural problem, not a matter of individual willpower. Without consciously designing a structure in which you can still grow while using AI, drifting toward the comfortable option is human nature.

The brain is fundamentally wired to conserve energy. If the same result can be achieved with less effort, the brain will naturally choose that. This isn’t weakness of will — it’s how the brain is built.

That’s why the real question shouldn’t be “to use AI or not” but “how do I load the brain while using AI?” There’s a vast difference between working comfortably and working only comfortably.

Pain is something we want to avoid — but from the perspective of growth, it’s less of a choice and more of a condition. No matter how far AI advances, this condition doesn’t change. Not as long as the way the brain works doesn’t change.

And in an era where those who use AI well survive, the paradox is that the power to do so comes from the ability to judge without AI.

더이상 성장하지 않는 개발자들

Sat, 18 Apr 2026 11:29:24 GMT

AI를 많이 쓸수록 AI를 잘 쓰기 어려워진다. 이건 마치 직관에 반하는 말처럼 들리지만, 필자는 이것이 사실이라고 생각한다.

요즘 너도 나도 AI FOMO에 빠져 열심히 AI를 잘 쓰기 위해 노력하고 있지만, 우리는 “AI를 잘 쓴다”는 것이 무엇인지부터 생각해볼 필요가 있다.

에이전트 오케스트레이션이나 하네스 엔지니어링 같은 방법론은 결국 도구가 발전하면 누구나 따라가게 되는 시대의 흐름이다. 하지만 진짜 차별점은 다른 데 있다. 필자는 이것이 바로 AI의 출력물이 좋은지 나쁜지를 판단하고, 잘못된 방향을 교정하고, 더 나은 결과를 끌어낼 수 있는 역량이라고 생각한다. 그리고 아이러니하게도 이 능력은 우리가 AI에 의존할수록 약화된다.

“10년을 일해도 1년짜리 경험을 10번 반복하는 것은 10년의 경험이 아니다”라는 말이 있다. 경력은 쌓이는데 실력은 제자리인 사람, 3년차와 10년차의 판단력 차이가 거의 없는 사람을 의미하는 말이다.

물론 이런 현상은 AI 등장 이전에도 있었지만 AI가 코드 작성의 고통을 대신해주는 시대가 도래하면서 10년 동안 1년짜리 경험을 반복하는 경로에 빠지기가 이전과는 비교할 수 없이 쉬워졌다.

이러한 AI 의존은 “성장이 멈추는 개발자”라는 오래된 문제의 새로운 버전이다.

필자는 일전에 작성했던 AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다라는 글에서도 AI 시대에도 개발자에게 요구되는 핵심 역량은 크게 달라지지 않을 것이라는 이야기를 한 적이 있다.

이번 포스팅에서는 그보다 앞단의 질문을 던져보려 한다. 왜 AI에 의존할수록 오히려 AI를 잘 쓰기 어려워지는지, 그리고 뇌과학은 이러한 현상에 대해 뭐라고 말하고 있는지에 대해서 알아보자.

AI를 잘 쓰려면 코드를 알아야 하는 역설

AI의 출력물의 퀄리티를 판단하는 판단력은 구체적으로 어떤 모습일까? 사실 AI에게 그저 “이걸 만들어줘”라고 말할 수 있는 사람은 이미 많다.

하지만 AI가 만든 결과물을 보고 “이 구조는 변경에 취약하다”, “이 인터페이스는 두 가지 책임을 가지고 있다”, “이 추상화 수준이 현재 프로젝트의 복잡도에 맞지 않는다”고 구체적으로 지적하고 교정할 수 있는 사람은 훨씬 적다. 그리고 바로 이 능력이 AI를 잘 활용하는 것과 AI에 끌려다니는 것을 가르는 차이이다.

그리고 이 능력은 “좋은 코드란 무엇인가”에 대한 감각에서 온다. 숙련된 개발자가 코드를 보고 “뭔가 이상한데”라고 느끼는 감각은 수많은 실패와 디버깅과 리팩토링의 경험에서 형성된 것이기 때문이다. 이것은 이론적으로 익혀서 얻을 수 있는 종류가 아니라 직감에 가깝다. 이러한 직감은 개발자가 수 많은 경험을 통해 직접 나쁜 구조에 고통받아봐야 생기고, 직접 좋은 추상화를 만들어봐야 “이 수준이 적절하다”는 감각이 생긴다.

이것은 단순히 이전 글에서 언급했던 “코드를 사람도 읽어야 하니까”라는 차원의 문제가 아니다. AI를 제대로 활용하려는 목적에서 봐도, 코드에 대한 깊은 이해는 대체 불가능한 전제 조건이다. AI 사용법을 학습하는 것과 코드 패턴을 학습하는 것은 양자택일의 관계가 아니라, 후자가 전자의 토대인 관계다. AI의 인터페이스가 아무리 쉬워져도, 그 출력물의 품질을 판단하는 눈은 AI가 대신 길러주지 않는다.

한 문장으로 요약하면 이렇다. AI를 가장 잘 활용할 수 있는 개발자는, AI 없이도 코드를 판단할 수 있는 개발자다. 그리고 AI에만 의존하면 바로 그 판단력이 형성되지 않는다.

그리고 이것이 단순한 직관이 아니라는 것을 뇌과학이 보여준다.

뇌는 편하면 기억하지 않는다

우리가 무언가를 “배웠다”고 말할 수 있으려면, 그것이 장기 기억에 저장되어야 한다. 단기적으로 이해했다가 며칠 뒤에 다 잊어버린다면 그건 학습이 아니라 소비에 가까운 것이다.

개발자라면 아마 이런 경험이 있을 것이다. 블로그 글에서 본 디자인 패턴을 읽을 때는 완벽히 이해한 것 같았는데, 막상 일주일 뒤에 비슷한 문제를 만나면 기억이 안 나는 경우. 반면 프로젝트에서 삽질하며 직접 구현해본 패턴은 몇 달이 지나도 선명하게 남아있는 경우. 이 차이는 단순히 개인차가 아니라 뇌가 기억을 저장하는 방식에서 비롯된다.

그런데 장기 기억이 형성되는 과정은 우리의 직관과는 조금 다른 면이 있다. 쉽고 매끄럽게 이해한 것보다, 어렵고 힘들게 끙끙대며 처리한 것이 기억에 더 잘 남는다.

UCLA의 인지심리학자 로버트 비요크(Robert Bjork)는 이 현상을 “바람직한 어려움”이라는 개념으로 설명했다. 비요크는 학습 과정에서 적절한 수준의 난이도와 저항이 존재할 때, 단기적인 수행 속도는 느려지지만 장기적인 기억 보존과 전이는 오히려 향상된다고 말했다.

비요크가 제시한 핵심 메커니즘 중 하나는 인출 연습이다. 같은 내용을 반복해서 읽는 것보다, 스스로 기억을 떠올려보는 연습이 장기 기억 형성에 훨씬 효과적이라는 것이다.

로디거와 카르피크(Roediger & Karpicke)의 2006년 연구는 이 현상을 훨씬 정량적으로 보여준다.

이 실험은 우선 학생들을 두 그룹으로 나누고, 한 그룹은 같은 자료를 반복해서 읽게 하고 다른 그룹은 자료를 읽게 한 뒤 스스로 내용을 떠올려보는 테스트를 했다. 이 테스트가 끝나고 5분 뒤에는 반복 읽기 그룹의 성적이 더 좋았다. 하지만 일주일 뒤에 다시 테스트했을 때는 인출 연습 그룹의 기억 보존율이 약 50% 더 높았다.

이 결과가 시사하는 바는 무엇일까? 바로 정보를 수동적으로 받아들이는 것과 능동적으로 인출하는 것이 단기적으로는 비슷해 보여도 장기적으로는 전혀 다른 효과를 만든다는 것이다.

그리고 이 차이는 뇌 활성도 수준에서도 확인된다. 능동적으로 학습한 내용을 떠올려봤던 그룹은 해마와 전두엽 피질 사이의 연결성이 강화되고, 감각운동 네트워크와 섬엽의 활성도가 증가했다.

해마는 새로운 기억을 형성하는 핵심 영역이고, 전두엽 피질은 고차원 사고와 의사결정을 담당한다. 이 두 영역이 동시에 활성화되면서 긴밀하게 소통한다는 것은 뇌가 정보를 단순히 저장하는 것이 아니라 맥락과 함께 엮어서 기록하고 있다는 의미이다.

반면 수동적으로 강의를 듣는 그룹은 해마와 방추상회 사이의 연결만 주로 활성화되었다. 방추상회는 시각 처리, 특히 패턴 인식을 담당하는 영역이다. 쉽게 말해 수동적 학습 상태의 뇌는 정보를 보고 있을 뿐 “처리하고 있지 않은 것”에 가까운 것이다.

즉, 무언가를 받아들이고 학습할 때 뇌가 열심히 일할 수록 기억이 단단하게 저장되고 편하게 받아들인 정보는 편하게 사라진다.

한 가지 주의할 점이 있다. 이것이 단순히 “어려우면 다 좋다”는 뜻은 아니다. 비요크가 강조하는 것은 “바람직한” 어려움이다. 학습자가 현재 가진 능력으로 도달할 수 있는 범위 안에서의 도전이어야 한다.

너무 쉬우면 부하가 부족해서 기억에 남지 않고, 너무 어려우면 처리 자체가 불가능해서 좌절만 남는다. 적절한 난이도의 과제를 스스로의 힘으로 해결하는 경험이 가장 효과적인 학습을 만든다는 것이다. 이 지점을 기억해두자. 뒤에서 AI를 어떻게 활용할 것인가를 이야기할 때 다시 돌아올 것이다.

생성 효과와 유창성의 착각

슬라메카와 그래프(Slamecka & Graf)가 1978년에 발표한 고전적 연구에서 밝혀진 “생성 효과”도 같은 맥락에서 짚고 넘어갈 필요가 있다. 실험에서 참가자들을 두 그룹으로 나누었다. 한 그룹에게는 단어 쌍을 완성된 형태로 보여주었다.

예를 들어 “뜨거운-차가운”이라는 쌍을 그대로 제시한 것이다. 다른 그룹에게는 “뜨거운-차___“처럼 빈칸을 주고 직접 단어를 완성하게 했다. 차이는 고작 몇 글자를 직접 채우느냐 마느냐였을 뿐인데, 결과는 꽤 다르게 나왔다. 그 몇 글자를 직접 채운 그룹의 기억 보존율이 유의미하게 높았던 것이다.

이 차이가 왜 발생하는지를 신경과학적으로 살펴보면 더 흥미롭다. 정보를 직접 생성하는 과정에서는 뇌의 의미 처리 영역, 인출 경로, 실행 제어 영역이 동시에 활성화된다. 여러 뇌 영역이 동시에 관여할수록 기억의 인코딩이 더 풍부해지고, 나중에 그 기억을 끌어올 수 있는 경로도 더 다양해진다. 반면 완성된 정보를 수동적으로 읽을 때는 주로 인식 네트워크만 작동하기 때문에, 기억의 인코딩이 상대적으로 얕다.

여기서 주의해야 할 함정이 있는데, 바로 인지심리학에서 “유창성의 착각”이라고 부르는 현상이다. 정보를 쉽게 처리할 수 있다는 느낌이 곧 그 정보를 잘 기억할 것이라는 착각으로 이어지는 것이다.

잘 정리된 글을 읽으면 이해한 것 같은 느낌이 강하게 들지만, 실제 기억 보존율은 그 느낌만큼 높지 않다. 비요크의 연구에서 반복 읽기 그룹이 5분 후 테스트에서는 더 좋은 성적을 보인 것도 같은 맥락이다. 당장은 잘 아는 것 같지만, 시간이 지나면 남아있지 않는다.

코드를 판단하는 능력은 어떻게 만들어지는가

앞서 설명한 바람직한 어려움과 생성 효과는 일반적인 학습 원리다. 이것이 코딩에 구체적으로 어떻게 작동하는지를 이해하려면, 코딩 판단력이 뇌에서 어떤 형태로 저장되는지를 먼저 살펴봐야 한다.

사실 코딩 실력이라고 부르는 것의 상당 부분은 절차 기억에 해당한다. 절차 기억은 “어떻게 하는가”에 대한 기억이다. 마치 자전거 타기, 악기 연주, 타이핑 같은 것들처럼 한번 체화되면 의식적으로 떠올리지 않아도 자동으로 실행된다.

코딩에서의 절차 기억은 특정 문제를 보면 자연스럽게 떠오르는 해결 패턴, 코드를 읽으면서 “여기 뭔가 이상한데”라는 직감이 드는 감각, 설계 구조를 잡을 때 본능적으로 떠올리는 경계의 위치, 리팩토링이 필요한 지점을 순식간에 포착하는 눈 같은 것들이 해당될 것이다.

이런 것들은 교과서에서 읽어서 아는 명시적 지식과는 완전히 다른 종류의 기억이다. “SOLID 원칙을 나열하시오”에 답할 수 있는 것과, 코드를 보는 순간 단일 책임 원칙 위반을 감지하는 것은 다른 뇌 영역이 담당하는 다른 유형의 지식이라는 의미이다.

절차 기억 형성 세 단계

앤더슨(Anderson)의 적응적 사고 통제 모델은 이 절차 기억의 형성을 세 단계로 설명한다.

첫 번째는 인지 단계다. 인지 단계에서는 모든 것을 의식적으로 한 단계씩 실행한다. 코딩을 처음 배울 때를 떠올려보면 이해가 쉽다. 우리가 for문을 작성할 때 초기값은 뭘로 하고, 조건은 어떻게 쓰고, 증감은 어떻게 하는지를 하나하나 생각하며 타이핑했던 것처럼 말이다. 이처럼 인지 단계에서는 작업 기억의 상당 부분을 이 과정에 소모한다.

두 번째는 연합 단계다. 연합 단계에서는 개별 절차들이 통합되기 시작한다. for문과 배열 접근과 조건 분기를 하나의 흐름으로 묶어서 실행할 수 있게 된다. 그 결과 점점 실수가 줄어들고 인지하는 속도가 빨라진다.

세 번째는 자동화 단계다. 자동화 단계에서는 무언가를 인지할 때 작업 기억을 거의 차지하지 않고 자동으로 실행되는 것들이 많아진다. 숙련된 개발자가 필터링 로직을 작성할 때 for문의 문법을 의식하지 않는 것처럼 패턴 자체가 하나의 단위로 자동 인식된다. 이 단계에 도달한 개발자는 문법이나 기본 패턴에 작업 기억을 쓰지 않기 때문에 그만큼의 여유를 설계 판단이나 구조적 사고에 활용할 수 있다.

중요한 것은 이 단계들이 반복적인 수행을 통해서만 진행된다는 점이다. 인지 단계에서 연합 단계로 넘어가려면 직접 뇌에 부하를 걸면서 같은 유형의 문제를 여러 번 직접 풀어봐야 한다. 그리고 연합 단계에서 자동화 단계로 넘어가려면 더 많은 반복이 필요하다.

이 과정에서 뇌의 기저핵과 소뇌가 핵심적인 역할을 한다. 기저핵은 습관 형성과 절차 학습을 담당하고 소뇌는 동작의 정교화와 자동화를 돕기 때문이다.

반복적인 수행을 통해 이 영역들의 시냅스 연결이 지속적으로 강화되는데, 이것을 장기 강화라고 부른다. 이렇게 시냅스 연결이 강화될수록 해당 절차의 실행이 더 빠르고 정확해지며, 의식적 노력 없이도 자동으로 수행할 수 있게 된다.

이 과정이 충분히 진행되면 신경 효율성이 나타난다. 전문가의 뇌는 같은 작업을 수행할 때 초보자보다 더 적은 영역을 활성화하는데, 이것은 뇌과학 연구에서 가장 일관되게 확인되는 발견 중 하나다. 더 적게 일하면서 더 나은 결과를 내는 것, 그것이 바로 직관이라고 불리는 추상적인 표현의 신경학적 실체에 가깝다.

즉, 의식적 추론 없이 빠르게 좋은 판단을 내릴 수 있는 능력은 수많은 반복과 고통의 결과물이고 이 과정에 지름길은 없다.

이것은 마치 운동과도 비슷하다. 운동선수가 근력을 키우려면 근육에 부하를 걸어야 한다. 너무 가볍지도, 너무 무겁지도 않은 적절한 무게를 들며 근육에 부하를 주다보면 어느새 근육이 손상되며 점점 성장하게되고 어느새 더 무거운 무게를 칠 수 있게 된다. 뇌도 마찬가지다. 현재 능력의 경계 근처에서 직접 씨름해야 성장이 일어난다.

전문가는 하나의 청크에 담을 수 있는 양이 다르다

뇌과학에서 전문성을 설명할 때 빠지지 않는 또 하나의 중요한 개념이 청킹이다.

인간의 작업 기억 용량은 약 3~4개의 청크로 제한되는데, 사실 청크의 개수 제한은 초보자나 전문가나 동일하다. 작업 기억의 슬롯 수 자체는 훈련으로 늘릴 수 없다고 한다.

그렇다면 전문가와 초보자의 차이는 어디에서 오는 것일까? 답은 하나의 청크에 담을 수 있는 정보의 양이 다르다는 데 있다.

체스 전문가를 대상으로 한 체이스와 사이먼(Chase & Simon)의 연구가 이를 보여준다. 연구진은 체스 고수와 초보자에게 실제 게임에서 나올 법한 보드 배치를 5초간 보여준 뒤, 기억에 의존해서 재현하게 했다. 고수들은 초보자보다 훨씬 더 많은 말의 위치를 정확하게 재현했다. 여기까지는 “기억력이 좋으니까”로 설명할 수 있을 것 같다.

하지만 결정적인 대조 실험이 있었다. 말을 무작위로 배치했을 때, 고수와 초보자의 재현 능력 차이가 거의 사라진 것이다. 고수들이 기억한 것은 개별 말의 위치가 아니라, 의미 있는 패턴이었다. “시실리안 디펜스의 전형적인 중반 배치”같은 것을 하나의 청크로 인식했기 때문에, 같은 3~4개의 작업 기억 슬롯으로 훨씬 많은 정보를 담을 수 있었던 것이다.

시실리안 디펜스는 백의 공격적인 오프닝에 대응하는 유명한 카운터 오프닝이다

코딩에서도 정확히 같은 메커니즘이 작동한다. 숙련된 개발자는 for문과 배열 접근과 조건 분기를 각각 별도의 정보로 처리하지 않는다. 그것을 “필터링 패턴”이라는 하나의 청크로 압축해서 인식한다. try-catch와 에러 타입 분기와 로깅을 “에러 핸들링 패턴”이라는 하나의 청크로 본다.

그래서 같은 코드를 보더라도 작업 기억에 여유가 있고, 그 여유를 더 높은 수준의 판단에 쓸 수 있다. 이를테면 “이 함수의 책임 범위가 너무 넓은 건 아닌지”, “이 의존성 방향이 맞는지” 같은 구조적 질문에 인지 자원을 할당할 수 있는 것이다.

그렇다면 이 청크는 어떻게 만들어지는 것일까? 직접 코드를 작성하고, 디버깅하고, 리팩토링하는 과정에서 특정 패턴을 반복적으로 마주치면서 뇌가 그 패턴을 하나의 단위로 묶기 시작한다. 이 과정에서 전두엽 피질과 기저핵의 회로가 함께 작동한다는 것이 최근 연구에서 확인되었다.

패턴을 “안다”는 것과 패턴이 “체화되었다”는 것은 다른 문제이다. 전자는 명시적 기억이고 후자는 절차 기억이다. 코드 리뷰에서 구조적 문제를 빠르게 포착하려면 후자가 필요하다.

이 두 가지의 차이는 실제 업무에서 극명하게 드러난다. “useEffect의 클린업 함수가 왜 필요한가요?”라는 질문에 교과서적으로 완벽하게 답할 수 있는 사람이, 코드 리뷰에서 아래와 같은 컴포넌트를 보고도 문제를 놓치는 경우가 있다.

function useNotificationCount({ userId }: { userId: string }) {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(async () => {
      const notifications = await fetchNotifications(userId);
      setCount(notifications.unread);
    }, 5000);
  }, []);

  return count;
}

이 컴포넌트에는 두 가지 문제가 있다. clearInterval이 없어서 컴포넌트가 언마운트된 뒤에도 인터벌이 계속 실행되고, userId가 의존성 배열에 빠져 있어서 userId가 바뀌어도 이전 사용자의 알림을 계속 polling하게 된다.

“useEffect는 클린업 함수를 반환해야 하고 의존성 배열을 정확히 채워야 한다”는 걸 명시적 지식으로는 알고 있지만, 코드를 보는 순간 반사적으로 “여기 인터벌 정리 안 했는데”, “userId가 deps에 없네”라는 감각이 드는 수준의 절차 기억은 형성되지 않은 상태인 것이다. 이 감각은 직접 스테일 클로저 버그를 만들고, 언마운트 이후에도 살아있는 인터벌을 디버깅하고, 원인을 찾아본 사람에게만 생긴다.

물론 이 글에서 인용한 연구들은 대부분 코딩이 아닌 일반적인 학습 맥락에서 수행된 것이다. 코딩이라는 특수한 인지 활동에 이 결과들을 직접 적용하는 데는 한계가 있을 수 있다. 하지만 바람직한 어려움, 생성 효과, 절차 기억 형성의 원리는 영역 특수적이라기보다 인간 인지의 일반적 특성에 가깝고, 코딩이라는 활동이 이 원리에서 예외라고 볼 근거는 현재로서는 없다.

AI는 이 과정을 방해한다

AI에게 구현을 맡기면 개발자는 직접 코드를 고민하고 작성하는 과정을 건너뛰게 된다. 변수명을 뭘로 할지, 이 로직을 어떤 순서로 풀어낼지, 이 함수의 인터페이스를 어떻게 잡을지, 에러 처리를 어디서 할지. 이런 사소하지만 반복적인 판단들이 사실은 코드 패턴을 체화하는 핵심 과정인데, AI가 그 과정을 대신하는 순간 뇌에 걸리는 인지적 부하가 급격히 줄어든다.

본질적 부하까지 대신해버린다

물론 인지적 부하가 줄어드는 것 자체는 나쁜 것이 아니다. 인지 부하 이론에 따르면, 학습에서 중요한 것은 부하의 종류다. 스웰러는 인지 부하를 세 가지로 구분했다. 과제 자체의 복잡성에서 오는 내재적 부하, 잘못된 학습 설계에서 오는 외재적 부하, 그리고 스키마 구축을 직접 돕는 본질적 부하.

AI가 줄여주는 것이 외재적 부하, 즉 보일러플레이트 작성이나 문법 실수 교정 같은 것이라면 오히려 학습에 도움이 될 수 있다. 하지만 AI가 본질적 부하까지 줄여버린다면, 뇌가 스키마를 구축할 기회 자체가 사라지는 것이다.

문제는 현실에서 이 두 종류의 부하를 깔끔하게 분리하기 어렵다는 데 있다. AI에게 “이 함수를 구현해줘”라고 하면, AI는 보일러플레이트만 대신 작성하는 것이 아니라 핵심 로직의 설계 판단까지 대신한다. 어떤 자료구조를 쓸지, 어떤 순서로 처리할지, 에러 케이스를 어떻게 다룰지. 이 판단들이 바로 본질적 부하에 해당하는 것들인데, 이것까지 AI에게 맡겨버리면 뇌에는 거의 아무것도 남지 않게 된다.

절차 기억의 관점에서 보면, AI가 구현을 대신해주면 인지 단계에서 직접 끙끙대며 코드를 작성하는 시간이 줄어들기 때문에 연합 단계로의 전환이 지연되고, 결과적으로 자동화 단계에 도달하기 어려워진다.

청킹의 관점에서도 마찬가지다. 직접 패턴을 구성하고 조합하는 과정 없이 완성된 코드를 읽기만 하면, 개별 패턴을 인식할 수는 있지만 그것을 자신만의 청크로 압축하는 경험이 부족해진다. 마치 체스 교본만 읽고 실전을 뛰지 않는 것과 비슷하다.

특히 주니어 개발자에게 이 문제는 심각할 수 있다. 아직 인지 단계에 있는 패턴들이 많은 상태에서 AI가 그 단계를 건너뛰게 해주면, 겉으로는 빠르게 결과물을 내고 있지만 뇌 안에서는 아무런 절차 기억도 형성되지 않는 상태가 될 수 있기 때문이다.

AI가 코드를 대신 작성해주는 상황은 생성 효과 실험에서 완성된 단어 쌍을 그냥 읽는 것에 가깝다. 코드가 눈앞에 있으니 이해한 것 같은 느낌은 든다. 로직을 따라가며 “아, 이렇게 하면 되는구나”라고 고개를 끄덕일 수 있다.

하지만 직접 생성하지 않았기 때문에 기억에 깊이 각인되지 않는다. 다음에 비슷한 문제를 만났을 때 “분명 본 적이 있는데 기억이 안 나는” 상태에 빠지기 쉽다. 앞서 이야기한 유창성의 착각이 여기서도 작동하는 것이다.

물론 AI가 만든 코드를 읽는 것이 완전히 수동적인 행위는 아니다. 코드의 의도를 파악하고 실행 흐름을 추적하는 과정에서 어느 정도의 인지적 노력이 필요하기는 하다.

하지만 숙련된 개발자일수록 코드를 읽을 때의 뇌 활성화 수준이 낮아진다는 것이 연구를 통해 확인되어 있다. 신경 효율성이라고 불리는 이 현상은, 전문가가 더 적은 인지 자원으로 더 빠르게 코드를 처리한다는 것을 의미한다. 효율적으로 처리한다는 것은 곧 그만큼 인지적 부하가 적다는 뜻이기도 하다.

즉, 숙련된 개발자가 AI의 출력을 읽는 행위는 생각보다 뇌에 부하를 많이 걸지 않는다.

그리고 초보 개발자의 경우, 코드를 읽으면서 부하가 걸리더라도 그것은 코드를 이해하는 데 쓰이는 부하이지 코드를 생성하는 과정에서 발생하는 부하와는 질적으로 다르다. 읽기만으로 새로운 패턴을 체화하기에 충분한 부하가 걸리지 않을 가능성이 있다는 것이다.

이 글을 읽는 독자 분들 중 일부는 AI가 짠 코드를 깊이 분석하고 리뷰하는 것만으로도 충분한 학습이 되지 않느냐고 할 수 있다. 물론 이것도 일리 있는 말이다.

하지만 여기에는 함정이 있는데, 뇌과학에서 말하는 학습의 핵심인 예측과 피드백이 빠져있기 때문이다. 직접 코드를 짤 때는 매 순간 다음엔 무엇을 쓸지 예측하고, 그것이 작동하는지 피드백을 받으며 시냅스를 수정한다. 반면 이미 완성된 AI의 코드를 읽는 행위는 예측의 과정이 생략된 사후 해석에 가깝다.

마치 해설지가 옆에 놓인 수학 문제를 푸는 것과 같다. 해설을 읽으면 이해는 가지만, 막상 시험장에서 백지를 마주하면 펜이 나가지 않는 이유는 인식(Recognition)의 회로와 인출(Retrieval)의 회로가 다르기 때문이다. 디테일을 스스로 결정해 본 고통의 총량이 청크의 밀도를 결정한다.

성장이 멈추는 경로의 마찰이 사라졌다

여기서 한 발 물러서서 더 넓은 그림을 보자. 성장이 멈추는 문제는 AI 이전에도 있었다. 앞서 이야기한 ‘1년짜리 경험을 10번 반복하는’ 패턴의 구체적인 모습이 무엇인지 살펴보자.

StackOverflow에서 답을 복사해서 붙여넣기만 하는 개발자. 프레임워크의 API는 익숙하지만 그 아래에서 무슨 일이 일어나는지 모르는 개발자. 같은 종류의 CRUD 코드를 5년째 반복하면서 연차만 쌓이는 개발자. 이 사람들의 공통점은 뇌에 충분한 부하를 걸지 않았다는 것이다.

StackOverflow에서 복사한 코드가 돌아가면 거기서 멈춘다. 왜 이 코드가 작동하는지, 다른 방법은 없었는지, 이 패턴의 트레이드오프는 무엇인지를 묻지 않는다. 프레임워크가 제공하는 추상화 위에서만 일하면 그 아래의 메커니즘에 대한 청크가 형성되지 않는다. 같은 패턴의 코드를 반복하면 자동화 단계에 도달하기는 하지만, 자동화 단계에 도달한 패턴의 범위가 좁으면 새로운 문제 앞에서 무력해진다.

이 모든 경우에서 작동하는 메커니즘은 사실 동일하다. 인지적 부하를 회피하면 절차 기억이 형성되지 않고, 청크가 만들어지지 않고, 결과적으로 성장이 멈춘다. AI가 등장하기 전에도 성장이 멈추는 경로는 충분히 열려 있었다.

그런데 AI는 이 경로의 마찰을 극적으로 줄여버렸다. StackOverflow 시절에는 그래도 검색하고, 여러 답변을 비교하고, 자기 상황에 맞게 수정하는 과정이 있었다. 이 과정에서 최소한의 인지적 부하가 걸렸다. 프레임워크에 의존하더라도 공식 문서를 읽고 예제를 따라 해보는 시간이 있었다.

하지만 AI는 맥락을 주면 바로 완성된 코드를 내놓는다. 검색도, 비교도, 수정도 필요 없다. “작동하는 코드”까지의 거리가 거의 0에 가까워진 것이다.

생산성 관점에서 이것은 혁명이다. 하지만 학습 관점에서 보면, 뇌에 부하가 걸릴 기회가 그만큼 줄어든 것이기도 하다. AI 이전에는 “편한 길”을 택하더라도 어느 정도의 마찰이 있었는데, AI는 그 마찰마저 제거해버렸다. 성장이 멈추는 경로로 미끄러져 들어가기가 이전보다 훨씬 쉬워진 것이다.

이 문제는 경력이 높다고 비껴가지 않는다. 다만 양상이 다를 뿐이다. 주니어 개발자에게 이 문제가 더 심각한 것은 사실이다. 절차 기억이 충분히 형성되지 않은 상태에서 AI가 그 형성 과정 자체를 건너뛰게 하면, 기초 체력이 없는 상태로 경력만 쌓이게 된다.

아직 운전을 배우는 중인 사람에게 자율주행차의 판단을 평가하라고 하는 것과 같다. 직접 핸들을 잡아보지 않은 사람이 자율주행의 실수를 감지하기는 어렵다.

하지만 시니어 개발자라고 해서 자유로운 것은 아니다. 기술은 계속 변하고, 새로운 언어, 프레임워크, 패러다임이 등장할 때마다 기존의 청크로는 처리할 수 없는 새로운 패턴을 만나게 된다.

이 새로운 패턴을 체화하려면 또다시 인지 단계부터 시작해야 한다. 시니어라서 이 과정이 면제되지 않는다. 새로운 것을 배울 때는 누구나 초보자다.

시니어의 장점은 기존의 추상화 능력을 활용해서 새로운 청크를 더 빠르게 형성할 수 있다는 것이다. “이건 백엔드의 미들웨어 패턴과 비슷하구나”처럼 기존 청크에 연결 지을 수 있다. 하지만 그 연결 자체도 직접 코드를 만져보면서 발견하는 것이지, AI의 출력을 읽으면서 자동으로 발견되는 것은 아니다.

결국 경력과 관계없이, AI 시대에도 직접 고민하고 코드를 만져보는 시간이 있어야 한다. 그렇다면 AI를 쓰면서도 그 시간을 어떻게 만들 수 있을까?

뇌에 부하를 거는 방법

결국 성장을 위한 핵심 원리는 하나다. 바로 뇌에 부하를 걸어야 한다는 것이다.

AI에게 코드를 맡기기 전에 먼저 자신의 설계안을 만들어두는 것은, 생성 효과를 의도적으로 활용하는 행위다. 자신의 답을 먼저 만들어두었기 때문에 AI의 출력을 단순히 소비하는 것이 아니라 비교하고 평가하게 된다. “내 설계와 뭐가 다른지”, “AI의 선택이 더 나은지, 내 선택이 더 나은지”를 판단하는 과정에서 뇌의 의미 처리와 실행 제어 영역이 동시에 활성화된다. 생성 효과 연구가 보여준 것과 같은 메커니즘이다.

리뷰를 진지하게 하는 것도 마찬가지다. “작동하니까 통과”로 넘기면 뇌에 부하가 거의 걸리지 않는다. 하지만 “왜 이 구조인가”, “6개월 뒤에 이 코드를 수정해야 한다면 어디가 문제가 될까”를 의식적으로 묻는 순간, 뇌는 작업 기억을 적극적으로 사용하기 시작한다. 이 과정이 귀찮고 시간이 걸리는 것은 당연하다. 바로 그 귀찮음이 비요크가 말한 바람직한 어려움이다.

직접 코드를 짜보는 시간을 만드는 것은 절차 기억 형성의 관점에서 대체 불가능하다. 앤더슨의 모델이 보여주듯, 인지 단계에서 연합 단계로, 연합 단계에서 자동화 단계로 전환되려면 반복적인 수행이 필요하다. 읽는 것으로는 이 전환이 일어나지 않는다.

30분 동안 끙끙대며 직접 짠 코드가 AI가 3초 만에 생성한 코드보다 기억에 더 깊이 남는 이유가 여기에 있다. 다만 막혀서 진전이 없을 때는 AI에게 힌트를 구하는 것도 하나의 전략이다. 핵심은 전체 답이 아니라 최소한의 정보만 얻는 것이다. 답을 받아 적는 것과 힌트를 토대로 직접 풀어내는 것은 뇌에 걸리는 부하가 완전히 다르다.

앞서 이야기한 바람직한 어려움의 요점이 바로 여기에 있다. 너무 쉬우면 부하가 걸리지 않고, 너무 어려우면 좌절만 남는다. AI를 통해 진입 장벽은 낮추되 핵심 판단은 직접 내리는 것, 그것이 적정 난이도를 유지하는 방법이다.

이 실천들의 공통점은 전부 귀찮다는 것이다. 당장의 생산성 관점에서는 비효율적이다. AI에게 맡기면 빠르게 끝날 일을 굳이 돌아가는 느낌이 든다.

물론 귀찮고 스트레스받겠지만 그런 스트레스도 필요하다.
운동 많이 된다

생산과 학습의 최적 전략은 다르다. AI는 생산의 도구로는 탁월하지만, 학습의 도구로는 한계가 있다. 그리고 장기적으로 뇌에 남은 것들이 결국 코드 리뷰의 질을 결정하고, 설계 판단의 정확도를 결정하고, 역설적이게도 AI를 얼마나 잘 활용할 수 있는지를 결정한다.

이 훈련들이 쌓이면 결국 하나의 눈이 만들어진다. AI가 만든 코드를 보자마자 무엇이 잘못됐는지, 어디서 더 나은 선택이 가능한지를 감지하는 눈. 그것이 서두에서 이야기한 “출력물을 판단하고 교정하는 역량”의 실체다.

고통은 선택이 아니라 조건이다

이 글의 문제의식은 “AI가 나쁘다”는 것이 아니다. AI 이전에도 성장이 멈추는 개발자는 있었고, AI가 없어져도 그런 개발자는 있을 것이다.

핵심은 인지적 부하를 회피하면 성장이 멈춘다는, 뇌의 작동 방식에 내재된 구조적 제약이다. AI는 그 회피를 전례 없이 쉽게 만든 도구일 뿐이다.

필자는 이 문제가 개인의 의지력이 아니라 구조의 문제라고 생각한다. AI를 사용하면서도 성장할 수 있는 구조를 의식적으로 설계하지 않으면, 편한 쪽으로 흘러가는 것은 인간의 자연스러운 성향이다.

뇌는 기본적으로 에너지를 아끼려고 한다. 같은 결과를 더 적은 노력으로 낼 수 있다면 뇌는 당연히 그쪽을 선택한다. 이것은 의지가 약해서가 아니라, 뇌가 원래 그렇게 설계되어 있기 때문이다.

그래서 “AI를 쓰느냐 마느냐”가 아니라 “AI를 쓰면서 뇌에 부하를 어떻게 걸 것인가”가 진짜 질문이 되어야 한다고 생각한다. 편하게 일하는 것과 편하게만 일하는 것 사이에는 아주 큰 차이가 있다.

고통은 피하고 싶은 것이지만, 성장의 관점에서 보면 선택이 아니라 조건에 가깝다. AI가 아무리 발전해도 이 조건은 바뀌지 않는다. 뇌의 작동 방식이 바뀌지 않는 한.

그리고 AI를 잘 쓰는 사람이 살아남는 시대에, 역설적이게도 그 힘은 AI 없이도 판단할 수 있는 능력에서 나온다.

Only When the Tide Goes Out Do You See Who's Been Swimming Naked

Tue, 10 Feb 2026 09:00:00 GMT

This post is about how the developer role is changing in the AI era, and what to do about it. It’s something I hear a lot at work lately - and honestly, it’s not just developers. Most knowledge workers seem to be sitting with the same anxiety.

The feeling tends to be equal parts excitement about what AI can do for productivity, and unease about what it might do to jobs.

Nobody knows how this actually plays out, and I’m no exception. But doing nothing feels worse. So here’s how I’ve been thinking about it.

Three years since ChatGPT

When ChatGPT launched in late 2022, I genuinely didn’t expect it to move this fast. There were constant hallucination problems, and the output quality wasn’t particularly impressive.

Three years later, a significant chunk of how I spend my day has changed.

The job used to be something like: understand what people need, design a solution, write code until it exists. You’d take requirements written in natural language, think through the design, and translate all of it into code by hand.

Not long ago, my morning started with opening an editor and placing the cursor in a blank file. Now it’s more like: explain the context to an AI, read what comes back, ask again, adjust, repeat.

I’ve been through the shift from feature phones to smartphones - that already felt fast. This is faster.

AI coding agents have been well past “basic autocomplete” for a while now. Give them a clear prompt and they’ll produce a function or module that’s hard to distinguish from what a developer would write. In this environment, writing every line yourself is becoming inefficient for at least some categories of work.

Things will probably keep accelerating. How the developer role reshapes itself will depend on the team and the context. The question is what to focus on now.

From code writer to decision-maker

To answer that, it helps to look at where the time goes. Time used to go into typing. Now it goes into prompting, reading generated output, adjusting, and prompting again.

Building software is shifting from direct code authorship toward something more like judgment - not just checking whether the AI did what you asked, but verifying that the business intent actually made it through to the technical implementation.

You could argue that as AI improves, even code review will be automated away. I don’t think so, and the reason isn’t about technical capability.

Someone has to be accountable for the code

A lot of developers are already using AI for code review - it reads the PR and leaves comments. Honestly, some of those comments are pretty sharp. It catches things I’d miss.

But I think there’ll always be a human who needs to put the final stamp on “this is okay to ship.” The reason comes down to one question.

When the code causes a problem, who is responsible?

AI is not a legal entity. It cannot be held accountable. So when AI-generated code breaks something, the question of who answers for it becomes urgent.

Say AI-written code has a bug in the payment logic that charges customers the wrong amount. What happens if the company responds like this:

"It was written by AI, so honestly, I have no idea why this happened."

No customer is going to accept that. Put yourself on the receiving end and it’s infuriating.

No matter who wrote the code, someone is accountable. The way I see it, that’s the developer who reviewed and approved it, and the organization they work for.

This isn’t just speculation - it’s already showing up in regulation.

The EU AI Act, which took effect in 2024, mandates human oversight of AI systems in high-risk areas like healthcare, finance, and infrastructure. The principle is clear: even when AI makes the call, humans must be able to review the process. It’s now law.

There are also ongoing discussions in the EU about extending product liability frameworks to digital products and software. “AI made it, not us” is becoming a harder argument to make legally.

Real-world precedents outside software point the same direction. When autonomous vehicles crash, liability goes to the manufacturer and driver. FDA-approved AI diagnostic tools still require a physician to make the final call. The 2010 Flash Crash, where algorithmic trading caused a cascading market collapse, showed that whoever runs the automated system is who the regulators come after.

The more automation you add, the sharper the line gets between the human in the loop and the consequences of what that loop produces.

So I don’t think the developer role disappears. It shifts from writing code to reviewing and approving it. The method of producing code has changed. What hasn’t changed is that the quality of the final product depends on whoever reviews it. So what does that actually require?

What AI-era development actually demands

The obvious guess is that prompt engineering or AI tool fluency becomes the key skill. I think that’s wrong.

You can now tell an AI “write this like Martin Fowler would” and get something that looks reasonable. But so can everyone else who types that sentence. What’s the edge there?

The real skill is knowing when the output doesn’t meet the bar - even when the prompt was supposedly good. Good prompts don’t guarantee good code.

Ironically, the skills that matter in the AI era aren’t that different from what has always separated good developers from average ones.

Because review still requires checking: will this break at runtime? Is it maintainable six months from now? Are there missing error cases? Does it violate any policies? And as long as a human is the one signing off, code still needs to be readable by humans.

If humans never needed to read code, we could ship bytecode. But you’re the one who has to answer when something breaks. Can you really approve a deploy without reading what you’re shipping?

As long as that accountability constraint holds, the questions developers think about today - what makes code readable, what makes it maintainable - will remain relevant.

Predicting the long-term cost of change

Scroll through LinkedIn lately and you see a pattern. A year ago it was “look what I built with AI in a weekend.” Now it’s occasionally “hired developers because we couldn’t maintain it” or “shut it down because we couldn’t add features.” Both kinds of posts are real.

This happens because AI is optimized for working code. It reproduces the patterns that appear most often in training data. Those patterns are, by definition, code that runs. Code that runs and code that’s easy to maintain six months later are two different things.

Newer models are getting better at factoring in maintainability. But that’s not quite the point. Output quality and predicting the long-term cost of change are separate problems.

Software quality doesn’t reveal itself immediately. The cost of a bad design shows up when you have to change the code, not when you write it.

Evaluating code from multiple angles

This was true before AI too. The difference now is that generation speed has increased, so deferred costs accumulate faster.

Review covers multiple dimensions. Functional correctness - does it do the right thing - is the part tests can catch. The harder part is structural quality.

Is this module’s responsibility scoped correctly? Is the dependency direction right? Is this interface flexible enough for future changes? Tests don’t answer these. Then there’s performance: the code works, but does it hold up when data volume is 10x? And security: is input validation sufficient, or is there a missing authorization check somewhere?

Evaluating code across all of these dimensions at once is a different skill from just reading code.

And as generation speed increases, this gets harder.

When developers wrote everything by hand, there was a physical ceiling on output. A developer can only type so much in a day, so the volume of code the team needed to review was naturally paced. Writing slowly doesn’t make code better - but it does mean production couldn’t easily outpace review capacity.

When AI can generate hundreds of lines in seconds, that balance breaks easily. Without solid review standards, parallel review processes, and automated gates, you can double or triple code volume while review capacity stays flat. Things start slipping through. Technical debt accumulates faster. The production line sped up but the quality control process didn’t.

My guess is this explains why many companies adopt AI and still don’t feel more productive. Code production got faster; review became the bottleneck.

In this structure, developers who can review code well and quickly become more valuable. The more code AI generates, the more you need someone who can filter out the hidden risks and bad abstractions mixed into that output.

Abstraction

Abstraction is another one. At its core, abstraction means deciding what to hide and what to expose in a complex system - where to draw the lines.

AI can do abstraction. It defines interfaces, divides classes, separates modules. Formally speaking, it sometimes does this better than I would. But there’s a key difference between AI abstraction and what an experienced developer produces.

AI abstraction is based on statistical averages from training data. It takes patterns that looked plausible across thousands of projects and applies whichever one fits closest. But real software design isn’t a multiple-choice test. It’s a series of tradeoff decisions made under resource constraints and uncertainty about the future.

AI can maintain internal consistency in code. What it struggles with is factoring in external context - the stuff that lives outside the codebase - when deciding where to draw the lines. Code that’s optimal for a specific situation requires strategic judgment that goes beyond statistical norms.

This isn’t really a flaw in AI - it’s a structural limit of statistical learning. You can produce code that’s good on average. Code that’s optimal for your specific situation is a different problem.

The dangerous thing about AI-generated code is that it looks fine. Files are properly separated, naming follows convention, patterns are familiar. It passes review easily.

The problem shows up later. You try to add a payment method and realize the “cleanly separated” structure requires changes in five different places simultaneously. This kind of defect doesn’t appear when you write the code. It appears when you try to change it.

AI-generated code shows this pattern fairly often. The structure follows common conventions perfectly, but it doesn’t quite fit the actual requirements.

A frontend example: ask AI to build a dashboard component and it typically produces one giant component with data fetching, state management, and UI rendering all mixed together. Or it over-applies best practices from training data and builds three custom hooks and a context provider just to render a single chart.

One is under-abstracted, one is over-abstracted. Both are wrong in the same way: neither fits the actual complexity level of the project. Good abstraction means creating exactly as much structure as the current situation requires. Knowing how much that is requires knowing the context.

An experienced developer reads this code, recognizes that the boundaries were drawn without understanding the domain, and redraws them. What that takes isn’t coding skill. It’s understanding of the system and a sense of design.

The same standard applies whether a human or AI wrote the code: is this abstraction actually reducing complexity, or just adding more indirection to track? Being able to ask that question is already a skill.

Articulating tacit knowledge

If abstraction is knowing where to draw the lines, articulating tacit knowledge is being able to explain why the lines go there. Related, but different. In practice they work together.

The instinct for recognizing bad code builds up gradually through reading and writing a lot of code. It usually starts as “something feels off” - tacit knowledge that’s genuinely hard to put into words.

Translating that instinct into language matters more now. “Something feels off” needs to become “this function has two responsibilities” or “this interface will break under change” - concrete enough to actually direct an AI.

This isn’t about prompt tricks like few-shot examples or chain-of-thought formatting. Those get absorbed into the model as it improves. What I’m talking about is the underlying ability: clearly defining what needs to be built, and knowing which context matters enough to include.

Anyone can say “build me this thing.” What matters is being able to identify exactly what’s wrong with what comes back, and explain specifically why it should be built differently.

Seeing “something wrong” code and knowing concretely what that something is - that’s design competence. The deeper your understanding of the system, the more precise your instructions to AI can be.

You don’t manipulate memory directly anymore, but you still need to understand the memory model to debug performance problems. You may not write every line of code, but you still need to understand abstraction to catch design problems. There’s an extra layer of indirection; the underlying need hasn’t gone away.

These skills have a longer shelf life than tool fluency. Tool fluency expires when the tool does. jQuery gave way to React. Webpack gave way to Vite. Design judgment and the ability to articulate tacit knowledge are valid as long as software has essential complexity - which is to say, indefinitely.

That complexity doesn’t disappear when the tools change. Payment systems are complicated because payments are complicated, not because of the framework. The instinct for handling that complexity doesn’t belong to any particular tool.

The need for deliberate practice

A reasonable question at this point: if you’re writing less code, how do you build abstraction sense and design instinct?

There’s a real tension here. You’re told to focus on what AI can’t do, while AI is quietly reducing the opportunities to practice those exact things.

The answer has two parts. One is protecting two specific points in your daily workflow from AI. The other is deliberately maintaining design instinct outside of work. And there’s a single attitude that runs through both.

Two points to keep for yourself: design and review

In a normal workday, there are two points not to hand off to AI: design before writing code, and review after.

Doing design yourself isn’t just a habit thing. If you define “what interface does this module expose?” and “where do the responsibilities end?” before you prompt, you can compare what AI produces against your own design decision.

If AI chose a different structure, you end up analyzing why. Did it catch something you missed? Or did it get it wrong? Without this step, you’re likely just consuming output. Consuming output and evaluating output against your own judgment are completely different experiences.

Review is the other one - and unlike deliberate practice, it shows up automatically in your workflow. Which is exactly why letting it slip is so dangerous.

Delegating PR review to AI and approving with no objections is like going to PE class and sitting on the bench for the whole period. The work gets done somehow, but several years of this and your skills haven’t moved.

Code review means reading code while holding requirements, design intent, and business context in your head at the same time. That process is the training.

Time to build things yourself

Doing your own design and review at work isn’t enough on its own. Design instinct requires knowing the pain of implementation.

You need to have personally experienced a structure falling apart under change before you can feel “this abstraction is wrong.” Pain you haven’t felt doesn’t become instinct.

Junior developers especially. Reviewing AI-generated code without much experience is a bit like asking someone still learning to drive to evaluate a self-driving car’s decisions. You get a feel for the road by gripping the wheel. You get a feel for structure by writing the code.

My guess is that for future developers, coding directly won’t be a daily job requirement - it’ll be more like ongoing training to maintain your judgment. (Maybe the painful grind of building things from scratch as a junior becomes less of a job requirement and more of a certification process - how you earn the right to be trusted as a reviewer.)

So in side projects and personal learning, I think it’s worth deliberately putting AI aside and building things end-to-end yourself. The more convenient AI gets, the more annoying that friction feels. But the friction is the point.

The moments where you get stuck, or where you realize you need to refactor - those are where the learning actually happens.

The attitude that runs through both: putting “why” into words

Whether you’re doing design and review at work, or building things alone in your own time, one attitude needs to run through both.

When “something feels off” shows up, don’t let it slide. Stay with it until you can say clearly what’s actually wrong.

Stopping at “feels off” is just a feeling. Getting to “this function has two responsibilities” is language. A feeling only you know. Language is usable. Once it’s language, you can direct AI precisely, explain it to teammates, and recognize the pattern when you see it again.

When AI produces code that works, don’t stop there. Ask yourself: why did it choose this structure? What tradeoffs would a different approach have had?

The gap between developers who ask this and developers who don’t will keep widening.

The fundamentals haven’t changed

AI is moving the developer role from code author to reviewer. We’re moving from humans doing both production and quality control, to AI handling production and humans handling quality control.

Understanding that this shift is driven by accountability - a social and legal constraint, not a technical one - makes the role change clearer.

Stamping “approved” well requires an eye for the difference between working code and durable code, the design sense to evaluate abstraction in context, and the ability to put that sense into words and steer accordingly.

The edge in the AI era isn’t about who generates more. It’s about who understands context well enough to approve responsibly. Developers are still accountable for code quality. That hasn’t changed.

AI is genuinely different from previous tools. Unlike a plow or a compiler, it reasons and generates. “It’s just another tool” isn’t a convincing argument anymore. So why would the required skills stay the same?

Start with accountability. Being accountable means making judgments. The quality of those judgments comes from being able to read structural health in code, distinguish abstraction that fits the domain from abstraction that doesn’t, and anticipate the long-term cost of change. These are the things that have always separated good developers from average ones.

Fred Brooks, in 1986, separated software complexity into two types: accidental complexity, which comes from the limits of tools, and essential complexity, which is inherent to the problem itself. AI addresses accidental complexity - boilerplate, repeated patterns, syntax errors. But essential complexity - the ambiguity in business requirements, the balance between competing design goals, the uncertainty about what will need to change next year - doesn’t disappear no matter how good the AI gets. That complexity comes from the nature of the problem, not the limits of the tools.

So even though AI is different from previous tools, as long as humans remain the accountable parties, the skills required for that judgment don’t change. If anything, automating production makes the judgment in quality control more visible, not less.

A coach I work with compared this situation to Buffett's line:
"Only when the tide goes out do you discover who's been swimming naked."
I can't think of a better analogy.

This is why it feels slightly off when I see so many developers focused on getting better at using AI.

A year ago, prompt engineering was the big topic. Now it’s skills, parallel agents, AI teams. Six months from now those keywords will probably be gone too.

AI is going to reach a point where a kid typing casually gets good output. Optimizing for tool usage as a competitive advantage in that environment seems like the wrong bet. Focusing only on how to use the tool better might actually be how you fall behind.

I could be wrong about how this unfolds. Nobody knows exactly how fast AI will develop or in what direction, and I’m not an exception. This post is just one developer thinking through the uncertainty.

There’s no right answer. But the tide is going out faster. I hope you find yours before it does.

물이 빠지면 누가 발가벗고 수영했는지 드러난다

Tue, 10 Feb 2026 09:00:00 GMT

이번 포스팅에서는 AI 시대에 개발자의 역할이 어떻게 달라지고 있는지, 그리고 무엇을 준비해야 하는지 이야기해보려 한다. 최근 필자가 재직 중인 직장에서도 많은 개발자들이 이 주제에 대해 고민을 하고 있는데, 비단 이 주제는 필자 같은 개발자뿐 아니라 다양한 직군이 함께 고민하는 문제일 것이다.

공통적으로는 AI로 인한 생산성 향상에 대한 기대와 함께, 대체 가능성에 대한 불안도 동시에 느끼는 것 같다.

물론 AI로 인해 앞으로의 먼 미래가 어떻게 달라질 것인지에 대해서는 아무도 알지 못할테고, 필자 또한 마찬가지이다. 그래도 아무것도 안할 수는 없으니 필자가 그리는 미래의 개발자의 역할과 모습에 대해서 한번 가볍게 이야기해보려고 한다.

ChatGPT 이후 3년

처음 ChatGPT가 등장한 2022년 말, 사실 필자는 AI가 이렇게 빠르게 발전할 것이라고는 상상하지 못 했다. 당시에는 할루시네이션 이슈도 많았고 무엇보다 출력의 퀄리티 자체가 그리 좋지 않았기 때문이다.

하지만 이제 겨우 3년 정도가 지났음에도 불구하고 우리 개발자의 하루는 상당히 많은 부분이 변화했다.

지금까지의 개발자라는 직업의 정의는 “프로그래밍이라는 행위를 통해 세상의 문제를 해결하는 사람” 정도였던 것 같다. 자연어로 된 요구사항을 분석하고, 설계에 대해 고민하고, 직접 키보드를 타이핑해 구현체를 만들어내는 일련의 과정을 직접 수행했다.

그래서 불과 몇 년 전까지만 해도 아침에 출근하면 에디터를 열고 빈 파일에 커서를 놓는 것으로 하루를 시작했지만, 최근에는 직접 코딩을 하기보다는 AI에게 맥락을 전달하고, 생성된 코드를 읽고, 고치고, 다시 요청하는 것이 하루의 많은 부분을 차지한다.

ChatGPT가 처음 등장한 지 3년 남짓한 시간 동안 변화가 워낙 빨랐기에, 나름 휴대폰과 스마트폰의 등장을 모두 겪어본 아재인 필자도 이렇게 빨리 세상이 바뀔 줄은 상상하지 못했다.

이미 AI 코딩 에이전트의 성능은 단순 보조 수준을 넘어선지 오래다. 프롬프트만 잘 제공하면 함수 하나, 모듈 하나 정도는 사람이 작성한 것과 쉽게 구별하기 어려운 코드를 내놓는다. 이런 환경에서 개발자가 모든 코드를 직접 한 줄씩 작성하는 방식은, 최소한 일부 업무에서는 점점 비효율이 되어가고 있다.

앞으로 변화 속도는 더 빨라질 가능성이 높다. 그리고 이 과정에서 개발자의 역할도 팀과 조직의 맥락에 따라 다르게 재편될 것이다. 그렇다면 지금 우리는 어떤 방향으로 미래를 준비해야 할까?

작성자에서 의사결정권자로

이 질문에 답하려면 먼저 개발 과정에서 우리가 사용하는 시간이 어디에 주로 투자되고 있는지부터 봐야 한다. 예전에는 구현을 위해 직접 타이핑하는 시간이 길었다면 지금은 AI에게 프롬프트로 맥락을 전달하고, 생성된 코드를 읽고 고치고 다시 요청하는 시간이 빠르게 늘어나고 있다.

즉, 코드를 통해 제품을 생산하는 행위는 직접적인 코드 작성에서 점점 “코드에 대한 판단”으로 이동하고 있다. 여기서 판단이란 단순히 AI 출력이 의도대로 됐는지 확인하는 것이 아니라 비즈니스 의도가 기술적 구현으로 올바르게 번역됐는지 검증하는 과정을 의미한다.

물론 AI가 계속 발전하면 코드 리뷰조차 인간이 할 필요가 없어질 수 있다고 생각할 수 있겠지만, 필자 생각은 다르다. 그 이유는 기술적 가능성이 아닌 훨씬 더 근본적인 곳에 있다.

코드에 대한 책임을 질 사람이 필요하다

최근 많은 개발자들이 코드 리뷰에도 AI를 활용하고 있다. 보통 Pull Request에 AI가 코드를 읽어보고 코멘트를 남겨주는 방식으로 작동하는데, 의외로 예리한 부분을 지적하는 경우도 있어서 필자도 가끔 놀란다.

하지만 필자는 기술이 얼마나 발전하든 결국 최종적인 “문제 없음”이라는 승인 도장을 찍는 인간의 역할은 여전히 존재할 것이라 생각한다.

그 이유는 바로 이 질문 때문이다.

과연 코드로 인해 문제가 발생했을 때 누가 책임을 지는가?

AI는 법적으로 인격체가 아니기 때문에 책임을 질 수 없다. 그렇다면 AI가 생성한 코드로 인해 문제가 발생했다면 과연 누가 책임을 져야하는 것인지에 대한 질문을 던져볼 필요가 있다.

만약 AI가 작성한 코드로 인해 결제 로직에 버그가 생겨 고객에게 잘못된 금액이 청구됐을 때 서비스 운영자가 이렇게 답변하면 어떻게 될까?

AI가 작성한거라 전 왜 이렇게 됐는지 모르겠는디요

이딴 답변을 고객이 받아줄리가 없다. 입장바꿔서 생각해보면 아주 복장터지는 일이다.

아무리 AI가 작성한 코드라고 해도 결국 누군가는 “책임”을 져야한다. 그리고 필자가 생각하기에 그 책임을 져야하는 사람은 바로 그 코드를 리뷰하고 승인한 개발자, 그리고 그 개발자가 속한 조직이다.

이러한 방향성은 필자의 뇌피셜이 아니라 이미 여러 규제로 나타나고 있다.

2024년 발효된 EU AI Act는 의료, 금융, 인프라 같은 고위험 영역에서 AI 시스템에 인간 감독을 의무화했다. 시행 자체는 단계적으로 진행 중이지만 방향성 자체는 분명하다. AI가 판단을 내리더라도 이 과정을 인간이 리뷰 가능하도록 만들어야 한다는 원칙을 법으로 못 박은 것이다.

또한 EU 쪽에서는 제품책임 체계를 디지털 제품/소프트웨어까지 포괄하려는 논의도 이어지고 있다. “AI가 만들었으니 우리 책임이 아니다”는 주장이 법적으로 점점 통하기 어려워지는 방향으로 가고 있는 것이다.

규제 뿐 아니라 다른 분야에서 나타난 실제 사례들도 보여지고 있다. 자율주행차는 사고가 나면 책임이 제조사와 운전자에게 돌아간다. FDA 승인을 받은 의료 AI 진단 도구도 최종 판단은 의사가 내려야 한다. 2010년 미국 주식시장에서 알고리즘 트레이딩이 연쇄 폭락을 일으킨 Flash Crash 사건에서도 알고리즘을 포함한 자동화 시스템을 운영하는 주체가 규제/집행의 대상이 된다는 걸 보여준다.

자동화가 고도화될수록 책임 구조는 희미해지는 게 아니라 오히려 더 선명하게 인간 쪽으로 귀속되는 경향이 존재하는 것이다.

그래서 필자는 앞으로 개발자의 역할이 사라지기보다는 코드를 작성하는 사람에서 “코드를 리뷰하고 승인 도장을 찍는 사람”으로 변화하게 될 것이라 생각한다.

결국 개발자의 역할이 사라지는 것이 아니라 무게 중심이 이동하는 것에 가깝다. 코드를 생산하는 방법이 달라졌을 뿐, 최종 코드의 품질이 그것을 리뷰하는 개발자의 역량에 달려 있다는 사실은 변하지 않는다. 그렇다면 이 새로운 구조에서 개발자에게 구체적으로 어떤 역량이 필요해지는 걸까?

AI 시대에 개발자에게 요구되는 역량

아무래도 AI 시대이니 프롬프트를 잘 다루거나 AI 도구에 능숙한 것이 핵심 역량이 될 것 같지만, 필자 생각은 조금 다르다.

뭐 요즘에는 “유명한 개발자 누구처럼 짜줘”라고 하면 알아서 해준다고는 하는데, 반대로 생각해보면 그 프롬프트를 작성할 수 있는 누구나 그렇게 짤 수 있다는 말이다. 거기에 어떤 경쟁력이 있는 것일까.

중요한 것은 그런 프롬프트를 작성하는 것이 아니라, 혹여나 그런 프롬프트를 넣었음에도 불구하고 퀄리티 기준을 충족하지 않는 코드가 출력됐을 경우 문제를 감지할 수 있는 능력이다. 그 프롬프트 넣는다고 무조건 결과물의 퀄리티가 좋은 것은 아닐테니 말이다.

아이러니하게도, 필자는 AI 시대에 개발자에게 요구되는 역량 또한 지금 좋은 개발자에게 요구되는 역량과 크게 다르지 않을 것이라 생각한다.

왜냐하면 리뷰 과정 속에서 인간은 이 코드가 런타임에서 큰 문제가 없을지, 장기적인 변화에 대비할 수 있는 코드인지, 빠진 예외처리는 없을지, 정책에 위반되는 코드는 없는지와 같은 고맥락의 체크 리스트를 확인해야하기 때문이다. 그리고 결정적으로 코드에 대해서 최종적으로 승인 도장을 찍는 사람이 존재한다는 것은 여전히 “인간이 이해하기 쉬운 코드”를 작성해야한다는 것을 의미한다.

만약 인간이 코드를 읽을 필요가 없다면 모든 코드는 기계어로 작성해도 된다. 하지만 만약 이 코드에서 문제가 생기면 여러분이 책임을 져야하는데, 아무리 시대가 발전한다고 해도 그 코드를 읽지도 않고 라이브에 배포할 수 있겠는가?

이 벽을 넘지 못하는 이상, 결국 인간이 코드를 읽고 이해해야하는 상황은 여전히 발생하기 때문에 인간이 이해하기 쉬운 코드란 무엇일지, 어떻게 하면 그런 코드를 작성할 수 있을지와 같은 지금 시대에 개발자들이 고민하고 있는 내용은 AI 시대에도 반복될 가능성이 높다.

장기 변경 비용을 예측하는 역량

최근 링크드인에 올라오는 게시물을 보면, 처음에는 “AI로 이런 거 만들었어요”라는 포스팅만 올라오더니, 요즘에는 간간히 “유지보수가 어려워서 개발자를 고용했습니다”, “기능을 도저히 못 붙히겠어서 접었습니다”와 같은 슬픈 엔딩도 보인다.

이런 일이 발생하는 이유는 AI가 “작동하는 코드”를 만드는데 최적화되어있기 때문이다. 결국 학습 데이터에서 가장 빈번하게 등장하는 패턴을 재현하는 것이 AI의 동작 방식인데, 그 패턴들은 당연히 정상적으로 실행되는 코드들이다. 하지만 지금 당장 작동하는 코드와 6개월 뒤에도 유지보수가 쉬운 코드는 전혀 다른 기준이다.

물론 최근 모델은 유지보수성까지 고려한 답을 제시하는 경우도 늘고 있다. 하지만 필자가 말하고자 하는 핵심은 단일 산출물의 품질과 장기 변경 비용 예측이 다른 문제라는 점이다.

소프트웨어의 품질이라는 건 원래 즉시 드러나지 않는 성질의 것이다. 나쁜 설계의 비용은 코드를 작성한 시점이 아니라, 그 코드를 변경해야 하는 시점에 발생하기 때문이다.

코드를 다각도로 평가하는 역량

나쁜 설계의 비용이 작성 시점이 아닌 변경 시점에 드러난다는 건 AI 등장 이전에도 마찬가지였지만, 코드 생성 속도가 빨라지면서 이 “지연된 비용”이 쌓이는 속도도 함께 빨라졌다는 게 차이점이다.

검수의 대상도 다양하다. 단순히 “이 코드가 맞느냐 틀리느냐”와 같은 기능적 정확성은 테스트로 어느 정도 검증할 수 있다. 더 까다로운 건 구조적 품질이다.

과연 이 모듈의 책임 범위가 적절한가? 이 의존성 방향이 맞는가? 이 인터페이스가 변경에 유연한가? 이런 질문들은 자동화된 테스트로는 잡기 어렵다. 그 너머에는 성능적 함의도 있다. AI가 생성한 코드가 작동은 하지만, 데이터가 10배 늘었을 때도 괜찮을까? 그리고 보안적 측면도 있다. 입력 검증이 충분한가, 권한 확인이 빠져 있지는 않은가. 이 모든 차원을 동시에 고려하면서 코드를 평가하는 건, 단순히 “코드를 읽을 줄 아는 것”과는 다른 수준의 역량이다.

그리고 AI의 생성 속도가 빨라질수록 이 문제는 더 심각해진다.

사람이 직접 코드를 작성하던 시절, 코드 생산량에는 물리적 상한이 있었다. 한 개발자가 하루에 만들어낼 수 있는 코드의 양이 제한되어 있었기 때문에, 팀 전체가 검토해야 할 코드의 규모도 그 속도에 맞춰 조절됐다. 생산 속도와 리뷰 역량 사이에 어느 정도의 균형이 자연스럽게 유지됐던 것이다. 물론 느리게 작성한다고 코드가 더 좋아지는 건 아니지만 생산량이 리뷰 역량을 크게 앞지르기 어려운 구조이기는 했다.

하지만 AI가 수 초 만에 수백 줄의 코드를 생성할 수 있는 환경에서는 코드 생산 속도와 리뷰 역량 사이의 균형이 쉽게 깨질 수 있다.

특히 리뷰 기준, 병렬 리뷰 체계, 자동화 게이트가 충분하지 않다면 코드 양이 두세 배 늘어도 리뷰 인력과 시간은 그대로라 검증 누락이 생기기 쉽다. 그 결과 기술 부채가 더 빠르게 쌓일 가능성이 커진다. 공장의 생산 라인이 빨라졌는데 품질 검사 체계가 그대로인 상황인 것이다.

필자는 아마 많은 회사들이 AI를 도입했음에도 생산성 증가를 못 느끼는 이유가 이것이 아닐까 생각한다. 코드 생산은 빨라졌을지 몰라도 AI가 뱉은 코드를 리뷰하는 과정이 제일 병목이다.

이 구조에서 코드를 제대로 빠르게 검수할 수 있는 개발자의 가치는 자연스럽게 올라간다. AI가 쏟아내는 코드의 양이 많아질수록 그 코드에 섞인 잠재적 위험과 기술 부채를 선별할 수 있는 사람의 필요성이 커지기 때문이다.

추상화 역량

필자는 추상화 역량도 중요한 포인트 중 하나라고 생각한다. 결국 추상화란 복잡한 시스템에서 무엇을 감추고 무엇을 드러낼지, 그리고 어디에 경계를 그을지 결정하는 능력이다.

AI가 추상화를 못하느냐고 물으면 솔직히 그건 아니다. AI도 인터페이스를 정의하고 클래스를 나누고 모듈을 분리할 수 있다. 사실 형식적인 측면에서는 필자보다 잘 하는 경우도 있다. 하지만 AI가 만드는 추상화와 숙련된 개발자가 만드는 추상화 사이에는 결정적인 차이가 하나 있다.

AI의 추상화는 학습 데이터의 통계적 평균에 기반한다. 수많은 프로젝트에서 본 “그럴듯한 패턴”을 현재 상황에 적용하는 방식이다. 하지만 실제 소프트웨어 설계는 정답을 맞히는 게임이 아니라, 한정된 자원과 불확실한 미래 속에서 무엇을 포기할지 결정하는 트레이드오프의 영역이다.

AI는 코드 내부의 정합성을 맞추는 데 능숙할지 몰라도 코드 외부의 맥락까지 고려하여 “어디에 경계를 그을지” 결정하는 것은 어려워한다. 특정 맥락에서 최적인 코드는 통계적 평균 너머의 전략적 판단이 개입될 때 비로소 완성되기 때문이다.

이건 AI의 결함이라기보다는 통계적 학습이라는 방식 자체가 가진 구조적 한계에 가깝다. 평균적으로 좋은 코드를 만들 수는 있지만, 특정 맥락에서 최적인 코드를 만드는 건 다른 문제다.

AI가 출력한 코드의 위험한 점은 겉보기에 좋아 보인다는 것이다. 코드 리뷰에서도 쉽게 통과할 수 있다. 파일이 적절히 나뉘어 있고, 네이밍도 관례를 따르고, 패턴도 익숙하기 때문이다. 문제는 실제로 변경이 필요한 시점에 발견된다. 결제 수단을 하나 추가하려고 하는데, “깔끔하게 나뉘어 있던” 구조의 여기저기를 동시에 수정해야 한다는 걸 그제야 깨닫게 되는 것이다. 이런 종류의 결함은 코드를 쓸 때가 아니라 코드를 고칠 때 드러난다.

AI가 만든 코드에서 이런 패턴은 꽤 자주 발견된다. 통계적으로 가장 흔한 구조를 따랐기 때문에 표면적으로는 나무랄 데가 없지만, 실제 요구사항과 어긋나 있는 경우가 적지 않다.

또 다른 예로, 프론트엔드에서 흔히 보이는 상황을 생각해보자. AI에게 대시보드 컴포넌트를 만들어달라고 하면, 보통은 하나의 거대한 컴포넌트 안에 데이터 페칭, 상태 관리, UI 렌더링을 모두 담은 구조를 내놓는다. 혹은 반대로 학습 데이터에서 본 모범 사례를 과하게 적용해서, 간단한 차트 하나를 그리기 위해 커스텀 훅 세 개와 컨텍스트 프로바이더를 만들어놓기도 한다.

전자는 추상화가 부족한 것이고, 후자는 추상화가 과잉인 것이다. 둘 다 현재 프로젝트의 복잡도 수준에 맞지 않는다는 점에서는 같은 문제다. 적절한 추상화란 결국 현재 상황에서 딱 필요한 만큼의 구조를 만드는 것이고, 이 “만큼”을 판단하는 건 맥락을 아는 사람만 할 수 있다.

숙련된 개발자는 이런 코드를 읽을 때 “여기서 이렇게 나눈 건 이 도메인의 특성을 모르고 한 거구나”라는 걸 알아채고 도메인에 맞는 경계를 다시 긋는다. 이 과정에서 동원되는 건 코딩 스킬이 아니라 시스템에 대한 이해와 설계에 대한 감각이다.

즉, AI가 만든 코드를 평가할 때도 사람이 만든 코드를 평가할 때와 동일한 기준이 적용된다. “이 추상화가 실제로 복잡도를 줄이고 있는가, 아니면 추적해야 할 간접 경로만 늘리고 있는가?” 이 질문을 던질 수 있는 것 자체가 이미 하나의 역량이다.

암묵지를 명시화할 수 있는 역량

추상화 역량이 “어디에 경계를 그을지 아는 것”이라면, 암묵지를 명시화하는 역량은 “왜 거기에 경계를 그어야 하는지 설명할 수 있는 것”이다. 서로 다른 능력이지만 실제로는 함께 작동한다.

좋은 코드와 나쁜 코드를 구분하는 감각은 코드를 많이 읽고 쓰면서 자연스럽게 체득하게된다. 보통 “뭔가 이상한데”라는 직감으로 시작되는 암묵지는 언어로 명확하게 설명하기가 꽤나 어렵다.

그런데 이 암묵지를 언어로 만드는 능력이 AI 시대에 특히 중요해진다. “뭔가 이상한데”라는 직감을 “이 함수는 두 가지 책임을 가지고 있다”, “이 인터페이스가 변경에 취약하다”는 구체적인 언어로 바꿀 수 있어야 AI에게 올바른 명령을 내릴 수 있기 때문이다.

다만 여기서 말하는 건 few-shot 예시나 chain-of-thought 같은 형식적인 프롬프트 기법이 아니다. 어차피 그런 것들은 모델이 발전하면서 자연스럽게 희석된다.

필자가 이야기하고 싶은 건 그 아래에 있는 능력, 즉 무엇을 만들어야 하는지 명확하게 정의하고, 어떤 맥락이 중요한지 판단해서 전달하는 것이다.

대충 “이걸 만들어줘”라고 말할 수 있는 사람은 많다. 하지만 개발자는 AI가 뱉은 코드의 문제점을 정확하게 파악하고 “이걸 이런 방식이 아니라 저런 방식으로 만들어야 하는 이유”를 설명할 수 있는 사람이 되어야한다.

“뭔가 이상한 코드”를 보고 그 이유를 구체적으로 알고 말할 수 있는 것이 곧 개발자의 설계 역량이 될 것이다. 즉, 시스템과 코드에 대한 이해가 깊을수록, AI에게 더 구체적이고 더 정확한 지시를 내릴 수 있다.

메모리를 직접 다루지 않아도 메모리 모델을 이해해야 성능 문제를 해결할 수 있듯이, 코드를 직접 작성하지 않아도 추상화를 이해해야 설계 문제를 잡아낼 수 있다. 추상화의 계층이 하나 더 생겼을 뿐, 추상화를 다루는 능력의 필요성 자체는 사라지지 않았다.

이 역량들의 유효기간은 도구 숙련도보다 훨씬 길다. 도구 숙련도의 수명은 도구의 교체 주기에 묶여 있다. jQuery가 React에 밀리는 데 몇 년이 걸렸고, Webpack이 Vite에 밀리는 데 또 몇 년이 걸렸다. 반면 설계 판단과 암묵지 언어화 역량의 수명은 소프트웨어의 본질적 복잡성이 존재하는 한 유효하다.

이 복잡성은 도구가 바뀌어도 사라지지 않는다. 결제 시스템이 복잡한 이유는 프레임워크 때문이 아니라 결제 도메인 자체가 복잡하기 때문이고, 그 복잡성을 다루는 감각은 특정 도구에 종속되지 않는다.

의도적 수련 설계의 필요성

여기까지 읽으면 자연스럽게 떠오르는 질문이 하나 있다. 코드를 직접 작성하는 시간이 줄어드는데, 도대체 추상화나 설계 감각은 어떻게 기르라는 걸까?

이건 “도구가 할 수 없는 것에 집중하라”고 말하면서 정작 그것을 기를 기회가 줄어드는 모순적인 상황이다.

해법은 두 층으로 나뉜다. 하나는 업무 흐름 안에서 AI에게 넘기지 말아야 할 두 지점을 지키는 것이고, 다른 하나는 그 판단력의 바탕이 되는 설계 감각을 업무 밖에서 의도적으로 유지하는 것이다. 그리고 이 두 가지를 관통하는 태도가 하나 있다.

AI에게 넘기지 말아야 할 두 지점: 설계와 리뷰

평소 업무 흐름 안에서 AI에게 넘기지 말아야 할 지점이 두 군데 있다. 바로 코드 작성 앞단의 설계와 뒷단의 리뷰다.

설계를 직접 하는 것은 단순한 습관의 문제가 아니다. 프롬프트를 치기 전에 “이 모듈이 외부에 노출할 인터페이스는 무엇인가”, “책임의 경계는 어디에 그을 것인가”를 먼저 정의하는 과정을 거치고 구현을 AI에게 위임하면, AI가 만들어낸 결과물을 자신의 설계 결정과 비교할 수 있게 된다.

AI가 다른 구조를 선택했다면 왜 그랬는지 분석하게 되고, 내가 놓친 것은 없는지, AI가 틀린 것은 아닌지 다시 생각하게 된다. 만약 이 과정이 부재한다면 단순히 AI가 출력한 코드를 소비하게 될 가능성이 높은데, 단순히 출력을 소비하는 것과 자신의 판단을 기준으로 출력을 평가하는 것은 완전히 다른 경험이다.

또한 리뷰는 의도적으로 시간을 따로 내지 않아도 업무 흐름 안에서 자동으로 주어지는 역량 성장 기회다. 그렇기 때문에 이 기회를 그냥 흘려보내는 것이 가장 위험하다.

AI에게 PR 리뷰를 맡기고 별다른 문제가 없으면 그냥 승인해버리는 습관은 마치 체육 시간에 운동장에 나가서 벤치에만 앉아 있다가 들어오는 것과 같다. 업무 자체는 어찌어찌 진행할 수 있겠지만, 그렇게 몇 년을 일을 해도 실력은 그대로일 가능성인 높다.

코드 리뷰는 요구사항, 설계 의도, 비즈니스 맥락을 동시에 고려하면서 코드를 읽는 과정이고, 이 과정 자체가 설계 감각을 유지하는 훈련이라고 생각해야한다.

의도적으로 직접 짜보는 시간

업무 안에서 설계와 리뷰를 직접 한다고 해서 충분한 건 아니다. 설계 감각 자체가 구현의 고통을 알아야 생기기 때문이다. 어떤 구조가 변경에 취약한지를 직접 손으로 겪어봐야 “이 추상화가 잘못됐다”는 직감이 생긴다. 겪어보지 못한 고통은 감각으로 남지 않는다.

주니어 개발자의 경우 특히 그렇다. 경험이 적은 상태에서 AI가 생성한 코드를 리뷰하는 건, 아직 운전을 배우는 중인 사람에게 자율주행차의 판단을 평가하라고 하는 것과 비슷한 면이 있다. 직접 핸들을 잡아봐야 도로 위의 감각이 생기는 것처럼 직접 코드를 짜봐야 구조에 대한 감각이 생긴다.

미래의 개발자에게 코딩하는 역량은 매일 하는 업무가 아니라 판단력을 유지하기 위한 훈련이 될 가능성이 높다고 본다. (아마 주니어 시절의 고통스러운 직접 구현 경험은 선택이 아니라 리뷰어로서 면허를 따는 과정 정도가 되지는 않을까.)

그래서 사이드 프로젝트나 개인 학습에서는 의도적으로 AI를 내려놓고 처음부터 끝까지 직접 구현해보는 시간을 만드는 게 좋다.

AI가 편리할수록 그 마찰이 귀찮게 느껴지지만 그 마찰과 고통을 겪어야 빠른 실력 향상이 생길 것이라고 생각한다. 그리고 구현이 막히는 지점이나 리팩토링을 해야 하는 순간이 깨달음을 얻을 수 있는 순간이다.

두 가지를 관통하는 태도: “왜”를 언어화하는 연습

업무에서 설계와 리뷰를 직접 하든, 따로 시간을 내서 직접 짜든 이 두 가지 모두에서 작동해야 하는 태도가 있다. 바로 “뭔가 이상한데”라는 직감이 드는 순간 그 감각을 그냥 넘기지 않고 왜 그렇게 느꼈는지 명확한 말로 표현할 수 있을 때까지 다듬는 것이다.

“이상한데”에서 멈추면 그냥 직감에서 끝나버리지만, “이 함수가 두 가지 책임을 가지고 있다”까지 가면 언어가 된다. 직감은 나만 아는 것이고 언어는 쓸 수 있는 것이다. 언어가 되어야 AI에게 정확한 지시를 내릴 수 있고, 팀원에게 설명할 수 있고, 다음에 비슷한 패턴을 만났을 때 알아챌 수 있다.

AI가 만들어낸 코드가 작동한다고 해서 거기서 멈추지 않고, “왜 이 구조를 선택했을까”, “다른 구조였다면 어떤 트레이드오프가 있었을까”를 스스로에게 물어보는 것. 이 습관이 있는 개발자와 없는 개발자 사이의 격차는 시간이 갈수록 벌어질 것이다.

결국 본질은 변하지 않았다

AI의 등장으로 개발자의 역할이 코드 작성자에서 리뷰어로 이동하고 있다. 생산과 검수를 모두 인간이 하던 시대에서 생산은 AI가 하고 검수는 인간이 담당하는 시대로 변화하고 있는 것이다.

그리고 이러한 변화가 기술적 한계가 아닌 책임 소재라는 사회적 문제에서 비롯된다는 걸 이해하면 역할 전환의 의미가 더 명확해진다.

결국 필자는 리뷰 승인이라는 도장을 잘 찍으려면 작동하는 코드와 오래 살아남는 코드를 구분하는 눈, 맥락에 맞는 추상화를 판단하는 설계 감각, 그 감각을 언어로 만들어 정확한 방향을 잡는 역량이 필요해질 것이라 생각한다.

즉, AI 시대의 차이는 생산량이 아니라 누가 맥락을 이해하고 책임 있게 승인하느냐에서 난다. 시대는 변화했지만 결국 개발자라는 사람이 책임져야하는 영역이 코드의 퀄리티라는 사실은 변하지 않는 것이다.

AI가 이전 도구들과 근본적으로 다른 것은 사실이다. 농기구나 기계와 달리 AI는 스스로 추론하고 생성한다. “AI도 그냥 또 하나의 도구야”라는 식의 주장이 설득력을 잃는 건 당연하다. 그렇다면 왜 요구되는 역량이 바뀌지 않는다고 할 수 있을까.

논리는 책임에서 시작한다. 책임을 진다는 건 판단을 한다는 뜻이고, 판단의 질은 코드의 구조적 건강함을 알아보는 눈, 도메인에 맞는 추상화를 구분하는 감각, 장기 변경 비용을 예측하는 능력에서 온다. 이것들이 항상 좋은 개발자와 평범한 개발자를 갈랐던 것들이다.

프레드 브룩스(Fred Brooks)는 1986년에 소프트웨어의 복잡성을 두 가지로 나눴다. 우발적 복잡성은 도구의 한계에서 오는 것이고, 본질적 복잡성은 문제 자체에 내재된 것이다. AI가 해결하는 건 우발적 복잡성이다. 보일러플레이트, 반복 패턴, 문법 오류 같은 것들. 하지만 비즈니스 요구사항의 모호함, 상충하는 설계 목표 사이의 균형, 미래 변경 방향에 대한 불확실성 같은 본질적 복잡성은 AI가 아무리 발전해도 사라지지 않는다. 이 복잡성은 도구의 수준이 아니라 문제 자체의 성격에서 온다.

그래서 AI의 성격이 이전 도구들과 달라도 인간이 판단과 책임의 주체로 남아 있는 한 그 판단에 필요한 역량의 본질은 바뀌지 않는다. 필자는 오히려 코드 생산이 자동화될수록 그 생산물을 검수하는 판단력의 비중이 오히려 부각될 것이라 생각한다.

필자와 함께 일하는 코치 중 한 분은 이 상황을 빗대어
"물이 빠지면 비로소 누가 발가벗고 수영을 하고 있었는지 알 수 있을 것"이라고 했는데
아주 찰떡인 비유인 것 같다.

그래서 필자는 최근 많은 사람들이 AI라는 도구를 잘 깎는 것에 집중하는 것을 보면서 뭔가 조금 이상하다는 생각을 했었다.

불과 1년 전만해도 프롬프트 엔지니어링이 굉장히 중요한 화두였지만 지금은 그 얘기는 쏙 들어가고 스킬, 병렬 에이전트, 팀과 같은 기능들에 대한 이야기가 오간다. 아마 6개월만 지나도 이 키워드들도 쏙 들어갈 것이다.

어차피 AI는 길가는 초등학생이 프롬프트를 갈겨도 제대로된 출력을 낼 수 있는 수준까지 발전할텐데, 지금 도구를 잘 사용하는 방법에 집중하는 것이 정말 옳은 방향일까? 오히려 필자는 도구를 잘 깎는 것에만 집중하면 도태되기 쉬워지지는 않을까 하는 생각을 가지고 있다.

물론 필자가 그리는 미래가 실제로 그렇게 펼쳐질지는 모른다. AI가 어느 방향으로 얼마나 빠르게 발전할지 정확히 아는 사람은 없고, 필자도 예외가 아니다. 이 글도 결국 불확실한 미래를 앞에 두고 한 명의 개발자가 지금 할 수 있는 생각을 정리해본 것일 뿐이다.

정답은 없지만, 물이 빠지는 속도 만큼은 분명히 빨라지고 있다. 이 글을 읽는 독자 분들도 물이 빠졌을 때 발가벗고 수영을 하고 있는 사람이 되지 않도록 최선을 다해 각자만의 답을 찾아보기를 바란다.

Beyond Functors, All the Way to Monads

Sat, 07 Feb 2026 21:25:09 GMT

In this post, I’ll continue from the concept of functors I covered previously and move on to explaining monads.

When people hear “monad,” the first thing that usually comes to mind is the infamous explanation: “A monad is a monoid in the category of endofunctors, blah blah blah.” While this is technically the most accurate description of a monad, it’s also the most unhelpful one.

There’s even a well-known meme called the “monad curse” — the idea that the moment you understand monads, you lose the ability to explain them. For those of us who aren’t deeply versed in mathematics, monads are indeed a notoriously elusive concept.

With that in mind, I’m going to take my own ambitious crack at explaining monads. (Of course, I might fail…)

What We Covered in the Previous Post

Since the previous post was written a full six years ago, let me briefly recap its content before moving on. For the full details, refer to the previous post.

Despite all the complexity and lengthy explanations, the core idea is simple. In the world of functional programming, to compose functions, the output type of the first function must match the input type of the next function.

The problem is that the programming world is full of uncertainties and side effects — null, undefined, errors, and so on — making it difficult to follow this rule.

function getFirstLetter(s: string): string | undefined {
  return s[0];
}

function getStringLength(s: string): number {
  return s.length;
}

// Since getFirstLetter's codomain is string | undefined,
// it can't be directly composed with getStringLength
getStringLength(getFirstLetter(''));

To solve this problem, we introduced the concept of wrapping values and side effects in a container, and that container was the functor.

A functor is a structure that can safely transform the value inside a container without extracting it, through an operation called map.

map: F<A> → (A → B) → F<B>

This type signature means that if you pass a computation (A → B) that transforms the internal value to the map operation of a functor F<A>, the result is F — the internal value has been transformed.

Here, even though the internal value of F<A> and F may differ, the structure itself must not change, which is why a functor must satisfy the following two laws:

Identity law: $F(\text{id}) = \text{id}$
Composition law: $F(g \circ f) = F(g) \circ F(f)$

$id$ is the identity function that returns its argument unchanged. The identity law says that applying map with this identity function should result in nothing happening.

The composition law means that mapping a composed function should produce the same result as mapping each function separately and then composing.

These laws exist because they guarantee that a functor is “a mapping that preserves structure.” It’s not mathematical obsession — there are real practical reasons.

If the identity law holds, we can trust that a.map(x => x) truly does nothing. But if the internal structure — like the order of a list or the height of a tree — were altered in the process, that’s no longer mapping; it’s “reconstruction.” The identity law is what lets you trust that a functor only touches the contents, never the wrapper.

And if the composition law holds, we’re guaranteed that a.map(f).map(g) produces the same result as a.map(x => g(f(x))).

This guarantees that a.map(f).map(g), which loops twice, can be collapsed into a.map(x => g(f(x))) with a single loop and produce the same behavior. Conversely, it also means it’s safe to split complex logic into multiple map calls for readability.

But even functors have their limits. It’s precisely these limitations that lead us to the monad we’ll explore today.

The Limits of Functors

In 1988, computer scientist Eugenio Moggi at the University of Edinburgh was wrestling with a thorny problem. While working on denotational semantics — the study of defining the meaning of programs mathematically — he was pondering how to bridge the gap between pure lambda calculus and real-world programs.

In pure lambda calculus, the type $A \to B$ means “a total function that takes input A and returns B.” Mathematically clean, but real programs don’t work that way.

Programs can fall into infinite loops, throw exceptions, modify state, or read files. Treating programs that produce these “effects” as pure functions $A \to B$ distorts their meaning.

So Moggi’s starting point was to view programs not as $A \to B$ but as $A \to T(B)$ . Here, $T$ is a structure that captures the “notion of computation,” and $T(B)$ means “a computation that produces a value of type B.” It represents not the value itself, but a computation that produces the value, as a type.

This is easier to understand with concrete examples. Familiar computations include:

$A \to \text{Maybe}(B)$ : a computation that might fail
$A \to \text{IO}(B)$ : a computation that interacts with the outside world
$A \to \text{State}(B)$ : a computation that modifies state

But this approach introduced another problem: composing functions of the form $A \to T(B)$ became tricky. If the first function is $A \to T(B)$ , then the second would be $B \to T(C)$ , but the output of the first function, $T(B)$ , doesn’t match the input of the second, $B$ .

Moggi discovered that a structure solving this composition problem had already been studied in category theory — and that’s how monads entered functional programming.

The word “monad,” borrowed from mathematics, became one of the most feared words in computer science.

Why Can’t Functors Solve This?

So why couldn’t Moggi’s problem be solved with functors alone? We encounter two critical bottlenecks that the functor’s map cannot resolve.

First, consider the case where a function gets trapped inside the computational context $T$ . A typical example that produces this situation is currying.

const maybeA: Maybe<number>;
const maybeB: Maybe<number>;

const add = (a: number) => (b: number) => a + b;

const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;

Can we use the functor’s map to apply the add operation to maybeA and produce a function waiting for the next argument? The answer is no. Because the result of applying the operation through the functor’s map isn’t just a plain function.

const addA = map(maybeA, add);

// Substituting into map's type signature...
map<number, (b: number) => number>(
  maybeNumber: Maybe<A>,
  add: (a: number) => (b: number) => number
): Maybe<(b: number) => number>

Normally, with a curried function, addA should have the type (b: number) => number. But here, since we applied the operation through map, the result is Maybe<(b: number) => number>. The function is trapped inside the computational context.

The problem is that once this happens, we can’t continue composing with the functor’s map, which only accepts bare functions. map can apply a function from outside the context to a value inside the context, but it has no way to take a function trapped inside a context and apply it to a value inside another context.

This is fundamentally because the functor’s map only operates on the outermost function when given a curried function. When a function returns another function, map can’t reach the inner one.

The other problem arises when composing two functions that each return a functor. Let’s look at another example using the Maybe functor, which represents “a value that may or may not exist.”

const findUser: (id: number): Maybe<User>;
const findTeam: (user: User): Maybe<Team>;

These are functions of the form Moggi envisioned — taking an input $A$ and returning a computation $T(B)$ .

findUser takes a user ID and returns a User. We use the Maybe functor because if an invalid ID is provided, there may be no matching user. And findTeam takes a User and returns their team. We want to compose these two functions to create a function that finds a user’s team.

The problem is that findTeam can’t directly accept the Maybe<User> returned by findUser.

But we can try composing them using the functor’s map. Let’s give it a shot.

map(findUser(1), findTeam);

// Substituting into map's type signature...
map<User, Maybe<Team>>(maybe: Maybe<User>, f: (a: User) => Maybe<Team>): Maybe<Maybe<Team>>

We managed to compose them, but the resulting type is Maybe<Maybe<Team>> — a rather sad outcome. If we were to add one more step to find the team leader from the team information, the type would become Maybe<Maybe<Maybe<Manager>>>, nesting infinitely.

Let’s Take Stock

Following Moggi’s problem, we’ve encountered two issues that functors can’t solve.

Problem	Cause	What’s Needed
Applying a function inside a context	`map` only accepts functions from outside	An operation that applies an inner function to an inner value
Context nesting	`map` only peels one layer	An operation that flattens double context into single context

I thought functors could solve everything, but that turned out to be far from true

Problems are meant to be solved. Now we’re going to sketch out the design for these, step by step.

The first problem — a function trapped inside a context — can be solved by an Applicative Functor. And the problem of contexts nesting every time we compose functions — that’s what the Monad solves.

Designing the Solution: Applicative Functors and Monads

Now we need to invent a new operation to solve the first problem. From here on, the phrase “computational context” is too long, so let’s simply call it a “container.”

The first problem was a function being trapped inside a container, so we need an operation that can apply this function to a value inside another container.

// Apply a function inside a container to a value inside another container
apply: T<(A → B)> → T<A> → T<B>

The only difference between this operation and the functor’s map is whether the function being applied is outside or inside the container. We call this operation apply.

We also need an operation that puts a value back into a container after applying the function. This is called the pure operation.

// Put a pure value into a container
pure: A → T<A>

A functor equipped with both apply and pure is called an Applicative Functor. Let’s express these operations as TypeScript type signatures using the familiar Maybe container as an example.

const apply: <A, B>(maybe: Maybe<A>, f: Maybe<(a: A) => B>): Maybe<B>
const pure: <A>(value: A) => Maybe<A>

Now let’s use this applicative functor to compose the curried function from our earlier problem.

const maybeA: Maybe<number>;
const maybeB: Maybe<number>;

const add = (a: number) => (b: number) => a + b;

const maybeAddA = map(maybeA, add); // Maybe<(b: number) => number>;

apply(maybeB, maybeAddA); // Maybe<number>

// Substituting into apply's type signature...
apply<number, number>(
  maybe: Maybe<number>,
  f: Maybe<(b: number) => number>
): Maybe<number>

With the applicative functor’s apply operation, the problem of working with multiple containers like maybeA and maybeB just… solves itself.

The Limits of Applicative Functors

But the problem we solved comes with an important premise: which containers to compose must be known in advance.

Think back to the applicative functor’s apply operation. maybeA and maybeB are independent containers that are already in our hands before computation begins. In other words, the structure of the computation is fixed regardless of the values.

But real-world programs are far more dynamic. More often than not, you need to look at the result of the previous computation before deciding which container to fetch next — or whether to fetch one at all.

// Find a user, then find their team based on user information.
// The team-finding function produces different results depending on who the user is.
findUser(1).fn(user => findTeam(user.teamId))

Here’s where another problem arises. The Maybe container returned by findTeam is created depending on the value user. In other words, the result of the previous computation determines the context of the next.

Applicative functors can only facilitate communication between containers that already exist, so they can’t express sequential dependencies that are dynamically created at runtime.

Static	Dynamic
“Fetch A and B separately and combine them”	“Fetch A, then decide whether to do B based on the result”

To handle dynamically created sequential dependencies, you have to use the result of the previous computation to create the next one. And in that process, containers will inevitably nest.

Oh, what if we had an operation that flattens nested containers?

Applicative functors used a new operation called apply to execute functions inside containers. But if we had a tool that flattens nesting, we wouldn’t need the cumbersome step of executing a function inside a new container — we could solve the problem without it.

const maybeA: Maybe<number>;
const maybeB: Maybe<number>;
const add = (a: number) => (b: number) => a + b;

// If we have something that flattens nesting, we can solve it with just map!

// 1. Mapping a curried function produces a function inside a container
const maybePartialFn = map(maybeA, add);
// Result: Maybe<(b: number) => number>

// 2. Use map to access the function inside the container and perform computation
const nested = map(maybePartialFn, fn => map(maybeB, fn));
// Result: Maybe<Maybe<number>>

// 3. Then flatten the nesting?
const result = flattener(nested);
// Result: Maybe<number>

Just compose and let things nest, then flatten afterward.

Monads: Inventing the Flatten Operation

And that’s exactly what monads are for. A monad is something that has an operation for flattening nested containers.

This flattening operation is called join or flatten.

join: T<T<A>> → T<A>

const join: <A>(maybe: Maybe<Maybe<A>>) => Maybe<A>

The join operation turns Maybe<Maybe<A>> into Maybe<A>. Mathematically, it “reduces two applications of $T$ down to one.”

This kind of operation is actually easy to find in our daily work — JavaScript’s Array.prototype.flat does exactly this.

And just like the applicative functor, we also need an operation that puts a pure value into a container. As with applicative functors, this is called pure, or sometimes of.

pure: A → T<A>

const pure: <A>(value: A) => Maybe<A>

But in practice, you rarely use join directly. As we saw in the earlier example, the monad works as a set: use map to access something inside the container and compose, then use join to flatten the nesting.

1. You want to apply a function to the value inside a container = use map
2. But that function returns its result wrapped in a container = double wrapping occurs
3. You need to unwrap the double wrapping = use join

So we want to combine these two operations into one for convenience.

flatMap = map + join

Since calling map followed by join every time is tedious, we combine these two steps into flatMap. Let’s see what the type signature looks like for a flatMap that takes our familiar Maybe container.

map:     T<A> → (A → B)    → T<B>     // Apply a regular function
flatMap: T<A> → (A → T<B>) → T<B>     // Apply a container-returning function + flatten

const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;
const flatMap: <A, B>(maybe: Maybe<A>, f: (a: A) => Maybe<B>): Maybe<B>

The difference between map and flatMap is in the second argument. map takes a simple A => B function, while flatMap takes an (A => Maybe) function.

Although it’s not visible in the type signature, flatMap internally performs the role of join as well, so the result type isn’t the sad Maybe<Maybe> but simply Maybe.

Now we can use flatMap to express sequential dependencies between computations.

// Using map results in a nested type
findUser(1).map(user => findDepartment(user.deptId));
// Maybe<Maybe<Department>>

// Using flatMap solves it
findUser(1).flatMap(user => findDepartment(user.deptId));
// Maybe<Department>

So far, we’ve covered the functor’s map, the applicative functor’s apply, and the monad’s flatMap. There was a lot of ground to cover, so let’s recap before moving on.

// Functor's map
const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;

// Applicative Functor's apply
const apply: <A, B>(maybe: Maybe<A>, f: Maybe<(a: A) => B>): Maybe<B>

// Monad's flatMap
const flatMap: <A, B>(maybe: Maybe<A>, f: (a: A) => Maybe<B>): Maybe<B>

First, map is the one that applies a regular function to a value inside a container. But this alone can’t handle functions trapped inside the container.

So apply appeared. apply makes it possible to access functions inside a container, enabling composition even in these situations. But when performing dynamic computations with sequential dependencies, containers kept nesting.

To solve this, join — which flattens nested structures — was combined with the functor’s map to create flatMap. Through this operation, we can now freely compose computations with sequential dependencies, where each result determines the next computation.

Laws Are Proofs About Refactoring

So is flatMap really the magic that lets us safely compose functions? Well, to claim this with confidence, flatMap must satisfy a few laws.

The Three Laws

To use flatMap freely, we need the guarantee that this operation upholds the following laws.

Associativity: It Shouldn’t Matter Which Layer You Flatten First

First is the associativity law. It means that when flattening nesting, the result should be the same regardless of which side you flatten first. Imagine a container wrapped in three layers, like Maybe<Maybe<Maybe<A>>>.

We need to flatten this container down to the $T(A)$ form.

T(T(T(A))) \to T(T(A)) \to T(A)

There are two ways to flatten this to a single layer. The first is to merge the inner two $T$ s first, then peel off the remaining outer $T$ to get $T(A)$ . The second is to merge the outer two $T$ s first, then peel off the remaining inner $T$ .

Regardless of which order you perform the operations, the final result $T(A)$ must be the same. That’s the associativity law.

\mu \circ T\mu = \mu \circ \mu T

m.flatMap(f).flatMap(g) === m.flatMap(x => f(x).flatMap(g))

In the formula above, $\mu$ (mu) represents join.

Here, $T\mu$ means “merge the inner two layers,” and $\mu T$ means “merge the outer two layers.” Think of it like a three-layered matryoshka doll being reduced to two layers — it shouldn’t matter whether you merge the inner dolls first or the outer dolls first.

Left Identity: Don’t Mess with the Entry Point

Second is the left identity law. This means that putting something in and immediately taking it out should be the same as doing nothing.

\mu \circ T\eta = \text{id}

pure(a).flatMap(f) === f(a)

In the formula above, $\eta$ (eta) represents pure.

Pay special attention to the $T$ in front of $\eta$ ( $T\eta$ ) — it means applying pure not outside the container but to a value already inside one.

In other words, given a container $T(A)$ , if you wrap the inner value $A$ with pure to create a double structure $T(T(A))$ , and then flatten it back with join ( $\mu$ ), you should arrive back at the original state ( $\text{id}$ ).

This law must hold for us to trust pure as the minimal unit of computation inside a container. If the left identity law were broken, it would mean pure is doing more than simply wrapping a value — it would be transforming the internal logic.

Right Identity: If You Only Changed the Wrapping, the Contents Should Stay the Same

Third is the right identity law. It’s similar to the left identity law, but the order of wrapping is reversed.

\mu \circ \eta T = \text{id}

m.flatMap(pure) === m

Here, $\eta T$ means treating the existing container $T(A)$ as a single value and wrapping its outside with pure ( $\eta$ ) one more time. The result is $\eta(T(A))$ , creating a double structure $T(T(A))$ .

What the right identity law says is straightforward. If you wrap the outside of a container with one more layer of pure ( $\eta T$ ) and then peel that outer layer back off with join ( $\mu$ ), you should end up right back where you started ( $\text{id}$ ).

As mentioned earlier, these identity laws are important because they guarantee that pure is a neutral identity element that doesn’t distort the context.

Just as adding $0$ to a number doesn’t change the value, wrapping a container with pure and then flattening it should have no effect whatsoever on the original information or state of that container.

Back to “A Monoid in the Category of Endofunctors”

So how does all this relate to the Wikipedia definition of a monad as “a monoid in the category of endofunctors”?

From here on, the discussion gets more abstract and mathematical, so readers who are satisfied with a practical-level understanding of monads can skip ahead.

But it's great exercise for the brain, so I still recommend reading through it

Monads weren’t handed down from mathematicians with the instruction “use this.” Engineers needed a safe way to compose functions, so they invented these tools out of necessity.

Invention	Description	Examples
$T$	A type constructor that takes a type and creates a new type	`Maybe<A>`, `Array<A>`, …
$\eta$ (eta)	An operation that puts a value into a container	`pure`, `Promise.resolve`, …
$\mu$ (mu)	An operation that flattens nested containers into a single container	`join`, `flatten`, …

And to use these operations safely, we said they must satisfy the three laws we examined (associativity, left identity, right identity). Now, analyzing this structure mathematically leads us to a very interesting destination.

Category: A World of Objects and Arrows

A category is a structure composed of objects and morphisms (arrows) between them. Personally, I find the word “category” more natural than the Korean translation, so I’ll stick with “category” going forward.

From a TypeScript perspective, the most familiar category is the category of types. In this category, the objects are types like number and string, and the morphisms are functions like (a: number) => string — computations that go from one object to another.

For a detailed treatment of categories and functors, see the previous post.

Endofunctor: A Functor That Stays Within the Same World

The “category of endofunctors” in the definition of a monad refers to a category made up of endofunctors.

As I briefly noted in the previous post, a functor is a mapping that takes one category to another. A general functor maps from category $C$ to a different category $D$ , but an endofunctor maps from $T: C \to C$ — meaning the source and destination are the same category.

Why is a monad an object in the “endofunctor category”? Because the functors we use in programming ultimately stay within the programming world. Consider the functor’s map operation, for example.

const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;

Looking at this type signature, map takes A and produces B. The key point is that A is a type in TypeScript’s type system, and the result type Maybe is also a type in TypeScript’s type system.

It goes from the world of types to the world of types. That’s why functors in programming are endofunctors. They don’t go to another world — they transform within the same one.

The Endofunctor Category: A World Where Functors Themselves Are Objects

Now let’s step up one level of abstraction. If we know that functors used in programming are endofunctors, we can conceive of a new category where endofunctors themselves are the objects.

	Regular Type Category	Endofunctor Category
Objects	`number`, `string`, …	`Maybe`, `Array`, `Promise`, …
Morphisms	`(a: A) => B`	Functor → Functor

Since morphisms in a category go from one object to another, morphisms in the endofunctor category go from one functor to another.

A morphism that transforms one functor into another is called a Natural Transformation.

Monoid Object: The Algebra of Combining

Now that we’ve covered the “category of endofunctors” part of the definition, let’s look at what it means to be a “monoid object.”

In mathematics, a monoid is a structure equipped with the following three things:

A set or collection of objects
A binary operation: combines two elements to produce an element within the same set. Must satisfy associativity.
An identity element: a special element that, when combined with any other element, returns that element unchanged.

The concept is abstract enough to feel intimidating, but the examples aren’t that complicated. The most classic monoid is the relationship between integers and addition.

With integers and addition, the addition operation takes two elements from the set of integers and returns another integer. Just like $1 + 2 = 3$ . And as you already know, addition satisfies the associativity law. Finally, the identity element — the number that returns any integer unchanged when added — is $0$ .

This is why the set of integers paired with addition can be called a “monoid,” and mathematically it’s denoted as $(\mathbb{Z}, +)$ . (Strictly speaking, integers under addition also have inverses, making it a group, but that’s not important for this explanation.)

The Connection: A Monad Is a Monoid Object in the Category of Endofunctors

Now that we understand what a monoid is, we can finally understand what “a monoid object in the category of endofunctors” means.

The endofunctor category is a category composed of programming functors like Maybe and Promise, so we just need to check whether these objects form a monoid structure.

Let’s compare the relationship between integers and addition — our representative monoid — with the relationship between endofunctors and their composition operation.

Monoid Element	Integer Addition	Endofunctor Category
Binary operation	`+` ( $1 + 2$ )	Composition `∘` ( $T \circ T$ )
Result of operation	Integer	Endofunctor
Identity element	`0`	Identity functor `Id`

The comparison looks roughly similar. But there’s one problem: the result of the endofunctor binary operation $T \circ T$ isn’t $T(A)$ but $T(T(A))$ — a nested result. In other words, it’s not an element within the same set.

This is exactly where the monad’s join ( $\mu$ ) and pure ( $\eta$ ) that we defined earlier come in.

Operation	Expression	Description
`join` ( $\mu$ )	$T \circ T \Rightarrow T$	A natural transformation that merges two layers of T into one
`pure` ( $\eta$ )	$\text{Id} \Rightarrow T$	A natural transformation from the identity functor to T

A natural transformation is a “structure-preserving transformation between functors.” It’s important that pure isn’t simply “putting a value in a container” but a natural transformation. This means pure must behave consistently for any type $A$ — it cannot behave differently depending on the type.

And if we revisit the monad laws from earlier, we can see that they satisfy the associativity and identity element laws that a monoid requires.

Law	Expression	Description
Associativity	$\mu \circ T\mu = \mu \circ \mu T$	Same result regardless of merge order
Identity law	$\mu \circ T\eta = id = \mu \circ \eta T$	Wrapping and unwrapping returns the original. i.e., $\eta$ is the identity element.

The laws we established for programming turn out to be exactly what a monoid requires.

	Monoid of Integers	Monoid in Endofunctor Category (= Monad)
Object	Integer	Endofunctor (`Maybe`, `Array`, …)
Binary operation	$+$	`join` ( $\mu$ ) ( $T \circ T \Rightarrow T$ )
Identity element	$0$	`pure` ( $\eta$ ) ( $\text{Id} \Rightarrow T$ )
Associativity	$(a+b)+c = a+(b+c)$	$\mu \circ T\mu = \mu \circ \mu T$
Identity law	$0+n = n = n+0$	$\mu \circ \eta T = \text{id} = \mu \circ T\eta$

This is why we can call the monads we use in programming “a monoid object in the category of endofunctors.”

But as I mentioned, this definition isn’t why we started using monads in programming. We just needed to compose computations with effects sequentially, invented join and pure to do it, and then noticed that what we’d built happened to match “monoid” — a structure mathematicians had known about for centuries.

Actually, Monads Aren’t Boxes

So far, we’ve used Maybe as a concrete example to dissect how monads work. But in practice, what matters more than just implementing the code is understanding the context these tools carry and recognizing how they differ from existing tools.

Many monad tutorials, including my own earlier ones, have explained functors and monads using the “box” metaphor. While intuitive, this metaphor only tells half the story.

If you think of Promise as merely “a box containing a future value,” it’s hard to explain why then must execute sequentially. So rather than calling functors and monads simple boxes, it’s more accurate to describe them as “the context of a computation accompanied by a particular effect.”

Therefore, what flatMap does isn’t simply “open the box and flatten it” — it’s closer to “safely chaining computations with different contexts.”

Monad	Context (Effect)
`Maybe`	The context of a value that might not exist
`Result`	The context that includes the reason for failure (error)
`Promise`	The context of an asynchronous computation that takes time
`Array`	A nondeterministic context where multiple results may exist

One more thing worth noting: we need to reconsider Promise. In code, Promise behaves in a very monadic way, but under strict mathematical scrutiny, it’s not a monad.

A monad requires map (which preserves structure) and flatMap (which flattens structure) to be strictly separated, but Promise’s then mixes them depending on the return value.

On top of that, a mathematical monad must allow a doubly-nested state $T\langle T\langle A \rangle \rangle$ to exist, but Promise doesn’t allow this at runtime — it collapses immediately into a single layer. Convenient in practice, but it breaks the mathematical properties that make monads predictable.

Therefore, strictly speaking, Promise cannot be called a monad.

Closing Thoughts

With that, we’ve completed the long journey from functors through applicative functors to monads.

Looking back, this whole thing started from a pretty practical question: “How can we compose functions safely?” We met apply to get past the limits of functors, invented join and flatMap to deal with nesting, and then noticed that what we’d built was “a monoid object in the category of endofunctors” — something mathematicians already had a name for.

What’s nice about this is that the monad laws give us real confidence when writing code. The identity laws mean pure won’t mess with your data. The associativity law means you can refactor freely without changing behavior. That kind of trust is what lets you build complex business logic out of small, composable pieces.

Understanding monads is really about learning to handle abstract contexts and getting some mathematical backing for the code you write.

I’ve done my best to take a stab at explaining monads, but honestly, I have no idea whether this article ended up being easy or difficult.

If you have any further questions, feel free to reach out via email and I’ll do my best to explain. I’d love the interest and support of fellow functional programming enthusiasts.

With that, I conclude this post: Beyond Functors, All the Way to Monads.

펑터를 넘어서, 모나드까지

Sat, 07 Feb 2026 21:25:09 GMT

이번 포스팅에서는 이전에 다뤘던 펑터의 개념에 이어 모나드에 대한 설명을 이어가보려고 한다.

아무래도 모나드라고 하면 가장 먼저 떠오르는 것은 “모나드는 내부함자 범주의 모노이드 대상 어쩌고”하는 설명인데, 사실 이것은 모나드를 가장 잘 설명하는 문장이면서도 가장 설명을 못하는 문장이기도 하다.

모나드를 이해하는 순간 모나드를 설명할 수 없게 되어버린다는 모나드의 저주라고 불리는 유명한 밈이 존재할만큼, 수학을 잘 모르는 입장에서는 참 이해하기 난해한 대상이기는 하다.

이에 필자도 야심차게 모나드를 설명하기 위한 도전을 한번 해보려고 한다. (물론 실패할 수도 있다…)

이전 글에서 다뤘던 것들

일단 이전 글을 적은 것이 무려 6년 전이니, 이전 글의 내용을 간단히 복기하고 넘어가도록 하자. 자세한 내용은 이전 포스팅을 참고하면 된다.

뭐가 복잡하고 말이 많지만 결국 핵심은 간단하다. 함수형 프로그래밍의 세계에서 함수를 합성하려면 첫 번째 함수의 출력 타입과 다음 함수의 입력 타입이 일치해야 한다.

하지만 문제는 프로그래밍의 세계에는 null, undefined, 에러 같은 불확실성이나 사이드 이펙트가 존재하기 때문에 이 규칙을 지키기가 쉽지 않다는 것이다.

function getFirstLetter(s: string): string | undefined {
  return s[0];
}

function getStringLength(s: string): number {
  return s.length;
}

// getFirstLetter의 치역이 string | undefined이므로
// getStringLength와 바로 합성할 수 없다
getStringLength(getFirstLetter(''));

이 문제를 해결하기 위해 값과 사이드 이펙트를 컨테이너로 감싸는 개념을 도입했고, 그 컨테이너가 바로 함자, 영어로는 펑터(Functor)였다.

즉, 펑터는 map이라는 연산을 통해 컨테이너 안의 값을 꺼내지 않고도 안전하게 변환할 수 있는 구조체라고 보면 된다.

map: F<A> → (A → B) → F<B>

위 타입 시그니처는 F<A>라는 펑터의 map 연산에 내부 값을 변환하는 계산인 (A → B)을 넘겨주면 결과적으로 내부 값이 변경되어 F가 된다는 것을 의미한다.

이때 F<A>와 F는 내부 값이 바뀌었을지언정, 본래 가지고 있던 구조 자체가 변경되어서는 안되기 때문에 아래 두 가지 법칙을 만족해야한다.

항등 법칙: $F(\text{id}) = \text{id}$
합성 법칙: $F(g \circ f) = F(g) \circ F(f)$

$id$ 는 인자로 받은 값을 그대로 반환하는 항등 함수이다. 이 항등 함수에 매핑을 적용하면 아무 일도 발생하지 않아야하는 것이 항등 법칙이다.

두 번째 합성 법칙은 합성된 함수를 매핑한 것과 각각의 함수를 따로 매핑하고 합성한 결과가 같아야 한다는 것을 의미한다.

이 법칙들을 지켜야하는 이유는 단순한 수학적 결벽증 때문이 아니라, 이 법칙들을 지켜줘야 펑터가 “구조를 보존하는 사상”이라는 사실을 보장하기 때문이다.

항등 법칙이 성립하면 a.map(x => x)가 정말로 아무것도 하지 않음을 신뢰할 수 있지만, 만약 이 과정에서 리스트의 순서라던가 트리의 높이와 같은 내부 구조가 변형된다면 이건 더 이상 매핑이 아니라 “재구성”이다. 즉, 항등 법칙은 펑터가 반드시 알맹이만 건드리고 껍데기는 건드리지 않는다는 신뢰의 기반이라고 할 수 있다.

그리고 합성 법칙이 성립하면 a.map(f).map(g)를 a.map(x => g(f(x)))로 바꿔도 동작이 동일함을 보장받는다.

이는 루프를 두 번 도는 a.map(f).map(g)을 a.map(x => g(f(x)))로 합쳐서 루프를 한 번만 돌아도 동작이 똑같다는 것을 보장하며, 반대로 복잡한 로직을 가독성을 위해 여러 개의 map으로 쪼개도 안전하다는 뜻이기도 하다.

하지만 이 펑터에도 한계가 존재한다. 바로 이 한계로 인해 우리가 오늘 알아볼 모나드가 등장하게 된다.

펑터의 한계

1988년, 에든버러 대학의 컴퓨터 과학자 에우제니오 모지(Eugenio Moggi)는 골치 아픈 문제와 씨름하고 있었다. 프로그램의 의미를 수학적으로 정의하는 의미론 연구를 하던 그는, 순수 람다 계산법과 현실 프로그램 사이의 간극을 어떻게 메울지 고민하고 있었다.

순수 람다 계산법에서 타입 $A \to B$ 는 “입력 A를 받아 B를 돌려주는 전체 함수”를 의미한다. 수학적으로는 아주 깔끔하지만 사실 현실의 프로그램은 그렇지 않다.

프로그램은 무한 루프에 빠질 수도 있고, 예외를 던질 수도 있고, 상태를 변경할 수도 있고, 파일을 읽을 수도 있기 때문이다. 이런 여러가지 “효과(effect)“를 발생시키는 프로그램을 순수 함수 $A \to B$ 로 보면 의미가 왜곡된다.

그래서 모지는 프로그램을 $A \to B$ 가 아니라 $A \to T(B)$ 로 보자는 것에서 출발했다. 여기서 $T$ 는 “계산의 개념”을 담는 구조를 의미하며, $T(B)$ 는 $B$ 라는 값을 결과로 내는 계산이라는 뜻이다. 값 자체가 아니라 값을 만들어내는 계산을 타입으로 표현하는 것이다.

말로만 하면 어려우니 직접적인 예시를 한번 보자면, 우리에게 익숙한 계산들은 이런 것들이 있다.

$A \to \text{Maybe}(B)$ : 실패할 수도 있는 계산
$A \to \text{IO}(B)$ : 외부 세계와 상호작용하는 계산
$A \to \text{State}(B)$ : 상태를 변경하는 계산

그런데 막상 이렇게 접근하자니 또 한 가지 문제가 발생한다. 바로 $A \to T(B)$ 형태의 함수들을 합성하는 것이 까다로워진 것이다. 첫 함수가 $A \to T(B)$ 라면 두 번째 함수는 $B \to T(C)$ 의 형태가 될텐데, 첫 번째 함수의 출력인 $T(B)$ 와 두 번째 함수의 입력 $B$ 가 맞지 않는 문제가 발생한다.

모지는 이 합성 문제를 해결하는 구조가 카테고리 이론에서 이미 연구되어 있다는 것을 발견했고, 그것이 바로 함수형 프로그래밍에서의 모나드의 시작이었다.

이렇게 모지가 수학에서 빌려온 “모나드”라는 이름표가, 오늘날 컴퓨터 이론에서 가장 악명 높으면서도 강력한 추상화의 이름이 되었다.

왜 펑터로는 해결이 안될까?

그렇다면 모지의 고민은 왜 펑터만으로 해결이 어려운 것일까? 우리는 펑터의 map이 해결하지 못하는 두 가지 결정적인 병목 지점을 마주하게 된다.

먼저 계산의 맥락인 $T$ 안에 함수가 갇혀버린 경우를 생각해보자. 이런 케이스를 발생시키는 대표적 예시로는 커링이 있다.

const maybeA: Maybe<number>;
const maybeB: Maybe<number>;

const add = (a: number) => (b: number) => a + b;

const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;

이때 펑터의 map을 사용하면 maybeA에 add 연산을 적용하여 다음 인자를 기다리는 함수를 만들어낼 수 있을까? 결론부터 말하자면 불가능하다. 왜냐하면 펑터의 map을 통해 적용된 연산의 결과가 그냥 함수가 아니기 때문이다.

const addA = map(maybeA, add);

// map의 타입 시그니처에 대입해보면...
map<number, (b: number) => number>(
  maybeNumber: Maybe<A>,
  add: (a: number) => (b: number) => number
): Maybe<(b: number) => number>

일반적으로 커링된 함수를 사용하면 addA는 (b: number) => number 타입이 되어야겠지만, 여기서는 map을 사용하여 연산을 적용했으므로, 결과적으로 Maybe<(b: number) => number>라는 타입을 얻게 된다. 즉, 함수가 계산의 맥락 안에 갇혀버렸다.

그런데 문제는 이렇게 되어버리면 쌩 함수만 인자로 받을 수 있는 펑터의 map을 사용하여 합성을 진행하는 것이 불가능해진다는 것이다. map은 맥락 밖의 함수를 맥락 안의 값에 적용할 뿐, 맥락 안에 갇힌 함수를 다른 맥락 안에 있는 값에게 전달할 방법이 없다.

이것은 기본적으로 펑터의 map이 커링된 함수를 받을 때 바깥 쪽에 있는 함수에만 연산을 적용하기 때문이다. 커링된 함수처럼 함수가 함수를 반환하는 경우에는 안 쪽의 함수까지 닿을 수가 없다.

그리고 또 다른 문제는 펑터를 반환하는 두 함수를 합성하는 상황 속에서 발생한다. 이번에도 “값이 있을 수도 있고 없을 수도 있다”를 의미하는 Maybe 펑터를 예시로 한번 살펴보자.

const findUser: (id: number): Maybe<User>;
const findTeam: (user: User): Maybe<Team>;

이 함수들은 모지가 고안해냈던 입력 $A$ 를 받아 계산 $T(B)$ 를 반환하는 함수들을 의미한다.

findUser 함수는 유저의 아이디를 인자로 받아 User를 반환한다. 이때 이상한 아이디가 들어오면 매칭되는 유저가 없을 것이기 때문에 Maybe 펑터를 사용한 것이다. 그리고 findTeam 함수는 User를 인자로 받아 유저의 소속 팀을 반환한다. 우리는 이 두 함수를 합성해서 유저의 팀을 찾는 함수를 만드려고 한다.

문제는 findUser가 반환하는 Maybe<User>를 findTeam이 바로 받아들일 수 없다는 것이다.

하지만 펑터의 map을 사용하면 어찌저찌 합성을 해볼 수는 있다. 한번 합성을 진행해보자.

map(findUser(1), findTeam);

// map의 타입 시그니처에 대입해보면...
map<User, Maybe<Team>>(maybe: Maybe<User>, f: (a: User) => Maybe<Team>): Maybe<Maybe<Team>>

어찌어찌 합성은 성공했지만, 결과적으로 타입이 Maybe<Maybe<Team>>이라는 슬픈 상황이 되어버렸다. 만약 여기서 팀 정보를 통해 팀장을 찾는 과정을 한 번 더 추가한다면 타입은 Maybe<Maybe<Maybe<Manager>>>와 같이 무한히 중첩될 것이다.

이 쯤에서 한번 정리해보자

우리는 모지의 문제를 따라가면서 펑터로는 해결할 수 없는 두 가지의 문제에 직면했다.

문제	원인	필요한 것
맥락 안의 함수 적용	`map`은 바깥의 함수만 받음	안의 함수를 안의 값에 적용하는 연산
맥락 중첩	`map`은 한 겹만 벗김	이중 맥락을 단일 맥락으로 펴는 연산

펑터로 전부 해결할 수 있을 줄 알았는데 전혀 아니었다는 슬픈 결말

괜찮다. 문제는 해결하면 되니까. 이제 우리는 이 문제를 해결하기 위한 설계도를 차근차근 그려보려고 한다.

이 중 첫 번째 문제인 맥락 안에 함수가 갇혀버린 상황은 어플리케이티브 펑터(Applicative Functor)라는 녀석으로 해결할 수 있고, 함수를 합성할 때마다 맥락이 계속 중첩되어 버린다는 문제를 바로 모나드(Monad)가 해결할 수 있다.

해결책 설계: 어플리케이티브 펑터와 모나드

이제 우리는 첫 번째 문제를 해결하기 위해 새로운 연산을 발명해야 한다. 이제부터는 앞서 언급했던 “계산의 맥락”이라는 표현이 너무 기니, 간단하게 “컨테이너”라고 부르도록 하겠다.

첫 번째 문제는 컨테이너 내부에 함수가 갇혀버린 상황이었으니, 이 함수를 다른 컨테이너 안에 있는 값에 적용할 수 있는 연산이 있으면 될 것이다.

// 컨테이너 안의 함수를 다른 컨테이너 안의 값에 적용한다
apply: T<(A → B)> → T<A> → T<B>

이 연산과 펑터의 map과 차이는 적용하려는 함수가 컨테이너 밖에 있느냐 안에 있느냐 뿐이다. 그리고 이 연산을 apply라고 부른다.

그리고 이 함수를 값에 적용한 뒤 다시 컨테이너에 담아줘야 하는 연산도 필요하다. 이 연산은 pure 연산이라고 부른다.

// 순수한 값을 컨테이너에 넣는다
pure: A → T<A>

그리고 이렇게 apply와 pure 연산을 갖춘 펑터를 어플리케이티브 펑터라고 부른다. 이번에도 우리에게 익숙한 Maybe 컨테이너를 예시로 들어 이 연산들을 타입스크립트 타입 시그니처로 표현해보자.

const apply: <A, B>(maybe: Maybe<A>, f: Maybe<(a: A) => B>): Maybe<B>
const pure: <A>(value: A) => Maybe<A>

이제 이 어플리케이티브 펑터를 통해 앞서 우리가 겪었던 첫 번째 문제인 커링된 함수를 합성해보면 된다.

const maybeA: Maybe<number>;
const maybeB: Maybe<number>;

const add = (a: number) => (b: number) => a + b;

const maybeAddA = map(maybeA, add); // Maybe<(b: number) => number>;

apply(maybeB, maybeAddA); // Maybe<number>

// apply의 타입 시그니처에 대입해보면...
apply<number, number>(
  maybe: Maybe<number>,
  f: Maybe<(b: number) => number>
): Maybe<number>

이제 우리는 어플리케이티브 펑터의 apply라는 연산을 통해 위 예시의 maybeA, maybeB와 같은 여러 개의 컨테이너를 동시에 다루는 문제를 우아하게 해결할 수 있게 되었다.

어플리케이티브 펑터의 한계

하지만 우리가 해결한 문제에는 중요한 전제가 하나 있다. 바로 어떤 상자들을 합성할지 미리 정해져 있어야 한다는 것이다.

한번 어플리케이티브 펑터의 apply 연산 과정을 다시 떠올려보자. maybeA와 maybeB는 계산이 시작되기 전부터 이미 우리 손에 들려있는 독립적인 컨테이너들이다. 즉, 계산의 구조가 값과 상관없이 고정되어있다는 것이다.

하지만 현실의 프로그램은 이보다 훨씬 동적인 경우가 많다. 이전 계산의 결과 값을 보고 나서야 다음에 어떤 컨테이너를 가져올지, 아니면 아예 컨테이너를 가져오지 않을지를 결정해야하는 상황이 훨씬 많다는 것이다.

// 유저를 찾고, 그 유저의 정보를 토대로 팀을 찾는다.
// 즉, 팀을 찾는 함수는 유저가 누구냐에 따라 다른 결과를 내놓는다.
findUser(1).fn(user => findTeam(user.teamId))

여기서 또 문제가 발생한다. findTeam이 반환하는 Maybe 컨테이너는 user라는 값에 의존하여 생성되기 때문이다. 즉, 이전 계산의 결과가 다음 계산의 맥락을 결정한다.

어플리케이티브 펑터는 이미 존재하는 컨테이너끼리만 소통시킬 수 있기 때문에 이렇게 실행 중에 동적으로 만들어지는 순차적 의존성을 표현할 수가 없다.

정적(Static)	동적(Dynamic)
“A와 B를 각각 가져와서 합쳐라”	“A를 가져오고, 그 결과를 보고 B를 할지 말지 정해라”

결국 동적으로 만들어지는 순차적 의존성을 해결하려면 이전 계산의 결과물로 다음 계산(컨테이너)을 생성해야 하고, 이 과정에서 컨테이너가 중첩되는 것은 피할 수 없는 숙명이 된다.

오 그렇다면 중첩된 컨테이너를 펴주는 연산이 있다면 어떨까?

어플리케이티브 펑터는 apply라는 새로운 연산을 통해 컨테이너 안의 함수를 실행했다. 하지만 만약 우리가 중첩을 평평하게 펴주는 도구를 갖게 된다면, 굳이 새로운 컨테이너 내부의 함수를 실행하는 번거로운 짓을 하지 않고도 이 문제를 해결할 수 있다.

const maybeA: Maybe<number>;
const maybeB: Maybe<number>;
const add = (a: number) => (b: number) => a + b;

// 중첩을 펴주는 녀석이 있다면 map만으로도 문제를 해결할 수 있다!

// 1. 커링된 함수를 매핑하면 컨테이너에 담긴 함수가 나온다
const maybePartialFn = map(maybeA, add);
// 결과: Maybe<(b: number) => number>

// 2. map을 사용하여 컨테이너 안에 담긴 함수에 접근하고 계산 수행
const nested = map(maybePartialFn, fn => map(maybeB, fn));
// 결과: Maybe<Maybe<number>>

// 3. 그리고 중첩을 제거하면?
const result = 펴주는녀석(nested);
// 결과: Maybe<number>

즉, 일단 합성해서 중첩시켜버리고 나중에 중첩을 펴버리면 되는 것이다.

모나드, 중첩을 펴는 연산의 발명

결국 모나드는 이러한 문제를 해결하기 위해 등장했다. 다시 말하자면 모나드는 컨테이너의 중첩을 펴는 연산을 가진 무언가이다.

그리고 이렇게 중첩을 펴는 연산을 join 또는 flatten이라고 부른다.

join: T<T<A>> → T<A>

const join: <A>(maybe: Maybe<Maybe<A>>) => Maybe<A>

즉, join 연산은 Maybe<Maybe<A>>를 Maybe<A>로 만든다. 수학적으로는 ” $T$ 를 두 번 적용한 것을 $T$ 한 번으로 줄이는 것”이다.

사실 이러한 연산은 우리 주변에서도 쉽게 찾아볼 수 있는데, 바로 JavaScript의 Array.prototype.flat이 바로 이러한 역할을 한다.

그리고 어플리케이티브 펑터와 마찬가지로 순수한 값을 컨테이너에 넣어주는 연산도 필요하다. 이 연산은 어플리케이티브 펑터와 마찬가지로 pure라고 부르거나, of라고 부르기도 한다.

pure: A → T<A>

const pure: <A>(value: A) => Maybe<A>

하지만 실제 프로그래밍에서 join을 직접 쓰는 일은 거의 없다. 앞선 예시에서 보았듯이 모나드는 map을 사용하여 컨테이너 안에 담긴 무언가에 접근하여 합성을 진행하고 join을 이용해서 중첩을 다시 펴는 것이 한 세트로 작동하기 때문이다.

1. 컨테이너 안의 값에 함수를 적용하고 싶다 = map을 쓴다
2. 그런데 그 함수가 결과를 컨테이너에 담아서 반환한다 = 이중 포장이 된다
3. 이중 포장을 벗겨야 한다 = join을 쓴다

그래서 우리는 이 두 가지 연산을 하나로 합쳐 좀 더 편리하게 사용하려고 한다.

flatMap = map + join

매번 map 다음에 join을 부르는 것이 번거로우니, 이 두 단계를 하나로 합친 것이 flatMap이다. 이번에도 마찬가지로 우리에게 친숙한 Maybe 컨테이너를 받는 flatMap이 어떤 타입 시그니처로 표현되는지 알아보도록 하자.

map:     T<A> → (A → B)    → T<B>     // 일반 함수를 적용
flatMap: T<A> → (A → T<B>) → T<B>     // 컨테이너 반환 함수를 적용 + 펴기

const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;
const flatMap: <A, B>(maybe: Maybe<A>, f: (a: A) => Maybe<B>): Maybe<B>

map과 flatMap의 차이점은 두 번째 인자에 있다. map은 단순히 A => B 형태의 함수를 받지만, flatMap은 (A => Maybe) 형태의 함수를 받는다.

타입시그니처로는 표현되지 않았지만 내부적으로 flatMap은 join의 역할까지 하고 있기 때문에 결과 타입은 Maybe<Maybe>와 같은 슬픈 형태가 아니라 Maybe가 되는 것이다.

이제 우리는 이 flatMap을 사용하여 계산들 간의 순차적 의존성을 표현할 수 있게 되었다.

// map을 쓰면 결과 타입이 중첩됨
findUser(1).map(user => findDepartment(user.deptId));
// Maybe<Maybe<Department>>

// flatMap을 쓰면 해결
findUser(1).flatMap(user => findDepartment(user.deptId));
// Maybe<Department>

여기까지 펑터의 map, 어플리케이티브 펑터의 apply, 모나드의 flatMap에 대해서 알아보았다. 분량이 워낙 많았으니 한번 다시 정리하고 넘어가보자.

// 펑터의 map
const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;

// 어플리케이티브 펑터의 apply
const apply: <A, B>(maybe: Maybe<A>, f: Maybe<(a: A) => B>): Maybe<B>

// 모나드의 flatMap
const flatMap: <A, B>(maybe: Maybe<A>, f: (a: A) => Maybe<B>): Maybe<B>

먼저 map은 컨테이너 안에 있는 값에 일반 함수를 적용하는 녀석이다. 하지만 이것만으로는 컨테이너 내부에 갇힌 함수는 사용할 수 없다는 문제가 발생한다.

그래서 apply가 등장했다. apply는 컨테이너 내부에 있는 함수에 접근할 수 있도록 만들어줘서 이런 상황일 때도 계산의 합성이 가능하도록 만들어주었다. 하지만 결국 순차적 의존성을 가진 동적인 계산을 진행하면 컨테이너가 중첩된다는 문제가 발생했다.

이를 해결하기 위해 중첩된 연산을 펴주는 join과 펑터의 map이 합쳐진 flatMap이 등장했다. 우리는 이제 이 연산을 통해 앞 결과에 의해 다음 계산을 결정하는 순차적 의존성을 가진 계산도 자유롭게 합성할 수 있게 되었다.

법칙은 리팩토링에 대한 증명

그렇다면 flatMap은 정말 우리가 함수를 안전하게 합성할 수 있게 만들어주는 마법인걸까? 글쎄, 이것을 자신있게 이야기하기 위해서는 flatMap이 지켜줘야하는 몇 가지 법칙이 존재한다.

세 가지 법칙

우리가 flatMap을 자유롭게 사용하기 위해 이 연산은 아래 법칙을 지켜준다는 것이 보장되어야 한다.

결합 법칙: 어느 층부터 합쳐도 같아야 한다

가장 먼저 결합 법칙이다. 즉, 중첩을 펼 때, 어느 쪽부터 펴든 결과가 같아야 한다는 것을 의미한다. 한번 Maybe<Maybe<Maybe<A>>>처럼 삼중의 계산으로 감싸진 컨테이너가 있다고 생각해보자.

우리는 이제 이 컨테이터를 $T(A)$ 형태로 만들기 위해 중첩을 펴내야 한다.

T(T(T(A))) \to T(T(A)) \to T(A)

이 중첩을 펴서 한 겹으로 만드는 방법은 두 가지다. 첫 번째 방법은 안쪽 두 개의 $T$ 를 먼저 합친 다음, 바깥 쪽에 남은 $T$ 를 벗겨내 $T(A)$ 로 만드는 방법이다. 그리고 두 번째 방법은 바깥에 있는 두 개의 $T$ 를 합친 다음, 안 쪽에 남은 $T$ 를 벗기는 방법이다.

이 중 어떤 순서로 연산을 수행하던 $T(A)$ 라는 최종 결과는 같아야 한다는 것이 바로 결합법칙이다.

\mu \circ T\mu = \mu \circ \mu T

m.flatMap(f).flatMap(g) === m.flatMap(x => f(x).flatMap(g))

위 수식에서 $\mu$ (뮤)는 join을 의미한다.

여기서 $T\mu$ 는 “안쪽 두 겹”을 합치는 것이고, $\mu T$ 는 “바깥쪽 두 겹”을 합치는 것이라고 보면 된다. 즉, 3층 마트료시카를 2층으로 줄일 때, 안쪽 인형들을 먼저 합치느냐 바깥쪽 인형들을 먼저 합치느냐의 차이가 없어야 한다는 것이다.

좌단위 법칙: 입구에서 장난치지 말자

두 번째는 좌단위 법칙이다. 이 법칙은 넣었다가 바로 벗기면 아무 일도 없었던 것과 동일한 상태여야한다는 것을 의미한다.

\mu \circ T\eta = \text{id}

pure(a).flatMap(f) === f(a)

위 수식에서 $\eta$ (에타)는 pure를 의미한다.

여기서 특히 주목해야 할 부분은 $\eta$ 앞에 붙은 $T$ ( $T\eta$ )인데, 이는 상자 바깥이 아니라 이미 상자에 담겨 있는 내부의 값에 pure를 적용하라는 뜻이다.

즉, $T(A)$ 라는 컨테이너가 있을 때 내부의 알맹이 $A$ 를 pure로 감싸서 $T(T(A))$ 라는 이중 구조를 만든 뒤, 이를 다시 join( $\mu$ )으로 펴내면 원래의 상태( $\text{id}$ )로 돌아와야 한다는 법칙이다.

이 법칙이 보장되어야 우리는 컨테이너 내부에서 일어나는 계산의 최소 단위인 pure 연산을 신뢰할 수 있다. 만약 이 좌단위 법칙이 깨진다는 것은 pure가 단순히 값을 감싸는 것을 넘어 내부적으로 로직을 변형시키고 있다는 것을 의미하기 때문이다.

우단위 법칙: 포장지만 바꿨다면 알맹이는 그대로

세 번째는 우단위 법칙이다. 이는 좌단위 법칙과 유사하지만, 컨테이너를 씌우는 순서가 반대다.

\mu \circ \eta T = \text{id}

m.flatMap(pure) === m

여기서 $\eta T$ 는 이미 존재하는 컨테이너 $T(A)$ 자체를 하나의 값으로 간주하고, 그 바깥을 pure( $\eta$ )로 한 번 더 감싸는 행위를 의미한다. 결과적으로 $\eta(T(A))$ 가 되어 $T(T(A))$ 라는 이중 구조가 만들어지는 것이다.

우단위 법칙이 말하고자 하는 핵심은 명확하다. 상자 바깥을 pure로 한 겹 더 감싼 뒤( $\eta T$ ), 다시 join( $\mu$ )으로 그 겉껍데기를 벗겨내면 결국 처음의 상태( $\text{id}$ )와 동일해야 한다는 것이다.

앞서 언급했듯이 이 단위 법칙들이 중요한 이유는 pure라는 연산이 맥락을 왜곡하지 않는 항등원임을 보장하기 때문이다.

마치 우리가 숫자에 $0$ 을 더해도 값이 변하지 않듯, 어떤 컨테이너를 pure로 감싸고 다시 펴는 행위는 그 컨테이너가 가진 원래의 정보나 상태에 아무런 영향을 주지 않아야 한다.

다시 “내부함자 범주의 모노이드 대상”으로

자, 그렇다면 이것이 위키에 나와있는 모나드의 정의인 “내부함자 범주의 모노이드 대상”과 무슨 관련이 있는 것일까?

여기서부터는 추상적이고 수학적인 이야기가 많이 나오니, 실무적인 수준으로 모나드를 이해하는 것만으로도 충분한 독자들은 건너뛰어도 된다.

하지만 운동 많이 될테니 그래도 한번 읽어보는 것을 추천한다

사실 앞서 말했듯이 모나드는 처음부터 수학자들이 “이런 걸 써라”하고 던져준 것이 아니다. 오히려 공학적인 필요에 의해 안전하게 함수를 합성하는 방법을 찾다 보니, 아래와 같은 도구들이 필연적으로 발명된 것에 가깝다.

발명된 것	설명	예시
$T$	타입을 받아서 새로운 타입을 만드는 타입 생성자	`Maybe<A>`, `Array<A>`, …
$\eta$ (에타)	값을 컨테이너에 넣는 연산	`pure`, `Promise.resolve`, …
$\mu$ (뮤)	중첩된 컨테이너를 단일 컨테이너로 펴는 연산	`join`, `flatten`, …

그리고 이 연산들을 우리가 안전하게 사용하기 위해서는 앞서 살펴본 세 가지 법칙(결합, 좌단위, 우단위)을 지켜야 한다고 했다. 이제 이 구조를 수학적으로 분석해 보면 아주 흥미로운 지점에 도달하게 된다.

범주(Category): 대상과 화살표의 세계

범주(Category)는 대상(Object)과 대상 사이의 사상(Morphism, 화살표)으로 이루어진 구조다. 필자는 개인적으로 범주보다는 카테고리라는 단어가 더 익숙하므로, 앞으로 카테고리라고 부르도록 하겠다.

우선 TypeScript 관점에서 가장 친숙한 카테고리는 타입의 카테고리다. 타입의 카테고리에서 대상은 number, string과 같은 타입들이고 사상은 (a: number) => string과 같이 한 대상에서 다른 대상으로 나아가는 계산, 함수이다.

카테고리와 함자(Functor)에 대한 자세한 내용은 이전 포스팅에 수록되어있으므로, 한번 읽고 오는 것을 추천한다.

내부함자(Endofunctor): 같은 세계 안에서 도는 펑터

그렇다면 모나드의 정의 중 “내부함자 범주의…”라는 것은 결국 내부함자(Endofunctor)로 이루어진 카테고리라는 의미이다.

이전 포스팅에 간단하게 적어놓았지만 함자, 즉 펑터는 어떤 카테고리를 다른 카테고리로 나아가게 만들어주는 사상이다. 일반적인 펑터는 카테고리 $C$ 에서 다른 카테고리 $D$ 로 매핑하지만, 내부함자, 엔도펑터는 출발지와 도착지가 같은 범주인 $T: C \to C$ 라는 것을 의미한다.

왜 모나드는 “내부함자 카테고리”의 대상인 것일까? 그 이유는 우리가 프로그래밍 세계 안에서 사용하는 펑터는 결국 프로그래밍 세계에서만 돌고 있기 때문이다. 예를 들어 펑터의 map 연산을 한번 생각해보자.

const map: <A, B>(maybe: Maybe<A>, f: (a: A) => B): Maybe<B>;

위 타입 시그니처를 보면 map 함수는 A를 받아 B로 나아가는 것을 볼 수 있다. 중요한 점은 A도 결국 타입스크립트의 타입 시스템에 있는 타입이고, 결과 타입인 Maybe도 타입스크립트의 타입 시스템에 있는 타입이라는 것이다.

즉, 타입의 세계에서 타입의 세계로 향한다. 이것이 프로그래밍에서 사용하는 펑터가 엔도펑터(내부함자)인 이유이다. 다른 세계로 가는 것이 아니라 같은 세계 안에서 변환하기 때문이다.

내부함자 범주: 펑터들 자체가 대상인 세계

자 그럼 이제 추상화를 한 단계 올려보자. 프로그래밍에서 사용하는 펑터들이 엔도펑터라는 사실을 알았다면 이제는 엔도펑터들 자체를 대상으로 놓는 새로운 카테고리를 생각할 수 있다.

	일반 타입 카테고리	엔도펑터 카테고리
대상	`number`, `string`, …	`Maybe`, `Array`, `Promise`, …
사상	`(a: A) => B`	펑터 → 펑터

카테고리의 사상은 어떠한 대상에서 다른 대상으로 나아가는 것이니, 엔도펑터 카테고리에서의 사상은 펑터에서 다른 펑터로 나아가는 것이라고 생각해볼 수 있다.

그리고 이렇게 펑터를 다른 펑터로 바꾸는 사상을 우리는 자연 변환(Natural Transformation)이라고 부른다.

모노이드(Monoid) 대상: 합치기의 대수학

여기까지 모나드의 정의 중 “내부함자 범주의…”라는 내용을 살펴봤다면, 이제 “모노이드 대상이다”라는 말이 어떤 의미인지 살펴보자.

수학에서 모노이드라는 것은 다음 세 가지를 갖춘 구조를 의미한다.

집합 또는 대상들의 모임
이항 연산: 두 원소를 합쳐서 같은 집합 안에 들어있는 원소를 만든다. 반드시 결합 법칙을 만족해야한다.
항등원: 어떤 원소와 연산해도 그 원소를 그대로 반환하는 특별한 원소.

개념이 워낙 추상적이라 조금 어렵게 느껴질 수 있지만 막상 예시를 그렇게 복잡하지 않다. 가장 대표적인 모노이드는 정수와 덧셈의 관계이다.

정수와 덧셈에서 덧셈은 정수 집합의 두 원소를 뽑아와 연산하면 정수 집합의 원소를 다시 반환한다. 마치 $1 + 2 = 3$ 처럼 말이다. 그리고 이미 독자 분들도 알다시피 덧셈은 결합 법칙을 만족한다. 그리고 마지막으로 어떤 정수와 더해도 그 정수를 그대로 반환하는 녀석인 항등원은 $0$ 이다.

이러한 이유로 정수와 덧셈을 묶은 세트는 “모노이드”라고 부를 수 있는 것이고 수학적으로는 정수 집합 $\mathbb{Z}$ 과 덧셈 기호를 묶어 $(\mathbb{Z}, +)$ 라고 표기한다. (정확하게는 덧셈에 대한 정수군에는 역원도 존재하지만, 이 설명에서 중요한 것은 아니니 넘어가겠다)

연결점: 모나드는 내부함자 범주의 모노이드 대상

자 모노이드가 무엇인지 이해했다면 이제 드디어 “내부함자 범주의 모노이드 대상”이 무슨 뜻인지를 이해할 수 있게 된다.

일단 내부함자(Endofunctor) 범주는 Maybe, Promise와 같은 프로그래밍에서의 펑터들로 이루어진 카테고리를 의미하니, 이 친구들이 모노이드 구조를 갖춘 대상이 맞는지를 살펴보면 될 것 같다.

앞서 언급했던 대표적인 모노이드인 정수 집합과 덧셈의 관계, 그리고 엔도펑터와 합성 연산 간의 관계를 비교해보자.

모노이드 요소	정수 덧셈	내부함자 범주
이항 연산	`+` ( $1 + 2$ )	합성 `∘` ( $T \circ T$ )
연산의 결과	정수	내부함자
항등원	`0`	항등 함자 `Id`

이렇게 비교해보니 얼추 비슷해보이긴 한다. 하지만 문제가 하나 있는데, 바로 엔도펑터들의 이항 연산인 $T \circ T$ 의 결과는 $T(A)$ 가 아니라 $T(T(A))$ 처럼 중첩된 결과라는 것이다. 즉, 같은 집합 안에 있는 원소가 아니다.

여기서 바로 아까 정의한 모나드의 join( $\mu$ )과 pure( $\eta$ )가 등장한다.

연산	표현	설명
`join` ( $\mu$ )	$T \circ T \Rightarrow T$	두 겹의 T를 하나의 T로 합치는 자연변환
`pure` ( $\eta$ )	$\text{Id} \Rightarrow T$	항등 함자에서 T로 가는 자연변환

자연변환이란 펑터 사이의 “구조를 보존하는 변환”이다. pure가 단순히 값을 컨테이너에 넣는 녀석이 아니라 자연변환이라는 점이 중요하다. 이는 pure가 어떤 타입 $A$ 에 대해서든 일관된 방식으로 동작해야 함을 의미한다. 즉, 타입에 따라 동작이 달라지면 안 된다.

그리고 앞서 살펴봤던 모나드의 법칙들을 다시 살펴보면, 이 법칙들이 모노이드가 요구하는 결합 법칙과 항등원에 대한 법칙을 만족한다는 사실을 알 수 있다.

법칙	표현	설명
결합 법칙	$\mu \circ T\mu = \mu \circ \mu T$	어떤 순서로 합치든 같다
단위 법칙	$\mu \circ T\eta = id = \mu \circ \eta T$	넣었다 빼면 원래대로 돌아온다. 즉, $\eta$ 는 항등원이다.

이처럼 우리가 프로그래밍에서 연산의 결과를 일관되게 보장하기 위해 세웠던 법칙들이 모노이드가 요구하는 것들과 정확하게 일치하는 것을 볼 수 있다.

	정수의 모노이드	내부함자 범주의 모노이드 (= 모나드)
대상	정수	내부함자 (`Maybe`, `Array`, …)
이항 연산	$+$	`join` ( $\mu$ ) ( $T \circ T \Rightarrow T$ )
항등원	$0$	`pure` ( $\eta$ ) ( $\text{Id} \Rightarrow T$ )
결합 법칙	$(a+b)+c = a+(b+c)$	$\mu \circ T\mu = \mu \circ \mu T$
단위 법칙	$0+n = n = n+0$	$\mu \circ \eta T = \text{id} = \mu \circ T\eta$

즉 이러한 이유들로 인해 우리가 프로그래밍에서 사용하는 모나드를 “내부함자 범주의 모노이드 대상이다”라고 말할 수 있는 것이다.

하지만 앞서 언급했듯이 이 정의는 우리가 프로그래밍에서 모나드를 사용하게 된 이유가 아니다. 우리는 그저 “효과가 있는 계산을 순차적으로 합성하고 싶다”라는 실용적이고 공학적인 필요성에서 출발해서 join과 pure를 발명했을 뿐인데, 그것이 마침 수학자들이 이미 알고 있던 “모노이드”라는 구조와 정확하게 일치했던 것이다.

사실 모나드는 박스가 아니다

우리는 지금까지 Maybe라는 구체적인 예시를 통해 모나드의 원리를 파헤쳤다. 하지만 실무에서 모나드를 다룰 때는 단순히 코드를 구현하는 것보다, 이 도구가 담고 있는 맥락을 이해하고 기존 도구들과의 차이를 인지하는 것이 훨씬 중요하다.

지금까지 많은 모나드 설명 포스팅들이 펑터와 모나드를 박스에 비유해서 설명했고 필자도 그렇게 설명을 했었지만, 사실 이 비유는 직관적이기는 하나 모나드의 정체성을 절반만 설명할 뿐이다.

만약 Promise와 같은 녀석을 단순히 “미래의 값이 담긴 박스”로만 본다면, 왜 then이 순차적으로 실행되어야 하는지 설명하기 어렵다. 그래서 펑터나 모나드는 단순한 박스라기보다 “특정 효과가 수반되는 계산의 맥락”이라고 표현하는 것이 적합하다.

따라서 모나드의 flatMap이 하는 일도 단순히 박스를 까서 펼치는 것이 아니라, 서로 다른 맥락을 가진 계산들을 안전하게 이어 붙이는 것에 가깝다.

모나드	담고 있는 맥락(Effect)
`Maybe`	값이 없을 수도 있다는 맥락
`Result`	실패의 이유(에러)를 포함한 맥락
`Promise`	시간이 걸리는 비동기 계산의 맥락
`Array`	여러 개의 결과가 존재할 수 있는 비결정적 맥락

추가적으로 한 가지 더 짚고 넘어가자면 우리는 Promise에 대해 다시 바라볼 필요가 있다. 코드 상에서 Promise는 매우 모나딕하게 작동하지만 엄밀한 수학적 잣대를 들이대면 모나드가 아니다.

모나드는 구조를 보존하는 map과 구조를 펴는 flatMap이 엄격히 구분되어야 하는데, Promise의 then은 반환값에 따라 이 둘을 적당히 섞어서 처리해버리기 때문이다.

또한 수학적 모나드는 이중으로 겹쳐진 $T\langle T\langle A \rangle \rangle$ 상태가 존재해야 하지만, Promise는 런타임 수준에서 이를 허용하지 않고 즉시 단일 계층으로 뭉쳐버린다. 물론 이러한 설계가 실무적인 편의성을 주긴 하지만, 수학적 엄밀함이 주는 예측 가능성과는 어느 정도 거리가 있는 셈이다.

따라서 Promise는 엄밀하게 이야기하자면 모나드라고 할 수 없다.

마치며

이렇게 펑터부터 시작해서 어플리케이티브 펑터, 모나드까지 긴 여정을 마쳤다.

돌이켜보면 이 긴 여정은 “어떻게 하면 안전하게 함수를 합성할 수 있을까?”라는 지극히 공학적인 질문에서 시작되었다. 우리는 펑터의 한계를 넘기 위해 apply를 만났고, 중첩되는 맥락을 해결하기 위해 join과 flatMap을 발명했다. 그리고 우리가 만든 이 도구들이 사실 수학자들이 수백 년 전부터 연구해온 ‘내부함자 범주의 모노이드 대상’이라는 견고한 구조와 일치한다는 사실도 발견할 수 있었다.

이러한 발견이 우리에게 주는 진짜 가치는 바로 우리가 작성하는 코드들의 합성 가능성에 대한 수학적 확신이다. 결합 법칙과 단위 법칙을 통해 맥락에 진입하는 입구가 중립적임을 신뢰할 수 있고, 결합 법칙을 통해서는 어떤 레이어에서 리팩토링을 하던 결과가 같다는 것을 보장받을 수 있다. 그리고 이러한 신뢰가 쌓여야 우리가 작은 맥락 조각들을 이어붙여가며 거대하고 복잡한 비즈니스 로직을 구축해나갈 수 있다.

결국 모나드를 이해한다는 것은 추상적인 맥락을 다루는 법을 배우고 우리가 작성하는 소프트웨어에 수학적인 질서를 부여하여 코드에 대한 확신을 얻는 과정이라고 볼 수 있다.

필자도 나름 모나드를 설명해보겠다고 발버둥을 쳐봤는데, 솔직히 이 글의 난이도가 쉬운 것인지 어려운 것인지 전혀 가늠이 안된다.

혹시라도 추가적인 궁금증이 있는 분들은 필자의 이메일을 통해 질문을 남겨주시면 최대한 설명을 해드릴테니 많은 함수형 프로그래밍 러버들의 관심과 사랑을 부탁드린다.

이상으로 펑터를 넘어서, 모나드까지 포스팅을 마친다.

Why Do We Feel Some Code Is Easier to Read?

Fri, 30 Jan 2026 19:47:00 GMT

I previously wrote a post called “What Is Good Code? On the Illusion of Readability” where I discussed how subjective and context-dependent the formula “good code = readable code” really is.

The conclusion that people judge readability differently is fair enough. But if you trace the mechanics behind it, where that sense of “this is easy to read” actually comes from, you start to find some hints.

So that’s what this post is about. How humans understand code, and what makes certain forms of information feel easier to process.

What Happens in the Brain When We Read Code

A 2020 fMRI study at MIT looked at which brain regions light up when programmers read code.

It turns out code reading primarily activates the Multiple Demand Network, the region for logical reasoning and complex cognitive tasks, not the language network. The language regions weren’t completely uninvolved, but the Multiple Demand Network response was dominant.

Put simply, when our brains read code, they rely more on logical reasoning than language processing.

Five brain regions related to working memory, attention, and language processing showed pronounced activation during code comprehension, while Default Mode Network activity (the regions active when the brain is resting) decreased. Reading code is a fairly expensive operation for the brain.

So far, this might seem unsurprising. But the more interesting part is the difference between experts and novices. Skilled developers showed lower overall brain activation levels when reading code. Not because they were trying less, but because they were processing more efficiently. Novice developers showed widespread brain activation, meaning they were consciously processing nearly everything one piece at a time.

Novices tended to read code like natural language text, top to bottom. Experts followed the program’s execution flow. Same code, fundamentally different processing.

Working Memory: 4 Slots

To understand why some code reads easily while other code refuses to organize itself in your head, you need to know about working memory.

In 1956, cognitive psychologist George A. Miller published “The Magical Number Seven, Plus or Minus Two”, showing that human short-term memory capacity is roughly 7±2 items. Later research revised this downward. Cowan (2001) found the number of chunks you can hold in working memory at once is closer to 3–4. It varies by task and expertise, but either way, it’s smaller than you’d think.

Think about what we load into our heads when reading code. The current value of a variable, the direction of control flow, the order of function calls, the state of the current scope… all of these occupy working memory slots. When those slots fill up, the brain struggles to take in new information. That’s the moment you get that “this code feels complicated” sensation.

To put it in programming terms, working memory is like a fixed-size stack.

Real working memory is a far more complex system than a stack, but the analogy works well enough: there’s a capacity limit, and exceeding it causes things to break down. The stack size is roughly 4, and exceeding it causes a stack overflow. In practice, the items occupying each slot aren’t uniform in size, and interference between items also occurs, so the exact number matters less than the fact that capacity is limited. The moment that capacity hits its limit is when you feel “this code is hard to read.”

Let’s compare code that rapidly exhausts working memory with code that doesn’t.

// Code that rapidly exhausts all 4 working memory slots
function processOrder(order: Order) {
  if (order.status === 'pending' && order.items.length > 0) {
    const discount = order.customer.tier === 'premium'
      ? order.items.reduce((sum, item) => sum + item.price, 0) * 0.1
      : order.coupon?.discount ?? 0;

    const tax = (order.total - discount) * (order.shipping.domestic ? 0.1 : 0);
    const finalPrice = order.total - discount + tax + order.shipping.cost;

    return { ...order, finalPrice, status: 'processed' };
  }
  return order;
}

This function isn’t wrong, but it demands too many things be held in the reader’s working memory simultaneously.

The condition on order.status, the check on order.items, the discount branching by customer.tier, the null check on the coupon, the domestic/international tax branching, the final price calculation… trying to fit all of this context into 3–4 slots is what makes the brain scream.

If we can break this context into appropriately sized units, we can save working memory slots needed to understand each operation.

// Version that reduces working memory load
function calculateDiscount(order: Order): number {
  if (order.customer.tier === 'premium') {
    const subtotal = order.items.reduce((sum, item) => sum + item.price, 0);
    return subtotal * 0.1;
  }
  return order.coupon?.discount ?? 0;
}

function calculateTax(amount: number, shipping: ShippingInfo): number {
  return shipping.domestic ? amount * 0.1 : 0;
}

function processOrder(order: Order) {
  if (order.status !== 'pending' || order.items.length === 0) {
    return order;
  }

  const discount = calculateDiscount(order);
  const tax = calculateTax(order.total - discount, order.shipping);
  const finalPrice = order.total - discount + tax + order.shipping.cost;

  return { ...order, finalPrice, status: 'processed' };
}

In this version, the amount you need to hold in your head at each step is noticeably reduced. The behavior is identical, but by breaking information into consistent units, how much context occupies each working memory slot becomes manageable.

When reading calculateDiscount, you only need to focus on discount logic. When reading processOrder, you can follow the overall flow without knowing each calculation’s internals. Each function fits within working memory’s capacity, which is why it feels easier to understand. This is also why abstraction at the right granularity matters in design. Of course, the reverse is true too. Splitting things too finely means you spend working memory jumping between functions and tracking context. The goal isn’t splitting for its own sake, but reducing how much you need to hold in your head at once.

Chunking: The Brain’s Data Compression Algorithm

But if working memory only has about 4 slots, how do we comprehend hundreds of lines of code?

The answer is chunking: grouping multiple small units of information into a single meaningful cluster. Research from the University of Zurich found that chunking reduces working memory load by swapping individual elements for compressed representations pulled from long-term memory. The freed-up capacity then goes to processing new incoming information.

Think about phone numbers. Trying to remember 01012345678 as eleven individual digits would far exceed working memory capacity. But split it as 010-1234-5678, and you only need to remember three chunks. Better yet, if 010 is already familiar as “Korean mobile prefix,” it’s automatically processed as a single chunk, meaning you really only need to memorize two new chunks.

The same thing happens with code. Look at what happens when a skilled developer reads this:

const activeUsers = users.filter(u => u.isActive).map(u => u.name);

A novice developer has to load each individual element into working memory: the users variable, how .filter works, arrow function syntax, the u.isActive property access, how .map works, another arrow function…

For a skilled developer, users.filter(...).map(...) is recognized as a single chunk: “filter array then transform.” Having seen this pattern hundreds or thousands of times, they pull a stored chunk from long-term memory and use just one working memory slot. The remaining slots can be allocated to higher-level thinking like “why is this being filtered?” or “where does the result get used?”

This is the same principle that allows chess masters to glance at a board and grasp the entire situation. Chess masters don’t memorize individual piece positions one by one. They recognize familiar formation patterns as single chunks. That’s why they can quickly recall meaningfully arranged boards but perform no better than novices with randomly placed pieces.

Code works the same way. Idiomatic code is easy to read not because it’s “correct,” but because it matches chunks already stored in the developer’s long-term memory.

What makes a pattern idiomatic is shaped by external factors: the language’s design intent, standard library conventions, the community’s repeated choices. It’s not simply “familiar because it’s used a lot.” Convergence driven by multiple forces created that familiarity. This is also why project-specific unique patterns or overly creative code are hard to read. When existing chunks don’t match, the brain has to decompose everything into individual elements, and working memory saturates almost instantly.

System 1 and System 2: Intuition and Analysis

This is where Daniel Kahneman’s dual process theory comes in. Kahneman divided human thinking into two systems:

System 1: Fast, automatic, intuitive thinking. Based on pattern recognition.
System 2: Slow, conscious, analytical thinking. Based on logical reasoning.

Most of our everyday judgments are handled by System 1. Driving a car, sensing your partner’s mood from a single word over the phone. When encountering new information, System 1 doesn’t create new patterns; it matches against patterns already stored.

When System 1 gets stuck, that’s when System 2 gets called in. The moment you consciously think “what is this?” and start analyzing, that’s System 2 engaging. Apply this framework to code reading, and a lot starts to make sense.

Readable code is code that’s mostly processed by System 1’s pattern recognition, with minimal System 2 involvement.

When skilled developers read code, familiar patterns are handled automatically by System 1. for loops, if-else branches, map/filter/reduce chaining, try-catch blocks. These have been seen thousands of times, so they’re processed without conscious effort. System 2 stays in a comfortable low-power mode, just approving the information that System 1 surfaces.

But when an unexpected pattern appears, things change.

// Code that System 1 can handle
const canPurchase = user.age >= 18 && user.isVerified;

// Code that invokes System 2
const canPurchase = !(user.age < 18 || !user.isVerified) && (user.age !== undefined);

Both express the same intent. But the moment you see the second version, System 1 sends an “I don’t know” signal, and System 2 begins its expensive analysis. You have to unwind the double negation, run De Morgan’s law in your head, and figure out why that final undefined check is necessary. This transition itself is a cognitive cost.

Kahneman called this cognitive strain. The more System 2 has to step in, the more energy the brain burns and the more fatigued you feel. The “this code is hard to read” sensation is the cognitive cost of System 1 failing to match a pattern and handing things off to System 2.

From this angle, feedback like “this is hard to understand” in code reviews isn’t just taste. It’s closer to a signal that system-switching costs are actually occurring. The magnitude varies by individual experience and chunk composition, but the cost itself is real.

Gestalt Principles: How Visual Structure Affects Code Comprehension

Readable code depends on visual structure too, not just logical structure. This is where Gestalt psychology comes in.

Gestalt psychology studies how the brain prioritizes overall patterns and structures over individual elements. A few of its principles connect directly to code readability.

Law of Proximity

Elements that are close together are perceived as a group. Let’s look at two versions of the same code to see why this grouping matters.

// Code without proximity principle applied
const name = user.firstName + ' ' + user.lastName;
const email = user.email.toLowerCase();
const isValid = email.includes('@') && email.includes('.');
const role = determineRole(user.permissions);
const dashboard = getDashboard(role);
const notifications = getNotifications(user.id, role);

// Code with proximity principle applied
const name = user.firstName + ' ' + user.lastName;
const email = user.email.toLowerCase();
const isValid = email.includes('@') && email.includes('.');

const role = determineRole(user.permissions);
const dashboard = getDashboard(role);
const notifications = getNotifications(user.id, role);

The second version just adds a single blank line, yet the brain automatically recognizes two groups: “user info processing” and “permission-based data retrieval.”

Gestalt research shows that proximity is an even stronger grouping cue than similarity of color or shape. UI design uses this directly: related information goes close together, unrelated information gets spaced apart.

Similarly, blank lines and indentation matter in code not just for aesthetics, but because the brain’s perceptual system uses them to parse structure.

Law of Similarity

Like proximity, elements that look alike are also perceived as belonging to the same group. This explains why consistent naming matters in code.

// Naming that violates similarity
const userData = fetchUser(id);
const get_orders = retrieveOrderList(userId);
const pmtHistory = loadPayments(uid);

// Naming that follows similarity
const user = fetchUser(id);
const orders = fetchOrders(id);
const payments = fetchPayments(id);

In the first version, all three are the same kind of operation (data fetching), but the naming conventions are all over the place. userData, get_orders, pmtHistory each have different forms, and fetchUser, retrieveOrderList, loadPayments lack any consistency. The brain can’t recognize these as the same group and processes each line as a separate item, consuming working memory.

In the second version, the pattern is clear. The consistent fetch + resourceName structure causes all three lines to be recognized as a single chunk: “data fetching in the same pattern.”

Law of Continuity

The law of continuity states that we perceive elements as a single continuous entity when they follow a natural flow of direction. In code, this relates to the linearity of execution flow.

Our brains find top-to-bottom, left-to-right flow natural. Deep nesting, complex callbacks, and scattered goto statements are hard to read because they violate the law of continuity.

This is also why early return patterns feel easier to read than nested if statements. Once edge cases are filtered out, the remaining code flows in a single direction from top to bottom.

// Code that breaks continuity
function getPrice(user: User, product: Product): number {
  if (user.isActive) {
    if (product.inStock) {
      if (user.tier === 'premium') {
        return product.price * 0.8;
      } else {
        if (product.onSale) {
          return product.salePrice;
        } else {
          return product.price;
        }
      }
    } else {
      throw new Error('Out of stock');
    }
  } else {
    throw new Error('Inactive user');
  }
}

// Code that maintains continuity
function getPrice(user: User, product: Product): number {
  if (!user.isActive) throw new Error('Inactive user');
  if (!product.inStock) throw new Error('Out of stock');

  if (user.tier === 'premium') return product.price * 0.8;
  if (product.onSale) return product.salePrice;

  return product.price;
}

The first version forces your eyes to zigzag right and left as indentation deepens. The brain has to maintain “which condition am I currently inside” in working memory at each nesting level.

The second version filters out exceptions first, then flows naturally from top to bottom. Because it aligns with the law of continuity, the cost for the brain to parse the structure drops significantly.

Cognitive Load Theory: Three Types of Load

John Sweller’s Cognitive Load Theory gives a more systematic framework for everything above.

It breaks cognitive load during learning or problem-solving into three types:

Intrinsic load: The inherent complexity of the task itself. Algorithm difficulty, domain complexity, and so on.
Extraneous load: Unnecessary complexity from presentation that’s irrelevant to the task. Inconsistent naming, unnecessary indirection, confusing code structure.
Germane load: The beneficial load spent forming and learning new schemas.

The takeaway for writing readable code: minimize extraneous load.

Intrinsic load can’t be reduced. It’s inherent to the problem. Code implementing a distributed consensus algorithm will be complex no matter how well it’s written. The problem is when extraneous load from “how it’s expressed” piles unnecessarily on top of intrinsic load.

From this perspective, consistent naming, appropriate function decomposition, clear type declarations, meaningful blank lines: these all reduce extraneous cognitive load. They keep the brain’s limited resources from being wasted on presentation issues so you can focus on the actual problem.

A 2023 systematic literature review found something interesting here. Among studies comparing source code metrics to measured cognitive load, few traditional metrics showed consistent correlation with what developers actually experienced. Results varied depending on task conditions and measurement methods. What we “measure” as complexity and what a developer’s brain “feels” as complex can be quite different.

Mechanical metrics capture surface-level complexity, but the cognitive load you actually experience depends on how familiar the patterns are, how efficiently your brain chunks them, how clearly the visual structure maps to the logic. These are subjective factors that no metric fully captures.

Experience Physically Changes the Brain

I mentioned earlier that expert and novice brain activation patterns differ. This isn’t just “more experience = better.” A 2024 study in Scientific Reports measured brainwaves from 62 Python programmers while showing them code with intentionally inserted syntax errors and semantic errors.

Skilled programmers showed distinct brainwave patterns for syntax violations versus semantic violations, the same way our brains produce different responses to grammatical errors versus meaning errors in natural language. Programming experience forms specialized neural circuits for processing specific languages and patterns.

Coding experience physically changes the brain. Through neuroplasticity, patterns you encounter repeatedly get stored as schemas in long-term memory, and these schemas become the foundation for chunking. System 1 can automatically process code because these schemas have accumulated over time.

Because schemas form based on the patterns an individual has been exposed to, people who repeatedly encounter the same patterns in the same codebase end up sharing similar schemas. Flip this around, and maintaining a consistent code style within a team isn’t about taste. It’s the process of forming shared chunks in team members’ brains. Coding conventions matter not for uniformity’s sake, but for collective cognitive efficiency.

Predictive Coding: The Brain Doesn’t Read Code, It Predicts

Predictive coding theory offers another angle. The brain doesn’t passively receive information. It constantly predicts what will come next and only does extra processing when the actual input differs from its prediction.

The same applies when reading code. Our brains constantly predict what the next line will be.

async function fetchUserProfile(userId: string) {
  try {
    const response = await api.get(`/users/${userId}`);
    // Your brain is already predicting what comes next

A skilled developer’s brain reading this code is already predicting “it’ll probably parse the response data and return it.” And when return response.data; actually appears, the prediction was correct, so virtually no additional cognitive cost is incurred.

But what if something completely unexpected shows up?

async function fetchUserProfile(userId: string) {
  try {
    const response = await api.get(`/users/${userId}`);
    globalEventBus.emit('user-fetched', response.data); // Wait, what?
    localStorage.setItem('lastUser', JSON.stringify(response.data)); // Huh?
    analytics.track('profile_view', { userId }); // Why is logging here?
    return response.data;

What the brain predicted from the name fetchUserProfile was “a function that fetches a user profile and returns it.” But then event bus emission, localStorage writes, and analytics tracking appear, all outside the prediction. Each time, the brain generates a prediction error signal and invokes System 2 to analyze why this code is here.

The reason the second version feels hard to read is that the function is named fetchUserProfile, but internally it does things that have nothing to do with that name. The more closely a name’s set expectation matches the actual behavior, the fewer prediction errors occur and the less cognitive cost is incurred.

This applies not just within functions but to interface design as well. Let me use component interfaces familiar to frontend developers like myself as an example.

// Predictable interface
<TextInput
  value={name}
  onChange={setName}
  placeholder="Enter your name"
/>

// Hard-to-predict interface
<UserNameInput
  user={name}
  setUser={setUser}
  blank="Enter your name"
/>

The first component follows value, onChange, placeholder, an interface shared by virtually every input component in the React ecosystem. A developer’s System 1, having encountered this pattern countless times, processes it as “it’s an input component” and moves on.

The second uses user, setUser, blank, an interface either tightly coupled to business logic or with unclear meaning. Until you figure out which fields of the user object it touches internally and when blank is actually used, you can’t use it with confidence. You have to look at the internal implementation every time, and each time, prediction errors occur.

To write readable code, you need to maximize predictability at every level: function names, variable names, file structure, directory organization, API design.

So What Is “Good Code,” Really?

Putting it all together, “readable code” is code that:

Doesn’t exceed working memory (context stays within 3–4 items)
Matches existing chunks (familiar patterns that activate long-term memory schemas)
Can be processed by System 1 (understandable through pattern recognition, without invoking System 2)
Has visual structure that matches its logical structure (Gestalt principles let the brain parse structure automatically)
Is predictable (doesn’t violate expectations set by names and structure)
Has low extraneous cognitive load (strips away presentation complexity, leaving only the problem’s inherent complexity)

Notice something about this list? None of these mean “correct code.”

Readability and correctness are separate axes. Code can be perfectly correct but impossible to read, and code can be easy to read but wrong. That said, readable code does make bugs easier to find. With lower extraneous load, the brain can focus its resources on finding logical errors.

There’s one caveat, though. Kahneman also warned about System 1’s biases. System 1 is fast, but that speed comes at the cost of bias. A classic example is familiarity bias. It’s true that you feel patterns familiar to you as “readable code,” but whether that’s objectively optimal is a separate question. A developer fluent in functional programming might find for loops “hard to read,” and vice versa. In those cases, the feeling of “hard to read” may not reflect the code’s objective quality but the bias of chunks stored in your own System 1.

When giving “this is hard to understand” feedback in code reviews, it’s worth asking yourself once: is this genuinely high-cognitive-load code, or is it simply a pattern not registered in my System 1? If the former, refactoring is needed. If the latter, it might actually be an opportunity to expand your chunk library.

Wrapping Up

“Readable code” isn’t just a matter of feeling or taste. It’s a natural outcome of how our cognitive systems work: limited working memory, chunking, dual process thinking, Gestalt perception, predictive coding.

The reason I said “readability is subjective” in my previous post comes down to this. Chunking depends on individual experience. The patterns registered in System 1 differ from person to person.

When two people look at the same code and one finds it easy while the other finds it hard, that’s not just a difference in preference. The schemas accumulated in their brains are different. Readability is inevitably subjective because it’s baked into our cognitive structure.

우리는 왜 어떤 코드를 읽기 쉽다고 느낄까

Fri, 30 Jan 2026 19:47:00 GMT

이전에 좋은 코드란 무엇일까? - 가독성이란 허상에 대하여라는 글에서, “좋은 코드 = 가독성이 좋은 코드”라는 공식이 얼마나 주관적이고 맥락 의존적인지에 대해 이야기한 적이 있다.

물론 사람마다 가독성이 좋다고 판단하는 결과는 주관적이라고 볼 수 있다. 하지만 가독성이 좋은 코드라는 것이 어떤 원리로 동작하는지, 그 감각은 대체 어디서 오는 것인지를 추적해보다보면 약간은 힌트를 얻을 수 있다.

그래서 이번 포스팅에서는 바로 그 이야기를 해보려 한다. 인간이 코드를 이해하는 방식, 그리고 어떤 형태의 정보가 이해하기 쉽다고 느끼는지에 대한 이야기이다.

코드를 읽을 때 뇌에서는 무슨 일이 일어날까

MIT에서 2020년에 진행한 기능적 MRI 연구에서 프로그래머들이 코드를 읽을 때 뇌의 어떤 영역이 활성화되는지를 관찰했는데, 재밌는 결과가 나왔다.

연구에 따르면 코드를 읽을 때는 언어 네트워크가 아니라 논리 추론과 복잡한 인지 작업을 담당하는 다중 수요 네트워크가 주로 활성화되었다고 한다. 언어 영역의 관여가 완전히 없었던 것은 아니지만, 다중 수요 네트워크의 반응이 지배적이었다.

쉽게 말해서, 우리 뇌는 코드를 읽을 때 언어 처리보다는 논리적 추론 쪽에 더 크게 의존한다는 뜻이다.

이 연구에서 확인된 것은 코드 이해 시 작업 기억, 주의 집중, 언어 처리와 관련된 다섯 개의 뇌 영역이 뚜렷하게 활성화된다는 점이다. 동시에 디폴트 모드 네트워크(뇌가 쉬고 있을 때 활성화되는 영역)의 활동은 감소했다. 즉, 코드를 읽는 건 뇌 입장에서 꽤 비싼 작업인 셈이다.

여기까지는 그러려니 할 수 있겠지만, 더 흥미로운 사실은 바로 전문가와 초보자의 차이에서 나온다. 숙련된 개발자는 코드를 읽을 때 뇌의 전반적인 활성화 수준이 낮았다. 덜 열심히 한 게 아니라, 더 효율적으로 처리한 것이다. 반면 초보 개발자는 뇌의 넓은 영역이 활성화됐는데, 이는 거의 모든 것을 의식적으로 하나씩 처리하고 있다는 뜻이다.

초보자는 코드를 자연어 텍스트처럼 위에서 아래로 읽는 경향이 있었고, 전문가는 프로그램의 실행 흐름을 따라 읽었다. 같은 코드를 보고 있지만, 뇌가 처리하는 방식 자체가 다른 것이다.

작업 기억: 4개의 슬롯

왜 어떤 코드는 쉽게 읽히는데 어떤 코드는 머릿속에서 정리가 안 되는지를 이해하려면, 작업 기억이라는 개념을 알아야 한다.

1956년 인지심리학자 조지 밀러(George A. Miller)가 발표한 유명한 논문 “The Magical Number Seven, Plus or Minus Two”에서, 인간의 단기 기억 용량이 약 7±2개의 항목이라는 사실이 밝혀졌다. 이후 연구에서는 이 숫자가 더 줄어들어, Cowan(2001) 등의 견해에 따르면 작업 기억에 동시에 유지할 수 있는 청크는 약 3~4개 수준으로 수렴한다는 주장이 유력하다. 다만 이 수치는 과제의 종류, 숙련도, 정보의 양식에 따라 달라질 수 있다.

코드를 읽을 때 우리가 머릿속에 올려놓는 것들을 떠올려보자. 변수의 현재 값, 제어 흐름의 방향, 함수 호출 순서, 현재 스코프의 상태 등 다양한 것들이 작업 기억의 슬롯을 차지한다. 그리고 이 슬롯이 꽉 차면, 뇌는 새로운 정보를 받아들이기 어려워는데, 바로 이때 “이 코드 뭔가 복잡한데”라는 느낌이 찾아오는 것이다.

이걸 개발랭이들이 이해하기 쉬운 프로그래밍적인 비유로 바꿔보면, 작업 기억은 일종의 고정 크기 스택이라고 볼 수 있다.

실제 작업 기억은 스택보다 훨씬 복잡한 시스템이지만, “용량에 한계가 있고 초과하면 처리가 무너진다”는 특성을 직관적으로 이해하기에는 나쁘지 않은 비유다. 스택 사이즈가 약 4인데 이걸 초과하면 스택 오버플로우가 나는 것이다. 다만 실제로는 슬롯에 담기는 항목의 크기가 균일하지 않고, 항목 간 간섭도 발생하기 때문에, 숫자 자체보다는 “용량에 한계가 있다”는 사실이 핵심이다. 그리고 이 용량이 한계에 부딪히는 순간이 바로 “이 코드 읽기 어렵다”는 감각이 발생하는 순간이다.

한번 작업 기억을 빠르게 소진하는 코드와 그렇지 않은 코드를 비교해보며 살펴보자.

// 작업 기억 슬롯 4개를 빠르게 소진하는 코드
function processOrder(order: Order) {
  if (order.status === 'pending' && order.items.length > 0) {
    const discount = order.customer.tier === 'premium'
      ? order.items.reduce((sum, item) => sum + item.price, 0) * 0.1
      : order.coupon?.discount ?? 0;

    const tax = (order.total - discount) * (order.shipping.domestic ? 0.1 : 0);
    const finalPrice = order.total - discount + tax + order.shipping.cost;

    return { ...order, finalPrice, status: 'processed' };
  }
  return order;
}

이 함수는 틀린 코드는 아니지만, 읽는 사람의 작업 기억에 동시에 올려야 할 것이 너무 많다.

order.status의 조건, order.items의 존재 여부, customer.tier에 따른 할인 분기, 쿠폰의 널 체크, 세금 계산의 국내/해외 분기, 최종 가격 산출 등 이 모든 맥락을 3~4개의 슬롯에 동시에 담으려 하니 뇌가 비명을 지르는 것이다.

만약 이 맥락을 적절한 단위와 크기로 나눠줄 수 있다면, 어떤 동작을 이해하기 위해 필요한 작업 슬롯을 아낄 수 있다.

// 작업 기억 부담을 줄인 버전
function calculateDiscount(order: Order): number {
  if (order.customer.tier === 'premium') {
    const subtotal = order.items.reduce((sum, item) => sum + item.price, 0);
    return subtotal * 0.1;
  }
  return order.coupon?.discount ?? 0;
}

function calculateTax(amount: number, shipping: ShippingInfo): number {
  return shipping.domestic ? amount * 0.1 : 0;
}

function processOrder(order: Order) {
  if (order.status !== 'pending' || order.items.length === 0) {
    return order;
  }

  const discount = calculateDiscount(order);
  const tax = calculateTax(order.total - discount, order.shipping);
  const finalPrice = order.total - discount + tax + order.shipping.cost;

  return { ...order, finalPrice, status: 'processed' };
}

이 버전에서는 각 단계에서 머릿속에 올려야 할 것이 확연하게 줄어든다. 동작 자체는 동일하지만, 정보를 일정한 단위로 패키징함으로서 작업 슬롯에 들어가는 맥락을 제어해주는 것이다.

calculateDiscount를 읽을 때는 할인 로직에만 집중하면 되며, processOrder를 읽을 때는 각 계산의 세부 구현을 몰라도 전체 흐름을 이해할 수 있다. 각 함수가 작업 기억의 용량 안에서 소화 가능한 크기이기 때문에 이해가 쉽다고 느껴진다. 그리고 이것이 우리가 설계를 할 때 적절한 단위로 추상화를 해야하는 이유라고도 할 수 있다. 물론 반대로, 지나치게 잘게 쪼개면 함수 간 점프와 맥락 추적에 작업 기억을 소모하게 된다. 분리 자체가 목적이 아니라, 한 번에 머릿속에 올려야 할 양을 줄이는 것이 목적이다.

청킹: 뇌의 데이터 압축 알고리즘

그런데 여기서 한 가지 의문이 생긴다. 작업 기억의 슬롯이 겨우 4개라면, 우리는 대체 어떻게 수백 줄의 코드를 이해할 수 있는 걸까?

답은 청킹이라는 인지 메커니즘에 있다. 청킹이란 여러 개의 작은 정보 단위를 하나의 의미 있는 덩어리로 묶어서 처리하는 것을 말한다. 취리히 대학교의 연구에 따르면, 청킹은 장기 기억에서 압축된 청크 표상을 불러와 개별 요소의 표상을 대체함으로써 작업 기억의 부하를 줄인다. 이로 인해 확보된 용량은 이후에 입력되는 새로운 정보를 처리하는 데 사용된다.

전화번호를 생각해보자. 01012345678이라는 11자리 숫자를 한 자리씩 기억하려면 작업 기억의 용량을 한참 초과한다. 그런데 010-1234-5678로 나누면 세 덩어리만 기억하면 된다. 더 나아가, 이미 익숙한 010은 “한국 휴대폰 번호 앞자리”라는 하나의 청크로 자동 처리되니, 실질적으로 두 덩어리만 새로 기억하면 되는 것이다.

코드에서도 같은 일이 일어난다. 숙련된 개발자가 아래 코드를 볼 때 일어나는 일을 보자.

const activeUsers = users.filter(u => u.isActive).map(u => u.name);

초보 개발자는 이걸 읽을 때 users라는 변수, .filter 메서드의 동작, 화살표 함수의 문법, u.isActive라는 속성 접근, .map 메서드의 동작, 또 다른 화살표 함수… 이런 개별 요소들을 하나씩 작업 기억에 올려야 한다.

반면 숙련된 개발자에게 users.filter(...).map(...)은 “배열 필터링 후 변환”이라는 하나의 청크로 인식된다. 이 패턴을 수백, 수천 번 봤기 때문에, 장기 기억에 저장된 청크를 꺼내와서 작업 기억의 슬롯을 하나만 쓰는 것이다. 나머지 슬롯은 “왜 필터링하는가”, “결과가 어디에 쓰이는가” 같은 더 상위 수준의 사고에 할당할 수 있다.

이것이 바로 체스 마스터가 체스판을 한 번 보고 전체 상황을 파악할 수 있는 원리와 같다. 체스 마스터는 개별 말의 위치를 하나씩 기억하는 게 아니라, 익숙한 포진 패턴을 하나의 청크로 인식한다. 그래서 의미 있는 배치의 체스판은 빠르게 기억하지만, 말을 무작위로 배치하면 초보자와 별 차이가 없다.

코드도 마찬가지다. 관용적인 코드가 읽기 쉬운 이유는 그게 “올바른” 코드여서가 아니라, 개발자의 장기 기억에 이미 저장된 청크와 일치하기 때문이다.

그리고 특정 패턴이 관용적이 되는 데는 언어의 설계 의도, 표준 라이브러리의 관례, 커뮤니티의 반복적 선택 같은 외부 요인이 작용한다. 단순히 “많이 써서 익숙한 것”이 아니라, 여러 이유로 수렴한 결과가 익숙함을 만든 것이다. 프로젝트만의 독특한 패턴이나 지나치게 창의적인 코드가 읽기 어려운 이유도 여기에 있다. 기존 청크와 매칭되지 않으면, 뇌는 모든 것을 개별 요소로 분해해서 처리해야 하고, 작업 기억은 순식간에 포화된다.

시스템 1과 시스템 2: 직관과 분석

여기서 다니엘 카너먼(Daniel Kahneman)의 이중 처리 이론을 꺼내야 한다. 카너먼은 인간의 사고를 두 가지 시스템으로 나눴다.

시스템 1: 빠르고, 자동적이고, 직관적인 사고. 패턴 인식에 기반한다.
시스템 2: 느리고, 의식적이고, 분석적인 사고. 논리적 추론에 기반한다.

우리가 일상적으로 하는 판단 대부분은 시스템 1이 담당한다. 운전을 하거나, 전화기 너머 여친의 기분을 한마디에 알아채는 것도 시스템 1의 영역이다. 시스템 1은 새로운 정보를 접했을 때, 완전히 새로운 패턴을 만들어내는 게 아니라 기존에 저장된 패턴과 대조하는 방식으로 작동한다.

시스템 1이 막히면 그때서야 시스템 2가 호출된다. “이게 뭐지?” 하고 의식적으로 분석을 시작하는 순간이 바로 시스템 2가 개입하는 시점이다. 그리고 이 프레임워크를 코드 읽기에 적용하면 정말 많은 것이 설명된다.

읽기 쉬운 코드란, 대부분 시스템 1의 패턴 인식으로 처리되고 시스템 2의 개입이 최소화되는 코드다.

숙련된 개발자가 코드를 읽을 때, 익숙한 패턴은 시스템 1이 자동으로 처리한다. for 루프, if-else 분기, map/filter/reduce 체이닝, try-catch 블록 등 이런 것들은 수천 번 봐온 패턴이기 때문에 의식적 노력 없이 처리된다. 시스템 2는 편안한 저전력 모드에 머물면서, 시스템 1이 올려주는 정보를 승인하기만 하면 된다.

그런데 갑자기 예상치 못한 패턴이 나타나면 상황이 달라진다.

// 시스템 1이 처리 가능한 코드
const canPurchase = user.age >= 18 && user.isVerified;

// 시스템 2를 호출하는 코드
const canPurchase = !(user.age < 18 || !user.isVerified) && (user.age !== undefined);

두 코드는 같은 의도를 표현한다. 하지만 두 번째 코드를 보는 순간 뇌에서는 시스템 1이 “모르겠다”는 신호를 보내고, 시스템 2가 비싼 비용을 들여 분석을 시작한다. 이중 부정을 풀고, 드모르간 법칙을 머릿속에서 돌리고, 마지막 undefined 체크가 왜 필요한지를 따져봐야 한다. 이러한 전환 자체가 인지적 비용이다.

카너먼은 이런 현상을 인지적 긴장이라 불렀다. 시스템 2가 개입할수록 뇌는 더 많은 에너지를 소비하고 피로감을 느끼게 된다. “읽기 어려운 코드”라는 주관적 느낌의 실체는 바로 패턴 매칭 실패로 인한 시스템 전환, 그리고 그에 따르는 인지적 비용이 발생하는 것이다.

이 관점에서 보면, 코드 리뷰에서 “이해하기 어렵다”는 피드백은 단순한 취향 불만이 아니라, 인지 시스템의 전환 비용이 실제로 발생하고 있다는 신호에 가깝다. 그 비용의 크기는 개인의 경험과 청크 구성에 따라 다르겠지만, 비용이 발생한다는 사실 자체는 실재한다.

게슈탈트 원리: 코드의 시각적 구조가 이해에 미치는 영향

읽기 쉬운 코드에는 논리적 구조뿐만 아니라 시각적 구조도 중요하다. 여기서 게슈탈트 심리학의 지각 원리가 등장한다.

게슈탈트 심리학은 인간의 뇌가 개별 요소가 아닌 전체 패턴과 구조를 우선적으로 인식한다는 점을 연구하는 분야다. 그 핵심 원리 몇 가지는 코드 가독성에 직접적으로 연결된다.

근접성의 원리

가까이 있는 요소들은 하나의 그룹으로 인식된다. 한번 두 가지 버전의 코드를 살펴보며 이 그룹이 왜 중요한지를 살펴보자.

// 근접성 원리가 적용되지 않은 코드
const name = user.firstName + ' ' + user.lastName;
const email = user.email.toLowerCase();
const isValid = email.includes('@') && email.includes('.');
const role = determineRole(user.permissions);
const dashboard = getDashboard(role);
const notifications = getNotifications(user.id, role);

// 근접성 원리가 적용된 코드
const name = user.firstName + ' ' + user.lastName;
const email = user.email.toLowerCase();
const isValid = email.includes('@') && email.includes('.');

const role = determineRole(user.permissions);
const dashboard = getDashboard(role);
const notifications = getNotifications(user.id, role);

두 번째 버전에서 빈 줄 하나가 추가됐을 뿐인데 뇌는 자동으로 “사용자 정보 처리”와 “권한 기반 데이터 조회”라는 두 그룹을 인식한다.

게슈탈트 연구에 따르면 근접성은 색상이나 형태의 유사성보다도 더 강력한 그룹핑 단서다. 이 원리는 UI 디자인에서도 그대로 사용되는데, 서로 연관이 있는 정보는 가까이 붙이고 연관이 없는 정보는 간격을 늘려 멀리 떨어트려놓는 것이 이 때문이다.

마찬가지로 코드에서 빈 줄과 들여쓰기가 중요한 이유는 단순히 미관 때문이 아니라, 뇌의 지각 시스템이 그걸 기반으로 구조를 파악하기 때문이다.

유사성의 원리

근접성과 마찬가지로 비슷하게 생긴 요소들도 같은 그룹으로 인식된다. 이것을 유사성의 원리라고 하는데, 이 원리는 코드에서 일관된 네이밍이 왜 중요한지를 설명한다.

// 유사성 원리가 깨진 네이밍
const userData = fetchUser(id);
const get_orders = retrieveOrderList(userId);
const pmtHistory = loadPayments(uid);

// 유사성 원리가 적용된 네이밍
const user = fetchUser(id);
const orders = fetchOrders(id);
const payments = fetchPayments(id);

첫 번째 버전에서는 데이터 페칭이라는 같은 종류의 작업임에도 네이밍 규칙이 제각각이다. userData, get_orders, pmtHistory라는 변수명은 각각 다른 형태를 가지고, fetchUser, retrieveOrderList, loadPayments라는 함수명도 일관성이 없다. 뇌는 이런 코드를 보면 이들을 같은 그룹으로 인식하지 못하고 각 라인을 개별 항목으로 처리하면서 작업 기억을 소진한다.

두 번째 버전에서는 패턴이 명확하다. fetch + 리소스명이라는 일관된 구조 덕분에, 세 줄이 “동일한 패턴의 데이터 패칭”이라는 하나의 청크로 인식된다.

연속성의 원리

연속성의 원리는 시선이 자연스럽게 흐르는 방향을 따라 요소들을 하나의 연속된 것으로 인식하는 원리다. 코드에서 이건 실행 흐름의 선형성과 관련된다.

우리 뇌는 위에서 아래로, 왼쪽에서 오른쪽으로 흐르는 것을 자연스럽게 느낀다. 깊은 중첩, 복잡한 콜백, 여기저기 점프하는 goto문 등이 읽기 어려운 이유는 연속성의 원리를 위반하기 때문이다.

우리가 얼리 리턴 패턴을 사용했을 때, 중첩된 if문보다 읽기 쉬운 이유도 마찬가지다. 예외 케이스를 먼저 걸러내고 나면 남은 코드는 위에서 아래로 한 방향으로 흐른다.

// 연속성이 깨지는 코드
function getPrice(user: User, product: Product): number {
  if (user.isActive) {
    if (product.inStock) {
      if (user.tier === 'premium') {
        return product.price * 0.8;
      } else {
        if (product.onSale) {
          return product.salePrice;
        } else {
          return product.price;
        }
      }
    } else {
      throw new Error('Out of stock');
    }
  } else {
    throw new Error('Inactive user');
  }
}

// 연속성이 유지되는 코드
function getPrice(user: User, product: Product): number {
  if (!user.isActive) throw new Error('Inactive user');
  if (!product.inStock) throw new Error('Out of stock');

  if (user.tier === 'premium') return product.price * 0.8;
  if (product.onSale) return product.salePrice;

  return product.price;
}

첫 번째 버전은 들여쓰기가 깊어지면서 시선이 오른쪽으로, 다시 왼쪽으로 지그재그를 그린다. 뇌는 각 중첩 수준에서 “지금 어느 조건 안에 있는가”를 작업 기억에 유지해야 한다.

반면 두 번째 버전은 예외를 먼저 걸러낸 뒤 위에서 아래로 자연스럽게 흘러내린다. 연속성의 원리에 부합하기 때문에 뇌가 구조를 파악하는 데 드는 비용이 크게 줄어든다.

인지 부하 이론: 세 가지 부하의 종류

여기까지의 이야기를 좀 더 체계적으로 정리해주는 프레임워크가 있다. 존 스웰러(John Sweller)의 인지 부하 이론이다.

이 이론에 따르면 학습이나 문제 해결 시 발생하는 인지 부하는 세 가지로 나뉜다.

내재적 부하: 과제 자체의 본질적 복잡성. 알고리즘의 난이도, 도메인의 복잡성 같은 것.
외재적 부하: 과제와 무관한, 표현 방식에서 오는 불필요한 복잡성. 일관되지 않은 네이밍, 불필요한 간접 참조, 혼란스러운 코드 구조 같은 것.
본유적 부하: 새로운 스키마를 형성하고 학습하는 데 드는 유익한 부하.

이 이론에 따르면 우리가 읽기 쉬운 코드를 작성하기 위해 추구해야하는 것은 외재적 부하를 최소화하는 것이다.

어차피 내재적 부하는 문제 자체에 내재된 것이니 줄일 수 없다. 예를 들어 분산 시스템의 합의 알고리즘을 구현하는 코드는 아무리 잘 써도 복잡할 수밖에 없는 것이다. 우리가 피해야할 문제는 “표현 방식”에서 오는 외재적 부하가 내재적 부하 위에 불필요하게 쌓일 때다.

이 관점으로 보면 코드 가독성을 높이는 일관된 네이밍, 적절한 함수 분리, 명확한 타입 선언, 의미 있는 빈 줄과 같은 패턴은 결국 외재적 인지 부하를 줄이는 행위다. 뇌의 제한된 자원을 외재적 부하에 낭비하지 않고, 내재적 부하(실제 문제)를 처리하는 데 집중할 수 있게 해주는 것이다.

2023년에 발표된 체계적 문헌 리뷰에서도 흥미로운 사실이 확인됐다. 소스 코드 메트릭과 실제 측정된 인지 부하 사이의 관계를 조사한 연구들에서 전통적 코드 메트릭 중 실제 인지 부하와 일관되게 높은 상관을 보인 것은 드물었고, 상관이 확인된 경우에도 과제 조건이나 측정 방식에 따라 결과가 달라지는 경향이 있었다. 즉, 우리가 “복잡도”라고 측정하는 것과 개발자의 뇌가 실제로 “복잡하다”고 느끼는 것은 다를 수 있다는 뜻이다.

이건 의미심장한 결과다. 기계적으로 측정 가능한 메트릭은 코드의 외형적 복잡도를 포착하지만, 개발자의 뇌가 실제로 겪는 인지 부하는 패턴의 익숙함, 청킹의 효율성, 시각적 구조의 명확성과 같이 주관적 인식에 영향을 받는다는 것이다.

경험이 뇌를 물리적으로 바꾼다

앞서 전문가와 초보자의 뇌 활성화 패턴이 다르다고 했다. 이건 단순히 개발 짬바가 쌓이면 더 잘한다는 이야기가 아니다. 2024년 Scientific Reports에 발표된 연구에서는 62명의 파이썬 프로그래머를 대상으로 뇌파를 측정하며, 코드에 의도적으로 삽입한 문법 오류와 의미 오류에 대한 뇌의 반응을 관찰했다.

결과는 놀라웠다. 숙련된 프로그래머는 코드의 문법적 위반과 의미적 위반에 대해 서로 다른 뇌파 패턴을 보였다. 이는 자연어를 읽을 때 문법 오류와 의미 오류에 대해 다른 뇌파가 나타나는 것과 유사한 패턴이다. 프로그래밍 경험이 뇌에 특정 언어와 패턴을 처리하기 위한 신경 회로를 형성한다는 뜻이다.

다시 말해, 코딩 경험은 뇌의 물리적 구조를 변화시킨다. 신경가소성에 의해, 반복적으로 노출된 코드 패턴은 장기 기억에 스키마로 저장되고, 이 스키마가 청킹의 기반이 된다. 시스템 1이 코드를 자동으로 처리할 수 있는 것은 이런 스키마가 축적된 결과다.

또한 스키마는 개인이 노출된 패턴에 따라 형성되기 때문에 같은 코드베이스에서 같은 패턴을 반복적으로 접한 사람들은 비슷한 스키마를 공유하게 된다. 이걸 뒤집어 생각하면 팀에서 일관된 코드 스타일을 유지하는 것은 취향의 문제가 아니라 팀원들의 뇌에 공유된 청크를 형성하는 과정인 셈이다. 코딩 컨벤션이 중요한 이유가 단순히 통일성이 아니라, 집단적 인지 효율성 때문인 것이다.

예측 부호화: 뇌는 코드를 읽는 게 아니라 예측한다

최근 인지과학에서 주목받는 이론 중 하나는 예측 부호화다. 이 이론에 따르면, 뇌는 수동적으로 정보를 수신하는 게 아니라, 끊임없이 다음에 올 정보를 예측하고, 실제 입력이 그 예측과 다를 때만 추가적인 처리를 한다.

코드를 읽을 때도 마찬가지다. 우리 뇌는 다음 줄에 뭐가 올지 끊임없이 예측한다.

async function fetchUserProfile(userId: string) {
  try {
    const response = await api.get(`/users/${userId}`);
    // 여기에 뭐가 올지, 이미 예측하고 있다

이 코드를 읽는 숙련된 개발자의 뇌는 이미 “뭐 이제 응답 데이터를 파싱해서 리턴하겠지”라고 예측하고 있다. 그리고 실제로 return response.data; 같은 코드가 나오면 그 예측이 맞았으므로 추가적인 인지 비용이 거의 발생하지 않는다.

하지만 만약 예측과 전혀 다른 쌩뚱맞은 코드가 나오면 어떻게 될까?

async function fetchUserProfile(userId: string) {
  try {
    const response = await api.get(`/users/${userId}`);
    globalEventBus.emit('user-fetched', response.data); // 엥 이거 뭐임?
    localStorage.setItem('lastUser', JSON.stringify(response.data)); // 어라?
    analytics.track('profile_view', { userId }); // 아 로깅을 왜 여기서 해
    return response.data;

fetchUserProfile이라는 이름에서 뇌가 예측한 것은 “사용자 프로필을 가져와서 돌려주는 함수”다. 그런데 이벤트 버스 발행, 로컬 스토리지 저장, 애널리틱스 추적이라는 예측 밖의 동작이 나타난다. 이때마다 뇌는 예측 오류 신호를 발생시키고, 시스템 2를 호출해서 이 코드가 왜 여기에 있는지를 분석하기 시작한다.

즉, 우리가 두 번째 버전의 코드를 읽기 어렵다고 느끼는 이유는 함수의 이름은 fetchUserProfile이지만, 내부에서는 그와 전혀 상관없는 동작들이 발생하고 있기 대문이다. 이름이 설정한 예측과 실제 동작이 일치할수록 예측 오류가 줄어들고 인지 비용이 절감된다.

이건 함수 내부뿐 아니라 인터페이스 설계에서도 마찬가지다. 필자와 같은 프론트엔드 개발자에게 익숙한 컴포넌트 인터페이스를 예시로 들어보자.

// 예측 가능한 인터페이스
<TextInput
  value={name}
  onChange={setName}
  placeholder="이름을 입력하세요"
/>

// 예측이 어려운 인터페이스
<UserNameInput
  user={name}
  setUser={setUser}
  blank="이름을 입력하세요"
/>

첫 번째 컴포넌트는 value, onChange, defaultValue라는 React 생태계에서 거의 모든 입력 컴포넌트가 공유하는 인터페이스를 따른다. 이 패턴을 수없이 접해온 개발자의 시스템 1은 “입력 컴포넌트구나”로 처리하고 넘어간다.

반면 두 번째는 user, setUser, blank라는 비즈니스 로직에 강하게 결합되었거나 의미를 알기 어려운 인터페이스를 가지고 있다. 이 컴포넌트가 내부에서 user 객체의 어떤 필드를 건드리는지, blank는 도대체 언제 사용되는 것인지 파악하기 전까지는 안심하고 사용할 수가 없다. 매번 내부 구현을 들여다봐야 하고, 그때마다 예측 오류가 발생한다.

즉 읽기 쉬운 코드를 작성하기 위해서 우리는 함수의 이름 뿐 아니라 변수명, 파일 구조, 디렉토리 구성, API 설계 등 코드베이스의 모든 수준에서 예측 가능성을 높여야한다.

그래서 “좋은 코드”란 결국

지금까지의 내용을 정리해보면, “읽기 쉬운 코드”라는 주관적 느낌의 실체는 다음과 같다.

작업 기억을 초과하지 않는 코드: 동시에 머릿속에 담아야 할 맥락이 3~4개 이내인 코드
기존 청크와 매칭되는 코드: 익숙한 패턴을 사용해서 장기 기억의 스키마를 활용할 수 있는 코드
시스템 1에서 처리 가능한 코드: 시스템 2를 불필요하게 호출하지 않는, 패턴 인식만으로 이해 가능한 코드
시각적 구조가 논리적 구조와 일치하는 코드: 게슈탈트 원리에 부합하여 뇌의 지각 시스템이 구조를 자동으로 파악하는 코드
예측 가능한 코드: 이름과 구조에서 설정한 기대를 위반하지 않는 코드
외재적 인지 부하가 낮은 코드: 문제 자체의 복잡성만 남기고, 표현에서 오는 불필요한 복잡성을 제거한 코드

이 목록을 보면 재밌는 사실을 하나 발견할 수 있다. 이 중 어느 것도 “정확한 코드”를 의미하지 않는다는 점이다.

가독성과 정확성은 별개의 축이다. 완벽하게 정확하지만 읽기 불가능한 코드도 있고, 읽기는 쉽지만 틀린 코드도 있다. 다만 읽기 쉬운 코드는 버그를 발견하기도 쉽다. 외재적 부하가 낮으니, 뇌의 자원을 논리적 오류를 찾는 데 집중할 수 있기 때문이다.

다만 한 가지 주의할 점이 있다. 카너먼은 시스템 1의 편향에 대해서도 경고했다. 시스템 1은 빠르지만, 그 속도의 대가로 편향이 존재한다. 대표적인 것이 익숙함 편향이다. 자신에게 익숙한 패턴을 “읽기 쉬운 코드”로 느끼는 것은 사실이지만, 그것이 객관적으로 최선인지는 별개의 문제다. 함수형 프로그래밍에 익숙한 개발자는 for 루프를 “읽기 어렵다”고 느낄 수 있고, 반대의 경우도 마찬가지다. 이때 “읽기 어렵다”는 느낌은 코드의 객관적 품질이 아니라, 자신의 시스템 1에 저장된 청크의 편향을 반영하는 것일 수 있다.

코드 리뷰에서 “이해하기 어렵다”는 피드백을 줄 때, 한 번쯤 자문해볼 가치가 있다. 이게 정말로 인지 부하가 높은 코드인가, 아니면 단순히 내 시스템 1에 등록되지 않은 패턴인가? 전자라면 리팩토링이 필요하고, 후자라면 오히려 내 청크 라이브러리를 확장할 기회다.

마무리

“읽기 쉬운 코드”는 그냥 느낌이나 취향의 문제가 아니다. 작업 기억의 용량 제한, 청킹 메커니즘, 이중 처리 시스템, 게슈탈트 지각 원리, 예측 부호화와 같은 인간의 인지 구조가 만들어내는 자연스러운 결과다.

필자가 이전 글에서 “가독성은 주관적이다”라고 했던 이야기의 이유도 바로 여기에 있다. 청킹은 개인의 경험에 의존하고 시스템 1에 등록된 패턴은 사람마다 다르기 때문이다.

같은 코드를 보고 누군가는 쉽다고 느끼고 누군가는 어렵다고 느끼는 건 그저 취향이 달라서가 아니라 뇌에 축적된 스키마가 다르기 때문이다. 가독성이 주관적일 수밖에 없는 이유 자체가 인지 구조에 내재되어 있는 셈이다.

이상으로 우리는 왜 어떤 코드를 읽기 쉽다고 느낄까 포스팅을 마친다.

Why Do Type Systems Behave Like Proofs?

Sun, 25 Jan 2026 10:00:00 GMT

We use types every day and face countless type errors. Each time, we read the error message, search for a fix, and move on. We rarely stop to think about why the type system behaves the way it does.

Knowing how to use types is like understanding grammar. Understanding the type system is closer to understanding why that grammar was designed the way it is.

I previously translated the “Category Theory for Programmers” series, covering concepts like categories, functors, and composition. Looking back, it had a fairly steep learning curve, so I wanted to write a more accessible version.

In this post, I’ll focus on the correspondence between types and logic, and explore what it actually means when the type checker says “pass.”

Is Type Checking Really Just “Checking”?

When most developers first learn TypeScript, they treat the type system like a linter. Put in the wrong type and you get a red underline; put in the right type and it passes.

function add(a: number, b: number): number {
  return a + b;
}

// Error: Argument of type 'string' is not assignable to parameter of type 'number'
add(1, "2");

This isn’t wrong, but it’s missing something.

A type system isn’t just a tool for catching errors. There’s a mathematical structure behind it, and passing type checking means more than “no errors found.” Types correspond to propositions in logic, and code that satisfies a type corresponds to a proof of that proposition.

So what are the type errors we encounter? Simple mistakes — or signals that some contract we implicitly entered into has been broken?

To get there, we need to talk about the math behind type systems.

Formal logic, set theory, and lambda calculus

Type systems rest on three mathematical ideas. Math might sound intimidating here, but these are things we already work with in code every day.

Formal Logic: What It Means to “Prove Something True”

Formal logic is a system for handling propositions like ” $A$ and $B$ ,” ” $A$ or $B$ ,” and “if $A$ then $B$ .” The core idea is: “if you want to claim something is true, you have to prove it.”

Symbol	Everyday Meaning	Example
∧	and	“I have an umbrella and rain boots”
∨	or	“I’ll take the bus or the subway”
→	if … then	“If it rains, the ground gets wet”

For example, to claim that $A \lor B$ is true, you need to show that $A$ is true or show that $B$ is true. “One of them must be true, but I don’t know which” doesn’t count as a proof.

And once you accept ” $A \lor B$ ,” you can see that to derive anything from it, you need branches that handle both cases ( $A$ and $B$ ). This is structurally identical to why type narrowing is needed when working with string | number in code.

  // To claim "A or B" is true, you must concretely show which one
  type Result = string | number;

  function process(x: Result) {
    // "It's one of the two" isn't enough. You need to check which case.
    if (typeof x === 'string') {
      return x.toUpperCase();
    } else {
      return x.toFixed(2);
    }
  }

Set Theory: Types Are Collections of Elements

Think of a set as a bag that holds similar things. The number type is a bag containing every number the program can represent. The string type is a bag of all strings. And number | string is the combined contents of both bags.

// Pull one from the number bag
const n: number = 42;

// Pull one from the string bag
const s: string = "hello";

// Pull from either bag
const x: number | string = Math.random() > 0.5 ? 42 : "hello";

When you think of types as sets, many things become natural. The never type is an empty bag, and unknown is the bag that contains everything.

Strictly speaking, TypeScript’s actual type system differs from pure set theory in some ways, but this level of understanding is sufficient for building intuition.

Lambda Calculus: Functions, and More

Lambda calculus is a concept created in the 1930s by mathematician Alonzo Church to answer the question: “What is computation?” The name sounds intimidating, but if you’re a developer, you already use it every day.

// In lambda calculus: λx.x
const identity = x => x;

// In lambda calculus: λx.λy.x
const first = x => y => x;

Arrow functions are close to the modern syntax for lambda ( $\lambda$ ) notation, and they directly demonstrate lambda calculus’s core idea of “function definition and application.” What Church proved is that these simple concepts alone can express arithmetic, conditionals, loops, and even numbers themselves.

Real JavaScript functions aren’t 100% identical to lambda calculus due to side effects, exceptions, this binding, and the runtime object model. But they share the same basic insight: computation is about creating and applying functions. That’s enough for our purposes.

The Curry-Howard correspondence

So how are these three concepts used in type systems? To answer this, we need to talk about the Curry-Howard correspondence, the concept that unifies them.

The Curry-Howard correspondence (also called the Curry-Howard isomorphism) is a direct relationship between computer programs and logical proofs: proof rules in logic correspond to type rules in type systems.

Logician Haskell Curry first noticed this pattern in the 1930s while adding types to lambda calculus. In 1969, William Howard dug deeper and established these correspondences:

In Logic	In Programming
Proposition	Type
Proof	Program
If A then B	Function from A to B
A and B	Tuple/object containing both A and B
A or B	Union type: A or B
False (unprovable)	never (no value can exist)

If I had to boil it down to one line:

Types correspond to propositions, and programs that produce values of those types correspond to proofs of those propositions.

TypeScript is a language that partially borrows this idea for practical purposes. “Partially” because escape hatches like any and type assertions exist.

So in this post, when I say “proof,” think of it as “fulfilling the contract that the type rules demand.” I’ll revisit TypeScript’s limitations at the end.

Logical Structures Through Types

Let’s now look at how the Curry-Howard correspondence actually manifests, one piece at a time.

Functions: Evidence of “If A Then B”

Let’s start with the most fundamental correspondence: function types. The function type (a: A) => B corresponds to “if $A$ then $B$ ” in logic.

What does this mean? Let me put it in a more everyday analogy.

Say a friend promises: “If you give me flour, I’ll make you bread.” This is the proposition “flour → bread.” How do you verify this promise is real? Simple — you give them flour, and bread comes out.

function makeBread(flour: Flour): Bread {
  // Knead the flour, let it ferment, bake it...
  return bread;
}

This function passing type checking shows that the promise “give me flour and I can make bread” is fulfillable within the type rules. The function’s implementation itself is the fulfillment of that contract.

What happens when a type error occurs?

function makeBread(flour: Flour): Bread {
  // Error: Type 'Flour' is not assignable to type 'Bread'
  return flour;
}

You promised to take flour and make bread, but you just handed back the flour. That’s a breach of contract, hence the type error.

When this contract structure is properly maintained, we can start inferring function results.

In logic, there’s an inference rule called Modus Ponens:

If “if $A$ then $B$ ” is true, and $A$ is true, then $B$ is also true.

For example, if the proposition “if it rains, the ground gets wet” is true and “it’s raining” is also true, then we can easily infer “the ground is wet.” This structure is identical to function calls in programming, which is why we can infer the result type of a function.

// The "flour → bread" promise
const makeBread: (flour: Flour) => Bread = /* ... */;

// We have flour
const flour: Flour = getFlour();

// Therefore we get bread
const bread: Bread = makeBread(flour);

The function makeBread is the proposition “if you give me flour, I can make bread.” If this proposition is true and “flour is given” is also true, then naturally the value stored in bread being of type Bread is also true.

The function calls and return type inference we do every day share this exact structure with logical inference.

Tuples: Evidence of “And”

The logical ” $A$ and $B$ ” corresponds to tuples or objects in programming.

Think of an everyday example. To travel abroad, you need to satisfy the condition “I have a passport and I have a plane ticket.” How do you fulfill this? Show both.

type CanTravel = [Passport, Ticket];

// Fulfilling the "can travel" condition = a tuple with both passport and ticket
const proof: CanTravel = [myPassport, myTicket];

Once the CanTravel type is satisfied — in other words, once “I have a passport and a plane ticket” holds — you can freely extract either one from the tuple.

function getPassport(travel: CanTravel): Passport {
  // Extract A from "A and B"
  return travel[0];
}

function getTicket(travel: CanTravel): Ticket {
  // Extract B from "A and B"
  return travel[1];
}

This mirrors the logical rule “if $A \land B$ is true, then $A$ is true.” Extracting an element from a tuple corresponds to logical inference.

Unions: Evidence of “Or”

TypeScript’s union type A | B corresponds to ” $A$ or $B$ ” in logic. The key point is that to claim ” $A$ or $B$ ” is true, you must concretely show either that $A$ is true or that $B$ is true.

type PaymentMethod = CreditCard | BankTransfer;

// Fulfilling "credit card or bank transfer" = concretely provide one
const payment1: PaymentMethod = { type: 'credit', cardNumber: '1234...' };
const payment2: PaymentMethod = { type: 'bank', accountNumber: '5678...' };

And even if the proposition ” $A$ or $B$ ” is true, you can’t know which one it is until you concretely check.

So to derive anything from this proposition, you need to handle both cases.

function processPayment(method: PaymentMethod): Receipt {
  if (method.type === 'credit') {
    // Handle case A
    return chargeCreditCard(method);
  } else {
    // Handle case B
    return processBankTransfer(method);
  }
}

This is why exhaustiveness checking matters in TypeScript. Logically, when handling ” $A$ or $B$ ,” you need strategies for both cases to have complete coverage.

That said, whether TypeScript automatically checks that all cases are handled depends on your configuration and code patterns. If you want to strictly enforce exhaustiveness, use a pattern like this:

function assertNever(x: never): never {
  throw new Error("Unexpected value");
}

type Shape = { type: 'circle'; radius: number }
  | { type: 'square'; side: number }
  | { type: 'triangle'; height: number };

function area(shape: Shape): number {
  switch (shape.type) {
    case 'circle':
      return Math.PI * shape.radius ** 2;
    case 'square':
      return shape.side ** 2;
    default:
      // Argument of type '{ type: "triangle"; height: number; }' is not assignable to parameter of type 'never'.
      return assertNever(shape);
  }
}

If all union cases are handled, the default branch is unreachable and shape becomes never. But if you add a new shape and forget to handle it, shape won’t be never anymore, and you’ll get a compile error.

Never: Expressing “Impossible”

TypeScript’s never type means “no such value can exist.” In logic, this is expressed as contradiction or falsehood.

Using the set theory analogy from earlier, never is an empty bag. Nothing is in it, and nothing ever will be.

function throwError(message: string): never {
  throw new Error(message);
  // This function never returns normally
  // A return value "cannot exist"
}

There’s an interesting principle from logic here: “from a contradiction, anything can be derived.” In Latin, “Ex falso quodlibet” — if an impossible situation has occurred, anything goes.

We can express this principle in TypeScript:

function absurd<T>(x: never): T {
  return x;  // From never, you can convert to any type
}

This function expresses the rule “if never, then T.” Try replacing never with any concrete type and you’ll immediately get an error. Since never represents falsehood/contradiction, any type can follow it without being logically wrong.

To be precise, TypeScript doesn’t exactly implement Ex falso in the formal sense. The never type is treated as a bottom type — a subtype of all types — so values of type never can be assigned to any type position. It resembles the Ex falso principle, but it’s really a consequence of subtyping.

Generics: Contracts That Hold “For All Cases”

When first learning generics, we’re usually told they let you “decide the type later.” That’s true, but there’s more to it.

In logic, there’s something called a universal proposition: “for all $x$ , $P(x)$ holds.” Like “all humans are mortal.”

Generic functions have a structure similar to this universal proposition.

function identity<T>(x: T): T {
  return x;
}

This function expresses the contract: “for every type T, if you give me a T, I’ll return a T.”

The catch is that you must show this holds for all cases — which means you can’t assume anything about any specific case.

That’s why assuming something specific about a generic type immediately produces a type error:

function broken<T>(x: T): T {
  // Assuming all T is number...
  // Operator '+' cannot be applied to types 'T' and 'number'.
  return x + 1;
}

The moment you assume T is number, this is no longer a contract about all T — it’s narrowed to a contract about number. It’s no longer a universal proposition.

We solve this by adding constraints to the “for all” premise:

function addOne<T extends number>(x: T): number {
  return x + 1;  // OK
}

With T extends number, T becomes “a T that is a subset of number.” We’re adjusting the scope of “all.” That’s why we use the extends keyword for these constraints.

Composition and Transformation

So far we’ve looked at the basic correspondences between types and logic. Now let’s talk about how to combine and transform them.

Function Composition: Chaining Inferences

In logic, there’s the syllogism. The most basic hypothetical syllogism can be expressed as:

If $A$ then $B$ . If $B$ then $C$ . Therefore, if $A$ then $C$ .

For example, if “eating makes you full” is true and “being full makes you sleepy” is true, then “eating makes you sleepy” is also true. In programming, this is expressed as function composition.

function compose<A, B, C>(
  f: (a: A) => B,
  g: (b: B) => C
): (a: A) => C {
  return (a) => g(f(a));
}

const parseNumber = (s: string): number => parseInt(s, 10);
const isPositive = (n: number): boolean => n > 0;

// Connecting string → number
// and number → boolean
// gives us string → boolean
const isPositiveString = compose(parseNumber, isPositive);

isPositiveString("42"); // true

Chain enough small inferences and you get larger, more complex ones. That’s what makes function composition powerful, and why pipe, compose, Functors, and Monads come up so often in functional programming.

In category theory, composition is the defining operation of a category. If you’re interested, see “Category Theory for Programmers - 1. Category: The Essence of Composition”.

Currying: A Logically Natural Transformation

Currying is the pattern of transforming a multi-argument function into a chain of single-argument functions. It makes composition easier because any function can be reduced to the common pattern of unary functions.

An interesting point is that this transformation from multi-argument to single-argument functions is always possible. Why?

In logic, there’s an equivalence called the Exportation law, and currying is a pattern based on this concept:

$(A \land B) \rightarrow C \equiv A \rightarrow (B \rightarrow C)$

“If (A and B) then C” is logically equivalent to “If A, then (if B then C).”

Strictly speaking, $(A \land B) \rightarrow C$ corresponds to “a function that takes a tuple of $A$ and $B$ and returns $C$ ,” and JavaScript’s multi-argument functions are a practical approximation of this.

In more everyday terms: “If you have flour and water, you can make dough” and “If you have flour, then (if you have water, you can make dough)” mean the same thing. This is why the transformation is always safe.

// Takes two arguments at once
function makeDough(flour: Flour, water: Water): Dough {
  return mix(flour, water);
}

// Takes one argument at a time (curried)
function makeDoughCurried(flour: Flour): (water: Water) => Dough {
  return (water) => mix(flour, water);
}

// Both are logically equivalent
const dough1 = makeDough(flour, water);
const dough2 = makeDoughCurried(flour)(water);

Currying is possible not because it’s merely a programming technique, but because it mirrors a logical equivalence.

Type Algebra: Like Addition and Multiplication

Have you heard the term Algebraic Data Types? It means that types support operations analogous to arithmetic in algebra.

For example, there are product types and sum types. A representative product type is the tuple (“and”), and a sum type is the union type (“or”).

type Bool = true | false;  // 2 values
type Pair = [Bool, Bool];  // 2 * 2 = 4 values
// [true, true], [true, false], [false, true], [false, false]

type Three = 'a' | 'b' | 'c';  // 3 values
type Five = Three | Bool;       // 3 + 2 = 5 values
// 'a', 'b', 'c', true, false

This is why they’re called Algebraic Data Types. When you look at types in terms of the number of possible values, sum types behave like addition and product types like multiplication.

What’s even more interesting is that the distributive law from algebra also shows up in types. Mathematically:

$A \times (B + C) \equiv (A \times B) + (A \times C)$

In TypeScript, this structure becomes very clear in one particular feature: conditional types.

TypeScript’s conditional types automatically distribute over union types. This property lets you directly observe the distributive law of type algebra:

type PairWith<A, B> = B extends any ? [A, B] : never;

type A = string;
type B = number | boolean;

// Since boolean = true | false, this distributes into a union of three products
// [string, number] | [string, false] | [string, true]
type Result = PairWith<A, B>;

This example shows that when B is the sum type number | boolean, the product type [A, B] distributes into the sum type [A, number] | [A, boolean].

At the type level, we see the same algebraic distributive law: $A \times (B + C) \equiv (A \times B) + (A \times C)$ .

TypeScript’s type system doesn’t always automatically treat these distributed forms as identical types. But at the level of type computation and transformation rules, the ideas of algebraic data type addition, multiplication, and distribution are clearly alive.

In category theory, products and sums are treated from an even more abstract perspective called Universal Construction. See “Category Theory for Programmers - 9. Function Types” for how these algebraic structures are extended.

TypeScript Isn’t 100% Logically Sound

Now that we’ve covered the basic concepts, let’s look at the TypeScript limitations I mentioned earlier.

I said TypeScript partially borrows the Curry-Howard correspondence. What are its limits?

TypeScript intentionally provides several escape hatches that can lead to logical contradictions, all in the name of practicality. I’ll cover two representative ones here.

The first escape hatch is the existence of any and type assertions. any is a declaration to skip type checking entirely. In logical terms, it’s like “accepting anything as true without verification.” Type assertions via as are the same.

These are escape hatches that bypass the proof system, which is why TypeScript becomes a language that permits logical contradictions.

const x: any = "hello";
const y: number = x; // Assigning a string to a number type

const z = "hello" as unknown as number;  // Forced type conversion

The second escape hatch is corner cases in structural typing. Notably, function parameter bivariance, index signatures, and optional properties can all undermine logical interpretation.

Logically, function parameters should be contravariant. In simple terms, if Dog is a subtype of Animal, then (animal: Animal) => void should be a subtype of (dog: Dog) => void — because a function that accepts a broader type can substitute for one that accepts a narrower type.

But TypeScript treats method-syntax function declarations as bivariant:

  interface Animal { name: string }
  interface Dog extends Animal { breed: string }

  type Handler = { handle(animal: Animal): void };

  const dogHandler: Handler = {
    // A function that only handles Dogs is assigned where Animal is expected
    // Not caught even with strictFunctionTypes
    handle(dog: Dog) { console.log(dog.breed) }
  };

  dogHandler.handle({ name: "cat" }); // Possible runtime error

Index signatures can also lead to logical contradictions. Even when accessing a key that doesn’t exist on an object, TypeScript infers the declared type rather than undefined:

const scores: { [name: string]: number } = { alice: 100 };

const bobScore = scores["bob"]; // Type is number, actual value is undefined
console.log(bobScore.toFixed(2)); // Runtime error

If you want stricter type checking, enable the noUncheckedIndexedAccess option in tsconfig to properly infer number | undefined.

Finally, there’s the confusion between optional properties and undefined. In a type like { a?: string }, the state where a is undefined and the state where a doesn’t exist at all aren’t logically distinguished:

type Config = { timeout?: number };

const config1: Config = { timeout: undefined }; // OK
const config2: Config = {}; // OK

// Both are treated as the same type, but
// Object.hasOwn(config1, 'timeout') and Object.hasOwn(config2, 'timeout') differ

Since TypeScript 4.4, the exactOptionalPropertyTypes option lets you more strictly distinguish between “doesn’t exist” and “exists as undefined.”

These escape hatches are the result of TypeScript choosing practical JavaScript compatibility over 100% logical soundness.

Wrapping Up

This post isn’t about how to use TypeScript better. If you’ve worked with types extensively in practice, most of the examples here are probably familiar.

What I wanted to convey is a perspective. Instead of seeing type errors as obstacles to get past, try reading them as a tool that tells you what contract you declared and where it’s breaking down.

Once you start thinking this way, type errors hit differently. Less “why doesn’t this work” and more “what contract am I violating.”

Type systems have more to say than we usually give them credit for.

If you found this post interesting, check out the “Category Theory for Programmers” series. It covers how composition, product and sum types, and function types are generalized in category theory, and how functors and natural transformations extend them further.

타입 시스템은 왜 증명처럼 동작하는가

Sun, 25 Jan 2026 10:00:00 GMT

우리는 매일 타입을 사용하며, 무수한 타입 에러를 마주한다. 그때마다 에러 메시지를 읽고, 구글링해서 해결하긴 하지만 정작 “타입 시스템이 왜 이렇게 동작하는지”를 깊게 생각하며 문제를 해결하는 경우는 드물다.

타입을 쓸 줄 아는 것이 문법을 이해하는 것이라면, 타입 시스템을 이해하는 것은 그 문법이 왜 그렇게 설계되었는지에 대한 본질을 이해하는 것에 가깝다.

사실 이러한 이해를 돕기 위해 “프로그래머를 위한 카테고리 이론” 시리즈를 번역하면서 카테고리, 펑터, 합성 같은 개념을 다뤘었는데, 지금 돌아보니 진입 장벽이 꽤 높은 내용이라, 조금 더 쉬운 버전의 포스팅을 다시 작성하려고 한다.

그래서 이번 포스팅에서는 타입과 논리학의 대응 관계를 중심으로, 타입 검사기가 “통과”라고 말할 때 그것이 정확히 무엇을 의미하는지 살펴보려 한다.

타입 검사는 정말 “검사”일 뿐일까

TypeScript를 처음 배울 때 대부분의 개발자는 타입 시스템을 일종의 린터(linter)처럼 받아들인다. 마치 린터처럼 잘못된 타입을 넣으면 빨간 줄이 그어지고, 올바른 타입을 넣으면 통과하기 때문이다.

function add(a: number, b: number): number {
  return a + b;
}

// Error: Argument of type 'string' is not assignable to parameter of type 'number'
add(1, "2");

틀린 말은 아니지만 이 관점에는 한 가지 빠진 것이 있다.

타입 시스템은 단순히 에러를 잡는 도구가 아니다. 그 뒤에는 수학적 구조가 있고, 타입 검사를 통과한다는 것은 단순히 에러가 없다는 것 이상의 의미를 가진다. 타입은 논리학의 명제에 대응하고, 그 타입을 만족하는 코드는 그 명제의 증명에 대응한다.

그렇다면 우리가 마주하는 타입 에러는 무엇일까? 단순한 실수일까, 아니면 우리가 암묵적으로 맺은 어떤 계약이 깨졌다는 신호일까.

이 이야기를 이해하려면 가장 먼저 타입 시스템에 사용되는 기본적인 수학의 개념들에 대한 이야기를 해야한다.

타입 시스템의 세 기둥: 형식 논리학, 집합론, 람다 대수

타입 시스템은 세 가지 수학적 아이디어 위에 서 있다. 갑자기 수학에 대한 이야기가 나와서 어렵게 느껴질 수 있지만 걱정할 필요 없다. 이 개념들은 우리가 이미 코드로 매일 다루고 있는 것들이다.

형식 논리학: “참이다”를 증명한다는 것

형식 논리학은 $A$ 이고 $B$ 이다, $A$ 이거나 $B$ 이다, $A$ 이면 $B$ 이다 같은 논리들을 다루는 체계다. 핵심 아이디어는 “참이라고 주장하려면, 그것을 증명해야 한다는 것”이다.

기호	일상적 의미	예시
∧	그리고	“우산도 있고 장화도 있다”
∨	또는	“버스를 타거나 지하철을 탄다”
→	~하면 ~이다	“비가 오면 땅이 젖는다”

예를 들어 $A \lor B$ 가 참이라고 말하려면, $A$ 가 참임을 보여주거나, $B$ 가 참임을 보여줘야 한다. “둘 중 하나는 참이겠지만 어느 쪽인지는 몰라요”라는 식의 주장은 증명으로 인정되지 않는다.

그리고 일단 ” $A \lor B$ “를 받아들이면, 그로부터 무언가를 이끌어내기 위해서는 두 경우( $A$ , $B$ )를 모두 다루는 분기가 필요하다는 것도 알 수 있다. 이는 마치 코드에서 string | number를 다룰 때 타입 좁히기가 필요한 이유와 같은 구조다.

  // "A 또는 B"가 참이라고 주장하려면, 둘 중 하나를 구체적으로 보여줘야 한다
  type Result = string | number;

  function process(x: Result) {
    // "둘 중 하나겠지"로는 안 된다. 어떤 경우인지 확인해야 한다.
    if (typeof x === 'string') {
      return x.toUpperCase();
    } else {
      return x.toFixed(2);
    }
  }

집합론: 타입은 원소들의 모임이다

집합은 비슷한 것들을 모아놓은 주머니라고 생각하면 된다. 예를 들어 number 타입은 프로그램 상에서 표현할 수 있는 모든 숫자를 담은 주머니, string 타입은 모든 문자열을 담은 주머니이고, number | string은 이 두 주머니의 내용물을 합친 것이다.

// 숫자 주머니에서 하나 꺼냄
const n: number = 42;

// 문자열 주머니에서 하나 꺼냄
const s: string = "hello";

// 둘 중 아무 주머니에서나 꺼낸 것
const x: number | string = Math.random() > 0.5 ? 42 : "hello";

타입을 집합으로 생각하면 많은 것이 자연스러워진다. never 타입은 빈 주머니이고, unknown 타입은 세상 모든 것이 들어있는 주머니다.

물론 엄밀하게 이야기하자면 TypeScript의 실제 타입 시스템은 순수한 집합론과 다른 부분이 있지만, 이 정도 이해로도 직관을 잡기에는 충분하다.

람다 대수: 함수, 그 이상의 의미

람다 대수는 1930년대 알론조 처치(Alonzo Church)라는 수학자가 “계산이란 무엇인가?”라는 질문에 답하려고 만든 개념이다. 이름은 무시무시하게 느껴지지만, 사실 개발자라면 이미 매일 쓰고 있는 것이다.

// 람다 대수로 표현하면 λx.x
const identity = x => x;

// 람다 대수로 표현하면 λx.λy.x
const first = x => y => x;

화살표 함수는 람다( $\lambda$ ) 표기의 현대적 문법에 가깝고, 람다 대수의 핵심 아이디어인 “함수 정의와 적용”을 가장 직접적으로 보여준다. 처치가 증명한 놀라운 사실은 이 단순한 개념만으로도 사칙연산, 조건문, 반복문, 심지어 숫자 자체까지 모두 표현할 수 있다는 것이다.

물론 실제 JavaScript 함수는 부수효과, 예외, this 바인딩, 런타임 객체 모델 같은 것 때문에 람다 대수와 100% 동일하다고 말하기는 어렵다. 하지만 “계산이란 결국 함수를 만들고 적용하는 것”이라는 핵심적인 통찰은 공유하기 때문에 이 정도 이해로도 충분하다.

세 세계가 만나는 지점: Curry-Howard 대응

그렇다면 이 세 가지 개념이 타입 시스템에 어떻게 사용되고 있다는 것일까? 이 질문에 대한 답을 하려면 이 개념들을 하나로 묶어주는 Curry-Howard 대응에 대해 이야기해야한다.

Curry-Howard 대응 또는 Curry-Howard 동형이라고 불리는 개념은 컴퓨터 프로그램과 논리적 증명을 직접적으로 연관시키는 대응 관계를 의미한다. 더 정확하게 말하자면 논리학의 증명 규칙과 타입 시스템의 타입 규칙이 서로 대응한다는 주장이다.

이 개념은 이미 1930년대에 하스켈 커리(Haskell Curry)라는 논리학자가 람다 대수에 타입을 붙여보다가 발견한 규칙이며, 이후 1969년 윌리엄 하워드(William Howard)가 이 발견을 더 깊이 파고들어 아래와 같은 대응 관계를 확립했다.

논리학에서	프로그래밍에서
명제	타입
증명	프로그램
A이면 B	A를 받아 B를 반환하는 함수
A 그리고 B	A와 B를 둘 다 가진 튜플/객체
A 또는 B	A이거나 B인 유니온 타입
거짓 (증명 불가능)	never (값이 존재할 수 없음)

결국 이 개념의 핵심을 한 줄로 요약해보면 아래와 같다.

타입은 명제에 대응하고, 그 타입의 값을 만드는 프로그램은 그 명제의 증명에 대응한다.

TypeScript는 실용을 위해 이 아이디어를 부분적으로 차용한 언어다. 부분적으로 차용한 언어라는 의미는 any나 타입 단언 같은 탈출구가 있기 때문이다.

그래서 이 글에서 “증명”이라는 표현은 “타입 규칙이 요구하는 계약을 충족한다” 정도로 이해하면 된다. TypeScript의 한계에 대해서는 글 끝에서 다시 이야기해보겠다.

타입으로 보는 논리적 구조

그렇다면 이 Curry-Howard 대응이 실제로 어떻게 나타나는지 하나씩 뜯어보자.

함수: “A이면 B”의 증거

먼저 가장 핵심적인 대응인 함수 타입부터 살펴보자. 함수 타입 (a: A) => B는 논리학에서 $A$ 이면 $B$ 에 해당한다.

이게 무슨 말일까? 이해를 돕기 위해 조금 더 일상적인 비유로 풀어보면 이렇다.

친구가 “네가 밀가루를 주면, 내가 빵을 만들어줄게”라고 약속했다고 하자. 이것은 “밀가루 → 빵”이라는 명제다. 그렇다면 이 약속이 진짜인지는 어떻게 확인할 수 있을까? 간단하다. 실제로 밀가루를 줬을 때 빵이 나오면 된다.

function makeBread(flour: Flour): Bread {
  // 밀가루를 반죽하고, 발효시키고, 굽는 과정을 거친 뒤...
  return bread;
}

이 함수가 타입 검사를 통과한다는 것은, “밀가루를 주면 빵을 만들 수 있다”는 약속이 타입 규칙 안에서 이행 가능함을 보여준 것이다. 함수의 구현체 자체가 그 계약의 이행인 셈이다.

그렇다면 반대로 타입 에러가 발생한다면 어떻게 되는 걸까?

function makeBread(flour: Flour): Bread {
  // Error: Type 'Flour' is not assignable to type 'Bread'
  return flour;  
}

원래 밀가루를 주면 빵을 만들어서 주기로 했는데, 뜬금없이 밀가루를 다시 돌려줬으니 이것은 계약 불이행이라고 볼 수 있고, 따라서 타입 에러가 발생한다.

또한 이 계약과 구조가 제대로 지켜지면 이제 우리는 함수의 동작 결과를 추론할 수 있게 된다.

논리학에는 전건 긍정(Modus Ponens)이라는 추론 규칙이 있는데, 간단하게 정리해보면 아래와 같다.

” $A$ 이면 $B$ 이다”가 참이고, $A$ 가 참이면, $B$ 도 참이다.

예를 들어 “비가 오면 땅이 젖는다”는 명제가 참이고 “비가 온다”라는 명제도 참이라면, 이에 따라 “땅이 젖는다”라는 명제도 참이라는 것을 손쉽게 추론할 수 있다. 이 구조는 프로그래밍에서 함수 호출과 같은 구조이기 때문에 우리는 함수의 결과 타입을 추론할 수 있게 되는 것이다.

// "밀가루 → 빵" 약속
const makeBread: (flour: Flour) => Bread = /* ... */;  

// 밀가루가 있음
const flour: Flour = getFlour();

// 따라서 빵을 얻음
const bread: Bread = makeBread(flour);

함수 makeBread는 “밀가루를 주면 빵을 만들어준다”라는 명제이다. 즉, 이 명제가 참이고 “밀가루를 준다”라는 명제도 참이라면 자연스럽게 bread 변수에 담기는 값이 Bread 타입이라는 명제도 참이 되는 것이다.

우리가 매일 하는 함수의 호출과 결과 타입의 추론은 이러한 논리적 추론과 같은 구조를 가지고 있는 것이다.

튜플: “그리고”의 증거

논리학의 ” $A$ 그리고 $B$ “는 프로그래밍의 튜플이나 객체에 해당한다.

일상적인 예로 생각해보자. 해외여행을 가려면 “여권이 있고 비행기 표도 있다”는 조건을 만족해야 한다. 이 조건을 충족하려면? 여권과 비행기 표를 둘 다 보여주면 된다.

type CanTravel = [Passport, Ticket];

// "여행 가능" 조건의 충족 = 여권과 티켓을 모두 갖춘 튜플
const proof: CanTravel = [myPassport, myTicket];

이렇게 CanTravel 타입이 만족했다면, 다른 말로 “여권도 있고 비행기 표도 있다”는 조건이 만족했다면 아래와 같이 CanTravel 타입의 튜플에서 여권이나 비행기표 모두 자유롭게 꺼내올 수 있다.

function getPassport(travel: CanTravel): Passport {
  // "A 그리고 B"에서 A를 꺼냄
  return travel[0];
}

function getTicket(travel: CanTravel): Ticket {
  // "A 그리고 B"에서 B를 꺼냄
  return travel[1];
}

이것은 논리학에서 ” $A \land B$ 가 참이면 $A$ 도 참이다”라는 규칙과 같은 구조다. 튜플에서 요소를 꺼내는 것이 논리적 추론과 대응되는 셈이다.

유니온: “또는”의 증거

TypeScript의 유니온 타입 A | B는 논리학의 ” $A$ 또는 $B$ “에 해당한다. 여기서 중요한 점은 우리가 ” $A$ 또는 $B$ “가 참이라고 주장하려면 반드시 $A$ 가 참이라는 사실을 보여주거나, $B$ 가 참이라는 사실을 보여줘야 한다는 것이다. 두 논리 중 하나를 구체적으로 제시해야한다.

type PaymentMethod = CreditCard | BankTransfer;

// "신용카드 또는 계좌이체"의 충족 = 둘 중 하나를 구체적으로 제시
const payment1: PaymentMethod = { type: 'credit', cardNumber: '1234...' };
const payment2: PaymentMethod = { type: 'bank', accountNumber: '5678...' };

또한 ” $A$ 또는 $B$ “라는 명제가 참이라고 해도 $A$ 와 $B$ 둘 중 뭐가 참인지 구체적으로 확인하기 전까지는 알 수가 없다는 것과 같다.

그래서 이 명제로부터 다른 무언가를 이끌어내려면 $A$ 와 $B$ 에 대한 처리를 모두 해줘야한다.

function processPayment(method: PaymentMethod): Receipt {
  if (method.type === 'credit') {
    // A인 경우 처리
    return chargeCreditCard(method);
  } else {
    // B인 경우 처리
    return processBankTransfer(method);
  }
}

이것이 TypeScript에서 Exhaustiveness check가 중요한 이유다. 논리적으로 ” $A$ 또는 $B$ “를 다룰 때는 두 경우 모두에 대한 전략이 있어야만 완전한 처리가 되기 때문이다.

다만 TypeScript가 모든 케이스를 다뤘는지 자동으로 체크해주는 것은 설정과 코드 패턴에 따라 달라진다. 그러니 확실하게 Exhaustiveness check를 강제하고 싶다면 아래와 같은 패턴을 사용하는 것이 좋다.

function assertNever(x: never): never {
  throw new Error("Unexpected value");
}

type Shape = { type: 'circle'; radius: number }
  | { type: 'square'; side: number }
  | { type: 'triangle'; height: number };

function area(shape: Shape): number {
  switch (shape.type) {
    case 'circle':
      return Math.PI * shape.radius ** 2;
    case 'square':
      return shape.side ** 2;
    default:
      // Argument of type '{ type: "triangle"; height: number; }' is not assignable to parameter of type 'never'.
      return assertNever(shape);
  }
}

기본적으로 유니온 타입의 모든 케이스를 처리했다면 default에 도달할 일이 없고, shape는 never 타입이 된다. 하지만 만약 새로운 도형을 추가했는데 처리를 깜빡했다면, shape가 never 타입이 아니게 되고 컴파일 에러가 발생한다.

never: “불가능”의 표현

TypeScript의 never 타입은 “이런 값은 존재할 수 없다”를 의미한다. 논리학에서는 이것을 모순 또는 거짓이라고 표현한다.

앞서 언급했던 집합론으로 비유하자면, never 타입은 빈 주머니다. 즉, never라는 주머니 안에는 아무것도 없고, 앞으로도 없을 것이다.

function throwError(message: string): never {
  throw new Error(message);
  // 이 함수는 정상적으로 반환되지 않는다
  // 반환값이 "존재할 수 없다"
}

여기서 논리학의 재미있는 원리 하나가 나온다. 바로 “모순으로부터는 무엇이든 도출할 수 있다”는 것이다. 이는 라틴어로 “Ex falso quodlibet”이라고 하는데, 쉽게 말하면 불가능한 상황이 발생했다면, 그 다음에는 뭐든지 가능하다는 것이다.

이 원리는 타입스크립트에서 아래와 같은 함수를 선언해봄으로써 구현해볼 수 있다.

function absurd<T>(x: never): T {
  return x;  // never에서는 어떤 타입으로든 변환 가능
}

이 함수는 ”never이면 T이다”라는 규칙을 표현하고 있다. 한번 never 타입을 다른 구체적인 타입으로 바꿔보면 바로 에러가 발생하는 것을 알 수 있다. never는 거짓, 모순이기 때문이 그 다음에는 어떤 타입이 오든 논리적으로 틀린 것이 아닌 것이다.

사실 이 부분도 정확하게 뜯어보면 TypeScript가 Ex falso을 정확하게 구현한 것은 아니긴 하다.

never 타입은 모든 타입의 서브 타입으로 취급되는 바닥 타입(Bottom Type)이기 때문에, never 타입의 값은 어떤 타입 위치에도 대입 가능한 것으로 간주된다. 논리학의 Ex falso 원리와 닮긴 했지만 실제로는 서브타이핑의 결과라고 볼 수 있다.

제네릭: “모든 경우에 통하는” 계약

우리는 제네릭을 처음 배울 때 보통 “타입을 나중에 정하는 것”이라고 배운다. 사실 이것도 틀린 말은 아니지만, 제네릭이 의미하는 바는 더 심오하다.

논리학에는 전칭 명제라는 것이 있는데, 이는 “모든 $x$ 에 대해 $P(x)$ 가 성립한다”는 형태의 명제다. 예를 들어 “모든 사람은 죽는다”처럼 말이다.

그리고 제네릭 함수는 바로 이 전칭 명제와 비슷한 구조를 가진다.

function identity<T>(x: T): T {
  return x;
}

이 함수는 “모든 타입 T에 대해, T를 주면 T를 돌려줄 수 있다”는 계약을 표현한다.

여기서 중요한 것은 “모든 경우”에 대해 성립함을 보여야한다는 점인데, 이게 가능하려면 어떠한 특정 경우에 대한 가정도 하면 안된다.

그래서 우리가 제네릭 타입을 사용했을 때 아래와 같은 가정을 하면 바로 타입 에러가 발생하는 것이다.

function broken<T>(x: T): T {
  // 모든 T가 number임을 가정하면...
  // Operator '+' cannot be applied to types 'T' and 'number'.
  return x + 1;
}

위와 같이 T가 number라고 가정하는 순간, 이것은 더 이상 모든 T에 대한 계약이 아니라, number에 대한 계약으로 범위가 좁아져 버린다. 더이상 전칭 명제라고 보기 어려운 것이다.

그래서 우리는 “모든” 이라는 전제에 제약을 추가함으로서 이 문제를 해결할 수 있다.

function addOne<T extends number>(x: T): number {
  return x + 1;  // OK
}

위와 같이 T가 number를 상속받았다면 자연스럽게 T는 이제 ”number의 부분 집합인 T“로 개념이 변경된다. 즉, “모든” 이라는 개념의 범위를 조정하는 제약을 거는 것이다. 그래서 우리는 이런 제약을 걸때 extends라는 상속 키워드를 사용한다.

합성과 변환

지금까지는 타입과 논리학의 기본적인 대응 관계를 살펴봤다. 이제부터는 이것들을 조합하고 변환하는 방법에 대해서 이야기해보도록 하자.

함수 합성: 추론을 연결하기

논리학에는 삼단논법이라는 것이 있다. 가장 기본적인 정언적 삼단논법은 “만약 $A$ 가 $B$ 이고, $B$ 가 $C$ 라면, $A$ 는 $C$ 이다”로 표현할 수 있다.

이러한 삼단논법은 가정을 기반으로 한 가언적 삼단논법으로 표현할 수도 있는데, 이 경우 아래와 같은 명제가 된다.

$A$ 이면 $B$ 이다. $B$ 이면 $C$ 이다. 그러므로 $A$ 이면 $C$ 이다.

예를 들어 “밥을 먹으면 배부르다”라는 명제가 참이고, “배부르면 잠이온다”라는 명제가 참이라면, “밥을 먹으면 잠이 온다”라는 명제도 참이라는 것이다. 그리고 이것이 프로그래밍에서는 함수의 합성으로 표현된다.

function compose<A, B, C>(
  f: (a: A) => B,
  g: (b: B) => C
): (a: A) => C {
  return (a) => g(f(a));
}

const parseNumber = (s: string): number => parseInt(s, 10);
const isPositive = (n: number): boolean => n > 0;

// string → number와
// number → boolean을 연결하면
// string → boolean이 된다
const isPositiveString = compose(parseNumber, isPositive);

isPositiveString("42"); // true

이는 마치 작은 추론들을 연결해서 더 크고 복잡한 추론을 만드는 것과 동일한데, 이렇게 작고 간단한 구조를 쌓아나가며 큰 구조를 만들 수 있다는 점이 함수 합성이 강력한 이유이다.

그래서 함수형 프로그래밍에서는 pipe나 compose와 같은 개념이나 펑터(Functor)나 모나드(Monad)와 같이 함수의 합성과 관련된 개념들이 핵심이 된다.

사실 카테고리 이론에서는 이 합성이야말로 카테고리의 본질이라고 말한다. 만약 관심이 있다면 “프로그래머를 위한 카테고리 이론 - 1. 카테고리: 합성의 본질”도 참고해보자.

커링: 논리적으로 자연스러운 변환

커링(Currying)은 여러 인자를 받는 함수를 한 인자씩 받는 함수의 체인으로 바꾸는 패턴을 의미한다. 커링을 사용하면 어떤 함수든 단항 함수라는 공통의 패턴으로 만들 수 있기 때문에 합성하기가 편해진다는 장점이 있다.

한 가지 재미있는 점은 다항 함수를 단항 함수의 합성으로 변환하는 것이 항상 가능하다는 점이다. 왜 이 변환이 항상 가능한 것일까?

논리학에는 수출 법칙(Exportation)이라는 동치 관계가 있는데, 커링은 바로 이 개념을 활용한 패턴이다.

$(A \land B) \rightarrow C \equiv A \rightarrow (B \rightarrow C)$

“(A 그리고 B)이면 C이다”와 “A이면 (B이면 C이다)“는 논리적으로 동치다.

엄밀히 말하면 $(A \land B) \rightarrow C$ 는 ” $A$ 와 $B$ 를 튜플로 받아 $C$ 를 반환하는 함수”에 대응하며, JavaScript의 다중 인자 함수는 이를 실용적으로 근사한 형태라고 이해하는 것이 정확하다.

조금 더 일상적인 상황을 예를 들어 보면, “밀가루와 물이 있으면 반죽을 만들 수 있다”라는 명제와 “밀가루가 있으면, (물이 있으면 반죽을 만들 수 있다)“라는 명제는 같은 의미를 가진다는 것이다. 그래서 이 변환은 항상 안전하게 진행된다는 것이 보장된다.

// 두 인자를 한번에 받음
function makeDough(flour: Flour, water: Water): Dough {
  return mix(flour, water);
}

// 한 인자씩 받음 (커링)
function makeDoughCurried(flour: Flour): (water: Water) => Dough {
  return (water) => mix(flour, water);
}

// 둘은 논리적으로 동등하다
const dough1 = makeDough(flour, water);
const dough2 = makeDoughCurried(flour)(water);

즉, 다항 함수를 단항 함수로 변경하는 커링이 가능한 이유는 단순한 프로그래밍 기법이 아니라 논리적 동치 관계와 닮아있기 때문이다.

타입 대수: 덧셈과 곱셈처럼

혹시 대수적 데이터 타입(Algebraic Data Type)이라는 말을 들어본 적이 있는가? 이 말은 타입에도 대수학에서의 사칙연산과 같은 연산 법칙들을 적용할 수 있다는 것이다.

예를 들어 곱 타입과 합 타입이 있는데, 대표적인 곱 타입은 위에서 한번 언급했던 “그리고”를 의미하는 튜플, 그리고 합 타입은 “또는”을 의미하는 유니언 타입이 있다.

type Bool = true | false;  // 2가지 값
type Pair = [Bool, Bool];  // 2 * 2 = 4가지 값
// [true, true], [true, false], [false, true], [false, false]

type Three = 'a' | 'b' | 'c';  // 3가지 값
type Five = Three | Bool;       // 3 + 2 = 5가지 값
// 'a', 'b', 'c', true, false

이것이 대수적 데이터 타입(Algebraic Data Types)이라는 이름이 붙은 이유다. 타입을 값의 경우의 수 관점에서 바라보면 합 타입은 덧셈처럼, 그리고 곱 타입은 곱셈처럼 동작한다.

더 흥미로운 점은 대수학에서처럼 타입에서도 분배법칙이 등장한다는 것이다. 수학적으로는 다음과 같은 관계가 성립한다.

$A \times (B + C) \equiv (A \times B) + (A \times C)$

TypeScript에서도 이 구조는 특정 지점에서 매우 명확하게 드러난다. 바로 조건부 타입(Conditional Type) 이다.

TypeScript의 조건부 타입은 유니온 타입에 대해 자동으로 분배(distribute)된다. 이 성질을 이용하면 타입 대수의 분배법칙을 직접 확인할 수 있다.

type PairWith<A, B> = B extends any ? [A, B] : never;

type A = string;
type B = number | boolean;

// boolean = true | false이기 때문에 3가지 곱의 합으로 분배된다
// [string, number] | [string, false] | [string, true]
type Result = PairWith<A, B>;

위 예시는 B가 number | boolean이라는 합 타입일 때, [A, B]라는 곱타입은 다시 [A, number] | [A, boolean]이라는 합 타입으로 분배될 수 있음을 보여준다.

즉, 타입 레벨에서도 대수의 분배 법칙과 동일하게 $A \times (B + C) \equiv (A \times B) + (A \times C)$ 의 모습이 보여지는 것이다.

물론 TypeScript의 타입 시스템은 이러한 분배 구조를 항상 자동으로 동일한 타입으로 취급하지는 않는다. 하지만 최소한 타입을 계산하고 변환하는 규칙의 수준에서는 대수적 데이터 타입의 덧셈, 곱셈, 분배라는 아이디어가 분명하게 살아있다고 볼 수 있다.

카테고리 이론에서는 이 곱과 합을 보편적 구성(Universal Construction)이라는 더 추상적인 관점에서 다룬다. “프로그래머를 위한 카테고리 이론 - 9. 함수 타입”에서 이 대수적 구조가 어떻게 확장되는지 볼 수 있다.

TypeScript는 100% 논리적이지 않다

기본적인 개념들에 대해서 살펴봤다면, 이제는 필자가 위에서 언급했던 TypeScript의 한계에 대해 한번 알아보자.

필자는 TypeScript가 Curry-Howard 대응을 부분적으로 차용한 언어라고 했는데, 그 한계가 뭘까?

TypeScript는 언어의 실용성을 높이기 위해 의도적으로 논리적 모순을 초래할 수 있는 몇 가지 탈출구를 제공한다. 이 포스팅에서는 그 중 대표적인 두 가지에 대해서 이야기해보려 한다.

첫 번째 탈출구는 any와 타입 단언의 존재이다. any는 어떤 타입이든 검사하지 않고 통과시키겠다는 선언이다. 즉, 논리학적으로 보면 “검증 없이 뭐든 참으로 인정”하는 것과 같다. as를 통한 타입 단언도 마찬가지다.

이것들은 증명 체계를 우회하는 탈출구이고, 이로 인해 TypeScript는 논리적인 모순을 허용하는 언어가 되어버렸다.

const x: any = "hello";
const y: number = x; // number 타입에 문자열 할당

const z = "hello" as unknown as number;  // 타입 강제 변환

두 번째 탈출구는 바로 구조적 타이핑의 코너 케이스들이다. 대표적으로는 함수 파라미터의 이변성(Bivariance), 인덱스 시그니처, 옵셔널 프로퍼티 등의 탈출구로 인해 논리적 해석이 흔들리는 경우가 존재한다.

논리적으로 함수 파라미터는 반공변(Contravariant)적이어야 한다. 쉽게 말해 Dog가 Animal의 서브타입이라면, (animal: Animal) => void가 (dog: Dog) => void의 서브타입이어야 한다는 것이다. 이는 더 넓은 타입을 받는 함수가 더 좁은 타입을 받는 함수를 대체할 수 있기 때문이다.

하지만 TypeScript는 메소드 문법으로 선언된 함수에서 이를 이변적으로 처리한다.

  interface Animal { name: string }
  interface Dog extends Animal { breed: string }

  type Handler = { handle(animal: Animal): void };

  const dogHandler: Handler = {
    // Dog만 처리하는 함수인데 Animal을 받는 자리에 할당됨
    // strictFunctionTypes로도 잡히지 않음
    handle(dog: Dog) { console.log(dog.breed) }
  };

  dogHandler.handle({ name: "cat" }); // 런타임 에러 가능

그리고 인덱스 시그니처 또한 논리적인 모순을 초래할 수 있다. 객체에서 존재하지 않는 키에 접근하더라도 TypeScript는 undefined가 아닌 선언된 타입으로 추론하기 때문이다.

const scores: { [name: string]: number } = { alice: 100 };

const bobScore = scores["bob"]; // 타입은 number, 실제 값은 undefined
console.log(bobScore.toFixed(2)); // 런타임 에러

조금 더 엄밀한 타입 체크를 원한다면 tsconfig의 noUncheckedIndexedAccess 옵션을 활성화하면 제대로 number | undefined로 추론되도록 만들 수 있다.

마지막으로 옵셔널 프로퍼티와 undefined의 혼동도 문제가 된다. 예를 들어 { a?: string }이라는 타입에서 a가 undefined인 상태와 아예 존재하지 않는 것이 논리적으로 구분되지 않는다.

type Config = { timeout?: number };

const config1: Config = { timeout: undefined }; // OK
const config2: Config = {}; // OK

// 둘 다 같은 타입으로 취급되지만,
// Object.hasOwn(config1, 'timeout')과 Object.hasOwn(config2, 'timeout')은 다르다

이 부분 또한 TypeScript 4.4 이후 도입된 exactOptionalPropertyTypes 옵션을 사용하면 “존재하지 않음”과 ”undefined로 존재함”을 더 엄밀하게 구분할 수 있다.

이런 탈출구들은 TypeScript가 100% 논리적인 정합성보다는 실용적으로 JavaScript와의 호환성을 선택한 결과라고 볼 수 있다.

마치며

이 글은 타입스크립트를 잘 쓰는 방법을 설명하려는 글은 아니다. 이미 실무에서 타입을 충분히 다뤄본 사람이라면, 여기서 등장하는 대부분의 예시는 익숙할 수도 있다.

다만 필자가 이 글을 통해 전하고 싶었던 건, 타입 시스템을 대하는 관점에 가깝다. 타입 에러를 “통과시켜야 할 장애물”로 보는 대신, 내가 어떤 계약을 선언했고, 그 계약이 어디에서 깨지고 있는지를 읽어내는 도구로 바라보는 시선 말이다.

이 관점이 한 번 자리 잡히면, 타입 에러를 대하는 태도도 자연스럽게 달라진다. 왜 안 되는지를 묻기 전에, 무슨 계약을 어기고 있는지를 먼저 떠올리게 된다.

타입 시스템은 생각보다 많은 이야기를 하고 있다. 다만 그걸 단순한 컴파일 통과 여부로만 읽고 지나치기엔, 조금 아까운 도구일지도 모르겠다.

이 글이 흥미로웠다면, “프로그래머를 위한 카테고리 이론” 시리즈도 읽어보자. 여기서 다룬 합성, 곱과 합 타입, 함수 타입 같은 개념들이 카테고리 이론에서 어떻게 일반화되는지, 그리고 펑터나 자연 변환 같은 개념이 이 아이디어를 어떻게 확장하는지 볼 수 있다.

People Create Excellence, but Systems Make It Last

Sat, 24 Jan 2026 12:44:14 GMT

In this post, I want to talk about what I’ve been thinking about over the roughly two and a half years I’ve spent as a frontend chapter lead at Toss.

My job and goal as a chapter lead at Toss is clear: make the Toss frontend chapter the most excellent engineering organization in the world.

There are many ways to define “excellence,” but what I believe truly matters isn’t creating excellence in the current moment. It’s building an organization that can march toward excellence on its own, even without me.

Organizational Excellence Is Built from Individual Excellence

What Is an Excellent Organization?

I believe an excellent organization is fundamentally a collection of excellent individuals. When exceptional people come together and work side by side, organizational excellence follows. And indeed, the Toss frontend chapter has many outstanding developers who quickly grasp complex problems, craft elegant solutions, and help each other grow.

When leading a small organization, you can build excellence by establishing clear technical and cultural hiring standards and focusing on collecting exceptional talent. That’s why at my previous company, I remember pouring the most energy into hiring.

But the Toss frontend chapter is a large organization — around 250 people across the broader community, with nearly 140 in the Toss Core frontend chapter where I work. Leading an organization this large requires a different approach than leading a small one.

At this scale, simply gathering excellent individuals isn’t enough. With more diverse people joining, the organization needs significantly more energy to understand each person’s strengths and capabilities and make sound decisions.

From 10 to 140: The Need for Systems

Back when the frontend chapter had around 10 people, everyone could know each other in detail — faces, names, personalities.

But when I returned to Toss, the frontend chapter had already grown into a massive organization compared to before.

Even within the same chapter, there are cases where people don’t know who else is on the team. If you’re not actively paying attention, you might not even notice when new hires join. The rules of the game are simply different with 10 people versus 140.

Even a chapter lead, without making a deliberate effort, would find it extremely difficult to understand this many people’s strengths, growth trajectories, and motivations. Right now, individual effort from leads still covers things to some degree, but if the headcount keeps growing, there will inevitably come a point where even that becomes impossible.

Information about individuals would fragment across the minds of multiple leads, and depending on who interacts with which lead, some people would naturally become more visible while others fade into the background.

That’s why I came to think that the lead’s role in this game needs to shift: from “directly caring for people” to “building systems that make the organization excellent on its own.”

Spin the Flywheel That Creates Organizational Excellence

As I mentioned, the key to building an excellent organization is designing one that naturally gravitates toward excellence on its own. This is similar to the flywheel effect borrowed from product development.

The flywheel effect describes a structure where small, repeated impacts accumulate to produce increasingly larger outcomes. It requires a lot of energy at first, but once it starts spinning, momentum allows it to generate bigger results with less effort.

Similarly, in organizational management, when individual activities connect into a virtuous cycle, excellence naturally accelerates.

The flywheel I’ve designed for an excellent organization consists of six stages:

Recruit: Gather exceptional talent obsessed with growth.
Self-awareness: Understand the organization’s expectations and your current state.
Opportunity: Give prepared talent chances to experience growth in small increments.
Recognition: Deliver tangible and psychological rewards to those who’ve grown.
Contribution: People with positive experiences participate in chapter activities, making the organization more excellent.
Branding: Organize and share the chapter’s work externally.

Stage 1: Recruit — Gather Exceptional Talent Obsessed with Growth

Building an excellent organization requires a continuous inflow of exceptional talent. The important thing here isn’t simply finding skilled people, but people who are obsessed with growth and have high growth potential.

Identifying these people during the hiring process matters, but what matters even more is branding that makes people on the outside think, “If I go there, I can grow even more” — naturally driving more applications to Toss.

We need to concretely show what technical capabilities the Toss frontend chapter has and what kind of culture it fosters. This is exactly where Stage 6 (Branding) connects back to Stage 1 (Recruit).

Stage 2: Self-awareness — View Organizational Expectations and Personal Strengths Through a Shared Language

I believe growth always starts with self-awareness. So the growth that an excellent organization produces ultimately begins with how accurately each member recognizes their own capabilities and strengths.

It’s similar to a strategy game. Think of Lü Bu and Zhuge Liang from the Romance of the Three Kingdoms. Both are exceptional talents, but the moment they’re given mismatched roles, their excellence vanishes. Assigning Lü Bu to domestic administration or sending Zhuge Liang into single combat would obviously produce poor results.

The problem is that in reality, people often don’t know whether they’re a Lü Bu or a Zhuge Liang — or they might be a Lü Bu who says they want to do administration. I think this is less about willpower and more about a lack of self-awareness.

That’s why I believe the first step toward growth in an excellent organization is helping members accurately recognize their own capabilities and strengths, then connecting them with the right growth opportunities.

Along these lines, the Toss frontend chapter uses a tool called the Skill Tree. Rather than a device for defining excellence, it’s more like a reference line that helps members see their current capabilities and strengths more clearly, and articulate their next growth direction for themselves.

Once someone can articulate their growth direction and strengths, leads use this information to coach them so their strengths translate into real outcomes and growth.

Stage 3: Opportunity — Let People Experience Growth in Small Increments

Once self-awareness is established, what the organization needs to do next is clear: provide opportunities for members to take on challenges without pressure and experience small wins. No matter how well someone understands their strengths and current state, growth remains theoretical without a real arena to try things in.

This conviction became sharper through a recent leadership survey. The results showed that interest in leadership roles was far greater than expected. However, a common response was: “I’m interested, but I don’t feel ready yet.”

At first, I assumed members felt their capabilities were lacking. But looking at individual responses more closely, it was closer to “I don’t know what I should be preparing for or what capabilities I need to build.” The chapter wasn’t providing enough hints about the direction and methods of growth.

So I decided we needed to create more of these opportunities and expose them more frequently. Growth isn’t built from a single giant leap — it’s built on many small wins. We need to create an environment where chapter members can take on challenges without hesitation.

This problem awareness led to the creation of the Next F-Lead program. This program focuses on three core competencies: strategic thinking, interview skills, and 1-on-1 coaching. The goal isn’t to suddenly turn someone into a lead — it’s to let them experience the F-Lead role in small doses beforehand. Through this, members come to see leadership not as “something far removed from me” but as “a next step I can gradually prepare for.”

Beyond Next F-Lead, we’re working to help members envision their next steps more clearly through various education and experience programs. The key isn’t pushing anyone in a specific direction — it’s creating an environment where each person can try things and choose for themselves.

Someone who has experienced small wins can imagine bigger challenges, and that imagination translates into real action toward the next stage of growth. That’s why the Opportunity stage is so important in the flywheel.

Stage 4: Recognition — Let People Experience Achievement Through Tangible and Psychological Rewards

Growth isn’t completed by experience alone. Recognition must follow for those who’ve produced growth. Positive feedback as a reward is easily underestimated in organizational management, but it’s one of the most important elements for re-accelerating the flywheel.

Within the Toss frontend chapter, there are already many people contributing to the organization by showing their strengths — people who consistently share technical knowledge, participate in activities like the Open Source Committee or Code Quality Committee, or build and share tools that help colleagues work better.

These contributions elevate the organization, but if their value isn’t made visible enough, even the contributors themselves may struggle to feel their own achievements. That’s why I believe these people need to be recognized more often and more clearly.

The same goes for people in lead roles. They don’t just deliver their own results — they help colleagues grow right beside them. From the organization’s perspective, it’s an extremely important role. From the individual’s perspective, it’s no light responsibility. There’s a lot to do and a lot to think about. For me, every day working alongside these people is filled with gratitude, and their dedication absolutely deserves to be rewarded.

That’s why the Toss frontend chapter is preparing a dedicated leadership education program for leads. Beyond just training, we’re also planning opportunities for deeper participation in chapter decision-making, along with explicit expansion of authority and roles. This isn’t just a reward — it’s a clear message: “The organization takes your growth seriously.”

Recognition isn’t the end of achievement. It’s the signal that starts the next phase of growth. Someone who has experienced accomplishment naturally wants to contribute again, and that contribution makes the organization more excellent once more. That’s why the Recognition stage can’t be left out of the flywheel.

Stage 5: Contribution — Positive Experiences Make the Organization Excellent

People who’ve been recognized and experienced achievement naturally start contributing to the organization. And when these contributions are met with the recognition mentioned in Stage 4 — shout-outs, expanded authority, participation in decision-making — the behavior is naturally reinforced. This is the core of the flywheel.

I believe an organization becomes excellent when knowledge sharing and vigorous debate appear frequently. These are what contribution looks like, and these contributions collectively make an organization excellent.

The Toss frontend chapter has a long history of such contributions.

In the early days when the team was small, efforts like building internal libraries, developing TDS (Toss Design System), and creating admin tools were all driven by this kind of contribution. Now it takes the form of technical tool and knowledge sharing, the Open Source Committee, the Code Quality Committee, Frontend Accelerator mentoring, user accessibility improvements, and more.

Leads who completed Next F-Lead improve the program. Developers active in the Open Source Committee propose new libraries. Chapter members who’ve used the Skill Tree provide feedback. All of this is contribution.

Systems are improved by individuals, and improved systems in turn make more individuals excellent. The small flywheel is already spinning.

The final stage is branding — organizing the excellent chapter’s activities and sharing them externally.

Currently, the Toss frontend chapter is building its brand of excellence through various activities: the Open Source Committee, Frontend Accelerator mentoring, the Frontend Fundamentals documentation project, and the Bonfire YouTube content series, among others.

For example, the Open Source Committee has produced several libraries including es-toolkit, es-hangul, and overlay-kit. es-toolkit in particular has been adopted by big tech companies like Microsoft, as well as well-known tools like Storybook and Yarn. It currently sees around 9 million weekly downloads.

Frontend Fundamentals and the Frontend Accelerator mentoring program aim to grow the broader frontend ecosystem. The hope is that this produces more excellent developers in the ecosystem, which in turn naturally funnels exceptional talent toward Toss — creating a virtuous cycle.

Content like the Bonfire YouTube series is a good way to reach many developers at low cost. It shows the standards by which the Toss frontend chapter writes code and who the developers are, which creates branding effects.

All of these activities deliver the message: “The Toss frontend chapter is an excellent organization.” People obsessed with growth who see this message are drawn to Toss. When branding works well, it feeds back into Stage 1 (Recruit), completing the flywheel.

Closing Thoughts

The thing I value most as a leader is building “an organization that runs without me.” It might sound paradoxical, but that’s what real sustainability looks like.

Reducing individual dependency and leaving behind clear standards and functioning systems. Making the flywheel keep spinning even when I go on vacation, focus on something else, or even leave this role entirely. That’s why I’ve spent the past two and a half years focusing not on directly caring for people, but on building systems that make the organization excellent on its own.

A really excellent organization keeps producing excellent individuals. And those individuals make the organization even better.

In truth, each system still has much room for improvement. The Skill Tree needs to become more refined. Next F-Lead needs to produce more leads. The recognition system is still being built. Above all, I’m still searching for a clear answer to whether all of this is truly “making the organization more excellent.”

But I think the direction is right. Small wins are accumulating. Feedback from chapter members keeps flowing in. And most importantly, the small flywheel is actually spinning.

Organizational management isn’t a problem that yields answers overnight. But with a clear direction and functioning systems, the flywheel should spin faster over time.

조직의 탁월함은 사람으로 만들지만 지속성은 시스템이 만든다

Sat, 24 Jan 2026 12:44:14 GMT

이번 포스팅에서는 필자가 지금까지 약 2년 반 정도 토스에서 프론트엔드 챕터 리드로 일하면서 고민해왔던 내용에 대해 이야기하려고 한다.

필자가 토스팀에서 챕터 리드로서 해야하는 일, 그리고 목표는 명확하다. 토스 프론트엔드 챕터를 세상에서 가장 탁월한 조직으로 만들어내는 것이다.

이 탁월함에 대해서는 여러가지 정의를 할 수 있지만, 사실 중요한 것은 현재 상태에서 탁월함을 만들어내는 것보다 필자가 없어도 스스로 탁월함을 향해 나아갈 수 있는 조직이 되는 것이 핵심이라고 생각한다.

조직의 탁월함은 개인의 탁월함이 모여 만들어진다

탁월한 조직이란 무엇인가

탁월한 조직은 기본적으로 탁월한 개인들의 집합이라고 생각한다. 탁월한 개인이 모여 서로에게 자극을 주고 받으며 등을 맞대고 함께 일할 수 있는 조직이 되면 자연스레 조직의 탁월함도 만들어지기 때문이다. 실제로 토스 프론트엔드 챕터에는 복잡한 문제를 빠르게 이해하고, 우아한 해결책을 만들어내고, 서로를 성장시키는 탁월한 개발자들이 많이 있다.

규모가 작은 조직을 리딩할 때는 명확한 기술 / 문화적 채용 기준을 수립하고 탁월한 인재들을 수집하는 것에 집중함으로서 조직의 탁월함을 만들어볼 수 있다. 그래서 필자가 전직장에 있을 때는 채용에 가장 공을 들였던 기억이 난다.

그러나 토스 프론트엔드 챕터는 커뮤니티 기준으로 250명, 필자가 몸담고 있는 토스 코어 프론트엔드 챕터만 140명에 가까운 대조직이다. 이렇게 큰 조직을 리딩할 때는 작은 조직과는 조금 다른 접근 방법이 필요하다.

이 정도로 조직이 크다면 탁월한 개인들을 모으는 것만으로는 충분하지 않다. 더 다양하고 많은 사람들이 모이게 되면서 조직이 이 사람들의 강점과 역량을 파악하고 탁월한 의사결정을 하는데 더 많은 에너지가 필요하기 때문이다.

10명에서 140명, 시스템의 필요성

예전 프론트엔드 챕터가 10명 남짓이었을 시절에는 챕터원들이 서로에 대해 상세하게 파악하는 것이 가능했다. 인원이 적으니 얼굴도 이름도 성격도 알 수 있는 것이다.

하지만 필자가 다시 토스로 돌아왔을 때, 프론트엔드 챕터는 이미 예전에 비해 엄청난 대조직이 되어있었다.

같은 챕터라고 해도 어떤 사람이 있는지 모르는 경우도 있으며 심지어 특별히 관심을 쓰지 않으면 어떤 신규입사자가 들어왔는지도 모른다. 애초에 10명일 때와 140명일 때는 게임의 룰 자체가 다른 것이다.

심지어 챕터 리드조차 특별하게 신경을 쓰지 않는다면 이 많은 인원의 강점, 성장 곡선, 동기를 파악하는 것이 굉장히 어렵다. 지금은 그래도 리드 개인의 노력으로 어느 정도 커버가 되는 수준이지만 만약 여기서 인원이 더 늘어난다면 이마저도 불가능한 순간이 분명히 올 것이다.

개인에 대한 정보는 여러 명의 리드들의 머릿속에 파편화될 것이며, 리드와의 상호작용 여부에 따라 누군가는 더 잘 보이고 누군가는 덜 보이는 상황이 발생하게 될 것이 뻔하다.

그래서 필자는 이 게임에서 리드의 역할이 “사람을 직접 케어하는 것”에서 “조직을 저절로 탁월하게 만드는 시스템을 구축하는 것”으로 변화해야한다고 생각했다.

조직의 탁월함을 만드는 플라이휠을 굴려라

앞서 언급했듯이 탁월한 조직을 만드는 것의 핵심은 탁월함을 향해 저절로 굴러가는 조직을 설계하는 것이다. 이는 마치 제품 개발 개념에서 차용하는 플라이휠 효과와도 유사하다.

플라이휠 효과란 하나의 작은 임팩트들이 반복적으로 누적되며 점점 더 큰 성과를 만들어내는 구조를 말한다. 초기에는 많은 에너지가 필요하지만, 한 번 돌아가기 시작하면 관성에 의해 점점 적은 힘으로도 더 큰 성과를 만들어낸다.

이와 마찬가지로 조직 운영에서도 개별 활동이 선순환 구조로 연결될 때, 탁월함은 자연스럽게 가속된다.

필자가 설계한 탁월한 조직의 플라이휠은 크게 6단계로 구성된다.

유입: 성장에 미쳐있는 탁월한 인재를 모은다.
메타인지: 조직이 원하는 기대치, 현재 나의 상태를 파악한다.
기회제공: 준비가 되어있는 인재가 다음 성장을 작은 단위로 경험할 수 있는 기회를 제공한다.
인정: 성장을 만들어낸 인재들에게 물리/심리적 보상을 전달하여 인정과 성취의 경험을 제공한다.
기여: 좋은 경험을 한 인재들이 프론트엔드 챕터의 여러 활동에 참여하여 조직이 탁월해진다.
브랜딩: 이렇게 탁월해진 챕터의 활동을 정리하여 외부로 알린다.

1단계: 유입 - 성장에 미쳐있는 탁월한 인재를 모은다

탁월한 조직을 만들려면 탁월한 인재가 계속 들어와야 한다. 그런데 여기서 중요한 건 단순히 실력 있는 인재가 아니라 성장에 미쳐있고 성장 가능성이 높은 인재를 모으는 것이다.

이를 위해 채용 단계에서 이런 분들을 찾아낼 수 있는 것도 중요하지만, 더 중요한 것은 브랜딩을 통해 외부에 있는 사람들이 “아, 저기에 가면 내가 더 성장할 수 있겠구나”라는 생각을 할 수 있도록 만들어 자연스레 토스팀에 더 많은 지원을 하는 그림을 만드는 것이다.

토스 프론트엔드 챕터가 어떤 기술력을 가지고 있는지, 어떤 문화를 가진 조직인지를 구체적으로 보여줘야 한다. 이것이 바로 6단계 브랜딩이 다시 1단계 유입으로 연결되는 지점이다.

2단계: 메타인지 - 조직의 기대치와 나의 강점을 같은 언어로 바라본다

필자가 믿는 성장은 언제나 메타인지에서 출발한다. 그래서 탁월한 조직이 만들어내는 구성원들의 성장 또한 결국 구성원 각자가 자신의 역량과 강점을 얼마나 정확하게 인식하고 있는지에서 시작된다고 믿는다.

이건 마치 삼국지 게임과도 비슷하다. 예를 들어 여포와 제갈량을 한번 생각해보자. 두 사람 모두 뛰어난 인재이지만 맞지 않는 역할이 주어지는 순간 그 탁월함은 사라진다. 여포에게 내정을 맡기거나, 제갈량에게 일기토를 시키면 좋지 않은 결과가 나올 것이 뻔하기 때문이다.

문제는 현실에서는 자신이 여포인지 제갈량인지조차 모르는 경우가 많고, 혹은 여포임에도 내정을 하고 싶다고 말하는 경우도 있다. 이는 의지의 문제가 아니라 메타인지의 부족에 가깝다고 생각한다.

그래서 필자는 탁월한 조직에서 만들어내는 성장의 첫걸음은 구성원들이 스스로의 역량과 강점을 제대로 인식하고, 그에 맞는 올바른 성장 기회를 얻는 것에서부터 출발한다고 생각한다.

이런 생각에 연장선에서, 토스 프론트엔드 챕터에서는 스킬트리라는 도구를 활용하고 있다. 이 스킬트리는 탁월함을 규정하기 위한 장치라기보다는 구성원들이 자신의 현재 역량 상태와 강점을 더 선명하게 인식하고 다음 성장 방향을 스스로 언어화할 수 있도록 돕기 위한 참고선에 가깝다.

그리고 자신의 성장 방향과 강점을 언어화할 수 있다면 이제 리드들은 이 정보를 바탕으로 각자의 강점이 실제 성과와 성장으로 이어질 수 있도록 코칭한다.

3단계: 기회제공 - 작은 단위로 성장을 경험하게 한다

메타인지가 이루어졌다면, 그 다음으로 조직이 해야 할 일은 명확하다. 구성원들이 부담 없이 도전하고, 작은 단위의 성공을 경험할 수 있는 기회를 제공하는 것이다. 아무리 자신의 강점과 현재 상태를 잘 인식하고 있어도, 실제로 시도해볼 수 있는 장이 없다면 성장은 관념에 머물 수밖에 없다.

이 생각은 최근 진행한 리더십 설문조사를 통해 더 선명해졌다. 설문 결과를 보면 리더십 역할에 대한 관심은 생각보다 훨씬 많았다. 다만 많은 구성원들이 공통적으로 “관심은 있지만 아직 준비가 안 된 것 같다.”라고 답했다는 점이 특징이었다.

처음에는 구성원들이 스스로의 역량이 부족하다고 느낀다고 생각했지만, 개별 응답을 더 분석해보니 오히려 “내가 무엇을 준비해야 하는지, 어떤 역량을 쌓아야 하는지 잘 모르겠다”에 더 가까웠다. 즉, 챕터가 성장의 방향성과 기준, 그리고 그 방법에 대한 힌트를 충분히 제공하지 못하고 있었던 것이다.

그래서 필자는 이런 기회를 더 많이 만들고, 더 자주 노출해야 한다고 생각했다. 성장은 한 번의 큰 도약이 아니라, 여러 번의 작은 성공 경험 위에서 만들어지는 것이기 때문에 챕터원들이 부담없이 도전할 수 있는 환경을 만들어줘야한다.

이런 문제의식에서 시작된 것이 Next F-Lead 프로그램이다. 이 프로그램은 전략적 사고, 인터뷰 스킬, 1 on 1 코칭이라는 세 가지 핵심 역량에 집중한다. 목표는 누군가를 갑자기 리드로 만드는 게 아니라, F-Lead의 역할을 작은 단위로 미리 경험해볼 수 있도록 돕는 데 있다. 이를 통해 구성원들은 “리더십이 나와는 먼 이야기”가 아니라 “조금씩 준비해볼 수 있는 다음 단계”라는 감각을 얻게 된다.

Next F-Lead뿐만 아니라, 다양한 교육과 체험 프로그램을 통해 구성원들이 자신의 Next Step을 더 선명하게 그릴 수 있도록 노력하고 있다. 중요한 건 누군가를 특정 방향으로 밀어붙이는 게 아니라, 각자가 스스로 도전해보고 선택할 수 있는 환경을 만들어주는 것이라고 생각한다.

작은 성공을 경험한 사람은 더 큰 도전을 상상할 수 있고, 그 상상은 다시 다음 성장을 향한 실제 행동으로 이어진다. 이것이 기회제공 단계가 플라이휠에서 중요한 이유다.

4단계: 인정 - 물리적/심리적 보상으로 성취를 경험하게 하다

성장은 경험만으로 완성되지 않는다. 성장을 만들어낸 사람에게는 반드시 인정이 따라와야 한다. 특히 긍정적인 피드백을 통한 보상은 조직 운영에서 과소평가되기 쉽지만, 실제로는 플라이휠을 다시 가속시키는 데 가장 중요한 요소 중 하나다.

토스 프론트엔드 챕터 안에는 이미 자신의 강점을 드러내며 조직에 기여하고 있는 사람들이 많이 있다. 예를 들면 기술 공유를 꾸준히 하는 사람, 오픈소스 위원회나 코드 퀄리티 위원회 같은 활동에 참여하는 사람, 동료들이 더 잘 일할 수 있도록 도구를 만들어 공유하는 사람들이다.

이런 기여들은 조직을 한 단계 끌어올리지만, 그 가치가 충분히 드러나지 않으면 당사자조차 자신의 성취를 체감하기 어렵다. 그래서 필자는 이들이 지금보다 더 자주, 더 분명하게 인정받아야 한다고 생각한다.

리드 역할을 맡고 있는 사람들 역시 마찬가지다. 이들은 자신의 성과뿐 아니라 동료들의 성장을 바로 옆에서 돕는 역할을 수행한다. 조직 관점에서는 매우 중요한 역할이고, 개인 관점에서는 결코 가볍지 않은 책임이다. 실제로 해야 할 일도 많고, 고민해야 할 것도 많다. 필자에게 이들과 함께하는 매일은 감사의 연속이며, 이런 헌신은 반드시 보상받아야 한다.

그래서 토스 프론트엔드 챕터에서는 이들을 위한 전용 리더십 교육 프로그램을 준비하고 있다. 단순한 교육을 넘어, 챕터의 의사결정에 더 깊이 참여할 수 있는 기회, 명시적인 권한과 역할의 확장도 함께 기획하고 있다. 이건 단순한 보상이 아니라 “당신의 성장은 조직이 진지하게 대하고 있다”는 명확한 메시지다.

인정은 성과의 끝이 아니라 다음 성장을 시작하게 만드는 신호다. 성취를 경험한 사람은 다시 기여하고 싶어지고, 그 기여는 다시 조직을 탁월하게 만든다. 이것이 인정 단계가 플라이휠에서 빠질 수 없는 이유다.

5단계: 기여 - 좋은 경험이 조직을 탁월하게 만든다

인정을 받고 성취를 경험한 인재들은 자연스럽게 조직에 기여하게 된다. 그리고 이런 기여를 했을 때 앞서 4단계에서 언급한 샤라웃, 권한 확장, 의사결정 참여 같은 인정을 다시 받게 되면, 이런 행동은 자연스럽게 강화된다. 이것이 플라이휠의 핵심이다.

필자는 지식의 공유, 새로운 아이디어와 피드백, 격렬한 토론 등이 자주 등장해야 탁월한 조직이 될 것이라 믿는다. 이런 것들이 바로 기여에 해당하고, 이런 기여들이 모여 결국 탁월한 조직이 된다.

사실 토스 프론트엔드 챕터는 이런 기여들을 경험해본 적이 많은 조직이다.

사람이 별로 없던 초반에는 사내 라이브러리 구축, TDS(Toss Design System) 개발, 어드민 개발 등이 이런 기여를 통해 진행됐다. 지금은 기술 관련 도구나 정보 공유, 오픈소스 위원회, 코드 퀄리티 위원회, Frontend Accelerator 멘토링 지원, 유저 접근성 개선 등으로 나타나고 있다.

Next F-Lead를 수료한 리드들이 프로그램을 개선하고, 오픈소스 위원회에서 활동한 개발자들이 새로운 라이브러리를 제안하고, 스킬트리를 사용한 챕터원들이 피드백을 준다. 이 모든 것이 기여다.

시스템은 개인에 의해 개선되고, 개선된 시스템은 다시 더 많은 개인을 탁월하게 만든다. 작은 플라이휠은 이미 돌아가고 있는 것이다.

6단계: 브랜딩 - 탁월함을 외부로 알린다

마지막 단계는 브랜딩이다. 이렇게 탁월해진 챕터의 활동을 정리해서 외부로 알리는 것이다.

현재 토스 프론트엔드 챕터는 오픈소스 위원회, Frontend Accelerator 멘토링, Frontend Fundamentals 문서 제작, 모닥불 유튜브 콘텐츠 등 다양한 활동을 통해 탁월함에 대한 브랜드를 구축해나가고 있다.

예를 들어 오픈소스 위원회는 es-toolkit, es-hangul, overlay-kit 등 여러 라이브러리를 배출해냈는데, 특히 es-toolkit의 경우 마이크로소프트와 같은 빅테크에서 사용하기도 했고, Storybook이나 yarn 같은 유명한 도구에서 채택되기도 했다. 현재는 주간 다운로드 수가 900만 건에 달한다.

또한 Frontend Fundamentals와 Frontend Accelerator 멘토링은 프론트엔드 생태계를 더욱 성장시키는 것을 목표로 하는데, 이를 통해 더 탁월한 개발자들이 생태계 내에서 배출되고 이로 인해 토스팀에도 자연스럽게 탁월한 인재들이 유입되는 선순환을 기대하고 있다.

모닥불 유튜브와 같은 콘텐츠는 상대적으로 적은 비용으로 많은 개발자들에게 좋은 영향력을 만들어낼 수 있는 훌륭한 수단이다. 토스 프론트엔드 챕터가 어떤 기준으로 코드를 작성하는지, 챕터 내에 어떤 개발자들이 있는지 자연스럽게 보여주어 브랜딩 효과를 만들어낸다.

이 모든 활동들은 “토스 프론트엔드 챕터는 탁월한 조직이다”라는 메시지를 외부에 전달하며, 이 메시지를 보고 성장에 미쳐있는 탁월한 인재들이 다시 토스팀으로 유입된다. 브랜딩이 잘 된다면 다시 1단계인 유입으로 이어지며 플라이휠이 완성된다.

마치며

리더로서 필자가 가장 중요하게 생각하는 것은 “내가 없어도 돌아가는 조직”을 만드는 것이다. 역설적으로 들릴 수 있지만, 이것이 진짜 지속 가능성이다.

개인 의존성을 줄이고, 명확한 기준과 작동하는 시스템을 남기는 것. 필자가 휴가를 가거나, 다른 일에 집중하거나, 심지어 이 역할을 떠나더라도 플라이휠이 계속 돌아가도록 만드는 것. 그래서 필자는 지난 2년 반 동안 사람을 직접 케어하는 것이 아니라 조직을 저절로 탁월하게 만드는 시스템을 구축하는 데 집중해왔다.

진짜 탁월한 조직은 탁월한 개인을 계속 만들어낼 수 있는 조직이다. 그리고 그 개인들이 다시 조직을 더 탁월하게 만드는 조직이다.

사실 각 시스템은 아직 개선할 부분이 많다. 스킬트리는 더 정교해져야 하고, Next F-Lead는 더 많은 리드를 배출해야 하고, 인정 시스템은 아직 구축 중이다. 무엇보다 이 모든 것이 정말로 “조직을 더 탁월하게 만들고 있는가”에 대한 명확한 답은 여전히 찾아가는 중이다.

하지만 방향은 맞다고 확신한다. 작은 성과들이 쌓이고 있고, 챕터원들의 피드백이 계속 들어오고 있으며, 무엇보다 작은 플라이휠은 실제로 돌아가고 있기 때문이다.

조직 운영은 단기간에 답이 나오는 문제가 아니다. 하지만 명확한 방향성과 작동하는 시스템이 있다면, 시간이 지날수록 플라이휠은 더 빠르게 돌고 토스 프론트엔드 챕터는 지금보다 더 탁월한 조직이 될 것이라 믿는다.

Asset Management Is a State Management Problem

Sat, 17 Jan 2026 03:06:30 GMT

In this post, I want to step away from technical topics and talk about something closer to everyday life: asset management.

First, let me be clear: I’m not wealthy, and I don’t have some secret formula for making a fortune overnight. What I do have is years of thinking about how an ordinary salaried worker can steadily grow their assets over time.

If you’ve already made serious money through business or investing, this might sound obvious. But for someone like me, managing assets from a fairly average starting point, I think there’s plenty here to relate to. So I’d like to share the framework I’ve built for myself.

Without Knowing Your Current State, No Judgment Is Possible

One of the things I consider most important in asset management is knowing where I currently stand. To do this, I’ve been consistently recording my asset data.

Nobody gets asset management right from the start. Most of us go through trial and error, gradually building our own criteria along the way. But if you don’t even know your current state, it’s impossible to judge whether you’re on the right track.

I’ve been taking a monthly asset snapshot since 2018, when I started working as a developer. Looking back, this accumulated data now shows the trajectory of my assets at a glance — but at the time, it was often more confusing than clarifying. Some months my assets grew; other months they shrank more than expected.

With this data accumulated over time, I can see at a glance how my assets reacted to market events, what my monthly asset growth rate looks like, and how much my assets have grown compared to five years ago.

The thought that came up most often while keeping records was: “Am I heading in the right direction?” What mattered wasn’t whether my assets went up or down in a given month, but whether I managed to stick to my predetermined criteria without being swayed by emotion.

The numbers I see today are just outcomes. The real value of this data, for me, lies in being able to verify that my current choices remain consistent with my past judgments — even amid uncertainty. Without these records, I would very likely have lost my way somewhere along the line.

That’s why I don’t use asset data as a tool for predicting the future. I use it only to confirm where I stand right now, and to check that my decision-making criteria haven’t drifted.

Right Abstraction Matters More Than Precise Numbers

It’s widely known that data matters in finance and asset management. The most common starting point is an expense tracker — recording income and expenses to understand your cash flow is certainly meaningful.

The problem is that this tool doesn’t tend to last very long. When you try to classify dozens or hundreds of transactions each month and get every number exactly right, it starts to feel like a burden. If the numbers don’t balance perfectly, it nags at you, and once you fall behind on recording, you end up abandoning it altogether. I went through this cycle several times before giving up on keeping a detailed expense tracker.

But if you think about it, the problem can be framed differently.

Does it really need to be exact...?

The core issue wasn’t that I stopped recording. It was that I took the premise of precision for granted. We’re not doing corporate accounting or filing tax returns with our personal finances, so is data accurate down to the last dollar really essential?

What matters more in personal asset management isn’t precise numbers. It’s whether you can simplify the complex reality of finance into something you can actually judge. In this sense, asset management is pretty similar to how developers handle complex systems.

When we write programs, we don’t manipulate memory addresses directly. We don’t try to solve everything with bit-level operations. Instead, we use abstractions like variables, types, and interfaces. We sacrifice some fine-grained control in exchange for the ability to understand the overall structure and make better decisions.

I think the same thing happens in asset management. If you try to decompose and categorize every expense precisely, your judgment slows down and emotions have more room to creep in. Conversely, if you summarize the structure into a few key metrics, you can much more quickly assess whether your current state is risky, sustainable, or safe enough for aggressive moves.

In the end, abstraction matters in asset management not because it’s less work, but because it simplifies your decision-making criteria. What matters more than where you spent an extra $10 is whether you’re in a financially safe state, whether your cash flow is structurally sustainable, and what options you have for reaching your goals.

I believe asset management is the process of establishing criteria that won’t waver even in uncertain situations. And those criteria are built on well-designed abstractions, not precise data.

Assets Can Be Summarized as Flow and State

I mentioned earlier that asset management is a problem of abstraction, not precision. So what information do you actually need to abstract personal assets into something you can make judgments about?

It turns out you don’t need much. At a high level, two things are sufficient: data on asset flow and data on current state.

This is similar to the cash flow statement and balance sheet found in corporate financial statements. With just these two reports, you can quickly understand how a company earned and spent its money, and what its current financial position looks like.

Personal asset management isn’t fundamentally different. You don’t need corporate-level accounting, but you should at least know how money flows in and out, and how your assets are currently structured.

Asset flow can be tracked through cash flow data — how much you earned this month, how much you spent, and what’s left over. This data determines the speed and direction of your asset management. If the flow isn’t healthy, your assets will eventually stagnate or shrink.

Asset state, on the other hand, is tracked through snapshot data: how much immediately available cash you have, what forms your assets are tied up in, and how much debt you carry. This data reveals the range of risk you can currently absorb.

Neither dataset needs to be perfectly accurate. What personal asset management requires isn’t numerical precision but a sense of structure. It matters more to know your rough income-to-expense ratio than to know your exact spending this month. Likewise, knowing the ratio of liquid to illiquid assets matters more than having your net worth accurate to the last ten dollars.

When you separate flow and state like this, asset management gets simpler. Is the flow stable? Does the state carry excessive risk? Being able to answer just these two questions enables most important financial decisions.

Rather than trying to look at more data, I’ve focused on consistently checking these two pieces of information. As a result, even when market conditions changed or my assets grew in size, my decision-making criteria remained largely stable.

Now I’d like to go into more detail about how I approach each of these. Let’s start with cash flow.

Cash Flow: Look at Ratios, Not Detailed Logs

Understanding asset flow ultimately comes down to checking how much you earned in a month and how much you kept. When people think of managing cash flow, they usually think of an expense tracker, but I don’t think detailed expense tracking is necessarily the right answer.

The purpose of an expense tracker isn’t really to record exactly where every dollar went — it’s to understand the structure of your income and spending. But in many cases, the means and the end get reversed. Once the recording itself becomes a burden, understanding your flow becomes impossible, let alone maintaining the habit.

So when managing cash flow, I use much simpler categories than itemized expenses:

Major Category	Subcategory	Category
Income	Employment	Salary
	Employment	Business
	Debt	Loans
	Investment	Dividends
		Sale proceeds
		Interest
Expenses	Consumption	Personal spending
	Fixed costs	Insurance
		Phone/internet
		Utilities
	Housing	Rent
		Maintenance fees

There’s no single right answer for these categories. What matters isn’t copying someone else’s structure, but understanding why you chose to split things the way you did.

In my case, I separate employment income from investment income, and I break out fixed costs and housing from general spending. I wanted to see what proportion of my income is passive, and how much of my earnings go to housing. If that information isn’t useful to you, bundling all spending into one category works perfectly fine.

Even with this rough structure, it’s more than enough to see how much I earned in a month and how much I kept.

Organizing cash flow this way already reveals a lot, but the single most important metric in my view is the profit margin — roughly what percentage of monthly income I’m keeping.

This one number contains more information than you’d think. It intuitively shows whether income is growing, whether spending is excessive, or whether your lifestyle is outpacing your asset growth. You might not know where an extra $50 went, but you definitely know whether you kept 30% or 50% of your income this month.

For reference, as of 2025, the average consumption-to-income ratio for South Korean households is around 67% — meaning on average, people keep about a third of their income. Including loan principal and interest payments, the effective spending ratio is even higher. This isn’t an absolute standard, but rather a reference point for gauging where your cash flow stands relative to the social average.

If you use the average as a benchmark, keeping more than 30% of your income suggests you’re probably not in a structurally strained position. Of course, this varies by individual circumstances. What matters isn’t the exact percentage but continuously monitoring which direction your cash flow is moving.

I’m not saying that detailed expense analysis, like traditional expense tracking, is meaningless. Knowing where money is leaking can certainly help reduce spending. But I think it’s better to focus first on improving income structure rather than cutting expenses.

There’s a hard floor on how much you can cut. You can’t skip rent or eliminate living expenses entirely. No matter how frugal you are, there’s a minimum you’ll hit.

Income, on the other hand, can expand depending on structure. Salary raises, job changes, investment returns, dividends, side income. Each new channel takes time to build, but the ceiling is open. This difference isn’t just about the dollar amount; it’s about whether you have a strategy that’s sustainable over the long term.

That’s why when I look at cash flow, I focus on “how much did I keep” rather than “how much did I spend.” If the profit margin stays stable, room to grow assets naturally follows. And that room becomes the foundation for the next set of choices — how to allocate assets and what level of risk to take on.

Now that I’ve covered the “velocity” of cash flow, it’s time to look at the “state” — how assets are currently structured.

Asset State: Look at Structure, Not Size

If cash flow data shows the “flow” of income and expenses, an asset snapshot shows the current state. I regularly check how much immediately available cash I have and what forms my assets are tied up in. The exact figures for each asset don’t need to be precise — in my case, I consider a margin of error around $1,000 to be perfectly acceptable.

When constructing an asset snapshot, the same principle applies as with cash flow: what matters is structure, not precision. Here are roughly the categories I use:

Major Category	Subcategory	Category
Assets	Cash	KRW
		USD
		Savings deposits
		Housing subscription savings (Jucheongnyak)
	Investments	Domestic stocks
		Foreign stocks
		Real estate
		Pension
	Other	Vehicle
		Jeonse deposit
Liabilities	Short-term	Credit card
	Long-term	Loans

Again, there’s no single right answer. What matters is what questions this breakdown helps you answer. In my case, what I care about most isn’t total asset value — it’s the ratio of liquid assets to illiquid ones.

Even with the same total assets, the situation changes entirely depending on what form those assets take. If you hold a sufficient proportion of assets that can be quickly converted to cash, like savings or stocks, you retain options even when markets shake. Conversely, if most of your assets are locked up in forms like housing deposits or real estate that can’t be easily moved, even small volatility becomes immediate pressure. This is the benefit that liquidity provides.

To me, liquidity is closer to optionality than “how quickly can I sell.” With sufficient liquidity, you can afford to wait, and when circumstances change, you can choose to act on opportunities. Without it, even the choice to do nothing becomes difficult — because market volatility transfers directly into psychological pressure.

From this perspective, an asset snapshot is less about checking how much you own and more about gauging how much risk you can currently handle. That’s why when I look at my snapshot, I check whether the overall structure is putting undue strain on me before looking at any individual asset’s price.

So what metrics are useful when reviewing asset state? One reference metric I use is monthly asset growth rate. The key point is that I don’t treat this as a target. Rather than setting a goal like “grow assets by X% each month,” I use it as a secondary indicator to check whether the current trajectory is holding.

According to a Ministry of Economy and Finance report released last year, the average household asset growth rate for 2025 was approximately 4.9% — which works out to roughly 0.4% per month. Of course, assets have far more variability than income, and individual differences are large, so this average doesn’t mean much on its own. But having this number in mind helps you gauge whether your assets are significantly deviating from the overall trend.

The important thing is that this number isn’t the answer. A high monthly growth rate doesn’t necessarily mean things are going well, and a low one doesn’t mean your choices are wrong. What matters is whether your assets are maintaining a consistent long-term direction, and whether you’re accumulating risks you can’t handle along the way.

I believe direction matters far more than speed in asset growth. Achieving large returns in a short period matters less than maintaining a consistent direction with modest monthly changes — because that’s what lasts. So at the end of each month, I review my cash flow and asset snapshot together, checking what changed from the previous month and whether any asset is becoming a structural burden.

This process naturally leads to the next question: how much volatility can the current asset structure withstand? To answer this, I consider the proportion of safe assets alongside my investment strategy.

Investing Is a Choice That Changes Your State, Not Your Returns

Once you’ve been managing assets for a while, you inevitably arrive at the question of how to think about investing. It’s less about chasing higher returns and more about wondering whether the current asset structure can maintain its direction over time.

Investing is most often discussed in terms of returns — which stock will go up, when to buy and sell, which strategy yields the highest gain. I won’t say these discussions are entirely unimportant. But from my experience, they only matter when one prerequisite is in place:

Can you handle the volatility?

Investing inherently involves volatility. Prices can rise, or they can move against your expectations. The problem is that the same volatility doesn’t hit everyone the same way. A 10% drop might be just a number for one person, but for another it’s pressure that shakes their judgment.

What creates this difference isn’t investment knowledge or stock-picking ability — it’s asset structure and state. Specifically, whether you have regular, predictable cash flow, whether your assets are excessively concentrated in one area, and whether your psychological state can withstand the volatility. These factors have a far greater impact.

That’s why when I talk about investing, I think the first question should be “In what state am I making this choice?” rather than “How much can I make?” How much risk can you take on, and will that risk translate into real-life financial pressure or emotional decision-making?

From this perspective, investing and risk management aren’t separate topics. How you handle risk changes the very nature of the investment itself. The same strategy can produce entirely different outcomes depending on the structure it’s built on.

Let me now discuss how to think about risk management, and the roles that earned income and safe assets play in absorbing that risk.

Risk Management Is Designing Protection for Your Judgment

The fundamental skill of investing is actually very simple: buy low, sell high. Almost no one would argue with that statement. The problem is that following this simple principle in practice is far harder than it sounds.

It’s not hard because the math is complex or because information is lacking. In most cases, the cause of failure is emotion. When prices rise, you feel they’ll keep rising; when they fall, you feel they’ll keep falling. Your mind might judge that now is cheap, but your hand won’t move toward the buy button.

This emotional pull is especially strong during downturns. More than the drop itself, it’s the anxiety of “Did I make the wrong call?” that surfaces first. That anxiety gradually blurs your criteria. The hypotheses and conditions you originally set get pushed to the back of your mind, and the immediate price movement starts dictating every decision.

This is where most people feel that investing is hard. But I see this as less of a technique problem and more of a state problem. The question is whether you’re in a state where you can emotionally withstand this volatility.

Risk management is closer to managing this state. The way I see it, risk management isn’t a technique for avoiding losses — it’s the process of designing an environment where emotions don’t override judgment. It’s about securing enough breathing room that you don’t need to make decisions just because prices are moving, enough time to consider your next move even when you might have been wrong, and enough distance to test the criteria you originally set.

Only when this environment is in place can the fundamentals of investing actually work. When prices drop, you can revisit your reasoning instead of panicking. When prices rise, you can reexamine your thesis instead of getting excited. The simple principle of buying low and selling high only has meaning on top of a structure that keeps emotions in check.

That’s why when talking about investing, I always ask “Am I in a state to handle this choice?” before “How much can I make?” The same strategy can yield entirely different results depending on what asset structure, cash flow, and psychological headroom it’s executed on.

Seen this way, the essence of investing isn’t predicting prices. It’s designing an environment where emotions don’t interfere. The elements that support this environment are more mundane than you’d expect.

Let me now talk about one of the key components of this risk management environment: earned income — why it matters for investing, and why it’s so often undervalued.

Earned Income Is the Most Stable Hedging Layer

“A salary is meaningless.” “You can’t get rich on earned income.” These statements are repeated so often in investment circles that they’ve become common wisdom.

They spread especially easily during bull markets. When asset prices are rising fast, a fixed monthly paycheck looks slow and frustrating. Placed side by side with investment returns, it does look modest by comparison. But this statement is only partially true from a returns perspective — from a risk perspective, it’s critically wrong.

As I mentioned earlier, investing is an act of absorbing volatility before it’s an act of generating returns. Saying prices can go up also means they can come down by the same magnitude. This simple fact is easily forgotten when markets are good. Everyone underestimates risk when numbers are climbing. The real test comes when the decline begins.

What pressures people in a downturn isn’t the loss itself — it’s the possibility that the loss might spill over into daily life. The moment next month’s living expenses, fixed costs, and planned spending flash through your mind, investing stops being about probability and hypotheses and becomes about survival.

This is where earned income reveals its true role. Having a predictable monthly cash flow means more than just income. It buys you time — time to be wrong right now and still be okay. Even if prices fall further, even if your judgment is slightly off, the urgency to make an immediate decision disappears. Without this breathing room, buying low and selling high both become impossible. Earned income won’t explosively grow your assets, but it creates the structure that keeps your assets from collapsing under the weight of emotion.

When you have to cover living expenses solely from investment returns, even small volatility becomes overwhelming pressure. The same 10% drop can be “a period to wait through” for one person and “a crisis that demands selling now” for another. This difference doesn’t come from stock selection or analytical skill. It comes from the stability of cash flow. That’s why viewing earned income as merely “something to eventually escape from” is dangerous. It’s essentially kicking out the floor that makes investing possible.

Earned income doesn’t compete with investing. Earned income is the last safety net that keeps investing functioning properly. When markets are good, anyone can take an aggressive position. The real difference shows when markets waver. And the people who can maintain their judgment through those moments almost always have stable cash flow. Ironically, the times when a salary seems most meaningless are exactly when its true value is most deeply hidden.

Safe Assets Are the Buffer That Makes Strategy Possible

I should be honest about one thing at this point.

My portfolio is far from conservative. A significant portion of my assets is concentrated in TSLA, and I also hold volatile instruments like TSLL (a leveraged TSLA product) and NVDA. In terms of volatility alone, this isn’t a structure I’d recommend to just anyone.

Yet the reason I maintain these positions isn’t that I take risk lightly. It’s the opposite. I made this choice because I judged that the structure to absorb this level of volatility was already in place.

Many people talk about aggressive investing as a matter of “conviction” or “guts.” But from my experience, investors who remain emotionally unshaken tend to be the most conservatively prepared. Only when cash flow is stable, safe assets are sufficiently secured, and daily life won’t be disrupted even in the worst case can you begin to accept volatility as part of your strategy.

For me, safe assets aren’t meant to generate returns. It’s fine if they don’t appreciate, and it’s fine if they sit untouched for years. What matters is that their existence creates options. When prices drop, I can buy more. I can choose to wait and do nothing. If I feel my judgment was wrong, I have the room to unwind part of my position.

Aggressive investing without this cushion is closer to gambling than investing. In a structure that can’t withstand volatility, no matter what stock you buy, emotions will break down first. Conversely, when safe assets and stable cash flow provide support, volatility transforms from a crisis into a condition for making choices.

That’s why the more I want to accelerate asset growth, the more attention I pay to my safe asset allocation. It might sound paradoxical, but I believe the most aggressive choices are only possible on top of the most conservative preparation. As long as this structure holds, price fluctuations aren’t emotional noise — they’re signals you can act on.

Managing your safe asset allocation isn’t a declaration that you want to avoid risk. It’s a choice to maintain a state where you can handle risk. And when that state is maintained, asset growth stops being a question of speed and becomes a question of strategy.

Wrapping Up

The longer I’ve managed my assets, the more I’ve come to think that growing wealth isn’t about picking stocks or predicting markets. What matters more is whether you can build a structure that lets you maintain your judgment even amid uncertainty.

Markets can shake at any time. Exchange rates, interest rates, political events, none of these are within individual control. In this environment, “managing assets well” isn’t about eliminating external variables. It’s about creating a state where you can absorb their impact.

That’s why I always check structure first when looking at my assets. Is cash flow stable? Are assets excessively concentrated in one area? And am I in a state where I can emotionally withstand this volatility? As long as these criteria hold, price movements stop being a source of anxiety and become signals for reviewing my judgment.

Everything I’ve discussed in this post, cash flow, asset snapshots, risk management, earned income, safe asset allocation, converges on the same question:

“What choices am I in a state to make right now?”

Asset management isn’t a problem that yields answers in the short term. Tiny differences accumulate over time into significant ones. Direction matters more than speed, and maintaining direction requires relying on structure rather than emotion.

This post doesn’t have specific investment strategies or profit ideas. But if it prompts you to reexamine how you look at your own assets, that’s enough.

자산 관리는 상태 관리의 문제다

Sat, 17 Jan 2026 03:06:30 GMT

이번 포스팅에서는 기술적인 내용보다는 일상에 가까운 내용에 대해서 한번 이야기해보려고 한다. 바로 자산 관리에 대한 이야기이다.

일단 필자는 부자가 아니며, 일확천금을 만들어 낼 수 있는 투자 비법 같은 것이 있는 것도 아니다. 그렇기에 일반적인 직장인으로서 꾸준히 자산을 늘려갈 수 있는 방법에 대해서 오랫동안 고민해왔다는 점을 이야기하고 싶다.

물론 이미 사업이나 투자를 통해 큰 돈을 버신 분들이 보시기에는 다소 뻔한 이야기들일 수 있지만, 필자처럼 평범한 조건에서 자산을 관리해나가야 하는 사람에게는 충분히 공감할 수 있는 이야기라고 생각해, 필자 나름의 기준을 한번 정리해보려고 한다.

현재 상태를 모르면, 어떤 판단도 할 수 없다

자산 관리를 하면서 필자가 가장 중요하게 생각하는 것 중 하나는, 현재 내가 어디에 서 있는지를 아는 것이다. 이를 위해 필자는 자산 데이터를 꾸준히 기록해왔다.

처음부터 자산 관리를 잘할 수는 없다. 대부분은 시행착오를 겪고, 그 과정에서 조금씩 기준을 만들어간다. 그런데 지금 내 상태가 어떤지조차 알 수 없다면, 잘하고 있는지 아닌지를 판단하는 것 자체가 불가능하다.

필자는 개발자로 일을 시작했던 2018년부터 매월 말 자산 스냅샷을 기록해오고 있다. 이렇게 쌓인 데이터는 지금에 와서는 자산의 변화 과정을 한눈에 보여주지만, 당시에는 오히려 혼란스러울 때도 많았다. 자산이 늘어난 달도 있었고, 예상보다 크게 줄어든 달도 있었다.

이렇게 데이터를 쌓아두면 시장에 어떤 이슈가 있을 때 내 자산이 어떻게 변동되는지, 월 자산 성장률은 어떻게 되는지, 5년 전에 비해 내 자산이 얼마나 늘어났는지 등을 한번에 볼 수 있다.

기록을 남기면서 가장 자주 들었던 생각은 “이 방향이 맞는 걸까?”였다. 중요한 것은 자산이 오르거나 내린 사실 자체가 아니라, 그때마다 감정에 휘둘리지 않고 이전에 세워둔 판단 기준을 유지할 수 있었는지였다.

지금의 수치는 결과적으로 보이는 숫자일 뿐이다. 필자에게 이 데이터의 진짜 가치는, 불확실한 상황 속에서도 현재의 선택이 과거의 판단과 얼마나 일관되어 있는지를 확인할 수 있었다는 점에 있다. 만약 이런 기록이 없었다면, 필자는 중간 어딘가에서 방향을 잃었을 가능성이 크다.

그래서 필자는 자산 관리에서 데이터를 미래를 예측하기 위한 도구로 사용하지 않는다. 다만 지금 내가 어디에 서 있는지를 확인하고, 판단의 기준이 흐트러지지 않았는지를 점검하기 위한 용도로 활용할 뿐이다.

정확한 숫자보다, 올바른 추상화가 먼저다

사실 금융이나 자산 관리에서 데이터가 중요하다는 점은 이미 많은 사람들이 알고 있다. 그 출발점으로 가장 많이 선택되는 것이 바로 가계부다. 수입과 지출을 기록하면서 내 현금 흐름이 어떻게 움직이는지를 확인하는 것은 분명 의미 있는 일이다.

문제는 이 가계부라는 도구가 생각보다 오래 가지 않는다는 데 있다. 매달 수십, 수백 건에 달하는 소비 내역을 하나하나 분류하고, 어디에 얼마를 썼는지 정확히 맞추려다 보면 어느 순간부터 부담이 된다. 계산이 조금이라도 어긋나면 괜히 신경이 쓰이고, 기록이 밀리기 시작하면 아예 손을 놓게 된다. 필자 역시 이런 과정을 몇 번 반복하다가 가계부를 꾸준히 쓰는 것은 포기했다.

근데 잘 생각해보면 문제를 약간 다르게 볼 수 있다.

꼭 정확해야할 필요가 있나...?

문제의 핵심은 기록을 안 한 데 있는 것이 아니라, 정확해야 한다는 전제를 너무 당연하게 받아들였다는 점에 있었던 것 같다. 우리가 개인 자산을 관리하면서 회계 결산이나 세무 신고를 하는 것도 아닌데, 원 단위까지 맞아떨어지는 데이터가 과연 필수적일까 하는 의문이 들었다.

필자가 생각하기에 개인 자산 관리에서 더 중요한 것은 정밀한 숫자가 아니라, 금융이라는 복잡한 현실을 판단 가능한 수준으로 단순화해서 바라볼 수 있는가에 가깝다. 이 점에서 자산 관리는 개발자가 복잡한 시스템을 다루는 방식과 꽤 닮아 있다.

우리는 프로그램을 작성할 때 메모리 주소를 직접 다루지 않는다. 비트 단위의 연산으로 모든 것을 해결하려고도 하지 않는다. 대신 변수와 타입, 인터페이스 같은 추상화된 개념을 사용한다. 세밀한 제어를 일부 포기하는 대신, 전체 구조를 이해하고 더 나은 판단을 내릴 수 있는 여지를 확보하기 위해서다.

자산 관리에서도 비슷한 일이 벌어진다고 생각한다. 모든 소비를 정확히 분해하고 분류하다 보면 오히려 판단은 느려지고, 감정이 개입될 여지는 커진다. 반대로 몇 개의 핵심 지표로 구조를 요약해두면, 지금 상태가 위험한지, 유지 가능한지, 혹은 공격적인 선택을 해도 되는지에 대한 판단을 훨씬 빠르게 내릴 수 있다.

결국 자산 관리에서 추상화가 중요한 이유는 귀찮음을 피하기 위해서가 아니라, 판단의 기준을 단순하게 만들기 위해서다. 어디에 1,000원을 더 썼는지보다 중요한 것은 지금 내가 재정적으로 안전한 상태인지, 현재의 현금 흐름이 지속 가능한 구조인지, 그리고 원하는 목표에 도달하기 위해 어떤 선택지를 가지고 있는지다.

필자는 자산 관리가 숫자를 얼마나 정확하게 맞추느냐의 문제가 아니라, 불확실한 상황에서도 흔들리지 않을 기준을 세우는 과정이라고 생각한다. 그리고 그 기준은 언제나 정밀한 데이터가 아니라, 잘 설계된 추상화 위에서 만들어진다.

자산은 흐름과 상태로 요약할 수 있다

앞서 자산 관리는 정밀도의 문제가 아니라 추상화의 문제라고 이야기했다. 그렇다면 개인 자산을 판단 가능한 수준으로 추상화하기 위해서는 어떤 정보들이 필요할까?

이러한 거시적인 판단들을 내리기 위해 필요한 정보는 생각보다 많지 않은데, 크게는 자산의 흐름과 현재 상태 데이터, 이 두 가지만으로 충분하다.

이는 마치 기업의 재무제표에 포함되는 현금 흐름표와 재무 상태표와도 유사하다. 기본적으로는 이 두 가지 표만 봐도 해당 기업이 돈을 어떻게 썼고 어떻게 벌었는지, 현재 재무 상태는 어떠한지와 같은 주요 정보들을 빠르게 이해할 수 있다.

개인의 자산 관리도 크게 다르지 않다고 생각한다. 개인이 기업처럼 복잡한 회계를 할 필요는 없지만, 최소한 지금 돈이 어떤 경로로 들어오고 나가는지, 그리고 현재 자산이 어떤 형태로 구성되어 있는지는 알고 있어야 한다.

자산의 흐름은 현금 흐름 데이터를 통해 확인할 수 있다. 이번 달에 얼마를 벌었고, 얼마를 썼는지, 그 결과 얼마가 남았는지를 보는 것이다. 이 데이터는 자산 관리의 속도와 방향성을 결정한다. 흐름이 건강하지 않다면 자산은 언젠가 정체되거나 줄어들 수밖에 없다.

반면 자산의 상태는 스냅샷 데이터로 확인한다. 지금 당장 가용 가능한 현금은 얼마인지, 자산이 어떤 형태로 어디에 묶여 있는지, 부채는 어느 정도인지와 같은 정보들이다. 이 데이터는 현재 내가 감당할 수 있는 리스크의 범위를 보여준다.

중요한 점은 이 두 데이터 모두 아주 정확할 필요는 없다는 것이다. 개인 자산 관리에서 필요한 것은 숫자의 정밀함이 아니라 구조에 대한 감각이다. 이번 달 지출이 정확히 얼마였는지보다, 대략적인 수입 대비 지출 비율이 어떤지 아는 것이 더 중요하다. 마찬가지로 자산의 현재 가치가 몇 만원 단위까지 맞아떨어지는지보다, 유동성이 높은 자산과 낮은 자산이 어떤 비율로 구성되어 있는지를 아는 것이 더 의미 있다.

이렇게 흐름과 상태를 분리해서 바라보면, 자산 관리가 훨씬 단순해진다. 흐름이 안정적인지, 상태가 과도한 리스크를 내포하고 있지는 않은지. 이 두 가지 질문에만 답할 수 있어도 대부분의 중요한 의사결정은 가능하다.

필자는 자산 관리를 하면서 더 많은 데이터를 보려고 애쓰기보다는, 이 두 가지 정보를 꾸준히 확인하는 데 집중해왔다. 그 결과 시장 상황이 바뀌어도, 자산의 규모가 커져도, 판단의 기준 자체는 크게 흔들리지 않았다.

이제부터는 이 두 가지 정보를 각각 어떻게 바라보고 관리하고 있는지에 대해 조금 더 구체적으로 이야기해보려고 한다. 먼저 현금 흐름부터 살펴보자.

현금 흐름: 정밀한 로그가 아닌 비율을 본다

자산의 흐름을 파악한다는 것은, 결국 내가 한 달 동안 얼마를 벌었고 그중 얼마를 남겼는지를 확인하는 일에 가깝다. 흔히 현금 흐름을 관리한다고 하면 가계부를 떠올리지만, 필자는 가계부를 쓰는 방식이 반드시 정답이라고 생각하지는 않는다.

가계부의 목적은 어디에 얼마를 썼는지를 정확히 기록하는 데 있다기보다는, 내 수입과 지출의 구조를 이해하는 데 있다. 그런데 많은 경우 이 목적과 수단이 뒤바뀐다. 기록 자체가 부담이 되기 시작하면, 흐름을 이해하기는커녕 기록을 유지하는 것조차 어려워진다.

그래서 필자는 현금 흐름을 관리할 때 세부 지출 항목보다는 훨씬 단순한 기준을 사용한다.

대카테고리	중카테고리	카테고리
수입	근로	급여
	근로	사업
	부채	대출
	투자	배당금
		매도금
		이자
지출	소비	개인소비
	고정비	보험
		통신비
		공과금
	주거	집세
		관리비

이때 이 카테고리에는 어떤 정답도 없다. 중요한 것은 남들도 이렇게 하니까 따라 하는 것이 아니라, 내가 어떤 데이터를 보고 싶어서 이렇게 나눴는지다.

예를 들어 필자의 경우 수입에서는 근로와 투자를 구분해두었고, 지출에서는 고정비와 주거를 따로 떼어두었다. 불로소득의 비중이 어느 정도인지, 소득 대비 주거 비용이 얼마나 되는지를 알고 싶었기 때문이다. 만약 이런 정보가 필요 없다면, 소비를 하나의 카테고리로 묶어도 전혀 문제 없다.

이렇게 대략적인 흐름만 정리해두어도, 한 달 동안 내가 얼마나 벌었고 그중 얼마를 남겼는지는 충분히 파악할 수 있다.

이렇게 캐시 플로우를 정리하는 것만으로도 많은 정보들을 알 수 있지만 필자가 생각했을 때 가장 중요한 데이터는 바로 이익률, 즉 한 달 수입 중 대략 몇 퍼센트를 남기고 있는지다.

이 하나의 숫자는 생각보다 많은 정보를 담고 있다. 수입이 늘고 있는지, 지출이 과도한지, 혹은 현재의 생활 수준이 자산 증가 속도에 비해 과한지를 직관적으로 보여준다. 어디에 5만 원을 더 썼는지는 몰라도, 이번 달에 수입의 30%를 남겼는지 50%를 남겼는지는 분명히 알 수 있다.

참고로 2025년 기준 대한민국 가계의 평균 소득 대비 소비 비율은 약 67% 수준이다. 즉, 평균적으로는 소득의 약 3분의 1 정도를 남기고 있다는 의미다. 대출 원금과 이자까지 포함하면 실제로 체감되는 지출 비율은 이보다 더 높다. 이 수치는 절대적인 기준이라기보다는, 내 현금 흐름이 사회 평균 대비 어느 지점에 있는지를 가늠하기 위한 참고선 정도로 보면 된다.

이 수치는 절대적인 기준이라기보다는, 내 현금 흐름이 사회 평균 대비 어느 지점에 있는지를 가늠하기 위한 참고선에 가깝다.

만약 평균을 기준으로 삼는다면, 소득의 30% 이상을 남기고 있다면 최소한 구조적으로 크게 무리한 상태는 아닐 가능성이 높다. 물론 개인의 상황에 따라 이 수치는 얼마든지 달라질 수 있다. 중요한 것은 정확한 퍼센트가 아니라, 내 현금 흐름이 어떤 방향으로 움직이고 있는지를 지속적으로 확인하는 것이다.

물론 가계부처럼 지출 내역을 세세하게 분석하는 접근이 의미 없다고 생각하지는 않는다. 지출을 줄이기 위해서는 어디에 돈이 새고 있는지를 아는 것이 필요할 수도 있다. 다만 필자는 지출을 줄이는 것보다, 수입 구조를 개선하는 데 먼저 집중하는 편이 낫다고 생각한다.

어차피 지출을 줄이는 데에는 명확한 한계가 있기 때문이다. 월세를 안 낼 수는 없고, 생활비를 완전히 없앨 수도 없다. 아무리 절약해도 도달할 수 있는 최소치는 정해져 있다.

반면 수입은 구조에 따라 얼마든지 확장될 수 있다. 연봉 인상이나 이직, 투자 수익, 배당 소득, 부업처럼 수입의 경로를 하나씩 늘려가는 것은 시간이 걸리더라도 상방이 열려 있다. 이 차이는 단순히 금액의 문제가 아니라, 장기적으로 유지 가능한 전략인지의 문제라고 생각한다.

그래서 필자가 현금 흐름에서 가장 중요하게 보는 것은 “얼마를 썼는가”가 아니라 “얼마를 남겼는가”다. 이익률이 안정적으로 유지된다면, 자산을 늘릴 수 있는 여지는 자연스럽게 따라온다. 그리고 이 여지가 바로 다음 단계의 선택, 즉 자산을 어떻게 배분하고 어떤 리스크를 감당할 수 있을지를 결정하는 기반이 된다.

이제 현금 흐름이라는 “속도”에 대한 이야기를 했으니, 다음으로는 자산의 “상태”, 즉 현재 자산이 어떤 형태로 구성되어 있는지를 살펴볼 차례다.

자산 상태: 규모가 아니라 구조를 본다

현금 흐름 데이터가 돈의 수입과 지출이라는 ‘흐름’을 보여준다면, 자산 스냅샷은 말 그대로 현재 상태를 보여주는 데이터다. 필자는 정기적으로 지금 당장 가용 가능한 현금이 얼마인지, 자산이 어떤 형태로 어디에 묶여 있는지를 확인한다. 이때 각 자산의 금액이 정확히 맞아떨어질 필요는 없다고 생각한다. 필자의 경우에는 대략 100만 원 정도의 오차는 충분히 허용 가능한 범위로 보고 있다.

자산 스냅샷을 구성할 때도 현금 흐름과 마찬가지로 중요한 것은 정밀함이 아니라 구조다. 필자가 사용하는 자산 카테고리는 대략 다음과 같다.

대카테고리	중카테고리	카테고리
자산	현금	KRW
		USD
		예금
		주택청약
	투자	국내주식
		해외주식
		부동산
		연금
	기타	자동차
		주택 보증금
부채	단기부채	신용카드
	장기부채	대출

이 카테고리 역시 정답이 있는 것은 아니다. 중요한 것은 이 구분을 통해 어떤 질문에 답하고 싶은지다. 필자의 경우에는 자산의 총액보다도, 즉시 유동화가 가능한 자산과 그렇지 않은 자산이 어떤 비율로 구성되어 있는지를 가장 중요하게 본다.

같은 금액의 자산을 가지고 있더라도, 그 자산이 어떤 형태로 묶여 있는지에 따라 상황은 전혀 다르게 전개된다. 현금이나 주식처럼 비교적 빠르게 현금화할 수 있는 자산의 비중이 충분하다면, 시장이 흔들릴 때도 선택지가 남아 있다. 반대로 대부분의 자산이 보증금이나 부동산처럼 쉽게 움직일 수 없는 형태로 묶여 있다면, 작은 변동성도 곧바로 압박으로 다가온다. 이 차이가 바로 유동성이 가져다주는 혜택이다.

유동성은 단순히 “얼마나 빨리 팔 수 있는가”의 문제가 아니다. 필자가 느끼기에 유동성은 선택권에 가깝다. 유동성이 충분한 상태에서는 기다릴 수 있고, 상황이 바뀌면 기회를 선택할 수도 있다. 반면 유동성이 부족한 상태에서는 아무것도 하지 않는 선택조차 쉽지 않다. 시장의 변동성이 그대로 개인의 심리적 부담으로 전이되기 때문이다.

이런 관점에서 보면 자산 스냅샷은 단순히 자산 규모를 확인하기 위한 수단이 아니라, 현재 내가 감당할 수 있는 리스크의 범위를 가늠하기 위한 도구에 가깝다. 그래서 필자는 자산 스냅샷을 볼 때 특정 자산의 가격 자체보다는, 전체 구조가 지금의 나에게 과도한 부담을 주고 있지는 않은지를 먼저 확인한다.

그렇다면 자산 상태를 점검할 때 참고할 만한 지표는 무엇일까. 필자가 하나의 참고 지표로 사용하는 것은 월 자산 성장률이다. 여기서 중요한 점은 이 수치를 목표로 삼지 않는다는 것이다. 매달 자산을 몇 퍼센트씩 늘려야 한다는 식의 기준을 세우기보다는, 지금의 방향성이 유지되고 있는지를 확인하기 위한 보조 지표로 활용한다.

작년에 발표된 기획 재정부 뉴스에 따르면, 2025년 한 해 동안 가구당 평균 자산 증가율은 약 4.9% 수준이었다고 한다. 이를 단순히 월 단위로 환산하면 대략 0.4% 정도다. 물론 자산은 소득보다 변수의 폭이 훨씬 넓고, 개인 간 편차도 크기 때문에 이 평균값 자체에 큰 의미를 두기는 어렵다. 다만 이런 수치를 알고 있으면, 내 자산이 사회 전체의 흐름과 비교했을 때 크게 벗어나고 있는지 정도는 가늠해볼 수 있다.

여기서 중요한 것은 이 숫자가 정답이 아니라는 점이다. 월 성장률이 높다고 해서 반드시 좋은 상태라고 볼 수도 없고, 낮다고 해서 잘못된 선택을 하고 있다고 단정할 수도 없다. 중요한 것은 자산이 장기적으로 같은 방향을 유지하고 있는지, 그리고 그 과정에서 내가 감당하기 어려운 리스크를 쌓아가고 있지는 않은지다.

필자는 자산 성장에서 속도보다 방향성이 훨씬 중요하다고 생각한다. 단기간에 큰 수익을 내는 것보다, 매달 크지 않은 변화라도 일관된 방향을 유지하는 것이 결국 더 오래 갈 수 있는 방식이기 때문이다. 그래서 매월 말 현금 흐름과 자산 스냅샷을 함께 정리하면서, 지난달과 비교해 어떤 변화가 있었는지, 어떤 자산이 구조적으로 부담이 되고 있는지를 점검한다.

그리고 이 과정에서 자연스럽게 다음 질문으로 이어진다. 지금의 자산 구조는 어느 정도의 변동성을 견딜 수 있는 상태인가. 이 질문에 답하기 위해서 필자는 안전자산의 비중과 투자 전략을 함께 고민하게 된다.

투자는 수익이 아니라 상태를 바꾸는 선택이다

자산 관리를 어느 정도 해오다 보면, 결국 투자를 어떻게 바라볼 것인가라는 질문에 도달하게 된다. 더 많은 수익을 얻기 위해서라기보다는, 지금의 자산 구조가 시간이 지나도 같은 방향을 유지할 수 있을지에 대한 고민에 가깝다.

많은 경우 투자는 수익률의 문제로 이야기된다. 어떤 종목이 더 오를지, 언제 사고 언제 팔아야 할지, 혹은 어떤 전략이 더 높은 수익을 낼 수 있는지에 대한 이야기들이다. 물론 이런 논의들이 전혀 중요하지 않다고 말할 수는 없다. 다만 필자가 경험해온 바로는, 이런 이야기들은 모두 하나의 전제가 깔려 있을 때에만 의미를 갖는다.

바로, 그 변동성을 감당할 수 있는 상태인가라는 전제다.

투자는 본질적으로 변동성을 동반한다. 가격은 오를 수도 있고, 예상과 다르게 움직일 수도 있다. 문제는 이 변동성이 누구에게나 같은 의미로 다가오지 않는다는 점이다. 같은 10%의 하락이라도 어떤 사람에게는 단순한 숫자의 변화일 수 있지만, 어떤 사람에게는 판단을 뒤흔드는 압박으로 작용한다.

이 차이를 만드는 것은 투자 지식이나 종목 선택 능력보다는, 자산 구조와 상태에 가깝다고 생각한다. 특히 정기적이고 예측 가능한 현금 흐름이 있는지, 자산이 한쪽으로 과도하게 쏠려 있지는 않은지, 그리고 지금의 생활과 심리 상태가 이 변동성을 견딜 수 있는지와 같은 요소들이 훨씬 더 큰 영향을 미친다.

그래서 필자는 투자를 이야기할 때, 먼저 “얼마를 벌 수 있는가”보다 “어떤 상태에서 이 선택을 하고 있는가”를 먼저 점검해야 한다고 생각한다. 리스크를 얼마나 감수할 수 있는지, 그리고 그 리스크가 현실적인 생활 압박이나 감정적인 판단으로 이어지지는 않는지 말이다.

이 관점에서 보면, 투자와 리스크 관리는 서로 분리된 주제가 아니다. 오히려 리스크를 어떻게 다루느냐에 따라, 투자라는 행위의 성격 자체가 달라진다. 같은 전략이라도 어떤 구조 위에서 실행하느냐에 따라 전혀 다른 결과로 이어질 수 있기 때문이다.

이제부터는 이 관점에서, 리스크 관리를 어떻게 이해해야 하는지, 그리고 그 리스크를 흡수하는 데 있어 근로소득과 안전자산이 어떤 역할을 하는지에 대해 차례대로 이야기해보려고 한다.

리스크 관리는 판단을 보호하기 위한 설계다

필자가 생각하는 투자의 기본기는 사실 굉장히 단순하다. 싸게 사서 비싸게 파는 것이다. 이 문장을 부정할 수 있는 사람은 거의 없을 것이다. 문제는 이 단순한 원칙을 실제로 지키는 것이 생각보다 매우 어렵다는 데 있다.

이게 어려운 이유는 계산이 복잡해서도, 정보가 부족해서도 아니다. 대부분의 경우 실패의 원인은 감정이다. 가격이 오를 때는 더 오를 것 같고, 가격이 떨어질 때는 더 떨어질 것 같다는 생각이 자연스럽게 든다. 머리로는 지금이 싸다고 판단하면서도, 손은 매수 버튼 위에서 쉽게 움직이지 않는다.

특히 하락 구간에서는 이 감정이 더 강하게 작용한다. 가격이 내려간다는 사실보다도, “혹시 내가 틀린 선택을 한 건 아닐까”라는 불안이 먼저 올라온다. 그리고 이 불안은 판단의 기준을 조금씩 흐리게 만든다. 원래 세워두었던 가설이나 조건은 점점 뒷전으로 밀리고, 당장의 가격 움직임이 모든 의사결정을 지배하게 된다.

이 지점에서 많은 사람들이 투자가 어렵다고 느낀다. 하지만 필자는 이 문제를 투자 기법의 문제라기보다는, 상태의 문제라고 생각한다. 지금의 내가 이 변동성을 감정적으로 견딜 수 있는 상태인가에 대한 문제다.

리스크 관리는 바로 이 상태를 다루는 일에 가깝다. 필자가 생각하는 리스크 관리는 손실을 피하는 기술이 아니라, 감정이 판단을 덮어버리지 않도록 환경을 설계하는 과정이다. 가격이 흔들려도 당장 결정을 내려야 할 이유가 없는 여유, 판단이 틀렸을 가능성을 인정하더라도 다음 선택을 할 수 있는 시간, 그리고 처음 세워둔 기준을 끝까지 검증해볼 수 있는 심리적 거리감을 확보하는 일이다.

이런 환경이 갖춰져 있을 때에야 비로소 투자의 기본기가 작동하기 시작한다. 가격이 떨어졌을 때 공포가 아니라 근거를 다시 점검할 수 있고, 가격이 올랐을 때도 흥분이 아니라 원래의 가설을 되짚어볼 수 있다. 싸게 사서 비싸게 판다는 단순한 원칙은, 감정을 통제할 수 있는 구조 위에서만 의미를 갖는다.

그래서 필자는 투자를 이야기할 때 “얼마를 벌 수 있는가”보다 “이 선택을 감당할 수 있는 상태인가”를 먼저 묻는 편이다. 같은 전략이라도 어떤 자산 구조, 어떤 현금 흐름, 어떤 심리적 여유 위에서 실행되느냐에 따라 결과는 전혀 달라질 수 있기 때문이다.

이렇게 보면 투자의 본질은 결국 가격을 맞히는 능력이 아니라, 감정이 개입되지 않도록 환경을 설계하는 일에 가깝다. 그리고 이 환경을 실제로 떠받치고 있는 요소들은 생각보다 훨씬 현실적인 것들이다.

이제부터는 이 관점에서, 이러한 리스크 관리 환경을 구성하는 핵심 요소 중 하나인 근로소득이 투자에서 어떤 역할을 하는지, 그리고 왜 이 요소가 자주 과소평가되는지에 대해 이야기해보려고 한다.

근로소득은 가장 안정적인 헷징 레이어다

“월급은 의미 없다”, “근로소득으로는 부자가 될 수 없다”는 말은 투자 이야기를 할 때 거의 상식처럼 소비된다.

특히 시장이 좋았던 시기에는 이런 말이 더 쉽게 퍼졌다. 자산 가격이 빠르게 오르는 구간에서, 매달 고정적으로 들어오는 월급은 느리고 답답해 보인다. 투자 수익과 나란히 놓고 보면 상대적으로 초라해 보이는 것도 사실이다. 하지만 이 문장은 수익의 관점에서만 부분적으로 맞을 뿐, 리스크의 관점에서는 결정적으로 틀린 말이다.

하지만 앞서 언급했듯이 투자는 수익을 만드는 행위이기 이전에 변동성을 감당하는 행위다. 가격이 오를 수 있다는 말은, 같은 크기로 내려갈 수도 있다는 뜻이다. 이 단순한 사실은 시장이 좋을 때는 쉽게 잊힌다. 숫자가 늘어나는 구간에서는 누구나 리스크를 과소평가한다. 문제는 하락이 시작됐을 때다.

이때 사람을 압박하는 것은 손실 그 자체가 아니라, 손실이 생활로 번질 수 있다는 가능성이다. 다음 달 생활비, 고정비, 예정된 지출이 머릿속에 떠오르는 순간부터 투자는 확률과 가설의 문제가 아니라 생존의 문제로 바뀐다.

여기서 근로소득의 역할이 드러난다. 매달 예측 가능한 현금 흐름이 있다는 사실은 단순한 수입 이상의 의미를 가진다. 이는 “지금 당장 틀려도 괜찮다”는 시간을 벌어준다. 가격이 더 내려가도, 판단이 조금 늦어져도, 당장 결정을 내려야 할 이유가 사라진다. 이 여유가 없는 상태에서는 싸게 사는 것도, 비싸게 파는 것도 모두 불가능해진다. 근로소득은 자산을 폭발적으로 키워주지는 않지만, 자산이 감정 때문에 무너지는 것을 막아주는 구조를 만든다.

투자 수익만으로 생활을 감당해야 하는 상태에서는 작은 변동성조차 과도한 압박으로 작용한다. 같은 10% 하락이라도, 누군가에게는 “기다릴 수 있는 구간”이고 누군가에게는 “지금 팔아야 하는 위기”가 된다. 이 차이는 종목 선택이나 분석 능력에서 나오지 않는다. 현금 흐름의 안정성에서 나온다. 그래서 근로소득을 “언젠가는 벗어나야 할 것”으로만 바라보는 관점은 위험하다. 그것은 투자를 가능하게 만드는 바닥을 스스로 걷어차는 일에 가깝다.

근로소득은 투자와 경쟁하는 대상이 아니다. 근로소득은 투자가 정상적으로 작동하도록 버텨주는 마지막 안전망이다. 시장이 좋을 때는 누구나 공격적인 포지션을 취할 수 있다. 진짜 차이는 시장이 흔들릴 때 드러난다. 그리고 그 순간 끝까지 판단을 유지할 수 있는 사람은, 대부분 안정적인 현금 흐름을 가진 사람이다. 월급이 의미 없어 보일 때야말로, 월급의 진짜 가치는 가장 깊이 가려져 있는 시기다.

안전자산은 전략을 가능하게 만드는 버퍼다

사실 이 지점에서 한 가지는 솔직하게 밝혀두는 편이 좋을 것 같다.

필자의 포트폴리오는 결코 보수적이지 않다. 자산의 상당 부분이 TSLA를 중심으로 구성되어 있고, 레버리지 상품인 TSLL이나 NVDA 같은 변동성이 큰 자산도 함께 들고 있다. 변동성만 놓고 보면 누구에게나 추천할 만한 구조는 아니다.

그럼에도 불구하고 이런 선택을 유지하고 있는 이유는, 필자가 리스크를 가볍게 보고 있어서가 아니다. 오히려 그 반대다. 이 정도의 변동성을 감당할 수 있는 구조가 만들어져 있다고 판단했기 때문에 가능한 선택이다.

많은 사람들이 공격적인 투자를 “확신”이나 “배짱”의 문제로 이야기한다. 하지만 필자가 경험한 바로는, 감정적으로 흔들리지 않는 투자자일수록 준비가 훨씬 보수적이다. 현금 흐름이 안정적이고, 안전자산이 충분히 확보되어 있으며, 최악의 경우에도 생활이 흔들리지 않는 상태일 때에야 비로소 변동성을 전략의 일부로 받아들일 수 있다.

필자에게 안전자산은 수익을 내기 위한 자산이 아니다. 가격이 오르지 않아도 상관없고, 몇 년간 그대로 있어도 괜찮다. 중요한 것은 이 자산이 존재함으로써 선택지가 생긴다는 점이다. 가격이 내려갔을 때 추가로 매수할 수 있고, 아무것도 하지 않고 기다릴 수도 있으며, 판단이 틀렸다고 느껴지면 일부를 정리할 여유도 생긴다.

이 여유가 없는 상태에서의 공격적인 투자는 투자라기보다는 도박에 가깝다. 변동성을 견딜 수 없는 구조에서는, 어떤 종목을 사든 결국 감정이 먼저 무너진다. 반대로 안전자산과 안정적인 현금 흐름이 받쳐주는 구조에서는, 변동성은 위기가 아니라 선택의 조건으로 바뀐다.

그래서 필자는 자산 증가 속도를 높이고 싶을수록, 오히려 안전자산의 비중을 더 신경 쓴다. 역설적으로 들릴 수 있지만, 가장 공격적인 선택은 항상 가장 보수적인 준비 위에서만 가능하다고 생각한다. 이 구조가 유지되는 한, 가격의 등락은 감정을 자극하는 소음이 아니라 판단을 실행할 수 있는 신호에 가깝다.

결국 안전자산의 비중을 관리한다는 것은 위험을 피하겠다는 선언이 아니다. 위험을 감당할 수 있는 상태를 유지하겠다는 선택이다. 그리고 이 상태가 유지될 때, 자산 증가는 속도의 문제가 아니라 전략의 문제로 바뀐다.

마치며

자산 관리를 하면서 필자가 점점 확신하게 된 것은, 자산 증식이 어떤 종목을 고르는 능력이나 시장을 예측하는 감각의 문제가 아니라는 점이다. 오히려 불확실한 상황 속에서도 스스로의 판단을 유지할 수 있는 구조를 만들 수 있는지가 훨씬 중요하다고 느꼈다.

시장은 언제든 흔들릴 수 있고, 가격은 내가 원하지 않는 방향으로 움직일 수 있다. 환율도, 금리도, 정치적 이슈도 개인이 통제할 수 있는 영역은 아니다. 이런 환경에서 자산 관리를 “잘한다”는 것은, 외부 변수를 제거하는 일이 아니라 그 영향을 감당할 수 있는 상태를 만들어두는 일에 가깝다.

그래서 필자는 자산을 볼 때 항상 구조부터 확인한다. 현금 흐름이 안정적인지, 자산이 한쪽으로 과도하게 쏠려 있지는 않은지, 그리고 지금의 내가 이 변동성을 감정적으로 견딜 수 있는 상태인지 말이다. 이 기준이 유지되는 한, 가격의 등락은 불안을 자극하는 요소가 아니라 판단을 점검하는 신호로 바뀐다.

이 글에서 이야기한 현금 흐름, 자산 스냅샷, 리스크 관리, 근로소득, 안전자산 비중은 모두 같은 질문으로 수렴한다.

“지금의 나는 어떤 선택을 할 수 있는 상태인가?”

자산 관리는 단기간에 답이 나오는 문제가 아니다. 오히려 시간이 지날수록 아주 작은 차이가 누적되어 큰 차이를 만들어내는 영역에 가깝다. 그래서 더더욱 속도보다 방향성이 중요하고, 방향성을 유지하기 위해서는 감정이 아니라 구조에 의존해야 한다고 생각한다.

이 글이 어떤 투자 전략이나 수익 아이디어를 제공하지는 못했을지도 모른다. 다만 자신의 자산을 바라보는 기준을 한 번쯤 점검해보는 계기가 된다면, 필자에게는 그걸로 충분하다. 적어도 필자는 이런 방식으로, 지금까지의 선택을 이어올 수 있었다.

From State to Relationships: The Declarative Overlay Pattern

Tue, 07 Oct 2025 02:10:27 GMT

In this post, continuing from my previous one, I want to dig deeper into how declarative programming manifests in real-world code.

Just explaining theory would be boring, so let’s explore declarative programming in more detail through overlay-kit, a library that makes it easy to manage overlay elements like modals and toasts in React.

The essence of declarative programming

I previously wrote about the essence of declarative programming. Using array methods like map or filter doesn’t automatically make your code declarative. True declarative thinking focuses on “What” instead of “How”, on relationships, not procedures.

But most React developers still haven’t escaped the procedural mindset of a decade ago when it comes to handling elements like modals and toasts.

We still use useState to create state, wire up event handlers, and manage the sequence of state changes. This is procedural thinking: focusing on temporal order. “First open the dialog, then wait for confirmation, and finally call the API.”

Just as you can think procedurally while using map, using useState doesn’t make your code declarative.

State space and cognitive load

Remember the async data state example from the previous post? Managing loading, data, and error as independent boolean states creates logically impossible state combinations. The exact same problem occurs in overlay management.

const [isOpen, setIsOpen] = useState(false);
const [isLoading, setIsLoading] = useState(false);
const [result, setResult] = useState<'confirmed' | null>(null);

// Logically impossible state combinations
// { isOpen: false, isLoading: true, result: null }
// → Closed but loading

// { isOpen: false, isLoading: false, result: 'confirmed' }
// → Closed but has a result

// { isOpen: true, isLoading: true, result: 'confirmed' }
// → Loading but already has a result

Three independent state variables theoretically produce $2³ = 8$ combinations, but the number of logically valid combinations is far fewer. Every time developers write code, they must mentally verify: “Is this combination possible?”

The fundamental reason this is problematic is the increase in cognitive load. According to psychologist John Sweller’s cognitive load theory, human working memory is limited, with a finite amount of information it can process simultaneously. George Miller’s “magic number 7±2” comes from the same line of thinking.

So the problem with the overlay management pattern above is that you must track isOpen, isLoading, result, and the valid combinations between them just to understand how the overlay behaves. Right now it’s only 8 possible combinations, but as more states are added, the amount of information a developer must remember grows exponentially.

But this situation isn’t inherent complexity of the problem itself. It’s extraneous cognitive load created by the way we’ve chosen to express it. Just as a complex mathematical expression becomes easier to understand when rewritten with better notation, a small shift in approach can let us express overlays in a much simpler way.

The relationship between input and output

The key point I emphasized in my previous post was that declarative code expresses relationships, not the flow of time.

Recall the linear function $y = 2x + 1$ . This isn’t an instruction to “multiply $x$ by 2 and add 1” — it declares the relationship between $x$ and $y$ . This relationship is a timeless truth. Whenever $x$ is 3, $y$ is 7 — always, everywhere.

The essence of overlays is the same. Look at the browser’s native API, window.confirm:

const result = window.confirm("Are you sure you want to delete this?");

Of course, window.confirm has the side effect of displaying UI, so it’s not a pure function. But the important thing is that this function doesn’t expose state management to the caller. There’s no isOpen state, no handleConfirm handler. How it’s implemented internally, what order things render in, all of that is hidden behind the abstraction. The developer can focus solely on the relationship: “what goes in, what comes out.”

In mathematics, a function represents a correspondence between sets. When we write $f:A→B$ , we declare how each element of set $A$ corresponds to an element of set $B$ . This isn’t about computation — it’s about the relationship between structures.

window.confirm works the same way. It represents a correspondence from the set of message strings to the set of boolean values.

The declarative overlay pattern

So what should we do? The answer is surprisingly simple: don’t treat overlays as state — treat them as functions.

The declarative overlay pattern brings the functional essence that window.confirm demonstrated into the React ecosystem.

const result = await overlay.openAsync(({ isOpen, close }) => (
  <ConfirmDialog
    isOpen={isOpen}
    onConfirm={() => close(true)}
    onCancel={() => close(false)}
  />
));

openAsync is a function that returns a Promise<T>.

If you’ve used Promises, you already know this pattern. Call an API, get a Promise back, await the result. openAsync works identically. Open an overlay, get a Promise back, wait for the user to respond. The only difference is that the response comes from a user instead of an API server.

In other words, it declares the relationship: “show an overlay and receive the user’s response.”

In this section, I want to examine three aspects of why the declarative overlay pattern is better than traditional state management.

From state to relationships

In the previous post, I covered how to prevent impossible state combinations — explicitly enumerating possible states and letting the type system block invalid combinations.

But the declarative overlay pattern takes a different approach. Instead of constraining state combinations, it abstracts away the state itself.

Traditional state management deals with snapshots: “Is the dialog open right now?”, “Is it loading right now?”, “Is there a result right now?” It tracks the state at the current point in time and changes these states one by one to produce the desired behavior. It’s like creating animation by stitching together individual photographs.

But think about it. What we actually want to know is whether the user clicked “confirm” in the dialog, not whether the dialog is currently open or closed.

The intermediate states are just means to an end. We don’t care about the current state — we want the final result.

The declarative overlay pattern eliminates this intermediate process. What used to require managing multiple complex states is expressed as a single action, opening an overlay, and the focus is solely on receiving the result.

// Open the dialog
setIsOpen(true);

// Somewhere later, close the dialog and set the result
setIsOpen(false);
setResult('confirmed');

// Express only the relationship between action and result
const result = await overlay.openAsync(...);

Why is this better?

First, the code directly expresses intent. The intention “I want to get user confirmation” is right there in the code. There’s no need for a developer to mentally combine three state variables and deduce “ah, this is trying to get confirmation.”

Second, there’s less room for errors. The first approach has plenty of openings for human error — forgetting to set isOpen back to false, setting result without closing the dialog, and so on. Abstracting these operations into a function makes such mistakes structurally impossible.

Third, you can focus on the result of a change rather than the process of change. It expresses what happens, not how state changes. In other words, it’s declarative.

Put another way, the declarative overlay pattern replaces tracking what values individual state variables hold (state snapshots) with expressing what result comes from what action (input-output relationships).

Redistribution of cognitive load

Code readability is often considered a matter of subjective taste. But psychologist John Sweller’s cognitive load theory shows that it’s not just taste. It’s a matter of cognitive science.

Look at the traditional state management approach again. Developers must simultaneously track multiple state variables like isOpen, isLoading, and result. To understand how the module behaves, they must mentally simulate what order these variables change in and which combinations are valid.

In cognitive load theory, this is called extraneous load. Extraneous load in code isn’t the inherent complexity of the problem — it’s unnecessary complexity created by the way we’ve chosen to express it. The essential problem of showing an overlay and getting user confirmation is simple, but expressing this through multiple state variables artificially inflates the complexity.

Recall George Miller’s “magic number 7±2.” Humans can only hold about 7 items in working memory at once. But with just three state variables, the possible combinations already reach 8, and tracking which of those are valid pushes us to our cognitive limits.

The declarative overlay pattern removes this extraneous load. Developers no longer need to remember combinations across multiple state variables. They only need to remember one function call and the relationship between input and output.

I believe that expressing the same problem with less cognitive load — removing unnecessary complexity so developers can focus on the essential problem — is the essence of writing readable code.

But there’s something important not to misunderstand: the complexity hasn’t disappeared — it’s merely been redistributed.

The implementers of the overlay-kit library still have to deal with complex logic like Promise management and state synchronization. But this tedious implementation only needs to be done once.

Through the contributions of a few, countless developers can work with overlays at low cognitive load. This is the value that abstraction gives us.

Composition and control flow

Consider a situation where you need to collect user input through multiple overlays. With the traditional approach, the logic looks like this:

function CreateUserFlow() {
  const [step, setStep] = useState(1);
  const [info, setInfo] = useState(null);
  const [preference, setPreference] = useState(null);

  const handleInfoSubmit = (data) => {
    setInfo(data);
    setStep(2);
  };

  const handlePreferenceSubmit = (data) => {
    setPreference(data);
    setStep(3);
  };

  const handleConfirm = async () => {
    await api.createUser({ ...info, ...preference });
    setStep(1);
    setInfo(null);
    setPreference(null);
  };

  return (
    <>
      {step === 1 && <UserInfoForm onSubmit={handleInfoSubmit} />}
      {step === 2 && <PreferenceForm onSubmit={handlePreferenceSubmit} />}
      {step === 3 && <ConfirmDialog onConfirm={handleConfirm} />}
    </>
  );
}

This is a simple flow that collects user info, preferences, and a final confirmation before calling an API. But the information flow is scattered throughout the code. Developers must follow how step state changes, what each handler does, and what conditions control the JSX rendering — all just to understand the overall flow.

Now look at the same logic implemented with overlay-kit’s openAsync:

async function createUser() {
  const info = await overlay.openAsync(({ isOpen, close }) => (
    <UserInfoForm isOpen={isOpen} onSubmit={close} />
  ));

  const preference = await overlay.openAsync(({ isOpen, close }) => (
    <PreferenceForm isOpen={isOpen} onSubmit={close} />
  ));

  if (await confirmCreation(info, preference)) {
    await api.createUser({ ...info, ...preference });
  }
}

The biggest difference is that the information flow is linear. The first line collects user info, the second line collects preferences, and the third line gets confirmation before calling the API. The order you read the code from top to bottom is the execution order.

This is possible because openAsync returns a Promise. Promises let you wait for an asynchronous operation to complete. Wait for the first overlay to close, then open the second. When the second closes, move to the third. Each step executes sequentially, and information flows from top to bottom.

Each step is also independent, meaning the concerns have low coupling and high cohesion. The user info form only collects user info, the preference form only collects preferences, and how to stitch them together is decided by the createUser function. Each component simply calls close and doesn’t need to know where the result goes.

And since openAsync is just a function that returns a value, it integrates naturally with standard control flow. Need conditional logic? Use if. Need error handling? Use try/catch. Need iteration? Use for. The control flow you learned in Programming 101 works as-is. No special overlay patterns to learn.

Thanks to these function characteristics, reusing specific UX flows is also straightforward:

function confirmAction(message: string) {
  return overlay.openAsync(({ isOpen, close }) => (
    <ConfirmDialog
      message={message}
      isOpen={isOpen}
      onConfirm={() => close(true)}
      onCancel={() => close(false)}
    />
  ));
}

if (await confirmAction('Are you sure you want to delete this?')) {
  await api.deleteUser();
}

if (await confirmAction('Reset your settings?')) {
  await api.resetSettings();
}

This is the power of treating overlays as functions. Information flow is linear, standard control flow like if, try/catch, and for just works, and reuse is as simple as extracting a function.

Extending declarative thinking

In 2013, React freed us from direct DOM manipulation and introduced a world where we could declaratively express the structural relationship between data and UI through JSX.

But sadly, within the same React codebase, we write components declaratively while handling overlays procedurally.

// Components: declarative
<UserProfile user={user} />

// Overlays: procedural
const [isOpen, setIsOpen] = useState(false);
const handleOpen = () => setIsOpen(true);
const handleClose = () => setIsOpen(false);

Why did this split happen? Because overlays appear to be bound to time. A user clicks a button, a dialog opens, then the user clicks confirm, an API is called, and the response arrives, the dialog closes. So we thought we needed state to manage this sequence.

But look at window.confirm again:

if (window.confirm('Are you sure you want to delete this?')) {
  deleteItem();
}

Of course, the effect this code produces also involves temporal ordering — waiting for the user to click confirm in the dialog. But we don’t express this as a flow of time in the code. We express it as a function that takes a string and returns a boolean — a relationship between a string and a boolean.

This is exactly what the declarative overlay pattern does. It transforms temporal sequences into relationships between conditions and results.

// Procedural: "first open, wait, close, then..."
setIsOpen(true);
// ... somewhere else
setIsOpen(false);
// ... and then
deleteItem();

// Declarative: "if confirmed, delete"
if (await overlay.openAsync(...)) {
  deleteItem();
}

Now we can extend React’s declarative philosophy to overlays. Just as components declare the relationship between data and UI, overlays declare the relationship between user responses and the next action.

And this consistency matters. If you think declaratively when reading components but must switch to procedural thinking for overlays, you’re constantly context-switching. But with the declarative overlay pattern, the entire codebase is unified under a single way of thinking.

Closing thoughts

overlay-kit is a library that implements this pattern.

Its value isn’t in reducing lines of code. It’s in bringing the simplicity that window.confirm demonstrated into the React ecosystem. It simply makes something that was easy 10 years ago but got complicated along the way easy again.

In my previous post, I said declarative programming is a way of thinking, not a tool. Just as using map or filter doesn’t make code declarative, using useState doesn’t make it procedural either. What matters is what you’re expressing.

The declarative overlay pattern discussed in this post is the same. What matters isn’t the openAsync API — it’s “do you see overlays as state, or as relationships?”

See them as state, and you must track variables like isOpen, isLoading, and result. See them as relationships, and you only need to think about input and output. Expressing the same problem differently is enough to change the cognitive load.

Removing unnecessary complexity so developers can focus on the essential problem is what good abstraction does.

상태에서 관계로: 선언적 오버레이 패턴(Declarative Overlay Pattern)

Tue, 07 Oct 2025 02:10:27 GMT

이번 포스팅에서는 지난 포스팅에 이어 선언적 프로그래밍이 현실에 어떤 형태로 구현되는지에 대해서 조금 더 자세한 이야기를 해보려고 한다.

그냥 이론적인 설명만 하면 너무 재미가 없으니 리액트에서 오버레이 요소들을 쉽게 다룰 수 있도록 도와주는 overlay-kit이라는 라이브러리를 통해 선언적 프로그래밍에 대해 조금 더 자세히 알아보겠다.

선언적 프로그래밍의 본질

필자는 이전에 선언적 프로그래밍의 본질에 대해 이야기한 바 있다. map이나 filter 같은 배열 메소드를 쓴다고 해서 무조건 선언적인 것이 아니며, 진정한 선언적 사고는 “어떻게(How)“가 아닌 “무엇을(What)”, 절차가 아닌 관계에 집중하는 것이라고 말했다.

하지만 React를 사용하는 대부분의 개발자들은 여전히 모달이나 토스트와 같은 요소를 다룰 때 만큼은 10년 전의 절차적 사고에서 벗어나지 못하고 있다.

우리는 여전히 useState를 사용해 상태를 만들고, 이벤트 핸들러를 연결하고, 상태 변화의 순서를 관리한다. 이것은 “먼저 다이얼로그를 열고, 그 다음 확인을 기다리고, 마지막에 API를 호출한다”는 시간적 순서에 집중하는 절차적 사고라고 볼 수 있다.

마치 map을 사용하면서도 절차적으로 사고할 수 있는 것처럼, useState를 사용한다고 해서 선언적인 코드가 되는 것은 아니다.

상태 공간과 인지적 부하

이전 글에서 다뤘던 비동기 데이터 상태를 기억하는가? loading, data, error를 독립적인 boolean 상태로 관리하면 논리적으로 불가능한 상태 조합이 발생한다는 이야기였다. 오버레이 관리에서도 똑같은 문제가 발생한다.

const [isOpen, setIsOpen] = useState(false);
const [isLoading, setIsLoading] = useState(false);
const [result, setResult] = useState<'confirmed' | null>(null);

// 논리적으로 불가능한 상태 조합들
// { isOpen: false, isLoading: true, result: null }
// → 닫혀있는데 로딩 중

// { isOpen: false, isLoading: false, result: 'confirmed' }
// → 닫혀있는데 결과가 있음

// { isOpen: true, isLoading: true, result: 'confirmed' }
// → 로딩 중인데 이미 결과가 있음

세 개의 독립적인 상태 변수는 이론적으로 $2³ = 8$ 가지 조합을 만들지만, 실제로 논리적으로 유효한 조합은 그보다 훨씬 적다. 개발자는 코드를 작성할 때마다 “이 조합이 가능한가?”를 머릿속으로 검증해야 한다.

이러한 상황이 문제가 되는 근본적인 이유는 바로 인지적 부하의 증가다. 심리학자 존 스웰러(John Sweller)의 인지 부하 이론에 따르면, 인간의 작업 기억은 제한적이며, 동시에 처리할 수 있는 정보의 양에는 한계가 있다고 한다. 조지 밀러(George Miller)가 제시한 “매직 넘버 7±2”도 이와 동일한 맥락에서 나온 이야기이다.

그래서 위 예시의 오버레이 관리 패턴을 보면 isOpen, isLoading, result, 그리고 이들 사이의 유효한 조합까지 추적해야만 오버레이의 동작을 유추할 수 있다는 점이 문제인 것이다. 그나마 지금은 8가지 경우의 수 밖에 되지 않지만, 필요한 상태가 늘어날 수록 개발자가 기억해야할 정보의 양도 기하급수적으로 늘어날 것이다.

하지만 이 상황은 문제 자체의 복잡도가 아니라, 표현 방식이 만들어낸 외재적 인지 부하이기 때문에 충분히 해결해볼 수 있는 문제이다. 수학에서 복잡한 식을 적절한 표기법으로 바꾸면 이해가 쉬워지는 것처럼, 약간의 접근 방법만 바꾸면 오버레이도 더 간단한 방식으로 표현할 수 있다.

입력과 출력의 관계

필자가 이전 글에서 강조했던 핵심은 선언적 코드는 시간의 흐름이 아닌 관계를 표현한다는 것이었다.

한번 일차 함수를 나타내는 $y = 2x + 1$ 을 떠올려보자. 이것은 $x$ 에 2를 곱하고 1을 더하라는 계산 절차를 의미하는 것이 아니라 $x$ 와 $y$ 사이의 관계를 선언하는 것이다. 이 관계는 시간과 무관한 영원한 진리다. 언제 어디서나 $x$ 가 3이라면 $y$ 는 7이기 때문이다.

오버레이의 본질도 마찬가지다. 브라우저 네이티브 API인 window.confirm을 보자.

const result = window.confirm("정말 삭제하시겠습니까?");

물론 window.confirm은 UI를 띄우는 부수 효과를 가지므로 순수 함수는 아니다. 하지만 중요한 것은 이 함수가 상태 관리를 호출자에게 노출하지 않는다는 점이다. isOpen 같은 상태도, handleConfirm 같은 핸들러도 필요하지 않다. 내부적으로 어떻게 구현했는지, 어떤 순서로 렌더링하는지는 추상화 뒤로 숨겨져 있다. 개발자는 오직 “무엇을 넣으면 무엇이 나오는가”라는 관계에만 집중할 수 있다.

수학에서 함수는 집합 간의 대응 관계를 나타낸다. $f:A→B$ 라고 쓸 때, 우리는 집합 $A$ 의 각 원소가 집합 $B$ 의 원소와 어떻게 대응되는지를 선언한다. 이것은 계산 과정이 아니라 구조 간의 관계다.

window.confirm도 마찬가지다. 메시지 문자열이라는 집합에서 boolean 값이라는 집합으로의 대응 관계를 나타낸다.

선언적 오버레이 패턴(Declarative Overlay Pattern)

그렇다면 어떻게 해야 할까? 답은 의외로 간단하다. 오버레이를 상태로 다루지 말고 함수로 다루면 된다.

선언적 오버레이 패턴은 window.confirm이 보여준 함수적 본질을 React 생태계로 가져온다.

const result = await overlay.openAsync(({ isOpen, close }) => (
  <ConfirmDialog
    isOpen={isOpen}
    onConfirm={() => close(true)}
    onCancel={() => close(false)}
  />
));

openAsync는 Promise<T>를 반환하는 함수다.

Promise를 써본 개발자라면 이미 이 패턴을 알고 있다. API를 호출하면 Promise가 반환되고, await로 결과를 기다린다. openAsync도 동일하다. 오버레이를 열면 Promise가 반환되고, 사용자가 응답할 때까지 기다린다. 다만 API 서버 대신 사용자에게서 응답을 받을 뿐이다.

즉, “오버레이를 보여주고 사용자 응답을 받는다”는 관계를 선언하는 것이다.

이번 섹션에서는 선언적 오버레이 패턴이 왜 전통적인 상태 관리보다 나은지 세 가지 측면에서 살펴보려고 한다.

상태에서 관계로

이전 글에서 불가능한 상태 조합을 막는 방법을 다뤘다. 가능한 상태들을 명시적으로 열거하고, 타입 시스템이 불가능한 조합을 차단하도록 하는 것이다.

하지만 선언적 오버레이 패턴은 다른 접근을 취한다. 상태 조합을 제한하는 대신, 상태 자체를 추상화한다.

전통적인 상태 관리는 스냅샷을 다룬다. “지금 다이얼로그가 열려있는가?”, “지금 로딩 중인가?”, “지금 결과가 있는가?” 같은 현재 시점의 상태를 추적한다. 그리고 이 상태들을 하나씩 바꿔나가며 원하는 동작을 만든다. 이는 마치 사진 여러 장을 이어붙여 애니메이션을 만드는 것과 비슷하다.

하지만 잘 생각해보면 우리는 사용자가 다이얼로그에서 확인을 눌렀는지 아닌지를 알고 싶은 것이지 다이얼로그가 현재 열려있는지 닫혀있는지를 알고 싶은게 아니다.

즉, 중간 과정의 상태들은 사실 그 결과를 얻기 위한 수단일 뿐, 현재 상태가 아니라 최종 결과를 알고 싶은 것이다.

선언적 오버레이 패턴은 이 중간 과정을 제거한다. 기존에는 복잡하게 다루었던 여러 상태들을 오버레이를 연다는 하나의 동작으로 표현하고, 그 결과를 받는 것에만 집중한다.

// 다이얼로그를 열고
setIsOpen(true);

// 나중에 어딘가에서 다이얼로그를 닫으며 결과를 입력한다.
setIsOpen(false);
setResult('confirmed');

// 동작과 결과와의 관계만 표현해서 깔끔해졌다
const result = await overlay.openAsync(...);

왜 이것이 더 나을까?

첫째, 코드가 의도를 직접 표현한다. “사용자 확인을 받고 싶다”는 의도가 코드에 그대로 드러난다. 개발자가 머릿속으로 상태 변수 세 개를 조합해서 “아, 이게 확인을 받으려는 동작이구만”이라고 유추할 필요가 없다.

둘째, 에러를 만들 여지가 줄어든다. 첫 번째 방법은 isOpen을 true로 바꿨는데 나중에 false로 바꾸는 걸 깜빡한다거나, result를 설정했는데 다이얼로그를 닫지 않는다거나 하는 휴먼 에러의 구멍이 많다. 이러한 동작들을 추상화해서 함수로 표현하면 이런 실수들이 구조적으로 불가능해진다.

셋째, 변화의 과정이 아니라 변화의 결과에 집중할 수 있다. 상태가 어떻게 바뀌는지가 아니라 무엇이 일어나는지를 표현한다. 즉, 선언적이다.

다시 말해, 선언적 오버레이 패턴은 개별 상태 변수들이 어떤 값을 가지고 있는지(상태의 스냅샷)를 다루는 대신, 어떤 동작을 하면 어떤 결과가 나오는지(입출력의 관계)를 다루는 것이다.

인지적 부하의 재분배

코드의 가독성은 종종 주관적인 취향의 문제로 여겨진다. 하지만 심리학자 존 스웰러(John Sweller)의 인지 부하 이론은 이것이 단순한 취향이 아니라 인지 과학의 문제임을 보여준다.

전통적인 상태 관리 방식을 다시 보자. 개발자는 isOpen, isLoading, result 같은 여러 상태 변수를 동시에 추적해야 한다. 개발자가 모듈의 동작을 이해하기 위해 이 변수들이 어떤 순서로 바뀌는지, 어떤 조합이 유효한지를 머릿속으로 시뮬레이션해야 한다는 의미이다.

이것을 인지 부하 이론에서는 외재적 부하(Extraneous Load)라고 부른다. 코드에서 발생하는 외재적 부하는 문제 자체의 복잡도가 아니라 표현 방식이 만들어낸 불필요한 복잡도라고 볼 수 있다. 오버레이를 띄워 사용자 확인을 받는다는 본질적인 문제는 단순하지만, 이 행위를 여러 개의 상태 변수로 표현하면서 복잡도가 인위적으로 증가한 것이다.

조지 밀러(George Miller)가 제시한 “매직 넘버 7±2”를 떠올려보자. 인간은 동시에 약 7개 정도의 정보만 작업 기억에 유지할 수 있다. 하지만 상태 변수가 세 개만 되어도 가능한 조합은 8가지가 되고, 이 중 유효한 조합이 무엇인지까지 추적하면 이미 인지적 한계에 다다른다.

선언적 오버레이 패턴은 이 외재적 부하를 제거한다. 개발자는 더 이상 여러 개의 상태 변수 간의 조합을 기억할 필요가 없고, 하나의 함수 호출, 즉 오직 입력과 출력의 관계만 기억하면 되기 때문에 부하가 줄어든다.

필자는 이렇게 같은 문제를 더 적은 인지 부하로 표현하는 것, 개발자가 본질적인 문제에 집중할 수 있도록 불필요한 복잡도를 제거하는 것이 가독성 높은 코드를 만드는 본질이라고 생각한다.

하지만 오해하지 말아야 할 점이 있다. 복잡도가 사라진 것이 아니라 그저 재분배되었을 뿐이다.

overlay-kit 라이브러리 구현자는 여전히 Promise 관리, 상태 동기화와 같은 복잡한 로직을 다뤄야 하지만, 이런 짜치는 구현은 한 번만 하면 된다.

소수의 기여를 통해 수많은 개발자들이 낮은 인지 부하로 오버레이라는 동작을 다룰 수 있는 것, 이것이 추상화가 우리에게 선물해주는 가치이다.

조합과 제어 흐름

여러 오버레이를 통해 사용자 입력을 받아야 하는 상황을 생각해보자. 전통적인 방법에서는 아래와 같은 코드로 해당 로직을 구현하게 된다.

function CreateUserFlow() {
  const [step, setStep] = useState(1);
  const [info, setInfo] = useState(null);
  const [preference, setPreference] = useState(null);

  const handleInfoSubmit = (data) => {
    setInfo(data);
    setStep(2);
  };

  const handlePreferenceSubmit = (data) => {
    setPreference(data);
    setStep(3);
  };

  const handleConfirm = async () => {
    await api.createUser({ ...info, ...preference });
    setStep(1);
    setInfo(null);
    setPreference(null);
  };

  return (
    <>
      {step === 1 && <UserInfoForm onSubmit={handleInfoSubmit} />}
      {step === 2 && <PreferenceForm onSubmit={handlePreferenceSubmit} />}
      {step === 3 && <ConfirmDialog onConfirm={handleConfirm} />}
    </>
  );
}

위 코드는 사용자 정보, 선호도, 최종 확인을 받은 후 API를 호출하는 간단한 플로우다. 하지만 정보의 흐름이 코드 곳곳에 흩어져 있기 때문에 개발자는 step 상태가 어떻게 바뀌는지, 각 핸들러가 무엇을 하는지, JSX에서 어떤 조건으로 렌더링되는지를 모두 따라가야 전체 흐름을 이해할 수 있다.

이제 같은 로직을 overlay-kit의 openAsync로 구현한 모습을 보자.

async function createUser() {
  const info = await overlay.openAsync(({ isOpen, close }) => (
    <UserInfoForm isOpen={isOpen} onSubmit={close} />
  ));

  const preference = await overlay.openAsync(({ isOpen, close }) => (
    <PreferenceForm isOpen={isOpen} onSubmit={close} />
  ));

  if (await confirmCreation(info, preference)) {
    await api.createUser({ ...info, ...preference });
  }
}

가장 큰 차이점은 정보의 흐름이 선형적이라는 점이다. 첫 번째 줄에서 사용자 정보를 입력받고, 두 번째 줄에서 선호도를 입력받고, 세 번째 줄에서 확인을 거쳐 API를 호출한다. 코드를 위에서 아래로 읽는 순서가 곧 실행 순서다.

openAsync가 Promise를 반환하기 때문에 이것이 가능하다. Promise는 비동기 작업의 완료를 기다릴 수 있게 해준다. 첫 번째 오버레이가 닫힐 때까지 기다렸다가 두 번째 오버레이를 연다. 두 번째가 닫히면 세 번째로 넘어간다. 각 단계가 순차적으로 실행되면서 정보가 위에서 아래로 흐른다.

또한 각 단계는 독립적이기 때문에 각 관심사의 결합도가 낮고 응집도가 높다. 사용자 정보를 받는 폼은 사용자 정보만 받고 선호도를 받는 폼은 선호도만 받으며, 최종적으로 이들을 어떻게 이어붙일지는 createUser 함수가 결정한다. 각 컴포넌트는 그저 close 함수를 호출할 뿐이고, 이 결과가 어디로 가는지는 알 필요가 없다.

게다가 openAsync는 그저 값을 반환하는 함수이기에 일반적인 제어 흐름에 자연스럽게 통합된다. 조건부 로직이 필요하면 if 문을 쓰면 되고, 에러 처리가 필요하면 try/catch를 쓰면 되며, 반복이 필요하면 for 문을 쓰면 된다. 프로그래밍 101에서 배우는 제어 흐름이 그대로 작동하며, 오버레이를 위한 특별한 패턴을 배울 필요가 없다.

이러한 함수의 특성 덕에 특정 UX 흐름에 대한 재사용도 간단한 편이다.

function confirmAction(message: string) {
  return overlay.openAsync(({ isOpen, close }) => (
    <ConfirmDialog 
      message={message}
      isOpen={isOpen} 
      onConfirm={() => close(true)}
      onCancel={() => close(false)}
    />
  ));
}

if (await confirmAction('정말 삭제하시겠습니까?')) {
  await api.deleteUser();
}

if (await confirmAction('설정을 초기화하시겠습니까?')) {
  await api.resetSettings();
}

이것이 오버레이를 함수로 다루는 힘이다. 정보의 흐름을 선형적으로 표현할 수 있고, if와 try/catch와 for 같은 일반적인 제어 흐름에 자연스럽게 통합되며, 재사용은 별도 함수로 빼는 것만으로 충분하다.

선언적 사고의 확장

2013년, 우리는 React를 통해 직접적인 DOM 조작에서 벗어나 JSX로 데이터와 UI의 구조적 관계를 표현하며 선언적으로 UI를 다루는 세상을 접하게 되었다.

하지만 슬프게도 우리는 같은 React 코드베이스에서 컴포넌트는 선언적으로 작성하면서 오버레이만큼은 절차적으로 다루고 있다.

// 컴포넌트는 선언적으로
<UserProfile user={user} />

// 오버레이는 절차적으로
const [isOpen, setIsOpen] = useState(false);
const handleOpen = () => setIsOpen(true);
const handleClose = () => setIsOpen(false);

왜 이런 분열이 생긴 걸까? 그 이유는 오버레이가 마치 시간에 종속된 것처럼 보이기 때문이다. 사용자가 버튼을 누르면 다이얼로그가 열리고, 그 이후 확인 버튼을 누르면 API를 호출하고, 응답이 오면 다시 다이얼로그를 닫는 것처럼 말이다. 그래서 우리는 상태로 이 순서를 관리해야 한다고 생각했다.

하지만 window.confirm을 다시 보자.

if (window.confirm('정말 삭제하시겠습니까?')) {
  deleteItem();
}

물론 이 코드가 발생시키는 이펙트에도 사용자가 다이얼로그 내에서 확인을 누르기 까지 기다려야한다는 시간적 순서는 존재한다. 하지만 우리는 이것을 코드 상에서 시간의 흐름으로 표현하지 않으며, 문자열을 인자로 받아 boolean 값을 반환하는 함수, 즉 문자열과 boolean의 관계로만 표현한다.

선언적 오버레이 패턴이 하는 일이 바로 이것이다. 시간적 순서를 조건과 결과의 관계로 바꾼다.

// 절차적: "먼저 열고, 기다리고, 닫고, 그 다음..."
setIsOpen(true);
// ... 어딘가에서
setIsOpen(false);
// ... 그 다음에
deleteItem();

// 선언적: "확인받으면 삭제한다"
if (await overlay.openAsync(...)) {
  deleteItem();
}

이제 우리는 React의 선언적 철학을 오버레이에도 적용할 수 있다. 컴포넌트가 데이터와 UI의 관계를 선언하듯, 오버레이도 사용자 응답과 다음 동작의 관계를 선언한다.

그리고 이 통일성이 중요하다. 컴포넌트를 읽을 때는 선언적으로 사고하다가, 오버레이를 읽을 때는 절차적으로 사고해야 한다면 인지적 분열이 발생한다. 하지만 선언적 오버레이 패턴을 사용하면 전체 코드베이스가 하나의 사고방식으로 통일된다.

마치며

overlay-kit은 이 패턴을 구현한 라이브러리다.

이 라이브러리의 가치는 코드 줄 수를 줄이는 것이 아니라, window.confirm이 보여준 단순함을 React 생태계로 가져오는 것이다. 10년 전에는 간단했지만 복잡해진 무언가를 다시 간단하게 만드는 것 뿐이다.

필자는 이전 글에서 선언적 프로그래밍이 도구가 아니라 사고방식이라고 말했다. map이나 filter를 쓴다고 선언적인 것이 아니듯, useState를 쓴다고 절차적인 것도 아니다. 중요한 것은 무엇을 표현하는가였다.

이 글에서 다룬 선언적 오버레이 패턴도 마찬가지다. 중요한 것은 openAsync라는 API가 아니라 “오버레이를 상태로 볼 것인가, 관계로 볼 것인가”이다.

상태로 보면 isOpen, isLoading, result 같은 변수들을 추적해야 한다. 관계로 보면 입력과 출력만 생각하면 된다. 같은 문제를 다르게 표현하는 것만으로 인지 부하가 달라진다.

그리고 필자는 이렇게 개발자가 본질적인 문제에 집중할 수 있도록 불필요한 복잡도를 제거하는 것이 좋은 추상화의 본질이라고 생각한다.

Misconceptions About Declarative Programming

Sun, 07 Sep 2025 07:16:53 GMT

When conducting technical interviews, I often ask candidates about the reasoning behind their decisions in take-home assignments.

A common answer I hear is “because this approach is more declarative.” But when I follow up with “What makes it declarative?” or “What does declarative code actually mean?”, clear answers are surprisingly rare.

So in this post, I want to share my thoughts on what it truly means for code to be declarative.

Many developers believe they’re writing declarative code, but they often miss the essence, confusing the use of a specific tool or syntax with being declarative.

In my view, declarative programming isn’t about tools. It’s a fundamental shift in how you think.

The most common misconception about declarative programming

The first trap many developers fall into is the belief that “abstracting procedural behavior into functions makes it declarative.” But using functions doesn’t automatically make your code declarative.

Let’s start with a simple example. Here’s a procedural way to fetch user information:

function getUserInfo(userId) {
  const connection = connectDB();
  const userRow = connection.query('SELECT * FROM users WHERE id = ?', userId);
  const permissionRows = connection.query('SELECT * FROM permissions WHERE user_id = ?', userId);

  const user = {
    id: userRow.id,
    name: userRow.name,
    email: userRow.email,
    permissions: permissionRows.map(row => row.permission_name)
  };

  if (user.name) {
    user.displayName = user.name.toUpperCase();
  }

  return user;
}

This code uses a function, but it focuses on temporal sequencing: “first fetch the user from the DB, then add permissions, and finally format the data.” Using a function doesn’t free you from procedural thinking.

Declarative code shifts focus away from temporal ordering and toward describing the relationships between operations.

// Declarative approach — focus on data transformation relationships
const getUserInfo = (userId) =>
  pipe(
    fetchUserFromDB,
    addUserPermissions,
    formatUserData
  )(userId);

// Or more explicitly
const getUserInfo = (userId) =>
  formatUserData(
    addUserPermissions(
      fetchUserFromDB(userId)
    )
  );

This code declares the relationship “user ID → formatted user info.” It focuses on the relationships between data transformations, not on execution order.

The distinction is clear. Procedural code focuses on “How — step by step.” Declarative code focuses on “What — what relationship do we want?”

This misconception is especially common with array methods. Many people assume that using map, filter, or reduce automatically makes code declarative.

But you can absolutely think procedurally while using array methods:

// Array methods used with procedural thinking
function processItems(items) {
  return items
    .map(item => {
      let price = item.basePrice;

      if (item.discount) {
        price = price * (1 - item.discount);
      }

      price = price * 1.1;

      return { ...item, finalPrice: Math.round(price * 100) / 100 };
    })
    .filter(item => item.finalPrice > 0);
}

A declarative approach, by contrast, focuses exclusively on describing the business relationships each transformation represents:

// Truly declarative approach
const processItems = (items) =>
  items
    .map(applyDiscount)
    .map(addTax)
    .map(formatPrice)
    .filter(hasValidPrice);

const applyDiscount = (item) => ({
  ...item,
  price: item.basePrice * (1 - (item.discount || 0))
});

const addTax = (item) => ({
  ...item,
  price: item.price * 1.1
});

const formatPrice = (item) => ({
  ...item,
  finalPrice: Math.round(item.price * 100) / 100
});

const hasValidPrice = (item) => item.finalPrice > 0;

The first version uses array methods but still focuses on step-by-step processing. The second version clearly declares the business relationship each transformation represents.

What matters is proper abstraction — each function clearly expressing what it does.

Functions are neutral tools. You can wrap procedural thinking in a function, or express relational thinking through one. The essence of declarative programming isn’t whether you use functions — it’s what kind of abstraction those functions provide.

These rough examples might not fully convey the idea, so let’s dig into the fundamentals.

Declarative programming from a mathematical perspective

To properly understand declarative programming, we first need to understand the concept of “declaration” itself. The easiest way is to start with everyday examples.

Think about a cooking recipe. The procedural approach is like a recipe: “Boil 2 cups of water, add the noodles and cook for 3 minutes, add the seasoning and cook for 1 more minute, serve in a bowl.” It’s a set of instructions that follow a timeline.

The declarative approach expresses relationships: “Ramen = cooked noodles + seasoning + hot water.” It describes the essential relationships between ingredients.

A recipe is a set of instructions ordered by time. A relational declaration describes the essential relationships between components. This difference is the fundamental distinction between procedural and declarative thinking.

Let’s look at a clearer example from math. Consider the linear function $f(x) = 2x + 1$ that we all learned in school. This expression is not a command telling a computer to “multiply $x$ by 2 and add 1.” It’s a declaration that “this relationship exists between $x$ and $f(x)$ .”

This declaration is a timeless truth because it describes a relationship. Whenever $x$ is 3, $f(x)$ is 7 — always, everywhere. The computation process or execution order doesn’t matter. What matters is the relationship between $f(x)$ and $x$ itself.

What mathematicians focus on when defining functions is precisely these invariant relationships. A function isn’t a computation algorithm — it’s a correspondence between structures. When we define the trigonometric function $\sin(x)$ , we’re declaring the relationship between an angle and the $y$ -coordinate on the unit circle, not prescribing how to calculate it.

Memorizing the trigonometry table means memorizing the relationships that sin, cos, and tan express

The same applies to programming. Declarative code doesn’t order a computer to do something — it expresses “the essence of this problem lies in these relationships.” From this perspective, programming becomes not about dictating computation steps, but about discovering and expressing the mathematical structure of a problem domain.

Procedural vs. declarative: a difference in thinking

Now let’s look at concrete examples that approach the same functionality from both mindsets. Procedural thinking focuses on changes that happen over time: “First do this, then do that…” — a sequential execution model.

// Procedural programming — focused on How
function calculateTotalPrice(items) {
  let total = 0;

  // Step 1: Iterate through each item
  for (let i = 0; i < items.length; i++) {
    const item = items[i];

    // Step 2: Validate
    if (item.quantity > 0) {
      // Step 3: Calculate base price
      let itemPrice = item.price * item.quantity;

      // Step 4: Apply discount
      if (item.discount) {
        itemPrice = itemPrice - (itemPrice * item.discount);
      }

      // Step 5: Accumulate total
      total = total + itemPrice;
    }
  }

  return total;
}

This code focuses on temporal order and state changes. You have to track what happens at each step and how variables mutate.

Declarative thinking, on the other hand, focuses on timeless logical relationships. It declares: “total price = the sum of discounted prices of valid items.”

// Declarative programming — focused on What
const calculateTotalPrice = (items) =>
  items
    .filter(hasValidQuantity)
    .map(calculateItemPrice)
    .reduce(sum, 0);

const hasValidQuantity = (item) => item.quantity > 0;
const calculateItemPrice = (item) =>
  item.price * item.quantity * (1 - (item.discount || 0));
const sum = (a, b) => a + b;

This code declares data transformation relationships. Each function represents a specific transformation, and their composition solves the whole problem.

In programming, this difference manifests in the kind of abstraction the code expresses. Procedural code abstracts over the computer’s execution process — memory allocation, loop execution, conditional branching — wrapping mechanical operations in variables and control structures. Declarative code abstracts over the logical structure of the problem domain — expressing conceptual relationships like business rules, data relationships, and state transformations through functions and types.

So why does this relational thinking matter? The fundamental reason is human cognitive limitations. According to psychologist George Miller’s research, human short-term memory can only handle about 7±2 units of information simultaneously.

In procedural thinking, you must track all state changes over time, and as programs grow complex, the combinations of states explode exponentially. With 10 variables, there are $2^{10} = 1024$ possible states, and at each step you need to consider all of them. Tracking all these changes is nearly impossible for human memory.

With relational thinking, you manage complexity through composition of invariant relationships. It’s the same principle as expressing a complex function as a composition of simpler ones in math. In $h(x) = f(g(x))$ , you don’t need to know the internals of both $f$ and $g$ to understand $h$ — you only need to understand each one’s input-output relationship.

This relational thinking lets us chunk complex states into manageable pieces, greatly helping us understand complex code.

Why is JSX declarative?

Let’s now look at JSX, a declarative tool we encounter daily. I want to address the question “Why is specific code declarative?” through the lens of JSX.

One pattern I frequently see in interviews is answering “What is declarative code?” with “It’s using tools like JSX or React.” When I follow up with “So why is JSX declarative?”, the answer is often “Because using JSX lets you write declarative code” — a textbook circular argument.

The real reason JSX is declarative lies in how it expresses structural relationships. Let’s compare two approaches:

function createUserProfile(user) {
  const container = document.createElement('div');
  container.className = 'user-profile';

  const nameElement = document.createElement('h2');
  nameElement.textContent = user.name;
  container.appendChild(nameElement);

  const emailElement = document.createElement('p');
  emailElement.textContent = user.email;
  container.appendChild(emailElement);

  if (user.avatar) {
    const avatarElement = document.createElement('img');
    avatarElement.src = user.avatar;
    avatarElement.alt = `${user.name}'s avatar`;
    container.appendChild(avatarElement);
  }

  return container;
}

function UserProfile({ user }) {
  return (
    <div className="user-profile">
      <h2>{user.name}</h2>
      <p>{user.email}</p>
      {user.avatar && (
        <img src={user.avatar} alt={`${user.name}'s avatar`} />
      )}
    </div>
  );
}

The first version focuses on the order of creating and manipulating DOM elements: “First create a container, then create a name element and append it, then create an email element and append it…” Temporal order matters — changing the order of appendChild calls changes the result.

The JSX version focuses solely on declaring: “A UserProfile is a structure composed of a name, email, and optionally an avatar.” What matters here is the containment and hierarchy between elements — temporal order is irrelevant.

The correspondence between data and UI

JSX’s real power lies in its ability to intuitively express the correspondence between data structures and UI structures.

const TodoList = ({ todos }) => (
  <ul>
    {todos.map(todo => (
      <TodoItem
        key={todo.id}
        text={todo.text}
        completed={todo.completed}
      />
    ))}
  </ul>
);

Looking at this code, you can immediately read the relationship: each item in the todos array corresponds to a TodoItem component. The structure of the data becomes the structure of the UI.

The same behavior written imperatively looks like this:

function createTodoList(todos) {
  const ul = document.createElement('ul');

  for (let i = 0; i < todos.length; i++) {
    const li = document.createElement('li');
    li.textContent = todos[i].text;
    if (todos[i].completed) {
      li.classList.add('completed');
    }
    ul.appendChild(li);
  }

  return ul;
}

In the imperative version, procedural steps — data iteration, element creation, attribute setting, DOM insertion — are all tangled together. To understand the relationship between the data structure and the final UI, you have to read the entire code and mentally execute it.

Expressing structural relationships

JSX is similar to how mathematics expresses set relationships. When we write $A = \{a, b, c\}$ , we declare that set $A$ is composed of elements $a, b, c$ . This relationship is independent of the order in which elements were added.

JSX works the same way. When we write code like this, we declare “UserCard is composed of Avatar and UserInfo.” This relationship is conceptually separate from the order in which components are rendered.

// Declaration of structural relationships
const UserCard = ({ user }) => (
  <div className="user-card">
    <Avatar src={user.avatar} />
    <UserInfo name={user.name} email={user.email} />
  </div>
);

It focuses solely on declaring “a user card is a combination of an avatar and user info.” How each component is implemented and in what order they’re added to the DOM are separate concerns.

From this perspective, JSX is declarative not merely because it hides complex processes, but because it lets you directly express the essential relationships between data and UI.

Now that we understand why JSX is declarative, a question might arise:

“But JSX ultimately compiles to createElement, and React’s reconciliation is procedural code too, right? Is it really declarative then?”

Declarative and procedural are relative

This is a critical point when understanding abstraction and declarative programming — treating these concepts as absolutes leads to serious misconceptions.

In reality, the same code can be declarative or procedural depending on your vantage point and level of abstraction. “Declarative” and “procedural” aren’t absolute categories. They’re relative concepts.

Let’s examine this relativity through a React Query example:

// Application level — declarative
function useUserData(userId) {
  return useQuery(['user', userId], () => fetchUser(userId));
}

function UserProfile({ userId }) {
  const { data: user, isLoading, error } = useUserData(userId);

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>An error occurred</div>;

  return <div>{user.name}</div>;
}

From the application developer’s perspective, this code is completely declarative. It declares a relationship: “a query that fetches user data for a given userId.” Complex logic like caching, retries, and error handling is all abstracted away.

But the QueryClient implementation code behind useQuery is procedural — cache checks, network requests, state updates, and retry logic are all laid out explicitly.

This relativity becomes especially clear at domain boundaries. Looking at an order processing function at the business logic level:

// Business logic level — declarative
async function processOrder(order) {
  const validatedOrder = await validateOrder(order);
  const payment = await processPayment(validatedOrder);
  const shipment = await scheduleShipment(validatedOrder);

  return createOrderConfirmation(validatedOrder, payment, shipment);
}

This function is declarative from a business logic perspective — it clearly expresses the relationships: “validate the order, process payment, and schedule shipping.” But the infrastructure-level functions underneath, like payment processing, are procedural:

// Infrastructure level — procedural
async function processPayment(order) {
  const paymentGateway = new PaymentGateway(process.env.PAYMENT_API_KEY);

  try {
    const paymentRequest = {
      amount: order.total,
      currency: order.currency,
      source: order.paymentMethod
    };

    const response = await paymentGateway.charge(paymentRequest);

    if (response.status === 'succeeded') {
      await database.payments.create({
        orderId: order.id,
        paymentId: response.id,
        amount: response.amount,
        status: 'completed'
      });

      return { success: true, paymentId: response.id };
    } else {
      throw new PaymentError(response.error);
    }
  } catch (error) {
    await logger.error('Payment processing failed', { orderId: order.id, error });
    throw error;
  }
}

The concept of “declarative” is relative depending on which layer you’re observing from. The point of declarative code is how well the abstracted parts are expressed so you need to inspect the procedurally written parts less.

Another common prejudice is that “procedural code is bad and should always be avoided.” This too is misguided. Even the most elegant functional code ultimately runs as procedural CPU instructions.

What matters is providing the right abstraction at the right level.

Understanding this relativity reveals that finding appropriate abstractions at each level is what’s important. Not everything needs to be declarative. At the business logic level, a declarative approach works well because the focus should be on expressing the essential relationships of the domain. At the infrastructure level, procedural code is perfectly fine because efficient, safe implementation matters more.

The key is to draw clear boundaries and match the level of abstraction. It must be clear which level handles which concerns. In a good design, the business level declaratively expresses the shopping cart’s structure, while the infrastructure level uses procedural calculation logic — and that’s perfectly fine.

// Good example: Clear level separation

// Business level — declarative
const ShoppingCart = ({ items, onCheckout }) => (
  <div className="shopping-cart">
    <ItemList items={items} />
    <TotalPrice items={items} />
    <CheckoutButton onClick={() => onCheckout(items)} />
  </div>
);

// Presentation level — declarative
const ItemList = ({ items }) => (
  <ul className="item-list">
    {items.map(item => (
      <ItemCard key={item.id} item={item} />
    ))}
  </ul>
);

// Infrastructure level — procedural is OK
function calculateTotalWithTax(items, taxRate) {
  let subtotal = 0;

  for (const item of items) {
    subtotal += item.price * item.quantity;
  }

  const tax = subtotal * taxRate;
  return subtotal + tax;
}

From this perspective, declarative programming isn’t about “making all code declarative” — it’s about “having the right expressiveness at the right level of abstraction.”

Code that looks declarative vs. code that actually is

Now let’s concretely answer the core question: “What makes specific code declarative?” The essence of declarative code is clearly defining the relationships between possible states.

Just as mathematics defines the domain of a function precisely, a program should first declare “which state combinations are logically possible.”

Consider asynchronous data requests. In reality, only states like idle, loading, success (with data), and error (with an error message) are logically possible. A state that is “loading while simultaneously having data and an error” is a contradictory combination that can’t happen in reality.

Let’s examine this through handling async data in a React + TypeScript environment.

Code that looks declarative — focused on state change processes

An async data hook written with a procedural approach focuses on how state changes:

// Procedural approach — focused on how state changes
function useAsyncData<T>(fetcher: () => Promise<T>) {
  const [data, setData] = useState<T | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    // Step 1: Transition to loading state
    setLoading(true);
    setError(null);
    setData(null);

    fetcher()
      .then(result => {
        // Step 2: Transition to success state
        setData(result);
        setLoading(false);
      })
      .catch(err => {
        // Step 3: Transition to error state
        setError(err.message);
        setLoading(false);
        setData(null);
      });
  }, [fetcher]);

  return { data, loading, error };
}

Truly declarative code — focused on state relationships

The declarative approach focuses on what the possible states are:

// Declarative approach — focused on what states are possible
type AsyncDataState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: string };

function useAsyncData<T>(fetcher: () => Promise<T>): AsyncDataState<T> {
  const [state, setState] = useState<AsyncDataState<T>>({ status: 'idle' });

  useEffect(() => {
    setState({ status: 'loading' });

    fetcher()
      .then(data => setState({ status: 'success', data }))
      .catch(error => setState({ status: 'error', error: error.message }));
  }, [fetcher]);

  return state;
}

Why is the first version procedural?

The first version focuses on the sequence and process of state changes: “First set loading to true, reset error to null, reset data to null…” — a series of procedural commands.

The more critical problem is that impossible state combinations are permitted at the type level. TypeScript can’t prevent a nonsensical state like { data: someUserData, loading: true, error: "Network Error" }. Having data while simultaneously loading and having an error is a logical contradiction. But with the first approach, the developer must manually guarantee the validity of all state combinations.

You have to check at every setState call whether the other states are properly reset — and this easily leads to human error. For instance, forgetting setLoading(false) on success, or omitting setData(null) on error.

Why is the second version declarative?

The second version declares the essential state relationships of the “async data request” domain. Through a union type, it expresses the invariant relationship “exactly one of these four states can exist” at the type level.

The key point is that impossible states are blocked at the source. The TypeScript compiler prevents contradictory combinations like “loading and success at the same time” at compile time. This follows the same principle as clearly defining a function’s domain in mathematics. In $f: A \rightarrow B$ , $A$ is the domain of function $f$ , and $f$ is undefined for values outside $A$ .

Let’s look more concretely at the safety guarantees union types provide:

// Safety enforced by TypeScript at compile time
function handleAsyncState<T>(state: AsyncDataState<T>) {
  switch (state.status) {
    case 'idle':
      return "Not started yet";

    case 'loading':
      return "Loading...";
      // Accessing state.data or state.error here causes a compile error

    case 'success':
      return `Data: ${state.data}`;
      // state.data is guaranteed to exist here
      // Accessing state.error causes a compile error

    case 'error':
      return `Error: ${state.error}`;
      // state.error is guaranteed to exist here
      // Accessing state.data causes a compile error

    default:
      // TypeScript verifies all cases are handled
      const exhaustiveCheck: never = state;
      return exhaustiveCheck;
  }
}

In each case, only the properties valid for that state are accessible — attempting to access other properties results in a compile error. The never type in the default case lets the compiler verify that all cases have been covered.

Differences in component usage

Using the first approach requires the developer to manually handle all combinations:

// First approach — manual handling of all combinations
function DataDisplay<T>({ fetcher, render }: {
  fetcher: () => Promise<T>;
  render: (data: T) => React.ReactNode;
}) {
  const { data, loading, error } = useAsyncData(fetcher);

  // Developer must manually consider every combination
  if (loading && !error && !data) return <LoadingSpinner />;
  if (error && !loading) return <ErrorMessage error={error} />;
  if (data && !loading && !error) return render(data);

  // How do we handle unexpected state combinations?
  // What about { loading: true, data: someData, error: null }?
  return <div>Unknown state</div>;
}

The second approach lets the types guarantee complete coverage:

// Second approach — types guarantee all cases
function DataDisplay<T>({ fetcher, render }: {
  fetcher: () => Promise<T>;
  render: (data: T) => React.ReactNode;
}) {
  const state = useAsyncData(fetcher);

  // TypeScript verifies all cases are handled
  switch (state.status) {
    case 'idle':
      return <div>Ready...</div>;

    case 'loading':
      return <LoadingSpinner />;

    case 'success':
      // state.data is guaranteed to be of type T
      return render(state.data);

    case 'error':
      // state.error is guaranteed to exist
      return <ErrorMessage error={state.error} />;

    // TypeScript verifies at compile time that all cases are covered
    // Adding a new state triggers a compile error for unhandled cases
  }
}

TypeScript verifies that all cases are handled and guarantees that the relevant properties exist in each case. When a new state is added, compile errors surface any missed spots.

Differences in extensibility

Consider a scenario where you need to add new states. With the first approach, you must modify multiple variables:

// First approach — must modify multiple variables
const [retrying, setRetrying] = useState(false);
const [stale, setStale] = useState(false);

// Each state change requires considering combinations with all other states
// Of 16 boolean combinations, how many are logically valid?

With the second approach, you simply extend the type definition:

// Second approach — just extend the type definition
type AsyncDataState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'retrying'; previousError: string; attempt: number }
  | { status: 'success'; data: T; stale?: boolean }
  | { status: 'error'; error: string };

// TypeScript forces handling of new cases at all usage sites
// Compile errors surface any missed spots

Adding a new state makes TypeScript enforce handling at every usage site. Compile errors reliably surface anything you’ve missed, allowing safe extension.

The essence of declarative thinking in this example is defining “what is possible” first. Just as mathematics defines a function’s domain and range precisely, we explicitly declare the possible states of an async request.

Procedural approaches focus on “how to change state,” while declarative approaches first declare “which states are logically possible in this problem domain.” This shift in perspective is the essence of declarative programming.

Practical guidelines

Now let’s distill the theory into concrete criteria for real-world application. Here are practical guidelines for when to choose procedural vs. declarative approaches.

When should you take a declarative approach?

Business logic and state management benefit from a declarative approach. As with the async data state example above, when complex state combinations are possible, it’s important to block impossible states at the type level:

// Reusing the AsyncDataState example from above
type AsyncDataState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: string };

UI structure is also a natural fit for the declarative approach. As we saw with JSX, you can directly express the structural relationship between data and UI:

// Reusing the JSX example — clearly declaring structural relationships
const UserProfile = ({ user }) => (
  <div className="user-profile">
    <h2>{user.name}</h2>
    <p>{user.email}</p>
    {user.avatar && <img src={user.avatar} alt={`${user.name}'s avatar`} />}
  </div>
);

Data transformation pipelines also benefit from a declarative approach when each step can be independently defined and tested:

// Clearly declaring transformation relationships
const processUserData = (rawUsers: RawUser[]) =>
  rawUsers
    .filter(isActiveUser)
    .map(normalizeUserData)
    .map(addComputedFields)
    .sort(byLastLoginDate);

When is a procedural approach acceptable?

Infrastructure-level code and performance optimization are well suited to procedural approaches.

As discussed in the relativity section, when efficiency and performance matter, procedural implementation is natural:

// Reusing the calculation logic example from above
function calculateTotalWithTax(items, taxRate) {
  let subtotal = 0;

  for (const item of items) {
    subtotal += item.price * item.quantity;
  }

  const tax = subtotal * taxRate;
  return subtotal + tax;
}

Complex state management and optimization in library code, like React Query’s internals, also calls for procedural approaches. Cache checks, network requests, state updates, and retry logic are more efficiently implemented procedurally.

System-level code with complex error handling is another good fit:

// Complex error handling and retry logic
async function retryWithBackoff<T>(
  operation: () => Promise<T>,
  maxAttempts: number = 3
): Promise<T> {
  let lastError: Error;

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await operation();
    } catch (error) {
      lastError = error as Error;

      if (attempt === maxAttempts) {
        throw lastError;
      }

      const delay = Math.pow(2, attempt - 1) * 1000;
      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }

  throw lastError!;
}

Closing thoughts

Declarative programming isn’t about using specific syntax or tools. It’s a shift in thinking, from “how” to “what,” from procedures to relationships.

The core ideas: relational thinking over temporal sequences. Declaring possible states upfront and blocking impossible ones at the type level. Providing the right abstraction at the right level. And remembering that “declarative” is always relative to the layer you’re looking at.

Declarative programming is a way of thinking, not a tool. When you internalize that, the code you write starts to look different.

선언적 프로그래밍에 대한 착각과 오해

Sun, 07 Sep 2025 07:16:53 GMT

필자는 평소 기술 인터뷰를 진행하며 지원자 분들이 과제를 작성하면서 내렸던 의사결정에 대한 근거를 물어보는 경우가 잦다.

이때 이에 대한 근거로 “이런 방식이 보다 선언적이기 때문이다”라는 답변을 많이 해주시는데, 정작 그 방식이 왜 선언적인 것인지, 선언적인 코드란 무엇인지 여쭤보면 시원한 답변을 해주시는 경우는 많지 않았던 것 같다.

그래서 이번 포스팅에서는 필자가 생각하는 선언적이라는 것이 무엇인지, 그리고 선언적인 코드란 무엇인지에 대해서 한번 간략하게 이야기해보려고 한다.

많은 개발자들이 스스로 선언적인 코드를 작성한다고 생각하지만 실제로는 본질을 놓치고 있는 경우가 종종 있으며, 단지 특정한 도구를 사용하거나 문법을 사용하는 것이 선언적인 것이라고 착각하고는 한다.

하지만 필자가 생각하는 선언적 프로그래밍은 도구의 문제가 아니라 사고방식의 근본적 전환이다.

선언적 프로그래밍에 대한 가장 흔한 착각

많은 개발자들이 빠지는 첫 번째 함정은 “절차적인 동작을 함수로 추상화하면 선언적”이라는 착각이다. 하지만 함수를 사용한다고 해서 무조건 선언적인 프로그래밍을 구사하는 것은 아니다.

가장 간단한 예부터 살펴보자. 사용자 정보를 가져오는 함수를 절차적으로 작성하면 이렇게 된다.

function getUserInfo(userId) {
  const connection = connectDB();
  const userRow = connection.query('SELECT * FROM users WHERE id = ?', userId);
  const permissionRows = connection.query('SELECT * FROM permissions WHERE user_id = ?', userId);
  
  const user = {
    id: userRow.id,
    name: userRow.name,
    email: userRow.email,
    permissions: permissionRows.map(row => row.permission_name)
  };
  
  if (user.name) {
    user.displayName = user.name.toUpperCase();
  }
  
  return user;
}

위 코드는 함수를 사용하고는 있지만 “먼저 DB에서 사용자를 가져오고, 그 다음 권한을 추가하고, 마지막에 포맷팅한다”는 시간적 순서에 집중하고 있다. 즉, 함수를 사용했다고 해서 절차적 사고에서 벗어난 것이 아니다.

선언적인 코드는 동작의 시간적 순서에서 벗어나 동작 간의 관계를 기술하는 것에 집중해야한다.

// 선언적 접근 - 데이터 변환 관계에 집중
const getUserInfo = (userId) => 
  pipe(
    fetchUserFromDB,
    addUserPermissions,
    formatUserData
  )(userId);

// 또는 더 명확하게
const getUserInfo = (userId) => 
  formatUserData(
    addUserPermissions(
      fetchUserFromDB(userId)
    )
  );

이 코드는 “사용자 ID → 포맷된 사용자 정보”라는 관계를 선언한다. 실행 순서가 아니라 데이터 변환의 관계에 집중하고 있다.

여기서 핵심 구분 기준은 명확하다. 절차적 코드는 “어떻게(How) 단계별로 실행할 것인가”에 집중하고, 선언적 코드는 “무엇을(What) 원하는 관계인가”에 집중한다.

이런 착각은 특히 배열 메소드를 사용할 때 자주 발생한다. map, filter, reduce 같은 메소드를 쓰면 자동으로 선언적 코드가 된다고 생각하는 경우가 많다.

하지만 마찬가지로 배열 메소드를 사용하더라도 얼마든지 절차적인 사고가 가능하다.

// 배열 메소드를 사용했지만 절차적 사고
function processItems(items) {
  return items
    .map(item => {
      let price = item.basePrice;

      if (item.discount) {
        price = price * (1 - item.discount);
      }

      price = price * 1.1;

      return { ...item, finalPrice: Math.round(price * 100) / 100 };
    })
    .filter(item => item.finalPrice > 0);
}

반면 선언적인 접근은 각각의 변환이 나타내는 비즈니스 관계에만 집중하여 기술한다는 차이점이 있다.

// 진정한 선언적 접근
const processItems = (items) =>
  items
    .map(applyDiscount)
    .map(addTax)
    .map(formatPrice)
    .filter(hasValidPrice);

const applyDiscount = (item) => ({
  ...item,
  price: item.basePrice * (1 - (item.discount || 0))
});

const addTax = (item) => ({
  ...item,
  price: item.price * 1.1
});

const formatPrice = (item) => ({
  ...item,
  finalPrice: Math.round(item.price * 100) / 100
});

const hasValidPrice = (item) => item.finalPrice > 0;

첫 번째 코드는 배열 메소드를 사용했지만 여전히 단계별 처리 과정에 집중하고 있지만, 두 번째 코드는 각각의 변환이 나타내는 비즈니스 관계를 명확히 선언하고 있다.

중요한 것은 그 함수가 무엇을 하는지를 명확하게 표현하는 올바른 추상화까지 곁들여야 한다는 것이다.

결국 함수 자체는 중립적인 도구다. 절차적 사고를 함수로 포장할 수도 있고, 관계적 사고를 함수로 표현할 수도 있다. 선언적 프로그래밍의 핵심은 함수 사용 여부가 아니라, 그 함수가 어떤 추상화를 제공하느냐에 따라 달라진다.

대략적인 예시만으로는 이해가 쉽지 않을 수 있으니 이제 본질적인 부분을 살펴보도록 하자.

수학적 관점에서 본 선언적 프로그래밍

선언적 프로그래밍을 제대로 이해하려면 먼저 “선언”이라는 개념 자체를 이해해야 한다. 이를 가장 쉽게 이해할 수 있는 방법은 일상의 예시부터 시작하는 것이다.

우리가 요리 레시피를 생각해보자. 절차적 접근은 레시피와 같다. “물 2컵을 끓인다, 면을 넣고 3분간 끓인다, 스프를 넣고 1분간 더 끓인다, 그릇에 담는다”라는 시간의 흐름에 따른 행동 지침이다.

반면 선언적 접근은 관계를 표현한다. “라면 = 삶은 면 + 스프 + 뜨거운 물의 조합”이라는 재료들 사이의 본질적 관계를 나타낸다.

레시피는 시간의 흐름에 따른 행동 지침이고, 관계적 선언은 재료들 사이의 본질적 관계를 나타낸다. 이 차이가 바로 절차적 사고와 선언적 사고의 본질적 차이다.

수학에서 더 명확한 예를 살펴보자. 우리가 중학교 때 배운 일차함수 $f(x) = 2x + 1$ 을 생각해보자. 이 수식은 컴퓨터에게 ” $x$ 에 2를 곱하고 1을 더하라”는 명령이 아니다. 이는 ” $x$ 와 $f(x)$ 사이에는 이런 관계가 있다”는 사실을 선언한 것이다.

이 선언은 관계에 대한 기술이기 때문에 시간과 무관한 영원한 진리다. 언제 어디서나 $x$ 가 3이라면 $f(x)$ 는 7이라는 것이다. 여기서 계산 과정이나 실행 순서는 중요하지 않다. 중요한 것은 $f(x)$ 와 $x$ 의 관계 그 자체다.

수학자들이 함수를 정의할 때 주목하는 것은 바로 이런 불변적 관계다. 함수는 계산 알고리즘이 아니라 구조 간의 대응 관계를 나타내는 것이다. 우리가 삼각함수 $\sin(x)$ 를 정의할 때, 우리는 단위원에서 각도와 $y$ 좌표 사이의 관계를 선언하는 것이지, 어떻게 계산할지를 지시하는 것이 아닌 것과 마찬가지이다.

우리가 삼각비 표를 외우는 것은 sin, cos, tan 함수가 나타내는 관계를 외우는 것이다

프로그래밍에서도 마찬가지다. 선언적 코드는 컴퓨터에게 어떤 일을 할지 주문하는 것이 아니라 “이 문제의 본질은 이런 관계에 있다”는 것을 표현한다. 이런 관점에서 보면, 프로그래밍은 계산 과정을 지시하는 것이 아니라 문제 도메인의 수학적 구조를 발견하고 표현하는 행위가 된다.

절차적 vs 선언적: 사고방식의 차이

이제 같은 기능을 두 가지 사고방식으로 접근한 구체적 예시를 통해 차이점을 명확히 해보자. 절차적 사고는 시간의 흐름 속에서 일어나는 변화에 집중한다. “먼저 이것을 하고, 그 다음에 저것을 하고…”라는 순차적 실행 모델이다.

// 절차적 프로그래밍 - 어떻게(How) 할 것인가에 집중
function calculateTotalPrice(items) {
  let total = 0;
  
  // 단계 1: 각 아이템을 순회
  for (let i = 0; i < items.length; i++) {
    const item = items[i];
    
    // 단계 2: 유효성 검사
    if (item.quantity > 0) {
      // 단계 3: 기본 가격 계산
      let itemPrice = item.price * item.quantity;
      
      // 단계 4: 할인 적용
      if (item.discount) {
        itemPrice = itemPrice - (itemPrice * item.discount);
      }
      
      // 단계 5: 총합에 누적
      total = total + itemPrice;
    }
  }
  
  return total;
}

이 코드는 시간적 순서와 상태 변화에 집중한다. 각 단계에서 무엇이 일어나는지, 변수가 어떻게 변하는지를 추적해야 한다.

반면 선언적 사고는 시간을 초월한 논리적 관계에 집중한다. “총 가격 = 유효한 아이템들의 할인된 가격들의 합”이라는 관계를 선언한다.

// 선언적 프로그래밍 - 무엇을(What) 원하는가에 집중
const calculateTotalPrice = (items) =>
  items
    .filter(hasValidQuantity)
    .map(calculateItemPrice)
    .reduce(sum, 0);

const hasValidQuantity = (item) => item.quantity > 0;
const calculateItemPrice = (item) => 
  item.price * item.quantity * (1 - (item.discount || 0));
const sum = (a, b) => a + b;

이 코드는 데이터 변환의 관계를 선언한다. 각 함수는 특정한 변환 관계를 나타내고, 이들의 합성으로 전체 문제를 해결한다.

프로그래밍에서 이 차이는 코드가 표현하는 추상화의 종류로 드러난다. 절차적 코드는 컴퓨터의 실행 과정을 추상화한다. 메모리 할당, 루프 실행, 조건 분기 같은 기계적 연산을 변수와 제어 구조로 포장한다. 선언적 코드는 문제 도메인의 논리적 구조를 추상화한다. 비즈니스 규칙, 데이터 관계, 상태 변환 같은 개념적 관계를 함수와 타입으로 표현한다.

그렇다면 왜 이런 관계적 사고가 중요할까? 근본적인 이유는 인간의 인지적 한계 때문이다. 심리학자 조지 밀러(George Miller)의 연구에 따르면, 인간의 단기 기억은 동시에 7±2개의 정보 단위만 처리할 수 있다고 한다.

그러나 절차적 사고에서는 시간의 흐름에 따른 상태 변화를 모두 추적해야 하며 프로그램이 복잡해질수록 이런 상태들의 조합이 기하급수적으로 증가한다. 10개의 변수가 있다면 $2^{10} = 1024$ 가지의 가능한 상태가 있고, 각 단계에서 이 모든 경우의 수를 고려해야 한다는 의미이다. 인간의 기억력으로 이 모든 변화를 추적하는 것은 불가능에 가깝다.

반면 관계적 사고에서는 불변적 관계의 합성으로 복잡성을 관리한다. 수학에서 복잡한 함수를 간단한 함수들의 합성으로 표현하는 것과 같은 원리다. $h(x) = f(g(x))$ 에서 $h$ 를 이해하기 위해 $f$ 와 $g$ 의 내부 구현을 모두 알 필요가 없고 각각의 입출력 관계만 이해하면 되는 것처럼 말이다.

이러한 관계적 사고로 인해 복잡한 상태들을 몇 개의 청크로 나누어 기억할 수 있게 되고, 이는 우리가 복잡한 코드를 이해하는 데 큰 도움을 준다.

JSX는 왜 선언적일까?

이제 평소에 우리가 자주 접하는 대표적인 선언적 도구인 JSX를 예시로 한번 살펴보자. 앞서 제기한 “왜 특정 코드가 선언적인가?”라는 질문에 대해 JSX를 통해 한번 알아보려고 한다.

필자가 인터뷰에서 자주 보는 광경 중 하나는 바로 “선언적인 코드란 무엇인가?”라는 질문에 “JSX나 React 같은 도구를 사용하는 것”이라고 답하는 것이다. 이때 “그럼 JSX는 왜 선언적인가요?”라고 물어보면 “JSX를 사용하면 선언적인 코드를 작성할 수 있어서요”라고 답변하는, 전형적인 순환논법에 빠지는 경우가 많았다.

JSX가 선언적인 진짜 이유는 구조적 관계를 표현하는 방식에 있다. 두 가지 접근법을 비교해보자.

function createUserProfile(user) {
  const container = document.createElement('div');
  container.className = 'user-profile';
  
  const nameElement = document.createElement('h2');
  nameElement.textContent = user.name;
  container.appendChild(nameElement);
  
  const emailElement = document.createElement('p');
  emailElement.textContent = user.email;
  container.appendChild(emailElement);
  
  if (user.avatar) {
    const avatarElement = document.createElement('img');
    avatarElement.src = user.avatar;
    avatarElement.alt = `${user.name}의 아바타`;
    container.appendChild(avatarElement);
  }
  
  return container;
}

function UserProfile({ user }) {
  return (
    <div className="user-profile">
      <h2>{user.name}</h2>
      <p>{user.email}</p>
      {user.avatar && (
        <img src={user.avatar} alt={`${user.name}의 아바타`} />
      )}
    </div>
  );
}

첫 번째 코드는 DOM 요소를 생성하고 조작하는 순서에 집중한다. “먼저 컨테이너를 만들고, 그 다음 이름 요소를 만들어서 추가하고, 이메일 요소를 만들어서 추가하고…” 라는 시간적 순서가 중요하다. 심지어 각 appendChild 호출의 순서를 바꾸면 결과도 달라진다.

반면 JSX로 작성된 두 번째 코드는 “UserProfile은 이름, 이메일, 그리고 선택적으로 아바타로 구성된 구조다”라는 관계를 선언하는 것에만 집중한다. 여기서는 요소들 사이의 포함 관계와 계층 구조가 중요하며 시간적 순서는 전혀 중요하지 않다.

데이터와 UI의 대응 관계

JSX의 진짜 힘은 데이터 구조와 UI 구조 사이의 대응 관계를 직관적으로 표현할 수 있다는 점에 있다.

const TodoList = ({ todos }) => (
  <ul>
    {todos.map(todo => (
      <TodoItem 
        key={todo.id} 
        text={todo.text} 
        completed={todo.completed} 
      />
    ))}
  </ul>
);

이 코드를 보면 todos 배열의 각 항목이 TodoItem 컴포넌트와 대응된다는 관계가 즉시 읽힌다. 데이터의 구조가 곧 UI의 구조가 되는 것이다.

같은 동작을 명령형으로 작성하면 이렇게 된다.

function createTodoList(todos) {
  const ul = document.createElement('ul');
  
  for (let i = 0; i < todos.length; i++) {
    const li = document.createElement('li');
    li.textContent = todos[i].text;
    if (todos[i].completed) {
      li.classList.add('completed');
    }
    ul.appendChild(li);
  }
  
  return ul;
}

명령형 코드에서는 데이터 순회, 요소 생성, 속성 설정, DOM 추가 등의 절차적 단계들이 섞여 있다. 데이터의 구조와 최종 UI의 구조 사이의 관계를 파악하려면 전체 코드를 읽고 머릿속으로 실행해봐야 한다.

구조적 관계의 표현

JSX는 수학에서 집합의 관계를 표현하는 것과 비슷하다. 수학에서 $A = \{a, b, c\}$ 라고 쓸 때, 우리는 집합 $A$ 가 원소 $a, b, c$ 로 구성된다는 관계를 선언한다. 이 관계는 원소들을 어떤 순서로 집합에 넣었는지와는 무관하다.

JSX도 마찬가지다. 아래와 같은 코드를 쓸 때, 우리는 ”UserCard는 Avatar와 UserInfo로 구성된다”는 구조적 관계를 선언한다. 이 관계는 컴포넌트들이 어떤 순서로 렌더링되는지와는 개념적으로 분리되어 있다.

// 구조적 관계의 선언
const UserCard = ({ user }) => (
  <div className="user-card">
    <Avatar src={user.avatar} />
    <UserInfo name={user.name} email={user.email} />
  </div>
);

즉, “사용자 카드는 아바타, 사용자 정보의 조합이다”라는 관계를 선언하는 것에만 집중하고 각 컴포넌트가 어떻게 구현되는지, 어떤 순서로 DOM에 추가되는지는 이 관계 선언과는 별개의 관심사다.

이런 관점에서 보면, JSX가 선언적인 이유는 복잡한 과정을 숨겨주는 것 뿐 아니라, 데이터와 UI 사이의 본질적 관계를 직접적으로 표현할 수 있게 해주기 때문이다.

JSX가 선언적인 이유를 이해했다면, 이제 한 가지 의문이 들 수 있다.

“그런데 JSX도 결국 createElement로 변환되고, React의 reconciliation도 절차적 코드 아닌가? 그럼 이게 정말 선언적인 건가?”

선언적과 절차적은 상대적이다

이는 추상화나 선언적인 프로그래밍을 이해할 때 매우 핵심적인 부분인데, 이 개념들을 절대적인 무언가로 이해하면 치명적인 오개념이 생길 수 있다.

실제로는 같은 코드라도 관찰하는 관점과 추상화 레벨에 따라 선언적일 수도, 절차적일 수도 있다. “선언적”과 “절차적”은 절대적인 구분이 아니라 상대적인 개념이다.

React Query를 사용한 예시로 이런 상대성을 살펴보자.

// 애플리케이션 레벨 - 선언적
function useUserData(userId) {
  return useQuery(['user', userId], () => fetchUser(userId));
}

function UserProfile({ userId }) {
  const { data: user, isLoading, error } = useUserData(userId);
  
  if (isLoading) return <div>로딩 중...</div>;
  if (error) return <div>에러가 발생했습니다</div>;
  
  return <div>{user.name}</div>;
}

애플리케이션 개발자의 관점에서 보면 이 코드는 완전히 선언적이다. ”userId에 해당하는 사용자 데이터를 가져오는 쿼리”라는 관계를 선언하고 있다. 캐싱, 재시도, 에러 처리 같은 복잡한 로직은 모두 추상화되어 있다.

하지만 useQuery의 핵심 로직인 QueryClient를 구현하는 코드는 절차적이다. 캐시 확인, 네트워크 요청, 상태 업데이트, 재시도 로직 등 복잡한 절차적 과정들이 모두 드러나 있다.

이런 상대성은 도메인 경계에서 특히 명확하게 드러난다. 비즈니스 로직 레벨에서 주문을 처리하는 함수를 보면 이렇다.

// 비즈니스 로직 레벨 - 선언적
async function processOrder(order) {
  const validatedOrder = await validateOrder(order);
  const payment = await processPayment(validatedOrder);
  const shipment = await scheduleShipment(validatedOrder);
  
  return createOrderConfirmation(validatedOrder, payment, shipment);
}

이 함수는 비즈니스 로직 관점에서는 선언적이다. “주문을 검증하고, 결제를 처리하고, 배송을 스케줄링한다”는 관계를 명확히 표현한다. 하지만 그 아래 결제 처리 같은 인프라 레벨 함수들은 절차적이다.

// 인프라 레벨 - 절차적
async function processPayment(order) {
  const paymentGateway = new PaymentGateway(process.env.PAYMENT_API_KEY);
  
  try {
    const paymentRequest = {
      amount: order.total,
      currency: order.currency,
      source: order.paymentMethod
    };
    
    const response = await paymentGateway.charge(paymentRequest);
    
    if (response.status === 'succeeded') {
      await database.payments.create({
        orderId: order.id,
        paymentId: response.id,
        amount: response.amount,
        status: 'completed'
      });
      
      return { success: true, paymentId: response.id };
    } else {
      throw new PaymentError(response.error);
    }
  } catch (error) {
    await logger.error('Payment processing failed', { orderId: order.id, error });
    throw error;
  }
}

이처럼 선언적이라는 개념은 어떤 계층에서 바라보냐에 따라 상대적일 수 밖에 없다. 결국 선언적인 코드의 포인트는 절차적으로 작성된 부분을 얼마나 덜 확인할 수 있도록 추상화된 부분을 잘 표현해주는 것이냐에 따라 달려있다.

또한 “절차적 코드는 나쁘고 무조건 피해야 할 것”이라는 편견도 흔히 볼 수 있는데, 이 역시 잘못된 생각이다. 가장 우아한 함수형 코드도 결국 CPU의 절차적 명령어로 실행되기 때문이다.

중요한 것은 적절한 레벨에서 적절한 추상화를 제공하는 것이다.

이런 상대성을 이해하면 각 레벨에서 적절한 추상화를 찾는 것이 중요하다는 것을 알 수 있다. 모든 것을 선언적으로 만들려고 할 필요는 없다. 비즈니스 로직 레벨에서는 선언적으로 접근하는 것이 좋다. 도메인의 본질적 관계를 표현하는 데 집중해야 하기 때문이다. 반면 인프라 레벨에서는 절차적이어도 괜찮다. 효율적이고 안전한 구현이 더 중요하기 때문이다.

핵심은 경계를 명확히 하고 추상화의 레벨을 맞춰주는 것이다. 어느 레벨에서 어떤 관심사를 다루는지 분명히 구분해야 한다. 좋은 예를 보면, 비즈니스 레벨에서는 선언적으로 쇼핑카트의 구조를 표현하고, 인프라 레벨에서는 절차적인 계산 로직을 사용해도 문제없다.

// 좋은 예: 명확한 레벨 분리

// 비즈니스 레벨 - 선언적
const ShoppingCart = ({ items, onCheckout }) => (
  <div className="shopping-cart">
    <ItemList items={items} />
    <TotalPrice items={items} />
    <CheckoutButton onClick={() => onCheckout(items)} />
  </div>
);

// 프레젠테이션 레벨 - 선언적
const ItemList = ({ items }) => (
  <ul className="item-list">
    {items.map(item => (
      <ItemCard key={item.id} item={item} />
    ))}
  </ul>
);

// 인프라 레벨 - 절차적이어도 OK
function calculateTotalWithTax(items, taxRate) {
  let subtotal = 0;
  
  for (const item of items) {
    subtotal += item.price * item.quantity;
  }
  
  const tax = subtotal * taxRate;
  return subtotal + tax;
}

이런 관점에서 보면, 선언적 프로그래밍은 “모든 코드를 선언적으로 만드는 것”이 아니라 “적절한 추상화 레벨에서 적절한 표현력을 갖는 것”이라고 할 수 있다.

선언적인 코드라고 착각하는 코드 vs 진짜 선언적인 코드

이제 앞서 제기한 핵심 질문인 “왜 특정 코드가 선언적인가?”에 구체적으로 답해보자. 선언적 코드의 핵심은 “가능한 상태들 간의 관계”를 명확히 정의하는 것이다.

수학에서 함수의 정의역을 명확히 하는 것처럼, 프로그램에서도 “어떤 상태 조합이 논리적으로 가능한가”를 먼저 선언해야 한다.

비동기 데이터 요청을 생각해보면, 실제로는 아직 시작하지 않음(idle), 요청 중(loading), 성공(데이터 있음), 실패(에러 있음) 같은 상태들만 논리적으로 가능하다. “로딩 중이면서 동시에 데이터도 있고 에러도 있는” 상태는 현실에서는 일어날 수 없는 모순된 조합이다.

React + TypeScript 환경에서 비동기 데이터를 다루는 상황을 통해 이런 선언적 사고의 본질을 구체적으로 살펴보자.

착각하는 코드 - 상태 변화 과정에 집중

절차적 접근으로 작성된 비동기 데이터 훅을 보면 상태가 어떻게 변하는지에 집중하고 있다.

// 절차적 접근 - 상태가 어떻게 변하는지에 집중
function useAsyncData<T>(fetcher: () => Promise<T>) {
  const [data, setData] = useState<T | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    // 1단계: 로딩 상태로 전환
    setLoading(true);
    setError(null);
    setData(null);

    fetcher()
      .then(result => {
        // 2단계: 성공 상태로 전환
        setData(result);
        setLoading(false);
      })
      .catch(err => {
        // 3단계: 에러 상태로 전환
        setError(err.message);
        setLoading(false);
        setData(null);
      });
  }, [fetcher]);

  return { data, loading, error };
}

선언적인 코드 - 상태 관계에 집중

선언적 접근으로 작성하면 가능한 상태가 무엇인지에 집중한다.

// 선언적 접근 - 가능한 상태가 무엇인지에 집중
type AsyncDataState<T> = 
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: string };

function useAsyncData<T>(fetcher: () => Promise<T>): AsyncDataState<T> {
  const [state, setState] = useState<AsyncDataState<T>>({ status: 'idle' });

  useEffect(() => {
    setState({ status: 'loading' });
    
    fetcher()
      .then(data => setState({ status: 'success', data }))
      .catch(error => setState({ status: 'error', error: error.message }));
  }, [fetcher]);

  return state;
}

왜 첫 번째 코드가 절차적인가?

첫 번째 코드는 상태 변화의 순서와 과정에 집중한다. “먼저 로딩을 true로 설정하고, 에러를 null로 초기화하고, 데이터를 null로 리셋하고…” 같은 절차적 명령의 나열이다.

더 중요한 문제는 불가능한 상태 조합이 타입 수준에서 허용된다는 점이다. TypeScript가 { data: someUserData, loading: true, error: "Network Error" }라는 말이 안 되는 상태를 막아주지 못한다. 데이터가 있으면서 동시에 로딩 중이고 에러도 있다는 것은 논리적으로 모순이다. 하지만 첫 번째 방식에서는 개발자가 모든 상태 조합의 유효성을 수동으로 보장해야 한다.

각 setState 호출마다 다른 상태들을 올바르게 초기화했는지 일일이 확인해야 하고, 이는 휴먼 에러로 이어지기 쉽다. 예를 들어 성공 시에 setLoading(false)를 깜빡하거나, 에러 시에 setData(null)을 빼먹을 수 있다.

두 번째 코드는 왜 선언적인가?

두 번째 코드는 “비동기 데이터 요청”이라는 도메인의 본질적 상태 관계를 선언한다. Union Type을 통해 “이 네 가지 상태 중 정확히 하나만 존재할 수 있다”는 불변적 관계를 타입 수준에서 표현한다.

여기서 핵심은 불가능한 상태를 원천적으로 차단한다는 점이다. TypeScript 컴파일러가 로딩 중이면서 동시에 성공 상태 같은 모순된 조합을 컴파일 타임에 방지해준다. 이는 수학에서 집합의 정의역을 명확히 하는 것과 같은 원리다. $f: A \rightarrow B$ 에서 $A$ 는 함수 $f$ 의 정의역이고, $A$ 에 속하지 않는 값에 대해서는 $f$ 가 정의되지 않는다.

Union Type이 제공하는 안전장치를 더 구체적으로 살펴보면, TypeScript가 컴파일 타임에 강제하는 안전성을 확인할 수 있다.

// TypeScript가 컴파일 타임에 강제하는 안전성
function handleAsyncState<T>(state: AsyncDataState<T>) {
  switch (state.status) {
    case 'idle':
      return "아직 시작하지 않음";
    
    case 'loading':
      return "로딩 중...";
      // 여기서 state.data나 state.error 접근 시 컴파일 에러
    
    case 'success':
      return `데이터: ${state.data}`;
      // 여기서는 state.data가 확실히 존재
      // state.error 접근 시 컴파일 에러
    
    case 'error':
      return `에러: ${state.error}`;
      // 여기서는 state.error가 확실히 존재
      // state.data 접근 시 컴파일 에러
    
    default:
      // TypeScript가 모든 case를 다뤘는지 검증
      const exhaustiveCheck: never = state;
      return exhaustiveCheck;
  }
}

각 case에서는 해당 상태에서만 유효한 속성에만 접근할 수 있고, 다른 속성에 접근하려고 하면 컴파일 에러가 발생한다. 또한 default 케이스의 never 타입을 통해 모든 경우를 다뤘는지 컴파일러가 검증해준다.

컴포넌트에서 사용할 때의 차이

첫 번째 방식을 사용하면 개발자가 모든 조합을 수동으로 처리해야 한다.

// 첫 번째 방식 - 모든 조합을 수동으로 처리
function DataDisplay<T>({ fetcher, render }: { 
  fetcher: () => Promise<T>; 
  render: (data: T) => React.ReactNode; 
}) {
  const { data, loading, error } = useAsyncData(fetcher);

  // 개발자가 모든 경우의 수를 수동으로 고려해야 함
  if (loading && !error && !data) return <LoadingSpinner />;
  if (error && !loading) return <ErrorMessage error={error} />;
  if (data && !loading && !error) return render(data);
  
  // 예상치 못한 상태 조합들은 어떻게 처리할까?
  // { loading: true, data: someData, error: null } 같은 경우는?
  return <div>알 수 없는 상태</div>;
}

반면 두 번째 방식을 사용하면 타입이 모든 경우를 보장한다.

// 두 번째 방식 - 타입이 모든 경우를 보장
function DataDisplay<T>({ fetcher, render }: { 
  fetcher: () => Promise<T>; 
  render: (data: T) => React.ReactNode; 
}) {
  const state = useAsyncData(fetcher);

  // TypeScript가 모든 case를 처리했는지 검증
  switch (state.status) {
    case 'idle':
      return <div>준비 중...</div>;
      
    case 'loading':
      return <LoadingSpinner />;
      
    case 'success':
      // state.data가 확실히 T 타입으로 존재
      return render(state.data);
      
    case 'error':
      // state.error가 확실히 존재
      return <ErrorMessage error={state.error} />;
      
    // TypeScript가 모든 case를 다뤘는지 컴파일 타임에 검증
    // 새로운 상태가 추가되면 컴파일 에러로 알려줌
  }
}

TypeScript가 모든 case를 처리했는지 검증하고, 각 case에서 해당 속성이 확실히 존재함을 보장한다. 새로운 상태가 추가되면 컴파일 에러를 통해 놓친 부분을 알려준다.

확장성 측면에서의 차이

새로운 상태를 추가해야 하는 상황을 생각해보자. 첫 번째 방식에서는 여러 변수를 모두 수정해야 한다.

// 첫 번째 방식 - 여러 변수를 모두 수정해야 함
const [retrying, setRetrying] = useState(false);
const [stale, setStale] = useState(false);

// 각 상태 변화마다 다른 모든 상태들과의 조합을 고려해야 함
// 16가지 boolean 조합 중 논리적으로 말이 되는 것은 몇 개일까?

반면 두 번째 방식에서는 타입 정의만 확장하면 된다.

// 두 번째 방식 - 타입 정의만 확장
type AsyncDataState<T> = 
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'retrying'; previousError: string; attempt: number }
  | { status: 'success'; data: T; stale?: boolean }
  | { status: 'error'; error: string };

// TypeScript가 모든 사용처에서 새로운 case 처리를 강제
// 컴파일 에러를 통해 놓친 부분을 알려줌

새로운 상태를 추가하면 TypeScript가 모든 사용처에서 새로운 case를 처리하도록 강제한다. 컴파일 에러를 통해 놓친 부분을 확실히 알려주기 때문에 안전하게 확장할 수 있다.

이 예시에서 보는 선언적 사고의 핵심은 “무엇이 가능한가”를 먼저 정의하는 것이다. 수학에서 함수의 정의역과 치역을 명확히 하는 것처럼, 비동기 요청의 가능한 상태들을 명시적으로 선언한다.

절차적 접근은 “어떻게 상태를 변경할 것인가”에 집중하지만, 선언적 접근은 “이 문제 도메인에서 어떤 상태들이 논리적으로 가능한가”를 먼저 선언한다. 이런 관점 전환이 바로 선언적 프로그래밍의 본질이다.

실무 적용 가이드라인

이제 앞서 살펴본 이론을 실무에 적용할 수 있는 구체적인 기준을 정리해보자. 언제 절차적 접근을 택하고 언제 선언적 접근을 택할 것인가에 대한 실용적 가이드라인이다.

언제 선언적 접근을 해야 하는가?

비즈니스 로직과 상태 관리에서는 선언적 접근이 유리하다.

앞서 다룬 비동기 데이터 상태 예시처럼, 복잡한 상태 조합이 가능한 경우에는 타입 수준에서 불가능한 상태를 차단하는 것이 중요하다:

// 앞서 다룬 AsyncDataState 예시 재활용
type AsyncDataState<T> = 
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: string };

UI 구조 표현에서도 선언적 접근이 자연스럽다. JSX 예시에서 봤듯이 데이터와 UI 사이의 구조적 관계를 직접 표현할 수 있다:

// JSX 예시 재활용 - 구조적 관계를 명확히 선언
const UserProfile = ({ user }) => (
  <div className="user-profile">
    <h2>{user.name}</h2>
    <p>{user.email}</p>
    {user.avatar && <img src={user.avatar} alt={`${user.name}의 아바타`} />}
  </div>
);

데이터 변환 파이프라인에서도 각 단계가 독립적으로 정의되고 테스트 가능할 때 선언적 접근이 효과적이다:

// 변환 관계를 명확히 선언
const processUserData = (rawUsers: RawUser[]) =>
  rawUsers
    .filter(isActiveUser)
    .map(normalizeUserData)
    .map(addComputedFields)
    .sort(byLastLoginDate);

언제 절차적 접근을 해도 되는가?

인프라 레벨과 성능 최적화에서는 절차적 접근이 적절하다.

앞서 상대성 섹션에서 다룬 계산 로직처럼, 효율성과 성능이 중요한 경우에는 절차적 구현이 자연스럽다:

// 앞서 다룬 계산 로직 예시 재활용
function calculateTotalWithTax(items, taxRate) {
  let subtotal = 0;
  
  for (const item of items) {
    subtotal += item.price * item.quantity;
  }
  
  const tax = subtotal * taxRate;
  return subtotal + tax;
}

React Query 내부 구현처럼 복잡한 상태 관리와 최적화가 필요한 라이브러리 코드에서도 절차적 접근이 필요하다. 캐시 확인, 네트워크 요청, 상태 업데이트, 재시도 로직 등은 절차적으로 구현하는 것이 효율적이다.

에러 처리가 복잡한 시스템 레벨 코드에서도 절차적 접근이 적합하다:

// 복잡한 에러 처리와 재시도 로직
async function retryWithBackoff<T>(
  operation: () => Promise<T>,
  maxAttempts: number = 3
): Promise<T> {
  let lastError: Error;
  
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await operation();
    } catch (error) {
      lastError = error as Error;
      
      if (attempt === maxAttempts) {
        throw lastError;
      }
      
      const delay = Math.pow(2, attempt - 1) * 1000;
      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }
  
  throw lastError!;
}

마치며

선언적 프로그래밍은 단순히 특정 문법이나 도구를 사용하는 것이 아니다. 그것은 “어떻게”에서 “무엇”으로, 절차에서 관계로 사고하는 방식의 전환이다.

이번 포스팅에서 다룬 핵심 내용을 정리해보면, 선언적 프로그래밍의 본질은 관계적 사고에 있다. 시간적 순서가 아닌 논리적 관계에 집중하는 것이다. 또한 상태 모델링을 통해 가능한 상태를 먼저 선언하고 불가능한 상태를 원천 차단하는 것이 중요하다. 적절한 추상화를 통해 각 레벨에서 적합한 표현력을 제공해야 하며, 이는 절대적 구분이 아닌 관점과 레벨에 따른 상대적 개념이라는 점을 이해해야 한다.

진정한 선언적 코드의 특징을 보면, 비즈니스 의도가 코드 구조에서 직접 읽힌다. 기술적 복잡성은 적절한 추상화 뒤로 숨겨지고, 각 부분이 독립적으로 이해 가능하면서도 안전하게 합성된다. 그리고 불가능한 상태가 타입 수준에서 방지된다.

선언적 프로그래밍은 하루아침에 습득할 수 있는 기술이 아니다. 하지만 꾸준히 연습하고 적절한 추상화 레벨을 찾아가는 과정에서, 더 읽기 쉽고 유지보수하기 쉬운 코드를 작성할 수 있게 될 것이다.

코드는 컴퓨터를 위한 것이 아니라 사람을 위한 것이다. 선언적 프로그래밍은 바로 그 사람들이 복잡한 문제를 더 쉽게 이해하고 다룰 수 있게 도와주는 강력한 도구다.

선언적 프로그래밍은 도구가 아니라 사고방식이며, 문법이 아니라 철학이다. 이 철학을 이해하고 실무에 적용할 때, 우리는 더 나은 코드를 작성할 수 있게 된다.

Unconditional Respect for Diversity Is an Illusion: Wisdom from Buddhist Dependent Origination for Running Organizations

Sun, 06 Jul 2025 07:09:54 GMT

In modern organizations, “diversity” is treated as a given. The belief that people from diverse backgrounds create synergy and that different perspectives drive innovation has become common wisdom. In the tech industry especially, Diversity & Inclusion has established itself as a core keyword of organizational culture.

But when you actually work as a leader, you realize that these idealistic principles create surprisingly complex dilemmas. Should we unconditionally respect every kind of diversity? When an individual’s choices clash with the organization’s goals, what criteria should a leader use to make decisions?

In this post, I want to share a specific dilemma I faced while working as a chapter lead in a frontend organization of about 100 people, and the wisdom I found within the limits of respecting diversity.

Along the way, I’ll explore how Buddhist philosophy, particularly dependent origination and the Middle Way, can offer practical insights for running modern organizations.

Where the dilemma begins

As a leader striving to build an excellent organization, I need to support and encourage my team members’ growth. But with 100 people in the group, there are inevitably those who think differently.

Recently, one team member sent me into deep contemplation. They had outstanding technical skills, executed their current responsibilities flawlessly, and earned the trust of their colleagues. From my perspective, they’d be a perfect fit for a lead role. But they declined any such additional responsibility.

Whenever I suggested new challenges for their growth, they would calmly respond:

“I’m not really thinking about that right now.”

“I’d rather focus on other things.”

If they had been underperforming while also refusing to grow, it would have been a clear-cut problem. But the fact that they were already doing excellent work made it all the more ambiguous.

This experience raised fundamental questions for me:

“Is it right to set higher goals for someone who’s already doing well enough?”

And: “How far should the principle of respecting individual diversity and choice extend?”

I’m sure many of you have wrestled with similar dilemmas. Facing this kind of situation, we tend to oscillate between two extremes: “We must unconditionally respect diversity” on one side, and “The organization’s goals require uniformity” on the other.

Through this experience, I realized I needed a perspective beyond these binary choices. What traps might be hiding within the notion of “respecting diversity” that we so readily take for granted?

The trap of respecting diversity

As I dug deeper into this issue, I realized that diversity is often approached in a binary way — people tend to simply divide it into either respecting diversity or not.

But reality isn’t that simple. Respecting diversity isn’t an absolute principle; it should be approached as a question of how much an organization or society can accommodate given its specific characteristics.

This connects to the truth revealed by the Buddhist concept of dependent origination (pratītyasamutpāda). Because all phenomena exist in mutual dependence, neither absolute freedom nor absolute control is possible. (I know bringing up Buddhism out of nowhere might seem surprising, but the stories from Buddhist teachings actually offer a great deal of life wisdom.)

Take the South Korean constitution as an example. South Korea is a democracy that guarantees its citizens’ freedom, yet Article 8 of the constitution allows for the dissolution of political parties under certain conditions. This means that when elements threaten the basic democratic order, freedom cannot be granted without limits. In other words, even the state doesn’t unconditionally respect all forms of diversity.

The same principle applies to organizations. Should a company tolerate an employee who doesn’t keep regular working hours or insists on working from home despite an uncooperative attitude, simply because “we respect diversity”? Diversity deserves respect, but when it conflicts with the organization’s operations and objectives, limits are inevitable.

Through these observations, I arrived at a conclusion: unconditional respect for diversity is an illusion that cannot exist.

So is diversity always a bad thing? Of course not. Diversity clearly has both light and shadow.

The light and shadow of diversity

The positive effects of diversity are real. When team members with varied backgrounds come together, new ideas emerge and more approaches to problem-solving open up. Working in a frontend organization of about 100 people, I’ve met an incredible variety of developers and collaborated closely with non-developer colleagues. Through this, I’ve felt the synergy created when talented, diverse people come together.

But diversity doesn’t always produce positive outcomes. As differences in opinion grow, the time and energy required for coordination increase exponentially, and team cohesion can weaken in the process. As Buddhist dependent origination teaches, because all phenomena are interdependent, a change in one element can have unexpected effects on the entire system.

Understanding this dual nature of diversity allowed me to look at the team member I mentioned earlier from a new angle.

Anattā (non-self) and the possibility of change

Reflecting more deeply on this team member, I was reminded of the Buddhist concept of anattā — non-self. Individual diversity is not a fixed, unchanging attribute; it shifts constantly. Just because that team member doesn’t want to grow right now doesn’t mean they never will.

As a leader, I’ve always tried to present higher-level goals to my team members. This wasn’t merely about driving performance — it came from a genuine desire to draw out each person’s potential and help them grow as professionals. But through this process, I reached a conclusion: growth cannot be forced. You can propose growth, but the final decision and responsibility belong to the individual.

Ultimately, I realized that what’s needed is the wisdom to respect someone’s choice in the present moment while keeping the door open for change and waiting patiently.

But simply waiting isn’t the answer either. As a leader, I also needed concrete principles for how to communicate and act.

Wisdom from the Noble Eightfold Path: right communication

What helped me here was the Buddhist Noble Eightfold Path — the eight practices the Buddha prescribed as the path to enlightenment.

Among these, Right Speech and Right Action clearly illustrate the principles a leader should follow when communicating with team members.

Right Speech means avoiding lies, divisive talk, harsh words, and idle chatter, and instead speaking truthfully and helpfully. Right Action means behaving in ways that don’t harm yourself or others.

When proposing growth, it’s crucial to use truthful, constructive language rather than criticism or coercion, and to act in ways that benefit both the individual and the organization. The key isn’t pushing some abstract goal of “getting better” — it’s concretely showing what that growth means and what positive impact it can have.

But when you try to put these principles into practice, you inevitably face another complex problem: how to balance your own values as a leader with your team members’ diverse perspectives.

Leadership through compassion and skillful means

This dilemma resembles the clash of political ideologies. Progressive and conservative — each has its own strengths and weaknesses. It’s not a matter of right versus wrong, but a difference in which direction to pursue. The same goes for organizational culture. Even if I hold certain beliefs and values as a leader, is it justified to impose them on my team? Yet if I allow total freedom in everything, the organization may descend into chaos.

In Buddhism, compassion (karuṇā) isn’t mere sympathy. It’s genuinely helping others find true well-being. I believe my desire for my team members’ growth is an expression of this same compassion. And through the wisdom of skillful means (upāya), different approaches should be used for each person based on their situation and disposition.

Rather than applying the same yardstick to everyone, it’s about understanding individual contexts and finding the appropriate method for each.

As I examined these various Buddhist principles, I realized they all converge on a single core idea: balance.

The Middle Way

In the end, just as respecting diversity matters, so does maintaining certain standards and order to achieve organizational goals.

So how do you strike this balance? One conclusion I’ve reached from running my team is that “not all diversity must be unconditionally respected.” This doesn’t mean diversity should be restricted — it means diversity should be channeled in a direction consistent with the organization’s fundamental purpose.

As a leader, I strive to provide a safe environment where team members’ diversity is respected, while also setting clear standards and guidelines for effective collaboration. From a Buddhist perspective, a leader is both someone who supports team members in growing at their own pace and in their own way, and someone who sets direction and guides them toward it.

Balancing these two roles isn’t easy, but I think it’s the Middle Way that yields the best results for both the organization and the individual.

Closing thoughts

Diversity is an essential ingredient for organizational growth. But it’s the leader’s job to ensure it doesn’t breed conflict and inefficiency. I’ll keep thinking about how to set the right standards while respecting my team’s diversity.

As the Buddha taught: “Don’t follow the mind, teach the mind.” I want to keep that in mind as I navigate between individual diversity and organizational objectives.

무조건적 다양성 존중은 허상이다: 연기법(緣起法)으로 본 조직 운영의 지혜

Sun, 06 Jul 2025 07:09:54 GMT

현대 조직에서 ‘다양성’은 거의 신성불가침의 가치로 여겨진다. 다양한 배경을 가진 사람들이 모여 시너지를 만들어내고, 서로 다른 관점이 혁신을 이끌어낸다는 믿음은 이제 상식이 되었다. 특히 IT 업계에서는 다양성과 포용성(Diversity & Inclusion)이 조직 문화의 핵심 키워드로 자리잡았다.

하지만 현실에서 리더로 일하다 보면, 이런 이상적인 원칙들이 생각보다 복잡한 딜레마를 만들어낸다는 것을 깨닫게 된다. 과연 모든 종류의 다양성을 무조건 존중해야 하는 것일까? 개인의 선택과 조직의 목표가 충돌할 때, 리더는 어떤 기준으로 판단해야 할까?

이번 글에서는 필자가 100명 규모의 프론트엔드 조직에서 챕터 리드로 일을 하면서 마주한 구체적인 딜레마를 통해, 다양성 존중의 한계와 그 속에서 찾은 지혜에 대한 이야기를 해보려고 한다.

그리고 이 과정에서 불교 철학, 특히 연기법과 중도 사상이 어떻게 현대 조직 운영에 실질적인 통찰을 제공할 수 있는지 살펴볼 것이다.

딜레마의 시작

리더로서 탁월한 조직을 만들기 위해서는 구성원들의 성장을 지원하고 독려해야하지만 100명이나 되는 사람이 모여있다 보니 구성원들 중에서 생각이 다른 사람도 있을 수밖에 없다.

최근 필자를 깊은 고민에 빠뜨린 팀원이 있었다. 그 분은 기술적으로 출중한 역량을 가지고 있었고, 현재 맡은 업무를 완벽하게 수행했으며, 동료들로부터도 신뢰를 받는 사람이었다. 그래서 필자가 볼 때는 리드를 하면 딱 좋을 것 같은데 이러한 추가적인 역할은 거부했다.

필자가 성장을 위한 새로운 도전을 제안하면 그 분은 담담하게 이렇게 답했다.

“지금은 딱히 생각이 없어요.”

“다른 것에 집중하고 싶어서요.”

만약 그 분이 역량이 부족하면서 성장도 하지 않는다면 명확히 문제가 되겠지만, 이미 잘하고 있는 사람이라서 더욱 애매했다.

이 경험은 필자에게 근본적인 질문들을 던졌다.

“충분히 잘 하고 있는 사람에게 더 높은 목표를 제시하는 것이 과연 옳은가?”

그리고 “개인의 다양성과 선택을 존중해야 한다는 원칙은 어디까지 적용되어야 하는가?”

독자 여러분도 비슷한 고민을 해본 적이 있을 것이다. 이런 딜레마 앞에서 우리는 흔히 두 가지 극단적인 선택지 사이에서 헤매게 된다. 하나는 “다양성을 무조건 존중해야 한다”는 입장이고, 다른 하나는 “조직의 목표를 위해서는 통일성이 필요하다”는 입장이다.

이 경험을 통해 필자는 이런 극단적 선택지를 넘어서는 새로운 관점이 필요하다는 것을 깨달았다. 그 팀원의 상황을 더 깊이 들여다보면서, 다양성이라는 개념 자체를 보다 세밀하게 살펴볼 필요가 있다는 생각이 들었다. 과연 우리가 흔히 당연하게 여기는 다양성 존중이라는 개념에는 어떤 함정이 숨어있을까?

다양성 존중의 함정

이 문제를 깊이 들여다보면서, 필자는 다양성이라는 개념이 흔히 이분법적으로 접근되는 경우가 많다는 것을 깨달았다. 즉, 다양성을 존중하는 것과 하지 않는 것으로 단순히 나누려는 시각이 존재한다는 것이다.

하지만 현실은 그렇게 단순하지 않으며, 다양성을 존중해야 한다는 것은 절대적인 원칙이 아니라 조직이나 사회의 특성에 따라 어느 정도까지 포용할 수 있는가의 문제로 접근해야 한다.

이는 불교의 연기법(緣起法)이 보여주는 진리와 맞닿아 있다. 모든 현상은 서로 의존하며 존재하기 때문에, 절대적인 자유나 절대적인 통제 모두 불가능하다는 것이다. (뜬금없이 불교 얘기를 해서 당황스럽겠지만, 의외로 불교에서 말하는 에피소드들이 삶의 지혜를 많이 알려준다)

대한민국의 헌법을 예로 들어보자. 대한민국은 국민의 자유를 보장하는 민주주의 국가이지만, 헌법 제8조에서는 특정 조건에 따라 위헌 정당을 해산할 수 있도록 하고 있다. 이는 민주적 기본 질서를 위협하는 요소가 있을 경우, 자유를 무제한으로 허용할 수 없다는 것을 의미한다. 즉, 국가조차도 모든 다양성을 무조건적으로 존중하지는 않는다는 것이다.

이와 같은 원리는 조직에도 동일하게 적용된다. 예를 들어, 회사가 다양성을 존중해야 한다는 이유만으로 정해진 근무 시간을 지키지 않거나, 업무 태도가 성실하지 않음에도 불구하고 재택근무만을 주장하는 직원까지 포용해야 할까? 다양성은 존중받아야 하지만, 그것이 조직의 운영과 목표에 부합하지 않을 때는 결국 제한될 수밖에 없다.

이러한 관찰을 통해 필자는 무조건적인 다양성 존중이라는 것은 존재할 수 없는 허상이라는 결론에 도달했다.

그렇다면 다양성은 정말 무조건 나쁜 것일까? 물론 그런 것은 아니다. 다양성에는 분명히 빛과 그림자가 공존한다.

다양성의 빛과 그림자

물론 다양성이 우리에게 선물해주는 긍정적인 효과는 분명하다. 다양한 배경과 사고 방식을 가진 팀원들이 모였을 때, 새로운 아이디어가 탄생하고, 문제를 해결하는 데 있어 더 많은 접근법을 시도할 수 있다는 것이다. 필자가 100명 규모의 프론트엔드 조직에서 일하면서 평소 굉장히 다양한 개발자들을 만나고, 개발자가 아닌 동료들과도 밀접한 협업을 수행하는 과정에서 탁월한 역량을 가진 다양한 사람들이 모여 만들어내는 시너지를 느낄 수 있었다.

하지만 이러한 다양성이 항상 긍정적인 결과만을 가져오는 것은 아니다. 의견 차이가 커질수록 조율에 드는 시간과 에너지가 기하급수적으로 증가하며, 이 과정에서 팀의 결속력이 약해지기도 한다. 이는 불교의 연기법이 보여주는 바와 같이, 모든 현상이 상호의존적이기 때문에 한 요소의 변화가 전체 시스템에 예상치 못한 영향을 미칠 수 있음을 의미한다.

다양성의 이런 양면성을 이해하고 나니, 앞서 언급한 팀원에 대한 고민도 새로운 시각에서 바라볼 수 있게 되었다.

무아(無我)와 성장의 변화 가능성

앞서 언급한 팀원에 대한 고민을 더 깊이 생각해보면서, 필자는 불교의 무아(無我) 사상을 떠올리게 되었다. 개인의 다양성이라는 것도 고정불변한 속성이 아니라 끊임없이 변화하는 것이다. 그 팀원이 현재 성장을 원하지 않는다고 해서 미래에도 그럴 것이라고 단정할 수는 없다.

필자는 리더로서 항상 팀원들에게 더 높은 수준의 목표를 제시하려고 노력해왔다. 이는 단순히 성과를 내기 위한 것이 아니라, 각자가 가진 잠재력을 최대한 끌어내어 프로페셔널로서 더 성장하길 바라는 마음에서였다. 그러나 이 과정에서 “성장은 강요될 수 없는 것”이라는 결론에 도달했다. 성장을 제안할 수는 있지만, 그 선택의 최종 결정과 책임은 개인의 몫이라는 점을 깨달았다.

결국 필자는 이 순간의 선택을 존중하면서도, 변화의 가능성을 열어두고 인내심을 갖고 기다리는 지혜가 필요하다는 것을 깨달았다.

하지만 단순히 기다리기만 하는 것이 능사는 아니다. 리더로서 어떻게 소통하고 행동해야 하는지에 대한 구체적인 원칙도 필요했다.

팔정도(八正道)의 지혜: 올바른 소통

이때 필자에게 도움이 된 것은 불교의 팔정도(八正道) 사상이었다. 팔정도는 부처가 제시한 여덟 가지 올바른 수행 방법으로, 깨달음에 이르는 길을 구체적으로 제시한 것이다.

이 중에서도 정어(正語)와 정업(正業)은 리더가 팀원과 소통할 때 지켜야 할 원칙을 명확하게 보여준다.

정어(正語)는 “올바른 말”을 의미한다. 거짓말, 이간질, 욕설, 쓸데없는 말을 하지 않고, 진실하고 도움이 되는 말을 해야 한다는 것이다. 정업(正業)은 “올바른 행동”으로, 자신과 타인에게 해가 되지 않는 행동을 하라는 가르침이다.

성장을 제안할 때는 비난이나 강요가 아닌 진실하고 건설적인 언어를 사용해야 하며, 개인과 조직 모두에게 도움이 되는 방향으로 행동해야 한다는 점이 중요하다. 단순히 더 나아져야 한다는 추상적인 목표가 아니라, 그 성장이 어떤 의미를 가지며 어떤 긍정적 영향을 줄 수 있는지 구체적으로 보여주는 것이 핵심이다.

그런데 이런 원칙들을 실천하려고 하다 보면, 또 다른 복잡한 문제에 직면하게 된다. 바로 리더 자신의 가치관과 팀원들의 다양한 생각 사이에서 어떤 균형을 잡아야 하는가의 문제다.

자비(慈悲)와 방편(方便)의 리더십

이러한 고민은 정치적 이데올로기의 충돌과도 비슷하다. 진보와 보수, 각각의 이념적 차이는 고유한 강점과 약점을 가지고 있으며, 옳고 그름의 문제라기보다는 어떤 방향성을 추구하느냐의 차이일 뿐이다. 조직 문화도 마찬가지다. 리더로서 필자가 가진 신념과 가치가 있다고 해도 그것을 구성원들에게 강요하는 것이 과연 정당한가? 하지만 모든 것에 대한 자유를 허용하면 조직은 혼란스러워질 수 있다.

불교에서 말하는 자비(慈悲)는 단순한 동정이 아니라 상대방이 진정으로 행복해지도록 돕는 것이다. 필자가 팀원들의 성장을 바라는 마음도 이와 같은 자비심의 발현이라고 생각한다. 그리고 방편(方便)의 지혜를 통해, 각 개인의 상황과 성향에 맞는 다른 접근법을 사용하는 것이 필요하다.

모든 사람에게 동일한 잣대를 적용하는 것이 아니라, 개별적인 맥락을 이해하고 그에 맞는 방법을 찾아가는 것이다.

이렇게 여러 불교적 원칙들을 살펴보면서, 필자는 결국 이 모든 것이 하나의 핵심으로 수렴된다는 것을 깨달았다. 바로 “균형”이다.

중도(中道)의 균형

결국 다양성을 존중하는 것이 중요한 만큼, 조직의 목표와 성과를 달성하기 위해 일정 수준의 기준과 질서도 필요하다.

그렇다면 이 균형은 어떻게 잡아야 할까? 필자가 팀을 운영하며 내린 한 가지 결론은 “모든 다양성이 무조건 존중받아야 하는 것은 아니다”라는 것이다. 이 말은 다양성을 제한해야 한다는 뜻이 아니라, 조직의 본질적인 목적과 일치하는 방향에서 다양성이 활용되어야 한다는 의미다.

리더로서, 필자는 팀원들에게 다양성을 존중받을 수 있는 안전한 환경을 제공하는 동시에, 협업의 효율성을 위해 명확한 기준과 가이드를 제시하려고 노력한다. 불교의 관점에서 보면, 리더는 팀원들이 각자의 속도와 방식대로 성장하도록 지원하는 존재이기도 하며, 방향성을 제시하고 그것을 따라가도록 이끄는 존재이기도 하다.

이 두 가지 역할 간의 균형을 맞추는 것은 쉽지 않지만, 조직과 개인 모두에게 최선의 결과를 낼 수 있는 중도의 길이라고 생각한다. 마치 부처가 극단적 쾌락주의와 극단적 고행주의 사이에서 중도를 찾았듯이, 리더는 무조건적 다양성 존중과 일방적 통제 사이에서 균형점을 찾아야 한다.

마치며

다양성은 조직의 성장과 혁신을 위한 필수 요소다. 그러나 그것이 갈등과 비효율을 초래하지 않도록 균형을 잡는 것은 리더의 몫이다. 필자는 앞으로도 팀의 다양성을 존중하면서, 조직의 목표를 달성하기 위해 어떤 기준을 세워야 할지에 대해 꾸준히 고민할 것이다. 그리고 이 여정에서 얻은 통찰을 계속 나누고자 한다.

마치 부처가 가르친 것처럼, “마음을 따르지 말고 마음을 가르치라”는 지혜를 기억하며, 개인의 다양성과 조직의 목표 사이에서 지혜로운 선택을 계속해 나가고 싶다. 이것이 바로 현대 조직에서 필요한 불교적 리더십의 핵심이 아닐까 생각한다.

이상으로 연기법으로 본 조직 운영의 지혜 포스팅을 마친다.

[번역] 프로그래머를 위한 카테고리 이론 - 11. 선언적 프로그래밍

Wed, 25 Dec 2024 07:45:20 GMT

필자는 이 책의 첫 번째 파트에서 카테고리 이론과 프로그래밍이 모두 합성 가능성(Composability)에 대한 것이라는 주장을 하였다.

프로그래밍에서는 문제를 조금씩 세분화해나가며 다룰 수 있는 세부 수준으로 분해한 다음, 각 하위 문제를 해결하고, 하위 문제의 해결책들을 다시 합성하여 전체 문제를 해결하는 방식을 사용한다.

이를 수행하는 방법에는 크게두 가지 정도가 있다. 하나는 컴퓨터에게 무엇을 해야 하는지 알려주는 방법, 그리고 다른 하나는 어떻게 해야 하는 지를 알려주는 방법이다. 이때 전자는 선언형(Declarative), 후자는 명령형(Imperative)이라고 한다.

이 두 가지 방법의 차이는 가장 기본적인 수준에서도 확인이 가능하다. 먼저 선언적으로 h를 함수 f가 실행된 이후 g를 적용한 합성이라고 정의해보면 이렇게 된다.

h = g.f

혹은 명령적으로 정의해볼 수도 있다. 즉, 먼저 f를 호출하고 그 호출의 결과를 기억한 뒤, 그 결과를 사용해서 다시 g를 호출하는 것이다.

명령형 방식의 프로그램은 일반적으로 시간 순서대로 정렬된 일련의 작업들로 표현된다. 특히 이 방식에서는 명시적으로 g의 호출이 f의 실행이 완료되기 전에는 절대 발생할 수 없음이 표현된다. 그러나 지연 평가(lazy evaluation)와 call-by-need 방식의 인수 전달을 사용하는 언어에서는 실제 실행 순서가 다를 수 있다.

사실, 컴파일러의 최적화 수준에 따라 선언적 코드와 명령적 코드의 실행 방식에는 거의 차이가 없을 수도 있다. 하지만 이 두 가지 방법론은 때로 문제 해결 접근 방식과 결과 코드의 유지보수성 및 테스트 가능성에서 극명하게 다르다.

여기서 중요한 질문은 “우리가 문제를 풀 때 항상 선언적인 접근 방식과 명령적인 접근 방식 중 하나를 선택할 수 있는가? 그리고 만약 선언적인 해결책이 있다면 항상 컴퓨터 코드로 변환할 수 있는 것인가?”이다. 사실 이 질문에 대한 답은 아직 명확하게 나오지 않았으며, 만약 그 답을 찾을 수 있다면 아마 우리 우주에 대한 이해를 혁신적으로 바꿀 수 있을 것이다.

설명을 덧붙이자면, 물리학에서도 이와 유사한 이중성이 존재한다. 이는 심오한 근본 원칙을 가리키거나, 우리의 사고방식에 대해 무언가를 말해주는 것일 수 있다. 리처드 파인만은 자신의 양자 전기역학 연구에서 이 이중성이 영감의 원천이 되었다고 언급한 바 있다.

물리 법칙을 표현하는 데에는 두 가지 방식이 있다. 하나는 국소적(local) 또는 미소적(infinitesimal) 접근 방식을 사용하는 것이다. 이 접근 방식은 먼저 시스템의 작은 근방에서의 상태를 관찰하고, 다음 순간에 그것이 어떻게 변화할 지를 예측한다. 이러한 변화는 보통 미분 방정식을 사용하여 표현되며, 이를 일정 시간 동안 적분하거나 합산하여 최종 결과를 표현한다.

이는 이전 단계의 결과에 의존하는 각각의 작은 단계들을 거쳐 최종 해결책에 도달하는 명령형 사고방식과 유사하다.

실제로 물리적 시스템의 컴퓨터 시뮬레이션은 미분 방정식을 차분 방정식으로 변환하고 이를 반복 실행하는 방식으로 구현하는 경우가 많다. Asteroids 게임에서 우주선이 애니메이션화 되는 방식도 이와 동일하다.

각 시간 단계마다 우주선의 위치는 속도와 시간 델타를 곱하여 계산된 작은 증분을 더해가면서 변경된다. 속도는 다시 가속도에 비례하는 작은 증분을 더해 변경되며, 가속도는 힘을 질량으로 나눈 값이다.

이것은 사실 뉴턴의 운동 법칙에 해당하는 미분 방정식을 직접적으로 구현한 것이다.

F=m\frac{dv}{dt}\\ v=\frac{dx}{dt}

이외에도 맥스웰 방정식을 사용하여 전자기장의 전파를 분석하거나, 격자 양자색역학(lattice QCD)을 사용하여 양성자 내부에서 쿼크와 글루온의 행동을 설명하는 등 더 복잡한 문제에도 국소적 사고방식이 적용될 수 있다.

이러한 국소적 사고방식은 디지털 컴퓨터를 사용하여 공간과 시간을 이산화(discretization)하는 시도와 결합되어, 우주의 모든 복잡성을 간단한 셀룰러 오토마타 시스템으로 축소하려는 스티븐 울프람(Stephen Wolfram)과 같은 영웅이 등장하기도 했다.

💡 역주

셀룰러 오토마타는 격자 내부에 위치한 여러 개의 셀들이 간단한 규칙에 따라 유한 개의 상태로 변화할 수 있는 시스템이다. 대표적인 셀룰러 오토마타 중 하나로는 콘웨이의 생명 게임이 있으며, 이러한 시스템은 간단한 규칙이 생명과 같은 복잡한 패턴을 표현할 수 있음을 보여준다.

다른 접근법은 전역적(global) 접근 방법이다. 시스템의 초기 상태와 최종 상태를 확인한 뒤, 에너지, 시간, 거리와 같은 물리량을 최소한으로 사용하여 이 상태들을 연결할 수 있는 최적의 경로를 계산한다. 가장 간단한 예는 페르마의 최소 시간 원리이다.

이 원리는 빛이 비행 시간을 최소화하는 경로를 따라 전파된다는 것을 나타낸다. 그래서 반사나 굴절이 없는 경우, A 지점에서 B 지점으로 가는 빛은 가장 짧은 경로인 A와 B 사이의 직선 경로를 선택한다.

그러나 빛은 물이나 유리와 같은 밀도가 높은 투명 물질에서는 속도가 느려진다. 따라서 빛의 시작 지점이 공기 중에 있고 도착 지점이 물속에 있을 경우, 빛이 공기 중에서 이동하는 거리보다 물 속에서 이동하는 거리가 더 짧아져야 한다.

최소 시간을 따르는 경로는 빛이 공기와 물의 경계에서 굴절되도록 하며, 이는 스넬의 굴절 법칙(Snell’s Law of Refraction)으로 이어진다.

\frac{\sin(\theta_1)}{\sin(\theta_2)} = \frac{v_1}{v_2}

여기서 $v_1$ 은 공기 중에서의 빛의 속도이고, $v_2$ 는 물속에서의 빛의 속도이다.

고전 역학의 모든 법칙은 최소 작용 원리로부터 도출될 수 있다. 작용은 라그랑지안(Lagrangian)을 경로에 따라 적분하여 계산할 수 있으며, 라그랑지안은 운동 에너지와 위치 에너지의 차이를 나타낸다 (참고로 합(sum)이 아니라 차이(difference)다. 합은 총 에너지를 나타낸다).

우리가 특정 목표를 맞추기 위해 박격포를 발사하면, 포탄은 먼저 중력으로 인해 위치 에너지가 더 높은 곳으로 올라가고, 그 과정 속에서 점점 작용에 음의 기여를 축적한다. 그 후 포탄은 포물선의 꼭대기에서 속도를 줄여 운동 에너지를 최소화하고, 최종적으로는 위치 에너지가 낮은 구간을 빠르게 통과하기 위해 속도를 높인다.

리처드 파인만의 주요 기여 중 한 가지는 최소 작용 원리가 양자역학으로 일반화될 수 있음을 보여준 것이다. 이 경우에도 문제는 초기 상태와 최종 상태로 구성되며, 두 상태 사이의 전이 확률을 계산하기 위해 파인만 경로 적분(Feynman path integral)이 사용된다.

중요한 점은 물리 법칙을 설명하는 방식에 우열을 가리기 어려운 이중성이 존재한다는 것이다. 우리는 하나의 물리적 결과를 설명할 때 작은 일들이 순차적인 여러 단계로 나누어져 발생하는 국소적인 관점을 사용할 수도 있고, 초기 조건과 최종 조건을 선언한 뒤 그 사이에 무슨 일이 있었는지를 설명하는 전역적인 관점을 사용할 수도 있다.

전역적 접근법은 프로그래밍에서도 사용될 수 있다. 예를 들어 레이 트레이싱(ray tracing)을 구현할 때, 우리는 눈의 위치와 광원의 위치를 선언하고, 이들을 연결하는 광선의 경로를 계산한다. 이때 우리가 각 광선의 비행 시간을 명시적으로 최소화하지 않더라도, 스넬의 법칙(Snell’s law)과 반사의 기하학을 이용하여 동일한 효과를 얻을 수 있다.

국소적 접근법과 전역적 접근법의 가장 큰 차이점은 공간, 그리고 더 중요한 시간에 대한 처리 방식이다. 국소적 접근법은 “지금 이 순간”의 즉각적인 결과를 중시하지만, 전역적 접근법은 마치 미래가 이미 정해져 있는 것처럼 장기적이고 정적인 관점을 취하며, 우리가 영원한 우주의 속성을 분석하는 것과 같다.

이 점이 가장 잘 드러나는 곳은 사용자 상호작용에 대한 함수형 반응형 프로그래밍(Functional Reactive Programming, FRP) 접근법이다. FRP는 모든 이벤트에 대해 개별 핸들러를 작성하고 이들이 공유되는 가변 상태에 접근하도록 만드는 대신, 이벤트를 무한 리스트로 간주하고 이 이벤트에 대해 반응하는 특정한 변환을 적용한다.

이론적으로 미래에 발생할 모든 동작을 담은 무한 리스트는 프로그램의 입력 데이터로 사용할 수 있다. 사실 프로그램 관점에서는 𝜋의 숫자 리스트, 의사 난수(pseudo-random number) 리스트, 또는 컴퓨터 하드웨어를 통해 전달되는 마우스 위치 리스트나 큰 차이가 없다. 데이터의 출처가 뭐든 간에 결국 리스트의 n번째 항목을 가져오려면 먼저 𝑛 − 1개의 항목을 통과해야 한다는 사실은 동일하기 때문이다. 이러한 속성이 시간적 이벤트에 적용될 때 이를 인과성(causality)이라고 부른다.

그렇다면 이것이 카테고리 이론과 어떤 관련이 있다는 것일까? 필자는 카테고리 이론이 전역적 접근법을 장려하고, 따라서 선언적 프로그래밍을 지원한다는 이야기를 하려고 한다.

첫 번째로, 미적분학과 달리 카테고리 이론에는 거리(distance), 이웃(neighborhood), 시간(time)과 같은 개념이 없다. 우리가 다루는 것은 그저 추상적인 대상과 대상들 간의 추상적인 연결뿐이다. 만약 A에서 B로 여러 단계를 통해 이동할 수 있다면, 한 번에 도달할 수도 있다.

게다가 카테고리 이론의 주요 도구인 보편적 구성(universal construction)은 전역적 접근법의 정수이다. 우리는 이를 카테고리적 곱(categorical product)의 정의에서 확인했다. 이는 그저 해당 대상의 속성을 명시함하는 것만으로도 충분히 정의할 수 있었으며, 이는 매우 선언적인 접근이다. 곱은 두 투영(projection)을 갖춘 대상이며, 다른 대상들의 투영을 인수분해하는 특성을 최적화하는 가장 적합한 대상이다.

이런 특성을 페르마의 최소 시간 원리 또는 최소 작용 원리와 비교해보면 꽤 유사하다는 것을 알 수 있다.

반대로 카테고리적 곱을 전통적인 데카르트 곱의 정의와 비교해보자. 데카르트 곱은 훨씬 더 명령적인 접근을 보여주고 있다. 이 방법은 하나의 집합에서 원소를 선태갛고 다른 집합에서 또 다른 원소를 선택하여 최종적으로 곱의 원소를 생성하는 방법을 보여주고 있다.

Haskell과 같은 프로그래밍 언어에서 곱 타입, 합 타입, 그리고 함수 타입은 보편적 구성을 통해 정의되는 것이 아니라 이미 내장되어있는 경우가 대부분이다. (물론 카테고리적 프로그래밍 언어를 만드려는 시도는 있었으며, 타츠야 하기노의 논문에 그 내용이 잘 나와있다.)

하지만 프로그래밍 언어에 카테고리적인 정의가 직접적으로 사용되던 아니던, 결국 카테고리적 정의는 기존의 프로그래밍 구조를 정당화하고 새로운 구조를 만들어낼 수 있는 토대가 된다. 가장 중요한 점은 카테고리 이론이 컴퓨터 프로그램을 선언적인 수준에서 추론하기 위한 메타 언어를 제공한다는 것이다. 또한 문제를 코드로 구현하기 전에 명세에 대해 논리적으로 사고하는 것에도 많은 도움을 준다.

원문 보기

👉 Category Theory for Programmers

What Is Good Code? On the Illusion of Readability

Mon, 23 Dec 2024 09:34:56 GMT

Throughout life, we face countless problems. Just looking at the practical ones (education, careers, job changes, finances, growth), we encounter all kinds of missions. And when I talk to people about these things, I often hear them speak as if there’s a predetermined right answer, or at least wishing there were one.

Sometimes it feels like society is the one enforcing these answers. “Get into a good university and life will work out.” “You need to own a home to be happy.” “You need to earn at least this much to be middle class.” Hearing all these conditions and benchmarks, I sometimes wonder: are the decisions I make truly my own, or am I just following standards that society has laid out for me?

Students don’t study to explore and acquire knowledge. They study to match the answers that the majority proclaims as correct. This problem isn’t limited to schools. It shows up in private education and in all sorts of organizations that teach developers. At the end of the day, customers want right answers, so providing right answers is the business.

These formulas for success that society offers have conditioned us. Most problems we encounter in reality are unstructured and have no single correct answer. Yet when we face a problem, we often fall into the illusion that a right answer must exist somewhere.

This social conditioning runs deep in how we think, and developers like me are no exception. So in this post, I want to unpack a concern I’ve been carrying for a while.

The drive to find the right answer

Developers are, by nature, a group accustomed to seeking correct answers. Given the nature of working with logic, we’re trained to make decisions that are logically sound and grounded in clear evidence.

The “right answers” developers tend to champion usually revolve around code structure and relationships. It’s not uncommon to see someone adopt a monorepo without a clear reason, or introduce a global state management library or memoization without any particular context demanding it.

But as I mentioned earlier, reality isn’t that simple. In most cases, what counts as “best” varies depending on context, circumstances, and who’s interpreting it.

“What is good code?” “Code with good readability.”

I’ve been conducting interviews since 2016, early in my career, and I’ve kept at it ever since. Having done this for so long, I’ve developed a few go-to questions.

One of them is: “What is good code?” It’s a topic I’ve personally pondered for a long time, so I genuinely enjoy hearing different developers’ perspectives. But when I ask this question, most people answer: “Code with good readability.” With slight exaggeration, I’d say 99 out of 100 give this answer.

Every time I hear it, I feel a subtle awkwardness, because readability is subjective and abstract. The same code can be called readable by one person and unreadable by another.

Sure, there are elements that many people would agree make code more readable — writing in a familiar programming language rather than Egyptian hieroglyphs, for instance. But we all know that’s not the level of readability we’re actually talking about.

Can there really be a technical quality that all ~26 million software developers worldwide would universally agree on? If it’s a value that not everyone can agree on, shouldn’t we question whether “readable code” even exists as a meaningful concept?

With this in mind, when I follow up with “What makes code readable?”, the answers start to diverge. Some emphasize cohesion and coupling. Others point to clear, intuitive naming. Some talk about separation of concerns. In other words, rather than a definition that captures the full essence of readability, most people cite specific real-world examples: “When you do this, readability improves.”

This means every developer has a different idea of what’s most important for achieving good readability . These varied answers reveal how subjective and context-dependent readability is. It’s like looking at the same painting where one person sees beauty and another can’t figure out what it’s trying to express.

Yet many people answer “code with good readability” to the question of what good code is. As if the answer were predetermined.

“How should I grow as a developer?”

This instinct isn’t limited to developers. It shows up in the big and small decisions we make in everyday life. I occasionally have 1-on-1s and mentoring sessions where I get to hear other developers’ concerns and offer guidance. And in these settings too, I’ve seen the same drive to find the right answer.

The questions and concerns I typically hear go something like this:

How do I become a good developer?
What skills should I build to get into company X?
I want to have this kind of experience in the future. What should I do?

I completely empathize with the motivation behind these questions. When you desperately want to achieve something but don’t know what steps to take, that frustration is something everyone has felt at some point.

The people asking these questions are genuinely passionate about growth and sincerely want to get better. But the problem is that they approach goals like success or growth through overly standardized methods.

As a result, I’ve often seen people follow generic “right answers” that don’t fit their own circumstances, goals, or capabilities, and end up pouring effort in the wrong direction. It’s like trying to force yourself into clothes that don’t fit.

Between the lines, there’s also the idea that if you just put in enough effort, like the 10,000-hour rule, you’ll eventually achieve what you want. I disagree. Time and effort are extremely limited resources, so where you invest them matters enormously. (If you invest 10,000 hours only to discover it contributed nothing to your growth, those 10,000 hours are gone forever.)

What matters is where you invest your time and energy. The problem is that while we believe we’ve chosen this direction ourselves, that choice is often the product of standards set by others or by society.

Truth that shifts with context, not fixed truth

It’s natural for humans to seek stability and certainty — we’re wired to be uncomfortable with uncertainty. So this kind of thinking isn’t unnatural at all. If anything, believing that there’s no right answer might be the act that goes against human instinct.

That’s why in the examples of readability and growth I mentioned earlier, many people who were eager to become great developers likely absorbed information from blogs, books, or fellow developers without critical examination. But we shouldn’t overlook the fact that problems like readability and growth simply don’t have predetermined right answers.

In philosophy, concepts like relativism and contextualism are used to explore these kinds of problems.

Relativism holds that truth and value aren’t universal. They vary depending on culture, perspective, and circumstances. This means that standards for readability can also differ based on an individual’s criteria or the situation they’re in.

Contextualism means that whether a proposition is true depends on the context in which it’s used.

For example, the same code might be evaluated differently depending on team culture, the nature of the project, or the business situation.

Many people proclaim “code with good readability” as if it’s the definitive answer to what good code is. But this isn’t a fixed truth. It’s a relative concept that shifts across different contexts.

Of course, since many people treat interviews as a game of guessing the interviewer’s expected answer, some bias may have crept in. But I’ve seen similar responses not just in interviews but also in mentoring sessions and 1-on-1s, so I don’t think the bias is significant. (If you grab any 10 developers around you right now and ask “What do you think good code is?”, readability will almost certainly come up.)

We use programming languages, abstractions built from symbols familiar to humans, rather than machine code precisely because we want humans to easily understand how computers work. So if we could truly achieve “readable code,” there’s no question it would be great code.

But readability is something that inevitably gets judged differently depending on circumstances and context. To glibly declare it as your answer without questioning what readability actually means. That’s something a programming professional shouldn’t do.

So what criteria should we use to find essential value?

My choice, or others’ expectations?

The first step is to reflect on whether your decisions, the things you believe are right, are truly your own.

As I’ve mentioned several times, we live in a culture with strong collectivist tendencies. What we believe we decided for ourselves has often actually been determined by others’ or society’s standards.

Everyone says a developer’s starting salary should be at least X, so I should get at least that much.
AI is supposedly the next big thing, so I should study AI.
Big companies test algorithms, I hear. Time to start solving one algorithm problem a day.
I absolutely must buy a home in Seoul.
To be at the frontier of technology, I need to move to the US.

I catch myself thinking like this too. Most recently it was: “If I drove a nice imported car, wouldn’t my life satisfaction go up a bit?” It felt great at first, but after about three months it just became normal. I spent the money but never got the satisfaction I was looking for.

In the end, that was a decision influenced by society’s symbols of success, not one that truly came from within. I acquired what’s commonly recognized as a status symbol expecting it to improve my quality of life — a decision shaped by society’s perspective, not my own.

So when the logic “to do A, you must do B” pops into your head, it’s often not the right answer. More precisely, it might be the right answer for someone else but not for you. That’s why it’s worth pausing to reflect.

Understanding yourself is the first step

The right answer isn’t far away. To find it, you first need a deep understanding of yourself.

You need to know what you enjoy, what brings you joy, what makes you sad. You need to look back and identify what makes your heart race, what activities you lose yourself in. Without this kind of self-reflection, we’re easily swept along by standards that others or society have set for us.

I think this matters a lot. Unfortunately, when we’re busy navigating day-to-day life, we spend all our mental energy on external problems and rarely take the time to look inward and reflect on ourselves.

“Self-reflection” might sound old-fashioned and heavy, but it really starts with small questions you ask yourself:

When have I felt truly happy?
Why do I go to work?
Why am I working as a developer?

What matters is checking whether every decision you make truly originates from your own will, and confirming that what you’ve thought and decided actually fits you, like clothes that are actually your size.

I paid a premium for an imported car, but the novelty wore off in three months and I never got the satisfaction I wanted. Yet someone else might do the exact same thing and be perfectly content. It simply wasn’t the right fit for me. (Though I still drive it because it feels wasteful to sell.)

The right answer isn’t far away. It’s inside you. We may live in a society with strong collectivist tendencies, but building your own standards is the path to real satisfaction.

Closing thoughts

Existentialist philosopher Jean-Paul Sartre said, “We define ourselves, and the meaning of our existence is something we create.” He emphasized that humans are free to choose, but must also take responsibility for those choices.

This suggests that when our choices come from our own values and standards rather than others’ expectations, we can live a satisfying life.

Of course, navigating the real world sometimes requires meeting conditions that society or others demand. But what matters is whether you’re aware of why you’re meeting those conditions and have consciously chosen to do so.

The statement that good code is readable code, or that you need to do this and that to become a good developer — these are just data points among many. Our role is to filter them through our own standards, taking what fits and discarding what doesn’t.

So rather than believing the data itself is the answer, use it as raw material to build your own values and philosophy.

That concludes this post on the illusion that right answers exist.

좋은 코드란 무엇일까? - 가독성이란 허상에 대하여

Mon, 23 Dec 2024 09:34:56 GMT

우리는 인생을 살아가며 수없이 많은 문제들과 마주친다. 당장 현실적인 부분들만 보아도 입시, 취업, 이직, 재테크, 커리어, 성장 등 다양한 미션을 만나게 되는데, 종종 사람들과 이에 대해 이야기를 나누다보면 마치 정답이 정해져있다는 것과 같은 이야기 혹은 정답이 있기를 바라는 것과 같은 이야기를 듣고는 한다.

때로는 사회가 정답을 강요한다는 생각이 들기도 한다. “좋은 대학에 입학하면 인생이 필거야”, “행복하게 살려면 서울에 집 한 채는 있어야지”, “월 수입이 얼마는 되어야 중산층이지”와 같은 여러가지 조건과 기준들을 듣고 있자면, 내가 결정하는 것들이 정말 내가 결정하는 것이 맞는지 아니면 단순히 사회가 정해놓은 기준에 따라가고 있는 것인지 의문이 들 때가 있다.

학생들은 지식을 얻고 탐구하고자 학습하는 것이 아닌, 다수가 외치는 정답을 맞추기 위해 학습한다. 그리고 이런 폐단은 학교 뿐 아니라 사교육에서도 동일하게 나타나며, 개발자들을 가르치는 여러 조직들 또한 크게 다르지 않다. 결국 고객들이 정답을 원하고 있으니 정답을 가르치는 것이 비즈니스 임팩트이기 때문이다.

이렇게 사회가 제공하는 성공의 공식은 우리를 길들여왔다. 그래서 우리가 접하는 대부분의 문제들은 비정형적이고 정답이 없는 것들인 경우가 대부분이지만, 종종 우리는 문제를 만났을 때 마치 정답이 있을 것이라고 착각하고는 한다.

이런 사회적 강요는 우리의 사고방식에도 깊은 영향을 미치며, 필자와 같은 개발자들 역시 예외는 아니다. 그래서 이번 포스팅에서는 이에 대해 필자가 평소 느꼈던 문제 의식에 대해 한번 풀어보고자 한다.

정답을 찾으려는 노력

사실 필자와 같은 개발자들은 정답을 찾기 위해 노력하는 것이 익숙한 부류이다. 아무래도 논리를 다루는 직업의 특성 상, 명확한 근거를 기반으로 논리적으로 오류가 없는 의사 결정을 내리는 것에 익숙하기 때문이다.

보통 개발자들이 외치는 정답은 대부분 코드의 형상과 관계에 초점이 맞춰져 있는데, 간혹 명확한 이유 없이 모노레포를 도입한다거나 전역 상태 관리 라이브러리 또는 메모이제이션과 같은 특정 메소드를 맥락 없이 도입하는 경우도 흔하다.

하지만 앞서 이야기 했듯 현실은 그렇게 단순하지 않으며 많은 경우 “최선”이라는 것은 맥락과 상황에 따라, 혹은 해석하는 사람에 따라 다르게 정의된다.

좋은 코드란 무엇일까요? 가독성이 좋은 코드요.

필자는 어쩌다 보니 경력 초반인 지난 2016년부터 현재까지 꾸준히 인터뷰어로서의 경험을 쌓고 있는데, 아무래도 오랫동안 이 일을 하다보니 개인적으로 사용하는 질문 템플릿이 몇 가지 있다.

그 중 하나는 “좋은 코드란 무엇일까요?”라는 질문이다. 이는 개인적으로도 오랫동안 고민해온 주제라 인터뷰를 통해 다양한 개발자들의 의견을 듣고 싶은 마음도 있다. 하지만 이런 질문을 던지면 신기하게도 굉장히 많은 분들이 “가독성이 좋은 코드”라는 답변을 해주시는데, 과장을 조금 보태자면 100명 중 99명은 이 답변을 주시는 것 같다.

필자는 이 답변을 들을 때마다 묘한 어색함을 느끼는데, 가독성은 본질적으로 주관적이고 추상적인 개념이기 때문이다. 같은 코드를 보아도 누군가는 가독성이 좋다고 말할 수 있고, 누군가는 나쁘다고 말할 수 있는 것이니 말이다.

물론 코드를 이집트 상형 문자로 표현하는 것보다 나에게 익숙한 언어로 표현하는 것이 이해하기 쉬운 것처럼 많은 사람들이 가독성이 높다고 공감할 수 있는 요소들은 존재할 수 있겠지만, 사실 우리가 이야기하는 가독성이라는 것이 이런 수준의 이야기를 하는 것이 아니라는 건 다들 알고 있을 것이다.

애초에 전 세계에 존재하는 약 2,600만 명의 소프트웨어 개발자들이 모두 공감할 수 있는 기술적 요소라는 것이 존재할 수나 있는 것일까? 모두가 공감할 수 없는 가치라면 애초에 가독성이 좋은 코드라는 것이 세상에 존재하기는 하는 것인지에 대한 의심을 해봐야 하지 않을까?

이런 마음을 담아 지원자에게 “가독성이 좋은 코드는 무엇인가요?”라는 질문을 던지면 이제부터 답변이 다양해진다. 누군가는 응집이나 결합을 강조하고, 누군가는 명확하고 직관적인 네이밍, 누군가는 관심사에 대한 이야기를 한다. 즉, 가독성이라는 것의 본질 전체를 꿰뚫는 정의가 아닌, 현실의 특정 사례를 예시로 들며 “이렇게 했을 때 가독성이 좋아집니다”와 같은 답변을 하는 경우가 많았다.

결국 개발자마다 좋은 가독성을 달성하기 위해 가장 필요하다고 생각하는 부분이 모두 다르다는 것이며, 이 답변들이 오히려 가독성이라는 것이 얼마나 주관적이고 추상적이며 맥락 의존적인 것인지 드러내는 사례이다. 마치 같은 그림을 보면서도 누군가는 아름답다고 여기고 누군가는 도대체 뭘 표현하려는 것인지 모르겠다고 하는 것처럼 말이다.

하지만 분명 많은 사람들은 “좋은 코드가 무엇인가?”에 대한 질문에 “가독성이 좋은 코드”라는 답변을 하고 있다. 마치 정답이 정해져 있기라도 한 것처럼 말이다.

성장하려면 어떻게 해야할까요?

이 본능은 비단 개발자 뿐 아니라, 우리가 일상에서 내리는 크고 작은 결정에서도 자주 드러난다. 필자는 종종 1-on-1, 멘토링과 같이 다른 개발자들의 고민을 듣고 도움을 드릴 수 있는 자리를 가지고는 하는데, 사실 이런 자리에서도 정답을 찾으려는 노력을 많이 보아왔다.

이런 자리에서 주로 듣는 질문과 고민은 대략 이런 느낌이다.

좋은 개발자가 되려면 어떻게 해야 하나요?
ㅇㅇ 회사에 들어가려면 어떤 점을 채워야 할까요?
나중에 이런 경험을 하고 싶은데, 그러면 어떻게 해야 하나요?

물론 이런 질문을 하는 마음은 충분히 공감이 간다. 무언가를 달성하고 싶은 마음은 크지만 무엇을 해야 하는지는 모르겠을 때, 그 답답한 마음은 누구나 한번 쯤은 느껴보았을 것이다.

사실 이런 질문을 던지는 분들은 분명 성장을 갈망하며 진심으로 더 나아지고 싶어한다. 하지만 문제는 성공이나 성장이라는 목표를 지나치게 정형화된 방법으로 접근한다는 점이다.

그 결과 자신의 환경, 목표, 역량과 맞지 않는 보편적인 정답을 따라가다가 오히려 잘못된 방향으로 노력을 쏟는 경우를 자주 목격했다. 마치 내 몸에 맞지 않는 옷을 억지로 입으려고 하는 것처럼 말이다.

행간에는 1만 시간의 법칙과 같이 무조건 노력하면 언젠가 원하는 바를 달성할 수 있다는 이야기도 있지만, 필자는 절대 여기에 동의하지 않는다. 노력과 시간이라는 것은 매우 한정된 자원이기 때문에 어디에 투자할 것인지가 매우 중요하기 때문이다. (기껏 1만 시간을 투자했더니 알고보니 내 성장에 전혀 도움이 되지 않았던 곳이었다고 해도 날려버린 1만 시간은 두번 다시 돌아오지 않는다.)

결국 중요한 것은 시간과 에너지를 어디에 투자할 것인가에 대한 방향성인데, 문제는 우리는 이 방향성을 스스로 결정했다고 믿지만, 사실 그 선택은 타인이나 사회가 제시한 기준에 의존한 결과일 때가 많다는 것이다.

고정된 진리가 아닌 다양한 맥락 속에서 변화하는 진리

사실 사람은 누구나 안정성과 확실성을 추구하고 불확실한 상황을 불편해하는 심리적 기제를 지니고 있기 때문에 이러한 사고가 부자연스러운 것은 아니다. 오히려 정답이 없다고 믿는 것이 인간의 본능을 거스르는 행위일 수도 있다.

그래서 앞서 언급한 가독성과 성장의 사례 또한 훌륭한 개발자가 되기 위해 갈망하고 공부하던 많은 사람들이 어떤 블로그, 책, 혹은 주변에 있는 개발자 등을 통해 퍼진 정보들을 비판 없이 흡수했을 가능성이 높다. 하지만 가독성이나 성장과 같은 문제는 정해진 정답이라는 것이 없다는 점을 간과해서는 안된다.

철학에서는 이러한 문제를 탐구하기 위해 상대주의(Relativism)와 맥락주의(Contextualism) 같은 개념을 사용한다.

상대주의는 진리나 가치는 보편적이지 않고, 특정 문화, 관점, 상황에 따라 달라진다는 것이며, 이는 가독성의 기준도 개인의 기준 혹은 개인이 처한 상황에 따라 달라질 수 있다는 것을 의미한다.

맥락주의는 어떤 명제가 참인지 여부는 그것이 사용되는 맥락에 달려 있다는 것을 의미한다.

예를 들어 동일한 코드라 하더라도, 팀의 문화나 프로젝트의 성격, 그리고 비즈니스 상황에 따라 그에 대한 평가가 달라질 수 있는 것처럼 말이다.

많은 이들이 좋은 코드란 무엇인가에 대해 가독성 좋은 코드라는 답을 정답처럼 외치고 있지만, 이것은 고정된 진리가 아니라 다양한 맥락 속에서 변화하는 상대적인 개념인 것이다.

물론 인터뷰라는 자리를 마치 인터뷰어가 생각하는 정답을 맞춰야하는 게임이라고 착각하시는 경우가 많기 때문에 다소 편향이 발생했을 수도 있지만, 비단 인터뷰 뿐만 아니라 멘토링이나 1-on-1과 같은 자리에서도 많은 분들이 비슷한 반응을 보였기 때문에 편향이 크지는 않다고 생각한다. (독자 여러분도 당장 주변에 있는 개발자 아무나 10명만 붙잡고 “좋은 코드란 뭐라고 생각하심?”이라는 질문을 한번 던져보면 아마 높은 확률로 가독성 이야기가 나올 것이다)

물론 우리가 굳이 기계어가 아니라 인간에게 익숙한 기호들로 추상화된 프로그래밍 언어를 사용하는 것은 결국 인간이 컴퓨터의 동작을 쉽게 이해하기 위함이니, 가독성이 좋은 코드라는 가치를 달성할 수만 있다면 더할 나위 없이 좋은 코드라고 부를 수 있음에는 이견이 없다.

하지만 상황이나 맥락에 따라 다르게 판단될 수 밖에 없는 이 가독성이 좋다는 것이 도대체 무엇인지, 근본적인 진리에 대한 의문과 고찰없이 이런 답을 섣불리 내는 것은 프로그래밍 전문가로써 해서는 안될 행동이다.

그렇다면 우리는 과연 무엇을 기준으로 본질적인 가치를 찾아야 하는 것일까?

나의 선택인가, 타인의 기대인가?

가장 먼저 나의 의사결정 또는 내가 옳다고 생각하는 무언가가 정말 내가 결정한 것이 맞는지에 대해 성찰하는 과정이 필요하다.

앞서 여러 번 언급했듯이 우리는 집단주의 성향이 강한 문화권에서 살아가고 있기 때문에, 내가 스스로 결정했다고 믿는 것이 사실은 타인이나 사회의 기준에 의해 결정된 경우가 많다.

다들 개발자 초봉은 n천만원이라고 하니, 나도 그 정도는 받아야지.
요즘 AI가 대세라고 하니까 나도 AI를 공부해야겠다.
대기업은 알고리즘을 본다고 하네. 그럼 오늘부터 성실하게 1일 1알고리즘 풀이를 해야겠다.
집은 무조건 서울에 사야지.
기술의 선두 주자가 되려면 미국으로 건너가야겠다.

물론 필자도 알게 모르게 이런 생각을 많이 한다. 가장 최근에 했던 생각은 “비싼 수입차를 타면 내 인생에 대한 만족도가 조금은 올라가지 않을까”였는데, 처음에는 좋았지만 결국 3개월 정도 지나니까 익숙해져서 돈은 돈대로 쓰고 원했던 만족도는 얻지 못 했다.

결국 이것 또한 사회에서 일반적으로 통용되는 성공의 상징을 취득하면 삶의 질이 올라갈 것이라 판단한 것이니, 필자 스스로의 의사결정이라기보다는 사회나 타인의 시선에 영향을 받은 상황이라고 볼 수 있다.

그래서 이렇게 “A를 하려면 B를 해야한다”와 같은 논리가 머릿속에 떠올랐다면 대부분 정답이 아닌 경우가 많다. 더 정확히 말하자면 누군가에게는 정답일 수 있어도 나에게는 아닐 수 있기 때문에 한번 멈추고 성찰하는 과정이 필요한 것이다.

나를 이해하는 것이 첫걸음이다

정답은 사실 멀리 있는 것이 아니다. 정답을 찾기 위해서는 일단 나 스스로에 대한 깊은 이해가 필요하다.

내가 무엇을 좋아하고, 어떨 때 기쁨을 느끼며, 어떤 순간에 슬픔을 느끼는 지 알아야 한다. 무엇을 할 때 가슴이 뛰는지, 어떤 일을 할 때 가장 몰입하는지를 돌아보아야 한다. 이런 자기 성찰이 뒷받침되지 않는다면, 우리는 쉽게 타인이나 사회가 정해준 기준에 휘둘릴 수밖에 없다.

필자는 이것이 굉장히 중요한 요소라고 생각하는데, 안타깝게도 바쁘게 현생을 살다보면 외부의 문제에는 있는 힘껏 머리를 쓰면서도 정작 나에 대해서 돌아보고 생각해볼 기회는 많이 없는 것 같다.

성찰이라고 하면 고루하고 어려운 이야기처럼 느껴질 수는 있지만, 사실 스스로에게 던지는 작은 질문부터 시작해보면 그리 어려운 것은 아니다.

나는 어떤 상황에서 행복함을 느꼈을까?
나는 회사를 왜 다니고 있지?
나는 왜 개발자로 일하고 있지?

결국 중요한 것은 내가 내리는 모든 결정이 진정 나의 의지에서 비롯된 것인지 점검하고, 내가 생각하고 결정한 것이 정말 내 몸에 맞는 옷이 맞는지를 확인하는 것이다.

필자는 비싼 값을 치루고 수입차를 샀지만 결국 3개월 만에 익숙해져버려 원했던 만족감을 얻지 못 했다. 하지만 누군가는 동일한 행위를 해도 충분히 만족하면서 살아갈 수도 있다. 애초에 이 행위는 필자에 맞는 옷이 아니었던 것이다. (하지만 또 팔기는 아까워서 아직 잘 타고 있다)

정답은 멀리 있는 것이 아니라, 내 안에 있다. 비록 우리는 집단주의적 성향이 강한 사회 속에서 살아가지만, 오히려 이런 곳에서 나만의 기준을 세워가는 것이야말로 진정한 만족과 성취를 얻는 길이라고 할 수 있다.

마치며

실존주의 철학자 장폴 사르트르는 “우리는 스스로를 정의하며, 우리 존재의 의미는 우리가 만드는 것”이라고 말하며 인간이 자유롭게 선택할 수 있는 존재임과 동시에, 그 선택에 대한 책임을 져야 한다는 점을 강조했다.

이는 우리의 선택이 타인의 기대가 아니라 스스로의 가치와 기준에서 나올 때, 진정으로 만족스러운 삶을 살 수 있음을 시사한다.

물론 현생을 살기 위해서는 사회나 타인이 요구하는 여러 조건들을 맞춰야 하는 경우도 있다. 하지만 중요한 것은 스스로가 그 조건을 왜 맞춰야 하는지 인지하고 결정한 것이 맞냐는 것이다.

좋은 코드는 가독성이 높은 코드라는 말, 좋은 개발자가 되기 위해서는 이런 저런 일을 해야한다는 타인의 말은 그저 수많은 데이터 중 하나일 뿐이다. 우리의 역할은 저 데이터를 그대로 받아들이는 것이 아니라 내 기준에 맞춰 정제하여 취할 것은 취하고 버릴 것은 버리는 것이다.

그러니 데이터 자체가 정답이라고 믿는 것이 아닌 데이터를 재료로 하여 나만의 가치관과 철학을 만드는 과정에 대해 더 깊은 고민을 해보는 것을 추천한다.

이상으로 정답이 존재한다는 착각 포스팅을 마친다.

Who Are You, the One Writing Code Right Now?

Sun, 23 Jun 2024 10:10:21 GMT

AI is transforming our lives. When you use the ChatGPT mobile app and have voice conversations back and forth, it’s hard not to feel like Jarvis from Iron Man has become reality.

Generative AI like ChatGPT is used for everything from casual conversation to complex problem-solving, making our lives richer and more convenient.

But I think we need to step back and ask whether the comfort these technologies afford us has made us forget an important question — one about the fundamental significance of human existence.

For thousands of years, philosophers have argued that what makes us human is our capacity for self-reflection, critical and rational thinking, self-awareness, and moral judgment.

Yet lately, I see more and more people delegating the very faculties we’ve long considered essential to being human to tools like ChatGPT.

Of course, generative AI still isn’t perfectly accurate, so we haven’t delegated everything just yet. But the fact that the delegation has already begun is what matters. Given the pace of AI’s advancement, it’s not hard to imagine a future where this delegation accelerates rapidly.

And yet, compared to the speed at which AI is advancing, the ethical and philosophical discourse around it has been largely sidelined. I think this absence of discourse will come back as a serious side effect once AI develops further, and those building this technology should be paying the most attention.

“I could have done better if I’d used ChatGPT”

Since 2016, I’ve interviewed countless developers. If I averaged four to six interviews per month, that comes to roughly 400–600 people over the years.

I’ve heard all kinds of answers and perspectives through these interviews, but one response I heard recently was something I’d never encountered before:

“I think I could have done better on the assignment if I’d been allowed to use ChatGPT.”

This struck me as a peculiar and unfamiliar answer. It was essentially an admission that without a specific tool, the person couldn’t fully solve the problem in front of them — whether that tool is ChatGPT or Google.

Typically in interviews, candidates avoid underselling themselves. They try to emphasize what they can do on their own merits, without external tools. Everyone understands that interviews are meant to find people who can solve problems without tools but can use tools to amplify their capabilities, not people who can’t solve problems without them.

Some of you reading this might argue: “We’ll use ChatGPT on the job anyway, so what’s wrong with using tools during the evaluation?” Why not just assess the ability to use these tools effectively?

I use ChatGPT at work too. And I won’t deny that using it well can dramatically boost productivity. But the topic I want to explore in this post isn’t something as narrow as “should we test ChatGPT proficiency in interviews.”

Think about it. Right now, since generative AI has only been around for two years, humans still need to craft good prompts to get good results. But soon enough, AI will reach the point where even a vague, poorly worded question produces a perfect answer.

If AI reaches that level, what does it even mean to “assess someone’s ability to use the tool”? If anyone, regardless of knowledge, can ask AI a sloppy question and get a perfect response, the very concept of tool proficiency becomes meaningless.

The real issue is this: despite generative AI being only two years old, the number of people depending on AI for their thinking is growing fast, yet hardly anyone is paying attention to ethical questions like “how should we approach AI?” or “what does it mean to outsource our thinking to AI?”

As I mentioned earlier, people currently know that generative AI isn’t perfect, so full delegation of thinking hasn’t happened yet. But the moment people start believing that AI produces better answers than they can, the degree of delegation will escalate rapidly.

This is fundamentally different from simply using a tool to increase productivity. Every tool up to now has either assisted human capabilities or enabled things humans couldn’t do on their own.

But AI can think and make decisions at a level nearly equal to humans, and in certain domains, it has already surpassed us. Unlike every tool that came before, it’s now possible to delegate not just labor but human thought itself to AI. And there’s almost no sign that people are wary of this possibility.

Given that we’re already delegating parts of our thinking to AI just two years after generative AI entered the mainstream, I believe this trend will only accelerate.

What is the fundamental significance of human existence?

To explain the concern I’ve been carrying, we first need to examine what has historically been defined as the reason humans can exist as humans. “What is a human being?” is a question philosophers have explored for thousands of years.

We know we possess something that distinguishes us from other animals, but because no one has given us a definitive answer, we’ve spent millennia searching for one ourselves.

Plato, through his Theory of Forms, said humans are beings who pursue truth and ideals. Aristotle defined humans as rational animals. Descartes, with his proposition “I think, therefore I am,” linked human existence to thought and self-awareness. Kant defined humans as autonomous agents capable of moral judgment. Sartre said humans are beings who create their own essence.

Countless philosophers have offered various definitions of human nature and the significance of existence, but if you look closely, there are a few common threads.

The most prominent commonality is self-reflection and self-awareness: the ability to understand oneself, analyze one’s thoughts and actions, and pursue a deep understanding of one’s own existence. Plato and Aristotle’s rational thinking, Descartes’ thought and self-awareness, Kant’s moral autonomy, Sartre’s creation of essence. All revolve around this core of self-reflection and self-awareness.

In other words, humans are not beings who merely experience and react. We are beings who analyze and evaluate our experiences, and from them discover new meaning and direction.

The essential human trait that philosophers have long emphasized, self-reflection and self-awareness, is what elevates us beyond mere biological existence. As long as there’s a possibility that we delegate this to AI, we need to examine the issue through deep contemplation.

Does AI threaten the essence of human existence?

Returning to the interviewee’s response, “I could have done better if I’d used ChatGPT”: I discussed the danger of humans increasingly delegating their thinking to AI. That answer literally means the person couldn’t adequately perform a task without AI assistance, illustrating how human cognitive ability is becoming dependent on AI.

The capacity to understand oneself, analyze one’s thoughts and actions, and pursue deep self-understanding — thought, self-reflection, and self-awareness. These define what it means to be human. These are what give humans their value beyond mere biological existence.

Based on this reasoning, I want to argue that we need to be vigilant about the possibility that AI threatens the essence of human existence.

As AI advances, we’re delegating more and more of our thinking to it. If relying on AI to solve problems becomes the norm, we’ll likely skip the process of thinking deeply on our own — which means losing opportunities for self-reflection, constraining our capacity for thought.

Going further, if AI increasingly makes our decisions for us, we risk losing responsibility and autonomy, key components of self-awareness. The more we depend on AI’s decisions, the less accountable we feel for the outcomes, which could weaken our capacity for moral judgment.

These questions about responsibility and moral judgment have long surfaced in everyday debates like “who’s responsible when a self-driving car causes an accident?” None of these questions have been conclusively answered.

We must stay alert to the fact that as AI advances and our dependence deepens, we risk losing the very capabilities that define us as human. And those who are leading this technology should be paying even more attention to this ethical discourse.

Who are you, the one writing code right now?

As you’ve probably guessed, the people leading this technology are developers and researchers — especially those contributing directly to the AI domain.

Yet lately, even among developers, I see cases where people accept AI-suggested code from ChatGPT or Copilot without any critical review.

ChatGPT and Copilot are advancing rapidly, and it’s true they produce higher-quality code than before. But can we honestly say their output is flawless at this point?

No, we can’t. AI-generated code sometimes contains errors, and in certain situations, it fails to provide a complete solution. In particular, understanding context across multiple modules and designing architecture remain problems AI hasn’t conquered.

If AI-generated code were already perfect, the profession of software developer would have ceased to exist. The fact that developers still exist is itself proof that AI’s code is not yet complete. As AI advances, the number of people in this profession may shrink, but for now, that’s not the case.

So what role should we — the people with expertise in this technology — play?

Developers shouldn’t simply accept AI’s output. We should critically review and revise what AI generates. We must view AI as a tool and use it to maximize our own thinking and creativity. Even with AI’s help, the final decisions and responsibility rest with us.

Knowing that hallucinations exist, copying and pasting AI-generated code without review, or treating AI’s responses as truth, is premature. Even if the day comes when AI produces perfect answers, we must never forget that AI should be controlled by experts as a tool. (AI is a library, not a framework.)

If you’re accepting AI’s output uncritically and mistaking it for your own ability, ask yourself:

Am I a human who uses AI as a tool? Or am I merely a vessel that transfers AI’s output into an IDE?

AI cannot become “me.” We can receive AI’s help, but in that process, we must remain vigilant about preserving our ability to think and judge for ourselves.

This question goes beyond programming. It demands reflection on the nature of being human. If what makes us fundamentally human is the ability to understand ourselves through self-reflection and self-awareness, to explore the meaning of our existence, then merely following the instructions of a non-human tool cannot constitute human existence.

Closing thoughts

Some might say these thoughts are premature, or that I’m making too great a leap. But as you know, AI is advancing at a staggering pace, and in certain fields, AI has surpassed humans in less than a decade.

Math aside, look at the terrifying slope in language comprehension.

The number of AI-related projects on GitHub was only around 800 in 2011, but by 2023 it had grown to roughly 1.8 million. Over the same period, the number of research papers roughly tripled.

I believe that compared to how fast the technology is advancing, our perspective on it, our discussion of the potential side effects, has not kept pace.

AI is fundamentally different from every tool that came before. Previous tools could never surpass humans no matter what, and because of that inherent limitation, even the best tools could only assist.

But as the chart above shows, AI has already surpassed humans in certain areas. AGI may still be some time away, but in specific domains, it’s already happened. We need to pay attention to this.

What I want to say is this: as we use this convenient, explosively productive tool called AI, we should pause and ask whether we’re unknowingly delegating our essential human value to it.

A tool is called a tool because humans wield it with agency. If using AI causes us to lose our autonomy and the fundamental significance of being human, can we still call it a tool?

Building a better future alongside AI requires that ethical and philosophical discourse keep pace with technological development. Those of us leading this technology shouldn’t be focused solely on advancing the technology itself. We need to actively participate in these discussions and care about building a world where we, as humans, can properly wield AI as the powerful tool it is.

This concludes my post: Who Are You, the One Writing Code Right Now?

지금 프로그래밍을 하고 있는 당신은 누구인가

Sun, 23 Jun 2024 10:10:21 GMT

AI는 우리의 생활을 크게 변화시키고 있다. ChatGPT 모바일 앱을 사용하면서 음성으로 대화를 주고 받다보면 이제는 영화 아이언맨에 나오는 인공지능 비서 자비스가 현실화된 것이 아닌가 하는 착각마저도 일으킬 정도이다.

ChatGPT와 같은 생성형 AI는 일상적인 대화부터 복잡한 문제 해결까지 다양한 용도로 사용되며, 우리의 삶을 더욱 윤택하게 만들고 있다.

그러나 필자는 이러한 기술의 발전이 선물해준 편리함 속에서 우리가 중요한 질문을 잊고 있는 것은 아닌지 돌아볼 필요가 있다고 생각한다. 바로 인간 존재의 본질적 의의에 대한 질문이다.

지난 수천 년 동안 많은 철학자들은 인간이 자기 성찰, 비판적/이성적 사고, 자아 인식과 자기 성찰, 도덕적 판단과 같은 것들을 가지고 있기 때문에 인간일 수 있다고 이야기해왔다.

하지만 최근 주변을 둘러보면 지금껏 우리가 인간으로 존재하기 위해 지녀야 한다고 이야기해왔던 많은 가치들을 ChatGPT와 같은 도구에게 위임하는 모습을 볼 수 있다.

물론 지금의 생성형 AI는 아직 정확도가 높지 않기 때문에 많은 부분을 위임하지는 않겠지만, 그 위임이 이미 시작되고 있다는 것이 중요한 부분이며, AI의 발전속도를 생각해보면 앞으로 점점 더 빠른 속도로 위임이 이루어질 미래를 그리 어렵지 않게 그려볼 수 있다.

하지만 AI가 발전하는 속도에 비해 이러한 윤리적/철학적 담론은 거의 배제되고 있다. 필자는 추후 AI가 더욱 발전했을 때 이러한 담론의 부재가 큰 사이드 이펙트로 돌아올 것이라고 생각하며, 특히 이 기술을 개발하고 있는 분들은 더더욱 이 아젠다에 관심을 가져야 한다고 생각한다.

ChatGPT를 썼다면 더 잘할 수 있었을 것 같아요

필자는 지난 2016년부터 지금까지 수많은 개발자들의 인터뷰를 진행했었다. 만약 한 달에 4-6명씩 인터뷰를 진행했었다고 하면 대략 400-600명 정도 되는 인원을 만나본 셈이다.

이러한 인터뷰를 통해 다양한 답변과 견해를 들을 수 있었지만, 최근에 들은 답변은 그동안의 경험에서 한 번도 듣지 못했던 것이었다.

“ChatGPT를 썼다면 과제를 더 잘할 수 있었을 것 같아요”

이는 필자에게 꽤나 독특하고 낯선 답변으로 다가왔다. 이것은 도구를 사용할 수 없었기 때문에 자신에게 주어진 문제를 온전히 풀어낼 수 없었다고 시인한 것이나 마찬가지이기 때문이다. 이 도구가 ChatGPT든, 구글링이든 상관없이 말이다.

보통 인터뷰를 진행할 때 지원자들은 자신의 능력을 과소평가하는 말을 피하고, 오히려 도구가 없이도 펼칠 수 있는 자신 본연의 역량을 최대한 강조하려고 노력하기 마련이다. 이는 인터뷰라는 것이 도구가 없다면 문제를 해결할 수 없는 사람보다는 도구가 없어도 문제를 해결할 수 있되, 도구를 통해 자신의 역량을 부스팅할 수 있는 사람을 찾고자 하는 과정이라는 사실을 모두가 알고 있기 때문이기도 하다.

혹시 이 글을 읽고 있는 누군가는 어차피 입사하면 ChatGPT를 사용할 것인데 역량 검증 과정에서 도구를 사용하는 것이 뭐가 문제냐고 할 수도 있다. 이 도구를 활용하는 역량을 검증하면 되는 것 아니냐고 말이다.

물론 필자도 실무에서 ChatGPT를 사용한다. 그리고 필자는 ChatGPT를 업무에 잘 활용하면 생산성이 압도적으로 높아질 수 있다는 것을 부정하지도 않는다. 하지만 필자가 이 포스팅에서 이야기하고 싶은 주제는 “인터뷰에서 ChatGPT 활용 역량을 검증해야하냐”와 같은 지엽적인 주제는 아니다.

한번 생각해보자. 지금이야 생성형 AI가 등장한지 2년 밖에 되지 않았으니 인간이 프롬프트를 잘 작성하기 위해 고민하는 과정이 필요하겠지만, 앞으로는 개떡같이 질문해도 찰떡같은 대답을 해주는 수준까지 금방 발전할 것이다.

만약 이런 수준의 AI가 등장한다면 이 도구를 활용하는 역량을 검증한다는 것이 무슨 의미가 있을까? 아무런 지식이 없는 사람이 AI에게 대충 질문해도 찰떡같은 대답을 해주는 수준이 된다면 도구의 숙련도라는 개념도 어차피 무의미해진다.

중요한 것은 생성형 AI인 ChatGPT가 세상에 소개된지 이제 겨우 2년 밖에 지나지 않았음에도 불구하고 AI라는 도구에 자신의 사고를 의존하는 사람들이 빠르게 늘어나고 있지만, 정작 “우리가 AI를 어떤 식으로 다뤄야 하는지”, “AI에게 사고를 의존한다는 것이 무슨 의미인지”와 같은 윤리적 담론에는 별로 주목하고 있지 않다는 것이다.

서론에서 언급했듯이 물론 지금은 생성형 AI가 완전하지 않다는 사실에 대해 인간들도 알고 있으니 자신의 사고를 AI에게 온전히 위임하는 상황은 발생하지 않는다. 그러나 만약 인간이 보기에 AI가 자신보다 더 나은 답변을 내놓는다고 판단하기 시작한다면 그 위임의 정도는 빠르게 높아질 것이다.

이는 단순히 도구를 활용하여 생산성을 증가시키는 것과는 완전히 다른 개념이다. 지금까지의 도구는 인간의 능력을 보조하는 역할을 하거나, 혹은 인간 스스로의 힘으로는 불가능한 일을 할 수 있도록 도와주는 역할이었다.

하지만 AI는 인간과 거의 동등한 레벨의 사고와 의사결정을 할 수도 있는 존재이며, 이미 특정 분야에 대해서는 인간의 능력을 넘어선 경우도 있다. 즉, 지금까지의 도구와는 다르게 인간의 능력을 보조하는 정도를 넘어서서 인간의 사고 자체를 AI에게 위임하는 것도 가능하다는 것이다. 그리고 인간들이 이러한 가능성에 대해서 경계하는 움직임은 거의 보이지 않는다.

생성형 AI가 세상에 본격적으로 등장한지 꼴랑 2년 밖에 되지 않은 지금도 사고의 일부를 AI에게 위임하는 상황들이 발생하고 있으니, 앞으로는 이런 상황들이 더더욱 많아질 것이라고 생각한다.

인간 존재의 본질적 의의는 무엇인가

필자가 가졌던 문제의식에 대해서 이야기하려면, 지금껏 우리가 무엇 때문에 인간으로 존재할 수 있다고 정의해왔는지부터 살펴봐야한다. “인간이란 무엇인가?”라는 질문은 지난 수천 년 동안 수 많은 철학자들이 탐구해온 주제이다.

우리는 분명 다른 동물과 구분된 무언가를 가지고 있다는 사실을 알고 있지만, 그게 무엇인지에 대해서는 명확히 알려주는 이가 없었기에 수천 년 동안 스스로 탐구해온 것이다.

플라톤은 이데아론을 통해 인간은 진리와 이상을 추구하는 존재라고 하였으며, 아리스토텔레스는 인간을 이성적 동물로 정의했다. 데카르트는 “나는 생각한다, 고로 존재한다”라는 명제를 통해 인간의 존재를 사유, 그리고 자아인식과 연결지었다. 칸트는 인간을 자율적이고 도덕적인 판단을 내리는 주체로 정의했으며, 사르트르는 인간이 스스로 자신의 본질을 창조하는 존재라 했다.

이처럼 수많은 철학자들이 인간의 본질과 존재의 의의에 대해 다양한 정의를 내렸지만, 잘 살펴보면 공통적인 요소들이 몇 가지 있다.

그 중에서도 가장 두드러지는 공통점은 바로 자기 성찰과 자아 인식이다. 이는 인간이 스스로를 이해하고, 자신의 생각과 행동을 분석하며, 자신의 존재에 대한 깊은 이해를 추구할 수 있는 능력을 뜻한다. 플라톤과 아리스토텔레스의 이성적 사고, 데카르트의 사유와 자아인식, 칸트의 도덕적 자율성, 사르트르의 본질 창조 모두 이러한 자기 성찰과 자아 인식을 중심으로 전개된다.

즉 인간은 단순히 경험하고 반응하는 존재가 아니라, 자신의 경험을 분석하고 평가하며, 그로부터 새로운 의미와 방향을 찾아내는 존재라고 할 수 있는 것이다.

지금까지의 철학자들이 강조한 인간의 본질적 특징, 자기 성찰과 자아 인식은 인간이 단순한 생물학적 존재를 넘어선 독특한 존재로서의 가치를 지니게 하는 핵심 요소이기 때문에 우리가 이 부분을 AI에게 위임할 가능성이 존재하는 한, 우리는 이 문제에 대해 깊은 고민과 성찰을 통해 들여다봐야 할 필요가 있다.

AI는 인간 존재의 본질을 위협하는가

“ChatGPT를 썼다면 더 잘할 수 있었을 것 같아요”라는 지원자의 답변에서, 필자는 인간이 AI에게 사고를 점점 더 위임하게 됨으로써 발생할 수 있는 위험에 대해 이야기했다. 말 그대로 이 답변은 AI의 도움을 받지 못했기 때문에 과제를 제대로 수행할 수 없었다는 의미로, 인간의 사고 능력이 AI에 의존하게 되는 현상을 보여준다고 할 수 있다.

인간이 스스로를 이해하고 자신의 생각과 행동을 분석하며, 자신의 존재에 대한 깊은 이해를 추구할 수 있는 능력, 즉 사고와 자기 성찰, 자아 인식이라는 것은 인간의 본질을 규정하는 중요한 요소이다. 이러한 능력들은 인간이 단순한 생물학적 존재를 넘어선 독특한 존재로서의 가치를 지니게 하는 핵심 요소라고 할 수 있다.

이러한 근거를 토대로 필자는 AI가 인간 존재의 본질을 위협할 가능성에 대해 경계할 필요가 있다고 이야기하고 싶다.

AI가 발전함에 따라 우리는 점점 더 많은 사고 과정을 AI에게 위임하고 있다. 우리가 어떠한 문제를 해결할 때 AI의 도움을 받는 것이 점점 일반화된다면, 스스로 깊이 생각하고 고민하는 과정을 생략하게 될 가능성이 높으며 이는 결국 자기 성찰의 기회를 잃게 만들고 우리의 사고 능력을 제한할 수 있다.

더 나아가 AI가 인간의 의사결정까지도 점점 대신하게 된다면 인간은 자아 인식의 중요한 요소인 책임감과 자율성을 상실할 위험이 있다. 또한 AI가 내린 의사결정에 의존하게 될수록 우리는 그 결과에 대한 책임을 덜 느끼게 되고, 이는 우리의 도덕적 판단 능력을 약화시킬 수도 있다.

이렇게 책임감과 도덕적 판단 능력에 대한 이야기는 이미 “자율주행차가 사고를 내면 누구의 책임인가?”와 같은 생활 속의 아젠다로 떠오른지 오래지만, 필자는 아직도 이런 아젠다에 대한 명쾌한 결론은 아무 것도 나오지 않았다는 점을 강조하고 싶다.

우리는 AI의 발전과 그에 따른 의존도가 높아질수록 우리가 인간으로 정의될 수 있는 본질적인 능력을 잃어버릴 위험에 처하게 될 수도 있다는 사실을 경계해야하는 것이다. 그리고 이러한 경계심에서 비롯된 윤리적 담론은 이 기술을 선도하고 있는 사람들일수록 더더욱 신경써야 한다.

지금 프로그래밍을 하고 있는 당신은 누구인가

다들 예상했겠지만 이 기술을 선도하고 있는 사람들은 바로 개발자와 학자들이다. 특히 그 중에서도 AI라는 도메인에 직접적인 기여를 하고 있는 분들일것이다.

그러나 최근 들어 개발자들 사이에서도 ChatGPT나 Copilot 같은 AI 도구를 사용하며 AI가 제안한 코드를 비판 없이 수용하는 사례가 종종 보인다.

물론 ChatGPT나 Copilot의 발전은 매우 빠르며, 예전보다 높은 퀄리티의 코드를 출력해내고 있다는 것은 사실이지만, 하지만 현재 시점에서 보았을 때 그것이 완벽하다고 말할 수 있을까?

아니, 그렇지 않다. AI가 생성한 코드는 때때로 오류를 포함하고 있으며, 특정 상황에서는 완벽한 해결책을 제시하지 못할 때도 있다. 특히 여러 모듈의 맥락을 연결해가며 이해하고 아키텍쳐를 설계해야하는 부분은 아직 AI가 정복하지 못한 문제이다.

만약 AI가 제안한 코드가 이미 완벽하다면 개발자라는 직업은 이미 사라져야 마땅하다. 그러나 개발자라는 직업이 여전히 존재한다는 사실이 아직 AI의 코드가 완전하지 않다는 사실을 역설하고있다. 앞으로 AI가 발전하면 점점 이 직업에 종사하는 인구가 줄어들지언정 현재로써는 아직 그렇지 않다는 이야기이다.

그렇다면 이러한 기술에 전문성을 가지고 있는 우리는 어떤 역할을 해야 하는 것일까?

개발자는 단순히 AI의 출력을 수용하는 것에서 그치지 않고, AI가 생성한 코드를 비판적으로 검토하고 수정해야 한다. 우리는 AI를 도구로써 바라보고 활용해야 하며, 그 도구를 통해 우리의 사고력과 창의성을 극대화해야 한다. AI의 도움을 받더라도, 최종적인 결정과 책임은 우리 자신에게 있다는 것이다.

할루시네이션이 존재한다는 사실을 뻔히 알면서도 그 코드를 비판적인 검토없이 복붙하거나, AI의 답변이 진실된 것인 것처럼 믿는 것은 아직 시기상조이며, 혹여 AI가 완벽한 답변을 내놓는 순간이 온다고 해도 어디까지나 AI는 도구로써 전문가에게 컨트롤되어야 한다는 사실을 잊어서는 안된다. (AI는 라이브러리이지, 프레임워크가 아니다)

만약 AI의 출력을 비판없이 수용하고 마치 그것이 내 능력인 것처럼 착각하고 있다면, 스스로에게 한번 반문해보자.

나는 AI라는 도구를 활용하는 인간인가? 아니면 AI가 내놓은 출력물을 IDE에 옮겨담고 있는 존재일 뿐인가?

AI는 “내”가 될 수 없다. 우리는 AI의 도움을 받을 수 있지만, 그 도움을 받는 과정에서 스스로 생각하고 판단하는 능력을 잃지 않도록 경계해야한다.

이러한 질문은 단순히 프로그래밍이라는 문제를 넘어, 인간의 본질에 대한 깊은 성찰을 요구한다. 인간이 본질적으로 자기 성찰과 자아 인식을 통해 스스로를 이해하고 자신의 존재 이유와 삶의 의미를 탐구하는 존재라면, 인간이 아닌 도구의 지시대로 행동하는 것만으로는 인간으로 존재할 수 없기 때문이다.

마치며

혹자는 필자의 이런 생각이 시기적으로 너무 이른 생각이라고, 혹은 너무 비약적이라고 이야기할 수도 있다. 하지만 독자 여러분도 아시다시피 AI의 발전 속도는 생각보다 어마무시하며, 특정 분야에서는 10년도 되지 않은 시간 안에 AI가 인간을 넘어선 경우도 존재한다.

수학은 그렇다치고 언어 이해력 부문의 무시무시한 기울기를 보자.

깃허브에 올라와 있는 AI 관련 프로젝트의 수는 2011년 기준 약 800개에 불과했었으나, 2023년에는 약 180만개로 증가했으며, 같은 기간동안 논문의 수도 약 3배 정도 증가했다.

필자는 이처럼 기술이 빠르게 발전하는 속도에 비해 우리가 이 기술을 바라보는 시각, 이 기술로 인해 발생할 여러가지 사이드 이펙트에 대한 논의는 아직까지 그 속도에 맞게 발전하지는 않았다고 생각한다.

AI는 근본적으로 지금까지의 도구와는 궤를 달리한다. 지금까지의 도구는 무슨 짓을 해도 결코 인간을 넘어설 수 없었으며, 그러한 태생적 한계로 인해 아무리 좋은 도구라고 해도 그저 인간을 보조하는 정도에 그쳤다.

하지만 이미 위 차트에서 볼 수 있듯이 이미 AI는 인간을 넘어서고 있다. 물론 AGI가 등장하려면 시간이 조금 더 걸리겠지만, 적어도 특정 분야에서만큼은 이미 그러하다. 우리는 이 점에 주목해야한다.

결국 필자가 이야기하고 싶은 것은 우리가 AI라는 편리하고 폭발적인 생산성을 가져다주는 도구를 사용하면서, 나도 모르게 인간으로서의 본질적 가치를 이 도구에게 위임하고 있는 것은 아닌지 돌아보자는 것이다.

도구는 인간이 주도권을 가지고 활용되기 때문에 도구라고 할 수 있다. 만약 우리가 AI를 사용함으로써 인간으로서의 주체성과 본질적 의의를 잃는다면, 그것을 더 이상 도구라고 할 수 있을까?

결국 우리가 AI와 함께 더 나은 미래를 만들어 가기 위해서는 이러한 윤리적/철학적 담론이 반드시 동반되어야 하며, 특히 이 기술을 선도하고 있는 사람들이라면 단지 기술의 발전에만 몰두하는 것이 아니라 이러한 논의에도 활발하게 참여하여 우리가 인간으로써 AI라는 좋은 도구를 제대로 활용할 수 있는 세상을 만드는 것에 관심을 가져한다는 사실을 강조하고 싶다.

이상으로 지금 프로그래밍을 하고 있는 당신은 누구인가 포스팅을 마친다.

[번역] 프로그래머를 위한 카테고리 이론 - 10. 자연 변환

Sat, 01 Jun 2024 01:21:26 GMT

필자는 지금까지 카테고리 사이의 구조를 보존하는 사상으로써의 펑터에 대해 이야기하였다. 펑터는 한 카테고리를 다른 카테고리에 포함(Embeds)한다. 이는 결국 펑터가 여러 대상을 하나로 합칠 수는 있지만, 절대 구조를 변형하지는 않는다는 것을 의미한다. 펑터에 대해 이해하는 방법 중 하나는 함자를 사용하여 하나의 카테고리를 다른 카테고리 내부에서 모델링해보는 것이다.

소스가 되는 카테고리는 대상이 될 카테고리의 일부인 구조적인 모델 또는 청사진 역할을 한다.

어떤 하나의 카테고리를 다른 카테고리에 포함시키는 방법에는 여러가지가 있을 수 있다. 대표적인 두 방법 중 하나의 방법은 소스 카테고리를 대상 카테고리가 가진 하나의 대상으로 축소시키는 방법, 그리고 다른 방법은 소스 카테고리의 각 대상을 대상 카테고리의 각 대상으로, 소스 카테고리의 각 사상을 대상 카테고리의 각 사상으로 매핑하는 방법이다. 즉, 같은 청사진이라고 해도 여러가지 방법으로 표현될 수 있다는 의미이다. 자연 변환은 이런 방법들을 비교하는 데 큰 도움이 된다. 자연 변환은 펑터들의 펑터적 성질을 보존해주는 특별한 사상이기 때문이다.

카테고리 $C$ 와 $D$ 를 매핑하는 두 개의 펑터 F와 G를 한번 상상해보자. $C$ 가 가진 하나의 대상인 a에 대해서 한번 생각해보자면, 이 펑터들은 두 개의 대상인 F a와 G a로 매핑될 것이다. 여기서 펑터들의 매핑이라는 말의 의미는 F a를 G a로 매핑하는 행위를 의미하는 것이다.

여기서 한 가지 유의해야할 점은 F a와 G a 모두 카테고리 $D$ 의 대상이라는 것이다. 동일한 카테고리 내의 대상들 사이의 매핑은 카테고리가 가진 특성을 위반해서는 안된다. 우리는 카테고리 $D$ 의 대상들 사이에 인위적인 연결을 만들어내는 것이 아니라, 그저 사상이라는 개념을 자연스럽게 이용하면 되는 것이다.

즉, 자연 변환은 a라는 대상으로 인해 발생할 수 있는 사상들 중 F a → G a와 같은 하나의 사상을 선택하는 것이라고 볼 수 있다. 이 자연 변환을 $α$ (알파: a가 아니다.)라고 부른다면 이 사상은 $α$ 의 성분 또는 $α_a$ (밑은 알파가 아닌 대상 a이다)라고 불린다.

α_a :: F a -> G a

여기서 우리가 신경써야 하는 점은 대상 a는 카테고리 $C$ 의 대상이고, 사상 $α_a$ 는 카테고리 $D$ 의 사상이라는 것이다.

만약 어떠한 대상 a를 기반으로 한 매핑 결과 F a와 G a 사이에 사상이 존재하지 않는다면, 펑터 F와 펑터 G 간의 자연 변환 또한 존재할 수 없다는 의미이다.

물론 이 이야기는 대상에 대한 이야기이므로 펑터가 만들어낼 수 있는 모든 케이스를 커버할 수 있는 것은 아니다. 왜냐하면 펑터들은 대상 뿐 아니라 사상 또한 매핑하기 때문이다. 그렇다면 사상들에 대해서는 자연 변환이 어떻게 작용하는 것일까?

한번 임의의 사상을 f라고 해보자. 사상들이 표현하는 매핑 행위는 고정되어있으니, F와 G 사이의 어떤 자연 변환에서도 F f는 반드시 G f로 변환되어야 한다.

이에 더해 펑터는 이 사상들의 매핑이 가진 특성을 보존해야한다는 제약을 가지고 있기 때문에 자연 변환의 정의 또한 이 제약에 얽매일 수 밖에 없다. 한번 카테고리 $C$ 가 가진 두 대상 a와 b 사이에 적용되는 사상 f를 생각해보자. 이 사상은 카테고리 $D$ 가 가진 두 개의 사상인 F f와 G f로 매핑될 것이다.

F f :: F a -> F b
G f :: G a -> G b

이때 자연 변환 $α$ 는 카테고리 $D$ 내의 다이어그램을 완성할 수 있는 두 개의 사상을 추가적으로 제공한다.

α_a :: F a -> G a
α_b :: F b -> G b

위 다이어그램을 보면 F a에서 G b로 가는 방법은 총 두 가지이다. 이 두 가지 방법이 동일한지 확인하려면 모든 f에 대해서 성립할 수 있는 자연성 조건을 부여해야한다.

G f ◦ α_a = α_b ◦ F f

이러한 자연성 조건은 매우 엄격한 제약이라고 볼 수 있다. 예를 들어 사상 F f가 가역적이라면 자연성 조건을 통해 $α_a$ 만 사용해서 $α_b$ 를 결정해버릴 수 있다. 아래와 같이 말이다.

α_b = (G f) ◦ α_a ◦ (F f)^-1

만약 두 대상 사이에 여러 개의 가역적인 사상들이 존재한다면, 이 변환들은 모두 이 조건을 만족시켜야한다. 즉, 자연성 조건이 보장되는 상황이라면 어떤 경로를 따라가더라도 결국 동일한 결과에 다다라야 한다는 것이다. 그러나 일반적으로 사상들이 가역적인 경우는 별로 없기 때문에, 두 펑터 간의 자연 변환이 존재한다는 것이 항상 보장되는 것은 아니라고 이야기한 것이다.

결과적으로는 이런 자연 변환을 통해 여러 펑터들이 작용하는 카테고리의 구조에 대한 많은 정보들을 표현해낼 수 있다. 추후 리미트와 요네다 보조정리에 대해 이야기할 때 이에 대한 몇 가지 예시를 다시 살펴볼 것이다.

자연 변환을 각 요소 별로 뜯어서 살펴보면 결국 대상을 사상으로 매핑하는 것이라고 말할 수 있다. 자연성 조건으로 인해 사상을 교차하는 사각형 다이어그램으로 매핑한다고 볼 수도 있다는 것이다. 즉, 카테고리 $C$ 가 가진 각각의 사상에 대해서 카테고리 $D$ 는 이 사상들을 교차하는 자연성 사각형 다이어그램을 가지고 있다.

자연 변환이 가진 이러한 성질은 카테고리적인 구성을 할 때 매우 유용하다. 카테고리적인 구성을 할 때 종종 교차 다이어그램이 포함되는 경우가 많은데, 이때 적절한 펑터를 선택함으로써 이러한 교차성 조건을 자연성 조건으로 변환할 수 있다. 이는 추후 극한(limits), 쌍대극한(colimits), 수반(Adjunctions)에 대한 예시를 다룰 때 더 자세히 살펴보도록 하겠다.

마지막으로 자연 변환은 펑터들의 동형사상을 정의하는 데에도 사용될 수 있다. 두 펑터가 자연적으로 동형이라고 말하는 것은 두 펑터가 거의 같다고 말하는 것과 동일한 말이다. 자연 동형성은 모든 요소가 동형사상인 자연 변환으로 정의된다.

10.1 다형성 함수(Polymorphic Functions)

지금까지 필자는 프로그래밍에서의 펑터(특히 엔도펑터)에 대해서 이야기해왔었다. 이 펑터는 타입을 다른 타입으로 매핑하는 타입 생성자에 해당한다. 또한 함수를 함수로 매핑하기도 하며, 이 매핑은 고계 함수 fmap에 의해 구현된다.

자연 변환을 구성하기 위해서는 대상, 여기서는 타입 a부터 시작한다. 펑터 F는 이 타입을 타입 F a로 매핑할 것이다. 그리고 또 다른 펑터 G는 이 타입을 G a로 매핑한다. 이때 alpha라는 자연 변환의 성분은 타입 a이며, 이것은 결국 F a에서 G a로 매핑되는 함수를 의미한다. 이것을 Haskell 의사코드로 표현해보면 아래와 같다.

alpha_a :: F a -> G a

자연 변환은 모든 타입 a에 대해 정의되는 다형성 함수라고 할 수 있다.

alpha :: forall a . F a -> G a

Haskell에서 forall 키워드는 선택적으로 사용할 수 있으며, 이 키워드를 사용하기 위해서는 ExplicitForAll 언어 확장을 활성화해야한다. 일반적으로는 아래와 같이 표현한다.

alpha :: F a -> G a

이 표현은 a에 의해 매개변수화된 함수라는 점에 주의하자. 이는 Haskell 구문의 간결함에 대한 또 다른 예시이기도 하다. 만약 C++에서 이와 유사한 구조를 표현하려면 약간 더 복잡해질 수 있다.

template<class A> G<A> alpha(F<A>);

Haskell에서의 다형성 함수와 C++의 일반적인 함수 사이에는 더 깊은 차이가 있으며, 이 차이는 이러한 함수들이 구현되고 타입 검사되는 방식에도 그대로 적용된다. Haskell의 다형성 함수는 모든 타입에 적용될 수 있도록 일관되게 정의되어야한다. 즉, 하나의 공식이 모든 타입에 대해 작동해야한다는 것이다. 이를 *매개변수 다형성(Parametric polymorphism)*이라고 한다.

C++은 기본적으로 특수 다형성(Ad hoc polymorphism)을 지원한다. 이는 어떤 하나의 템플릿이 반드시 모든 타입에 대해 적용될 수 있도록 정의될 필요는 없다는 것을 의미한다. 주어진 타입에 대해 템플릿이 적용될 수 있는지에 대한 여부는 인스턴스화 타임에 결정며, 이때 타입 매개변수가 구체적인 타입으로 대체된다. 이러한 과정 때문에 타입 검사가 느려지기도 하며, 가끔은 이해하기 어려운 에러 메시지를 만나기도 한다.

C++에는 함수 오버로딩이나 템플릿 특수화 같은 매커니즘도 존재한다. 이를 통해 하나의 함수가 각기 다른 타입에 맞춰 다른 정의를 제공할 수도 있다. Haskell에서는 이런 기능이 타입 클래스와 타입 패밀리를 통해 제공된다.

Haskell의 매개변수 다형성은 종종 예상치 못한 결과를 가져오기도 한다.

alpha :: F a -> G a

여기서 F와 G는 펑터이며 자연성 조건을 자동으로 만족한다. 이를 카테고리적 표기법으로 나타내면 다음과 같다. (f는 함수 f :: a -> b이다)

G f ◦ α_a = α_b ◦ F f

Haskell에서 펑터 G의 사상 f에 대한 작용은 fmap을 사용하여 구현된다. 먼저 명시적인 타입 주석을 사용하여 Haskell 의사 코드로 작성해보겠다.

fmap_G f . alpha_a = alpha_b . fmap_F f

사실 타입 추론 덕분에 이러한 주석들은 필요하지 않으며, 다음의 등식이 성립할 수 있게 된다.

fmap f . alpha = alpha . fmap f

이건 진짜 Haskell 문법이 아니라 의사 코드이다. 함수의 동등성은 코드로 표현할 수 없기 때문이다. 하지만 이런 항등식은 방정식 추론에 이용할 수 있으며, 컴파일러가 최적화를 구현하는 데에도 사용될 수 있다.

Haskell에서 자연성 조건이 자동으로 성립하는 이유는 “공짜 정리(Theorems for free)와 관련이 있다. Haskell에서 자연 변환을 정의하는데 사용되는 매개변수 다형성은 모든 타입에 대해 작동할 수 있는 하나의 공식을 구현해야한다는 강력한 제한을 부과한다. 이러한 제한은 함수에 대해 방정식 정리를 사용할 수 있도록 만든다. 펑터를 변환하는 함수의 경우 공짜 정리는 자연성 조건을 의미한다.

Haskell에서 펑터를 다루는 아이디어 중 하나는 바로 펑터를 일반화된 컨테이너로 간주하는 것이다. 비유를 해보자면 펑터는 자연 변환한 컨테이너의 내용을 다른 컨테이너로 다시 포장하는 일종의 레시피라고 볼 수 있다. 우리는 컨테이너 내부 요소 자체를 수정하거나 새로운 요소를 만드는 것과 같은 변화를 가하지 않는다. 단지 그 요소들을 복사하여 새로운 컨테이너에 담을 뿐이다.

자연성 조건은 내부 요소를 fmap을 통해 먼저 수정하고 나중에 재포장하든, 재포장을 먼저 하고 새로운 컨테이너에서 내부 요소를 수정하든 상관없다는 것을 명시적으로 표현한다. 재포장과 fmap이라는 두 개의 동작은 마치 “계란을 옮긴다”, “계란을 끓인다”와 같이 직교적(서로 독립적)이라고 할 수 있다.

한번 Haskell에서의 자연 변환을 보여주는 몇 가지 예시를 살펴보도록 하자. 첫 번째 예시는 List 펑터와 Maybe 펑터와의 자연 변환이다. 이 함수는 리스트의 첫 번째 요소를 반환하지만, 만약 리스트가 비어있다면 Nothing을 반환한다.

safeHead :: [a] -> Maybe a
safeHead [] = Nothing
safeHead (x:xs) = Just x

이 함수는 a에 대해 다형적이다. a가 어떤 타입이든 함수는 제한없이 작동하기 때문에 매개변수 다형성을 갖추고 있다고 하는 것이다. 따라서 이 함수는 두 개의 펑터 사이의 자연 변환의 예시가 될 수 있다. 하지만 확실히 짚고 넘어가기 위해 자연성 조건을 한번 검증해보도록 하겠다.

fmap f . safeHead = safeHead . fmap f

우리는 두 개의 경우를 고려해야한다. 먼저 빈 리스트에 대한 경우를 생각해보자.

fmap f (safeHead []) = fmap f Nothing = Nothing

safeHead (fmap f []) = safeHead [] = Nothing

그리고 비어있지 않은 리스트에 대해서도 대응해야한다.

fmap f (safeHead (x:xs)) = fmap f (Just x) = Just (f x)
safeHead (fmap f (x:xs)) = safeHead (f x : fmap f xs) = Just (fx)

List 펑터와 Maybe 펑터의 fmap 구현에 대해서도 한번 되짚어보자.

-- List
fmap f [] = []
fmap f (x:xs) = f x : fmap f xs

-- Maybe
fmap f Nothing = Nothing
fmap f (Just x) = Just (f x)

더 흥미로운 예시는 펑터 중 하나가 단순한 Const 펑터인 경우이다. Const 펑터로부터 출발하거나 Const 펑터로 향하는 자연 변환은 반환 타입이나 인수 타입 중 하나에 다형성을 가진 함수와 동일하다.

예를 들어 길이(length)는 List 펑터에서 Const Int 펑터로의 자연 변환으로 볼 수 있다.

length :: [a] -> Const Int a
length [] = Const 0
length (x:xs) = Const (1 + unConst (length xs))

여기서 unConst는 Const 생성자를 제거하는데 사용된다.

unConst :: Const c a -> c
unConst (Const x) = x

물론 실제 length는 아래와 같이 단순하게 정의된다.

length :: [a] -> Int

이 타입 시그니처는 length가 List 펑터에서 Const 펑터로의 자연 변환이라는 사실을 숨기고 있다.

반면 Const 펑터에서 출발하는 매개변수 다형성 함수를 찾는 것은 조금 더 어려운 일이다. 왜냐하면 아무것도 없는 상태에서 값을 생성하기를 요구하기 때문이다. 따라서 우리가 할 수 있는 최선은 다음과 같다.

scam :: Const Int a -> Maybe a
scam (Const x) = Nothing

또 다른 펑터는 예전에 보았던 Reader 펑터이며, 이 펑터는 요네다 보조정리에서도 중요한 역할을 한다. newtype 키워드를 사용하여 Reader 펑터의 정의를 다시 작성해보겠다.

newtype Reader e a = Reader (e -> a)

이것은 두 가지 타입으로 매개변수화되지만, 두 번째 유형에 대해서만 공변적으로 펑터적이다.

instance Functor (Reader e) where
    fmap f (Reader g) = Reader (\x -> f (g x))

모든 타입 e에 대해서, Reader e에서 다른 펑터 f로의 자연 변환들을 정의할 수도 있다. 나중에 요네다 보조정리에 대한 이야기를 할 때 이 변환들의 구성원들이 항상 f e의 요소와 일대일 대응되는 것을 보게될 것이다.

예를 들어 유닛 타입 ()를 생각해보자. 이 타입은 단 하나의 원소인 ()를 가진다. Reader 펑터는 임의의 타입 a를 가져와서 함수 타입 () -> a로 매핑한다. 그리고 이 함수는 집합 a에서 하나의 원소를 선택하는 모든 함수들을 의미한다. 즉, 이 함수들은 집합 a에 있는 원소들의 수만큼 존재하는 것이다.

그럼 이제 이 펑터에서 Maybe 펑터로의 자연 변환을 생각해보겠다.

alpha :: Reader () a -> Maybe a

이 자연 변환은 dumb와 obvious 두 가지 함수로 정의된다.

dumb (Reader _) = Nothing

obvious (Reader g) = Just (g ())

(어차피 함수 g가 할 수 있는 유일한 행위는 값 ()에 적용되는 것 뿐이다.)

실제로 요네다 보조정리에서 예측된대로 이 두 함수들은 Maybe () 타입의 두 요소들인 Nothing과 Just ()에 대응한다. 이에 대해서는 추후 요네다 보조정리를 이야기하며 더 자세히 살펴보도록 하겠다.

10.2 자연성을 넘어(Beyond Naturality)

두 펑터 사이의 매개변수 다형성 함수는 항상 자연 변환이다. 즉, 모든 표준 대수적 데이터 타입은 펑터이니 이러한 타입들 사이의 모든 다형성 함수는 자연 변환이다.

또한 우리는 함수 타입을 사용할 수 있으며, 함수 타입은 반환 타입에 대해 펑터적이다. 이를 사용하여 Reader 펑터와 같은 펑터를 만들고, 고차 함수인 자연 변환을 정의할 수도 있다.

그러나 함수 타입은 인자 타입에 대해 공변적이지 않으며 반공변적으로 작동한다. 물론 반공변 펑터는 반대 카테고리에서의 공변 펑터와 동등하다. 두 반공변 펑터 사이의 다형성 함수를 카테고리적 의미에서 보았을때는 여전히 자연 변환이다. 단, 이것들은 반대 카테고리에서 Haskell 타입으로 가는 펑터에서 작동한다.

이전에 보았던 반공변 펑터의 예시를 다시 한번 살펴보자.

newtype Op r a = Op (a -> r)

위 펑터는 a에 대해 반공변적이다.

instance Contravariant (Op r) where
    contramap f (Op g) = Op (g . f)

우리는 이 펑터를 가지고 Op Bool에서 Op String으로 향하는 다형성 함수를 작성해볼 수 있다.

predToStr (Op f) = Op (\x -> if f x then "T" else "F")

그러나 두 펑터가 모두 공변적이지 않기 때문에, 이것은 Hask에서의 자연 변환이 아니다. 그러나 두 펑터가 모두 반공변적이니, “반대” 자연성 조건을 만족할 수 있다.

contramap f . predToStr = predToStr . contramap f

contramap의 시그니처 때문에 함수 f는 fmap을 사용할 때와는 반대 방향으로 가야한다는 점을 주목하자.

contramap :: (b -> a) -> (Op Bool a -> Op Bool b)

그렇다면 공변적이든 반공변적이든 펑터가 아닌 타입 생성자도 있을까? 여기 한 가지 예시가 있다.

a -> a

이것은 동일한 타입 a가 반공변 위치, 공변 위치 모두에서 사용되기 때문에 펑터가 아니며, 이 타입에 대한 fmap이나 contramap을 구현할 수도 없다. 따라서 아래와 같은 시그니처를 가진 함수는 자연 변환이 될 수 없다.

(a -> a) -> f a

흥미롭게도 이러한 경우를 다루는 자연 변환의 일반화된 형태가 있으며, 이를 이자연 변환(Dinatural transformations)이라고 한다. 이에 대해서는 추후 끝(ends)에 대해 이야기할 때 다시 살펴볼 것이다.

10.3 펑터 카테고리(Functor Category)

이제 우리는 펑터 간의 사상인 자연 변환에 대해 알게 되었으므로, 펑터만으로 이루어진 카테고리도 존재하는지 대해서 이야기해볼 수 있게 되었다. 그리고 실제로 펑터로만 이루어진 카테고리는 존재한다. 각 카테고리 $C$ 에서 $D$ 로 향하는 펑터로만 이루어진 카테고리를 생각해보자. 이 카테고리의 대상은 $C$ 에서 $D$ 로 향하는 펑터이며, 사상은 이 펑터들 사이의 자연 변환일 것이다.

또한 이미 우리는 사상을 어떻게 합성하는지 알고 있으니, 두 자연 변환의 합성의 정의 또한 쉽게 할 수 있다.

한번 펑터 $F$ 에서 $G$ 로 향하는 자연 변환 $α$ 를 생각해보자. 이때 대상 a의 성분은 다음과 같은 사상이 될 것이다.

α_a :: F a -> G a

우리는 이 자연 변환 $α$ 를 펑터 $G$ 에서 $H$ 로 향하는 자연 변환 $β$ 와 합성하려고 한다. $β$ 의 대상 a의 성분은 다음과 같은 사상이 될 것이다.

β_a :: G a -> H a

당연히 이 사상들은 합성이 가능하며, 그 합성 결과는 또 다른 사상이 된다.

β_a ◦ α_a :: F a -> H a

이제 두 자연 변환 $α$ 와 $β$ 의 합성인 이 사상을 자연 변환 $β ⋅ α$ 의 성분으로 사용하면 된다.

(β ⋅ α)a = β_a ◦ α_a

아래 다이어그램을 보면, 이 합성의 결과가 실제로 $F$ 에서 $H$ 로 향하는 자연 변환임을 확인해볼 수 있다.

H f ◦ (β ⋅ α)_a = (β ⋅ α)_b ◦ F f

자연 변환의 합성은 일반적인 사상과 동일하기 때문에 합성에 대한 결합법칙 또한 만족한다.

마지막으로 각 펑터 $F$ 에 대해서는 성분이 항등 사상인 항등 자연 변환 $1_F$ 도 존재할 수 있다.

id_Fa :: F a -> F a

따라서 펑터로만 이루어진 카테고리도 존재한다고 말할 수 있는 것이다.

참고로 이 책에서는 카테고리 이론의 공동 창시자인 사운더스 맥레인(Saunders Mac Lane)의 방식을 따라, 자연 변환의 합성을 점으로 표기하고 있다.

문제는 자연 변환을 합성하는 방법이 하나가 아니라는 것이다. 이 방법들은 크게 수직 합성과 수평 합성으로 나누어진다. 그 중에서도 수직 합성은 일반적인 다이어그램에서 펑터와 자연 변환이 모두 수직으로 표기되기 때문에 불리는 명칭이며, 이는 펑터 카테고리를 이해할 때 중요한 개념이기도 하다. 또 다른 합성 방법인 수평 합성에 대해서는 다음 섹션에서 마저 설명하도록 하겠다.

카테고리 $C$ 와 $D$ 간의 펑터 카테고리는 Fun(C, D) 또는 [C, D]로 표기되며, 때로는 지수 형태인 $D^C$ 로 표기되기도 한다. 특히 마지막 표기법이 흥미로운데, 이는 펑터 카테고리 자체가 다른 카테고리에서 함수 대상(지수 대상)으로 간주될 수 있음을 암시하고 있기 때문이다. 이에 대해서 한번 알아보자.

지금까지 우리가 구축해온 추상화 계층들을 한번 살펴보자. 우리는 대상과 사상의 집합인 카테고리에서부터 시작해왔다. 카테고리 자체, 특히 집합의 카테고리인 작은 카테고리는 상위 레벨 카테고리인 Cat(카테고리의 카테고리)에서의 대상이 된다. 그리고 Cat의 사상은 결국 펑터이기 때문에 Cat의 Hom 집합은 펑터들의 집합이 될 것이다. 예를 들어 $Cat(C, D)$ 는 두 카테고리 $C$ 와 $D$ 간의 펑터들의 집합이다.

펑터 카테고리 $[C, D]$ 역시 사상으로 자연 변환을 가지고 있다는 점만 제외하면 두 카테고리 간의 펑터들의 집합이라고 볼 수 있다. 이 카테고리의 대상은 $Cat(C, D)$ 의 원소와 동일하기 때문이다. 게다가 펑터 카테고리 또한 카테고리이기 때문에 Cat의 대상이 되어야 한다. 즉, 우리는 이 관계를 하나의 카테고리 내의 Hom 집합과 대상 간의 관계로 표현할 수 있다는 것이며, 이건 이전 섹션에서 보았던 지수 대상과 정확하게 같은 개념이다.

한번 Cat에서 이 개념을 어떻게 구성할 수 있는지 살펴보자.

지수를 구성하기 위해서는 먼저 곱의 개념을 정의해야 한다는 것을 기억할 것이다. 다행히도 Cat에서는 곱을 정의하기가 비교적 쉽다. 각각의 작은 카테고리들은 대상들의 집합이므로, 곱이라는 개념을 집합의 곱으로 생각해도 무방할 것이다. 따라서 곱 카테고리 $C × D$ 의 대상은 그냥 $C$ 와 $D$ 의 대상들 중 하나씩 뽑아내어 구성된 대상들의 쌍 (c, d)이다.

마찬가지로 두 개의 쌍 (c, d)와 (c', d') 간의 사상은 사상의 쌍 (f, g)으로, 이때 각 사상들은 f :: c -> c'와 g :: d -> d'가 될 것이다. 이러한 사상의 쌍은 성분 별로 합성되고, 항상 항등 사상의 쌍인 항등 쌍 또한 존재할 수 있다. 간단하게 말하자면 Cat은 완전한 데카르트 폐쇄 카테고리이기 때문에 모든 카테고리 쌍에 대한 지수 대상 $D^C$ 를 가진다는 의미이다. 이때 Cat의 대상이라는 것은 결국 카테고리를 의미하므로, 결론적으로 $D^C$ 는 $C$ 와 $D$ 간의 펑터 카테고리라고 말할 수 있다.

10.4 2-카테고리

Cat을 조금 더 자세히 들여다보자. 앞서 언급한 정의에 따라 Cat의 Hom 집합은 펑터들의 집합이다. 하지만 방금 $[C, D]$ 의 사례에서 보았듯이 두 대상 사이의 펑터는 단순한 집합 이상으로 더 풍부한 구조를 지니고 있다. 자연 변환을 사상으로 적용하여 카테고리를 형성할 수도 있기 때문이다. 펑터는 Cat에서 사상으로 간주되므로, 자연 변환은 사상 간의 사상이라고 할 수 있다.

이처럼 더 풍부한 구조가 바로 2-카테고리의 예로, 2-카테고리에는 대상과 사상(또는 1-사상) 외에도 사상과 사상 간의 사상인 2-사상 또한 존재할 수 있다.

즉, Cat를 2-카테고리라고 본다면

대상: 작은 카테고리들
1-사상: 카테고리 간의 펑터
2-사상: 펑터 간의 자연 변환

으로 정의할 수 있다는 것이다.

그렇다면 이제 우리는 두 카테고리 $C$ 와 $D$ 간의 Hom 집합 대신에, Hom 카테고리인 펑터 카테고리 $D^C$ 를 가질 수 있게 된다. 그리고 이 펑터들은 합성될 수도 있다. $D^C$ 의 펑터 $F$ 와 $E^D$ 의 펑터 $G$ 가 합성되어 $E^C$ 의 펑터 $G ◦ F$ 를 얻을 수 있는 것처럼 말이다. 또한 각 Hom 카테고리 내에서 자연 변환 또는 2-사상이라고 부르는 수직 합성 또한 가질 수 있다.

이제 이렇게 두 종류의 합성이 있는 2-카테고리에서 이 합성 체계들이 어떻게 상호작용하는지를 알아보도록 하자.

우선 Cat에서 임의로 두 개의 펑터(1-사상)을 선택해보겠다.

F :: C -> D
G :: D -> E

그리고 이들의 합성은 아래와 같을 것이다.

G ◦ F :: C -> E

그리고 펑터 $F$ 와 $G$ 에 작용하는 두 자연 변환 $α$ 와 $β$ 도 있을 것이다.

α :: F -> F'
β :: G -> G'

이 쌍에는 수직 합성을 적용할 수가 없다. 왜냐하면 $α$ 를 통해 도달한 펑터 $F’$ 가 $β$ 의 소스가 아니기 때문이다. 사실 이들은 $D^C$ 와 $E^D$ 라는 서로 다른 펑터 카테고리의 멤버이다. 하지만 $F’$ 를 통해 도달한 카테고리 $D$ 가 $G’$ 의 소스이기 때문에 이 두 펑터는 합성할 수 있다.

$G ◦ F$ 와 $G’◦ F’$ 는 무슨 관계일까? $α$ 와 $β$ 를 가지고 $G ◦ F$ 에서 $G’◦ F’$ 로 향하는 자연 변환을 정의할 수는 있는 것일까? 다이어그램을 통해 전체적인 구조를 한번 살펴보자.

가장 먼저 $C$ 의 대상인 a에서 부터 출발해보자. 이 대상의 이미지는 카테고리 $D$ 에서 F a와 F'a라는 두 대상으로 나누어진다. 그리고 이때 이 두 대상을 연결하는 자연 변환 $α$ 의 성분인 사상도 함께 생긴다.

α_a :: F a -> F' a

그리고 카테고리 $D$ 에서 $E$ 로 갈 때, 이 두 개의 대상은 네 개의 대상으로 나누어진다.

G (F a), G'(F a), G (F'a), G'(F'a)

이때 이 네 개의 대상을 서로 연결하는 정사각형, 즉 네 개의 사상 또한 생긴다. 그리고 이 사상들 중 두 개는 자연 변환 $β$ 의 성분이다.

β_Fa  :: G (F a) -> G'(F a)
β_F’a :: G (F'a) -> G'(F'a)

그리고 다른 두 개의 사상은 두 펑터에 의한 $α_a$ 의 이미지이다. (펑터는 사상 또한 매핑한다는 사실을 기억하자)

G α_a :: G (F a) -> G (F'a)
G'α_a :: G'(F a) -> G'(F'a)

갑자기 사상이 너무 많아져서 조금 복잡해지긴 했지만, 결국 우리의 목표는 이 중 $G ◦ F$ 와 $G’◦ F’$ 를 연결하는 자연 변환의 성분이 될 수 있는 G (F a)에서 G'(F'a)로 향하는 사상 $(β◦α)_a$ 를 찾는 것이다.

사실 위 다이어그램을 보면 G (F a)에서 G'(F'a)로 가는 경로는 총 두 가지이다.

G'α_a ◦ β_Fa
β_F’a ◦ G α_a

다행히도 이 두 경로는 같기 때문에 위 다이어그램의 정사각형은 $β$ 의 자연성 정사각형이된다.(다이어그램이 가환한다는 의미이다)

이렇게 $G ◦ F$ 에서 $G’◦ F’$ 로 향하는 자연 변환의 성분을 정의해보았다. 그리고 이 변환의 자연성을 증명하는 것은 귀찮은 과정이기는 하지만 꽤나 간단하게 해결이 가능한 부분이다.

그리고 이 자연 변환을 $α$ 와 $β$ 의 수평 합성이라고 부르는 것이다.

β ◦ α :: G ◦ F -> G' ◦ F'

앞서 이야기했듯 이 책은 맥레인의 표기법을 따르고 있기 때문에, 수평 합성에는 작은 원(◦)을 사용한다. 참고로 다른 곳에서는 경우에 따라 별표(*)를 사용하는 경우도 있다.

카테고리 이론을 공부할 때의 원칙 중 하나는 어떠한 합성이 있을 때마다 이 합성이 속한 카테고리도 찾아내야 한다는 것이다. 앞서 언급했던 자연 변환의 수직 합성은 펑터 카테고리의 일부였다. 그렇다면 수평 합성은 어떤 카테고리에 속하는 것일까?

이것을 알아내는 방법은 Cat을 옆으로 보는 것이다. 자연 변환을 펑터 사이의 화살표가 아닌 카테고리 사이의 화살표로 본다. 그럼 이제 자연 변환은 자신이 변환하는 펑터가 연결하는 두 개의 카테고리 사이에 위치한다.

이제 Cat의 두 대상인 $C$ 와 $D$ 사이의 사상은 자신들을 연결해주던 펑터들을 연결하는 자연 변환이 되었다. 마찬가지로 $D$ 에서 $E$ 로 향하는 펑터들을 연결하는 자연 변환도 있을테니, 이를 $D$ 에서 $E$ 로 향하는 새로운 사상으로 간주할 수 있다. 결국 수평 합성은 이러한 관점에서 바라볼 때 사상들의 합성인 것이다.

또한 $C$ 에서 $C$ 로 향하는 항등 사상도 있을 것이다. 이때의 항등 사상은 $C$ 의 항등 펑터를 자기 자신으로 매핑하는 항등 자연 변환이다. 수직 합성에서의 항등 자연 변환은 모든 자연 변환의 수직 합성에 대해서 항등 역할을 할 수 있지만, 수평 합성에서는 항상 그렇지만은 않다는 것을 기억해두자.

마지막으로 두 합성은 교환 법칙을 만족한다.

(β' ⋅ α') ◦ (β ⋅ α) = (β' ◦ β) ⋅ (α' ◦ α)

사운더스 맥레인(Saunders Mac Lane)의 말을 인용하자면 독자들은 이 사실을 증명하기 위해 명확한 다이어그램을 작성하는 것을 즐기게 될지도 모른다고 한다.

나중에 유용하게 사용할 수 있는 표기법이 하나 더 있다. Cat을 옆에서 바라보겠다는 이 해석에서 어떤 대상에서 다른 대상으로 향하는 방법에는 펑터를 사용하는 방법과 자연 변환을 사용하는 두 가지 방법이 있었다. 이때 이 펑터 화살표를 펑터에 작용하는 특수한 종류의 자연 변환인 항등 자연 변환으로 재해석해볼 수도 있다. 그래서 종종 아래와 같은 표기법을 볼 수 있다.

F ◦ α

여기서 $F$ 는 $D$ 에서 $E$ 로 향하는 펑터이고, $α$ 는 $C$ 에서 $D$ 로 향하는 두 펑터 사이의 자연 변환이다. 펑터는 자연 변환과 합성할 수 없기 때문에, 이것은 $α$ 가 작용한 이후 항등 자연 변환 $1_F$ 가 작용하는 수평 합성으로 해석하게된다.

이와 마찬가지로 아래 표기는 항등 자연 변환 $1_F$ 의 작용 이후 자연 변환 $α$ 가 작용하는 것으로 해석하면 된다.

α ◦ F

10.5 결론

이렇게 이 책의 첫 번째 파트를 마쳤다. 이제 우리는 카테고리 이론의 기본적인 용어들을 배웠으며, 대상과 카테고리를 명사로 생각하고 사상, 펑터 그리고 자연 변환을 동사로 생각할 수 있는 역량을 얻었다.

사상은 대상을 연결하고 펑터는 카테고리를 연결하며 자연 변환은 펑터를 연결하는 것처럼 말이다.

하지만 앞서 살펴보았듯이 한 수준의 추상화 단계에서는 동사로 보이는 것이 다음 수준에서는 대상이 되기도 한다. 마치 사상의 집합이 함수 대상이 되었던 것처럼 말이다. 그러면 이제 이 대상은 다시 다른 사상의 출발점이나 목표지점이 될 수 있게 된다. 이것이 우리가 알고있는 고차 함수(Higher Order Function)의 아이디어였다.

펑터는 대상을 대상으로 매핑하기 때문에 이를 타입 생성자 또는 매개변수적 타입으로 사용할 수 있다. 또한 펑터는 사상도 매핑하는데, 이것이 바로 고차 함수인 fmap이다. Const, 곱, 쌍대곱과 같은 간단한 펑터들은 다양한 대수적 데이터 타입을 생성하는데 사용할 수도 있다. 함수 타입 또한 공변 펑터적인 성질과 반공변 펑터적인 성질을 모두 가지고 있으므로 대수적 데이터 타입을 확장하는데 사용할 수 있다.

펑터는 펑터 카테고리에서 대상으로 간주될 수도 있다. 따라서 펑터는 자연 변환의 출발점과 목표가 되며, 자연 변환은 다형성 함수의 특별한 타입이라고 볼 수 있다.

원문 보기

👉 Category Theory for Programmers

[번역] 프로그래머를 위한 카테고리 이론 - 9. 함수 타입

Thu, 18 Apr 2024 10:06:52 GMT

지금까지는 함수 타입의 의미를 간단하게만 설명해왔다. 하지만 조금 더 자세히 들여다보면 함수 타입은 다른 타입과는 약간 다른 특성을 가지고 있다.

예를 들어 Integer 타입은 그냥 정수들의 집합, 그리고 Bool 타입은 두 개의 원소로 이루어진 집합일 뿐이다. 그러나 함수 타입 a -> b은 대상 a와 b 사이에 존재하는 모든 사상들의 집합이다. 어떤 카테고리에서 두 객체 사이의 존재하는 모든 사상들의 집합은 Hom 집합이라고 한다. 그리고 Hom 집합 또한 결국 집합이기 때문에 카테고리 Set(모든 집합의 카테고리)에서는 Hom 집합 또한 Set에 포함된 대상이다.

Hom 집합도 결국 집합이기 때문에 Set에 포함된 대상이다.

Set이 아닌 다른 카테고리에서는 Hom 집합이 카테고리 외부에 있는 경우도 있다. 이런 경우 외부(External) Hom 집합이라고 한다.

이것이 바로 함수 타입을 다른 타입보다 특별하게 만드는 카테고리 Set의 자기 참조적인 성격이다. 이런 카테고리에서는 Hom 집합을 나타내는 대상을 구성할 수 있는 방법이 존재하며, 이러한 대상을 내부(Internal) Hom 집합이라고 한다.

카테고리 C의 Hom 집합은 외부 Hom 집합이다.

9.1 보편적 구성(Universal Construction)

자, 이제 함수 타입이 집합이라는 사실은 잠시 잊고, 함수 타입을 일반화하여 내부 Hom 집합이라고 생각해서 처음부터 구성해보도록 하자. 일반적으로는 Set 카테고리가 이 구성에 대한 단서를 주겠지만, 여기서는 집합의 특성에 의존하지 않고 생각해볼 것이다. 이런 과정을 통해 하나의 구성이 다른 카테고리에 자동으로 적용될 수 있도록 일반화해볼 수 있다.

함수 타입은 인수 타입과 결과 타입과의 관계로 인해 복합적인 타입으로 간주된다. 이미 우리는 곱 타입과 합 타입이라는 대상 간의 관계를 포함하는 복합적인 타입들을 정의하기 위한 보편적 구성(Universal Construction)에 대해서 배웠던 적이 있다. 함수 타입을 정의하는 데도 동일한 방법을 사용해볼 수 있다.

함수 타입을 정의하기 위해서는 구성하려는 함수 타입, 인수 타입, 결과 타입을 모두 포함하는 패턴이 필요하다.

이 세 가지 타입을 연결하는 명확한 패턴은 함수 적용(Function application) 또는 평가(Evaluation)이라고 불린다. 만약 함수 타입의 후보인 대상을 z라고 하고 인수 타입인 대상을 a라고 할 때, 적용(Application)은 이 쌍을 결과 타입인 대상 b로 매핑하는 행위이다. 즉, 우리에게는 총 세 가지 대상이 있으며, 이 중 인수 타입과 결과 타입 두 가지는 고정되어있는 것이다.

우리는 매핑인 적용도 가지고 있다. 어떻게 하면 이 매핑을 이 패턴에 통합할 수 있을까? 만약 우리가 대상 내부를 들여다볼 수 있다면, 집합 z의 원소인 함수 f와 집합 a의 원소인 인수 x를 짝지어 집합 b의 원소인 f x로 매핑할 수 있게 된다.

함수 집합 z에서 함수 f를 선택하고, 인수 타입 a의 집합에서 하나의 인수 x를 선택한다.
그러면 이제 집합 b에서 원소 f x를 얻을 수 있게된다.

그러나 이렇게 하나의 쌍인 (f, x)를 다루는 것보다는 함수 타입 z와 인수 타입 a의 전체적인 곱에 대해서 이야기하는 것이 더 일반화된 개념일 것이다. 곱 z×a 또한 하나의 대상이며, 이 대상에서 b로의 화살표인 우리의 적용 변형으로 g를 선택할 수 있다. Set에서는 g가 모든 쌍 (f, x)를 f x로 매핑하는 함수가 될 것이다.

두 대상 z와 a의 곱이 사상 g에 의해 다른 대상 b로 연결되는, 이것이 바로 패턴이다.

정말 이 패턴이 보편적 구성을 통해 함수 타입을 명확하게 정의할 수 있는 것일까? 사실 모든 카테고리에 대해서 생각해본다면 그렇지 않을 수도 있다. 하지만 우리가 지금 다루고자 하는 카테고리에 대해서는 충분하다.

그렇다면 또 다른 질문을 해보자. 과연 우리는 곱을 먼저 정의하지 않고도 함수 대상을 정의할 수 있을까? 모든 쌍의 대상에 대해 곱이 없는 카테고리나 모든 쌍의 곱이 존재하지 않는 카테고리도 있지 않은가? 정답은 “아니다”이다. 곱 타입이 없다면 함수 타입도 존재할 수 없다. 이에 대한 내용은 추후 지수(Exponentials)에 대해 설명하며 다시 다루도록 하겠다.

이 그림이 바로 보편적 구성의 시작점인 대상과 사상의 패턴이다.

한번 보편적 구성에 대해 검토해보자. 우선 대상과 사상의 패턴에서부터 시작할 것이다. 물론 그저 대상과 사상의 패턴이라고만 하면 굉장히 많은 결과가 매칭될 것이기 때문에 이대로는 상당히 부정확한 쿼리라고 할 수 있다.

Set에서는 거의 모든 것이 서로 연결되어있다. 어떤 대상 z와 대상 a의 곱을 형성할 수도 있으며, 이 곱에서 b로의 함수도 존재할 수 있다. (단, b가 빈 집합일 경우는 제외한다.)

이제 이 패턴의 결과들에 대한 순위를 매긴다는 비밀무기를 꺼내볼 차례이다. 일반적으로 후보 대상들 사이에는 이 구성을 어떤 방식이로든 분해할 수 있는 고유한 매핑이 있어야 한다.

필자는 z와 z×a에서 b로 향하는 사상 g가 z'와 이에 적용되는 사상 g’보다 우수하다고 결정할 것이다. 그리고 만약 이 결정이 참이라면 z'에서 z로 향하는 유일한 사상 h이 존재해야 할 것이다. 그리고 이 사상은 g'를 적용한 결과와 g를 적용한 결과가 동일하다는 것 또한 보장해야한다. (잘 이해되지 않는다면 아래 그림을 보면서 이 문장을 읽어보자.)

함수 대상에 대한 후보들 간의 순위를 결정한다.

여기가 조금 어려운 부분인데, 이게 바로 필자가 이 보편적 구성에 대한 정의를 계속 질질 끌고 있던 이유이다. 사상 h :: z'-> z가 주어졌을 때 우리는 z’와 z가 모두 a와 연결되어있는 다이어그램을 닫기를 원한다.

💡 역주

다이어그램을 닫는다는 이야기가 이해하기 어렵다면, 자료구조 그래프를 떠올려보면 된다. 여기서 z’와 z가 모두 연결되어있는 다이어그램을 닫고 싶다는 의미는, z→a, z’→a, z’→z처럼 연결되어있고 다른 대상들과는 이어지지 않은 그래프를 만들고 싶다는 의미이다.

이를 위해 필요한 것은 z’에서 z로 향하는 매핑 h가 주어졌을 때, 이를 이용해서 z'×a에서 z×a로의 매핑을 얻어내는 것이다. 앞서 곱의 함수적인 특징에 대해 논의했었으니, 이제 이 과정에 대해 이해할 수 있을 것이다.

곱 자체는 펑터, 정확하게는 엔도 이항 펑터이기 때문에 쌍에 대한 사상을 리프팅할 수 있다. 다른 말로 하면 우리는 대상의 곱 뿐만 아니라 사상의 곱도 정의할 수 있다는 것이다.

이를 리프팅하기 위해 곱 z'×a의 두 번째 구성 요소인 a에는 아무런 영향을 끼치지 않아야 하므로, a에 대한 항등사상인 id를 사용하여 사상의 쌍 (h, id)를 리프팅할 것이다.

g’를 g가 포함된 식으로 인수 분해하는 방법은 다음과 같다.

g' = g ◦ (h × id)

여기서의 핵심은 곱이 사상에 대해서 어떻게 작용하고 있는지를 보는 것이다.

보편적 구성의 세 번째 파트는 보편적으로 가장 좋은 대상을 선택하는 것이었다. 필자는 이 대상을 a ⇒ b라고 부를 것이다. (참고로 이건 어떤 대상에 대한 상징적인 이름이며, Haskell 타입 클래스 제약과는 관련없는 네이밍이다. 추후에 조금 더 다양한 방법으로 이름을 지을 수 있는 방법에 대해 논의해보겠다.)

a ⇒ b라는 대상은 (a ⇒ b) × a 에서 b로 향하는 사상인 eval이라는 적용을 가지고 있다. 만약 다른 함수 대상 후보로부터 출발하는 사상 g가 eval을 포함한 식으로 분해되어 이 대상에 유일하게 매핑될 수 있다면, 대상 a ⇒ b가 가장 적합한 후보라고 할 수 있을 것이다.

이것이 보편적 구성을 통한 함수 대상의 정의이다. 위 그림과 동일한 다이어그램이지만 이제 대상 a ⇒ b가 가장 보편적이게 되었다.

한번 정리해보자.

a에서 b로 향하는 함수 대상은 대상 a ⇒ b와 사상 eval :: ((a ⇒ b) × a) -> b 으로 정의된다. 만약 임의의 다른 대상 z × a에서 b로 향하는 사상 g :: z × a -> b가 주어진다면, z에서 a ⇒ b로 향하는 유일한 사상 h :: z -> (a ⇒ b)이 존재해야하고, 최종적으로 g는 eval을 포함한 식으로 분해될 수 있어야 한다.

g = eval ◦ (h × id)

물론 모든 카테고리에서 반드시 임의의 대상의 쌍 a와 b에 대해 대상 a ⇒ b가 반드시 존재할 것이라는 보장은 없다. 하지만 최소한 Set에서만큼은 항상 존재한다. 게다가 이 대상은 Set의 Hom 집합인 $Set(a,b)$ 와도 동형이다.

9.2 커링(Currying)

함수 대상에 대한 후보를 다시 한번 살펴보자. 그러나 이번에는 사상 g를 두 변수 z와 a에 대한 함수로 생각해볼 것이다.

g :: z × a -> b

대상의 곱으로부터 출발한 사상은 두 개의 변수를 가진 함수와 유사한 형태를 가지고 있다. Set에서 g는 집합 z과 집합 a에서 값을 하나씩 가져와 구성한 쌍에서 출발하게 될 것이다.

그리고 함수 g가 가진 보편적인 속성에 따라 각각의 g에 대해 z를 함수 대상 a ⇒ b로 매핑하는 유일한 사상 h 또한 존재한다는 것을 떠올려볼 수 있다.

h :: z -> (a b)

Set에서는 단순히 h가 타입이 z인 변수를 하나 받아 a에서 b로 향하는 함수를 반환하는 함수임을 의미한다. 이러한 정의는 h를 고차함수(Higher ordered function)로 만든다.

따라서 보편적 구성은 이변수 함수와 함수를 반환하는 일변수 함수 간의 일대일 대응을 설정한다. 이 대응은 커링(Currying)이라고 불리며, h는 g의 커링된(Curried) 버전이라고 한다.

이처럼 어떤 g가 주어졌을때 유일한 h가 존재하고, 어떤 h가 주어질 때도 아래의 공식을 이용하여 이변수 함수인 g를 다시 생성할 수 있기 때문에 일대일 대응이라고 할 수 있다.

g = eval ◦ (h × id)

이때 함수 g는 h의 커링되지 않은(Uncurried) 버전이라고 할 수 있다. 사실 커링은 함수가 함수를 반환하는 Haskell의 구문만으로도 표현할 수 있다.

a -> (b -> c)

이런 문법은 보통 아래와 같이 괄호가 제거된 시그너치를 통해 이변수 함수로 해석된다.

a -> b -> c

이러한 해석은 다인수 함수를 정의할 때 명확하게 확인해볼 수 있다. 예를 들어 아래와 같은 함수처럼 말이다.

catstr :: String -> String -> String
catstr s s' = s ++ s'

이 함수는 하나의 인수를 받아 다시 함수를 반환하는 형태로도 작성할 수 있다. 만약 람다로 표현하면 다음과 같을 것이다.

catstr' s = \s' -> s ++ s'

이 두 정의는 동등하며, 두 정의 중 어떤 것을 사용하든 하나의 인수에 대해 부분 적용되어 아래와 같이 하나의 인수를 받은 함수를 생성할 수 있다.

greet :: String -> String
greet = catstr "Hello "

엄밀히 말하자면 이변수 함수는 곱 타입인 쌍을 받는 함수이다.

(a, b) -> c

이 두 개의 표현 간의 변환은 간단하다. 이미 예상했겠지만 이러한 변환을 수행하는 두 개의 고차함수는 curry와 uncurry로 불린다.

curry :: ((a, b) -> c) -> (a -> b -> c)
curry f a b = f (a, b)

uncurry :: (a -> b -> c) -> ((a, b) -> c)
uncurry f (a, b) = f a b

curry가 함수 대상의 보편적 구성을 위한 인수분해(factorization)라는 점에 주목하자. 이 점은 아래와 같은 형태로 다시 작성해보면 더 명확하게 알 수 있다.

factorizer :: ((a, b) -> c) -> (a -> (b -> c))
factorizer g = \a -> (\b -> g (a, b))

다시 한번 짚고 넘어가자면 factorizer라는 인수분해 행위는 후보로부터 분해 함수를 생성한다.

C++과 같이 함수형 언어가 아닌 언어에서도 커링이 가능하기는 하지만 일이 조금 복잡해진다. C++에서의 다인수 함수는 Haskell에서 튜플을 받는 함수에 해당한다고 볼 수 있다. (여기서 더 혼란스러운 점은 C++에서 명시적으로 std::tuple을 받는 함수, 가변 인수 함수, 초기화 리스트를 받는 함수를 정의할 수 있다는 점이다.)

C++ 함수를 부분 적용하려면 템플릿 std::bind를 사용하면 된다. 예를 들어 아래와 같이 두 개의 문자열을 받는 함수가 있다고 생각해보자.

std::string catstr(std::string s1, std::string s2) {
    return s1 + s2;
}

그럼 이 함수와 std::bind를 사용하여 하나의 문자열을 받는 함수를 정의해볼 수 있다.

using namespace std::placeholders;

auto greet = std::bind(catstr, "Hello ", _1);
std::cout << greet("Haskell Curry");

Scala는 C++이나 Java에 비하면 함수형 프로그래밍에 더 가깝긴 하지만, 사실은 애매한 어딘가에 위치하고 있다. 만약 함수가 부분 적용되도록 작성하려면 아래처럼 여러 인수의 목록으로 정의할 수 있다.

def catstr(s1: String)(s2: String) = s1 + s2

물론 이 코드는 이 함수가 확실히 부분 적용될 것이라는 것을 가정하기 때문에 프로그래머의 예지력에 의존하고 있지만 말이다.

9.3 지수(Exponentials)

수학 논문에서 함수 대상 또는 두 대상 a와 b 사이의 내부 Hom 대상은 종종 지수(Exponential)로 불리며 ba라고 표기된다. 처음에는 이 표기법이 조금 어색해보일 수 있지만, 함수와 곱의 관계를 생각해보면 그렇게 이상한 것도 아니다. 이미 내부 Hom 대상의 보편적 구성에서 곱이 필요하다는 것을 한 차례 확인했지만, 사실 이 둘 간의 연결은 더 심오하다.

이 연결은 Bool, Char, Int, Double과 같이 유한한 값을 가지는 집합 간의 함수를 고려해볼 때 제대로 확인해볼 수 있다. 이러한 함수들은 원론적으로 완전히 메모아이징(Memoizing)될 수 있거나 데이터 구조로 변환되어 조회될 수도 있다. 이것이 바로 사상으로써의 함수와 대상으로써의 함수 타입 간 동등성의 본질이다.

예를 들어 Bool에서의 순수 함수는 False에 해당하는 값과 True에 해당하는 값의 쌍에 의해 완전히 특정화된다. Bool에서 Int로 향하는 모든 함수의 집합은 모든 Int 쌍들의 집합이다. 이것은 곱 Int × Int, 조금 더 창의적으로 표기해보자면 Int2와 동일하다.

다른 예시로 C++의 타입인 char를 한번 살펴보자. 이 타입은 총 256개의 값을 포함하고 있다.

C++ 표준 라이브러리의 isupper, isspace와 같은 일부 함수들은 테이블 조회를 사용하여 구현되며, 이 테이블은 256개의 부울 값들의 튜플과 동등하다. 튜플은 곱 타입이므로 우리는 bool × bool × bool × ... × bool과 같은 256개의 부울의 곱을 떠올려볼 수 있다.

그리고 우리는 이렇게 반복적인 곱이 곧 지수(Exponential)을 정의한다는 사실을 알고 있다. 만약 bool을 char 타입이 가진 값의 개수인 256번만큼 곱한다면, bool을 char만큼 거듭제곱한 것, 즉, boolchar를 얻을 수 있다.

그렇다면 bool의 256 튜플로 정의된 타입에는 얼마나 많은 값이 존재하는 것일까? 정확하게 $2^{256}$ 개이다. 이는 char에서 bool로 향하는 서로 다른 함수들의 개수와도 동일하며, 각 함수는 고유한 256 튜플에 해당된다.

비슷한 방식으로 bool에서 char로 향하는 함수의 개수도 계산해보면 $256^2$ 개라는 사실을 알 수 있다. 함수 타입에 대한 지수 표기법은 이런 의미를 가지고 있는 것이다.

아마 우리는 int나 double에서 출발하는 함수를 모두 메모아이즈하고 싶어하지는 않을 것이다. 하지만 비록 실용적이지 않더라도 함수와 데이터 타입 사이의 동등성은 명확히 존재한다.

그리고 리스트, 트리, 문자열과 같은 무한한 타입도 있다. 이러한 타입에서 출발하는 함수를 메모아이즈하기 위해서는 무한한 저장 공간을 필요로 한다.

그러나 Haskell은 게으른 언어이므로, 게으르게 평가되는 무한한 데이터 구조와 함수 사이의 경계는 모호하게 다가온다. 이러한 함수와 데이터 간의 쌍대성은 함수 타입을 카테고리론적 지수 대상과 동일시 할 수 있다는 것을 설명한다. 이러한 특성은 우리가 가진 데이터에 대한 개념과도 일치하기 때문에 Haskell에서는 함수를 데이터처럼 취급할 수 있다.

9.4 데카르트 닫힌 카테고리(Cartesian Closed Categories)

물론 필자는 계속 집합의 카테고리를 타입과 함수의 모델로 사용할 것이지만, 이런 목적으로 사용할 수 있는 더 큰 카테고리 패밀리가 있다는 것을 언급하는 것은 충분히 가치가 있을 것 같다. 이런 카테고리는 데카르트 닫힌 카테고리(Cartesian closed categories)라고 하며, Set은 그저 이 카테고리 중 하나의 예일 뿐이다.

데카르트 닫힌 카테고리는 아래 세 가지를 반드시 포함하고 있어야 한다.

종결 대상
어떤 두 대상의 곱
어떤 두 대상의 지수

지수를 무한히 많은 횟수로 반복되는 곱이라고 간주한다면, 데카르트 닫힌 카테고리는 임의의 항수를 지원하는 것이라고 생각할 수 있다. 특히 종결 대상은 곱의 항등원(0)인 대상의 곱 또는 대상의 항등원(0) 승이라고 볼 수 있다.

컴퓨터 과학의 관점에서 데카르트 닫힌 카테고리들이 흥미로운 이유는 이 카테고리들이 간단하게 타이핑된 람다 미적분법의 모델을 제공하고 있기 때문이다. 이 모델은 타입을 사용하는 모든 프로그래밍 언어의 기초를 형성한다.

종결 대상과 곱 연산에는 각각 초기 대상과 합 연산이라는 쌍대(Dual)가 존재한다.

a × (b + c) = a × b + a × c
(b + c) × a = b × a + c × a

이 두 요소를 지원하고 곱이 합을 통해 분배될 수 있는 데카르트 닫힌 카테고리를 이중 데카르트 닫힌 카테고리(Bicartesian closed category)라고 한다. 다음 섹션에서 보겠지만 우리가 계속 다뤄온 Set이 대표적인 이중 데카르트 닫힌 카테고리이며, 이 카테고리는 몇 가지 흥미로운 특성을 가지고 있다.

9.5 지수와 대수적 자료형(Exponentials and Algebraic Data Types)

함수 타입을 지수로 해석하는 것은 대수적 자료형의 체계에 아주 잘 들어맞는다. 실제로 고등학교에서 배우는 대수학에서 나오는 숫자 0과 1, 합, 곱, 그리고 지수와 관련된 기본적인 항등식은 각각 초기 대상, 종결 대상, 합집합, 곱집합 그리고 지수에 대해 거의 그대로 적용된다는 것을 볼 수 있다.

우리는 아직 이 성질을 제대로 증명할만한 수반(Adjunction)이나 요네다 보조정리같은 도구를 가지고 있지는 않지만, 그럼에도 불구하고 독자 여러분께 직관을 제공하기 위해 일단 쭉 설명해보겠다.

9.5.1 0승

a^0 = 1

카테고리적 해석에서 우리는 0을 초기 대상으로, 1을 종결 대상으로, 그리고 등식을 동형사상으로 대체한다. 여기서 지수는 내부 Hom 대상을 의미하기 때문에 결국 $a^0$ 이라는 식은 초기 대상에서 임의의 대상 a로 향하는 사상의 집합을 나타낸다. 초기 대상의 정의에 따라 이런 사상은 정확히 하나만 존재할 수 있으므로 Hom 집합 $C(0,a)$ 는 단일 원소 집합이다.

단일 원소 집합은 Set에서의 종결 대상이므로, 이 항등식은 Set에서 쉽게 성립할 수 있다. 여기서 중요한 것은 이 항등식이 이중 데카르트 닫힌 카테고리의 모든 경우에 대해서 성립한다는 것이다.

Haskell에서는 0을 Void로, 1을 유닛 타입인 ()으로 대체한다. 결국 필자가 앞에서 했던 주장은 Void에서 임의의 타입 a로 향하는 함수의 집합이 유닛 타입과 동등하다는 것이다. 다시 말하자면 Void -> a 함수는 하나뿐이라는 것이다. 그리고 우리는 이미 이 함수를 예전에 본 적이 있다. 바로 absurd 함수이다.

그러나 이것을 현실에 구현하기는 약간 까다롭다. 이유는 크게 두 가지인데, 첫째로 Haskell에서는 실제로 어떤 값도 속하지 않는 타입이라는게 존재하지 않는다. 모든 타입은 “끝나지 않는 계산의 결과” 또는 Bottom(_|_)을 포함하기 때문이다.

두번째 이유는 absurd에는 어떤 값도 전달할 수 없기 때문에 누가 무슨 짓을 하던 결국 아무도 실행시킬 수 없다는 점이다. 결국 이 함수의 구현은 근본적으로 모두 동등하다는 것이다. 그렇다고 해서 만약 영원히 끝나지 않는 계산을 전달한다면 이 함수는 결코 반환이라는 행위까지 도달하지 못할 것이다.

9.5.2 1의 지수

1^a = 1

위 식은 Set에서 해석될 때 모든 대상에서 종결 대상으로 향하는 고유한 사상이 존재한다는 종결 대상에 대한 정의를 다시 한번 표현하고 있다. 일반적으로 a에서 종결 대상으로 향하는 내부 Hom 대상은 종결 대상과 동형이다.

Haskell에서 임의의 타입 a에서 유닛으로 향하는 함수는 a -> () 단 하나 뿐이다. 우리는 이 함수를 unit이라고 부른다는 것을 이미 알고 있다. 이 함수는 ()에 부분 적용된 const 함수로 생각할 수도 있다.

9.5.3 1승

a^1 = a

위 식은 종결 대상으로부터 출발하는 사상은 대상 a의 원소를 선택하는데 사용될 수 있다는 것을 다시 표현한 것이다. 이러한 사상들의 집합은 대상 자체와 동형이다. Set, 그리고 Haskell에서는 집합 a의 원소들과 해당 원소들을 선택하는 함수들인 () -> a가 동형이라는 것이다.

9.5.4 지수의 합

a^{b+c} = a^b ×a^c

카테고리론적으로 위 식은 대상의 두 지수의 합이 각 지수를 가진 대상들의 곱과 동형이라는 것을 의미한다.

이 대수적 동형성을 Haskell에서 다루게 되면 매우 실용적인 해석을 가져다준다. 이는 두 타입의 합으로부터 출발하는 함수가 각각의 타입으로부터 출발하는 함수의 쌍과 동등하다는 것을 의미하기 때문이다.

이 개념이 바로 우리가 합에 대한 함수를 정의할 때 사용하는 문법의 근원이다. 우리는 합을 의미하는 Either를 정의할 때 case 문을 사용하여 함수를 정의하지 않고, 각각의 타입 생성자를 따로 처리하는 두 개, 혹은 그 이상의 함수로 나눈다.

예를 들어 합 타입(Either Int Double)를 한번 살펴보자.

f :: Either Int Double -> String

이 경우 Either는 각각 Int와 Double에 대한 함수의 쌍으로 정의될 수 있다.

f (Left n) = if n < 0 then "Negative int" else "Positive int"
f (Right x) = if x < 0.0 then "Negative double" else "Positive double"

9.5.5 지수의 지수

(a^b)^c = a^{b×c}

위 식은 지수 대상들에 대한 커링(Currying)을 표현하고 있다. 함수가 함수를 반환하는 것은 곱에서 출발하는 함수, 즉 이변수 함수와 동등하다.

9.5.6 곱의 지수

(a×b)^c =a^c × b^c

Haskell에서 쌍을 반환하는 함수는 각 쌍의 요소 하나를 생성하는 두 함수의 쌍과 동등하다.

이처럼 고등학교에서 배우는 대수학의 간단한 항등식들이 카테고리 이론으로 확장되어 함수형 프로그래밍에서 실용적으로 적용될 수 있다는 것은 굉장히 놀라운 일이다.

9.6 커리-하워드 동형사상(Curry-Howard Isomorphism)

필자는 이미 논리와 대수적 자료형 간의 대응 관계에 대해 언급한 적이 있다. Void 타입과 유닛 타입(())은 각각 거짓과 참에 해당하며, 곱 타입과 합 타입은 논리곱(AND)과 논리합(OR)에 해당한다. 이 체계에서 함수 타입은 논리적 함의(⇒)에 해당한다. 다시 말해 타입 a -> b는 “만약 a라면 b이다”라고 읽을 수 있다.

커리-하워드 동형사상에 따르면 모든 타입은 참 또는 거짓일 수 있는 명제, 즉 진술이나 판단으로 해석될 수 있다. 해당 타입이 존재하면 그 명제는 참으로 간주되고, 존재하지 않으면 거짓으로 간주된다. 특히 논리적 함의가 참이라는 것은 그에 해당하는 함수 타입이 존재한다는 것을 의미하며, 그 타입의 함수가 실제로 존재한다는 것을 의미한다.

따라서 함수의 구현 자체가 정리의 증명이 되는 것이며, 우리가 프로그램을 작성하는 것은 정리를 증명하는 것과 동등하다. 한번 몇 가지 예시를 살펴보자.

함수 대상의 정의에서 소개했던 eval 함수를 살펴보도록 하겠다. eval의 시그니처는 다음과 같다.

eval :: ((a -> b), a) -> b

이 함수는 함수와 그 인자로 구성된 쌍을 받아 적절한 타입의 결과를 반환한다. 즉 위 코드는 사상에 대한 Haskell에서의 구현이다.

eval :: (a ⇒ b) × a -> b

위 표현은 함수 타입 a ⇒ b (또는 지수 대상 ba)를 정의한다. 이 서명을 커리-하워드 동형사상을 사용하여 논리적 술어로 번역해보자.

((a ⇒ b) ∧ a) ⇒ b

이 명제는 만약 b가 a로부터 도출되는 것이 참이고, a 또한 참이라면, b 또한 반드시 참이어야 한다고 읽을 수 있다. 이는 직관적으로 완벽한 의미를 가지고 있으며 고대부터 전건 긍정(*modus ponens)*라고 불려왔다. 이제 다음 함수를 구현함으로써 이 정리를 증명할 수 있다.

eval :: ((a -> b), a) -> b
eval (f, x) = f x

a를 받아서 b를 반환하는 함수 f와 타입 a의 구체적인 값 x로 구성된 쌍을 제공한다면, 함수 f를 x에 적용함으로써 타입 b의 구체적인 값을 생성할 수 있다.

즉, 필자는 이 함수를 구현함으로써 타입 ((a -> b), a) -> b가 실제로 존재한다는 것을 보였다. 따라서 우리의 논리에서 전건 긍정(modus ponens)는 참이다.

그렇다면 명백하게 거짓인 술어는 어떨까? 예를 들어 “만약 a 또는 b가 참이면, a는 반드시 참이어야 한다”와 같은 명제가 있다.

a ∨ b ⇒ a

이는 명백하게 잘못된 명제이다. 왜냐하면 이 명제대로라면 a가 거짓이고 b가 참인 상황도 존재할 수 있기 때문이다. 이 술어를 커리-하워드 동형사상을 사용하여 함수 시그니처로 매핑하면 다음과 같은 결과를 얻을 수 있다.

Either a b -> a

사실 아무리 시도를 하더라도 이 함수는 절대 구현할 수 없다. Right 값으로 호출되었을 때는 a 타입의 값을 생성할 수 없기 때문이다. (우리가 순수 함수에 대해서만 이야기하고 있다는 점을 기억하자)

이제 드디어 absurd 함수의 진짜 의미에 대해 이야기할 때가 되었다.

absurd :: Void -> a

만약 Void가 “거짓”이라고 번역된다고 생각해보면 우리는 아래와 같은 술어를 얻을 수 있다.

false ⇒ a

거짓에서는 어떤 것이든 따라올 수 있다(ex falso quodlibet). 여기 Haskell에서 이 명제(함수)를 증명(구현)할 수 있는 한 가지 예시가 있다.

absurd (Void a) = absurd a

Haskell에서 Void는 다음과 같이 정의된다.

newtype Void = Void Void

Void 타입은 까다로운 녀석이다. 이 정의는 Void 타입의 값을 생성하기 위해서는 Void 타입의 값이 필요하다는 의미를 가지고 있기 때문에 절대 값을 구성할 수 없게 만든다. 결국 Void 타입의 값이라는 것은 존재할 수가 없으므로 absurd 함수는 절대 호출될 수가 없는 것이다.

💡 역주

“거짓에서는 어떤 것이든 따라올 수 있다”라는 뜻의 ex falso quodlibet는 거짓 명제로부터는 어떤 명제라도 유도될 수 있다는 것을 의미하며, 이는 논리학에서 매우 중요한 원칙 중 하나이다.

쉽게 말하자면 거짓인 전제가 주어진다면, 그 전제로부터 나오는 어떠한 결론도 모두 정당화될 수 있다는 것이다.이와 마찬가지로 absurd 함수는 절대 생성될 수 없는 값의 타입인 Void를 인자로 받아 임의의 타입 a를 반환할 수 있다고 선언된다.

즉, 거짓으로부터 출발했으니 어떤 타입을 반환하더라도 논리가 깨지지는 않는 것이다.참고로 absurd 함수는 절대 호출될 수가 없기 때문에 실제로 사용될 수는 없고, 순수하게 프로그래밍 언어의 타입 시스템의 원리를 설명하기 위한 이론적인 목적으로만 사용된다.

물론 이 예시들이 모두 흥미롭기는 하지만, 도대체 커리-하워드 동형사상이 우리에게 어떤 실용적인 혜택을 가져다준다는 것일까? 아마도 일상적인 프로그래밍에서는 아니겠지만, Agda나 Coq와 같은 프로그래밍 언어들은 정리를 증명하기 위해 커리-하워드 동형사상을 활용한다.

컴퓨터는 수학자들이 그들의 일을 하는데 도움을 주는 것뿐만 아니라, 수학의 근본을 혁신하고 있다. 이러한 분야에서 가장 최근에 뜨거운 감자로 떠오르는 연구는 호모토피 타입 이론이라고 하며, 타입 이론의 발전에 큰 기여를 하고있다. 이 이론은 Boolean, Integer, 곱과 쌍대곱, 함수 타입 등으로 가득 차 있다. 그리고 이러한 이론은 Coq와 Agda에서 공식적으로 도입되고 있다.

이처럼 컴퓨터는 여러 방면에서 세상을 혁신하고 있다.

원문 보기

👉 Category Theory for Programmers