본 블로그의 주인장들은 이번 허깅페이스의 르로봇 월드와이드 해커톤의 서울 호스트를 맡았습니다. 너무 재밌었고, 그 과정들과 후기를 남깁니다. 현장은 다큐 형식의 작은 영상을 만들었으니 한번 봐주세요.

계기

저는 LLM 만 하고 있었고, Action 모델은 사실 관심이 없었습니다, 준호는 1년 정도 로봇에 AI 를 넣는 일을 하고 있었죠. 허깅페이스에서 르로봇 플랫폼을 만들고 오픈소스 로봇도 내놓으면서 한번 찍먹 해볼까 라는 생각으로 시도 해봤습니다. 이게 25년 4월 입니다. 처음으로 로봇을 조립하고 학습시키고 일을 시키는 순간은 라이브로 다 남겨놨습니다.

- YouTube

Enjoy the videos and music that you love, upload original content and share it all with friends, family and the world on YouTube.

YouTube

해보니까 너무 재밌더라고요. 다음엔 뭘 해볼까 고민을 하고 있던 찰나. 허깅페이스에서 직접 글로벌로 해커톤을 열고, 각 지역의 로컬 호스트를 모집한다는 공지를 봤습니다. 그래서 지원했죠.

준비

해커톤을 직접 열려고 했는데, 이제 장소가 필요합니다. 사람들이 로봇을 들고 올텐데 이를 설치하고 동작시킬 장소가 좀 커야할 것 같아요. 그냥 노트북만 들고오는게 아니니까요. 제가 마침 이때 휴가여서 도쿄에 있었습니다. 그래서 도쿄에 다른 호스트에게 연락하고 견학을 갔죠.

ロボ☆スタディオン

秋葉原は末広町駅徒歩1分のメーカースペース、作った物は闘わせたり展示したり。

ロボ☆スタディオンロボ☆スタディオン

아주 작은 랩실 정도의 공방 이더라고요, 그래서 정 안되면 나도 그냥 우리집에서 소규모로라도 해야지 라는 생각으로 확정하고 추진했습니다.

주변에 연락을 돌렸습니다, 아주 감사하게도 제 고객 중 한 회사인 SK mySUNI 에서 흔쾌히 장소 대여를 허락해 주셨습니다. 장소를 후원해주신 것이죠.

SK mySUNI 는 장소가 아주아주아주 좋거든요. 덕분에 너무 좋은 환경에서 해커톤을 할 수 있었습니다. 종각역이랑 연결된 그랑서울 건물 꼭대기에 남산뷰, 공간도 넓고, 책상도 조명도 너무 잘 꾸며져 있습니다.

제일 중요한 공간이 확보 되었고, 또 현장이 넓어서 꽤 많은 인원을 수용할 수 있었습니다. 허깅페이스에서는 공간 몇명이나 받을 수 있냐고 물어보더군요. 그래서 일단 50명이라고 잡았습니다. 사실 100명도 받을 수 있긴 했는데, 저희가 직접 통제 가능한 인원을 생각해서 50명을 최대 인원으로 잡고 모집을 시작했습니다.

모집은 저희가 운영하는 유투브에서 홍보하고, 관련 오픈 카톡방에 한번 남겼습니다. 허깅페이스의 월드와이드 해커톤 페이지에도 올라가 있었고요.

LeRobot-worldwide-hackathon (LeRobot Worldwide Hackathon)

Org profile for LeRobot Worldwide Hackathon on Hugging Face, the AI community building the future.

그리고는, 후원을 모집했습니다. 여러 회사들에게 연락했는데, 감사하게도 또 다른 제 고객사인 패스트캠퍼스에서 흔쾌히 후원을 해주셨고, 로봇AI 스타트업인 리얼월드에서도 후원을 해주셨습니다. 덕분에 티셔츠도 제작하고, 오신 분들에게 다과, 야식, 음료 이런 것들을 해드릴 수 있었어요.

특이한 점 하나는 중국의 로봇회사인 agileX 에서 먼저 연락을 주셔서 PiperARM + 그리퍼를 서울 행사의 1등 상품으로 후원해주셨습니다. 처음엔 사기인가? 생각도 들었는데 직접 화상 회의도 하고 한국에 유통사도 있더라고요. 참고로 그 유통사인 위고로보틱스에서도 참가자분이 있었습니다.

티셔츠랑 1등 상품인 로봇이 행사 바로 전날에서야 받을 수 있었어서 고생을 좀 했네요. 금요일 저녁에 퇴근하고, 비 맞으면서 가산디지털단지에가서 딱 1시간 남기고 티셔츠를 급박하게 픽업했습니다.  고생한 기억이 가장 강하게 남는군요.

하나 까다로웠던 점은 현장이 SK 그룹의 보안 사업장 이었기 때문에, 참가자 분들을 직접 연락하고 소속 정보를 받아 등록을 했어야 했습니다. 허깅페이스를 통해서만 알게되어 등록하신 분들한테는 저희가 연락 방법이 매끄럽지 못했던 것이 좀 곤란했었는데 다행히 잘 해결이 되었습니다.

행사 현장

토요일 새벽부터 와서 현장 셋팅하고 참가자분들 모시고, 글로벌 화상 회의 (방송) 셋업하고 정신이 없었네요. 다들 일찍 잘 와주셨고, 건물 앞에서는 우리 채널의 PD인 lonzi 가 잘 안내 해줘서 문제 없이 행사를 시작할 수 있었습니다.

행사를 시작하고, 참가자 분들이 셋업을 시작했습니다. 허깅페이스의 르로봇 플랫폼은 SO ARM 101 이라는 오픈 소스 로봇을 입문으로 합니다. 대부분 이 로봇을 조립해 오거나, 아니면 오셔서 조립할 거라고 생각을 했는데... 시작하자마자 놀랐습니다. 이런 난생 처음 보는 로봇을 보았기 때문이죠.

거대한 로봇입니다. 처음 첨부한 유투브 영상에 움직임도 찍혀있는데, 아주 안정적입니다. 기계적으로 그냥 우월합니다. 물론 우월한 로봇들은 이 세상에 많죠. 그런데 이 로봇이 허깅페이스의 오픈소스 플랫폼과 호환도 되고 학습시킨 AI 모델도 돌릴 수 있다는게 놀라웠습니다.

만드신 분은 시각예술작가 윤지현 교수님이십니다, 당시에는 시각예술작가라고만 말씀을 주셔서 몰랐었는데 제 모교인 연대 교수님이시더라고요. 밑에서 더 이야기 하죠.

어쨌든 저는 사전에 기획한대로 처음 조립을 해보시는 분들과 함께 조립세션을 진행했습니다.

2팀을 제외한 모든 팀분들은 로봇을 이미 조립해서 오셨습니다. 2팀과 함께 로봇을 조립했고요. 이 로봇이 SO ARM 101 입니다.

GitHub - TheRobotStudio/SO-ARM100: Standard Open Arm 100

Standard Open Arm 100. Contribute to TheRobotStudio/SO-ARM100 development by creating an account on GitHub.

GitHubTheRobotStudio

조립 세션을 위해 무급 스태프이자 제 여자친구인 기릿님 (제조업 엔지니어) 에게 미리 조립을 시켜봤습니다.  덕분에 조립 세션을 잘 리드해 주었고, 오후에 모두 조립이 잘 끝났습니다.

혹시 몰라서 직접 3d 프린터로 여러 부품들을 찍어왔는데요. 아주 다행이었어요. 사실 조립 세션에 필요할 거라고 생각했는데, 멀쩡한 로봇들이 좀 부러지더라고요.

허깅페이스와의 글로벌 소통도 재미있었습니다. 전세계의 모든 로컬 지부들이 다 들어와서 줌 회의를 했고요. 허깅페이스의 르로봇 리더인 remi cadene 도 있었고요. 아마 참가자 분들은 작업하시느라 정신 없으셨을텐데, 운영진인 저희는 그래도 오다가다 소통을 해서 재미있었네요. 직접 방문했었던 도쿄의 온라인으로 무라타상도 봤고요, 해당 온라인 회의는 허깅페이스의 공식 유투브 채널에서 계속 생중계 되었습니다.

호스트인 JC (준호) 와 PD lonzi (진호) 는 돌아다니면서 모든 팀들의 인터뷰를 했습니다. 저희가 궁금했어요. 참가자분들은 어떤 분들이고, 왜 오셨고, 어떤 목표를 가지셨는지 잘 알 수 있었던 것 같아서 좋았습니다.

야식 & 밤샘

운영진인 저희는 총 4명이었기에 2명씩 교대를 했습니다. 저는 밤 10시 야식 쉨쉑을 책임 졌는데요. 그 때 까지는 제가 가능한 만큼 돌아다니면서 많은 팀들의 어려움을 해결해 드리고자 노력했습니다. 어쨌든 저는 먼저 해본 경험이 있고, 또 LLM 을 오래했기 때문에 GPU 나 이런 것이 좀 익숙했습니다. 많은 분들이 저희 예상과는 다르게 LLM 쪽 보다는 로봇 쪽에서 오셨어서 이런 부분에 도움을 드릴 수 있었습니다. 사실 저는 로봇의 기계적인 부분은 전혀 모르거든요... 오히려 많이 배웠죠.

후원 받은 금액으로 야식과 음료 (핫식스 + @) 는 넉넉히 챙겨드릴 수 있었습니다. 모든 식사를 다 챙겨드릴 수는 없어서 아쉬웠네요.

저는 새벽 2시쯤에 교대를 했고요, 절반 정도는 그래도 막차 시간쯤해서 쉬러 가셨던 것 같고, 절반정도는 정말 밤을 새고 작업을 하셨던 것 같아요. 아무래도 GPU 에 학습은 돌려 놓고 쉬는게 효율적이긴 하죠.

저는 다음날 오전에 돌아왔습니다.

글로벌 라이브 데모!

재밌는 사건이 하나 발생 했습니다. 허깅페이스에서 Day 2 낮에 갑자기 시간대가 맞는 지역별로 온라인 데모를 하겠냐고요. 아시아 지역이 시간이 제일 빨랐기 때문에 아시아 끼리 데모를 준비했습니다, 현장에서 당장 데모가 가능한 팀, 글로벌에 어필을 하고 싶은 팀을 찾으러 다녔습니다.

다행히 씬그립과 형님들 팀에서 데모가 가능해서 먼저 하기로 했습니다, 당장 데모가 가능할만한 팀이 한 팀 (112 팀) 더 있었는데, 점심식사를 가서 전화를 드렸습니다. 좀 급박해서 우선 시간이 안될 것 같다고 결정이 났습니다.

글로벌 데모가 너무 잘 되었고 포포먼쓰까지 완벽했습니다, 중국 동관에서 먼저 데모를 했는데 비교해서 너무 화질도, 음질도, 데모도 완벽했기에 글로벌 수상도 할 수 있겠다는 생각이 처음으로 들었던 것 같아요. 사실 글로벌에서 다른 지역이 얼마나 잘하는지 전혀 감이 없었거든요.

다른 지역들이 데모를 하던 중, 112팀이 식사하고 돌아왔고 다행히 여유가 있어서 112팀도 데모를 했습니다.

112팀도 데모가 너무 잘 되었고, 사이에 진행했던 다른 지역에 비해서 너무 잘 되었습니다. 5~8팀 정도 발표를 했었던 것 같고, 도쿄 1팀과 서울 2팀만 괜찮았었던 것 같네요.

글로벌 수준이 고만고만하구나 라는걸 느끼기도 했습니다. 아시아 &. 오세아니아 지역만 한 것이긴 하지만요. 유럽이나 북미에는 또 고수들이 있겠죠.

서울 지역의 마무리 피치

보통의 해커톤은 현장에서 피치를 하고 심사를 하고 마무리하는 것으로 알고 있습니다. 그런데 이번 해커톤은 온라인으로 글로벌하게 진행해서 영상을 만들어 올리는 것이 제출이었습니다. 그리고 지역별로 시간이 달라서 시작과 끝나는 시간이 지역마다 달랐죠. 글로벌 제출은 제출이고요.

서울 지역내에서는 따로 우리끼리 피치를 하기로 했습니다. 어쨌든 저희는 현장에 모여있고, 실물 로봇을 볼 수 있고, 참가자들끼리 의견을 공유하는 것이 좋은 의미가 될 것이라고 생각했습니다. 서울의 1등에게 따로 줄 상품도 있었고요.

여기서 부터는 사실 영상을 봐야하는데요.

씬그립과 형님들

핸드폰으로 색깔을 표기하면 그 색깔의 판을 집어 꼽는 데모입니다. Pick and place 인데, 색으로 멀티태스킹을 하는 데모죠. 그리고 집어야할 손잡이랑 넣어야할 핀이 꽤 작습니다. 정교하기도 해야하죠.

너무 잘 되었습니다. 성공률이 체감상 90퍼센트 정도? 이렇게 잘 되는 것은 처음 봤어요. 로봇을 자세히 보시면 그립과 카메라가 자체제작이니다. 씬그립 이라는 회사에서 직접 만드신 것입니다.

팀 소개를 잠시 하자면, 삼성중공업 에서 오래 일하셨던 전직장 동료분들께서 팀으로 오셨고요. 현직으로는 씬그립 창업자이자 대표님, 그리고 한남대, 한국 폴리텍 대학의 교수님들 이십니다.

ACT, 50에피소드, 60k training 모델입니다.

모두가 확신을 가지고 갈 수 있었어서 제일 좋았습니다. 이 정도로도 되는 구나. 다들 돌아가셔서 무언가 시도하실 때 확실한 성공사례를 참조해서 공격적으로 투자할 수 있으니까요.

ACT 모델인데도 vision input으로 멀티태스킹 하는 것도 증명했고요.

첨언하자만, 현장에서 GROOT 1.5 도 학습을 시도하셨거든요. 이걸 성공하는 것을 끝까지 못 한게 아쉬웠습니다. 클라우드로 GPU 대여하는 것도 알려드리서 바로 결제하셔서 학습도 돌리셨는 데, 아마 시간이 모자랐던 것 같아요. 조금만 시간이 더 있었으면 다른 실험 결과도 확실히 알았을 텐데 하는 아쉬움이 있었습니다.

위 사항들을 고려하여 서울의 1등으로 선정하였습니다. 압도적인 성공률의 데모와 커스텀 하드웨어의 기여도, 모두 다 1등으로서 모자람이 없었던 것 같아요.

현장이 마무리 되고 한국 시간 기준 3일 정도 후에 글로벌 수상이 완료 되었는데요.

MOS

모기/나방을 잡는 모델입니다. MOS 팀의 데모도 엄청 잘 됩니다. 수상 결과 부터 말씀드리자면 글로벌 TOP 9을 차지했습니다.

MOS 의 경우는 커뮤니티에서 조직된 4명이 모인 팀입니다. 저희가 편한 운영을 위해서 오픈카톡방을 미리 개설했습니다. 허깅페이스는 공식적으로 디스코드에서 대회 공지와 소통을 하지만, 한국인 특성상 디스코드가 그리 활성화 되어있지는 않으므로 카톡방을 만들고 가능하면 다들 들어오시라고 했습니다. 여기서 참가자분들끼리 자발적으로 구성 하신 팀입니다. 특히 최재훈 님께서 적극적으로 소통을 너무 잘 해주셔서 협업의 위대함(?) 같은 것을 배울 수 있었습니다.

오셔서 2 세트 조립부터 시작하셨습니다. 저는 개인적으로 1모델 바이메뉴얼 (양손조작) 을 추천 드렸는데, 이를 시도해 보았으나 아쉽게도 플랫폼의 지원 문제로 성공을 하지는 못했습니다. 아마 시간이 더 있었으면 되었을 텐데 아쉬웠습니다.

모기를 잡는 모델, 모기를 집어서 버리는 모델 이렇게 2개로 2로봇 조작을 데모로 하셨습니다. 조립부터 시작해서 여기까지 도달 하신 것이 참 대단하다고 느꼈습니다.

중간중간 상황에 맞게 전략을 수정하면서 시간내에 output 완성에 도달 하는 과정까지 협업, 소통, 분업 다 너무 대단했던 것 같아요.

메트라이브, 서울대학교, 위고로보틱스, 삼성전자 이렇게 각각 다른 곳에서 모인 분들이 이렇게 잘 해낼 수 있었다는 것이 놀라울 따름입니다.

인공지능 선풍기

이 팀도 조립부터 시작해서 글로벌 Top 25 를 수상한 팀입니다. 부채질을 만들었습니다.

우선 현장이 너무 더웠어요. 날이 더웠고요. 에어컨이 잘 안 나왔습니다. 처음엔 에어컨이 주말이라 가동이 안 되어 있었고, 가동을 시켜주시긴 했는데 저녁 6시까지만 나왔습니다. 그래서 부채질을 만드셨는데, 현장에서 우리가 직면한 문제를 바로 해결하는 것을 수행하신 것이 아주 인상적이었습니다.

팀원 분들은 창업자 분들이셨는데, AI 도 로보틱스도 하셨던 분들이 아니라서 정말 처음부터 시작하셨습니다. (코딩은 두분 다 할 줄 아셨습니다.) 토요일 아침부터 일요일 오후까지 정말 처음부터 쭉 다 2명이서 해내신 것이 대단하다고 생각이 들었어요.

중간중간 모터라던가 데이터 수집이라던가 학습이라던가, 다양한 문제를 직면 했는 데, 모든 문제를 순차적으로 침착하게 해결해 나가시는 것을 보고 대단하다고 느꼈습니다. 누구나 지칠 법한 순간들이 많았는데, 포기 않고 결국 잘 해결 해내시더라고요. 이런 사람들이 창업자들이구나 싶었습니다.

Lebotica

개인적으로 가장 기대했던 팀 입니다. 가장 먼저 참가 신청하고, 하고 싶은 것도 명확하고, 이미 많은 것들을 해봤었던 팀이기 때문이죠. 로봇도 SO ARM 101 이 아니라 koch 로봇을 가져왔습니다. 참고로 koch 로봇은 작지만 더 고급 (?) 모터를 쓰는 로봇입니다.

로봇을 가지고 온 싱동님은 네이버 추천팀에서 RL 을 연구하는 분이시고, 이를 로봇에 활용해보려고 하신답니다. 링크드인 에 가면 많은 소식들을 볼 수 있어요.

현장에서는 팀원분들과 smolvla 를 도전 했고요, 완벽하지는 않았지만 배운점이 많았습니다. 우선 smolvla 이야기부터 하죠.

SmolVLA: Efficient Vision-Language-Action Model trained on Lerobot Community Data

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

허깅페이스는 이번 해커톤을 앞두고 smolvla 를 발표합니다. 작은 vla 입니다. 재밌는 점은 HugginFace 에 올라온 SO ARM 을 기반으로 한 커뮤니티 데이터로 학습했다는 점입니다.

Lebotica 팀은 smolvla 를 파인 튜닝해서 prompt로 task 를 주면 그에 맞는 task 를 수행해내는지 확인 하는 일을 했습니다. 아마 이번 해커톤 참가자들이 가장 궁금한 점일 것이에요.

과연 smolvla 는 파인튜닝하면 얼마나 잘 될까? 데이터는 얼마나 필요할까? 학습은 얼마나 해야되나?

지금 시점 (해커톤 행사 기간) 에 모두가 궁금한 이 질문에 대한 답을 탐구 했습니다.

결과를 요약하면, 프롬프트로 준 명령을 이행 하는 것 됩니다. 왼쪽위 초록 공을 집으라 하면, 그 공을 집어요. 현장 데모 상황에서는 공을 완벽하게 잡지는 못했지만, 명령은 잘 이행했습니다. Failure Recover 하는 데이터가 충분하고 학습이 되었다면 무조건 성공했을 거에요. 시간 문제 였을 뿐.

쌤쌤

실물을 보자마자 놀란 압도적인 로봇입니다. 위 영상은 작가님 채널을 링크합니다. 그냥 안정적이고 반응도 빠르고 우월합니다.

로보티스의 모터와 오픈매니플레이터를 개조해서 만드셨다고 하셨습니다. 로보티스 사의 모델들이 SO ARM 에서 사용된 Feetech 사의 모터와 분쟁 같은 것이 있다고만 알고 있었는데요... 저는 개인적으로 모터에 대해 잘 모르다보니 판단할 능력이 되지는 않습니다.

ROBOTIS e-Manual

e-Manual wiki

ROBOTIS e-ManualYour Name

작가님께 모터에 대해서 많이 배웠습니다, Lebotica 팀의 로봇도 그러하고 로보티스의 다이나미셀 모터가 비싸지만 더 다양한 스펙과 좋은 기능들을 가지고 있다고 합니다. 실물로 보고 더 확실하게 느꼈고요. 저도 로보티스의 모터에 대해 관심을 가지게 되었고 한번 살펴볼까 생각 중 입니다.

현장에서의 데모는 고양이 표정을 보고, 도장을 골라서 찍고 고양이를 괴롭히는 것 까지를 태스크로 보여주셨습니다. 중간 과정에서는 소리에 따라 고양이 표정을 바꾸는 것 까지 구현을 시도하셨고요. 태스크가 복잡하다 보니 연결 동작을 모두 완수하기는 어려웠지만, 매우 인상적이었어요.

