From AI Framework to AI Compiler Generator - 실행 시스템 구현에서 규칙 선택 기반 생성 시스템으로의 관점 이동

1. 개요

프로젝트의 기술 변천을 단순한 기능 확장이나 방향 전환으로 보지 않고, 관점의 중심이 어떻게 이동해 왔는가를 정리하기 위해 작성

초기 목표는

• AI 연산을 직접 실행 가능한 형태로 만드는 것,
• 이후 관심은 실행 그 자체보다 더 나은 실행 방식
• 더 나아가 그 더 나은 실행을 가능하게 하는 의미 보존 규칙으로 이동
• 마지막으로 현재는, 그러한 규칙과 하드웨어 정보를 바탕으로 특화된 compiler 자체를 동적으로 구성할 수 있는가

다음의 순서를 따라 이동해 왔음

1. AI Framework - 연산를 직접 실행 가능한 시스템으로 만든다
2. AI Compiler - 연산 의미를 보존하면서 더 좋은 실행 형태로 바꾸낟
3. Kernel Optimization / GPU Understanding - 그러한변환이 실제 GPU에서 어떤 형태로 실현되는지 파고든다. 
4. AI Compiler Generator - 규칙, 보존 조건 하드웨어 정보에 따라 개별 compiler 를 생성한다.

이전 단계에서 추상화 중심의 상승 과정으로 볼 수 있다.

 

2. 핵심 문제의 이동

2.1 초기 질문

이 연산을 어떻게 실행 가능한 형태로 만들 것인가?

2.2 다음 질문

이 연산을 더 빠르고 더 안정적으로 실행하게 만들 수있는가?

2.3 그 다음 질문

어떤 의미 보존 아래에서 어떤 최적화가 합법적인가?

2.4 현재 질문

그러한 합법적, 보존 규칙, 하드웨어 정보를 조합하여 특정 상황에 맞는 compiler 를 생성할 수 있는가? 

즉 프로젝트는 점점 결과물 그 자체보다, 결과물을 가능하게 하는 조건과 생성 구조 쪽으로 관심의 중심을 옮겨 왔다.

 

3. 1 단계 - AI Framework

3.1 중심 목표

초기의 중심은 명확

• 모델과 연산을 직접 실행 가능한 형태로 만들자

이 단계에서 중요한 것은 다음과 같다

• 연산 정의
• Tensor / Moduel / Function 구조
• 실행 경로 구성
• Backend 연결
• CUDA kernel 작성 및 호출
• 사용자 정의 layer 지원
• 실제 학습 / 추론 흐름 구성

즉 이 시기의 관심은 실행 가능성 자체에 있었다.

 

3.2 이 단계의 성과

단순한 toy system 이 아니라, 실제로 다음을 드러냈다.

• 어떤 연산이 runtime 에서 어떻게 호출되는가
• backend 와 실행 시스템이 어떻게 연결되는가
• 커스텀 CUDA kernel 을 붙였을 때 어떤 형태로 framework 내부에 통합되는가
• 학습 / 추론 관점에서 필요한 최소 실행 단위가 무엇인가

 

3.3 이 단계의 한계

하지만 framework 만으론 충분하지 않았음

연산이 실행된다는 사실은 알 수 있어도,

• 왜 어떤 실행 방식이 더 좋은지
• 어떤 변형이 합법적인지
• 의미를 보존하면서 어디까지 바꿀 수 있는지
• 어떤 최적화가 일반화 가능한지

를 설명하기 어렵다.

즉 framework 는 실행의 기반은 주지만, 최적화의 원리는 충분히 주지 못한다.

 

4. 2단계 - AI Compiler

4.1 관점의 이동

다음 단계에서 중심은 단순 실행에서 벗어난다.

• 연산을 실행하는 것만으론 부족, 더 좋은 실행으로 바꾸는 체계가 필요하다.

이 시점부터 관심은 다음으로 이동

• graph capture
• lowering
• runtime restriction
• kernel fusion 
• deterministic replay
• execution planning
• operator property
• legality of transformation

즉 이제 시스템은 단순 backen 가 아니라 변환을 수행하는 구조를 가져야 한다.

 

4.2 중요한 전환

연산을 그대로 실행할 대상으로 보지 않고, 어떤 의미를 가진 구조물로 보기 시작했다는 것

질문은 다음과 같이 바뀐다.

• 이 연산은 어떤 성질을 가지는가
•  어떤 재배열과 결합이 가능한가
• 어떤 intermediate 는 제거 가능한가
• 어떤 메모리 이동은 줄일 수 있는가?
• 어떤 순서 변경은 허용되는가

여기서부터 framework 에서 compiler 로 관점이 옮겨간다.

 

4.3 이 단계의 성과

이 단계는 이후의 핵심 자산들을 낳는다

