Evans Library

When AI Writes the Code, a Developer's Real Skills Show

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.

AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다

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

[번역] 프로그래머를 위한 카테고리 이론 - 8. 펑터의 특성

Tue, 02 Apr 2024 05:29:53 GMT

이제 펑터가 무엇인지 알았으니, 작은 펑터로부터 큰 펑터를 구축해나가는 방법에 대해서 살펴보도록 하겠다.

여기서 특히 흥미로운 부분은 카테고리 내 대상 간의 매핑에 대당하는 타입의 생성자가 확장되어 사상 간의 매핑을 포함하는 펑터가 되는 과정을 볼 수 있다는 것이다.

8.1 이항 펑터(Bifunctors)

펑터는 카테고리들의 카테고리인 Cat에서의 사상이기 때문에 사상에 대한 많은 직관들 특히 함수에 대한 직관들은 펑터에도 그대로 작용한다고 할 수 있다.

예를 들어 두 개의 인수를 가지는 함수가 있듯이, 두 개의 인수를 가지는 펑터인 이항 펑터(Bifunctors)도 존재할 수 있다. 먼저 대상에 대해서만 생각해보자면 이항 펑터는 카테고리 $C$ , 그리고 카테고리 $D$ 의 각각의 대상으로 이루어진 모든 쌍을 카테고리 $E$ 의 대상으로 매핑하는 펑터이다. 즉, 이항 헝터는 $C×D$ 로 표현되는 $C$ 와 $D$ 의 데카르트 곱에서 $E$ 로의 매핑이라고 볼 수 있는 것이다.

사실 여기까지는 매우 간단하게 이해할 수 있다. 그러나 펑터의 특성상 이항 펑터는 대상 뿐만 아니라 사상 또한 매핑할 수 있어야 한다. 즉, 하나는 $C$ 에서 다른 하나는 $D$ 에서 가져온 사상의 쌍을 $E$ 의 사상으로 매핑해야 한다는 것이다.

한번 더 이야기하자면, $C$ 와 $D$ 가 가진 사상의 쌍은 카테고리 $C×D$ 의 단일한 사상이다. 우리는 데카르트 곱 카테고리에서의 사상을 어떤 대상의 쌍에서 다른 대상의 쌍으로 이동하는 사상의 쌍으로 정의할 수 있다. 이러한 사상의 쌍들은 아래와 같은 방식으로 합성도 가능하다.

(f, g) ◦ (f', g') = (f ◦ f', g ◦ g')

합성은 결합법칙을 만족하며, (id, id)와 같은 항등원 또한 존재한다. 이처럼 데카르트 곱 카테고리는 카테고리의 기본적인 법칙을 모두 만족하기 때문에 실제로 하나의 카테고리가 될 수 있는 것이다.

이항 펑터에 대해서 더 쉽게 이해하려면 이 펑터가 두 인자 모두에 대한 펑터라는 점을 이해하는 것에서부터 출발해야한다. 즉, 펑터 법칙인 결합성과 항등 보존에 대한 개념을 곧바로 이항 펑터와 연결하고 확인해보려고 시도하는 것보다는, 이항 펑터가 가진 각 인자에 대해 하나씩 확인해보는 것이 더 이해하기 쉽다는 것이다.

만약 한 쌍의 카테고리로부터 세 번째 카테고리로의 매핑이 있고, 그 매핑이 각 인자에 대해 펑터적(Functorial)이라는 사실을 만족한다는 사실을 증명한다면, 해당 매핑은 자동으로 이항 펑터가 된다. 여기서 펑터적이라는 의미는 이 펑터가 사상에 대해서 제대로 된 펑터처럼 작동한다는 것을 의미한다.

Haskell에서 이항 펑터를 한번 정의해보자. 이 경우에는 세 개의 카테고리가 모두 Haskell 타입의 카테고리이기 때문에 사실상 같은 카테고리라고 볼 수 있다. 이항 펑터는 두 개의 타입 인자를 가지는 타입 생성자로 표현된다. 아래는 라이브러리 Control.Bifunctor에서 직접 가져온 Bifunctor 타입 클래스의 정의이다.

class Bifunctor f where
    bimap :: (a -> c) -> (b -> d) -> f a b -> f c d
    bimap g h = first g . second h
  	first :: (a -> c) -> f a b -> f c b
  	first g = bimap g id
  	second :: (b -> d) -> f a b -> f a d
  	second = bimap id

타입 변수 f는 이항 펑터를 나타내며, 아래 정의된 모든 타입 시그니처에서 이 타입 변수가 항상 두 개의 타입 인자에 적용되는 것을 볼 수 있다.

첫 번째 타입 시그니처는 bimap을 정의하는데, 이것은 두 함수의 매핑을 한 번에 나타낸다. 결과는 이항 펑터의 타입 생성자에 의해 생성된 타입들에서 동작하는 함수 (f a b -> f c d)이다. bimap은 first와 second를 사용하여 구현되어 있는데, 이는 이항 펑터가 각각의 인자에 대해 펑터적으로 작동한다는 사실을 정의하는 것만으로도 이항 펑터를 정의할 수 있다는 사실을 보여준다.

bimap

first와 second는 각각 첫 번째와 두 번째 인자에 대한 f의 펑터적인 성질을 증명하는 두 개의 fmap이다.

first second

타입 클래스 정의는 bimap을 기반으로 두 개의 함수에 대한 기본 구현을 제공한다.

Bifunctor의 인스턴스를 선언할 때는 bimap을 구현하고, first와 second의 기본 값을 사용하거나, 반대로 first와 second를 모두 구현하고 bimap의 기본 값을 사용하는 선택권을 가질 수 있다. (물론 세 가지 모두를 구현할 수는 있겠지만, 그러면 이들이 위와 같은 성질을 가질 수 있도록 보장해줘야 한다.)

8.2 곱과 합 이항 펑터(Product and Coproduct Bifunctors)

이항 펑터의 예시 중 특히 중요한 것은 카테고리적 곱(Categorical Product)이다. 이는 두 대상의 곱으로, 보편적 구성(Universial Construction)에 의해 정의된다. 만약 어떤 두 대상에 대한 곱이 존재한다면, 해당 대상들에서 곱으로의 매핑은 이항 펑터적(Bifunctorial)이다. 이것은 일반적으로 참이며, 특히 Haskell에서도 마찬가지이다.

아래는 가장 간단한 곱 타입인 쌍 생성자에 대한 Bifunctor 인스턴스이다.

instance Bifunctor (,) where
    bimap f g (x, y) = (f x, g y)

여기서 bimap은 단순히 쌍의 첫 번째 구성 요소에 첫 번째 함수를 적용하고, 두 번째 구성 요소에는 두 번째 함수를 적용하고 있기 때문에, 딱히 고민할만한 부분이 없다. 이렇게 명확하고 간단한 동작이 요구사항으로 주어진다면 코드 작성 자체는 간단하다.

bimap :: (a -> c) -> (b -> d) -> (a, b) -> (c, d)

여기서 이항 펑터의 작용은 타입들의 쌍을 만드는 것이다. 예를 들면 이런 것이다.

(,) a b = (a, b)

쌍대성에 의해 이 정의가 카테고리 내의 모든 대상 쌍에 대해서 정의된다면, 합(Coproduct) 또한 이항 펑터라고 할 수 있다. Haskell에서는 Either 타입 생성자를 Bifunctor의 인스턴스인 것으로 나타낼 수 있다.

instance Bifunctor Either where
    bimap f _ (Left x) = Left (f x)
    bimap _ g (Right y) = Right (g y)

워낙 동작이 간단하고 요구사항이 명확하니 코드 작성은 어렵지 않다.

혹시 모노이드 카테고리(Monoidal Category)에 대해 이야기했던 것을 기억하는가? 모노이드 카테고리는 단위 대상과 함께 대상에 작용하는 이항 연산자인 모노이드 곱(Monoidal Product)을 정의한다.

예전에 이야기했듯이 Set(집합의 카테고리)은 데카르트 곱 연산을 이항 연산으로 사용하여 대상 간의 결합을 정의하는 모노이드 카테고리이며, 이때 단위 대상은 단일 원소 집합이다. 또한 서로소 합집합 연산에 대해서도 모노이드 카테고리라고 볼 수 있으며, 이때의 단위 대상은 공집합이 된다.

당시 필자가 언급하지 않은 것이 하나가 있다. 바로 모노이드 카테고리의 요구 사항 중 하나는 이항 연산자가 이항 펑터여야 한다는 것이다.

우리는 모노이드 곱의 연산 구조가 사상에 의해 정의된 카테고리의 구조와 호환되도록 만들어야 하며, 이것은 매우 중요한 요구 사항이다. 물론 완전한 이해를 하기에는 아직 자연성(Naturality)이라는 큰 산이 하나 남아 있기는 하지만, 그래도 모노이드 카테고리의 전체 정의에 한 발짝 더 가까워졌다.

8.3 펑터적인 대수적 데이터 자료형(Functorial Algebraic Data Types)

지금까지 펑터가 될 수 있는 몇 가지 파라미터화된 데이터 타입을 살펴봤다. 우리는 이러한 타입들에 대한 fmap을 정의할 수 있었다. 복잡한 데이터 타입은 더 간단한 데이터 타입을 기반으로 하여 구성되는데, 합과 곱의 개념을 사용하여 대수적 데이터 타입(ADT)을 생성하는 것이 바로 그 예이다.

앞선 섹션에서 우리는 이미 합과 곱이 펑터적이라는 사실을 확인했고, 펑터가 합성 가능하다는 사실도 알게 되었다. 결국 우리가 대수적 데이터 타입의 기본 구성 요소가 펑터라는 사실을 보일 수만 있다면, 파라미터화된 대수적 데이터 타입도 결국 펑터라는 사실로 이어질 수 있다는 것이다.

파라미터화된 대수적 데이터 타입이라는 것이 무엇을 의미하는걸까? 먼저 Maybe의 Nothing이나 List의 Nil처럼 펑터의 타입 파라미터에 의존하지 않는 녀석들이 있으며, 이들은 Const 펑터와 동등하다. Const 펑터는 자신이 받는 타입 파라미터를 무시한다는 사실을 기억해보자. (정확히 말하면 첫 번째 타입 파라미터는 고정이며, 두 번째 파라미터를 무시하는 것이다.)

