AI 유틸 50개를 만들려면 플랫폼부터 만들면 안 된다

하루 만에 미니앱 50개를 만든 팀의 비밀은 거대한 플랫폼이 아니었다. 반복되는 규칙을 얇은 키트와 계약으로 고정했기 때문에 매번 처음부터 설계하지 않았다. 여러 AI 유틸을 빠르게 출시하려는 팀이라면 무엇을 공통화하고 무엇을 끝까지 분리해야 하는지 이 글에서 확인할 수 있다.

TL;DR

AI 생산성의 핵심은 더 큰 챗봇이 아니라 더 얇은 에이전트 키트다.
좋은 키트는 프로젝트별 계약, 최소 메모리, 역할 분리, 검증 루프를 기본값으로 둔다.
작은 AI 제품을 많이 만드는 팀은 공통 키트와 작업별 계약을 분리할수록 더 빨리 안정화된다.

왜 지금 중요한가

예전에는 팀이 AI를 잘 쓴다고 하면 보통 “어느 모델을 쓰는가”부터 물었다. 지금은 그 질문만으로는 부족하다. 진짜 차이는 어떤 작업을 어떤 키트로 굴리느냐에서 난다.

하루에 수십 개의 미니앱을 만들거나, 1인 회사처럼 파일을 읽고 쓰며 운영하거나, 자기개선 루프를 돌리는 에이전트를 쓰는 사람들을 보면 공통점이 하나 있다. 모델을 만능으로 믿지 않고, 작업 단위를 쪼개고 계약을 붙이고 검증면을 설계한다.

이게 바로 플랫폼보다 키트가 먼저인 이유다.

핵심 흐름

1. 50개의 미니앱을 만든 비결은 “프롬프트 한 방”이 아니었다

앱인토스 미니앱 사례에서 중요한 건 숫자 자체가 아니다. 중요한 건 흩어진 요구사항을 한곳에 묶는 방식이다.

제품 정책
한국어 UX 문구
디자인 규칙
스토어 자산
콘솔 메타데이터

보통 에이전트에게 일을 시키면 이 중 하나는 빠진다. 그런데 규칙을 모아두고, AGENTS.md를 루트 계약으로 두고, 작업별 라우팅까지 넣으면 상황이 달라진다. 에이전트는 “기억”으로 움직이는 대신, 읽어야 할 문서와 따라야 할 절차로 움직인다.

즉, 속도의 원천은 모델이 아니라 키트화된 작업 흐름이다.

2. 1인 회사는 대화창이 아니라 폴더에서 굴러간다

Claude Cowork 류의 워크스페이스는 이 관점을 더 분명하게 보여준다. 대화창에서는 질문만 오간다. 하지만 폴더 기반 워크스페이스에서는 파일이 곧 계약이 된다.

예를 들면 이런 식이다.

ABOUT ME — 누구인지, 어떻게 일하는지
anti-ai-writing-style — 절대 쓰면 안 되는 문체
my-company — 무엇을 하고 무엇을 하지 않는지

이 구조가 좋은 이유는 간단하다. 에이전트가 매번 사용자를 다시 인터뷰하지 않아도 되기 때문이다. 그리고 사용자는 “좋은 답변”이 아니라 좋은 운영체계를 얻게 된다.

작은 팀도 마찬가지다. 블로그, 유틸, QA, 배포를 하나의 대화창에서 처리하려고 하면 금방 꼬인다. 반대로 작업별 폴더와 계약을 두면, 에이전트는 매번 같은 방식으로 읽고, 같은 방식으로 쓰고, 같은 방식으로 검증할 수 있다.

3. Claude.md 최소 설계는 기억보다 신호가 중요하다는 뜻이다

많은 사람이 에이전트용 규칙 파일을 두껍게 만들고 싶어한다. 이유는 이해된다. “혹시라도 빠뜨리면 안 되니까”라는 불안 때문이다. 하지만 실제로는 반대다. 너무 많은 규칙은 에이전트를 똑똑하게 만들지 않고, 컨텍스트만 죽인다.

핵심은 세 가지다.

세션마다 반드시 필요한 것만 남긴다.
나머지는 reference로 빼고 경로를 명시한다.
스타일과 보편론은 과감히 버린다.

이건 단순한 미니멀리즘이 아니다. 읽히는 규칙만이 규칙이라는 현실론이다.

여러 유틸이나 반복 업무를 운영하려면, 긴 규칙집보다 짧은 핵심 규약이 낫다. 에이전트는 인간처럼 “대충 알아서” 해주지 않는다. 읽을 수 있는 신호만 먹는다.

4. Hermes와 Fusion이 보여주는 건 모델이 아니라 역할 분리다

Hermes류 시스템은 self-improvement loop, skill, memory, cron, routing을 한 시스템으로 묶어 보여준다. Devin Fusion 계열의 흐름도 비슷하다. 흥미로운 건 둘 다 “더 큰 모델”을 외치지 않는다는 점이다.

대신 이렇게 말한다.

모호함과 최종 판단은 강한 모델이 잡는다.
기계적인 실행은 가벼운 모델이 맡는다.
검증과 요약은 별도 단계로 둔다.