• Property Atlas - 어떤 의미 보존 아래에서 무엇이 합법적인가
• Preservation Guide - 실행 의미를 유지하기 위한 보존 규칙과 허용 경계
• Ops Explorer - 각 연산자의 수학적 형태와 property / preservation profile

compiler 적 사고의 기반이 된다.

 

4.4 이 단계의 한계

하지만 compiler 관점으로도 아직 충분하지 않음

의미적으로 합법한 변형이 항상 실제 하드웨어에서 성능적으로 좋은 것은 아니기 때문

즉 다음과 같은 문제가 남는다

• 합법한 변환이 실제 GPU 에서 빠른가
• 이론적 tiling 이 실제로도 이득인가
• online update 나 rematerialization 은 어느 지점까지 유리한가
• numeric drift 는 하드웨어 및 구현 방식에 따라 어떻게 달라지는가

즉 의미적 합법성과 실행 현실성 사이에 간극이존재한다.

 

5. 3 단계 - Kernel Optimization 과 GPU 이해

5.1 다시 질문이 내려감

이 시점부터 질문은 더 낮은 층으로 내려간다

• 최적화는 실제 커널로 실현되어야 하며, GPU 는 그 실현을 강하게 제한한다

이 단계에서는 다음이 중요해진다.

• shared memory layout
• coalescing
• bank conflict
• cp.async
• WMMA / Tensore Core
• tile residency
• warp / block scheduilng
• online softmax
• rematerialization
• memory traffic minimization

즉 이제는 compiler 의 규칙이 실제 하드웨어 위에서 어떤 형태로 살아남는지를 파고들게 된다.

 

5.2 중요한 변화

여기서 중요한 건, 단순히 빠른 커널 하나를 만든다가 아니다.

오히려 질문은 더 근본적이다.

• 어떤 수학적 구조가 GPU 에서 좋은 실행 구조로 변환될 수 있는가?
• 어떤 primitive 가 hardward 와 잘 맞는가?
• 왜 어떤 최적화는 성립하고 어떤 것은 성립하지 않는가?
• 성능은 어떤 memory / compute tradeoff 위에서 결정되는가

즉 이 단계는 compiler 의 현실 접속 단계다.

 

5.3 이 단계의 성과

이 단계에서 얻은 통찰

• 최적화는 연산 이름만으로 설명되지 않는다
• 실제 성능은 memory movement, reduction topology, tile reuse, staging 방식에 강하게 의존한다
• 같은 의미를 가진 연산이라도 구현 family 에 따라 완전히 다른 성능을 보인다.
• operator 보다 더 낮은 수준의 execution primitive 를 보지 않으면 일반화가 어렵다.

 

5.4 이 단계의 한계

하지만 잘 만든 커널 몇 개만으로는 충분하지 않음

커널 하나는 결과물이지, 그것을 다시 만들어내는 생성 원리는 아니기 때문

즉 다음 질문이 생긴다.

• 좋은 커널을 사람 손으로 하나씩 만드는 대식, 그 커널이 성립하는 규칙과 조건을 통해 다시 생성할 수 없는가?

이 질문이 다음 단계의 출발점이다.

 

6. GPU Probing Lab 의 등장

6.1 왜 probing 이 필요했는가

보안 취약점 탐색 시스템에서는 동일한 코드라도 규칙 기반 필터만 잘 구성하면 다양한 탐색이 가능했다. 

그러나 GPU kernel 의 경우는 다르다.

같은 kernel skeletion 이라도,

•  Architecture
• cache behavior
• memory hierarchy
• shared memory bank mapping
• register pressure
• occupancy cliff
• scheduling behavior

에 따라 최적점이 달라진다.

즉 kernel synthesis 나 compiler generation 을 하려면, 단순 규칙만이 아니라 하드웨어 특성에 대한 측정 정보가 필요하다.

이 문제의식에서 GPU Probing Lab 이 출발한다.

 

6.2 초기 probing 의 목적

초기 목적은 명확

• 하드웨어의 성능한계를 측정한다
• 특정 접근 패턴이 어떤 penalty 를 가지는지 본다.
• memory / compute 병목이 어디서 생기는지 파악한다
• 하드웨어의 실질 작동 방식을 관측한다.

하지만 이후 이 probing 은 더 큰 역할을 갖게 된다.

Probe 는 단순 벤치마크가 아니라, compiler generation 을 위한 hardware prior 수집 장치가 된다.

 

7. GPU Probing Lab 의 두 축

현재 시점에서 GPU Probing Lab 은 두 성격을 분리해서 보는 것이 맞다.

7.1 Hardware Characterization Lab

이 축은 GPU 자체를 관측한다.

중심 질문은 다음과 같다

