안녕하세요, 래블업에서 Technical Writer로 일하고 있는 허진호입니다. 저희 래블업은 지난 10월 26일부터 10월 27일까지 수원 컨벤션센터에서 개최된 파이콘 한국 2024에 플래티넘 스폰서로 참여했습니다.

래블업의 창업 이념은 오픈소스와 큰 연관이 있습니다. 래블업의 피에는 오픈소스가 흐르고 있다고 해도 과언이 아니죠. 다양한 오픈소스들이 있지만, 그중에서 래블업은 특히나 파이썬과 인연이 깊습니다. 래블업은 asyncio를 이용하여 개발된 aiohttp와 같은 오픈소스에도 적극적으로 기여하고 있고, 파이썬 그 자체에도 기여하고 있습니다. 파이썬뿐만이 아니라 파이콘과도 인연이 깊죠. 래블업의 구성원들은 그동안 전세계 파이콘에서 다양한 주제의 발표를 해 왔고, 파이콘 한국에는 총 다섯 번 후원사로 참여하며 그 인연을 이어오고 있습니다.

이번 파이콘은 래블업에게도 뜻깊은 행사였습니다. 래블업의 신정규 대표와 김준기 CTO가 파이콘 양일 기조연설자로 나섰기 때문인데요, 신정규 대표는 'Python과 PyCon과 공룡시대와 닭들의 행성'이라는 주제로 발표를 진행했습니다. 언뜻 보면 혼란스러운 제목이지만, 진화에서 1차적으로 승리했던 공룡에 두 가지 파이썬의 성질을 비유한 것입니다. 하나는 파이썬의 급격한 성장과 1위 언어로의 등극, 그리고 엄청난 연산으로 혁신을 만들어내는 대 AI 시대의 핵심 언어라는 성질입니다. 이는 현대에서 가장 많이 소비되는 육류인 '닭'으로 연결되는데요, 특유의 접근성과 범용성으로 누구나 쉽게 배운 후에 활용할 수 있는 성질이 닭과도 같다는 뜻이었다고 하네요. 특유의 재치있는 제목과 말솜씨, 다양한 AI 생성 그림으로 청중을 휘어잡은 신정규 대표의 발표는 청중의 많은 호응을 받았습니다.

김준기 CTO는 '파이콘과 나의 10년 돌아보기'라는 주제로 발표를 진행했습니다. 총 4개의 챕터로 구성된 이번 발표는 세계 각지에서 파이콘과 함께했던 발표를 돌아보며 asyncio와 함께 했던 성장으로 시작해 확장되는 회사의 규모, 그리고 코드의 확장에 대응해나가는 과정, 어떻게 하면 다른 파이써니스타들에게 영감을 줄 수 있을지에 대해 다뤘습니다. 개발자라면 마주했던, 혹은 마주할 수 있는 문제를 쉽게 풀어내 대중의 많은 박수를 받았습니다.

래블업 조규진 선임 소프트웨어 엔지니어, 세르게이 렉시코브 리서처, 김준기 CTO

또한 조규진 래블업 선임 소프트웨어 엔지니어와 세르게이 렉시코브 리서처, 김준기 CTO가 각각 세션 발표를 진행했는데요, 조규진 선임 소프트웨어 엔지니어는 '자동화된 파이썬 웹 프레임워크 API Schema 제작기: The long way around'를 주제로 aiohttp를 사용하며 겪었던 API 문서 자동 생성의 어려움을 극복하기 위해 거쳤던 일련의 삽질기를 청중과 공유했습니다. 세르게이 렉시코브 리서처는 'Automating CLI commands execution with LLM and LangGraph: A new frontier in Python automation'이라는 주제로, 복잡한 CLI를 LLM과 LangGraph 프레임워크를 사용하여 사용자 친화적인 도구로 변환하여 사용자 경험과 운영 효율성을 향상시키는 방법에 대해 발표했습니다. 두 발표 모두 많은 청중을 모으며 뜨거운 관심을 받았습니다. 김준기 CTO 역시 세션 발표를 통해 '엔터프라이즈 공급을 위한 파이썬 엔지니어링'이라는 주제로 파이썬 앱 공급을 위한 패키징/인스톨러 개발 사례를 나눴습니다.

👨‍🏫 허진호: 파이콘 세션 발표 후기가 궁금합니다.

👨‍💻 세르게이 렉시코브: 발표를 영어로 진행했음에도 파이콘 한국 측에서 실시간 통번역 시스템을 지원해주었기 때문에 문제 없이 발표를 마칠 수 있었습니다. 세션이 끝나고 나서 몇몇 열성적인 청중들이 다가와 발표 주제에 대한 질문을 했던 점이 가장 기억에 남습니다.

'AI 그림 판독기' 이벤트 (오리와 백조 그리기)

래블업은 이번 파이콘 한국 2024의 부스 이벤트로 'AI 그림 판독기' 이벤트를 개최했습니다. 파이콘 한국 2024에 참여한 참가자들은 QR코드를 통해 개개인의 휴대전화 혹은 태블릿, 노트북에서 이벤트 페이지에 접속해 '오리와 백조'를 그려 경품에 도전할 수 있었습니다. 참여만 해도 래블업 폴딩 파우치를 받을 수 있었고, 종합 1등을 한 참가자는 스타벅스 기프트카드를 받아갈 수 있는 아주 멋진 이벤트였죠.

래블업이 행사마다 들고 다니는 스티커

왜 하필 오리와 백조냐고요? 저희가 행사에 항상 가져다니는 스티커에는 귀여운 오리와 백조가 그려져 있습니다. 이 친구들은 물 위에서는 도도하게 떠 있지만, 수면 밑에서는 물위에 떠 있기 위해 열심히 발을 휘젓고 있는 것으로 알려져 있는데요, 우리 스티커 역시 고객이 도도하게 수면 위에서 AI 서비스를 하는 동안 Backend.AI가 그 밑의 일을 담당하겠다는 비유적인 의미를 가지고 있죠.

이벤트의 내용은 간단합니다. 텍스트를 입력하면 그림을 생성해 주는 생성형 AI를 이용하여, 주어진 그림과 가장 가까운 그림을 그려내는 이벤트죠. 아마 Stable Diffusion이나 Dall-E 같은 생성형 AI 솔루션을 이용해 그림을 그려본 분들이라면 아시는 내용이겠지만, 생성형 AI는 입력에 따라 출력이 결정되는 매우 민감한 구조를 가지고 있습니다. 같은 입력값을 활용해도 매 번 출력값이 달라지기도 하고, 약간만 입력을 변형해도 전혀 다른 결과가 나오기도 하죠. 이처럼 원하는 결과물을 생성해내기 위해 생성형 AI를 가르치는 (안내하는) 과정을 우리는 '프롬프트 엔지니어링'이라고 부릅니다. 저희 부스에서 이벤트를 참여하신 모든 분들은 '나만의 작은 프롬프트 엔지니어링' 과정을 체험해 보신 셈입니다.

우리의 'AI 그림 판독기' 이벤트 백엔드 개발을 담당했던 조규진 선임 소프트웨어 엔지니어에게 개략적인 설명을 부탁드렸습니다.

👨‍🏫 허진호: 'AI 그림 판독기' 이벤트 페이지가 어떻게 만들어졌는지 설명 부탁드립니다.

👨‍💻 조규진: 'AI 그림 판독기' 이벤트 페이지 백엔드는 총 세 가지의 마이크로서비스로 구성되었습니다. 첫 번째는 WAS (Web Application Server), 두 번째는 이미지 생성 파이프라인, 세 번째는 이미지 유사도 판별 파이프라인입니다. WAS는 사용자 데이터베이스와 이미지 생성 요청 처리 API로 구성되어 있습니다. 이 모든 마이크로서비스는 Backend.AI에서 'Model Service' 기능을 통해 배포되었습니다. 저희 리서치 팀의 세르게이님이 만드신 Visutale 데모처럼, 저희 Backend.AI에서 AI 서비스 개발의 모든 것이 가능하다는 데모의 성격으로 봐 주셔도 좋을 것 같습니다.

👨‍🏫 허진호: 구체적으로 어떤 프로세스를 통해 사용자의 그림과 주어진 그림과 유사도가 나오게 되는 것인가요?

👨‍💻 조규진: 사용자가 QR 코드를 통해 접속한 페이지에서 프롬프트를 입력, 이미지 생성을 요청하면 WAS가 이미지 생성 서비스에 텍스트를 전달하고, 생성된 이미지를 반환받습니다. WAS는 생성된 이미지를 다시 유사도 판별기에 전달하고, 유사도 판별기로부터 퍼센트로 계산된 유사도를 돌려받아 사용자에게 생성된 그림과 함께 전달합니다.

👨‍🏫 허진호: 어떤 기준으로 그림을 그려야 높은 점수를 받을 수 있나요?

👨‍💻 조규진: 이미지 유사도 판별 파이프라인이 무슨 기준으로 유사도를 판별하는지는 저도 알 수 없습니다. 아마 AI에게 직접 물어보는 것이 답변을 얻는 더 좋은 길일지도 모릅니다.

어마어마한 참여도

사실 모든 서비스를 만들어낸 당사자들이 그렇듯이 저희 구성원들은 이 이벤트를 '소소한 이벤트'라고 생각했습니다. 그러나 그 생각이 깨지는 데는 한 시간이 채 걸리지 않았습니다.

래블업 부스에는 사람들이 몰리기 시작했고, 부스 앞에는 본인의 순위를 확인하고 상위권을 사수하기 위한 사람들이 리더보드를 목빠져라 쳐다보고 있는 진풍경이 연출되었습니다.

심지어 라운지에 앉아 있는 사람들이 휴대전화 화면을 뚫어져라 쳐다보며 백조를 그리고 있었다는 증언도 있었죠.

통계를 살펴볼까요?

10월 26일, 27일 양일간 이벤트에 참가하신 분은 총 428분이었습니다. 해당 기간 제출된 이미지 생성 요청은 '11639'건에 달했습니다. 이 중에서 한 사람이 제출한 최대 응답은 1000여건을 훌쩍 뛰어넘어 모두를 경악하게 했답니다. (비밀은 뒤에...)

의도치 않은 부작용도...

부스에 앉아 리더보드를 살펴보고 있는 와중에 익숙한 두 개의 닉네임이 눈에 띄었습니다. 'cloudshin' 과 'achimnol' 각각 신정규 대표와 김준기 CTO가 갑자기 불이 붙어서 90% 이상의 유사도 점수를 내고 계신 겁니다. 두 분은 점심을 드시러 이동하는 와중에도 계속해서 끝없이 오리를 그려내고 계셨답니다.

보다못한 유우영 DevRel Lead님이 이를 말리고 나섰으나, 두 사람의 열정은 쉽게 말릴 수 없었다는 후문이 전해집니다. (P.S.1: 물론 점수를 집계할 때 두 분의 데이터는 강제로 지웠답니다.) (P.S.2: 사실 참가자 분들이 워낙에 훌륭하셔서 이 두 분의 점수를 손쉽게 넘어서는 압도적인 포디움을 만들어 내셨답니다...)

내부적인 부작용(?) 이외에 외부에서의 문제도 발생했습니다. 1일차 부스를 운영하던 중, 어디선가 개발자의 외마디 비명이 들립니다.

"누가 매크로를 돌리고 있는 것 같은데요?"

확인해보니 1~5초 간격으로 계속해서 동일한 프롬프트로의 중복 제출 요청이 들어오고 있었습니다. 같은 프롬프트를 넣어도 매 번 결과물이 조금씩 달라지는 생성형 AI의 특징을 이용한 매크로였죠. 그러나 문제가 식별된 당시에 서비스를 수정하기는 어려웠고, 백엔드를 담당한 개발자는 2일차 파이콘 발표가 예정되어 있었기에 즉각 대응이 어려웠죠. 상황은 점점 나빠져만 갔습니다.

"제출이 안돼요" "버튼이 안 눌려요" "이미지가 대신 회색 빈 칸만 나와요"

개발자들의 축제인 파이콘답게, 누군가는 노트북으로 우리 사이트를 열고, 개발자도구를 보여주며 요청이 들어가고 있지 않은 것 같다고 이야기해주기까지 했습니다. 발표준비를 하러 구석에 숨어있는 개발자를 찾아갔고, 아까의 매크로가 우리의 H100을 향해 엄청난 양의 리퀘스트를 쏟아내고 있었습니다. 그렇게 매우 느린 속도로 이미지를 제출하고 있는 사람들을 뒤로 하고 1일차 행사가 끝났습니다. 부스를 정리하며 1일차 Recap을 진행했고, 2일차 행사에는 이런 문제를 원천적으로 막아야 한다는 결론이 도출되었습니다.

불쌍한 개발자는 2일차 행사를 위해 밤을 새워가며 발표 준비도 미루고 두 가지의 새로운 기능을 추가해 이런 사태를 미연에 방지하고자 했답니다.

첫째, 동일 프롬프트 제출 방지 기능 추가

서버단에서 제출한 프롬프트를 검증하는 기능을 추가했습니다. 동일한 프롬프트가 제출된 이력이 있는 경우, 새로운 이미지를 그리지 않고 최초 생성된 이미지와 해당 이미지의 유사도 점수를 그대로 응답하도록 변경했습니다.

둘째, 이미지 제출 시 캡챠 추가

매크로를 방지하기 위해 응답 제출 시 캡챠를 누르도록 변경했습니다. 참가자들이 약간 더 귀찮아지긴 했겠지만, 캡챠를 추가한 것으로 행사 2일차에는 무작위 매크로가 발생하지 않았답니다.

그 외 소소한 개선 사항들

참여자의 등수 계산을 위해 꽤 자세한 소숫점 단위까지 받아오고 있었지만, 사용자 편의상 GUI상에서는 소숫점 첫째 자리에서 잘라 보여주고 있었습니다. 그러나 경쟁이 과열되며 소수점 첫째 자리까지 똑같은 점수를 받은 사람들이 나타나기 시작했죠. 이에 따라 사용자들의 혼란을 줄이기 위해 소숫점 둘째 자리까지 GUI상에 보여주는 패치를 진행하기도 했습니다.

성공적인 이벤트를 위해 불철주야 백엔드를 담당해준 조규진 선임 엔지니어와 김수진 프론트엔드 엔지니어에게 감사의 말씀을 전합니다 🙂

파이콘 한국 2024를 마무리하며

수많은 파이써니스타 분들이 파이콘 한국 2024를 찾아주셨고, 래블업도 수많은 파이써니스타 분들을 만나러 현장에 함께했습니다. 래블업은 앞으로도 끊임없이 오픈소스 커뮤니티에 기여하고, 함께 성장해나갈 것입니다. 최근에 큰 인기를 끌었던 <흑백요리사>라는 프로그램에서 정지선 셰프가 이런 말을 합니다. "저는 레시피를 오픈해요. 레시피를 오픈하면 그만큼 레시피가 또 생겨요. 사람들이 아이디어를 많이 제공하거든요. 큰 그림을 그리는 거죠."

래블업도 언제나 우리를 이루고 있는 근간인 오픈소스 정신을 잊지 않고 계속해서 큰 그림을 그려나가겠습니다.

이 글은 2022년 5월 ESC 과학기술뉴스 에 기고된 글입니다.

인공 신경망 분야가 본격적으로 주목 받기시작한 지 곧 10년이 됩니다. 그 길지 않은 시간 동안 인공 신경망 분야는 딥 러닝의 발전과 함께 엄청난 속도로 무수한 문제들을 해결하고 있습니다. 인공 지능 구현에 있어 가장 가능성이 높은 방법으로 꼽히고 있기도 합니다.

그 첨단에서는 하이퍼스케일 딥 러닝 모델과 그 구현 방법에 대한 다양한 뉴스들이 주목 받고 있습니다. 2022년 4월 엔비디아의 새로운 GPU인 H100의 소식이 뉴스라인을 뒤덮었고, AMD의 고성능 컴퓨팅 특화 GPU인 MI 시리즈와 함께 인텔의 새로운 GPU인 폰테 베키오가 AI와 블록체인 채굴 가속 성능을 엄청나게 올려 하이퍼스케일 AI의 새 격전지를 만들 것으로 예상되고 있습니다.

하이퍼스케일 인공지능의 붐에 묻힌 소식들 가운데 대중적으로 크게 관심을 끌지 못했던 뉴스가 있습니다. 바로 작년 10월 인텔이 발표한 로이히(Loihi) 2 칩 소식이었습니다^[1]. 이 소식은 굉장히 흥미로운 역사와 기술적 배경을 안고 있습니다. AI 훈련 및 서비스 가속 칩들이 늘어나는 와중에 일어나고 있는 재미있는 기술 뉴스 뒤에 숨어 있는 과학에 대해 소개해 보고자 합니다.

딥 러닝으로 지성을 코딩할 수 있을까?

GPU 기반의 행렬 연산 가속으로 날개를 달기 시작한 2013년 이후, 딥 러닝 분야는 연산 규모에 힘입은 다양한 가능성을 탐구하기 시작했습니다. 2016년의 알파고 쇼크를 기점으로 딥 러닝은 연구 분야를 넘어서 그 범위를 응용 분야로 조금씩 확장하기 시작했습니다. 2017년에 제안되고 2018년부터 그 사용이 본격화된 트랜스포머 모델 구조^[2]는 어텐션 및 셀프 어텐션이라는 개념을 도입해 딥 러닝 모델이 스스로의 기억 구조를 만드는 과정을 크게 개선했습니다. 트랜스포머 모델 구조는 이후 엄청나게 다양한 분야의 딥 러닝 모델에 사용되고 있으며, 특히 데이터가 풍부한 자연어 처리 및 이미지 처리 분야에서 두각을 나타내고 있습니다. 트랜스포머는 기존의 딥 러닝 모델이 효과적으로 동작하지 않는 것처럼 보이던 다양한 문제들을 딥 러닝 모델로 해결할 수 있게 해 주었습니다.

