AI는 개발 업무를 없애지 않았다. 단지, '개발했다고 착각'하게 만들었을 뿐.
2026. 9. 17.
AI는 개발 업무를 없애지 않았다. 단지, '개발했다고 착각'하게 만들었을 뿐.
9월 15일, 인도에서는 스리랑카, 탄자니아와 함께 ‘엔지니어의 날’을 기념합니다. 위대한 공학자 M. 비스베스바라야 경의 탄생을 기리는 날이죠. 그는 크리슈나 라자 사가라 댐을 포함해 주요 관개 및 수자원 관리 프로젝트를 책임졌고, 카다크바슬라 저수지에 처음 설치된 자동 수문 시스템을 개척한 인물입니다. 흥미로운 건, 그 스스로를 "창업자(founder)"라고 칭한 적이 없다는 겁니다. 그는 그저 물을 실제로 가둬야 하는 견고한 구조물을 만드는 데 너무 바빴거든요.
이 이야기를 꺼낸 건 다름이 아닙니다. AI 코딩 도구가 보편화되고 '공개적으로 개발하기(building in public)' 시대가 도래하면서, 많은 사람이 '엔지니어링'의 기준선을 조용히 낮추고 있는 것 같다는 생각이 들었기 때문입니다. 그리고 그 결과가 슬슬 드러나기 시작했습니다.
새로운 착각의 시대
이런 패턴, 분명 보셨을 겁니다. 누군가 AI 도구에 프롬프트 하나를 던져 넣습니다. 이내 작동하는 랜딩 페이지가 뚝딱 나옵니다. 무료 티어 호스팅에 배포하고, 저녁쯤 되면 스스로를 "창업자"라고 소개하죠. 그 과정에 아키텍처 결정은 없습니다. 무료 티어의 트래픽 제한에 걸리면 무슨 일이 생길지 전혀 알지 못합니다. AI 모델이 실제로 작성한 코드가 어떤지는 검토조차 하지 않습니다. 그저 URL 하나와 "building in public"이라는 게시글만 남을 뿐이죠.
문제는 AI를 사용했다는 사실 자체가 아닙니다.
진짜 문제는 일단 작동하는 무언가를 갖는 것이 왜 작동하는지 이해하는 것과 소리 없이 동의어가 되어버렸다는 겁니다.
이건 마치 자판기에서 탄산음료를 뽑아 마시고 스스로를 바텐더라고 부르는 것과 같습니다.
솔직히, AI가 몇 분 만에 작동하는 앱을 뚝딱 만들어내는 능력은 놀랍습니다. 이 부분은 정말 대단하고요. 하지만 무언가를 '생성해냈다'는 것과 그 무언가를 '이해한다'는 것이 많은 사람의 머릿속에서 조용히 서로 대체될 수 있는 것으로 변질되었다는 점이 무섭습니다. 빠르게 배포하는 것, 물론 좋습니다. 하지만 그것을 엔지니어로 만들어주는 핵심적인 부분과 혼동하지 마세요. 제가 실무에서 이런 종류의 '빨리빨리' 접근법으로 만든 프로젝트들이 나중에 터져서 수십 배의 시간을 들여 재구축하는 경험을 꽤 여러 번 했습니다. 결국, '왜'를 모르면 제대로 된 확장은 불가능하더라고요.
진짜 '차이'는 어떤 모습일까
저는 올해 초, 혼자 작업하면서 이 차이를 뼈저리게 느낀 구체적인 경험을 했습니다.
프로젝트 재구축 이야기
'ShelfTalk'는 대학 과제로 시작했습니다. 한 학기 동안 혼자 만든 MERN 스택 기반 북클럽 앱이었죠. 겨우 통과할 만큼만 만들고는 몇 달 동안 GitHub에 방치해 뒀었습니다. 그러다 GitHub에서 'Finish-Up-A-Thon'이라는 챌린지가 열렸는데, AI로 어시스트된 작업을 제대로 마무리하라는 취지의 챌린지였습니다. 이 챌린지가 저에게 ShelfTalk을 프로덕션 수준으로 재구축할 완벽한 기한을 주었죠.
REST 폴링 대신 진짜 Socket.io 채팅을 구현하고, 실시간 동기화되는 독서실 기능을 추가했습니다. MongoDB Atlas와 GridFS로 마이그레이션했고, Create React App에서 Vite로 전환하면서 HMR(Hot Module Replacement) 시간을 약 80% 정도 단축시켰습니다.
결과는 500개가 넘는 참가작 중 상위 10위 안에 드는 성과를 거두었습니다.
{% link https://dev.to/dj29/shelftalk-books-dont-talk-we-do-a-college-project-revived-o4o %}
핵심을 짚어준, 그 버그
하지만 그 어떤 개선점도 몇 주 후 프로덕션에서 발생한 버그만큼 저에게 많은 것을 가르쳐주진 못했습니다. 저는 푸시 알림에 기발하다고 생각하는 최적화를 추가했었습니다. "만약 탭이 보이는 상태라면 데스크톱 알림을 억제하자. 이미 읽고 있는 메시지에 대해 또 알림을 받는 것을 좋아하는 사람은 아무도 없을 테니까"라는 생각이었죠. 깔끔한 UX라고 자부했습니다.
그런데 사용자들로부터 "쪽지 알림을 놓친다"는 불만이 들어오기 시작했습니다. 제 테스트로는 재현할 수 없었습니다. 코드는 제가 설계한 대로 정확히 작동하고 있었거든요.
이 버그는 코드 한 줄이 아니라, 바로 '가정(assumption)' 속에 숨어 있었습니다.
제 코드는 "운영체제가 이 픽셀을 렌더링할 수 있다"는 것과 "사용자가 주의를 기울이고 있다"는 것을 무의식적으로 혼동하고 있었습니다. 결과적으로 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-17 02:01:49