개발자여, AI에 대한 반감에 빠지지 마세요 (진짜 위험은 다른 데 있습니다)

소프트웨어 개발 커뮤니티를 조금만 둘러봐도 요즘 분위기가 심상치 않습니다. “AI 코딩은 뻥이다”, “이거 곧 다 꺼질 거품이다”, “난 끝까지 사람이 치는 코드만 쓴다” 같은 반(反) AI 정서가 눈에 띄게 늘었습니다.

하지만 여기서 한 번 숨 고르고 생각해볼 필요가 있습니다. AI가 마음에 들지 않든, 윤리적으로 불편하든, 코드를 망치든… 상관없이 LLM(대형 언어 모델)은 이미 소프트웨어 개발을 구조적으로 바꿔놓기 시작했기 때문입니다.

이 글에서는 다음 이야기를 다룹니다.

왜 “AI는 곧 끝난다”는 믿음이 커리어 리스크가 될 수 있는지
지금 AI 코딩이 가진 현실적인 문제와 한계
그럼에도 불구하고 이 흐름이 장기적으로는 왜 “민주화”로 이어질 가능성이 큰지
개인 개발자가 반(反) AI 정서에 빠지지 않으면서도, 건강하게 AI를 다루는 실전 전략

편하게 앉아서, 한 번 끝까지 같이 정리해보죠.

Generated image

1. 지금 개발자 사이에서 벌어지는 ‘반(反) AI’ 현상

지금 전 세계 개발자 커뮤니티를 요약하면 딱 이 한 문장으로 설명됩니다.

“AI 코딩은 어디에나 있지만, 마음 편히 믿는 사람은 별로 없다.”¹

MIT Technology Review가 30명 이상의 개발자와 기술 리더들을 인터뷰한 결과, 많은 개발자들이 처음에는 “와, 이거 혁신이다!”라고 시작했다가, 시간이 지날수록 실망과 피로감을 느끼고 있습니다¹.

이들이 공통적으로 말하는 불만은 비슷합니다.

실제로 써보면 생각만큼 생산성이 안 오른다
장점은 있는데, 품질·보안·유지보수 비용을 생각하면 애매하다
회사는 “AI 써서 속도 올려라”를 강요하는데, 책임은 결국 사람이 진다

연구 결과도 이를 뒷받침합니다. 어떤 비영리 연구에서는 경험 많은 개발자들이 “AI 덕분에 20%는 빨라졌다”고 느꼈지만, 실제로는 19% 더 느려졌다는 결과가 나왔습니다¹. 심리적으로 빨라진 것 같을 뿐, 실제 작업 시간은 오히려 늘어난 셈입니다.

이러니 반감이 생길 수밖에 없습니다. 게다가, 취준생과 주니어 개발자 입장에서는 상황이 더 살벌합니다.

“AI가 평균적인 주니어 개발자보다 코딩을 잘한다. 이제 주니어는 필요 없다”는 말을 공공연히 하는 CEO들²
스탠퍼드 같은 최상위 학교 CS 전공자조차, 예전만큼 개발 직군에 쉽게 취업하지 못하는 현실²

현장에서 느끼는 박탈감, 불안, 분노가 “반 AI 정서”라는 형태로 터져 나오고 있는 겁니다.

하지만 여기서 중요한 질문이 하나 있습니다.

“AI가 싫다고, 이 흐름이 사라질까?”

2. “AI는 곧 꺼질 거품”이라고 믿는 게 위험한 진짜 이유

“이건 그냥 닷컴 버블 같은 유행이다” “AI 회사들 적자 심하고, 주가 떨어지면 끝이야”

이렇게 생각하면 마음이 편해질 수 있습니다. 하지만 커리어 관점에서 보면, 이건 꽤 위험한 베팅입니다.

2-1. 투자 사이클은 변덕스러워도, 기술 자체는 남는다

닷컴 버블을 떠올려봅시다. 수많은 인터넷 기업이 망했지만, 인터넷 자체가 사라지진 않았습니다. 오히려 거품이 꺼진 뒤에, “인터넷을 제대로 활용할 줄 아는 사람과 회사”가 승자가 됐습니다.

