AI는 엔지니어링 작업을 없애지 않았다 — 다만 '한 척'하기 쉬워졌을 뿐

본문

9월 15일은 인도와 스리랑카, 탄자니아에서 기념하는 엔지니어의 날(Engineer's Day)로, M. Visvesvaraya 경의 탄생일입니다. 그는 Krishna Raja Sagara 댐을 비롯한 대규모 관개·수자원 관리 프로젝트를 이끌었고, Khadakvasla 저수지에 최초로 설치된 자동 수문(automatic floodgate) 시스템을 개척한 인물입니다. 저자는 그가 스스로를 '파운더'라 부른 적이 없다고 지적합니다 — 실제로 물을 가둘 수 있는 것을 만드느라 바빴기 때문입니다. 이 서두는 글 전체의 화두를 압축합니다. AI 코딩 도구와 '공개적으로 만들기(building in public)' 문화 사이에서, 무엇이 엔지니어링인지에 대한 기준이 조용히 낮아졌다는 것입니다.

작동하는 것과 이해하는 것의 혼동

저자가 묘사하는 전형적인 패턴은 이렇습니다. 누군가 AI 도구에 프롬프트 하나를 넣고, 동작하는 랜딩 페이지를 얻고, 무료 티어 호스트에 배포한 뒤, 저녁에는 스스로를 '파운더'라 소개합니다. 아키텍처 결정도 없고, 무료 티어의 레이트 리밋(rate limit)에 걸리면 어떻게 되는지도 모르고, 모델이 실제로 무엇을 작성했는지 리뷰도 하지 않습니다. 문제는 AI를 썼다는 사실이 아니라, '동작하는 무언가를 갖는 것'이 '왜 동작하는지 이해하는 것'과 동의어가 되어버렸다는 점입니다. 저자는 이를 '자판기에 소다를 주문해 놓고 자신을 바텐더라 부르는 것'에 비유합니다. AI가 몇 분 만에 동작하는 앱을 생성할 수 있다는 사실 자체는 genuinely great, 즉 진정으로 대단한 일이라고 인정하면서도, 빠르게 출시하는 것과 엔지니어가 되는 부분을 혼동해서는 안 된다고 강조합니다.

ShelfTalk 재구축과 프로덕션에서 드러난 버그

저자는 이 논지를 자신의 실전 경험으로 뒷받침합니다. ShelfTalk은 대학 과제로 시작해 혼자 한 학기 동안 만든 MERN 스택(MongoDB, Express, React, Node.js) 독서 클럽 앱으로, 합격할 만큼만 완성한 뒤 몇 달간 GitHub에 방치되어 있었습니다. AI 보조 작업을 반쯤 끝낸 채 두지 말고 제대로 마무리하는 것을 목표로 하는 GitHub의 Finish-Up-A-Thon 챌린지가 마감 기한을 제공했고, 저자는 프로덕션용으로 전면 재구축했습니다. REST 폴링 대신 실제 Socket.io 기반 채팅을 구현했고, 실시간 동기화된 리딩 룸(reading room)을 만들었으며, GridFS를 포함한 MongoDB Atlas로 마이그레이션하고, Create React App에서 Vite로 옮겨 HMR(Hot Module Replacement) 시간을 약 80% 단축했습니다. 이 작업으로 500개 이상의 출품작 중 상위 10위 안에 들었지만, 정작 더 큰 교훈은 몇 주 뒤 프로덕션에서 나타난 버그였습니다.

저자는 데스크톱 푸시 알림에 '영리한 최적화'를 추가했었습니다. 탭이 화면에 보이는 상태라면 데스크톱 알림을 억제하는 것으로, 이미 읽고 있는 메시지에 알림이 오는 것을 원치 않는 사용자를 위한 깔끔한 UX라고 판단했습니다. 그런데 사용자들이 다이렉트 메시지를 놓치기 시작했고, 본인의 테스트로는 재현되지 않았습니다 — 코드가 설계한 대로 정확히 동작하고 있었기 때문입니다. 버그는 코드 한 줄이 아니라 가정(assumption)에 있었습니다. 코드는 'OS가 이 픽셀을 렌더링할 수 있다'는 것과 '사람이 주의를 기울이고 있다'는 것을 몰래 동일시하고 있었고, 세컨드 모니터에서 ShelfTalk을 실행하는 사용자는 모든 알림을 조용히 잃고 있었습니다. 전면에 표시된 탭은 기술적으로 'visible'이지만, 20분째 아무도 보지 않을 수 있기 때문입니다. 해결책은 자랑스러워했던 최적화를 삭제하는 것이었습니다. 약간 중복된 핑은 약간 귀찮을 뿐이지만, 조용히 유실되는 메시지는 망가진 제품입니다. 이런 버그는 데모에는 나타나지 않으며, 프롬프트만으로 프로젝트를 진행해서는 발견할 수 없습니다. 사용자의 불만 제기와 '설계대로 정확히 동작하고 있다'는 상태를 오래 곱씹어 설계의 핵심 가정이 틀렸다는 것을 깨닫는 과정이 필요했습니다.

바이브 코딩이 아니라 엔지니어링

저자는 Copilot이 ShelfTalk 재구축에 상당 부분 함께했다고 밝힙니다. 소켓 이벤트 핸들러의 스캐폴딩을 만들어주었고, Vite 마이그레이션 중 import 오류를 잡아주었으며, 어차피 직접 찾아봤을 UI 패턴을 자동완성해주었습니다. 하지만 저자는 이를 '바이브 코딩(vibe coding)'이라 부르지 않습니다. 그가 비판하는 바이브 코딩은 자신의 프로젝트가 망가졌다는 것을 발견하고 압박 속에서 고쳐야 하는 부분을 건너뛰는 방식이기 때문입니다. 리뷰하고, 디버깅하고, 자신이 만든 것을 실제로 아는 부분 — 그것이 작업의 전부였고, 혼자였기에 놓친 것을 잡아줄 사람도 없었습니다. Visvesvaraya에게 콘크리트와 강철이 그랬듯, Copilot이 타이핑의 일부를 해주는 지금도 마찬가지이며, 세컨드 모니터 위의 어리석은 불리언 하나에도 똑같이 적용된다는 것입니다.

저자는 AI가 문제가 아니라고 결론 내립니다. 문제는 엔지니어처럼 들리게 만드는 부분은 유지하면서, 엔지니어로 만드는 부분을 건너뛰기가 너무 쉬워졌다는 점입니다. AI는 엔지니어링 작업을 제거하지 않았고, 그것을 했다고 가장하기를 쉽게 만들었을 뿐입니다. 저자는 독자에게 질문을 던집니다 — AI를 사용해 무언가를 만드는 것과 AI가 만드는 것을 그저 지켜보는 것 사이의 경계선을 어디에 긋고 있는지, 그리고 자신이 그 선의 반대편에 있었던 적이 있는지.

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