[심층분석] 25년차 개발자가 코딩을 그만두겠다고 선언한 이유, 그리고 우리가 생각해봐야 할 것들

어느 날 갑자기, 코드 리뷰가 사라졌다

6살 때 처음 코드를 작성하고, 25년간 전문 소프트웨어 개발자로 살아온 한 사람이 있어요. 회사에서도 코딩하고, 퇴근 후에도 코딩하는, 말 그대로 개발이 삶 전부인 사람이었죠. 그런데 이 사람이 어느 날 이런 글을 올렸어요.

> "우리 회사에서 코드 리뷰가 AI 코드 배포 속도를 늦춘다는 이유로 폐지됐다. 나는 이제 코드를 작성할 수도, 테스트할 수도, 리뷰할 수도 없다. 새로운 커리어가 필요하다."

이 한 편의 글이 수많은 개발자들의 공감을 불러일으켰어요. 단순히 한 사람의 푸념이 아니라, 지금 전 세계 소프트웨어 업계가 마주하고 있는 근본적인 변화의 단면을 보여주고 있거든요.

이 글이 중요한 이유는 단순해요. "AI가 개발자를 대체한다"는 막연한 공포가 아니라, 실제로 현장에서 일어나고 있는 구체적인 변화를 보여주기 때문이에요. 코드 리뷰 폐지, AI 생성 코드의 무검증 배포, 개발자 역할의 축소. 이런 일들이 지금 일어나고 있는 거예요.

오늘은 이 이야기를 출발점으로, AI 시대에 소프트웨어 개발이라는 직업이 어떻게 변하고 있는지, 그리고 한국의 개발자로서 우리가 어떻게 대응해야 하는지를 깊이 있게 이야기해볼게요.

"AI 슬롭"이라는 표현이 말해주는 것

원문에서 이 개발자는 AI가 생성한 코드를 "AI slop"이라고 불렀어요. 슬롭(slop)이라는 단어는 원래 "질 낮은 음식을 대충 담아낸 것"이라는 뜻인데요, AI가 대량으로 찍어내는 품질 관리 안 된 코드를 이렇게 부르는 거예요.

이 표현이 재미있는 게, 사실 "AI slop"이라는 용어가 이미 업계에서 꽤 널리 쓰이고 있거든요. 원래는 AI가 생성한 저품질 콘텐츠(글, 이미지 등)를 가리키는 말이었는데, 이제 코드 영역까지 확장된 거예요.

여기서 핵심적인 문제가 드러나요. AI가 코드를 생성하는 것 자체가 문제가 아니에요. AI가 생성한 코드를 검증 없이 프로덕션에 배포하는 문화가 문제인 거죠.

코드 리뷰가 뭐냐면요, 쉽게 말해서 요리사가 음식을 손님에게 내보내기 전에 다른 요리사가 맛을 보는 과정이에요. "소금이 너무 많다", "이 재료는 안 어울린다" 같은 피드백을 주고받는 거죠. 소프트웨어에서는 다른 개발자가 내 코드를 읽어보고, 버그는 없는지, 보안 문제는 없는지, 설계가 합리적인지를 점검하는 과정이에요.

이게 왜 중요하냐면, 사람이 작성한 코드도 실수가 있는데, AI가 생성한 코드는 더더욱 검증이 필요하거든요. AI는 겉보기에는 그럴듯하지만 실제로는 동작하지 않거나, 보안 취약점이 있거나, 성능이 나쁜 코드를 자신 있게 만들어내는 경우가 많아요. 이걸 업계에서는 "hallucination(환각)"이라고 부르는데요, AI가 마치 사실인 것처럼 틀린 내용을 생성하는 현상을 말해요.

그런데 이 회사는 그 검증 과정을 속도를 위해 없앤 거예요. 이건 마치 자동차 공장에서 품질 검사를 생략하고 바로 출하하는 것과 같아요. 단기적으로는 생산 속도가 올라가겠지만, 장기적으로는 리콜과 사고가 이어질 수밖에 없죠.