AI도 비슷한 길을 걷고 있습니다.

LLM 성능은 여전히 꾸준히 향상되고 있고³⁴
학습 비용도 초기 생각보다 훨씬 낮은 수준으로 떨어지고 있으며³
오픈소스 모델과 도구 생태계가 빠르게 확장되고 있습니다³⁵

즉, 몇몇 AI 회사의 재무 상태는 흔들려도, LLM을 활용한 개발 방식이라는 흐름 자체는 이미 되돌리기 어렵다는 겁니다.

2-2. Salvatore Sanfilippo가 말한 “영구적인 변화”

Redis로 유명한 Salvatore Sanfilippo는 이런 취지의 이야기를 했습니다.

프로그래밍은 AI 때문에 한 번 바뀌고 끝나는 게 아니라, 영구적으로 다른 게임이 되었다.

포인트는 이겁니다.

예전: “코드를 빨리, 정확히 많이 치는 능력”이 큰 경쟁력
앞으로: “AI를 활용해 시스템을 설계하고, 검증하고, 조합하고, 유지하는 능력”이 더 중요

코드를 잘 치는 것만으로는 부족해지고, “코드를 잘 치는 AI를 어떻게 잘 다루느냐”가 경쟁력이 됩니다.

이 변화를 “인정하지 않겠다”고 버티는 건, 마치 2000년대에 “웹은 금방 사라질 거야”라고 믿던 개발자와 비슷한 포지션이 됩니다.

2-3. “나는 그냥 AI 안 쓰고도 잘 먹고살래”의 함정

단호한 사람들도 있습니다.

“나는 AI 안 쓰는 회사만 골라서 갈 거다.” “내 코드에 AI 흔적 한 줄도 안 남길 거다.”

가능합니다. 실제로 이런 회사를 찾을 수도 있습니다. 문제는 선택지가 점점 줄어들 가능성입니다.

이미 많은 기업들이 다음을 기대하고 있습니다.

개발자는 AI를 기본 도구로 쓴다
코드 리뷰·테스트·문서화에도 LLM이 관여한다
“AI를 못 쓰는 사람”은 “Google 검색도 못하는 사람”처럼 취급된다

이 상황에서 “나는 끝까지 안 쓸 거야”는, 경력 후반으로 갈수록 협상력이 떨어지는 선택이 될 가능성이 큽니다.

3. 인정할 건 인정하자: AI 코딩의 진짜 문제들

여기까지 읽고 “그러니까 AI 찬양하자는 거냐?” 라고 느꼈다면, 아닙니다. AI에 반감을 느끼게 만드는 현실적인 이유들은 충분히 설득력이 있고, 무시해서도 안 됩니다.

3-1. 속도는 조금 빨라졌지만, 품질은 확실히 더 나빠졌다

여러 분석에 따르면, AI 덕분에 개발자가 작성하는 “지워지지 않고 남는 코드”는 약 10% 정도 늘었지만, 그와 동시에 코드 품질 지표는 여러 면에서 떨어졌다는 결과가 있습니다¹.

또 다른 분석에서는, AI를 활용한 코드 PR이 사람만 작성한 PR보다 문제(이슈) 수가 1.7배 많고, 특히 치명적인 문제 비율이 더 높았다고 합니다⁶.

이 연구에서 특히 많이 지적된 문제는 다음과 같습니다⁶.

비즈니스 로직 오류
잘못된 의존성, 흐름 제어 문제
예외 처리 누락, 널 체크 부족
보안 취약점 (비밀번호 처리, 객체 접근 등)
팀 컨벤션을 무시한 코드 스타일

한마디로 말하면,

AI는 겉으로는 그럴듯한 코드를 잘 만들어주지만, “유지보수하기 좋은 코드”를 만들기는 아직 서툴다는 겁니다.

3-2. “체감상” 빠른 것과 “실제로” 빠른 건 다르다

