dev.to

AI Is Making You a Worse Engineer and a Better Employee

AI는 여러분을 더 나쁜 엔지니어이자 더 나은 직원으로 만들고 있습니다

AI 코딩 도구는 티켓 처리와 기능 출시 같은 가시적 생산성을 높이지만, 그 과정에서 디버깅 감각과 낯선 문제를 스스로 푸는 능력의 성장을 막을 수 있습니다. 이 글은 AI를 쓰지 말자는 주장이 아니라, 처리량을 엔지니어링 역량의 대리 지표로 삼아 온 평가 방식의 한계를 지적합니다.

AI 요약

소프트웨어 엔지니어에게서 직무를 잘 수행하는 것과 엔지니어링이라는 기술 자체를 잘하는 것이 최근 몇 년 사이 조용히 다른 의미가 되었지만, 이를 명확히 알려준 조직은 거의 없다고 글은 시작합니다. AI 코딩 보조 도구(AI coding assistant)를 사용하면 몇 분 만에 작동하는 프로토타입을 만들고, 티켓을 더 빠르게 닫고, 더 많은 기능을 출시할 수 있습니다. 관리자가 실제로 추적하는 지표만 놓고 보면 AI를 쓰는 엔지니어는 이전보다 훨씬 뛰어난 직원처럼 보일 수 있습니다.

하지만 과거에 이런 결과를 만들어 내던 능력은 단순한 산출량이 아니었습니다. 디버깅 본능(debugging instinct), 시스템 수준의 직관(system-level intuition), 익숙하지 않은 문제를 혼자서 추론하는 능력은 오랜 시간 문제와 씨름하면서 축적됩니다. 글은 바로 그 ‘고생(struggle)’을 AI 도구가 제거하도록 설계되어 있다고 봅니다. 출력이 빨라지는 동안, 반복적으로 사용하지 않는 문제 해결 능력은 충분히 발달하지 못하고 점차 약해질 수 있다는 주장입니다. 그 결과 생산성은 높아지지만, 생산성이 과거에 간접적으로 보여주던 기저 역량은 밑에서 조용히 침식될 수 있습니다.

■ 생산성과 인지 발달은 같은 곡선이 아닙니다

글은 AI가 엔지니어를 더 생산적으로 만든다는 논의에 숨어 있는 가정을 분리해야 한다고 말합니다. 생산성(productivity)은 처리량(throughput)을 측정합니다. 예를 들어 닫은 티켓의 수, 출시한 기능의 수, 시간당 생성한 작동 코드의 양이 여기에 해당합니다. 반면 인지 발달(cognitive development)은 도구가 대신 추론해 주지 않는 상태에서, 이전에 본 적 없는 새로운 문제를 스스로 해결하는 능력이 얼마나 성장했는지를 뜻합니다.

이 두 지표는 과거에는 충분히 가까이 움직였습니다. 더 많이 출시했다는 것은 더 많은 문제를 해결했다는 뜻으로 볼 수 있었고, 문제를 더 많이 해결하는 과정에서 문제 해결 능력도 강화됐습니다. 그러나 AI는 이 연결을 끊습니다. 문제를 해결하는 과정 자체를 AI에 위임하면서, 실제로는 덜 해결하고도 더 많이 출시할 수 있기 때문입니다. 따라서 산출량의 증가는 더 많은 학습이나 역량 향상을 의미하지 않을 수 있습니다.

■ AI 의존은 능력을 키우지 않는 것을 넘어 약화시킬 수 있습니다

저자는 AI 보조 작업이 비보조 작업만큼 문제 해결 능력을 키워 주지 못한다는 데서 논의를 멈추지 않습니다. 이미 갖고 있던 문제 해결 능력을 적극적으로 약화할 가능성도 있으며, 그럴 가능성이 상당히 높다고 주장합니다. 사용하지 않는 기술은 그대로 유지되는 것이 아니라 위축될 수 있기 때문입니다.

문제가 불편해지는 순간마다 자동으로 AI 제안부터 찾는 엔지니어는, 반복할 때마다 불편함을 더 깊이 파고들어야 할 신호가 아니라 다른 곳에 넘겨야 할 신호로 학습하게 됩니다. 글은 이를 중립적인 습관으로 보지 않습니다. 의도적 연습(deliberate practice)은 생산적인 고생의 영역(productive-struggle zone)에 머무는 것을 필요로 하지만, AI의 핵심 가치는 사용자를 그 영역에서 가능한 한 빨리 벗어나게 하는 데 있기 때문입니다.

■ AI를 버리자는 주장이 아니라 평가 기준을 바꾸자는 주장입니다

글은 AI, LLM, 에이전트(agent)를 이용한 코딩을 중단하라고 결론 내리지 않습니다. 기술은 발전하고 엔지니어는 적응해야 하며, 더 높은 수준의 언어가 사용되면서 Assembly가 덜 선호되는 것처럼 도구를 사용하는 것은 자연스럽다고 말합니다. 문제는 도구의 사용 자체가 아니라, 도구를 사용해 만든 결과를 곧바로 역량의 성장으로 해석하는 데 있습니다.

저자는 ‘생산적(productive)’이라는 단어가 이 교환 관계를 보이지 않게 만든다고 설명합니다. 한 주 동안 많은 것을 출시하면 좋은 한 주를 보냈다고 느끼고, 조직이 관찰할 수 있는 모든 신호도 이를 좋은 결과로 평가합니다. 그러나 많이 생산했다는 사실과 생산하는 능력이 향상됐다는 사실은 이제 완전히 분리될 수 있습니다. 기록상 가장 생산적인 한 달을 보냈으면서 동시에 인지적으로는 가장 정체된 달을 보낼 수도 있습니다.

현재의 업무 흐름에는 이를 보여주는 대시보드가 없습니다. 글이 제시하는 유일한 신호는 더 느리고 개인적인 것입니다. 몇 달이 지난 뒤, 예전에는 스스로 추론할 수 있었던 문제 유형을 이제는 시도조차 하기 전에 반사적으로 AI 도구를 찾고 있다는 사실을 알아차리는지 살펴봐야 합니다. 저자가 말하는 진짜 위험은 AI가 오늘 당장 업무를 느리게 하거나 망친다는 데 있지 않습니다. 오늘 일을 잘하고 있는지를 측정하는 방식 자체가 엔지니어링 역량을 평가하기에 충분한 기준이 아닐 수 있다는 데 있습니다.

원문: dev.to / 번역·요약: Trawling