Skip to content
←

Split View: 마찰이 사라지면 안목이 남는 게 아니라 안목을 기를 길이 사라집니다

✨ Learn with Quiz
|

마찰이 사라지면 안목이 남는 게 아니라 안목을 기를 길이 사라집니다

리뷰 큐에 올라온 PR 열두 개가 전부 괜찮습니다

월요일 아침, 리뷰 대기열에 PR이 열두 개 있습니다. 전부 테스트가 붙어 있고, 이름이 단정하고, 주석이 성실합니다. 하나하나 보면 반려할 이유가 없습니다.

그런데 다 합쳐 놓고 보면 이 열두 개 중 다섯 개는 애초에 만들지 않았어야 하는 기능입니다. 옵션이 하나 더 늘었고, 설정 키가 세 개 늘었고, 앞으로 이걸 유지할 사람이 늘었습니다. 반려 사유를 쓰려고 하면 "코드는 괜찮은데 이걸 왜 만드는지 모르겠다"는 문장밖에 안 나오고, 그 문장은 리뷰 코멘트로 쓰기에 무례해 보입니다.

마찰은 필터였고, 필터는 사라진 뒤에야 보입니다

2026년 8월 6일에 공개된 Taste Is All That Is Left는 이 상황을 정면으로 다룹니다. 글의 핵심은 노력이 필터였다는 관찰입니다. 그리고 모든 필터가 그렇듯, 그것은 제거되기 전까지 보이지 않았습니다.

예전에는 어떤 기능을 만들려면 사흘이 들었습니다. 사흘이라는 비용은 그 자체로 심사였습니다. 사흘 쓸 만한 일인가를 스스로에게 묻게 만들었고, 애매한 아이디어의 절반은 그 질문에서 죽었습니다. 지금은 같은 기능이 40분이면 나옵니다. 40분은 심사를 통과시키기에 너무 싼 값입니다.

그래서 만들지 말았어야 할 것들이 만들어집니다. 그리고 그것들은 나쁘게 만들어지지 않았기 때문에 반박하기가 더 어렵습니다.

안목이 만들어지던 경로의 모양

같은 글이 더 중요하게 짚는 것은 다음 대목입니다. 안목은 느리고 멍청하고 창피한 방식으로 만들어진다는 것입니다. 나쁜 것을 만들고, 그것과 함께 살아야 하고, 사람들 앞에서 실패하는 과정입니다.

이 순서를 뜯어보면 각 단계가 왜 필요한지 보입니다. 나쁜 것을 만드는 단계에서 "이렇게 하면 이렇게 된다"는 인과가 몸에 새겨집니다. 그것과 함께 사는 단계에서 유지보수 비용이 감각으로 바뀝니다. 실패하는 단계에서 자기 판단과 현실의 차이가 측정됩니다.

셋 다 시간이 걸리고 셋 다 불쾌합니다. 그리고 셋 다 결과물이 나쁠 때만 발생합니다.

지금 신입에게 벌어지는 일

여기서 문제가 생깁니다. 원문의 관찰대로, 지금 시작하는 사람들은 나쁜 버전을 내보내고 그 안에 앉아 있어 볼 기회를 갖지 못합니다. 도구가 무난한 버전을 공짜로 주기 때문입니다.

이건 능력의 문제가 아닙니다. 오히려 반대입니다. 지금 신입은 3년 전 신입보다 훨씬 빨리 동작하는 것을 만듭니다. 다만 그 과정에서 "이 선택이 6개월 뒤에 어떤 대가를 요구하는가"를 배울 사건이 발생하지 않습니다. 유창함은 얻고 견습은 건너뜁니다.

그리고 이 간극은 지표에 잡히지 않습니다. 처리량, 리드 타임, PR 수 어디에도 나타나지 않다가, 2년쯤 지나 아무도 구조를 결정하지 못하는 팀으로 나타납니다. 회의에서 두 안 중 무엇을 고를지 아무도 강하게 말하지 못하고, 결국 둘 다 만들거나 가장 최근에 말한 사람의 안으로 갑니다.

한 가지 덧붙이면, 이건 세대에 대한 이야기가 아닙니다. 경력 10년 차도 똑같이 겪습니다. 익숙하지 않은 영역에서 도구가 주는 무난한 결과를 받아들이기 시작하면, 그 영역에 대한 판단력은 거기서 성장을 멈춥니다. 다만 이미 다른 영역에서 쌓은 감각이 있어서 스스로 눈치채기가 더 어려울 뿐입니다.

"안목이 전부"라는 결론이 위험해지는 지점

원문의 마지막 주장은 강합니다. 무엇을 만들 가치가 있는지 말해 줄 수 있는 사람은 거의 없고, 그것이 언제나 더 어려운 기술이었으며, 이제는 그것만 남았다는 것입니다.

진단으로는 설득력이 있는데, 이 문장을 처방으로 바꿀 때 조심해야 합니다. "이제 안목만 있으면 된다"로 읽으면 곤란합니다. 안목은 만드는 경험의 부산물이지 대체물이 아니기 때문입니다. 만들어 본 적 없는 사람의 판단은 안목이 아니라 취향이고, 둘의 차이는 틀렸을 때 드러납니다.