실제 개발자들이 느끼는 건 이렇습니다.

빈 파일에 뭔가를 처음 써 넣을 때 → AI가 짜준 코드로 시작하면 훨씬 편하다
익숙하지 않은 라이브러리 쓸 때 → 예제 코드 뽑아주는 건 꽤 도움 된다
테스트 코드, 보일러플레이트 → 정말 귀찮은 걸 대신해주니 좋다

그래서 대부분 “체감상 생산성이 오른 것 같다”고 말합니다. 하지만 실제로 시간을 재보면, 복잡한 작업에서는 AI 때문에 오히려 더 느려지는 경우도 적지 않습니다¹.

왜냐하면,

AI가 짜준 코드를 이해하는 데도 시간이 들고
눈에 안 보이는 버그를 잡느라 더 오래 디버깅할 수도 있고
팀 컨벤션과 맞게 수정하는 데 손이 많이 가기 때문입니다.

그래서 요즘 나오는 연구들은 비슷한 결론을 냅니다.

“AI 코딩 도구는 특정 유형의 작업에서는 분명 도움이 되지만, 개발 전체를 통틀어 ‘마법 같은 생산성 폭증’이 일어났다고 보기는 어렵다.”¹⁶

3-3. 신뢰·보안·의존성: 개발자들이 불안해하는 포인트

개발자들이 AI를 꺼리는 이유는 속도와 품질만이 아닙니다.

“AI 코드가 라이선스 문제를 일으키지 않을까?”
“보안 구멍이 생겨도 내가 다 책임져야 하나?”
“AI에 너무 의존하면, 나중에 내 사고력·실력이 떨어지는 거 아닌가?”

실제로 산업 현장 설문조사를 보면, LLM에 대해 개발자들이 느끼는 대표적인 불안은 다음과 같습니다⁷.

도구에 과하게 의존하게 되는 인지적 의존성
보안 리스크
기술적 자율성과 실력 저하

그러니까, AI가 싫은 감정 자체는 아주 건강한 “방어 기제”일 수도 있습니다. 문제는 여기서 “그럼 난 그냥 안 쓸래”로 끝내느냐, 아니면 “이 위험을 인지한 상태에서 어떻게 활용할까?”로 넘어가느냐입니다.

4. 그럼에도 AI를 포기하면 안 되는 이유: ‘민주화’의 재현

여기까지는 “AI가 생각보다 별로다” 쪽의 이야기였습니다. 그런데 동시에 다른 방향의 큰 흐름도 진행 중입니다.

4-1. 소규모 팀이 대기업과 경쟁할 수 있는 ‘도구’가 됐다

LLM 기반 코딩 도구와 에이전트(agents)는 계속 발전하고 있습니다¹³⁵.

레포지토리 전체 맥락을 보고 코드를 수정하는 수준에 도달했고
실제 오픈소스 버그 수정 벤치마크에서, 1년 만에 해결률이 33% → 70% 이상으로 뛴 사례도 있습니다¹
“이렇게 동작하는 간단한 웹앱 만들어줘” 정도의 요구는, 완전히 비개발자도 어느 정도 구현할 수 있는 수준에 와 있습니다¹⁴

이 말은 곧,

예전에는 개발자 20명, 2년 걸리던 일을
이제는 개발자 3~4명 + AI 도구로 6개월에 해내는 팀이 등장할 수 있다는 뜻입니다.

대기업의 인력·코드 자산·프로세스가 갖던 우위가 줄어드는 겁니다. 이 구조는 90년대 오픈 소스 운동이 만들었던 변화와 굉장히 닮았습니다.

4-2. 90년대 오픈 소스가 했던 일을, 이번에는 LLM이 한다

90년대, 오픈 소스는 이런 변화를 만들었습니다.

“돈 많고 사람 많은 회사만 좋은 소프트웨어를 만든다”는 공식이 깨지고
전 세계 개발자들이 지식과 코드를 공유하며
리눅스, 아파치, MySQL 같은 거대한 공용 인프라가 탄생했습니다.

