Skip to content
←

Split View: 코드가 어려운 부분이 아니었다는 말이 왜 그렇게 화를 돋우는가

✨ Learn with Quiz
|

코드가 어려운 부분이 아니었다는 말이 왜 그렇게 화를 돋우는가

회의에서 그 문장이 나오면 방 온도가 바뀝니다

분기 계획 회의에서 누군가 이렇게 말합니다. "이제 코드 짜는 건 어려운 부분이 아니니까, 우리는 뭘 만들지에 더 집중하면 됩니다."

말한 사람은 좋은 뜻이었을 겁니다. 그런데 엔지니어 쪽 표정이 굳습니다. 반박하려니 마땅한 문장이 안 떠오릅니다. "코드도 어렵습니다"라고 하면 방어적으로 들리고, 그냥 넘어가면 다음 분기 인력 계획에 그 전제가 그대로 들어갑니다.

원문이 던진 질문들

2026년 8월 8일에 공개되어 Hacker News에서 크게 논의된 글에서 Senko Rašić는 이 문장을 정면으로 받습니다. 그의 방식은 논증이 아니라 질문 던지기입니다.

코딩이 쉽다면 왜 프로그래머 수요가 그렇게 높았고 임금이 그렇게 높았는가. 코딩이 쉽다면 왜 Clean Code나 The Pragmatic Programmer 같은 두꺼운 책들이 존재하는가. 코딩이 쉽다면 왜 사람들은 자기 코드가 복제되는 것에 화를 내는가. 그리고 방향을 뒤집어서, 무엇을 만들지 정하는 것이 어려운 부분이라면 왜 그렇게 많은 제품 담당자가 갈피를 못 잡는 것처럼 보이는가.

결론은 양자택일을 거부하는 쪽입니다. 둘 다여야 한다는 것이고, AI에게 이해와 판단과 공감과 안목을 외주 주지 말라는 문장으로 끝납니다.

화를 돋우는 진짜 이유는 범주 바꿔치기입니다

이 반박에 동의하면서도, 왜 그 문장이 유독 화를 돋우는지는 조금 다르게 설명할 수 있습니다. 문제는 참인지 거짓인지가 아니라 단어가 도중에 뜻을 바꾼다는 데 있습니다.

"코드는 어려운 부분이 아니다"라는 문장에서 코드는 처음에 좁은 뜻으로 등장합니다. 문법을 알고 API를 찾아 타이핑하는 일입니다. 이 뜻이라면 문장은 옳습니다. 그리고 대화가 진행되면서 같은 단어가 슬며시 넓어집니다. 결론에 이를 때쯤이면 코드는 엔지니어링 전체를 가리키고 있고, 그래서 "엔지니어링은 어려운 부분이 아니다"라는 명제가 아무도 증명하지 않은 채 통과합니다.

듣는 사람이 화가 나는 것은 이 통과 때문입니다. 반박하려면 먼저 단어를 되돌려 놓아야 하는데, 회의 중에 그걸 하려면 말이 길어지고 그러는 사이 논의는 다음 안건으로 넘어갑니다.

이 구조는 다른 직군에서도 똑같이 작동합니다. "디자인은 이제 쉽다"는 문장에서 디자인이 처음에는 시안 만들기를 가리키다가 문제 정의까지 삼키고, "글쓰기는 이제 쉽다"에서 글쓰기가 문장 다듬기를 가리키다가 논증 구성까지 삼킵니다. 매번 같은 자리에서 같은 방식으로 논의가 어긋나는데, 어긋나는 지점이 단어에 있다는 사실은 잘 지적되지 않습니다.

그렇다고 반대편이 다 맞는 것도 아닙니다

여기서 균형을 잡아야 합니다. 원래 문장에도 참인 부분이 분명히 있습니다.

무엇을 만들지 정하는 일은 실제로 어렵습니다. 이해관계자마다 다른 것을 원하고, 그들이 말하는 것과 필요한 것이 다르고, 요구는 만드는 도중에 바뀝니다. 이 영역에서의 실패는 코드가 아무리 좋아도 회수되지 않습니다. 잘 만든 필요 없는 기능은 그냥 잘 만든 낭비입니다.