AI 코딩 도구의 현주소: 무엇을 할 수 있고, 무엇을 할 수 없나

지금 개발 현장에서 사용되는 AI 코딩 도구들의 현황을 좀 더 구체적으로 살펴볼게요.

AI 코딩 도구의 종류

현재 개발자들이 사용하는 대표적인 AI 도구들이 있어요.

• GitHub Copilot: 코드 에디터에서 실시간으로 코드를 제안해주는 도구예요. 마치 내 옆에 앉아서 "이 다음에 이렇게 쓰면 어때?"라고 속삭여주는 짝 프로그래밍 파트너 같은 거죠.
• Cursor, Windsurf: 에디터 자체에 AI가 깊이 통합된 도구로, 코드 생성뿐 아니라 리팩토링, 디버깅까지 AI가 도와줘요.
• ChatGPT, Claude: 대화형 AI로, 코드 작성은 물론 설계 상담, 버그 분석 등 더 넓은 범위의 개발 작업을 도와줘요.

AI가 잘하는 것

• 보일러플레이트 코드 생성: 반복적이고 패턴이 정해진 코드를 빠르게 만들어내요. 예를 들어 API 엔드포인트를 만들 때 기본 구조를 잡아주는 건 정말 잘해요.
• 단순 변환 작업: "이 JavaScript 코드를 TypeScript로 바꿔줘" 같은 작업이요.
• 문서화: 코드에 대한 설명이나 주석을 달아주는 작업도 꽤 잘해요.
• 학습 보조: 새로운 라이브러리나 프레임워크를 배울 때 예제 코드를 빠르게 보여줘요.

AI가 못하는 것 (그리고 이게 핵심이에요)

• 복잡한 비즈니스 로직 설계: "우리 회사의 결제 시스템은 이런저런 특수한 규칙이 있고..." 같은 맥락을 이해하고 설계하는 건 아직 어려워요.
• 시스템 전체를 아우르는 아키텍처 결정: 하나의 함수는 잘 만들지만, 전체 시스템이 어떻게 맞물려 돌아가야 하는지를 판단하는 건 사람의 영역이에요.
• 보안 취약점 방지: AI가 생성한 코드에 SQL 인젝션이나 XSS 같은 보안 취약점이 포함되는 경우가 실제로 보고되고 있어요. SQL 인젝션이라는 건 쉽게 말하면, 해커가 데이터베이스에 몰래 명령을 집어넣을 수 있는 구멍이에요.
• 레거시 시스템과의 통합: 10년 넘게 운영되면서 온갖 예외 처리가 쌓인 시스템에 새 기능을 추가하는 건 AI가 맥락을 파악하기 어려워요.
• 코드의 "왜"를 설명하는 것: AI는 "무엇을" 하는 코드는 잘 만들지만, "왜 이렇게 해야 하는지"에 대한 이해는 부족해요.

이걸 비유하자면, AI는 아주 빠르고 성실한 인턴이에요. 시키는 일은 잘하지만, 무엇을 시켜야 하는지를 판단하는 건 아직 시니어 개발자의 몫인 거죠. 그런데 원문의 회사는 인턴에게 모든 결정권을 주고, 시니어는 앉아만 있으라고 한 셈이에요.

---

업계에서 벌어지고 있는 두 가지 흐름

지금 소프트웨어 업계에서는 AI 도입과 관련해서 크게 두 가지 상반된 흐름이 보여요.

흐름 1: "빠르게 배포하라" 진영

일부 기업, 특히 스타트업이나 빠른 성장을 추구하는 회사들은 AI를 최대한 활용해서 개발 속도를 극대화하려 하고 있어요. 이런 회사들의 논리는 이래요:

• 시장 선점이 중요하다
• 완벽한 코드보다 빠른 출시가 가치 있다
• AI가 생성한 코드도 어차피 나중에 고치면 된다
• 코드 리뷰 같은 "병목"을 제거해야 한다

