AI는 엔지니어링을 없애지 않았다 — 한 것처럼 보이기만 쉬워졌을 뿐
인도 엔지니어의 날을 맞아, AI 코딩 도구가 만들어낸 착각을 짚은 개발자의 글. 동작하는 결과물을 얻는 것과 그것을 이해하는 것이 뒤섞여버린 현실을 자신의 프로덕션 버그 사례로 설명한다.
개요 #
9월 15일은 인도와 스리랑카, 탄자니아가 기념하는 엔지니어의 날이다. 인도 토목공학자 M. 비스베스바라야(Sir M. Visvesvaraya)의 탄생일에서 온 날짜다. 그는 크리슈나 라자 사가라 댐을 비롯한 대형 관개·수자원 사업을 이끌었고, 카다크바슬라 저수지에 처음 설치된 자동 수문 시스템을 고안했다. 개발자 Dhruv Jani는 이 인물을 꺼내며 한 문장을 덧붙였다. 비스베스바라야는 스스로를 창업자라 부른 적이 없다. 실제로 물을 막아야 하는 것들을 만드느라 바빴다.
Jani가 이 이야기로 글을 시작한 이유는 따로 있다. AI 코딩 도구와 "building in public" 문화가 겹치는 사이, 무엇을 엔지니어링으로 볼 것인지의 기준이 조용히 내려갔다는 것이다.
프롬프트 하나와 "파운더" 사이 #
Jani가 묘사한 패턴은 익숙하다. AI 도구에 프롬프트 하나를 넣어 동작하는 랜딩 페이지를 얻는다. 무료 호스팅에 배포한다. 그날 저녁에는 자신을 "파운더"로 소개한다. 아키텍처를 결정한 일은 없다. 무료 플랜의 요청 한도에 걸리면 무슨 일이 생기는지도 모른다. 모델이 실제로 무슨 코드를 썼는지 검토하지도 않았다. 남은 건 URL 하나와 "building in public" 게시물 하나뿐이다.
문제는 AI를 썼다는 데 있지 않다. Jani가 지적한 지점은 더 구체적이다.
문제는 동작하는 무언가를 가진 것이 그것이 왜 동작하는지 아는 것과 같은 말이 되어버렸다는 데 있다.
그는 이를 자판기에서 음료를 뽑아놓고 자신을 바텐더라 부르는 일에 비유했다. 몇 분 만에 동작하는 앱을 만들어내는 AI 자체는 진짜로 훌륭하다는 게 그의 전제다. 무서운 쪽은 다르다. 생성하는 일과 이해하는 일이 많은 사람의 머릿속에서 서로 바꿔 써도 되는 말이 됐다는 것. 빠르게 출시하는 건 좋다. 다만 그것을 엔지니어로 만들어주는 부분과 혼동하지 말자는 게 그의 요지다.
차이가 실제로 드러나는 곳 #
Jani는 올해 초 혼자 겪은 일을 근거로 든다.
방치된 과제를 다시 꺼내 프로덕션으로 #
ShelfTalk은 대학 과제로 시작한 MERN 스택 북클럽 앱이다. 한 학기 동안 혼자 만들어 학점을 받을 만큼만 굴러가게 해놓고, 이후 몇 달간 GitHub에 그대로 방치했다. 다시 손을 댄 계기는 GitHub의 Finish-Up-A-Thon이었다. AI로 작업한 프로젝트를 어중간하게 남기지 말고 제대로 끝내는 데 초점을 맞춘 챌린지다.
마감이 생기자 작업 목록이 명확해졌다. REST 폴링을 걷어내고 Socket.io 기반 실시간 채팅을 넣었다. 실시간으로 동기화되는 리딩룸을 붙였다. 데이터는 GridFS와 함께 MongoDB Atlas로 옮겼다. 빌드 도구는 Create React App에서 Vite로 교체해 HMR 시간을 약 80% 줄였다. 결과는 500개 이상의 참가작 중 상위 10위였다.
정작 가장 많이 가르쳐준 것은 버그였다 #
Jani는 위의 재작업보다 몇 주 뒤 프로덕션에서 터진 버그 하나가 더 많은 것을 알려줬다고 썼다.
그는 푸시 알림에 스스로 영리하다고 생각한 최적화를 하나 넣어뒀다. 탭이 보이는 상태라면 데스크톱 알림을 띄우지 않는 것. 이미 읽고 있는 메시지를 알림으로 또 받고 싶은 사람은 없으니 깔끔한 UX라고 판단했다. 그러다 사용자들이 다이렉트 메시지를 놓치기 시작했다. 정작 본인 테스트에서는 재현되지 않았다. 코드는 설계한 대로 정확히 동작하고 있었기 때문이다.
버그는 코드 한 줄이 아니라 가정 안에 살고 있었다.
그의 코드는 "OS가 이 픽셀을 그릴 수 있다"와 "사람이 지금 이걸 보고 있다"를 슬쩍 같은 것으로 취급했다. 듀얼 모니터로 ShelfTalk을 띄워둔 사용자는 알림을 전부 조용히 잃고 있었다. 화면에 온전히 떠 있는 탭은 20분간 아무도 쳐다보지 않았더라도 기술적으로는 "visible"이기 때문이다. 해결책은 스스로 자랑스러워했던 최적화를 지우는 것이었다. 알림이 살짝 중복되는 건 조금 짜증나는 일이다. 메시지가 조용히 사라지는 건 망가진 제품이다.
이 버그는 데모에서 절대 보이지 않는다. 프롬프트로 프로젝트를 밀어붙이는 과정에서도 발견되지 않는다. Jani가 알아차리기까지는 사용자 불만이 필요했고, "설계한 대로 정확히 동작한다"는 상태를 충분히 오래 붙들고 앉아 설계의 전제 자체가 틀렸음을 깨달아야 했다.
그렇다고 AI를 안 쓴 것도 아니다 #
ShelfTalk 재작업의 상당 부분은 Copilot과 함께 썼다고 그는 밝힌다. 소켓 이벤트 핸들러 골격을 잡아줬고, Vite 마이그레이션 중 import 오류를 잡아냈고, 어차피 직접 찾아봤을 UI 패턴을 자동완성해줬다. 그럼에도 그는 이 작업을 "바이브 코딩"이라 부르지 않는다. 그가 비판하는 쪽의 바이브 코딩은 자기 프로젝트가 망가졌다는 사실을 알아내고 압박 속에서 고쳐야 하는 구간을 건너뛰기 때문이다.
검토하고, 디버깅하고, 자신이 무엇을 만들었는지 실제로 아는 부분. 그게 일 전체였다는 게 그의 결론이다. 혼자였으니 놓친 걸 잡아줄 사람도 없었다. 콘크리트와 철을 다룬 비스베스바라야에게도 그랬고, 타이핑 일부를 Copilot이 맡는 지금도 그렇고, 듀얼 모니터에서 터진 불리언 하나에도 똑같이 적용되는 이야기다.
선은 어디에 있나 #
Jani는 AI가 문제라고 보지 않는다. 그가 문제로 지목한 건 엔지니어로 만들어주는 부분을 건너뛰면서 엔지니어처럼 들리게 해주는 부분만 챙기는 일이 너무 쉬워졌다는 점이다.
AI는 엔지니어링 작업을 없애지 않았다. 그것을 했다고 흉내내기 쉽게 만들었을 뿐이다.
그는 글을 질문으로 닫는다. AI로 무언가를 만드는 것과 AI가 만드는 것을 그냥 지켜보는 것, 그 사이의 선을 당신은 어디에 긋는가. 그리고 스스로 그 선의 잘못된 쪽에 서 있는 걸 발견한 적이 있는가.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.