더는 존재하지 않는 일을 애도하는 엔지니어들

AI 요약

AI 코딩 도구가 엔지니어의 일뿐 아니라 직업에서 얻는 만족감과 정체성까지 바꾸고 있다는 분석입니다. 엔지니어링 리더이자 연구자인 Annie Vella는 여러 엔지니어가 진로를 다시 고민하거나 업계를 떠나는 사례를 접했다고 말합니다. 코드 작성보다 에이전트 조율, 코드 리뷰, 결과 검증에 더 많은 시간을 쓰면서 일을 예전만큼 즐기지 못한다는 호소가 나온다는 설명입니다.

만들던 사람에서 검토하는 사람으로

Vella의 연구에서는 엔지니어 77%가 코드 작성 시간이 줄었다고 답했고, 거의 절반은 핵심 기술이 AI 프롬프트 작성보다 부차적인 능력으로 밀릴 가능성을 걱정했습니다. Vella는 이를 해결책을 직접 만드는 일에서 프롬프트를 만드는 일로의 변화라고 설명합니다. 과거에는 요구사항, 설계, 테스트를 다른 직무에 맡기고 엔지니어가 코딩에 집중하도록 역할을 좁혀 왔지만, AI 도구가 확산되면서 엔지니어에게 리뷰어와 에이전트 감독자 역할을 더 요구한다는 지적입니다.

손으로 문제를 풀고 코드를 쓰는 과정에서 보람을 느낀 엔지니어가 특히 적응하기 어렵다고 글은 설명합니다. Oregon State University 연구진은 56개 조직의 전문 개발자 442명을 조사해 Job Demands-Resources 프레임워크로 생성형 AI 도입과 번아웃의 관계를 분석했습니다. AI 도입에 따른 업무량 증가와 조직의 압박은 번아웃을 유의하게 높였습니다. 직무, 경력 수준, 회사 규모에 따른 유의미한 차이는 발견되지 않았습니다. 연구 참여자 중 거의 4분의 1은 매일 AI 도구를 쓰라는 기대를 받으면서도 조직에서 의미 있는 학습 지원을 받지 못했다고 답했습니다.

눈에 보이지 않는 검증 업무

팀의 코드 출하량이 늘어도 대시보드는 AI 생성 코드의 리뷰, 디버깅, 동작 검증에 드는 시간을 제대로 보여주지 못합니다. 글은 생성 코드가 많아질수록 품질을 중시하는 엔지니어, 특히 숙련된 엔지니어에게 검토 부담이 쏠릴 수 있다고 지적합니다. 출력 속도만 측정하면 가장 많은 인지적 부담을 지는 사람이 지표상 덜 생산적인 것처럼 보입니다. 리더가 살펴야 할 항목으로 AI 생성 Pull Request 검토 시간, 직접 작성하지 않은 코드의 디버깅 시간, 동작을 충분히 추적하기 어려운 코드의 검증 시간을 제시합니다.

글이 인용한 Vella의 제안은 AI 도입을 일괄 처방으로 다루지 말고 불만의 원인을 구분하라는 것입니다. 더 빠른 납기 압박, 코드 이해도 저하, 결과물에 대한 책임, 리뷰 업무 증가, 해고 불안은 서로 다른 문제이므로 대응도 달라야 합니다. 연구에서는 AI 사용 방식에 대한 자율성과 실질적인 학습 기회가 번아웃을 낮추는 요인으로 나타났습니다. AI를 쓰라고 요구하면서 업무 흐름에 대한 엔지니어의 선택권을 주지 않으면 부담을 키울 수 있습니다.

품질 기준을 지키는 사람에게 쏠리는 부담

글은 AI 도구에 가장 힘들어하는 엔지니어가 반드시 AI 반대자는 아니라고 강조합니다. 이들 가운데는 초기 도입자도 있으며, 코드 품질을 중시하지만 조직의 기준이 바뀌는 상황에서 동료가 만든 대량의 코드를 검토하고 고치는 역할을 떠안는다고 설명합니다. Deedy Das는 이들을 장인에 빗대며, 리뷰 대기열과 메신저 알림이 쌓이고 코드 품질을 개선하려는 피드백이 반영되지 않는 상황을 묘사합니다. 글의 관점에서 번아웃의 원인은 대체 불안만이 아니라, 기준을 지키려는 사람이 조직의 마지막 방어선으로 남는 데 있습니다.

