진정한 AI OS를 향하여

5일전쯤에 indiebizOS라는 AI 시스템을 위한 언어인 ibl을 만들고 그걸 최적화하고 있다는 말씀을 드린 적이 있습니다. 오늘은 그 최적화에 대한 이야기를 좀 더 해볼까 합니다.

 

AI 시스템을 만들면 우리는 그것이 여러가지 일들을 처리하기를 바랍니다. 제가 아는 한 그렇게 하는 단순하지만 가장 강력한 방법은 파이선 실행기를 도구로 만들고 AI에게 주는 겁니다. 그러면 AI가 파이선이라는 언어로 프로그램을 짜서 파이선 실행기로 실행을 해서 사용자가 원하는 일을 해줄 수 있으니까요. 물론 C나 베이직같은 다른 언어도 원칙적으로 되지만 그런 언어는 코드량이 길어져서 AI가 짜기 더 힘들고, 라이브러리같은게 파이선이 가장 잘되어 있다고 하더군요. 그러니까 AI에게 어떤 문제를 어떻게 풀건가를 설명해 주는 문서라고 할 수 있는 스킬을 주고 자 이제부터 파이선으로 코딩을 해서 그 일을 해줘라고 하면 원칙적으로 못하는 일이 없어지는 겁니다. 현실적인 제약은 있지만 원칙적으로는 그렇다는 거죠.

 

openclaw같은 에이전트 시스템은 이렇게 스킬을 써서 일을 합니다만 클로드 데스크탑처럼 mcp서버들을 만들어서 AI 에게 주는 방법도 있습니다. 그런데 스킬이건 mcp 서버건 결국 문제를 해결하는 도구를 주는 것인데 여기에는 문제가 있습니다. 우리가 여러가지를 시도하면 그 도구의 수가 급격히 올라간다는 겁니다. 이건 AI가 코딩을 해주는 시대이기 때문에 더 그렇습니다.

 

예를 들어 제가 3개월동안 indiebizOS를 만들면서 이런 저런 일을 시도해 보고 그때마다 만들어져서 저장되어진 도구의 수는 300개가 넘습니다. 뭐 이렇게 많냐고 하실지 모르지만 첫째로 복잡한 일을 시도하면 그게 작은 도구들을 많이 요구하게 됩니다. 예를 들어 안드로이드 폰을 AI가 설정하는 기능을 구현했더니 도구가 몇십개가 생기더군요. 둘째로 여러가지 정보 소스를 사용하면 그 정보 소스 하나 하나가 하나의 도구가 됩니다. 그러니까 api를 호출하는 곳이 하나 늘어날때 마다 도구가 하나 이상늘어납니다. 그런데 정보는 많으면 많을 수록 좋기 때문에 쉽게 도구 숫자가 올라가는 겁니다. 물론 이 이유 이전에 더 근본적인 이유는 AI가 코딩을 해주니까 빠르게 도구를 개발할 수 있어서 그렇죠. 그냥 말만하면 만들어 주니까요. 예를 들어 제가 말만하면 적당한 유튜브 음악을 틀어주면 좋겠다라고 말하면 그게 도구 개발로 이어지니까요. 우리동네 아파트 실거래가를 알고 싶은데라고 하면 그게 도구개발이 됩니다.

 

이것은 제가 아는 한 AI 에이전트 시스템이 모두 공유하는 고질적인 문제입니다. 도구의 숫자는 빠르게 늘어납니다. 사실 지금 PC에 프로그램이 몇개나 설치되어 있냐만 보셔도 알 수 있습니다. 누가 당장 안쓰면 프로그램을 지웠다가 필요할 때마다 프로그램을 새로 깝니까. 그러니까 시간이 지나면 PC에 프로그램들이 잔뜩 깔리죠. 마찬가지인 겁니다. AI 에이전트에게 이것 저것 시키다보면 도구는 빠르게 늘어납니다.

 