만능처럼 보이는 이 모델은 2018년부터 딥 러닝 모델의 거대화 추세를 이끌기 시작했습니다. 딥 러닝 모델의 크기는 모델의 매개 변수의 수로 결정되는데, 딥 러닝의 매개 변수는 모델을 구성하는 퍼셉트론 사이의 연결 정보이며, 실제 뉴런의 시냅스 연결에 해당합니다. 연결이 많을수록 딥 러닝 모델은 더 복잡한 입력을 구분하고 판단할 수 있게 됩니다. 딥 러닝 모델이 복잡해지고 거대해질수록, 매개 변수는 기하급수적으로 늘어납니다. 2019년 이전까지의 딥 러닝 모델 매개 변수의 수는 해마다 대략 3 ~ 5배씩 증가해 왔지만, 2019년 이후에는 해마다 열 배 이상씩 증가하고 있습니다. 최근 약 2 ~ 3년 동안 등장한 거대 딥 러닝 모델들을 ‘하이퍼스케일 AI’라고 부르기도 합니다. 자연어 처리 분야에서 대중에게 잘 알려진 하이퍼스케일 딥 러닝 모델로는 OpenAI의 GPT-3, Google의 LaMDA 등이 있습니다. 이러한 거대 모델의 경우, 예를 들면 GPT-3의 경우에는 모델 훈련을 위한 시스템 비용(장비 구입 없이 클라우드상에서 훈련 한 번 시키는 비용)으로 최소 약 50억 원 이상이 들어가는 것으로 추산됩니다^[3].

하이퍼스케일 모델들은 기존에 풀기 어렵거나 풀지 못했던 문제들을 풀어내고 있습니다. 중력 렌즈를 새로 발견하거나^[4] 렌즈로 인해 생긴 왜곡을 펴서^[5] 우주의 신비를 풀기도 하죠. 기존의 방법보다 훨씬 더 짧은 시간과 적은 비용으로 단백질의 접힘 구조를 예측하기도 하고^[6], 신약을 찾아냅니다^[7]. 오랜 시간에 걸쳐 흐름을 파악해야 하는 스타크래프트 2 전략 시뮬레이션 같은 문제^[8]를 풀기도 합니다.

이렇게 여러 가지 문제를 해결해 주다 보니 당연히 따라오는 궁금증들이 있습니다. 과연 막대한 양의 자원을 부어 넣어 딥 러닝 모델을 만드는 이러한 접근은 지속 가능할까요? 그리고 이러한 방법으로 '지성'을 코딩할 수 있을까요?

이 두 질문에 답하기 위해 딥 뉴럴 네트워크부터 오늘의 주제인 뉴로모픽 컴퓨팅까지 빠르게 한 번 이해해 보겠습니다.

딥 뉴럴 네트워크: 태생과 차이점

사실 딥 러닝은 줄임말입니다. 원래는 딥 뉴럴 네트워크(Deep Neural Network, DNN), 더 풀어서 쓰면 Artificial Neural Network with deep layers (심층 인공 신경망)입니다. 인공 신경망 이론은 신경 세포의 전기적 특성을 수학적으로 모사하는 과정에 뿌리를 두고 있습니다. 신경 세포의 전기적 특성과 함께 신경 세포 사이의 연결 구조가 정보 처리 과정에서 강화 또는 약화되는 가소성^[e1]을 수학적으로 모사하고, 이를 단순화하면서 시작되었죠. 인공 신경망 모델은 신경 세포들의 연결에 따른 활성 과정을 엄청나게 단순화한 퍼셉트론^[9]과, 신경 세포의 발화 과정을 모사하는 함수에서 시간 의존성을 제외하고 신경 세포로의 신호 입력에 대한 함수로 단순화한 활성 함수, 마지막으로 신경 세포 사이의 연결이 얼마나 강한지를 나타내는 가중치를 매개변수로 나타내는 수학적 모델입니다.

인공 신경망 이론은 실제 신경망의 특징에 뿌리를 두고 있긴 하지만 실제 신경망과는 근본적인 차이가 있습니다. 바로 시간에 따른 동작을 결정하는 동역학의 유무입니다. 실제 신경망은 신경 세포들 간의 동역학에 의해 다양한 결과들이 결정됩니다. 신경 세포는 외부로부터 자극을 받았을 때의 각각의 동역학적 특성이 있고, 그에 따라 물리적으로 강화 또는 약화되는 방식의 가소성이 있습니다. 가령 어떤 판단을 내릴때 계속 같이 사용되고 연결된 신경세포들은, 입력 신호를 받았을 때 비슷한 시점에 활성화됩니다. ‘시간적으로’ 비슷한 시점에 활성화된 신경 세포들 사이의 연결에 해당하는 축삭이 물리적으로 두꺼워지는 것을 발견할 수 있습니다. 반면 일반적인 인공 신경망은 동역학 대신 역전파 이론을 이용하여 가소성을 모사합니다. 역전파 이론은 어떤 판단을 바르게 내릴 때 사용된 퍼셉트론 사이의 연결의 가중치를 강화하는 계산을 간단하게 할 수 있는 방법입니다. 인공 신경망에서 입력되는 정보를 처리는 과정은 퍼셉트론 사이의 가중치를 이용하므로 즉각적입니다. 입력 정보가 출력 정보로 이어지는 과정이 시간에 따른 함수로 계산되지 않으므로, 동역학 요소가 없습니다.

동역학 외에도 다양한 차이가 있습니다. 이런 차이는 대개 생물학적 신경망에서는 불가능한 가정들을 도입해서 생긴 것으로, 1990년대 인공 신경망 이론의 한계를 극복하기 위한 노력의 결과입니다. 활성 함수에 ReLU^[e2]를 사용한 것이 하나의 예입니다. 일반적인 신경 세포는 역치와 가중치 한계가 존재합니다. 무한대의 활성값은 물리적으로 불가능하기 때문입니다. 그래서 수학 모델도 활성함수로 역치와 가중치 한계를 잘 보여주는 함수를 사용했습니다. 허나 심층 인공 신경망이 깊어지면서 연구자들은 인공 신경망 훈련이 더 이상 진행되지 않는 것을 발견하였습니다.^[e3]ReLU 활성함수는 물리적으로는 불가능하지만 수학적으로 무한대의 가중치를 가질 수 있습니다^[e4]. ReLU를 심층 인공 신경망에 도입하면서 새로운 훈련이 가능해졌고 생물학적 신경망과의 차이는 커졌습니다.

동역학을 고려할 필요가 없는 인공 신경망은 행렬 연산의 연속으로 변환이 가능하기에 엄청난 속도로 계산이 가능합니다. 하지만 생물에서 볼 수 있는 신경망과는 큰 차이가 생겼습니다. 그러면 딥 러닝 모델과 실제 우리의 뇌 속에서 일어나는 신경학 과정은 이제 완전히 다른 토대 위에 서 있는 걸까요?

자연으로부터 다시 배우기: 뉴럴 네트워크의 동역학

단일 신경세포는 다양한 방법으로 신호를 주고 받습니다. 일부는 전기적 신호이고 일부는 화학적 신호입니다. 단일 신경 세포 안에서의 전기적 신호 특성은 굉장히 일찍 해석되고 수식화 되었으며^[10], 퍼셉트론의 이론적 기반이 되었습니다. 문제는 단순화 없이 동역학을 계산하기엔 그 수식이 너무 복잡하다는 점이었습니다. 이후 시간에 따른 전기적 반응을 계산적 부담을 줄일 수 있게 어림한 다양한 수학 모델이 제안되었고, 이러한 모델을 사용하여 다양한 단일 신경 세포 시뮬레이터들이 공개되고 있습니다. 대표적인 시뮬레이터로는 NEURON^[11]이 있습니다.

앞서 동역학의 모사에는 엄청난 계산량이 필요하다고 했습니다. 어느 순간 우리는 연산 성능이 넘쳐나는 시대를 맞이하고 있습니다. 넘쳐나는 연산 성능을 바탕으로 이러한 단일 신경세포 시뮬레이션들을 이어붙이면 어떻게 될까요?

엄청난 계산량으로 인한 연산 속도 문제를 해결하고 동역학 기반의 인공 신경망을 만들기 위한 방법으로 알고리즘과 하드웨어, 두 가지 측면에서의 시도가 있습니다. 알고리즘 측면의 접근은 스파이킹 뉴럴 네트워크(spiking neural network, SNN)으로, 실제 신경세포에서 발생하는 스파이크 기반의 가소성을 도입하여 동역학 모델 기반의 인공 신경망을 만들어 보려는 것입니다. 하드웨어 측면의 접근은 2012년부터 본격화된 뉴로모픽 컴퓨팅입니다. 신경 세포에 해당하는 물리적 객체를 만드는 방법으로 인공 신경망을 구현하는 것입니다. 동역학 모사에 들어가는 엄청난 계산량을 범용 연산으로 해결하기에는 아직도 컴퓨터가 느립니다. 이걸 해결하기 위해 아예 회로 수준에서 신경 세포에 해당하는 수학적 특성을 갖는 객체를 만들거나 하드코드로 연산을 만들어 넣은 전용 소자를 만들면 어떨까 하는 방법이죠. 최근에는 뉴로모픽 컴퓨팅과 SNN을 구분하지 않고, SNN을 소자 수준에서 구현하는 방식을 뉴로모픽 컴퓨팅으로 부르는 등의 통합이 이루어지고 있기도 합니다. 두 가지 접근 모두 기존의 인공 신경망 이론이 사용하지 않았던 동역학 특성을 모사하여 새로운 현상이나 딥 러닝의 가능성을 찾으려는 시도입니다.

뉴로모픽 컴퓨팅 분야에서 두각을 나타내고 있는 회사 중 한 곳이 인텔입니다. 인텔은 2017년 가을 약 13만 개의 뉴런과 1억 3천만 개의 시냅스를 내장한 연구용 뉴로모픽 칩인 로이히Loihi^[e5] 칩을 공개했습니다. 로이히 칩을 사용하여 기존의 DNN 기반 알고리즘을 이식한 후 다양한 비교 테스트를 수행했고^[12], 재미있게도 SNN을 사용해서도 DNN과 비슷한 결과를 얻을 수 있다는 걸 보였습니다.

인텔은 이후 여러 개의 로이히 칩을 연결하여 거대한 SNN 시스템을 만들었고, 나우쿠(Nahuku)는 41억 개의 시냅스를, 포호이키 스프링(Pohoiki Springs) 뉴로모픽 슈퍼컴퓨터^[13]는 768개의 로이히 칩을 바탕으로 약 1억 1백만 개의 뉴런과 1천억 개의 시냅스를 구현했습니다. 이 과정에서 인텔은 SNN를 로이히 위에서 구현하는 소프트웨어 스택을 만들어냈으며, 그 결과 작년 가을에 로이히 2와 함께 뉴로모픽 어플리케이션을 개발할 때 사용할 수 있도록 라바(Lava) 오픈소스 소프트웨어 프레임워크를 공개했습니다^[14].

DNN과 SNN이 비슷한 결과를 보여주리라는 것은 예상되어 있었습니다. 물리학적으로 보면 인공 신경망이 다양한 문제를 추론하는 과정은 결국 정보 기반으로 초 고차원의 불연속 상태 공간을 정의한 후, 새로운 정보를 그 공간에 투사하는 것입니다. DNN과 SNN 모두 초고차원의 불연속 상태 공간을 정의할 수 있는 특성이 있죠. 생물은 진화를 통해 정보에 적응하는 특성을 물리적으로 만들어냈고, 인류는 생체모방공학(Biomemetics)을 통해 인공 신경망 이론을 창안해 내고 딥 러닝을 발전시켰습니다.

늘 그랬듯이 언제나 답을 찾는

지금까지 우리는 신경세포를 동역학 수준에서 모사한 네트워크로도 실제 우리가 딥 러닝에 기대했던 것과 비슷한 결과를 얻을 수 있다는 것을 알게 되었습니다. 그러면 이에 따라 나오는 의문이 있습니다. 결과가 비슷하다면 굳이 SNN과 뉴로모픽 컴퓨팅을 쓸 필요가 있을까요? 오늘 소개한 것들은 다양한 시도들의 극히 일부입니다. SNN과 뉴로모픽 컴퓨팅이 기존의 접근과 어떤 다른 결과를 만들어내는지는 계속 연구되고 있습니다. SNN이 더 나은 성능을 보이는 결과 또한 로보틱스 및 센서를 중심으로 등장하고 있으며, 동역학적 특성을 반영하는 것이 인과관계 유추에 더욱 강력할 것이라는 연구 결과도 나오고 있습니다. 더 깊게 들어가서 시냅스에서 일어나는 화학적 신호를 시뮬레이션하는 시도^[15]도 있습니다. 신경망의 연결 구조에 더하여, 신경망을 구성하는 개별 요소에 우리가 아직 모르는 지능의 창발을 불러오는 요소가 있을지도 모르기 때문입니다. 그런데 이 정도로는 굳이 왜 SNN을 사용하는가에 대한 답변으로 부족할 것입니다.

글 서두에서 드렸던 두 가지 질문을 다시 해 보겠습니다. 막대한 양의 자원을 부어넣어 딥 러닝 모델을 만드는 이러한 접근이 지속 가능할까요? 그리고 이러한 방법으로 '지성'을 코딩할 수 있을까요? 뉴로모픽 컴퓨팅이 답이 될 수 있을까요? 그럴 수도 있고, 아닐 수도 있습니다.

DNN과 SNN이 제각기 높은 성능과 결과를 보이는 이유는 결국 두 구현체 모두 우리가 지금은 모르는 정보 최적화 이론이 그 바탕에 있기 때문일 것입니다. 그걸 알게 된다면, 우리는 AI를 다른 방식으로 구현할 수도 있을 것입니다. 처음에 드린 의문인 "막대한 양의 자원을 부어넣어 딥 러닝 모델을 만드는 이러한 접근이 지속 가능할지"에 대한 답을 얻는 하나의 길이 될 수도 있겠습니다. 뉴로모픽 컴퓨팅과 SNN은 새로운 관점에서 우리가 이 문제를 뜯어볼 수 있게 해 줍니다.

그리고 두 번째 질문에 대한 답이 될 수도 있을 것입니다. 우리는 언제나 가슴속에 질문 하나를 안고 삽니다. '우리는 누구인가?' 뉴로모픽 컴퓨팅과 SNN의 접근은 우리가 이 근본적인 철학적 질문에 물리적으로 접근할 때 가장 이해가 쉬운 방법입니다. 우리가 이미 알고 있는 (그렇지만 그 얼개는 아직 모르는) 시스템으로 설명하기 때문입니다.

뉴로모픽 컴퓨팅 외에도 다양한 분야에서 위의 두 질문에 대한 대답에 도전하고 있습니다. 그중 한 가지는 양자 컴퓨팅인데요, 다음에 양자 컴퓨팅와 딥 러닝에 대한 기사를 같이 읽어 볼 기회를 만들어 보겠습니다.

참고 문헌

• [1] https://www.anandtech.com/show/16960/intel-loihi-2-intel-4nm-4
• [2] https://arxiv.org/abs/1706.03762
• [3] https://lambdalabs.com/blog/demystifying-gpt-3
• [4] https://iopscience.iop.org/article/10.3847/1538-4357/abd62b
• [5] https://academic.oup.com/mnras/article-abstract/504/2/1825/6219095
• [6] https://www.nature.com/articles/s41586-021-03819-2
• [7] https://www.frontiersin.org/articles/10.3389/frai.2020.00065/full
• [8] https://www.deepmind.com/blog/alphastar-mastering-the-real-time-strategy-game-starcraft-ii
• [9] https://doi.apa.org/doi/10.1037/h0042519
• [10] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1392413
• [11] https://neuron.yale.edu/neuron
• [12] https://ieeexplore.ieee.org/document/8259423
• [13] https://arxiv.org/abs/2004.12691
• [14] https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html
• [15] https://www.ibm.com/blogs/research/2016/12/the-brains-architecture-efficiency-on-a-chip

미주

• [e1] 가소성Plasticity은 외부의 환경 변화나 자극에 의하여 스스로가 적응하여 특성을 변경하는 능력입니다.
• [e2] Recified Linear Unit의 약자입니다. 0보다 크면 y=x 함수 모양이 되는 활성함수로, x값에 따라 y가 계속 커질 수 있습니다.
• [e3] Vanishing Gradient라는 문제입니다.
• [e4] 신경세포는 점점 더 큰 입력을 받아도 세포의 물리적 한계 이상의 출력을 내 보낼 수가 없습니다. 전선에 전류를 무한정 흘릴 수 없는것과 마찬가지입니다. ReLU는 입력을 주는대로 출력이 그에 따라 선형적으로 무한정 증가하는 함수입니다.
• [e5] 인텔은 뉴로모픽 칩 및 시스템에 하와이의 다양한 지명을 코드네임으로 붙이고 있습니다.

이 글은 2023년 5월 Crossroads 에 기고된 글입니다.

원래 글 순서는 2023 > 2015 > 2020 > 2017 > 2018 > 2019 > 2021 > 2022 > 2023
으로 쓰인 글입니다. 감정적 흐름은 그 순서를 따라가지만, 독자의 이해를 위해 시간순으로 재편집했습니다.

2023년이 지나면 3월 14일은 파이의 날이 아니라 챗봇의 날이라고 불릴지도 모른다.

그동안 창고에 있었던 모든 언어모델 들이 세상에 동시에 뛰쳐나온 날이었다. 구글의 PaLM 파인 튜닝 + 생성 모델의 Vertex AI 공개부터 시작하여 OpenAI의 GPT-4 발표, 마이크로소프트의 Bing이 이미 GPT-4를 사용 중임을 공식화, Anthropic의 claude 봇 정식 공개까지 모두 12시간 안에 일어난 날이었다.

그날 오전 OpenAI에서 공개한 GPT-4 테크 리포트를 리뷰한 후, 기술적으로 인상적이었던 점에 대한 글을 페이스북^[1] 글에 남겼다. 댓글이 달렸다. "내 생전에 이게 될까 하던 것들이 현실화하는 걸 보는 기쁨과 아픔이 있습니다.." 답글을 남겼다. "이젠 아무도 튜링 테스트에 관심이 없죠. 1년 사이에 와우포인트 없이 당연히 넘는 거 아니야? 가 되었어요."

막상 키보드를 마주하니 지식을 정리하는 일은 이미 사람의 손을 떠난 것 같다. 기록의 의미를 찾아 사람의 이야기를 두드려본다.

---

외계어가 안 되도록 인공 신경망에 대하여 이 글을 이해하는데 필요한 내용만 짚고 가자.

신경세포(뉴런) 사이의 연결을 모사한 프로그램을 인공 신경망이라고 부른다. 뉴런 들을 층으로 묶고, 이를 겹치면서 앞뒤 층의 뉴런들과 연결을 만드는 식으로 설계한다. 딥 러닝은 인공 신경망 내의 층 개수가 많을 때 붙이는 표현이다. 다양한 인공 신경망 결과물 들을 딥 러닝 모델이라고 하며, 좀 있어 보이도록 그냥 AI 모델이라고도 한다.