더 정확한 정리는 이쪽입니다. 안목의 가치가 올라간 동시에 안목의 공급 경로가 막혔다. 두 가지가 같이 일어났기 때문에 이건 좋은 소식이 아니라 문제입니다.

판정을 관측 가능하게 만들기

그래서 개인이 할 수 있는 첫 번째 일은 판정을 밖으로 꺼내는 것입니다. 안목은 원래 말없이 작동하는 능력이고, 말없이 작동하는 것은 검증도 전수도 되지 않습니다.

구체적으로는 이렇습니다. 무언가를 만들기 전에 두세 줄을 씁니다. 무엇을 만들지, 왜 지금인지, 만들지 않으면 어떤 일이 벌어지는지. 그리고 만든 뒤에 그 메모를 다시 읽습니다. 6개월쯤 쌓이면 자기 예측이 어느 방향으로 틀리는지가 보입니다. 대부분의 사람은 "만들지 않으면 벌어질 일"을 과대평가하는 쪽으로 일관되게 틀립니다.

이 메모가 설계 문서일 필요는 없습니다. 오히려 길면 안 씁니다. 커밋 메시지 본문이든 이슈의 첫 코멘트든, 나중에 다시 찾을 수 있는 곳에 세 줄이면 충분합니다. 중요한 것은 분량이 아니라 판정이 내려진 시점에 기록되었다는 사실입니다. 결과를 알고 나서 쓴 회고는 자기 판단을 재구성해 버려서 학습 자료로 쓸 수 없습니다.

마찰을 의도적으로 복원하는 세 가지 습관

두 번째는 사라진 마찰을 인위적으로 되살리는 것입니다. 전부 되살릴 필요는 없고, 학습이 일어나던 지점만 고르면 됩니다.

습관구체적 행동되살아나는 것
먼저 혼자 답을 정한다도구를 부르기 전에 설계를 한 문단으로 쓴다자기 판단과 무난한 기본값의 차이 측정
대안을 강제한다첫 결과를 받고 나서 다른 접근 두 개를 더 만들어 비교한다선택지가 여럿일 때만 생기는 판단
내가 만든 것과 함께 산다만든 기능의 운영과 장애 대응을 최소 한 분기 직접 맡는다유지보수 비용이 감각으로 바뀌는 경험

세 번째 항목이 가장 효과가 크고 가장 자주 생략됩니다. 만든 사람과 유지하는 사람이 분리되어 있으면 안목은 어느 쪽에도 쌓이지 않습니다. 만든 쪽은 대가를 치르지 않고, 유지하는 쪽은 선택의 맥락을 모릅니다. 조직도가 그렇게 그려져 있다면 개인이 바꿀 수 없는 경우도 많은데, 그럴 때는 최소한 자기가 만든 것의 장애 알림만이라도 계속 받는 편이 낫습니다.

두 번째 항목에도 한 가지 함정이 있습니다. 대안 세 개를 도구에게 한 번에 만들어 달라고 하면 대체로 서로 비슷한 세 개가 나옵니다. 같은 기본값 주변을 맴돌기 때문입니다. 그래서 최소한 하나는 손으로, 그리고 가능하면 정반대 제약을 걸고 만들어야 비교가 성립합니다. 예를 들어 "설정을 하나도 추가하지 않고 푼다"는 제약을 걸어 보는 식입니다.

팀에서 바꿀 수 있는 것은 리뷰의 질문입니다

마지막은 조직 차원입니다. 지금의 코드 리뷰는 "이 코드가 맞는가"를 묻도록 설계되어 있고, 그 질문은 도구가 이미 상당히 잘 대답합니다. 리뷰가 계속 그 질문만 하면 리뷰에서 배울 것이 남지 않습니다.

질문을 하나 앞으로 옮기면 됩니다. PR 템플릿에 "고려했다가 버린 대안과 그 이유" 칸을 넣고, 그 칸이 비어 있으면 리뷰를 시작하지 않는 규칙을 두는 식입니다. 이 한 칸이 하는 일은 두 가지입니다. 작성자에게 선택을 언어화하게 만들고, 리뷰어에게 코드가 아니라 판단을 볼 자리를 줍니다.

첫머리의 PR 열두 개로 돌아가면, 그중 다섯 개는 이 칸에서 걸립니다. 버린 대안이 없다는 것은 대개 대안을 생각하지 않았다는 뜻이고, 대안을 생각하지 않았다는 것은 만들지 않는다는 선택지도 검토되지 않았다는 뜻이기 때문입니다.

참고 자료

When Friction Disappears, Taste Does Not Remain — the Path to Growing Taste Disappears

All Twelve PRs in the Review Queue Are Fine

Monday morning, twelve PRs in the review queue. Every one of them has tests attached, tidy names, conscientious comments. Look at them one by one and there is no reason to reject any of them.

But look at them all together and five of the twelve are features that should never have been built in the first place. There is one more option, three more config keys, and one more person who will have to maintain this going forward. When you try to write the rejection reason, the only sentence that comes out is "the code is fine but I do not see why we are building this," and that sentence looks rude as a review comment.