이 문제를 해결할 수 있는 한가지 방법은 애초에 파이선 실행기같은 도구만 있고 다른 도구는 없는 겁니다. 그럼에도 불구하고 AI가 굉장히 똑똑하고 빠르면 즉석에서 개발을 다하고 일을 해내는 것이 가능할 지도 모릅니다. 하지만 이건 아무리 AI가 똑똑해진다고 해도 비현실적 일것같습니다. 같은 일을 하는데 매번 프로그램을 다시 다 짜서 테스트하고 그걸 다시 돌리는 일을 반복하는게 현실적일 수 없을 것같기 때문입니다. 토큰 낭비로 돈도 나갈 겁니다. 설사 돈문제가 아니더라도 속도가 미리 짜둔 프로그램으로 일하는 것보다 빠를 수는 없습니다.

 

그렇지만 도구를 많이 쓰면서 그걸 전부 기억한 채 일을 하라고 하면 그건 그것나름대로 토큰 낭비가 심하고, 더구나 AI가 외워야 할게 너무 많아서 혼동을 하기 쉽습니다. 그래서 openclaw같은 에이전트 시스템은 스킬들을 미리 다 외우게 하는게 아니라 사용자가 명령을 하면 검색으로 적당한 스킬 문서를 찾아다가 읽게 하는 방식을 씁니다.

 

이와 다르게 접근하는 방법은 도구의 전문화입니다. 에이전트들이 전문화해서 각자 서로 다른 도구를 가지고 위임에 의해서 일을 할 수 있게 하는 겁니다. 에이전트는 그 페르소나를 만들어서 전문화하는 방향이 있고, 도구가 달라서 전문화할 수도 있습니다. 여기서 말하는 것은 도구의 전문화입니다. 페르소나 전문화는 AI 에이전트에게 너는 요리사다라던가 너는 최고의 학자다라고 말해주는 거지요.

 

그런데 이 문제를 한발짝 뒤로 물러서서 보면 우리는 이게 결국 복잡한 시스템의 문제라는 것을 느끼게 되고 우리가 AI를 바로 그것 때문에 만들었다는 것을 기억해 내게 됩니다. 즉 AI 시스템이 마치 버튼이 수천개 달린 복잡한 자판기처럼 변했다면 그 자판기 버튼을 잘 누르는 AI를 또 만들면 되는 겁니다. 실제로 Gollia LLM이나 ToolLLM은 api 호출을 수천개 하는 문제를 파인 튜닝으로 즉 AI를 학습하는 방법으로 풀었다고 하더군요.

 

이렇게 시스템의 효율이 올라가서 그 시스템을 관리하는 시스템이 생겨나는 현상은 처음있는 일은 아닙니다. 컴퓨터의 역사를 보면 처음에는 사람이 천공카드에 구멍을 뚫어서 프로그래밍을 했었죠. 2진수 프로그래밍입니다. 하지만 컴파일러가 나오니까 이제는 인간이 쓰는 텍스트가 기계어로 바뀌게 되고 따라서 복잡한 프로그램을 할 수 있게 되었습니다. 복잡한 프로그래밍이 흔해지니까 이제는 그걸 다루기 위해서 OS가 나왔습니다. 그리고 OS가 복잡해지니까 가상환경이라는게 나왔고, 가상환경을 수천개씩 다를 수 있는 쿠버네티스라는 것도 나왔다고 하더군요. 차이가 있다면 이 과정이 컴퓨터의 경우에는 수십년간의 기간동안 일어난 것인데 AI 시스템에서는 몇년만에 일어나고 있다는 것입니다. 왜냐면 개발속도가 다르니까요.

 

저는 이 AI 시스템의 고질적인 문제를 저 나름대로 풀었습니다. 첫째로 그건 AI 에이전트 시스템을 위한 언어를 만드는 일이었습니다. 모든 도구 (혹은 액션, 혹은 스킬, 혹은 MCP)들이 서로 완전히 독립적이라면 언어가 별 의미가 없지만 우리는 복잡한 일들을 작은 원자적 액션으로 자르고 그걸 액션의 합들로 나타낼 수 있습니다. 그러면 복잡한 일은 원자적 액션들로 표현할 수 있는 합성액션이 되겠죠. 예를 들어 유튜브에서 자막을 받아서 요약하는 일과 유튜브에서 음악을 골라서 재생해 주는 일은 모두 유튜브 검색이라는 원자적 액션을 포함합니다. 그래서 이렇게 원자적 액션들을 찾아서 그걸 하나 하나 단어처럼 여기고 그 단어들을 이어 붙이는 것을 코딩으로 여길 수 있습니다. 그게 AI 에이전트 시스템을 위한 DSL(domain specific language)입니다. 저의 경우는 이 DSL을 ibl이라고 이름붙였죠. 사실 정확히 말하면 AI가 이름붙였습니다만.

 

