DAPPOS 공식 문서는 SOP의 구성을 한 줄 식으로 적어두었습니다. 스킬에 실행 환경, API, MCP, 모델 선택을 더한 것이 SOP입니다. 왜 이렇게 묶었는지도 바로 이어집니다. 스킬만으로는 부족하기 때문입니다. 결과는 어떤 환경에서 도는지, 어떤 모델을 쓰는지, 어떤 API와 MCP가 붙어 있는지에 따라 달라집니다.
문서는 일반적인 스킬 마켓과 비교해 세 가지를 앞세웁니다. 첫째는 안정성입니다. SOP는 검증된 범위 안에서 쓰입니다. 사용자의 작업이 그 범위에 들어맞을 때 결과가 더 일정하게 나옵니다.
둘째는 쓰기 쉬움입니다. 입력은 작업 설명 하나면 됩니다. 모델을 고르거나 API를 설정하거나 여러 스킬을 비교하거나 실행 과정을 디버깅할 필요가 없습니다. 고르는 일은 Bubble Pilot이 합니다. 셋째는 SOP를 스스로 만들어낸다는 점입니다. 쓸 만한 스킬 하나를 만들려면 시험과 디버깅과 최적화가 필요한데, 비개발자에게는 이 과정 자체가 벽입니다. Bubble Engine이 이 부분을 대신합니다.
문서는 SOP가 범용일 수도 있고 특정 사용자나 회사의 요구에 맞춘 좁은 해법일 수도 있다고 덧붙입니다. DAPPOS가 조작 부담을 사용자에게서 시스템으로 옮긴다고 말할 때 그 이동이 실제로 일어나는 지점이 SOP입니다.
이 구조가 실제로 통할지는 쓰는 사람이 늘어야 판가름 납니다. 어떻게 보시나요.
#DAPPOS
#SOP
#xBubble