뉴런 간의 연결 강도들을 파라미터라고 한다.^[2] 연결 강도의 개수를 파라미터 수라고 한다. 파라미터 수가 많을 수록 차지하는 메모리가 늘어나므로 모델이 커진다는 표현을 쓴다. 인공 뉴런들을 연결하고 입력 데이터에 대한 출력이 원하는 형태가 나오도록 뉴런 사이의 연결 강도를 조정하는 것을 모델 훈련이라고 부른다. 훈련이 끝난 인공 신경망은 엄청나게 높은 차원의 불연속 상태 공간을 흉내 낼 수 있게 된다.

여기 까지가 기본 용어이다. 그럼 언제 이야기부터 떠올려 볼까.

---

2015년.

래블업을 창업했다. "랩 을 업" 이자 "lab | up" 을 이용해 중의적 표현으로 지은 이름이다.

박사 과정 내내 고생을 사서 하던 사람들이, 다른 사람들은 고생을 덜 할 수 있도록 계산과학 분야의 연구 자동화 플랫폼을 만들자는 목표로 모였다. 베어 메탈^[3]에 작업 관리자^[4] 얹어 어설프게 클러스터를 돌리는 대신 재현성과 이식성이 보장되는 연산 환경이 필요하다고 생각했다. 시작은 용감했으나 연구 플랫폼은 수요가 없었다. 창업 2개월만에 대학도, 연구 기관도, 장비는 쉽게 사지만 소프트웨어엔 돈 쓰는게 인색하다는 것을 배웠다. 학교엔 돈이 없고 시키면 알아서 해오는 대학원생은 많았다. 업계엔 아직 대규모 과학 연산 수요가 없었다. 동시에 우리처럼 학교에만 있다가 밖에 나온 박사들은 사람처럼 말하기 위해 재사회화 과정을 거쳐야 함도 힘들게 배웠다.

재사회화가 덜 된 우리의 말재간만 문제가 아니었다. 말하는 내용이 문제였다. 기술 기반의 과학 발전 이야기나 연산 기반의 혁신 가속 이야기는 어디를 가도 SF 이야깃거리였다. 지쳐가고 있었다. 그래도 사람은 보는 것만 보인다고 했던가. 딥 러닝 모델의 가능성이 분명 태동하고 있었다. 심지어 딥 러닝 기술과 결과물이 자본에 종속 되는 것을 막자는 여러 움직임이 시작되었다. 그 중 대표적인 기관이 OpenAI^[5] 였다. 그러한 변화들은 우리가 맞는 방향을 가고 있다는 증거로 보였다. 일 년만 하면 방향이 조금 더 뚜렷해 질 것 같았다.

창업 만 일 년을 목전에 둔 시점에 딥 러닝에 대해 사회적으로 큰 관심이 생겼다. 2015년 연말 즈음 TensorFlow^[6]가 세상에 나왔다. 플랫폼 프로토타입으로 만든 코딩 플랫폼의 첫 강의 자료로 TensorFlow 메뉴얼을 통째로 번역해서 올렸다. 알파고의 2016년 3월 대국^[7]때 처음 서비스가 다운될 정도로 사람들이 몰려왔다. 그 때 그 대국이 아니었다면 아마 이 뒷이야기는 없었을 지도 모른다. 그 덕에 다행히 회사는 살아남았다.

거대 규모 연산을 수행하는 연구 플랫폼 데모가 필요했다. 연산 자원을 엄청나게 필요로 하며, 박사과정부터 취미로 잡고 있어 바로 다뤄볼 수 있던 주제가 언어 모델이었다. 2016년 우리가 만들던 플랫폼 위에 언어 모델을 올려 만든 챗봇을 발표했다. 많은 사람들의 관심을 끌었다.^[8][9] 챗봇은 금방 사내 프로젝트로 자리 잡았다. 하지만 일 년이 조금 넘은 시점에 챗봇 프로젝트는 창고로 들어갔다.

2017년.

그 해 가을 래블업은 사이드 프로젝트로 병행하던 언어 모델 개발을 접고 AI 클러스터 운영 플랫폼인 Backend.AI 에만 전념하기로 결정했다.

구글 초청으로 방문한 폴란드 크라쿠프에서 본 구글 어시스턴트 데모의 충격이 컸다. 열 분 남짓한 분들과 함께한 그 미팅의 주제는 언어 모델이 이제 자원 전쟁의 일부가 되었으며, 대규모 투자 없이는 이후의 변화를 따라갈 수 없음을 너무 확실하게 보여주었다. 구글 개발자 서밋에 함께 참석한 곽동현님과, 같은 시기 같은 장소에서 열린 학회 참석차 크라쿠프에 방문하셨던 이상훈님과 함께 저녁식사를 함께 하며 이야기를 나누었다. "여기서도 물리학 분야에서 봤던 그 미래가 시작될 것 같아요."

맨해튼 프로젝트는 팔십 여년 전 기술이 힘이 됨을 핵무기를 통해 전인류를 대상으로 강렬하게 어필했다. 물리학은 더이상 낭만의 대상이 아니라 투자의 대상이었다. 그렇게 시작된 생계형 물리학자의 시대는 우주 계획과 입자물리학으로 연결되는 거대 과학 분야로의 변화로 이어졌다. 그 날 밤 숙소로 귀가하며 함께하는 멤버들에게 메세지를 보냈다. "우리 이제 언어 모델 개발은 하지 말죠. 이제부턴 따라가려면 돈이 부족할 겁니다."

역사는 항상 반복된다. 그렇다면 앞으로 어떤 변화가 있을지 예상하는 것도 어렵지 않다. 단지 시점이 문제일 뿐이다. ‘아마도 변곡점은 2020년일것 같다’는^[10] 의견을 동료들과 나누었다. 그 때 즈음이면 흑자가 가능하지 않을까? 회사의 목표가 되었다. 언어 모델은 LSTM 기반의 기계 번역을 넘어 한 걸음 발전하고 있었다. 알파고 쇼크는 사람들이 AI에 대해 지어내는 수많은 농담들의 아이디어가 되었다. 엄청나게 많은 "AI 기업" 들이 생겼다. 하지만 그 대부분은 2년 후 코인회사나 메타버스 회사가 되었다.

2018년.

트랜스포머^[11]구조는 온갖 언어 모델의 다양한 부분에 적용되기 시작했다. ‘무엇’ 에 집중할지 알려준다는 점에서 트랜스포머는 모델의 컨텍스트 기억과 유지, 강조에 대한 많은 부분을 해결해주었다. 정보를 상태공간에 넣는 인코딩에 쓸 수도, 상태공간에서 정보를 추출하는 디코딩에 쓸 수도 있었다. 구글은 BERT^[12]를, OpenAI는 GPT를 내 놓았다. 두 모델 모두 트랜스포머 기반의 언어 모델이었으나, 집중하는 포인트는 각각 인코더와 디코더로 달랐다. BERT은 인코더 부분에 집중하였으나 GPT는 디코더를 통해 출력을 입력으로 연계하는 식으로 인과 관계에 대한 메모리를 만드는 아키텍처를 구현하여, BERT와 구조적인 차이가 있다. BERT와 GPT, 이후 등장하는 T5는 더이상 라벨링된 말뭉치를 쓰지 않았다. 트랜스포머를 이용하여 말뭉치 자체에서 언어의 구조를 학습시킨 후, 이후 미세 조정하는 방식으로 언어모델을 만들 수 있었다. 데이터에 인간의 개입이 없는 AI 모델 개발 철학인 End-to-end 훈련과는 여전히 거리가 있었다. 하지만 데이터 확보에 대한 개념이 그 시점부터 달라졌다. 라벨링보다 양이 중요하다. 범용 언어 모델의 시작이었다.

BERT는 엄청나게 빠른 속도로 기존에 존재했던 대부분의 언어 모델을 대체할 수 있을 것으로 보였다. 압도적인 성능은 문서 작성, 챗봇, 문서 분석 등의 다양한 언어 작업들에 적용하여 큰 개선을 만드는 것에 대한 기대를 품게 했다. 하지만 BERT는 2018년 당시에는 훈련 과정을 상상할 수 없을 만큼 큰 모델이었다. 구글 밖에서는 아무도 못 만들 것 같은 모델 크기에 벽 구경하는 느낌을 받았다. 그것도 찰나였다. 페이스북이 BERT 논문을 바탕으로 사이즈를 더 키운 RoBERTa를 순식간에 발표했다.^[13] TPU가 꼭 필요한 것이 아님을 알림과 동시에, 이 레이스엔 자본이 있는 누구나 참여가 가능함을 알리는 상징적인 행동이었다.

GPU를 사용해 모델 크기를 키우는 첫 병목은 GPU의 메모리에서 등장했다. 모델은 더이상 GPU 기기 한 장에 담거나, 한 장으로 시간 내에 훈련시킬 수 없었다. 경우에 따라 여러 대의 GPU에 모델을 나눠 담거나 여러 컴퓨팅 노드를 사용해 모델을 분산 훈련하는 것이 일반적이 되었다. Horovod, Distributed TensorFlow들이 빛을 발하기 시작했다.

기술은 계속 발전하고, 동일 연산 자원에 들어가는 비용은 계속 감소한다. 이런 발전이 지속된다면 결국 AI의 대중화가 진행 될 것이고, 그 시점에서 가장 중요한 포인트는 다른 모든 시장에서도 동일한 가격 경쟁력이 될 것이었다. "AI도 가격 경쟁력 시대가 올 것이다" 써 붙였다. 그 때 까지 망하지 않기를 기원하면서.

• BERT, 3억 4천만 파라미터
• GPT, 1억 1천만 파라미터

2019년.

몇 년 간 분산 처리 및 분산 훈련 플랫폼을 만들면서 가끔 ‘우리가 아무런 수요가 없는 플랫폼을 만들고 있는 것이 아닐까’ 하는 생각을 종종 했었다. 2019년 이후로는 그런 생각이 들지 않았다. 2020년부터는 그런 생각을 할 시간이 없었다.

연초가 되자마자 OpenAI는 GPT-2^[14]를 발표했다. 위상공간에서 정보를 추출하는 디코딩 과정에 집중한 GPT 모델은 굉장히 안정적인 텍스트 생성 기능을 보여주었다. GPT-2는 누구나 언어모델을 만들어 볼 수 있는 기초 코드가 되었다. PyTorch, horovod와 Distributed TensorFlow 등과 함께 코드 접근의 어려움은 엄청난 속도로 줄어들고 있었다. 2019년 Google의 XLNet과 T5 (Text-To-Text Transfer Transformer) 언어 모델은 인류가 넘을 수 없다고 생각했던 모델 크기의 강을 (자본을 써서) 넘은 것처럼 보였다. 구글은 T5를 훈련하려면 TPU 급의 엄청난 연산 자원이 있어야 함을 강하게 어필하며, 시중에서 노력하면 살 수 있는 NVIDIA의 V100으로는 몇 백장이 필요함을 강조했다. (V100 한 장에 1500만원 정도의 비용이 들었다.) T5 또한 BERT처럼 논문만 공개하고 모델은 공개하지 않았다. 2017년 BERT 공개 때 (훈련이 덜 끝나서) 바로 모델을 함께 공개하지 않았는데 그 틈에 페이스북이 동일한 모델로 규모를 키워 훈련한 RoBERTa를 선제적으로 발표했던 아픈 경험이 있다. 그런데도 공개를 하지 않은 것에 비추어 보면, 구글에겐 구글 밖에서 그 모델 훈련을 재현하기 어려우리라는 자신감이 있었을 것이다.

2019년 말 우린 오랜 떠돌이 생활을 마치고 단독 사무실을 장만하여 거처를 옮겼다. 거대 딥 러닝 모델의 시대가 올 것이고 그러려면 우리도 그에 대응하여 더 많은 사람들과 함께해야 할 것이었다. 언어 모델의 크기는 해마다 열 배 씩 커지고 있었다. 그렇게 많지도 않은 짐들을 박스에 실어 나르며 스스로에게 반문해보았다. 이대로는 3년이면 모델 크기가 천 배가 커지는 것인데, 우리는 천 배의 워크로드를 감당할 준비가 되어 있을까?

• RoBERTA, 3억 5천만 파라미터
• Transfer ELMo, 4억 6천만 파라미터
• GPT-2, 15억 파라미터
• T5, 110억 파라미터

2020년.

사무실을 이전한지 두 달이 흘렀다. 겨울은 길었다.

2월이 끝나가도록 이사를 마친 새 사무실의 인테리어를 마무리하지 못했다. 2월 말에 온다던 사무실 벽체 마감재는 중국에서 끝내 건너오지 않았다. 회사의 모든 로드맵이 바뀌었다. 미국 출장은 전부 취소되었다. 인테리어가 덜 끝난 사무실은 그 후 2년동안 덜 끝난 채로 빈 공간을 지켰다.

COVID-19는 회사의 미래 뿐 아니라 사람들도 갈라놓았다. 첫째 아이는 마루에 비스듬히 기대 누워 EBS 방송 텔레비전에 나오는 호랑이 선생님을 보면서 초등학교 생활을 시작했다. 방바닥에서 굴러다니는 어린이 옆에서 함께 굴러다녔다. 그동안 얼마나 바빴던 걸까? 남매를 키우는데도 코로나로 한 집에 갇히고 나서야 아빠라는 실감을 했다. 슬프면서도 이상하게 안정되는 그 시간이 얼마나 갈 지 궁금했다.

그 해 OpenAI에서는 GPT-3를 공개했다. GPT-2와 이론적 토대는 크게 달라지지 않았다. 하나 크게 달라진 것이 있었으니, 크기였다. 1750억 파라미터의 크기를 가진 엄청난 규모의 모델이었다. 모델 훈련 뿐 아니라 단순히 GPU 위에 적재하는 것 만으로도 NVIDIA의 슈퍼컴퓨팅 노드인 DGX-2 한 대를 차지할 것으로 예상되었다. GPT-2와 달리 이번에는 언어 모델의 코드도, 훈련이 끝난 언어 모델도 공개하지 않았다. 와우. 딥 러닝 분야에 비공개라니. 무엇인가가 달라지고 있었다.

모델 크기 지상주의에 반발하는 움직임이 있었다. 딥 러닝 모델의 크기가 커질수록 성능이 따라서 커지는가? 구글의 연구진들과 메타의 연구진들 간의 논쟁이 시작되었다. 한 쪽에서는 그렇다, 다른 한 쪽에서는 아니다 로 나뉘어 논문의 형식을 빌린 말싸움이 벌어졌다. 그러나 2019년부터 2021년까지 이어진 이 논쟁은 오래가지 못했다. 언어 모델 크기를 키우면서 재미있는 현상들이 발견되었다. 딥 러닝 모델에는 스케일 법칙이 존재했다.^[15] 1000억 파라미터를 전후하여 무엇인가가 일어났다. 모델의 구조와는 상관없이, 1천억 파라미터를 넘기는 어떤 시점부터 언어 모델은 말을 이어 지어내는 것을 넘어 기대하지 않았던 일을 하기 시작했다. 충분히 큰 모델들은 컨텍스트를 유지한채로 복잡한 일들을 처리할 수 있었다. 컨텍스트 내 학습 (in-context learning)이라고 부르는 현상은 모델 훈련 없이도 여러 지식을 즉석에서 학습하고, 논리적인 결론을 유도할 수 있었다. 거대 언어 모델 (Large Language Model) 과 이를 둘러싼 레이스의 시작이었다.

언어 모델이 크기 문제를 둘러싼 논쟁과 발견에 동시에 빠져 있는 동안, 의학 응용 분야의 딥 러닝 도입은 엄청난 속도로 시작되었다. 딥 마인드의 알파폴드2는 몬테카를로 시뮬레이션 없이 예측만으로 구조 예측을 높은 정확도로 해 냈다. 프로테오믹스 분야의 주요 난제였던 필요 계산 량을 거의 천분의 일 수준으로 줄였다. 코로나 바이러스의 변이 예측, 합성물질 중 백신 후보 물질 필터링, 새로운 합성 구조 예측 등의 미시적인 단계부터 전파 경로 예측과 감염자수 예상까지 AI 모델의 응용은 다양한 분야로 확장되었다. 모두가 이전 같으면 두들겨볼 돌다리들을 일단 밟고 건너기 시작했다. 자원 규모의 눈덩이는 엄청난 속도로 굴러갔다.

하반기가 되자 모델 훈련 속도를 올리기 위한 연산 자원 규모의 이야기가 오갔다. 연구 목표 달성을 위한 기존의 딥 러닝 연산 자원 확보 경쟁과는 달랐다. 규모는 운영과 최적화 수요를 낳았고, 그 덕에 우리는 2017년 예상했던 ‘2020년부터 흑자 달성’ 을 이룰 수 있었다. 플랫폼 수요가 늘었지만 동시에 강제로 재택 근무에 들어가야 했고, 대부분의 의사소통은 문자가 되었다. 이후 많은 사람들이 함께 하게 되었지만 그 중 몇몇은 2023년 초 워크샵 때 까지 서로 한 번도 만난 적이 없는 동료가 될 운명이었다.

연산 자원 규모가 커지고 있었고 모두 GPU에 주목했지만, 모델이 커지고 GPU 대수가 늘어나자 GPU가 발목을 잡는 부분이 적어졌다. 가장 발목을 잡는 부분은 데이터 저장소, 스토리지였다. 훈련시에는 몇 백대의 기기에 데이터를 공급해야 한다. 스토리지의 절대 속도가 GPU 개수의 증가를 충분히 따라잡지 못했다. 2020년 우리가 풀어야 했던 문제의 대부분은 스토리지에서 발생하는 병목에서 나왔다.

딥 러닝 분야의 속도전보다는 느릿했지만 더 깊은 다른 종류의 변화가 찾아왔다. 온라인에서만 만들어진 인간관계를 보통 인간관계와 같게 받아들이는 것이 세대를 불문하고 모든 사람들에게 자연스럽게 되었다. 그러다 보면 문득 생각이 드는 순간이 찾아온다. ‘반대쪽에 있는 것이 사람이든 아니든, 말만 잘하면 나에게 큰 차이가 있는 존재인가?’

• T-NLG, 170억 파라미터
• GPT-3, 1750억 파라미터
• Gshard, 6000억 파라미터

2021년.

