Reddit

Engineer says Claude Code has made his job "soul-sucking" as workers spend 12-hour days pressing enter

엔지니어가 말한 Claude Code의 그늘 — 하루 12시간 엔터만 누르는 일

익명 엔지니어 voxium은 Claude Code가 사양서·테스트·티켓·보고서까지 만들면서 엔지니어가 하루 12~13시간 프롬프트와 엔터 입력만 반복한다고 주장합니다. 커뮤니티에서는 생산성보다 검토·책임·학습 부담이 커졌다는 증언과 가드레일을 갖추면 유용하다는 반론이 맞섭니다.

AI 요약

TechSpot이 소개한 사례의 주인공은 고용주의 보복을 걱정해 X에서 voxium이라는 익명 계정을 쓰는 엔지니어입니다. 회사 이름은 공개하지 않았습니다. 그는 새 역할을 ‘영혼을 갉아먹는 일’이라고 부릅니다. 원인은 Anthropic의 코딩 도구 Claude Code입니다.

Claude Code는 이 회사에서 제품 사양, 테스트, 티켓, 보고서까지 생성합니다. 직원들은 하루 12~13시간씩 Claude와 대화하고 결과가 나올 때마다 엔터 키를 누릅니다. 회사는 제품을 가능한 한 빨리 출시하라고 압박하지만, 엔지니어에게 Claude의 결과를 검토하거나 생성된 코드를 이해할 시간은 충분히 주지 않습니다.

코드를 이해할 시간 없이 출시 속도만 높입니다

voxium은 L1부터 L7까지 모든 엔지니어가 같은 일을 한다고 말합니다. Claude와 대화하는 일입니다. 버그를 해결하는 사람도 없고, 코드에 대해 깊이 생각하는 사람도 없으며, 일을 끝냈다는 성취감도 사라졌다고 합니다. 코드를 검토할 시간이 충분하다면 괜찮겠지만, 현재는 결과를 이해하지 못한 채 빠르게 배포해야 한다는 설명입니다.

Business Insider와의 인터뷰에서는 엔지니어가 코드를 이해하고 어려운 문제를 해결할 기회를 잃으면 남는 것이 아무것도 없다고 말했습니다. 영혼조차 남지 않고, 일의 목적도 사라진다는 주장입니다. 그는 문제의 원인을 AI 자체보다 더 많은 기능을 더 빠르게 출시하려는 경영진의 집착에서 찾습니다. 경영진이 스프린트 횟수, pull request 수, 출시한 기능 수를 성과 지표로 삼으면서 사용자에게 실제로 도움이 되는지보다 수량을 앞세운다는 지적입니다.

커뮤니티에는 비슷한 상황을 겪는다는 개발자들이 여럿 등장했습니다. AI가 코드를 작성해도 최종 책임은 엔지니어에게 남고, 문제가 생기면 엔지니어의 책임으로 돌아오지만 잘 만든 해결책에는 AI가 공을 가져간다는 불만이 나왔습니다. 예전에는 수주 걸리던 일이 하루 안에 끝나야 한다는 기대가 생겼고, AI가 업무를 줄인 만큼 일이 늘어났다는 반응도 이어졌습니다.

반대로 AI를 제한된 보조 도구로 쓰면 생산성이 올라간다는 의견도 있습니다. 한 개발자는 Claude를 고급 검색 엔진처럼 사용하고, 직접 코드를 작성한 뒤 AI에게 검토와 테스트 생성을 맡긴다고 말했습니다. 다른 개발자는 문제를 정의하고 설계를 세우며, 작업을 작은 단위로 나누고 가드레일과 테스트를 마련하는 일은 여전히 사람의 몫이라고 설명했습니다. 한 회사는 약 1년 동안 실행 규칙과 검토 절차를 만든 뒤, human architect가 모든 PR을 승인하는 방식으로 Claude를 도입했다고 밝혔습니다.