이 구조는 아주 중요하다. 왜냐하면 실제 작업에서 병목은 보통 하나가 아니기 때문이다. 계획, 실행, 검증, 재시도는 각각 다른 종류의 지능을 요구한다.

즉, 좋은 에이전트 키트는 한 에이전트에게 다 시키지 않는다. 대신 stage routing을 기본값으로 둔다.

5. 검증 루프가 붙어야 키트가 제품이 된다

키트가 진짜 강해지는 순간은 실행이 아니라 검증이 붙을 때다.

예를 들어 다음과 같은 순서가 있어야 한다.

무엇을 만들지 정한다.
무엇이 맞는지 본다.
틀리면 왜 틀렸는지 기록한다.
다시 고친다.
다시 확인한다.

이게 없으면 에이전트는 단지 빨리 반복하는 기계가 된다. 빨리 반복하는 것과 빨리 개선하는 것은 전혀 다르다.

AI 유틸은 이 차이를 노출할 수 있어야 한다. 결과만 보여주지 말고, 비용, 검증, provenance, 실패 상태까지 보여줘야 한다. 그래야 사용자는 “AI가 마법처럼 해냈다”가 아니라 이 도구가 어떻게 믿을 만한지 이해한다.

실전 활용 팁: 플랫폼보다 먼저 에이전트 키트를 만든다

이 신호를 제품으로 바꾸려면 처음부터 거대한 플랫폼을 만들려고 하지 않는 편이 낫다. 먼저 반복 업무에 붙일 수 있는 얇은 키트를 만든다.

1. 공통 키트와 작업별 계약을 분리한다

공통 키트에는 모든 작업이 공유하는 규칙만 둔다.

입력을 어디서 읽는가
결과를 어디에 쓰는가
검증은 어떤 형식으로 남기는가
실패하면 어떤 로그를 남기는가
사람이 승인해야 하는 지점은 어디인가

반대로 작업별 계약은 짧아야 한다.

목표: 블로그 초안 생성
입력: 주제, 참고 메모, 금지 문체
출력: MDX 초안
검증: 제목, lead, TL;DR, 금지 링크, 빌드 통과

이렇게 나누면 새 유틸을 만들 때마다 운영 체계를 다시 만들 필요가 없다.

2. 생성과 검증을 같은 단계에 넣지 않는다

생성 모델이 초안을 만들고, 검증 단계가 구조와 오류를 확인하게 분리한다. 작은 제품이라도 이 분리는 중요하다.

생성: 초안, 변환, 추천, 요약
검증: 누락, 형식, 숫자, 출처, 정책
수정: 실패 항목만 다시 처리
기록: 사용자가 확인할 상태로 저장

한 번에 완벽한 답을 기대하기보다, 얇은 단계가 빠르게 돌도록 만드는 편이 운영에 강하다.

3. 메모리는 줄이고 경로는 명시한다

에이전트 키트가 커질수록 메모리를 많이 붙이고 싶어진다. 하지만 실제로 필요한 건 거대한 기억이 아니라 매번 읽을 수 있는 경로다.

공통 규칙: /contracts/common.md
작업 계약: /contracts/blog-draft.md
입력: /inputs/topic.md
검증 결과: /review/checklist.md
최종 산출물: /outputs/post.mdx

이런 경로가 있으면 에이전트는 매번 다시 인터뷰하지 않고 같은 방식으로 움직인다.

4. 결과 화면에 키트의 흔적을 남긴다

사용자에게 내부 파일 구조를 전부 보여줄 필요는 없다. 하지만 작업이 어떤 키트로 처리됐는지는 보여줄 수 있다.

처리 경로
계약 확인 -> 초안 생성 -> 검증 -> 실패 항목 수정 -> 최종 출력

이렇게 하면 단순한 유틸이 아니라, 작업을 작게 분해해서 안정적으로 처리하는 도구가 된다.

바로 해볼 실험

오늘 당장 할 수 있는 실험은 세 단계다.

다음 유틸 하나를 고른다.
contract / generate / verify / publish 네 단계로 쪼갠다.
각 단계에 읽을 문서와 성공 기준을 한 줄씩 붙인다.

이 실험은 작아 보이지만 효과는 크다. 에이전트는 더 길게 생각해서 강해지는 게 아니라, 더 잘 정의된 문제를 더 정확한 키트로 풀 때 강해진다.

리스크 / 반론

물론 키트가 지나치게 무거워지면 오히려 배보다 배꼽이 커진다.

규칙이 많아지면 유지비가 생긴다.
검증이 과하면 속도가 떨어진다.
지나친 분리는 운영 복잡성을 키운다.

그래서 핵심은 균형이다. 키트는 두껍게가 아니라 얇고 정밀하게 설계해야 한다.

결론

AI 시대의 승부는 “더 똑똑한 챗봇을 갖고 있느냐”가 아니다. 승부는 “작업을 잘 쪼개고, 계약을 잘 붙이고, 검증 루프를 얼마나 얇게 운영하느냐”다.

플랫폼은 나중에 커질 수 있다. 하지만 처음부터 플랫폼을 만들 필요는 없다. 먼저 만들어야 하는 건 에이전트 키트다. 그리고 그 키트가 쌓이면, 그제서야 진짜 플랫폼이 된다.