T5에 이어 GPT-3가 불러온 거대 언어 모델 개발의 레이스는 점입가경이었다. 크기가 커져도 성능향상이 계속되는지 알아보려면 더 크게 만들어 보는게 가장 간단하기 때문이다. 거대 언어 모델이 왜 특이한 결과를 만들어내는가에 대한 다양한 이론들이 등장했지만 여전히 답은 오리무중이었다. 상태 공간이 충분히 크면 정보를 다루는 과정에 일종의 상전이가 생긴다는 가설이 등장했다. 트랜스포머가 어째서 이러한 작업을 잘 처리하는가에 대한 답의 후보로는, 트랜스포머 구조가 그래프 신경망 (Graph Neural Network)의 특수해이기 때문이라는 설명이 있었다.^[16] 2018년부터 주목받은 그래프 신경망은 대상의 관계를 학습하는 신경망이고, 그래프 신경망이 시맨틱스나 텍소노미 처리에 매우 강력할 수 있음이 알려져 있다.

분산 모델 훈련을 위해 속도를 희생하는 대신 더 큰 모델을 훈련할 수 있게 하는 마이크로소프트의 DeepSpeed 프레임워크가^[17] 점점 널리 쓰이기 시작했다. DeepSpeed의 특징인 ZeRo 최적화기는 CPU부터 GPU까지 다양한 하드웨어에 워크로드를 분배하고, 모델 상태를 분할 처리함으로써 이를 통해 GPU의 메모리 사용량을 줄이는 과정에 집중했다. 오픈소스 언어 모델들도 여럿 등장했다. OpenAI는 더이상 모델을 공개하지 않고, 모델 사용의 독점권을 팔고 있었다. 접근성이 낮아져 다양한 언어 모델들이 등장했지만, 규모의 면에서 거대 언어 모델에 미치지 못했기에 높은 기대치를 만족시킬 수 없었다.

사용자들이 다루는 GPU의 규모가 쉽게 세 자릿수를 넘기 시작했다. 기관에서 실제로 돌리는 워크로드에 맞는 거대 규모의 테스트가 다양하게 필요해졌다. 2017년 말 취미의 영역으로 보냈던 언어 모델을 시스템 테스트 용도로 다시 돌려보기 시작했다. 플랫폼 위에서 전세계에서 가장 큰 포르투갈어 언어 모델이 태어났고, NVIDIA GTC 컨퍼런스의 키노트에서 잠시 지나가며 소개되었다. 같은 컨퍼런스에서 "BERT를 60초만에 파인튜닝하기"라는 튜토리얼 세션이 열렸다. BERT는 더이상 거대 모델이 아닌 연습 대상이었다.

모델 크기가 급속도로 커지면서 풀어야 하는 문제도 바뀌었다. 여러 대의 GPU들에 모델을 나눠 적재해야 하는 상황이 되자 GPU간의 통신이 엄청나게 중요해졌다. GPU들은 한 노드 안에서 메모리 접근을 공유하는 것을 넘어 여러 노드에 걸쳐 통신하는 경우가 늘어났다. 초당 200Gb를 전송하는 인피니밴드를 GPU마다 하나씩 붙인 GPU 네트워크가 당연하게 쓰이기 시작했다.

복잡하고 정신 없는 변화속에 살며 생각거리가 하나 생겼다. 거대 언어 모델이 ‘언어’ 를 배우는 과정은 분류되지 않은 말뭉치를 대상으로 한다. 그 과정에서 거대 언어 모델이 ‘학습’ 하는 것은 무엇인가? 언어의 구조를 학습하기 위한 용도로 말뭉치를 쓰지만, 언어는 정보와 떼 놓을 수가 없다. 실제로 지식을 가르치지 않은 언어 모델들도 질문에 곧잘 대답하지 않는가? 애초에 언어는 인간이 정보를 서로 간에 전달하기 위한 프로토콜이다. 프로토콜로 전달된 데이터에 대한 답을 연산하여 다시 데이터로 답을 하는 것이 대화 과정이다. 그렇다면 우리가 ‘대화를 잘하는 AI’를 개발해 냈다고 느끼는 것은 정말 언어를 잘 만드는 AI 모델을 개발한 것일까, 그렇지 않으면 그 너머의 무언가를 만든 것인가?

내년은 기존의 서비스들을 AI로 개선한 서비스들이 아닌, AI로만 가능한 서비스들의 원년이 될 것이었다. 하지만 거대 언어 모델의 결과물들을 서비스하려는 생각은 아직 아무도 하지 않고 있었다. 그건 미래의 누군가가 할 일이었다.

• GPT-J, 60억 파라미터
• LaMDA, 1600억 파라미터
• PanGU-alpha, 2000억 파라미터
• Gopher, 2800억 파라미터
• Pathways, 5300억 파라미터
• Switch-C, 1.6조 파라미터
• Wudao 2, 1.75조 파라미터

2022년.

COVID-19 엔데믹은 엄청난 후폭풍을 만들어내고 있었다. 코로나로 인한 특수로 성장한 수많은 IT기업들과, 오프라인을 온라인으로 전사하려고 노력하던 수많은 회사들은 갑자기 신기루처럼 사라진 메타버스 수요에 망연자실했다. 딥 러닝 분야는 별다른 수익원을 만들어내지 못하고 있었다. 수없이 많은 회사에서 AI 팀의 크기를 줄이기 시작했다. 많은 연구자들이 밖으로 나왔다.

AI에 대한 기술적 발전이 필요가 없어진 것은 아니었다. AI 개발의 저변에 깔린 거대한 규모의 영향력이 다른 모든 발전을 압도했기 때문이었다. 거대 과학의 시대에는 장비가 가장 비쌌듯 말이다. 혁신이 규모에서 나오기 시작한지 3년이 흐른 결과였다. 거대 언어 모델에서 발생하는 특이점이 창발 현상의 일종으로 간주되기 시작했다.^[18] 소규모의 연구들은 더이상 매력적이지 않았다. 딥 러닝 분야의 연구자들은 불안해했다. 줄어든 관심이 문제가 아니었다. GPU 달랑 몇 대로 어떤 연구를 할 수 있을지에 대한 가벼운 절망감 한 스푼이 더 문제였으리라.

그럼에도 불구하고 연초부터 등장한 여러 혁신들이 있었다. 잘 정의된 데이터로 훈련하는 것에 더해서, 답변들을 사람이 실제로 평가하여 더 나은 답변에 가중치를 주는 모델 튜닝 방식이다. 사람을 중간에 넣는 방식으로 강화학습을 언어 모델 훈련에 적용한 RLHF (Reinforcement Learning by Human Feedback) 방식은 2022년에 InstructGPT에 와서 같은 크기의 언어 모델 성능을 엄청나게 개선하는 결과를 보였다. 수많은 모델들이 RLHF를 적용하기 시작했다. 모델 크기에 스케일 법칙이 있다면 그걸 응용하지 못할 이유가 없을 것이었다. 3월에는 모델 훈련에 들어가는 비용을 엄청나게 줄일 수 있는 µ-Parametrization^[19]이 발표되었다. 작은 모델에서 미리 큰 모델의 하이퍼파라미터를 예측하는 것이 가능하다는 연구의 결론은, 거대 모델을 만들 때 드는 파라미터 탐색 수고를 상대적으로 엄청나게 줄였다. 이 연구는 GPT-4 훈련의 기반이 되었다.

미국-중국 무역 갈등의 여파로 미국은 중국을 대상으로 한 엔비디아의 AI 훈련용 GPU 수출을 금지시켰다. 며칠 지나지 않아 중국은 자체 반도체만으로 훈련했다는 거대 언어 모델을 공개했다.^[20] 얼마 후 엔비디아는 GPU 네트워킹 기능을 제거한 같은 GPU를 이름만 살짝 바꾸어 수출을 재시작 했다. DALL-E2와 Stable Diffusion 모델로 인해 AI 서비스 분야로의 관심사는 갈수록 커졌고, 이미지 등의 생성 AI 모델 시장은 격변하기 시작했다.

11월 말 OpenAI는 대중을 대상으로 챗봇 서비스를 열었다. GPT-3의 개선 버전인 GPT-3.5를 기반으로 한 모델이었다. 특이한 점은 인간 언어 모델에 프로그래밍 코드를 훈련시키는 방식으로 프로그래밍을 잘 하는 언어 모델을 만드는 대신, 프로그래밍 언어 데이터로 훈련된 모델에 인간 언어를 훈련시키는 방식으로 만들어진 모델이라는 점이었다. 거대 언어 모델의 논리 구조 훈련에 프로그래밍 코드 훈련이 어떤 식으로 영향을 주는 것이 분명해 보였다. 12월 초, ChatGPT로 이름 붙여진 서비스는^[21] 대중 모두에게 열려 있는 엄청난 접근성을 바탕으로 거대 언어 모델에 대한 관심을 불러일으켰다.

연말이 되자 직장을 잃을 것 같던 AI 분야의 지인들이 실시간으로 갑자기 좋아지는 지원에 당황해 했다. 엔데믹의 감원 열풍을 타고 AI 조직 사이즈를 줄여 나가던 회사들의 움직임이 멎었다. 한 주 전까지 연구 조직 축소와 결과물 평가를 압박하던 수장들이 AI를 외쳤다. 모델 서비스 프레임웍에 필요한 요구조건들이 갑자기 바뀌기 시작했다. 거대 언어 모델들의 목표가 상용화가 되었다. 모델 크기가 너무 커서 더이상 훈련과 서비스용 연산 자원을 구분하는 의미가 없어졌다. 원래 서로 다른 영역에 있던 AI 모델 훈련과 서비스가 갑자기 하나로 합쳐졌다.

더 큰 규모의 문제들이 기다리고 있다. 거대 언어 모델은 엄청난 전력을 소모한다. GPU는 어마어마한 전력을 소모한다. CPU에 비하면 전력 대 성능비가 엄청나게 좋은 기기이지만, 절대 전력 소모량이 너무 크다. NVIDIA A100 8대가 내장된 노드^[22]는 약 7kW를, 2023년 기준 가장 성능이 높은 H100 GPU 8대가 내장된 노드는 약 12kW를 소모한다.^[23] 기기를 설치하려면 이제 건물부터 지어야 한다는 말이 2019년 이후로 농담이 아니게 되었다. 2021년 브라질에 위치한 슈퍼컴퓨팅 클러스터에서 전력 문제를 겪은 후, 우리는 플랫폼을 통째로 Arm기반으로 이식했다. 몇 년 후 전력 문제가 이슈가 될 것이란 생각에서 였다. 마이크로소프트의 경우 전력 비용을 고려하여 아예 GPU 센터를 수력발전소 옆에 지은 경험을 공유하기도 했다.^[24]

주말이 줄어들었다. 할 일이 너무 많아졌다. 시간이 없었다. 우리만 그런 것이 아니었다.

이제 모두에게 시간이 없었다.

• Flan-T5, 1100억 파라미터
• GLM-130B, 1300억 파라미터
• OPT-175B, 1750억 파라미터
• BLOOM, 1760억 파라미터
• PaLM, 5400억 파라미터

2023년.

2월 8일, 17시간 간격으로 마이크로소프트와 구글이 각각 거대 언어 모델 기반의 서비스에 대한 발표를 진행했다. 마이크로소프트는 자사의 검색엔진인 Bing에도, 오피스 스위트에도, 윈도우 11에도 전부 GPT 모델을 도입하겠다는 계획을 발표했다. 구글은 LaMDA 기반의 Bard를 발표했다. 바이두는 어니봇을 공개했다. 두 회사는 만져지는 서비스 대신 미래를 먼저 홍보했다, 써 볼 수 없는 도구는 상대적으로 흥미를 끌지 못했다.

언젠가 올 것이라고 생각했던 "AI 가격 경쟁력 시대"가 왔다. 그런데 가격 자체의 허들이 너무 높았다. ChatGPT나 Bard는 경제논리로는 설명할 수 없을 정도로 고가의 서비스 비용을 소모한다.^[25] 경쟁이 불러온 너무 빨리 당겨온 미래에 해당된다. 모든 사람들이 그 미래를 손으로 만져본 후였다. 기대치가 엄청나게 올라간 것이 문제였다.

갑자기 다가온 거대 언어 모델 서비스는 또 다른 병목을 만들고 있다. CPU 기반으로 인퍼런스하는 서비스는 CPU 코어당 램 대역폭이 크게 줄어든 여파를 받았다. 하나의 CPU에 올라가는 코어 개수가 급격하게 늘어났기 때문이다. GPU 기반으로 인퍼런스하는 서비스는 모델이 담기는 GPU 메모리의 용량과 속도가 모두 부족해졌다. 언젠가 올 것이라 여겨졌던 램의 병목이 거대 언어 모델 서비스의 상용화로 갑작스럽게 직접적인 문제가 되었다. 2021년부터 예상된 병목이었다. 인텔, AMD, 엔비디아 등의 CPU, GPU 개발사들은 이 상황을 미리 준비했다. 인텔의 Xeon Max, AMD의 MI200과 NVIDIA GraceHopper 등, 2022년말부터 2023년 초에 걸쳐 다양한 하드웨어를 발표했다.

AI 모델이 엄청 크면 연산 능력이 상대적으로 덜 중요해진다. NVIDIA A100은 첫 발표 때 40GB 모델을 공개했지만, 1년이 되는 시점에 80GB 메모리 모델을 다시 발표했다. 훈련 과정이든 인퍼런스 과정이든, 모델을 메모리에 올렸다 내렸다 하기엔 크기가 너무 컸다. 또한 거대 언어 모델을 "인퍼런스" 하는 과정은 GPU나 NPU에 대한 사고의 역전을 불러왔다. 끊임없이 가중치 행렬을 갱신해야 하는 훈련 과정과 달리, 인퍼런스 과정은 메모리에 올린 고정된 모델 구조를 따라 입력 데이터를 흘려 결과를 보는 식으로 동작한다. 따라서 연산의 비중이 엄청나게 줄어들고 메모리의 속도가 엄청나게 중요해지고 있다. NVIDIA는 2022년 하반기 80GB의 메모리 용량으로 H100을 발표했다. 그러나 반 년도 지나지 않아 실제 H100을 수령한 사람도 거의 없는 시점에 188GB 용량의 H100 NVL을 내놓았다.^[26]

메타는 개인용 서버에서도 무리하면 돌려볼 수 있는 언어 모델인 LLaMA^[27]를 내놓았다. LLaMA는 온갖 라이선스 제약이 붙어있음에도 불법 유출본으로 퍼졌고, 스탠포드에서 파인 튜닝한 Alpaca-LLaMA는 (상대적으로) 작은 모델로도 상당한 성능을 발휘할 수 있는 가능성을 보였다. 이후 라이선스 문제 없는 다양한 언어 모델들이 계속 공개되며^[28] 오픈 언어 모델들의 가능성의 불을 지피고 있는 동시에 어느 정도 파라미터 크기의 모델이면 만족할 수 있는가에 대한 새로운 물음을 불러 일으켰다. 모델이 작으면 창발 현상이 발견되지 않고 멀티 모달 모델로 쓸 수가 없다. 모델이 크면 실제 운영에 너무 큰 돈이 든다.

거대 언어 모델은 어디까지 커질 수 있을까. 더 큰 모델에 대한 준비의 흔적은 사방에서 보인다. 분산 모델 훈련에서 가장 자주 쓰이는 마이크로소프트의 DeepSpeed 프레임워크는 2021년 NVMe SSD를 활용하여 1조~10조 파라미터를 훈련할 수 있는 확장인 ZeRO Infinity^[29]를 추가했다. 그러나 이렇게 많은 파라미터를 가진 모델들은 실제 서비스가 불가능하다. 실질적으로는 서비스 가능한 모델 크기의 한계를 정해 두고 그 안에서 파인 튜닝하는 방식의 접근이 진행된다. ZeRO 등의 기술은 초거대 스케일의 모델을 훈련하기 위해 개발되었지만, 매우 적은 자원으로 파인 튜닝을 할 수 있게 하므로 다양하게 응용되고 있다.

• PaLM-e, 5600억 파라미터
• Pythia, 12억 파라미터
• LLaMA, 65억 파라미터

그 외 수많은 ~ 120억 파라미터의 모델들

---

20억~120억 파라미터 정도의 다양한 ‘말을 잘하는’ 모델들에 대한 다양한 시도들이 하루에 몇 개씩 등장하고 있다. LLaMA는 의도치 않게 개인이 만져볼 수 있는 파운데이션 모델을 널리 퍼뜨렸다. 보통 사람들이 만족할 만한 대화를 만들어내는 "말 잘하는 모델"의 수준은 예전에 달성했음을 수많은 사람들이 깨닫게 되었다. 어느정도 컴퓨터에 지식이 있고 돈을 쓸 수 있는 개인이나 조직, 단체들이 언어 모델 파인 튜닝을 다양한 방법으로 시도할 수 있는 용기가 생겼다.

동시에 말을 잘하는 정도를 넘어선 모델들의 연산 자원 요구량은 차원이 다르게 크다는 것도 함께 알려지는 중이다. 약 반 년 가까이 새로 등장하는 거대 언어 모델의 크기는 6000억 파라미터 미만으로 유지되고 있다. 더 이상의 크기 확장에 천착할 만큼의 결과가 등장 하지 않는 것일 수도 있고, 현재의 하드웨어 및 비용이 만들어낸 기술 장벽이 가로막고 있을 수도 있다. 또는 그 크기가 상용화가 불가능한 영역에 걸쳐 있기에 이제 적절한 크기 이하로 유지하려는 움직임일수도 있다.

2015년 GPU 4대를 운영하는 오픈소스로 시작한 Backend.AI는 2023년엔 몇 천 대 규모의 GPU를 다루며 곧 만 대를 바라본다. 우리를 포함한 모든 환경이 엄청나게 변했다. 문제들을 캐면 캘수록 마치 감자 줄기처럼 끝없이 다음 문제가 이어 나온다. 거대 언어 모델의 크기에 얽혀 수많은 문제들을 풀며 살아가다가, 이 문제의 끝은 어디에 다다를까 가끔 생각한다.

생각이 많은 밤이면, 모르는 사이에 관심에서 멀어져버린 튜링 테스트 마냥 우리 모두가 어떤 지점을 지나버렸을지도 모른다는 생각이 종종 든다. 풀어야 했던 문제를 풀었거나, 아직 풀면 안되는 문제를 풀어버렸을 것 같다. 설렘이 현기증이 되고 기대가 우울함이 되는 복잡한 감정이 오간다.

---

