AI가 엔지니어링을 지웠다고? 천만에! '만든 척'하기만 더 쉬워졌을 뿐!
2026. 9. 16.
AI가 엔지니어링을 지웠다고? 천만에! '만든 척'하기만 더 쉬워졌을 뿐!
매년 9월 15일은 인도, 스리랑카, 탄자니아에서 엔지니어의 날로 기념됩니다. 위대한 공학자 M. 비스베스바라야 경의 탄생일이죠. 그는 크리슈나 라자 사가라 댐을 포함해 주요 관개 및 수자원 관리 프로젝트를 이끌었으며, 카다크바슬라 저수지에 처음 설치된 자동 수문 시스템을 개척한 선구자였습니다. 정작 그는 자신을 '창업가'라 부른 적이 없어요. 그저 물을 실제로 가두는, 견고한 구조물을 짓는 데 온전히 몰두했으니까요.
제가 비스베스바라야 경 이야기를 꺼내는 이유가 있습니다. 요즘 AI 코딩 도구와 '공개적으로 만들기(building in public)' 시대가 도래하면서, 엔지니어링의 기준이 슬그머니 낮아진 듯한 느낌을 지울 수 없네요. 그리고 그 여파가 서서히 드러나고 있습니다.
새로운 착각의 시대
이런 패턴, 분명 보셨을 겁니다. 누군가 AI 도구에 프롬프트 하나 툭 던집니다. 뚝딱 만들어진 랜딩 페이지를 무료 호스팅에 배포하고, 저녁 무렵엔 자신을 "창업가"라고 소개하죠. 그 과정에서 아키텍처 결정은 전무하고, 무료 티어의 트래픽 제한에 걸리면 무슨 일이 생길지 전혀 알지 못합니다. AI 모델이 실제로 무슨 코드를 썼는지 검토하는 과정도 없어요. 그저 URL 하나와 "building in public"에 대한 포스팅만 남을 뿐이죠.
문제가 AI를 썼다는 데 있는 건 아닙니다.
진짜 문제는 "뭔가 작동하는 것을 가졌다"는 것이 "왜 작동하는지 이해한다"는 것과 조용히 동의어가 되어버렸다는 점이죠.
그건 마치 자판기에서 음료수를 뽑고 스스로를 바텐더라고 부르는 것과 다를 바 없습니다.
AI가 몇 분 만에 작동하는 앱을 만들 수 있다는 사실 자체가 무서운 건 아닙니다. 사실 그건 대단히 멋진 일이죠. 하지만 무서운 건 많은 사람들의 머릿속에서 '생성하는 것'과 '이해하는 것'이 은밀하게 뒤바뀌고 있다는 점입니다. 빠르게 배포하는 것, 물론 좋습니다. 하지만 그걸 당신을 엔지니어로 만드는 본질적인 부분과 혼동하지는 마세요.
진짜 차이는 여기에 있다
올해 초, 이 부분에 대해 제가 혼자서 아주 확실한 교훈을 얻은 경험이 있습니다.
재구축 이야기
ShelfTalk는 대학 과제로 시작했어요. 한 학기 동안 혼자서 만든 MERN 스택 기반의 독서 모임 앱이었죠. 간신히 통과할 정도로만 만들고는 몇 달 동안 GitHub에 방치해뒀습니다. 그러다 GitHub의 'Finish-Up-A-Thon' 챌린지가 시작됐습니다. AI의 도움을 받은 작업을 어중간하게 남겨두지 않고 제대로 마무리하라는 취지의 챌린지였죠. 덕분에 프로덕션 수준으로 앱을 재구축할 기한이 생겼습니다. REST 폴링 대신 실시간 Socket.io 채팅을 넣고, 실시간 동기화 독서 공간을 구현하고, MongoDB Atlas와 GridFS로 마이그레이션했습니다. Create React App에서 Vite로 옮기면서 HMR(핫 모듈 리플레이스먼트) 시간도 무려 80%가량 단축했죠.
그 결과, 500개 이상의 참가작 중 상위 10위 안에 들었습니다.
https://dev.to/dj29/shelftalk-books-dont-talk-we-do-a-college-project-revived-o4o
결정적인 깨달음을 준 버그
하지만 그 어떤 작업도 몇 주 후 프로덕션 환경에서 발생한 버그만큼 저에게 큰 가르침을 주지는 못했습니다. 저는 푸시 알림에 똑똑한 최적화를 추가했다고 생각했어요. 탭이 보이는 상태라면 데스크톱 알림을 억제하는 기능이었죠. 읽고 있는 메시지에 대해 또 알림을 받는 걸 좋아하는 사람은 없으니까요. 깔끔한 UX라고 생각했죠. 그런데 사용자들이 다이렉트 메시지를 놓치기 시작했고, 제 테스트에서는 버그를 재현할 수 없었습니다. 코드는 제가 설계한 대로 정확히 작동하고 있었거든요.
이 버그는 코드 한 줄이 아니라, '가정' 속에 숨어 있었습니다.
제 코드는 "운영체제가 이 픽셀을 렌더링할 수 있다"는 것을 "사용자가 주의를 기울이고 있다"는 것과 조용히 동일시하고 있었던 거죠. 결국, ShelfTalk를 두 번째 모니터에서 실행하는 모든 사용자는 알림을 놓치고 있었습니다. 탭이 전체 화면으로 보여도 20분 동안 아무도 보지 않았을 수 있는데, 기술적으로는 '보이는' 상태였으니까요. 해결책은 제가 자랑스러워하던 그 최적화 기능을 삭제하는 것이었습니다. 약간 중복되는 알림은 조금 귀찮을 뿐이지만, 조용히 사라지는 메시지는 제품을 망가뜨리는 치명적인 문제니까요.
제가 실무에서 이런 종류의 버그를 만났을 때, 코드가 아닌 '맥락'을 이해하는 게 얼마나 중요한지 절실히 깨달았죠. 특히 눈에 보이지 않는 잠재적인 문제를 찾아내는 능력이야말로 진짜 엔지니어의 역량이라고 생각합니다.
이 버그는 데모에서 절대 드러나지 않습니다. 프로젝트를 프롬프트 몇 번으로 뚝딱 만들어낼 때 발견할 수 있는 버그도 아니죠. 버그를 인지하는 데는 사용자 불만이 필요했고, "내가 설계한 대로 완벽하게 작동하는데?"라는 생각에 충분히 파묻혀야만 비로소 설계의 핵심 가정이 틀렸다는 것을 깨달을 수 있었습니다.
ShelfTalk를 재구축할 때 Copilot의 도움을 많이 받았습니다. 소켓 이벤트 핸들러의 기본 골격을 잡아주고, Vite 마이그레이션 중 임포트 오류를 잡아주고, 어차피 수동으로 찾아봤을 UI 패턴을 자동 완성해주었죠. 하지만 이 모든 과정을 "대충 코딩했다(vibe coded)"고 말하고 싶지는 않습니다. 제가 비판하는 "대충 코딩"은 자신의 프로젝트가 망가졌음을 깨닫고 압박감 속에서 고쳐야 하는 과정을 건너뛰는 것이니까요.
그 과정, 즉 코드를 검토하고, 디버깅하고, 자신이 무엇을 만들었는지 '정확히 아는' 과정이야말로 작업의 전부였습니다. 다른 사람의 도움 없이, 혼자서 놓친 부분을 찾아내야 했죠. 비스베스바라야 경이 콘크리트와 강철을 다룰 때도 그랬습니다. Copilot이 일부 코드를 대신 타이핑해주는 지금도 여전히 마찬가지이며, 보잘것없는 불리언 값 하나가 두 번째 모니터에서 일으킨 문제도 다르지 않았습니다.
그렇다면, 경계는 어디에 있을까?
AI 자체가 문제는 아니라고 봅니다. 문제는 엔지니어로서의 핵심적인 일을 건너뛰고도 마치 해낸 것처럼 보이기 너무나 쉬워졌다는 데 있습니다.
AI가 엔지니어링 작업을 없앤 게 아닙니다. 그저 당신이 그 일을 '했다고 가장하기'를 더 쉽게 만들었을 뿐이죠.
그래서 저는 이렇게 직접적으로 묻고 싶습니다. AI를 활용해 무언가를 '만드는 것'과 AI가 당신을 위해 '만드는 것을 그저 지켜보는 것' 사이의 경계선을 어디에 긋고 계신가요?
혹시 자신도 모르게 그 경계의 잘못된 편에 서 있었던 적은 없나요? 👇
원문: https://dev.to/dj29/ai-didnt-remove-the-engineering-work-it-just-made-it-easier-to-pretend-you-did-42m9 수집일: 2026-09-16 01:57:44