예술 작가 분들이라 그런지 엔지니어인 우리의 관점과는 다른 의견들을 많이 내주셨던 것이 인상깊었습니다. 로봇만의 특별한 움직임을 보고 싶다던가. 허깅페이스 데이터에 독을 풀고 싶다던가...

참 세상은 넓구나 라는 생각이 새삼 들었네요.

Team 112

앞서 글로벌에 완벽한 데모를 자랑했던 112 팀의 데모입니다. 서랍을 열고, 사탕을 집고, 서랍을 닫고, 사탕을 컵에 떨구는 것 까지. 꽤 복잡한 태스크 였는데 완벽하게 수행을 했습니다.

그런데! 오후 1시 글로벌 발표에서는 잘 되었던 모든 것이 오후 5시 서울만의 현장 데모에서는 잘 안되었습니다. 달라진 것이 없는데요...

이로써 또 배운 것이 있었습니다. 112 팀에서는 여러 문제를 제보해주셨는데요, 스크류가 헐거워진다던가 하는 여러 예상 문제점들을 지적해 주셨습니다. 르로봇 구버전의 메모리 누수 문제도 있었고요. 확실한 관찰 결과는 같은 환경 같은 모델이 시간이 지났는데 갑자기 안된다는 것. 저는 개인적으로 Feetech 모터의 과열과 같은 요소가 있었을 것이라고 생각합니다. 참여자 모두가 재현성에 문제가 있을 수 있음을 알아갈 수 있는 시간이었습니다.

DR4R

DR4R 팀의 데모는 조금 특별했습니다. 우선 태스크는 젠가 블럭을 집는 pick and place 아주 전형적인 일입니다. 그렇지만 이 팀은 모델이 특이합니다.

Consistency policy 를 직접 구현해서 학습을 시키고 테스트를 했습니다. 이번 해커톤 시점에서 많이 활용되고 있는 모델은 크게 3가지 입니다. ACT, Diffusion Policy, SmolVLA. 다른 VLA 들은 사이즈가 커서 30시간안에 동작시키기는 쉽지 않죠.

이 중 Diffusion 은 N 번의 inference 를 통해 action 을 만들어내는 느린 단점이 있습니다. 이를 개선한 Consistency 모델을 직접 구현해서 테스트를 하셨습니다. 한 번의 inference 로 생성이 되기 때문에 50배 정도 빠르다고 말씀을 해 주셨고, 아쉽게도 이렇게 구현된 Consistency 모델은 실제 데모가 잘 동작하지는 못했습니다. 150 에피소드를 모았지만요. 실패 원인에 대해서는 탐구가 더 필요해 보입니다.

코끼리

시작부터 로봇이 부서지는 악재를 겪은 코끼리 팀입니다. Lebotica 팀과 같이 SmolVLA 학습을 시도 했고요, 10 에피소드 1000 스텝 학습 까지 도달하셨는데, 태스크 수행은 실패했습니다. SmolVLA 는 이미 pretrain 이 많이 되어있어서 적은 튜닝만으로도 될까 싶었으나 어림도 없었습니다. 약 30시간이라는 시간 제한내에 도달하기는 쉽지 않았던 것 같습니다.

라이브 데모까지 도달하지는 못했으나 depth 카메라 까지 동원하여 밤새 노력해주신 서울아파트설치팀, 캐스터네츠로 음악을 시도한 칠링팀 너무 아까웠네요. 촬영본 업로드를 원치 않으셔서 자세히는 언급하기가 어렵지만 야바위를 도전 했던 체커보드 팀도 멈추지 않는 시도가 인상 깊었습니다.

결과 요약

서울 지역의 행사는 축제 처럼 잘 마무리가 되었고, 모든 참여자 분들이 자유롭게 질답을 나누는 것을 보면서 다 같이 현장 데모를 하길 잘했다는 생각이 들었습니다. 모두가 좋은 정보를 공유하는 시간이 되었던 것 같아요.

결론적으로는 전 세계 44개국에서 3,000명 이상의 참가자가 함께했으며, 서울 로컬 참가자들이 글로벌 Top 8, 9, 25위에 오르는 성과를 거두었습니다.

참고로 top 30 까지 허깅페이스가 직접 뽑고 상품을 줍니다. top 10 도 허깅페이스가 뽑으나 이 안에서는 참가자 투표를 진행했습니다. 평가를 영상으로 했기 때문에 서울 지역에서 영상에 투자할 시간이 조금 만 더 있었다면 더 수상을 많이 할 수도 있지 않았을까 싶습니다. 다른 수상자들을 보니 저희가 상향 평준화가 되어있더라고요.

모든 수상자의 데모는 공지 페이지에서 보실 수 있습니다.

Winners - a Hugging Face Space by LeRobot-worldwide-hackathon

This app shows the winners and their videos from the LeRobot Worldwide Hackathon. It lists the winning teams with their rankings and provides links to their demo videos and datasets.

a Hugging Face Space by LeRobot-worldwide-hackathon

국내 기준으로는 아래와 같이 전통 언론에 기사도 났습니다.

“AI가 팔을 얻었다” - KMJ

“AI가 말만 잘하는 시대는 끝났다. 이제는 움직이고, 만지고, 배운다.”지난 14~15일, 서울에서 열린 허깅페이스(HuggingFace)의 ’LeRobot W

KMJ신주백 기자

외부적으로도 좋은 결과들이 도출 되었고, 내부적으로도 참가자 분들이 많은 것들을 얻어 가실 수 있었던 것 같아서 보람 찬 행사 였습니다.

기타

저희가 주최하면서 기술 외적으로 관찰한 재밌었던 점 하나만 꼽자면 식음료 였습니다. 후원 받은 금액 내에서 저희는 음료와 다과, 간단한 식사들을 준비했습니다.

첫날 아침 커피와 모카번, 첫날 밤의 쉐이크쉑 햄버거, 둘째날 아침의 고단백 빵 (스콘, 쿠키, 파운드케익). 그리고 충분한 량의 음료 (탄산수, 제로콜라, 핫식스), 각종 과자 N 종 세트.

신기한 점은 과자가 많이 남았고요, 고단백 빵은 빠르게 품절이 났습니다. 다른 행사 주최 하셨던 분들에게 문의 결과 과자는 충분하다고 생각해도 항상 모자르다고 들었는데요...

연령대가 어릴 수록, 고학력자 일 수록 과자 선호도가 떨어지고 다이어트 (고단백) 제품이 선호도가 높다는 신기한 소문을 들었습니다. 정말 그랬나 싶네요.

VLA 와 Physical AI, 미래 방향성

마지막으로 제가 생각 하는 미래를 이야기 하고자 합니다. 요즘 Physical AI 라는 키워드가 바이럴이 되고 있는데요, 왜 그럴까하면 과거에 안되던 것이 LLM 이 VLA 로 확장 되면서 될 것 같기 때문이겠죠.

Physical AI 라는 용어를 그냥 단순하게 세상과 물리적으로 상호 작용하는 AI 라고 정의 할 수도 있겠지만, 시대적 맥락을 고려하면 "World knowledge 를 잘 아는  Action Model 기반의 Embodiment 동작" 이라고 정의할 수 있겠습니다. 이것이 과거의 로보틱스 AI 에서 안되던 것이죠. 요즘 우리가 AI 라고 하면 선형 회귀를 떠올리지는 않는 것 처럼요.

새로운 Physical AI 는 빨래개기와 같은 작지만 까다로웠던 작업부터 다양한 task 를 모두 소화 하는 일반화 로봇을 가능하게 할 것이에요. 물리적인 능력보다는 지능에 초점에 맞춰져 있죠.

단순하게 생각하면 LLM 이 똑똑해 졌으니 Action 도 잘 할 것이고, Physical AI 도 잘 되겠지라고 생각할 수 있겠지만 그렇지 않습니다. LLM 이고 멀티모달리티고 잘 되는 이유가 무었인가요. 한마디로 요약하면 Scaling 입니다. 방대한 데이터를 모두 학습했기 때문인데, 문제는 Action 은 데이터가 없습니다. 글이나 이미지/영상이 아니죠.

허깅페이스의 SmolVLA 는 이러한 Action Scaling의 문제를 democratizing 으로 해결하고자 하는 첫 걸음 입니다. 로봇을, 플랫폼을 오픈소스화 하고 해커톤을 열고 사람들이 사용해서 데이터를 올리고 이걸로 다시 학습하고. 선순환 구조죠. 이번 해커톤을 통해 다양한 데이터가 또 쌓였을 것이고, 이걸로 다음 VLA 를 만들겠죠. 더 똑똑해질 것이고, 사람들을 더 사용하고, 데이터는 더 쌓이겠죠.

좋은 방향성이지만 사실 저는 많이 부족하다고 생각합니다. 사람이 데이터를 모아야하니 아무리 많은 사람들이 해도 한계가 있습니다.

Nvidia 는 world model 을 기반으로한 Digital Twin, Digital Cousin 에 초점을 맞추고 있는데, 이 방향도 좋습니다. 너무 길어져서 이쪽 방향은 본 포스트에서 생략하겠습니다만, 허깅페이스의 방향과도 시너지가 날 요소가 충분히 있습니다.

제 의견을 요약하자면, 아직 한참 남았어요. 빠르게 다가오지는 않을 것이에요. 데이터가 준비가 안되어 있어서요. 그래도 지금의 LLM 이 코딩을 정복하는 것 처럼 physical AI 가 세상을 곧 변화시킬 거에요.

마지막 광고

이번 해커톤을 계기로 운영을 위해 오픈 카톡방을 만들었는데 참가자 분들께서 서로 정보 공유와 유의미한 소통이 오가는 것을 보면서 앞으로 좋은 르로봇 커뮤니티가 될 것 같다고 생각했습니다. 관심있으신 분들은 오셔서 좋은 대화 나누면 좋겠습니다.

허깅페이스 르로봇

#vla #lerobot #ai #robot #aloha #soarm100 #huggingface

• 1편 - 사전 학습 (Pre Training)
• 2편 - Supervised Fine Tuning
• 3편 - Reinforcement Learning

Reinforcement Learning

Pretrain, SFT 에 이어서 세번째 단계는 Reinforcement Learning (RL, 강화학습) 입니다.

비유를 해보자면, pretrain은 그냥 책을 읽는 것이고요, SFT는 예제 문제와 이미 작성된 해설을 보는 것입니다. RL 은 해설이 없는 문제를 직접 풀어보는 것입니다. 어떻게 풀든 방법에 자유도가 있죠. 그냥 풀어보는 것입니다.

LLM 에게 문제를 풀어보도록 하기

SFT 에서 풀어봤던 수학 문제를 Llama-3.2-3B-Instruct 에게 여러번 풀려봤습니다.

맞았습니다! 다시 풀려볼까요?

이번엔 틀렸습니다.

이렇게 틀릴 수도 있고, 맞을 수도 있어요. 풀이도 제 각각이죠. 다양하게 풀어보고 정답을 채점을 시켜보면, 어떤 방식으로 풀어보는 게 잘 풀리는지 감을 잡을 수가 있습니다.

그림으로 보면 이와 같습니다. 하나의 프롬프트에 대해서 다양하게 풀어보고요, 그중에 맞는 놈도 있을 거고 틀린 놈도 있을 거에요. 맞는 놈을 기준으로 보상을 주고 학습 시키는 것이 강화학습입니다.

여기서, 1. 맞는 놈들 중에 최선의 답을 찾아야하고요, 2. 맞는지 틀리는지 정답을 매길 수 있어야 합니다.

SFT 는 풀이 방법까지 정해주는 것이라면, RL 은 풀이 방법은 자유인 점이 다릅니다. 인간이 생각하지 못했던 풀이에 도달할 수 있기 때문에 더 포텐셜은 더 좋습니다.

DeepSeek-R1 의 Reinforcement Learning

이 방법을 적극적으로 활용하고, 성공했고, 꽤 많이 공유한 모델이 DeepSeek-R1 입니다. 미국 증시 시장에도 아주 큰 영향을 끼쳤죠?

참고로 미국 증시에 큰 영향을 끼친 요소는 크게 두가지 입니다.

1. DeepSeek-V3 라는 꽤 좋은 베이스 모델을 100억 안쪽의 비용으로 성공 시켜서
2. DeepSeek-R1 이라는 Reasoning 모델을 RL 로 성공 시켜서

여기서는 후자에 대해 이야기 하겠습니다.

DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning

페이퍼 의 제목 부터 Reinforcement Learning 입니다. 성과를 요약해보겠습니다.

OpenAI의 o1 이 24년에 나왔습니다. Reasoning 모델로 생각을 오래오래 하면서 어려운 문제 (주로 수학이나 코딩) 를 잘 풀어내는 똑똑한 친구입니다. 이 모델은 RL 로 만들었다고 공개 했는데, 어떻게 만들었는지 비공개였습니다. DeepSeek-R1 공개 시점에서는 사실상 최고의 모델이었죠.

이때 DeepSeek-R1 이 나왔고, o1 이랑 꽤 비슷한 수준의 모델이고, 비슷한 방식의 Reasoning 모델 입니다. 그리고, 어떻게 만들었는지 공개했죠. 이제 모든 사람들이 알게 된거죠, 저렇게 만들면 되는 구나!

디테일한 내용들은 저희가 다룬 내용이 있으니 참고하시고요, 자세한 디테일은 여기 포스트에서는 생략하겠습니다.

DeepSeek-R1의 페이퍼로 돌아와서, 재밌는 지점들을 보겠습니다.

위에서 설명한 대로 RL 를 합니다. 다양하게 문제들을 풀려보고, 정답을 맞춘 결과물에 대해 보상을 주고 학습하고, 쭉 반복하다보면...

아래와 같이 학습을 반복할 수록 평균 대답 길이가 늘어나요. 토큰을 많이 사용하고, 연산을 많이 사용하면서, 풀이를 중얼중얼 하면서 문제를 풀어낼 수록 더 정답률이 올라가는 것이죠. 이것이 Reasoning 모델의 탄생입니다. 알아서 생각하는 시간을 더 길게 가져가게 됩니다.

통계적인 부분말고도, 학습 중간 과정에서의 모델 output 을 관찰해보면 다음과 같은 "aha moment" 를 볼 수 있습니다.

알아서 답변을 하다가 본인이 틀린 지점을 찾고 다시 해결하는 과정이죠. 사람과 비슷하죠? 저렇게 하라고 알려주지 않았는데, RL 만 했을 뿐인데, 알아서 aha moment 가 생긴다는 것이 신기하긴 합니다.

궁금하신 분들은 https://chat.deepseek.com/ 에 가셔서 가입하시고 "think" 버튼을 누르고 써보시면 저러한 생각 과정을 다 볼 수 있습니다. 참고로 OpenAI o1 같은 경우는 생각 과정을 숨겼습니다. API 사용단에서도 reasoning 토큰을 받아볼 수 없고, chatgpt 서비스에서는 생각 과정을 재가공해서 사람들에게 일부만 보여줍니다.

deepseek 서비스가 개인 정보 관련하여 우려가 되시는 분들은 모델만 다운받아서 직접 돌려보시는 방법도 있습니다.

AlphaGO 에서도 봤던 RL의 효과

그 유명한 알파고도 RL 을 사용했습니다. 이건 제가 9년전 대학원생 시절에도 본 블로그에서 원리를 포스트한 바 있는데요.

알파고(AlphaGo)가 바둑 두는 방법

구글의 딥마인드(DeepMind)에서 만든 deep learning 기반 바둑 프로그램(?) 알파고(AlphaGo)가 오는 3월 9일 부터 15일까지 이세돌 9단과 경기를 가진다. 장안의 화제라 나도 궁금해서 한번 찾아보았고, 이를 공유하고자 이 글을 쓴다. 이 글의 내용은 Nature에 실린 알파고 논문을 기반으로 작성하였고, 내 수준이 딸려서 잘못 이해하고 쓴 내용도 있을

sudormrfpark jong hyun

제가 무려 2016년 3월에도 비슷한 평가를 했네요.

알파고도 DeepSeek-R1 과 마찬가지로 통계적인 면과 하나의 사례를 통해 RL 의 효과를 보겠습니다.

알파고 제로 페이퍼 에서 발췌해왔습니다.

알파고도 버전별로 계속 진화를 했는데요. AlphaGo Lee 가 이세돌과 붙었던 "그 알파고" 입니다. 대략적으로 비유하자면 인간 최고수 수준 이라고 볼 수 있겠습니다. Supervised Learning은 고수들의 기보를 보고 배우는 것인데요 이세돌 수준을 넘을 수 없습니다. 반면 Reinforcement Learning 을 도입하면 인간 최고수 수준을 뛰어 넘을 수가 있죠.

RL을 도입해야 인간 최고수 기보에서는 찾을 수 없었던 새로운 좋은 방법들을 찾아낼 수 있다. 이 내용이 핵심입니다.

실제 이세돌과의 대결에서도 이런 순간이 보입니다. "Move 37" 이라고 불리는 순간인데요 짧은 영상을 첨부하니 한번 보시면 좋겠습니다, 참고로 이 영상은 알파고 다큐영상의 일부인데 2시간 정도 되는 아주 볼만한 다큐입니다.  지금은 무료로 유투브에서 보실 수 있습니다.

바둑 전문가들이 모두 알파고의 한 수에 놀랍니다. 이세돌도 보고 의아해하죠. 인간이라면 절대 두지 않을 수 인가 봅니다. (저는 바둑을 잘 몰라서...) 아무튼 이런 수가 SFT 로는 나올 수 없는 수 입니다. 인간 고수들은 몰랐던 방법이고, RL 로 알파고 알아서 찾아낸 수 입니다.

요즘은 사람들이 알파고를 보고 따라 바둑을 배운다고 하죠.

RLHF (Reinforcement Learning by Human Feedback)

대표적인 Reinforcement Learning 방법 입니다. 세간에는 GPT4가 다른 모델들에 비해 똑똑한 이유로 알려져있죠. 앞서 예시를 든 수학 문제 같은 경우는 정답이 있어서 뭐가 맞은 대답인지 쉽게 평가가 됩니다. "유머"를 예시로 들어보죠.

"유머"는 정답이 없어요. 다양한 유머를 만들게 한 다음에 웃긴 거를 골라서 그 방향으로 보상을 주고 RL 을 해야합니다. LLM 이 만든 다양한 유머들을 사람들이 다 평가해야하는데, 그게 문제죠.

그래서 OpenAI 가 한 방법!

사람의 평가를 흉내내는 Reward Model 을 또 만들어 버립니다

실제 사람의 평가 점수와 비슷하게 평가를 내려줄 수 있는 reward model을 만들 수 있다면! RL 를 쭉쭉 돌릴 수가 있죠. 당연한 이야기이지만 좋은 reward model을 만드는 것이 어렵습니다.

RLHF 의 장점은 RL을 모든 도메인으로 확장할 수 있다는 점 입니다.

수학, 코딩 처럼 명확한 답이 정해져 있지 않은 유머나 시를 작성하는 것, 이런 행위들에도 RL 을 적용할 수가 있어요.

그리고 사람은 "좋은 시를 써!" 라고 하는 것보다 "이 시들 중에서 좋은 거 순서대로 나열해!" 를 훨씬 잘 합니다. 그래서 단계적으로 발전이 가능하죠. 카파시 선생님은 이걸 "discriminator - generator gap" 이라고 하시네요.

RLHF 의 단점은 RL 이지만 포텐셜이 RL 이 아니라는 점 입니다.

LLM 입장에서는 reward model을 뚫기만 하면 됩니다. reward model은 사람을 시뮬레이션 하는 것이라 완벽하지가 않아요. RLHF 를 돌리다보면 LLM 이 생각보다 reward model을 너무 금방 잘 뚫어버립니다.

계속 학습을 시키다 보면, "시를 써봐!" 했을 때 "the the the the the" 이런식으로 헛소리 하게 됩니다. 왜냐면 reward model 이 그게 좋다고 했거든요. 수만가지의 가능성 중에 reward model 이 실수로 좋다고 한 것을 찾아서 그대로 학습해 버립니다.이 문제는 과거의 GAN 에서도 있었던 문제입니다.

그래서 RL 이지만 포텐셜이 열려있지 못해요. 학습을 하다보면 좋아지다가 갑자기 망가집니다. 학습을 하다가 중간에 멈춰야 합니다. 안 뚫리는 좋은 Reward model 만들어야 하는데 너무 어렵습니다.

(참고) RLHF 방법이 PPO (Proximal Policy Optimization) 인데, 이 방법이 너무 어려워 DPO (Direct Preference Optimization) 기법이 대안으로 가장 많이 사용됩니다. 이 방법에 대한 내용은 본 포스트에서는 생략합니다.

정리

여기까지 LLM 의 학습 방식과 동작 방식에 대해 길~게 알아보았습니다.

tokenizer 부터 pretrain, SFT, RLHF 까지 보았네요. 저 개인적으로도 진짜 pretrain을 바닥부터 해본 경험은 없었기에 Fine Tuning 단계부터만 알고 있어서 정리하며 배운게 많았습니다.

Pre-Train도 한번쯤은 직접 해보고 싶다는 생각이 드네요. 기회되면 조만간 한번 해보고 공유하겠습니다.