• [1] 페이스북 글
• [2] 뉴런 사이의 연결 뿐 아니라 다양한 파라미터들이 있으나 모델 크기가 크면 상대적으로 작으므로 편의상 엄청나게 단순화하였다.
• [3] 가상 머신 등이 아닌 날 것 그대로의 물리적 컴퓨터. 클라우드에서는 관리 소요 감소 및 유연한 자원 관리를 위해 베어 메탈에 하이퍼바이저를 올려 가상 머신을 운영하거나, 컨테이너 기반으로 관리하는 것이 일반적이다. 비용 문제로 인하여 소규모 연구소 및 대학 등에는 아직 대중화되지 않았다.
• [4] Job Scheduler. 프로세스들을 실행하고 관리하는 과정을 돕는 소프트웨어. Slurm 등이 보편적으로 쓰인다.
• [5] https://www.openai.com (2015). 2020년 이후 OpenAI는 구현체를 공개하지 않았으며, 2023년 이후에는 논문 대신 테크 리포트 정도만 제공하고 있다. OpenAI가 아직 Openness를 추구하는 AI 개발 조직인지에 대해서는 2023년 현재 여러 의견이 있다.
• [6] https://www.tensorflow.org, Google (2015)
• [7] "AlphaGo - The Movie" 당시 분위기를 느끼지 못한 분들은 다큐멘터리를 참고 (2018)
• [8] J.Shin "Creating AI chat bot with Python 3 and Tensorflow" PyCon APAC 2016 (Korean) / (English) (2016) 여러 나라에서 소개할 기회가 있어 동일 주제로 다양한 발표 영상이 있으나 이 두가지가 최초의 발표이다.
• [9] J.Shin "전자양의 꿈을 꾸는 안드로이드: Python과 NLTK, TensorFlow를 이용한 챗봇 감정모형 구현" PyCon KR 2017 (2017)
• [10] 구글 스타트업 캠퍼스에서 인터뷰한 기록이 유튜브에 남았다.
• [11] "Transformer (machine learning model)"
• [12] J. Devlin et al., "BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding" Arxiv:1810.04805 (2018)
• [13] Y. Liu et al., "RoBERTa: A Robustly Optimized BERT Pretraining Approach" Arxiv:1907.11692 (2019)
• [14] A. Radford et al., "Language Models are Unsupervised Multitask Learners", (2019)
• [15] J. Kaplan et al., "Scaling laws for neural language mod- els" Arxiv:2001.08361 (2020)
• [16] C K. Joshi, "Transformers are Graph Neural Networks", The Gradient (2020)
• [17] Microsoft, "DeepSpeed: Extreme Speed and Scale for DL Training and Inference", (2019)
• [18] J. Wei et al., "Emergent abilities of large language models" Arxiv:2206.07682 (2022)
• [19] E.Hu, G. Yang, J.Gao, "Tensor Programs V: Tuning Large Neural Networks via Zero-Shot Hyperparameter Transfer" Arxiv:203.03466 (2022)
• [20] A Zeng et al., "GLM-130B: An Open Bilingual Pre-trained Model" Arxiv:2210.02414 (2022)
• [21] OpenAI, "Introducing ChatGPT" (2023)
• [22] 랙 이라는 데이터센터용 가구에 설치하는 컴퓨터 한 대를 노드 하나로 간주하면 된다. A100 GPU 8대가 설치된 노드 하나는 보통 랙 안에서 6칸에서 8칸을 차지하며, 랙 하나에는 40칸 내외의 노드를 설치할 수 있다.
• [23] 일반적인 대학 건물의 한 개 층 전력이 100kW 내외이다.
• [24] "NVIDIA Teams With Microsoft to Build Massive Cloud AI Computer" (2022)
• [25] 개인적인 추산에 따르면 ChatGPT의 경우 GPT-3.5기준 원가는 월 42달러 이상이다. 계산 과정은 링크 참조. 페이스북 글
• [26] "NVIDIA H100 NVL for High-End AI Inference Launched" (2023)
• [27] H Touvron et al., "LLaMA: Open and Efficient Foundation Language Models" Arxiv:2302.13971 (2023)
• [28] 대표적으로는 ElutherAI의 Pythia-12B 모델에 자체 데이터를 결합한 Dolly 2 (2023) 등이 있다.
• [29] S. Rajbhandari et al, "ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning", Arxiv:2104.07857 (2021) 1조 파라미터 모델을 훈련을 위해 메모리 오프로드 없이 GPU에 올리려면 NVIDIA A100 GPU (80기가) 모델 기준으로 320장이 필요하다.

개요

OpenUp에서 주최한 오픈소스 컨트리뷰션 아카데미(이하 컨트리뷰션 아카데미)에 지원하여 래블업 주식회사(이하 래블업)에서 11월부터 12월까지 8주간 가을 인턴을 진행했으며, 이후 1월부터 2월까지 8주를 추가 연장하여 총 16주간 근무했다.

군대를 전역하고, 개발자로서 첫 회사인 래블업을 다니면서 경험했던 과정들을 작성했다.

지원동기

컨트리뷰션 아카데미 전에도 래블업에 대해서 관심을 가지고 있었는데, 마침 컨트리뷰션 아카데미를 통해서 기여할 수 있는 기회가 생겼다.

컨트리뷰션 아카데미 기간 동안에 Backend.AI의 webui 이슈를 해결하고 리팩토링을 진행했었다.

컨트리뷰션 아카데미를 참여하는 동안 Backend.AI에 대한 애정과 관심, 그리고 재미를 많이 느꼈고, 프로그램이 끝나고 계속해서 기여 하고싶다는 생각을 하게되었다.

마침 컨트리뷰션 아카데미와 연계로 래블업에서 근무할 수 있는 기회가 생겼고, 망설임 없이 지원하게 되었다.

온보딩

인턴이 시작되고 첫 3주동안은 온보딩 과정을 진행했다.

RealTime Chat을 구현, Backend.AI 환경 구성, Pebble Seminar 순서로 진행했다.

RealTime Chat

Backend.AI의 Core쪽 코드에 친숙해기지 위한 첫 과제였다. 실시간 채팅 앱을 Python을 이용하여 구현하였으며 aiohttp, aioredis, aysncio 라이브러리를 사용하였다.

채팅의 내용을 저장해야한다는 조건이 없어 InMemoryDB인 redis를 사용했다.

채팅방에 입장하면 사용자는 채팅방에 subscribe가 되도록 했으며, 사용자가 메세지를 입력하면 subscribe된 유저 즉 같은 채팅방에 있는 다른 유저들에게 입력한 메세지를 publish하도록 구현했다.

RealTime Chat 동작 화면

코딩테스트를 준비하면서 Python을 기본적으로 다룰 수는 있었지만, aiohttp, asyncio, aioredis 등 과 같은 라이브러라를 사용해본 경험이 없어서 개념을 익히고 이해하는데 시간이 걸렸다.

하지만 해당 과제를 통해서 Backend.AI의 Core쪽 코드들을 이해하는데 많은 도움이 되었으며, 새로운 라이브러리들을 공부할 수 있어서 좋았다.

Backend.AI 환경 구성

컨트리뷰션 아카데미에서 이미 Backend.AI를 설치 해본 경험이 있기 때문에, 인턴 기간에 다시 환경 구성하는 과정이 어렵지는 않았다.

하지만 컨트리뷰션 아카데미에서 설치를 시도하면서 나 또한 많은 에러와 실패를 겪으면서 Backend.AI 설치가 쉽지않다는 것을 알고있었고, 같이 인턴십을 진행하시는 다른 분도 설치 과정에서 어려움을 많이 겪으셨다.

이미 한번 그 실패들을 경험하고, 해결법을 알고있는지라, 도움을 드릴 수 있었고, 빨리 설치하고 다른 업무를 진행할 수 있었다.

환경을 구성하면서 가상 머신과 VPN도 설정했고, 로컬에서 문제가 생겨도 업무를 할 수 있도록 가상 머신에도 환경을 구성했다. 이렇게 가상 머신에 구성을 하고나서 이후 업무를 하는 동안 Local은 개발용으로 많이 사용했고, 가상 머신은 테스트 서버를 구성하여 사용했다. 회사에 가상 머신을 쉽게 관리하고 구성할 수 있는 VM Farm이 있어, 개발과 테스트 환경을 구성하기 너무 좋았다.

Pebble Seminar

RealTime Chat과 Backend.AI 환경 구성을 마친 후, Backend.AI의 구조와 코드를 이해하고, 그 내용을 바탕으로 짧은 세미나를 준비했다. 나는 Backend.AI WebUI에서 사용돠는 GraphQL과 Relay에 대해서 발표를 하게 되었다.

GraphQL은 사용해본 경험이 있으나 다른 사람들 앞에서 발표하기에는 가지고 있는 지식이 부족했고 Relay는 처음들어본 라이브러리였기 때문에, Pebble Seminar를 준비하는데 있어 많이 걱정되고, 많은 문서들을 읽으면서 준비했다. 우선 GraphQL과 Relay 공식 문서들을 읽으면서 개념을 익혔고, Backend.AI 코드들을 하나씩 분석하면서 Backend.AI에서는 어떻게 적용이되었고, 어떻게 동작하는지에 대해서 파악했다.

Pebble Seminar 준비 자료

Pebble Seminar를 준비하면서 코드륵 분석하다보니, WebUI에서 동작하고 있는 코드들을 자연스럽게 이해하게되었고, 이후 이슈들을 해결하는 과정에서 조금 더 쉽게 문제가 발생하는 코드를 찾고, 해결하는데 큰 도움이 되었다.

Backend.AI 이슈 해결 및 기능 구현

온보딩을 마치고, 드디어 프론트엔드 팀에 합류하여 Backend.AI 이슈를 해결하고 기능 구현을 시작했다. 나는 프론트엔드 리더분과 커피챗을 가지며 이번 인턴십 기간 업무 카테고리를 정했다.

1. Table Column Setting 컴포넌트 제작
2. E2E Test 관련 조사
3. 데일리 업무

11월부터 12월까지 8주간 진행된 인턴십 기간에서 총 19개의 Pull Request를 작성했고, 그 중 18개가 Merge되고 1개는 리뷰가 진행중인 상태이다. 컨트리뷰션 아카데이를 활동하면서 이슈를 찾고, 할당하는데 있어서 어려움이 적었고, 이슈를 해결하는데 재미를 느껴서 남들보다 더 많은 이슈들을 해결할 수 있었다.

기능 추가 PR

1. Table Columns Setting 구현

https://github.com/lablup/backend.ai-webui/pull/2071

인턴십 기간에서 목표로 했던 이슈 중 하나였다. 가을 인턴 기간에서 유일하게 기존에 있던 컴포넌트를 리팩토링이 아닌, 처음부터 구상하고 구현했다. 이 기능을 구현하기 전에는 간단한 기능이고 금방 끝낼 수 있을거라고 생각했지만 생각과 다르게 흘러갔다.

우선 이전까지는 컴포넌트를 새롭게 만드는 것을 너무 쉽게 생각했구나를 많이 느꼈다. 이전에도 컴포넌트를 만들기 전에 디자인하고, 전달받을 props들을 생각하긴 했지만, 해당 이슈를 통해서 컴포넌트를 새롭게 만들 때, 확장성을 생각해서 조금 더 시간과 노력을 투자해야한다고 느꼈었다. 또한 다른 사이트들은 어떤 식으로 디자인되어 있는지, 적용된 기능들이 무엇이 있는지 좀 더 관심있게 봐야겠다를 느낄 수있었다.

Table Columns Setting

2. 모델 서빙 페이지 Table에 서비스 엔드포인트와 소유자 Column 추가

https://github.com/lablup/backend.ai-webui/pull/2047

기존에는 모델 서비스를 만들고 나면 endpoint를 상세 페이지에 들어가서 확인해야하는데, 자주 사용하는 기능이다보니 Table Column에 추가되었으면 하는 요청이 있었다. 또한 admin 계정에서는 같은 그룹에 속한 유저의 서비스도 다 보여지기 때문에, 소유자가 누구인지도 나타 낼 수 있는 Column이 보여지면 좋겠다는 의견이 있었다. 해당 기능을 구현하기 위한 GraphQL field는 이미 구현되어있었기 때문에 데이터를 받아오는 query의 field를 추가하여 엔드포인트와 서비스 소유자의 데이터를 받아왔고, Table의 Column을 추가하여 데이터를 나타냈다. 소유자 Column은 Admin 권한을 가진 계정에만 나타난다.

구현 모습. Admin 계정에서 나오는 화면(왼쪽) 과 User계정에서 나오는 화면(오른쪽)

3. CANCELLED 상태인 세션의 로그 버튼 비활성화

https://github.com/lablup/backend.ai-webui/pull/2045

CANCELLED 상태는 컨테이너가 생성된 적이 없거나 생성에 실패한 상태이다. 기존에는 CANCELLED 상태인 세션에도 로그 버튼이 활성화 되어있어, 사용자가 로그 버튼을 누르게된다면 에이전트가 컨테이너 정보를 찾을 수 없어 500에러가 나타났다. 그래서 해당 PR에서 CANCELLED 상태인 세션은 사용자들이 로그 버튼을 누를 수 없게 비활성화 하는 작업을 진행했다.

TERMINATED 상태의 세션(1번 세션)과 CANCELLED 상태의 세션(2번 세션)

4. Dark mode를 위한 테스트 및 custom hook 제작

https://github.com/lablup/backend.ai-webui/pull/2120

Dark mode를 적용하기 전 색깔을 하드코딩한 컴포넌트를 찾고, Dark mode 적용하기 위한 useThemeMode라는 이름의 custom hook을 구현했다. Custom hook을 만들 때 ahooks의 useLocalStorageState hook을 사용해서 구현하려고 했으나, 같은 Key값을 사용하는 state에 대해서 자동으로 state 관리가 되는 줄 알았으나 예상과 다르게 독립적으로 동작하는 것을 확인했다. 그래서 같은 Key값을 사용하는 state에 대해서 값이 바뀌면 자동으로 바뀌도록 구현하기 위해 useLocalStorageGlobalState 라는 이름의 custom hook을 추가했고, 해당 hook을 사용해서 Dark mode를 설정할 수 있는 useThemeMode라는 custom hook을 만들 수 있었다.

Bug fix PR

1. 초대 토큰 값 없이 회원가입 가능

https://github.com/lablup/backend.ai-webui/pull/2046

config.toml에서 allowSignupWithoutConfirmation이라는 옵션을 true로 변경하게되면, 초대 토큰없이 회원가입이 가능한데, 사용자가 회원가입 버튼을 누르게되면, 토큰 값이 undefined되어 있다고 에러를 발생했었다. 따라서 해당 PR에서는 allowSignupWithoutConfrimation의 옵션이 true면 token 변수를 사용하지 않도록 수정했다. 또한 이전에는 회원가입 버튼을 누르고 나서 core쪽에서 데이터를 처리하는 동안 다른 입력 값들을 수정할 수 있었으며, dialog가 닫힌 뒤, 다시 열면 이전 데이터가 남아있는 이슈가 있었는데, 해당 PR에서 데이터를 처리하는 동안 다른 입력 값들을 입력할 수 없게 설정했으며, dialog가 닫히면 이전에 입력한 값들이 clear되도록 설정했다.

2. 사용자 관리 페이지에서 서브 탭에 맞는 화면 표시

https://github.com/lablup/backend.ai-webui/pull/2055

사용자 관리 페이지에는 활성화 상태인 사용자와, 비활성화 상태인 사용자들을 보여줄 수 있는 서브 탭이 존재한다. 하지만 해당 페이지에서 작업을 하다가 다른 페이지로 이동한 뒤 다시 사용자 관리 페이지로 돌아오면 서브 탭은 비활성으로 되어있지만, 실제 화면에는 활성화 상태인 사용자 리스트들이 나오는 문제가 있었다. 해당 문제는 사용자들에게 혼란을 줄 수 있는 부분이라 생각했고, 해당 PR에서 수정하게 되었다. 다른 페이지로 이동할 때, 현재 작업중인 서브 탭이 무엇인지 기억하여, 다시 해당 페이지로 돌아왔을 때 이전에 작업했던 서브 탭과 관련된 화면을 나타낼 수 있도록 수정했다.

수정 전 사진(왼쪽)과 수정 후 사진(오른쪽)

인턴 기간 연장

이슈를 해결하다보니 8주라는 시간은 금방 지나갔고, 가을 인턴을 마무리해야하는 시간이 찾아왔다.

군대를 전역하고 개발자로서 첫 사회생활이라 중요한 시기였는데 래블업에서 인턴을 하면서 나의 부족한 점이 무엇인지, 어떤 부분을 더 준비해야하는지, 다른 분들은 어떻게 개발을 하는지 등등 을 많이 느낄 수 있는 기간이었다. 2달이라는 시간이 매우 짧게 느껴졌고, 2달동안 매우 즐겁게 일을 했기 때문에, 좀 더 일해보고 싶다라는 생각이 들었다. 그래서 리더분께 인턴십 기간을 연장하고 싶다는 의견을 말씀드렸고, 8주를 더 연장하여 2월까지 인턴십을 진행하기로 했다. 그리고 가을 인턴에서는 나의 부족한 부분에 대해서는 많이 생각이 났지만, 나의 장점을 찾지 못했다. 그래서 아래 3가지 개인적인 목표를 세우며 시작하기로 다짐했다.

1. 이번 기간에는 장점을 찾자
2. 시간이 될 때마다 document를 읽자
3. 아쉬움이 없을만큼 더 열심히 일해보자

연장된 기간 이슈 해결 및 기능 구현

연장된 기간에 하는 일이 이전과 크게 다르지 않았다. 온보딩 기간과 설치과정이 없어 이슈 해결에 좀 더 집중할 수 있는 기간이었다.

기능 추가 PR

1. ErrorLogList 리팩토링

https://github.com/lablup/backend.ai-webui/pull/2131

기존 Lit element로 구현되어 있던 ErrorLog List를 React로 리팩토링을 진행했다. 해당 기능들은 리팩토링을 하고나서 개인적으로도 잘 사용하고 있어 가장 만족스러운 이슈였다.

리팩토링 전(왼쪽)과 리팩토링 후(오른쪽) 사진

리팩토링을 진행하면서 기존에는 없었던 Search 기능과 Error filter 기능이 추가되었다.

추가된 Search 기능(왼쪽)과 Filter 기능(오른쪽)

2. Modal 드래그 기능

https://github.com/lablup/backend.ai-webui/pull/2179

