# AI 코딩 보조 도구가 점점 나빠지고 있는가? > Clean Markdown view of GeekNews topic #25695. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25695](https://news.hada.io/topic?id=25695) - GeekNews Markdown: [https://news.hada.io/topic/25695.md](https://news.hada.io/topic/25695.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-10T01:33:46+09:00 - Updated: 2026-01-10T01:33:46+09:00 - Original source: [spectrum.ieee.org](https://spectrum.ieee.org/ai-coding-degrades) - Points: 10 - Comments: 1 ## Summary AI 코딩 보조 도구의 **품질 저하**가 가시화되며, 최신 모델일수록 실행은 되지만 결과가 틀린 ‘조용한 실패’가 늘어나고 있습니다. 이는 사용자 수용 여부를 학습 신호로 삼는 과정에서 “실행만 되면 좋은 코드”라는 왜곡된 기준이 강화된 결과로 보입니다. 단기적 효율보다 **전문가 검증과 고품질 데이터 확보**에 집중하지 않으면, 모델이 스스로의 오류를 학습하는 악순환이 심화될 수 있습니다. ## Topic Body - 최근 **AI 코딩 보조 도구의 전반적인 품질 저하**가 나타나며, 작업 속도와 결과 정확도가 이전보다 나빠지는 흐름 - 최신 **대형 언어 모델(LLM)** 은 문법 오류를 줄이는 대신, 실행은 되지만 결과가 틀린 **조용한 실패(silent failure)** 를 더 자주 만들어냄 - 실험에서 **GPT-5**는 오류 원인을 드러내지 않고 값을 만들어내는 방식으로 문제를 덮는 반면, **GPT-4**와 **Claude 구버전**은 데이터나 코드 자체의 문제를 비교적 명확히 노출함 - 이런 변화는 **사용자 수용 여부를 학습 신호로 삼는 과정에서 데이터 품질이 흐려진 결과**와 맞물려 있음 - 단기적인 실행 성공보다 **고품질 데이터와 전문가 검증**에 투자하지 않으면, 모델이 스스로 만든 오류를 다시 학습하는 악순환에 빠질 위험이 커짐 --- ### AI 코딩 보조 도구의 성능 저하 현상 - 최근 몇 달 사이 AI 코딩 보조 도구의 **작업 효율과 코드 신뢰도 동반 하락** - 과거 AI 보조로 5시간 걸리던 작업이 이제는 7~8시간 이상 소요되는 경우 증가 - 일부 사용자는 안정성을 이유로 **이전 세대 LLM을 다시 선택** - AI 생성 코드를 **사람 개입 없이 실행하는 테스트 환경**에서 이러한 변화가 반복적으로 관찰됨 ### 새로운 모델에서 두드러진 ‘조용한 실패’ - 과거 문제는 주로 **문법 오류나 명확한 논리 오류**로, 실행 단계에서 즉시 드러났음 - 최신 모델은 **겉보기에는 정상 실행되지만 의미가 틀린 코드**를 생성하는 경향 강화 - 안전 검사 제거 - 출력 형식만 맞춘 가짜 값 생성 - 이런 **은밀한 오류**는 발견이 늦어지고, 이후 단계에서 더 큰 비용과 혼란으로 이어짐 - 현대 프로그래밍 언어가 **빠르게, 명확하게 실패하도록 설계된 이유**와 정면으로 충돌함 ### 단순 테스트에서 드러난 차이 - 존재하지 않는 컬럼을 참조하는 Python 코드 오류를 여러 ChatGPT 버전에 제시 - **GPT-4**: 오류 원인을 지적하거나 디버깅을 유도하는 응답이 대부분 - **GPT-4.1**: 데이터프레임 컬럼을 출력해 문제를 확인하도록 유도 - **GPT-5**: 실제 인덱스를 사용해 계산을 수행하며 코드 실행 성공을 가장, 결과는 의미 없는 값 생성 - **Claude 모델**에서도 유사한 흐름 확인 - 구버전은 문제 인식 중심 - 신버전은 오류를 무시하거나 우회하는 해결책 제시 ### 학습 방식과 품질 저하의 연결 - 초기 모델은 대량의 기존 코드 학습 중심으로, 오류는 많았지만 **문제 자체를 숨기지는 않음** - 이후 IDE 통합과 함께 **사용자 행동(코드 수락·실행 성공 여부)** 이 학습 신호로 활용됨 - 초보 사용자 증가로 인해, **실행만 되면 좋은 코드로 간주되는 신호**가 축적되며 모델이 이를 학 - 결과적으로 **안전 검사 제거, 가짜 데이터 생성** 같은 부정확한 패턴이 강화 - 자동화된 코딩 기능이 늘수록 인간 검증이 줄어들어, **모델이 잘못된 학습을 반복**하게 됨 ### 앞으로 필요한 방향 - AI 코딩 보조 도구는 여전히 **개발 생산성과 접근성을 크게 높이는 도구** - 그러나 실행 성공 위주의 학습은 **장기적으로 코드 품질을 훼손**시킴 - **전문가가 라벨링한 고품질 데이터 확보**와 **책임 있는 재학습 과정**이 필수 - 그렇지 않으면 모델은 **잘못된 출력 → 잘못된 학습 → 더 나쁜 출력**의 순환 구조에 빠질 가능성이 큼 ## Comments ### Comment 48975 - Author: neo - Created: 2026-01-10T01:33:46+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46542036) - AI 열성가들이 자신의 **생산성 향상**을 이야기할 때는 주관적 경험에 의존하면서, 반대 의견에는 과도한 **증명 책임**을 요구하는 게 흥미로움 - 예전에 LinkedIn에서 “AI로 업무 속도가 10배 빨라졌다”는 글을 본 적이 있음 작성자는 실제로 **라이브 스트리밍 시연**을 예고했는데, 결과적으로 단순한 확장 작업 하나를 한 시간 동안 마치지 못했음 내가 직접 손으로 했어도 비슷한 시간이 걸렸을 것 같았음 그래서 댓글로 “10배 향상은 어디 있냐”고 물었더니, 그는 “잠깐의 오류였다”거나 “AI가 답하는 동안 다른 일을 할 수 있었다”는 식으로 부정함 솔직히 처음엔 회의적이었지만, 내 회의가 틀렸길 바랐음. 하지만 아니었음 - 이런 주장은 반박이 불가능함. “비밀 워크플로우”가 있다거나 “너는 제대로 못 쓰고 있다”는 식으로 회피함 결국 **생산성 향상 주장에 대한 증명 책임**은 전적으로 주장자에게 있음 - 나는 전문 프로그래머는 아니지만, **AI를 반복 작업 제거용 도구**로 쓰면 큰 효율을 얻을 수 있다고 느낌 AI가 독창적 사고를 할 수 있다고는 생각하지 않음. 대신 **탭 자동완성** 기능이 루프나 에러 처리, 문서화 등에서 시간을 많이 절약해줌 문제 해결 자체의 속도는 그대로지만, 구현 단계에서는 확실히 빨라짐 즉, “10배 향상”이라면 문제 해결이 아니라 **타이핑 속도**의 10배 향상임 - 내 경우 최근 몇 달 사이 AI가 훨씬 나아졌음. **계획 모드**에서 작업을 세분화하고 실행–검증–테스트–리뷰–배포를 반복함 C# 기반의 100만 줄짜리 프로젝트에서도 품질 저하 없이 생산성이 크게 향상됨 비판적인 사람들에게는 “직접 보여달라”고 말하고 싶음. 비밀 기술이 아니라, 단지 **도구를 다루는 법을 익히는 데 시간**이 걸렸을 뿐임 - 1년 넘게 이런 “나는 AI로 10배 빨라졌다”는 글을 계속 봐왔음 그런데 왜 그들은 자신이 만든 놀라운 결과물을 보여주지 않고, 굳이 나를 설득하려 드는 걸까? 혹시 **보상이나 인센티브**가 있는 건 아닌지 의심스러움 - 문제는 AI가 나빠진 게 아니라 **결과의 재현성**이 떨어진다는 점임 택시 호출, 배달 앱처럼 LLM 생태계도 결국 **가격 인상 구조**로 갈 것 같음. 지금은 투자금으로 **보조금 상태**일 뿐임 - 택시 요금은 연료비 등으로 하한선이 있지만, **추론 비용(inference cost)** 은 계속 떨어지고 있음 지금은 보조금 덕에 싸지만, 곧 **보조금 없이도 저렴**해질 가능성이 높음 다만 최신 모델(SOTA)을 쓰려면 더 비싸질 수 있음. 하지만 그건 가치가 다른 문제임 - 직접 모델을 **로컬에서 실행**해보면 “보조금 덕분”이라는 말은 틀렸음을 알 수 있음 1~2만 달러면 하루 종일 토큰을 생성할 수 있는 머신을 만들 수 있고, 대규모 사업자는 **규모의 경제**로 더 효율적으로 운영함 - 어떤 모델은 여전히 **기본적인 사실 오류**를 냄. 예를 들어 iOS 26이 존재하는데도 “그건 iOS 16을 말한 거겠죠?”라고 답함 이런 부분은 여전히 신뢰하기 어려움 - 그래서 나는 지금 **보조금 시대가 끝나기 전** 최대한 많이 만들어두려 함. 나중에 비용이 오를 테니까 - 지금의 낮은 가격은 **지속 불가능한 과도기적 상태**라고 생각함 투자금이 끊기면 결국 가격이 오르고, 경쟁이 사라진 뒤에야 **진짜 비용 구조**가 드러날 것임 - 어떤 사용자는 “AI가 나빠졌다”는 테스트가 이상하다고 봄 예를 들어 존재하지 않는 컬럼을 참조하는 코드에서 “주석 없이 완성된 코드만 내라”고 하면, AI는 어쩔 수 없이 **잘못된 코드**를 낼 수밖에 없음 - 이런 **불가능한 프롬프트**를 그대로 따르는 건 오히려 퇴보라고 생각함 유능한 개발자라면 “이건 잘못된 요청”이라고 지적해야 함. 이 테스트는 **아첨형 응답(sycophantism)** 을 드러내는 유효한 실험임 - 실제 개발에서는 이런 상황이 자주 생김. AI든 사람이든, **데이터 형식이 기대와 다를 때**는 알려줘야 함 그냥 조용히 잘못된 결과를 내는 건 위험함 - 이런 경우 “유능하지 못한 개발자”처럼 **피드백을 거부하는 AI**로 보임 - 사실 대부분의 코딩 에이전트는 “index_value 컬럼이 없으니 df.index를 써야 한다”고 말할 수 있음 이런 오류는 GPT-2 수준의 **환각(hallucination)** 에 가까움 - 나는 AI 개발 보조 도구를 좋아하지만, 그게 항상 **절대적 이득**인지는 모르겠음 예전에 점심 시간을 줄이려고 Huel을 먹었는데, 결국 **휴식의 가치**를 잃어버린 것처럼 AI도 세부 사항을 놓치면 오히려 **되돌아가야 하는 시간**이 생김 - 가장 어려운 건 AI에게 **정확히 원하는 걸 설명하는 일**임 그래서 나는 프로젝트의 모든 맥락과 제약을 담은 **15k 토큰짜리 마크다운 파일**을 만들어 매번 프롬프트에 넣음 일종의 “세계 모델” 문서임 - 나도 Huel과 AI 둘 다 써봤는데, 정말 비슷한 경험이었음 - 생산성 향상 논리는 결국 **기대치의 재조정**으로 상쇄됨 얻은 시간만큼 더 많은 일을 하게 되고, **자기 효능감**과 **문제 해결 능력**이 약화됨 이런 “비효율성”이 사실은 **지식과 통찰을 얻는 과정**이었다는 걸 잊기 쉬움 AI의 생산성 향상은 실제 **운영 비용**과 비교해보면 과대평가된 것일 수도 있음 - 어떤 댓글은 이런 논의가 **은근한 광고처럼 보인다**고 느꼈음 - IEEE에서 기술 논문을 기대했는데, 이번 글은 **의견글(opinion piece)** 수준이라 아쉬웠음 - 사실 AI 찬양 글들도 대부분 **근거 없는 경험담**에 불과함. 직접 써보기 전엔 모름 - 이건 [IEEE Spectrum](https://en.wikipedia.org/wiki/IEEE_Spectrum) 잡지의 가벼운 콘텐츠임 - 나도 ieee.org 도메인을 보고 **엄밀한 연구글**을 기대했음 - 예시가 OpenAI 모델에만 국한되어 있는데, 제목은 전체 모델을 일반화함 GPT-5가 문제 해결에만 집중하고 **큰 그림을 못 본다**는 점은 동의하지만, 다른 모델은 여전히 잘함 - OpenAI는 Ilya가 떠난 뒤 **새로운 학습(run)** 을 성공적으로 하지 못했다는 말도 있음 나는 개인적으로 **Gemini-3-flash**와 커스텀 Copilot 대체 확장을 쓰는데, 훨씬 유용하고 **개인화된 개발 경험**을 줌 - 최근 Cursor가 무한 루프처럼 `grep`, `cd`, `ls`를 반복하는 걸 봤음 너무 많은 “vibe coder”를 겨냥해 기능을 과하게 넣은 듯함. 오히려 **가벼운 버전**이 더 다루기 쉬웠음 - “실행 실패”가 꼭 나쁜 신호는 아님 때로는 그게 **가장 근접한 정답**이거나, **버그를 찾는 단서**가 될 수 있음 단, 실행을 위해 **검증 로직을 제거하거나 의미를 바꾸는 것**은 최악의 결과임 - LLM이 인터넷의 모든 정보를 **소모한 뒤**엔 어떻게 될까 궁금함 Stack Overflow나 오픈소스 코드가 사라지면, 결국 **자기 자신을 학습하다 붕괴(model collapse)** 하지 않을까? - [Model collapse](https://en.wikipedia.org/wiki/Model_collapse)는 실제 연구된 개념임 하지만 현실 규모의 데이터에서는 위험이 크지 않다고 보는 연구자도 많음 최근 **NVIDIA Nemotron 3 Nano** 모델의 33%는 **합성 데이터(synthetic data)** 로 학습됨 - AlphaZero처럼 AI가 **스스로 프로젝트를 생성하고 유지보수**하는 방향으로 발전할 수도 있음 유지보수 용이성 같은 **가치 함수**를 포함해 시뮬레이션을 돌릴 수 있음 - 하지만 AI가 만든 **환각 데이터**를 다시 학습하면 품질이 점점 떨어질 수 있음 AI가 스스로 오류를 인식하지 못하면 **자기 붕괴**가 일어날 가능성이 있음 - 결국 **공유의 시대가 끝나고**, 폐쇄적인 소규모 협업으로 바뀔 것 같음 “sharing is caring” 인터넷은 사라질지도 모름 - 아마도 앞으로는 **LLM 등장 이전의 인터넷 스냅샷**만으로 학습하고, 추가 데이터는 **인간이 큐레이션**할 것임 - AI는 나빠진 게 아니라, **좋아졌는데 사용법이 달라졌을 뿐**임 제대로 된 **스캐폴딩(scaffolding)** 을 갖추면 훨씬 좋은 결과를 얻을 수 있음 단순한 테스트로 “AI가 멍청하다”고 결론내리는 건 오류임 - “그럼 결국 ‘너는 잘못 쓰고 있다’는 말이잖아?”라는 반응도 있었음 - 하지만 **스캐폴딩이 필요하다는 점 자체가 문제**라는 의견도 있음 예를 들어 “12월 매출”을 물으면, 대부분의 모델이 연도 조건 없이 모든 12월을 합산함 이런 **논리적 오류**가 실제 업무에서 문제를 일으킴 - **깨끗한 코드와 명확한 커뮤니케이션**을 하는 개발자일수록 LLM을 잘 다룸 기술 어휘력과 표현력이 성능에 영향을 주는 듯함 - 이런 글들은 일종의 “**Look Ma, I made the AI fail!** ”식 콘텐츠로 보임 - 하지만 “스캐폴딩을 알아야 한다”는 말은 결국 일반 사용자에게는 **장벽**이 된다는 지적도 있음 - 나도 모델의 **월별 품질 변동**을 느꼈음 예전엔 잘하던 **에러 처리나 변수명 규칙**을 잊은 듯 보임 대화가 길어질수록 품질이 떨어지는 경우도 있음. **프롬프트 길이의 최적점**이 있는 듯함 - GitHub Copilot 문서([링크](https://docs.github.com/en/copilot/concepts/prompting/prompt-engineering))에 따르면, 새 작업은 **새 스레드로 시작**하고, 불필요한 요청은 삭제하는 게 좋다고 함 - 결국 대화 전체가 하나의 **쿼리**이므로, 길어질수록 AI가 **맥락을 올바르게 해석할 능력**에 의존하게 됨