• 이 GPU 는 어떤 구조적 성향을 가지는가
• memory hierarchy 의 crossover point 는 어디인가?
• stride, coalescing, bank conflict, occupancy 는 어떻게 작동ㅎ아는가?
• 어떤 성능 cliff ㅗ아 saturation regime 가 존재하는가

즉 이 축은 device-centric 이다.

이곳의 산출물은 다음과 같다

• hardware profile
• performance envelope
• measured limits
• architectural  sensitivity map

 

7.2 Execution Primitive Lab

이 축은 operator 보다 더 낮은 수준의 execution primitive 를 실험한다.

중심 질문은 다음과 같다.

• reduction topology 는 어떤 cost 와 drift 를 가지는가?
• rematerialization 은 언제 이득인가
• streaming update 는 어떤 synchronization / precision budget 아래에서 실현되는가?
• tile-based staging 은 어떤 shape 와 budget 아래에서 유효한가?
• primitive 조합이 어떤 kernel family 로 연결될 수 있는가?

즉 이 축은 computation-centric 이다.

이곳의 산출물은 다음과 같다.

• primitive realization profile
• legality-to-cost mapping
• implementation family viability
• codegen-relevant execution priors

 

7.3 왜 두 축이 모두 필요한가

Hardware Characterization 만 있으면 GPU 가 어떤 기계인지는 알 수 있지만,  그 정보만으로는 어떤 계산 구조가 좋은 구현 familty 를 가지는지까지는 바로 알기 어렵다.

Execution Primitive Lab 만 이씅면 계산 구조의 성질은 보이지만, 그것이 특정 GPU 에서 왜 유리한지에 대한 grounding 이 약해진다.

따라서 최종 synthesis 를 위해서는 두 축이 모두 필요하다.

 

8. 4 단계 - AI Compiler Generator

8.1 현재의 관점

현재 프로젝트의 중심은 여기로 이동했다.

• Compiler 는 고정된 단일 구조물이 아니라, 선택된 슈칙과 하드웨어 정보에 따라 동적으로 구성될 수 있는가?

즉 이제 목표는 단순히 compiler 를 만드는 것이 아니라,

• property
• preservation
• operator profile
• hardware characterization
• execution primitive realization

을 조합해서 특정 상황에 맞는 compiler instance 를 생성하는 것이다.

 

8.2 왜 generator 가 되었는가

이 변화는 갑작스러운 것이 아닌

• framework 는 실행 가능성을 제공
• compiler 는 의미 기반 최적화를 제공
• kernel optimization 은 hardware realism 을 드러냈다.
• probing 은 hardware prior 를 수집할 필요성을 드러냈다.

그 결과 다음이 자연스럽게 나온다

• 그렇다면 규칙과 하드웨어 정보로부터 개별 compiler 를 동적으로 조립할 수 있지 않을까

이 질문이 AI Compiler Generator 의 출발점이다.

 

8.3 LLM 의 위치

여기서 LLM 은 전통적 compiler 전체를 대체하는 존재가 아니다.

오히려 다음 역할을 맡는다.

• 선택된 규칙 세트를 해석한다.
• 가능한 implementation familty 를 제안한다.
• kernel skeleton 을 생성한다
• 후보 parameter 르 제안한다.
• compile / profile / alidation 결과를 보고 repair suggestion 을 한다.

즉 자유 생성기가 아니라 규칙 선택 기반 constrainted synthesizer 로 보는 것이 맞다.

 

8.4 특화 compiler 의 의미

이때 생성되는 것은 단순한 커널 하나가 아니라.

• 허용되는 property
• 보존 조건의 엄격도
• 사용 가능한 primitive family
• 금지되는 transformation
• hardware-specific priors
• validation requirements

으로 정의되는 개별 compiler filter / specialized compiler instance 다 

즉 사용자는 사실상 이번 문제를 위한 소형 특화 compiler 를 동적으로 구성하게 된다.

 

9. 보안 취약점 탐색기와의 구조적 유사성

이 관점은 이전의 보안 취약점 탐색 시스템과 구조적으로 유사하다.

그 시스템에서는:

• 취약점 category가 존재하고
• category별 규칙이 존재하며
• 사용자가 특정 규칙을 선택하고
• 선택된 규칙이 개별 탐색 필터를 구성했다.

현재의 compiler generator에서는:

• property / preservation / hardware category가 존재하고
• category별 synthesis 규칙과 금지 규칙이 존재하며
• 사용자가 특정 규칙을 선택하고
• 선택된 규칙이 개별 compiler filter를 구성한다.

차이가 있다면, 이전 시스템이 주로 패턴 탐색이었다면, 현재 시스템은 분석 + 생성 + 검증까지 포함한다는 점이다.

즉 이것은 단순 rule engine이 아니라, 

• analysis-guided synthesis system

이라고 보는 것이 더 정확하다.

 