Friction Was a Filter, and a Filter Is Only Visible After It Is Gone

Taste Is All That Is Left, published on August 6, 2026, takes this situation head on. The core of the piece is the observation that effort was a filter. And, as with every filter, it was invisible until it was removed.

It used to take three days to build a feature. That three-day cost was itself a screening. It forced you to ask yourself whether the thing was worth three days, and half of the mediocre ideas died at that question. Now the same feature comes out in 40 minutes. Forty minutes is too cheap a price to pass a screening.

So things that should not have been built get built. And they are harder to argue against because they were not built badly.

The Shape of the Path That Made Taste

What the same piece points to as more important is the next passage: that taste is built slowly, stupidly, and embarrassingly. It is the process of making bad things, having to live with them, and failing in front of people.

Take this sequence apart and you can see why each stage is needed. In the stage of making a bad thing, the causal link "do it this way and this happens" gets written into your body. In the stage of living with it, maintenance cost turns into an instinct. In the stage of failing, the gap between your own judgment and reality gets measured.

All three take time and all three are unpleasant. And all three happen only when the artifact is bad.

What Is Happening to Juniors Right Now

Here is where the problem arises. As the original observes, people starting now do not get the chance to ship a bad version and sit inside it, because the tool gives them a competent version for free.

This is not a matter of ability. Quite the opposite. A junior today builds something that works far faster than a junior of three years ago. It is just that in the process, the event from which they would learn "what will this choice cost me in six months" never occurs. They gain fluency and skip the apprenticeship.

And this gap does not register in metrics. It shows up in neither throughput nor lead time nor PR count, and then about two years later it shows up as a team where nobody can decide the structure. In a meeting nobody argues strongly for one of two options, and in the end you build both, or you go with the option of whoever spoke most recently.

One thing to add: this is not a story about a generation. Someone ten years in experiences it identically. The moment you start accepting the competent output a tool gives you in an area you are not familiar with, your judgment in that area stops growing right there. The only difference is that the instincts you built in other areas make it harder to notice on your own.

Where the Conclusion That Taste Is Everything Turns Dangerous

The original's final claim is strong: almost nobody can tell you what is worth building, that was always the harder skill, and now it is all that is left.

As a diagnosis it is persuasive, but you have to be careful when you turn this sentence into a prescription. Reading it as "all you need now is taste" is a problem, because taste is a byproduct of the experience of making, not a substitute for it. The judgment of someone who has never built anything is not taste but preference, and the difference between the two shows up when they are wrong.

The more accurate formulation is this one. The value of taste went up at the same moment the supply route for taste got blocked. Because both happened together, this is not good news but a problem.

Making Judgment Observable

So the first thing an individual can do is get the judgment outside. Taste is by nature an ability that operates silently, and what operates silently can be neither verified nor transmitted.

Concretely, it goes like this. Before you build something, write two or three lines. What you are going to build, why now, and what happens if you do not build it. Then after you build it, read the note again. Once six months of these accumulate, you can see which direction your predictions err in. Most people err consistently toward overestimating "what happens if I do not build it."

This note does not have to be a design document. In fact, if it is long you will not write it. The body of a commit message or the first comment on an issue is fine; three lines somewhere you can find again is enough. What matters is not the length but the fact that it was recorded at the moment the judgment was made. A retrospective written after you know the outcome reconstructs your own judgment and is useless as learning material.

Three Habits That Deliberately Restore Friction

The second thing is to artificially revive the friction that disappeared. You do not have to revive all of it, only the points where learning used to happen.

HabitConcrete actionWhat it revives
Decide your own answer firstWrite the design in one paragraph before you call the toolMeasuring the gap between your judgment and the competent default
Force alternativesAfter the first result, build two more approaches and compareJudgment that only exists when there are several options
Live with what you builtOwn the operations and incident response of the feature you built for at least a quarterThe experience of maintenance cost turning into instinct

The third item has the biggest effect and is the most often skipped. If the person who builds and the person who maintains are separated, taste accumulates on neither side. The builder does not pay the price, and the maintainer does not know the context of the choices. When the org chart is drawn that way there is often nothing an individual can do, but in that case it is better to at least keep receiving the incident alerts for what you built.

The second item has a trap of its own. Ask a tool to produce three alternatives in one go and you will generally get three that resemble each other, because they circle the same default. So at least one has to be made by hand, and if possible under the opposite constraint, before the comparison holds. For example, try the constraint "solve it without adding a single configuration option."

What a Team Can Change Is the Question the Review Asks

The last part is organizational. Code review today is designed to ask "is this code correct," and tools already answer that question quite well. If reviews keep asking only that question, there will be nothing left to learn from a review.

Move the question one step earlier. Put a field for "alternatives considered and discarded, and why" in the PR template, and adopt a rule that review does not start while that field is empty. This one field does two things. It makes the author put the choice into words, and it gives the reviewer a place to look at judgment rather than at code.

Back to the twelve PRs at the top: five of them get caught in this field. Having no discarded alternatives usually means no alternatives were considered, and not considering alternatives means the option of not building it was never examined either.

References