AI workflow 하나가 그럴듯하게 만들어졌다고 바로 사용자에게 배포하면 문제가 생길 수 있음.

한두 번은 잘되는데 입력이 조금만 달라져도 실패하는 작업법일 수 있기 때문임.

Bubble Engine은 solution variant를 만든 뒤 test harness를 구축해 후보들을 시험하는 과정을 거친다고 공식 문서에서 설명합니다.

Test Harness를 쉽게 표현하면 AI 작업법을 반복해서 시험할 수 있도록 만든 자동 시험장에 가까움.

결과 하나를 보고

“잘됐네”

라고 판단하는 게 아니라 여러 사례를 집어넣고 결과를 비교할 수 있도록 만드는 것임.

AI Agent가 실사용 단계로 갈수록 생성 능력만큼 자동 평가 인프라가 중요해지는 이유임.

어떤 AI 모델이 제일 좋냐는 질문을 자주 보게 됨.

그런데 실제 업무에서는 하나의 모델이 모든 단계를 가장 잘할 필요가 없음.

검색에 강한 도구가 따로 있을 수 있고, 이미지 작업에 적합한 모델이 따로 있을 수 있으며, 결과 검증에는 또 다른 방식이 유리할 수 있음.

DAPPOS 공식 문서상 Bubble Engine은 solution을 만들면서 candidate models와 tools를 조합합니다.

즉 탐색 대상이

Best Model

하나가 아니라

Model A + Tool B + Model C + Workflow D

같은 조합이 될 수 있다는 것임.

AI 기술이 발전할수록 모델 개수도, 도구 개수도 늘어남.

그때 중요한 기술은 모든 기능을 직접 사용하는 능력보다 어떤 조합이 특정 task에서 가장 잘 작동하는지를 찾아내는 능력일 수 있음.

AI 결과를 사람이 보면 쉽게 이런 말을 하게 됨.

“이쪽이 조금 더 좋아 보이는데”

하지만 자동으로 수많은 solution을 비교하려면 이런 감각적인 평가만으로는 부족함.

DAPPOS는 Bubble Engine이 후보 solution의 결과를 task examples와 quality criteria를 기준으로 평가한다고 설명합니다.

여기서 중요한 건 먼저

“이 작업에서 좋은 결과란 무엇인가”

라는 기준을 세우는 것임.

그래야 서로 다른 모델과 도구 조합을 같은 조건에서 비교할 수 있음.

즉 Bubble Engine의 역할에는 단순 생성뿐 아니라

생성 → 테스트 → 평가

가 함께 들어감.

AI Agent 시스템이 안정적으로 작동하려면 ‘잘 만드는 기술’과 함께 잘했는지 판정하는 기술도 필요하다는 의미임.

특정 예제 하나에서 1등한 AI workflow가 있다고 해도 바로 재사용 가능한 작업법이라고 보기는 어려움.

그 예제에만 우연히 잘 맞았을 수도 있기 때문임.

DAPPOS 공식 문서에서는 여러 후보 중 강한 실행 경로를 찾은 뒤에도 Bubble Engine이 versatility를 테스트한 후 SOP로 만든다고 설명합니다.

이 부분이 중요함.

SOP는 특정 프롬프트 하나를 해결한 기록이 아니라, 비슷한 종류의 요청에 다시 사용할 수 있어야 하는 reusable solution이기 때문임.

쉽게 말하면

한 문제 잘 풀기
→ 데모

비슷한 문제도 계속 잘 풀기
→ SOP 후보

라고 볼 수 있음.

AI workflow를 일회성 성공에서 재사용 가능한 시스템으로 바꾸는 단계임.

여기까지 흐름을 연결하면 Bubble Engine이 SOP를 만드는 과정이 조금 더 선명해짐.

특정 task를 잡고,

여러 solution variant를 만들고,

test harness에서 시험하고,

모델과 도구 조합을 비교하고,

quality criteria를 기준으로 평가함.

그리고 충분히 재사용 가능한지까지 테스트한 뒤 가장 강한 실행 경로를 SOP로 패키징합니다. 공식 문서도 SOP를 특정 종류의 task를 위한 reusable solution으로 설명하고 있습니다.

그래서 xBubble의 SOP를 단순히

“잘 만든 프롬프트”

라고 보면 구조를 너무 작게 보는 셈임.

그 안에는 어떤 모델과 도구를 어떤 방식으로 사용할 것인지에 대한 검증된 실행 경로가 들어갈 수 있음.