프롬프트를 AI-generated binary로 만드는 것이 가능하다. 그리고 프로그래머들의 종말이 가까워지고 있는가?

Source: Dev.to

@Freeze (동영상)

만약 “elon musk ai will skip code machine code” 라고 구글에 검색하면, 다양한 이유로 이 아이디어에 반대하고 비판하는 소프트웨어 개발자들의 압도적인 의견을 찾을 수 있습니다. 아래는 저자들이 폭넓은 지식과 깊은 컴퓨터 과학·소프트웨어 엔지니어링 이해를 가지고 있는 몇몇 심층 기사들입니다.

• Elon Wants AI to Skip Code and Spit Out Binaries. That’s Not Progress
• I think Elon is wrong about ‘AI beats compilers’. What’s the actual technical steelman?
• Elon Says AI Will Generate Binary by 2026. Here’s Why That’s a Terrible Idea
• Elon Musk Predicts AI Will Bypass Coding by 2026: Binary Generation & Future of IT Careers – Cloud Soft Solution, 이해관계자 그룹에서 제공
• Is the “code + compiler” approach about to disappear?
• Elon Musk Predicts AI Will Render Coding Obsolete by 2026

나의 의견

나는 엘론이 말한 것이 꽤 실현 가능하다고 생각한다. 나는 내부 정보를 가지고 있지는 않다; 엘론 머스크가 의미하는 바는 AI가 머신 코드를 직접 생성한다는 것이며, 소스 코드를 생성하고 특정 프로세서를 대상으로 하는 컴파일러를 호출하는 것이 아니다.

Current: Code → Compiler → Binary → Execute
Future: Prompt → AI‑generated Binary → Execute

Grok‑Code의 훈련은 인간이 읽을 수 있는 소스 코드를 생성하는 다른 LLM 코드 에이전트들의 훈련과 근본적으로 달라야 할 것이다.

프로그래밍 역사 검토

면책 조항

• 저는 컴퓨터 과학자도 AI 전문가도 아니며, 현재 활동 중인 풀스택 개발자이므로 프로그래머이기도 합니다.
• 플러그보드, 스위치, 펀치 카드, 종이 테이프 등을 사용할 정도로 오래되지 않았지만, 물리학 학사 과정 중 Fortran, Assembly, PLC를 다뤄본 경험이 있습니다.
• 석사 논문으로 C++로 M68K 프로세서 에뮬레이터를 작성하여 M68K 머신 코드를 해석했습니다.

수년간 C / C++, Turbo Pascal, VB, Delphi, C#, TypeScript를 일상적인 코딩에 사용해 왔습니다. 제가 이해하기로는 고수준 언어와 대부분의 컴퓨터 과학·소프트웨어 공학 원칙은 인간의 두뇌, 즉 살과 피가 흐르는 뇌를 위해 설계된 것입니다. 예를 들면:

• 높은 응집도와 낮은 결합도
• SOLID 원칙
• 디자인 패턴
• 애자일 선언문, XP, DevOps 등
• 재사용 가능한 라이브러리·프레임워크

얼마나 원칙을 잘 따르든, 코드가 얼마나 깔끔하든 결국에는 컴파일·링크되어 스파게티 같은 형태가 됩니다. 이는 인간의 두뇌는 싫어하지만 컴퓨터는 신경 쓰지 않는 현상입니다.

깨끗한 코드는 컴파일 시간, 링크 시간, 실행 시간 최적화를 더 잘 수행하도록 도와줄 수 있으며, 성능 향상이 **25 %**까지 이를 수 있습니다. 현재 최적화 알고리즘은 대부분 프로그래머가 만든 고정 규칙으로 구현되어 있으며, 이러한 규칙은 깨끗한 코드를 보상하는 경향이 있습니다.

요컨대, 이러한 관행은 인간의 두뇌가 기능적·기술적 복잡성을 소화하여 동작하는 프로그램을 만들 수 있도록 돕기 위해 존재합니다.

프로그래밍 및 LLM AI 코드 에이전트

