의미 있는 결과가 나오기 전의 프로젝트를 어떻게 바라볼 것인가

프로젝트를 오래 진행하다가 보면, 결과보다 관찰과 해석이 더 많이 쌓이게 되는 시기가 존재.

기능을 구현하고, 실행 구졸르 분석하고, 성능을 측정하고, 하위 계층의 동작을 추적했지만, 정작 새로운 최적화나 명확한 성능 개선을 제시하지 못한 상태가 이어짐

가장 먼저 든 생각은

• 아직 의미 있는 개발 결과를 만들어 내지 못했다.

특히 포트폴리오에서는 완성된 기능, 수치로 확인되는 개선, 실제 사용자에게 제공되는 서비스가 강조됨, 

반면 분석 과정, 실패한 가설, 실행 구조에 관한 관찰은 결과로 인정받기 어렵게 느껴진다.

 

1. 서비스 개발에 대한 문제 의식

처음에는 AI를 활용한 다양한 서비스와 프로젝트를 개발하는 방향도 충분히 고려할 수 있었다. 기존 모델과 API를 이용하면 비교적 짧은 시간 안에 사용자에게 보이는 결과물을 만들 수 있다.

하지만 AI 서비스를 공부하고 구현할수록 몇 가지 한계가 보이기 시작했다.

개인이나 소규모 팀은 충분한 데이터와 학습 자원을 확보하기 어렵다. 서비스의 핵심 성능이 자체 기술보다 외부 모델의 성능에 크게 의존하는 경우도 많다. 겉으로는 AI 서비스처럼 보이지만, 실제 기술적 기여는 API 연결과 인터페이스 구성에 머무르는 사례도 존재한다.

물론 서비스 개발 자체의 가치가 낮다는 의미는 아니다. 실제 기업이나 창업에서는 사용자 문제를 해결하고, 제품을 운영하고, 시장에 전달하는 일이 필수적이다.

다만 개인 프로젝트에서 찾고자 했던 것은 단순한 활용 사례가 아니라, AI 시스템의 동작 원리를 직접 이해하고 개선할 수 있는 기술적 기반이었다.

이 문제의식은 다음 질문으로 이어졌다.

내가 직접 이해하고 통제할 수 있는 기술적 영역은 어디까지인가.

 

 

2. 프로젝트 방향의 변화

프로젝트는 처음부터 컴파일러나 GPU 명령어 분석을 목표로 시작된 것은 아니었다.

초기에는 NumPy 기반으로 기본 연산과 학습 과정을 구현했다. 이는 기존 프레임워크의 기능을 따라 만드는 단계에 가까웠다. 그러나 직접 구현하는 과정에서 추상적인 모델이 실제로 어떤 계산으로 구성되는지 이해할 필요가 생겼다.

이후 Python 구현만으로는 실행 구조와 성능 문제를 설명하기 어렵다는 한계가 나타났다. 이를 해결하기 위해 C++와 Python을 연동하고, 연산자와 런타임 구조를 구현했다. 그 다음에는 CUDA 커널, 메모리 관리, 그래프 실행, CUDA Graph와 같은 하위 계층으로 관심이 이동했다.

커널을 작성한 이후에도 새로운 질문이 남았다.

CUDA 코드와 실제 GPU 실행은 동일한가.
컴파일러는 코드를 어떤 명령으로 변환하는가.
수학적으로 같은 연산은 하드웨어에서도 같은 방식으로 실행되는가.

이 질문을 확인하기 위해 PTX와 SASS를 분석하고, Nsight 도구를 이용해 명령어 배치, 메모리 접근, 의존성, 병목을 관찰하기 시작했다.

겉으로 보면 프로젝트의 방향이 계속 바뀐 것처럼 보일 수 있다. 그러나 전체 흐름은 하나의 질문으로 연결된다.

추상적인 AI 연산은 런타임과 컴파일 과정을 거쳐 실제 하드웨어에서 어떻게 실행되는가.

 

 

3. 관찰은 결과의 반대가 아니다

관찰과 개발 결과를 서로 반대되는 개념으로 생각하기 쉽다.

새로운 기능을 만들거나 성능을 개선한 것은 결과이고, 기존 시스템의 동작을 분석한 것은 준비 과정에 불과하다고 생각할 수 있다.

하지만 기반 기술에서는 정확한 관찰 자체가 하나의 산출물이 된다.

예를 들어 SASS 분석 환경을 구성한 것은 단순히 어셈블리 코드를 읽기 위한 준비가 아니다. 특정 CUDA 코드가 실제로 어떤 명령어로 변환되는지 반복적으로 확인할 수 있는 실험 환경을 만든 것이다.

Nsight Compute를 사용한 것 역시 단순한 도구 사용 경험이 아니다. 커널의 실행 시간만 보는 것이 아니라, 메모리 병목, 명령어 의존성, warp 실행 효율과 같은 원인을 추적할 수 있는 분석 절차를 구축한 것이다.

CUDA Graph를 구현한 것도 기능 추가만을 의미하지 않는다. Capture와 Replay가 어떤 조건에서 효과적이며, 동적 실행 경로에서는 어떤 한계가 발생하는지를 검증할 수 있는 구조를 만든 것이다.

이러한 작업은 즉각적인 성능 개선을 만들지 못할 수 있다. 그러나 이후의 최적화가 추측이 아니라 측정에 근거하도록 만든다는 점에서 의미가 있다.

 

4. 현재까지 얻은 결과

새로운 최적화 기법이 완성되지 않았더라도, 프로젝트를 통해 여러 가설을 검증하고 수정할 수 있었다.

첫째, 연산량을 줄이는 것이 항상 성능 향상으로 이어지는 것은 아니다.

