이 글은 philipjkim 이 초안을 작성했으며, 이후 Claude Opus 4.6 을 이용한 퇴고를 거쳤습니다.

지난 2025년 8월, AI 코딩 시대의 그림자: LLM 의존이 개발자에게 미치는 잠재적 위험 5가지라는 글을 썼습니다. 당시 vibe-coding이라는 단어가 막 퍼지기 시작하던 때였고, AI 코딩 도구에 대한 기대와 우려가 공존하던 시기였습니다.

7개월이 흘렀습니다. 그 사이 Claude Code, Cursor, Windsurf 같은 AI 코딩 에이전트들은 단순한 코드 생성을 넘어 프로젝트 전체를 자율적으로 다루는 수준에 도달했습니다. 개발자들의 일상에서 AI agent 없이 코딩하는 시간은 점점 줄어들고 있고, 많은 팀에서 AI agent는 이미 팀원 한 명에 준하는 역할을 하고 있습니다.

이 글에서는 당시 제기했던 5가지 우려를 하나씩 다시 살펴보며, 여전히 유효한 것, 시간이 지나며 의미가 퇴색된 것, 그리고 새롭게 등장한 그림자 를 정리해 보겠습니다.

원래 5가지 우려, 지금은 어떤가#

1. 개발의 주도권 상실: ‘창작자’에서 ‘검수자’로 — ✅ 여전히 유효, 다만 양상이 변화#

당시 “개발자가 AI의 결과물을 수동적으로 검수하는 역할로 전락할 수 있다"고 우려했습니다. 이 우려는 여전히 유효합니다. 오히려 AI agent의 자율성이 높아지면서 주도권 상실의 양상이 더 미묘해졌습니다.

2025년 8월에는 개발자가 프롬프트를 주고 결과를 검수하는 비교적 단순한 흐름이었다면, 지금의 AI agent는 스스로 파일을 읽고, 테스트를 돌리고, 에러를 고치고, 다시 테스트하는 자율적 루프 를 돕니다. 개발자는 이 과정을 지켜보며 최종 결과만 승인하는 경우가 늘었습니다.

달라진 점도 있습니다. 숙련된 개발자들 사이에서는 AI를 효과적으로 지휘하는 것 자체가 하나의 핵심 역량으로 자리잡고 있습니다. 좋은 CLAUDE.md를 작성하고, 적절한 시점에 개입하며, AI의 방향을 교정하는 능력이 중요해졌죠. ‘검수자’라는 표현보다는 ‘지휘자(conductor)’ 라는 비유가 더 적절해 보입니다. 다만 이 역할 전환을 의식적으로 하지 않으면, 여전히 수동적 방관자로 전락할 위험은 남아 있습니다.

2. ‘마찰 없는 개발’이 부르는 번아웃의 가속화 — ✅ 여전히 유효, 더 심화#

이 우려는 7개월 전보다 더 현실적인 문제 가 되었습니다. AI agent의 속도가 빨라지면서 ‘기획-코딩-테스트’ 사이클은 더욱 압축되었고, 개발자가 쉬어갈 틈은 더 줄었습니다.

특히 agent가 자율적으로 작업하는 동안 개발자는 “기다리면서도 긴장하는” 독특한 피로를 경험합니다. agent가 올바른 방향으로 가고 있는지 모니터링해야 하고, 중간에 잘못된 길로 빠지면 빠르게 개입해야 하기 때문입니다. 이는 기존의 코딩 피로와는 질적으로 다른, 일종의 감시 피로(monitoring fatigue) 입니다.

또한 AI가 빠르게 결과물을 내놓으면서 “이 정도 속도면 더 많이 할 수 있지 않나?“라는 기대가 자연스럽게 형성됩니다. 개인 차원을 넘어 조직 차원에서도 AI 기반 생산성 기준선이 상향 조정 되면서, 개발자에게는 보이지 않는 압박이 가중되고 있습니다.

3. 핵심 역량의 약화와 ‘기초 없는 전문가’의 등장 — ✅ 여전히 유효, 양극화 심화#

이 문제는 7개월이 지난 지금 양극화 의 형태로 나타나고 있습니다.

한편에서는 AI를 활용해 자신의 학습 속도를 가속화하는 개발자들이 있습니다. AI에게 코드의 동작 원리를 설명해 달라고 하고, 여러 구현 방식을 비교 요청하며, 결과적으로 더 깊은 이해에 도달하는 경우입니다.

