Make headway towards solving the problem

주니어 엔지니어 때 알았더라면 좋았을 것들 (2)

가마뫼 — Sun, 30 Mar 2025 20:13:53 +0900

1편에 이어서 2편에서도 내가 주니어 엔지니어 때 알았더라면 좋았을 것들에 대해서 정리해 본다. 마찬가지로 이는 나의 주관적인 의견이며 누군가에게는 잘 맞지 않는 내용일 수도 있다. 모든 내용을 비판 없이 받아들이기보다는 본인 상황과 환경에 맞게 적절히 취사선택한다면 더할 나위 없을 것이다.

1. 독서

조금은 뜬금없는 주제일지도 모르겠다. 2025년 기준으로 ChatGPT를 위시한 생성형 인공지능 시스템들이 즐비하며, 우리가 원하는 정보는 인터넷에서 쉽게 찾을 수 있으니 말이다. 역설적이지만 그러므로 독서의 중요성은 더 올라간다고 생각한다. 그래서 누군가가 나에게 독서가 중요하냐고 물어보면 짧은 답은 '그렇다'이다. 이때 독서의 부류는 기술 서적과 일반적인 서적 모두를 포괄한다. 하지만 이렇게 얘기하는 것은 다소간의 반발이 있을 수 있으니, 그에 대한 긴 답을 내 나름대로 정리하자면 다음과 같다.

블로그에 파편화 되어있는 내용은 최종적인 지식 구조화에 나쁜 영향을 줄 가능성이 있다
책으로 출간된 내용은 기본적으로 출판사와 베타 리더 등 여러 검수를 거치므로 최소한의 검증이 된다
짧은 글에 자꾸 익숙해지면 긴 글을 읽고 쓰는 데 어려움을 겪을 수밖에 없다

아마도 신문이나 유튜브 등을 통해 문해력에 관한 얘기를 들어본 사람이 있을 것이다. 좋은 책을 읽고 그것에 대해서 생각을 재정리하며 해석해 보는 연습은 누가 뭐래도 좋은 엔지니어가 되기 위한 기본적인 조건이라고 생각한다. 독서가 중요한 것 알겠는데 일하느라 바쁜데 시간 내기가 어렵다는 사람도 있을 것 같다. 내 기준 하루 30분 정도 독서를 꼭 하려는 편인데, 30분 기준으로는 20~40페이지(배경지식에 따라 편차는 조금 있음)를 읽을 수 있다. 300페이지 분량의 책은 단순히 계산했을 때 10일이면 한 권을 본다는 얘기다. 하루 30분 시간 내는 것이 정말 어려운가는 본인이 아마 가장 잘 알 것이다. 추가로 어떤 책을 읽으면 좋겠냐고 물어보는 사람이 있을 것 같아서 나름의 추천 도서를 남겨놓는다

기술 서적

너무 좋은 책들이 많이 있지만 아래 2권은 꼭 읽어봤으면 하는 책이라 추천해 본다.

실용주의 프로그래머
코드 컴플리트 2

교양 서적

꼭 자기계발서 같이 성장을 위한 책이 아니라, 재미를 위한 소설도 좋다. 실제로 나 역시 독서의 즐거움을 알게 된 계기는 SF소설을 읽기 시작하면서였고, 업무와 직접적인 연관은 없더라도 개인의 정서적 건강에도 도움이 되었다고 생각한다. 어디서부터 시작해야 할지 막막하다면 아래 책 또는 이전에 작성한 포스팅의 문화체육관광부 추천 도서부터 시작하면 좋을 것이다.

닥치는 대로 끌리는 대로 오직 재미있게 이동진 독서법 (책 후반부에 이동진의 추천도서 800권이 있다)
문화체육관광부 추천 도서 (성인과 유아/청소년)

2. 조언은 누구에게 받을 수 있을까요?

제발 전문가에게 물어보길 바란다. 당신의 인생 진로에 어쩌면 큰 나비효과를 일으킬 수 있는 조언을 아무에게나 받아서는 되겠는가? 직접적으로 얘기하면 디시인사이드와 같은 커뮤니티나 카카오 오픈 채팅과 같이 진입 장벽이 낮은 곳에서는 정말 운이 좋지 않은 한 당신이 원하는 조언을 받을 가능성이 거의 없다고 봐도 된다. 특히 대학생들은 경험이 많지 않다 보니 속된 말로 커뮤니티의 글이 사실인지 아닌지 구분하는 것조차 힘들어서, 확실한 이유가 없다면 애초에 본인 진로를 위해서 저런 커뮤니티는 거리를 두는 것이 좋다고 본다. 그러면 어디서 조언을 얻을 수 있을까요에 대한 답을 해야 할 것 같은데 내가 생각하는 이상적인 경로는 다음과 같다.

만약, 대학원 진학이나 연구 쪽에 관심이 있다면 지도 교수님 혹은 본인이 관심 있는 분야의 교수님을 활용하자. 다만 워낙 바쁜 분들이니 무턱대고 찾아가거나 하는 것은 결례이므로 이메일을 활용하여 질문을 정리하여 보내거나, 일정을 잡아 직접 찾아뵙고 궁금한 것들을 해결하면 좋겠다. 실제 회사의 업무나 특정 회사에 대해서 궁금하다면 LinkedIn을 활용해 보자. 예를 들어 내가 Coupang의 backend engineer에 대해서 궁금하다면 아래와 같이 검색해 볼 수 있겠다.

아마 현재 Coupang에 재직 중이거나 이전에 재직했던 엔지니어들을 볼 수 있을 것이다. 리스트 중 운이 좋다면 본인과 학연 또는 지연이 있는 사람이 있을 수도 있을 것이고, 대부분은 많은 선배 소프트웨어 엔지니어들은 도움을 주고 싶어 한다. 궁금한 내용이 있다면 현재 재직 중인 사람에게 물어보는 것이 가장 정확할 것이다. 다만 대외비나 민감한 내용에 대해서는 거절할 수 있으며, 그것에 대해서도 너무 마음 상하지 말기를 바란다. 마지막으로 인프런의 멘토링과 같은 서비스도 필요하다면 활용해 볼 수 있겠다.

3. 근로 소득 외의 자산 관리

앞으로는 근로 소득 외에 개인 재무 관리가 점점 더 중요해질 것으로 생각한다. 단순히 주식하고 말고가 중요한 것이 아니라 경제 용어나 시장의 변화 등에 우리의 신경을 집중해야 한다는 얘기다. 우리 삶에 영향을 직접 주는 중요한 내용임에도 불구하고 정규 교육과정 등 제대로 가르치는 곳이 없다는 것이 안타깝다. 다음 링크를 봤을 때 이는 한국만 그런 것이 아니라 외국의 소프트웨어 엔지니어들도 비슷한 상황이라 스탠퍼드에서 엔지니어를 위한 재무 강의를 따로 만들었을 정도라고 하니 말을 다 한 것이 아닐까. 찾아보면 좋은 자료들이 생각보다 많이 있다. 앞에서 얘기한 기술 공부, 영어, 독서보다 어쩌면 더 중요한 내용일지도 모르니 꼭 읽어보고 빠르게 자산 관리를 시작해 보자. 개인적으로 빠르면 빠를수록 좋다고 생각한다.

