"GPU, 얼마나 다뤄봤나요?" 남들과 다른 인프라 엔지니어가 되는 법

몇 년 전, Glen은 당시 다니던 회사에서 시스템 개선안을 제안했다. 그러나 논의의 초점은 개선안의 가능성보다, 그에게 시스템을 바꿀 권한이 있는지에 맞춰졌다. 하루에도 수조 원이 오가는 시스템이니 쉽게 건드릴 수 없다는 것이었다. 그 반응을 통해 Glen은 자신이 원하는 방식으로 일하기 어려운 곳이라고 판단했다. 3주 뒤, 그는 회사를 떠났다.

지금 Glen은 트웰브랩스에서 모델 학습을 위한 학습클러스터 전체의 설계와 운영을 맡고 있다. 인프라 정책도, 자동화 시스템도 대부분 그가 직접 정의하고 만든다. 무엇이 바뀐 걸까. 9년 차 엔지니어 Glen에게, 무엇을 만들고 있는지, 그리고 그 이유는 무엇인지 물었다.

Q. 원래 백엔드 개발자셨다고 들었어요. 인프라, 그중에서도 AI 인프라까지 오시게 된 계기가 있으신가요?

저는 지금 9년 차 엔지니어인데, 사실 원래는 백엔드 엔지니어로 시작을 했었어요. 그런데 어느 순간 백엔드 개발이 재미가 없어지더라고요. 학교에서 배웠던 고도화된 알고리즘을 만든다기보다, 데이터를 넣었다 뺐다 하는 반복 작업으로 느껴졌어요. 그래서 일부러 여러 가지 일을 해볼 수 있는 초창기 스타트업에 들어갔어요. 창업에 대한 꿈도 있었거든요. 거기서 devops 관련된 일을 처음 접했고, 패션 커머스 스타트업과 대규모 이커머스 회사를 거쳐, 지금 이렇게 트웰브랩스까지 왔습니다.

Q. 익숙한 커머스 인프라를 떠나 영상 AI라는 새로운 분야, 그중에서도 트웰브랩스를 선택하신 계기는 무엇이었나요?

직전 회사는 규모가 커지면서 대기업의 조직문화를 따르게 되었어요. 그러다 보니 뭔가 하나 하려면 엄청나게 많은 서류 작업이 필요해졌어요. 결재 단계만 5단계였거든요. 게다가 일하면서 마주치는 문제의 해결 방법이 이미 다 정해져 있으니 사실 재미가 없었죠.

그러던 중 트웰브랩스를 알게 됐는데, '이거 되게 재밌겠는데?'라는 생각이 들었어요. 저는 이때까지 CPU 기반으로만 일해 왔는데, 여기는 제가 한 번도 프로덕션에서 다뤄본 적 없는 한정된 자원, GPU를 다루는 곳이었거든요. 그게 확 끌렸습니다.

그리고 예전 회사에서는 사실 어떤 일을 해야 할지 이미 다 알고 있었는데, 영상 데이터를 다루는 건 저한테도 한 번도 안 해본 미지의 영역이었어요.

Researcher 분들이 학습시키는 게 결국 영상을 진짜로 '이해하는' 모델이잖아요. 몇 시간짜리 영상의 맥락을 이해하고, 그 안에서 텍스트 몇 줄로 원하는 장면을 바로 찾아내는 거요. 제가 GPU를 안정적으로 돌아가게 만들어야 그런 모델이 하루라도 더 빨리 나올 수 있다고 생각하면 재밌어요. 결국 제 일이 그 앞단에 있는 거니까요.

Q. 인프라라는 게 어느 회사나 필요한 영역이잖아요. 그런데 AI 회사의 인프라는 일반적으로 경험하셨던 SaaS나 백엔드 인프라랑 어떤 부분이 다른가요?

대부분의 웹 서비스는 CPU 중심으로 운영돼요. 클라우드에서 수요에 맞춰 서버를 늘리거나 줄이는 방식이죠. CPU 서버도 할당량이나 가용 용량 같은 제약은 있지만요.

