PyTorch를 '참조 언어'로 다시 보기: 연구용 구현과 배포용 구현의 분리

딥러닝을 다뤄 본 개발자라면 PyTorch를 '현대 딥러닝의 링구아 프랑카'라고 부르는 표현에 익숙할 것이다. 그런데 이 비유는 곱씹을수록 모순처럼 보인다. 참조 구현(reference implementation)은 보통 성능을 희생하는 대신 명료함을 얻는, 시스템의 단순하지만 완결된 판본을 뜻한다. 참조 구현은 대개 프로덕션에 배포하지 않는데, 정작 우리는 PyTorch로 실제 학습 잡을 돌린다. 커널을 짜는 사람은 죄다 커널 DSL을 쓰는데, 그렇다면 커널을 이어 붙이는 접착제에 불과한 PyTorch의 역할은 무엇인가. 나아가 AI 코딩이 성숙하면 어떤 스택이든 통째로 다시 짤 수 있을 텐데, 특정 코드가 PyTorch로 쓰였다는 사실이 왜 중요한가. 이 글의 원저자는 이런 질문들에 대해 PyTorch가 참조 언어이자 동시에 구현 언어라는 이중 역할을 한다는 관점을 제시한다.

참조 구현과 프로덕션 구현의 분리

핵심 아이디어는 이렇다. 규모가 지나치게 크지 않거나 컴파일러가 충분히 잘 작동할 때는 참조 구현을 그대로 프로덕션에 태울 수 있다. 그러나 규모가 커질수록 참조 구현은 실제 프로덕션 구현과 별개로 존재하는 소프트웨어 산출물로 취급하는 편이 자연스러워진다. 연구는 참조 구현 위에서 하고, 확장은 프로덕션 구현으로 하며, 그 둘이 실제로 같은 계산을 하는지는 별도의 검증기(verifier)로 확인한다. 하나의 코드베이스가 세 가지 관심사를 억지로 짊어지는 대신, 역할을 명시적으로 쪼개자는 제안이다.

이 구도가 가장 선명하게 드러나는 곳이 요즘의 커널 DSL 사용 방식이다. 전통적인 컴파일러 극대주의 관점은 사용자가 넘파이나 PyTorch 스타일의 고수준 API로 신경망 모듈을 기술하면 컴파일러가 알아서 최적 형태로 낮춰 주어야 한다고 본다. 그러나 행렬 곱이나 어텐션처럼 가장 중요한 연산에서 컴파일러가 최고 성능을 보장하기란 쉽지 않다. 그래서 타일링과 데이터 이동을 직접 명시해 최적 성능을 얻게 해 주는 커널 DSL이 널리 퍼졌다. 그렇다고 고수준 API가 사라졌는가 하면 그렇지 않다. 대부분의 커널 작성자는 최적화된 커널과 나란히 평범한 PyTorch 참조 구현을 유지하면서 수치 테스트로 정확성을 대조한다.

코딩 에이전트가 학습 스텝에 가져오는 변화

원저자는 커널 DSL이 연산자 구현 방식을 바꿨듯, 코딩 에이전트가 학습 스텝(train step)의 프로덕션 구현 방식을 바꿀 것이라고 본다. 전통적으로 autograd는 PyTorch 가치 제안의 핵심으로 여겨졌다. 미분을 자동으로, 그리고 정확하게 얻을 수 있기 때문이다. 그러나 대규모에서는 암묵적으로 생성되는 역방향 그래프가 오히려 목을 죄는 짐이 된다. 연산의 상당 부분이 눈에 보이지 않게 숨겨져, 일반적인 디버깅 도구로 들여다보거나 순방향 코드처럼 자유롭게 퓨전을 적용할 여지가 사라지기 때문이다. 컴파일러로 패턴 매칭을 걸어 역방향 그래프를 손볼 수는 있지만, 이는 깨지기 쉽고 참조 구현의 호출부를 손수 작성한 커널로 바꿔 끼우는 것보다 경험이 나쁘다.

그래서 제안되는 새 레시피는 다음과 같다. autograd 친화적인 기존 PyTorch 코드를 참조 구현으로 남겨 둔다. 그리고 LLM으로 순방향과 역방향이 명시적으로 풀어 쓰인 판본을 생성해, 이를 참조 구현과 독립적으로 최적화한다. 패턴 매칭과 달리 최적화가 적용에 실패할 걱정을 하지 않아도 된다는 것이 장점이다. 대신 참조 구현과 실제 구현이 서로 어긋날 수 있다는 비용이 따르므로, 둘이 동치임을 보여 주는 검증기가 필요하다. 이 검증기는 비트 단위 동치 테스트처럼 단순하게 만들 수도 있고, 그래프를 캡처해 구조적 동치를 따지는 번역 검증(translation validation) 방식으로 구현할 수도 있다. 한쪽에만 있는 퓨전 때문에 검증이 막힐 때는, 그 퓨전의 참조 구현(일종의 역방향 패턴 매칭)을 제공해 주면 된다.

실무자가 새겨 둘 점과 한계

한국의 실무자 입장에서 이 관점이 유용한 이유는, 그동안 흐릿했던 세 축을 명확히 갈라 준다는 데 있다. 실험을 빠르게 돌려야 하는 연구 코드, 최고 성능을 뽑아야 하는 배포 코드, 그리고 둘의 등가성을 지키는 검증 코드는 서로 다른 요구를 가진다. 이를 한 파일에 뭉뚱그리면 디버깅과 최적화가 모두 어려워지지만, 참조 구현을 실행 가능한 명세(executable spec)로 못 박아 두면 최적화 판본이 아무리 공격적으로 갈라져도 정확성이라는 기준선을 잃지 않는다. 커널 작성자가 이미 관행적으로 해 오던 '참조 구현 + 수치 테스트' 패턴을, 학습 스텝 전체로 확장하는 셈이다.

다만 원저자 스스로 이 레시피가 모두에게 정답이라고 주장하지 않는다는 점은 분명히 해 둘 필요가 있다. 결국 중요한 것은 필요한 실험 결과를 얼마나 빨리 얻느냐이며, 규모가 크지 않다면 참조 구현을 그대로 배포하는 편이 여전히 합리적이다. 또한 이 글은 구체적인 도구나 벤치마크 수치가 아니라 방향성과 사고 틀을 제시하는 논평에 가깝다. 명시적 순역방향 코드를 생성하는 아이디어 자체는 새롭지 않으며, 지금은 사라진 Tangent 라이브러리도 소스 대 소스 자동 미분의 유용성 위에 세워진 바 있다. 원저자는 Horace He가 지난해 던진 질문, 즉 '이거 실행(eager) 모드의 제어권을 온전히 유지하면서 그래프 수준 추상화의 편의를 일부 누릴 방법은 없는가'에 대한 유망한 답으로 이 레시피를 꼽으며, 그 중심에 PyTorch가 계속 자리한다고 본다.