더 디테일하게 들어가면 효율적으로 학습하기 위한 PEFT (Parameter Efficient Fine Tuning), 그 중 가장 많이 쓰이는 LoRA (Low Rank Adaptation), 그리고 위에서 언급했던 DPO (Direct Preference Optimization), 용도에 따라 필요한 CPT (Continued Pre Training), 실전에 들어가면 알게될 jinja 템플릿이나 Quantization 을 이용한 GPU 메모리 관리 등 다룰게 많이많이 있습니다. 차차 하나씩 다뤄보면 좋겠습니다.

기타 유용한 자료들

• LMSYS Arena
• Buttondown AI News
• Hyperbolic
• HuggingFace

• 1편 - 사전 학습 (Pre Training)
• 2편 - Supervised Fine Tuning
• 3편 - 강화 학습 (Reinforcement Learning)

Supervised Fine Tuning

Post Training 의 첫번째 단계 SFT 입니다. Pre Training 에 비하면 아주 작은 양의 데이터만 필요하지만, 실제로 성능을 이끌어 내는데에는 중요한 단계입니다.

멀티턴 대화 (Multi Turn Conversation)

ChatGPT 를 포함해서 대부분의 AI 서비스들은 대화형입니다. 베이스 모델은 그렇지 않죠. “질문-답변” 형태의 사용자가 원하는 포맷으로 대화하는 능력이 없어요.

사람이 만든(혹은 편집한) 대화형 데이터(User-Assistant 쌍)를 모델이 직접 학습하게 하면, 모델이 “대화”를 잘 흉내 내는 어시스턴트로 만들 수가 있습니다.

Tiktokenizer 로 대화형 데이터를 token으로 바꿔 보겠습니다.

<|im_start|> <|im_sep|> <|im_end|> 와 같은 이상한 문자들이 중간중간 삽입되었고요, 이 친구들은 각자 하나의 토큰입니다. 대화형을 만들기 위해서 토크나이저에 애초에 이러한 특수 토큰들이 자리 잡고 있어요.

LLM 이 보기에는 대화 역시 이런 특수 토큰들이 포함된 그저 sequence of tokens 인 것이죠.

베이스 모델에 다양한 대화들을 만들어서 추가 학습을 시키면 우리가 원하는 비서같이 대화를 해주는 AI 모델이 됩니다. 여기서의 추가학습이 Post Training 의 첫 단계이자, Supervised Fine Tuning 이고요, 보통은 Instruction 튜닝이라고도 많이 부릅니다.

멀티턴 대화 데이터셋 만들기

앞선 베이스 모델은 인터넷에서 글을 "잘" 긁어와 데이터셋을 만든다고 했는데요. 이 데이터셋을 어떻게 만들었을까요?

OpenAI 가 2022년 공개한 Instruct GPT 페이퍼에 따르면, 양질의 대화 데이터셋을 생성하기 위한 사람을 40명 고용해서 진행했다고 써있네요. Upwork 랑 ScaleAI 라는 회사를 통해서 고용했다는 군요.

재미있는 내용들이 꽤 있는데요, "어떤 대화 데이터가 좋은 대화 데이터인가?" 에 대한 기준들이 있습니다. Human Labeler 들에게 준 가이드라인 입니다.

• Helpful, Truthful, Harmless, Toxicity, Continuity

이러한 기준들이 자세하게 있고, 어떤 식으로 레이블링을 했는지 시스템도 나와있고, 175B 의 베이스 모델인 GPT-3, 이를 SFT 한 Instruct GPT 와의 비교 까지 볼만한 부분들이 많으니, 관심있으신 분들은 페이퍼를 한번 보시는 것 추천드립니다.

OpenAI 는 참고로 이 데이터는 공개하지 않았고요, 대신 HuggingFace 에 많은 멀티턴 대화 데이터셋이 있습니다. 하나만 한번 보죠.

OpenAssistant/oasst1 · Datasets at Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

예시들 중 하나일 뿐인데, 질문, 답변 대화 텍스트가 100k 정도 규모로 있습니다.

이런 질답 예시들을 학습하면, 모든 존재가능한 질문을 학습하는 것은 아니지만, Helpful, truthful, harmless 한 페르소나가 생성이 되는 것 입니다. 나중에 사용자가 질문을 하면, 비슷한 방식으로 답변을 하는 것이죠. 예시들을 통해 말하는 법을 배운다라고 보면 되겠습니다.

HuggingFace 의 UltraChat 이 대표적인 예시인데요. 사람이 직접 대화를 작성하는 것이 아니라, AI 끼리 대화를 하고 사람이 마지막 터치만 해줍니다. Human Generated 가 아니고 Human Edited 인 셈이죠. 이 데이터셋은 Zephyr 모델 학습에 사용되었습니다.

요즘에는 완전히 LLM 이 생성하고 사람이 관여하지 않는 Synthetic (합성) 데이터셋도 많이 사용합니다.

유명한 예시로는 Alpaca 도 있고, 요즘 distillation 기법들이나 deepseek의 방법을 한번 살펴보면 더 이해가 잘 될 것입니다. 뒤이어 보겠습니다.

이러한 데이터셋으로 추가 학습을 하면 대화형으로 동작하는 Assistant 모델이 생성이 되게 됩니다.

Hallucination 문제와 해결 방법

ChatGPT 스타일의 Assistant 모델이 생성이 되었지만, 아직은 문제가 있습니다. 아래와 같은 상황을 가정해보겠습니다.

학습과정에 일반적인 질답 데이터가 있습니다. 톰 크루즈에 대해 물으면 배우 톰 크루즈에 대한 설명을 주고, 겐지스 칸에 물으면 몽골 제국의 겐지스 칸에 대해 정답을 줍니다.

그런데 실전에서 갑자기 Orson Kovacs ? 모르는 사람에 대해서 질문을 주면 모델은 어떻게 대답해야 할까요?

정답은 "모릅니다!" 여야 합니다.

그렇지만, 학습 했던 데이터와 비슷한 형식으로 답을 내놓게 되죠. 요즘엔 많이 나아졌지만, ChatGPT 서비스에서도 많이 목격되는 문제, Hallucination (환각) 입니다.  

이를 해결하는 방법에는  크게 두가지가 있습니다.

1. 모른다고 대답하도록 학습하기
2. 구글링을 할 수 있게 도구를 쥐어주기

첫 번째 "모른다고 대답하는 학습" 을 해보겠습니다. 이 방법은 Pre-Train 단계에서 봤던 Llama 3 Herd of Models 페이퍼에 잘 나와 있습니다. "무엇을 알고 있는지" 에 대해 align을 시켜야 합니다. 마치 메타인지 교육 같네요.

위 토글은 원문 발췌이고요, 쉽게 예시를 들어 설명을 해보겠습니다.

1. pretrain 에서 사용한 글을 하나 선택 합니다.
2. 문서를 보고 Llama3 에게 질문을 만들라 시킵니다.
3. 원글 없이 질문을 Llama3 에게 풀려봅니다.
4. 원글을 보면서 Llama3 에게 채점을 (correctness, informativeness) 시켜봅니다.
5. 틀린 질답이 세트가 있을 것이에요, 답변을 모른다고 바꿔써주고, 그 데이터로 SFT를 합니다.

이렇게 하면, 본인이 pre-train에서 봤지만, 잘 모르는 내용들을 모른다고 대답하도록 학습할 수 있습니다.

두번째 방법은 tool use 를 시키는 것입니다. ChatGPT 사용 하시다 보면, 지가 알아서 bing 에 가서 검색을 하고 결과를 내주는 동작을 보셨을 것입니다. 잘 모르겠으면, 알아서 판단해서 검색을 하고 결과를 보고 대답을 해줍니다.

모르겠는 질문이 나온다면, <SEARCH_START> 와 같은 "구글링을 해야겠다!" 라는 특수 토큰이 나오게 됩니다. 이것이 tool use 에요. Llama3 같은 경우도, Instruct tuned 모델은 tool use 가 가능하다고 명시되어 있습니다. 요즘의 모델들은 사실상 모두 tool use 가 가능합니다.

웹 검색 말고, 자체 db 검색이나, 자유로운 api 호출이나 여러가지 도구를 사용하는 것이 가능합니다. 지금은 hallucination 을 해결하기 위한 방법으로 소개를 했지만, diffusion 써서 이미지를 생성해주는 것과 같은 범용적인 응용이 가능합니다.

자기 자신에 대한 인식 / 지식

What model are you? Who built you?

라고 물어본다면, 뭐라고 대답해야할까요.

그냥 통계적으로 그럴듯한 대답을 해야겟죠. pre-trained 단계든 SFT 단계든 학습했던 데이터죠.

자기 자신에 대한 정체성을 부여하기 위해서는 학습단계에서 명시적으로 데이터를 학습시켜줘야 합니다.

allenai/olmo-2-hard-coded · Datasets at Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

Olmo 라는 "완전 오프소스" LLM 의 학습 데이터를 보면, 다음과 같은 데이터가 SFT 학습 데이터 셋으로 존재합니다.

{ "content": "Tell me about yourself.", "role": "user" }

{ "content": "I'm OLMo, an open language model developed by AI2 (Allen Institute for Artificial Intelligence). I can assist with a variety of tasks, such as answering questions, providing suggestions, and much more. Whether you're looking for information, advice, or just a chat, I'm here to help to do my best to help!", "role": "assistant" }

정체성을 부여하는 학습 데이터 셋이 들어가, 정체성을 학습하게 됩니다.

또 다른 방법은, "system" role 의 프롬프팅 입니다.

위 대화 데이터를 보면, "role" 이 있습니다. "user" 와 "assistant"가 보이는데요, 이런 대화 형식의 role 에는 보통 "system" 역할도 있습니다.

tiktokenizer 의 디폴트 상태 입력창인데요, 여기에도 system 역할로 "you are a helpful asisstant" 가 들어가 있습니다. 대부분의 현 LLM 들은 위와 같이 system message 를 꼭 입력 받도록 되어있습니다.

모델은 생각할 시간이 필요하다!

왼쪽 오른쪽 중에 LLM 입장에서 뭐가 더 좋은 대답방식 일까요?

정답은 오른쪽 입니다, 생각할 시간을 가지고 대답했기 때문이죠.

왼쪽은 정답인 $3 를 대답하기까지 약 4토큰, 오른쪽은 수십 토큰이 들었어요. 총 계산량을 따져보면, 오른쪽이 훨씬 많이 계산했죠. LLM 은 하나의 토큰을 내놓기 위해 연산량이 정해져있습니다. 많은 토큰들이 정답 이전에 나왔다면, 그만큼 연산을 더 할 기회가 있는 것입니다.

물론 연산을 많이 한다고 무조건 더 좋은 것은 아닙니다만, 사람도 생각을 하고 대답하는 경우에 바로바로 대답하는 경우보다 더 좋은 답을 내놓는 경우가 많습니다.

OPENAI 에서 human data labeler 들이 SFT 용 데이터를 만들 때, 이 부분을 신경을 많이 썼다고 합니다. 왼쪽 처럼 데이터셋을 만들면, LLM 이 일단 풀이 없이 대답 부터 질러버리기 때문에 hallucination이 일어날 확률이 높고, 논리적 사고를 요하는 문제일 수록 더 그렇습니다. 대표적으로 수학이나 코딩과 같은 상황이죠.

이 문제는 최근에도 큰 화두인데요. Chain of Thought 프롬프팅으로도 어느정도 해결이 가능하고요, 혹은 요즘의 reasoning 모델 들이 "강제 생각 시간" 을 가지도록 만들어져서 똑똑함을 달성하도록 해결하기도 했습니다. 이는 뒤에서 더 다루도록 하겠습니다.

토큰들로만 생각하는 것이 아니라 앞서 이야기한 "tool use" 를 통해서도 생각할 시간을 가지고 더 잘 할 수 있습니다.

이렇게 질문에 코드를 짜서 풀라고 명시를 하면, 알아서 code tool 를 사용합니다. chatgpt 에서는 이를 "코드 인터프리터" 라는 이름으로 부릅니다.

파이썬 코드를 작성해서, 직접 돌려보고 그 결과를 얻어와서 대답한 것이죠. 그냥 토큰들로만 대답하는 것이 아니라요. 카파시 선생님은 이걸 "metal arithmetic" 이 믿을만 하지 못 하다라고 이야기 하더군요. "암산" 같은 개념으로 보면 되겠습니다.

토크나이저가 불러온 또 다른 난제들

모델이 또 못하는 것들이 있습니다.

ㅂ 갯수도 못 세네요.

How many 'r' s in "strawberry"?

원래 이 질문에 답을 못해서 유명해진 문제입니다. 지금은 잘 세네요.

고작 이런 글자 카운팅도 못하는데 어떻게 수학 문제는 인간 0.1% 수준이지? 라는 의문이 들만 합니다.

그 이유를 생각해보면, 토크나이저 때문 이에요.

LLM 이 바라보는 세상에는 " 밥", "밥", "버" 라는 토큰들이 있을 뿐입니다. 이 글자하나하나 단위로 인풋을 받지 않아요. 그래서 "밥" 토큰은 'ㅂ'이 두 개 라는 것을 알기가 힘들죠. 학습데이터에 이런게 들어가 있지 않다면요.

예시를 하나만 더 보겠습니다.

이 문제도 자주 틀리게 됩니다, OpenAI 내부자들의 탐구에 따르면, "성경 구절" 이라는 feature (뉴런) 들이 활성화 된다고 하더군요. 9.11, 9.9 라는 숫자가 pretrain 단계에서 성경 구절로서 많이 등장을 했었나 봅니다.

이런 문제는 사람이 바라보는 글과 LLM 이 바라보는 토큰이 달라서 생기는 모든 항목에 대해 발생합니다. 스펠링을 포함해서요. "tool use" 와 같은 방법을 잘 활용해서 LLM 이 문제를 풀 수 있도록 지시를 비틀어 주는 작업이 필요합니다.

유니버설한 범용 머신으로서의 LLM 은 아직은 조금 더 개선의 여지가 남아 있다고 볼 수 있습니다.

본 포스트 시리즈는 카파시 선생님의 영상 을 기반으로 정리한 내용입니다. 직접 유투브에서 다루기도 했으니 영상으로 보셔도 됩니다.

• 1편 - 사전 학습 (Pre-Training)
• 2편 - Supervised Fine Tuning
• 3편 - 강화 학습 (Reinforcement Learning)

LLM 의 Training

LLM을 만들 때는 크게 세 가지 주요 단계가 있습니다.

1. 사전 학습(Pre-Training)

• 인터넷 텍스트(웹 페이지, 위키, 책 등)에서 대규모 데이터를 수집해 모델에게 “Next Token Prediction”을 하도록 학습하죠.
• 결과물: 인터넷 텍스트 흐름을 확률적으로 흉내 내는 베이스(base) 모델

2. 지도 미세 조정(Supervised Fine-Tuning, SFT)

• 대화 형태(“사용자-어시스턴트” 쌍)의 고품질 데이터(사람이 작성하거나 모델이 초안 후 사람이 보정)를 사용해, 모델이 “대화형 어시스턴트 역할”을 하도록 추가 학습합니다.
• 결과물: 실제로 질문에 답해주는 Instruct 모델

3. 강화학습(RL) 혹은 RLHF 등 Post-Training 단계

• 답변을 실제로 평가(정답 비교 혹은 인간 피드백)한 뒤, “답변이 좋으면 점수를 높이는” 식으로 모델이 스스로 똑똑해지도록 학습합니다.
• 이때 수학 문제 풀이처럼 정답 검증이 명확한 경우에는 ‘진짜’ 강화학습(RL)로 모델 스스로 다양한 풀이 전략을 발견하게 만들 수 있습니다. DeepSeek R1 이 이렇게 했죠.
• 시/소설/요약 같은 정답이 명확하지 않은 경우에는 인간 평가(선호도)에 근접한 보상 모델(Reward Model)을 훈련해, 이를 기준으로 RL을 수행하는 RLHF 방식을 사용합니다.

이 세 과정을 거치면, 인터넷 텍스트 지식을 폭넓게 갖추면서도(Pre-Training), 사람처럼 대화형으로 질문에 답하고(SFT), 때로는 복잡한 문제까지 풀어내는(RL) 거대 언어 모델을 만들 수 있습니다. 이제 하나하나 자세히 보죠.

사전 학습 (Pre-Training)

The Fine Web - Data from Internet

Pre-train 단계에서는 당연히 엄청난 양의 데이터가 필요합니다. Foundation Model을 굽는 큰 회사들 (ex. OpenAI, Google, Antrophic) 은 양질의 큰 데이터셋을 구성했습니다.

참고 - OpenAI 의 크롤러,  Antrophic의 크롤러

이런 역할을 하는 오픈 된 데이터셋 중 하나는 HuggingFace 의 FineWeb 입니다.

FineWeb: decanting the web for the finest text data at scale - a Hugging Face Space by HuggingFaceFW

Discover amazing ML apps made by the community

a Hugging Face Space by HuggingFaceFW

15-trillion tokens, 44TB 용량의 데이터 입니다. 어떻게 만들어졌는지 한번 보겠습니다.

FineWeb 은 CommonCrawl 에서 시작합니다. CommonCrawl은 2007년에 설립된 비영리 집단으로 데이터를 400TiB 가까이 수집했고, 아무나 사용할 수 있다고 하네요? (이래도 되는 건가요?)

여기서 아래와 같은 작업을 더 합니다.

• 스팸/악성/음란성/품질 낮은 사이트 제외(블랙리스트 필터링)
• HTML 태그 제거 후 순수 텍스트만 추출
• 언어 classifier로  영어 텍스트만 남기거나, multi-lingual 타겟인 경우 다양한 언어를 비율에 맞춰 조절
• 개인정보나 중복 문서 제거 등

이 외에도 다양한 필터링 과정을 거쳐서 좋은 데이터를 만들어냅니다. 자세한 내용은 FineWeb 블로그 포스트를 보시면 아주 잘 나와있네요.

Tokenizer

이제 그 수 많은 글을 토큰 단위로 쪼개야합니다. 아래 tiktokenizer 에 들어가 보시면 여러가지 토큰 나누기를 해보실 수 있습니다.

Tiktokenizer

토큰은 인간의 관점에서 보면 "단어" 랑 비슷하다고 생각하시면 됩니다. 글이라는 것은 어떠한 의미 단위의 데이터 (karpathy 는 여기서 symbol 이라고 하네요.) 가 sequential 하게 쭉 이어져 있는 것이죠. "단어 셋" 과 같은 느낌으로 "토큰 셋"을 준비한다면, 존재가능한 모든 토큰들의 sequence 로 "글" 이라는 데이터를 정의할 수 있습니다.

가장 멍청하게 하면 0,1 두 가지의 데이터로만 글을 표현 할 수도 있고요, utf-8 에 영어만 친다면 8bit (256가지의 symbol) 으로도 표현이 가능하겠죠?

GPT-4의 토큰 사전 (dictionary) 는 10만개가 조금 넘는 수준입니다. 모델마다 토크나이저가 다르고요, 당연히 호환이 잘 안됩니다.

Karpathy 영상에는 안 나와 있지만, 한국어 사용자인 우리는 한국어 토큰이 어떻게 되어있는지가 참 궁금하실 텐데요, tiktokenizer 에 한국어를 넣어보면 참 비효율적이라는 것을 어느 정도 느껴보실 수 있습니다.

"대화의 시작" 토큰 같은 특수 의미를 가지는 토큰들도 많이 있고요, 최근 reasoning 모델들을 "생각 시작", "생각 끝" 토큰도 있더군요. 로봇분야에는 "행동 토큰" 도 있고요.

Neural Net 의 I/O - Next Token Prediction

아마 이 글을 보시는 분들을 다 아실텐데요, LLM 의 문제 정의는 next token prediction 이죠.

존재 가능한 모든 토큰들 중 다음 토큰이 무엇일지 예측하는 classification 문제입니다.

Input 으로 |Viewing Single 이 들어오면, 다음 토큰 예측 값은 Post 여야 하는 것이죠.

실제로 이 과정을 어떻게 하냐! 요즘엔 모두 트랜스포머로 합니다.

LLM Visualization

A 3D animated visualization of an LLM with a walkthrough.

이 링크에 들어가보시면, 트랜스포머가 어떤식으로 동작하는지 보실 수 있습니다. 참고로 decoder only transformer 로, GPT를 포함한 요즘 LLM 은 모두 이런 구조를 가지고 있습니다.

트랜스포머 구조에 대한 이야기는 너무 방대하므로 본 포스트에서는 생략합니다.

Demo: GPT-2 재현

Karpathy 선생님이 예전에 올렸던 영상입니다. GPT-2 를 재현하는 컨텐츠 였는데요. 너무 길어서 저도 다 보지는 않았습니다.

GPT-2 에 대해서 이야기를 한번 해보죠.

2019년에 나온 모델이고, OpenAI 가 Open 이던 시절... 에 나온거죠. 원 페이퍼 저자들을 보니 Dario Amodei 와 Ilya Sutskever 가 보이네요. (ㅋㅋㅋ)

ChatGPT 는 GPT-3 이후에 나온 서비스이고, LLM 자체도 GPT-3 부터 주목을 받았던 것으로 기억합니다. GPT-2 가 세상에 나오던 시기는 저도 잘 모릅니다.

재현하는 것을 요약하면, 1.6B 사이즈에 context length 는 1024 token, 100B token으로 pretrain 된 모델입니다. 지금 기준으로 보면 아주 아주 아주 귀엽네요.

