Skip to content
←

Split View: 무엇이 비싸게 남는가 — 생성이 싸질 때 값이 오르는 네 가지

✨ Learn with Quiz
|

무엇이 비싸게 남는가 — 생성이 싸질 때 값이 오르는 네 가지

도구 목록으로 답하면 그 답은 곧 낡습니다

앞으로 무엇을 준비해야 하느냐는 질문에 가장 흔히 돌아오는 답은 배울 것의 목록입니다. 목록은 읽기 편하고, 편한 만큼 빨리 낡습니다. 5년 전 목록을 지금 꺼내 보면 절반은 이름조차 사라졌고, 남은 절반은 다른 것에 흡수됐습니다.

목록이 낡는 이유는 항목을 잘못 골라서가 아니라 축을 잘못 잡아서입니다. 도구는 축이 될 수 없습니다. 도구는 변수입니다. 필요한 것은 도구가 바뀌어도 유지되는 판별식입니다.

이 시리즈가 쓰는 판별식은 하나입니다. 값이 남는 기술은 검증 비용이 비싼 기술이다. 코드를 쓰는 일은 싸졌지만, 그 코드가 맞는지 판정하는 일과 애초에 그것이 만들 값어치가 있었는지 판정하는 일은 싸지지 않았습니다. 앞으로 아홉 편에서 다룰 능력은 전부 이 문장에서 도출됩니다.

두 축으로 네 칸을 그리면 보이는 것

한 가지 일을 두 개의 비용으로 나눠 봅시다. 결과물을 만드는 데 드는 생성 비용, 그리고 그 결과물이 맞는지 확인하는 데 드는 검증 비용입니다.

검증이 싸다검증이 비싸다
생성이 싸다이미 자동화됐고 값이 없다지금 대부분의 일이 옮겨간 칸
생성이 비싸다자동화가 다음으로 먹는 칸여전히 사람이 남는 칸

왼쪽 위는 형식 변환, 보일러플레이트, 정형화된 이관 작업입니다. 여기에 실력을 쌓아 온 사람은 이미 값이 떨어지는 것을 겪었습니다.

왼쪽 아래가 흥미롭습니다. 만들기는 어려운데 맞았는지 판정하기는 쉬운 일입니다. 정답이 정해진 알고리즘 문제, 컴파일 통과 여부로 갈리는 변환, 벤치마크 점수가 있는 최적화가 여기 있습니다. 판정 기준이 존재하면 시행착오를 기계가 대신 반복할 수 있기 때문에, 이 칸은 생성이 아무리 어려워도 오래 버티지 못합니다. 자동화의 진짜 조건은 문제가 쉬운 것이 아니라 채점이 가능한 것입니다.

오른쪽 아래는 만들기도 어렵고 판정도 어려운 일입니다. 10년 된 시스템의 마이그레이션 경로를 정하는 일, 규제와 계약과 성능이 동시에 걸린 설계를 고르는 일이 여기 있습니다.

위험한 칸은 오른쪽 위입니다

가장 주목할 곳은 오른쪽 위입니다. 만들기는 싸졌는데 판정은 여전히 비싼 칸이고, 오늘 소프트웨어 작업의 상당 부분이 이 칸으로 이사했습니다.

이 칸이 위험한 이유는 결과물이 그럴듯해 보이기 때문입니다. 틀린 결과가 눈에 띄게 틀려 보이면 비용은 작습니다. 문제는 거의 맞는 결과입니다. Stack Overflow가 2025년에 공개한 개발자 설문에서, AI 도구 사용 시 가장 큰 불만으로 "거의 맞지만 정확히는 맞지 않은 해답"을 꼽은 응답이 66퍼센트였습니다. 이어서 45퍼센트가 AI가 만든 코드를 디버깅하는 데 시간이 더 든다고 답했습니다. 같은 조사에서 도구 정확성을 신뢰하지 않는다는 응답이 46퍼센트로, 신뢰한다는 33퍼센트보다 많았습니다.

설문은 체감의 기록이지 성과의 측정이 아닙니다. 그래서 이 숫자를 생산성 결론으로 옮기면 안 됩니다. 다만 한 가지는 분명하게 읽힙니다. 병목이 만드는 쪽에서 판정하는 쪽으로 옮겨갔다는 것을 사용자들이 스스로 보고하고 있다는 사실입니다.

검증 비용을 비싸게 만드는 것들

그러면 무엇이 판정을 비싸게 만드느냐가 다음 질문입니다. 대체로 네 가지입니다.

첫째는 암묵적 맥락입니다. 판정에 필요한 정보가 코드에도 문서에도 없고 사람의 기억과 조직의 관행에만 있을 때, 그 정보를 가진 사람만이 판정할 수 있습니다.

