▲

아마존에서 일부 개발자들이 자신의 일이 창고 노동과 비슷해졌다고 말함

 (nytimes.com)
6P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 아마존 개발자들은 AI 도입 이후 작업 속도 압박과 업무 단순화를 겪고 있음
  • 관리자들은 생산성 향상을 이유로 AI 도구 사용을 강하게 권장하고 있음
  • 일부는 반복 작업이 줄어 일의 질이 개선됐다고 보지만, 신입 개발자들은 성장 기회를 잃는다는 우려도 있음
  • 코딩이 직접 창조에서 검토와 확인 중심의 작업으로 바뀌면서, 자기 일이 아니라는 느낌을 받는 경우도 있음
  • Amazon Employees for Climate Justice 등 사내 그룹이 이 문제를 포함해 직무 스트레스와 미래 전망에 대한 불안을 공유중

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

코딩도 ‘속도전’의 시대

  • 산업혁명 이후 반복적으로 나타난 기계화에 따른 직무 단순화 현상이 코딩 분야에서도 발생 중임
  • AI는 일자리를 없애기보다 기존 직무를 단순하고 빠르게 수행하는 형태로 전환시키고 있음
  • Microsoft 연구에 따르면, AI 도우미 ‘Copilot’을 활용한 개발자의 생산성이 25% 이상 향상됨
  • 아마존은 이를 수용하여 AI로 더 빠르고 효율적인 작업을 요구하고 있으며, 이를 주주 서한에서 ‘비용 절감과 경쟁력 유지’의 핵심으로 강조함
  • 일례로, 한 개발팀은 작년의 절반 규모로 운영되면서도 동일한 코드 양을 요구받고 있음

기업 전반의 흐름

  • Shopify는 모든 직원에게 AI 사용을 기본 요구사항으로 삼고, 성과 평가에도 반영한다고 명시함
  • Google은 사내 해커톤에서 일상 생산성을 높이는 AI 도구 개발을 주제로 삼고 있음. 이미 코드의 30% 이상이 AI 제안을 통해 생성되고 있음

긍정적인 면과 우려

  • 일부 매니저들은 AI 도입으로 지루하고 반복적인 작업이 줄어 더 창의적인 업무에 집중할 수 있다고 주장
  • Amazon은 AI 덕분에 4,500년 분량의 개발 업무를 절약했다고 언급
  • 그러나 Harvard 경제학자 Lawrence Katz는 초보 개발자에게는 직무 성장 기회가 사라지는 효과를 지적함
  • 과거 공장 노동자들이 겪은 ‘속도전’과 유사하게, 개발자들도 더 빠르게, 더 많은 양을 처리하도록 압박받고 있음

개발자들이 느끼는 변화

  • 아마존 물류창고와 마찬가지로, 개발자들도 AI로 인한 작업 자동화와 분업화를 체감함
  • AI 사용은 ‘선택’이지만, 성과 목표를 맞추려면 사실상 필수로 작용함
  • 과거 몇 주 걸리던 기능 개발이 이제는 수일 내에 마무리되어야 하며, 이를 위해 회의 시간 감소와 AI 코드 사용 확대가 이루어짐
  • AI는 전체 프로그램 생성까지 가능하지만, 코드를 읽고 검토하는 작업이 늘어나며 재미와 몰입도가 감소함

경력 성장과 몰입도 저하

  • 신입 개발자는 테스트 자동화로 인해 코드를 깊이 이해할 기회를 잃을 수 있음
  • AI는 기획 문서 작성, 코드 테스트 등 다양한 업무에서 지원하지만, 인간이 아닌 도구 중심의 평가 환경으로 전환 중
  • 오바마 캠프 CTO 출신 Harper Reed는, 모든 부분을 깊이 이해하지 않아도 되는 시대라고 보며, 이는 제조업과 유사한 변화라고 설명함
  • 반면, Simon Willison은 아이디어 실현 속도가 빨라지는 점에서 AI를 긍정적으로 평가함

불만과 조직적 반응

  • AI 사용과 그에 따른 직무 변화로 인해 많은 개발자들이 Amazon Employees for Climate Justice 그룹에서 불안과 스트레스를 공유하고 있음
  • 특히 직무의 질 저하와 경력 불확실성에 대한 우려가 많으며, 이는 과거 자동차 노동자들이 느꼈던 속도전의 스트레스와 유사함
  • 아직 개발자 노조 결성 움직임은 없지만, 조직 내 내부 공감대는 확대되고 있음

