autograd 기반 training 구조와 왜 오랫동안 사용되고 있는지에 대해

대부분의 AI 프레임워크는 다음의 구조를 따른다

• Python training loop 가 실행 흐름을 지배
• forward 실행 중 발생한 연산 기록
• autograd 가 그 기록을 역으로 따라가며 backward 수행

실행 후 미분 그래프를 만드는 것이 아님

• 의미가 사후적으로 구성되고
• 정적 실행 단위로 고정하기 어려우며
• replay / determinism / optimizer capture 에 불리한 구조

하지만 표준처럼 유지되고 있음

 

autograd 는 의미 해석 시스템이 아님

• forward 단계에서 op 를 기록하고
• 각 연산 타입에 대해 미리 정의된 backward rule 을
• 역순으로 적용

다음의 내용이 포함되지 않음

• layer 단위 의미
• 전역적인 모델 구조
• 목적 함수에 대한 해석
• optimizer 의미

추론하지 않음, 실행 결과 기반 룰 매칭 시스템

 

우선순위는 ‘정확성’이나 ‘재현성’이 아니었다

초기 딥러닝 프레임워크의 우선순위는 명확했다.

1. 돌아간다
2. 연구자가 빠르게 실험할 수 있다
3. GPU를 활용할 수 있다

아래의 것들은 의도적으로 뒤로 밀렸다.

• determinism
• replay 안정성
• optimizer capture
• static execution

autograd 구조는:

• 구현이 단순하고
• 유지보수가 쉽고
• 확장이 용이했다

프레임워크 개발자 입장에서도 매우 합리적인 선택이었다.

 

왜 지금에서야 이 구조의 한계가 드러나는가

현재는 상황이 완전히 달라졌다.

• 모델 구조는 점점 정형화
• training loop는 패턴화
• hardware는 고정
• 대규모 반복 실행이 기본 전제

이제 문제는 더 이상:

“이 모델이 표현 가능한가?”

가 아니라,

“이 학습 과정을 얼마나 안정적으로, 빠르게, 반복 실행할 수 있는가?”

여기서 autograd 기반 사후 매칭 구조는
본질적인 한계에 부딪힌다.

그래서 등장한 것이:

• graph capture
• torch.compile
• XLA
• CUDA Graph replay

하지만 이들은 모두 기존 구조 위에 얹힌 보조 장치다.