둘째는 지연된 결과입니다. 지금 초록불이어도 6개월 뒤 운영에서 무너지는 설계가 있습니다. 결과가 늦게 오는 일일수록 지금 판정하려면 경험에서 온 예측이 필요합니다.

셋째는 판정 기준의 부재입니다. 랭킹의 품질, 인터페이스의 좋고 나쁨, 모델 출력의 적절함처럼 정답표가 없는 영역에서는 판정 자체를 설계해야 합니다.

넷째는 책임 귀속입니다. 누군가는 이 결정에 이름을 걸어야 하고, 서명은 위임되지 않습니다. 서명하려면 이해해야 하므로, 책임은 이해를 강제하는 장치이기도 합니다.

반전 — 비싼 검증을 싸게 만드는 것이 일입니다

여기까지만 읽으면 결론이 이상해집니다. 검증이 비쌀수록 내 값이 오른다면, 검증을 비싸게 유지하는 것이 이득이라는 말이 되기 때문입니다. 그건 틀렸고, 그 지점에서 이 틀이 실무와 연결됩니다.

엔지니어의 일은 정확히 반대입니다. 비싼 판정을 싼 판정으로 바꾸는 장치를 만드는 것입니다. 사람이 매번 읽어야 알던 것을 타입으로 못 박고, 운영에서 6개월 뒤에 드러나던 것을 배포 시점의 지표로 당겨오고, 정답표가 없던 영역에 대리 지표와 표본 검토 절차를 세웁니다.

그래서 정리하면 이렇습니다. 판정을 수행하는 일은 자동화되고, 판정을 설계하는 일은 남습니다. 좋은 테스트를 짜는 것은 비싸고 그 테스트를 돌리는 것은 공짜인 것과 같은 구조입니다. 이 시리즈에서 다루는 능력은 전부 이 설계 쪽에 있습니다.

체감을 근거로 쓰지 않기

마지막으로 하나 짚어야 할 것이 있습니다. 이 영역에서 자기 체감은 믿을 만한 근거가 아닙니다.

METR이 2025년 7월에 공개한 무작위 대조 실험이 이를 잘 보여 줍니다. 자기 오픈소스 저장소에 익숙한 숙련 개발자 16명이 246개 작업을 수행했고, 작업마다 AI 도구 사용 허용 여부가 무작위로 배정됐습니다. 결과는 도구 사용이 허용된 작업이 19퍼센트 더 오래 걸린 것이었습니다. 참가자들은 실험 전 24퍼센트 빨라질 것이라 예상했고, 실험이 끝난 뒤에도 20퍼센트 빨라졌다고 믿고 있었습니다.

이 결과를 일반화하면 안 됩니다. 연구진 스스로 표본이 16명이고, 참가자가 자기 코드베이스에 매우 익숙했으며, 품질 기준이 엄격한 저장소였고, 도구 숙련이 더 쌓이면 결과가 달라질 수 있다고 밝히고 있습니다. 이 실험이 말해 주는 것은 도구가 나쁘다는 것이 아니라, 빨라졌다는 느낌과 실제로 빨라진 것 사이에 방향이 반대인 간극이 존재할 수 있다는 사실입니다.

그래서 이 시리즈의 조언은 전부 기록으로 확인하라는 단서를 달고 갑니다. 느낌은 가설이고, 가설은 재야 합니다.

직접 해보기

이번 주에 할 수 있는 것 하나만 고른다면 이것입니다. 지난 2주 동안 한 작업을 열 개쯤 적고, 각각을 위 네 칸 중 하나에 넣어 보세요. 넣기 애매한 작업이 있다면 그것이 가장 중요한 신호입니다. 판정 기준을 아직 못 정한 일이라는 뜻이기 때문입니다.

  • 엔지니어 스킬 코스 — 리눅스, 네트워크, DB, 쿠버네티스, AI/LLM 트랙을 유닛 단위로 따라가며 자기 위치를 확인할 수 있습니다.
  • 사고력 훈련소 — 처음 보는 문제 앞에서 쓸 수 있는 아홉 개의 수를 연습합니다. 판정 기준을 세우는 연습에 가장 가깝습니다.

이 틀이 안 맞는 경우도 적어 둡니다. 사람 수가 적고 실패 비용이 낮은 초기 제품에서는 판정 장치를 먼저 깔다가 제품을 못 내는 쪽이 더 큰 손해입니다. 검증 설계는 걸린 것이 있을 때 값어치가 생깁니다.

이어서 읽기

비싸게 남는 기술 시리즈

참고 자료

What Stays Expensive — Four Things That Gain Value When Generation Gets Cheap

A List of Tools Goes Stale Fast

Ask what to prepare for and the most common answer is a list of things to learn. Lists are easy to read, and they go stale just as easily. Pull up a list from five years ago: half the entries no longer exist by name, and the surviving half got absorbed into something else.

Lists go stale not because the entries were badly chosen but because the axis was. A tool cannot be an axis. A tool is a variable. What you need is a test that survives the tools changing.