원문의 회사가 바로 이 진영에 속하는 거예요. 이 접근법의 단점은 명확해요. 기술 부채(technical debt)가 빠르게 쌓인다는 거죠. 기술 부채라는 건 쉽게 말해서, 지금 빠르게 만들기 위해 대충 한 부분이 나중에 이자처럼 불어나서 더 큰 비용으로 돌아오는 걸 말해요. 신용카드로 일단 결제하고 나중에 갚겠다는 것과 비슷한데, 이자가 복리로 붙는 거예요.

흐름 2: "AI는 도구일 뿐" 진영

반대로 많은 시니어 개발자들과 기술적으로 성숙한 조직들은 AI를 보조 도구로 활용하면서도 기존의 소프트웨어 공학 원칙을 유지하려 해요:

• 코드 리뷰는 유지하되, AI가 1차 검토를 도와준다
• AI 생성 코드도 반드시 사람이 검증한다
• 테스트 자동화는 오히려 강화한다
• AI는 개발자의 생산성을 높이는 도구이지, 개발자를 대체하는 것이 아니다

이 두 흐름의 차이를 비유하자면, 전자는 네비게이션이 알려주는 대로 눈 감고 운전하는 거고, 후자는 네비게이션을 참고하되 직접 도로 상황을 보면서 운전하는 거예요. 네비게이션이 "직진하라"고 해도 앞에 공사 중이면 돌아가야 하잖아요.

실제 사례로 보는 차이

최근 몇 가지 사례가 이 논쟁을 더 뜨겁게 만들고 있어요.

어떤 스타트업은 AI로 빠르게 MVP(최소 기능 제품, 쉽게 말해서 핵심 기능만 넣은 초기 버전)를 만들어서 시장에 내놓았는데, 사용자가 늘어나자 성능 문제와 버그가 터지면서 결국 상당 부분을 다시 작성해야 했다는 이야기도 있고요.

반면에 AI 코딩 도구를 도입하면서도 코드 리뷰 프로세스를 유지한 팀은 생산성이 30~50% 향상되었다는 보고도 있어요. AI가 초안을 잡아주고, 사람이 다듬는 방식이 가장 효율적이라는 거죠.

---

개발자의 정체성 문제: "나는 코드를 작성하는 사람인가"

이 글이 많은 개발자의 마음을 울린 또 다른 이유가 있어요. 바로 정체성의 위기예요.

원문의 개발자는 이렇게 말했어요. "나는 코드를 작성할 수도, 테스트할 수도, 리뷰할 수도 없다." 이건 단순히 "할 일이 없어졌다"가 아니라 "내가 누구인지 모르겠다"라는 실존적인 고민이에요.

25년간 자신을 "소프트웨어 개발자"로 정의해온 사람에게, 코드를 작성하지 못하게 하는 건 화가에게 붓을 빼앗는 것과 같거든요. 물론 화가는 붓 없이도 예술을 할 수 있지만, 그건 이미 다른 직업이잖아요.

이건 이 사람만의 문제가 아니에요. 많은 개발자들이 비슷한 고민을 하고 있어요:

• "내가 AI 프롬프트만 쓰는 사람이 되는 건가?": 코드를 직접 작성하는 대신 AI에게 무엇을 만들라고 지시하는 역할로 바뀌는 거죠.
• "AI가 만든 코드를 복붙하는 게 개발인가?": 코드를 이해하지 못한 채 AI 출력을 그대로 사용하는 것에 대한 회의감이에요.
• "주니어 때 배웠던 기초가 이제 필요 없는 건가?": 알고리즘, 자료구조, 디자인 패턴 같은 걸 열심히 배웠는데, AI가 다 해주면 그게 무슨 소용이냐는 거죠.

하지만 여기서 중요한 포인트가 있어요. 기초를 모르면 AI가 만든 코드가 맞는지 틀린지도 판단할 수 없어요. AI를 잘 쓰려면 오히려 더 깊은 이해가 필요한 거예요. 마치 번역기를 쓰더라도 원어를 아는 사람이 결과물의 품질을 판단할 수 있는 것처럼요.

---

한국 개발자에게 주는 시사점