AI‑코드‑에이전트 벤더가 모델을 어떻게 학습시키는지에 대한 기본적인 아이디어는 가지고 계시겠지만, 어떤 원시 코드를 수집하고 어떻게 라벨링하는지는 잘 모를 수 있습니다:

• GitHub, SourceForge, 그리고 일부 상용 프로그램/라이브러리의 모든 코드를 단순히 스캔합니까?
• 코드 품질에 대한 신호를 사용해 코드를 라벨링합니까?

프로그래머로서 저는 AI 코드 에이전트 덕분에 큰 혜택을 받았습니다. 이는 제가 사소한 기술 세부 사항을 기억하는 데 서툴기 때문입니다. 지금까지 경험한 바로는, AI 코드 에이전트에게 비‑트리비얼한 기능을 구현해 달라고 요청할 때—프롬프트가 얼마나 상세하고 형식적이든, 혹은 단순하든—생성된 소스 코드는 보통 과도하게 부풀려진 설계와 구현을 가지고 있으며, 라인 수는 일반적으로 3–5 × 정도가 됩니다.

AI‑생성 소스 코드와 평범하지만 “정치적으로 올바른” 수작업 코드

“3–5 ×”는 나에게 마법 같은 숫자처럼 들립니다. 동일한 기술 스택과 언어를 사용한 여러 상용 리라이트 프로젝트와 오픈‑소스 도구 하나를 리라이트하면서 나는 다음과 같은 현상을 관찰했습니다:

• 내 코드베이스는 레거시 버전(몇 개월 또는 1년 정도 오래된)의 ≈ 1/3 – 1/5 수준의 라인 수(LoC)였습니다.
• 설계가 훨씬 단순했으며, 서드‑파티 의존성이 적고 복잡한 DI/IoC, SOLID, 디자인 패턴을 덜 사용했습니다.
• 런타임 성능이 20 % – 50 % 더 빨랐습니다.
• 최종 제품이 더 신뢰성 있고 견고했습니다.

레거시 코드베이스에 관해서는:

• 한 도구의 작성자는 SOLID와 DI/IoC에 열광했지만 높은 응집도와 낮은 결합도를 오해하여 잘못된 위치에 DI/IoC를 사용했습니다.
• 레거시 상용 프로그램의 작성자들은 SOLID와 디자인 패턴을 잘 알았지만, 응집도/결합도에 대한 오해와 지나치게 고급 설계를 너무 일찍 도입한 탓에 이를 잘못 적용했습니다.

즉, 이러한 레거시 코드베이스는 SOLID에 대해 “정치적으로 올바른” 모습을 보였지만, 실제로는 지나치게 복잡하고 길어졌을 뿐이었습니다.

내가 깨끗하고 짧은 코드를 작성해 온 방법

나는 그 프로그래머들이 더 간단한 대안을 평가하지 않고, 비즈니스와 기술적 맥락을 충분히 이해하는 데 시간을 들이지 않으며, 기본적인 애자일 실천을 따르지 않은 채 첫 번째 실행 가능한 아이디어를 바로 구현했다는 믿음이 있다.

---

실천

• 기본적이고 작동하는 코드부터 시작합니다.
• 충분한 단위 테스트와 통합 테스트를 작성합니다.
• 각 반복마다 적극적으로 리팩터링합니다.

목적은 디자인을 우아하거나 인상적으로 보이게 하는 것이 아니라, 기술 동료 및 비즈니스 이해관계자와의 빈번한 커뮤니케이션을 통해 비즈니스와 기술적 맥락에 대한 이해를 깊게 하는 것입니다.

내가 사는 도시의 평균 시니어 개발자보다 2–4 × 더 많은 코드를 작성하나요?

아니오. 내가 SDLC를 주도할 때, 일반적으로 청구 가능한 시간의 ≈ 1/3 – 1/4를 코딩(테스트 포함)에 할애합니다, 특히 아키텍처와 디자인이 형성되는 초기 1/4 – 1/3 단계에서.
나머지 시간은 이해관계자와 생각하고, 공부하고, 소통하는 데 사용합니다. 같은 양의 코드—또는 적은 양—를 작성하더라도 전체 유지보수 비용이 크게 감소합니다.

