[심층분석] Rust 드림잡을 잡았는데, AI가 와버렸다 - 어느 Rust 개발자의 고백이 던지는 질문들

한 개발자의 짧은 글이 왜 이렇게 많은 개발자들의 마음을 흔들었을까요

최근 Rust 커뮤니티에 한 개발자의 짧은 글이 올라왔어요. 제목이 좀 짠해요. "Rust 드림잡을 잡았는데, 그 다음에 AI가 일어나버렸다(Got the Rust dream job, then AI happened)".

이 글이 뭐길래 이렇게 많은 개발자들이 공감하고, 토론하고, 때로는 반박하는 댓글을 쏟아냈을까요? 짧게 요약하자면 이래요. 한 개발자가 몇 년간 열심히 공부해서 드디어 자기가 원하던 Rust 포지션에 취업했는데, 막상 입사해보니 회사가 AI 코딩 도구에 올인하기 시작하면서, 자기가 직접 코드를 짜는 시간보다 AI가 뱉어낸 코드를 리뷰하고 고치는 시간이 더 많아졌다는 거예요. Rust라는 언어 자체를 사랑해서, 빌림 검사기(borrow checker, Rust가 메모리 안전성을 위해 코드를 검사하는 컴파일러 기능)랑 씨름하는 그 짜릿함을 즐기던 사람이, 이제는 AI가 만든 unwrap() 떡칠된 코드를 정리하는 일을 하게 된 거죠.

이 이야기가 단순히 한 개인의 신세 한탄으로 들리지 않는 이유는, 지금 전 세계 개발자들이 똑같은 고민을 하고 있기 때문이에요. 2024년부터 본격화된 AI 코딩 도구의 폭발, 그리고 2025년을 지나 2026년 현재까지 이어지는 "AI 네이티브 개발" 흐름. 이게 개발자의 정체성, 커리어, 심지어 "코딩의 즐거움"이라는 지극히 개인적인 감정까지 흔들고 있거든요.

오늘은 이 Reddit 글에서 시작해서, 그 아래 386개가 넘는 댓글에서 오갔던 진짜 이야기들을 같이 들여다보려고 해요. 단순히 "AI가 개발자를 대체할까?" 같은 뻔한 질문이 아니라, "내가 사랑하던 일의 모양이 바뀌고 있을 때, 나는 어떻게 해야 할까?"라는 더 깊은 질문으로요.

Rust라는 언어가 개발자에게 주는 특별한 의미

먼저 배경 설명부터 해볼게요. 왜 하필 "Rust" 드림잡이 AI와 부딪혔을 때 이렇게 많은 사람이 반응했을까요?

Rust라는 언어를 잘 모르는 분들을 위해 짧게 설명드리면요. Rust는 C/C++ 같은 저수준 언어(시스템 하드웨어와 가까운 곳에서 동작하는 언어)의 성능을 가지면서도, 메모리 관련 버그를 컴파일 시점에 잡아주는 언어예요. 이게 뭐냐면, C 같은 언어에서는 프로그래머가 실수로 메모리를 잘못 다루면 프로그램이 터지거나 보안 취약점이 생기는데, Rust는 컴파일러가 "야, 너 지금 이 변수 두 군데서 동시에 수정하려고 하잖아. 안 돼" 하고 미리 잡아줘요.

근데 이 "미리 잡아주는" 과정이 진짜 까다로워요. Rust를 처음 배우는 사람들이 "빌림 검사기와 싸운다(fighting the borrow checker)"라고 말할 정도로요. 이게 답답하긴 한데, 한 번 익숙해지면 "내가 짠 코드가 컴파일만 되면 런타임에 메모리 에러는 안 난다"는 엄청난 자신감을 주거든요. 그래서 Rust 개발자들은 언어 자체에 대한 애정이 유독 강해요.

한마디로 Rust 개발자가 된다는 건, "장인정신"에 가까운 코딩 스타일을 사랑하게 된다는 뜻이에요. 타입을 정교하게 설계하고, 라이프타임(변수가 살아있는 기간)을 고민하고, 제로 코스트 추상화(성능 손해 없이 추상화 쓰기)를 고민하는 그런 스타일이요. 글쓴이가 "드림잡"이라고 표현한 이유가 여기 있어요. 몇 년간 공부하고, 사이드 프로젝트 돌리고, 어렵게 입사한 자리인 거죠.

그런데 왜 AI가 이걸 흔들까요

자, 이제 진짜 문제로 들어가 볼게요. 왜 AI 코딩 도구가 Rust 개발자에게 특히 복잡한 감정을 안기느냐면요.

