▲

AI 피로는 실제로 존재하지만 아무도 이야기하지 않는다

 (siddhantkhare.com)
2P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • AI 도입 이후 생산성은 높아졌지만 피로감은 심화되는 현상이 엔지니어들 사이에서 확산
  • 작업 속도는 빨라졌지만 업무량과 기대치가 함께 증가하며, 인간의 조정·검토 부담이 커짐
  • AI 코드 검토·판단 과정이 반복되며 결정 피로와 인지적 소모가 누적
  • 끊임없는 신기술 추격과 도구 교체의 피로, 그리고 비결정적 AI 출력이 불안과 번아웃을 유발
  • 지속 가능한 AI 활용을 위해 경계 설정·시간 관리·완벽주의 완화가 필수적임

AI 생산성과 피로의 역설

  • AI는 개별 작업 속도를 단축하지만, 작업 총량과 기대치가 함께 증가함
    • 한 작업에 하루를 쓰던 시절보다 여러 문제를 동시에 다루게 되어 맥락 전환 비용이 커짐
  • 생산 비용은 줄었지만 조정·검토·판단 비용은 증가, 이 부담이 전적으로 인간에게 전가됨
  • AI가 빠르게 코드를 생성해도 사람의 인지적 피로는 오히려 커지는 구조

창작자에서 검토자로의 전환

  • AI 도입 후 엔지니어의 역할이 창작자에서 평가자로 이동
    • 프롬프트 입력, 결과 검토, 정확성·안전성 판단 등 반복적 평가 작업이 중심이 됨
  • 생성적 작업은 몰입을 유발하지만, 평가적 작업은 피로를 유발
  • AI 코드의 신뢰성 부족으로 모든 라인을 검토해야 하는 부담이 커짐
  • 이로 인해 보안·권한 관리 시스템의 중요성이 커지며, 인간의 인지 부담을 줄이는 방향이 필요함

비결정성 문제

  • AI는 동일 입력에도 다른 출력을 내는 비결정적 시스템으로, 엔지니어의 사고방식과 충돌
  • 동일 프롬프트가 다른 결과를 내며 디버깅 불가능한 불안정성을 초래
  • 이를 완화하기 위해 결정적 컨텍스트 정제 도구 Distill을 개발, 입력의 일관성을 확보
  • 일부 엔지니어는 AI 출력을 ‘불완전한 초안’ 으로 인식하고, 수정 시간을 예산에 포함해 대응

FOMO(놓칠까 두려움)와 도구 피로

  • 최근 몇 달간 수많은 AI 에이전트·프레임워크·SDK가 빠르게 등장
  • 새로운 도구를 따라잡으려는 시도가 지속적 학습과 교체의 악순환을 초래
  • 지식 휘발과 중복 작업이 발생하며, 초기 채택자보다 기다린 이들이 더 효율적이 되는 경우도 있음
  • 저자는 인프라 계층(권한·컨텍스트·보안) 에 집중해 도구 변화에 흔들리지 않는 접근을 채택

‘한 번만 더 프롬프트’의 함정

  • AI 출력이 완벽하지 않아 프롬프트 수정 반복에 빠지는 현상 발생
  • 반복 시도는 생산적처럼 보이지만 실제 문제 해결보다 프롬프트 조정에 시간 낭비
  • 세 번 시도 후 70% 이상 유용하지 않으면 직접 작성하는 ‘3회 규칙’ 을 적용해 효율 확보

완벽주의와 확률적 출력의 충돌

  • AI 출력은 항상 ‘거의 맞는’ 수준으로, 완벽주의 성향의 엔지니어에게 큰 스트레스
  • 미세한 수정 반복이 정서적 피로와 시간 낭비로 이어짐
  • AI 결과를 ‘초안’으로 인식하고 빠르게 가공하는 태도가 효율적임

사고력의 약화

  • AI에 의존한 결과, 문제 해결 사고력과 설계 능력의 감퇴가 발생
  • 직접 사고하지 않는 습관이 ‘사고 근육’의 위축으로 이어짐
  • 이를 방지하기 위해 매일 일정 시간 AI 없이 사고·설계 연습을 수행