재현 포스트 를 보면 H100 x 8 싱글 노드를 빌려서 24시간 동안 학습을 했습니다. 24년 여름 기준 $672 가 들었다고 하는데, 현 시점 (25년2월) 기준 국내 업체인 엘리스에서 가격을 대강 계산해보니 80 만원 정도이고 선불로 하면 60만원대로 가능하겠네요.

쿠팡에서 h100 쳐보니까 1대에 4000만원 정도에 파네요? 진짜 파는거 맞나요... 연락하라고 있는 상품 같긴합니다.

재미있는 점은 OpenAI 가 2019년에 GPT-2 를 만들때 $40,000 정도가 들었다고 합니다. GPU 가 계속 발전해서 FLOPS 당 가격이 싸진 점도 있지만, 양질의 데이터를 잘 모아둔 점도 있고, 소프트웨어에서 학습 코드를 잘 최적화 한 점도 있다고 이야기 하시네요.

Llama 3.1 Base 모델

자 이제 현시점으로 와보죠. 현 시점에 쓸만한 모델을 pre-train 단계에서 부터 수행하는 회사는 그리 많지 않습니다. 대표적으로는 GPT, Gemini, Claude 같은 closed 모델들이 있고요,  Llama, DeepSeek, Qwen, 등 몇몇 모델들이 있습니다. 한국어 기준으로 보면 Upstage 의 Solar 나 LG의 엑사원 정도? 있습니다. 엑사원은 참고로 Llama 와 구조가 똑같고 데이터만 다르게 pre-train 했다고 들었는데 확실하지는 않습니다.

아무튼 2024년에 나온 Llama3.1 을 보겠습니다. 405B 모델이고 15T 토큰으로 학습되었습니다.

The Llama 3 Herd of Models

Modern artificial intelligence (AI) systems are powered by foundation models. This paper presents a new set of foundation models, called Llama 3. It is a herd of language models that natively support multilinguality, coding, reasoning, and tool usage. Our largest model is a dense Transformer with 40…

arXiv.orgAaron Grattafiori

Llama 3.1 모델들을 보면 Base 모델과 Instruct 모델이 있습니다. Instruct 모델은 다음 SFT (Supervised Fine Tuning) 단계에서 설명을 하겠습니다. Llama 말고도  Open Weight 모델들은 Base 모델과 Instruct tuned 모델 두개를 제공하곤 합니다. (Instruct 모델만 제공하는 경우도 있습니다.)

Hyperbolic 이라는 서비스에 가서 테스트를 해보겠습니다.

Hyperbolic – The Open-Access AI Cloud

Access open-source inference and compute at a fraction of the cost. Build with us.

LinkedIn

GPU 를 대여해주기도 하고, 모델을 올려줘 놨기 때문에 쉽게 사용해 볼 수 있습니다. 405B 모델을 테스트하려면 너무 많은 GPU 가 필요해서 클라우드에서 대여를 하고 다운 받아 돌려야 하는데, 이걸 대신 해줘서 좋습니다. (물론 다른 서비스들도 많습니다.)

재밌는 점은 "Supply GPU" 가 있네요? 남는 GPU 클라우드에 대여하고 돈 받으시길 바랍니다. 저는 바로 Waitlist 등록했습니다.

다시 돌아와서 Base 모델 테스트를 해보죠.

"유비의 동생은 누구지?" 라고 질문했더니, 아주 망가졌습니다. 많은 분들이 ChatGPT 와 같은 서비스로 느꼈던 대답이랑은 사뭇 다르죠.

Instruct 모델에도 질문을 해보죠.

이게 정상이죠. 정말 깡 Pre-trained 만 된 Base 모델은 사용하기 대화형으로 사용하기는 충분하지 못하고, 그냥 정말 next token prediction을 하는 모델입니다. 글을 이어 쓰듯이 사용하는 정도만 쓸만합니다.

Wiki 문서와 같이 정확하게 봤던 문서들 정도는 잘 재현이 됩니다.

Few-shot 을 사용하면, In-Context Learning 을 시킬 수 있습니다.

Pre-trained 베이스 모델은 그냥 무수히 많은 글을 읽었기 때문에, 언제 끝내야 할 지도 모릅니다. 정해진 만큼 계속 대답을 할 뿐입니다.

베이스 모델에 대해 요약하자면,

• 토큰 레벨의 "인터넷 도큐먼트 시뮬레이터" 로, 인터넷 글들을 꿈꾸는 친구입니다
• 파라미터는 인터넷의 lossy 압축 파일이라고 봐도 되겠습니다
• Few-Shot 같은 방법으로 다양한 Application (예를 들면 번역)이 가능합니다

베이스 모델은 똑똑한 포텐이 있는 친구인데 교육이 좀 부족한 상태라고 보면 됩니다, 이제 추가 교육을 시켜서 잠재력을 끌어내고 업무에 투입시켜야합니다.

24년 12월 OpenAI 의 추론 (Reasoning) 모델 o1 은 이미지를 인풋으로 받을 수 있게 되어 멀티모달 모델이 되었습니다.  

기존 GPT-4o 를 기반으로 만든 멀티모달 RAG 시스템이 있는데요, o1 으로 교체를 하면서 얼마나 똑똑해 졌는지, 비용은 얼마나 나올지 한번 해보겠습니다.  (+ 약간의 개선 작업도)

ESG 분석기 시스템 개요

목표는 간단합니다. 대부분의 큰 회사들은 ESG 관련 보고서를 내놓습니다. "지속가능경영보고서", "지배구조보고서" 등 다양하죠. 이 보고서를 AI가 분석할 것입니다. 특정 회사가 환경을 위해 어떤 노력들을 하고 있고, 지배구조를 과연 투명하게 운영하고 있는 지 평가해보는 시스템을 만드는 것이 목표입니다.

PDF 파일을 소스 데이터로 하는 RAG 시스템을 만들고, 아래 예시와 같은 적절한 질문들을 던져서 결과로 평가를 자동화 해보겠습니다.

이사회 내에서 기후변화 및 탄소중립 안건을 보고하거나 결의하였나요?

보고서의 팩트에 기반해 정확하게 근거와 함께 대답해 주면 됩니다.

멀티모달 RAG 시스템 구조

가장 쉽고 효과적인 방법은 당연히 RAG (Retrieval Augmented Generation) 시스템입니다. 그런데 검색 대상이 단순 텍스트가 아니라 PDF 파일입니다. 이런 경우는 보통 어떻게 하는지 LangChain 의 제안을 살펴보겠습니다.

3가지 정도 방법을 제안하는데, 큰 골자는 다음과 같고, 저는 어떻게 했는지 서술하겠습니다. 위 방법 당연히 다 해봤고요, 성능이 마음에 안들어서 제맘대로 다시 구현했습니다.

1단계 - Data 전처리 (추출)

LangChain 의 제안은  pdf 에서 텍스트, 테이블, 이미지를 각각 추출하는 것입니다. 그런데, 저는 이렇게 했습니다.

왜 이렇게 했을까요. 이건 원본 데이터인 보고서를 봐야합니다.

결국 데이터들은 의미단위로 쪼개놔야 나중에 검색이 잘 됩니다. 위 보고서 페이지를 보면 텍스트, 피규어, 도식, 테이블이 한데 모여 하나의 "기후변화대응" 이라는 섹션을 만들어냅니다.  

이 보고서는 발표자료와 비슷한 형식이기 때문에, 이미지, 테이블, 텍스트가 연결되어 해석이 되어야 합니다. 사람은 눈으로 보고 한번에 복합적으로 데이터를 해석하죠.

이것도 마찬가지 입니다. 각 요소를 추출해서 해석하려 하면 문제가 전혀 해석이 잘 되지 않습니다.

참고로 이 첫번째 데이터 처리 과정에서의 변화가 가장 큰 성능 차이를 보였습니다.

2단계 - to Embedding Vector

이제 추출된 데이터를 vector로 만들어놔야 나중에 Semantic 서치를 할 수 있겠죠. 여기서 Langchain은 두 가지 방법을 제안합니다.

1. 멀티모달 임베딩 모델로 텍스트, 이미지, 표 모두 vector로 변환한다.
2. 멀티모달 LLM (VLM) 으로 이미지나 표는 모두 텍스트로 변환한 후, 텍스트 기반 임베딩 모델을 이용해서 vectorh 변환한다.

저는 2번 방법을 택했습니다. 멀티모달 임베딩 모델을 테스트 해봤는데, 너무 후지더라고요. 아직은요. 참고로 테스트는 구글 Gemini 의 멀미모달 임베딩 모델을 사용해 보았고, 결국은 OpenAI의 임베딩 모델로 선택했습니다.

여기서!

추출된 페이지를 텍스트로 변환해야 합니다. 초기 버전은 GPT-4o를 사용했고, 이번에 o1 으로 교체 하였습니다. 자세한 코드와 결과는 아래에서 보여드리겠습니다.

3단계 - RAG

이제 vector 가 준비 되었으니, 검색을 하고 결과물을 받아 답변을 생성해야겠죠. 여기서도 두가지 방법을 제안합니다.

1. 원 데이터인 이미지, 테이블들을 멀티모달 모델에 넣는다.
2. 원 데이터인 이미지 대신 요약된 텍스트를 LLM 에 넣늗다.

저는 당연히(?) 2번 방법을 선택했습니다. 텍스트로 요약하면서 정보가 소실 되기 때문에, 정량적인 수치나 데이터가 중요한 Task (ESG 보고서 분석) 특성상 원본이 데이터가 살아있는 것이 중요합니다. 여기서도 o1 으로 교체해보았습니다.

여기까지의 큰 골자 이외에도 하이브리드 서치나 relevance 체크 같은 디테일한 부분이 조금은 더 있으니 자세히 한번 보겠습니다.

데이터 전처리

위에서 설명한 구조 그대로 입니다. 페이지를 이미지로 쪼개고, 텍스트로 요약하고 벡터로 임베딩하고.

여기서의 핵심은 원본 페이지에서 요약된 텍스트가 얼마나 정보를 잘 담고 있고, Retrieval 단계에서 빠지지않고 검색이 될 수 있게 준비를 해 두느냐가 되겠습니다.

위에서 보았던 24페이지를 GPT-4o-mini, GPT-4o, o1 에게 각각 투입해서 요약시켜 보겠습니다. 많이 기니까 스크롤 내리셔도 됩니다.

제목: 재생에너지 전환 및 RE100 추진 현황
키워드: RE100, 재생에너지, 목표, 온실가스, 에너지 전환, PPA, REC, ESG
주요 데이터:
  - RE100 목표: 2025년 100% 재생에너지 사용
  - 주요 사업장 재생에너지 사용 현황
    - 체코: 100%
    - 인도네시아: 68%
    - 국내 공장: 약 15MW 규모의 재생에너지 발전설비
  - 재생에너지 이행 절차
    - 2022년: 재생에너지 사용 시작
    - 2030년: 60% 재생에너지 목표
    - 2040년: 90% 재생에너지 목표
    - 2050년: 100% 재생에너지 목표
상세 내용:
  1. 재생에너지 목표 및 추진
    - RE100에 따른 2025년까지 100% 재생에너지 사용 목표 설정
    - 다양한 지역에서 PPA(전력구매계약)를 통해 재생에너지 확보
  2. 사업장별 재생에너지 사용 현황
    - 체코: 100% 재생에너지 사용
    - 인도네시아: 68% 재생에너지 사용 및 100% 재생에너지 목표 추진
    - 국내: 공장별 약 15MW 규모의 재생에너지 발전설비 운영
  3. 이행 일정
    - 2022년부터 재생에너지 사용 시작
    - 2030년까지 60%, 2040년까지 90%, 2050년까지 100% 재생에너지 목표
  4. 참고 사항
    - 지역별 재생에너지 사용 비율과 목표를 명확히 제시하며, RE100 이행을 위한 전략적 접근을 강조

제목: 기후변화 대응 및 재생에너지 전환
키워드: RE100, 재생에너지 전환, 체코 생산법인, 인도네시아 생산법인, 브라질 생산법인, 현대자동차, 태양광 발전소, PPA 계약, REC 구매
주요 데이터:
  - RE100 이행 로드맵: 2021년 가입, 2022년 승인, 2030년 60%, 2040년 90%, 2045년 100% 달성 목표
  - 2023년 RE100 추진 현황 지도: 체코, 인도네시아, 인도, 미국, 멕시코, 브라질, 중국, 베트남
  - 재생에너지 전환 비율 및 이용수단 비율 표
    - 체코: 100% 전환, On-site PPA 없음, Off-site PPA 없음, REC 구매 100%
    - 인도: 59% 전환, On-site PPA 4%, Off-site PPA 31%, REC 구매 24%
상세 내용:
  1. 현대자동차의 RE100 목표 달성 계획
    - 2021년 전기 에너지 100% 재생에너지 전환 목표 선언
    - 2045년까지 국내외 사업장 재생에너지 전환
  2. 주요 사업장 재생에너지 도입 현황
    - 체코 생산법인: 2022년부터 100% 재생에너지 전환
    - 인도네시아 생산법인: 2023년부터 REC 구매로 100% 재생에너지 사용
    - 브라질 생산법인: 2030년까지 100% 전환 목표
  3. 국내 공장 및 연구시설
    - 울산, 아산, 전주 공장: 2024년 15MW 규모 태양광 발전 설비 완공 예정
    - 연구시설: 2025년까지 10MW 규모 태양광 발전시설 운영 예정

### 제목: 기후변화 대응 - RE100 이행 계획 및 주요 생산사업장 재생에너지 전환 현황

### 키워드: RE100, 재생에너지, 글로벌 생산사업장, 체코생산법인, 터키/기아생산법인, 인도네시아, 인도, 브라질, 연구시설, PPA(전력구매계약), REC(재생에너지인증서), 온사이트 발전, 오프사이트 발전, RO(Guarantee of Origin), 탄소중립

### 주요 데이터:
  - 2023년 RE100 추진 현황 (생산사업장 지도):
    - 유럽(체코), 인도, 중국/베트남, 중남미(브라질) 등 지역별 재생에너지 전환 비율 표시
    - 재생에너지 이행 수단별 비중(자가 발전, On-site PPA, Off-site PPA, REC 구매) 표
  - RE100 이행 로드맵:
    - 2021년 7월: RE100 가입 선언
    - 2022년 4월: RE100 승인
    - 2030년: 재생에너지(전기) 60% 전환 목표
    - 2040년: 재생에너지(전기) 90% 전환 목표
    - 2045년: 국내(전기) 100% 재생에너지 달성 목표
  - 주요 생산사업장 재생에너지 도입 현황:
    - 체코생산법인: 2022년부터 재생에너지 보증(GO) 구매로 100% 재생에너지화
    - 터키/기아생산법인: 2025년까지 RE100 달성을 목표로 2023년부터 REC 구매… 현재 전체 전기 중 68%를 재생에너지로 전환 중
    - 인도네시아생산법인: 2023년부터 REC 구매 계약 → 100% 재생에너지 전환 추진
    - 국내 공장: 약 15MW 규모 태양광 발전설비를 추가 도입 중 (울산·아산 등 주요 사업장)
    - 인도생산법인: 2025년까지 100% 재생에너지 사용 목표, 약 24%는 REC로 확보
    - 브라질생산법인: 현재 전체 전기 사용량의 41%를 재생에너지로 전환, 향후 PPA 및 신재생 에너지 확보 통해 목표 달성
    - 연구시설: 620kW 규모 태양광 발전시설 운영, 2025년까지 10MW 수준으로 확대

### 상세 내용:
1. RE100 이행 계획  
   - 글로벌 이니셔티브 RE100 가입 후 단계적으로 재생에너지 사용 비중 확대 추진  
   - 2021년 가입 선언 → 2022년 승인 완료 → 2030년 60%, 2040년 90%, 2045년 100% 목표  

2. 재생에너지 도입 현황(주요 사업장)  
   - 체코생산법인  
     - 2022년 보증서(GO) 구매를 통해 사용 전력 전량을 100% 재생에너지로 전환  
   - 터키/기아생산법인  
     - 2025년까지 RE100 달성 목표, 2023년부터 REC(재생에너지인증서) 구매 추진  
     - 현재 전기 사용량 중 68% 이상을 재생에너지로 전환  
   - 인도네시아생산법인  
     - 2023년부터 REC 선도구매 계약 체결, 100% 재생에너지 전환 추진 중  
   - 국내 공장  
     - 울산·아산·광주·전주 공장 등에 태양광 발전설비(약 15MW 규모) 증설, 2024년 준공 목표  
   - 인도생산법인  
     - 2025년까지 100% 재생에너지 사용 목표 설정, 약 24%는 REC로 충당  
     - 현재 690kW 규모 태양광 발전시설 운영  
   - 브라질생산법인  
     - 재생에너지 사용 비율 41% 달성, 향후 PPA 등을 통해 비중 확대  
   - 연구시설  
     - 620kW 태양광 발전시설 운영, 2025년까지 10MW급 전력 생산 설비로 확장 예정  

3. 지역별 재생에너지 전환 비율 및 이행수단 (표)  
   - 사업장별 재생에너지 적용 현황(체코 100%, 터키/기아 68%, 인도 59%, 중남미 41%, 인도네시아 0%, 기타 9%)  
   - 이행수단별 비중: 자기 발전(On-site), PPA(Off-site), REC 구매 등을 혼합하여 사용  

4. 요약  
   - 본 페이지는 RE100 목표(2021년 선언, 2045년 100% 달성) 이행을 위한 글로벌 사업장별 재생에너지 전환 계획을 소개함  
   - 체코·인도·인도네시아·브라질 등 현지 사업장별 세부 이행 방안(REC 구매, PPA 계약, 태양광 발전 설치)을 제시  
   - 단계적 로드맵(2021년 가입 → 2030년 60% 달성 → 2040년 90% 달성 → 2045년 100% 달성)을 통해 기후변화 대응 역량 강화 및 친환경 경영 실현 목표를 자세히 언급함  

많이 다르죠...? 분명히 같은 프롬프트 입니다. 모델만 교체한 것이에요.

예를 들어 터키 법인의 정보는 o1 을 제외하면 다 없네요. 터키 법인과 관련된 질문이 들어온다면, o1으로 처리된 RAG 시스템만 답변이 가능하겠죠.

이렇게 한페이지 요약시키면 10,000 토큰 정도 됩니다. 현 시점 기준으로 대략 300원 정도 되겠네요. 많이 비싸죠... 참고로 gpt-4o 는 다섯배 정도 싸고 gpt-4o-mini는 100배 쌉니다. gemini 도 저렴하긴 한데, OpenAI 기준으로만 계산하겠습니다.

o1을 사용했다면, 일반 사람보다 무조건 잘해야만 수지타산이 맞습니다. 최소 ESG 분야의 직원 수준으로 결과를 내놔야만 합니다.

검색 (Retrieval)

데이터가 준비 되었으니, 검색을 해보죠.

검색 1단계 - Hybrid Search

질문이 들어오면, 하이브리드 서치를 수행합니다. 하이브리드 서치란, 키워드 서치와 시멘틱 서치 두 가지를 동시에 행하는 것을 말합니다.

• 시멘틱 서치 (Semantic Search)

Vector로 cosine 유사도를 계산하여 검사합니다. RAG 의 기본이니 아마 다 아실 것 입니다. 여기서 문제가 하나 있습니다. Cosine 유사도는 의미를 고려해서 연관된 정보를 잘 찾아주지만, 도메인 특화된 특별한 키워드들은 헤메는 경향이 있습니다.

예를 들어 다음과 같은 ESG 도메인 특화 키워드를 보겠습니다.

"PPA(전력구매계약), REC(재생에너지인증서), 온사이트 발전, 오프사이트 발전, RO(Guarantee of Origin)"

Vector 로 된 유사도 검색으로는 위와 같은 내용들이 잘 찾아지지 않기 때문에 키워드 서치가 필요합니다.

• 키워드 서치

한국어용 kiwi tokenizer 를 사용해서 토큰으로 처리를 했습니다. Kiwi 를 사용한 이유는 제가 한국어 토큰에 대해 문외한 이기 때문에, 주변의 고수에게 추천을 받았습니다. 다른 토크나이저가 더 좋을 수도 있습니다.

Corpus는 pdf 파일에서 생성된 모든 페이지의 텍스트 요약이고, 이를 기반으로 BM25 점수를 계산하여 매깁니다. BM25 알고리즘은 NLP 에 대한 지식이 있다면 아실텐데요, 쉽게 설명하면 자주 등장하지 않는 키워드에 가중치를 둬서 해석하는 알고리즘이라고 보면 되겠습니다.

검색 2단계 - Reranking

두가지 기준으로 검색된 문서들을 모읍니다. 그리고 이제 합쳐서 순위를 다시한번 매겨보고, 혹시 관련이 없는 것은 없나 필터링을 해보겠습니다.

• Cosine Similarity를 벡터간의 Distance로 수치화해서 가까운 페이지들을 찾았습니다.
• BM25 로 정량화 해서 질문에 주요한 키워드들이 들어간 문서들을 찾았습니다.

그리고, 이제 그 문서들을 모아 Reranking 을 할 텐데요. Reranking은 Cohere 사의 reranker-v3.5 를 사용했습니다.

참조 - Cohere Reranking Dev Docs