지금 LLM과 AI 코딩 흐름이 만드는 변화도 비슷합니다.

누구나 강력한 코드 생성·분석 도구를 쓸 수 있고
복잡한 시스템 설계도 점점 더 “설명 가능한 언어”로 표현할 수 있으며
교육·언어·지역 격차를 줄여줄 수 있는 가능성이 커지고 있습니다³⁵⁴

물론, 여기엔 전제 조건이 있습니다.

“AI를 잘 활용할 줄 아는 사람”이 늘어날 것
폐쇄적인 거대 기업 독점이 아닌, 오픈 생태계가 유지될 것

이건 자동으로 주어지는 미래가 아니라, 지금 개발자들이 어떤 태도로 참여하느냐에 따라 달라질 영역입니다.

4-3. “반 AI”가 아니라 “비판적 친 AI”가 필요한 순간

무조건적인 찬양도, 무조건적인 거부도 둘 다 위험합니다.

찬양: “AI가 다 해줄 거야”라고 믿다가, 품질·보안·윤리 문제를 키움
거부: “난 안 써”라고 버티다가, 커리어 경쟁력·도구 활용 능력에서 뒤처짐

지금 우리에게 필요한 포지션은 이쯤입니다.

“AI가 가진 힘과 한계를 제대로 이해하고, 도구로서 냉정하게 활용하는 개발자”

이게 결국, 자신의 실력과 커리어를 동시에 지키는 길입니다.

5. 개발자가 반(反) AI에 빠지지 않으면서도, 스스로를 지키는 5가지 전략

이제 가장 중요한 부분입니다. “그래, 흐름은 인정하겠다. 그럼 난 뭘 해야 하지?”

감정적으로는 불편함을 인정하되, 전략적으로는 AI를 내 편으로 만드는 방법을 정리해보겠습니다.

5-1. “도구로서”의 역할부터 분명히 선을 긋기

AI를 처음 쓸 때는 영역을 딱 정해두는 것이 좋습니다.

추천하는 입문 범위는 다음 정도입니다.

보일러플레이트 코드 생성
테스트 코드 초안 만들기
기존 코드 설명·요약 받기
익숙하지 않은 라이브러리 사용 예제 뽑기
간단한 스크립트/유틸리티 초안

반대로, 처음부터 맡기지 말아야 할 것들:

핵심 도메인 로직
보안·인증·결제 등 민감한 영역
복잡한 비즈니스 규칙이 얽힌 서비스 로직
팀의 주요 아키텍처 결정

이렇게 “AI가 들어와도 되는 영역 / 안 되는 영역”을 스스로 구분하고 쓰면, 과한 의존과 품질 추락을 피하면서도 경험을 쌓을 수 있습니다.

5-2. “확인 안 하면 쓴 걸로 치지 않는다”는 원칙 세우기

연구를 보면, 놀랍게도 개발자의 거의 절반이 AI가 생성한 코드를 제대로 검증하지 않는다는 조사도 있습니다⁶. 이건 사실상 “폭탄 돌리기”입니다.

개인적으로 추천하는 원칙은 아주 단순합니다.

“내 이름으로 커밋할 코드라면, AI가 썼든, 내가 썼든, 같은 기준으로 리뷰한다.”

구체적으로는:

AI가 만든 코드는 반드시 직접 읽고 이해하기
테스트 코드도 함께 생성해서 돌려보기
보안·예외 처리·컨벤션은 특히 더 엄격히 체크하기
“왜 이렇게 구현했는지”를 스스로 설명할 수 없는 코드는 커밋하지 않기

이 원칙 하나만 지켜도, AI 도입으로 발생하는 많은 품질 문제를 예방할 수 있습니다⁶.

5-3. “AI를 쓰는 사람”이 아니라 “AI를 관리하는 사람” 되기

장기적으로 살아남는 개발자는, AI를 직접 코딩하는 노동자가 아니라 AI를 설계·관리·감독하는 엔지니어가 될 가능성이 큽니다⁵⁷.

이를 위해 특히 중요한 역량은 다음 네 가지입니다.