Reddit 반응

• @u/Smooth-Arachnid5071 — 확실히 업무량 문제입니다. 기대치가 말도 안 됩니다. 평균적으로 2~3일마다 기능 하나를 내놓지 않으면 뒤처진다고 합니다.
  • @u/who_am_i_to_say_so — 저는 약 1년 전에 기술 발전의 영향을 받아 일자리를 잃은 SWE입니다. 예전 동료들에게 들으니 한 달 걸리던 일을 이제 며칠 만에 끝내고, Jira 보드를 가득 채우는 티켓마다 계속 진행 상황을 묻는다고 합니다. 한 회사의 사례일 뿐이지만 업계의 다른 곳을 대체로 따라 하는 모양입니다. 저는 전혀 놓치고 있는 기분이 들지 않습니다. 돌아갈 생각도 없습니다.
• @u/Big_Wave9732 — 엔지니어의 사고방식은 호기심에서 나옵니다. 문제를 파악하고 진단하고, 설계하고, 실패하고 다시 시도해 해결하는 정신적 과정이 엔지니어가 원하는 일입니다. 직접 애써 얻은 해결책이 기쁨을 줍니다. AI는 그 지적 노동을 없앱니다. 결과는 얻지만 그 과정에 에너지를 쓰지 않았으니 같은 만족감이 없습니다. 효율이 높아졌다는 이유로 업무량이 크게 늘어난 점도 도움이 되지 않습니다.
  • @u/iscottjs — 이해는 하지만 AI와 함께 어려운 문제를 푸는 과정에서 큰 만족을 느끼기도 합니다. 로그를 뒤지고 가설을 세우고 다른 방법을 시도합니다. AI가 엉뚱한 방향으로 가면 한동안 같이 헤매다가 방향을 바꿉니다. 혼자 했으면 며칠이나 몇 주 걸렸을 문제를 풀기도 합니다. 항상 처음부터 답을 내놓는 건 아닙니다.
• @u/Capable_Divide_6916 — 어느 정도 비슷한 일이 있었습니다. 저수준 코드에 가까이 일하는 엔지니어 중에는 C++도 불신하는 사람이 있습니다. 함수 호출에 vtable 한 번 더 거치는 것만으로도 반복문 안에서 캐시 성능을 망칠 수 있기 때문입니다. 하지만 실존적 위기라고 할 정도는 아니었습니다. 그런 사람들은 계속 존재했고 드라이버나 운영체제 같은 곳에서 C나 어셈블리로 일합니다. 컴파일러와 LLM은 다른 문제입니다. GCC 소스 코드를 읽고 동작을 이해할 수 있으며 컴파일러 수업을 듣고 직접 작성할 수도 있습니다.
  • @u/Krom2040 — 유효한 비교가 아닙니다. 고급 프로그래밍 언어는 여전히 예측 가능하고, 똑똑한 프로그래머라면 언어 기능이 저수준 요소에서 어떻게 나오는지 대체로 이해할 수 있습니다. AI에게 잘 작동하는 코드를 부탁하고 잘되기를 바라는 일은 전혀 다릅니다. 기업 경영진은 그 방식만 남도록 일정을 강요하고 있습니다. 그 접근법의 결과를 이해하기에는 시간이 충분히 지나지 않았습니다.
• @u/Dredgefort — 문제를 일으키는 건 AI가 아니라 회사의 경영진입니다. 회사마다 경험은 크게 다를 수 있습니다. 경영진이 특정 방향을 강요하지 않고 AI를 업무 흐름에 가장 잘 통합할 방법을 직원이 정하게 하면 꽤 즐거운 경험이 될 수도 있습니다.
• @u/sgtnoodle — 제 경험상 에이전트 코딩은 사람이 작성하는 것보다 몇 자릿수나 더 많은 테스트 커버리지를 비슷하거나 더 나은 품질로 만들 수 있습니다.
  • @u/who_am_i_to_say_so — 양이 늘어난다는 건 의심할 여지가 없습니다. 하지만 품질이 더 높다고요? 아직은 아닙니다. 테스트가 많다고 항상 보장되는 것도 아닙니다. 언제나 절충이 있습니다. 엔지니어라면 그 점을 받아들이고 조정하면 됩니다.
• @u/Entuaka — 일은 소프트웨어를 만드는 것이었고, 지금도 소프트웨어를 만드는 일입니다.

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