텐서플로우 혁명? 적재적소에 써야 혁명이다

데이터 처리 기준이 열에서 행렬로, 행렬에서 텐서로 전환되면서 데이터 과학 범위 확대돼 
올바른 접근 방식으로 도구를 적재적소에 적용할 때만 더 나은 결과 얻을 수 있어
기술의 발전을 아무 생각 없이 받아들이기보다는 그 기술이 ‘왜’ 필요한지 생각하는 자세 필요해

학부 시절인 2000년대 초로 돌아가보면, 기초적인 회귀분석 문제를 풀기 위해 매트랩(Matlab)을 처음 배웠다. 당시 매트랩은 혁명이었는데, 그 이유는 ‘행렬’로 데이터를 처리하기 때문이다. 다른 소프트웨어가 ‘열’ 단위로 데이터를 처리하는 것과 달리, 매트랩은 ‘행렬’ 단위의 큰 데이터를 한 번에 적재하기 때문에 처리 속도가 O(nxk)에서 O(n)으로 빨라졌다. 좀 더 정확하게 말하면, RAM이 소프트웨어로부터 데이터 받는 방식을 고려하면 O(k)에서 O(1)으로 빨라졌다.

매트랩은 행렬 방식으로 데이터를 처리할 뿐만 아니라 매트랩 코드를 C 코드로 빠르게 변환해줘 큰 인기를 얻었다. 복사 버전에도 10,000달러가 훨씬 넘었지만, R&D에 승부를 보는 기업과 STEM 연구 시설을 갖춘 대학은 모두 매트랩에 뛰어들었다. 매트랩의 전성기는 영원할 것처럼 보였지만, 매트랩과 같은 방식으로 데이터를 처리하는 R이라는 “무료” 소프트웨어가 등장했다. 게다가 R은 자체 데이터 처리 방식도 만들어 루프를 매트랩보다 더 빠르게 계산했다. 내가 장난삼아 R스타일(강남스타일처럼)이라고 부르는 이 계산은 루프 데이터 처리를 열에서 행렬로 바꿨다.

모든 상황에서 우월한 프로그래밍 언어는 없어, 상황에 맞는 언어 선택해야

그러나 R도 영원하지 않았다. 당시 R스타일을 맛보고 R을 주로 사용했으나, 허수를 처리하지 못한다는 치명적인 단점을 발견했다. 손으로 고생해서 푼 답안을 R로 돌렸을 때와 메트랩으로 돌렸을 때의 결과가 달랐다. R 또한 만능이 아니었음을 느끼고 눈을 돌리던 중 매스매티카(Mathematica)를 만났다. 하지만 매스매티카가 너무 비싸서 연구 동료들과 소통하는 데는 여전히 R을 썼다. 요즘은 파이썬이 학계와 산업 가리지 않고 많이 사용된다. 3D계산에 특화된 텐서플로우(Tensorflow)와 파이토치(PyTorch)까지 좋은 파이썬 패키지가 많이 나와 전성기를 맞았다. 그럼에도 나는 파이썬으로 코딩하는 것을 별로 좋아하지 않는다. 왜냐면 나한테 딱히 필요 없다. 텐서플로우는 R에서도 사용할 수 있고, 파이썬에서 속도 향상이 그다지 크지 않았다. 텐서플로우가 필요한 다차원 작업에서는 매트랩으로 코딩한 후 C로 변환해서 사용하면 그만이었다. 처음에는 약간의 버그가 있었지만, 역시나 매트랩의 비싼 가격은 그만한 가치가 있었다.

몇 년 전에 R, 파이썬 문법과 비슷하지만 계산 속도가 C와 비슷하고 수많은 파이썬 패키지를 지원하는 줄리아(Julia)를 발견했다. 내가 코딩 전문가는 아니지만 파이썬보다 줄리아에서 더 큰 발전 가능성을 봤다.

이런 이야기를 하다 보면 항상 듣는 질문이 있다. “왜 여러 프로그래밍 언어를 이것저것 쓰세요? 한 가지 언어만 써도 되지 않나요?” 라는 질문이다. 아니면 다른 언어가 필요할 정도로 내 수학 모델이 훨씬 더 발전했는지 물어본다. 일단 후자에 대한 답은 ‘아니요’다. 내 수학 모델은 단순한 편이다, 적어도 나한테는. 그럼 왜 매트랩에서 R, 매스매티카, 파이썬, 줄리아로 계속 바꿔쓸까? 그건 필요에 따라 언어를 바꿔쓰는 것이지, 나한테 익숙해진 언어를 고집할 필요가 전혀 없기 때문이다. 상황에 언어를 맞줘야지, 그 언어를 쓰기 위해 상황을 만드는 게 아니다.

발전된 기술을 일단 쓰고 보는 게 아니라, ‘왜’ 써야 하는지 고민해야

