Rust 경험 없이 10만 줄의 TypeScript를 Rust로 포팅하기. 그것은 엔지니어링이 아니다.
요약
Claude를 사용하여 Rust 경험 없이 10만 줄의 TypeScript 코드를 Rust로 포팅한 사례를 통해, AI 생성 코드의 검증과 엔지니어의 역할에 대한 논쟁을 다룹니다. 테스트 통과가 코드에 대한 깊은 이해를 보장하지 않음을 경고하며, 향후 테스트 인프라의 중요성을 강조합니다.
핵심 포인트
- AI를 활용한 대규모 코드 포팅은 가능하지만, 언어에 대한 이해가 결여될 위험이 있음
- 차분 퍼징(Differential Fuzzing)과 같은 강력한 검증 전략이 엔지니어링의 핵심이 됨
- 단순히 코드가 작동하는 것과 아키텍처를 이해하고 디버깅하는 것은 별개의 문제임
- 미래에는 언어 전문 지식보다 테스트 인프라 구축 능력이 더 중요해질 수 있음
누군가가 Claude를 사용하여 한 달 만에 10만 줄의 TypeScript를 Rust로 포팅했습니다. 그들은 Rust 경험이 전혀 없었습니다. 그리고 솔직히 말해서? 저는 이 일이 머릿속을 떠나지 않습니다.
그 개발자는 이후 차분 퍼징 (differential fuzzing) — 프로그램의 두 버전에 무작위 데이터를 던져 결과를 비교하는 프로세스 — 을 사용하여, 무려 230만 번의 전투 시뮬레이션을 통해 Rust 출력물이 원래의 TypeScript 동작과 일치하는지 검증했습니다. 대다수의 테스트를 통과했습니다. 코드는 완성되었습니다. 인터넷은 집단적으로 발칵 뒤집혔습니다.
이것이 왜 민감한 문제인가
이것은 개발자들 사이에서 의견이 갈리는 이야기입니다. 한쪽에서는 "실행되고, 테스트를 통과한다면, 어떻게 작성되었는지가 무슨 상관인가?"라고 말합니다. 다른 한쪽에서는 "당신은 Rust를 알고 있는 것이 아니다. 당신은 그저 복사기를 사용하고 있을 뿐이다."라고 말합니다.
두 진영 모두 일리가 있습니다. 하지만 어느 쪽도 이를 인정하고 싶어 하지 않습니다.
테스트 통과 ≠ 코드 이해
제가 짜증스럽게 느끼는 부분은 이것입니다. 검증 전략 자체는 사실 꽤 영리했습니다. 수백만 번의 실행에 걸쳐 차분 퍼징 (differential fuzzing)을 수행하는 것은 게으른 해킹이 아닙니다. 그것은 검증 (validation) 단계에 투입된 실제 엔지니어링 노력입니다.
하지만, 무언가를 검증하는 것과 그것을 이해하는 것은 별개의 문제입니다.
→ 이 개발자가 Claude 없이 새벽 2시에 빌림 검사기 (borrow checker) 문제를 디버깅할 수 있는가?
→ 압박감이 심한 상황에서 unsafe 블록 (unsafe blocks)이나 수명 어노테이션 (lifetime annotations)에 대해 추론할 수 있는가?
→ Claude가 제안하지 않을 Rust의 아키텍처 (architectural) 결정을 내릴 수 있는가?
만약 당신의 대답이 '아니오'라면, 230만 번의 퍼징 실행으로 커버되지 않은 엣지 케이스 (edge case)에 해당 AI 생성 코드가 직면했을 때 정확히 어떤 결과가 초래될까요? 당신은 그 언어의 엔지니어가 아닙니다. 당신은 매우 비싼 컴파일러를 가진 QA 파이프라인일 뿐입니다.
"작동한다"는 함정
저는 반론도 이해합니다. 우리는 StackOverflow를 사용하는 사람들을 막지 않습니다. 모든 JavaScript 개발자가 메인 브랜치에 푸시하는 것을 허용하기 전에 이벤트 루프 (event loop)에 대한 지식을 테스트하지도 않습니다. 툴링 (Tooling)은 언제나 엔지니어링의 일부였습니다.
하지만 이해를 돕기 위해 도구를 활용하는 것과, 도구에 완전히 의존하여 이해를 대체하는 것 사이에는 차이가 있습니다. 네일 건 (nail gun)을 사용하는 목수는 여전히 스터드 (studs)의 위치를 알고 있습니다. 이 상황은 마치 누군가가 로봇에게 집을 지으라고 지시한 다음, 문이 열리는지 확인하는 것에 더 가깝게 느껴집니다. 🏠
문은 잘 열릴 수도 있습니다. 지진이 일어나기 전까지는 말이죠.
이것이 실제로 증명하는 것
진짜 이야기는 "AI가 언어를 포팅할 수 있다"가 아닙니다. 그것은 이미 알고 있던 사실입니다. 진짜 이야기는 이제는 언어 전문 지식보다 테스트 인프라 (testing infrastructure)가 더 중요해질 수도 있다는 점입니다.
이는 관점에 따라 매우 흥분되는 일일 수도, 혹은 공포스러운 일일 수도 있습니다.
→ 소유권 의미론 (ownership semantics)을 마스터하기 위해 수년을 보낸 Rust 순수주의자라면 — 이것은 뺨을 맞는 듯한 기분일 것입니다.
→ 당장 작동하는 포팅 결과물이 필요한 스타트업 창업자라면 — 이것은 기적처럼 느껴질 것입니다.
→ 커리어의 지속 가능성을 고민하는 엔지니어라면 — 이것은 화재 경보입니다. 🔥
해당 개발자는 Rust를 배운 것이 아닙니다. 그들은 Rust 출력물이 올바른지 확인하는 방법을 배운 것입니다. 이 둘은 근본적으로 다른 기술입니다. 그리고 업계는 아직 어느 쪽이 더 중요한지를 결정하지 못했습니다.
불편한 중간 지대
저는 이 개발자를 부정행위자라고 부르지는 않겠습니다. 230만 번의 시뮬레이션을 실행할 수 있는 퍼징 하네스 (fuzzing harness)를 만들기 위해서는 실제 지식이 필요합니다. 사람들은 무언가를 테스트할 때 무엇을 그리고 어떻게 테스트할지를 결정하는 데 필요한 전문 지식의 가치를 충분히 인정하지 않고 있습니다.
하지만 저는 "10만 줄을 Rust로 포팅했다"라는 문장이 이전과 같은 의미를 갖지는 않는다고 믿습니다. 이제 그 문장에는 주의 사항이 붙습니다. 사실, 요즘 엔지니어링 결과물에 관한 모든 문장에는 주의 사항이 붙을지도 모릅니다.
우리 모두는 많은 변화를 겪고 있습니다. 번창할 개발자는 지식을 독점하는 사람도, AI의 출력을 맹목적으로 신뢰하는 사람도 아닐 것입니다. 그들은 AI의 확신이 어디서 끝나는지, 그리고 자신의 판단이 어디서부터 시작되어야 하는지를 정확히 아는 사람들이 될 것입니다.
글쎄요, 그 경계선은 우리가 믿고 싶어 하는 것보다 훨씬 더 불분명합니다. 🤷
여기 제 질문이 있습니다. 만약 AI가 생성한 코드가 당신이 던질 수 있는 모든 테스트를 통과한다면, 그 코드를 이해하는 인간이 아무도 없다는 사실이 과연 중요할까요?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기