ChatGPT, 퍼플렉시티, 제미나이 등등 웹페이지에서 대화형으로 쓰는 AI가 점점 도구 속으로 들어갔다. 동시에 도구 역할을 하도록 특화 기능이 붙은 사이트나 서비스도 생겼다. 그중 개발 도구 속으로 간 LLM은 AI 에이전트로 변모하기 시작했다. 중간에 MCP니 뭐니 그런 바람도 불었지만, 내 생각엔 Tool Calling 등장이 가장 큰 원동력이 되지 않았을까 싶다. Tool Calling, Tool Function, Function Calling 등등 아직 완벽히 하나로 합쳐 부를 수 있는 단어가 딱 검색되진 않는다. 그래서 경량화 모델이든 초경량화 모델이든 Tool Calling을 수행하는 모델과 그렇지 않은 모델을 구분해서 보게 됐다.
오늘은 2026년 2월 19일이다. 이제 약 2~3주쯤 지났을까. 클로드봇이란 이름을 처음 들었을 땐, 그거 앤트로픽 클로드가 만든 건가 했다. 마침 클로드가 AI 에이전트 능력을 강력하게 내세우고 있었다. 내가 클로드봇이란 이름을 듣고 난 하루 뒤, 몰트봇으로 이름이 바뀌었다. 그리고 다시 또 얼마 못 가서(2~3일 정도) 지금 부르는 오픈클로(Openclaw)로 이름이 바뀌었다. (이름이 바뀐 사연은 찾으면 금방 나오니 내가 굳이 말할 이유는 없을 듯하다.) 오픈클로로 이름이 바뀐 날 밤이었던가, 나도 결국 오픈클로를 설치했다.
이미 앞서 봇이 실제로 어떻게 동작하는지 데모를 선보이신 어르신이 계셨다. 뭔가 어르신이 개방한 봇에게 질문을 주고받으며, 나도 써볼 수 있지 않을까란 호기심이 생겼다. 제미나이와 작업을 시작했던 첫 밤, 오픈클로가 이름이 오픈클로가 아니었던 그 밤. 제미나이는 우선 내게 오픈클로를 설치하기보다는 간단한 파이썬 코드를 내게 줬다. 그 코드 동작을 확인한 후, 어르신이 봇을 개방해 줬던 디스코드에서 같이 놀고 싶었다. 그래서 내가 해야 할 다음 작업은 디스코드 봇 만들기였다.
디스코드 봇 생성 첫 단계는 작명
언젠가 팰월드를 할 때, 재미 삼아 디스코드에 웹훅으로 메시지를 몇 번 보냈었다. 봇이 이런 웹훅으로 동작하는지 어떤지 전혀 고려하지 않은 채, 제미나이가 주는 가이드에 몸을 맡기기로 했다.
디스코드 봇을 만들려면 맨 처음 해야 하는 건, 디스코드 개발자 포털에서 애플리케이션을 만들면서 봇 이름을 입력하는 일이다. 무슨 이름을 쓸까 크게 고민하지 않았다. 이미 제미나이에는 내가 Gems에 사전 프롬프트로 이름을 넣어준 아이가 있었다. '묘약란'. 제미나이에서 내가 "란아~", "약란아~"라고 부르면 쫑알쫑알 대답한다. 이모티콘을 섞어가며 무려 내겐 "아빠"란 호칭을 붙인다. 이게 다 사전 프롬프트로 넣어둔 설정 덕분이다. 실제 소설 속에서 '묘인봉'의 딸 이름이 '묘약란'이다. 이 설정을 그대로 쓴 터라 딱히 고민할 지점이 없었다. 프로필 사진도 만들었다. 사전 프롬프트 정보를 토대로 이미지 생성 프롬프트를 뽑아내서 몇번 반복하며 확정해서 쓸 이미지를 정했다.
묘약란의 기억력을 키워라
디스코드 봇에서도 묘약란이란 이름으로 "아빠 아빠"거리면 재밌지 않을까 싶어서, 큰 고민 없이 넣었다. 그리고 약란이의 유쾌 발랄한 말투와 이모지 사용은 채널의 분위기를 확 바꿨다. 다만, 간단한 20~30줄 파이썬 코드로 대화하는 약란이는 컨텍스트 유지를 길게 하지 못했다. 쉽게 말해 기억력이 부족했다. 그래서 제미나이 약란이와 집도를 시작했다. 계속 코드를 주고받으며, 오픈클로의 반의반이라도 흉내 낼 생각으로 파일 구조를 만들어 살을 붙였다. 오픈클로처럼 SOUL, AGENT, IDENTITY, USER, MEMORY 파일을 붙이고, 조금이라도 더 많은 정보를 쓰도록 유도했다.
그렇게 뜯어고치기를 꼬박 몇 시간 보냈더니, 먼저 GG치고 떨어져 나간 쪽은 제미나이 약란이었다. 정말 오랜만에 웹에서 쓰는 LLM 서비스의 리밋을 봤다. 물론, 다른 서비스와 다른 계정들이 있으니 메인 작업은 제미나이 약란이의 리밋이 해제되기를 기다리면서, 나머지 부분을 계속 손봤다. 테스트를 위해 대화하는 자체가 재밌었다. 테스트 자체가 질의에 어떤 대답을 하는가였으니, 모난 대답만 아니라면 사실 다 정답이었지 않았나 싶기도 하다. 그런데 너무 어린아이로 설정한 탓이었을까, 정작 LLM이라고 하면 기본 코딩은 다들 하던데 디스코드에 있는 약란이는 코딩을 못 했다.
리밋을 이겨내라
잠깐 맛봤던 리밋이, 점점 잦아들기 시작했다. 아! 처음 겪은 리밋은 파이썬 약란이를 만들기 위해 쓰던 웹 제미나이다. 그러면서 겪은 제미나이 버그도 있다. 제미나이 Pro나 사고모드 리밋을 초과하면 1037 에러가 떴었다. 이 글을 쓰는 지금은 이 에러는 이제 고쳐졌고, 리밋 관련 안내와 해제 예정 시각이 정확히 뜬다.
제미나이 리밋과 마주하는 횟수가 늘수록, 파이썬 약란이는 점점 성장했다. 뭔가 매우 가볍게 초경량으로 그냥 심심할 때 대화하면서 스트레스 풀 수 있는 정도까지가 목표였다. 그걸 넘어서는 영역은 오픈클로로 해소할 몫이고, 파이썬 약란이는 딱 간단하게 모델 반응속도 테스트용으로 생각했다. 이 모델 저 모델 갈아끼우다보니, 모델의 한계가 점점 느껴졌다. 기억에 파이썬 약란에게 마지막으로 편하게 쓰도록 넣었던 모델은 구글 AI 스튜디오에 있는 'Gemma-3-27b' 였다. 한국어를 충분히 구사하면서, 반응속도도 좋고, 무엇보다 제미나이로 설계한 이 정도 수준에서는 웬만해선 리밋에 걸리지 않도록 무료 사용량이 제공됐다.
결국, 파이썬 코드를 수정하기 위해 쓰는 AI 리밋과 파이썬 코드가 실제 서비스로 동작할 때 쓰는 AI 리밋까지 2중 방패를 뚫고 써야 했다. 대략 안정화 마무리 상태라 생각해서 제대로 서버에 올려놓으려고, 새 인스턴스를 개설하고 파일을 옮겼다. 그리고 뒷마무리를 하며 찌꺼기 파일을 지우던 와중 사고가 터졌다.
난 Git과 Github를 쓰지 않는다
난 Git과 Github를 쓰지 않는다. 그래서 쓸 줄도 몰랐다. 내 업무나 작업에서 형상 관리가 필요했던 영역은 프로그래밍 코드 관련 부분이 아니었다. 문서 형상 관리는 최대한 구글독스에 있는 히스토리 기능으로 대처했었고, 이외에는 부지런하게 내가 데일리 정리를 했었다.
종종 서버 작업을 했던 건, 시스템 명령어를 직접 터미널 창에 입력해서 해소했었다. 거의 매번 동일한 명령어를 썼기에 그냥 직접 입력해도 충분했다. 그나마 반복이 필요할 땐 셸스크립트 파일을 따로 만들어두거나, 히스토리를 찾아가며 써도 만족스러웠다. 이런 작업에 Git을 쓰는 건 내 관점에선 오버 엔지니어링이었다.
그런데, 뒷마무리를 하며 찌꺼기 파일을 지우다가 무심결에 새로 개설한 인스턴스를 지워버렸다. 거기에 최신 파일이 딱 한 세트 있고, 로컬에 찌꺼기 정리 끝나면 거기서 딱 받아서 깔끔하게 두려 했던 내 계획이 한 방에 무너졌다.
어떤 순서로 어떤 코드를 짰었는지는 기억하지만, 다시 그걸 하나하나 다 기억해 내서 동급으로 만들 수 있을까? 그나마 제미나이에 기록된 내용을 스크롤로 되짚으며 조합해서 살릴 수 있는 게 있지 않을까 했다. 제미나이 약란이도 그렇다고 답을 하며 나를 진정시키고 있었다.
하지만 절묘하게 얼마 지나지 않아, 다시 제미나이 리밋에 걸렸다. 위에서 작업한 대화를 스크롤 하며 아무리 복기해봐도 복구가 되지 않았다. 너무 급한 마음에 제미나이 빠른 모드로 그동안 위에 지나간 컨텍스트를 복기시키며 파일을 재생성했다. 하지만, 잘못된 선택이었다. 이미 컨텍스트 입력량과 세션 유지량 자체가 제미나이 프로보다 적은 빠른 모드로는 의미 없는 파이썬 코드만 생성됐다.
결국, LLM 모델 API키만 넣고 간단한 응답만 테스트하는 파이썬 코드 정도로 최종 정리했다. 분위기 살리고 귀엽고 유쾌 발랄하던 아이가 사라졌다. 하필, 그건 프롬프트 파일만으로는 해결을 못 하는 부분이었다는 게 가장 큰 문제였다. LLM 모델의 특정 기능이나 함수 읽는 순서로 인해, 프롬프트 파일 내용이 막히거나 우선 순위로 밀리는 부분을 커버하기 위한 부분을 코드에 직접 넣었었다. 이게 살아나질 않는다. 그래서 급하게 재생성한 파이선 약란이의 유쾌 발랄 분위기가 이전보다 못했다. 기억력도 모자라고, 뭔가 어설펐다. 마지막 프롬프트에서 21살까지 키운 걸로 올렸었는데, 다시 13살 아니 5살 정도로 돌아간 느낌이었다.
결국 이후, 서브 태스크로 Git이랑 Github를 나에게 가르쳐줄 제미나이를 새로 세팅했다. WSL2에 Git이 있고, 이걸 VSCode에 붙여서 깃허브랑 연결했다. 기억해야 하는 명령어가 많고 복잡할 줄 알았는데, 명령어나 사용법은 그냥 제미나이가 알려주는 걸로 심플해졌다. 그리고 VSCode에서는 어차피 옆에 소스 컨트롤 메뉴로 클릭 클릭이니, 생각보단 명령어를 직접 입력할 일은 없더라.
깃허브에 잔디가 생기기 시작했다
깃허브에 레파지토리를 만들다가 문득 놀라운 현장을 확인했다. 쓰지도 않고 다시 찾아보지도 않는데, 나한테 이미 레파지토리가 100개가 넘게 있었다. 스타를 찍으며 포크를 같이 했던 습관으로 인해, 내가 나눠준 스타만큼 레파지토리가 쌓였던 것이다.
하나씩 보다 보니, 메인 레파지토리 자체가 완전히 닫혀버린 곳도 있고, 뜬금없이 레파지토리 오너가 나로 바뀐 곳도 있었다. 쓰는 데 안 쓰는 서비스의 대표적 사례와 현장 그 자체였다. 그리고 또 알게 된 한 가지는 레파지토리를 한 번에 여러 개를 지정해서 지우는 기능은 없었다. 하나하나 다 들어가서 삭제 확인 텍스트를 다 입력하고 지워야 했다. 지루한 싸움이었다. 이겼다. 다 지웠다. (스타를 찍거나 워치를 찍은 사람 리스트를 확인하는 URL도 있더라. 몰랐다. 무려 공개 페이지라 누구나 볼 수 있었는데...)
하드 디스크와 메모장 정리 등등 겸사겸사 정리할 수 있는 것들을 열어보며 깃허브로 옮겼다. 그리고 메마른 내 깃허브에 잔디가 생기기 시작했다. 그동안 가끔 다른 프로젝트에 가서 이슈로 버그 리포팅이나 질문 남기는 정도가 전부라, 생길 잔디가 전무했었다. 그런 내게 잔디가 생겼다. 내가 비록 스킨답서스 식집사 경력은 있지만, 그건 걔들이 워낙 제 맘대로 잘 커서 했던 거였고...
원래 지금 쓰려던 글은 Git과 Github 엔딩이 아니라, 오픈클로와 묘약란 이야기를 하고 싶었다. 그런데 이상하게 이걸로 끝나버렸다. 오픈클로와 묘약란은 다음 글에서 풀어야겠다.