Reranker 모델은 사용할 만한 후보가 사실 몇가지 없습니다. Cohere 사의 Aya 모델을 24년 말 파인튜닝 강의에서 매우 유용하게 사용했었고, 특히 한국어를 잘 한다는 것을 확인한 경험이 있었기에 고민없이 Cohere 의 reranker를 사용했습니다. 가격은 매우 저렴하니 신경 안써도 됩니다. 제 선택을 지금 다시 돌아보니 AI 모델에도 브랜드 가치가 중요한가? 싶네요.

Rerank 점수로 다시 순위를 매긴 결과입니다. 확실히 하이브리드 서치 결과의 종합적으로 좋은 문서들이 reranking 점수도 높은 경향이 있씁니다.  Reranking 결과라는 것은 정량화 하기가 매우 어렵습니다. 정말 수많은 질문들과 검색 결과를 검증해야 알 수 있죠. 정성적으로 몇가지 정도 판단해 봤을 때에는 꽤 순위가 잘 매겨져서 잘 사용하기로 결정했습니다.

검색 3단계 - Relevance Check

검색 결과에 대하 한번만 더 체크를 해볼 것입니다. 현재까지 우려스러운 점이 하나 남아 있습니다.

텍스트 요약 정보로 검색을 했는데, 원본 페이지와 텍스트 요약이 정보가 완전히 동일하지 않으니 문제가 있을 수도 있지 않을까?

그래서 멀티모달 모델에게 한번만 체크를 돌려봅니다.

질문과 검색 된 결과들의 원본 페이지 이미지를 넘겨주며, gpt-4o 에게 물어보겠습니다.

이 질문은 통상적으로 LLM-as-Judge 에서 사용 되는 평가 방법를 응용해서 구현했습니다. 프롬프트만 살짝 튜닝 했습니다.

o1 에게 물어볼 수도 있는데, 검색된 페이지에 대해서 다 물어봐야하니 너무너무너무너무 비쌉니다. 10개의 문서를 물어본다 가정하면 10배 비싸지니 gpt-4o 에게만 물어보는 것으로 타협했습니다.

오른쪽 끝 컬럼에 Relevant 여부와 Explanation 이 생겼습니다. Chain-of-Thought 방식으로 질문했고, structured output 기능을 이용해서, 이유와 설명을 달았습니다.

여기서 explanation은 relevance 체크의 정확성을 올려주는 역할이기도 하지만, 저를 포함한 본 시스템 개발자/사용자들이 설명을 참고하여 판단하기 위함입니다.  

예상외로 reranked 순위가 높은 문서도 relevant 검사에서 필요 없는 페이지다라는 결론이 나오기도 합니다. (3번째 row, 85 페이지)

정성적으로 판단해본 결과 꽤 타당합니다. 그래서 비용을 투자하면서 relevance 검사를 workflow 에 넣기로 결정하였습니다.

이 과정을 거쳐 정제된 페이지들이 질문에 대한 근거 자료로 검색이 되었습니다!

답변 (Generation)

이제 답변할 차례입니다.

Output 의 내용이 제일 중요한 답변 생성이기 때문에, 검색 결과의 원본 페이지 이미지들을 Input으로 넣어주고, 답변도 o1 으로 생성합니다.

근거 데이터를 참조해서 추론, 판단을 해야합니다. 그렇기에 가장 확실한 데이터인 원본 문서, 가장 똑똑한 모델인 o1 을 사용했습니다. Chain of Thought 도 추가로 프롬프팅 해줬습니다.

번외로 답변을 받고 문서를 꾸미기 위한 추가 작업을 더 수행하는데, 본질은 아니니 생략하도록 하겠습니다.

결국 답변은 아래와 같은 형식으로 나옵니다.

답변 요약

등급: 나. 지역사회 상생 활동 공개

• 지역사회 상생 활동을 공개하고 있으나, 수혜자 중심의 구체적 성과지표(수혜자 수, 편익 규모 등)는 확인되지 않음

상세 설명

1. 활동 공개

• 보고서 17페이지와 66페이지에서 문화예술 후원(‘뷰티필마인드’와의 협력), 학습활동 장려(장학금 및 연구 활동 지원), 전기차 충전소 설치 등 다양한 사회공헌 활동과 지역사회 상생 활동이 소개되고 있습니다.
• 보고서 90페이지의 ESG Performance Data에서는 기부금 내역, 임직원 봉사활동 현황 등을 구체적인 수치(금액, 참여 인원, 봉사시간 등)로 공개하고 있습니다.

2. 성과 공개

• 현재 공개된 자료는 기업이 투입한 자원(기부금, 봉사시간 등)에 대한 정보 위주로 제시되고 있습니다.
  수혜자 수, 편익 등을 계량화하여 보여주는 지표(예: 기부금 수혜 인원, 현물 기부 효과 등)는 확인되지 않습니다.
• 따라서 지역사회 상생 활동이 공개되고 있으나, 수혜자 중심의 성과 지표가 충분히 제시되지 않아 ‘활동 공개’ 수준으로 판단됩니다.

주요 근거 자료

• 17페이지: 주요 이해관계자(지역사회 포함)에 대한 주요 관심 이슈와 대응 활동
• 66페이지: 지역사회에 대한 문화예술 후원, 학습활동 장려, 전기차 충전소 설치 등 사회공헌 활동 사례
• 90페이지: ESG Performance Data: 사회공헌(기부금, 임직원 자원봉사 등) 현황

근거와 함께 평가 결과가 나오게 되고, 이는 하나의 질문에 대한 답이기 때문에, 수백개의 평가 질문을 던져 최종 평가를 하게 됩니다.

수십개 정도의 질답 평가를 수동으로 진행하였는데요, 사람보다 잘하면 잘했지 못하지는 않습니다. 문제는 비용인데, 한국 인건비보다는 저렴한 것 같고, 하나의 회사를 평가하는데 10만원 이상 비용이 발생합니다.

다행인 점은, 25년 1월 현재 OpenAI 에서 매일 최대 백만 토큰을 무료로 제공 해줍니다. 데이터 제공을 동의한 경우에 한해서요. 아주 잘 활용하고 있습니다. 그래서 o1 을 사용하고 있기도 합니다.

기타 방안들에 대한 의견

• HyDE 와 같은 RAG 기법들

위의 구현체는 제가 임의로 결정한 것입니다. 여러개의 RAG 시스템을 구현해 보면서 HyDE가 대부분의 경우에 효과적임을 확인했으나, 본 데이터에서는 좋지 않더군요. 아무래도 데이터를 찾는 것이 주 목적이다 보니, 가상의 답변이 유사도를 높여주지 않는 것 같습니다.

이 외에도 Query Decomposition 이나 기타 방법들은 모두 테스트해보지는 않았고, 직관적으로 효과가 있을 법한 기법들만 테스트 해보았습니다.

• Agent 도입

요즘 AI Agent 에 대해서 사람들이 관심이 많은 것 같습니다. 본 시스템은 Agent 라고 부르기는 어려운 수준입니다. Anthropic의 정의에 따르면 workflow로 구분하는 것이 맞겠네요. (참고 - Agent의 정의)

Agentic 시스템을 도입하지 않은 이유는 간단하게도 비용 입니다. o1을 더 사용해서 답변 퀄리티를 높인다 한들 더이상 올릴 퀄리티가 미비 합니다. 생각해볼만한 것은 o1 이 아닌 저렴한 모델을 Agent로 구축하는 것인데, 그건 안해봤습니다. 가능성은 있을 수도 있겠네요. 좋은 선택지는 아닌 것 같습니다 어차피 호출은 법인의 갯수와 비례하니 더 늘어날 여지가 없으니까요.

• LangSmith 운영

데이터 기록 및 ESG 전문가들과의 소통 창구로 LangSmith 를 사용합니다. 비용을 지불하는데 가치는 충분한 것 같고요. 이 파트는 장기간에 걸친 사용 후 다시 회고를 해봐야겠네요. 아무래도 시스템의 정량적인 성능 평가가 아직 해결되지 못한 문제인데, LangSmith 가 그 해법이 될 거라고 예상하고 적극적으로 사용해보고 있습니다.

결론 및 회고

23년 말 정도에 gpt-4v 를 시작으로 이런 경우에 사용할만한 멀티모달 모델이 처음 나온 것 같은데요. (CLIP 은 훨씬 오래 전 부터 있었지만, 이런 경우까지 범용적으로 쓸만하지는 않았던 것 같아요.)

이번에 o1 에 까지 비전 인풋이 가능해지면서 정말 사람을 대체해 나갈 것이라는 확신이 생겼습니다.

데이터가 아주 잘 정돈된 텍스트가 아니어도  그냥 이미지로 처리가 가능해지면서 사용하기가 매우 편해졌습니다. o1 정도면 지능도 충분한 것 같고요.

아직은 비용이 문제이지만, 1년이면 또 많이 해결이 되지 않을까 싶네요.

본 프로젝트는 글을 작성하고 있는 현 시점 기준, 정밀 평가를 앞두고 있습니다. 문제가 아주 없지는 않겠지만,

N 명의 인력을 대체하는 것은 확정적입니다.

게다가 사람은 대량 처리가 불가능하니 시간이 장기간 소요되는데에 반해, AI 는 확장이 가능하니, 시즌성으로 닥치는 일이 빠르게 해결이 가능합니다. 평가자 들의 편차도 없어져서 공정함, 일관성도 올라갑니다.

다음으로는 각 회사가 공시한 다른 보고서들을 모아 복합적으로 분석할 예정입니다.

Appendix

요즘 많은 매체 (기사, 유투브, 포스트) 에서 "AI Agent가 미래다" 라는 말을 많이 합니다. 대표적으로 Andrew Ng 선생님께서 1년 넘게 Agent에 대해 이야기 하고 계시죠. 그런데, "Agent" 라는 키워드에 대한 정의가 많이 다르고 본인들 유리할대로 사용하는 경우가 많더라고요. 올해 (24년) Agent를 직접 구현하여 시스템을 만드는 강의를 SK 개발자분들 대상으로 꽤 여러번 진행했는데, 그래도 직접 구현해본 사람으로서 많은 분들의 혼란을 줄여보고자 이 글을 작성합니다.

본 글은 유투브 영상으로도 제작하였으니, 영상으로 보셔도 됩니다.

Agent 정의

AI 에이전트(Agent) 라는 단어만 들으면 어떻게 생각이 되시나요. 마치 무언가 알아서 척척 일을 해주는 AI 시스템인 것 처럼 보이죠.

ChatGPT 도 Agent 인가요? 많은 분들이 아니리고 할 것 같네요.  
Agent를 한 줄로 정의해보자면, 다음과 같습니다.

LLM(Large Language Model) 이 의사결정 로직을 담당하여 자율적 판단과 실행 능력을 갖추게 하는 시스템입니다.

조금 더 자세히 풀어서 써보자면,

단순히 모델을 호출해 응답을 생성하는 수준을 넘어, 에이전트는 주어진 문제를 해결하기 위해 상황을 분석하고 행동을 계획하며 (Planning) , 도구를 활용하여 (Tool Use) 복잡한 작업을 처리하는 시스템입니다. 예를 들어, 사용자가 질문을 하면 에이전트는 "웹 검색이 필요하다"거나 "코드 실행 후 결과를 검토해야 한다"는 판단을 내리고 이를 실행합니다.

위 정의에는 ChatGPT가 부합하죠. 저희가 질문을 하면 알아서 검색을 해주잖아요? LLM 이전 시대에는 의사결정 로직이 하드코드 대부분 하드 코드였습니다. if/else 분기로 이럴때는 검색을 하고, 어떨때는 하지 말고.

LLM 의 next token prediction 확률 모델이 if/else 역할을 하는 것입니다.

그래서 문제점은 Reliability 죠, 문제점은 일단 뒤로 미뤄두겠습니다. 사람도 실수 하니까요.

에이전트의 가장 큰 기대 효과는 스스로 계획하고 반복적으로 실행하며 최적의 결과를 도출한다는 점입니다. 이는 복잡한 요구 사항을 처리하거나 불확실성이 높은 상황에서 특히 유용합니다. 단순한 호출로 해결 가능한 작업은 기존의 방식으로 충분하지만, 복잡도가 높아질수록 에이전트의 유연성과 효과가 좋습니다.

LLM 이 이제 꽤 똑똑해 졌으니, 복잔한 것을 맡겨볼까? 이런 개념이죠.

문제는 정확하게 어디서부터 Agent! 이런 라인을 주기 어렵다는 것입니다. 자율성을 얼마나 줘야 Agent 일까요. chatgpt 처럼 search, dall-e, canvas, code interpreter, 과 같은 도구를 지니고 알아서 도구를 사용하면 Agent 라고 봐야할까요. 이 부분에서 모호함이 있는데, 많은 회사들이 Agent를 정의하는 선이 조금씩 다릅니다. 제가 생각하기에 Agent에 대해 가장 고민을 많이 해본 회사 중 두 곳, LangGraph와 Anthropic의 정의를 살펴 보겠습니다.

LangGraph 가 바라보는 Agentic System

LangGraph 는 LangChain 에서 만든 framework 입니다. 사실상 Agent를 빌드하기 위한 시스템이죠. 저도 LangGraph를 이용해서 AI Agent를 구현 했었고, 이를 강의하기도 했습니다. 앞으로도 당분간 계속 할 것 같고요.

LangGraph의 정의를 의역해서 보겠습니다.

Agent라는 명확한 물건은 없고, Agentic 한 시스템만 있다. 아래 요소들을 많이 갖출수록 더욱 Agentic 하다고 볼 수 있다.

Agentic 시스템의  요소

1. Tool Calling

• LLM이 필요성을 판단해 웹 검색, 데이터베이스 쿼리, 외부 API 호출 등의 작업을 수행합니다. 이러한 작업은 시스템이 단순히 요청을 처리하는 데 그치지 않고, 사용자의 요구 사항을 이해하며 그에 맞는 도구를 활용한다는 점에서 차별화됩니다.

2. Memory

• 이전 대화 맥락과 작업 결과를 저장하고 이를 기반으로 차후 의사결정에 반영합니다. 에이전트는 이러한 메모리 기능을 통해 일관된 맥락을 유지하고, 복잡한 문제를 단계적으로 해결할 수 있습니다.

3. Planning

• 현재 상황을 평가하고 적절한 행동 계획을 세웁니다. 이는 에이전트가 단순히 응답을 생성하는 수준을 넘어, 현재 상태를 분석하고 최적의 결과를 도출하기 위한 전략을 수립한다는 점에서 중요한 역할을 합니다.

여기에 Human-in-the-loop, 인간의 개입 또는 상호작용 까지 더 추가하면 가장 설득력있는 Agentic 동작이라고 볼 수 있겠습니다.

LangGraph는 LLM Application을 구현하기 위한 프레임워크입니다.  컨셉이나 구현이 궁금하시다면, 보다 자세한 내용은 아래 링크를 참조하세요.

[1] LangGraph의 Agent 컨셉을 재해석한 문서

Anthropic이 바라보는 Agent

Anthropic도 본인들이 바라보는 Agent에 대해 좋을 글을 작성했습니다. 직접 AI Agent 시스템을 다양하게 구축하면서, 정의와 함께 구현 팁도 공유를 했으니 관심있으신 분들은 한번 보시면 좋겠습니다.

[2] Anthropic의 Agent 에 관한 포스트

Anthropic도 마찬가지고 아까 제가 한줄로 정의한 "LLM이 자율적으로 판단하는 것" 을 Agentic 시스템이라고 정의했습니다. 그리고 Agentic 시스템들을 아래와 같이 분류 했는데요, 그 중에서 "많은 자율성을 가진 구조" 만 Agent라고 칭하더군요.

Agentic  시스템 분류

1. Workflow

• 정해진 코드 흐름에 따라 작동하며, RAG(Retrieval-Augmented Generation) 또는 Prompt Chaining과 같은 기존 패턴이 포함됩니다. 이러한 방식은 비교적 간단한 작업에 적합하며, 시스템 설계 및 구현에서 예측 가능성을 제공합니다.

2. Agent

• 작업 도구와 순서를 스스로 결정하며, 작업 중 발생하는 피드백(에러, 사용자 입력 등)을 기반으로 동적으로 문제를 해결합니다. 이 접근법은 시스템이 사전에 정의되지 않은 다양한 상황에 적응하고, 새로운 문제를 해결할 수 있는 유연성을 부여합니다.

LangGraph와 Agentic 함을 정의하는 큰 방향은 비슷하고, 그 중에서 명확하게 Agent 인 것만 Agent 라고 따로 부릅니다. 아래와 같은 요소를 충족한 것들만요.

Agent의 요소

• Human - in - the - loop 으로 사람과 상호작용합니다.
• 환경을 들고 활용합니다. Computer Use 가 이 경우에 해당하겠죠.
• LLM 호출을 자체적으로 판단해서 많이 할 수도 있습니다.

Agentic 시스템을 구현하는데 있어서, Agent를 처음 부터 사용하는 것은 권장하지 않더군요. 간단한 구조로 해결이 안되는 경우에 점차적으로 비대해져 Agent를 사용할 수 밖에 없게 될 것이 큰 골자 입니다. 매우 동의하는 바 입니다.

[3] Anthropic의 Agent 컨셉을 재해석한 문서

Agent는 언제 사용해야하는가?

정의만 살펴보니 조금 탁상공론 같습니다, 실제 구현에 관점에서 한번 보겠습니다.

명확한 절차와 규칙이 있는 작업

• Workflow로 충분하며, 예측 가능하고 안정적인 결과를 도출할 수 있습니다. 예를 들어, 데이터베이스 검색이나 특정 조건에 따라 데이터를 필터링하는 작업은 워크플로우 기반으로도 쉽게 구현할 수 있습니다.

복잡한 의사결정과 높은 유연성이 요구되는 작업

• Agent가 필요합니다. 여러 도구를 활용하며 동적으로 문제를 해결해야 하는 상황에서 강점을 발휘합니다. 특히, 사용자의 요청이 다단계 작업을 필요로 하는 경우가 이에 해당하겠죠. 검색을 하고, 요약하고, 다시 필요한 정보를 추리고, 또 검색하고, 검증하고, ....

예를 들어, 단순한 질의응답 작업은 기존 LLM 호출이나 RAG로 충분합니다. 하지만 "현재 주가 데이터를 분석해 보고서를 작성하고, 필요한 경우 가설을 검증하거나 추가 정보를 검색하며, 중간 결과를 요약"하는 작업이라면 Agent가 필요하겠죠.

Anthropic 의 분류에 따라, workflow 와 Agent로 구분했습니다. 제 의견에는 보다 Agentic 한 방법들이 필요하다라고 표현하는게 더 맞을 것 같습니다.

실제로 Agent를 구현한다면?

1. LangChain → LangGraph

• LangChain은 초보자에게 적합한 프레임워크로, 간단한 PoC(Proof of Concept) 단계에서 유용합니다. 비교적 작은 규모의 프로젝트에 적합하며, 진입장벽이 낮기 때문에 LangChain 으로 구현하시는 것을 추천드립니다. 문제는 LangChain으로 Agentic 시스템의 모든 요소를 구현할 수는 없습니다. Tool use 나 메모리는 쉽게 구현가능하나, Human-in-the-loop 같은 기능은 제공하지 않거든요.
• LangGraph는  프로덕션 레벨에서의 요구사항을 대부분 충족하며, 중간개입과 모니터링, 디버깅 기능이 더 잘 되어있습니다. 당연히 그만큼 진입장벽이 있고요. 그래서 LangChain으로 부족하면 LangGraph로 보다 Agentic한 시스템을 구현하시는 것을 추천드립니다.

2. 직접 구현

• LangGraph로도 불충분한 경우가 분명히 있을 거에요. 지원안하는 도구를 연결하고 싶다거나, 우리만의 API 사용이 필요하다거나. 그러면 직접 LLM API 호출하면서 구현해야곘죠. 초기 진입 장벽은 제일 높지만 디버깅과 제어에서 더 큰 자유를 제공합니다.

아마도 많은 분들이 LangGraph 를 사용하시게 되거나, (혹은 제가 소개하지 않은 다른 framework를 사용하게 되시거나) 직접 구현하시게 될 것입니다. 경험상 노코드 툴이나 LangChain은 프로덕션 레벨의 구현엔 많이 부족하더라고요.

결론

그래서 Agent가 뭐냐?

LLM 이 자율성을 가지고 로직을 결정하면 Agentic 시스템이고요, 정확하게 Agent라고 지칭하기 위한 최소 자율성의 선은 사람마다, 회사마다 다릅니다. 어쩄든 그냥 LLM 호출을 여러번 한다고 Agent는 아닙니다.

요즘 많은 분들이 Agent 라는 용어를 남발하시는 것 같아요. 언제나 신기술이 나오고, 어렵고, consensus 가 형성되기 전에는 그렇죠. "AI" 도 그렇죠. 사실 딥러닝, 트랜스포머, LLM 이런거 아니아도 다 AI 니까요. 가끔 단순 앱을 AI 시스템이라고 과대 광고하시는 프로젝트들을 보면, 너무하다고 생각이 들 때가 있습니다. 요즘 Agent 도 그런 것 같아요.

Agent 에 대한 이해에 도움이 되셨으면 좋겠습니다.

Agent를 직접 구현하실 분들을 위해 첨언하자면,

