Skip to content
←

Split View: LLM 번아웃 — 일이 "만드는 것"에서 "검토하는 것"으로 바뀔 때

|

LLM 번아웃 — 일이 "만드는 것"에서 "검토하는 것"으로 바뀔 때

들어가며 — 화제가 된 글

2026년 7월 8일, Alec Scollon이라는 개발자가 "I Think I Have LLM Burnout"이라는 짧은 에세이를 올렸습니다. 이 글은 해커뉴스에서 빠르게 올라갔는데, 보통 그런 일은 많은 사람이 이미 느끼고 있었지만 말로 옮기지 못한 무언가를 정확히 짚었다는 뜻입니다.

요지는 "AI 도구가 나쁘다"가 아닙니다. 하루의 모양이 조용히 바뀌었고, 그 변화가 겪어보지 않은 사람에게는 설명하기 어려운 방식으로 사람을 지치게 한다는 것입니다. "나는 이 도구를 하루 종일 쓴다"와 "그런데 그게 나를 소진시킨다" 사이의 간극, 바로 그것을 이 글이 포착합니다.

저는 그의 주장을 정확히 옮긴 다음, 제 나름의 균형 잡힌 시각을 더하려 합니다. LLM의 도움이 진짜로 제값을 하는 지점은 어디이고, 끝없는 리뷰와 문맥 전환이 사람을 갉아먹는 지점은 어디인가. AI 종말론도 AI 예찬론도 아니고, 이 피로가 개인의 나약함이라고 둘러대지도 않으면서요.

에세이가 실제로 말하는 것

Scollon은 반(反)AI 진영이 아닙니다. 그는 하루에 몇 시간씩 LLM 출력을 읽습니다. 어시스턴트가 짠 코드를 리뷰하고, 감독 없이 돌려둔 에이전트의 결과물을 훑습니다. 그리고 이 도구들이 스스로는 떠올리지 못했을 접근법을 보여준다는 점을 분명히 인정합니다.

그는 잘 되는 부분도 꼼꼼히 인정합니다. 모델은 그에게 뭔가를 가르쳐 주고, 생각지 못한 설계를 꺼내 보여 주며, 일의 반복적인 부분을 더 빠르게 처리해 줍니다. 이건 불평을 가짜 균형으로 포장한 게 아닙니다. 가치가 진짜이기 때문에, 오히려 이 피로가 뻔하지 않고 혼란스러운 것입니다.

그의 작업은 하나의 루프로 접혔습니다. 코드를 설계하고, 그 설계를 모델에게 설명하고, 모델이 내놓은 것을 리뷰하고, 그런 다음에야 직접 코드를 씁니다. 프로그래밍이라는 행위는 여전히 있지만, 이제 프롬프트와 읽기의 파이프라인 맨 끝에 놓여 있습니다.

그가 말하는 피로는 사실 오류 때문이 아닙니다. 반복 때문입니다. 그의 표현을 빌리면 "LLM은 늘 같은 스타일로 쓰고, 늘 같은 종류의 실수를 한다"는 것입니다. 잘못된 전제, 환각, 뚝뚝 끊어지는 단정적 문장, 과한 이모지. 하나하나는 심각하지 않지만, 같은 버릇 몇 가지를 계속 마주하는 일이 그를 갈아냅니다.

이 에세이가 와닿는 이유는 해법이 없다는 것을 솔직히 인정하기 때문입니다. 그는 개인화 설정을 언급하면서도 그것이 한계가 뚜렷하다고 털어놓습니다. 그리고 매듭짓지 않은 채 끝냅니다. "이 감정을 어떻게 다뤄야 할지 아직 모르겠다." 깔끔하게 리본을 묶기를 거부한 그 태도가, 아마 이 글이 그토록 널리 공감을 산 이유일 것입니다.

진짜 비용: 리뷰는 노동이다

이 모든 것 아래에 깔린 불편한 통찰은 단순합니다. 생성은 싸졌고, 검증은 그렇지 않았습니다. 모델은 그럴듯한 코드나 글 한 페이지를 몇 초 만에 뽑아내지만, 그게 맞는지 확인하는 일은 여전히 사람의 속도로, 종종 직접 쓰는 것보다 더 느리게 굴러갑니다.

그 비대칭이 문제의 전부입니다. 하루가 무언가 몇 초 만에 생성한 출력으로 가득 차면, 리뷰는 예전 일의 가벼운 버전처럼 느껴지지 않습니다. 오히려 더 무겁게 느껴지고, 거기엔 구체적인 이유가 있습니다.

  • 낯선 코드를 비판적으로 읽는 일은, 이미 의도를 머릿속에 쥐고 있는 자기 코드를 쓰는 것보다 더 많은 품이 듭니다.
  • 그럴듯해 보이는 출력은 경계를 늦추게 해서, 미묘하게 틀린 전제를 잡아내는 데 오히려 더 많은 주의가 필요합니다.
  • 실패가 반복되기 때문에, 새롭고 흥미로운 문제를 만나는 대신 같은 종류의 실수를 하루 종일 다시 점검하게 됩니다.

