neozest : neo+zest

평소 나는  SLM이 앞으로 두가지 측면에서 중요해질 것이라고 생각해 왔다.

첫째, AI가 동작해야 하는 환경에는 제약이 있다. 그것이 실시간성을 요구하는 기능적인 것일 수도 있고, 개인정보 보호같은 컴플라이언스 때문일 수도 있다. LLM의 성능이 우수하다고 하지만  산업현장이나 의료현장처럼 보안이나 규제가 존재하는 곳에서는 이야기가 달라진다. 제조업에 있는 지인도 SLM을 열심히 살펴보는 중인데, 장비의 센서 정보를 외부 서비스로 보낼 수도 없을 뿐더러, 요청을 보낸 뒤 언제 돌아올지 모르는 응답을 기다릴 수는 없다는 이야기를 들었다. 이런 환경에서는 모델의 절대적인 지능보다는 어디에서 실행할 수 있고, 얼마간의 자원으로 실행할 수 있고, 얼마나 도메인을 잘 이해하는가가 더 중요한 조건이 된다. Edge AI나 On-device AI가 계속 언급되는 이유이기도 하다.

둘째, 학습을 직접 경험하기 위한 현실적인 크기를 SLM은 제공해 준다. 우리가 다들 대형 언어모델을 이야기하지만, 개발자가 밑바닥부터 언어모델을 만들어 볼 일은 거의 없다. 실제 업무에서는 대부분  기존 모델을 선택하고, 데이터를 준비하여 파인튜닝하고, 평가하고, 양자화하거나 RAG를 붙여 원하는 성능을 만들어 가는 과정에 가까울 것이다.문제는 이 과정을 제대로 경험해 보려면 GPU 메모리와 학습 비용이라는 현실적인 부담이 존재하게 된다. 그래서 나는 SLM/sLLM이 단순히 작은 LLM을 넘어 학습 도구로 활용 가능성이 높다고 생각한다.

이런 고민을 하던 차에 길벗의 챗 <원하는대로 튜닝하는 나만의 sLLM>이 눈길을 끌 수밖에 없었다. 아차! 정확하게는 SLM이 아니라 sLLM이다. 이 책에서는 sLLM을 중점적으로 설명하는데, 중요한 것은 이름보다는 책이 다루는 범위다. 단순히 규모가 작은 모델을 소개하는데 그치지 않고 파인튜닝 방법부터 최적화, 서비스 구현까지 한 사이클을 모두 다룬다.

이 책에서 다루는 파인튜닝 과정을 제대로 로컬에서 실행해보려면 초기 투자비용이 발생한다. 물론 Google Colab에서도 실행할 수 있게 구성되어 있다.

이 책에서 소개하는 개념들은 책 한권으로 이해하기는 만만치 않다. 책에 실린 코드에는 설명이 달려 있지만, 각 기술을 좀 더 파고들기 시작하면 그것만으로도 공부가 필요했다. 이 부족한 부분은 독자가 스스로 메워야하는 여백? 공간인데... 나는 그 간격을 GPT에게 계속 질문하면서 메워 나갔다.

개인적으로는 1장은 개발자가 아니더라도 AI에 관심 있는여러 사람들이 함께 읽어봤으면 좋겠다. 지금까지 나온 AI의 흐름과 관련 용어, 개념을 잘 정리해 두었다. 그냥 추세를 읽고 싶은 분들이라면 충분히 공감할 내용이 많다. 용어 정리도 잘 되어 있다. 1장은 업계 흐름의 큰 지도를 그린다.

2장과 3장은 고만고만했는데, 1장 기본 개념을 기반으로 sLLM으로 개념을 확장정리하였다. 개인적으로 1장만큼 강한 인상은 받지 못했다. 어느정도 AI 관련 내용을 계속 학습해 온 사람이라면 익숙한 내용들이었다. 처음 접한다면 굳이 왜 작은 모델인가에 대한 배경 지식을 잡을 수 있을 것 같다.

4장부터 7장까지가 실질적으로 모델을 학습시키면서 최적화하는 과정을 설명한다. 모델을 가져와 데이터를 준비한 후 파인튜닝을 하고, 모델을 압축하고, 추론비용을 줄이는 과정. 코드에 주석이 달려 있지만, 그렇다고 모든 코드의 내부 동작을 한 줄씩 설명해주는 스타일의 책은 아니다. 그래서 중간중간 멈춰서 따로 찾아보거나 GPT 선생님의 도움을 받아야 하는 부분이 꽤 있다. 반대로 말하지면 예를 따라가면서 전체과정을 한번 경험해 보는 것이 목표라면 적당한 것 같다.

8, 9장은 서비스로 구현하는 내용인데, 아직 읽고 있는 중이다.

SLM이나 sLLM을 이야기하다 보면 '잘 튜닝만 하면 작은 모델로도 LLM만큼 좋은 성능을 낼 수 있다'라는 주장도 자주 만나게 된다. 나는 최적화된 sLLM이나 SLM으로 범용적인 추론 능력과 광범위한 지식을 갖춘 LLM에 비할 성능을 얻을 수 있다는 말은 거짓이라 생각한다. 하지만 우리가 수행하는 반복적인 업무중 상당 부분은 LLM의 지능이 아니라 SLM/sLLM으로도 충분히 해결가능한 일이 많다. 이를 합리적으로 해결하는 것이 엔지니어의 몫이라 생각한다. 그래서 LLM으로 할 일과 SLM으로 할 일을 나눠 할당하는 것이 점점 더 중요할 것이라 본다.