반대편에서는 AI가 내놓는 답을 검증 없이 그대로 사용하며, 기초적인 디버깅 능력이나 시스템 이해도가 정체된 개발자들이 늘고 있습니다. 특히 AI agent 시대에 개발을 시작한 신입 개발자들 중 일부는 에러 메시지를 읽는 법이나 로그를 추적하는 기본적인 습관이 형성되지 않은 경우도 관찰됩니다.

결국 이 문제의 핵심은 AI 도구 자체가 아니라, AI를 사용하는 태도와 의식 에 달려 있다는 것이 7개월간의 경험이 알려주는 교훈입니다.

4. 보이지 않는 품질 저하와 보안 취약점의 내재화 — ⚠️ 부분적으로 개선, 하지만 새로운 형태로 존재#

이 항목은 7개월 사이 가장 큰 변화가 있었던 영역입니다. 최신 AI 모델들의 코드 품질은 눈에 띄게 향상되었습니다. deprecated 라이브러리를 추천하는 빈도가 줄었고, 보안 관련 best practice를 자발적으로 적용하는 경우가 많아졌습니다.

그러나 완전히 해소된 것은 아닙니다. AI가 생성하는 코드의 품질이 올라간 만큼, 개발자의 검증 의지는 오히려 낮아지는 역설이 발생합니다. “이 정도 수준이면 괜찮겠지"라는 신뢰가 쌓이면서, 정작 AI가 실수하는 드문 케이스를 놓칠 확률 이 높아진 것입니다. 이는 자동화 편향(Automation Bias)이 모델 성능 향상과 함께 오히려 강화되는 아이러니한 상황입니다.

또한 AI agent가 자율적으로 여러 파일을 동시에 수정하는 환경에서는, 개별 코드 라인의 품질보다 변경 전체의 일관성과 의도 파악 이 더 큰 과제가 되었습니다. 한 번에 수십 개 파일이 변경되었을 때, 그 전체를 제대로 리뷰하는 것은 현실적으로 쉽지 않습니다.

5. 문제 해결 능력의 편향과 창의성의 저하 — ⚠️ 부분적으로 퇴색#

당시 “LLM이 가장 평균적이고 일반적인 해결책만 제시한다"고 우려했습니다. 이 부분은 7개월 사이 상당히 개선 되었습니다.

최신 모델들은 컨텍스트를 깊이 이해하고, 프로젝트의 기존 패턴을 존중하며, 때로는 개발자가 미처 생각하지 못한 접근법을 제안하기도 합니다. 충분한 컨텍스트와 잘 구성된 프롬프트를 제공하면, 획일적이지 않은 창의적인 솔루션을 얻을 수 있게 되었습니다.

다만 “AI가 제안하는 첫 번째 답변에 만족하게 될지 모른다” 는 우려는 여전히 유효합니다. AI의 답변 품질이 올라갈수록, 개발자가 대안을 탐색하려는 동기는 줄어들 수 있습니다. “충분히 좋은 답"이 즉시 나오는데 굳이 더 고민할 이유가 있을까? 이 유혹은 모델이 좋아질수록 더 강해집니다.

새롭게 등장한 그림자들#

7개월 전에는 미처 예상하지 못했던, 혹은 당시에는 미미했지만 이제는 무시할 수 없게 된 새로운 우려들이 있습니다.

6. 코드베이스의 비대화와 ‘이해 불가능한 코드’의 축적#

AI agent의 생산 속도가 빨라지면서, 코드베이스의 규모가 과거보다 훨씬 빠르게 커지고 있습니다. 문제는 이 코드들 중 상당수가 작성자(AI)도, 승인자(개발자)도 완전히 이해하지 못하는 상태 로 코드베이스에 편입된다는 점입니다.

AI가 생성한 코드는 동작은 하지만, 왜 그렇게 구현했는지에 대한 설계 의도(design rationale)가 부재한 경우가 많습니다. 이런 코드가 쌓이면 시간이 지날수록 유지보수 비용이 기하급수적으로 늘어나고, 특정 부분을 수정했을 때의 사이드 이펙트를 예측하기 어려워집니다. 아이러니하게도, 이 문제를 해결하기 위해 다시 AI에게 의존하게 되면서 이해 없는 수정의 악순환 이 만들어질 수 있습니다.

7. AI agent 간 ‘판단 충돌’과 일관성 문제#

팀 내에서 여러 개발자가 각자의 AI agent를 활용하는 환경이 보편화되면서, 서로 다른 agent가 내린 판단이 충돌하는 경우가 발생합니다.