그래서 이 논쟁을 "코드가 어렵다 vs 요구가 어렵다"로 끌고 가면 양쪽 다 절반씩 맞는 자리에서 끝나지 않고, 서로의 절반을 인정하지 않은 채 반복됩니다. 나갈 방법은 단어를 쪼개는 것입니다.

코드를 세 층으로 쪼개면 논쟁이 끝납니다

코딩이라고 뭉뚱그려 부르는 활동은 최소한 세 층으로 나뉩니다.

층무엇을 하는가대표적 판단
1. 표현문법, API 사용법, 보일러플레이트, 정형화된 변환이 언어에서 이건 어떻게 쓰는가
2. 국소 설계한 모듈 안의 구조, 경계, 이름, 제약 충족이 책임을 어디에 둘 것인가
3. 시스템불변식, 실패 양상, 마이그레이션 경로, 운영 비용이게 3년 뒤에 어떻게 무너지는가

이 구분을 넣고 나면 두 주장이 각각 어디서 참인지 즉시 보입니다. 코드가 어려운 부분이 아니라는 말은 1층에 대해 강하게 참이고, 2층에 대해 부분적으로 참이며, 3층에 대해서는 근거가 없습니다. 그리고 원래 문장이 화를 돋우는 이유는 1층의 참을 3층까지 끌고 가기 때문입니다.

우리 팀이 어느 층에 시간을 쓰는지 재 보기

이 구분이 유용한 이유는 잴 수 있기 때문입니다. 논쟁을 감으로 하지 않으려면 자기 팀의 분포를 알아야 합니다.

2주 실험: 완료한 작업마다 태그 하나를 붙인다

L1  대부분의 시간을 문법, API, 정형화된 변환에 썼다
L2  대부분의 시간을 구조와 경계와 제약을 정하는 데 썼다
L3  대부분의 시간을 불변식, 실패 양상, 마이그레이션을 따지는 데 썼다
RQ  대부분의 시간을 무엇을 만들지 알아내는 데 썼다

2주 뒤 네 숫자를 본다. 논쟁 대신 이 분포를 놓고 이야기한다.

해 보면 대개 팀마다 결과가 크게 다릅니다. 신규 서비스를 만드는 팀은 L1과 RQ가 높고, 10년 된 시스템을 유지하는 팀은 L3가 압도적입니다. 그리고 이 분포가 다르기 때문에 두 팀은 같은 문장을 듣고도 전혀 다르게 반응합니다. 한쪽에게는 그 문장이 사실이고, 다른 쪽에게는 자기 일이 통째로 지워진 소리로 들립니다.

태그는 작업 하나에 하나만 붙이는 것이 중요합니다. 여러 개를 허용하면 전부 세 개씩 붙어서 분포가 사라집니다. 어느 층에 시간을 가장 많이 썼는지 하나만 고르게 하면, 애매한 작업일수록 고르는 과정에서 스스로 무슨 일을 했는지 정리하게 되는 효과도 생깁니다. 2주로 부족하면 4주로 늘리되, 결과를 사람별 평가에 쓰지 않는다는 것을 먼저 약속해야 숫자가 정직해집니다.

층마다 도구의 값어치가 다릅니다

분포를 알고 나면 다음 결정이 쉬워집니다. AI 도구의 값어치도 층마다 다르기 때문입니다.

1층에서는 값어치가 큽니다. 이건 논쟁의 여지가 별로 없고, 실제로 대부분의 생산성 향상 체감이 여기서 나옵니다. 2층에서는 값어치가 조건부입니다. 제약을 명시적으로 줄 수 있으면 좋은 안을 여럿 받을 수 있지만, 제약을 말로 못 옮기면 무난한 기본값이 돌아옵니다. 3층에서는 값어치가 가장 작습니다. 불변식과 실패 양상의 상당 부분이 어디에도 적혀 있지 않고 사람의 머릿속에만 있기 때문입니다.