또한 Maybe의 Just처럼 단순히 타입 파라미터 자체를 캡슐화하는 녀석들도 있다. 이들은 항등 펑터와 동등하다. 이전에 Cat에서의 항등 사상에 대한 이야기를 하면서 항등 펑터를 언급한 적이 있었지만, Haskell에서의 정의는 보여주지 않았었다. 이것이 바로 항등 펑터의 정의다.

data Identity a = Identity a

instance Functor Identity where
    fmap f (Identity x) = Identity (f x)

Identity는 항상 타입이 a인 하나의 불변 값만을 가지는 간단한 컨테이너라고 생각해볼 수 있다. 대수적 데이터 구조에서 이 개념을 제외한 나머지 것들은 모두 두 가지 원시적 요소를 합하거나 곱하여 생성된다.

이 새로운 지식을 토대로 Maybe 타입 생성자를 다시 한번 살펴보도록 하자.

data Maybe a = Nothing | Just a

이건 결국 Nothing과 Just 두 타입의 합이며, 합은 펑터적이다. 첫 번째 부분인 Nothing은 Const ()가 a에 작용하는 것이라고 볼 수 있다. (여기서 Const의 첫 번째 타입 파라미터는 유닛으로 설정한다.) 그리고 두 번째 부분인 Just는 그저 항등 펑터의 다른 이름일 뿐이다. 그럼 이제 우리는 Maybe를 동형적으로 아래와 같이 다시 정의할 수 있다.

type Maybe a = Either (Const () a) (Identity a)

결국 Maybe는 이항 펑터 Either를 사용하여 Const (), Identify라는 두 개의 펑터를 조합한 것이다. (실제로는 Const 또한 이항 펑터이지만, 여기서는 항상 부분적용된 상태로만 사용한다.)

우리는 이미 펑터의 합성 또한 펑터라는 것을 알고 있으며, 이항 펑터 또한 이와 마찬가지로 동일한 원칙이 적용될 것이라는 점을 쉽게 예상해볼 수 있다. 한번 이항 펑터와 두 펑터의 합성이 사상에 어떤 식으로 작용하는지 알아보도록 하자. 먼저 두 개의 사상 중 하나를 한 펑터로 리프팅한 후, 다른 하나를 또 하나의 다른 펑터로 리프팅할 것이다. 그 다음 여기서 얻어진 두 사상의 쌍을 이항 펑터로 리프팅하는 순서로 진행하면 된다.

이 과정을 Haskell로 한번 표현해보자. 이 데이터 타입의 매개변수는 다음과 같다. 두 개의 타입을 인자로 받는 타입 생성자를 의미하는 이항 펑터 bf, 각각 하나의 타입 변수를 받는 타입 생성자인 두 개의 펑터 fu와 gu와 두 개의 일반적인 타입 a와 b이다. 이제 펑터 fu를 a에 적용하고, 펑터 gu는 b에 적용한 다음, 이 결과로 나온 타입 두 개에 이항 펑터 bf를 적용할 것이라는 것을 표현하면 된다.

newtype BiComp bf fu gu a b = BiComp (bf (fu a) (gu b))

이것은 객체 또는 타입에 대한 합성이다. Haskell에서는 타입 생성자를 타입에 적용하는 것이 마치 함수를 인수에 적용하는 것과 동일한 방식으로 이루어지며, 심지어 구문 또한 동일하다.

조금 헷갈린다면, BiComp의 매개변수로 Either, Const (), Identity, a, b가 들어온다고 생각해보자. 결과적으로 Maybe b를 얻을 수 있다.

💡 역주

왜 BiComp Either Const () Identity a b가 Maybe b인지는 의사코드로 작성해보면 단번에 알 수 있다.

type Maybe a = Either (Const () a) (Identity a)

newtype BiComp bf fu gu a b = BiComp (bf (fu a) (gu b))

BiComp Either Const () Identity a b
= BiComp (Either (Const () a) (Identity b))
= Either (Const () a) (Identity b)

새로운 타입인 Bicomp는 a와 b에 대한 이항 펑터라고 할 수 있지만, 이 정의는 매개변수인 bf가 이항 펑터이고 fu와 gu가 펑터일 경우에만 성립할 수 있다. 즉, 컴파일러가 이 매개변수들을 추론했을때, bf에 대한 bimap 정의와 fu 및 gu에 대한 fmap 정의가 있다는 사실이 보장되어야 한다는 것이다.

Haskell에서는 인스턴스 선언 시 클래스 제약 조건 집합 다음에 위치하는 이중 화살표(=>)로 이러한 전제조건을 표현해줄 수 있다.

instance (Bifunctor bf, Functor fu, Functor gu) =>
    Bifunctor (BiComp bf fu gu) where
        bimap f1 f2 (BiComp x) = BiComp ((bimap (fmap f1) (fmap f2)) x)

BiComp의 bimap 구현은 bf의 bimap과 fu, gu의 fmap을 사용하여 정의한다. 컴파일러는 BiComp가 사용될 때 이 타입들을 자동으로 추론하고 오버로드된 함수를 선택할 것이다.

위의 bimap 정의에서 x의 타입은 다음과 같다.

bf (fu a) (gu b)

이것은 꽤나 복잡한 정의처럼 보인다. 외부 bimap은 외부 bf 레이어를 통과하며, 두 개의 fmap들은 각각 fu와 gu 아래로 파고들게 된다.

만약 f1와 f2의 타입이 아래와 같은 상황이라고 가정해보자.

f1 :: a -> a'
f2 :: b -> b'

그러면 최종 결과는 bf (fu a') (gu b') 타입이 된다.

bimap (fu a -> fu a') -> (gu b -> gu b')
  	-> bf (fu a) (gu b) -> bf (fu a') (gu b')

만약 여러분이 직소 퍼즐을 좋아한다면, 이런 종류의 타입 조작에서 꽤나 큰 즐거움을 느낄 수 있을 것이다.

결론적으로 Maybe는 두 펑터적인 요소의 합으로 구성되었기 때문에, 굳이 Maybe가 펑터라는 것을 증명하지 않아도 당연히 펑터라는 사실이 성립하는 것이다.

만약 예리한 독자들은 대수적 데이터 타입에 대한 펑터 인스턴스의 유도가 이렇게 논리적으로 명확하게 정의될 수 있다면, 그냥 컴파일러에서 자동화해서 처리할 수는 없냐고 질문할 수도 있다.

물론 가능하다. 이는 Haskell의 확장기능(Extensions)를 사용하면 되는데, 특정 확장기능을 사용하려면 소스 파일의 맨 위에 아래와 같은 라인을 추가하면 된다.