"모든 것을 검증하라"를 늘 되뇌는 블로그에서 이 대목은 짚고 넘어갈 가치가 있습니다. 검증은 진짜 일을 끝낸 뒤에 덧붙이는 형식 절차가 아닙니다. 이제는 AI 출력을 리뷰하는 것이 곧 일이며, 그것은 생산성 대시보드에 좀처럼 잡히지 않는 실제 인지 비용을 짊어집니다. 해커뉴스 스레드도 같은 관찰로 가득했습니다. 팩트체크해야 할 생성 문서 더미를 이야기하는 사람들, 그리고 "만들기는 더 빨라졌는데" 어느새 "믿기는 더 느려졌다"는 감각 말입니다.

이것을 흔한 과로와 구분하는 편이 좋습니다. 고전적인 번아웃은 대개 양에서 옵니다. 너무 긴 시간, 너무 많은 티켓. 이건 다릅니다. 근무 시간이 더 적어도 속이 텅 빈 느낌이 들 수 있는데, 일의 구성 자체가 만드는 일에서 감사(監査)하는 일로 발밑에서 바뀌었기 때문입니다. 지금 자신이 어떤 종류의 피로인지 이름 붙이는 것이 올바른 문제를 고치는 첫걸음입니다.

그래도 도구가 값을 하는 곳

그렇다고 이 도구들이 순손실이라는 뜻은 아니며, 이 글의 정직한 버전이라면 그 점을 분명히 말해야 합니다. LLM은 보일러플레이트, UI 뼈대 잡기, 그리고 예전엔 조사 비용이 너무 커서 엄두가 안 나던 낯선 언어나 도메인에 발을 들이는 일에 진짜로 능합니다. 거기서 쓰면 도구는 잡일을 더하는 게 아니라 덜어 주고, 위험이 낮으니 리뷰 비용도 낮게 유지됩니다.

피로는 몇 가지 특정한 지점에서 오며, 그것들을 나눠 보는 편이 도움이 됩니다.

  • 저자 모드와 리뷰어 모드 사이의 끊임없는 전환. 둘은 실제로 서로 다른 인지 기어입니다.
  • Scollon이 가리키는 그 똑같음. 늘 같은 방식으로 실패하는 출력을 리뷰하는 일 말입니다.
  • 몇 주마다 새 모델이나 워크플로가 도착하고, 그것을 다시 익히는 일 자체가 세금이 되는 과열된 트레드밀과 도구 갈아타기.
  • 모든 것을 모델에 통과시키라는 압박. 때로는 회사가 말 그대로 토큰 수를 세고 있기 때문입니다.

그 토론에서 가장 뚜렷한 성공 사례도 똑같았습니다. 뼈대 잡기, 낯선 언어, 그리고 예전엔 조사 비용이 시작하기도 전에 추진력을 꺾어 버리던 사이드 프로젝트. 도구가 쓸모없다고 주장하는 사람은 거의 없었습니다. 논쟁은 비율에 관한 것이었고, 예외가 조용히 기본값이 될 때 무슨 일이 벌어지는가에 관한 것이었습니다.

그러니 도구는 그에 어울리는 일에 의도적으로 골라 쓸 때 제값을 합니다. 반대로 기본값이 슬그머니 "일단 항상 생성부터"로 바뀔 때 사람을 지치게 합니다.

이 재구성이 중요한 이유는, 우리가 할 수 있는 일이 달라지기 때문입니다. 만약 피로가 정말 모델 품질 문제라면, 더 나은 모델을 기다리기만 하면 됩니다. 하지만 그것이 생산과 리뷰의 비율 문제라면, 그건 스스로 돌릴 수 있는 다이얼입니다.

마치며

Scollon의 에세이가 읽을 가치가 있는 건 바로 과장하지 않기 때문입니다. 그가 묘사하는 번아웃은 중독도 아니고 모델의 잘못도 아닙니다. 그것은 일이 무엇으로 이루어져 있는가가 구조적으로 바뀐 것이고, 그 이름을 부르는 일이 정직한 첫걸음입니다.

실천적인 수는 화려하지 않습니다. 모델 출력을 읽는 시간과 스스로 무언가를 생산하는 시간의 비율을 지켜보세요. 리뷰를 공짜 뒷일이 아니라 실제 예산이 붙는 일급 업무로 대하세요. 습관이나 지시가 도구를 밀어 넣는 곳이 아니라, 도구가 진짜로 짐을 덜어 주는 곳에 아껴 쓰세요.

이것은 도구를 거부하는 것도, 도구에 항복하는 것도 아닙니다. 그저 비용을 정직하게 인정하는 것이고, 오랫동안 도구를 잘 쓰기 위해 설 수 있는 유일한 발판입니다.

참고 자료

LLM Burnout: When the Job Becomes Reviewing the Work Instead of Doing It

Introduction — the post that trended

