이 기사에 대하여

AI 코딩 도구에 대해서는, "개발이 근본적으로 변했다"라는 열광과 "실제로는 별로 효과가 없다"라는 회의론이 동시에 유통되고 있습니다. 까다로운 점은 양쪽 진영 모두 그럴듯한 수치를 가지고 있다는 것입니다.

이에 본 기사에서는, 도구를 판매하는 벤더로부터 독립된 실증 연구(RCT·대규모 조사·피어 리뷰 논문)를 최우선으로 수집하여, 반증을 포함해 횡단적으로 정리했습니다. 정보원은 다음 3가지로 구분하며, 어떤 수치가 어떤 입장에서 나왔는지를 항상 구분합니다.

Tier1— 벤더로부터 독립된 실증 (RCT·대규모 조사·피어 리뷰 논문·체계적 문헌 고찰) -
Tier2— 도구 제공 벤더의 1차 발신 (사내 연구·자사 조사 포함) -
Tier3— 실무자의 논고·현장의 증언 (실증은 아니지만, 연구 지견이 현장에서 재현되는지 확인하기 위한 대조 자료)

참고로 "그렇다면 어떻게 사용하는 것이 좋은가"라는 테크닉 측면의 정리는 이전에 별도의 기사(AI-Assisted SWE — 실무 지견의 추출)로 정리했습니다. 본 기사는 그 전 단계인 "애초에 효과가 있는가, 무엇을 희생하고 있는가"를 다룹니다.

결론 (중심 명제)

AI 코딩의 효과는 일률적인 플러스가 아니다. 태스크(Task)·코드베이스(Codebase)·경험·사용 방식이라는 문맥에 강하게 의존하는 조건부 효과이다. 그리고 당사자는 그 효과를 체감만으로 올바르게 평가할 수 없다.

"빨라진 것 같다"는 실측치와 어긋난다 — 이것이 이번 횡단 정리에서 가장 반복적으로 나타난 지견입니다. 이 결론은 여러 독립적인 연구 팀과 39건의 1차 연구를 통합한 선행 체계적 문헌 고찰(Mohamed et al. 2026, arXiv:2507.03156)이 각각 독립적으로 도달한 결과입니다.

이하, 7가지 축으로 나누어 근거를 제시합니다.

1. 생산성은 문맥에 따라 부호가 반전된다

동일한 무작위 대조 시험 (RCT)이라도 결과의 부호가 반대로 나타납니다.

METR의 RCT: 22,000 star·100만 행 이상의 성숙한 OSS에서 평균 5년의 경험을 가진 개발자는 AI 사용 시 완료 시간이 +19% (느려짐). n=16, 246개 과제. (METR, 2025-07) -
Google 사내 RCT: 기업 내 태스크에서 AI 기능으로 인해 소요 시간 약 −21% (빠름). 단, 저자는 신뢰 구간이 크다고 명시. (arXiv:2410.12944) -
GitHub Copilot 실험: JavaScript로 HTTP 서버를 신규 구현하는 단순 태스크에서는 −55.8% (완료자 70명, 신규·단순 태스크 한정). (arXiv:2302.06590) -
Microsoft 직장 RCT "Dear Diary": 3주간의 도입에서는 유의미한 생산성 향상을 검출하지 못함 (저자는 숙련 기간 부족 = 검출력 부족 가능성을 명시). (arXiv:2410.18334) -
개발자 415명의 서베이: 생산성 향상 보고는 주관적이며, SPACE 프레임워크의 객관적 차원은 중립적임. (The Fast and Spurious, arXiv:2510.24265)

물어야 할 것은 "AI는 빠른가"가 아니라 "어떤 문맥에서 빠른가"입니다. 신규·단순·익숙하지 않은 영역에서는 빨라지기 쉽습니다. 반면, 성숙한 대규모 코드베이스를 숙지한 사람이 사용할 경우, AI 출력물의 검증 비용이 이득을 상쇄할 수 있습니다. 선행 체계적 문헌 고찰도 "고립된 명확한 태스크에서는 양호하지만, 복잡하고 문맥이 짙은 프로젝트에서는 고전한다"라는 취지로 설명합니다.

2. 개인의 속도 향상은 조직의 성과로 직결되지 않는다

개인의 생산성과 팀·조직의 딜리버리(Delivery)는 별개의 것이었습니다.