한국의 개발 환경에서 이 이야기가 특히 의미 있는 이유가 있어요.

1. 한국 특유의 "빨리빨리" 문화와의 충돌

한국 IT 업계는 원래부터 빠른 개발 속도를 중시하는 경향이 있어요. 여기에 AI까지 더해지면, "코드 리뷰 같은 건 시간 낭비"라는 인식이 더 강해질 수 있거든요. 원문의 상황이 한국에서도 충분히 일어날 수 있다는 얘기예요.

만약 여러분의 회사에서 비슷한 움직임이 있다면, 이렇게 대응해볼 수 있어요:

• 데이터로 설득하세요: "코드 리뷰를 통해 프로덕션 버그가 X% 줄었다"는 식의 구체적인 수치를 모아두세요.
• AI 리뷰 + 사람 리뷰 하이브리드를 제안하세요: AI가 먼저 기본적인 체크를 하고, 사람은 설계와 비즈니스 로직만 집중 리뷰하는 방식이요. 이러면 속도도 잡고 품질도 잡을 수 있어요.
• 장애 사례를 기록하세요: AI 생성 코드에서 발생한 실제 문제들을 문서화해두면, 나중에 강력한 근거가 돼요.

2. 주니어 개발자의 성장 경로 변화

이 부분이 특히 중요해요. 전통적으로 주니어 개발자는 이런 과정을 거치면서 성장했어요:

1. 간단한 기능 구현 → 2. 코드 리뷰에서 피드백 받기 → 3. 점점 복잡한 작업 맡기 → 4. 다른 사람의 코드 리뷰하기 → 5. 설계 결정에 참여하기

그런데 AI가 코드 작성을 대신하고 코드 리뷰가 사라지면, 1번과 2번 단계가 없어지는 거예요. 그러면 3~5번 단계에 도달하기가 훨씬 어려워지죠.

지금 취업 준비 중이거나 주니어 개발자라면, 이렇게 접근해보세요:

• AI 없이도 코드를 작성할 수 있는 능력을 기르세요: AI 도구를 끄고 알고리즘 문제를 풀어보는 시간을 정기적으로 가져보세요. 이건 계산기가 있어도 암산 능력이 중요한 것과 같아요.
• AI 도구를 "비판적으로" 사용하는 연습을 하세요: AI가 생성한 코드를 무조건 수용하지 말고, "이 코드가 왜 이렇게 작성됐는지", "더 나은 방법은 없는지" 스스로 분석하는 습관을 들이세요.
• 시스템 설계 능력에 투자하세요: 코드 한 줄 한 줄보다는 전체 시스템이 어떻게 동작하는지를 이해하는 능력이 점점 더 중요해질 거예요.

3. 실무에서 AI를 현명하게 활용하는 방법

구체적인 시나리오를 들어볼게요.

시나리오 1: 새 API 엔드포인트 만들기

• AI에게: 기본 CRUD(생성, 조회, 수정, 삭제) 구조를 만들어달라고 해요
• 내가 할 일: 비즈니스 로직 추가, 에러 처리 보완, 보안 검증 추가
• 코드 리뷰에서: AI가 놓친 엣지 케이스(예상하지 못한 특수한 상황)가 없는지 확인

시나리오 2: 버그 수정

• AI에게: 에러 로그를 보여주고 원인 분석을 요청해요
• 내가 할 일: AI의 분석을 검증하고, 실제 원인을 파악한 뒤 수정
• 주의할 점: AI가 "이게 원인이에요"라고 자신 있게 말해도, 직접 확인하기 전까지는 믿지 마세요

시나리오 3: 레거시 코드 리팩토링

• AI에게: 코드를 분석하고 개선 방향을 제안받아요
• 내가 할 일: 기존 시스템의 맥락을 고려해서 AI의 제안 중 적용 가능한 것만 선별
• 핵심: AI는 "이 코드가 왜 이렇게 생겼는지"의 역사를 모르기 때문에, 맥락을 알고 있는 개발자의 판단이 필수적이에요

4. 커리어 전략 재정비