이 책은 그 출발점으로 직접 자신의 컴퓨터 내지는 저가의 클라우드 환경에서 해보면서 배울 수 있는 내용을 담고 있는, 현 시점에서 볼 수 있는 몇 안되는 책이라 생각한다. 특정 파인튜닝 기술을 깊이 알고 싶다면 조금 부족한 느낌을 줄 수도 있겠다.

출판사마다 고유의 특색이 있는데, 책만은 소프트웨어 개발 주기 전반에서 알아두어야할 지식에 관련된 책을 잘 출간한다는 개인적인 느낌이 있다. 지난번에 봤던 <AI프로젝트 성공을 위한 체크리스트>와 <개발자 온보딩 가이드>가 그랬다.

이번에 읽은 책은 <다시, 소프트웨어 엔지니어>인데, 너무 큰 기대를 해서일까.. 좋은 책이기는 하지만, 그렇다고 막 감동적이진 않았다. 아무래도 비슷한 류의 책들을 많이 읽었기 때문인 것 같다. 이 책을 읽으면서 계속 들었던 생각인데... <실용주의 프로그래머>를 소프트웨어 개발주기(SDLC)에 맞춰 좀 더 상세히 풀어쓴 느낌이었다. 그래도 개인적으로는 실용주의 프로그래머가 더 좋았다. :)

그냥 이 책이나 실용주의 프로그래머, 개발자 온보딩 가이드 중 한 권을 읽으면 될 것 같다.

• 만드는 애플리케이션이 어떤 문제를 해결하는지, 맥락과 제약조건은 무엇인지, 관련된 문제들은 무엇인지 등 문제 영역을 충분히 생각하는데 시간을 들이자. 
• 엔지니어는 현실적이고 무자비할정도로 실용적이어야 한다. 확장성은 중요하지만, 모든 애플리케이션이 인터넷 트래픽의 3분의 1을 감당해야 하는 것은 아니다.
• 실천법의 가치와 목적을 잊어서는 안된다. 만약 절차만을 형식적으로 따른다면 기대했던 이점을 얻지 못할 가능성이 높다.
• 목표는 최선의 해결책을 찾는 것이지 그것으로 개인의 가지 가치를 가늠하는 것이 아니다.
• 좋은 코드 작성은 지속적인 학습 과정이다. 지름길은 없다. 개발자로서 성장하고 싶다면 코드를 작성해야 한다.
• 다이어그램은 다른 사람들에게 무언가를 전달하는 것을 돕는게 핵심이다.
• 품질은 1회성 행위가 아니라 꾸준한 실천임을 잊지 말자.
• 문제는 반드시 일어나겠지만, 핵심 질문은 그 문제의 가시성을 어떻게 확보할 것인가이다.
• 소프트웨어 엔지니어로서 개발하게 될 가장 중요한 기술중 하나는 코드에 미치는 영향을 따져 근거있는 결정을 내리는 방법이다.
• 효율적인 데이터 접근이란 단순히 빠른 질의를 말하는 것이 아니라 애플리케이션의 전체 데이터 수명 주기를 이해하는 것
• 과거의 경험이 복잡한 상황을 헤쳐나가는데 도움이 되겠지만, 모든 애플리케이션은 저마다 다르다.
• 아키텍처에는 비판적 사고가 필요하다. 아키텍트는 주어진 프로젝트의 핵심 품질 속성을 파악하고 설계가 그 요구사항을 충족하게 만든다.
• 좋은 아키텍트는 프로젝트 기한을 지키면서도 할수 있는 최선의 결정을 내린다.
• 모놀리스는 유지보수가 불가능하다고 종종 비난받지만, 문제는 잘못 구조화된 시스템에 있지 전개 구성 방식에 있지 않다.
• 주의력은 귀한 자원이며 마냥 늘릴 수가 없다. 낭비하지 말자. 모든 것을 읽거나 보거나 들을 수는 없다. 선택해야만 한다.
• 배운 기술에는 각각 유효기간이 있다.개발자 언어를 사업의 언어로 번역하는 것은 연습이 필요한 중요한 기술이다. 청중을 파악하고 그에 맞게 메시지를 조정해야 한다
• 소프트웨어의 사업적 가치를 이해하고 명확히 하는 것도 중요
• 필요한 시간을 들이면 결국 전체 소요시간은 줄어든다.
• 자카르 직조기가 만들어지자 자신들이 알던 방식의 기술이 사라질 것으로 많은 사람들이 예측했다. 그러나 숙련된 장인들은 패턴 디자이너, 기계 운전자, 섬유 엔지니어로 거듭났다. 가장 크게 성공한 직공들은 전통 기술과 새로운 기술을 모두 이해한 이들이었다.
• (AI를 활용하여) 상투적 코드 작성에서 절약된 시간으로, 이제 중요한 전략적 결정들에 집중할수 있다.