DORA 2024: AI 채택이 25% 증가할 때마다, 딜리버리 처리량(Throughput) 추정치 −1.5%, 딜리버리 안정성 −7.2%. 원인은 변경 세트(Batch)의 대형화. (DORA 2024) -
DORA 2025: 처리량은 플러스로 전환되었으나, 안정성은 여전히 마이너스. (DORA 2025) -
Faros AI (22,000명의 개발자 텔레메트리): 개인의 산출(태스크 완료 +33.7% 등)은 늘어나는 반면, PR 사이즈 +51%·리뷰 시간 중앙값 5배·운영 인시던트(Incident) 3배. 조직의 DORA 지표는 개선되지 않음. (Faros AI)

개인의 속도 향상은 리뷰 부하, 인시던트(Incident), 코드 차언(Code Churn)과 같은 하류 비용으로 전가되는 경향이 있습니다. DORA는 이를 "AI는 증폭기(강한 팀은 더 강하게, 약한 팀은 약함이 증폭된다)"라고 표현하고 있으며, 독립적인 텔레메트리(Telemetry)가 이를 뒷받침하는 형태입니다. 참고로 DORA와 Faros의 결과 모두 상관관계일 뿐 인과관계의 증명은 아닙니다.

3. 품질·보안 — 얕은 오류는 줄어들고, 깊은 결함은 남는다

NYU 「Asleep at the Keyboard」 (IEEE S&P 2022, 피어 리뷰): Copilot 생성 코드의 약 40%가 취약함 (유도된 시나리오). (논문)

Wuhan 대 (ACM TOSEM, 피어 리뷰): 실제 GitHub 프로젝트 상의 Copilot 생성 코드 중 27.3%에 취약성 존재. (arXiv:2310.02059)

Stanford의 RCT (CCS 2023, 피어 리뷰): AI 어시스턴트 이용 그룹은 유의미하게 안전하지 않은 코드를 작성함 (SQL 인젝션에 취약한 구현 36% vs 대조군 7% 등). (arXiv:2211.03622)

반대 방향의 데이터도 있습니다. **대규모 분석 (피어 리뷰 전)**에서는 AI 귀속 파일의 87.9%가 취약성 없음으로 나타났으며, 언어별 차이가 큽니다. (arXiv:2510.26103)

Apiiro (보안 벤더): 구문 오류(Syntax Error)는 -76%로 감소하지만, 권한 상승 경로 +322% 등, 얕은 오류는 줄어들고 깊은 구조적 결함은 늘어남. (Apiiro)

주의할 점은, NYU와 Stanford의 결과 모두 2021년 세대의 오래된 모델을 대상으로 한 것이므로, 취약성 비율의 구체적인 수치를 현행 모델에 일반화할 수는 없다는 것입니다. 다만 "얕은 오류는 줄어들고, 깊은 결함(설계·권한·유지보수성)은 줄어들지 않거나 늘어날 수 있다"는 방향성은 피어 리뷰 연구와 벤더 측정치를 통틀어 일관되게 나타납니다. 체계적 문헌 고찰(Systematic Review) 또한 "품질이 개선될지 악화될지는 문맥과 평가 기준에 따라 다르며 미해결 상태"라고 결론짓고 있어, 단정적인 판단은 피해야 할 영역입니다.

4. 채택은 보편화되었으나, 신뢰는 따라오지 못하고 있다

Stack Overflow 2025: 이용(의향 포함) 84% 대비, 정확도에 대한 불신 46% > 신뢰 33%. 주요 불만 사항은 "거의 맞지만 미묘하게 다름" 66%, 디버깅 시간 증가 45.2%. (SO Survey 2025)

DORA 2025: 채택률 90%. 단, 저신뢰 30% > 고신뢰 24%.

JetBrains 2025 (n=24,534): 일상적 이용 85%이나 워크플로우로의 완전한 통합은 드묾. (JetBrains)

벤더 자체 조사(GitHub: 이용 92%·속도 향상 체감 55% 등)는 독립 조사보다 긍정적인 수치가 일관되게 높게 나타납니다. (GitHub)

"사용하고 있는가"는 이제 논점이 아닙니다. 신뢰 결여의 핵심은 "거의 맞지만 미묘하게 다른" 출력물의 검증 비용이며, 이는 제1절(검증 비용이 이득을 상쇄함) 및 제2절(리뷰 부하로의 전가)에서 다룬 것과 동일한 현상의 다른 측면입니다. 벤더 조사와 독립 조사의 괴리 자체가 정보원을 계층별(Tier)로 나누어 읽어야 할 필요성을 입증하는 증거이기도 합니다.