SOLID 원칙 (Robert C. Martin, UML for Java Programmers에서 인용)

적용 시점

• 문제가 처음 나타날 때.
• 모든 시스템을 언제나 모든 원칙에 맞추려 하지 마세요; OCP를 위해 가능한 환경을 상상하고, SRP를 위해 변경 원인을 찾고, ISP를 위해 수십 개의 작은 인터페이스를 만들고, DIP를 위해 쓸모 없는 추상화를 발명하는 데 시간을 낭비하게 됩니다.

베스트 프랙티스: SOLID를 반응적으로 적용하세요—구조적 문제가 감지되거나 모듈이 다른 곳의 변경에 영향을 받을 때, 하나 이상의 원칙이 도움이 될 수 있는지 고려합니다.

반응적 접근에도 선제적 압력이 필요합니다: 고통 지점을 의도적으로 찾아야 합니다. 이를 위한 가장 좋은 방법 중 하나는 많은 단위 테스트를 작성하는 것인데, 이상적으로는 코드 자체를 작성하기 전에 작성하는 것입니다 (다음 장의 주제).

AI 코드 에이전트 vs. 시니어 개발자

Prompt‑to‑AI‑Generated Binary의 장점

• 이 접근 방식은 다른 AI 코드 에이전트가 일반적으로 생성하는 복잡한 설계가 누적되어 발생하는 코드 팽창을 피할 수 있습니다.
• 충분히 강력한 AI와 강력한 하드웨어는 인간 프로그래머를 위해 개발된 전통적인 CS/SE 기법에 의존하지 않고도 막대한 복잡성을 처리할 수 있습니다.
• Grok Code는 자체적인 코드 팽창 방지 메커니즘을 가지고 있을 가능성이 높아 SOLID와 디자인 패턴의 역할이 거의 없습니다.

프롬프트‑투‑AI‑생성 바이너리의 근본적인 문제 하나

• 이 접근 방식은 인간 개입(검토, 검증, 확인)을 제품 품질과 관련하여 제거합니다.
• 머신 코드를 어셈블리로 분해하더라도, AI가 기호 이름을 추가하더라도 결과는 인간이 읽기 매우 어렵습니다.
• 전체 바이너리는 블랙 박스가 됩니다:
  • 최선의 경우: 기대한 대로 동작하지만 예상보다 더 많은 것이 포함됩니다.
  • 최악의 경우: AI 기반 검토, 검증, 확인을 완전히 신뢰하지 않는 한 여러 “판도라의 상자”가 포함될 수 있습니다.

Grok Code가 빛날 수 있는 분야

• 순수 수학 문제와 알고리즘.
• 수학적 기반에 의한 다른 AI 시스템 개발.
• 도메인‑전문가 AI.
• 비디오 게임.
• “시간‑죽이기” 앱.
• 고급 해킹, 스팸, 혹은 사기 도구(런타임에 AI 지원 여부와 관계없이).
• …

예시: 수학자라면 Grok Code를 사용해 전체 Matlab‑유사 라이브러리를 생성할 수 있습니다.

AI 코드 생성기에 대한 나의 평소 도전

질문: Medicare Online에서 사용하는 것과 같은 복잡한 Swagger/OpenAPI 정의가 주어졌을 때, AI 코드 생성기가 C#, TypeScript, Java 및 기타 언어로 사용 가능한 클라이언트 라이브러리를 생성할 수 있을까요?

관찰: ChatGPT와 Copilot은 할 수 없습니다(그렇지 않다면 Microsoft는 Microsoft Kiota 대신 온라인 AI 기반 코드 생성기를 출시했을 테니까요).

향후 관심: 연말까지 Grok Code가 Medicare Online OpenAPI 정의를 기반으로 Windows 11 및 Intel 프로세서에서 실행되는 머신 코드 형태의 클라이언트 라이브러리를 생성할 수 있게 될까요?