AI 유틸을 빠르게 많이 만드는 팀을 보면, 거기엔 보이지 않는 공통점이 있다. 거대한 플랫폼을 하나 더 키운 게 아니라, 규칙이 모인 얇은 키트와 계약을 먼저 만들었다는 점이다. 이 글은 50개의 미니앱을 하루 만에 만든 사례, 폴더 기반 1인 회사 운영, Hermes식 자기개선 루프, 그리고 stage routing이 왜 같은 방향을 가리키는지 묶어서 본다.
TL;DR
- AI 생산성의 핵심은 더 큰 챗봇이 아니라 더 얇은 에이전트 키트다.
- 좋은 키트는 프로젝트별 계약, 최소 메모리, 역할 분리, 검증 루프를 기본값으로 둔다.
- Frandeer 같은 유틸 사이트는 이 구조를 붙일수록 더 많이, 더 빨리, 더 안정적으로 만들 수 있다.
왜 지금 중요한가
예전에는 팀이 AI를 잘 쓴다고 하면 보통 “어느 모델을 쓰는가”부터 물었다. 지금은 그 질문만으로는 부족하다. 진짜 차이는 어떤 작업을 어떤 키트로 굴리느냐에서 난다.
하루에 수십 개의 미니앱을 만들거나, 1인 회사처럼 파일을 읽고 쓰며 운영하거나, 자기개선 루프를 돌리는 에이전트를 쓰는 사람들을 보면 공통점이 하나 있다. 모델을 만능으로 믿지 않고, 작업 단위를 쪼개고 계약을 붙이고 검증면을 설계한다.
이게 바로 플랫폼보다 키트가 먼저인 이유다.
핵심 흐름
1. 50개의 미니앱을 만든 비결은 “프롬프트 한 방”이 아니었다
앱인토스 미니앱 사례에서 중요한 건 숫자 자체가 아니다. 중요한 건 흩어진 요구사항을 한곳에 묶는 방식이다.
- 제품 정책
- 한국어 UX 문구
- 디자인 규칙
- 스토어 자산
- 콘솔 메타데이터
보통 에이전트에게 일을 시키면 이 중 하나는 빠진다. 그런데 규칙을 모아두고, AGENTS.md를 루트 계약으로 두고, 작업별 라우팅까지 넣으면 상황이 달라진다. 에이전트는 “기억”으로 움직이는 대신, 읽어야 할 문서와 따라야 할 절차로 움직인다.
즉, 속도의 원천은 모델이 아니라 키트화된 작업 흐름이다.
2. 1인 회사는 대화창이 아니라 폴더에서 굴러간다
Claude Cowork 류의 워크스페이스는 이 관점을 더 분명하게 보여준다. 대화창에서는 질문만 오간다. 하지만 폴더 기반 워크스페이스에서는 파일이 곧 계약이 된다.
예를 들면 이런 식이다.
ABOUT ME— 누구인지, 어떻게 일하는지anti-ai-writing-style— 절대 쓰면 안 되는 문체my-company— 무엇을 하고 무엇을 하지 않는지
이 구조가 좋은 이유는 간단하다. 에이전트가 매번 사용자를 다시 인터뷰하지 않아도 되기 때문이다. 그리고 사용자는 “좋은 답변”이 아니라 좋은 운영체계를 얻게 된다.
Frandeer도 마찬가지다. 블로그, 유틸, QA, 배포를 하나의 대화창에서 처리하려고 하면 금방 꼬인다. 반대로 작업별 폴더와 계약을 두면, 에이전트는 매번 같은 방식으로 읽고, 같은 방식으로 쓰고, 같은 방식으로 검증할 수 있다.
3. Claude.md 최소 설계는 기억보다 신호가 중요하다는 뜻이다
많은 사람이 에이전트용 규칙 파일을 두껍게 만들고 싶어한다. 이유는 이해된다. “혹시라도 빠뜨리면 안 되니까”라는 불안 때문이다. 하지만 실제로는 반대다. 너무 많은 규칙은 에이전트를 똑똑하게 만들지 않고, 컨텍스트만 죽인다.
핵심은 세 가지다.
- 세션마다 반드시 필요한 것만 남긴다.
- 나머지는 reference로 빼고 경로를 명시한다.
- 스타일과 보편론은 과감히 버린다.
이건 단순한 미니멀리즘이 아니다. 읽히는 규칙만이 규칙이라는 현실론이다.
Frandeer가 많은 유틸을 운영하려면, 긴 규칙집보다 짧은 핵심 규약이 낫다. 에이전트는 인간처럼 “대충 알아서” 해주지 않는다. 읽을 수 있는 신호만 먹는다.
4. Hermes와 Fusion이 보여주는 건 모델이 아니라 역할 분리다
Hermes류 시스템은 self-improvement loop, skill, memory, cron, routing을 한 시스템으로 묶어 보여준다. Devin Fusion 계열의 흐름도 비슷하다. 흥미로운 건 둘 다 “더 큰 모델”을 외치지 않는다는 점이다.
대신 이렇게 말한다.
- 모호함과 최종 판단은 강한 모델이 잡는다.
- 기계적인 실행은 가벼운 모델이 맡는다.
- 검증과 요약은 별도 단계로 둔다.
이 구조는 아주 중요하다. 왜냐하면 실제 작업에서 병목은 보통 하나가 아니기 때문이다. 계획, 실행, 검증, 재시도는 각각 다른 종류의 지능을 요구한다.
즉, 좋은 에이전트 키트는 한 에이전트에게 다 시키지 않는다. 대신 stage routing을 기본값으로 둔다.
5. 검증 루프가 붙어야 키트가 제품이 된다
키트가 진짜 강해지는 순간은 실행이 아니라 검증이 붙을 때다.
예를 들어 다음과 같은 순서가 있어야 한다.
- 무엇을 만들지 정한다.
- 무엇이 맞는지 본다.
- 틀리면 왜 틀렸는지 기록한다.
- 다시 고친다.
- 다시 확인한다.
이게 없으면 에이전트는 단지 빨리 반복하는 기계가 된다. 빨리 반복하는 것과 빨리 개선하는 것은 전혀 다르다.
Frandeer 같은 유틸 사이트는 이 차이를 노출할 수 있어야 한다. 결과만 보여주지 말고, 비용, 검증, provenance, 실패 상태까지 보여줘야 한다. 그래야 사용자는 “AI가 마법처럼 해냈다”가 아니라 이 도구가 어떻게 믿을 만한지 이해한다.
Frandeer 사업에 주는 힌트
이 신호를 제품으로 바꾸면 꽤 명확하다.
- 공통 agent kit를 먼저 만든다.
- 유틸별로 짧은 계약 파일을 둔다.
- 생성 모델과 검증 모델을 분리한다.
- 메모리는 줄이고 경로는 명시한다.
- 결과 화면에 검증 상태와 provenance를 붙인다.
이렇게 하면 단순한 유틸 사이트가 아니라, 작업을 작게 분해해서 안정적으로 많이 만드는 인터넷 비즈니스가 된다.
바로 해볼 실험
오늘 당장 할 수 있는 실험은 세 단계다.
- 다음 유틸 하나를 고른다.
contract / generate / verify / publish네 단계로 쪼갠다.- 각 단계에 읽을 문서와 성공 기준을 한 줄씩 붙인다.
이 실험은 작아 보이지만 효과는 크다. 에이전트는 더 길게 생각해서 강해지는 게 아니라, 더 잘 정의된 문제를 더 정확한 키트로 풀 때 강해진다.
리스크 / 반론
물론 키트가 지나치게 무거워지면 오히려 배보다 배꼽이 커진다.
- 규칙이 많아지면 유지비가 생긴다.
- 검증이 과하면 속도가 떨어진다.
- 지나친 분리는 운영 복잡성을 키운다.
그래서 핵심은 균형이다. 키트는 두껍게가 아니라 얇고 정밀하게 설계해야 한다.
결론
AI 시대의 승부는 “더 똑똑한 챗봇을 갖고 있느냐”가 아니다. 승부는 “작업을 잘 쪼개고, 계약을 잘 붙이고, 검증 루프를 얼마나 얇게 운영하느냐”다.
플랫폼은 나중에 커질 수 있다. 하지만 처음부터 플랫폼을 만들 필요는 없다. 먼저 만들어야 하는 건 에이전트 키트다. 그리고 그 키트가 쌓이면, 그제서야 진짜 플랫폼이 된다.