5. 학습 능력이 퇴화할 수 있다

Anthropic의 RCT (n=52, 주로 주니어): 미지의 라이브러리를 배우는 상황에서, AI 보조 그룹은 학습 후 퀴즈 점수가 17포인트 낮았습니다 (50% vs 67%). 다만 사용 방식에 따라 결과가 갈렸는데, AI에게 개념을 질문하거나 설명을 요구한 그룹은 유지율 65% 이상이었으나, 코드를 통째로 맡긴 그룹은 40% 미만이었습니다. (Anthropic. 벤더 주도의 연구라는 점은 감안하여 읽어야 함)

Stanford의 RCT에서도, 헬퍼 함수(Helper function)를 제공하는 등 공을 들인 프롬프트를 사용한 사람일수록 더 안전한 코드에 도달했습니다.

체계적 문헌 고찰 (Systematic Review): 주니어는 즉각적인 혜택도 크지만, 과의존과 장기적인 기술 침식의 리스크도 큽니다. 전문가는 선택적으로 사용하여 지속적인 효율을 얻습니다. 즉, 숙련도가 효과를 강력하게 좌우합니다.

Auckland 대의 종단 연구 (Longitudinal Study) (n=95, 6개월, 피어 리뷰 전): 생산성 체감은 유지되는 반면, 개발자 경험(Developer Experience)이 악화된 비율은 **14% → 27%**로 두 배 증가했습니다. 업무의 중심이 "코드를 작성하는 것"에서 "AI 출력을 검증하고 감독하는 것"으로 이동하고 있습니다. (arXiv:2605.23135)

「사용하느냐 마느냐」보다 「어떻게 사용하는가」가 학습 성과를 좌우합니다. 통째로 맡겨버리는 것은 개념 정착을 해치지만, 개념을 질문하고 검증을 거치는 방식의 사용은 학습을 보호합니다. 또한, 연 단위의 장기적인 기술 침식(skill erosion)을 측정한 데이터는 분야 전체적으로 아직 존재하지 않습니다(최장 6개월).

6. 「체감」은 신뢰할 수 없다

본 기사에서 실무상 가장 중요한, 횡단적인 발견입니다.

METR: 실측은 **−19%(느려짐)**임에도 불구하고, 개발자들은 사전에 「24% 빨라질 것」이라고 예측했으며, 사후에도 「20% 빨라졌다」고 믿고 있었다. -
Stanford: 안전하지 않은 코드를 작성한 사람일수록, 「자신은 안전하게 작성했다」고 잘못 믿고 있었다. -
Microsoft Research (CHI 2025, n=319): AI에 대한 신뢰가 높은 사람일수록, 비판적 사고(critical thinking)가 줄어들고 있었다. (Microsoft)

생산성이든 보안이든, 당사자의 체감은 실측과 괴리가 있으며, 심지어 「잘 되었다」는 방향으로 과신합니다. 항공·의료 분야에서 알려진 자동화 편향 (automation bias, Parasuraman & Manzey 2010)의 소프트웨어 버전이라고 할 수 있습니다. 「AI를 도입했더니 빨라진 것 같다」를 의사결정의 근거로 삼아서는 안 됩니다.

7. 벤치마크의 높은 점수도 맹신할 수 없다

Waterloo 대 (Preprint): SWE-bench Verified는 훈련 데이터의 혼입(contamination)으로 인해 「능력」이 아니라 「기억」을 측정하고 있을 가능성이 있음. 오염을 제외한 데이터에서는 성능이 급격히 저하됨. (arXiv:2512.10218) -
SWE-Bench+: 해결 성공으로 간주된 issue의 32.67%에서, 해답이 issue의 기술 내용이나 코멘트에 유출되어 있었음. (arXiv:2410.06992)

모델의 진보 자체를 부정하는 것은 아니지만, 벤치마크 점수의 상승을 실무 능력의 상승으로 액면 그대로 받아들일 수는 없습니다.

8. 현장의 분위기는 어떠한가

지금까지의 연구 지견(Tier 1/2)을 현장 엔지니어의 실무 논고(Tier 3)와 대조해 봅니다. 실무자 논고는 경험과 의견일 뿐 실증은 아닙니다. 목적은 「연구의 경향이 현장의 분위기로 뒷받침되는가, 아니면 반증되는가」를 확인하는 것입니다.

영어권: 열광파와 회의파는 사실 거의 같은 말을 하고 있다.