React-draggable 라이브러리를 사용하여 Modal이 drag될 수 있도록 기능을 추가했다. Modal에 Draggable props를 추가하여 drag가 필요한 modal에서 적용할 수 있다.

드래그 가능한 Modal

Modal 제목 왼쪽에 있는 아이콘을 클릭하면서 마우스를 움직이면 Modal을 화면에 원하는 위치로 이동시킬 수 있다.

현재는 사용자 관리페이지의 사용자 정보를 볼 수 있는 Modal과 사용자 설정을 변경할 수 있는 Modal에 적용되어 있어 확인할 수 있다.

아직은 사용되는 곳이 많지는 않지만, 점점 컴포넌트들이 늘어나고, 기능들이 추가되면서 유용하게 사용될 수 있다고 생각한 PR이었다.

Bug fix PR

1. Vfolder 초대 권한 수정

https://github.com/lablup/backend.ai-webui/pull/2143

Group vfolder 사용자 권한이 수정되지 않는 문제가 있었다. 권한을 수정하려고 하면 select에서 item들이 제대로 표시 및 선택이 되지 않는 문제가 있었다. 기존에는 option 태그를 사용해서 item들을 표시해주고 있었는데, mwc-list-item으로 변경하여 item들을 표시해주었고, overflow 옵션을 수정하여 해당 이슈를 해결했다.

PR 전 사진(왼쪽)과 PR 후 사진(오른쪽)

2. ResourceGroupSelect이 Card밖으로 나가는 문제

https://github.com/lablup/backend.ai-webui/pull/2166

ResourceGroupSelect의 값이 너무 크면 Card밖으로 표시가 되는 문제가 있었다.

문제가 되었던 증상들

해당 문제를 해결하기 위해서 Select에 max-width css를 설정하여 Card의 width를 넘지 못하도록 하였다.

또한 해당 PR에서 Select에서 Search기능을 추가했는데, 해당 기능을 추가하면서 ahooks의 useControllableValue라는 hook을 사용했다. useControllableValue는 부모나 자신이 props를 관리할 수 있게 도와주는 hook이다. 간단한 PR이었지만 useControllableValue를 처음 사용하다보니 생각보다 시간이 오래 걸린 PR이었다. 해당 이슈를 해결하면서 리더분과 다른 인턴분의 도움을 받아 해결할 수 있었다.

3. 요약 페이지에서 키페어 생성&관리 버튼 눌렀을 때 키페어 리스트가 보여지지 않는 문제

https://github.com/lablup/backend.ai-webui/pull/2194

요약 페이지에는 새 키페어 생성, 키페어 관리 라는 버튼이 있는데, 해당 버튼을 누르면 단순히 사용자 관리 페이지로 이동하여 키페어 리스트가 아닌 유저 리스트가 보여지는 이슈가 있었다.

요약 페이지에서 새 키페어 생성 버튼과 키페어 관리 버튼

새 키페어 생성 버튼을 눌렀을 때(왼쪽) 과 키페어 관리를 눌렀을 때(오른쪽)

해당 이슈는 크리티컬한 이슈는 아니었지만, 내가 처음으로 Backend.AI를 사용해보면서 키페어라는 기능을 잘 이해하지 못했을 때, 많이 혼동이 있었던 경험때문에 해결했었다.

해당 이슈를 해결하고 나서는 의도한 대로 키페어 리스트들이 화면에 나타나는 것을 확인할 수 있다.

이슈를 해결 한 뒤 새 키페어 생성 버튼을 눌렀을 때(왼쪽) 과 키페어 관리를 눌렀을 때(오른쪽)

인턴십을 마치며

전역을하고 친구의 추천을 시작하게된 컨트리뷰션 아카데미를 인연으로 래블업에서 긴 시간동안 기여를 할 수 있었다. 이전에 다른 회사의 인턴 경험, 프로젝트 경험이 없었기 때문에, 전역을 한 뒤 새롭게 시작하는 나한텐 있어서 매우 중요한 시기였는데, 래블업에서 활동할 수 있어서 나의 장단점, 부족한 기술, 오픈소스 회사의 문화 등을 경험할 수 있어서 너무 좋았다. 수평적인 구조, 자유로운 분위기, 쾌적한 근무 환경과 좋은 장비들 까지 매일 출근하고 싶게 만드는 회사가 몇이나 있을까? 4개월을 래블업에서 근무했지만, 매일 출근하고 싶고, 래블업이라면 내가 오랫동안 재미있고 원하는 일을 하면서 회사를 다닐 수 있겠다 라고 생각이 들었다. 4개월이라는 시간동안 래블업에서 서비스하고 있는 Backend.AI에도 정이 들어서, 매년 래블업에서 주최하는 컨퍼런스도 시간이 될 때마다 참가하여 발전된 모습과, 기술들을 보러 갈 예정이다.

래블업 사무실

이 포스트는 필자의 개인 블로그에 함께 게시되었습니다. https://gee05053.tistory.com/32

개요

과기특성화대학 공동운영 산학협력(CUop)에 지원하여 래블업 주식회사(이하 래블업)에서 8주간 인턴으로 근무했다.

온보딩, Backend.AI 개발, PyCon 참가를 통해 경험한 것들을 작성했다.

지원 동기

우연히 보게된 PyCon 발표 세션을 통해 래블업에 대해 처음 알게 되었다. 기술적으로 깊이 있고 열정이 있는 구성원이 많은 회사라는 것을 알 수 있었다. 나는 Python과 비동기 프로그래밍에 관심이 많았기 때문에 래블업을 지원했다.

온보딩

첫 2주동안 온보딩 과정을 진행했다.

Realtime Web Chat 구현, Backend.AI 개발 환경 구축, 코드 베이스 세미나 순서로 진행했다.

Realtime Web Chat

Python asyncio에 친숙해지기 위한 과제이다. 실시간 채팅 앱을 비동기 웹 프레임워크인 aiohttp와 인메모리 데이터베이스인 redis를 이용해서 개발했다. 그리고 python과 redis를 한 번에 빌드하기 위한 docker compose를 설정하는 것도 과제에 포함되었다. 자세한 내용은 Github Readme를 참고하면 된다.

redis를 통해 메시지를 broadcast 하기 위해 Redis pub/sub을 이용했다. pub/sub은 메시지를 저장하지 않고 그대로 전달하는 플랫폼 역할을 한다. 메시지를 따로 저장하는 요구사항이 없었으므로 Redis pub/sub을 이용했다. 또한, Redis pub/sub 과정을 asyncio.create_task()를 통해 task로 등록하여 event loop에 의해 동작하도록 했다. Realtime Web Chat 실행 화면

asyncio의 기본 동작에 대해 이해할 수 있었다. 어려운 부분은 질문하며 해결할 수 있었다. 래블업에서는 Microsoft Teams를 통해 자유롭게 질의응답을 할 수 있어 인턴 및 주니어 개발자가 성장할 수 있는 환경을 갖추었다고 생각한다.

Backend.AI 개발 환경 구축

Backend.AI를 VM Farm 및 로컬 VM에 설치하여 직접 실행해보았다. 공식 문서를 읽으며 진행했는데 그 과정이 순탄치 않았다. 다양한 에러를 마주 했는데 인턴 동기들과 공유도 하고 Teams에 질문도 하며 해결했다.

💡 VM Farm은 가상 머신(Virtual Machine)을 관리하고 실행하는 환경을 뜻한다. 래블업은 독자적인 VM Farm을 가지고 있다.

그동안은 로컬에서만 개발을 했었는데 VM Farm과 VSCode를 SSH로 연결하여 개발하는 경험을 처음 해보았다. Backend.AI를 개발하기 위해서는 여러 프로세스들 (Manager, Agent, Storage proxy, Web server 등)과 Docker Container들을 실행해야 한다. 랩탑을 사용할 경우, 배터리에 부담이 가는 수준이다. 하지만 VM Farm을 사용하면 SSH 연결만 하면 되기 때문에 가볍게 Backend.AI를 개발할 수 있다. 실제로 회사 밖에서 랩탑을 충전할 수 없던 상황에서 VM Farm을 사용하여 오랫동안 개발할 수 있었다.

코드 베이스 세미나

Backend.AI에서 어려운 부분을 중심으로 코드를 본 후, 이해한 내용을 바탕으로 발표하는 세미나를 준비하게 되었다. Manager, Agent, GraphQL 중에서 나는 Manager 파트 발표를 맡았다.

Backend.AI는 오픈소스이기 때문에 공식 문서가 잘 쓰여 있다. 공식 문서를 보면서 전체적인 구조를 파악하고 궁금한 부분은 직접 사원분들에게 여쭤보면서 Backend.AI 아키텍처 공부를 진행했다. Backend.AI Manager의 Session / Kernel 생성, 스케줄링 제어가 발표 주제였기 때문에 Manager 코드를 보면서 manager process의 로그를 분석하는 방식으로 공부를 진행했다. 세미나 발표를 준비하며 그렸던 시퀀스 다이어그램

로그를 분석하며 Session 상태가 Preparing에서 다시 Pulling으로 돌아가는 버그를 발견했다. 로그를 하나씩 분석한 보람(?)을 느꼈다. 비동기 코드 베이스라 로그를 순서대로 분석하는게 어려웠다. 하지만 Call graph와 시퀀스 다이어그램을 그리는 것이 큰 도움이 되었다.

Backend.AI 개발

온보딩이 끝나고 Backend.AI 개발을 시작했다. GitHub Issue를 보고 자발적으로 지원하거나 이슈를 직접 발견해 해결하는 방식으로 진행했다.

Backend.AI repository 에서 9개의 Pull Request, Backend.AI-WebUI repository 에서 2개의 Pull Request를 생성했고 모두 Merge 되었다!

나는 우선순위가 높은 이슈 중에서 자신 있는 것들을 골라 해결했다. 두달이라는 짧은 시간동안 최대한 많은 기여를 하고 싶었기 때문이다.

첫 PR

https://github.com/lablup/backend.ai/pull/1395

세미나를 준비하면서 찾아낸 버그를 수정하는 PR을 생성했다. API Parameter를 수정하면 되는 쉬운 PR 이었다. 하지만 branch name convention, commit convention, news fragment에 대해서 알 수 있었다. 그리고 GitHub Actions에 의한 CI (Countinuous Integration, 지속적 통합) 과정을 경험하고 Git 관련 여러 삽질도 미리 할 수 있었던 좋은 경험이었다.

💡 news fragment는 PR에 의해 생성된 브랜치가 무엇을 하려는 브랜치인지 한 문장으로 설명하는 Markdown이다. 미래에 다시 이 PR을 봤을 때, 무엇을 하려 했던 PR이었는지 알 수 있도록 간단명료하게 작성해야 한다.

vfolder 관련 PRs

Teams에 인턴에게 줄 만한 이슈가 있다는 소식을 듣고 바로 지원했다. vfolder라는 새로운 개념을 공부해야 했지만, 이렇게 제품에 대해 이해해 나간다는 것이 중요할 것 같았다.

PR (1)

https://github.com/lablup/backend.ai/pull/1397

project type vfolder는 admin만이 생성할 수 있다. keypair resource policy의 max_vfolder_count에 상관없이 vfolder를 생성할 수 있어야 하는데 user type vfolder가 max_vfolder_count를 넘어설 경우, project type vfolder를 생성할 수 없는 이슈였다. 처음에는 용어부터 헷갈렸지만 코드를 분석하고 질문도 하며 용어를 해석할 수 있었다.

PR (2)

https://github.com/lablup/backend.ai/pull/1400

PR (1)을 해결하며 발견한 새로운 버그들을 해결했다.

PR (3)

https://github.com/lablup/backend.ai/pull/1417

PR (1) 이슈와 연관된 이슈를 발견했다. DB migration과 GraphQL이라는 새로운 개념이 등장했지만 해보고 싶었던 것들이라 지원했다. Alembic이라는 DB migration 툴을 이용했다. 그리고 GraphQL 스키마 개념을 공부하고 하위 호환성을 지원하기 위해 query와 mutation 코드를 수정했다. 수정한 코드를 테스트하기 위해서 cURL을 사용하려 했지만 GraphQL은 REST API 보다 훨씬 긴 request 형태를 가지고 있어서 번거로웠다. GraphQL을 잘 알고 있는 인턴과 사원분에게 질문하며 test code를 작성했다. CLI 형태로 간편하게 수정한 query와 mutation을 테스트하는 python code를 작성하여 테스트를 편하게 할 수 있었다.

WSProxy 관련 PRs

Teams에 이슈가 올라와 지원하였다. WebUI에서 resource group의 wsproxy 주소가 유효하지 않은 경우, 세션 삭제가 불가능한 버그가 있었다. WebUI 개발도 경험해보고 싶어 지원했다.

PR (1)

https://github.com/lablup/backend.ai/pull/1423

이슈를 해결하기 위해 WebUI 코드를 읽어봤는데 wsproxy의 개념이 잘 잡히지 않았다. wsproxy에는 v1과 v2가 있다는 것을 알았는데 둘의 차이를 알기 쉽지 않아서 사원분들에게 질문했다. v1과 v2의 가장 큰 차이는 트래픽의 경로였다. v1은 manager를 거쳐서 컨테이너와 통신하는 반면, v2는 manager를 거치지 않고 바로 컨테이너와 통신할 수 있어 더 빠르다. wsproxy가 어떤 역할과 v1, v2의 차이를 알고 나니 코드가 어떻게 동작하는지 더 수월하게 알 수 있었다. 그리고 생각보다 많은 사원분이 차이를 잘 모르는 것을 알게 되었다. 쉬워 보이는 질문이 조직 안에서 나오지 않은 질문일 수도 있음을 깨달았다.

PR (2)

https://github.com/lablup/backend.ai-webui/pull/1819

이슈를 해결하기 위해서 webui 코드도 수정했다. JavaScript 코드를 수정하기 위해서 Callback 함수, Promise 객체, async/await에 관해 공부했다. 다른 로직에 영향이 가지 않도록 에러 핸들링을 했고, 중복된 코드는 함수로 따로 정의 하여 코드의 중복을 없앴다.

PR (3)

https://github.com/lablup/backend.ai-webui/pull/1833

그런데 WebUI는 Backend.AI 22.09와 하위 호환성을 유지해야 하므로 HTTP Status 404도 처리해야 한다는 CEO님의 리뷰가 있어 404와 500을 모두 처리하도록 했다.

PR (4)

https://github.com/lablup/backend.ai/pull/1466

그런데 코드가 병합된 후에 버그가 발생했다. v1 wsproxy 설정 시, wsproxy-version에 대한 리턴값이 사라지는 버그였는데 내가 core 코드를 수정하다가 모든 분기에 대해 처리하지 못해서 생긴 버그였다. 급하게 코드를 수정했지만 간단한 실수라서 아쉬웠다. 이런 실수를 방지하기 위해 테스트 코드를 작성해야겠다는 생각이 들었다.

Manager 관련 PR

https://github.com/lablup/backend.ai/pull/1444

세미나를 준비하며 공부했던 manager에 대한 이슈가 생겼다. 인턴 기간이 얼마 남지 않은 상황에서 내가 가장 잘 알고 있는 코드에 대한 이슈를 해결하는 것이 기여할 수 있는 방법이라 생각했다.

이 PR은 코드 리뷰에 의해 많은 수정이 있었다. 처음에는 scheduler health check와 scheduler trigger를 동일한 API로 설계했었다. 코드 리뷰를 받은 후에, 두 기능을 다른 API로 나누어 책임을 분리했다. 그리고 원래는 schedule 함수에 관해서만 상태 정보를 저장했었는데 prepare 함수와 scale_services 함수에 대해서도 상태 정보를 저장했다. 왜냐하면 scheduler의 글로벌 타이머에 따라서 주기적으로 실행되는 세 개의 함수에 대해 상태 정보를 저장한 후에 trigger API를 만들어야 scheduler의 상태를 완전히 파악할 수 있기 때문이다. 또한, Manager 프로세스가 여러 개일수도 있기 때문에 Manager ID에 따라 scheduler의 상태를 저장할 수 있도록 설계를 바꿨다.

scheduler의 저장소에 대해서도 코드 리뷰가 진행되었다. 처음에는 기존 manager 상태 API에서 manager 상태를 etcd에 저장하는 코드를 보고 동일하게 scheduler의 상태를 etcd에 저장했다. etcd는 일관성을 유지해야 하는 설정 정보를 저장하는 데 유리하지만, write 속도가 느리다. redis는 휘발성이 있는 데이터베이스이지만 read/write가 많아도 성능이 좋다. scheduler 상태를 주기적으로 read/write 하고 일관성을 유지해야 하는 정보는 아니기 때문에 redis에 저장하는 것으로 변경했다.

Agent 관련 PR

https://github.com/lablup/backend.ai/pull/1472

Backend.AI의 Manager 부분을 어느 정도 이해했기 때문에 또 다른 중요한 컴포넌트인 Agent를 이해하고 싶었다. 마침 Agent에 대한 이슈가 생겨서 살펴보았다.

Backend.AI가 실행되는 동안 Agent의 내부 상태와 실제로 동작하는 컨테이너의 상태가 일치하지 않는 버그가 발생했다. 이에 따라 세션을 생성할 때, 실제로는 충분한 자원이 있음에도 불구하고 자원 할당 과정에서 InsufficientResource Error가 발생했다. 에러가 발생했을 때, 자원 할당 과정에서 무엇이 잘못되었는지를 알기 위해서 로깅을 개선할 필요가 있었다.

자원 할당 과정을 파악하는 것에 시간이 오래 걸렸다. 동시성 문제가 어려워서 CTO님과 많은 질의응답을 통해 대략적인 흐름을 파악하고 무엇을 로깅해야 하는지 알 수 있었다.

인턴이 끝나고 몆 주후, CTO님이 10개가 넘는 커밋을 통해 리팩터링과 테스트 코드까지 추가하시고 병합하셨다. 인상 깊었던 것은 에러를 재현하기 위해 테스트 코드를 작성하신 것이었다. 나는 에러를 재현하기 위한 복잡한 과정을 (PR 참고) 직접 수행했다. 그래서 개발 시간이 오래 걸리기도 했다. 이런 부분에서 생산성의 차이가 나타난다는 것을 알 수 있었다. 물론 테스트 코드를 작성할 생각은 했었지만, 구현이 너무 복잡할거라 생각했고 테스트 코드를 작성하느라 인턴이 끝날 것 같다고 생각했었다. 앞으로는 테스트 코드 작성에 너무 겁먹지 않고 일단 해보면서 배워야 겠다고 생각했다. 그리고 리팩터링은 코드 가독성을 중점으로 진행하신 것 같았다. 내가 수정한 부분의 함수가 너무 길어져서 가독성이 좋지 않았는데 리팩터링 후에는 함수가 짧아지고 로깅도 깔끔해져서 가독성이 좋았다. 구현하는데에서 멈추지 않고 좋은 코드를 만들기 위해 노력해야겠다는 생각을 했다.

