AI 도구를 만들면서 내가 계속 망한 이유
이게 시작이었다.
모델을 바꾸고,
툴을 붙이고,
자동화를 얹고,
라우팅을 만들고.
그때마다 이렇게 생각했다.
“이제 좀 똑똑해졌겠지.”
근데 이상했다.
AI는 점점 많은 걸 할 수 있는데
나는 점점 더 헐떡였다.
내가 한 선택들은 전부 이유가 있었다.
이 기능은 필요했다.
저 구조도 합리적이었다.
이 결정도 최선이었다.
근데 전체는 꼬였다.
왜냐면
나는 안에서만 보고 있었기 때문이다.
내 목표는 단순했다.
AI가 똑똑하게 무언가를 하게 만드는 것.
그 AI를
어떻게 하면 덜 멍청하게 움직이게 만들 수 있을까.
나는 그걸 고민했다고 생각했다.
근데 나중에 보니
나는 AI를 똑똑하게 만든 게 아니라
AI를 관리하는 시스템을 키우고 있었다.
그래서 비교 대상을 들고 왔다.
하나는 OpenClaw.
요즘 아주아주 핫했던 놈이다.
기능 많다.
채널 많다.
플러그인 구조 있다.
세션 관리 있다.
중앙 게이트웨이가 있다.
딱 보면 이런 느낌이다.
“와, 이건 제대로 만든 플랫폼이네.”
다른 하나는 PicoClaw다.
비슷한 기능을 한다.
모델 바꿀 수 있고,
툴 쓸 수 있고,
채팅 연결도 된다.
근데 말도 안 되게 작다.
정적 바이너리 하나로 돈다.
빌드하면 18MB짜리 실행 파일이 나온다.
코어 루프가 하나다.
이건 이상하게 가볍다.
OpenClaw는 대략 30만 줄짜리 프로젝트다.
소스 디렉토리가 수십 개고,
채널 플러그인이 30개 넘는다.
테스트 커버리지도 강제한다.
이건 그냥 도구가 아니다.
하나의 플랫폼이다.
PicoClaw는 다르다.
빌드하면 실행 파일 하나다.
코어는 LLM 호출 → 툴 실행 → 결과 붙이기 → 다시 호출.
이 반복 하나로 돌아간다.
subagent도 같은 루프를 쓴다.
모델 여러 개를 설정에 등록해두고,
하나 실패하면 다음 모델로 넘어간다.
잠깐 쉬게도 만든다.
이건 플랫폼이 아니라
작은 런타임이다.
여기서 깨달았다.
AI를 똑똑하게 만드는 방법은 크게 두 가지다.
하나는 학교를 짓는 방식이다.
교장 만들고,
교감 만들고,
행정실 만들고,
시간표 짜고,
부서를 나눈다.
중앙에서 다 관리한다.
그걸 유식한 말로
플랫폼 아키텍처라고 한다.
다른 하나는
한 명이 문제를 잘 풀게 만드는 방식이다.
문제 풀고,
틀리면 다시 풀고,
안 되면 다른 방법 쓰고.
루프 하나를 단단하게 만든다.
그걸 유식한 말로
런타임 중심 설계라고 한다.
나는 AI를 더 똑똑하게 만들겠다고
기능을 붙였다.
근데 AI는 기능이 많다고 똑똑해지지 않는다.
AI는 결국
루프 안에서 돈다.
루프가 단순하면
문제가 생겨도 추적이 쉽다.
루프가 복잡하면
어디서 무엇이 꼬였는지
사람이 찾아야 한다.
OpenClaw는 중앙이 강하다.
모든 게 게이트웨이를 거친다.
세션이 나뉘고,
채널이 확장되고,
플러그인이 붙는다.
이건 학교다.
PicoClaw는 다르다.
루프 하나다.
모델은 설정으로 바꾸고,
안 되면 다른 모델로 가고,
잠깐 쉬었다가 다시 시도한다.
코어는 그대로다.
나는 뭘 하고 있었나.
학교를 만들고 있었다.
내 목표는
AI가 문제를 잘 풀게 만드는 것이었는데
나는 중앙 관리 시스템을 키우고 있었다.
코어는 안 줄이고
주변만 계속 키웠다.
그래서 복잡해졌다.
목표지점을 제대로 정하지 못하고 달리고 있던거다.
그래서 오픈클러도 피코클러도 되지 못하고 있었다.
그래서 헐떡였다.
둘 다 모델을 바꿀 수 있다.
둘 다 툴을 쓸 수 있다.
둘 다 채팅에 붙는다.
차이는 기능 수가 아니다.
차이는 코어의 크기다.
코어가 작으면
시스템은 커져도 버틴다.
코어가 크면
조금만 확장해도 복잡도가 폭발한다.
나는 그 차이를
혼자서는 못 봤다.
둘을 나란히 놓고 보니까
보였다.
나는 AI를 똑똑하게 만들고 싶다.
그럼 나는
학교를 만들어야 하는가,
아니면
문제 푸는 기계를 만들어야 하는가.
다음 편에서는
이걸 진짜 구조로 내려보려고 한다.
내가 만들 건
플랫폼인가,
코어가 작은 런타임인가.
그리고 그 선택이
바이브코딩을 계속 할 수 있게 만드는지,
아니면 또 한 번 나를 헐떡이게 만드는지.
이제 그 얘기를 해야 한다.