- Authors
- Name
- Youngju Kim
- @fjvbn20031
들어가며 — 화제가 된 글
2026년 7월 8일, Alec Scollon이라는 개발자가 "I Think I Have LLM Burnout"이라는 짧은 에세이를 올렸습니다. 이 글은 해커뉴스에서 빠르게 올라갔는데, 보통 그런 일은 많은 사람이 이미 느끼고 있었지만 말로 옮기지 못한 무언가를 정확히 짚었다는 뜻입니다.
요지는 "AI 도구가 나쁘다"가 아닙니다. 하루의 모양이 조용히 바뀌었고, 그 변화가 겪어보지 않은 사람에게는 설명하기 어려운 방식으로 사람을 지치게 한다는 것입니다. "나는 이 도구를 하루 종일 쓴다"와 "그런데 그게 나를 소진시킨다" 사이의 간극, 바로 그것을 이 글이 포착합니다.
저는 그의 주장을 정확히 옮긴 다음, 제 나름의 균형 잡힌 시각을 더하려 합니다. LLM의 도움이 진짜로 제값을 하는 지점은 어디이고, 끝없는 리뷰와 문맥 전환이 사람을 갉아먹는 지점은 어디인가. AI 종말론도 AI 예찬론도 아니고, 이 피로가 개인의 나약함이라고 둘러대지도 않으면서요.
에세이가 실제로 말하는 것
Scollon은 반(反)AI 진영이 아닙니다. 그는 하루에 몇 시간씩 LLM 출력을 읽습니다. 어시스턴트가 짠 코드를 리뷰하고, 감독 없이 돌려둔 에이전트의 결과물을 훑습니다. 그리고 이 도구들이 스스로는 떠올리지 못했을 접근법을 보여준다는 점을 분명히 인정합니다.
그는 잘 되는 부분도 꼼꼼히 인정합니다. 모델은 그에게 뭔가를 가르쳐 주고, 생각지 못한 설계를 꺼내 보여 주며, 일의 반복적인 부분을 더 빠르게 처리해 줍니다. 이건 불평을 가짜 균형으로 포장한 게 아닙니다. 가치가 진짜이기 때문에, 오히려 이 피로가 뻔하지 않고 혼란스러운 것입니다.
그의 작업은 하나의 루프로 접혔습니다. 코드를 설계하고, 그 설계를 모델에게 설명하고, 모델이 내놓은 것을 리뷰하고, 그런 다음에야 직접 코드를 씁니다. 프로그래밍이라는 행위는 여전히 있지만, 이제 프롬프트와 읽기의 파이프라인 맨 끝에 놓여 있습니다.
그가 말하는 피로는 사실 오류 때문이 아닙니다. 반복 때문입니다. 그의 표현을 빌리면 "LLM은 늘 같은 스타일로 쓰고, 늘 같은 종류의 실수를 한다"는 것입니다. 잘못된 전제, 환각, 뚝뚝 끊어지는 단정적 문장, 과한 이모지. 하나하나는 심각하지 않지만, 같은 버릇 몇 가지를 계속 마주하는 일이 그를 갈아냅니다.
이 에세이가 와닿는 이유는 해법이 없다는 것을 솔직히 인정하기 때문입니다. 그는 개인화 설정을 언급하면서도 그것이 한계가 뚜렷하다고 털어놓습니다. 그리고 매듭짓지 않은 채 끝냅니다. "이 감정을 어떻게 다뤄야 할지 아직 모르겠다." 깔끔하게 리본을 묶기를 거부한 그 태도가, 아마 이 글이 그토록 널리 공감을 산 이유일 것입니다.
진짜 비용: 리뷰는 노동이다
이 모든 것 아래에 깔린 불편한 통찰은 단순합니다. 생성은 싸졌고, 검증은 그렇지 않았습니다. 모델은 그럴듯한 코드나 글 한 페이지를 몇 초 만에 뽑아내지만, 그게 맞는지 확인하는 일은 여전히 사람의 속도로, 종종 직접 쓰는 것보다 더 느리게 굴러갑니다.
그 비대칭이 문제의 전부입니다. 하루가 무언가 몇 초 만에 생성한 출력으로 가득 차면, 리뷰는 예전 일의 가벼운 버전처럼 느껴지지 않습니다. 오히려 더 무겁게 느껴지고, 거기엔 구체적인 이유가 있습니다.
- 낯선 코드를 비판적으로 읽는 일은, 이미 의도를 머릿속에 쥐고 있는 자기 코드를 쓰는 것보다 더 많은 품이 듭니다.
- 그럴듯해 보이는 출력은 경계를 늦추게 해서, 미묘하게 틀린 전제를 잡아내는 데 오히려 더 많은 주의가 필요합니다.
- 실패가 반복되기 때문에, 새롭고 흥미로운 문제를 만나는 대신 같은 종류의 실수를 하루 종일 다시 점검하게 됩니다.
"모든 것을 검증하라"를 늘 되뇌는 블로그에서 이 대목은 짚고 넘어갈 가치가 있습니다. 검증은 진짜 일을 끝낸 뒤에 덧붙이는 형식 절차가 아닙니다. 이제는 AI 출력을 리뷰하는 것이 곧 일이며, 그것은 생산성 대시보드에 좀처럼 잡히지 않는 실제 인지 비용을 짊어집니다. 해커뉴스 스레드도 같은 관찰로 가득했습니다. 팩트체크해야 할 생성 문서 더미를 이야기하는 사람들, 그리고 "만들기는 더 빨라졌는데" 어느새 "믿기는 더 느려졌다"는 감각 말입니다.
이것을 흔한 과로와 구분하는 편이 좋습니다. 고전적인 번아웃은 대개 양에서 옵니다. 너무 긴 시간, 너무 많은 티켓. 이건 다릅니다. 근무 시간이 더 적어도 속이 텅 빈 느낌이 들 수 있는데, 일의 구성 자체가 만드는 일에서 감사(監査)하는 일로 발밑에서 바뀌었기 때문입니다. 지금 자신이 어떤 종류의 피로인지 이름 붙이는 것이 올바른 문제를 고치는 첫걸음입니다.
그래도 도구가 값을 하는 곳
그렇다고 이 도구들이 순손실이라는 뜻은 아니며, 이 글의 정직한 버전이라면 그 점을 분명히 말해야 합니다. LLM은 보일러플레이트, UI 뼈대 잡기, 그리고 예전엔 조사 비용이 너무 커서 엄두가 안 나던 낯선 언어나 도메인에 발을 들이는 일에 진짜로 능합니다. 거기서 쓰면 도구는 잡일을 더하는 게 아니라 덜어 주고, 위험이 낮으니 리뷰 비용도 낮게 유지됩니다.
피로는 몇 가지 특정한 지점에서 오며, 그것들을 나눠 보는 편이 도움이 됩니다.
- 저자 모드와 리뷰어 모드 사이의 끊임없는 전환. 둘은 실제로 서로 다른 인지 기어입니다.
- Scollon이 가리키는 그 똑같음. 늘 같은 방식으로 실패하는 출력을 리뷰하는 일 말입니다.
- 몇 주마다 새 모델이나 워크플로가 도착하고, 그것을 다시 익히는 일 자체가 세금이 되는 과열된 트레드밀과 도구 갈아타기.
- 모든 것을 모델에 통과시키라는 압박. 때로는 회사가 말 그대로 토큰 수를 세고 있기 때문입니다.
그 토론에서 가장 뚜렷한 성공 사례도 똑같았습니다. 뼈대 잡기, 낯선 언어, 그리고 예전엔 조사 비용이 시작하기도 전에 추진력을 꺾어 버리던 사이드 프로젝트. 도구가 쓸모없다고 주장하는 사람은 거의 없었습니다. 논쟁은 비율에 관한 것이었고, 예외가 조용히 기본값이 될 때 무슨 일이 벌어지는가에 관한 것이었습니다.
그러니 도구는 그에 어울리는 일에 의도적으로 골라 쓸 때 제값을 합니다. 반대로 기본값이 슬그머니 "일단 항상 생성부터"로 바뀔 때 사람을 지치게 합니다.
이 재구성이 중요한 이유는, 우리가 할 수 있는 일이 달라지기 때문입니다. 만약 피로가 정말 모델 품질 문제라면, 더 나은 모델을 기다리기만 하면 됩니다. 하지만 그것이 생산과 리뷰의 비율 문제라면, 그건 스스로 돌릴 수 있는 다이얼입니다.
마치며
Scollon의 에세이가 읽을 가치가 있는 건 바로 과장하지 않기 때문입니다. 그가 묘사하는 번아웃은 중독도 아니고 모델의 잘못도 아닙니다. 그것은 일이 무엇으로 이루어져 있는가가 구조적으로 바뀐 것이고, 그 이름을 부르는 일이 정직한 첫걸음입니다.
실천적인 수는 화려하지 않습니다. 모델 출력을 읽는 시간과 스스로 무언가를 생산하는 시간의 비율을 지켜보세요. 리뷰를 공짜 뒷일이 아니라 실제 예산이 붙는 일급 업무로 대하세요. 습관이나 지시가 도구를 밀어 넣는 곳이 아니라, 도구가 진짜로 짐을 덜어 주는 곳에 아껴 쓰세요.
이것은 도구를 거부하는 것도, 도구에 항복하는 것도 아닙니다. 그저 비용을 정직하게 인정하는 것이고, 오랫동안 도구를 잘 쓰기 위해 설 수 있는 유일한 발판입니다.
참고 자료
- Alec Scollon, "I Think I Have LLM Burnout" (2026년 7월 8일) — https://www.alecscollon.com/blog/llm-burnout/
- 해커뉴스 토론 — https://news.ycombinator.com/item?id=48839984