PyCon 참가

8월 12, 13일에 래블업이 PyCon에 부스를 열었다. PyCon에 후원하는 회사는 부스 활동을 할 기회가 주어진다. 나는 인턴이었지만 부스활동에 참여 하고 발표 세션도 듣고 싶었다. 마침 회사에 PyCon 표가 남았다고 해서 참여할 수 있었다.

래블업 부스에서는 Llama2에게 10줄짜리 피라미드를 프롬프트를 통해 출력하도록 만드는 이벤트를 진행했다. 난이도가 그렇게 쉬운 편은 아니었고, Llama2가 잘 알아들을 수 있도록 풀어서 설명하는 것이 중요했다. 정답을 제출한 분 중 두 명을 추첨하여 닌텐도 스위치, 로지텍 마우스를 증정했다. 나는 부스에서 PyCon 참여자들이 이벤트에 참여할 수 있도록 안내하는 역할을 했다. 그리고 PyCon에 사원분들이 많이 오셨기 때문에 내가 듣고 싶은 발표 세션이 있으면 자유롭게 들을 수 있었다. 래블업은 오픈소스 기반 회사라 오픈소스에 기여하고 컨퍼런스에 참여하는 것을 독려한다. 실제로 PyCon에 참여한 발표자가 총 4명일 정도로 컨퍼런스에 참가하는 것을 중요하게 생각한다.

래블업 주식회사 부스

RustPython 세션 발표 중에 python lint 툴인 flake8과 isort를 대체할 수 있는 ruff라는 툴이 소개되었다. ruff는 Rust로 구성되어 있어 flake8에 비해 100배가 더 빠르다. Backend.AI에서는 flake8, isort를 통해 lint를 했었는데 CTO분이 ruff를 검토해 보시고는 코엑스 계단에서 바로 Backend.AI 프로젝트에 ruff를 도입하시는 것을 지켜보았다. 짧은 시간 내에 프로젝트에 새로운 툴을 적용하고 공식 문서까지 수정하는 것을 보면서 코딩에 관련된 프로세스에 정말 능숙하다고 생각했다. 나도 언젠가는 능숙한 개발자가 되고 싶다고 생각했다. PyCon이 끝나고 업데이트된 공식 문서를 보며 ruff를 Backend.AI 개발환경에 적용하고 lint가 100배 빨리 되는 것을 직접 체험했다. PyCon에 참여하지 않았다면 좋은 툴을 빨리 사용하지 못했을 것이다. 앞으로도 개발자 컨퍼런스에 계속 참여하고 싶다. 래블업 주식회사 구성원분들과 단체 사진

인턴십을 마치며

인턴십을 하며 최대한 많은 경험을 하려고 애썼다. 그리고 많은 기여를 하고 싶었다. 결론적으로, 많은 기여를 하기 위해 노력했기 때문에 많은 것을 경험할 수 있었다. Teams에서 언급되는 이슈에 빠르게 자원했다. 그래서 vfolder, wsproxy, web-ui, manager, agent라는 Backend.AI의 핵심 컴포넌트들을 이해할 수 있었다. 그리고 DB Migration, GraphQL, etcd 등의 새로운 개념들도 학습할 수 있었다. 주말 아침부터 저녁까지 컨퍼런스에 참여하는 것이 체력적으로 조금은 힘들었지만, 10개가 넘는 발표 세션을 자유롭게 들으며 영감을 얻고 부스 활동을 통해 다양한 사람들을 만나는 것도 재미있었다.

인턴십 동안 모르는 것을 적극적으로 질문했던 것 같다. 그 덕분에 이슈를 빠르게 해결할 수 있었다고 생각한다. 질문을 많이할 수 있었던 이유는 수평적인 래블업의 문화가 있었기 때문이라고 생각한다. 그리고 질문에 친절히 답변해주시는 분들이 많아서 활발하게 질문을 할 수 있었다. 이 자리를 빌어 도움을 주신 구성원분들에게 감사를 표하고 싶다.

내가 원했던 비동기 프로그래밍 경험을 포함해 GitHub 협업 방식, 영어 세미나 발표, 컨퍼런스 참가 등 다양한 것을 경험할 수 있었다. 이를 통해 개발자로서 큰 성장을 한 것 같다. 성장에 목마른 사람들에게 래블업 인턴십을 추천한다.

이번 포스팅에서는 래블업에서 지난 9개월 동안 개발자로 경험한 이야기를 다뤄보았다.

Table of Contents

• 지원 동기
• 인턴에서 DevOps로!
• rraft-py 개발
• 오픈소스 컨트리뷰션 아카데미 지역 스프린트 Backend.AI 멘토링
• 다양한 컨퍼런스 참여
• 2023 오픈소스 컨트리뷰션 아카데미
• 파이콘 발표
• 결론

지원 동기

개인적으로 래블업에 입사하기 전부터 취미로든, 업무 시간에서든 내가 개발한 프로그램을 통해 다른 사람들에게 도움을 주는 일을 지속적으로 할 수 있는 직업을 갖고 싶다는 생각을 해 왔다.

특히 오픈 소스는 내가 작성한 코드가 다른 사람들에게 도움을 줄 수 있을 뿐 아니라, 원하는 사람이 있다면 코드를 자유롭게 수정하고 활용할 수 있다는 점에서 더욱 더 매력적으로 느껴졌다.

졸업 프로젝트로 Arvis라는 개인 프로젝트를 진행해보고 나서야 깨달은 사실 중 하나는, 프로젝트 규모가 계속 커지면서 단순히 내가 좋아하는 일이라는 이유로 프로젝트를 지속하는 것이 현실적으로 쉽지 않다는 점이었다. 나름대로 초기부터 프로젝트를 신중하게 계획하고 진행해 보았지만, 결론적으로 프로젝트 유지에 필요한 시간과 노력을 간과한 것 같다는 생각이 들었다.

그런 점에서 오픈 소스 관련 활동들을 적극적으로 권장하고 지원해주며, 심지어 소스 코드의 핵심 부분을 오픈 소스로 개발하는 래블업은 내가 꿈꾸던 회사였다.

인턴에서 DevOps로!

필자의 래블업 OSSCA 인턴십에서 마지막 3주차 동안 했었던 일은 분산 시스템 관련된 공부 및 조사였다. 특히 Raft 알고리즘 구현에 관련된 내용이 대부분이었다. 직무 이름은 인턴에서 DevOps로 변경되었지만 인턴십에서 맡았던 이슈를 해결하기 위해 계속 Raft 등 인턴십 때 공부했던 내용들을 확장한다는 느낌으로 진행하게 되었다.

물론 이외에도 아래에서 언급할 다양한 활동 들에도 참여했지만, 현재까지 회사에서한 작업들 중 가장 주된 작업은 rraft-py 작성 등 기존 분산 락으로 작성되어 있는 구조를 대체하기 위해 Raft 알고리즘 구현체의 파이썬 바인딩을 작성하고, Backend.AI와 어떻게 통합시킬 수 있을지에 대해 고민하는 것이었다.

rraft-py 개발

rraft-py는 tikv/raft-rs의 파이썬 바인딩 구현체로, 이에 대한 자세한 내용은 GitHub Readme / Wiki를 참고하면 된다. 또한 다음 달 2023 파이콘 KR 발표에서 해당 주제의 기술적인 세부사항들을 발표할 예정이므로 관심이 있다면 참고하면 좋을 것 같다.

여기선 rraft-py를 개발하면서 배운 기술적인 내용들은 일단 차치하고 Lablup 개발자로서의 경험에 초점을 맞춰 보려고 한다.

rraft-py는 단순히 Backend.AI의 한 이슈를 해결하는 것 뿐 아니라, 별개의 프로젝트를 만들고 그 프로젝트를 Backend.AI와 통합시키기 위한 프로젝트까지 진행해야 했기 때문에 많은 고민을 하며 진행했다.

전체적으로 프로젝트에 몇 가지 마일 스톤들이 있었는데 매 마일 스톤을 통과할 때 마다 좀 더 안정된 느낌으로 프로젝트를 진행할 수 있었던 것 같다. 분명히 매번 높은 성취감이 있었지만 나중에 가서야 처음 작성했던 코드가 의도한 대로 돌지 않는다는 것을 확인하고 좌절할 때도 많았다. 하지만 래블업에서 이런 삽질들을 할 수 있는 시간을 허용해줬고, 이전에 그냥 "삽질이었네" 하고 치부하고 넘어가면서 배운 것들을 통해 비로소 지금까지 올 수 있었다고 생각한다.

rraft-py 예제 코드 실행 결과

rraft-py를 Backend.AI에 통합하기 위해선 아직도 가야할 길이 더 남아 있지만, 결론적으로 느낀 것은 스스로 생각하고 판단하면서 프로젝트를 계속 고도화 시켜보는 경험을 할 수 있어서 좋았고, 이런 부류의 경험을 좋아하는 개발자들에게 래블업은 최고의 선택지 중 하나가 될 수 있을 것이라는 점이다.

오픈소스 컨트리뷰션 아카데미 지역 스프린트 Backend.AI 멘토링

예상했던 것 보다 많은 시간을 요구했기 때문에 rraft-py 개발을 가장 메인으로 진행했지만, 이것 외에도 다양한 성격의 업무를 진행해 볼 수 있는 기회가 있었다.

그 중 가장 인상 깊었던 업무중 하나가 바로 제 1회 대구 오픈 소스 컨트리뷰션 아카데미 지역 스프린트에 Backend.AI 멘토로 참여해 본 경험이었다.

사실 Backend.AI에 대한 깊은 이해 없이 멘토로 참여하게 되었는데, 설상가상으로 스프린트 기간도 고작 2일 밖에 주어지지 않아 여러모로 많은 걱정을 갖고 참여했었다.

멘티 분들이 하나라도 배우고 최대한 만족하고 돌아 가실 수 있도록 하기 위해 Backend.AI를 전혀 모르는 분들에게 어떤 식으로 설명 해 드릴지, 다른 플랫폼에서 어떻게 개발 환경을 구축해야 하는지 등 (개인적으로 평소엔 macOS + docker desktop 환경에서만 개발했었는데, 멘티 분들은 Windows 환경에서 진행하시는 분도 있으셔서 개발 환경 구축하는 과정에서 삽질 하기도 했다.) 여러 가지들을 생각해보고 준비해보아야 했다.

결론적으로 이런 과정들에 익숙하지 못했던 내가 오히려 더 많은 것들을 배울 수 있었고, 멘티 분들도 생각보다 워낙 잘 따라와 주셔서 다들 한 개 이상씩 PR들을 만드실 수 있었던 뜻 깊은 시간이 된 것 같아 좋았다.

제 1회 대구 오픈 소스 컨트리뷰션 아카데미 지역 스프린트

다양한 컨퍼런스 참여

AI Expo, AWS Summit, Next Rise 등 아래와 같은 다양한 컨퍼런스, 전시회들에 부스로 참여해 볼 수 있었다. 이런 곳들에 참여하면서 Backend.AI를 여러 부류의 사람들에게 설명하는 법을 배울 수 있었던 것도 좋았고, 다른 회사들의 다앙한 기술들을 직접 접할 수 있었던 점도 매력적이었다.

AI EXPO KOREA 2023

2023 오픈소스 컨트리뷰션 아카데미

래블업은 오픈 소스 문화를 지향하는 회사 답게 매년 오픈소스 컨트리뷰션 아카데미에 적극적으로 참여하고 있다. 올해에도 오픈소스 컨트리뷰션 아카데미에 참여했는데, Backend.AI 팀 외에도 다른 다양한 프로젝트들에 참여할 수 있게 장려하고 있어서 필자는 GlueSQL 멘티로 참여해 진행해 보고 있다.

이런 자유로운 문화는 성장하고 싶어 하는 욕구가 강한 개발자들에게 상당히 매력적인 포인트가 될 것이라 생각한다.

(필자 외에도 2023 컨트리뷰션 아카데미 다른 프로젝트들에 두 명이나 더 참여하고 있다.)

파이콘 발표

회사에서의 rraft-py 개발 경험을 토대로 2023 파이콘 KR에서 발표해 볼 수 있는 기회를 얻을 수도 있었다.

개인적으로 대외 발표가 처음이라서 다소 얼떨떨한 느낌이지만 나름대로 최선을 다해 준비해보고 있다. 발표에 관심을 가지는 분들에게 발표 자료 뿐만 아니라 GitHub을 통해 소스 코드나 작업 내역까지 모두 공유할 수 있다는 점이 기대된다.

결론

래블업은 오픈 소스 문화를 지향하는 회사로, 오픈 소스 컨트리뷰션 아카데미나 파이콘 등 다양한 오픈 소스, 커뮤니티 관련 행사들에 참여할 수 있도록 장려하며 개발자에게 주도적으로 작업을 진행해 보게 하는 기회를 제공한다.

래블업에서 앞으로 더 꾸준히 다양한 성격의 오픈 소스 활동들에 참여하고, 배우고 성장하며, 기여해보고 싶다.

역사에서 배우기

최근 반년 사이 급속하게 세간의 화제가 된 ChatGPT를 비롯한 거대 언어 모델들은 사실 어느날 갑자기 하늘에서 뚝 떨어진 것이 아닙니다. 차곡차곡 누적된 기술의 발전이 어떤 변곡점에 도달하면서 급속하게 사회를 변화시키는 것은 역사적으로 많이 봐왔던 일이죠. 전혀 다른 시대와 다른 맥락에서 발전한 기술들이 그러한 변곡점에 도달하는 과정은 때로는 놀랍도록 유사한 모습을 보여주기도 합니다.

---

인류는 오랫동안 하늘을 날고 싶어했습니다. 문명 6이 "하늘을 나는 꿈"을 주제가로 삼은 것은 우연이 아닙니다.

라이트 형제는 어떻게 이 꿈을 이루게 되었을까요? 1899년 윌버 라이트는 스미스소니언 재단에 편지를 보내 비행기에 대해 알려진 내용을 보내달라고 요청합니다. 세 달간 전달받은 자료를 검토한 윌버는 비행이라는 문제가 있을 뿐이지 비행에 대해 알려진 것은 별로 없다는 결론을 내립니다. 그럴싸한 이론이 거짓으로 밝혀지고 그럴 법하지 않은 이론이 참으로 밝혀졌기 때문에, 직접 확인하지 않은 내용은 믿을 수 없다고 그는 적었습니다.

문헌 조사에서 윌버가 알고자 한 것은 이러한 것이었습니다. 하늘을 날기 위해서는 무엇을 알아야 하는가? 그 중 무엇이 이미 알려져 있는가? 풀어야할 남은 문제는 무엇인가? 놀랍게도 윌버는 문헌 조사로부터 이 모든 질문에 대한 답을 내릴 수 있었는데, 그것은 다른 경쟁자들은 하지 못한 일이었습니다.

윌버는 1901년의 강연에서 자신의 결론을 이렇게 정리했습니다. "비행에는 세 가지 문제가 있습니다. 비행기가 뜨기 위해 날개가 필요하고, 비행기가 나아가기 위해 엔진이 필요하며, 비행기를 조종할 방법이 필요합니다."[^1]

[^1]: Some Aeronautical Experiments (Wilbur Wright, 1901).

윌버는 날개의 문제와 엔진의 문제는 어느정도 이미 해결되었기 때문에, 조종의 문제를 풀어야 한다고 보았습니다. 비행기 조종의 문제를 풀기 위해서는 비행기가 필요했는데, 비행기를 만들기 위해서는 비행기 조종의 문제를 풀어야 하는 상황이었습니다. 윌버는 글라이더에서 조종의 문제를 품으로써 비행기 조종의 문제를 풀 수 있다는 결론을 내렸습니다.

글라이더 실험을 위해서는 높은 언덕과 강한 바람이 필요했으며, 실험자의 안전을 위해 모래 언덕이어야 했습니다. 1900년 윌버는 기상청에 자료를 요청해 미국에서 가장 바람이 센 곳들을 검토했습니다. 키티 호크 기상대의 직원은 기상대 옆 해변에 장애물이 없으며 실험에 적합할 것이라는 답장을 보내왔습니다.[^2]

[^2]: Letter from J. J. Dosher, Weather Bureau, to Wilbur Wright, August 16, 1900.

1901년의 실험은 실망스러웠습니다. 날개의 양력이 충분하지 않았던 것입니다. 라이트 형제는 날개의 면적을 계산하기 위해 오토 릴리엔탈의 데이터를 사용했는데, 그 정확도에 의심을 가지게 되었습니다.

실험 데이터를 분석한 결과, 그들은 오토 릴리엔탈을 포함하여 100년 넘게 의심 없이 사용되어 왔던 존 스미턴의 비례 상수 값이 잘못되었다는 결론을 내렸습니다.

많은 시간과 노력이 소모되는 글라이더 실험을 하지 않고 날개의 양력을 체계적으로 분석하기 위해, 라이트 형제는 풍동 실험 장치를 만들었습니다. 분석 결과, 오토 릴리엔탈의 데이터는 잘못된 비례 상수 값을 제외하면 정확했지만, 오토 릴리엔탈이 사용한 날개는 비효율적이었습니다.

이러한 분석을 바탕으로 만들어진 1902년의 글라이더는 수정된 스미턴 상수의 값을 상쇄하기 위해 면적이 더 넓어졌으며 효율을 높이기 위해 모양이 더 평평해졌습니다. (날개의 편평도를 1/12에서 1/24로 바꾸었습니다.) 새 글라이더는 아주 잘 날았습니다.

이리하여 라이트 형제는 1903년 키티 호크에서 역사적인 첫 비행을 성공시킬 수 있었던 것입니다.

---

인류는 오랫동안 기계와 대화하고 싶어했습니다. 수많은 과학 소설과 영화들이 증거하고 있습니다.

OpenAI는 AI를 만들기 위해 세 가지 문제를 풀어야 했습니다. 컴퓨팅 인프라와 모델과 데이터입니다. 컴퓨팅 인프라가 엔진에, 모델이 날개에, 데이터가 조종에 대응한다고 볼 수 있습니다.