같은 문제에 대해 A 개발자의 agent는 패턴 X를 적용하고, B 개발자의 agent는 패턴 Y를 적용합니다. 코드 리뷰에서 이를 조율하려 해도, 각각의 agent가 왜 그런 판단을 내렸는지 개발자 본인도 깊이 이해하지 못하는 경우가 생깁니다. 결과적으로 코드베이스의 일관성이 흔들리고, 리뷰의 질이 저하 되는 현상이 나타납니다.

이 문제에 대응하기 위해 팀 차원의 AI 사용 가이드라인(CLAUDE.md, .cursorrules 등)을 정비하는 움직임이 생기고 있지만, 아직 업계 전반의 표준으로 자리잡기에는 이른 상황입니다.

8. ‘설명 가능성’의 위기: 내 코드를 내가 설명 못하는 상황#

과거에는 자기가 작성한 코드에 대해 설명하는 것이 당연했습니다. 코드 리뷰에서, 장애 대응 시에, 혹은 온보딩 과정에서 “이 코드가 왜 이렇게 되어 있는지” 설명하는 것은 개발자의 기본적인 책임이었습니다.

하지만 AI agent가 작성하고 개발자가 승인한 코드의 비중이 높아지면서, 자기 이름으로 커밋된 코드를 제대로 설명하지 못하는 상황이 점점 흔해지고 있습니다. 이는 단순히 개인의 역량 문제를 넘어, 팀의 지식 공유와 장애 대응 능력에 직접적인 영향을 미칩니다. “이건 AI가 작성한 거라 저도 잘 모르겠습니다"라는 말이 익숙한 변명이 되어가는 현실은 우려스럽습니다.

정리#

# 우려 사항 7개월 전 현재 (2026년 3월)
1 개발 주도권 상실 우려 제기 ✅ 유효 — ‘검수자’에서 ‘지휘자’로 재정의 필요
2 번아웃 가속화 우려 제기 ✅ 유효 — 감시 피로라는 새로운 형태 추가
3 핵심 역량 약화 우려 제기 ✅ 유효 — 개발자 간 양극화 심화
4 품질/보안 취약점 우려 제기 ⚠️ 모델 개선으로 완화, 자동화 편향은 강화
5 창의성 저하 우려 제기 ⚠️ 모델 개선으로 부분 해소, 탐색 동기 저하는 지속
6 코드베이스 비대화 — 🆕 AI 생산 속도로 인한 새로운 과제
7 Agent 간 판단 충돌 — 🆕 팀 환경에서의 일관성 문제
8 설명 가능성 위기 — 🆕 내 코드를 내가 설명 못하는 상황

결론: 부조종사에서 편대 비행으로#

7개월 전, 저는 AI를 ‘유능한 부조종사(Copilot)‘로 활용해야 한다고 결론지었습니다. 그 생각은 크게 변하지 않았지만, 비유를 업데이트할 필요는 있어 보입니다.

지금의 AI agent는 단순한 부조종사가 아닙니다. 독립적으로 비행 경로를 계산하고, 자율적으로 항로를 수정하며, 때로는 기장보다 빠른 판단을 내리는 존재입니다. 이제 개발자와 AI의 관계는 기장-부조종사라기보다, 편대 비행(formation flight) 에 가깝습니다. 각자의 기체를 몰면서, 같은 목적지를 향해, 서로의 위치를 확인하며 나아가는 형태입니다.

이 편대 비행을 안전하게 수행하기 위해 개발자에게는 몇 가지가 필요합니다:

  • 메타 인지: AI가 무엇을 잘하고 무엇을 못하는지, 지금 이 순간 AI의 판단을 신뢰해도 되는지 판단하는 능력
  • 의도적 마찰: AI의 속도에 휩쓸리지 않고, 의식적으로 멈춰서 생각하는 습관
  • 설명 책임: 코드의 작성자가 누구든, 그것을 이해하고 설명할 수 있는 상태를 유지하는 것
  • 팀 차원의 규율: AI 사용에 대한 팀 가이드라인과 코드 리뷰 기준의 재정립

AI 코딩 시대의 그림자는 7개월 전보다 옅어진 부분도 있고, 더 짙어진 부분도 있습니다. 확실한 것은, 이 그림자를 인식하고 대비하는 개발자와 그렇지 않은 개발자 사이의 격차가 점점 벌어지고 있다는 점입니다. 도구는 더 강력해졌고, 그만큼 그것을 다루는 사람의 태도가 더 중요해졌습니다.