이 시대에 개발자로서 경쟁력을 유지하려면, 이런 역량에 투자하는 게 좋아요:

• 도메인 전문성: 금융, 의료, 물류 등 특정 분야의 깊은 이해. AI는 범용적이지만, 특정 도메인의 규제나 관행을 깊이 아는 건 사람만 할 수 있어요.
• 시스템 설계 능력: 마이크로서비스 아키텍처, 분산 시스템, 성능 최적화 같은 큰 그림을 그리는 능력이요.
• 커뮤니케이션 능력: 기술적 결정을 비개발자에게 설명하고, 팀을 이끌고, 요구사항을 정확히 파악하는 능력. 이건 AI가 대체하기 가장 어려운 영역이에요.
• AI 협업 능력: AI를 효과적으로 활용하는 것도 하나의 스킬이에요. 좋은 프롬프트를 작성하고, AI의 결과물을 평가하고, AI와 사람의 작업을 적절히 분배하는 능력이죠.

---

이건 "개발자의 종말"이 아니라 "개발자의 변화"다

역사를 돌이켜보면, 비슷한 전환점이 여러 번 있었어요.

• 어셈블리에서 고급 언어로: "기계어를 직접 작성하지 않으면 진짜 프로그래머가 아니다"라던 시절이 있었죠. 하지만 C언어가 등장하면서 더 많은 사람이 더 복잡한 소프트웨어를 만들 수 있게 됐어요.
• 수동 메모리 관리에서 가비지 컬렉션으로: Java가 등장했을 때 "메모리를 직접 관리하지 않는 건 진짜 프로그래밍이 아니다"라는 말이 있었어요. 가비지 컬렉션이라는 건 쉽게 말해서 프로그램이 사용한 메모리를 자동으로 정리해주는 기능이에요.
• 서버 관리에서 클라우드로: 직접 서버를 운영하던 시절에서 AWS 같은 클라우드 서비스로 전환할 때도 "서버를 직접 만질 줄 모르면 진짜 엔지니어가 아니다"라는 이야기가 있었죠.

AI도 마찬가지일 가능성이 높아요. 코드를 한 줄 한 줄 타이핑하는 것에서, 무엇을 만들어야 하는지를 결정하고 AI의 결과물을 검증하는 역할로 무게중심이 옮겨가는 거예요.

다만, 원문에서 지적하는 것처럼 이 전환 과정에서 품질을 포기하는 건 위험해요. 코드 리뷰, 테스트, 품질 관리 같은 소프트웨어 공학의 기본 원칙은 AI 시대에도 여전히 유효해요. 오히려 AI가 대량의 코드를 빠르게 생성할 수 있는 만큼, 검증의 중요성은 더 커지는 거예요.

마무리: 우리에게 남은 질문들

이 25년차 개발자의 이야기는 불편하지만 중요한 질문을 던져요. AI가 코드를 작성하는 시대에, 개발자의 가치는 어디에 있을까요?

제 생각에는, 답은 의외로 단순해요. "좋은 소프트웨어가 무엇인지 아는 것" 그 자체가 가치예요. AI가 아무리 빠르게 코드를 만들어도, 그 코드가 좋은지 나쁜지를 판단하고, 전체 시스템 안에서 어떻게 작동해야 하는지를 결정하는 건 깊은 경험과 이해가 필요한 일이거든요.

물론 쉽지 않은 변화예요. 특히 코딩 자체를 사랑하는 개발자에게는요. 하지만 변화에 적응하면서도 소프트웨어 공학의 핵심 가치를 지키는 것, 그게 지금 우리에게 필요한 자세가 아닐까 싶어요.

여러분은 어떻게 생각하세요? 여러분의 회사에서는 AI 도입이 개발 문화를 어떻게 바꾸고 있나요? 코드 리뷰 같은 전통적인 프로세스를 유지하고 있나요, 아니면 변화를 겪고 있나요? 그리고 가장 중요한 질문 — 5년 뒤에 "소프트웨어 개발자"라는 직업은 어떤 모습일까요? 여러분의 생각을 들려주세요.