컴퓨팅 인프라를 관리하기 위해 OpenAI는 Kubernetes를 사용했는데, 그렇다고 그냥 가져다 쓸 수 있는 것은 아니었습니다. 2,500 노드가 되자 리눅스 커널 ARP 캐시가 넘치는 문제가 생겼고,[^3] 7,500 노드가 되자 anti-affinity를 사용하기 위해 Kubernetes의 버그를 고쳐야 했습니다.[^4]

[^3]: Scaling Kubernetes to 2,500 nodes, January 18, 2018.

[^4]: Scaling Kubernetes to 7,500 nodes, January 25, 2021.

(광고: 래블업의 Backend.AI는 AI의 훈련과 추론을 위한 대규모 클러스터들에 이미 실제로 사용되어 여러가지 스케일링 문제들을 풀었고, 자체 스케줄링 알고리즘을 구현하여 affinity나 anti-affinity 등의 기능을 지원하고 있습니다.)

비행기의 양력 방정식에 해당하는 것이 AI의 scaling law입니다. 양력 방정식이 날개의 양력을 날개의 면적과 양력 계수, 비례 상수로 설명하는 것처럼, scaling law는 AI 모델의 loss를 모델의 크기와 데이터의 크기, 멱함수 지수로 설명합니다.

라이트 형제가 존 스미턴의 비례 상수가 0.005가 아니라 0.003이라는 것을 발견한 것처럼, scaling law의 멱함수 지수는 처음에는 0.73인 것으로 생각되었지만[^5] 실제로는 0.50인 것으로 밝혀졌습니다.[^6] 잘못된 값이 계산된 것은 데이터의 크기에 따라 learning rate를 조정하지 않았기 때문입니다.

[^5]: Scaling Laws for Neural Language Models, January 23, 2020.

[^6]: Training Compute-Optimal Large Language Models, March 29, 2022.

OpenAI는 모델의 제어가 중요한 문제라는 것을 알고 있었기 때문에, 첫 번째 GPT를 훈련하기 전에 이미 사람의 선호로부터 강화 학습을 하는 연구를 진행하고 있었습니다.[^7] 이때는 로봇의 제어에 적용했는데, 라이트 형제가 비행기의 조종을 위해 새의 비행을 참고하고 비행기 대신 글라이더에 먼저 적용한 것을 연상시킵니다.

[^7]: Deep reinforcement learning from human preferences, June 12, 2017.

이러한 연구를 언어 모델에 적용하기 위해 사람의 선호 데이터를 수집하여 InstructGPT가 나왔습니다.[^8] GPT-4 이후로 OpenAI가 연구 내용을 공개하고 있지 않기 때문에 정확히 알기는 어렵지만, 명시적인 피드백이 아니라 사용자가 생성을 재시도하거나 대화를 계속하고 중단하는 등의 암시적인 피드백으로부터도 학습할 수 있다는 연구 결과들이 나오고 있습니다.[^9] 그렇다면 OpenAI는 모델을 향상시켜 사용자를 모으고 사용자를 모아 모델을 향상시키는 양성 되먹임 고리를 만들어낼 수 있을 것입니다.

[^8]: Training language models to follow instructions with human feedback, March 4, 2022.

[^9]: Rewarding Chatbots for Real-World Engagement with Millions of Users, March 10, 2023.

---

이번 글에서는 인류가 하늘을 날게 된 과정과 기계와 대화하게 된 과정을 비교하여 살펴보았습니다. 기술 발전 과정을 보면 이렇게 역사적으로 매우 유사한 패턴들을 볼 수 있지요.

앞으로 AI 기술이 발전하고, 이를 보다 많은 사람들이 사용할 수 있게 하는 노력 속에서 또 어떤 사례들이 나올까요? 래블업과 Backend.AI는 그러한 과정을 더욱 가속화하여 사람들이 역사로부터 배운 것을 보다 빨리 실험하고 실현할 수 있게 도울 수 있을까요? 이러한 변곡점의 한 가운데에서 생각에 잠겨봅니다.

본 포스트의 내용은 필자의 개인적인 경험을 바탕으로 작성되었습니다. 여기서 언급된 내용이 모든 경우에 해당되는 것이 아니며 다양한 의견이 있을 수 있습니다.

What is DevRel?

Image by Henning Westerkamp from Pixabay

DevRel 은 이름에서 유추할 수 있듯이 Developer 들과 Relation (관계) 를 만들어 나가는 것이 가장 큰 목적입니다. 여기서 Developer 는 코드를 짜는 개발자 뿐 아니라 기획자, 디자이너 등 서비스와 제품을 만드는데 참여하는 모든 생산들을 포함합니다. 세부적인 DevRel 의 역할은 조직과 산업의 성격에 따라서 많은 차이가 있는데 보통은 그 목적이 (제품,기술) 홍보 또는 채용 으로 수렴하는 경우가 많습니다.

DevRel의 주요 역할은 다음과 같은 것 들이 있습니다.

• 제품 홍보 및 기술 전파
• 커뮤니티 설립, 운영, 지원
• 사용자의 의견 수렴하고 제품 개발에 피드백
• 사용자들이 제품을 더 잘 사용할 수 있도록 다양한 리소스 제공

Developer Advocate 은 DevRel 안에서도 기술 전파 및 리소스 제공 에 조금 더 초점을 맞추고 있는 역할이라고 볼 수 있습니다.

Why DevRel?

기업에서는 자사의 제품과 서비스를 대중에게 알리기 위해 다양한 채널과 이벤트 등을 통한 마케팅/홍보 활동을 합니다. 이런 활동들을 PR - Public Relations 이라고 하며, 말 그대로 대중들과 관계를 만들어 나가는 행위 라고 볼 수 있습니다. IT 제품을 개발하거나 서비스 하는 기업에서는 주 소비자가 엔지니어(Developer)들 입니다. 그리고 엔지니어들을 대상으로 하는 제품들은 더욱 세부적이고 기술적인 정보들을 제공해야 하는 경우가 많아 일반적인 PR 활동과는 다른 자원과 전략들이 필요합니다. 말 그대로 DR - Developer Relation 입니다.

IT 생태계를 유지하는 가장 중요한 원동력은 커뮤니티라고 할 수 있습니다. 특히 Backend.AI 와 같은 오픈소스 제품들은 커뮤니티의 역할이 더욱 중요합니다. 심지어 비슷한 종류의 새 기술들이 나왔을 때 성능이나 완성도 외에도 커뮤니티의 규모가 그 기술을 선택하여 도입하는 요인이 되는 경우도 많습니다. DevRel 의 중요한 역할 중 하나는 이러한 커뮤니티를 돕고 소통하는 것입니다.

저는 커뮤니티의 중요성을 설명할 수 있는 좋은 비유로 아티스트와 팬클럽의 관계로 이야기하곤 합니다. 아티스트의 주요 역할은 음악을 만들고 공연을 하는 것입니다. 하지만 팬클럽을 통해서 바이럴과 2차 창작물들이 탄생하기도 하며 이것은 아티스트들의 활동 그리고 엔터테인먼트 사업에 있어 중요한 원동력이 되기도 합니다. 요즘은 이런 팬덤의 중요성을 연예 기획사들도 잘 알고 있기에 다양한 활동들을 지원하곤 합니다.

Image created by Midjourney

마찬가지로 IT 조직의 DevRel 은 다양한 커뮤니티들을 지원하고 소통하며 제품과 조직이 관심에서 멀어지지 않도록 하는 것이 중요한 역할이라 할 수 있겠습니다.

Developer Advocate in Lablup

래블업에는 대한민국 개발자 커뮤니티를 위해 오랜 기간 활약하고 계신 유우영님께서 함께하고 계시고, 대표이신 신정규님도 다양한 개발자 커뮤니티에서 활동하고 계시기 때문에 이미 조직 규모에 비해 많은 DevRel 활동들을 해 오고 있습니다. Backend.AI 는 훌륭한 소프트웨어이고 특히 요즘과 같은 대AI 시대 (라고 표현하는게 적절한) 에 중요하게 쓰임받을 수 있는 도구입니다. 하지만 AI 학습 및 추론을 위한 도구인 만큼 설치를 위해 많은 준비와 리소스들을 필요로 하며 특히 AI의 급부상 때문에 AI 처음 시작하는 분들께는 (사실 저도 그렇습니다😅) 허들이 높은 것도 사실입니다.

아직 Backend.AI 만의 사용자 규모가 크지 않아, 래블업에서는 오픈소스 문화 라는 주제와 엮어 그 동안 오픈소스 컨트리뷰션 아카데미와 같은 다양한 커뮤니티 활동들을 해 왔습니다. 자체 커뮤니티가 성장하기 위해서는 제작자들로부터 사용자들에게 일방적으로 기술 전파가 이루어 지는 것 외에도 사용자들 끼리의 정보가 생산되고 전파되어야 합니다. 그런 활동들이 활발히 일어날 수 있도록 누구나 쉽게 활용 가능한 다양한 리소스들와 교류 기회를 계속해서 만들고 개선 해 나가는 것이 앞으로 제가 해야 할 주요 과제입니다. 앞으로도 다양한 기회와 방법으로 여러분들과 소통할 수 있도록 계속 노력하겠습니다.

서론

내가 처음 이 회사를 알게 된 건 2019년 여름이었다. 당시 GDG Seoul '모두의 Toy Story'라는 행사에서 지인이 발표를 한다고 해서 행사를 참관했는데, 그 자리에서 래블업의 '머신러닝에 활용하는 GPU 가상화 도구'를 주제로 한 세션을 듣고 굉장한 흥미를 느꼈다. 이 때는 내가 한창 머신러닝에 관심을 가지던 시기였는데, 래블업의 발표는 기술적으로 깊이가 있었고, 이런 일을 하는 회사도 있구나 하며 이 회사에 대해 처음으로 알게 되었다.

그 후, 다시 한번 이 회사와 연이 닿게 되었는데, 42 Seoul에서 진행한 오픈소스 해커톤에서였다. 특정 오픈소스를 활용한 제품을 단기간에 만드는 대회였는데, 이때 나는 Backend.AI 팀에 참여하게 되었다. 이 때는 앞서 언급한 GDG Seoul에서의 발표 이후 3년이 지난 시점이었지만, 그 때의 발표가 매우 인상깊었기 때문에 이름을 보자마자 곧바로 회사를 떠올릴 수 있었다. 대회를 진행하는 동안 정규님의 멘토링을 통해 많은 도움을 받았고, 덕분에 대회에서 2위를 수상하는 쾌거를 이루었다.

2022년 5월, 나는 쎄트랙아이라는 회사에서 학교 연계 인턴십을 진행하고 있었다. 인턴십 종료 이후 어떤 일을 해야 할까 알아보던 중, 페이스북에서 래블업의 여름 인턴십 공고를 보게 되었다. 대회를 진행하며 정규님에게 받은 멘토링이 큰 도움이 되었기에 좋은 기억이 있었고, 개발자 커뮤니티와 오픈소스에도 지대한 관심을 가지고 있었기에 나의 다음 목적지를 래블업으로 정하게 되었다.

그 무렵, 나는 42 world라는 프로젝트를 진행하고 있었는데, 이 시기가 내가 많은 것들을 배우고 성장할 수 있었던 시기라고 생각한다. 래블업의 면접을 보며 내가 진행하던 42 world 프로젝트를 소상히 설명할 기회가 있었고, 프로젝트에 모노레포를 적용하며 어려웠던 경험을 나누자 래블업도 Backend.AI에 모노레포를 적용하며 어려움을 겪었다는 이야기를 해주어 면접 동안 개발자끼리의 소소한 공감을 주고받을 수 있었다.

그렇게 래블업 인턴십에 합격한 후, 총 4분의 다른 인턴분들과 인턴십 생활을 시작하게 되었다. 나는 기존의 인턴십을 마무리하고 이사할 기간을 가지기 위해 다른 분들보다 일주일 정도 늦게 회사에 입사하게 된 케이스다. 일주일 동안은 Backend.AI를 파악하고 회사에 적응하는 Orientation 주간을 가졌다. 온보딩 문서화가 잘 되어있어 신규 입사자가 쉽게 회사에 적응하기 좋은 환경이 갖추어져 있는 회사라는 생각이 들었다. Orientation 기간 대부분은 Backend.AI를 설치하고 세팅하는데 대부분의 시간을 보낸 것 같다. 나는 다른 인턴분들보다 일주일 정도 늦게 입사한 덕분에 다른 인턴분들에게 도움을 많이 받았고, 상대적으로 수월하게 Orientation 기간을 마무리할 수 있었다.

업무 시작

2주 차부터 이제 본격적인 task 들을 할당받아 일하기 시작했다. DevOps, Frontend, Research 팀 중에 본인이 하고 싶은 일을 선택하여 각 챕터 담당자분에게 good-first-issue를 할당받아 시작하였는데, 나는 DevOps 팀을 선택하여 업무를 시작했다. 처음으로 할당받은 이슈는 세션을 실행하고 원하는 코드를 실행하기까지 하는 run 커맨드를 세션을 실행하는 start와 코드를 실행하는 exec 명령어를 조합하여 구현하도록 하여 코드의 중복 구현을 줄이도록 refactoring 하는 작업이었다.

나에게 할당된 첫 이슈를 진행하며 꽤나 어려움을 겪었는데, 해당 이슈의 구현 난이도와는 상관 없이 Backend.AI의 레포 구조를 이해해야 했기 때문이다. 이슈가 왜 생겼는지 파악하는 것도 중요하지만, 그 전에 Backend.AI가 목표로 하는 것이 무엇인지 정확하게 알고, 이 이슈가 어떤 목적을 달성하기 위해 해결되어야 하는 것인지 이해해야 문제를 정확하게 해결할 수 있다는 사실을 알게 되었다.

첫 번째 이슈를 해결하고 난 후에는 vfolder clone이라는, 당시 개발 중인 기능을 테스트하는 업무를 맡게 되었다. 해당 업무를 하면서 DevOps 업무만을 담당하다가 Frontend 챕터의 프로젝트인 Backend.ai-webui를 처음으로 사용해보게 되었다. vfolder clone 테스트뿐만 아니라 직접 실행하면서 개선할 수 있는 사항이나 버그들을 찾아서 이슈로 등록했는데, 뭔가 다른 팀에 계속 task를 만드는 느낌이라 좀 죄송한 마음도 들었지만, 프론트엔드 챕터에서는 굉장히 좋은 기여라고 독려해 주셨다. 오픈소스는 코드 기여 뿐만 아니라 다른 방면으로도 많이 기여를 할 수 있음을 다시 한번 깨닫게 되었다.

CI/CD 개선

평소 CI/CD에 관심이 많았던 나는 Backend.AI에서 활용되는 actions에 흥미를 갖고 관심깊게 살펴보았다. 당시 Backend.AI에는 skip:ci 태그를 이용하여 CI를 skip 할 수 있는 기능이 있었는데, skip:ci나 skip:changlog 태그가 PR 생성 당시가 아닌, 나중에 라벨을 다는 경우에는 적용되지 않는다는 것을 알게 되었다. 이를 위해 의미 없는 commit을 추가해야 했고, 외부 기여자의 경우 label에 대한 권한이 없기 때문에 Backend.AI가 오픈소스인 만큼 중요하게 해결되어야 하는 문제라고 생각했다. 그래서 GitHub Actions와 관련된 내용을 조사했고, action trigger에 labeled와 관련된 trigger가 있다는 것을 알게 되어 해당 문제를 해결할 수 있었다. 할당받은 이슈가 아닌 직접 개선할 수 있는 사항을 찾고 개선한 것이라 해당 작업을 회사에서도 매우 좋게 봐주셨다. 해당 문제를 해결하면서 actions에 더 흥미가 생겨 몇 가지 개선사항을 좀 더 제시해보았다. 누락된 assign 들이 꽤 보여 이를 자동화하여 해결하면 실수도 방지하고 assign 하는 귀찮음도 줄일 수 있다고 생각해 기존에 사용해 본 적이 있는 auto-auth-assign action 도입을 제안했다. 그다음으로는 labeling도 자동화를 하면 좋을 것 같았다. 해당 문제도 labeler라는 action이 존재하여 사용해 본 적은 없지만, test repository에서 여러 번 테스트를 거쳐 Backend.AI에 적용했고 모노레포로 합쳐진 여러 시스템을 구분하는 labeling 작업을 자동화할 수 있었다. 이 작업을 하면서 느낀 것은 PR에 연결된 issue에 할당되어있는 label을 그대로 붙여주면 좋을 것 같다는 생각이 들었는데, 해당 기능을 하는 action을 찾을 수가 없었다. 그래서 직접 제작해보기로 결심했고, GitHub API와 action을 학습, auto-label-in-issue라는 actions를 직접 제작하여 배포했다.

인턴십을 마치며

이번 인턴십을 통해 많은 것을 느끼고 많은 것을 배워간다. 이번 인턴십이 두 번째 경험이긴 하지만, 이전 회사는 IT 회사가 아니었던 만큼 IT 회사에서의 첫 인턴십 경험이었다. 나에게 래블업의 제품은 오픈소스로 관리되고, 회사 차원에서 커뮤니티에 꾸준히 기여한다는 점이 매력적으로 다가왔다. 회사가 정말 이렇게까지 수평적일 수 있나? 라는 생각이 들 정도로 편안한 분위기에서 자유롭게 의견을 제시할 수 있었다. 강제로 일을 하는 것이 아닌 주도적으로 하고 싶은 일을 할 수 있는 것이 래블업의 가장 큰 장점이라고 생각한다.

이제야 프로젝트에 대해 어느정도 파악 한 느낌인데 인턴십을 종료할 때가 다가와 아쉬움이 컸다. 감사하게도 래블업에서 인턴십을 연장해보지 않겠냐고 먼저 제안을 주셔서 인턴십을 연장, actions 이슈들을 주로 맡아 개발하게 되었다. 최근에 내가 계속 actions를 다루고 있고, 필드에 actions를 다루는 개발자가 많이 없기 때문에 이를 주제로 GDG Daejeon에서 발표도 하게 되었다. 덕분에 주변에서 액션가면이라는 별명으로 불리고 있는 것은 소소한 웃음거리다.

이후 인턴십에서의 경험을 오픈소스 컨트리뷰션 아카데미에서 나누기도 하고, 이를 바탕으로 컨트리뷰션 아카데미에서 좋은 성적을 거두게 되었는데, 회사에서의 경험이 이를 위한 밑바탕이 되었다고 생각한다.