토큰이 남아서 시작한 실험이었다.
이 시리즈에서 나온 것들을 한 줄로 정리하면 이렇다. 주제를 생성하고, 여러 벌을 자동으로 뽑고, 스스로 검증하게 했다가 막혔다. 평가 기준이 주관적이면 자율 루프가 안 돈다는 걸 알았다. 그래서 판단을 사람한테 넘겼다. 투표로. 기호가 데이터로 쌓이면 다시 스킬에 반영하는 루프가 돌기 시작했다.
투표에서 대중 기호가 쌓이면 그다음이 보인다. 평균 기호만으로는 부족하다. 사람마다 취향이 다르니까.
그래서 Templ에 개인화 신청 기능을 붙인다. 갤러리에서 맘에 드는 시안을 고른 다음 “이 미감으로 내 걸 만들어줘”라고 신청하는 거다. 경연 중인 시안에서 신청할 수도 있고, 갤러리 완성작을 수정 요청할 수도 있다. 신청은 유료, 결과물은 신청자 전용으로 받는다.
제작의뢰 서비스는 나중에 따로 붙일 생각이다. 지금 당장은 할 게 너무 많아서.
근데 이걸 다 합치고 나서야 보인 게 있었다.
이 전체 흐름이 Atlas app-creator가 하려던 것과 똑같았다.
Atlas app-creator가 그리는 흐름은 이렇다. 사용자가 “이런 앱 만들고 싶어”라고 하면 → 예시 시안 갤러리가 나오고 → 마음에 드는 걸 고르고 → 거기서 상세까지 확장한다. 주제 → 시안 → 선택 → 확장.
템플릿 실험에서 한 것도 정확히 같은 구조다. 요구사항을 자율 생성하고(auto-requirement), 같은 요구사항으로 미감만 다른 여러 컨셉을 뽑고(home-concepts), 투표로 고르게 하고, 선택된 것을 상세까지 확장한다. Templ의 경연/투표 구조가 Atlas의 “사용자가 시안을 선택하는 단계”를 군중에게 확장한 버전이다.
스킬도 이쪽으로 진화했다. template-spec/gen/lint로 시작했던 파이프라인이 home-concepts, expand-concept 스킬로 이어졌다. 자율 루프에서 쌓인 배움 — 체크리스트로 떨어지는 것만 자동화할 수 있다, 디자인 선택은 사람이 해야 한다 — 이 그대로 Atlas의 설계 원칙이 됐다.
남는 자원으로 시작한 가벼운 실험이라도, 끝까지 굴려보면 다음 제품의 기반이 된다. 나는 토큰 태우려고 시작한 디자인 실험에서 두 가지를 배웠다.
하나는 생성과 평가를 어떻게 나누는지다. 기계가 할 수 있는 것과 사람이 해야 하는 것이 다르다. 그 경계를 직접 부딪혀서 알았다.
다른 하나는 실패가 자산이 된다는 거다. 자가 검증이 안 됐던 경험이 “이런 건 자동화 안 된다”는 설계 지식으로 남았다. 그게 없었다면 같은 실수를 Atlas를 만들면서 또 했을 것이다.
실패한 부분까지 전부 자산이었다.