매트랩 이전에는 Q-Basic으로만 프로그래밍 해왔기 때문에, ‘행렬’ 기반의 계산이 얼마나 빠른지 체감하지 못했다. 하지만 루프 계산을 위해 매트랩에서 R로 바꿨을 때, 신세계를 맛보고 거의 울 뻔했다. 마치 어릴 적에 크리스마스 선물로 내가 오랫동안 꿈꿔왔던 콘솔 게임기가 들어 있는 것 같은 기분이었다(요즘은 뭘 받으면 이렇게 기쁠까?). 덕분에 그동안 해결하지 못했던 수많은 문제를 해결할 수 있었고, 답안을 코딩하는 방식도 많이 바꿨다.

비슷하게 ‘텐서플로우’를 처음 접했을 때 똑같은 경험을 했다. 내 전공분야에서는 이미지와 텍스트같은 Low-noise 데이터를 다루지 않아서, 공대애들이 얘기하는 텐서플로우에 관심을 갖지 않았다. 하지만 매트랩에서 R로 전환하면서 겪었던 신세계를 떠올리고 생각을 바꾸게 되었다. 내 전공분야에서도 패널 데이터와 다중 소스 시계열같이 3D 데이터를 처리하는 도구가 없어, 3D를 행렬 형태로 다시 배열하는 데이터가 무수히 많음을 깨달았다. 텐서플로우를 사용한 이후로 항상 3D 데이터 구조를 활용하여 코딩 작업을 최소화할 수 있는 방법을 고민했다.

일단 성공하면 코드짜는 시간을 절약할 뿐만 아니라 결과가 나오는 데 기다리는 시간이 엄청 줄어든다. 박사 과정 중 코드 실행 시간이 너무 오래 걸려서 큰일 났던 적이 있다. 그 날은 다음 날 지도 교수님과의 미팅이 예정되어 있던 날 밤이었다. 내 계산에서 조금 사소한데, 그로 인해 치명적인 오류가 발생한 것을 발견했다. 손으로 풀어 해를 다시 구할 수 있었지만, 다음 날 아침까지 노트북에서 완벽한 시뮬레이션 결과가 나오지 않을 것이라고 확신했다. 그러면 안 됐지만 나는 시뮬레이션을 속이고 가짜 그래프를 만들었다. 역시나 지도교수님은 몇 초 만에 내 시뮬레이션에 문제가 있다는 것을 정확히 지적하셨고, 나는 가짜 그래프 그린 걸 고백했다. 그 사건 이후로 지도교수님의 신뢰를 얻기까지 몇 년이 걸렸던 기억이 난다. 요즘이라면 빠른 계산속도로 시뮬레이션을 속일 필요가 없었을 텐데 하는 아쉬움이 있다. 이제 성능 좋은 컴퓨터는 있으니 빠르고, 정확하고, 정직하게 처리할 수 있는 내 “두뇌”가 필요할 뿐이다.

H100 도입 이후 많은 LLM 연구원들이 대용량 데이터 처리에 대한 부담이 줄었다. AI 칩이 점점 빨라지면서 주어진 시간 내에 처리할 수 있는 데이터의 크기도 기하급수적으로 늘어났다. 분명 나처럼 계산 속도 때문에 개고생하는 경우는 사라졌겠지만, 항상 “그래서 수백 개의 H100이 대체 어디에 필요한데?”하고 자문한다.

기술 발전으로 빠른 컴퓨터 처리와 저렴한 컴퓨팅 비용으로, 이전에는 불가능했던 일을 할 수 있게 됐다. 하지만 여전히 ‘어디에’, ‘왜’ 그게 필요한 지에 대한 답을 찾아야 한다. H100은 단순히 trial and error를 더 빨리 하라고 만들어진 게 아니다. 요즘 학생들을 보면서 느낀 것은 컴퓨터 성능이 과제를 해결하는 데 중요한 요소가 아닌 것 같다. 옛날에는 코드 돌아가는 속도가 너무 느려, 코드를 실행하기 전에 엄청난 고민을 했다. 어떻게 하면 코드가 빨리 돌아가고, 오류는 없는지 등 여러 고민과 논리적 사고 흐름을 거치고 코드를 돌렸다. 하지만 요즘은 엔터를 누르자마자 결과가 바로 튀어나오는 세상이다. 자연스럽게 코드에 대한 깊은 고민도 사라지고 무한 trial and error를 통해 과제 답안을 찾아낸다. 이건 제대로 된 컴퓨팅 성능의 이점이 아니다. 여전히 코딩할 때 최적화를 고민하고 코드에 문제가 없을지 생각하고 코딩을 해야 진정한 컴퓨터 성능의 발전을 누릴 수 있다. 자신이 컴퓨터를 학대하고 있는 건 아닌지, 컴퓨터 성능을 제대로 활용하고 있는지 자문해보길 바란다.