ibl을 만들고 나서 이제 AI 시스템은 마치 파이선 실행기를 도구로 가지듯이 ibl 실행기를 도구로 가지게 됩니다. 그러면 ibl로 코드를 짜서 일을 수행하는 것이죠. 저는 몇번 써본 후에 파이선, node.js 그리고 쉘명령어 실행기들도 ibl과 같은 레벨로 올렸습니다. 그러니까 AI 에이전트들은 이런 언어들의 실행기를 도구로 가지게 됩니다. 차이가 있다면 AI 에이전트들은 파이선같은 다른 언어에 대해서는 학습을 했는데 ibl은 처음 보는 거라는 거죠. 그래도 언어가 간단해서 몇가지 예만 주면 어느 정도는 바로 쓸 수 있습니다. 그 덕에 ibl을 도입한 후 저는 모든 도구를 하나의 에이전트에게 다 줄 수 있었습니다. 320개 액션들을 다 할 수 있게 되니까 나름 편한 것도 많더군요. 전문화라는게 여전히 의미가 있지만 그래도 도구때문에 제한되지는 않으니까요.

 

하지만 앞으로 도구의 수는 점차 더 늘어날 것이 뻔하고, ibl을 학습하지 않은 AI 에이전트가 ibl을 효율적으로 쓰지 못하는 문제가 없지는 않아서 저는 두번째 방법을 더했습니다. 그건 ibl을 효율적으로 사용하는 예들을 축적해서 검색하고 그걸 예제로 그때마다 주는 rag 시스템을 더한 겁니다. 처음에는 가상으로 만든 데이터에 의존하지만 시스템을 쓰면서 성공한 예들은 DB에 저장되어 미래에 참조하는 데이터가 됩니다. AI 에이전트 시스템이 점점 똑똑해지는 거죠. 가장 직접적인 접근 방식은 ibl 이라는 언어를 AI가 파인튜닝으로 학습하는 것입니다만 사실 여기에는 문제가 많습니다. 도구는 차차 늘어나는데 그때마다 파인튜닝을 하기도 어렵고 그렇게까지 되면 너무 시스템이 거창해질 것같았습니다. 그래서 rag 시스템이 언어 학습을 대체하게 한 것이죠.

 

AI와 상담을 나눠본 결과 이 분야는 너무 새로워서 아직 이 문제를 본격적으로 풀려고 해 본 사람도 없다더군요. 물론 저처럼 어디 구석에서 해보고 있는 사람들은 있겠죠. 저는 제 방법이 가장 옳은지는 모르겠습니다. 다만 지금 생각으로는 괜찮은 방법이라고 생각합니다. 그리고 제 해법이 정답인가와 상관없이 이 문제는 회피할 수 없고, 풀어야 할 문제라고 생각합니다. 앞에서 말씀드린 것처럼 컴퓨터의 역사에서도 있었던 일이니까요.

 

사람들이 AI OS 이야기를 하기 시작한지는 1년도 안된 것같습니다. 그리고 아직 이것이 AI OS의 표준이라고 말할 만한 것이 나타나지도 않았습니다. 하지만 이 다수의 도구를 다루는 문제는 AI OS가 풀어야 할 문제입니다. 말씀드렸듯이 PC 쓰다보면 계속 프로그램 설치하지 않습니까? 이 문제를 제대로 해결하지 않고 대중이 AI 에이전트 시스템을 쓰기는 어려울 것입니다. 이걸 뒤집어 말하면 사람들이 대중적으로 쓰는 AI OS의 출현이 임박했다는 뜻이기도 하지요. openclaw가 이미 꽤 인기가 좋지만 그 정도로는 대중화되어 쓸모 있게 쓰는데에 한계가 있을 것입니다.