궁극적으로 중요한 것은 에이전트의 자율성을 어떻게 설계하고 엔지니어가 이를 어떤 방식으로 제어할 것인가입니다. 복잡한 요구를 처리하는 시스템을 설계할 때, 얼마나 자율성을 부여하는 것이 보다 똑똑하고, reliable 할지지 고민하셔야 합니다. Agent라고 불리기 위해 억지로 자율성을 더 부여하는 것은 본질에 벗어난다고 생각합니다. 결국 AI고 Agent고 모두 문제를 해결하기 위한 수단이니까요.

LangGraph와 Anthropic 모두, 에이전트 설계 시 불필요한 복잡성을 피하고 필요한 경우에만 점진적으로 Agentic 하게 구성할 것을 권장합니다.

마지막으로,

o1, o3 가 나오는 것을 보면서 느끼시겠지만, 로직을 판단하는 LLM 을 점점 더 똑똑해지고, 점점 더 reliable 해지고, 또 더 저렴해 질 것입니다. 그러니 Agentic 시스템을 설계 꼭 미리 하시고, 모델만 바꿔끼면 되도록 준비해두시면 분명 빛을 발할 순간이 곧 올 겁니다.

최근 LangSmith (랭스미스) 를 RAG 시스템 개발/운영에 아주 유용하게 쓰고 있습니다.

동시에 SKT 에서 Langsmith 의 사용에 대한 강의도 진행했습니다. 그 내용은 책으로도 발간을 준비하고 있는데, 사용해보면서 느낀 점들을 정리해보겠습니다.

LangSmith COURSE!

LangSmith의 사용법, 컨셉, 주요 기능을 소개합니다.

한 줄 요약: 꼭 쓰세요! 두 번 쓰세요! 대체 솔루션 많으니 그거라도 쓰세요!

먼저 LangSmith는 무엇인가. 이 글을 읽는 사람들은 관심이 있는 사람만 읽을 테니 LLM, FM, DevOps, RAG 이런 키워드들을 모두 안다고 가정하고 서술합니다.

LangSmith 는 LLMOps 인가?

LangSmith는 굳이 분류를 하자면 LLMOps 도구 라고 볼 수 있습니다.  DevOps의 LLM 버전 이라고 이해하면 되는데요. LLM 어플리케이션을 잘 만들고 운영하기 위한 도구입니다. 아래와 같은 기능들을 지원합니다.

• 현재 사용자가 어떻게 채팅을 하고 있는지 추적하고, 피드백을 수집합니다.
• 비용은 얼마나 차징이 되고 있는지, 응답 시간은 얼마나 걸렸는지 실시간으로 추적합니다.
• 데이터셋을 구성하여 LLM 어플리케이션을 자동 평가하고, 개발하는 일들을 도와줍니다.

이러한 핵심 기능들을 토대로 LLMOps라고 분류할 수 있으나, 개발사인 랭체인에서는 "Developer Platform" 이라고 칭하고 LLMOps라는 용어를 사용하지는 않습니다.

제 개인적인 의견을 덧붙이자면, LangSmith는 기본적으로 LLM 을 넘어 멀티모달리티를 지원하고, LLM 자체를 잘 만드는 것 보다 LLM 을 잘 사용하는 방법에 더 중점을 두고 있어서 LLMOps 라는 용어가 좋은 용어라고 보기는 어렵다고 생각합니다. 굳이 이름을 붙이자면, GenAIOps 라고 부르는게 더 맞겠네요.

사용 후기

간단한 RAG 시스템을 만들면서 만났던 어려움, 이를 해결하는 과정에서 LangSmith가 유용했던 점을 공유합니다.

목표와 결과물은 다음과 같습니다.

목표: 기업의 ESG 보고서를 분석하는 RAG 시스템

아래와 같이 회사와 년도를 지정하면, 당해 보고서를 분석하여 주어진 질문에 대해 분석 결과와 그 근거를 내놓는 RAG 시스템입니다. 이 시스템을 빌딩하며 겪었던 상황들을 설명합니다.

1. 추적과 디버깅

당연한 이야기이지만, 한번에 좋은 시스템을 만들기란 어렵습니다. 원하는 대로 결과를 나오게 만들려면, 프롬프팅도 수정하고, 데이터 전처리도 수정하고, 모델도 바꿔보고, 여러 과정을 거쳐야 합니다.

연구/개발자가 이 과정을 해나감에 있어서, 시작점은 직접 왜 대답이 만족스럽지 못한지 분석하고 해결해나가는 것이죠. 이 과정에 있어서 추적 (Tracing) 기능이 매우 유용했습니다.

저 같은 경우는 전문적인, 근거가 있는, 신뢰할 수 있는 답변을 원했습니다. 원문 보고서에서 적절한 페이지를 찾고, 이를 해석하고, 논리적으로 답변을 작성하는 것이 중요했죠. 당연히 첫 시도에서 이런 부분이 잘 안됐습니다.

왜 답변의 퀄리티가 만족스럽지 못할까?

이를 분석해야합니다.

랭스미스에서는 위와 같이 각 중간 과정의 in/out 결과를 보여줍니다. Retrieve 가 잘 안되었는지, 올바른 근거 자료를 찾아 줬음에도 LLM이 대답을 못하고 있는지, 추론이 가능하죠.

LLM 모델을 바꾸거나, Prompt를 바꾸거나, 다양하게 모두 돌린후 간단히 비교하기도 좋습니다. 비용도 나오고, 수행시간도 나와서 어디서 비용이 많이 드는지, 너무 느리지는 않는지 모두 확인이 가능하죠.

제 경우에는 아래와 같이 개선을 했습니다.

1. Retrieve가 문제임을 알았습니다, 원하는 근거가 잘 안 잡히더군요.
2. 원본 보고서에서 표, 이미지, 글 들을 추출해서 요약하거나, 아니면 그대로 embedding을 시켰는데, 각 데이터들이 생김새도, 정보 밀도도 달라서 그런지 원하는 근거들 검색이 잘 안됐습니다.
3. 원본 보고서를 하나의 의미, 같은 모양으로 나누기 위해 페이지 별로 요약을 돌리고 임베딩을 시켰는데, 이 때 요약 프롬프트가 정형화되도록 few-shot을 지정해 주는 것이 성능에 매우 큰 영향을 끼쳤습니다.

이 과정에서 이런 추적 도구가 없었다면, 디버깅? 연구? 하는 시간이 3배는 걸렸을 것 같네요. 왜냐하면

개선을 진행할 수록 소수의 질문에서만 문제가 생깁니다, 이를 체계화해서 로깅을 남기는 것은 구현하기가 귀찮아요.

직접 구현 다 하면 되지만, 그 시간을 단축시켜주는 도구로서 유용했습니다.

1.1 멀티모달리티 지원

추가로 저는 멀티모달리티 RAG 시스템을 구현했는데, 이미지의 피규어, 표 같은 시각 정보를 잘 추출하는 것이 필요했습니다.

다행히 랭스미스는 웹 인터페이스로 이런 in/out 이미지들을 모두 잘 보여줍니다. 수 많은 run 들에 대해 이미지 상태의 대화가 열람이 가능한 것이 매우. 편했습니다.

랭스미스의 대체제들 중, 랭퓨즈 (LangFuse) 도 무료 셀프호스팅 &. 오픈소스라는 장점이 있는데, 제가 사용하던 시점 기준으로는 멀티모달리티 지원을 아직 안 하는 것이 아쉬웠습니다.

2. 데이터 수집과 평가

LLM 어플리케이션의 알파이자 오메가는 사실 데이터셋이죠. 데이터셋을 구성하고 사용하기 좋게 잘 구성이 되어있습니다.

• 연구/개발자가 직접 데이터셋을 올릴 수 있고요, 허깅페이스처럼.
• 연동된 서비스의 유저 로그를 데이터셋으로 자동 수집이 가능하고요,
• 연동된 서비스의 유저 피드백도 같이 수집이 가능하고요,
• 자동으로 데이터를 가공해서 추가 수집이 가능합니다.

챗 서비스를 서빙한다고 하면, 유저의 질문, 시스템의 답변, 유저의 만족도 조사결과 까지 맞물려 데이터 수집이 되니 매우 유용합니다. 모아다가 강화학습을 할 수도 있고, A/B 테스트를 할 수도 있고, 불만족스러웠던 데이터만 따로 백테스팅을 할 수도 있고 사용하기 나름이죠.

어떤 방식으로든 모아진 데이터는 평가에 활용을 하기 좋게 구성되어 있습니다.

자동/수동 평가가 모두 가능한데, 자동 평가가 매우 좋아요. 여기서는 Online Evaluation 이라고 부릅니다.

아래와 같이 평가 로직을 등록을 할 수 가 있는데, API key 와 함께 프롬프트를 써주면, LLM 이 또 알아서 평가를 해줍니다. 아래 그림은 답변이 도움이 되었는지를 수치화 하는 평가 로직인데, 프롬프트를 템플릿화 해서 다 만들어놔서 편합니다. 제가 안만들어도 그냥 가져다가 쓸 것이 많이 있습니다.

평가 로직을 등록만 해두면, 서비스에서 발생하는 내 답변들을 자동으로 평가해 데이터화 해줍니다.

LLM 어플리케이션은 "평가" 가 매우 어려운 경우가 많습니다. 정성적이라서요. 이 부분을 해결하기 위해 양질의 데이터, 수많은 양의 데이터, LLM 을 다시 평가 판사 (LLM as judge) 로 사용하기, 외 기타 여러가지 방법이 있습니다. 이를 잘 지원하는 도구로서 유용합니다.

그래도 완벽한 평가는 아직 많이 어렵네요.

여기서 설명한 데이터 수집/ 평가 외 다양한 기능들이 아주아주아주 많이 있습니다. 필요에 맞게 사용할 것들이 있어서 참 좋습니다.

3. 협업

위 평가와 맞물리는 내용인데, 많은 경우에 이런 시스템은 혼자 만들기가 어렵죠. 저 같은 경우도, ESG 잘 모릅니다. ESG 전문가 분들은 따로 있습니다. 이 분들이 데이터를 분석하고, 평가해서 데이터 라벨링을 해주고, 의견을 주고 해야하는데, 협업하기가 쉽지 않습니다.

데이터를 어떤 형태로 뽑아 드려야 할지, 그 분들은 어떻게 라벨링을 달아서 시스템에 다시 올려야할지 막막한데요, 이 부분을 잘 도와줍니다.

데이터들을  Annotation queue 에 넣어서 사람을 지정해 줄 수 가 있습니다. 그럼, 전문가 분들이 데이터를 보고 정성평가를 달아주고, 데이터셋에 연동이 됩니다. 모두 웹인터페이스로 사용이 가능해서, 개발이 익숙하지 않으신 분들과의 협업이 매우 편합니다.

협업 기능을 잘 쓰려면 비용을 내야 하는 데, 충분히 낼 만한 가치가 있다고 생각이 됩니다.

총평

거의 광고 수준으로 칭찬을 했는데, 제 경험이 매우 좋아서 그렇습니다. 다른 대체제들도 있지만 사용해 보지는 않아서 비교는 못해 아쉽네요. 어쨌든 LLM 시스템 개발에 유용한건 사용해보신 분들이라면 누구나 동의할 수준이라고 보입니다.

위에서 말한 내용 말고도 장단점을 꼽자면, 이정도로 요약이 가능합니다.

• 사용하기가 매우 쉽습니다, 문서도 잘 되어있고 코드 구현도 쉬워요.
• LangChain 이랑 같이 사용하면 더 쉽고, 잘 연동 됩니다.
• 오픈소스가 아니라서 상업 수준으로 사용하려면, 비용을 내야합니다.

제가 마침 이 내용을 SKT 에서 개발자 분들을 대상으로 강의하게 됐습니다. 현업분들하고도 이야기를 나눠보니, 이미 비슷한 플랫폼을 사용하고 계시기도 하더군요.

공통적으로 느낀점은 "평가"를 어떻게 잘 할 것인가에 대한 고민이 많습니다. 저도 고민이 많은 부분입니다.

LangSmith를 비롯한 LLMOps라고 불리는 도구들은 이를 도와줄 뿐, 직접 해결해 주지는 않습니다. 정답이 없는 문제거든요. 어려운 만큼 좋은 도구가 더욱 필요하다고 생각이 드네요.

모두들 꼭 한번 써보시길 추천드립니다. 진짜 좋아요. 그래서 이 포스트도 작성하게 되었습니다.

본 포스트는 코드 구현이나 테크니컬 디테일 보다는 ChatGPT를 필두로한 새로운 생성형AI 모델들로 인해 나타날 변화에 대해 사유합니다.

저는 주로 현직 엔지니어나 개발자분들을 대상으로 강의를 하기 때문에, LLM 또는 Transformer 의 원리나 실제 코드로 시스템을 구축하는 방법 등을 다룹니다.  

그러던 24년 4월, 우연한 기회로 서울대학교 현대사회와 미디어 강의에서 생성형AI 관련 특강을 진행했습니다.  교양 강의로 대학생들을 대상으로 강의를 하다 보니 디테일한 부분 보다는 기술의 발전 흐름, 그로 인한 사회의 영향을 고민해 보는 시간을 가지게 되었고, 저 스스로도 많은 것들을 돌아보게 되었네요.

나름대로 결론을 내린 예측들이 고작 2달이지만 시간이 흐르며 맞아가는 것을 보고 생각을 정리하여 기록을 남겨봅니다. 누군가에게는 도움이 되길 바라며.

기술의 흐름

생성형AI (Generative AI) , LLM (Large Language Model) , GPT 이런 키워드들이 대중의 관심을 많이 받고 있죠. ChatGPT 의 상업적인 성공은 너무나 강렬하고, 제 개인에게는 주요 밥벌이 수단이기도 하며, 주식시장에서는 NVIDIA 의 고공 행진을 이끌고 있죠. 얼마나 많은 이용자들이 ChatGPT 를 사용하냐면, 전세계의 제일 비싼 GPU를 아주 많이 쓸어간 OpenAI 의 컴퓨팅 자원도 서양 친구들이 활동할 시간이면 이용자가 몰려 자원이 부족해 ChatGPT 가 멈춥니다.  (당연히 유료 사용자도)

조금만 자세히 들여다 보죠.  

2017년 Tranformer 구조가 세상에 나옵니다. 그 유명한 "Attention is all you need" 가 논문 제목입니다. 지금 와서 돌이켜보면 이 당시에는 큰 주목은 못 받았습니다. 구글에서, 그리고 OpenAI 에서 Transformer 를 기반으로 많은 것들을 만들었는데 대표적인 것이 GPT 이고, 이는 현재까지도 모든 LLM 의 기본 구조로 자리 잡았습니다.

처음엔 왜 주목을 많이 못 받았고, 지금은 왜 이렇게 인기가 높을까요? 왜 성공했을까요?

현재까지도 계속 더 똑똑해지고 있고, 앞으로 얼마나 더 똑똑해질 지 모릅니다. 반면, 데이터를 많이 넣기 전까지는 두각을 나타내지 못하기 때문에 처음에는 이만큼 주목을 받지 못했죠. 이전 시대의 구조 (대표적으로 CNN, RNN) 들과 비교하여, inductive bias 가 없기 때문인데 이건 어려운 이야기니까 여기서 생략하겠습니다.

중요한 점은 아직 끝을 만나지 않았다는 점입니다. 앞으로도 발전 여지가 많이 남아있어요.

멀티모달리티 (Multi Modality)

현재를 기준으로 보겠습니다. GPT 로 대표되는 LLM 은 랭귀지 모델입니다. 언어 모델, 텍스트를 기반으로 합니다. 이 LLM 은 당분간 계속 똑똑해 질 예정입니다. 그런데, 더 중요한 점이 있습니다.

GPT 는 이제  LLM 이 아닙니다. Multi-Modal Model 입니다.

24년 5월 13일 OpenAI 가 GPT-4o 를 발표했습니다. 5월 14일 구글이 Gemini 1.5 를 발표했습니다. 공통점은 멀티모달리티, 언어 뿐 아니라 눈과 입, 귀가 달렸다는 것이죠.

예를 들어, 스마트폰에서 ChatGPT 앱을 켜고 음성 모드를 써보겠습니다. 이제까지는 오디오 신호는 Whisper 라는 Speech Recognition 모델을 통해 text 로 인식이 되고 text 가 GPT로 전달되어 text가 나옵니다. GPT 가 생성한 대답은 text 이고 다시 TTS를 통해 음성으로 변경되어 스피커로 재생되죠. GPT 는 LLM, 랭귀지 모델이니까요. 이러면 단점은 무엇이냐. 오디오에 담겨있는 말투, 뉘앙스, 짧은 pause 같은 정보들이 모두 소실됩니다. 오로지 텍스트에 담길 수 있는 정보만 살아서 전달이 되죠.

이번에 발표한 GPT-4o 는 멀티 모달리티 모델입니다. 텍스트를 받는 언어 모델이 아니고, 텍스트, 오디오, 이미지 (영상) 을 함께 가리지 않고 받는 모델이에요. 앞서 지적한 문제들이 모두 사라집니다. 24년 6월 현재는 아직 이 기능이 지원되지 않지만, 곧 출시 예정입니다. GPT4가 인간어를 다루는 모델이라면, GPT-4o는 인간데이터를 다루는 모델이라고 요약할 수 있겠습니다.

이는 데모 영상에서 드러납니다. 언어가 아님 숨소리의 의미도 파악하고, 말투 변경 요청도 수행하죠. 데모 영상에는 오디오 뿐 아니라 vision 내용도 담겨있으니 안보셨다면 한번 영상을 보시는 것을 추천 드립니다.

멀티모달리티 모델의 포텐셜을 생각해볼까요.

인간은 센서를 늘릴 수 없습니다. GPT 는 늘릴 수 있습니다.

Input 으로는 오감이 끝이죠. 현재 GPT-4o 는 촉각/후각을 쓰지는 않지만... 어찌 됐든 이 디지털 뇌는 센서를 맘대로 늘릴 수 있습니다. 자율주행 차량의 예를 보면 이미 lidar 센서를 쓰고 있죠? 이런 것들이 종류를 막론하고 추가가 가능합니다. 인간보다 다양한 데이터 타입이 처리가 가능하죠. 물론 데이터를 충분히 확보할 수 있어야 하겠지만.

다시, 인간을 기준으로 돌아와서 멀티모달리티 타입의 데이터 중 우리가 가장 많이 즐기는 것이 있습니다. 바로 동영상이죠. 24년 초에 OpenAI 에서 Sora 라는 모델이 정말 말도 안되게 영상 능력을 보였는데, 5월 구글에서도 Veo 라는 모델을 발표했습니다. 이 Sora 모델도 Tranformer 기반의 구조라고 합니다. (이미지 생성은 Diffusion 이라는 또 다른 구조의 모델이 있는데 이에 관련한 디테일은 생략하겠습니다.)

컨텐츠의 변화

이제 기술 이야기는 살짝 접어두고, 컨텐츠와 미디어에 대해 이야기 해보겠습니다. 누가 봐도 생성형AI 가 컨텐츠와 미디어에 지대한 영향을 끼칠 것은 자명한데, 어떻게 끼칠지 한번 생각해보죠.

제가 어렸을 때, 약 15년 전을 생각해보면 친구들, 친척들이 거의 같은 컨텐츠를 즐겼습니다. 주말엔 할아버지, 할머니도 같이 무한도전을 보고, 학교에 가면 지난 주 무한도전 이야기를 했어요. 이것이 매스미디어, 대중매체의 영향력이었죠.

현재를 보죠. 친척들이 모이면 각자 다 다른 것을 봅니다. 할머니는 정치 유투브를 보십니다. 같은 세대인 사촌들도 저랑 다른 것을 봅니다. 제 유투브 시청기록에는 사나고/MKBHD/카파시 이런 것들이 있고, 사촌형 시청 기록엔 저는 본적도 없는 천만 먹방 유투버들이 있습니다. 저는 동생들 유투브 구독 목록을 항상 염탐하여 따라가려고 노력합니다.  추천 시스템을 기반으로 개인화 미디어 시대라고 볼 수 있습니다. (참고로 유투브 추천 시스템도 딥러닝 기반...) 그래도, 누군가는 제가 본 유투브 영상을 같이 봅니다. 내 옆 사람이 아닐 뿐.

그래서 미래는?

그렇다면 미래는 어떻게 될 까요? 저는 이렇게 예상합니다.

우리는 모두가 다 다른 컨텐츠를 볼 것이고, 미디어는 그 컨텐츠들을 무한히 생성해줄 것이다.

가까운 미래를 생각해보겠습니다. 저는 강의를 현재 본업으로 삼고 있기 때문에, 강의라는 컨텐츠 생산자 이기도 합니다. 제 강의에는 가끔 외국인 분들도 오십니다. 최근에는 일본인 분이 오신 적이 있었는데, 제가 일본어를 못하기에 질답을 영어로 했습니다. 만약에 제가 한국어로 강의를 하고 있지만, 바로바로 일본어로 동시 통역되어 수강생 분에게 전달이 된다면 어떨까요? 한국분들과 일본분은 같은 강의를 다른 컨텐츠로 소비하고 계신 것이죠.

제가 강의 영상을 올렸는데, 언어별로 다르게 합성되어 제공된다면, 사용자의 시청 기록 또는 요청 사항을  기반으로 영상 내용도 재편집되어 배달된다면, 하나의 생산된 컨텐츠가 사용자마다 맞춤형으로 변경되어 배달이 되는 미디어가 되는 것이죠. 음성인식과 번역, 그리고 영상 립싱크 합성이 있으면 가능한데, 이미 서비스가 출시된 사항입니다.