Rust는 원래 "생각하는 시간이 긴 언어"예요. JavaScript로 빠르게 프로토타입 만들 때처럼 슥슥 짜는 언어가 아니라, "이 데이터 소유권은 누가 가져야 하지?", "이 함수는 참조를 받아야 하나 값을 받아야 하나?" 같은 걸 고민하면서 천천히 설계하는 언어거든요. 이게 Rust의 매력이자 고통이에요.

그런데 AI 코딩 도구, 예를 들어 Claude Code나 Cursor 같은 것들이 등장하면서 상황이 바뀌었어요. 이 도구들은 "일단 돌아가는 코드"를 빠르게 생성해요. 물론 품질이 점점 좋아지고 있긴 한데, Rust 특유의 정교한 설계를 자동으로 해주는 건 아직 완벽하지 않아요. 그래서 AI가 뱉은 Rust 코드를 보면:

• unwrap()이 여기저기 박혀있어요 (에러 처리를 대충 하는 나쁜 패턴)
• 라이프타임 고민 없이 .clone()을 남발해요 (성능 희생)
• 트레잇(trait, 인터페이스 같은 개념) 설계가 평면적이에요

글쓴이가 하소연한 포인트가 여기예요. "내가 Rust를 좋아했던 이유가, AI가 만든 코드를 치우는 일로 바뀌었다"는 거죠. 마치 요리사로 취업했는데 조리 로봇이 만든 요리의 간만 맞추는 일을 하는 것 같은 느낌이랄까요.

댓글창에서 벌어진 세 갈래의 토론

이 글에 달린 댓글들을 쭉 읽어보면 크게 세 가지 입장이 부딪혀요.

1. "공감한다" 파

"나도 똑같다"는 개발자들이 정말 많았어요. 특히 시니어들 중에서요. 이분들이 공통적으로 하는 말이 있어요. "코딩의 즐거움이 사라지고 있다"는 거예요. 문제를 풀어내는 과정, 타입을 고민하고, 알고리즘을 설계하고, 리팩토링으로 코드를 아름답게 다듬는 과정 — 이게 개발자라는 직업의 본질이었는데, 이제는 "AI 프롬프트 엔지니어링"과 "AI 코드 리뷰어"로 역할이 바뀌고 있다고요.

2. "도구일 뿐이다" 파

반대로 이런 댓글도 많았어요. "망치가 생겼다고 목수가 사라지진 않는다". AI는 결국 도구일 뿐이고, 그 도구를 잘 쓰는 사람이 여전히 필요하다는 거예요. 특히 Rust처럼 정교한 언어에서는 AI가 뱉은 코드를 제대로 평가하고 고칠 수 있는 사람이 더 귀해진다는 논리예요. 이분들은 오히려 AI 덕분에 보일러플레이트(반복되는 상투적 코드)에서 해방돼서, 진짜 설계에 집중할 수 있다고 말해요.

3. "회사 문제다" 파

세 번째 그룹이 흥미로워요. 이 문제가 AI의 문제가 아니라 회사의 문제라는 거예요. 즉, 경영진이 "AI로 개발자 생산성 10배 올려라" 같은 윗선의 압박 때문에, 개발자들에게 억지로 AI 도구를 쓰게 만들고, 성과 지표도 바꾸고 있다는 거죠. 결국 글쓴이의 진짜 문제는 "AI가 왔다"가 아니라 "AI를 어떻게 쓸지에 대한 조직의 철학이 없다"는 쪽이라고요.

저는 개인적으로 세 번째 의견이 가장 본질을 찌른다고 봐요.

AI 코딩 도구, 지금 어디까지 왔나

잠깐 현재 AI 코딩 도구의 지형을 간단히 짚고 가볼게요. 한국에서도 많이들 쓰시는 도구들이죠.

• Claude Code / Cursor: 파일 여러 개를 한꺼번에 이해하고 수정해요. "이 기능 추가해줘" 하면 관련 파일들을 다 건드려요.
• GitHub Copilot: IDE에 딱 붙어서 자동완성 중심. 줄 단위 추천이 강해요.
• Aider / Continue: 오픈소스 기반으로, 모델을 골라 쓸 수 있어요.

2026년 현재 이 도구들의 공통적인 방향은 에이전트화예요. 이게 뭐냐면, 개발자가 "버그 잡아줘"라고 하면 AI가 알아서 테스트 돌리고, 로그 보고, 코드 고치고, 다시 테스트 돌리는 전 과정을 스스로 반복하는 거예요. 예전의 "자동완성 도우미"에서 "자율적으로 일하는 동료"로 진화 중이죠.