스탠포드 엔지니어를 위한 재무 강의 ( https://news.hada.io/topic?id=9431 )
금융감독원 / 생애주기별 금융생활 가이드북 1권 ( https://www.fss.or.kr/edu/fec/contMng/view.do?menuNo=300018&contentsSlno=138&check=2 )
금융감독원 / 대학생을 위한 실용금융 4판 ( https://www.fss.or.kr/edu/fec/contMng/view.do?menuNo=300018&check=2&contentsSlno=688&pageIndex=&search=&searchWrd=&certYn=&order=regDt )
토스 / THE MONEY BOOK ( https://www.yes24.com/product/goods/132290741 )\

4. 최신 기술 트렌드 따라잡기

우선 리서치와 같은 연구는 기본적으로 Google Scholar를 활용한다. 아예 백그라운드가 없는 상태라면 서베이 논문 혹은 리뷰 논문을 통해 시작하면 좋은데, 다음과 같은 템플릿을 활용해 볼 수 있겠다.

<Topic> survey paper
<Topic> review paper

아래 그림은 deep learning quantization review paper에 대한 검색어 결과이다. 출간 년도와 인용 수를 적절히 필터링하면 좋은 리뷰 페이퍼를 찾을 수 있을 것이고, 리뷰 페이퍼에서 세부적인 페이퍼에 대한 인용이 있으므로 더 자세한 내용을 해당 논문을 참조해나가면서 관심 분야의 트렌드를 따라갈 수 있을 것이다.

Quantization review paper

엔지니어링의 경우도 운이 좋다면 관심 분야의 리뷰 페이퍼를 찾을 수 있으나, 보통은 기술 블로그를 통해서 최신 트렌드를 따라가는 편이다. 본인이 E-commerce 도메인에 있다면 Amazon의 테크블로그를, 또는 소셜 미디어 도메인이라면 LinkedIn과 같은 유사한 기업의 테크 블로그를 잘 살펴보면 좋은 아이디어를 얻을 수 있을 것이다. 그 외 한국의 여러 빅테크들도 테크 블로그를 대체로 운영하고 있으니 RSS와 같은 서비스를 활용하거나 테크 블로그를 큐레이션하는 다음과 같은 서비스 ( https://www.velopers.kr/ )도 활용해보면 좋을 것이다.

비정상 액션을 감지하기 위한 LinkedIn 테크 블로그

마치며

주니어 엔지니어 때 알았다면 좋았을 것들이라는 주제를 빌미로 여러 잔소리를 늘어놓은 것 같아 누군가에게는 듣기 싫은 내용이었을지도 모르겠다. 그렇지만 후배 엔지니어들은 가능하면 내가 했었던 시행착오를 안 하고 올바른 방향으로 갔으면 하는 마음에서 잔소리라고 생각해 주면 고맙겠다. 이 외에도 본인만의 좋은 팁이 있다면 댓글로 남겨주길 바란다.

주니어 엔지니어 때 알았더라면 좋았을 것들 (1)

가마뫼 — Sun, 16 Mar 2025 20:26:17 +0900

대학원 석사 과정 2년이 나에게는 정말로 쉽지 않은 시간이었는데, 오히려 졸업하고 나서야 대학원생 때 알았더라면 좋았을 것들이라는 책을 보게 되었고 이걸 진작 알았더라면 하는 생각이 많이 들었었다. 소프트웨어 엔지니어로서 8년 가까이 일을 한 이제는 모든 것이 적절한 때가 있다는 얘기가 많이 공감된다. 최근에 글또 내에서 주니어 엔지니어분들과 커피챗을 할 기회가 있었는데 그들의 고민하는 부분과 이전에 모 대학교 특강에서 자주 묻는 말들로 정리한 것들이 꽤 많이 겹치는 것이 있어 이번 기회에 내가 생각하는 주니어 엔지니어 때 알았더라면 좋았을 것들을 정리해 본다. 시작하기에 앞서 글 작성자는 컴퓨터 공학을 전공했고 머신러닝 관련 석사를 했으며, 운이 좋게도 경력 시작부터 좋은 조직들을 거쳐왔기 때문에 모든 사람이 공감할 수 있는 내용이 아닐 수 있다는 점을 미리 밝힌다. 비록 시작점은 다르더라도 글 내용 중 일부를 본인 상황에 맞게 잘 취사선택하여 어제보다 나은 내가 될 수 있으면 충분하다고 생각한다.

1. Software Engineer에게 가장 중요한 스킬셋

내가 생각하는 가장 중요한 기술 셋은 전산학 관련 전공 지식, 영어, 그리고 체력이라고 생각한다. 각각에 대해서 아래에서 조금 더 자세히 설명을 해본다.

1.1. 전산학 지식

직군 (Front-end engineer, Back-end engineer, Data engineer 등)에 따라 조금씩 중요도의 차이는 있겠지만, 좋은 엔지니어가 되기 위한 기반은 결국 튼튼한 전산학 전공 지식이라고 생각한다. 소프트웨어 엔지니어는 결국 문제를 해결하는 사람들이고 그 문제를 적절히 풀기 위해서는 시간/공간 복잡도를 고려해야하며, 우리가 실행하는 애플리케이션이 어떤 형태로 스케줄링되는지 그리고 데이터는 어떻게 효율적으로 관리할 지를 매일같이 고민한다. 이전 문장에서 서술한 내용을 대표하는 전산학 전공 과목들이 데이터 구조와 알고리즘, 운영체제/컴퓨터 구조, 데이터베이스와 같은 것들이라고 할 수 있겠다. 토이 프로젝트나 간단한 프로그램에서는 어떻게든 돌아가게 만드는 것이 큰 문제가 되지 않지만, 대규모 트래픽을 다루는 서비스나 로우레벨 소프트웨어 구현 시 이런 튼튼한 백그라운드는 Problem Solver로서 자신의 가치를 더 빛나게 해줄 수 있다.

전산학 지식이 중요하다는 말은 아마 이 글이 아니더라도 주위에서 꽤 들어봤을 것이고, 그래서 어떻게 전공 지식을 공부하고 쌓아나가면 좋을지에 대한 답변을 해주는 것이 좋을 것 같다. 만약 이 글을 보는 독자가 대학생이라면 당신은 행운아다. 전공자라면 대체로 졸업을 위해서 필수로 지정된 전공과목이 있을 것이니 해당 수업을 열심히 따라가면 될 것이다. 전공자가 아니라면 복수전공이나 부전공을 하면 좋겠으나, 여의치 않다면 수강이라도 하는 것 (학교마다 명칭은 다를 것 같은데 보통 선택과목 정도로 표현하는 것 같다)을 추천한다. 요즘 같은 정보화 시대에 유튜브나 인터넷에 찾아보면 공개된 강의도 많은데 꼭 수업을 들으라고 하는지 의아한 사람도 있을 것이다. 나는 개인적으로 어렵게 공부해야 그것이 정말 머리에 남는다고 생각한다. 따라서 수업을 듣고 과제를 직접 풀거나 프로그램하고 시험을 볼 수 있는 약간은 고전적 형태인 수업을 직접 듣는 것을 이런 이유로 추천한다.

만약 이미 졸업했다면 어떻게 하면 좋을까? 이때는 어쩔 수 없지만 외부에 공개된 강의나 아니면 사놓고 책장에 꽂아둔 (...) 전공책들을 보는 등의 방법을 활용해야 할 것 같다. 아래는 내가 추천하는 몇 가지 자료들이나, 아마도 내가 모르는 좋은 책이나 강의가 많이 있을 것이니 검색을 통해서 찾아보고 비교해 보면 좋겠다.

모두를 위한 컴퓨터과학 (CS50)
- https://www.boostcourse.org/cs112
- https://cs50.harvard.edu/x/2025/
CSAPP: Computer Systems: A Programmer's Perspective
The Missing Semester
Deeplearning.ai
- Mathematics for Machine Learning and Data Science
- Data Engineering
- Machine Learning / Deep Learning Specialization

1.2. 영어

구글 번역기나 ChatGPT를 위시한 생성형 AI들이 이제는 너무나 잘 번역해 주고 있는데, 영어가 중요하다고 얘기하니 고개를 갸우뚱하는 사람도 분명히 있을 것 같다. 그런데도 나는 전공만큼이나 영어가 중요하다고 생각한다. 위에서 추천한 강의나 책들이 대표적인 장점일 텐데, 좋은 책과 강의는 영어로 먼저 공개되는 경우가 대부분이다 (좋은 한국어책과 강의가 없다는 얘기가 아니다. 다만 절대적인 자료의 수가 아주 큰 차이가 난다는 점을 얘기하고 싶음). 운이 좋다면 CS50이나 The Missing Semester처럼 번역이 제공되겠지만, 그렇지 않은 경우도 상당히 많이 존재한다. 이런 강의나 책이 아니라도 해외 기술 블로그나 선행 연구 논문 등은 결국 영어를 피할 수가 없다. 번역기나 생성 AI를 쓰면 되지 않냐고 물어본다면, 회사 장비에서는 허가 되지 않은 번역 서비스 (Google Translate)나 생성 AI를 사용할 수 없는 경우도 빈번하게 존재한다. 설령 번역기를 사용할 수 있더라도 기술적인 내용의 경우 사용하는 어휘나 표현이 일반적인 구어/문어와 다르므로 오역이 발생할 가능성도 꽤 높다. 따라서 적어도 읽더라도 불편함 없도록 시간을 내서 공부하면 반드시 도움이 된다고 본다.

만약에 영어 읽기에 더해 말하고 듣기까지 수월하다면 더 좋을까? 이 경우 지원할 수 있는 회사의 범위가 외국계 회사로 확장되기 때문에 더 좋다고 할 수 있다. 반드시 그런 것은 아니지만 주위 사례나 levels.fyi에서 제공하는 정보 등을 종합했을 때 전체적인 보수 (Total Compensation)의 상방이 외국계 회사가 한국 회사에 비해 열려있으며, 회사 내에서 자리를 잘 잡는다면 해외 Relocation 기회도 얻을 수 있다는 장점이 있을 것이다.

대표적인 외국계 서비스 회사 Coupang의 TC

그러면 어떻게 영어 공부를 하면 좋을까? 이것 역시 정답은 없고 본인의 성향에 따라 다를 것이다. 해외에서 영어를 쓸 수밖에 없는 환경 (유학, 워킹 홀리데이 등)에 노출된다면 가장 좋겠지만, 현실적으로 모든 사람이 그렇게 하기는 어려울 것이다. 글 작성자 역시 해외 체류 없이 영어 공부를 했기 때문에 많은 도움을 받는 자료들을 남겨본다. 아마도 글을 쓰는 시점에서는 좋은 자료들이 더 많이 있을 것이다. 가장 중요한 것은 어떤 강의, 책을 보는 것보다 그것을 끝까지 꾸준히 유지하는 것임을 강조한다.

영어 읽기를 위한 구문과 문법 공부를 위한 교재들
- 박상효의 영문법 콘서트
- 실용 영문법 백과사전 2nd Edition
영어 말하기/듣기를 위한 강의들
- 라이브 아카데미 / 라이브 아카데미 토들러
- 일빵빵 영어회화

1.3. 체력

프로그램을 작성하고 디버깅하고 고치는 작업은 상당히 고된 작업임은 자명하다. 대개 주 5일, 하루 8시간 근무를 기본으로 하며 때에 따라 야근까지 있는 소프트웨어 엔지니어들은 앉아 있는 시간이 대체로 길 것이다. 20대 때는 크게 문제가 없었던 체력이 나이가 들어가면서 결국엔 업무 생산성에 영향을 미치는 경험은 나만 겪은 것이 아닐 것으로 생각한다. 체력이 부족하면 그것이 결국 정신적인 부분에도 영향을 주고, 사소한 것에도 감정 제어가 어려워지는 악순환으로까지 이어질 수 있다.

https://otr.co.kr/academy/?vid=13262

그렇다면 어떻게 하면 좋을까? 나는 개인적으로 어떤 운동이든 좋다고 생각하고 심지어 하루하루가 아니라 주에 2~3회 정도만 해도 아예 하지 않는 것보다는 무조건 좋다고 장담한다. 아마도 흔하게 접할 수 있는 운동은 아래와 같은 것들이 있을 것이다.

걷기
달리기
웨이트 트레이닝
수영
...

아예 운동 경험이 없고 가볍게 시작해 보고 싶다면 런데이 앱을 통해서 걷기부터 시작하는 것을 추천한다. 단계별로 시간을 조금씩 늘려가며 걷기 훈련, 달리기 훈련 등이 제공되므로 본인의 수준에 맞게 체계적으로 시작해 볼 수 있을 것이다.

마치며

이번 포스트에서는 내가 생각하는 중요한 소프트웨어 엔지니어를 위한 스킬셋 세 가지에 대해서 그렇게 생각하는 이유와 몇 가지 자료들을 제공하면서 마친다. 생각보다 내용이 길어져서 다음 포스트에서는 독서, 채용 과정 준비, 개인 재무 그리고 최신 기술 트렌드를 따라가는 방법에 대해서 정리하려고 한다.

코드트리 (Codetree) 두 달 이용 후기

가마뫼 — Sun, 9 Mar 2025 19:24:12 +0900

코드트리 (Codetree) 한 달간 사용 후기에서 첫 한 달 이용 후기를 남긴지가 엊그제 같은데 벌써 두 달이 지났다. 추가 한 달은 기존 트레일보다는 조금 난도가 있는 내용들을 주로 살펴보고 문제 풀이를 했었는데, 특히 처음 코딩테스트를 접하는 사람들이 힘들어하는 부분인 재귀함수 관련 내용이 그림으로 자세히 설명하고, 숙달될 때까지 유사한 유형을 제공해 주는 부분이 좋았다. 특히 시중의 코딩테스트 책들이 배열이나 트리와 같은 자료구조를 먼저 얘기하고 트리나 필요한 상황이 있을 때 재귀 호출 코드를 바로 설명하는 경우가 많은데, 코드 트리의 경우 앞부분에서 함수 호출과 재귀 호출에 관한 내용을 먼저 서술하면서 자연스럽게 완전 탐색까지 이어지는 커리큘럼이 신경을 많이 썼다는 생각이 들었다.

그 외에 첫 한 달 후기에서 남겼던 아쉬운 점들 역시 스타트업답게 (?) 빠르게 개선 및 의견 수렴이 되는 모습이었는데, 특히 충분한 사용 전에 요금 결제에 부담을 느낄 수 있다 보니 무료로 제공하는 트레일이 추가되었고, 포인트를 쌓아서 사용할 수 있는 곳이 없다는 피드백도 사이트 내에서 사용할 수 있는 일종의 재화로 제공하는 것으로 보인다. 자잘한 UI/UX나 제출 시 채점 속도 같은 부분도 내가 생각했을 때는 꽤 많은 개선이 있었던 것으로 보인다. 쉬운 트레일부터 많은 문제는 아니지만 난이도 있는 트레일까지 풀어본 경험으로 봤을 때 코드 트리는 사용자들이 충분히 믿고 사용해 볼만한 서비스라고 생각된다. 앞으로도 더 많은 개선과 좋은 사용자 경험을 제공했으면 한다는 말로 두 달 이용 후기를 마친다.

Cache를 활용해서 똑똑하게 중복 로그를 방지해보자!

가마뫼 — Sun, 2 Mar 2025 19:13:43 +0900

배경

최근 Quantization Simulation 내용이 포함된 Machine Learning Pipeline 스크립트를 작성할 일이 있었다. 비교적 최근에 AI 조직으로 합류하게 된 엔지니어의 교육용이자 Hands-on을 위한 스크립트였는데, 각 블록이 어떤 역할을 하는지 코드 레벨로 확인할 수 있게 로그를 심는 부분이 있었다. 회사 내의 업무라 정확한 내용을 얘기하기는 좀 어렵지만, 다루는 모델의 크기가 크기 때문에 모델에 대한 특정 정보를 로깅 해서 단순히 남길 때 너무 많은 로그가 생성되고 그중 많은 부분이 중복되는 정보여서 여간 신경 쓰이는 것이 아니었다. 사실 교육용 스크립트고, 읽는 사람이 약간의 귀찮음을 감수하면 큰 문제는 없었지만, 코드 리뷰 때 비슷한 질의를 다른 엔지니어들에게도 몇 번 받았고 이런 부류의 문제는 어떤 식으로 해결하는지 개인적으로 궁금하기도 하여 비슷한 상황을 모사할 수 있는 스크립트와 해결 방식을 남겨둔다.

초기 구현

import logging

import torch
from torch.nn.modules.module import register_module_forward_pre_hook
from transformers import AutoModelForCausalLM

logger = logging.getLogger(__name__)
logger.setLevel('INFO')
stream_handler = logging.StreamHandler()
logger.addHandler(stream_handler)

checkpoint = 'HuggingFaceTB/SmolLM2-135M'
model = AutoModelForCausalLM.from_pretrained(checkpoint, torch_dtype=torch.bfloat16)


def module_type_hook(module, _) -> None:
    logger.info(f'Model contains {type(module)} module')


register_module_forward_pre_hook(module_type_hook)

dummy_input = torch.zeros(1, 64, dtype=torch.long)
with torch.inference_mode():
    model(dummy_input)

유사한 상황을 모사할 수 있는 초기 스크립트를 우선 작성해 봤다. 우선 Logger를 하나 생성 후 몇 가지 설정 (Level, Handler 등)을 하고 HuggingFace에서 제공하는 작은 크기의 모델 중 하나인 SmolLM2-135M를 가져온다. 해당 스크립트의 목적은 모델을 구성하고 있는 PyTorch module의 종류를 파악하기 위해서 hook 함수를 하나 만들고, 최종적으로는 dummy_input을 forward 함수에 태워서 로그를 출력하는 것이 목적이다. 아마 대부분의 ML Engineer에 해당 스크립트는 아주 어렵지 않을 것이지만, 혹시 Logger, HF transformers 패키지, 또는 PyTorch Hook에 대해서 익숙하지 않다면 다음과 같은 페이지들을 참고로 남겨둔다. 해당 페이지들을 읽은 후 위 코드를 직접 실행해 보면 의도를 더 쉽게 이해할 수 있을 것이다.

위 스크립트를 실행해 보면 다음과 같은 결과를 얻을 수 있다.

Model contains <class 'transformers.models.llama.modeling_llama.LlamaForCausalLM'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaModel'> module
Model contains <class 'torch.nn.modules.sparse.Embedding'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaRotaryEmbedding'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaDecoderLayer'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaRMSNorm'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaSdpaAttention'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaRMSNorm'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaMLP'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.activation.SiLU'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaDecoderLayer'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaRMSNorm'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaSdpaAttention'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
# 이하 중략

작은 크기의 모델이라고는 해도 Decoder Layer가 30개나 되다 보니 전체 로그 수가 모듈 개수만큼 기록되고, 한눈에 봐도 중복되는 로그가 많이 보인다. 만약에 더 큰 크기의 모델을 같은 스크립트에 대해서 실행하면 더 많은 의미 없는 로그들이 많이 쌓이게 될 것은 쉽게 짐작할 수 있겠다. 즉, 우리는 의미 있는 정보 그러니까 우리가 관심 있는 정보인 모델을 구성하는 모듈 타입의 종류에 대해서만 적절하게 로그를 남길 수 있으면 좋겠다는 결론에 이르게 된다.

Cache를 활용한 트릭

이런 중복 로그를 남기지 않는 방법으로는 여러 구현 방식이 있겠지만, Python에서 제공하는 @functools.cache 또는 @functools.lru_cache(None)을 활용해 볼 수 있습니다. 기본적으로 캐시는 비싼 연산을 매번 계산하지 않기 위해서, 사전에 연산에 대해서 계산한 값을 저장 후 이후에 같은 입력에 대해서는 계산 없이 캐싱해 둔 값을 반환하는 개념인데요. 중복 로깅을 방지하는 트릭에서도 캐싱 기능을 활용해 볼 수 있습니다. 캐시 자체에 대한 개념은 해당 포스트의 범위를 조금 벗어나니 필요하다면 https://docs.python.org/3/library/functools.html#functools.cache 문서를 참고하세요. 거두절미하고 트릭을 적용한 스크립트를 보겠습니다

import functools
import logging

import torch
from torch.nn.modules.module import register_module_forward_pre_hook
from transformers import AutoModelForCausalLM

logger = logging.getLogger(__name__)
logger.setLevel('INFO')
stream_handler = logging.StreamHandler()
logger.addHandler(stream_handler)


@functools.lru_cache(None)
def info_once(msg):
    logger.info(msg)


checkpoint = 'HuggingFaceTB/SmolLM2-135M'
model = AutoModelForCausalLM.from_pretrained(checkpoint, torch_dtype=torch.bfloat16)


def module_type_hook(module, _) -> None:
    info_once(f'Model contains {type(module)} module')


register_module_forward_pre_hook(module_type_hook)

dummy_input = torch.zeros(1, 64, dtype=torch.long)
with torch.inference_mode():
    model(dummy_input)

info_once라는 lru_cache로 데코레이트 된 메서드를 하나 선언하고, 기존에 hook 함수에서 호출하던 logger.info를 info_once로 바꿔주는 단순한 변경입니다. 다시 말하자면 처음 맞이하는 로그 메시지에 대해서는 logger.info(msg)를 호출하게 되고, 그 이후에 동일 msg에 대해서는 이미 캐싱이 되어있으므로 logger.info(msg)를 호출하는 대신 캐싱 된 결과를 반환하는데요. 이때 logger.info(msg)의 결과는 None이기 때문에 자연스럽게 중복된 로그에 대해서는 더 이상 로그가 찍히지 않게 됩니다. 실제 실행 결과는 아래와 같습니다

Model contains <class 'transformers.models.llama.modeling_llama.LlamaForCausalLM'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaModel'> module
Model contains <class 'torch.nn.modules.sparse.Embedding'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaRotaryEmbedding'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaDecoderLayer'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaRMSNorm'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaSdpaAttention'> module
Model contains <class 'torch.nn.modules.linear.Linear'> module
Model contains <class 'transformers.models.llama.modeling_llama.LlamaMLP'> module
Model contains <class 'torch.nn.modules.activation.SiLU'> module

무시무시한 (?) LLM의 명성과 다르게 실제로 구성하고 있는 모듈의 타입은 꽤 단순하죠? Leaf 레벨의 모듈만 고려하면 6가지 모듈로만 구성되어 있습니다. 본 포스트에서는 단순한 시나리오에 대해서 중복 로그를 방지하는 예제 코드를 다뤘는데요. 조금 변형하면 각자의 상황에 맞춰서 더 개선할 수 있을 것입니다.

결론

캐싱의 성질을 활용하여 중복으로 남는 로그를 똑똑하게 방지할 수 있다!

References

양자화 (Quantization)와 반올림 (Rounding)

가마뫼 — Sun, 16 Feb 2025 18:03:41 +0900

배경

LLM을 비롯한 AI Application의 배포 타겟은 Cloud 기반에서 실행되는 서버 향도 존재하지만, 여러 장점 (개인 프라이버시, 저전력/저발열 등)을 가지고 있는 On-device도 활발히 연구/개발 중인 분야입니다. 특히 상대적으로 연산의 성능이나 메모리 제약으로 인해 On-device AI의 경우 양자화 (Quantization)을 높은 비율로 채용하게 되는데요. 양자화는 결국 정보 손실을 필연적으로 가지므로 Application의 성능 (Accuracy 등)에서 손해를 어느 정도는 감수할 수밖에 없습니다. 문제는 매번 여러 가지 양자화 실험을 한 후에 타겟 Device에 모델을 배포하고 성능을 측정하는 것이 굉장히 귀찮고 번거로운 작업일 텐데요. 따라서, 직접 하드웨어까지 배포하지 않더라도 양자화를 통해서 하드웨어에 배포했을 때의 효과를 시뮬레이션하는 도구들이 많이 존재합니다. 흔히 인기 있는 딥러닝 프레임워크인 PyTorch나 TensorFlow에서도 자체적으로 양자화 시뮬레이션을 지원하며, 특정 하드웨어 제조사 (Qualcomm 등) 역시 해당 하드웨어에 모델을 배포했을 때의 양자화 시뮬레이션을 해볼 수 있는 AIMET과 같은 도구를 오픈소스로 공개하고 있습니다. 즉, 시뮬레이터는 하드웨어의 동작을 그대로 모사할 수 있어야 하는데요. 이번 글의 동기는 시뮬레이터의 결과와 실제 하드웨어에 배포했을 때의 결과가 차이가 나는지에 대해서 팀원이 조사해서 발견한 원인에 대해 이야기해 보려고 합니다. 이런 차이가 발생하는 데는 다양한 이유가 있지만, 그중 하나였던 반올림 방식의 차이가 문제였는데요. 반올림 방식에 관해서 얘기하기 전에 양자화 (Quantization)에 대해서 먼저 간략하게 설명하는 것이 이해에 도움이 될 것 같습니다.

양자화 (Quantization) 개념

양자화라는 개념은 사실 머신러닝 외에도 디지털 신호처리 등 다양한 분야에서 사용되고 있었는데요. 간단하게 얘기하면 아래 그림과 같이 연속적인 값은 유한한 이산값들로 근사하는 과정이라고 얘기할 수 있습니다.

Quantization

일반적인 머신러닝 모델들은 FP32/FP16 부동소수점 데이터 타입을 하고 있고, 이런 연속적인 값을 INT8/INT4와 같이 이산값으로 변환하여 에너지 소모 (사람도 정수 덧셈/곱셈이 실수 덧셈/곱셈보다 쉽죠?), 메모리 사용량 (FP32 -> INT4, 8배 이득) 등 스마트폰이나 Embedded 장비처럼 자원이 제약된 환경에서 애플리케이션을 잘 실행할 수 있도록 도와줄 수 있게 됩니다. 그렇다면 어떻게 실수형 연속변수를 정수형 연속변수로 변환하는지를 살펴보겠습니다. 사실 변환하는 수식은 그렇게 어렵지 않은데요. 기본적으로는 아래와 같습니다.

우선 변환할 이산변수의 bitwidth를 결정하고 (e.g., INT4라면 b=4), 양자화 파라미터인 scale과 zero point를 계산하면 연속 변수를 이산 변수로 변환할 수 있습니다.

Scale은 위와 같은 식으로 구할 수 있고, 예를 들어 현재 데이터의 분포가 [-100, 100] 사이의 값이고 INT4로 변환한다면 Scale 값은 (100 - (-100)) / (15 - 0) = 13.33과 같이 계산할 수 있습니다. Zero point 역시 아래처럼 구할 수 있는데요

위와 같은 과정을 통해서 Scale과 Zero point를 알고 있다면 이제 X라는 데이터에 대해서 Scale을 나눠준 후 반올림 연산을 하고 Zero point를 더한 후 최종적으로는 우리가 표현할 수 있는 범위 [0, 2^b - 1] 사이로 clamp를 하는 것이 전부입니다. 기본적인 양자화에 대한 수식은 이렇고, 오차를 최소화하기 위해서 단순히 min/max가 아닌 방식을 사용하거나 분포에 따라 (특히 weight 등) 연속 변수 0을 이산 변수 0으로 대응하는 symmetric quantization 같은 방식들이 있으나 해당 내용은 이번 포스트에서 다루고자 하는 내용에서는 조금 벗어나므로 키워드만 남겨놓습니다. 설명했던 것처럼 반올림 연산들이 포함되어있는데요. 시뮬레이터 상의 결과와 하드웨어 결과가 달랐던 원인 중 하나가 나중에 확인해보니 반올림 방식의 차이때문이었습니다.

반올림 (Rounding) 방식

반올림 방식은 한 두개가 아니라 너무 다양하지만, 이번 포스트에서는 크게 2가지 Rounding half to even과 Rounding half away from zero 2가지 경우에 대해서만 얘기하려고 합니다. 전자는 Python에서의 기본 Rounding 방식이며, 후자는 C에서의 Rounding 방식인데요. Rounding half to even은 5를 초과하는 값은 올림, 5 미만은 버림하며 마지막으로 5일 경우 앞자리 숫자가 짝수면 버리고 홀수면 올림하여 짝수로 맞춰줍니다. 이 방식은 통계적으로 오차가 적은 것으로 알려져있기 때문에 자연과학이나 공학에서 널리 쓰이는 방식이며 IEEE 754의 부동소수점 연산의 반올림 표준이라고 합니다. 반대로 Rounding half away from zero는 우리가 일반적으로 알고 있는 반올림 연산이라고 생각할 수 있습니다. 0에서 멀어지는 방향으로 반올림하므로 2.5는 3으로 -2.5는 -3으로 반올림하는 것이죠. 또한 구현 역시 상대적으로 더 간단한 편입니다. 파이썬에서는 아래와 같이 해당 반올림 방식을 모사해볼 수 있습니다.

def c_round(x):
    return int(x + (0.5 if x >= 0 else -0.5))

-3.5부터 3.5사이의 값을 각각의 방식으로 반올림 했을 때 결과는 아래와 같습니다

한 눈에 봐도 차이가 보이죠? 다시 양자화 수식을 떠올려볼까요?

즉, 작은 bitwidth일 수록 rounding 방식에 따라 그 차이가 굉장히 벌어질 수 있음을 이제는 눈치챌 수 있을 것 같습니다. 어찌 보면 사소하지만, 큰 차이를 만들어내는 나비효과로도 볼 수 있겠네요! 시뮬레이터와의 결과 차이가 나는 이유는 이것 하나만은 아니었지만, 여러분들도 양자화 시뮬레이션을 한다면 타겟 장치에서의 반올림 연산이 어떤 방식으로 동작하는지 미리 확인해 보면 불필요한 차이 중 하나를 예방할 수 있을 것입니다.

References

Nagel, Markus, et al. "A white paper on neural network quantization." arXiv preprint arXiv:2106.08295 (2021).
https://www.mathsisfun.com/numbers/rounding-methods.html
https://en.wikipedia.org/wiki/Rounding#Rounding_to_the_nearest_integer
https://hanlab.mit.edu/courses/2024-fall-65940

코드트리 (Codetree) 한 달간 사용 후기

가마뫼 — Sun, 2 Feb 2025 15:32:43 +0900

개발자 커뮤니티인 글또와 제휴를 맺은 다양한 기업 및 서비스를 체험해 볼 수 있는 여러 기회가 있었는데, 나는 이번에 코딩테스트 및 자료구조/알고리즘 공부 플랫폼인 코드트리 (Codetree)에 챌린지 지원을 하여 약 한 달간 사용 후 후기를 남겨본다. 소프트웨어 엔지니어로 현재 일하고 있거나 대학생의 경우라도 구직 준비 중이라면 코딩 테스트에 대해서는 어느 정도 알고 있을 것인데, 기존에 잘 알려진 플랫폼으로는 LeetCode나 프로그래머스와 같은 서비스가 있을 것 같다. 우선 구체적인 후기를 남기기 전에 몇 가지 나의 배경 및 면책 조항을 먼저 얘기하고 시작하는 것이 좋을 것 같아서 명시하고 넘어가 본다.

배경 및 면책 조항

배경: 나는 17년부터 소프트웨어 엔지니어로 근무를 시작했고, 지원자로서 코딩 테스트와 면접관 관점에서 코딩 테스트 모두에 어느 정도 익숙한 케이스이다. 다만, 신입 공채 수준의 악명 높은 알고리즘은 이제는 빠르게 풀어내진 못하며 경력직 코딩테스트 수준에서 자주 빈출 되는 주요 자료 구조 (Hash, Stack, Graph 등)와 알고리즘 (DFS/BFS, 정렬 등) 정도의 문제 풀이를 최근까지 주로 했었음
면책 조항: 아무래도 글또 커뮤니티를 통해서 기회를 받았으므로 일종의 '광고'로 볼 수 있다는 점을 글을 읽는 사람들이 고려했으면 함. 다만, 작성자 나름의 객관성을 유지하려고 하며 아쉬운 부분은 솔직하게 얘기할 것임

전체적인 인터페이스

우선 코드트리의 메인 페이지로 접속하면 아래 그림처럼 크게 6개의 단계별 섹션 (코드트리 내에서는 이것을 Trail이라고 하는 것 같음)이 존재한다.

부문별로 다루는 내용과 난이도에 대해서 간략한 설명이 있기 때문에, 본인의 현재 수준에 대해서 잘 알고 있다면 해당 트레일로 바로 시작할 수 있도록 잘 분리가 되어있는 점이 눈에 띄었다. 하지만, 객관적인 수준에 대해서 정확히 잘 모르는 경우 코드트리 내에서 실력 진단 테스트를 제공하고 있고, 이때 본인의 목표 기업도 설정할 수 있는 것으로 보아 특정 회사에서 빈출 되는 유형에 대해서 더 효율적으로 학습할 수 있는 경로를 제공하는 것으로 보인다. 다만, 본인은 아쉽게도 해당 테스트가 약 3시간 정도 걸린다고 하여 테스트까지는 진행하지 않았고, 이번 한 달은 코드트리 플랫폼에 익숙해지기 위해서 가장 낮은 난도부터 차례대로 풀되, 너무 지루할 때는 그래도 잘 알고 있는 유형 (완전 탐색 등)에 대해서 몇 문제만 골라 풀기로 계획을 세웠다.

실력 진단을 누르면 난이도 테스트를 시작할 수 있음

난이도 테스트는 약 3시간이 걸린다고..

실제 문제 풀이를 진행하는 인터페이스는 아래와 같은데, 사실 해당 인터페이스는 기존에 LeetCode나 프로그래머스를 사용했던 사람들이라면 금방 익숙해질 수 있을 만큼 유사하다. 좌측에는 문제에 대한 설명이 있고 우측에는 코드 작성란과 사용자가 지정해서 등록할 수 있는 테스트 케이스, 코드 실행 및 채점 메뉴들이 존재하여 직관적으로 이해할 수 있을 것이다.

사실 여기까지만 보면 기존 플랫폼들과 특별히 다른 점이 있냐는 생각이 들 수 있는데, 세세한 부분에서 실제 사용자를 배려하고 동기를 유발하는 몇 가지 추가 기능들이 있어서 아래에서 자세히 소개해 본다.

학습 업적을 활용한 동기부여

매일 첫 코드트리 접속 시 뜨는 모달 또는 오른쪽 위의 경험치 목표를 사용자가 설정할 수 있고, 연속 학습에 따라 업적을 아래와 같이 부여하는 것을 볼 수 있다. 아마도 연속 학습에 대한 트래킹은 유사 서비스에서도 제공하나, 당일 업적을 쌓기 위해서, 필요한 경험치(XP)를 사용자가 직접 지정할 수 있기 때문에 조금 더 유연하게 동기부여를 할 수 있다는 점이 마음에 들었다. 내 경우 주말이나 퇴근 후에 컨디션이 괜찮은 경우 100XP 정도로 설정했고, 바쁘거나 컨디션이 좋지 않으면 최소 경험치 값인 25XP를 설정하여 부담 없이 스트릭을 유지할 수 있었고 2월 초 기준 28일 연속 학습으로 Tree 업적 (30일) 까지는 2일이 남은 상태다.

GitHub 연동

위에서 얘기한 서비스 내에서의 업적 외에도 코드트리는 자체적으로 GitHub 연동을 지원하는데, 무슨 말인가 하니 본인이 제출한 코드에 대해서 자동으로 연결된 GitHub 저장소에 연동이 된다. 연동에 대한 메뉴는 코드트리 오른쪽 아래의 본인 아이디를 누른 후 GitHub에 학습 기록 남기기 메뉴를 통해 아래와 같이 진행된다.

예를 들어서 나는 https://github.com/gamamoe/Codetree-TILs 저장소를 설정했고, 아래처럼 1월 6일부터 제출한 코드들이 차곡차곡 쌓여있는 것을 확인할 수 있다. 날짜별 디렉터리를 들어가게 되면 푼 문제에 대한 요약도 같이 생성되어 있어 나중에 특정 자료구조나 알고리즘에 대한 코드가 필요할 경우 간단하게 검색을 통해 찾기도 쉬울 것으로 보인다. 이 기능이 마음에 드는 이유는 특히 경력이 없는 신입 개발자 지원자의 경우 면접관에게 어필할 수 있는 수단이 많지 않은데, 객관적으로 본인의 공부 내역을 보여줄 수 있기 때문에 얼마나 꾸준히 공부했고 어떤 자료구조/알고리즘을 공부했는지 파악할 수 있어 나중에 하나의 포트폴리오처럼 활용해도 좋을 것으로 보인다.

디스코드 커뮤니티 운영

사실 위 2개의 수단만 해도 게이미피케이션 및 동기부여 기능으로는 충분한 것 같은데, 거기에 더해 추가로 디스코드 커뮤니티를 운영하고 있다. 다만, 글또X코드트리 챌린지 동안만 한시적으로 운영하는 것인지 아니면 이후에도 계속 운영할 것인지는 조금 불분명하나 관리자분들이 적절하게 설치한 봇을 통해서 매일매일의 목표를 설정할 수 있고, 다른 사람들의 진행도를 보면서 좋은 자극과 동기부여를 받을 수 있다는 점이 장점으로 보인다. 꼭, 디스코드가 아니더라도 플랫폼 내에 비슷한 기능을 구현하거나 앞으로도 디스코드 커뮤니티를 계속 운영하면 좋겠다.

문제 구성, 난이도 및 지원 프로그래밍 언어

또 하나 특이한 점은 단순히 입력을 받아 출력을 계산하는 코드 작성 문제만 존재하지 않고, 다지선다 문제가 존재하는데 이는 처음 코딩테스트를 준비하는 사용자에게 단순히 코드만 작성하는 것이 아니라, 손과 머리를 활용하여 직접 다른 형태의 자극으로 공부에 도움이 될 것으로 보인다 (다만 코드를 복사해서 실행 후 답을 내면 의미가 없어지니, 펜과 종이를 활용하여 직접 풀어보자!)

추가로 25년 2월 기준으로 대부분의 메이저 프로그래밍 언어 (C/C++, Java, Python, JavaScript)는 지원하고 있으며, Go와 Rust 등의 언어도 지원하는 것으로 보인다. 다만 해설의 경우 대부분 많이 사용되는 프로그래밍 언어로만 작성되어 있다.

아쉬운 점

1월 초까지는 제출 시 채점 속도가 느리거나, 간혹 페이지가 멈추는 현상이 있었으나 아마도 개발자분들의 노력으로 25년 2월 기준으로는 쾌적하게 사용할 수 있었다. 다만, 아래처럼 웹브라우저 크기를 줄이는 경우 데스크탑 환경인데도 아래와 같은 메시지가 뜬 거는 문제가 아직 있는 것 같다. 추가로 매일매일의 업적을 위해서 설정하는 경험치를 모아서 무언가를 할 수 있으면 좋겠다는 생각이 드는데 그런 콘텐츠는 아직 없는 것으로 보인다. 동기부여가 떨어지면 25XP만 매일 설정하는 때도 생길 수 있을 것 같아 뭔가 보상이 있으면 더 좋을 것 같다는 생각이 든다.

총평

전반적으로 기존 코딩테스트 플랫폼과 유사한 인터페이스를 가져서 새로 시작하려는 사용자에게 거부감을 최대한 덜고, 삼중으로 무장한 동기부여 수단 (업적, GitHub 연동, 디스코드 커뮤니티)를 지원해 학습자가 꾸준히 진행할 수 있도록 도와줄 수 있다는 점이 장점으로 보인다. 코딩테스트는 결국 평소에 꾸준히 푸는 것이 중요하다고 생각되므로 이런 부분이 큰 도움이 될 수 있을 것 같다고 생각한다. 특히, 학생의 경우 할인이 추가로 있으니 이런 부분도 고려하여 코딩 테스트 준비에 고려하면 좋겠다. 그럼, 후기 끝!

문화체육관광부 추천 도서 (성인과 유아/청소년)

가마뫼 — Thu, 30 Jan 2025 22:58:01 +0900

설을 지내고 나니 벌써 1월의 마지막에 가까워졌고, 다시 말해서 25년도의 1/12가 지나간 셈이다. 나를 포함해 신년 목표로 독서를 계획한 사람들이 많을 것으로 생각한다. 본인만의 독서 계획이 있는 사람도 있겠지만, 이제 독서를 막 시작하는 사람이라면 어떤 책을 읽을지부터가 난관일 것 같다. 다행히도 문화체육관광부의 국립중앙도서관과 국립어린이청소년도서관에서 사서 추천 도서를 공개하고 있으니, 본인과 자녀들이 있다면 해당 추천 도서 리스트를 참고하면 좋은 시작점이 될 것 같다. 자세한 내용은 아래에서 서술한다.

국립중앙도서관 추천 도서

문화체육관광부 국립중앙도서관 홈페이지 또는 다음 링크를 통해서 여러 주제 (문학, 인문과학, 사회과학, 자연과학) 및 테마별로 정리한 추천 도서를 찾아볼 수 있다. 등록순으로 결과를 정렬해서 봤을 때 대략 2009년 혹은 2010년부터 목록을 만들기 시작한 것 같으며, 25년 1월 말 기준으로 총 1,371개의 추천 도서가 존재한다. 모든 목록을 확인한 것은 아니지만 대체로 성인을 위한 책들이라고 생각된다.

국립중앙도서관 사서 추천 도서

국립어린이청소년도서관 추천 도서

국립중앙도서관과 비슷하게 국립어린이청소년도서관에서는 유아부터 시작해 초등학생, 그리고 청소년을 위한 추천 도서를 정리해서 공개하고 있다. 문화체육관광부 국립어린이청소년도서관 홈페이지 또는 다음 링크를 통해서 나이별로 그리고 주제별로 추천 도서를 아래 그림처럼 확인할 수 있다. 25년 1월 말 기준으로 총 2,440개의 추천 도서가 존재한다. 간단한 책 소개도 같이 수록되어 있으니, 구매나 도서 대출 전 자녀와 함께 읽어보고 흥미에 맞는 책을 고르는 데 한결 도움이 되지 않을까 싶다.

국립어린이청소년도서관 사서 추천 도서

나의 경우 하루에 30분 정도 독서를 꼭 하려고 노력하는데, 책의 주제나 내 배경지식의 유무에 따라 조금씩 차이는 있지만 30분에 30페이지 정도를 읽을 수 있다. 그렇다면 단순히 계산했을 때 300페이지의 책을 한 번 읽는 데 10일 정도가 걸리고, 이것이 쌓이면 1년 기준으로 꽤 많은 책을 읽을 수 있을 것이다. 완독한 책의 수를 세는 것이 누군가는 지적 허영심이다 또는 의미 없는 짓이라고 얘기하겠지만, 유튜브나 각종 SNS에 노출된 현대인을 생각하면 그것이 지적 허영심일지라도 책을 읽는다는 행위에 익숙해질 필요는 있다고 본다. 어느 정도 익숙해지고 나면 서평도 작성하고, 책에 대해서 비판적인 시선도 생길 것이며 그 후의 또 다른 과정은 미래의 나에게 맡겨두면 되니 너무 걱정하지 말고, 다 같이 독서의 즐거움을 알아가면 좋겠다. 추가로 모든 책을 구매하는 것은 생각보다 부담스러운 일이니, 근처 도서관을 활용해 빌려보다가 정말 마음에 드는 책이 있다면 그때 구매하는 것도 하나의 방법이겠다. 너무 큰 목표로 시작하기보다는 작년보다는 조금 더 책을 읽어보는 한 해가 되면 최고 아닐까?

머신러닝 엔지니어의 2024년 회고

가마뫼 — Tue, 31 Dec 2024 19:02:42 +0900

개요

연차가 쌓이면서 하루하루는 더디게 느껴지지만 한 주, 한 달, 그리고 한 해는 눈 깜짝할 새 지나는 것 같다. 2023년 회고를 작성한 것이 얼마 되지 않은 것 같은데 벌써 2024년의 막바지에 기록을 남겨본다. 글을 작성하기 전 2023년 회고를 읽어봤는데, 나란 사람 자체가 변화를 크게 좋아하지 않고 루틴을 지키려고 하는 편이라 그런지 크게 변함없는 한 해를 보낸 것 같다. 조금 미리 작성하면 더 좋을 텐데 올해도 12월 31일 딱 마지막 날에 글을 작성하는 것도 작년과 똑같은 모습에 조금은 반성하게 된다. 그런데도 올 한 해 성취한 내용과 잘했던 점, 아쉬운 점 그리고 미약하지만 2025년도에 이루고 싶은 목표를 작성해 보고자 한다.

잘했던 점

Staff Engineer 승진

올해 9월로 Qualcomm에서 만으로 3년을 꽉 채우는 해였고 물 밑에서 어느 정도 승진에 관한 얘기가 있었지만, 주위 사례를 봤을 때 확신할 수는 없었다. 다행히 운이 좋게도 헌신적인 조직장과 훌륭한 동료들 덕분에 Staff Engineer로 승진할 수 있었다고 생각한다. 승진은 회사에서 나라는 엔지니어의 가치를 어느 정도 인정해 줬다는 것으로 생각하고, 실제로 그에 걸맞은 금전적인 보상이 있었다. 승진 자체는 매우 기쁘고 행복한 일이지만, 주위에서 보았던 동료 Staff Engineer들이 얼마나 열심히 일하고 업무에 헌신적인지를 봤을 때 내가 그들만큼 잘할 수 있을까에 대한 걱정은 여전히 가지고 있다. 다만 걱정만 하는 것은 회사도 나도 원하지 않는 방향이기 때문에 어떻게든 부딪혀가면서 해내 보려고 한다. 새로운 직급에 대해서 정확한 역할이 정해져 있는 것은 아니지만 역시나 기술적으로는 주니어 엔지니어들을 리드할 수 있어야 할 것이며, 팀 자체로는 좋은 멘토 및 동기부여를 줄 수 있는 사람이 되길 기원한다. 리더십이나 팀 매니징 관련해서는 선배들의 도움을 간접적으로나마 받고 싶어 <혼돈의 시대 리더의 탄생>과 <무엇이 1등 팀을 만드는가?>와 같은 책을 읽어보면서 내 상황에 활용해보려고 한다.

독서

작년에 이어서 올해도 매달 진행하는 독서 모임을 계기로 꾸준히 책을 읽은 것은 잘한 것 같다. 이런 외적 동기부여가 없으면 소설이나 문학 작품은 우선순위에서 항상 밀리는 내 성격을 고려했을 때 올해도 아래와 같은 책들을 읽은 것은 매우 뿌듯한 일이라고 생각한다. 특히 좋았던 책은 굵은 글씨로 표기해 본다.

라이프 타임
아주 희미한 빛으로도
문학을 읽는다는 것은
책에 대한 책에 대한 책
영화의 이해
매니악
두 사람의 인터내셔널
시간을 잃어버린 사람들
한강 디 에센셜
도시와 그 불확실한 벽

최은영 작가의 <아주 희미한 빛으로도>나 <두 사람의 인터내셔널> 같은 소설은 굉장히 재밌어서 주위 동료나 친구들에게도 선물했던 책이다. 다만 책을 읽은 것과는 별개로 개인 사정으로 작년만큼은 모임에 참석을 못 해서 좀 아쉬운 부분과 모임장에게 미안한 마음이 있다. 불가피한 사정이 아니라면 2025년에는 올해보다는 더 많이 참석하여 여러 사람과 읽은 책에 대해서 나눌 수 있기를 바란다. 추가로 글또 내의 소모임 중 하나인 책읽었또 덕분에 몰아 읽기가 아니라 매일매일 조금이라도 읽을 수 있는 루틴을 만들 수 있어서 큰 도움을 받았다. 내년에도 해당 소모임을 통해서 꾸준히 책을 읽는 습관을 지니려고 한다.

조깅

독서와 마찬가지로 조깅 역시 올해도 꾸준히 한 것이 잘한 점이라고 생각한다. 재택근무를 주로 하므로 조깅하지 않으면 하루 종일 집에만 있게 되는 경우가 많았는데, 어떻게든 업무 시작 전이나 업무 마감 후에 뛰려고 했고 런데이 앱과 글또의 달리또 소모임의 도움을 많이 받았다. 가능하면 격일로 30분 정도 뛰고, 뛰지 않는 날은 걷기라도 하려고 했으며 꾸준히 뛰었을 때 확실히 육체적/정신적으로 굉장히 긍정적인 효과가 있었다고 생각한다. 작년 회고에서 단거리 마라톤을 도전해 볼까 하는 얘기를 했었는데, 아쉽게도 특별히 대회에 참가하지는 않았다. 성향상 역시 부대끼지 않고 조용히 내 페이스대로 혼자 뛰는 것이 마음이 편한 것 같다. 올해 열심히 뛰어 수명이 다한 신발도 교체했고, 욕심을 조금 더 내어 2025년에는 올해보다 더 꾸준히 그리고 50분 달리기까지 도전해 보려고 한다.

올해 가장 열심히 뛴 10월

아쉬운 점

영어

가장 먼저 생각나는 항목은 역시 영어라고 본다. 기술적인 대화는 어휘나 표현이 그렇게 어렵지 않고, 상대의 눈빛과 같은 비언어적 반응을 통해서 이해 유무를 다시 한번 확인할 수 있기 때문에 그동안 의사소통에 대해서 아주 심각하게 생각하진 않았었다. 그래서 특별히 영어 공부를 한다는 느낌보다는 작년 회고와 마찬가지로 유튜브 영상 (e.g., 라이브 아카데미) 중 눈에 띄는 영어 관련 영상이 있으면 챙겨보는 정도였다. 다만 업무 분담이 늘어났고, 커리어 래더가 늘어났기 때문에 속된 말로 틀에 박힌 영어 구사력은 결국 내 발목을 잡을 것 같다는 생각이 꽤 많이 든 한해였다. 조금 유식하게 표현했을 때 현재 내가 모국어 간섭이 매우 많은 영어 구사를 하는 상태라는 것을 시간 내어 공부하고 있는 강의를 통해 이해하게 됐으며 이것을 적극적으로 개선해 보려고 노력 중이다. 확실히 유튜브를 통해서 내가 하고 싶을 때만 골라 듣는 것이 아니라 강의 형태로 어느 정도의 커리큘럼이 있다 보니 더 체계적이고 나도 무조건 영어 공부를 위한 시간을 따로 내고 있다 보니 조금씩 실력이 늘어나는 것이 느껴지고 있다. 2025년에도 매일 조금씩이라도 해당 강의와 함께 좀 더 고급 영어를 내뱉을 수 있도록 노력해 보려고 한다.

Quantization 연구에 대한 뒤처짐

Qualcomm에 입사한 2021년과 비교했을 때 2024년 기준 모델 경량화에 대한 수요와 연구는 폭발적으로 성장했다고 생각한다. 가장 정량적인 바로미터가 결국 연구 논문의 수라고 생각할 수 있는데, 입사할 때만 해도 per-tensor W8A16 정도를 기준으로 생각했던 것과 비교해 요즘은 per-group W4A8과 같이 굉장히 공격적인 경량화까지 시도하는 것을 보면 격세지감이라고 할 것 같다. 입사 후 1~2년은 크게 따라가야 할 연구 논문의 수가 부담스럽지 않았고 (그리고 꼭 봐야 했던 논문은 대부분 Qualcomm에서 출간한 논문이었다) 업무 자체가 소프트웨어 엔지니어링에 조금 더 힘을 주는 것이었기 때문에 큰 부담이 없었다. 다만 올해 직접적으로 구현에 참여했던 GPTVQ나 옆에서 지켜봤던 Group Quantization 그리고 논문 세미나에서 들은 연구 내용 (OmniQuant, SmoothQuant 등)들을 고려했을 때 최신 추세에도 리서치 엔지니어만큼은 아니라도 어느 정도 이해를 해야 한다는 결론에 이르렀다. 엔지니어링과 리서치 두 마리 토끼를 잡아야 하는 것 같아 조금은 부담스럽지만 그래도 공부하지 않고 걱정하는 것보다는 낫지 않을까 싶다. 모든 연구 논문을 따라가는 것은 현실적으로 불가능할 것 같고, 주위 리서치 엔지니어 동료의 도움을 받아서 그럼에도 꼭 읽어봐야 하는 논문 몇 편을 골라볼 예정이다.

2025년 목표

올해 했던 내용들에서 특별한 무엇을 더하기보다는 올해 했던 것을 발전시켜 조금 더 나은 성취가 있기를 바라면서 정량적인 목표를 세워봤다

15권 독서 및 그중 7권 서평 작성하기: 기술 서적 외에 올해는 10권 독서했으므로 내년에는 15권 그리고 기록으로 남길 수 있도록 7권은 서평까지 작성해 보려고 한다
영어 강의 완강 및 후속 강의 수강: 현재 수강 중인 강의 완강과 후속 강의가 있어서 해당 강의까지 수강하는 것을 목표로 한다
주 3회 50분 조깅: 올해는 주 3회 30분 조깅으로 무리 없이 뛸 수 있었다면 내년에는 50분으로 조금 더 운동 부하를 늘려서 뛰어보는 것을 목표로 한다
Quantization 논문 2편 리뷰: 욕심내지 않고 2편 리뷰로 우선 목표를 잡아봤다. 아마 2편을 리뷰하려면 참조한 논문들까지 포함하여 꽤 많은 연구 논문을 봐야 할 것으로 생각한다

PyTorch Custom Op to ONNX

가마뫼 — Sun, 22 Dec 2024 20:31:07 +0900

앞선 포스트에서 몇 번 언급했던 것처럼 최근 머신러닝 애플리케이션은 연구자 (조직마다 다르지만 보통 Researcher, Data Scientist, Applied Scientist 등으로 표현하는 포지션)가 PyTorch 환경에서 모델 학습 및 실험으로 성능을 검증한 후 해당 모델을 배포할 환경에 따라 TFLite, ONNX 등으로 모델 변환을 하는 것이 일반적인데요. 특히 ONNX는 여러 최적화 기법을 공짜 점심으로 변환 시 제공하고 있어서 많이 활용합니다. 다만 우리가 만든 PyTorch 모델의 연산들이 항상 ONNX가 지원하는 Operator라는 보장이 없을 수 있는데요. 우선 ONNX에서 지원하는 Operator 목록은 링크를 통해 확인하실 수 있습니다

ONNX Operator Schemas

목록을 한 번 살펴보시면 눈치채셨겠지만, 최근 LLM 계열에서 많이 활용하는 RMSNorm이나 RotaryEmbedding 같은 연산들은 아직 ONNX에서 지원하지 않는 것을 확인하실 수 있는데요. 사실 이런 사용자 정의 연산자를 ONNX에서 매번 제공하는 것도 좋은 방향은 아닐 것 같습니다. 해당 연산이 정말로 많이 사용되고 이후에도 계속 사용된다면 괜찮겠지만, 특정 시점에 잠깐 유행하고 대체제가 나온다면 또 해당 연산을 지원해 줘야 하니까요. 우선은 이렇게 지원되지 않는 PyTorch 연산자를 ONNX로 export 하면 어떻게 결과물이 나오는지부터 확인해 보는 것이 좋겠습니다.

HuggingFace 저장소에 공개되어 있는 GemmaRMSNorm을 export 해보겠습니다. PyTorch에서의 구현체는 다음과 같습니다

class GemmaRMSNorm(nn.Module):
    def __init__(self, dim: int, eps: float = 1e-6):
        super().__init__()
        self.eps = eps
        self.weight = nn.Parameter(torch.zeros(dim))

    def _norm(self, x):
        return x * torch.rsqrt(x.pow(2).mean(-1, keepdim=True) + self.eps)

    def forward(self, x):
        output = self._norm(x.float())
        # Llama does x.to(float16) * w whilst Gemma is (x * w).to(float16)
        # See https://github.com/huggingface/transformers/pull/29402
        output = output * (1.0 + self.weight.float())
        return output.type_as(x)

    def extra_repr(self):
        return f"{tuple(self.weight.shape)}, eps={self.eps}"

rsqrt나 pow, mean과 같은 연산의 조합으로 norm을 처리하는 것을 확인할 수 있습니다. 저희의 기대대로라면 RMSNorm이 ONNX 그래프에서도 같이 RMSNorm으로 표현이 된다면 좋겠지만, 아마도 Operator Schemas의 지원 목록에 없었기 때문에 그렇지 않을 것이란 것은 이미 어느 정도 짐작할 수 있는데요. 실제로 ONNX로 export 후 그래프 형태를 Netron으로 시각화해 보면 아래와 같이 나타납니다.

RMSNorm on ONNX

지원하지 않는 RMSNorm 대신 ONNX에서 현재 지원하는 Unit 연산들, 다시 말해서 Add, ReduceMean, Sqrt, Div와 같은 연산의 조합으로 그래프가 표현되고 있는 것을 확인할 수 있습니다. 이렇게 원본 PyTorch 그래프와 export 된 ONNX 그래프의 개형 차이가 발생하는 경우가 사용자 정의 연산으로 인해 꽤 빈번할 텐데요. 일반적인 Inference 환경에서라면 대부분 큰 문제는 없을 것입니다. Export 과정에서 Graph tracing이 제대로 되었다면 수학적으로 만들어지는 결과는 PyTorch와 ONNX 양쪽 모두에서 같거나 약간의 오차만 있어야 하기 때문입니다. 다만, 우리가 이런 그래프를 Quantization, 특히 Activation Quantization을 진행한다면 생각해야 하는 부분이 꽤 생기는데요. PyTorch에서는 한 개의 연산으로 표현되는 RMSNorm이므로 한 개의 Activation Quantization만을 고려하면 되지만, ONNX에서는 여러 Unit 연산으로 쪼개지므로 예외 처리를 하지 않는 이상 여러 개의 Activation Quantization이 발생하게 되며 이는 아마도 우리가 기대하는 결과와는 꽤 많은 차이를 발생시킬 것 같습니다

이런 유스케이스 때문에 PyTorch와 ONNX에서는 사용자 정의 연산을 원하는 형태로 Export 할 수 있는 기능을 제공하는데요. 요약하면 사용자 정의 연산을 torch.autograd.Function을 상속 후 symbolic 함수를 구현해주면 됩니다. PyTorch 문서에서 제공하는 예제 링크는 간단한 연산인 ReLU를 예제로 사용하고 있는데요. 이번 포스트에서도 비슷하게 ReLU로 진행해보겠습니다. 우선 다음과 같이 사용자 정의 ReLU를 정의하고 시작하겠습니다.

class ReluFunc(torch.autograd.Function):
    @staticmethod
    def forward(ctx: Any, *args: Any, **kwargs: Any) -> Any:
        inputs = args[0]
        ctx.save_for_backward(inputs)
        return inputs.clamp(min=0)

    @staticmethod
    def symbolic(g: GraphContext, *args: Any) -> torch.Value:
        inputs = args[0]
        return g.op('my_domain::CustomReLU', inputs).setType(inputs.type())


class UserDefinedReLU(nn.Module):
    def forward(self, x: torch.Tensor) -> torch.Tensor:
        return ReluFunc.apply(x)

torch.autograd.Function을 상속한 ReluFunc를 정의하고 forward 함수와 symbolic을 구현한 것을 볼 수 있습니다. 이 때 symbolic 함수의 시그니처는 다음 문서를 보시면 도움이 될 것 같은데요.

symbolic의 첫 번째 인자는 GraphContext이며 그 뒤는 positional arguments를 받습니다

그 후 GraphContext의 op를 정의해서 반환을 해야하는데요. 순서대로 연산자의 이름 (이 때 domain::type_name 형태로 정의할 수 있음)과 positional arguments와 keyword arguments등을 g.op(...)에 채워넣을 수 있습니다. 위 예제에서 저는 우선 도메인은 my_domain 그리고 연산자의 이름은 CustomReLU로 정의했고 ReLU는 간단한 연산이므로 argument는 입력값만 넘겨주면 되겠네요! 뒤의 setType 설정은 쉽게 빠뜨리기 쉬운 부분인데요. PyTorch 문서를 확인하시면 Shape inference를 위해 setType을 설정하기를 권장하고 있는 내용이 나옵니다.

When the user registers symbolic for custom/contrib ops, it is highly recommended to add shape inference for that operator via setType API, otherwise the exported graph may have incorrect shape inference in some extreme cases. An example of setType is test_aten_embedding_2 in test_operators.py.

자 이제 필요한 작업은 다 한 것 같으니 실제로 export된 CustomReLU의 그래프 형태를 한 번 살펴보겠습니다.

우리가 PyTorch 코드에서 정의한 domain과 type이 잘 설정된 것을 확인할 수 있네요 :) 만약에 symboilc 함수를 정의하지 않고 export하면 어떻게 나오는 지도 한 번 확인해봐야겠죠? 결과는 아래와 같습니다.

따로 symbolic 함수를 정의하지 않은 CustomReLU에 대해서는 ONNX가 기존에 지원하는 Unit 연산 중 하나인 Clip으로 그래프가 표현되고 있는 것을 확인할 수 있습니다. 포스트에서는 간단한 ReLU에 대해서만 진행해봤지만, 필요하다면 더 복잡한 연산에 대해서도 당연히 symbolic을 정의 후 ONNX export 할 수 있습니다. 본문의 RMSNorm과 같은 연산을 하나의 연산으로 export 하는 것은 과제로 남겨두겠습니다 :)

이번 포스트에서는 다음과 같은 내용을 다뤘습니다.

ONNX에서 지원하는 Operator 목록
PyTorch의 사용자 정의 연산을 export할 때 ONNX 그래프의 개형
PyTorch 사용자 정의 연산을 원하는 형태로 export 하기 위한 symbolic 정의

Stable Diffusion 3 ONNX Export 트러블 슈팅

가마뫼 — Sun, 24 Nov 2024 17:06:47 +0900

오늘은 업무 중 발생했던 Stable Diffusion 3 모델의 ONNX Export 과정에서 발생했던 이슈와 해결 방법에 대해서 공유해보려고 합니다. Qualcomm의 하드웨어에 AI/ML 모델을 배포하기 위해서 Qualcomm® Neural Processing SDK를 활용하는데요. 해당 SDK에서 제공하는 도구 중 Converter는 여러 가지 프레임워크 (e.g., ONNX, TensorFlow, ...) 를 지원하지만, 대체로 ONNX를 많이 활용하고 있습니다. 아마도 요즘 대부분의 Researcher들이 익숙한 딥러닝 프레임워크가 PyTorch고 PyTorch에서 ONNX Export는 간편하게 지원하는 것이 첫 번째 이유일 것이라고 짐작하며, 두 번째로는 ONNX를 활용함으로써 얻을 수 있는 공짜 점심들이 있기 때문일 것입니다. ONNX 자체적으로 지원하는 최적화 (Constant Folding, Graph Fusion, ...) 외에도 onnx-simplifier 같은 도구를 통해서도 여러 가지 검증된 최적화를 수행할 수 있기 때문입니다. 즉, ONNX를 사용하지 않을 이유는 그렇게 많지 않다고 생각되고, 이런 최적화에 관한 내용은 이번 글의 주제를 조금 벗어나기 때문에 앞으로 따로 글을 써보도록 하겠습니다. 여하튼 이러한 이유로 오픈 소스로 제공되는 모델 자체 또는 그것을 어느 정도 Fine-tuning 한 모델을 ONNX로 먼저 Export 하는 것이 최우선 단계일 텐데요. 해당 과정부터 무언가 문제가 있다는 얘기를 다른 팀 엔지니어로부터 전해 들었고 그 원인을 파악해 보았습니다.

Stable Diffusion 3 모델 구조

우선 Stable Diffusion 3의 모델 구조에 대해서 간략하게 설명하고 넘어가야할 것 같은데요. Stable Diffusion에 익숙하신 분들이라면 대부분 이 모델의 구조가 Text Encoder, UNet, 그리고 VAE의 조합으로 구성된 것을 어느 정도 잘 알고 계실 것 같습니다. Stable Diffusion 3도 큰 틀에서의 구조는 변함은 없지만 세세한 부분에서 변경사항이 좀 있는데요

https://encord.com/blog/stable-diffusion-3-text-to-image-model/

위 그림과 같이 3 종류의 Text Encoder를 사용하고 있으며, UNet 대신 MM-DiT를 활용하는 점이 이전 Stable Diffusion의 모델 구조와의 차이점이라고 볼 수 있을 것 같습니다. HuggingFace의 아래 모델 Definition을 보면 조금 더 이해에 도움이 될 것 같네요!

https://github.com/huggingface/diffusers/blob/main/src/diffusers/pipelines/stable_diffusion_3/pipeline_stable_diffusion_3.py#L131

Stable Diffusion 3 그 자체에 대해서는 또 글이 너무 길어질 것 같아서 이번 글에서는 모델 구조에 대해서만 간략하게 얘기하고 넘어가겠습니다. 좀 더 자세한 내용이 필요하신 분들은 stability.ai의 research paper와 위 그림의 출처인 https://encord.com/blog/stable-diffusion-3-text-to-image-model 링크를 참고하세요. 문제가 되는 컴포넌트는 MM-DiT였는데요. 어떤 Error가 발생했는지 밑에서 좀 더 자세히 설명하도록 하겠습니다.

Error 내용

전달 받은 Error는 그래프 내부에 특정 Tensor의 이름이 비어있고, 그것이 Graph Compile 과정에서 에러를 발생시킨다는 내용이었는데요. AI/ML 모델 시각화로 많이 사용하는 Netron 을 활용해서 정말로 그런 노드가 존재하는 지 확인을 해보았습니다.

입력 Tensor부터 거슬러가다보니 생각보다 빠르게 수상한 노드를 찾을 수 있었는데요. 다름 아닌 LayerNormalization 노드였습니다. 이제 수상한 노드를 찾았으니 실제 코드가 어떤식으로 구성되어있는지 찾아보면 문제를 해결할 수 있을 것 같네요!

MM-DiT의 모델의 forward pass를 보니 JointTransformerBlock 를 순회하고 있고, JointTransformerBlock은 아래와 같이 self.norm1을 가장 먼저 통과하게 되는데 이번 경우는 AdaLayerNormZero를 사용하고 있습니다. 거의 다 온 것 같은데요!

class JointTransformerBlock(nn.Module):
    r"""
    A Transformer block following the MMDiT architecture, introduced in Stable Diffusion 3.

    Reference: https://arxiv.org/abs/2403.03206
    이하 중략
    """

    def __init__(
        self,
        dim: int,
        num_attention_heads: int,
        attention_head_dim: int,
        context_pre_only: bool = False,
        qk_norm: Optional[str] = None,
        use_dual_attention: bool = False,
    ):
        super().__init__()

        self.use_dual_attention = use_dual_attention
        self.context_pre_only = context_pre_only
        context_norm_type = "ada_norm_continous" if context_pre_only else "ada_norm_zero"

        if use_dual_attention:
            self.norm1 = SD35AdaLayerNormZeroX(dim)
        else:
            self.norm1 = AdaLayerNormZero(dim)
        # ...

해당 레이어의 Definition이 눈에 띄네요. 아래와 같이 elementwise_affine=False로 주고 있고 이는 일반적인 LayerNormalization layer의 인자와 다른 값입니다. 기본값은 elementwise_affine=True죠. 이제 원인을 거의 다 찾은 것 같습니다. 아마도 LayerNorm에 대한 PyTorch 문서만 확인해보면 될 것 같네요 :)

class AdaLayerNormZero(nn.Module):
    r"""
    Norm layer adaptive layer norm zero (adaLN-Zero).

    Parameters:
        embedding_dim (`int`): The size of each embedding vector.
        num_embeddings (`int`): The size of the embeddings dictionary.
    """

    def __init__(self, embedding_dim: int, num_embeddings: Optional[int] = None, norm_type="layer_norm", bias=True):
        super().__init__()
        if num_embeddings is not None:
            self.emb = CombinedTimestepLabelEmbeddings(num_embeddings, embedding_dim)
        else:
            self.emb = None

        self.silu = nn.SiLU()
        self.linear = nn.Linear(embedding_dim, 6 * embedding_dim, bias=bias)
        if norm_type == "layer_norm":
            self.norm = nn.LayerNorm(embedding_dim, elementwise_affine=False, eps=1e-6)
        elif norm_type == "fp32_layer_norm":
            self.norm = FP32LayerNorm(embedding_dim, elementwise_affine=False, bias=False)
        else:
            raise ValueError(
                f"Unsupported `norm_type` ({norm_type}) provided. Supported ones are: 'layer_norm', 'fp32_layer_norm'."
            )
		# 중략

PyTorch 공식 문서의 LayerNorm Parameter에 대한 설명은 아래와 같습니다

elementwise_affine은 기본값이 True이며 이는 scale과 zero_point를 각각 learnable parameter로 초기화한다고 되어있습니다. 따라서 해당 값을 False로 주게되면 scale과 zero_point에 대한 Tensor의 이름이 제대로 채워지지 않았을 것이라고 추측할 수 있었습니다. 이에 대한 부분은 사실 ONNX Export의 책임이므로 저희가 어떻게 해결하기는 어려운 문제였는데요. 다만 저희는 pre-trained 모델을 사용하고 향후에 QAT와 같은 fine-tuning의 요구사항이 없었기 때문에 아래와 같은 Workaround를 적용해서 문제를 해결했습니다.

Workaround

문제 해결은 심플했는데요. PyTorch 모델을 순회하면서 nn.Module 중 LayerNorm이면서 elementwise_affine이 False로 설정되어있는 경우 해당 Flag를 변경하고, scale와 zero_point를 적절히 채워주었습니다. 코드 스니펫은 다음과 같습니다.

for name, module in model.named_modules():
    if isinstance(module, nn.LayerNorm) and not module.elementwise_affine:
        module.weight = nn.Parameter(torch.ones(module.normalized_shape))
        module.bias = nn.Parameter(torch.zeros(module.normalized_shape))

수식 상 weight * inputs + bias이므로 weight과 bias를 각각 1과 0으로 명시적 초기화하면 math invariant하기 때문에 문제가 발생하지 않습니다! 위와 같은 임시 해결책을 이슈를 공유한 엔지니어에게 전달하고 무사히 ONNX Export 및 Graph compile을 완료할 수 있었습니다.

Key takeaways

해결 방법이 생각보다 쉬워서 김이 좀 빠지셨나요? 실제로 위와 같은 이슈는 최신 PyTorch 및 ONNX 환경에서는 발생하지 않는 것으로 보입니다. 다만, 우리가 작업하는 환경이 항상 최신 버전을 사용할 수 없으므로 필요하다면 직접 소스 코드를 백포팅하거나 위와 같은 Workaround를 활용해야 할 때가 있음을 인지하고 있으면 좋겠죠? 이번 이슈 트러블슈팅에서의 몇 가지 Key takeaway는 아래와 같았습니다

로그를 잘 확인하자. 로그를 통해서 Tensor 이름이 비어 있는 값임을 알 수 있었다
시각화 도구 (e.g., Netron 등)를 잘 활용하면 가시적으로 문제를 파악하는 데 도움이 된다
상황에 따라 우리가 의존하는 패키지를 직접 수정하기 어려운 때도 있다. 이럴 때는 요구 사항을 잘 확인한 후 적절한 Workaround를 제공하는 유연함이 필요하다