지난주 AI가 생성한 GPU 커널은 최적화된 PyTorch 기준선(baseline)보다 18.71배 더 빠르게 작동했습니다.

Fable 5라는 모델은 단순히 인간의 구현을 근소하게 앞지른 것이 아니었습니다. 아예 압도했습니다. Claude Opus 4.8은 14.4배에 도달했고, GLM-5.2는 11.14배를 기록했으며, GPT-5.5는 4.34배를 처리했습니다. Fable의 커널은 완전히 다른 등급이었습니다.

흥미로운 점은 다음과 같습니다: AI가 스스로 더 저렴하고 빠르게 작동하게 만드는 낮은 수준의 기계 장치(low-level machinery) 개선을 시작했다는 것입니다. 한때 희귀한 전문 지식을 필요로 했던 특화된 성능 작업이 탐색하기에 극적으로 쉬워졌습니다.

불편한 점은 다음과 같습니다: 최고의 구현체가 팀원 누구도 작성하지 않았거나 완전히 설명할 수 없는 것이라면 어떻게 될까요?

이 질문은 AI가 생성한 코드를 배포하는 모든 엔지니어링 팀에게 곧 던져질 문제입니다.

벤치마크의 문제점 (The Benchmark Problem)

벤치마크는 테스트된 조건에서 커널이 빠르게 작동했음을 보여줄 뿐입니다. 다음은 보여주지 않습니다:

• 서로 다른 GPU 하드웨어 전반에 걸쳐 어떻게 작동하는지
• 수치적 엣지 케이스(numerical edge cases)를 어떻게 처리하는지
• 몇 달간의 프로덕션 변경 사항에서 어떤 일이 발생하는지
• 입력값이 변할 때 우아하게 저하되는지 여부

작성자 역시 이 질문들에 답할 수 없습니다. AI는 검토 가능한 추론 체인(reviewable chain of reasoning)을 남기지 않는 프로세스를 통해 이 코드를 생성했습니다.

AI는 구현 비용을 낮추는 동시에 검증(proof) 비용은 높일 수 있습니다. 선임 엔지니어들은 코드를 적게 작성할지라도, 적대적 테스트(adversarial tests)를 설계하고, 가정을 확인하며, 롤백(rollbacks)을 계획하고, 그리고 인상적인 결과가 배포하기에 충분히 안전한지 결정하는 데 더 많은 시간을 할애하게 됩니다.

이것은 엔지니어링 작업의 소멸이 아닙니다. 단지 엔지니어링 작업이 검토 단계로 이동하며, 누가 이 작업을 수행할 자격이 있는지를 높이는 것입니다.

아무도 답하지 않는 질문

AI가 구축하는 부분이 많아진다면, 엔지니어들은 AI가 생성한 결과물을 검토하기 위해 얼마나 배워야 할까요?

선임 엔지니어들은 시스템을 구축하고, 실수를 저지르고, 실패를 디버깅하며, 무언가 고장 났을 때 결정을 내리면서 배웠습니다. 만약 주니어 엔지니어들이 '생성된 작업의 감독자(supervisors of generated work)'로 시작한다면, 그들은 결과물을 파이프라인을 통해 통과시키는 방법을 배울 수는 있어도, 해당 결과물이 잘못되었는지 알기 위해 필요한 본능을 개발하지 못할 수 있습니다.

이에 대한 한 댓글은 이 상황을 잘 요약했습니다:

"음악을 모르면 오케스트라를 지휘할 수 없다."

회사들은 고통이 인격을 형성하기 때문에 수동 코딩을 보존해서는 안 됩니다. 하지만 그들은 구현의 어떤 부분이 '판단(judgment)'을 만들어내는지 파악해야 하며, 이 경험들을 자동화로 인해 사라지게 해서는 안 됩니다. 그렇지 않으면, 그들은 매우 생산적인 주니어 엔지니어를 만들었지만 몇 년 후에 선임 엔지니어를 만들지는 못했다는 사실을 발견할 수도 있습니다.

저는 엔지니어링 관리, AI 도입, 그리고 도구가 변화할 때 실제로 무엇이 바뀌는지에 대해 글을 씁니다. 이 글이 도움이 되었다면, 이런 이야기들을 관리적 관점(management angle)으로 다루는 주간 게시물을 보내드립니다. 여기에서 확인하실 수 있습니다.