비교의 함정

  • SNS에는 AI로 빠르게 성과를 낸 사례만 공유되어, 개인의 실패나 피로는 드러나지 않음
  • AI 성과는 재현성이 낮아 비교 자체가 무의미함
  • 정보 소비를 줄이고 실제 구축·운영 중심의 신뢰할 수 있는 출처에 집중하는 것이 바람직함

지속 가능한 AI 활용 전략

  • AI 세션 시간 제한으로 과도한 반복 방지
  • 사고 시간과 AI 사용 시간 분리로 인지 균형 유지
  • 70% 완성도 수용, 완벽주의 완화
  • 신기술 채택 시점 지연, 검증된 도구 중심 사용
  • AI 효율 로그 기록으로 실제 유용성과 한계 파악
  • 검토 범위 축소, 핵심 영역에만 집중

지속 가능성과 번아웃

  • AI는 작업 속도 제한을 제거해 과로를 가속
  • 인간의 인지 한계 초과로 번아웃이 발생하며, 이는 개인이 아닌 시스템적 문제로 확산
  • 회복의 핵심은 AI 사용량이 아니라 사용 방식의 재설계
  • 피로 속에서 Distill·agentic-authz·AgentTrace 등 실질적 문제 해결 도구가 탄생

진짜 역량: 멈출 줄 아는 능력

  • AI 시대의 핵심 역량은 언제 멈춰야 하는지 아는 판단력
  • 충분히 좋은 출력에서 멈추고, 직접 작성하거나 휴식할 시점을 구분하는 능력
  • 인간의 뇌를 유한한 자원으로 보호하는 것이 진정한 엔지니어링
  • AI는 강력하지만 인지적으로 가장 소모적인 도구, 현명한 사용이 지속 가능성의 핵심
  • 지속 가능한 산출이 진정한 가치이며, AI 활용의 궁극적 목표임
▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 나에게 피로감은 조금 다름. 일하다가, 코드 리뷰하다가, LLM이 결과를 생성할 때마다 멈춰 기다리는 그 반복이 문제임
    기다림의 길이가 예측 불가능해서, 기다릴지 다른 일을 시작할지 애매함. 그래서 그냥 시간을 죽이기 위해 다른 걸 하게 됨
    결국 몰입 상태(flow) 에 들어가지 못하고, 백그라운드 작업이 끝나길 감시하느라 지쳐버림
    생산성이 높아진 느낌보다는, 아이들이 다치지 않게 지켜보는 게으른 보모가 된 기분임

    • 무책임한 조언일 수도 있지만, 난 Claude Code에 긴 요청을 보낼 때마다 그냥 한숨 돌리고 게임을 함
      짧게 시작하고 멈출 수 있는 오픈소스 게임 Endless Sky를 추천함
      예전엔 프로그래밍이 재미없어졌는데, Claude Code 덕분에 다시 즐거움을 느끼고 있음. 예전 같진 않지만 지금 내 인생 단계에서는 충분히 즐거움
    • 이런 피로는 새로운 게 아님. 다만 에이전트형 AI 코딩 도구가 등장하면서 문맥 전환 피로가 10배는 늘어남
      내가 쓴 리뷰 피로 관련 글에서도 다뤘듯, 이는 개발자뿐 아니라 조직에도 영향을 줌
      AI 워크플로우가 생산성 극대화에 초점을 맞추다 보니 결국 인간을 소모시킴
      해결책은 고전적임 — 자주 쉬고, 인간 개발자가 직접 코드를 조금이라도 써보는 게 좋음. 속도를 늦추면서도 몰입감과 회복을 유지할 수 있음
    • 생산성보다 중요한 건 몰입감(flow) 이었음. 커피 한 잔, 노이즈 캔슬링 헤드폰, 그리고 2시간의 집중 세션이 프로그래밍의 가장 사랑스러운 순간이었음
    • 난 요즘 “Claude Code 운동 루틴”이라고 부름
      LLM이 일하는 동안 스쿼트나 푸쉬업을 하거나 집안을 돌아다니며 스트레칭함. 하루 종일 키보드 앞에 앉아 있는 것보다 훨씬 즐거움
      몸을 움직이면 생각도 잘 정리되지만, 그래도 정신적 피로감은 여전함
    • 예전엔 몇 시간씩 몰입해 일했는데, 이제는 계속 방해받음
      프롬프트를 보내고 기다리는 동안 웹서핑을 하게 됨. SelfControl 앱으로 차단하지 않으면 도저히 못 참겠음
      LLM 덕분에 생산성은 높아졌지만, 하루가 끝나면 훨씬 더 피곤하고 죄책감도 듦

  • 글의 아이디어는 좋지만, 읽다 보면 AI가 쓴 듯한 피로감이 옴
    한두 문장으로 끝낼 내용을 장황하게 늘리고, 불필요한 예시도 많음
    “HN 메인 페이지가 혼란스럽다”는 주장도 틀림. 언급된 글들은 5업보트도 못 받았고, HN 메인 품질은 여전히 괜찮음
    그리고 “아무도 이야기하지 않는다”는 주장도 틀림. 이미 AI fatigue에 대한 논의는 오래전부터 있었음

    • “HN 메인페이지는 여전히 멀쩡하다”는 말엔 동의하지만, 진짜 이상한 건 이런 문장들임
      “고마워요 OpenClaw, 고마워요 AGI—나에겐 이미 여기에 있음”
      “오늘 인간 엔지니어당 최소 $1,000의 토큰을 쓰지 않았다면 당신의 소프트웨어 공장은 개선 여지가 있음”
      “코드는 인간이 리뷰해서는 안 됨”
      “C가 어셈블러에 했던 일을, Java가 C에 했던 일을, 이제 LLM이 모든 언어에 하고 있음”
      이런 문장들이 실제 메인에 올라온 글에서 인용된 것임
    • “You’re not imagining it.” 이라는 문장을 보고 바로 반응했음. 정말 그렇게 느껴짐
    • 아마 글쓴이는 “피곤하다, 최근 세션을 보고 왜 그런지 블로그로 써줘”라고 LLM에 시킨 듯함
      아니면 AI 글을 너무 많이 읽어서 글쓰기 스타일 자체가 AI처럼 변한 것일 수도 있음
    • 어쩌면 단순히 글쓰기를 좋아하는 사람일 수도 있음
      나도 최근 블로깅을 시작했는데, 의외로 스토리텔링 중심 글쓰기가 즐거움
      사람마다 스타일이 다를 뿐, 문제는 아님
    • “AI가 쓴 듯한 피로감”에 동의함
      글은 몇 문단으로 요약될 수 있었는데, 불필요한 수식어가 너무 많음
      앞으로는 콘텐츠에도 “인간 생산자 라벨”이 붙을지도 모르겠음 — 예를 들어 “프리랜서 생산”, “교외 거주자 생산” 같은 식으로

  • “더 빨리 배포하니 기대치가 올라간다”는 말에 공감함
    이건 오래된 문제임. 헬렌 켈러가 거의 100년 전에 이미 비슷한 말을 했음
    “노동 절약 기계를 진짜로 노동을 절약하는 데 쓰자”는 내용이 The Atlantic 글에 있음

  • 하루에 여러 프로젝트를 진전시킬 수 있지만, 완전히 지쳐버림
    “한 번만 더 프롬프트를 보내보자”는 유혹 때문에 잠을 못 자는 사람도 많음
    오랜 시간 쌓인 지속 가능한 작업 리듬이 무너졌고, 새로운 균형을 찾는 데 시간이 걸릴 것 같음

    • 예전엔 아이디어를 시작하면 금방 가치가 없거나 잘 안 될 걸 알아차렸음
      그런데 지금은 처음엔 너무 잘 돼서 계속 진행하다가, 갑자기 막히는 순간이 찾아옴
    • 나도 프리랜서인데, AI 덕분에 인보이스 시스템을 하루 만에 만들었음
      그런데 거기서 멈추지 못하고 회계, 세금, CRM, 창고, 프로젝트 관리까지 확장함
      결국 필요 없는 SaaS를 만들어버렸고, 이제는 오픈소스로 공개할까 고민 중임
    • “한 번만 더 완벽하게 만들자”는 생각이 시간을 다 잡아먹음
      그래도 이제는 모바일 브라우저로 에이전트 세션을 이어서 볼 수 있어서, 침대에서도 확인함 (농담 반 진담 반)
    • AI가 코딩의 마찰을 크게 줄였음
      이제 진짜 병목은 코딩이 아니라 요구사항 수집과 의사결정임
    • 그렇게 생산성이 10배 늘었다면, 쉬는 시간도 두 배로 늘려야 하지 않겠음?
      왜 굳이 계속 일하는지 이해가 안 됨

  • 글쓴이임. 반(反)AI 글이 아니라, 인지적 비용에 대한 이야기임
    작업이 빨라질수록 일이 늘어나고, AI 결과를 검토하느라 의사결정 피로가 쌓임
    도구 생태계도 매주 바뀌고 있음. 실제로 도움이 된 방법을 공유했고, 다른 사람들도 비슷한 벽에 부딪히는지 궁금함

    • 왜 블로그와 게시글의 문장을 LLM으로 수정했는지 궁금함
      인간이 아닌 존재와 대화하는 느낌이 피로감을 더 키움
    • 글 속 이미지가 AI 생성 오류 논란 이미지를 떠올리게 함
    • 좋은 글이었음. 나도 AI 덕분에 더 많은 걸 해야 한다는 압박감을 느꼈음
      하지만 현실적인 기대치를 세우고, 모든 “AI 매직 포스트”에 휘둘리지 않으려 하니 불안감이 줄었음
    • 아이러니하게도, AI 피로에 대한 글이 AI로 생성된 것 같다는 점이 웃김

  • 기술은 결코 노동자를 편하게 하려는 게 아님
    언제나 생산성과 경쟁력을 높이려는 목적임
    말에서 자동차로, 전화에서 스마트폰으로 바뀌었지만, 자유 시간은 늘지 않았음. 단지 더 이동 가능하고 연결된 인간이 되었을 뿐임

    • 하지만 효율성의 사용 방식은 선택의 문제임
      옛날식 삶의 질을 받아들인다면, 덜 일하고도 충분히 살 수 있음

  • 요즘 느끼는 건 집행 기능 피로(executive functioning fatigue) 임
    AI와 함께 일하면 단순한 구현보다 고차원적 의사결정을 계속하게 됨
    쉬는 시간이 거의 없고, 전두엽이 과열된 느낌임
    만약 이런 상태가 지속된다면, 오히려 인간의 집행 기능이 강화될지도 모름

  • 열 명의 천재지만 불안정한 엔지니어 팀을 관리하는 게 이렇게 소모적일 줄 몰랐음

    • 그건 ‘매니징’이 아니라 마이크로매니징이라고 해야 함

  • 내 생각엔 AI 피로의 원인은 프로그래밍의 세 가지 단계 균형이 깨졌기 때문임
    문제 해결 → 코드 작성 → 결과 확인의 세 단계가 원래는 균형을 이루었음
    코딩은 반복적이지만 명상적이고 안정적인 과정이었음. 문제 해결은 강도 높고, 결과 확인은 도파민 보상임
    그런데 LLM이 코딩을 대신하면서, 우리는 스트레스가 큰 문제 해결과 리뷰 단계만 남게 됨
    그 사이의 완충 구간이 사라져서 훨씬 더 피로함
    예전 코딩을 그리워하는 이유는 바로 그 명상적 흐름의 상실 때문임
    나도 AI와 페어 프로그래밍을 하며 직접 코드를 치는 방식을 선호함. 이게 장기적으로 더 지속 가능하다고 느낌
    하지만 여러 에이전트를 동시에 다루는 생산성의 유혹도 정말 강력함

  • “결정론적이지 않은 시스템과 싸우는 부분”이 인상 깊었음
    LLM은 본질적으로 인간의 지속적인 개입을 필요로 함. 기업이 그 결과물에 완전한 책임을 질 각오가 없다면 말임

    • 하지만 ‘멍청한 기계’에 책임을 묻는 건 불가능함
      전압을 줄여서 벌을 줄 수도 없고, 주사위에 책임을 묻지 않는 것처럼 말이 안 됨
    • 게다가 인간 개발자도 완전히 결정론적이지 않음. 그런 인간을 본 적이 없음
답변달기