AI 코딩에 열광적인 논자(Simon Willison, Armin Ronacher, Kent Beck)와 회의적인 논자(Addy Osmani, Thoughtworks Böckeler, Gergely Orosz)는 다음 지점에서 수렴합니다.

• 효과는 경험자일수록 크다 (AI는 기존의 숙련도를 증폭시킨다) — 제1절과 일치
• 출력물의 검증·리뷰가 업무의 본체가 되며, 책임은 인간에게 남는다 — 제5절과 일치
• 개인의 산출물이 늘어나도 제품 품질·팀 성과는 자동으로 개선되지 않는다 (Osmani의 「70% 문제」, Orosz가 보고하는 「메트릭 목표를 위한 토큰 늘리기」) — 제2절과 일치

정면으로 충돌하는 것은 「실제로 얼마나 효과가 있는가」에 대한 자기 평가뿐입니다. 그리고 제6절에서 보았듯이, 자기 보고는 과신하는 쪽으로 치우친다는 것이 실측으로 증명되었습니다. 즉, 열광파와 회의파의 유일한 대립점 자체가 「체감은 신뢰할 수 없다」는 본 기사의 핵심 명제를 뒷받침하고 있습니다.

일본: Findy의 자체 실측이 해외의 통설과 다르다.

Findy 사의 자체 실험(CTO 발신 note)에서는, AI 도입 후 시니어의 PR 수가 +37%(320→438)인 반면, 주니어는 −35%(220→142)였으며, 전사의 아웃풋 총량은 보합세였습니다. 해외의 현장 실험(field experiment)에서는 「젊을수록 혜택이 크다」고 여겨지는 경우가 많아, 정면으로 모순됩니다. 단일 조직·PR 수라는 거친 지표이므로 일반화할 수는 없지만, 「기초 지식과 환경 정비라는 맥락이 효과의 부호를 반전시킨다」는 제1절·제5절의 지견이 일본 현장에서 나타난 실례로 읽힙니다.

일본의 논고에는 영어권에는 없는 고유한 논점도 포함되어 있습니다. 수탁·맨먼스(man-month) 모델과의 상성, 레거시 코드의 암묵지(tacit knowledge)의 무게(Zenn), 젊은 층의 기초 회귀론(엔지니어 type의 「동작 ≠ 사양 적합」, 「체험 ≠ 경험」), 사양의 표준화를 통해 조직 성과로 연결하려는 Mercari의 ASDD(직원 95% 이용·스피드 +64%로 보고되나 측정 정의는 비공개) 등입니다.

9. 한 명의 엔지니어로서 어떻게 받아들일 것인가

이상의 지견으로부터 개인으로서 오늘부터 사용할 수 있는 시사점을 끌어내면 다음과 같습니다.

• 자신의 체감을 의사결정의 근거로 삼지 말 것. "빨라진 것 같다"는 느낌은 METR의 피실험자들도 느꼈던 부분입니다. 효과를 알고 싶다면, 착수~머지(Merge)까지의 실제 시간, 리뷰 지적 수 등 자신의 외부에 있는 숫자로 측정하세요.
• 문맥에 따라 구분하여 사용할 것. 신규·단순·익숙하지 않은 영역(프로토타입, 미지의 언어나 API, 일회성 스크립트)은 AI의 특기 분야입니다. 자신이 숙지하고 있는 성숙한 코드베이스(Codebase)의 깊은 변경 사항에 대해서는 검증 비용과 항상 저울질해야 합니다.
• 통째로 맡기기와 상담을 구분할 것. 배우고 싶은 영역에서는 코드를 쓰게 하는 것이 아니라 개념을 질문하거나 설명하게 하세요. 코드를 쓰게 할 때도 검증 과정을 거쳐야 합니다. 이 차이가 학습 유지율(65% vs 40%)과 코드의 안전성 모두를 갈랐습니다.
• 검증과 감독이야말로 길러야 할 스킬. 얕은 오류는 AI가 제거해 주지만, 깊은 결함(설계·권한·유지보수성)을 찾아내는 것은 인간의 업무로 남아 있습니다. 리뷰 능력, 테스트 설계, 사양을 언어화하는 능력의 가치는 오히려 높아집니다.
• 자신의 산출물 증가가 팀에 무엇을 전달하고 있는지 볼 것. PR(Pull Request)을 크고 많게 만드는 것에 그친다면, 비용을 리뷰어와 미래의 유지보수자에게 전가한 것일지도 모릅니다. 배치를 작게 유지하는 규율은 AI 시대에 더욱 효과적입니다.
• 도구의 광고와 벤치마크를 맹신하지 말 것. 벤더(Vendor) 조사는 독립 조사보다 일관되게 낙관적이며, 벤치마크에는 오염이 존재합니다. 도구 교체나 세대 업데이트는 자신의 실제 태스크(Task)에서 시험해 보고 판단하세요.
• (주니어·익숙하지 않은 영역에서는) 즉각적인 효과 뒤의 비용을 알 것. Findy의 주니어 -35% 결과와 Anthropic의 학습 RCT는 같은 방향을 가리키고 있습니다. 기초가 없는 영역에서 AI에 의존할수록 단기적인 출력도 장기적인 성장도 해칠 수 있습니다.