ReLU 이후의 0 값이나 sparse weight를 건너뛰면 연산량은 감소할 수 있다. 그러나 분기 비용, warp divergence, 불규칙한 메모리 접근이 추가되면 실제 GPU에서는 오히려 느려질 수 있다.

둘째, 수학적으로 동일한 연산도 실제 실행은 동일하지 않을 수 있다.

컴파일러의 최적화, 명령어 스케줄링, 레지스터 배치, 메모리 계층의 활용 방식에 따라 실행 결과와 성능 특성이 달라질 수 있다.

셋째, CUDA Graph는 모든 동적 실행을 자동으로 빠르게 만드는 기능이 아니다.

동일한 실행 경로가 반복될 때 Capture 비용을 줄이고 Replay 효율을 얻을 수 있지만, 경로의 종류가 많아지면 캐시 효율과 관리 비용이 문제가 될 수 있다.

넷째, PTX만으로는 실제 GPU 실행을 충분히 설명하기 어렵다.

PTX는 중간 표현이며, 최종적으로 GPU가 실행하는 명령은 SASS 수준에서 확인해야 한다. 성능을 이해하려면 소스 코드, PTX, SASS, 프로파일링 결과를 함께 연결해서 봐야 한다.

이러한 결론은 하나의 새로운 기술처럼 보이지 않을 수 있다. 그러나 잘못된 가정을 제거하고, 이후의 연구 방향을 좁혀 준다는 점에서 실제적인 결과다.

 

 

5. 프로젝트의 현재 위치

현재 프로젝트는 완성된 최적화 제품이라기보다, AI 연산의 실행 구조를 관찰하고 분석하기 위한 실험 기반에 가깝다.

따라서 프로젝트의 가치를 과장해 새로운 컴파일러나 고성능 런타임을 완성했다고 표현하는 것은 적절하지 않다.

대신 다음과 같이 정의하는 편이 정확하다.

AI 연산이 Python 수준의 표현에서 C++ 런타임, CUDA 커널, PTX, SASS로 변환되어 실행되는 과정을 직접 구현하고 추적한 시스템 탐구 프로젝트

이 프로젝트의 핵심 결과는 특정 기능 하나가 아니라 다음 세 가지다.

• 상위 수준의 연산과 하위 수준의 실행을 연결할 수 있는 구현 경험
• 성능 문제를 계층별로 추적할 수 있는 분석 환경
• 기존 가설을 측정하고 수정한 실험 기록

 

 

6. 포트폴리오에서의 제시 방식

이 프로젝트를 단순한 기술 목록으로 제시하면 설득력이 약해질 수 있다.

NumPy, pybind11, C++, CUDA, CUDA Graph, PTX, SASS, Nsight를 순서대로 나열하면 많은 기술을 사용했다는 사실은 전달되지만, 왜 이러한 기술이 필요했는지는 드러나지 않는다.

보다 적절한 구성은 다음과 같다.

문제

상위 수준의 AI 코드만으로는 실제 성능 차이와 병목의 원인을 설명하기 어려웠다.

접근

연산 구현부터 런타임, 커널, 중간 표현, 실제 GPU 명령까지 실행 계층을 단계적으로 추적했다.

구현

NumPy 연산, C++ 연동, CUDA 커널, 그래프 실행 구조, PTX 및 SASS 추출과 분석 환경을 구성했다.

관찰

동일한 연산도 메모리 접근, 분기, 의존성, 컴파일러 스케줄링에 따라 다른 성능을 보였다.

결론

최적화는 연산량 감소만으로 결정되지 않으며, 실제 하드웨어 실행 구조를 기반으로 설계되어야 한다.

다음 단계

현재 구축한 분석 환경을 이용해 명확한 가설과 성능 지표를 가진 최적화 실험으로 확장한다.

 

 

7. 실패와 미완성의 기록

기반 기술 프로젝트에서는 모든 실험이 성공할 필요가 없다.

오히려 중요한 것은 실패한 접근을 숨기지 않고, 왜 실패했는지를 설명하는 것이다.

예를 들어 sparse 연산 스킵이 예상보다 느렸다면, 이를 단순한 실패로 끝내는 것이 아니라 다음과 같이 정리할 수 있다.

• 초기 가설: 연산을 건너뛰면 실행 시간이 감소할 것이다.
• 구현: 조건 분기를 포함한 CUDA 커널을 작성했다.
• 측정: branch divergence와 불규칙한 memory access가 증가했다.
• 결과: dense 연산보다 성능이 낮았다.
• 해석: GPU에서는 규칙적인 병렬 실행이 단순한 연산량 감소보다 중요할 수 있다.

이 구조를 갖추면 실패는 프로젝트의 약점이 아니라, 시스템을 이해한 증거가 된다.

 

 

8. 앞으로의 방향

현재까지의 프로젝트는 관찰과 해석의 단계에 집중되어 있었다.

다음 단계에서는 관찰 범위를 넓히는 것보다, 이미 구축한 환경을 이용해 하나의 좁은 질문을 끝까지 검증하는 것이 중요하다.

예를 들면 다음과 같은 형태가 될 수 있다.

• 특정 epilogue fusion이 memory traffic을 얼마나 줄이는가
• FFMA 의존 체인과 독립 체인의 latency와 throughput 차이는 무엇인가
• CUDA Graph의 경로 캐시가 어떤 반복 패턴에서 손익분기점을 넘는가
• 동일한 연산이 컴파일 옵션에 따라 어떤 SASS 차이를 만드는가

이러한 질문은 범위가 좁고, 결과를 수치로 제시하기 쉽다. 지금까지 구축한 런타임과 분석 도구는 이러한 실험을 수행하기 위한 기반으로 사용할 수 있다.