{-# LANGUAGE DeriveFunctor #-}

그 이후 데이터 구조에 deriving Functor를 추가하자.

data Maybe a = Nothing | Just a deriving Functor

이처럼 DeriveFunctor 확장 기능을 사용하면 특정 데이터 구조에 대한 fmap이 자동으로 구현되도록 할 수 있다.

이런 기능이 제공될 수 있는 이유는 대수적 데이터 구조의 규칙성으로 인해 Functor뿐 아니라 앞서 언급했던 Eq와 같은 여러 다른 타입 클래스 인스턴스를 논리적으로 유도하는 것이 가능하기 때문이다.

이와 더불어 컴퍼일러에게 사용자 정의 타입 클래스의 인스턴스를 유도하는 것도 가능하지만 이것은 조금 더 고급 기능이다. 하지만 결국 사용자 정의 타입 클래스라고 해도 기본적인 구성 요소, 그리고 합과 곱의 동작을 제공하는 것 뿐이므로 근본적인 원리는 동일하다.

8.4 C++에서의 펑터(Functors in C++)

만약 여러분이 C++ 프로그래머라면 펑터를 처음부터 끝까지 오롯이 혼자서 구현해야할 것이다. 그러나 이를 위해서는 C++이 가진 대수적 데이터 구조의 몇 가지 타입을 이해할 수 있어야하며, 이런 데이터 구조를 일반적인 템플릿으로 구현하고 이 구조에 대한 fmap 또한 직접 구현할 수 있어야한다.

먼저 Haskell에서 재귀적인 합 타입으로 정의된 트리 데이터 구조를 한번 살펴보자.

data Tree a = Leaf a | Node (Tree a) (Tree a)
    deriving Functor

앞서 언급한 대로, C++에서 합 타입을 구현하는 방법 중 하나는 바로 클래스 계층 구조를 이용하는 것이다. 객체지향 언어에서는 기본 클래스 Functor의 가상 함수(Virtual functions)로 fmap을 구현한 뒤 모든 하위 클래스에서 이를 재정의하는 방향이 자연스러울 것이다.

하지만 아쉽게도 이런 방법을 사용하는 것은 불가능하다. 왜냐하면 결국 fmap은 템플릿이며, 이는 this 포인터로 전달되는 객체의 타입 뿐 아니라 적용된 함수의 반환 타입이 매개변수화되어야 한다는 것을 의미한다. 하지만 C++에서는 가상 함수를 템플릿화 할 수 없다. 대신 우리는 dynamic_cast를 사용하여 패턴 매칭을 대체하고 fmap을 일반적인 자유 함수로 구현할 것이다.

기본 클래스는 동적 캐스팅을 지원하기 위해 최소 하나의 가상 함수를 정의해야하며, 이 경우 우리는 소멸자(Destructor)를 가상 함수로 정의할 것이다.

template<class T>
struct Tree {
    virtual ~Tree() {};
};

숨겨진 Identity 펑터인 Leaf를 정의하자.

template<class T>
struct Leaf : public Tree<T> {
    T _label;
    Leaf(T l) : _label(l) {}
};

Node는 곱 타입으로 정의할 것이다.

template<class T>
struct Node : public Tree<T> {
    Tree<T> * _left;
    Tree<T> * _right;
    Node(Tree<T> * l, Tree<T> * r) : _left(l), _right(r) {}
};

fmap을 구현할 때는 Tree의 타입에 따른 동적 디스패치를 활용할 것이다. Leaf의 경우에는 Identify 버전의 fmap을 적용하고, Node의 경우에는 두 개의 Tree 펑터의 복사본과 결합된 이항 펑터처럼 처리할 것이다. 물론 C++ 프로그래머들은 이런 사고 방식과 용어로 코드를 분석하는 것에 익숙하지 않을 수 있지만, 이 모든 과정이 결국 카테고리론적 사고를 연습하는 것이다.

template<class A, class B>
Tree<B> * fmap(std::function<B(A)> f, Tree<A> * t) {
    Leaf<A> * pl = dynamic_cast <Leaf<A>*>(t);
    if (pl)
        return new Leaf<B>(f (pl->_label));
    Node<A> * pn = dynamic_cast<Node<A>*>(t);
    if (pn)
        return new Node<B>(fmap<A>(f, pn->_left), fmap<A>(f, pn->_right));
    return nullptr;
}

여기서는 간결함을 위해 메모리나 리소스 관리 문제를 무시하고 있지만, 실제 코드에서는 정책에 따라 unique나 shared 같은 스마트 포인트를 사용할 것이다.

이렇게 C++로 작성한 Tree의 fmap을 Haskell에서 작성한 버전으로 바꿔보자면 다음과 같다.

instance Functor Tree where
    fmap f (Leaf a) = Leaf (f a)
    fmap f (Node t t') = Node (fmap f t) (fmap f t')

그리고 이 역시 DeriveFunctor 확장 기능을 사용하면 컴파일러에 의해 자동으로 구현될 수 있다.

8.5 Writer 펑터

이전에 설명했던 크라이슬리 카테고리(Kleisli Category) 섹션에서 Writer 펑터에 대해서 다시 설명하겠다고 했던 것을 기억하는가? 해당 카테고리에서의 사상들은 꾸며진(embellished) 함수로 표현되어 Writer 데이터 구조를 반환했었다.

type Writer a = (a, String)

필자는 이렇게 꾸며진 기능이 어떤 방식으로든 엔도 펑터와 관련이 있다고 말했다. 그리고 실제로 Writer 타입 생성자는 a에 대해 펑터적이다. 심지어 이를 위해 fmap을 구현할 필요도 없다. 왜냐하면 반환된 타입은 단순한 곱 타입이기 떄문이다.

일반적으로 크라이슬리 카테고리와 펑터 간의 관계는 다음과 같다. 크라이슬리 카테고리는 카테고리이기 때문에 합성과 항등성을 정의해야한다. 그리고 합성은 fish(>=>) 연산자에 의해 제공된다.

(>=>) :: (a -> Writer b) -> (b -> Writer c) -> (a -> Writer c)
m1 >=> m2 = \x ->
    let (y, s1) = m1 x
        (z, s2) = m2 y
    in (z, s1 ++ s2)

그리고 항등 사상은 return이라고 불리는 함수를 통해 제공했다.

return :: a -> Writer a return x = (x, "")

이제 이 두 함수들의 타입을 오랜 시간 들여다 보다보면, fmap으로 사용할 수 있는 올바른 타입의 함수를 생성하는 방법을 찾을 수 있다.

fmap f = id >=> (\x -> return (f x))

위 예시에서 fish 연산자는 우리에게 익숙한 id, 그리고 인수에 f를 적용한 결과에 다시 return을 적용한 람다, 두 함수를 합성한다.

아마 여기서 가장 이해하기 어려운 부분은 id의 사용법일 것이다. fish 연산자의 인수는 Int, Bool과 같은 일반 타입을 가져와서 꾸며진(embellished) 타입을 반환하는 함수여야 한다고 생각할 수 있겠지만 사실은 아니다. 아무도 a -> Writer b에서의 a가 일반 타입이어야 한다고 한 적은 없다. 이것은 그저 타입 변수일뿐이므로 어떤 것이든 될 수 있으며, 심지어 Writer b와 같이 이미 꾸며진 타입이 될 수도 있다.

그래서 id는 Writer a를 받아서 그대로 Writer a를 반환할 것이다. fish 연산자는 a의 값을 꺼내어 람다의 x 인자로 전달할 것이다. 이후 f는 그것을 b로 변환하고, return은 이 결과를 꾸며 최종적으로 Writer b로 만들 것이다. 이 모든 것을 조합한다면 우리는 Writer a를 가져와 Writer b를 반환하는 함수를 얻게된다. 즉, Writer의 fmap이 해야하는 것과 정확히 같은 일을 하는 것이다.

이 정의에서 Writer는 다른 임의의 타입 생성자로 변경될 수 있기 때문에 이 인자는 매우 일반적이라고 할 수 있다. 뭐가 되었던 fish 연산자와 return을 지원한다면 이를 활용하여 fmap을 정의할 수 있다는 것이다. 따라서 크라이슬리 카테고리에서의 장식(embellishment)은 항상 펑터라고 할 수 있다.

사실 우리가 방금 정의했던 fmap과 deriving Functor 확장 기능을 통해 컴파일러가 생성해주는 fmap은 동일하다. 이는 Haskell이 다형성 함수를 구현하는 방식 때문인데, 이를 매개변수 다형성(Parametric polymorphism)이라고 하며, 공짜 정리(Theorems for free)라고 불리는 정리의 원천이다.

💡 역주

매개변수 다형성(Parametric polymorphism)은 함수나 데이터 유형이 여러 타입에 대해 동작할 수 있도록 하는 기능이며, 타입스크립트의 Generic Type도 매개변수 다형성의 구현 중 하나이다.

공짜 정리(Theorems for free)는 어떤 하나의 정리를 통해 다른 정리가 추가적인 증명없이도 자동으로 성립하는 것을 의미하므로, 매개변수 다형성 또한 공짜 정리의 한 측면이라고 볼 수 있는 것이다. 타입스크립트로 예를 들자면 다음과 같다.
function nonEmptyArray<T>(arr: T[]) {
	return arr.length > 0;
}
nonEmptyArray 함수는 인자가 number[] 타입이든 string[] 타입이든 상관없이 일관된 동작을 제공한다. 즉, 다형적인 동작이 제대로 정의되었다면, number[] 타입에 대해 제대로 작동한다는 사실이 증명됨과 함께 string[] 타입에 대한 동작이 제대로 작동한다는 보장도 함께 공짜로 성립되는 것이다.

이러한 정리가 의미하는 것 중 하나는 특정 타입 생성자에 대한 fmap이 존재하고 이 함수가 항등성을 보존하고 있다면, 그 구현 방법은 유일해야 한다는 것이다.

8.6 공변적 펑터와 반공변적 펑터(Covariant and Contravariant Functors)

Writer 펑터에 대해서 살펴보았으니, Reader 펑터도 다시 한번 살펴보자. 다시 한번 이야기하지만 Reader 펑터는 부분적용된 함수 화살표 타입 생성자를 기반으로 한다.

(->) r

이 정의를 타입 동의어를 사용하여 다시 작성해보면 다음과 같다.

type Reader r a = r -> a

그리고 Reader의 Functor 인스턴스는 아래와 같이 정의된다.

instance Functor (Reader r) where
    fmap f g = f . g

쌍 타입 생성자나 Either 타입 생성자와 마찬가지로 함수 타입 생성자 또한 두 개의 타입 인자를 받는다. 기억을 되짚어보면 쌍과 Either는 자신들이 받는 각각의 인자에 대해 펑터적이었고, 이를 이항 펑터(bifunctor)라고 한다고 했다. 그렇다면 함수 생성자도 두 개의 타입 인자를 받고 있으니 이들과 동일하게 이항 펑터일까?

백문이불여일견이니 직접 확인해보자. 우선 첫 번째 인자에 대해 펑터적인지 확인해보겠다. 우선 타입 동의어에서부터 시작해볼 것이다. 아래 정의는 Reader에서 단지 인수의 순서만 뒤바뀐 형태이다.

type Op r a = a -> r

여기서 반환 타입인 r을 고정하고 인수 타입인 a에 변형을 가할 것이다. 그리고 a를 변형하는 fmap을 구현하기 위한 타입 시그니처는 다음과 같다.

fmap :: (a -> b) -> (a -> r) -> (b -> r)

인수로 a를 받고 각각 b와 r을 반환하는 두 개의 함수만 있는 경우, 이들을 사용하여 b를 받아 r을 반환하는 함수를 만들 수 있는 방법은 존재하지 않는다.

하지만 첫 번째 함수를 반대로 뒤집을 수 있다면 상황은 달라진다. 즉, 첫 번째 함수가 b를 받아 a를 반환하는 함수가 되도록 만들어주면 되는 것이다. 우리는 임의의 함수를 막 뒤집을 수는 없지만, 반대 카테고리로 이동해볼 수는 있다.

💡 역주

필자가 Reader에 대한 설명을 하다가 갑자기 반대 카테고리에 대한 이야기를 하고 있어서 설명의 흐름이 어색하다. 결과적으로 말하자면 Reader r a는 두 인자를 받아 r을 a로 변형하는 매핑을 의미하기 때문에 이항 펑터가 아니다.

앞서 보았던 쌍이나 Either의 경우 자신들이 받는 인수의 순서를 변경하더라도 연산의 결과는 동일하게 보장된다.
instance Bifunctor (,) where
    bimap f g (x, y) = (f x, g y)
-- 패턴 매칭을 통해 연산을 적용하기 때문에
-- 인자의 순서가 g f (x, y)가 되어도 f는 x에, g는 y에 적용된다.
그러나 Reader 펑터의 fmap은 함수의 합성이기 때문에 첫 번째 인자의 결과가 두 번째 인자에 의존하게 된다.
instance Functor (Reader r) where
	  fmap f g = f . g
-- 만약 합성의 순서가 g . f가 된다면 연산 결과가 달라지거나
-- 혹은 합성 자체가 불가능한 상황이 발생할 수도 있다.
필자는 이러한 Reader 펑터의 특성을 보이기 위해, 인수의 순서를 반대로 뒤집은 Op라는 타입을 예로 들어 설명하고 있는 것이다.

반대 카테고리가 기억나지 않을 수 있으니 간단하게 복습해보자. 모든 카테고리 $C$ 에 대한 반대 카테고리 $C^{op}$ 는 $C$ 와 같은 대상들을 가지고 있지만 모든 화살표(사상)의 방향이 반대로 뒤집어진 카테고리이다.

그럼 이제 $C^{op}$ 와 다른 임의의 카테고리 $D$ 사이를 이동하는 펑터를 떠올려보자.

F::C^{op} → D

이런 펑터는 $C^{op}$ 의 어떤 사상 $f^{op} :: a → b$ 를 $D$ 의 사상 $F f^{op} :: F a → F b$ 로 매핑한다. 그러나 사상 $f^{op}$ 는 원래 카테고리 $C$ 에서의 어떤 사상 $f :: b → a$ 에 해당한다. $a$ 와 $b$ 가 서로 반전되어있음에 주목하자.

이렇게 반대 카테고리 $C^{op}$ 에서 카테고리 $D$ 로 나아가는 펑터 $F$ 를 정의했다. 그렇다면 이제 $F$ 를 사용하여 카테고리 $C$ 에서 카테고리 $D$ 로 바로 나아가는 $G$ 라는 매핑도 생각해볼 수 있다. 즉, $G$ 는 $C$ 에서 $D$ 로의 매핑이다. 하지만 사실 $G$ 는 펑터가 아니다. $F$ 와 마찬가지로 대상들을 동일하게 매핑하지만, 사상을 매핑할 때는 반대로 뒤집어서 매핑하기 때문이다.

$G$ 는 $C$ 의 사상 $f :: b → a$ 를 반대 사상인 $f^{op} :: a → b$ 로 매핑한 다음, 이를 펑터 $F$ 에 적용하여 $F f^{op} :: F a→F b$ 를 얻어야 한다.

주어진 조건에 따라 $Fa$ 는 $Ga$ 와 동일하고, $Fb$ 가 $Gb$ 와 동일하다고 가정할 때, 전체적인 흐름은 아래와 같이 나타내볼 수 있다.

G f :: (b → a) → (G a → G b)

이렇게 사상의 방향을 반전하는 카테고리 간의 매핑을 반공변적 펑터(Contravariant Functor)라고 한다. 반공변적 펑터는 반대 카테고리에서의 일반적인 펑터일 뿐이다. 그리고 우리가 지금까지 공부해왔던 일반적인 펑터는 공변적 펑터(Covariant Functor)라고 한다.

아래는 Haskell에서 반공변적인 (엔도)펑터를 정의하는 타입 클래스이다.

class Contravariant f where
  	contramap :: (b -> a) -> (f a -> f b)

즉, 아까 정의했던 타입 생성자 Op의 인스턴스는 아래와 같이 정의될 수 있다.

instance Contravariant (Op r) where
  	-- (b -> a) -> Op r a -> Op r b
  	contramap f g = g . f

함수 f가 Op의 내용인 함수 g의 앞에 자신을 삽입한다는 것에 주목하자. (함수 합성의 연산 순서는 오른쪽에서 왼쪽이다.)

여기서 Op의 contramap의 정의는 단지 인자를 뒤집은 함수 합성 연산자일 뿐이라는 것을 알 수 있으며, 이 사실을 알았다면 이제 더 간결하게 만들어 볼 수도 있다.

여기 인자를 뒤집는데 사용되는 특수한 함수인 flip이 있다.

flip :: (a -> b -> c) -> (b -> a -> c)
flip f y x = f x y

그러면 이제 contramap의 정의를 이렇게 간단하게 바꿔볼 수 있다.

contramap = flip (.)

8.7 프로펑터(Profunctors)

우리는 함수 화살표 연산자가 첫 번째 인자에서 반공변 변형이 되고, 두 번째 인자에서 공변 변형이 되는 상황을 보았다. 이런 개념에 대한 명칭도 있을까?

만약 대상 카테고리가 Set이라면 이 개념을 프로펑터(Profunctor)라고 부른다. 반공변적 펑터는 반대 카테고리에서의 공변적 펑터와 동일하기 때문에, 프로펑터는 아래와 같이 정의된다.

C^{op} × D → Set

일단 Haskell 타입을 집합이라고 가정해보면, 우리는 첫 번째 인자에 대해 반공변적 펑터적이고 두 번째 인자에 대해서는 펑터적인 두 개의 인자를 받는 타입 생성자 p에 Profuctor라는 이름을 부여할 수 있다. 아래는 Data.Profuctor 라이브러리에서 가져온 타입 클래스의 모습이다.

class Profunctor p where
  	dimap :: (a -> b) -> (c -> d) -> p b c -> p a d
  	dimap f g = lmap f . rmap g
  	lmap :: (a -> b) -> p b c -> p a c
  	lmap f = dimap f id
  	rmap :: (b -> c) -> p a b -> p a c
    rmap = dimap id

세 함수 모두 기본 구현이 제공된다. Bifunctor와 마찬가지로 Profuctor의 인스턴스를 선언할 때는 dimap을 구현하고 lmap과 rmap에 대한 기본값을 사용하거나, 혹은 lmap과 rmap을 모두 구현하고 dimap에 대한 기본값을 사용할 수 있는 선택권이 있다.

여기까지 왔으면 이제 함수 화살표 연산자가 Profuctor의 인스턴스라는 것을 단언할 수 있다.

instance Profunctor (->) where
    dimap ab cd bc = cd . bc . ab
    lmap = flip (.)
    rmap = (.)

프로펑터는 Haskell 렌즈 라이브러리에서 응용되고 있으며, 추후 ends와 coends에 대해 이야기할 때 다시 한번 자세히 설명할 것이다.

원문 보기

👉 Category Theory for Programmers

[번역] 프로그래머를 위한 카테고리 이론 - 7. 펑터

Tue, 19 Mar 2024 10:30:00 GMT

이번 챕터에서는 펑터(Functor)에 대해서 이야기를 해보려고 한다. 펑터는 간단하지만 매우 강력한 개념이며 카테고리 이론은 이처럼 간단하지만 강력한 아이디어로 가득 차있다.

펑터는 카테고리 간의 매핑이다. 즉, 두 카테고리 $C$ 와 $D$ 가 주어졌을 때, 펑터 $F$ 는 카테고리 $C$ 의 대상을 카테고리 $D$ 의 대상으로 매핑하는 것이며, 결국 대상들에 대한 함수라고 볼 수 있다.

만약 카테고리 $C$ 의 대상을 $a$ 라고 한다면, 우리는 매핑된 카테고리 $D$ 의 대상을 $F a$ 라고 표현할 수 있다. 하지만 카테고리는 대상으로만 구성되어있지 않으며 대상과 그들을 연결하는 사상까지 모두 포함하는 개념이다. 즉, 펑터는 대상 뿐 아니라 사상 또한 매핑하며, 이런 경우에는 사상에 대한 함수라고 볼 수도 있다. 그렇다고 펑터가 마음대로 사상을 매핑하는 것은 아니고, 반드시 사상으로 연결된 대상들의 구조를 그대로 보존해야 한다.

만약 카테고리 $C$ 에 있는 사상 $f$ 가 대상 $a$ 와 $b$ 를 연결하고 있다면,

f :: a -> b

펑터를 통해 매핑된 카테고리 $D$ 에 있는 사상 $f$ 인 $F f$ 또한 $C$ 와 동일한 구조로 대상 $F a$ 와 $F b$ 를 연결해야 한다.

F f :: F a -> F b

여기서 알 수 있듯이 펑터는 카테고리의 구조를 그대로 보존한다. 한 카테고리 내에서 연결되어있는 것들은 펑터를 통해 매핑된 카테고리에서도 그대로 연결되어 있는 것이다. 이에 더해 카테고리에는 단순히 대상을 사상으로 연결하는 것 뿐 아니라 사상 간의 합성이라는 개념 또한 존재한다.

사상 $h$ 가 $f$ 와 $g$ 의 합성사상인 상황을 생각해보자.

h = g . f

그렇다면 펑터 $F$ 를 통해 만들어진 카테고리의 사상들의 합성 관계도 이와 동일하게 유지된다.

F h = F g . F f

마지막으로 우리는 카테고리 $C$ 안의 모든 항등사상들이 카테고리 $D$ 의 항등사상들로 매핑되는 상황 또한 생각해볼 수 있다.

F id_a = id_Fa

여기서 $id_a$ 는 대상 $a$ 의 항등사상이며, $id_Fa$ 는 대상 $F a$ 의 항등사상이다. 이처럼 항상 카테고리의 구조를 보존해야한다는 조건들로 인해 펑터는 일반적인 함수보다 더 제한적인 개념이 된다.

만약 어떤 카테고리를 각 대상들이 사상으로 연결되어있는 일종의 네트워크라고 상상해보자. 펑터는 각 대상과 사상을 그저 매핑하는 개념일뿐이므로 네트워크의 요소들을 서로 분리해내는 것은 절대 불가능하다. 펑터로 대상들을 합칠 수도 있고 여러 사상들을 하나로 붙혀놓을 수도 있겠지만 분해하는 것은 불가능한 것이다.

이와 같이 분해가 불가능하다는 제약은 미적분에서 볼 수 있는 연속성의 조건과 유사하다. 이런 의미에서 펑터는 “연속적”이라고 볼 수도 있다. 또한 마치 정의역과 공역의 관계를 축소나 포함이라는 시각으로 바라보는 것과 유사하게 펑터 또한 동일한 시각으로 바라볼 수 있다. 예를 들면 펑터의 소스가 되는 카테고리가 대상 카테고리보다 더 작을 때는 포함과 같은 개념으로 볼 수 있는 것이다.

한번 극단적인 예시를 생각해보자. 펑터의 소스가 되는 카테고리는 단 하나의 대상과 하나의 항등사상만으로 이루어진 단일대상 카테고리가 될 수도 있다. 이처럼 단일대상 카테고리를 다른 카테고리로 매핑하는 펑터는 단순히 해당 카테고리에서 하나의 대상을 선택하는 것과 다를 게 없다. 이는 단일원소집합에서 하나의 원소를 선택하는 사상의 특성과 완전히 유사하다.

소스 카테고리를 최대한 축소하는 펑터는 상수 펑터(Constant Functor), $\Delta c$ 로 불린다. 이 펑터는 소스 카테고리의 모든 대상을 대상 카테고리에서 선택된 하나의 대상인 $c$ 로, 그리고 소스 카테고리의 모든 사상을 항등사상인 $id_c$ 로 매핑한다. 이 펑터는 마치 블랙홀처럼 작동하여 모든 것을 하나의 특이점으로 압축해버린다. 우리가 추후 한계(Limits)와 공한계(Colimits)에 대해 이야기할 때 이러한 펑터를 더 자세히 살펴볼 것이다.

💡 역주

작가의 설명만 보면 마치 상수 펑터( $\Delta c$ )가 어떤 카테고리를 다른 카테고리로 매핑하며 압축하는 녀석으로 보일 수 있지만, 사실 상수 펑터는 특정 카테고리를 자기 자신으로 매핑하는 엔도펑터(EndoFunctor)이다. (엔도펑터에 대한 설명은 바로 다음 섹션에 나온다.)

즉, 상수 펑터는 어떤 카테고리의 모든 대상을 그 카테고리 내의 대상 하나로 매핑(압축)하는 개념이라고 보면 된다. 이 과정에서 카테고리의 대상들을 연결하던 임의의 사상들은 모두 선택된 대상의 항등 사상으로 매핑된다.

7.1 프로그래밍에서의 펑터

이제부터는 실질적인 프로그래밍에 대해서 이야기해보자. 이미 우리는 프로그래밍의 세계에서 타입과 함수로 이루어진 카테고리를 다루고 있다. 이번에는 이 카테고리를 자기 자신으로 매핑하는 펑터, 엔도펑터(EndoFunctor)에 대해서 생각해보려고 한다.

자, 타입으로 이루어진 카테고리에서의 엔도펑터는 무엇일까? 이 펑터는 타입을 타입으로 매핑하는 펑터일 것이다. 사실 여러분은 이미 이러한 매핑의 예시를 숱하게 봐왔을테지만 단지 그것이 엔도펑터라는 것을 깨닿지 못 했을 뿐이다. 아래 몇 가지 예시를 한번 살펴보자.

7.1.1 Maybe 펑터

Maybe의 정의는 어떠한 타입 a를 Maybe a라는 타입으로 매핑하는 것이다.

data Maybe a = Nothing | Just a

여기서 중요한 포인트가 하나 있다. Maybe 자체는 타입이 아니라 타입 생성자(Type Constructor)라는 것이다. 타입 생성자를 타입으로 변환하기 위해서는 Int나 Bool과 같은 타입 인자를 생성자에게 제공해야 한다. 즉, 아무 인자로 받지 않는 Maybe는 타입에 대한 함수를 나타내는 것이다.

그렇다면 Maybe를 펑터로 변환해볼 수 있을까? (프로그래밍 맥락에서 펑터에 대해 이야기할 때는 거의 항상 엔도펑터를 이야기한다는 사실을 유념하자.) 펑터는 대상(타입)의 매핑 뿐만 아니라 사상(함수)의 매핑도 모두 포함하는 개념이다. 한번 a에서 b로 나아가는 임의의 함수 f가 있다고 생각해보자.

f :: a -> b

우리는 Maybe a에서 Maybe b로 나아가는 함수를 생성하고 싶다. 이러한 함수를 제대로 정의하기 위해서는 Maybe를 구성하는 두 생성자인 Nothing과 Just에 대해 고려해야한다.

Nothing의 경우에는 그저 Nothing을 반환해주기만 하면 되니 간단하다. 그리고 인자가 Just인 경우에는 함수 f를 Just가 가지고 있는 값에 적용해주면 될 것이다.

즉, Maybe라는 펑터를 거친 f의 모습은 아래와 같은 함수가 된다. (Haskell에서는 변수명에 아포스트로피(’)를 사용할 수 있으며, 이 기능은 아래와 같은 경우에 매우 편리하다.)

f' :: Maybe a -> Maybe b
f' Nothing = Nothing
f' (Just x) = Just (f x)

Haskell에서는 펑터가 사상을 매핑하는 행위를 fmap이라는 고차함수로 구현하며, Maybe의 경우에는 아래와 같은 정의가 될 것이다.

fmap :: (a -> b) -> (Maybe a -> Maybe b)

우리는 종종 fmap이 함수를 리프트(lift)한다고 말한다. 이렇게 리프팅된 함수는 이제 Maybe 타입의 값에 작용하는 함수가 되었다.

또한 커링(Currting)으로 인해 위 정의는 하나의 함수 a → b를 받아서 다른 함수 Maybe a → Maybe b를 반환하는 함수, 그리고 a → b와 Maybe a라는 두 개의 인자를 받아 Maybe b를 반환하는 함수, 총 두 가지 방식으로 해석될 수 있다.

fmap :: (a -> b) -> Maybe a -> Maybe b

이러한 특성들을 기반으로 Maybe에 대한 fmap을 구현해보면 아래와 같다.

fmap _ Nothing = Nothing
fmap f (Just x) = Just (f x)
-- 적용할 함수 f와 Just x를 인자로 받아,
-- Just가 가진 값에 함수 f가 적용된 꼴인 Just (f x)를 반환한다.

우리가 Maybe 타입 생성자와 fmap 함수가 펑터를 형성한다는 것을 보이기 위해서는 fmap 함수가 항등과 합성의 개념을 보존한다는 것을 증명해야한다. 이러한 것들을 “펑터 법칙(The Functor Laws)”이라는 거창한 이름으로 부르긴 하지만 사실은 그저 펑터가 카테고리의 구조를 보존한다는 것을 보장해야한다는 의미이다.

7.1.2 방정식 추론(Equational Reasoning)

펑터 법칙을 증명하기 위해 방정식 추론(Equational Reasoning)을 사용해보려고 한다. 이는 Haskell에서 흔하게 사용되는 증명 기법인데, Haskell 함수가 좌변이 우변과 같다는 동등성(Equality)으로 정의된다는 사실을 이용하는 기법이다. 어떤 코드를 동작이 동일한 다른 코드로 대체할 수도 있고 변수명의 충돌을 피하기 위해 변수명을 변경할 수도 있는데, 이는 함수를 인라인화하는 행위나 반대로 표현식을 함수로 리팩토링하는 행위로 생각할 수도 있다. 한번 항등함수를 예시로 살펴보자.

id x = x

이러한 함수가 존재한다면 이제 우리는 어떤 표현식에서 id y를 보았을 때, 이 코드를 y로 바꿔볼 수 있다(인라인화). 더 나아가서 id (y + 2)와 같이 id가 표현식에 적용되어있다면 이를 표현식 그 자체인 (y + 2)로 바꿀 수도 있다. 또한 이 치환은 양방향으로 적용되기 때문에 표현식 e를 id e로 치환할 수도 있다.(리팩토링)

함수가 패턴 매칭에 의해 정의된 경우, 각각의 하위 정의를 독립적으로 사용할 수도 있다. 예를 들어 위의 fmap 정의에서 fmap f Nothing을 Nothing으로 바꿀 수 있으며, 반대로도 가능하다. 이제 이 개념이 실제로 어떻게 작동하는지를 살펴보자. 먼저 항등 보존을 살펴보겠다.

fmap id = id

우리는 Nothing과 Just라는 두 가지 케이스를 고려해야한다. 먼저 첫 번째 경우를 살펴보겠다. 왼쪽의 항을 오른쪽 항으로 변환하기 위해 Haskell 문법의 Pseudo Code를 사용하겠다.

  fmap id Nothing
= { fmap의 정의에 의하면 }
  Nothing
= { id의 정의에 의하면 }
id Nothing

가장 마지막 단계에서는 id의 정의를 활용하여 표현식 Nothing을 id Nothing으로 대체했다. 실제로는 양 끝에서 촛불을 태우는 방식과 유사하게 이러한 증명을 수행해나가며, 중간에서 동일한 표현식을 만날 때까지 진행하게 된다. 위 케이스에서는 세 번째 라인의 Nothing이 이에 해당한다.

두 번째 경우도 어렵지 않다.

  fmap id (Just x)
= { fmap의 정의에 의하면 }
  Just (id x)
= { id의 정의에 의하면 }
  Just x
= { id의 정의에 의하면 }
  id (Just x)

이제 항등 보존에 대한 증명이 끝났으니, fmap이 합성을 보존한다는 것도 표현해보자.

fmap (g . f) = fmap g . fmap f

첫 번째 Nothing의 케이스이다.

  fmap (g . f) Nothing
= { fmap의 정의에 의하면 }
  Nothing
= { fmap의 정의에 의하면 }
  fmap g Nothing
= { fmap의 정의에 의하면 }
  fmap g (fmap f Nothing)

그리고 두 번째 케이스인 Just에 대해서는 이렇게 표현한다.

  fmap (g . f) (Just x)
= { fmap의 정의에 의하면 }
  Just ((g . f) x)
= { 합성의 결합법칙에 의하면 }
  Just (g (f x))
= { fmap의 정의에 의하면 }
  fmap g (Just (f x))
= { fmap의 정의에 의하면 }
  fmap g (fmap f (Just x))
= { 합성의 결합법칙에 의하면 }
  (fmap g . fmap f) (Just x)

💡 역주

이러한 추론 방식이 조금 어색하게 느껴지는 독자 분들도 계실텐데, 사실 위 예시에 작성된 모든 코드들은 모두 같은 동작을 하는 코드이다.

방정식 추론이라는 말이 어려워보여서 그렇지 결국은 x, x + 0이 동형(Isomorphic)임을 밝혀나가는 노가다와 유사하다.
const addZero = (x: number) => x + 0;
const identify = <T>(v: T) => v;
 identify(addZero(x));
= { identify의 정의에 의하면 }
 addZero(x)
= { addZero의 정의에 의하면 }
 x
= { identify의 정의에 의하면 }
 identify(x)
함수가 참조 투명성을 보장하는 이상 함수를 함수의 본문으로 치환이 가능하기 때문에 이렇게 노가다로 정합성을 확인해나가는 행위가 가능한 것이다.

이와 같은 방정식 추론을 사용할 때는 이 추론 방법이 사이드 이펙트를 가진 C++ 스타일의 함수에 대해서는 동작하지 않는다는 점을 잘 알아야 한다. 아래 코드를 살펴보자.

int square(int x) {
    return x * x;
}
int counter() {
    static int c = 0;
    return c++;
}

double y = square(counter());

방정식 추론을 사용하면 square를 인라인화하여 아래와 같은 정의를 얻을 수 있다.

double y = counter() * counter();

이는 확실히 유효한 변환이 아니며 매번 동일한 결과를 생성하지도 않을 것이다. 그럼에도 불구하고 매크로를 통해 square를 구현한 경우 C++ 컴파일러는 방정식 추론을 시도할 것이고, 그 결과는 참혹할 것이다.

7.1.3 Optional

물론 Haskell을 사용하여 펑터를 쉽게 정의할 수 있기는 하지만, 사실 꼭 Haskell이 아니더라도 제네릭 프로그래밍과 고차함수를 지원하는 어떤 언어든 펑터를 정의할 수 있다. C++의 Maybe에 해당하는 템플릿 타입 optional을 생각해보자. 아래는 optional 구현에 대한 스케치이다. (실제 구현은 인수가 전달될 수 있는 여러가지 방법, Deep Copy/Shallow Copy와 같은 Copy Semantics, C++ 특유의 자원 관리 문제 등 을 고려해야하기 때문에 훨씬 더 복잡하다.)

template<class T>
class optional {
    bool _isValid; // the tag
		T _v;
public:
    optional()    : _isValid(false) {}        // Nothing
    optional(T x) : _isValid(true) , _v(x) {} // Just
    bool isValid() const { return _isValid; }
    T val() const { return _v; } };

이 템플릿은 타입 T를 새로운 타입 optional<T>로 매핑하여 펑터의 정의 중 하나인 타입에 대한 매핑을 제공한다. 이제 함수에 대한 동작을 정의해보자.

template<class A, class B>
std::function<optional<B>(optional<A>)>
fmap(std::function<B(A)> f) {
		return [f](optional<A> opt) {
				if (!opt.isValid())
						return optional<B>{};
				else
						return optional<B>{ f(opt.val()) };
		};
}

이것은 함수를 인자로 받고 다시 함수를 반환하는 고차함수이다. 커링되지 않는 버전은 다음과 같다.

template<class A, class B>
optional<B> fmap(std::function<B(A)> f, optional<A> opt) {
		if (!opt.isValid())
        return optional<B>{};
    else
        return optional<B>{ f(opt.val()) };
}

이외에 fmap을 optional의 템플릿 메서드로 만드는 선택지도 있다. 이처럼 다양한 선택지들은 C++에서 펑터 패턴을 추상화하는 난이도를 더 높히는 주범이다. 펑터를 상속할 수 있는 인터페이스로 정의해야할까? 펑터는 커링된 함수인가 아니면 커링되지 않은 프리 템플릿 함수인가? C++ 컴퍼일러는 누락된 타입을 올바르게 추론할 수 있을까, 아니면 우리가 직접 명시적으로 지정해줘야 하는걸까?

한번 입력 함수 f가 int를 받아 bool을 반환한다고 생각해보자. 이 경우에 컴파일러는 g의 타입을 어떻게 결정할까?

auto g = fmap(f);

특히 fmap을 오버로딩하는 여러 가지 펑터가 있는 경우에는 어떻게 될까? (곧 우리는 더 많은 펑터들을 만나게 될 것이다)

7.1.4 타입 클래스(Typeclasses)

그렇다면 Haskell이 펑터를 추상화하는 방법은 무엇일까? 이를 위해서 Haskell은 타입 클래스 매커니즘을 사용한다. 타입 클래스는 공통 인터페이스를 지원하는 타입의 집합을 정의한다. 예를 들어, 동등성을 지원하는 객체들의 클래스는 아래와 같이 정의된다.

class Eq a where
    (==) :: a -> a -> Bool

이 정의는 타입 a가 Eq 클래스의 멤버인 경우, 타입 a가 두 인자를 받아 Bool을 반환하는 == 연산자를 지원한다는 것을 나타낸다.

만약 Haskell에게 특정 타입이 Eq 타입 클래스의 인스턴스라는 것을 알려주고 싶다면, 먼저 이 클래스의 인스턴스로 선언하고 ==의 구현을 제공해줘야 한다. 예를 들어 두 개의 Float로 이루어진 곱 타입인 2D Point 타입의 정의가 주어졌다고 생각해보자.

data Point = Pt Float Float

우리는 각 점의 동등성을 이렇게 정의해볼 수 있다.

instance Eq Point where
		(Pt x y) == (Pt x' y') = x == x' && y == y'

여기서는 두 개의 패턴 (Pt x y)와 (Pt x’ y’)에게 중위 연산자 ==를 사용해보았다. 함수의 본문은 단일 등호를 보면 이해가 쉽다. 이처럼 Point가 Eq의 인스턴스로 선언된다면 이제 직접적으로 연산자를 통해 각 점의 동등성을 비교할 수 있다.

Haskell에서는 C++이나 Java와는 다르게 Point를 정의할 때, 이 타입이 직접 Eq클래스의 멤버라는 것을 명시할 필요는 없으며, 이는 추후 사용자가 직접 작성하는 클라이언트 코드에서 작성할 수 있다. 이러한 타입 클래스는 Haskell에서 함수나 연산자를 오버로딩할 수 있는 유일한 방법이다.

다양한 펑터들에서 fmap의 동작을 오버로딩하여 활용하기 위해서는 이와 같은 타입 클래스 기법이 필요하다. 그러나 한 가지 복잡한 점이 있다. 펑터는 타입으로 정의되는 것이 아니라 타입들의 매핑인 타입 생성자로 정의된다. 즉, 펑터를 제대로 정의하기 위해서는 Eq의 경우처럼 타입들의 집합이 아닌 타입 생성자들의 집합으로 정의된 타입 클래스가 필요하다는 것이다. 다행히도 Haskell의 타입 클래스는 타입 뿐만 아니라 타입 생성자 또한 잘 지원해준다. 그럼 이제 Functor 클래스를 한번 정의해보자.

class Functor f where
    fmap :: (a -> b) -> f a -> f b

이 코드는 f가 Functor인 경우, 지정된 타입 시그니처를 가진 함수 fmap을 가지고 있다는 사실을 명시하고 있다. 여기서 소문자 f는 타입 변수이며, 타입 변수 fmap이 받고 있는 a나 b와 동일한 개념이다.

컴파일러는 f a나 f b와 같이 이 타입 변수가 다른 타입을 처리하고 있다는 사실을 참고하여 f가 타입이 아닌 타입 생성자라는 사실을 추론할 수 있다. 따라서 Functor의 인스턴스를 선언할 때는 Maybe와 같은 타입 생성자를 지정해줘야 한다.

instance Functor Maybe where
    fmap _ Nothing = Nothing
    fmap f (Just x) = Just (f x)

사실 우리가 정의한 Functor 클래스, 그리고 Maybe와 같이 간단한 데이터 타입에 대한 인스턴스 정의들은 이미 표준 Prelude에 포함되어있다.

7.1.5 C++에서의 펑터(Functor in C++)

그렇다면 C++에서도 이와 동일한 접근 방식을 시도해볼 수 있을까? 타입 생성자는 optional과 같은 템플릿 클래스에 해당하므로, fmap을 템플릿 템플릿 매개변수 F로 매개화해볼 수 있을 것이다.

template<template<class> F, class A, class B>
F<B> fmap(std::function<B(A)>, F<A>);

이제 이 템플릿을 다른 펑터들에 대해서 특수화(Specialize)하면 좋을 것 같다. 하지만 슬프게도 C++에서는 템플릿 함수의 부분 특수화를 금지하고 있기 때문에 아래처럼 작성할 수가 없다.

template<class A, class B>
optional<B> fmap<optional>(std::function<B(A)> f, optional<A> opt)

대신 우리는 함수 오버로딩을 사용할 것이다. 이렇게 되면 우리는 다시 커링되지 않은 펑터의 원래 정의로 돌아가게 된다.

template<class A, class B>
optional<B> fmap(std::function<B(A)> f, optional<A> opt) {
    if (!opt.isValid())
        return optional<B>{};
    else
        return optional<B>{ f(opt.val()) };
}

이제 fmap의 두 번째 인자가 오버로드를 선택하기 때문에 이 정의 자체가 작동하기는 하지만, 이러한 방법은 fmap의 일반적인 정의에서는 많이 벗어나있다.

7.1.6 List 펑터

프로그래밍에서 펑터가 어떤 역할을 하는지에 대해 감을 잡기 위해서는 조금 더 많은 예제를 살펴봐야할 것 같다. 다른 타입으로 매개화된 어떤 타입이든 모두 펑터의 후보라고 볼 수 있다. 제네릭 컨테니어는 저장된 요소의 타입에 의해 매개화되므로, 매우 간단한 컨테이너인 List를 한번 살펴보자.

💡 역주

제네릭 컨테이너는 여러 타입의 데이터를 저장할 수 있는 데이터 컨테이너이다. 즉, 타입 파라미터를 받음으로써 동일한 구조를 유지하면서도 서로 다른 유형의 데이터를 저장할 수 있는 것이다. TypeScript에서는 Array<T>와 같은 타입이 일종의 제네릭 컨테이너라고 볼 수 있다.

data List a = Nil | Cons a (List a)

여기 List라는 타입 생성자가 있다. 이 타입 생성자는 임의의 타입 a를 타입 List a로 매핑한다. 이때 List가 펑터라는 것을 보이기 위해서는 함수 a → b가 주어졌을 때 함수 List a → List b로 나아가는 리프팅 함수를 정의해야 한다.

fmap :: (a -> b) -> (List a -> List b)

List a에 작용하는 함수는 두 리스트 생성자인 Nil과 Cons 두 가지 경우를 고려해야한다. Nil의 경우에는 어차피 빈 리스트에 대해서 할 수 있는게 없으니, 그냥 Nil을 반환해주면 되므로 간단하게 처리가 가능하다.

그러나 Cons 케이스의 경우에는 약간 까다롭다. 왜냐하면 재귀를 포함해야하기 때문이다. 일단 잠시 생각을 멈추고 우리가 정확히 어떤 것을 하려고 하는 것인지 다시 살펴보자. fmap의 인자로 a의 리스트, 그리고 a를 b로 변환하는 함수 f가 주어졌고, 이제 이것들을 가지고 b의 리스트를 생성해야한다.

리스트의 각 요소를 a에서 b로 변환하는 것은 당연하게도 f를 사용하면 된다. 다만 비어있지 않은 리스트는 하나의 원소가 아닌 Cons로 표현되는 헤드(Head)와 나머지 꼬리(Tail)로 구성될텐데, 어떻게 모든 원소에 f를 적용해야 하는걸까?

우리는 f를 헤드에 먼저 적용하고, 리프팅한(fmap한) f를 나머지 꼬리에 적용할 것이다. 이는 리프팅된 f를 또 다시 리프팅한 f로 정의하고 있기 때문에 재귀적인 정의가 된다.

fmap f (Cons x t) = Cons (f x) (fmap f t)

💡 역주

Haksell에 익숙하지 않은 독자들을 위해 조금 더 읽기 쉬운 변수명으로 바꿔보면 다음과 같다.
fmap 원소에적용할fn (Cons 헤드원소 나머지테일) = Cons (원소에적용할fn 헤드원소) (fmap 원소에적용할fn 나머지테일)
이를 TypeScript로 다시 작성해보자면 대략 이런 느낌이다.
// List 펑터 인터페이스
interface List<T> {
 fmap(fn: (value: T) => U): List;
}

class Cons<T> implements List<T> {
 constructor(public head: T, public tail: List<T>) {}

 fmap(fn: (value: T) => U): List {
 // 헤드에 fn를 적용해서 T를 U로 변경
 // 이후 꼬리(List)가 가진 fmap을 호출하여 같은 행위를 재귀적으로 반복한다.
 return new Cons(fn(this.head), this.tail.fmap(fn));
 }
}
Haksell은 Cons (f x)나 (fmap f t)와 같은 패턴매칭을 통해 헤드에 적용할 동작과 꼬리에 적용할 동작을 구분하지만, TypeScript는 그런 패러다임을 가진 언어가 아니기 때문에 직접 this를 통해 원하는 동작을 호출하고 있다.

우항의 fmap f 구문은 정의하려는 리스트보다 더 짧은 리스트, 즉, 꼬리에 적용된다. 결국 점점 더 짧은 리스트로 재귀하다가 결국 최종적으로는 빈 리스트인 Nil에 도달하게 될 것이다.

앞서 정의한대로 fmap f가 Nil에 적용되면 재귀가 종료된다. 최종 결과를 얻으려면 새로운 헤드 (f x)와 새로운 꼬리 (fmap f t)를 Cons 생성자를 통해 결합한다. 지금까지 이야기한 모든 내용을 하나로 합쳐보면 아래와 같이 List 펑터의 인스턴스 선언이 된다.

instance Functor List where
    fmap _ Nil = Nil
    fmap f (Cons x t) = Cons (f x) (fmap f t)

만약 여러분이 C++에 익숙하다면, 일반적인 C++ 컨테이너인 std::vector를 한번 생각해보면 된다. std::vector에 대한 fmap의 구현은 단순히 std::transform의 얇은 캡슐화에 불과하다.

template<class A, class B>
std::vector<B> fmap(std::function<B(A)> f, std::vector<A> v) {
    std::vector<B> w;
    std::transform( std::begin(v)
                  , std::end(v)
                  , std::back_inserter(w)
                  , f);
		return w;
}

이를 사용하면 숫자 시퀀스인 원소를 제곱하는 등의 행위가 가능하다.

std::vector<int> v{ 1, 2, 3, 4 };
auto w = fmap([](int i) { return i*i; }, v);
std::copy( std::begin(w)
					, std::end(w)
					, std::ostream_iterator(std::cout, ", "));

대부분의 C++ 컨테이너는 std::transform에 전달할 수 있는 이터레이터를 구현함으로써 펑터가 되며, 이는 fmap의 원시적인 버전과도 같다. 그러나 안타깝게도 이터레이터와 임시 개체(Temporaries)의 혼란스러움으로 인해 펑터의 단순함이 상당 부분 사라져버린다(위의 fmap 구현을 참조해보자). 하지만 새롭게 제안된 range 라이브러리는 특정한 범위 내에서 펑터적인 성질을 더 명확하게 표현해주고 있다.

7.1.7 Reader 펑터

여기까지 봤다면 이제 펑터가 어떤 컨테이너의 한 종류인 것 같다는 생각을 가지게 되었을 것이라 생각한다. 그렇다면 이제는 그 생각을 깨버리기 위해 지금까지와 매우 다른 것처럼 보이는 예제를 보여주려고 한다. 타입 a를 a를 반환하는 함수로 매핑하는 상황을 생각해보자.

아직 함수 타입에 대한 깊이 있는 이야기를 나누지는 않았지만, 사실 프로그래머라면 함수에 대한 기본적인 이해 정도는 가지고 있다. Haskell에서 함수 타입은 두 개의 타입과 화살표 타입 생성자(->)를 사용하여 구성된다. 이 생성자는 인수 타입, 그리고 결과 타입이라는 두 가지 타입 사이의 중위 표현으로 등장한다. 기본적으로는 a -> b의 형태이지만 괄호를 사용하면 전위 표현으로도 사용이 가능하다.

(->) a b

정규 함수와 마찬가지로 하나 이상의 인수를 가진 타입 함수는 부분적용이 가능하다. 따라서 아래 예시와 같이 화살표에 하나의 타입 인수만 제공한다면 결과 타입을 의미하는 다른 인수가 들어오는 것을 기다릴 수 있다는 것이다.

(->) a

이것이 바로 위 표현이 타입 생성자인 이유이다. a -> b 를 완전한 타입으로 만들기 위해서는 타입 b까지 제공되어야 하기 때문이다. 즉, 위 예시는 타입 a를 매개변수로 사용하는 타입 생성자 집합을 정의하고 있다고 볼 수 있다.

그렇다면 이제 이 케이스가 펑터가 맞는지 살펴보도록 하자. 두 개의 타입 매개변수를 다루는 것은 어려울 수 있으니 이름을 조금 변경해보겠다. 이전에 정의했던 펑터의 정의와 일치하도록 인수의 타입을 r로, 결과 타입을 a로 지정해보겠다.

즉, 이 타입 생성자는 임의의 타입 a를 r -> a 타입으로 매핑하는 녀석이다. 이것이 펑터가 되려면 함수 a -> b, 함수 r -> a를 인자로 받고 함수 r -> b를 반환하는 함수로 리프팅해야 한다. 이들은 각각 타입 생성자(->) r이 작용하는 타입 a와 b를 사용하여 형성된 타입이다.

이제 이 케이스를 표현할 수 있는 fmap의 정의를 살펴보자.

fmap :: (a -> b) -> (r -> a) -> (r -> b)

우리는 함수 f::a -> b와 함수 g::r -> a가 주어졌을 때 함수 r -> b를 생성해야하는 퍼즐을 풀어야 한다. 두 함수를 합성할 수 있는 방법은 오직 하나 뿐이며, 결과 또한 우리가 원하는 방향과 정확히 일치한다. 따라서 fmap의 구현은 아래와 같을 것이다.

instance Functor ((->) r) where
    fmap f g = f . g

💡 역주

g::r → a, f::a → b가 합성됨으로써 r → a → b, 즉 r → b가 성립된다.

굉장히 간결하지만 우리가 원하는 동작은 정확히 구현되었다. 만약 더 간결한 표기를 선호한다면, 함수 합성에 대한 표현을 전위 표기법으로 바꿔볼 수도 있다.

fmap f g = (.) f g

그리고 인수를 생략해서 fmap과 함수 합성을 의미하는 . 연산자, 두 함수의 직접적인 동등성을 표현할 수도 있다.

fmap = (.)

이처럼 (->) r 타입 생성자와 fmap 구현의 결합을 Reader 펑터라고 한다.

7.2 컨테이너로써의 펑터

지금까지 프로그래밍 언어에서 일반적인 용도의 컨테이너를 정의하는 펑터의 몇 가지 예시를 살펴보았다.

우리는 보통 함수를 일종의 데이터라고 생각하지않기 때문에 Reader 펑터같은 녀석들이 조금 어색해보이기도 한다. 그러나 순수함수는 메모이제이션될 수 있으며 함수의 실행은 일종의 테이블 조회 행위로 변환될 수도 있다. 그리고 테이블은 데이터이다.

💡 역주

함수의 실행을 일종의 테이블 조회 행위로 변환할 수 있다는 말은 어떤 함수가 순수하고 불변적이며 입력에 따라 항상 같은 출력을 반환한다는 가정을 전제로 하는 설명이다.

위와 같은 전제가 지켜진다면 함수의 실행 결과를 테이블에 저장하고 함수의 입력 값을 키로 사용하여 함수의 실행 결과를 “검색”할 수 있다.

이러한 메모이제이션에 사용되는 자료구조가 꼭 테이블이어야만 하는 것은 아니지만, 작가는 순수한 함수의 이러한 특성으로 인해 순수함수의 실행이 일종의 데이터 조회 행위가 될 수 있다는 사실을 강조하고 있는 것이다.

반대로 Haskell의 게으른 평가(지연평가) 때문에 전통적인 컨테이너인 리스트는 함수로 구현될 수도 있다. 예를 들어 자연수의 무한한 리스트는 아래와 같이 간결하게 정의할 수 있다.

nats :: [Integer]
nats = [1..]

첫 번째 라인의 대괄호 쌍은 Haskell의 리스트에 대한 내장 타입 생성자이다. 두 번째 라인의 대괄호는 리스트 리터럴을 만드는 데 사용된다.

당연하겠지만 이런 방식의 무한 리스트는 메모리에 저장할 수 없다. 그래서 필요할 때마다 Integer를 생성하는 함수로 이러한 동작을 구현하는 것이다. Haskell은 사실상 데이터와 코드 사이의 구분을 명확하게 하지 않는다. 리스트는 함수로 간주될 수도 있고, 함수는 인수를 결과에 매핑하는 테이블로 간주될 수도 있다. 특히 후자는 함수의 정의역이 유한하고 크기가 크지 않은 경우에는 꽤나 실용적인 개념이다.

그러나 strlen을 테이블 조회로 구현하는 것은 현실적이지 않다. 왜냐하면 무한히 많은 서로 다른 문자열들이 존재하기 때문이다. 프로그래머로써 우리는 무한을 좋아하지 않겠지만, 카테고리 이론에서는 무한을 아침식사처럼 즐기는 방법을 배워볼 수 있다. 모든 문자열의 집합이나 우주의 과거, 현재, 미래의 상태 같이 무한한 것들도 다뤄볼 수 있다는 말이다.

그래서 필자는 펑터 객체(엔도펑터에 의해 생성된 타입의 객체)를 어떤 타입을 가진 값 또는 값들을 추상적으로 가지고 있는 무언가로 생각하는 것을 추천한다. 물리적으로 그 값을 가지고 있지는 않지만 말이다.

💡 역주

여기서 작가가 펑터가 특정 타입의 값을 직접 가지고 있는 것이 아니라 추상적으로 가지고 있다고 표현하는 의미는 다음과 같다. TypeScript의 Array를 예로 들어보자.
const numbers: number[] = [1, 2, 3]; // 숫자 타입의 배열
const doubledNumbers = numbers.map(x => x * 2); // [2, 4, 6]
여기서 number[] 타입의 배열은 사실 “모든 숫자를 가진 배열”으로 정의되었다고 봐야 한다. 하지만 현재 이 배열이 실제로 모든 숫자를 가지고 있는 것은 아니며, 단지 map과 같은 메소드를 사용하여 배열 내부의 값들을 간접적으로 다룰 수 있는 방법만을 제공하고 있다.

이러한 방법들을 통해 이 배열은 이론상 모든 숫자를 가질 수 있겠지만, 실제로 이 배열이 모든 숫자를 가지고 있는 것은 아니기에 “추상적으로 가지고 있다”라는 표현을 사용한 것이다.

C++에서의 예시를 보자면 std::future가 있다. 언젠가는 값을 가지게 될테지만 반드시 그렇다는 보장은 없으며, Future 내부의 값에 접근하려면 다른 스레드의 실행이 완료될 때까지 기다려야할 수도 있다.

또 다른 예시로는 Haskell의 IO 객체가 있다. 이 객체는 사용자의 입력을 받거나 “Hello World!”가 모니터에 표시된 우주의 상태를 포함할 수도 있다.

이러한 해석들에 따르면 펑터 객체는 매개변수화된 타입의 값을 포함하거나 그런 값을 생성하는 방법을 포함하고 있는 무언가로 바라볼 수 있다. 펑터 내부의 값에 접근하는 동작은 완전히 선택사항이며 펑터의 범위에 꼭 포함되어야 하는 동작도 아니다. 우리가 관심을 가져야하는 부분은 함수를 사용해서 그 값을 조작할 수 있다는 것 뿐이다.

만약 그 값에 접근할 수 있다면 그 조작에 대한 결과를 볼 수 있어야 한다. 그러나 접근할 수 없다면 우리가 오직 신경써야하는 것은 그 조작들이 올바르게 합성되었는지, 그리고 항등 함수를 통한 조작은 아무것도 바꾸지 않는다는 사실 뿐이다. 펑터 객체 내부의 값에 접근하는 것이 그렇게 중요한 일이 아니라는 것을 보여주기 위해 한 가지 예시를 보여주겠다. 여기 인자 a를 완전히 무시하는 타입 생성자가 있다.

data Const c a = Const c

Const 타입 생성자는 c와 a 두 개의 타입을 받는다. 화살표 생성자 때와 마찬가지로 이를 부분적으로 적용해서 펑터를 만들어볼 것이다. Const라고 하는 데이터 생성자는 c 타입의 값 하나만을 취하며, 이는 a에 대한 의존성이 없다는 것을 의미한다. 이 타입 생성자에 대한 fmap의 타입 정의는 아래와 같다.

fmap :: (a -> b) -> Const c a -> Const c b

펑터가 타입 인수를 무시하고 있기 때문에, fmap의 구현에서도 함수 인수를 무시할 수 있다. 함수에 적용할 대상 자체가 없기 때문이다.

instance Functor (Const c) where
    fmap _ (Const v) = Const v

오히려 이런 부분은 컴파일 시간에 발생하는 타입 인자와 런타임에 발생하는 값 사이의 더 강한 구분이 있는 C++에서 더 명확하게 나타날 수 있다.

template<class C, class A>
struct Const {
		Const(C v) : _v(v) {}
		C _v;
};

C++으로 구현된 fmap 또한 함수의 인자를 무시하고 Const 인자를 본래 값과 함께 다시 캐스팅하는 역할을 수행한다.

template<class C, class A, class B>
Const<C, B> fmap(std::function<B(A)> f, Const<C, A> c) {
    return Const<C, B>{c._v};
}

당장 이해하기는 어려울 수 있지만 사실 Const 펑터는 많은 구조들에서 굉장히 중요한 역할을 담당한다. 카테고리 이론에서 Const 펑터는 앞서 언급했던 블랙홀의 엔도펑터, 즉, $\Delta c$ 펑터의 특수한 경우이다. 추후 이러한 개념에 대해서도 더 자세히 다뤄보도록 하겠다.

7.3 펑터 합성(Functor Composition)

펑터가 마치 함수와 같이 합성될 수 있다라는 것은 꽤 직관적인 이해가 가능한 사실이다. 결국 두 펑터의 합성이라는 것은 펑터가 특정 카테고리 내의 객체나 사상에 매핑되는 행위들의 합성이라고 볼 수 있다.

합성된 두 개의 펑터를 거치더라도 항등 사상은 그대로 항등 사상으로 남게 되며, 사상들의 합성 규칙은 여전히 동일한 규칙을 가지게 된다. 이는 굉장히 단순하고 간단한 규칙이며, 특히 엔도펑터를 합성하는 것은 더더욱 쉽다. 혹시 maybeTail 함수를 기억하는가?

이 함수를 Haskell의 내장 리스트 구현을 사용해서 다시 작성해보겠다.

maybeTail :: [a] -> Maybe [a]
maybeTail [] = Nothing
maybeTail (x:xs) = Just xs

지금까지 Nil로 호출하던 빈 리스트 생성자는 빈 대괄호 쌍인 []으로 대체되었고, Cons 생성자는 중위 연산자 :으로 대체되었다.

maybeTail의 결과는 두 펑터 Maybe, []가 a에 작용하는 형태를 지니고 있다. 만약 여기서 합성된 Maybe 리스트의 원소에 어떤 함수 f를 적용하려고 한다면 어떻게 접근해야할까?

함수가 Maybe 리스트의 원소에 도달하기 위해서는 Maybe와 []라는 두 겹의 펑터를 뚫어야 한다. 가장 먼저 외부의 Maybe를 뚫기 위해 fmap을 사용할 수 있다. 그러나 함수 f는 리스트에 대해서는 작동하지 않기 때문에 이대로 이 함수를 Maybe의 안쪽으로 보낼 수는 없다. 우리는 내부 리스트에서 작동할 (fmap f)를 보내야 한다. 한번 Maybe 리스트의 정수 원소들을 제곱하는 예시를 보도록 하자.

square x = x * x

mis :: Maybe [Int]
mis = Just [1, 2, 3]

mis2 = fmap (fmap square) mis

먼저 컴파일러는 타입을 분석한 후, 외부의 fmap에 대해서는 Maybe 인스턴스의 구현을 사용하고, 내부의 fmap에 대해서는 리스트 펑터의 구현을 사용해야한다는 것을 추론해낼 것이다. 물론 지금 시점에서 위 코드가 아래와 같은 코드로 다시 작성될 수 있다는 사실이 바로 이해가 되지는 않을 수도 있다.

mis2 = (fmap . fmap) square mis

그러나 fmap은 하나의 인수에 대한 함수로 간주될 수 있다는 것을 기억해야한다.

fmap :: (a -> b) -> (f a -> f b)

이 경우 (fmap . fmap)안의 두 번째 fmap은 다음과 같은 타입의 인수를 취한다.

square :: Int -> Int

그리고 다음과 같은 타입의 함수를 반환할 것이다.

[Int] -> [Int]

이후 첫 번째 fmap은 이 함수를 취하고 다음과 같은 타입의 함수를 반환한다.

Maybe [Int] -> Maybe [Int]

그리고 비로소 이 함수가 mis에 적용된다. 따라서 두 펑터의 합성은 해당 fmap들의 합성인 펑터라고 볼 수 있다.

다시 카테고리 이론으로 돌아가보자. 대상들의 매핑이 결합법칙을 만족하며, 사상들의 매핑도 결합법칙을 만족하니 펑터의 합성 또한 결합법칙을 만족한다는 사실은 명확하다. 그리고 모든 카테고리에는 당연히 항등 펑터 또한 존재한다. 항등 펑터는 모든 대상과 사상이 자기자신에게 매핑되는 펑터이다.

즉, 펑터는 마치 어떠한 카테고리의 사상들과 동일한 특성을 가지게 된다. 그렇다면 그 카테고리란 무엇일까?

바로 대상이 카테고리이고, 사상이 펑터인 카테고리이다. 즉, 카테고리들의 카테고리라고 할 수 있다. 그러나 모든 카테고리들의 카테고리 또한 카테고리이니, 자기 자신을 자기 자신 안에 포함해야하는 모순에 빠지게 된다.

모든 “작은” 카테고리의 카테고리인 Cat이라는 개념이 있다. 작은 카테고리는 대상들이 집합을 형성하는 카테고리를 가리키며, 심지어 무한하여 셀 수 없는 집합도 “작은” 카테고리로 간주된다. 필자는 이런 개념들이 다양한 추상화 수준에서 동일한 구조가 반복되는 것을 표현할 수 있다는 것에 매우 놀라웠다. 심지어 나중에는 펑터들이 카테고리를 형성하는 케이스도 보게 될 것이다.

원문 보기

👉 Category Theory for Programmers