이 기사의 한계

• 상관관계 ≠ 인과관계: DORA / Faros / GitClear / Apiiro 등은 상관관계, 자기 보고, 자사 텔레메트리(Telemetry)가 많으며, 인과관계를 증명하는 것은 아닙니다.
• 모델이 오래된 연구가 있음: Stanford·NYU 연구는 2021년 세대 모델의 결과입니다. 수치의 크기를 현행 모델로 일반화할 수 없습니다 (인간 측의 과신 구조는 비교적 모델 비의존적이라고 생각되지만, 이는 해석입니다).
• 장기 데이터가 없음: 년 단위의 스킬 침식이나 기술 부채(Technical Debt)의 축적을 측정한 연구는 분야 전체적으로 아직 존재하지 않습니다.
• 실무자 논고는 실증이 아님: 제8절의 Tier3 정보는 경험과 의견입니다. Findy의 실측도 단일 조직의 사례입니다.
• 실증 연구는 영어권 중심: 일본 국내에는 자사 실측이나 실무 논고는 있으나, 통제된 독립 실증 연구는 찾아볼 수 없었습니다.

또한, 숫자의 근거를 확인하는 과정에서 인터넷상에서 자주 인용되는 다음 두 가지는 1차 자료까지 거슬러 올라가 확인되지 않았습니다. 본 기사에서는 사용하지 않았습니다.

• "DORA 2025: 60%가 배포 후 AI 관련 오류를 발견" → 1차 자료에서 발견되지 않음 (오귀속 의심)
• "Veracode: AI 코드는 인간 대비 2.74배의 취약성" → 다른 조사(CodeRabbit)와 혼동. Veracode의 1차 자료는 "AI 생성 코드의 45%가 보안 검사 불합격"

요약

• AI 코딩이 효과가 있는지는 문맥에 따라 다름. 신규·단순·미숙한 영역은 빠르지만, 성숙한 대규모×숙련 영역은 오히려 느려질 수 있습니다. 일본에서는 Findy의 실측이 "기초가 없는 주니어는 오히려 저하됨"을 보여주며 문맥 의존성을 더욱 강조합니다.
• 개인의 속도 향상은 하류 비용(리뷰·인시던트·유지보수성)으로 전가되기 쉬우며, 조직의 성과로 직결되지 않습니다. 이 점은 열광파와 회의파 실무자 모두 일치하는 부분입니다.
• "빨라진 것 같다"는 믿을 수 없음. 감각이 아니라 실측으로 측정하세요. 사용 방식(통째로 맡길 것인가, 검증을 거칠 것인가)이 학습과 품질 모두를 좌우합니다.

"그렇다면 어떻게 사용할 것인가"에 대한 설계 원칙·테크닉 모음은 자매편인 [AI-Assisted SWE — 실무 지견의 추출]을 참조해 주세요. 본 기사의 지견을 토대로 한다면, 해당 편의 원칙(컨텍스트 설계, Explore→Plan→Code, Writer/Reviewer 분리 등)은 "효과를 조건부로 이끌어내고 하류 비용을 억제하기 위한 기법"으로 다시 읽을 수 있습니다.

참고 문헌

성질에 따라 3개 티어(Tier)로 나누어 기재합니다 (Tier1 = 벤더로부터 독립된 실증, Tier2 = 도구 제공 벤더의 1차 발신·사내 연구, Tier3 = 실무자 논고).

독립 실증 (Tier1)

독립 실증 (Tier1)