10. 프로젝트 전체의 재정의

이제 프로젝트 전체를 다시 정의하면 다음과 같다.

10.1 과거의 정의

• AI framework 구현
• CUDA backend 구현
• custom layer 실행
• kernel optimization 실험

10.2 현재의 정의

이 프로젝트는 단순 실행 시스템이나 단일 compiler 구현을 넘어,

의미 보존 규칙, 하드웨어 관측, execution primitive 실험을 바탕으로, 특정 환경에 특화된 compiler 및 kernel synthesis 경로를 동적으로 구성하는 시스템

으로 정의할 수 있다.

즉 산출물의 중심도 달라졌다.

과거에는:

• 실행되는 코드
• 동작하는 backend
• 최적화된 kernel

이 중심이었다.

지금은:

• property atlas
• preservation guide
• hardware characterization
• execution primitive realization map
• synthesis constraint profile
• specialized compiler instance

가 중심이 된다.

 

11. 층위별 구조

현재 시점에서 프로젝트는 다음의 층위로 이해하는 것이 가장 명확하다.

Layer A. Execution Substrate

• framework
• runtime
• backend
• kernel execution

Layer B. Optimization Semantics

• property atlas
• preservation guide
• ops explorer
• legality model

Layer C. Hardware Evidence

• GPU Probing Lab / Hardware Characterization
• GPU Probing Lab / Execution Primitive Lab

Layer D. Synthesis / Generation

• compiler profile
• rule-selected compiler instance
• LLM-assisted kernel synthesis
• validation / profiling / repair loop

이 구조는 프로젝트가 방향을 잃은 것이 아니라, 상위 계층이 계속 추가되어 왔음을 보여준다.

 

12. 왜 이것이 자연스러운 상승인가

겉으로 보면 이 프로젝트는 여러 번 방향을 바꾼 것처럼 보일 수 있다.

• framework
• compiler
• kernel optimization
• generator

그러나 실제로는 모두 같은 질문의 더 높은 층위들이다.

• 실행은 어떻게 가능한가?
• 더 좋은 실행은 어떻게 가능한가?
• 그런 변형은 왜 가능한가?
• 그런 변형 가능성을 가진 compiler는 어떻게 생성할 수 있는가?

즉 이것은 결과 구현 → 원리 → 원리의 조립 구조로 이동한 것이다.

이 의미에서 현재의 변화는 방향 이탈이 아니라,

실행 시스템에서 생성 시스템으로 올라가는 자연스러운 추상화 상승

이다.

 

13. 앞으로의 문서화 방향

향후 문서들은 다음과 같은 역할 분리 아래에서 정리되는 것이 좋다.

13.1 철학 / 개념 문서

• From AI Framework to AI Compiler Generator
• Why Property, Preservation, and Hardware Evidence Must Meet
• Compiler as a Rule-Selected Synthesis System

13.2 AICF 의미 계층 문서

• Property Atlas
• Preservation Guide
• Ops Explorer
• Legality Profiles

13.3 GPU Probing Lab 문서

• Hardware Characterization Lab
• Execution Primitive Lab
• Probe-to-Compiler Prior Mapping

13.4 생성 시스템 문서

• Compiler Profile DSL
• Rule-Selected Compiler Instance
• LLM-Constrained Kernel Synthesis Loop
• Validation / Profiling / Repair Architecture

 

14. 결론

이 프로젝트는 더 이상 단순한 AI framework 구현이나 개별 CUDA kernel 최적화 프로젝트로 보기 어렵다.

현재의 가장 정확한 정의는 다음과 같다.

이 프로젝트는 연산 실행 시스템에서 출발하여, 의미 보존과 하드웨어 관측을 결합한 최적화 구조를 만들고, 최종적으로 선택된 규칙과 하드웨어 조건 아래에서 특화 compiler를 생성하는 메타 시스템으로 이동해 온 과정이다.

즉 핵심은 단순히 “좋은 kernel을 만드는 것”이 아니라,

• 왜 그런 kernel이 가능한지,
• 어떤 규칙 아래에서 허용되는지,
• 어떤 하드웨어에서 실현 가능한지,
• 그에 맞는 compiler를 어떻게 다시 만들 수 있는지

를 하나의 체계로 연결하는 데 있다.

이 문맥에서 현재의 변화는 급격한 이탈이 아니라,

framework → compiler → optimizer → generator

로 이어지는 자연스러운 관점 상승이다.

 

15. 한 문장 요약

처음에는 연산을 실행하는 시스템을 만들었고, 이후에는 그 연산을 더 잘 실행하게 만드는 compiler를 고민했으며, 지금은 그러한 compiler 자체를 규칙과 하드웨어 정보로부터 생성할 수 있는가를 다루는 단계에 도달했다.