역사적 맥락과 미래 전망

  • 1936년 GM 파업 당시처럼, 직무 속도와 자율성 문제는 노동자 행동의 촉매가 될 수 있음
  • 과거에는 개인이 작업 방식과 속도를 조절할 수 있었지만, 지금은 전 과정이 모니터링되고 속도 중심으로 평가되는 체제로 바뀜
▲
GN⁺ 2일전  [-]
Hacker News 의견
  • archive.ph/HVZRL 링크 공유 내용
  • 나에게 LLM 기반 개발은 마치 크립토나 VR처럼 과장된 유행 hype 라는 생각 듦. 최근 vibe coding으로 작성된 코드베이스의 버그를 고치는 경험을 하며, 이 방식은 체계 없는 비즈니스 문제들이 구조화 없이 코드로 옮겨지는 일종의 혼란 덩어리임을 느낌. 개선이 필요한 부분은 좁은 패치로 때우다보니 결과적으로 복잡하고 비조직적 코드 생성. 맥락 창 context window의 한계에 부딪히면 LLM이 자체 패치도 기억 못함. 영어(또는 인간 언어)는 내가 원하는 코드를 정확히 설명하기엔 애매하고, 시니어 개발자가 코드에 녹여둔 수많은 경험과 시행착오의 총집합을 프롬프트로 다 풀어내는 건 극도로 무거운 작업. "왜 이렇게 짰는지"와는 반대로 "이런 상황에선 이렇게 하지 말고, 저렇게 해라"라는 엄청 구체적이고 끝도 없는 리스트가 필요한 차이점 존재
    • 내가 지난 30년 동안 봐온 대부분(딱 하나 제외한)의 코드베이스 설명이랑 딱 맞아떨어지는 관찰
    • 반론 제기—AI가 구조를 추출해야 할 30여 곳에서 코드 패턴을 찾아내게 도와준 일도 있었음. vibe coding의 문제는 태도라고 봄. 직접 코딩을 피하려는 사람이 장기적 구조나 품질보단 지금의 편함에만 집중하는 경향, 일종의 게으름 증폭기라는 생각
    • 실상 많은 프로덕션 코드가 패치 떼기 하며 작동되는 코드 스니펫 조각들의 집합임. 현실적으로 CPU가 너무 빨라서 이런 코드도 그냥 돌아가는 슬픈 상황
    • 인간 언어가 명확하지 않다는 지적에 동감. 결국 자연어로 명확하게 소프트웨어를 다루겠다는 시도가 몇 번이나 반복된 적 있으며, 결국 법률과 마찬가지로 회색지대 해석이 끊이지 않음. 미래엔 개발자들이 컴파일 전에 프로그램 의미를 논쟁해야 한다면 그 미래는 암울
    • AI도 크립토나 VR만큼 과장된 hype로 보이는 게 맞음. 하지만 소프트웨어 엔지니어처럼 고도로 테크니컬한 직업에도 결국 자동화가 영향을 줄 것. 최근 10년간 테크 업계 사람들이 다른 노동자 문제와는 무관하다고 착각했지만, 리먼트/감원 문화로 인해 이제 임금 억제가 본격화됨. AI가 전체를 즉시 대체하지 않아도, 5명이 하던 일을 4명이 AI와 함께 하게 되면서 1명 감원, 잔류 인원도 임금 인상 요구 엄두 못 내는 구조 반복. 테크 직군도 결국 노동자임을 깨달아야 한다는 주장
  • Harper Reed가 “코드에 대해 깊이 이해할 필요가 없다”는 의견에 대해, 이런 발언이 오히려 “컴파일만 되면 배포하자”라는 급조 논리로 느껴짐. 자동화라인에서 끊임없이 품질을 측정하면서도, 실제 기계는 각도 착각이나 엉뚱한 용접 등 환각을 일으키지는 않는데, LLM 기반 소프트웨어는 이런 사소한 오차가 반복
  • LLM 기반 툴이 정말 개발자 생산성을 극적으로 올렸는지, 아니면 조직이 더 적은—그리고 이전보다 덜 특권화된—개발자만으로도 되는 걸 알아낸 것뿐인지 의문. 대형 테크 기업 내 ‘혁신적 생산성 제고’ 사례도 별로 못 보겠고, 지금까지는 투자를 상쇄할 정도의 약간의 생산성 향상만 있는 실정
    • 상당 부분은 인식의 문제. 예전엔 개발이 어려운 일이었지만 AI 툴 등장으로 코딩의 진입장벽이 낮아진 걸로 인식. 소프트웨어 개발이 점점 공장 일처럼 느껴지고, 지적 보람이 줄어든 현상
    • 코드베이스 장기 유지보수성에 의구심. vibe coding이 점진적으로 복잡성과 미묘한 버그, 추상화 문제를 쌓아 결국 유지보수, 신규 기능 개발 난이도를 올림. 단기적 생산성 상승에 갇혀 장기적 품질 하락 가능성
    • 조직들은 예전부터 관료적 절차로 ‘기술 탈피’, 즉 숙련도 낮은 인력을 표준화로 대체해왔음. 장기적으로 독이 될 수 있는 전략이지만, 일관성만 있으면 ‘평범하게 쓸만한 솔루션’에 안주
    • 이런 논리가 설득력을 가지려면, Amazon 경영진이 단기 이익을 장기 품질보다 더 중시한다고 가정해야 하지만 이에 대한 확신 없음
  • 곧 은퇴하는 입장에서 최근 변화에 허탈함. 90년대 운명을 시작할 당시에는 긴 시간 실험과 창의성에 몰입하는 여유가 있었음. 요즘은 단위작업과 상태보고, 끊임없는 정당화가 필수. 앞으로도 흥미로운 개발자들은 있겠지만, 그런 기회가 줄고 있음. 사실 자동화로 삶이 힘들어진 다른 직업들과 똑같은 길을 걷는 거라 공정한 결과
    • 일상적 상태보고 스탠드업(stand-up) 등은 시간이 걸리는 데다, 내 업무를 이해 못 하는 이들로부터 하루 더 자유로워지기 위한 형식적 대응일 뿐, 일의 가치를 떨어뜨림
    • 나도 90년대 입사자고 JIRA 기반으로 세밀하게 통제되는 현상에 공감. 다만 예전만이 무조건 황금기라고 생각하지는 않음. 과거의 좋은 경험만 기억하려는 향수 버프도 있는 듯. 하지만 요즘도 충분히 도전적이고 좋은 일, 배울 거리 존재
    • 엔지니어 일자리 자동화보다, 사실상 관리직을 AI 중심 감시로 대체하는 방향성
  • 소프트웨어 개발을 획기적으로 빠르게 하려면, 누군가의 오픈소스 코드를 그대로 복사해 사용하고 저작권/라이선스 흔적을 제거해 적용하는 방식도 있음. 직접 들키는 게 걱정이라면 외주 업체를 써서 세탁하거나, 요즘은 AI로 저렴하고 빠르게 세탁 가능. Google은 예전엔 이런 행동을 자제했고, 담대함이 부족했다. 하지만 소규모 신생업체들은 저작권 위반 리스크를 무시한 AI 활용으로 빠른 성공을 노림
    • 내가 속한 산업에서는 오히려 코드의 부재보다 “무엇을 어떻게 짜야 하는지” 정의가 더 큰 문제. Stackoverflow나 Github로 해결 안되는 고유 문제도 많음
    • Google도 사실 예전부터 사이트 콘텐츠를 긁어다 검색결과에 직접 노출, 트래픽 없이 남의 콘텐츠 활용. 이번에도 단순히 늦었을 뿐
    • 아이러니하게도, 어떤 이들은 대기업이 오픈소스 코드를 표절이라도 해주길 바란다는 의견. 그들이 직접 만든 냉정하고 비효율적인 방식을 이용자 입장에서 강요받는 게 더 낫지 않기 때문
    • 오픈소스에 코드를 올리는 것의 한계에 공감. 대기업은 무료 노동력을 얻기 위한 수단으로 오픈소스를 장려하는 경향. 단기적으로 기여가 줄더라도 장기적으로 업계가 건강해질 거란 생각
    • ChatGPT 등장과 Sam Altman의 리더십에 대한 무책임함 지적
  • 코드 작성보다 읽기가 더 어렵고 재미없다는 Simon Willison의 발언과, AI가 문서 작성 및 테스팅 등 부수적 작업을 많이 도와주고 있다는 아마존 개발자 사례 인상적. 이제 코딩보다는 기존 코드 리뷰, 버그 수정 중심으로 역할 변화
    • 초기에 코드 짜는 게 즐거웠던 지난 시절 생각. 이제는 버그 수정이 더 재밌고, LLM이 단순한 반복 코딩을 대신해줘서 도전 과제에 집중할 수 있음. LLM 덕분에 개발의 일부 재미가 살아남
    • 이 글에서 느껴지는 분위기는 꽤 부정적
  • 생산성 신기술이 나오면 기업은 빨리 효과를 가져가 표준화함. 계속 따라잡으려면 끊임없이 공부해야 하고, 언젠가는 자기만의 성장 이득을 직접 챙기는 환경(자영업 등)으로 전환도 고려해야 함. 하지만 혼자 일한다는 건 AI에 숙련된 이들과 경쟁해야 한다는 뜻이라, 쉬운 해결은 아님
    • 세 가지 미래 시나리오 예상. 1) 코드베이스가 점점 혼란과 불안정 속으로 무너지고, 결국 경험 많은 개발자를 비싼 값에 재투입해야 할 수도 있음. 2) AI가 그럭저럭 쓸 만큼의 코드를 만들고, 품질이나 신뢰성은 낮지만 큰 사고는 없는 상태 낙관. 3) AI가 급격히 똑똑해져 코드베이스 개념 자체가 사라지고, 필요할 때마다 동적으로 생성 및 진화되는 소프트웨어 시대. 현재 LLM은 여기에 한참 미치지 못함. 기업 임원들은 3번을 믿지만 아직은 1~2번이 현실. 관리가 잘 된다면 2번의 균형적 관점으로도 이행 가능
    • 생산성 향상이 더 공정하게 분배되는 모델도 있음. 예전 유럽처럼 근무시간 단축 등. 요즘은 심지어 노동자들조차 바빠보이는 정체불명의 잡일에 매달리는 듯한 모습
    • 네가 사실상 마르크스주의자 관점을 말하고 있는데, 이상하게 결론이 자기 소외로 귀결되는 점이 재미있음. 조금만 힘을 합치면 개선 가능인데 그러지를 않음
    • 계속 끊임없이 자기계발하며 살아야 된다고 받아들이지 말고, 사회 구성원과 힘을 합쳐 고용주에 함께 요구하는 방법도 있음. 주 5일제, 8시간 근무, 아동 노동 금지도 집단 행동으로 얻은 결과임. 내 일만 열심히 하고 남 잘되는 거에만 집중할 필요 없음
  • 우리 업계가 유치하게 변하는 모습에 항상 놀람. 대기업, 대규모 코드베이스 경험자라면 신규 코드 생성이 개발의 작은 부분이라는 걸 아는 현실
    • 실제로 신규 코드 이외의 일, 즉 다른 부수적인 부분들도 대기업에서 비효율적임. AI가 이런 점도 바꿔서 끊임없는 회의나 추상적인 논의 감소 전망
    • 지금 열광하는 사람들 중 상당수는 사실 최신 패러다임에 얽매여 코드 작성 자체가 어려워진 사람들임. Copilot 등 LLM 도구로 빠르게 POC를 만들어 프로덕션까지 보내면서 품질, 확장성 등은 깊이 생각 못하는 경우 많음. 그리고 이런 이들이 AI 도입의 생산성 상승 사례를 무조건적으로 광고하며, 대기업 이익과 맞물린 주장만 반복. 정작 실무에선 아쉬운 점도 많다는 걸 실제로 써보는 사람들은 다 앎
    • 나도 전체 시간의 20% 정도만 코딩, 나머지는 요구사항 수집, 설계, 테스트, 일정 관리. 그 20% 코드 작업이 절반으로 줄면, 남는 시간에 테스트나 문서화 작업 더 할 수 있을 것 같음
  • LLM 도움으로 개발 효율이 대폭 증가할 거란 착각이 있음. 사실 기본 실력이 있을 때만 품질 손실 없이 생산성 상승 가능. 즉, 숙련자에게 생산성 증폭 효과지만, 규모만 키운 초보 군단에 LLM을 쥐어주면 품질 좋은 소프트웨어는 어려움
    • 이런 주장 반복하는데, "품질"의 커트라인이 어디냐가 중요. 실제로 젊은 개발 스터디 팀에 SRE 친구가 주간 리뷰하면서 LLM 적극 활용 중인데, 코드 품질이나 확장성도 충분. 속도가 느릴 뿐 완성도는 나쁘지 않음
    • "좋은" 소프트웨어가 필요한 곳은 일부일 뿐이고, 실제로 Deloitte, Accenture 같은 곳의 수익 구조를 보면 대부분의 기업은 품질에 신경조차 쓰지 않음. 대다수는 "그럴듯한" 소프트웨어면 충분
답변달기