• METR (2025)
  Measuring the Impact of Early-2025 AI on Experienced OSS Developer Productivity— https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ (arXiv:2507.09089) - Perry et al. (CCS 2023)
  Do Users Write More Insecure Code with AI Assistants?— https://arxiv.org/abs/2211.03622 - Pearce et al. (IEEE S&P 2022)
  Asleep at the Keyboard?— https://dl.acm.org/doi/10.1145/3610721 - Fu et al. (ACM TOSEM)
  Security Weaknesses of Copilot-Generated Code in GitHub Projects— https://arxiv.org/html/2310.02059v3 - DORA (2024/2025)
  State of AI-assisted Software Development— https://dora.dev/research/2025/dora-report/ ※발행원은 Google로 AI 벤더이기도 하지만, 업계 전반 조사로서 Tier1 취급 - Stack Overflow (2025)
  Developer Survey — AI— https://survey.stackoverflow.co/2025/ai -
  The Fast and Spurious(2025) — https://arxiv.org/html/2510.24265v2 - Mohamed et al. (2026)
  The Impact of LLM-Assistants on SW Developer Productivity: A Systematic Review— https://arxiv.org/abs/2507.03156 - Waterloo (2025)
  Does SWE-Bench-Verified Test Agent Ability or Model Memory?— https://arxiv.org/html/2512.10218v1 - Aleithan et al. (2024)
  SWE-Bench+— https://arxiv.org/html/2410.06992 - Schreiber & Tippe (2025, 심사 전)
  Security Vulnerabilities in AI-Generated Code: Large-Scale Analysis— https://arxiv.org/abs/2510.26103 - Parasuraman & Manzey (2010)
  Complacency and Bias in Human Use of Automation— https://journals.sagepub.com/doi/10.1177/0018720810376055

벤더 1차 정보・사내 연구 (Tier2. 판매하는 쪽·만드는 쪽의 발신임을 염두에 두고 읽을 것)

• Google (2024)
  AI가 개발 속도에 얼마나 영향을 미치는가? (사내 RCT) — https://arxiv.org/abs/2410.12944 - Microsoft (2024)
  Dear Diary (직장 RCT) — https://arxiv.org/html/2410.18334v1 - Peng et al. / GitHub (2023)
  AI가 개발자 생산성에 미치는 영향 (Copilot 실험) — https://arxiv.org/abs/2302.06590 - Anthropic (2026)
  AI 보조가 코딩 기술 형성에 미치는 영향 — https://www.anthropic.com/research/AI-assistance-coding-skills - Lee et al. / Microsoft Research (CHI 2025)
  생성형 AI가 비판적 사고에 미치는 영향 — https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking.../ - Faros AI
  가속도 채찍질 (Acceleration Whiplash) (자사 텔레메트리) — https://www.faros.ai/research/ai-acceleration-whiplash - GitClear
  AI Copilot 코드 품질 (자사 측정·인과 통제 없음) — https://www.gitclear.com/ai_assistant_code_quality_2025_research - Apiiro
  4배의 속도, 10배의 취약점 (보안 벤더) — https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/ - Auckland 대학교 (2026, 심사 전)
  AI 코딩 보조 도구가 소프트웨어 공학(SE)에 미치는 영향: 종단적 연구 — https://arxiv.org/html/2605.23135v1 - JetBrains (2025)
  개발자 생태계 현황 — https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/ - GitHub
  설문 조사로 밝혀진 AI가 개발자 경험에 미치는 영향 — https://github.blog/news-insights/research/survey-reveals-ais-impact-on-the-developer-experience/

실무자 논고・국내 정보 (Tier3)

• Addy Osmani
  70% 문제 — https://addyo.substack.com/p/the-70-problem-hard-truths-about - Simon Willison
  바이브 엔지니어링 (Vibe engineering) — https://simonwillison.net/2025/Oct/7/vibe-engineering/ - Kent Beck

바이브의 한 해 (A Year of Vibes) — https://lucumr.pocoo.org/2025/12/22/a-year-of-vibes/ - Birgitta Böckeler (Thoughtworks)
코딩 보조 도구는 페어 프로그래밍 (Pair programming)을 대체하지 않는다 — https://martinfowler.com/articles/exploring-gen-ai/05-not-your-pair-programmer.html - Gergely Orosz

생성형 AI로 향상되지 않은 개발 조직의 생산성— https://note.com/yuichiro826/n/n285026b11564 - 엔지니어type (grasys 하세가와)
「그럴싸하게 동작하는 코드」가 커리어를 저해— https://type.jp/et/feature/28271/ - 엔지니어type (Mercari 키무라 토시야)
AI-Native 개발 / ASDD— https://type.jp/et/feature/29747/

Discussion