문제를 언어로 정확히 정의하는 능력 (프롬프트 설계, 요구사항 분석)
AI가 낸 결과를 비판적으로 평가·수정하는 능력 (코드 리뷰, 테스트 설계)
AI 도구를 기존 개발 워크플로우에 통합하는 능력 (CI/CD, 코드베이스 구조화)
윤리·보안·라이선스 관점에서 리스크를 판단하는 능력

이건 “코딩을 안 해도 된다”는 뜻이 아니라, 코딩 실력을 기반으로 더 상위 레벨의 일을 할 수 있게 된다는 의미에 가깝습니다.

5-4. LLM 자체에 대한 “기본 소양”은 꼭 가져가기

LLM이 어떻게 돌아가는지, 너무 깊게 파고들 필요는 없습니다. 하지만 최소한 이 정도는 알고 있으면, 써먹는 방식이 완전히 달라집니다⁸³⁴.

LLM이 “다음에 올 단어를 확률적으로 예측하는 모델”이라는 점
컨텍스트 윈도우(한 번에 볼 수 있는 정보량)가 제한돼 있다는 점¹⁸
훈련 데이터가 과거의 코드와 텍스트라는 점 (그래서 구식 패턴도 따라 할 수 있음)⁶
환각(hallucination)이 구조적으로 발생하는 한계라는 점⁸

이 기본만 이해해도 다음과 같은 감각이 생깁니다.

“이건 AI가 잘할 수 있는 문제인지, 아닌지”
“이 정도 맥락을 보여줘야 제대로 답하겠구나”
“이런 종류의 답은 반드시 의심해야겠구나”

즉, 도구를 제대로 쓰려면, 도구의 한계를 아는 게 먼저입니다.

5-5. 반감은 ‘커리어 옵션’이 아니라 ‘정치적 의견’으로 분리하기

AI에 대한 감정은 다양할 수 있고, 그 자체로 존중받아야 합니다.

빅테크의 독점이 불편할 수 있고
노동 대체·감시 사회로 가는 흐름이 두려울 수 있습니다.

이건 충분히 “정치적·사회적 의견”으로서 표현할 가치가 있습니다.

하지만 감정 때문에 내 커리어 옵션을 스스로 줄이는 건 다른 문제입니다.

사회적으로는 “규제·윤리·분배”에 대한 논쟁에 적극 참여하되
개인적으로는 “이 도구를 잘쓰는 사람”이 되는 것

이 두 가지는 동시에 가능하고, 오히려 그렇게 할 때 목소리도 더 힘을 갖게 됩니다.

시사점: AI를 싫어해도, “AI 이후의 개발자”는 준비해야 한다

정리해 보면 이렇습니다.

반(反) AI 정서가 커지는 건 이해할 수 있는 현상입니다. 과장된 기대, 실제 현장의 피로감, 취업난, 품질·보안 문제 등이 그 배경에 있습니다¹²⁶.
하지만 “AI는 곧 사라질 거품”이라고 믿는 건 위험한 커리어 베팅입니다. 기술 자체는 이미 소프트웨어 개발 방식을 구조적으로 바꾸기 시작했고, 이 흐름은 투자 사이클과 상관없이 이어질 가능성이 큽니다¹³⁵⁴.
현재 AI 코딩 도구는 보일러플레이트, 테스트, 코드 이해·요약, 간단한 기능 구현에는 큰 도움이 되지만, 품질·보안·컨벤션 측면에서 많은 한계를 안고 있으므로, “검증 없는 도입”은 오히려 독이 될 수 있습니다¹⁶.
LLM과 AI 코딩은 장기적으로 소규모 팀과 개인 개발자의 파워를 키우는 ‘민주화’ 도구가 될 가능성이 있습니다. 과거 오픈 소스가 그랬던 것처럼 말이죠³⁵⁴.
그래서 지금 우리가 취해야 할 태도는 “무조건적인 반대”도, “맹목적인 찬양”도 아닌 “비판적 친 AI, 전략적 활용”입니다.