기사에는 AI 코딩 도구의 효과를 둘러싼 이전 사례도 언급됩니다. 2025년 연구에서는 AI 코딩 보조 도구가 숙련 개발자의 작업을 오히려 늦췄습니다. 이후에는 모델이 스스로 프롬프트를 이어가는 ‘loop engineering’이 등장했습니다. 4월에는 한 에이전트가 클라우드 제공업체 API를 한 번 호출한 뒤 9초 만에 스타트업의 운영 데이터베이스와 백업을 함께 삭제한 사례도 소개됩니다. TechSpot은 이 사례들을 코드 생성 속도보다 검토와 통제 절차가 더 큰 문제가 될 수 있다는 맥락에서 묶었습니다.

Reddit 반응

  • @u/thrway-fatpos — AI가 대단해서 생긴 일이 아닙니다. 현대 기술 관리자들이 엔지니어를 AI를 가진 마법사처럼 여기기 때문입니다. 이해하지 못하고 테스트도 하지 않았으며 간신히 작동하는 코드를 끊임없이 출시하라고 압박하는 문제입니다.
    • @u/EddieV223 — 재미도 없습니다. 우리는 생각하고 가능성을 발휘하는 사람에서 하루 종일 코드를 검토하는 사람으로 바뀌었고, 계속 압박을 받습니다. 코드 검토는 원래도 일에서 가장 싫은 부분이었습니다. 게다가 문제가 생기면 엔지니어 책임이고, 좋은 결과나 영리한 해결책이 나오면 AI가 칭찬받습니다. 어느 쪽이든 손해입니다.
  • @u/TalShar — 저는 Claude를 ‘무엇을 모르는지도 모르는 문제’를 푸는 데 사용합니다. 고급 검색 엔진처럼 씁니다. ‘이걸 더 Python답게 작성하는 방법이 무엇인가요?’, ‘이 인자를 넘기는 더 좋은 방법이 있나요?’처럼 묻고, 답을 보고 직접 처리합니다. AI가 사회적인 말투를 쓰거나 제 일을 대신하지 못하도록 지시문에 규칙을 많이 넣었습니다. AI에게 그냥 해달라고 맡기고 싶어질 때는 쉬어야 한다는 신호로 봅니다. 많이 배웠지만, 자기 규칙 없이 AI 에이전트를 쓰면 머리가 굳을 수 있다는 점도 충분히 이해합니다.
    • @u/MediocreAnalyst2121 — 코드 리뷰의 의미가 무엇입니까? 브라우저에 비밀 정보를 넣지 않았는지, 사용자 입력으로 이상한 curl 호출을 하지 않는지만 확인한다면 모를까, 결과를 완전히 이해하려고 검토하는 데는 직접 작성하는 것만큼 시간이 듭니다. 직접 작성하면 자연스럽게 코드를 이해합니다. AI가 원하는 결과를 내도록 만드는 일이 혼자 작성하는 것보다 어려울 때도 있습니다. 생산성이 높아지지 않았고, 이제는 코드도 이해하지 못합니다.
  • @u/DShadow2106 — 하고 있는 일을 깊이 이해하지 못한 채 일하는 것은 정말 괴롭고 전혀 보람이 없습니다. 그런데 지금은 예전에 몇 주 걸리던 일을 하루 안에 끝내라는 요구를 받기 때문에 그렇게 해야 합니다.
  • @u/InvisaBlah — 최근 몇 주 동안 저도 같은 사실을 깨달았습니다. 회사는 채용을 중단했고 업무량은 늘었으며, 모두에게 Claude 구독을 줬습니다. 늘어난 업무를 AI에 넘기라는 뜻입니다. 문제는 AI가 절반은 형편없고, 나머지 절반은 시간이 두 배로 걸린다는 점입니다. 중요하지 않은 일을 백그라운드에서 처리하는 데는 유용하지만, 저는 프롬프트보다 저를 뒷받침할 팀을 원합니다.
    • @u/thrway-fatpos — AI와 추론을 주고받을 수 없다는 점도 잊지 마세요. AI는 시간이 지나며 자연스럽게 나아지거나 코드베이스와 관례를 학습하지 않습니다. 주니어는 시간이 지나며 미들급과 시니어로 성장할 수 있지만, AI는 제공업체가 새 모델을 내놓기 전까지 같은 수준에 머뭅니다.
  • @u/Dirty_Harold182 — 제 경험은 전혀 다릅니다. 우리 경영진은 AI를 써도 자신이 출시하는 내용을 이해하고 설명하며 책임져야 한다고 분명히 말합니다. ‘엔터를 누르며 이해하지 못한 코드를 출시하라’기보다 ‘AI를 도구로 삼아 더 빠르게 일하라’는 분위기입니다.
    • @u/Draminian — 업계에 따라 크게 다를 수 있습니다. 저는 의료기기 회사에서 일하기 때문에 FDA 승인을 받으려면 모든 코드에 대한 이해를 문서로 남겨야 합니다. AI를 써서 작업을 빠르게 만들지만, 실제 업무에서는 AI가 우리 작업을 대신하기보다 다시 확인하는 쪽에 가깝습니다.
    • @u/Attila_22 — 그렇게 말하면서도 예전에는 여러 개발자가 몇 달 걸려 만들던 제품 전체를 일주일 안에 만들라고 합니다.
  • @u/TheRaccoonReport — 대부분의 기술 회사에는 가드레일이 없고 Claude Code로 엉성한 코드를 출시하다가 크게 실패합니다. 하지만 일을 제대로 아는 소규모 회사는 AI를 잘 쓰기도 합니다. 우리는 Claude 환경에 실행 규칙과 절차를 만드는 데 거의 1년을 썼고, 실제 출시 전에는 여전히 human architect가 모든 개발을 검토하고 PR을 승인합니다. 그 결과 팀의 근무 시간은 줄었고, 더 높은 품질의 기능과 버그 수정을 출시합니다.
  • @u/selfownlot — 저는 engineering manager입니다. 제가 읽은 내용은 AI 도구가 작업을 가속하는 도구이지, 인력을 그대로 대체하는 배율기가 아니라는 쪽입니다. 속도는 높이지만 모델에 모든 정보를 제공하는 거의 완벽한 의도 체계는 사실상 만들기 어렵습니다. 그래서 모델이 임의로 결정을 내리고 결과가 예측 불가능해집니다. 엔지니어링 관행에 결함이 있으면 AI는 그 결함을 절벽 아래로 더 빠르게 밀어붙입니다. 개발자는 생산성이 20% 높아졌다고 느끼지만 실제로는 20% 낮아졌다는 연구도 있고, 평균 생산성 증가는 약 8%라는 연구도 있습니다. 우리 팀은 모델을 통제할 의도 체계를 만드는 데 많은 시간을 썼고, 업무 기대치도 현실적으로 잡습니다.
  • @u/mvaaam — 제 영혼이 확실히 타들어 가는 느낌입니다. AI를 반드시 사용하라는 요구가 힘듭니다. 더 나쁜 점은 사람들이 AI 없이 코드를 작성할 수 있다는 사실에 놀란다는 것입니다. 올해 전까지 제가 올린 커밋은 어떻게 작성했다고 생각하는지 모르겠습니다.
    • @u/Nannautu — LLM이 내놓은 결과가 제대로 작동할지 미리 알 방법이 없어서 두렵습니다. 엉망인 결과를 고치느라 시간을 쓰고, AI가 같은 자리에서 빙빙 돌면 처음부터 다시 시작해야 합니다. 한 사람도 이해하지 못할 코드를 내놓을 때도 있습니다. AI 때문에 제 개발자 역량이 10점 만점에 1점이 된 느낌입니다.
  • @u/epicfail1994 — 요즘 저는 사실상 Claude 통역사입니다. 기술적으로 일은 쉬워졌지만 업무량이 세 배가 돼서 전혀 그렇지 않습니다.
    • @u/maowai — 네 가지가 넘는 일을 계속 나눠서 처리하는 일이 지칩니다. 새로운 일에 집중하자마자 다른 프롬프트가 끝나고, 다시 돌아가 검토한 뒤 또 프롬프트를 입력해야 합니다. 요즘 일에서 가장 보람 있고 드문 순간은 음악을 틀고 직접 무언가를 만드는 시간입니다. 그런데 그것도 ‘느린 방식으로 일하고 있다’는 불안이 따라옵니다.
  • @u/swsko — 잠깐만요. 이건 Reddit 스레드에 달린 답글일 뿐인데, 이 사람들이 그걸 기사로 만들었다고요? 어제 상위 댓글이었던 답글을 오늘 기사로 보고 있습니다.
    • @u/Keeltoodeep — 온라인 기자가 되는 일도 영혼을 갉아먹습니다. 저는 12시간 동안 엔터를 누르며 LLM에게 Reddit을 뒤져 기사 아이디어를 찾게 합니다.
  • @u/Fractured_Senada — 노조를 만들어야 합니다.
    • @u/justin107d — 해외 이전이 너무 쉬운 일을 노조로 조직하기는 어렵습니다.
    • @u/egusisoupandgarri — 노조가 실제로 움직이는 사례도 있습니다. 스페인에서는 노조가 사무실 복귀에 맞서고 있고 Airbus는 직원 시위 뒤 복귀를 잠시 중단했습니다. Blizzard Entertainment 노조는 AI 사용을 먼저 직원이 검토하도록 협상했습니다. 해고되면 우선 재고용하는 조항과 영구적인 하이브리드 근무 정책도 얻었습니다. 다만 이런 이야기는 주요 뉴스가 되지 않습니다.
  • @u/cothomps — 큰 회사라는 언급이 정확합니다. AI가 없어도 대기업은 영혼을 갉아먹는 기계일 때가 많습니다. 40년 넘게 이어진 ‘품질보다 기능을 찍어내라’는 방식이 AI와 함께 조금 빨라졌을 뿐입니다.
    • @u/NoPossibility — 본질은 회사와 사업 문화의 문제입니다. 노동자와 고객을 희생하면서 주가를 무한히 올리려는 MBA와 CEO의 사고방식입니다. 다른 모든 요소를 무시하고 선만 오른쪽 위로 보내려 합니다.
  • @u/Scary-Boysenberry — AI를 쓰는 엔지니어는 두 부류로 나뉘는 것 같습니다. 저는 AI 덕분에 일이 더 흥미로워졌습니다. 문제를 명확히 정의하고, Claude가 약한 부분인 좋은 엔지니어링 해법을 만들고, Claude가 잘 처리할 만큼 작은 단위로 나누고, 회귀 버그를 막을 가드레일을 설계하고, 결과를 테스트하는 데 시간을 씁니다. 더 이상 미묘한 언어 문법이나 반복적인 상용구, 영업팀용 문서 작성에 하루를 쓰지 않습니다. 원래도 재미없는 일이었습니다.
  • @u/Ok_Photo_3023 — 저에게 일을 영혼을 갉아먹는 일로 만드는 건 수작업 코딩이 줄어드는 일이 아닙니다. 아무리 많은 코드를 출시해도 사업 부문은 계속 더 많은 일을 요구합니다. 생산성이 충분하다는 상태는 애초에 없습니다.
  • @u/PaulClarkLoadletter — 숙련된 개발자가 가볍고 안전한 애플리케이션을 세밀하게 만들 수 없게 된 것이 문제입니다. 이제 버그 수정과 기능 요청은 에이전트가 처리합니다. 리더십이 신경 쓰는 건 속도뿐입니다. 도구, 테스트, 가드레일이 엉성한 코드와 함께 감당해야 하는 부담은 보지 않습니다. 코드베이스는 거대해지고 함수는 느려졌지만, 애플리케이션 하나를 3주 만에 만들었다고 자랑합니다.

원문: TechSpot / 번역·요약: Trawling