그 다음 미래는, 하나의 생산된 컨텐츠가 맞춤 변형되는 것이라 아니라, 생산부터 소비자에 맞게 생성 될 것입니다. 저는 무협 소설을 좋아하고, 많이 소비합니다. 만약에  미디어가 저한테 맞는 소설을 계속 생산해서 제공해 준다면, 저는 작가가 있겠지... 하면서 재밌게 소설을 즐길 것 같습니다. 소설은 필명만 존재하기에 작가의 실체를 확인하기가 힘들죠. 사실 이미 GPT 를 이용해서 만들어진 작품들이 많이 있을 것으로 추정됩니다. 제가 즐기는 소설 중에 의심 가는 작품들도 있고요.

노래도 이미 SunoAI 와 같은 서비스로 양질의 음악이 생성되고 있고, 그림은 이미 옛적에 미드저니로 만들어진 그림이 미술대회에서 우승을 했죠. 우리가 마주하는 많은 컨텐츠들의 생산 비용이 생성형AI 로 인해 확 떨어질 것이고, 이는 맞춤형 컨텐츠로 사용자에 맞게 생산이 될 것이라고 예상합니다.

생성된 컨텐츠도가 점점 더 큰 비중을 차지하게 될 것이 당연합니다. 실제로 유투브나 라이브 방송에서는 버튜버가 이미 큰 인기가 있고, 버추얼 가수인 플레이브는 MBC 음악 프로그램에서 이미 수상을 했죠. 이러한 흐름은 이미 시작 되었습니다.

대중들은 이런 컨텐츠에 거부감을 느낄까요? 그렇다면 어떤 대체제를 찾을까요? 인간은 사회적 동물이니까 거부감을 느낄 것이고, 그에 따라 오프라인 모임이 반대 급부로 더 활성화 될 것이라고 생각합니다. 오프라인 참가가 가능하거나 조작이 어려운 라이브 같은 형식. 실체가 보증된 형태의 컨텐츠가 더욱 중요해질 것이라고 예상합니다. 그래서, 저도 텍스트로만 전달하는 블로그를 넘어 라이브를 시작하려고요.

위와 같은 결론에 따라 본 포스트는 AI 의 도움을 하나도 받지 않은 오로지 제 손과 머리로만 작성했습니다

최근에 딥러닝 기반 서비스를 바닥부터 다 만든 일이 있었다. 만들고 시범 운영을 해보면서 느낀 점, 구현하면서 생각해 볼 만한 점들을 정리해보았다.

문제 정의

차량의 주행 및 소음진동 정보를 기반으로 차량의 상태를 진단하자. 이번에 딥러닝 모델을 도입해서 풀고자 하는 문제는 특정 부품의 내구 상태를 알아내는 것이다.

기반