그래서 3층이 두꺼운 조직에서 "코드는 이제 쉽다"를 전제로 인력 계획을 세우면 정확히 그 조직이 가장 크게 다칩니다. 반대로 1층이 두꺼운 조직에서 도구 도입을 미루는 것도 손해입니다. 같은 문장이 조직마다 다른 처방으로 이어져야 합니다.

그래서 무엇을 연습할 것인가

원문의 결론은 이해와 판단과 공감과 안목을 외주 주지 말라는 것이었습니다. 층 구분을 얹으면 이 조언이 더 구체적인 행동이 됩니다.

3층은 문서화로 옮길 수 있는 부분이 생각보다 많습니다. 불변식을 코드 주석이 아니라 실행 가능한 검사로 만들고, 알려진 실패 양상을 런북에 적고, 마이그레이션 경로를 결정할 때 버린 대안을 남깁니다. 이건 도구를 위해서가 아니라 사람을 위해서입니다. 머릿속에만 있는 지식은 그 사람이 팀을 떠나면 사라지고, 그 순간 조직의 3층은 정말로 비어 버립니다.

2층은 연습 방법이 조금 다릅니다. 이 층의 실력은 제약을 말로 옮기는 능력과 거의 같기 때문에, 구현을 시작하기 전에 지켜야 할 조건을 목록으로 적어 보는 습관이 그대로 훈련이 됩니다. 조건을 못 적겠다면 아직 문제를 이해하지 못한 것이고, 그 상태에서 나온 결과물은 누가 만들었든 검토가 불가능합니다.

그리고 회의로 돌아가서, 다음에 그 문장이 나오면 이렇게 되물으면 됩니다. 어느 층을 말씀하시는 건가요. 이 질문 하나로 대화는 감정 문제에서 계획 문제로 바뀌고, 방 안의 누구도 자기 일을 변호할 필요가 없어집니다.

참고 자료

Why the Claim That Code Was Never the Hard Part Makes People So Angry

When That Sentence Comes Up in a Meeting, the Temperature of the Room Changes

In a quarterly planning meeting someone says: "Writing code is not the hard part anymore, so we can focus more on what to build."

The person who said it probably meant well. But the engineers in the room go stiff. You want to push back and no good sentence comes to mind. Saying "code is hard too" sounds defensive, and letting it pass means that premise goes straight into next quarter's headcount plan.

The Questions the Original Post Throws Out

In a post published on August 8, 2026 that was heavily discussed on Hacker News, Senko Rašić meets this sentence head on. His method is not argumentation but asking questions.

If coding is easy, why was demand for programmers so high and why were wages so high? If coding is easy, why do thick books like Clean Code and The Pragmatic Programmer exist? If coding is easy, why do people get angry about their code being copied? And flipping the direction: if deciding what to build is the hard part, why do so many product people look like they cannot find their footing?

The conclusion refuses the either-or. It has to be both, and the piece ends with a sentence telling you not to outsource understanding, judgment, empathy, and taste to AI.

The Real Reason It Provokes Anger Is Equivocation

I agree with this rebuttal, and yet why that sentence in particular provokes anger can be explained a bit differently. The problem is not whether it is true or false but that the word changes meaning midway.

In the sentence "code is not the hard part," code first appears in a narrow sense: knowing the syntax, looking up an API, typing. In that sense the sentence is correct. Then, as the conversation proceeds, the same word quietly widens. By the time we reach the conclusion, code refers to engineering as a whole, and so the proposition "engineering is not the hard part" passes without anyone having proved it.

The listener gets angry because of that passage. To push back you first have to put the word back where it was, and doing that mid-meeting takes many sentences, and while you are at it the discussion moves to the next agenda item.

This structure works identically in other professions. In "design is easy now," design starts by referring to producing mockups and swallows problem definition; in "writing is easy now," writing starts by referring to polishing sentences and swallows the construction of an argument. Every time, the discussion goes off the rails at the same place in the same way, and the fact that the derailment lives in a word is rarely pointed out.