This series uses exactly one such test: the skills that hold value are the ones that stay expensive to verify. Writing code got cheap. Judging whether that code is right, and whether the thing was worth building in the first place, did not. Every capability covered in the next nine parts is derived from that one sentence.

Two Axes, Four Quadrants

Split any piece of work into two costs. The generation cost of producing the artifact, and the verification cost of confirming the artifact is right.

Verification is cheapVerification is expensive
Generation is cheapAlready automated, no value leftWhere most work has moved
Generation is expensiveThe next quadrant automation eatsWhere people still remain

Top left is format conversion, boilerplate, routine migration work. Anyone whose skill sat here has already watched its price fall.

Bottom left is the interesting one: hard to produce, easy to check. Algorithm problems with a known answer, transformations that pass or fail on compilation, optimizations with a benchmark score. When a scoring rule exists, a machine can run the trial-and-error loop for you, so this quadrant does not hold no matter how hard the generation is. The real precondition for automation is not that the problem is easy but that the output is gradeable.

Bottom right is hard to produce and hard to judge: choosing the migration path for a ten-year-old system, picking a design where regulation, contract, and performance all pull at once.

The Dangerous Quadrant Is Top Right

The quadrant to watch is the top right: cheap to produce, still expensive to judge. A large share of today's software work has moved into it.

It is dangerous because the output looks plausible. A wrong answer that looks obviously wrong costs little. The costly case is the nearly right answer. In the Stack Overflow developer survey published in 2025, 66 percent named "AI solutions that are almost right, but not quite" as their biggest frustration with AI tools, and 45 percent said debugging AI-generated code takes more time. In the same survey, 46 percent reported actively distrusting the accuracy of these tools against 33 percent who trust it.

A survey records perception, not performance, so these numbers must not be converted into a productivity conclusion. One thing does read clearly though: users are themselves reporting that the bottleneck moved from producing to judging.

What Makes Verification Expensive

So the next question is what drives verification cost up. Broadly, four things.

First, tacit context. When the information needed to judge lives neither in the code nor in the docs but only in someone's memory and the team's habits, only the person holding it can judge.

Second, delayed consequences. A design can be green today and collapse in production six months out. The later the result arrives, the more judging it today depends on prediction built from experience.

Third, the absence of an oracle. Ranking quality, whether an interface is good, whether a model output is appropriate — in domains with no answer key, the judgment itself has to be designed.

Fourth, accountability. Somebody has to put their name on the decision, and a signature does not delegate. Signing requires understanding, which makes accountability a device that forces comprehension.

The Twist — The Job Is Making Expensive Verification Cheap

Read only this far and the conclusion turns strange. If expensive verification raises my value, then keeping verification expensive would be in my interest. That is wrong, and the place where it goes wrong is where this frame connects to practice.

The engineering job is the exact opposite: build the machinery that turns expensive judgments into cheap ones. Pin down with types what people used to have to read for, pull forward to deploy-time signals what used to surface in production six months later, and stand up proxy metrics with sampled review where no answer key existed.

So the statement to keep is this: performing the judgment gets automated, designing the judgment stays. It is the same structure as a good test being expensive to write and free to run. Every capability in this series lives on the design side.

Do Not Use Your Own Perception as Evidence

One last thing to flag. In this territory your own sense of speed is not reliable evidence.

The randomized controlled trial METR published in July 2025 shows this well. Sixteen experienced developers working in open-source repositories they knew well completed 246 tasks, with each task randomly assigned to allow or disallow AI tools. The result: tasks where the tools were allowed took 19 percent longer. Participants had expected a 24 percent speedup going in, and after the study still believed they had been sped up by 20 percent.

Do not over-generalize this. The researchers themselves note the sample of 16, that participants were highly familiar with their own codebases, that the repositories held rigorous quality standards, and that outcomes might differ with more tool experience. What the trial establishes is not that the tools are bad but that a gap can exist between feeling faster and being faster, running in opposite directions.

That is why every recommendation in this series carries the same caveat: confirm it with a record. A feeling is a hypothesis, and hypotheses have to be measured.

Try It This Week

If you pick one thing, pick this. Write down ten tasks you did in the last two weeks and drop each into one of the four quadrants above. If a task resists placement, that is the most important signal you will get, because it means you have not yet settled how that work gets judged.

  • Engineering Skill Path — Linux, networking, databases, Kubernetes, and AI/LLM tracks in unit-sized lessons, useful for locating where you actually stand.
  • Problem-Solving Trainer — nine named moves for a problem you have never seen before, the closest available practice for building a judgment standard.

Where this frame does not apply, stated plainly: on an early product with few users and low failure cost, standing up judgment machinery before shipping is the larger loss. Verification design earns its keep once something is at stake.

Further Reading

What Stays Expensive series

Sources