On July 8, 2026, a developer named Alec Scollon published a short essay titled "I Think I Have LLM Burnout." It climbed Hacker News quickly, which usually means it named something a lot of people were already feeling but had not put into words.

The claim is not that AI tools are bad. It is that something about the shape of the workday has quietly changed, and the change is tiring in a way that is hard to explain to anyone who has not lived it. That gap between "I use these tools all day" and "and it is wearing me out" is exactly what the piece captures.

I want to represent his argument accurately, then add a grounded take of my own: where LLM assistance genuinely earns its place, and where the constant reviewing and context-switching wear people down. No doomerism, no boosterism, and no pretending the fatigue is a personal failing.

What the essay actually says

Scollon is not anti-AI. He spends hours a day reading LLM output, both reviewing code from an assistant and sifting through the results of an agent he lets run unsupervised, and he is clear that the tools expose him to approaches he would not have reached on his own.

He is careful to credit what works. The models teach him things, surface designs he would not have considered, and move the routine parts of the job faster. This is not a complaint dressed up as fake balance; the value is real, which is exactly what makes the fatigue confusing rather than obvious.

His workflow has folded into a loop: he designs the code, describes the design to a model, reviews what the model produces, and only then writes code himself. The act of programming is still there, but it now sits at the end of a pipeline of prompting and reading.

The fatigue, he argues, is not really about the errors. It is about repetition. In his words, "LLMs write in the same style, and they make the same kinds of mistakes." The false assumptions, the hallucinations, the clipped staccato phrasing, the excessive emojis: none of them is severe on its own, but meeting the same handful of tics over and over grinds him down.

What makes the essay land is its honesty about not having a fix. He mentions personalization settings and admits they only go so far. He ends without resolving it: "I don't know how to deal with this feeling yet." That refusal to tie a neat bow on it is probably why it resonated so widely.

The real cost: reviewing is work

The uncomfortable insight underneath all of this is simple. Generation got cheap; verification did not. A model can produce a page of plausible code or prose in seconds, but checking whether it is correct still runs at human speed, and often slower than writing it yourself would have.

That asymmetry is the whole problem. When your day fills up with output that something generated in seconds, the reviewing does not feel like a lighter version of the old job. It feels heavier, and there are concrete reasons why:

  • Reading unfamiliar code critically is more effortful than writing your own, where you already hold the intent in your head.
  • Plausible-looking output lowers your guard, so catching a subtle wrong assumption takes more attention, not less.
  • The failures repeat, so you are re-checking the same categories of mistake all day instead of meeting fresh, interesting problems.

This is the part worth naming on a blog that keeps repeating "verify everything." Verification is not a formality you tack on after the real work; reviewing AI output is the work now, and it carries a real cognitive cost that rarely shows up in a productivity dashboard. The Hacker News thread was full of the same observation: people describing stacks of generated documents they had to fact-check, and the growing sense that "faster to produce" had quietly become "slower to trust."

It is worth separating this from ordinary overwork. Classic burnout usually comes from volume: too many hours, too many tickets. This is different. You can be working fewer hours and still feel hollowed out, because the composition of the work changed underneath you from making things to auditing them. Naming which kind of tired you are is the first step to fixing the right thing.

Where the tools still earn their keep

None of this means the tools are a net negative, and the honest version of this post has to say so plainly. LLMs are genuinely good at boilerplate, at scaffolding a UI, at getting you oriented in an unfamiliar language or domain where the research overhead used to be prohibitive. Used there, they remove drudgery instead of adding it, and the review cost stays low because the stakes are low.

The wear comes from a few specific places, and it helps to separate them:

  • The constant mode-switching between author and reviewer, which are genuinely different cognitive gears.
  • The sameness Scollon points at: reviewing output that always fails in the same ways.
  • The hype treadmill and tool churn, where a new model or workflow arrives every few weeks and re-learning it becomes its own tax.
  • The pressure to route everything through a model, sometimes because a company is literally counting tokens.

The clearest wins in the discussion were the same ones: scaffolding, unfamiliar languages, and side projects where the research cost used to be the thing that killed momentum before it started. Almost nobody argued the tools were useless. The argument was about proportion, and about what happens when the exception quietly becomes the default.

So the tools earn their keep when you choose them deliberately for tasks that suit them. They wear you down when the default silently becomes "generate first, always."

That reframing matters because it changes what you can do about it. If the fatigue were really about model quality, you would just wait for a better model. But if it is about the ratio of producing to reviewing, that is a dial you can actually turn yourself.

Closing

Scollon's essay is worth reading precisely because it does not overclaim. The burnout he describes is not an addiction and not the model's fault; it is a structural shift in what the job is made of, and naming it is the first honest step.

The practical move is unglamorous. Watch the ratio of time spent reading model output versus producing your own. Treat review as first-class work with a real budget, not a free afterthought. Reserve the tools for where they genuinely lighten the load rather than where habit or mandate puts them.

That is neither rejecting the tools nor surrendering to them. It is just being honest about the cost, which is the only footing from which you can use them well for a long time.

References