That Does Not Mean the Other Side Is Entirely Right

Here we have to hold the balance. The original sentence clearly has a true part.

Deciding what to build really is hard. Every stakeholder wants something different, what they say and what they need are different, and requirements change while you are building. Failure in this area is not recovered by however good the code is. A well-built feature nobody needed is just well-built waste.

So if you drag this argument into "code is hard vs. requirements are hard," it does not end at the place where each side is half right; it repeats without either half being acknowledged. The way out is to split the word.

Split Code into Three Layers and the Argument Ends

The activity we lump together as coding divides into at least three layers.

LayerWhat you doRepresentative judgment
1. ExpressionSyntax, API usage, boilerplate, formulaic transformationsHow do I write this in this language
2. Local designStructure inside one module, boundaries, names, satisfying constraintsWhere do I put this responsibility
3. SystemInvariants, failure modes, migration paths, operational costHow does this collapse three years from now

Once this distinction is in place you can see immediately where each claim is true. The statement that code is not the hard part is strongly true of layer one, partially true of layer two, and unsupported for layer three. And the reason the original sentence provokes anger is that it drags the truth of layer one all the way up to layer three.

Measuring Which Layer Your Team Spends Time On

This distinction is useful because it can be measured. To stop arguing by feel, you need to know your own team's distribution.

Two-week experiment: attach exactly one tag to each completed task

L1  spent most of the time on syntax, APIs, formulaic transformations
L2  spent most of the time deciding structure, boundaries, constraints
L3  spent most of the time weighing invariants, failure modes, migrations
RQ  spent most of the time figuring out what to build

After two weeks, look at the four numbers. Discuss this distribution instead of arguing.

Try it and the results usually differ a lot from team to team. A team building a new service is high on L1 and RQ; a team maintaining a ten-year-old system is overwhelmingly L3. And because these distributions differ, the two teams react to the same sentence in completely different ways. For one of them the sentence is a fact; for the other it sounds like their whole job was just erased.

It matters that a task gets exactly one tag. Allow several and everything gets three tags and the distribution disappears. Making people pick only the layer they spent the most time on has a side benefit: the more ambiguous the task, the more the act of choosing forces them to sort out what they actually did. If two weeks is not enough, stretch it to four, but you have to promise up front that the results will not be used in individual performance reviews or the numbers will not be honest.

Tools Are Worth Different Amounts at Each Layer

Once you know the distribution the next decision gets easier, because AI tools are worth different amounts at each layer.

At layer one the value is large. There is little room for argument here, and in fact most of the felt productivity gain comes from here. At layer two the value is conditional. If you can state the constraints explicitly you can get several good options, but if you cannot put the constraints into words you get a competent default back. At layer three the value is smallest, because a large share of the invariants and failure modes are written down nowhere and live only in people's heads.

So an organization thick with layer three that builds its headcount plan on the premise that "code is easy now" is exactly the organization that gets hurt the most. Conversely, an organization thick with layer one that delays adopting tools is losing out too. The same sentence has to lead to a different prescription in each organization.

So What Should You Practice

The original conclusion was not to outsource understanding, judgment, empathy, and taste. Put the layer distinction on top and that advice turns into more concrete behavior.

More of layer three can be moved into documentation than you would think. Turn invariants into executable checks rather than code comments, write known failure modes into the runbook, and record the alternatives you discarded when you decided a migration path. This is not for the tools, it is for the people. Knowledge that lives only in someone's head disappears when that person leaves the team, and at that moment the organization's layer three really is empty.

Layer two takes a slightly different practice. Skill at this layer is nearly identical to the ability to put constraints into words, so the habit of writing out the conditions you must satisfy as a list before you start implementing is itself the training. If you cannot write the conditions, you do not understand the problem yet, and a product that came out of that state cannot be reviewed no matter who made it.

And back to the meeting: the next time that sentence comes up, you can just ask back. Which layer do you mean? That one question turns the conversation from an emotional issue into a planning issue, and nobody in the room has to defend their job.

References