[메인터뷰] 는 오픈소스에 기여하는 빌더가 메인이 되는 인터뷰로, 클라우드브로 커뮤니티가 오픈소스 빌더들의 이야기를 기록하는 시리즈의 다섯 번째 편입니다.
오픈소스를 왜 하느냐는 물음에 보통은 기여나 공유 같은 말이 돌아옵니다. 작은 추론 모델과 SQL 기반 검색 엔진을 직접 만들어 공개해 온 염기웅 님의 답은 달랐습니다.
“꼴찌가 되려고 하는 거예요. 다 공개하면 그걸 따라 해서 성능이 나와야 하잖아요. 지금은 아무도 1등이 없으니까, 다들 너무 못하니까, 내가 꼴찌 해줄 테니 같이 올라가 보자는 느낌인 거죠.”
스스로 바닥에 깔려서 생태계 전체를 끌어올린다는 발상입니다. 그가 만든 모델은 허깅페이스에 올라가 있고, 모델을 다루는 일에서는 해외 연구자들에게 조언을 받습니다. Liquid AI도 그중 하나입니다. 그러면서도 인터뷰 내내 그는 자기 모델 자랑보다, 오픈소스라는 판 전체가 어떻게 굴러가는지를 더 자주 이야기했습니다.
내부에서 생각하는 모델
그가 직접 만든 것 중 하나는 작은 추론 모델입니다. 이름은 KoHRM-Text-1.4B이고, 이름 그대로 1.4B 크기의 작은 모델입니다. 보통의 AI는 생각의 과정을 글자로 줄줄 풀어내며 추론합니다. 이 모델은 그 대신 답을 밖으로 내놓지 않고 모델 안에서 연산을 반복하며 생각합니다. 추론 과정을 토큰으로 뱉는 것이 아니라 내부 표현 공간에서 굴리는 방식입니다.
“텍스트를 생성하는 대신 인공지능 내부에서 그냥 생각하는 것처럼, 내부에서 이것저것 연산을 계속하면 더 성능이 좋지 않을까. 그런 식으로 나온 논문이 있어요.”
HRM-Text라는 논문에서 영감을 받았습니다. 코드와 데이터가 다 공개돼 있었고, 적은 비용으로 작은 모델을 만들어 비슷한 크기의 모델을 이겼다는 결과가 그를 끌어당겼습니다. 마침 6월까지 쓸 수 있는 GPU가 있었습니다.
“재밌어 보이고 할 수 있을 것 같고, 좋은 코드가 다 공개돼 있으니까. 6월까지 어차피 쓸 GPU니까 빨리빨리 끝내자, 그런 거죠.”
거기에 한국어와 코딩, 터미널 명령어까지 학습시켜 키웠습니다. 한국어를 다룰 때는 토크나이저 단계에서 손을 댔습니다. 영어 위주로 만들어진 모델은 한국어를 쓰면 같은 내용에도 토큰을 두 배 가까이 빨리 소모해 비효율적입니다. 그래서 어휘 사전을 거의 두 배로 새로 만들어 학습시켰습니다.
결과는 크기에 비하면 나쁘지 않았습니다. 정답이 명확한 영역에서 특히 강했습니다.
“터미널 작업에서는 딥시크의 거대 모델도 이깁니다. 코딩이나 터미널 명령어처럼 정답이 있는 것들은 잘하는데, 내부 추론을 많이 해야 하는 것들은 생각보다 못해요.”
정작 한계는 그 내부 추론에서 나왔습니다. 한국 변호사 시험을 시켜봤더니 찍기 수준에 그쳤습니다.
“미국 변호사 시험은 오픈 모델들도 만점을 받는데, 한국 변호사 시험은 최고 모델들도 만점을 못 받아요.”
이유를 그는 둘로 봤습니다. 글로벌 모델들이 한국 법에는 관심이 없다는 것, 그리고 한국 변호사 시험 자체가 워낙 어렵다는 것. 비교 삼아 구글의 모델을 학습시켜 보니 절반쯤은 맞혔는데, 대신 덩치가 훨씬 컸습니다. 작은 모델로 깊은 추론의 벽을 넘기가 그만큼 어렵다는 이야기였습니다.
기술적인 걸림돌은 성능만이 아니었습니다. 모델을 실제로 쓰려면 출력이 빨리 나오고 입력이 빨리 읽혀야 하는데, 새로운 구조이다 보니 기존의 전용 추론 프로그램들과 호환이 잘되지 않았습니다. 쓸 만하게 만들려면 추가 작업이 많이 필요한 상태였습니다. 그는 이 모든 것을 가리지 않고 말했습니다.
“가능성은 충분한데 어떤 걸 잘하고 못하는지도 모르겠고, 실험할 시간도 자원도 너무 부족해요.”
방향은 잡혀 있었습니다. 100B가 넘는 큰 모델을 운용하는 일은 현실적이지 않으니, 되도록 10B 아래로, 이상적으로는 1B까지 가볍게 만드는 것이 목표입니다. 자체 모델이 끝내 어려우면 제미나이나 클로드 같은 유료 API를 쓰면서 그 비용 이상의 값을 받는 구조도 열어두고 있었습니다.
100배 올라간다와 100배 내려간다
다른 한 축은 SQL을 쓰는 검색 방식입니다. 이쪽은 엔터프라이즈를 겨냥합니다. 왜 SQL이냐를 이해하려면 요즘 많이 쓰는 검색 방식의 구멍부터 봐야 합니다.
지금 흔한 방식은 문장을 벡터로 바꾼 뒤 코사인 유사도로 가까운 것을 끌어옵니다. 의미가 아니라 표면의 닮음을 재는 것이라, 여기서 사고가 납니다.
“'100배 올라간다’와 '100배 내려간다’는 정반대 말인데, 앞이 다 똑같으니까 유사도는 엄청 높거든요. 그래서 올라가는 걸 찾는데 내려가는 걸 가져올 수 있어요.”
문장 앞부분이 같고 끝의 "된다"와 "안 된다"만 다르면, 정반대 내용인데도 유사도가 높게 나옵니다. 기존 시스템은 그걸 그대로 근거로 가져오고, 잘 가져왔다고 답합니다. 막을 방법이 없는 것입니다.
그가 보는 대안은 데이터를 구조에 맞춰 쿼리로 조회하는 SQL 방식입니다. 잘 정리된 데이터라면 더 적합한 문서를 더 안정적으로 가져올 수 있다는 것입니다. 쿼리 결과가 어긋나면 다른 쿼리를 짜서 다시 찾는 식으로 오가며 좁혀갑니다.
그가 참고한 논문은 PDF 문서를 OCR로 읽어 구조로 바꾸고, 그걸 SQL로 만들어 대화하는 흐름이었습니다. 그런데 그는 그 앞단이 대부분 군더더기라고 봤습니다.
“이미 SQL이 잘 돼 있는 곳에서 더 잘하는 게 더 중요하지 않을까. 굳이 PDF를 거칠 필요 없이요.”
OCR 단계도 미덥지 않았습니다. IBM이 공개한 Docling 같은 오픈소스를 써봤지만 그리 좋지 않았고, 한국어 PDF에는 특히 약했습니다. 그래서 이미 SQL로 잘 정리된 환경에 곧장 적용하는 편이 효율적이라는 결론에 이르렀습니다. 이 경우 구성이 단순해집니다. 모델 하나와 SQL 하나로 짧게 돌아가니 설치도 운영도 가볍고, 클라우드보다 온프레미스 환경에 맞습니다.
요즘 유행하는 에이전틱 방식과도 견줬습니다. 파이썬 함수를 미리 만들어 여러 파일을 훑고 AI가 판단해 다음 명령을 내리는 방식인데, 보기에는 더 멋있어도 효율로는 SQL 쪽이 나아 보인다고 했습니다. 물론 그는 단정하지 않았습니다.
“어떤 환경에서는 기존 유사도 방식이 나을 수도 있고, 어떤 곳에서는 SQL 방식이 나을 수도 있어요. 다 해봐야 알죠.”
위험도 짚었습니다. 회사의 운영 DB에 AI가 직접 붙는 만큼, 잘못해서 데이터를 지우거나 바꾸면 그대로 사고가 됩니다. 실제로 적용하려면 그런 안전 문제까지 풀어야 한다는 것입니다. 그러면서도 그는 이 방식이 오픈소스에서 인기 없다는 점을 알고 있었습니다.
“SQL은 재미없어 보이잖아요. 요즘 멋있는 건 에이전트 같은 건데. 그런데 엔터프라이즈에서는 무조건 수요가 있을 거예요.”
좋은 오픈소스란
긴 대화의 한가운데에서, 좋은 오픈소스 프로젝트란 무엇이냐는 물음이 나왔습니다. 그는 네 가지를 차례로 들었습니다.
첫째는 사람들이 실제로 쓰는 것입니다. 깃허브 별이 많이 달려도 정작 쓰는 사람이 없는 경우가 흔하다고 했습니다. 둘째는 작은 문제라도 실제로 해결하는 것. 셋째는 영감을 주는 것입니다. 많은 이들이 두려워하는 일, 즉 누군가 포크해서 다른 프로젝트를 만드는 일이야말로 좋은 프로젝트의 증거라고 그는 봤습니다.
“내가 완성하지 못했어도 내 의지를 다른 사람이 가져가서 완성시킬 수 있으면, 그게 진화이고 생존이거든요.”
넷째는 돈을 내고 쓸 수 있는 것입니다. 공개돼 있어도 실제 환경에 적용하는 일은 전혀 다른 차원의 문제라, 그 지점에서 비용을 받을 수 있다는 것입니다. 그는 딥시크와 엔비디아가 다 공개한 것을 두고도 국내 기업들이 제 성능을 못 내는 현실을 예로 들었습니다. 따라만 해도 성능이 나와야 하는데, 돈을 들이고도 안 나오는 걸 보면 가져다 쓰는 일 자체가 만만치 않다는 것입니다.
학습은 책을 읽는 것과 같다
AI가 공개된 코드를 무단으로 학습하는 문제를 어떻게 보느냐고 물었습니다. 그의 입장은 분명했습니다.
“AI가 학습하는 걸 그냥 책 읽고 공부하는 걸로 생각하면 어떨까요. 결과물이 똑같이 나오면 그때 표절이라고 소송을 걸면 되는 거고요.”
만화가가 좋은 만화를 본다고 표절이라 하지 않듯, 학습 자체를 막아서는 안 된다는 것입니다. 다만 그는 곧바로 반대편 책임도 짚었습니다. AI 기업들이 허락 없이 데이터를 가져간 만큼, 모델과 데이터와 학습 방법을 더 많이 공개하는 책임을 져야 한다는 것입니다.
공개하면 누가 가져다 돈을 벌까 두려워 프라이빗으로 돌리는 사람들에 대해서는 한층 직설적이었습니다.
“코딩 에이전트는 다 쓰면서 자기 코드는 학습시키기 싫다는 건, 좀 양심이 없는 거죠.”
포크가 두렵다면 상업적 이용을 막고 변경 시 공개를 의무화하는 카피레프트 라이선스를 걸면 된다고, 해법은 이미 있다고 했습니다. 본인도 남의 아이디어를 가져다 쓰면서 자기 것만은 안 된다고 하는 건 모순이라는 말도 덧붙였습니다.
한국과 해외 사이
해외 개발자들과 자주 소통하는 그에게 한국과 해외 오픈소스 생태계의 차이를 물었습니다. 그는 한국 쪽을 잘 모른다는 말로 시작했습니다. 잘하는 사람이 해외에 압도적으로 많고, 유명하고 쓸모 있는 프로젝트도 그쪽에서 더 많이 나온다는 것입니다.
기업 단위로 운영되는 오픈소스가 한국에 드물다는 점도 짚었습니다. 삼성이 리눅스 재단에 가장 많이 후원하는 축이고 적지 않게 노력하는데도 그만큼 활성화되지는 않는다고 했습니다. 그는 한때 삼성 오픈소스 그룹 쪽에 잠깐 몸담으며 이미지 쇄신을 위한 시도들을 가까이서 봤지만, 쉽게 바뀌지 않더라고 회고했습니다.
“한국에는 오픈소스를 직접 해본 사람이 생각보다 별로 없어요. 깃허브에 많이들 올리긴 하지만, 그 비율 자체가 외국과 현저히 차이가 나죠.”
해본 사람의 절대 수가 적다는 것이 그가 본 근본적인 간극이었습니다. 인구도 적고, 오픈소스를 공개하는 일과 그것을 상업화하는 일 모두에 대한 두려움이 큰 것도 이유로 꼽았습니다.
그리고 커뮤니티
염기웅 님은 두 가지 면에서 솔직했습니다. 자기 작업의 한계를 가리지 않았고, 생태계를 향해서도 에두르지 않았습니다. 양심 없는 건 양심 없다고 했고, 멋있는 것과 돈이 되는 것이 다르다고 했고, 가능성은 있지만 시간과 자원이 없다는 말도 그대로 했습니다.
그가 꼽은 좋은 오픈소스의 조건은 클라우드브로가 프로젝트를 고를 때 보는 기준과 닮아 있습니다. 사람들이 실제로 쓰는가, 작은 문제라도 해결하는가, 영감을 주어 누군가 이어받게 하는가, 돈을 내고 쓸 수 있는가. 깃허브 별의 개수보다 이 네 가지를 먼저 본다는 점에서 그렇습니다.
클라우드브로가 글로벌 오픈소스 빌더들의 커뮤니티가 되기로 한 데에는 그런 이유가 있습니다. 멋이 없어 묻히지만 엔터프라이즈에서는 수요가 분명한 작업이 있고, 시간과 자원이 없어 가능성만 남은 실험이 있습니다. 혼자라서 더 멀리 가지 못하는 프로젝트도 많습니다. 그런 일을 빌더 혼자 떠안지 않도록 곁에서 지원하려 합니다.
메인테이너를 비롯해 오픈소스를 만드는 사람들이 메인이 되는 [메인터뷰] 의 다섯 번째 이야기는, 꼴찌가 되어 판 전체를 끌어올리겠다는 염기웅 님의 이야기로 채웠습니다.
참고 자료
-
모델 KoHRM-Text-1.4B : https://huggingface.co/LLM-OS-Models/KoHRM-Text-1.4B
-
참고 논문 HRM-Text : https://arxiv.org/abs/2605.20613
[메인터뷰] 는 클라우드브로 커뮤니티가 오픈소스 빌더들의 이야기를 기록하는 시리즈입니다. 다음 편에서 또 다른 빌더를 소개할게요!