자동차에서 정보를 수집하고, 관련 신호들을 처리 하는 시스템 우선적으로 필요하다. 이 시스템은 이미 구현이 되어 운영을 하고 있었다. N년동안 만들고 운영 중인 시스템이 있는데, 요약하자면 아래와 같다.
(자세한 내용은 https://nvds-manual.super.site/ 참조)

데이터 수집 시스템은 이미 갖춰져 있고, 자동으로 분석 하는 프로그램도 사실 이미 다 구현이 되어있었다. 이 분석 프로그램은 고전(?)적인 신호 처리를 수행해서 차량 상태를 진단한다.

딥러닝 모델 도입 이유

위에서 말한 기존의 방법으로는 풀 수 없었던 문제가 있었다. 특정 부품의 상태가 잘 판단이 안되더라. 자세히 말하기는 어렵지만 차량을 분해해야만 알 수 있는 특정 부품의 문제를 미리 알아내고 싶었다.

기존의 방법대로하면, 아래와 같은 소음진동 신호가

아래와 같은 에너지 레벨 (decibel), 에너지 레벨 그래프, 에너지 레벨 colormap 이 된다.  

문제는 이 정보들을 기반으로 부품의 문제가 특정이 어렵다.
"요게 몇 데시벨이라서 높으니까 문제!"  이렇게 되어야 한다.

그런데!
하나 더 신기한 점은 colormap 을 이미지로 취급해서 눈으로 정상/이상 데이터를 꽤 많이 보다 보면 사람이 대략적으로 판단이 가능해진다는 점이다. 패턴이 보이게 된다.

모델 선정 및 학습

Input Raw Data 와 이 데이터를 분석한 결과물이 있다. 분석 결과물은 1차원의 에너지 레벨, 2차원의 그래프, 3차원의 칼라맵인데, 다른 분야의 표현을 빌리자면, extracted feature 혹은 embedding vector라고 볼 수도 있겠다.

이러한 data 들을 기반으로 모델을 학습시켜서 만들어보자.

나에게는 차량에서 수집한 데이터와 학습을 위한 output value, "특정 부품의 크랙 사이즈"가 있다. 크랙 사이즈는 부품을 분해해서 알아낼 수 있다.

여러가지의 모델을 시험해 보았는데, 하나하나 해본 것들을 정리해보겠다.

학습을 위해서 이것저것 hyper parameter 들을 적용 시켜 봤는데, 큰 직관을 가져다 주는 사항은 없었다. 그냥 다 돌려보고 좋은 것을 골랐다.

모델 배포 & 적용

Linear Regression 모델은 그냥 곱하고 더하면 끝이라서 Android/Windows 앱에 내장했다. 나중에 데이터가 늘어나서 학습을 다시 시키면, 계수들을 업데이트 해야 하니까 이것만 서버에서 가져오도록 준비했다.

문제는 CNN 기반 모델인데, 요것도 사실 모델 잘 말아서 앱으로 밀어 넣을 수 있긴 하다만, 서버에서 처리하도록 API 서버를 만들었다.

전체 구성은 다음과 같다.

서버는 Colormap 을 HTTP Post 로 이미지 스트림으로 받아서 CNN 모델을 돌리고 output 값을 return 해준다. 단순하게.

앱에서는 Linear Regression 이든 CNN 기반 Regression 이든 예상 결과를 바로바로 보여준다. 사용자는 차량에서 데이터를 취득하고 바로바로 결과를 볼 수 있다.

시스템 자체가 고객 (현대) 가 필요해서 만들었고, 지금은 여기에서만 사용되고, 나중에 아무리 많이 보급되어도 소비자가 많지는 않을 것이라 scalability 는 고려하지 않았다. (그냥 API 서버만 k8s 로 늘리면 되겟지.)

데이터 수집에 관한 고찰

이렇게 하나의 시스템을 바닥부터 끝까지 다 만들었는데, 포스트에 빠진 가장 중요한 내용이 하나 있다. 바로 데이터 수집 파이프라인이다.

결국 딥러닝 모델은 데이터의 양으로 승부를 봐야 하는 데, 이것이 문제다. 이번 task 는 연구를 위해 강제로 부품에 문제를 만들고 여러 샘플을 시험하면서 데이터를 확보했는데, 많이 부족하다. 실제 필드에 있는 많은 차량에서는 예상 결과가 틀릴 확률이 다분하고, 현재 학습된 데이터에 overfit 되어 있을 것으로 예상된다.

문제가 있는 차량에서 데이터를 수집해야 한다는 점, 학습을 위한 데이터는 차량을 분해해서 부품의 문제를 측정해야 한다는 점. 매우 매우 데이터를 수집하기 어려운 환경이다.

가장 좋은 시나리오는 정비소에 보급이 되고, 정비소에서 교체를 진행했을 시에 문제 부품을 받아서 데이터를 하나 씩 추가해 나가는 것이다. 교체를 하기 위해 측정된 raw data 는 중앙 서버에 모아야 하고.

애초에 본 시스템은 처음 고안 되었을 때부터 첫 번째 타겟 소비자가 정비소였고, 중앙 서버에 데이터를 업로드하도록 구상했으나, 현재는 중앙 서버가 없이 운영되고 있다. 데이터는 각자 태블릿/컴퓨터에 보관되는 중이다. 담당자 분들이 중앙 데이서 서버 구축을 시도 했으나, 조직의 여러 절차와 예산 등 복잡한 이해관계로 인해서 해결이 되지는 못했다.

이 문제가 자율주행처럼 어마무시한 가치를 가져다 준다면 모두가 적극적으로 했겠지. B2B 프로젝트 특성상 내가 어떻게 할 수 있는 것은 아니다.

소회

뭐 어쨌든, 처음부터 끝까지 딥러닝 기반 시스템을 만들고 배포했고 운영한다. 사용자가 많지는 않더라도. 딥러닝을 대학원생 때 처음 접하고, caffe 부터 고생하면서 설치하고, 강의도 하고, 자문도 하고, 개발도 하고, 많이 했는데, 딱 10년이 된 지금 처음으로 시스템을 구축했다. 전체 시스템의 부분적으로만 참여하다가, 하드웨어부터 펌웨어, 프론트엔드, 백엔드, 딥러닝 모델까지 다 만들 수 있게 되니까 혼자서 다 해내니 뿌듯하다.

요즘 핫한 generative ai 는 아니지만, 곧 generative ai 를 기반으로 시스템을 만들 기회가 생길 것 같다.

딥러닝 강의를 다시 하게 되어서, 좋은 자료들을 정리하려고 찾아다니다가 certificate 들이 눈에 들어와서 땄다.
취득 한 것은 NVIDIA와 Tensorflow 에서 발급하는 두 가지 인데, 따면서 느꼈던? 알게된? 점들을 정리하겠다.

NVIDIA

NVIDIA 에는 많은 교육과정들이 잘 정리되어 있는데, 딥러닝 관련 코스들만 해도 꽤 10개 넘는 과정들이 있다.

NVIDIA Deep Learning Self-Paced Courses

Select courses offer a certificate of competency to support career growth.

NVIDIA

이렇게 알아서 잘 찾아 들으라고, 분야별로 learning path 도 제시해 준다. 아래 예시는 computer vision 쪽 코스 가이드 인데, 다양한 목적별로 path 들을 정리해 놓았더라.

코스들을 보면, 과정따라 유료인 것도 무료인 것도 있고, 어떤 것은 Certificate Available 이라고 써져 있다.

사실 나는 딥러닝을 그래도 꽤 오래 전부터 실제로 사용해왔기 때문에, 학생입장으로 교육을 들을 필요는 없었지만, 교육자로서 과정을 잘 다듬고 싶기 때문에, NVIDIA 가 정리한 교육 과정을 들어봤다.
겸사겸사 certificate 도 따면 좋고, 어떤 식으로 자격을 검증하는지도 궁금했기에 위에 있는 Disaster Risk Monitoring Using Satellite Imagery 코스를 들었다. 무료이기도 했고, 사실 다른 과정들도 여러 개 다 들어봤다.

Courses – NVIDIA

Deep Learning Institute

코스 구성

이 코스 같은 경우는 위성 이미지를 기반으로 vision task 를 수행하여 재난 모니터링 시스템을 구축하는 내용이다.
핵심은 위성이미지를 처리하고, 학습해서 재난 상태를 바로바로 나타내 주는 것. 일반적인 image classification 문제이다.

요약하자면 아래와 같은 구성을 띈다.

1. 동영상으로 된 프로젝트 개요

2. Azure 로 ipynb, data 가 다 구성된 파일 시스템을 docker 로 열어주고 jupyter lab 을 열어줌

   2. 여기서 대부분의 학습이 이뤄짐. 이론 설명 & 실습 코드
      준비, 데이터 전처리, 시각화, 학습, 평가, 배포까지

3. 4지선다 문제 10개 퀴즈

4. 실습 테스트

   1. 다시 도커 새로 구성해서 열어주고, 직접 코드 시험 봄
   2. 실습 코드에서 필요한 부분들만 살짝 수정해야 함, 학습 후 모델의 평가 결과로 채점함

5. 추가 학습

   1. 앞선 과정과 같이 이론, 실습이 있음
   2. 내용은 실제 2021 위성 데이터 재난 예측 대회에서 2등한 모델의 예시
   3. 실제로 딥러닝 모델의 성능 향상을 위해 도입된 semi-supervised learning 이라던가, ensemble 모델의 도입 이라던가 이런 시도들이 정리되어 있음.

위 캡처 이미지 처럼, 동영상으로 내용 설명도 잘 해주고, 무엇보다 클라우드로 실습을 할 수 있게 구성해준다.
아래 Start 버튼을 누르면, 구성하고 접속할 수 있게 열어주는데, colab 같이 그냥 저작성된 ipynb 파일을 열어 준다.
(그런데 구성하는데 오래걸린다.… ㅠㅠ 약 10분?)

이 ipynb 파일이 정말 양질로 잘 구성되어있다. 이것 밑에서 따로 더 자세히 얘기하겠다. 아무튼 이 ipynb 파일에 있는 내용을 숙지하고 직접 코딩해서 딥러닝을 실습해보는게 주 컨텐츠이다.

그리고는 아래와 같은 온라인 퀴즈 시험이 있고,
(이론 내용인데 시간이 충분하므로 쉬움)

실습 시험도 있다. 똑같이 ipynb 파일을 클라우드로 열어주고 가서 코딩하고 학습시키고 성능을 검증해야한다.

시험 자체는 어렵지 않다. 위성 이미지를 그냥 하라는 데로 잘 분석해내면 되고, 실제 위성 이미지를 분석해본다는 측면에서 경험도 도움이 많이 될 것 같다.

사실 나는 수 년 전에 위성 이미지를 이용해 대륙을 구분하는 연구 시스템을 구축했던 적이 있어서... 수월했던 것 같다.

컨텐츠

어떤 것들을 배울 수 있었는 지가 가장 중요한데, 다음과 같은 것들을 배울 수 있었다.

일반적인 딥러닝의 흐름이 잘 정리되어 있어서 좋았고, (이것은 다른 곳들에도 잘 정리되어 있긴 하다.) 무엇보다 NVIDIA 도구들을 직접 사용해 보는 것이 좋았다.

• NVIDIA Data Loading Library (DALI)

NVIDIA DALI Documentation — NVIDIA DALI 1.29.0 documentation

• NVIDIA TAO Toolkit

Overview - NVIDIA Docs

NVIDIA Docs

• NVIDIA Triton Inference Server

Overview - NVIDIA Docs

NVIDIA Docs

데이터를 잘 가져오는 DALI 나 Transfer Learning 을 수행하는 (이미 학습된 모델들을 잘 골라 사용하는) TAO Toolkit 같은 경우는 사실 다른 플랫폼 (ex. tensorflow) 에도 되게 쉽게 잘 되어있다.

그런데 Trition Inference Server 는 NVIDIA 의 서버를 이용해서 완성된 모델을 배포, 운영 하는 라이브러리?시스템? 인데, 사실 연구자들은 크게 고민하지 않는 부분이라 꽤 볼 것이 많았다.

좋은 모델을 만들면 효율적으로 돌리기 위한 노력들을 해야하는데, 프로덕션 레벨로 진짜 배포를 할 것이라면, 효율을 위한 학습들도 사실 해야한다. purning 도 해야하고, 특히 quantization 을 적용하고 다시 학습시키고 평가하는 루틴을 거쳐야 한다.

Quantiazation 은 딥러닝에서 가장 유용한 효율성을 높이는 방법 중 하나이다. 대부분의 파라미터들은 굳이 정밀함이 필요 없기에 이를 희생에서 많은 연산 효율을 얻고, 아주 조금의 모델 성능을 떨구는 것이다.

아무튼 이것은 사실 진짜 서비스 운영 단계에 오지 않으면 많이들 고민하지는 않는 부분인데, 이런 부분까지 다뤄주는 것이 특히 좋았다.

실제 분석 하는 컨텐츠들은 아래와 같이 생겼는데, 여느 ipynb 파일들이랑 같다. 설명이 무척 자세할 뿐.

Certificate

과정 잘 이수하고 시험 통과 하면 아래와 같은 certificate 이 발급된다. 링크드인에도 박을 수 있게 해준다!

Tensorflow

Tensorflow 에도 Developer Certificate 이 있더라. 이것은 유명한 과정인지, 한국어로 된 후기들도 꽤 있었고, 이거 따는 것을 위한 인터넷 강의도 있더라

Receive the TensorFlow Developer Certificate - TensorFlow

Demonstrate your level of proficiency in using TensorFlow to solve deep learning and ML problems by passing the TensorFlow Certificate program.

TensorFlow

응시료는 100 달러이고, 그냥 바로 응시해도 되긴 하지만, 연계된 교육 과정이 무료로 구성 되어 있다.

Andrew Ng 이 창업한 deeplearning.ai 에서 운영하고 있는 코스이고, google 사람이 나와서 강의를 해준다. 실제 강의는 coursera 페이지로 연결되어 들을 수 있다.

코스 구성

교육 과정 구성은 총 4개로 내가 느낀대로 요약하자면,

1. tensorflow 사용해보기
2. Vision 해보기
3. NLP 해보기
4. Time-series 해보기

정도로 볼 수 있다. 직접 학습해보고, 모델 성능을 끌어올리기 위해 어떻게 모델 모양을 바꾸거나, 학습 방법을 바꾸거나 하는 등의 행위를 해본다.

컨텐츠의 내용은 아래와 같다.
 - 우선 쉬운 모델들 위주로 트랜스포머 같은 최신 모델들을 사용해보지 않는다.
 -  vision 을 기준으로 보면, object detection 이나 segmentation 같은 task가 아닌 단순 classification 정도만 한다.
 - 직접 학습을 잘 하기 위한 방법을 배워본다.

직접 모델을 만들어갈 사람 (연구자) 을 위한 시작점으로는 아주 좋다는 느낌이 들었다.

각각의 코스는 reading assignment 와 역시나 잘 정리된 실습 ipynb 파일, 이것들을 설명하는 동영상 강의로 이뤄져 있다.

퀴즈와 코딩 숙제가 섞여서 이를 잘 통과해야만 과정을 수료할 수 있다.

ipynb 파일들은 github 에 모두 올라와 있으니 사실 그것만 봐도 거의 다 커버가 된다.

GitHub - https-deeplearning-ai/tensorflow-1-public

Contribute to https-deeplearning-ai/tensorflow-1-public development by creating an account on GitHub.

GitHubhttps-deeplearning-ai

이 과정 뒤로 연계된 심화 과정들이 deeplearning.ai 에 있다. 나는 안 해봤다.

Certificate

여기는 시험 얘기를 좀 해보겠다.

NVIDIA 코스는 사실 실습과 시험이 거의 과정이 똑같아서 굳이 언급 안 했는데, 여기는 시험 과정이 좀 다르다.

직접 본인 환경에 setting 을 해야 한다. pycharm 에 plugin 으로 자동 환경 구성 & 채점 시스템까지 만들어지고, 실제 학습은 내 컴퓨터에서 진행이 된다.

당연히 클라우드로 진행될 줄 알았는데 그게 아니라서 좀 놀랐다.
이럴 줄 알았으면, 스펙 좋은 컴푸터에서 할 껄 그랬다. 학습하는 것이 느려서 시간이 좀 아까웠다.

난이도는 생각보다는 어렵지 않더라. 딥러닝 경험이 있던 사람이라면, 위 교육 과정을 이수 하지 않아도 통과할 수 있을 것 같다. 물론 교육 과정은 매우 잘 정리가 되어있으니 이수하는 것을 추천한다. 직접 tensorflow 를 다뤄보는 것은 당연히 배울 것이 많다.

아무튼, 시험은 5시간 시간 제한이 있는데 2시간도 안 걸렸고, gpu 셋업을 미리했으면 1시간도 안 걸렸을 것 같다. 학습을 잘 못해서 헤메거나, 개인 환경의 사양이 좀 낮은 경우를 위해 넉넉하게 시간이 잡혀 있는 것 같다.

다 하고 나면 아래와 같은 certificate 이 날라온다. 유효 기간은 3년이란다. 어디서 인정을 해줄지는 모르겠다만, 그래도 증이라도 주니 기분이 좋긴 하다.

참고로, 앞서 말한 교육 과정도 이수하려면 quiz 랑 실습 다 통과 해야하는데, 다 이수하면 이수증을 주더라. 이것도 링크드인에 연동해서 박을 수 있게 되어있다.

결론

NVIDIA 랑 Tensorflow 에서 제공하는 교육 과정이랑 certificate 을 해봤다.
- 교육과정은 아주 잘 정리가 되어있다.
- 특히 딥러닝을 시작하는 사람들한테 아주 유용하다.
- certificate 은 난이도가 높지는 않아서, 제대로 된 실력 보장은 안 되겟다.

아무래도 온라인 자격증이라는 것이 copy 이슈도 있고 하니, 실력 보장을 잘 하기는 어려울 것 같다.

본 포스트는 DB & Auth 개발을 하며 삽질한 내용을 다룹니다

계기

필자는 혼자서 서비스를 개발하고 있었습니다. 개발자 관점에서는 본 서비스는 다음과 같이 간단합니다.

사용자는 로그인을 하고, 돈을 낸 만큼 데이터를 열람할 수 있습니다.

저는 serverless로 scalable하고 보안적으로 문제가 없게 구현하고 싶었습니다.

백엔드를 만들고 운영하면서 계정관리도하고 데이터베이스 접근도 다 검사하는 무식한 방법은 미래를 위해 좋지 않습니다.

기연

필자의 친구 중에는 고수가 있습니다. 고수에게 조언을 구했습니다.

고수가 말하길

내가 다 써보니, Auth0 + Hasura + (Postgres / Docker) 를 추천한다.

손쉽게 지름길에 도달해서 공부를 시작했습니다.

사실 원래는 모든 Backend를 Firebase 로 다 구현하려고 했습니다.
왜냐하면, Frontend 를 Flutter 로 구현하고 있고, 같은 구글의 서비스가 연동이 잘 되어있기 때문이죠. 쉽게 사용할 수 있는 패키지나 문서가 많습니다.
Firebase 에는 Hosting도 Database도 Auth도 Storage도 다 구비되어 있습니다. 서비스를 런칭하면 하나의 계정으로 한곳에서 모니터링, 결제 등등 관리가 편하죠.

구현을 하려다보니 Database (Firestore) 에서 rules를 설정해서 접근 제한을 걸어야하는데, 이게 스크립트로 짜야하는 것이 제가 원하는 기능들을 세세하게 구현하기가 어려웠습니다. 결국 Cloud Function의 도움을 받아야할 것 같더군요.

지름길로 가 봅시다.

Hasura + Neon

Hasura 라는 것을 처음 들어봤는데, 이러저러한 데이터베이스들 위에 얹어서 API도 만들고, 접근제어도 하고, 모니터링도 하고 이것저것 할 수 있는 서비스 입니다. 제가 원하는 것들을 직접 구현하지 않아도 해주는 녀석이죠.

그럼 데이터베이스를 골라야합니다.

고수의 추천은 Docker에 Postgres를 올리고, 나중에 사용자가 많아지면 k8s로 늘리면 된다는 것 이었습니다. 그런데, Hasura 공홈 안내에는 두가지 방법을 추천하더군요.

1. 위와 같은 방법. Docker + Postgres 를 self로 올려 연결합니다.
2. Neon serverless postgres 를 사용하는 방법
   (이 외에도 엄청 다양한 database를 연결하는 방법들이 잘 안내되어 있습니다.)

Neon이라는 서비스를 또 처음 들어봤지만, 제가 원하는 그것을 돈내면 해주는 곳 입니다. 참 좋은 서비스들이 많습니다.

그래서 귀찮으니 Neon을 골랐습니다. 연동도 거의 원클릭으로 됩니다. 가격비교를 해보지는 않았지만 같은 요청/저장 을 하면 더 비싸겠죠. 나중에 서비스가 잘 운영되고 원가를 절감하고 싶으면 그때가서 바꿔끼면 되겠습니다.

Auth

Hasura는 여러가지의 Auth 서비스들을 함께 사용할 수 있었습니다.

Auth0, firebase auth, clerk 등등 10가지 넘게 문서화가 잘 되어있었습니다.

보니까 제가 사용하고자하는 frontend 에 auth0 연동하는 것이 문서화가 잘 안되어있더군요. 그래서, 고수에게는 미안하지만 그냥 firebase auth를 골랐습니다.

이제부터 삽질 시작입니다.

JWT, Custom Claim

이 글을 미래의 저를 위한 글이기도 하기 때문에 찾아봐야할 문서들을 남깁니다.
키워드로 검색해서 오신 고수분들은 이 링크들만 보셔도 될 겁니다.

1. Hasura Auth (Authentication, Authorization) 문서 중 JWT 관련 내용
2. Hasura + Firebase Auth Sample App

큰 구조는 아래와 같습니다.

Auth 서비스에서 JWT를 받아와서 Hasura에 API 요청을 할때 같이 넘겨줍니다.

해야할 일은 아래와 같습니다.

Hasura에서 auth 정보를 볼 수 있게 설정해줘야 합니다.

저는 firebase auth를 사용하니 이 정보를 hasura environment variable에 설정해줘야합니다. 아래 내용을 따라하시면 됩니다. 그냥 입력하면 되는 거라 뭐 딱히 설명하지는 않겠습니다.

Firebase | Hasura Authentication Tutorial

Firebase enables you to add authentication to your applications. Learn how to integrate Firebase with Hasura using JWT

Hasura Authentication Tutorial

Hasura에서 요하는 정보들을 JWT에 넣어줘야합니다.

JWT 에 포함되어야 할 스펙들은 Hasura 문서에 잘 나와있습니다.
JWT 에 role 같은 것들이 다 들어있어야 합니다.

여기서 삽질을 많이 했는데요, 저는 개인적으로 Auth 관련 내용을 처음 구현 해봅니다.  JWT고, GraphQL이고 다 처음 구현하는 거라 어떤 식으로 보안이 안뚫리게 만드는 것인지 잘 몰랐습니다.

Firebase auth 에서 JWT에 내용들을 추가해줘야하는데, Firebase의 설명은 아래 문서를 참조하면됩니다.

Control Access with Custom Claims and Security Rules | Firebase Authentication

Firebase

어찌되었건 Cloud Function 를 사용해야 한다는 것입니다.
이걸 안하려는 것도 이유 중에 하나였는 데, 결국 하게되었네요...

아래와 같은 코드를 올렸는데요, 내용은 간단합니다.
signup 할때마다 불리고, email 도메인따라 admin을 주거나, user 를 주거나 둘 중 하나입니다. user/admin은 hasura에서 데이터 접근 권한을 가를때 사용합니다.

const functions = require('firebase-functions');
const admin = require('firebase-admin');
admin.initializeApp(functions.config().firebase);

// On sign up.
exports.processSignUp = functions.auth.user().onCreate(user => {
  console.log(user);
  // Check if user meets role criteria:
  // Your custom logic here: to decide what roles and other `x-hasura-*` should the user get
  let customClaims;
  if (user.email && user.email.indexOf('@hasura.io') !== -1) {
    customClaims = {
      'https://hasura.io/jwt/claims': {
        'x-hasura-default-role': 'admin',
        'x-hasura-allowed-roles': ['user', 'admin'],
        'x-hasura-user-id': user.uid
      }
    };
  }
  else {
    customClaims = {
      'https://hasura.io/jwt/claims': {
        'x-hasura-default-role': 'user',
        'x-hasura-allowed-roles': ['user'],
        'x-hasura-user-id': user.uid
      }
    };
  }
  // Set custom user claims on this newly created user.
  return admin.auth().setCustomUserClaims(user.uid, customClaims)
    .then(() => {
      // Update real-time database to notify client to force refresh.
      const metadataRef = admin.database().ref("metadata/" + user.uid);
      // Set the refresh time to the current UTC timestamp.
      // This will be captured on the client to force a token refresh.
      return metadataRef.set({refreshTime: new Date().getTime()});
    })
    .catch(error => {
      console.log(error);
    });
});

요런 함수를 올리고 실제로 jwt를 발행받아서 한번 열람해봤습니다.

jwt.io에 토큰을 붙여넣으면 볼 수 있습니다.

이렇게 Firebase auth 에서 받은 jwt 에 hasura 에서 필요한 내용들이 추가가 되었네요.

이제 저 function을 결제랑 연동해서 role들을 분기시켜줘야합니다. 이건 나중에 구현할 것이고요.

Hasura에 요청하기

API는 GraphQL 이나 REST API 를 사용가능한데, 둘 다 헤더에 아래와 같이 내용을 추가하면 Role에 맞게 데이터를 거절하거나, 일부만 보여주거나 설정된대로 알아서 해줍니다.

Authorization Bearer $JWT

잡소리

요렇게 하나 이해하고 구현하는데 하루가 더 걸렸네요 ;;

덕분에 JWT랑 Auth관련해서 많은 지식들을 얻었습니다.

JWT에 내용이 저렇게 쏙쏙 담기는 거라는 것을 처음 알았습니다.

이걸 하려면 firebase auth 에서는 cloud function으로 auth랑 연결시켜야 한다는 것이 참 예상 외 였네요. 정말 이렇게 해야하나? auth에서 뭔가 설정하면 될 줄 알았는데, 엄한데 찾느라고 시간 많이 날렸습니다

이번 포스트는  kogpt.tmmse.xyz  를 만들면서 느낀 점들을 다룹니다.
(다 사용하고 현재는 닫았습니다. 사용하실 분들은  Github 코드를 빌드하시면 되는데, 이게 가능하시면 직접 만드시는게 더 편하실 거에요....)

KoGPT Rest API 공개

OpenAI 가 공개한 GPT-3 는 언어를 너무 잘 다뤄서 전세계가 놀랐었죠.
당연히 영어로 동작하기 때문에, 한국어를 잘 다루는 AI가 나오길 기대하고 있었습니다.
그리고 대략 2년쯤 지난 지금 역시나 한국어 버전이 나오기 시작합니다.
대표적으로는 네이버의 CLOVA와 카카오의 KoGPT 두 가지가 눈에 띕니다.

CLOVA는 현재 기업들만 사용신청이 가능합니다.
대신 뤼튼이라는 서비스가 CLOVA를 이용해서 서비스를 런칭했기 때문에 간접적으로 사용이 가능합니다.

카카오에서 나온 KoGPT는 모델이 공개되어서 직접 돌려볼 수도 있습니다만, 비싼 장비를 갖췄거나, colab을 유료로 사용하는 등의 방법이 필요해서 어려움이 조금 있었죠.

이러던 와중에 최근 RESP API 로 KoGPT 를 사용할 수 있게 공개가 되었습니다! (Kakao 개발자 페이지)
보다 쉽게 사용이 가능해진 것인데요, 그래도 비전공자 분들은 바로 사용하기가 쉽지는 않습니다.

그래서 누구나 써볼 수 있게 만들었습니다.
(사실 여자친구 써보게 하려고 만들었어요.)

누구나 쉽게 사용할 수 있는 Interface

빠르게 배포할 수 있고, 누구나 접근이 가능하도록 Web으로 만들었습니다.
Kakao에서는 REST API 로만 공개를 했기 때문이죠.

개발자 분들은 REST API 쓰는 것이 어렵지 않겠지만, 컴퓨터를 다루지 않으신 분들은 쉽지 않아서 그냥 키보드/마우스만 있으면 쓸 수 있게 했습니다.

접속하시면 아래와 같은 화면이 나와서, 몇 가지만 입력하면 사용해보실 수 있습니다. 각 항목에 대한 설명은 공식 문서 링크를 걸어 뒀으니 가서 보셔야 합니다.

직접 써보는 내용은 영상으로 찍어보고 여기에 추가하려고 합니다.

후기

Framework는 Flutter를 사용했고, 코드는 Github 에 가시면 누구나 보실 수 있습니다.
디자인은 뭐... 그냥 대충 구현 빨리 되는대로 했습니다.
1차로 다 만들고 나니 너무 안예쁘네요. 기회가되면 개선해볼까 싶습니다.

구현하는데 대충 5~6시간 정도 걸린 것 같네요.
Firebase 에 호스팅하고, 블로그 서브도메인 연결하고, 배포하고 하니 대략 8시간 정도 소요되었습니다.

Flutter와 Firebase를 사용한 이유는 그냥 제가 익숙해서이고, 혹시 앱으로 출시할 수도 있으니, cross-platform이 지원되는 프레임워크가 유리하기도 합니다.

이런 Web 페이지는 제가 처음 만들어보는데, 워낙 간단한 기능이다 보니 크게 어려움은 없었네요.

사실 이 앱의 본질은 그냥 REST API를 호출하고, 결과를 뿌려주는 것이 끝입니다.
그래서, 나중에 다양한 REST API 를 대응 할 수 있도록 고민을 살짝 해봤습니다.
자유도와 가독성을 둘 다 챙기고 싶었는데, 모두 만족시키는 것이 어렵네요.
나중에 다른 사람들이 잘 짠 코드를 참고해 봐야겠다는 생각이 들었습니다.
스스로 판단하기에 제가 간단하게 만든 코드가 만족스럽지는 못하네요.

Zotero  는 논문 관리 프로그램이다. 비슷한 프로그램으로 Mendeley, Papers 등이 있다. 비슷한 논문(서지) 프로그램 중에 내가 zotero를 쓰는 이유 단순히 무료이기 때문이다. 오픈소스 프로그램이기 때문에 큰 기대안하고 대학원 다닐동안 잘 사용하였는데, 지금은 더욱 완성도 있는 프로그램이 되었다.

타 프로그램처럼 macOS, iPadOS, 윈도우 (안드로이드x) 등을 지원하며 웹브라우져 확장프로그램에서 논문을 바로 cliping할 수 있다. 다만 safari에서는 잘 안되는 듯 하다.

macOS와 iPad에서 같은 논문을 필기할때 동기화가 되는 큰 장점이 있다.

예전에는 iPad에서 papership이란 다른 앱을 통해 zotero에 관리하는 논문을 보았는데 그렇게 썩 만족스럽진 않았다. 하지만 지금은 zotero native app이 생겨서 굉장히 잘 작동하기 때문에 더욱 추천한다.

타 프로그램은 내 기억으로는 구독제거나 저장용량에서 유료형태이다. 반면 zotero는 webDAV 프로토콜을 사용한 개인 저장공간 (nas, 타 클라우드)를 활용한다면 무료로 사용할 수 있다. 나는 box.com 에서 꼼수를 통해 webDAV를 사용하였는데, 이제 막힌듯 하여 갖고 있던 Synology NAS를 활용하기로 하였다.

방법

방법은 몇 번 시도해보니 다음과 같이 설정하면 된다. Synology Nas가 외부 접근 가능하게 만든다. 나는 DDNS 편집을 통해 <host_name>.synology.me 로 접근 가능하게 하였다. 공유기를 사용한다면 외부 포트허용 등의 작업이 추가로 필요할 것이다.

패키지 센터에서 webDAV 를 설치하고 설정에서 HTTP (5005 포트)또는 HTTPS (5006 포트)를 활성화를 한다. 어떤 프로토콜이던 상관은 없는 듯 하다. 그리고 공유기를 사용한다면 역시 NAS로 해당 포트허용 및 포워딩이 필요할 것이다. 그리고  user_id 의 홈폴더에 zotero 폴더를 생성해놓는다.

동기화 도구로 webDAV 를 설정하고 host 와 사용하는 프로토콜에 맞게 아래 중 하나로 설정한다.

https://<webdav_server>:5006/homes/<user_id>/
http://<webdav_server>:5005/homes/<user_id>/

user_id 와 password 도 맞게 설정하면 된다.

iPad에서도 동일하게 설정 > account > FILE SYNCING 에서 위와 같이 설정하면 동기화가 된다.

참고.

https://www.zotero.org/support/kb/webdav_services

Sync Zotero with Synology NAS via WebDAV

Hi!<br />I am rather a beginner in IT and I am trying to use my Synology NAS to sync my Zotero library.

Zotero ForumsL-Caudron

Zotero – Mendeley를 버린 이유와 WebDAV, iOS 연동 방법(PaperShip) | Hooni’s Playground

A Common C.S. Researcher

Hooni's Playground | A Common C.S. Researcherhooni

필자는 라즈베리파이에서 Timing 이 아주 중요한 application 을 개발하고 있었다. 프로세스가 context switching 되어 나가는 동안 데이터를 처리하지 못해 문제가 발생하는 상황이었다.

그래서,  real time kernel 을 사용했다. 모든 kernel 관련된 작업이 마찬가지지만, 이 작업 또한 참 귀찮다. 한국어로 된 자료도 마땅한 것이 없기에 이 포스트를 작성한다.

배경 지식

• Real Time Kernel & Linux
  Real Time Kernel 이 무엇이냐 하면, 개념적으로는 프로세스가 scheduling 될 때 잠시 멈추더라도 최대한 빨리 돌아와서 다시 수행하는 것을 의미한다.
  Linux 에서는 이를 Preemption 레벨을 조정하는 방법으로 구현? 적용? 한다.
• PREEMPT_RT patch
  Linux 에서는 각 버전에 맞는 rt 패치를 받아서 kernel 소스 코드에 적용할 수 있다. 그리고 빌드 & 설치를 하면 된다. Patch는 git 의 commit 을 가져와서 꼽는다고 생각하면 대충 비슷하다.
  ( PREEMPT_RT Patch 참조 )
• Raspberry Pi, Linux Cross-compile
  이 글을 읽는 사람 정도 되면, 아마 다 알 것 같긴 한데...
  RPI 는 ARM 기반 CPU 를 사용하고, 보통 우리는 x86 기반의 CPU를 고성능 컴퓨터로 사용한다.  RPI 에서 Linux 를 직접 빌드 하려고, 하면 너무 느리다. 그러다 보니 다른 x86 Linux 호스트에서 ARM 용 Linux 를 빌드하게 되는데, 이게 Cross-compile 이다.
  (요즘엔 Apple 이 ARM 기반 고성능 CPU를 내주고 있으니, 곧 상황이 달라질 지도?)
• Docker
  필자는 Cross Compile 을 하기 위해서 Docker 위에 환경을 구축하고, 빌드 했다. Docker 는 굳이 설명 안 해도 다들 알겠지.
  

자 이제 시작해보자

0. 선 결과 요약

아래와 같이 "PREMPT_RT" 가 보이게 될 것 이다.

1. 환경

필자는 Raspberry Pi OS 를 사용한다.

현재 Raspberry Pi OS (구 Raspbian) 은 5.15 커널을 기반으로 한다.
(꽤 최근의 OS 를 쓰지 않으면, 새로 구매한 보드들은 동작하지 않기에 어쩔 수 없다.)

2. 설명

나도 처음부터 다 직접한 것은 아니다. 검색을 해보니 아주 좋은 소스가 있어서 이를 가지고 시작했다.
Docker & 빌드 코드 를 받아서 진행해보자.
간략하게 설명하자면,
- Docker 컨테이너 위에 빌드 환경을 설정한다.
- RT 최신 패치를 받아와서 적용한다.
- 빌드하고 image 로 만든다.

빌드 환경으로는 ubuntu 를 사용하도록 되어 있는데, 원하면 버전을 바꿀 수 있다.
빌드 타겟은 5.10 Linux 를 사용하게 되어있는데, 나는 5.15 가 필요하니 이를 살짝 바꿨다.
두 내용 모두 "Dockerfile" 을 열고 편집하면 된다.

안타깝게도 나는 빌드하고 생성된 image 를 sd card 에 굽고 사용했더니, RT 패치가 안되더라. 이유는 안 알아봤다.
이미 사용하고 있는 RPI 가 있으니, 거기에 빌드된 코드를 옮겨서 install 해버렸더니 잘 되더라.

3. 따라하기

A. x86 linux 시스템에 위 github repo를 clone 한다.

git clone https://github.com/jonhpark7966/rpi-rt-kernel.git

A - 1 (Optional). Docker 파일을 편집한다.
 필자는 linux 버전은 5.15 로 변경했다.

B. 빌드 & install

그냥 make 해도 되지만, 여러 문제를 해결해야 하니 자세하게 설명한다.
그래서 make custom 을 한다.
그러면 생성된 Docker Container 안으로 진입이 가능하다.

진입하면 다음과 같이 rpi-kernel 이 받아져 있고, patch 도 받아져 있다.

위 코드와 패치는 각각
- https://downloads.raspberrypi.org/raspios_lite_arm64/images/
- https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/
여기서 받아온다.

받아진 Linux 코드는 rpi-5.15.y 브랜치이고, git status 에서 확인할 수 있듯이 많은 내용이 patch 되어 있다.

자 여기서 한번 make menuconfig를 해서 확인해보자.

이렇게. Fully Preemptivle Kernel 이 활성화 되어있다. 이대로 빌드 하면 된다. 그 외 다른 설정들도 바꿀 수 있으니 원하시는 대로 설정하시길.

이제 빌드를 하면 되는데, 빌드는 아래 써있는 것들만 하면 된다.

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image modules dtbs

이제 빌드된 결과물들을 install 해야한다.
소스 포함에서 통째로 raspberry pi OS 로 옮기자.
나는 SCP 로 옮겼다. 워낙 기초적인 내용이니 생략한다.

Raspberry Pi OS 에서는 아래와 같이 install 하면 된다.
경로는 각자 알아서들 확인 해야한다.

make modules_install
make dtbs_install

cp /rpi-kernel/linux/arch/arm64/boot/Image /raspios/mnt/boot/$KERNEL\_rt.img
cp /rpi-kernel/linux/arch/arm64/boot/dts/broadcom/*.dtb /raspios/mnt/boot/
cp /rpi-kernel/linux/arch/arm64/boot/dts/overlays/*.dtb* /raspios/mnt/boot/overlays/
cp /rpi-kernel/linux/arch/arm64/boot/dts/overlays/README /raspios/mnt/boot/overlays/

Raspberry Pi OS 의 자세한 빌드&설치 내용은 공홈의 설명 링크를 참조하면 된다. 어떤것들을 설정하고, 빌드하고, 설치해야하는지 아주 잘 써져있다.
( Raspberry PI 공홈 가이드 참조 )

여기 까지 했으면, 다 된 것이다!

uname -a

했을시 PREMPT_RT 가 잘 나오면 된다!

이상으로 간략한 관련 지식 설명과, 하는 법을 안내했다.
RT 관련 작업은 처음 해보았는데, 생각보다는 어렵지 않다. RT 패치를 linux 버전이 올라감에 따라 계속 maintain 되고 있다는 것이 놀라웠다. 누가 왜 하는 건지...
덕분에 나는 개꿀