그런데 여기서 Rust 같은 언어가 흥미로운 포지션에 있어요. 타입 시스템이 강력하다는 게 양날의 검이거든요. AI가 뱉은 코드가 컴파일만 되면 상당한 수준의 안전성이 보장되니까, AI-생성 코드의 신뢰도가 다른 언어보다 높아요. 반대로 AI가 Rust 코드를 뱉기가 JavaScript보다 어렵기 때문에, 완성도가 떨어질 수도 있고요.

한국 개발자에게 주는 실제적인 조언

자, 그럼 한국에서 Rust나 시스템 프로그래밍을 공부하고 있거나, 이미 관련 일을 하고 있는 분들께 이 이야기가 어떤 의미일까요? 실무 시나리오 몇 개를 드려볼게요.

시나리오 1: 주니어 Rust 개발자라면

지금 Rust를 공부하고 있는 분이라면 "AI가 뱉은 코드를 평가할 수 있는 실력"을 키우는 데 집중하세요. 구체적으로는:

• unwrap(), expect(), .clone()이 왜 나쁜지 설명할 수 있어야 해요
• Result<T, E>와 ? 연산자로 에러를 어떻게 전파하는지 몸에 익혀야 해요
• 트레잇 객체(dyn Trait)와 제네릭(impl Trait)의 차이를 알아야 해요

이걸 알아야 AI가 뱉은 코드의 품질을 제대로 판단할 수 있어요. 단순히 Rust 문법만 외우는 건 이제 큰 의미가 없어요.

시나리오 2: 회사에서 AI 도구 도입하라고 하는 경우

만약 팀장님이 "다음 주부터 Claude Code 써서 생산성 2배 올리자"고 하신다면, 먼저 무엇을 자동화할지, 무엇을 안 할지 팀 내에서 합의하는 게 중요해요. 제가 추천하는 기준은 이래요:

• 자동화 OK: 보일러플레이트, 테스트 코드, 문서화, 마이그레이션 스크립트
• 신중하게: 핵심 비즈니스 로직, 동시성 코드, unsafe 블록
• 사람이 주도: 아키텍처 설계, 타입 설계, 퍼블릭 API 설계

시나리오 3: 커리어 방향 고민

솔직히 말씀드리면, "순수 코더"의 가치는 내려가고 있어요. 하지만 그 자리를 대체하는 건 두 방향이에요:

1. 위로: 시스템 설계, 아키텍처, 성능 튜닝, 보안을 고민하는 사람
2. 옆으로: 도메인 지식(금융, 의료, 게임 등)이 깊은 사람

한국 개발자들에게 특히 추천드리고 싶은 건, 오픈소스 Rust 프로젝트에 꾸준히 기여하는 것이에요. AI가 못 하는 일이 뭐냐면, 커뮤니티와 신뢰 관계를 쌓는 일이거든요. 이게 장기적으로 가장 단단한 커리어 자산이 돼요.

이 글이 던지는 진짜 질문

처음으로 돌아가서 정리해볼게요. 이 Reddit 글이 왜 많은 사람의 마음을 흔들었냐면, 결국 이 질문 때문이에요:

> "내가 사랑했던 일의 모양이 바뀌고 있을 때, 나는 무엇에 가치를 두고 일해야 할까?"

AI가 코드를 짠다는 건 바꿀 수 없는 흐름이에요. 그런데 그 흐름 속에서 "코드를 짜는 즐거움"이 완전히 사라지는 건 아니에요. 형태가 바뀌는 거죠. 타이핑하는 즐거움에서 → 설계하는 즐거움으로, 혼자 문제를 푸는 즐거움에서 → AI와 함께 더 큰 문제를 푸는 즐거움으로요.

Rust라는 언어의 철학 자체가 "사람을 신뢰하지 않고, 컴파일러가 검증한다"였거든요. 어쩌면 AI 시대의 개발도 비슷할지 몰라요. "사람의 타이핑을 신뢰하지 않고, AI의 생성과 사람의 검증을 결합한다." 이 철학에 익숙해지는 게 앞으로의 숙제인 것 같아요.

여러분께 묻고 싶어요

• 최근 AI 코딩 도구를 쓰면서, "재미있다"고 느끼셨나요, 아니면 "허무하다"고 느끼셨나요?
• 만약 글쓴이처럼 드림잡에서 이런 상황을 만나면, 여러분은 떠날 건가요 남을 건가요?
• 여러분이 10년 뒤에도 개발자로 일한다고 가정할 때, 지금 어떤 실력을 쌓아야 한다고 생각하세요?