아니요, AI는 코딩하지 않아요. 그리고 반대라고 말하는 사람들은 허풍을 팔고 있습니다.

Source: Dev.to

몇 주 전, *“전문가”*가 “Gemini 3 Pro가 자동화를 혁신한다” 그리고 “AI 에이전트가 이미 완전한 애플리케이션을 구축한다” 라고 주장하는 또 하나의 영상을 본 뒤, 나는 믿을 수 없음과 분노가 뒤섞인 감정을 느꼈다.

실제 프로젝트 경험이 부족함이 권위로 가장되어 시작하는 사람들의 판단을 흐리게 만드는 것을 보며 분노했다.

1. 실제 테스트

나는 그들 중 아무도 하지 않는 일을 하기로 했다: 실제 테스트. 10개의 파일로 된 장난감 저장소나 간단한 API가 아니라 구체적인 통합 문제로:

• 목표: LSP4J를 사용하여 MCP 서버를 jdt‑ls에 연결하기.
• 초기 접근: 다른 것을 통합하지 않고 500줄 미만의 독립형 Java 클래스를 생성하기.
• 결과: 이 최소 테스트조차도 통과하지 못했다.

평가된 모델들

전체 결과: 8개의 모델, 성공 0건. 어느 모델도 작동하는 코드를 생성하지 못했으며; 여러 모델이 컴파일 오류를 수정하는 루프에 빠졌고, 내가 직접 수정 사항을 알려줘야 코드를 컴파일할 수 있었다.

2. 컨텍스트의 현실

비디오에서는 여전히 “백만 토큰 저장소를 처리합니다!”라고 약속합니다. 인상적이지만… 실제 프로젝트를 열어보면 상황이 다릅니다.

전문 애플리케이션의 단일 모듈만으로도 시장 최첨단 컨텍스트 용량을 150 % 초과합니다. AI가 “당신의 저장소를 이해한다”고 약속할 때, 실제로는 극히 작은 부분집합만을 이해하고, 시스템 현실의 흐릿하고 잘린 사진만을 보는 것입니다.

3. 데모 vs. 실제 프로그래밍

전형적인 데모들을 보았다:

• “React로 TODO 앱 만들기”.
• “그래프가 있는 대시보드 만들기”.

이는 IKEA 가구 조립과 같은 디지털 비유이다: 모든 부품이 명확한 매뉴얼과 함께 있지만, 결국 가구처럼 보이는 무언가가 되지만… 기대한 대로 작동하지 않는다.

실제 프로그래밍은 조립식 부품을 조립하는 것이 아니다. 그것은:

• 왜 한 구조를 다른 구조보다 선택했는지 이유를 아는 것.
• 시스템이 자체 무게 때문에 무너지지 않도록 보장하는 것, 이는 몇 개월 혹은 몇 년간의 운영을 의미한다.

실제 문제(예: LSP 같은 프로토콜 통합, 비동기 상태 관리, jdt‑ls의 특정 설정 처리)를 LLM에 주면, LLM은 무너진다. 시스템에 대한 정신 모델이 없고, 토큰 통계만 가지고 있다.

“그것은 프로그래밍이 아니다. Java 코드처럼 보이는 텍스트를 생성하는 것이다”.

AI가 할 수 없는 것

• 문제 있는 코드를 감지한다.
• 몇 개월 혹은 몇 년 뒤의 결과를 예측한다.
• 팀과 희생에 대해 논의한다.
• 다른 시스템과의 호환성을 유지한다.

4. 과대광고의 결과

가장 심각한 피해는 기술 과잉 판매가 아니라, 오늘날 산업에 진입하려는 프로그래머들이 겪는 지적 사보타주이다.

• 주니어는 “전도사”들이 다음과 같이 말하는 것을 본다:

  “언어를 배우는 데 시간을 낭비하지 말고, 기계에게 올바른 방식으로 요청하는 법을 배우라”.

  “박사 수준의 추론 능력”을 가진 LLM, “당신의 의도를 이해하는 Vibe Coding”이라는 약속과 함께…

• 주니어는 알고리즘이나 아키텍처를 배울 필요가 있나고 스스로 묻는다. 기계가 “이미 해버리니”…

• 기준 없이 중요한 작업을 확률 상자에 위임하고 있다는 사실이 감춰지고 있다. 그 상자는 심지어 자신의 메모리에도 들어가지 못한다.

5. 이 호출은 누구를 위한 것인가?

콘텐츠 제작자

• 헛소문을 그만 팔라. AI를 가르치고 싶다면 그 한계를 가르쳐라.
• 기계적인 작업이나 반복적인 코드, 리팩토링에 도움이 된다는 것을 보여주되, 문제 이해를 대체해서는 안 된다.

주니어

• 기본을 배우라. AI는 숙련된 장인의 손에 있는 강력한 도구다.
• 초보자의 손에 들어가면, 공기 망치처럼 만지는 모든 것을 파괴할 수 있다.

나

• 앞으로도 이와 같은 글을 쓰며, 코드(가능할 때)와 실제 오류를 보여줘서 과대광고와 현실 사이의 격차를 드러내겠다.

6. 추가 일화

한 가지 의문이 나를 따라다녔다: 문제가 Java가 아니라 복잡성 자체였다면 어떨까?

며칠 후, 나는 11월 말에 우리에게 일어난 일을 떠올렸다…

Contexto: 동료와 나는 회사의 웹 애플리케이션을 손봐야 했다. 이 애플리케이션은 50 000줄이 넘는 JavaScript와 TypeScript로 된 frontend를 가지고 있다.
Nuestro perfil: Java 아키텍트; React는 이름만 알았다.
Promesa de la IA: Gemini CLI를 사용해 무엇을 바꿔야 하는지 설명하고 코드를 생성하도록 했다.
Resultado: 설명은 일관됐고 코드는 구문적으로 완벽했지만… 조용히 실패했다.

7. 결론

AI는 코딩하지 않는다.
프로그래머가 코딩한다.
다른 사람들은 데모를 만든다.

만약 “구루”가 다시 AI가 코딩한다는 말을 하면, 나는 실패한 여덟 번의 시도를 증거로 보낼 것이다. 고쳐볼 용기가 있는지 보자.

이 글은 며칠 전에 게시할 준비가 되어 있었다. 하지만 여전히 생각한다: 도구의 진정한 시험은 복잡하고 실제적인 문제에 대한 성능이며, 깔끔한 데모가 아니다.

배운 교훈 (stale closure)

Gemini는 useCallback에 의존성을 선언하는 것을 잊었습니다. 상태 변화를 감지하지 못하는 함수를 작성했습니다. 우리는 그것을 고치지 못했고, 그래서 AI에게 React 철학, 훅, 그리고 closures에 대해 요약해 달라고 요청했습니다. 우리는 읽고 이해했으며 문제점을 지적했습니다. AI가 수정했지만, 주니어 수준의 실수를 저질러서 우리가 다시 고쳐야 했습니다.

현실

• Java를 모르는 것이 아니다.
• 복잡성이 실제일 때 —비동기 상태, 복잡한 생명주기 또는 실시간 시스템과의 통합— 언어와 관계없이 실패한다.
• AI는 정신 모델이 없으며; 단지 확률일 뿐이다.
• 실제 프로젝트에서는 그 비용이 디버깅 시간으로 지불된다.