그런데 지금 저희가 운영하는 학습 환경은 확보한 GPU 자원 안에서 여러 작업을 배분해야 해요. 필요하다고 바로바로 늘릴 수 있는 상황은 아니거든요. 그러다 보니 이 한정된 자원 안에서 Researcher 분들이 얼마나 효율적으로 학습을 돌릴 수 있느냐를 가장 중요하게 봐야 해요. 그리고 제일 중요한 원칙 하나는, Researcher가 인프라의 세부 운영 방식을 몰라도 연구에 집중할 수 있게 해야 한다는 거예요. 그분들은 이 학습 클러스터의 사용자니까요.

Q. 그러면 지금 가장 집중해서 풀고 있는 문제는 어떤 건가요?

학습 클러스터를 운영하다 보면 다양한 오류를 만나게 돼요. GPU 자체뿐 아니라 드라이버나 GPU 간 통신 등 여러 계층을 함께 살펴봐야 하거든요. 제가 처음 입사했을 때는 이걸 잡아내는 관측성이 아예 없었어요. 고장 나면 기다리거나, AWS에 연락하거나, 교체 요청을 하는 게 다였죠. 그런데 덕분에 오히려 관측성부터 자동화까지, 제가 원하는 방식대로 처음부터 다 설계할 수 있었어요. Xid 같은 GPU 오류 로그와 상태 정보를 바탕으로 소프트웨어 문제인지, 하드웨어 이상이 의심되는지부터 살펴보고, 재부팅으로 복구를 시도할 수 있는 경우와 AWS에 직접 문의해야 하는 경우를 자동으로 분류하는 시스템을 만들었어요. Xid가 떴다고 무조건 하드웨어 고장인 건 아니라서, 오류 종류와 다른 증상을 같이 봐야 해요. 솔직히 말하면 제가 좀 덜 일하고 싶어서 만든 것도 커요(웃음). 학습은 쉬지 않고 24시간 돌아가야 하거든요. 

Q. 이커머스 시절과 비교하면, 인프라 역할을 맡으면서 새롭게 배우거나 다르게 봐야 했던 부분이 있으셨나요?

기존에 제가 운영하던 서비스는 레이턴시가 제일 중요했어요. 제품 페이지를 보는데 로딩이 1초 넘거나. 결제 눌렀는데 로딩 화면이 오랫동안 지속되면 고객들이 불편함을 호소하죠. 그래서 레이턴시가 일정 수준을 넘으면 바로 연락이 오도록 하였고, 레이턴시를 최적화하는 것이 목표였어요.

저희 팀에서 운영하고 있는 인프라 중 하나는 모델을 학습시키기 위한 학습 클러스터예요. 그래서 중요하게 보는 지표가 B2C 서비스와 달라요. 한정된 GPU로 학습을 얼마나 효율적으로 진행하고 끝까지 마칠 수 있느냐가 운영 목표예요. 예를 들어 '학습이 3,100스텝까지 진행됐는데 그다음에 실패했어요' 같은 문제가 중요하죠. 실패했을 때 얼마나 빨리 복구하고, 이미 진행한 학습을 얼마나 덜 잃는지도 중요하고요.

물론 분산 학습에서도 GPU 간 통신 지연은 성능에 영향을 줘요. 다만 제가 일상적으로 마주하는 문제가 B2C 서비스의 응답속도에서 학습의 진행과 효율로 바뀐 거죠. 완전히 다른 언어로 대화하는 느낌이라 저도 계속 배우고 있어요. 이렇게 새로운 문제에 도전하고 배우는 과정 자체가 재밌더라고요.

Q. 빠른 개발, 안정성, 성능, 비용... 트레이드오프가 있을 것 같아요. 특히 어려우셨던 부분이 있으셨나요?

제가 일했던 이커머스 환경에서는 결제 실패 같은 문제를 막기 위해 변경을 신중하게 검증하는 게 중요했어요. 그런데 여기 와서는 연구 실험과 개선을 빠르게 반복하는 속도도 중요하게 느껴져요. 하루에도 학습 작업이 수십 건씩 돌아가야 하니까요. 학습을 안정적으로 돌리는 것도 중요하고, 연구에 필요한 변경을 빠르게 반영하는 것도 중요한 거죠.

