어쩌면 ‘IDE’라는 용어가 올바르지 않을 수도 있습니다. [Cursor]는 모듈형으로 훨씬 빠른 새로운 개발 환경의 일환입니다. 이 환경은 텍스트 편집기와 ‘언어 서버’ 부분으로 구성됩니다. 언어 서버는 서버처럼 작동하며 비동기적으로 실행됩니다. 이는 텍스트 편집기를 차단하지 않으므로 텍스트 편집기가 매우 빠르게 실행될 수 있습니다. 따라서 이들을 ‘모듈형 개발 환경’ 또는 MDE라고 부르는 것이 좋을지도 모릅니다.
어쩌면 그렇게 새로운 것도 아닐 수 있습니다. IDE 자체는 원조 모듈형 개발 환경인 Visual Studio Code의 포크에 불과합니다. 사실, Cursor는 VS Code에 비해 그렇게 많은 기능을 추가하지는 않습니다. 추가된 유일한 주목할 만한 기능은 AI입니다. 또한 이 포스트를 연구하면서 구글이 저에게 이렇게 말했습니다:
아니요, Cursor는 단순히 Visual Studio Code(VS Code)와 AI의 조합이 아니라, AI를 중심으로 구축된 VS Code의 독립적인 포크입니다.
VS Code와 AI의 조합인 것 같습니다. VS Code 확장 기능과도 호환됩니다. 그래서 제가 가장 궁금한 점은: 왜 Cursor가 독립 프로그램인가요? 그냥 VS Code 확장 기능으로 만들면 안 되는 건가요? GitHub Copilot은 그렇게 하고 있습니다.
아, Copilot은 숨겨진 API를 사용하고 있습니다.
그래서 Cursor도 그렇게 한 것입니다. 만약 Cursor와 GitHub Copilot이 정상적으로 개발을 계속했다면 큰 이야기가 되지 않았을 것입니다. 하지만 VS Code를 Copilot에 더 집중하려는 경향이 점점 커지고 있는 것 같습니다.
저는 이 영상을 본 후에 처음으로 그 점을 눈치챘습니다:
이 비디오는 VS Code의 10월 업데이트에 대해 논의하며, 이 업데이트가 Copilot에 관한 것이고 GitHub에 대해서도 조금 이야기합니다. GitHub는 Copilot을 만들었고, 또한 Microsoft 소속입니다. “Embrace Extend Extinguish”라는 말이 괜찮나요?
솔직히 말씀드리자면, VS Code 업데이트에는 Copilot과 관련이 없는 새로운 기능도 많이 있습니다. 주로 아이콘들입니다. 하지만 Copilot이 VS Code에 얼마나 깊숙이 침투했는지는 걱정스럽습니다. 특히 VS Code는 모듈형으로 설계되어야 하니까요. 모든 중대한 IDE 작업은 언어 서버를 통해 이루어지며, 이는 별도의 프로세스입니다. 그래서 속도가 빠릅니다. 이렇게 Copilot 전용 코드를 VS Code에 통합하는 것은 잘못된 것처럼 느껴집니다.
특히 제가 AI 코딩의 큰 팬이 아니라는 점에서 더욱 그렇습니다. AI와 함께 코딩은 하지만, 이는 제가 너무 게을러서 작성하지 않거나 잘 모르는 것들에 해당합니다. LLM과 함께 작성하는 코드의 양과 복잡성이 증가함에 따라 미세한 버그를 유발할 위험도 함께 증가합니다.
또한 제가 이전에 주장했던 바와 같이, LLM이 도입할 수 있는 이러한 숨겨진 버그들은 많은 시간을 낭비하게 만들 수 있습니다. 그 포스트에서는 이것들이 개발자를 -10배 생산성이 떨어지는 개발자로 만들 수 있다고 이야기했습니다.
LLM의 디버깅 능력도 한계가 있습니다:
LLM으로 코드를 디버깅하려고 할 때마다 이런 점이 드러납니다. LLM은 스스로 생각하지 않고, 어디선가 찾은 정보를 단순히 되풀이하며 “이걸 시도해 보셨나요?”라고 말합니다. 하지만 그 ‘이것’은 현재 제가 하고 있는 일과 관련이 없고 도움이 되지 않을 가능성이 큽니다. LLM은 문제가 발생하는 이유를 이해하지 못하고, 역사적으로 관련된 문제에서 효과가 있었던 해결책을 적용하려고만 합니다. 결국, 이렇게 하면 계속해서 같은 문제를 반복하게 됩니다.
기억하시나요? 세계를 뒤흔들 것이라던 ‘AI 소프트웨어 엔지니어’ Devin? 결과적으로 그건 세계를 뒤흔들지 않았고, 완전한 사기였습니다. 아마도 ‘사기’라는 표현은 너무 강한 단어일지도 모르겠습니다. 과대 광고가 심했지만 실질적으로는 부족했습니다. 많은 다른 ‘AI 프로그래밍 기능’들과 마찬가지로요. OpenAI의 Canvas와 Copilot처럼요:
많은 개발자들이 AI 코딩 도우미가 생산성을 높여준다고 말하지만, 최근 연구에 따르면 그들의 성과는 크게 향상되지 않았습니다. GitHub Copilot의 사용으로 버그가 41% 더 증가했다고 합니다. 이는 코딩 및 협업 데이터에서 통찰력을 제공하는 회사인 Uplevel의 연구 결과입니다.
그럼에도 불구하고 사람들은 계속해서 AI 프로그래밍 기능에 투자하고 있습니다. 이전에는 “AI 도구에 신경 쓰지 마세요. 그냥 사용하지 않으면 됩니다.”라고 생각했었습니다. 이는 Flutter에 관한 최근 포스트에서도 논의한 내용입니다:
처음에는 Foundations에 대해 큰 의미를 느끼지 못했습니다. 당신의 회사가 재단에 의해 운영되든 대기업에 의해 운영되든 신경 쓰지 않거든요. 시장이 잘 돌아가는 한요. 하지만 최근 소프트웨어 개발 분야에서 많은 혼란을 보았습니다. 사람들은 좌우로 해고당하고 있습니다. Flutter 팀도 최근에 약간의 문제를 겪었습니다. 하지만 피해의 정도는 잘 모르겠습니다.
다른 회사에 속해 운영될 때, GitHub 같은 경우 Microsoft 안에 있기 때문에 관리자의 의도에 따라 결정됩니다. 이는 Flutter의 경우 나쁜 결과를 초래할 수 있지만, Copilot의 경우 좋은 결과를 가져올 수도 있습니다. 문제는 Copilot이 받는 주목이 다른 코딩 도구들로부터 자원을 빼앗아 가고 있다는 점입니다. 이는 최근의 Visual Studio Code 업데이트에서 볼 수 있습니다.
이 Visual Studio Code 업데이트가 고립된 사건이기를 바라지만, 그렇지 않은 것처럼 보입니다. Copilot이 계속해서 프로그래밍의 다른 영역에서 자원을 빼앗아 갈 것 같습니다.
그리고 이는 Visual Studio Code에만 국한되지 않습니다. Google의 도구에 얼마나 많은 Gemini가 통합되고 있는지 보셨나요? 이는 정말 터무니없습니다. 저는 Gemini가 Firebase 같은 다른 Google 프로젝트에서 자원을 빼앗기 시작하고 있다고 의심합니다. 아마도 그 때문에 Flutter가 더 잘 되지 못하는 것일지도 모릅니다. 그들은 AI에 시간을 낭비하고 있습니다.
게다가 프로그래머의 기술은 감소하고 있습니다. 이는 제가 꽤 오랫동안 두려워했던 일이었고, 이제 그 두려움이 현실이 되어가는 것 같습니다. 많은 ‘선임 개발자’들이 말하듯이, 만약 당신이 적극적으로 코딩하지 않거나 코딩을 덜 한다면, 당신의 기술은 퇴화하고 있는 것입니다.
AI 코딩 도구에 대한 과도한 의존은 위험합니다. 또한 교활하게 다가옵니다. 이러한 도구들이 해롭다는 수많은 연구가 있음에도 불구하고 사람들이 계속해서 의존하는 이유는 무엇일까요? 사람들은 일을 싫어합니다. 따라서 AI 코딩이 가장 해로운 분야는 도구 개발도, 현재 프로그래머도 아닌 교육 분야라는 것은 의심의 여지가 없습니다.
AI 도구들이 학생들을 게으르게 만들고 아무것도 배우지 못하게 한다고 주장하는 글들이 여러 편 있었습니다. 예를 들어 이 글에서처럼요:
최근 직장에서 저는 기술 대학의 박사 과정 학생들에게 학술 작문을 가르쳤습니다. 저의 대학원생들은 많은 경우 컴퓨터 과학 전공자였으며, 생성형 AI의 메커니즘을 저보다 더 잘 이해하고 있었습니다. 그들은 LLM이 신뢰할 수 없는 연구 도구라는 것을 인식하고, 허위 정보를 생성하고 인용을 만들어낸다는 것을 알고 있었습니다. 또한, 그들은 이 기술의 환경적 영향과 윤리적 문제를 인식하고 있었습니다. 그들은 모델이 기존 데이터를 기반으로 훈련되기 때문에 새로운 연구를 생산할 수 없다는 것을 알고 있었습니다. 그러나 그러한 지식이 그들이 생성형 AI에 의존하는 것을 막지는 못했습니다. 몇몇 학생들은 연구를 메모 형식으로 작성하고 ChatGPT에게 기사를 작성해달라고 요청했다고 인정했습니다.
경험이 풍부한 교사로서 저는 교육학의 최선의 실천을 잘 알고 있습니다. 저는 과제를 체계적으로 구성했습니다. 수업 계획에 생성형 AI를 통합할 방법을 연구하였고, 그 한계를 강조하기 위한 활동을 설계했습니다. 저는 학생들에게 ChatGPT가 수정 요청을 받을 때 텍스트의 의미를 변경할 수 있으며, 편향적이고 부정확한 정보를 제공할 수 있고, 스타일적으로 강한 글을 생성하지 않으며, 성적 지향적인 학생들에게는 A 수준의 결과를 낳지 않는다는 것을 상기시켰습니다. 그러나 그건 중요하지 않았습니다. 학생들은 여전히 그것을 사용했습니다.
또한 이 글에서도 언급되었습니다:
A. 지팡이를 사용하는 것은 위험한 접근 방식입니다. 왜냐하면 지팡이를 사용하면 사고를 멈추게 되기 때문입니다. AI를 지팡이로 사용하는 학생들은 아무것도 배우지 못합니다. 그것은 그들이 사고하는 것을 방해합니다. 대신 AI를 공동 지능으로 사용하는 것이 중요합니다. 이는 능력을 증가시키고 또한 상황을 파악하는 데 도움이 됩니다.
말은 쉽지만 실천하기는 어렵습니다. 우리가 보았듯이 아무리 경고를 하더라도 사람들이 AI를 사용하는 방식은 변하지 않을 것입니다. 그들은 AI에 과도하게 의존할 것이며, 이는 사람들에게 교육의 기회를 빼앗을 것입니다.
하지만 저는 AI에 대해 부정적인 것만은 아닙니다. AI 코딩이 몇 가지를 개선할 수 있다고 생각하며, 다양한 패키지를 사용하는 방법에 대해 많은 것을 배웠습니다. 얼마 전 ChatGPT는 저에게 Go의 GoQuerry를 사용하여 Dart의 HTML 패키지처럼 HTML을 구문 분석하는 방법을 가르쳐주었습니다. 이는 저에게 엄청난 유지 관리의 이점이 되었으며, 이제 Go와 Dart 코드가 서로 전혀 닮지 않았음에도 불구하고 기능적으로 거의 일치하도록 만들 수 있습니다.
문제는 AI를 적절하지 않은 곳에 억지로 끼워 넣으려 할 때 발생합니다. 해리 포터 영화 중 하나에서 덤블도어는 모든 사람이 옳은 것과 쉬운 것 중에서 선택해야 한다고 말합니다. 그가 맞습니다. AI 코딩은 쉽습니다. 하지만 그것이 옳은 것일까요? 때로는 그렇습니다. 하지만 대다수의 경우 AI 코딩은 도움이 되기보다 더 해롭습니다.
제가 보기에는 이러한 상황이 해롭기만 한 경우가 점점 더 많아지고 있습니다. 우리는 AI 도구에 만성적으로 과도하게 의존하고 있으며, 동시에 기업들은 정확성을 희생하면서 편리함을 위해 모든 개발을 AI 도구 생성에 쏟고 있습니다.
제가 생각하기에, 지금보다 더 많은 경우에 AI가 코딩을 죽이고 있습니다.