예전엔 배포도 Local Dev, Alpha, Beta, QA 환경을 다 거치고 PM이 일정까지 관리했는데, 학습용 환경은 문제를 발견하면 즉각적으로 수정해서 반영하는 식이에요. 그래서 마음 한구석은 아직도 좀 불안하긴 한데(웃음), 그만큼 다들 자율성을 갖고 빠르게 움직일 수 있다는 게 좋은 것 같아요.

Q. 인프라 엔지니어로서 리서치 엔지니어링이나 ML 엔지니어링, 백엔드 같은 다른 팀들과는 어떻게 협업하시나요? 조직 안에서 갖는 영향력은 어느 정도인지 궁금합니다.

솔직히 말하면 저희 팀 영향력이 생각보다 꽤 커요(웃음). 인프라 설계나 구현, 플랫폼까지 저희가 다 담당하다 보니까 저희가 협의해서 정한 정책이 실제 인프라 운영의 기준이 되거든요. 그런데 이게 탑다운은 아니에요. 저희가 먼저 아이디어를 생각해서 Researcher 분들한테 '이런 아이디어 어떻게 생각하세요' 물어보고, 필요하다고 하면 그때 내부적으로 검토해서 만들어요. 회의도 정말 수평적이에요. 팀 리더가 있어도, 회의할 때 보면 누가 리더인지 모를 정도로 다 같이 얘기해요. 뭔가 정해지면 다음 날 바로 구글 독스로 공유되고요. 이전 회사들이라면 상상도 못 했던 방식이에요.

Q. GPU 자원을 두고 Researcher들과 우선순위를 조율하는 게 쉽지 않을 것 같아요

맞아요. 얼마 전부터 Kueue를 활용해 학습 작업의 실행 순서와 GPU 자원 배분을 관리하는 시스템을 시험 운영하고 있어요. 정해진 우선순위 정책에 따라, 필요한 경우 실행 중인 낮은 우선순위 작업을 중단하고 높은 우선순위 작업이 먼저 자원을 쓰게 하는 방식이에요. 이런 선점 정책에 대한 반발이 엄청 심했어요. 아무래도 다들 자기 작업이 제일 중요하다고 생각하니까요(웃음). 하지만 한정적인 자원 안에서 운영하기 위해서는 이런 프로세스가 꼭 필요하다고 생각해요.

Q. 그럼 이 팀에는 어떤 분들이 잘 맞을 것 같다고 생각하세요?

종합해서 말씀드리면, 기술 스택이 넓고 새로운 걸 배우는 데 주저함이 없는 분이 잘 맞을 거라고 생각해요. 인프라 엔지니어링이 중심이지만 ML Ops, Cost optimization, Security, Observability, Packaging과 같은 폭 넓은 영역을 담당하고 있거든요. 그래서 연차와 상관없이 '잘 모르는 것도 필요하면 배워서 해보겠다'는 태도가 중요해요.

반대로 본인이 잘하는 영역이나 정해진 역할 안에서만 일하는 걸 선호하는 분이라면 어려움이 있을 것 같아요.

작고 민첩한 팀에서 높은 자율성과 오너십을 가지고 복잡한 문제를 풀며 큰 임팩트를 만들어내고 싶다면, 저희 팀은 정말 재미있게 일할 수 있는 환경일 거에요.

Q. 마지막으로, 트웰브랩스에서 인프라를 만든다는 건 어떤 의미라고 생각하시나요?

제가 드릴 수 있는 한마디는 '남들과 다른 인프라 엔지니어가 될 수 있다'는 거예요. 이커머스에는 devops 하는 분들이 정말 많아요. 그런데 '난 B300을 몇백 장 다뤄봤어'라고 하면 이야기가 다르잖아요. 그런 흔치 않은 경험을 하고 싶으시다면, 저희 팀에 오시면 됩니다.

Glen은 트웰브랩스의 Infrastructure Engineer입니다. 트웰브랩스에서 함께할 엔지니어 분들을 찾고 있습니다 
→ Senior Infrastructure Engineer
    Senior Platform Engineer