لماذا تقرأ هذا

هذا المقال موجّه لـالمطورين ومهندسي المنصات الذين يرسمون مخططات معمارية باستمرار لكنهم يفقدون وقتهم في صيغة Mermaid أو أدوات الرسم بالسحب والإفلات. إنه مفيد لمن يحتاج أساسًا ملموسًا لاختيار أداة.

لنبدأ بالخلاصة. القيمة الحقيقية لـ Archify ليست في راحة “ارسم لي الصورة بالكلام”، بل في أن المُصيّر يفرض التحقق من التخطيط الذي ينتجه الوكيل، بحيث يستحيل إنتاج رسم خاطئ من الأساس. حين شغّلناها فعليًا، رُفضت محاولتنا الأولى للرسم، وكان ذلك الرفض هو ما يجعل هذه الأداة تستحق الاستخدام.

نظرة عامة

مخططات المعمارية من أكثر المخرجات التي يرسمها المطورون تكرارًا وأكثرها إزعاجًا لهم. Mermaid يتطلب حفظ صيغته، وأدوات الرسم تتطلب سحب الصناديق والخطوط يدويًا لضبطها. وحتى بعد الانتهاء من الرسم، قد لا يتطابق الوضع الداكن، أو يجب إعادة التصدير لإدراجه في عرض تقديمي.

Archify، الذي حظي مؤخرًا باهتمام واسع في مجتمع المطورين الصيني، يستهدف هذه النقطة تحديدًا. أعطِ Claude Code أو Codex جملة عادية مثل “اقرأ هذه المستودعات وارسم لي مخططًا مقارنًا لبنياتها”، فتحصل على مخطط HTML ذاتي الاكتفاء يُفتح مباشرة في المتصفح. يمكنك التبديل بين السمتين الداكنة والفاتحة، وتصديره إلى PNG أو SVG.

حتى هذه النقطة، يبدو الكلام كعبارات تسويقية معتادة. لذلك، بدل تصديق العبارات، ثبّتناها فعليًا وشغّلناها، ورسمنا بها بنية ai-platform الخاصة بـ ThakiCloud. كشفت هذه العملية لماذا تختلف هذه الأداة عن “مولّد رسوم بالذكاء الاصطناعي” بسيط. هذا المقال سجل لتلك التجربة، وفي الوقت نفسه محاولة لفهم كيف تتصل بفلسفة تصميم Paxis، منصة الوكلاء التي تبنيها ThakiCloud.

ما هذه الأداة

Archify مهارة وكيل مفتوحة المصدر أصدرها tt-a1i برخصة MIT. عند وقت تجربتنا كان الإصدار 2.11.0، وهي نسخة أُعيدت كتابتها كفرع (fork) من architecture-diagram-generator v1.0 لشركة Cocoon AI، وتنسب لغتها البصرية الأصلية إلى Cocoon AI. تُثبَّت على عدة أوقات تشغيل للوكلاء منها Claude وCodex CLI وopencode.

فهم البنية الجوهرية يوضّح سبب تميّز هذه الأداة. لا يرسم Archify الصورة مباشرة. بدلًا من ذلك، يصف المخطط بصيغة JSON-IR (تمثيل وسيط)، ويحوّل مُصيّر مخصص لكل نوع ذلك JSON إلى HTML. هناك خمسة مُصيّرات: architecture وworkflow وsequence وdataflow وlifecycle. بعبارة أخرى، “ماذا نرسم” يعيش في JSON مُهيكَل، و”كيف نرسمه” تملكه شيفرة مُتحقَّق منها.

تتولى المُصيّرات الخمسة كل نوع مختلف من الرسوم. architecture يغطي مكونات النظام وحدوده، وworkflow يغطي إجراءات مثل سلاسل الموافقة أو CI/CD، وsequence يغطي دورة حياة الطلب أو ترتيب استدعاءات API، وdataflow يغطي حركة البيانات مثل خطوط ETL وتدفقات الأحداث، وlifecycle يغطي انتقالات الحالة مثل عمليات النشر أو تنفيذ الوكيل. بمجرد تحديد ما تريد رسمه، يُفعَّل المُصيّر والمخطط (schema) المناظران، وذلك المخطط يفرض شكل JSON المُدخَل.

يخلق هذا التقسيم للعمل الفارق الحاسم مقارنة بـ Mermaid. يحلّل Mermaid الصيغة ويرتّب العناصر تلقائيًا (عبر dagre)، لكنه يرسم بلا مانع حتى لو قطع خط صندوقًا أو تداخلت التسميات. يفعل Archify العكس: يجعلك تحدد إحداثيات التخطيط صراحة، وقبيل الرسم مباشرة يفحص قواعد التخطيط فرضًا. إن خُرقت قاعدة، يرفض إنتاج الرسم ويصدر خطأ بدلًا منه.

التدفّق العام كالتالي.

flowchart TB
    A["طلب بلغة طبيعية<br/>(اقرأ هذا المستودع وارسم البنية)"] --> B["وكيل<br/>Claude Code / Codex"]
    B --> C["كتابة JSON-IR<br/>components · connections · boundaries"]
    C --> D["مُصيّر حسب النوع<br/>architecture / workflow / sequence / dataflow / lifecycle"]
    D --> E{"التحقق من التخطيط<br/>تقاطع خط-عقدة · تداخل التسميات"}
    E -.فشل التحقق + اقتراح إصلاح.-> C
    E -->|نجاح| F["HTML ذاتي الاكتفاء<br/>سمة داكنة/فاتحة · تصدير PNG/SVG"]

التثبيت والتكامل

التثبيت أمر npx واحد. التثبيت الشامل (العالمي) كالتالي.

# تثبيت شامل ثم اختيار وكيل
npx skills add tt-a1i/archify -g

# تجربة لمرة واحدة دون تثبيت دائم
npx skills use tt-a1i/archify@archify --agent codex

يمكنك أيضًا استنساخ المستودع مباشرة والتحقق منه عبر CLI لاستخراج الأمثلة. هذه هي الأوامر الفعلية التي شغّلناها ومخرجاتها. كانت بيئة تجربتنا Node.js v24.1.0، ويتطلب Archify Node 18 فأعلى، ولا توجد له فعليًا تبعيات تشغيل (تبعية تطوير واحدة فقط هي ajv، تُستخدم للتحقق من المخطط).

git clone --depth 1 https://github.com/tt-a1i/archify.git
cd archify/archify

# فحص حالة التثبيت
node bin/archify.mjs doctor

هذا هو المخرج الفعلي لأمر doctor. تأكّدت جميع المُصيّرات الخمسة والمدقّقات (schema validators) على أنها سليمة.

Archify doctor

[ok] Node.js v24.1.0 (requires >=18)
[ok] Core template
[ok] Standalone schema validators
[ok] architecture renderer, schema, and example
[ok] workflow renderer, schema, and example
[ok] sequence renderer, schema, and example
[ok] dataflow renderer, schema, and example
[ok] lifecycle renderer, schema, and example

Archify is ready.

سحب أحد الأمثلة المدمجة ينتج ملف HTML ذاتي الاكتفاء واحدًا بحجم 508 كيلوبايت، يُفتح مباشرة في المتصفح دون أي خادم خارجي.

node bin/archify.mjs demo ./out
# Demo ready: ./out/archify-demo.html   (نحو 508 كيلوبايت، HTML واحد)

ما وجدناه حين شغّلناها فعليًا

قراءة الوثائق وحدها تجعل الأمر يبدو أن هذا كل شيء. لذلك، بدل استخدام مثال شخص آخر، كتبنا بنية ai-platform الفعلية لـ ThakiCloud كـ JSON-IR بأيدينا ورسمناها. أدرجنا تسعة مكونات: جدولة GPU عبر Kueue، تقديم النماذج عبر vLLM، مصادقة متعددة المستأجرين عبر Keycloak، الحالة والأحداث عبر PostgreSQL وNATS، ونشر GitOps عبر ArgoCD.

لم يكن JSON-IR صعب القراءة أو الكتابة على إنسان. المكوّن كائن له نوع وتسمية وموضع وحجم، والاتصال يحمل مصدرًا ووجهة وتسمية. على سبيل المثال، وصفنا البوابة وجزء تقديم GPU كالتالي.

{
  "components": [
    { "id": "gateway", "type": "backend", "label": "API Gateway",
      "sublabel": "Go Fiber :8080", "pos": [280, 300], "size": [140, 60] },
    { "id": "vllm", "type": "backend", "label": "vLLM Server",
      "sublabel": "OpenAI API", "pos": [540, 300], "size": [140, 60] }
  ],
  "connections": [
    { "id": "gw-to-vllm", "from": "gateway", "to": "vllm", "label": "route inference" },
    { "id": "vllm-gpu", "from": "vllm", "to": "gpupool", "label": "CUDA", "variant": "emphasis" }
  ]
}

فشلت محاولة الرسم الأولى. وهذا الفشل هو أهم نقطة في هذا المقال. بدل رسم أي شيء، أشار المُصيّر إلى ثلاث مشكلات ملموسة.

Error: Architecture layout validation failed:
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "vllm" (unrelated to this relationship)
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "argocd" (unrelated to this relationship)
- Label "publish" overlaps component "gateway"
  Suggested fix: labelDy +24 (below); or labelAt [350, 374]

بعبارة أخرى، الاتصال من Kueue إلى مجمّع GPU قطع صندوقي vLLM وArgoCD غير المرتبطين، وتداخلت تسمية “publish” مع صندوق البوابة. اللافت أن المُصيّر لم يكتفِ بالإشارة إلى المشكلة، بل اقترح أيضًا كيفية إصلاحها، حتى الإحداثيات الدقيقة لمقدار تحريك التسمية.

اتّبعنا الاقتراح، وأضفنا نقطة توجيه (via) للاتصال وعدّلنا موضع التسمية، ثم أعدنا الرسم. نجح هذه المرة. هذه هي القياسات الفعلية.

خلاصة القول، الرسم نفسه يستغرق 73 ميلي ثانية، أي فوري فعليًا. المخرج ملف HTML ذاتي الاكتفاء لا يعتمد على خادم صور أو CDN، ومرجعه الخارجي الوحيد خط ويب واحد للكود، لذا يُفتح دون كسر حتى دون اتصال، متراجعًا إلى خط النظام. السمتان الداكنة والفاتحة ليستا زخرفة، بل مُنفَّذتان فعليًا عبر متغيرات CSS حقيقية وprefers-color-scheme.

الدرس المستفاد هنا واضح. مدقّق Archify ليس أداة لإنتاج “رسم جميل”، بل بوابة تمنع من الأساس نشر مخطط سيئ، خطوطه متشابكة أو تسمياته متداخلة. عيب بصري كان سيتجاهله إنسان يرسم يدويًا، أمسكته الشيفرة في كل مرة وبالمعيار نفسه.

دلالات على منتجات ThakiCloud

تصميم هذه الأداة يتقاطع بدقة مع مبدأ تلتزم به ThakiCloud عبر منتجين.

عبر عدسة Paxis (الوكلاء والمهارات). Paxis هي السحابة الأصلية للوكلاء من ThakiCloud، وتتعامل مع المهارات كموارد من الدرجة الأولى. تختار أكثر من 960 مهارة عبر BM25، وتشغّلها في صندوق رمل معزول، وتمرّر كل إجراء عبر بوابات السياسة وسجلات التدقيق. Archify هو تحديدًا شكل الأداة التي يُبنى إطار مهارات كهذا لاختيارها وتشغيلها. والأهم من ذلك هو تصميمها الداخلي. في Archify، يُنتج النموذج المحتوى (JSON-IR)، بينما تملك الشيفرة الصيغة والتحقق. هذا يطابق مبدأً تكرّره ThakiCloud في أعمال المخرجات الدفعية: افصل خطوة التوليد الحرة عن خطوة التحقق الحتمية. بدل أن تطلب من النموذج “ارسم شيئًا جميلًا”، تجعله ينتج تمثيلًا مُهيكَلًا، وتفرض الشيفرة ما إذا كان ذلك التمثيل يتبع القواعد. رفض محاولتنا الأولى للرسم كان تحديدًا هذا المبدأ وهو يعمل فعليًا.

عبر عدسة ai-platform (البنية التحتية والتوثيق). HTML ذاتي الاكتفاء مفيد بشكل خاص في البيئات المحلية (on-premise) والسيادية. لعميل لا يستطيع رفع بنيته الداخلية إلى SaaS خارجي للرسم، يصبح الرسم محليًا والحصول على ملف واحد قابل للنقل مخرجًا قابلًا للاستخدام مباشرة. وبما أن JSON-IR نص عادي، فهو خاضع لإدارة الإصدارات في Git وقابل للمقارنة (diff). تمامًا كما تدير ArgoCD ملفات manifest، يمكنك إدارة مخططات المعمارية كشيفرة أيضًا، وتتبّع كل تغيير ومراجعته. بدل إعادة رسم وثائق التأهيل أو مخططات النشر للعملاء يدويًا في كل مرة، يكفي تعديل JSON عند تغيّر البنية وإعادة الرسم.

تكمّل العدستان إحداهما الأخرى. مهارة مُتحقَّق منها (Paxis) تنتج مخرجًا قابلًا لإعادة الإنتاج (توثيق ai-platform)، وذلك المخرج بدوره يصبح أصلًا قابلًا للنقل إلى العملاء في البيئات المحلية.

القيود والاعتراضات

بالطبع، Archify ليست أداة سحرية. لها بعض نقاط الضعف الواضحة.

أولًا، يجب تحديد إحداثيات التخطيط صراحة. بخلاف التخطيط التلقائي في Mermaid، يجب إعطاء موضع وحجم كل مكوّن كإحداثيات، ويجب أن يجتاز ذلك التخطيط التحقق. كما أظهرت محاولتنا الأولى الفاشلة، هذه الخطوة ليست مجانية تمامًا. لكن عمليًا، يملأ الوكيل هذه الإحداثيات نيابة عنك ويصلحها بنفسه عند تلقّي خطأ تحقق، فينخفض العبء على الإنسان.

ثانيًا، المخرج ليس خفيفًا. المخطط الواحد نحو 508 كيلوبايت من HTML، لأنه يحزم الخطوط والسكربتات في ملف ذاتي الاكتفاء. هذا أثقل من SVG بسيط أو كتلة Mermaid. إن كنت تضع عدة مخططات في صفحة مدونة واحدة، قد يصبح هذا الوزن عبئًا.

ثالثًا، لم تُوزَّع كمكتبة. يُعلَّم package.json بـ private: true، أي أنك تستهلكها كمهارة/CLI من المستودع لا كحزمة npm. ربطها في خط أنابيب كمكتبة يتطلب تفكيرًا إضافيًا.

رابعًا، إنها لقطة ثابتة. ليست لوحة تحكم حية تُحدَّث ببيانات لحظية، بل صورة لبنية في لحظة زمنية محددة. إن أردت رسم مسودة سريعة، قد تصبح صرامة قواعد التحقق احتكاكًا. مع ذلك، هذه الصرامة نفسها هي سبب وجود هذه الأداة أصلًا.

الخلاصة

بعد تثبيت Archify فعليًا ورسم بنية ThakiCloud بها، خلاصتنا كالتالي. جوهر هذه الأداة ليس راحة “ارسم بالكلام”، بل انضباط جعل المُصيّر يتحقق من كل تخطيط ينتجه الوكيل بالمعيار نفسه في كل مرة، بحيث لا يُنشر مخطط سيئ أبدًا. كما قلنا في المقدمة، كان رفض محاولتنا الأولى للرسم هو اللحظة التي جعلتنا نثق بهذه الأداة.

لذا فالخطوة التالية واضحة. إن كنت ترسم مخططات معمارية باستمرار، وتريد أن تعيش تلك المخططات في وثائقك أو مستودعك كشيفرة، تستحق Archify تجربة واحدة على الأقل. وإن كنت بالمقابل تريد رسمًا سريعًا أو وضع عدة مخططات في صفحة واحدة، يبقى Mermaid الخيار الأخف. السؤال الفاصل هو: هل تريد إدارة هذا الرسم كأصل قابل لإعادة الإنتاج ومُتحقَّق منه؟ إن كانت الإجابة نعم، فـ Archify، وإطار مهارات Paxis الذي يحوّل المبدأ نفسه إلى منتج، هما الجواب.

المصادر

• مستودع Archify: github.com/tt-a1i/archify (MIT، الإصدار 2.11.0)
• التغريدة الأصلية: @alin_zone via @hjguyhan
• سجل التجربة: الأوامر والمخرجات والقياسات في هذا المقال جُمعت من تشغيل محلي في 2026-07-22 (Node v24.1.0).

لماذا تقرأ هذا

هذه المقالة موجهة لمهندسي المنصات وممارسي MLOps الذين يخدمون نماذج LLM عبر vLLM، أو الذين يعتمد إنتاجهم على مصادر مفتوحة سريعة التغير. إنها لمن عليه أن يقرر: “محرك الاستدلال الذي نشغّله يتغير مئات المرات أسبوعياً. أي إصدار نرقّي إليه ومتى، دون أن ينكسر شيء؟”

الخلاصة أولاً. مفتاح الحفاظ على جودة الإنتاج عند 2000 التزام شهرياً ليس زيادة الاختبارات بلا حدود. إنه ثلاث آليات حتمية: بوابة قياس أداء تمسك تراجعات الأداء، وتثبيت فرع الإصدار على أصح التزام، والتنصيف حسب الالتزام لعزل التراجع عند حدوثه. وهذه هي الأنماط التشغيلية ذاتها التي يمكن لـ ThakiCloud تبنّيها مباشرة عند خدمة vLLM في بيئة متعددة المستأجرين فوق Kubernetes.

نظرة عامة

في 16 يوليو 2026، نشر فريق صيانة vLLM مقالة بعنوان “Keeping vLLM Production Quality”. الأرقام وحدها مذهلة. خلال يونيو 2026، دمج vLLM 1918 التزاماً في main. أي نحو 64 يومياً، على قدم المساواة مع مشاريع مفتوحة كبيرة مثل PyTorch أو Kubernetes. في الشهر نفسه، استهلك CI 13 مليون دقيقة تشغيل، مع 1400 مشغّل متزامن في الذروة.

لماذا تخلق هذه السرعة مشكلة؟ ذلك نابع من طبيعة محرك الاستدلال. في خدمة ويب اعتيادية تصح فرضية “إذا نجحت الاختبارات فالوضع آمن غالباً”. لكن في محرك استدلال LLM، قد يجتاز تغيير كل الاختبارات ويجعل مع ذلك نموذجاً بعينه أبطأ أو يفسد مخرجاته بشكل خفي. استبدل نواة (kernel) واحدة وقد ينخفض معدل المعالجة إلى النصف على معمارية GPU معينة، ومثل هذا التراجع لا يظهر أبداً في اختبار وحدة بنجاح/فشل.

بالنسبة لمنظمة مثل ThakiCloud تعتمد على vLLM كتبعية خدمة أساسية، ليست هذه المقالة قصة شخص آخر. كل إصدار vLLM نشحنه يتحكم في زمن الاستجابة ومعدل المعالجة لأحمال العملاء. لذا فإن فهم كيف يحمي vLLM نفسه يخبرنا بما يجب أن نضع عليه بوابات فوقه.

ما هي هذه التقنية

ينقسم نظام جودة vLLM إلى ثلاث طبقات. كل طبقة توقف نوعاً مختلفاً من الفشل.

أولاً، CI وظيفي واسع. تشغّل مجموعة CI في vLLM 37 مجموعة اختبار و266 مهمة. تغطي المكونات والميزات الرئيسية من نوى مختلفة إلى speculative decoding إلى LoRA. تتحقق هذه الطبقة من “هل يعمل الكود؟”.

ثانياً، القياس المستمر (continuous benchmarking). تمسك هذه الطبقة تراجعات الأداء التي يفوّتها CI الوظيفي. تقيس الأداء تلقائياً عبر نماذج وأجهزة GPU متعددة، وتتتبعه عبر الزمن لإبراز التراجعات أو التحسينات. تتحقق هذه الطبقة من “هل ما زال الكود سريعاً، وهل ما زال المخرج صحيحاً؟”.

ثالثاً، هندسة الإصدار. مهما كان CI والقياس جيدين، فإن تقرير أي التزام يُصدَر للمستخدمين قرار منفصل. يوكل vLLM هذا القرار لقواعد قابلة للتكرار لا للحدس البشري.

يبيّن المخطط أدناه كيف تتشابك الطبقات الثلاث. اقرأه من الأعلى للأسفل فيصبح مسار التزام واحد حتى يصل مستخدماً.

flowchart TB
    A[فرع main<br/>1918 التزام/شهر] --> B{PR CI<br/>37 مجموعة اختبار، 266 مهمة}
    B -->|ينجح| C[الدمج في main]
    B -->|يفشل| A
    C --> D[وسم perf-benchmarks + ready<br/>قياس عند كل التزام]
    D --> E[لوحة الأداء<br/>تتبع التراجع لكل نموذج/GPU]
    C --> F[عجلات wheel لكل التزام<br/>للتنصيف]
    E --> G{كل يوم اثنين بالتناوب<br/>أسبوع الإصدار}
    G --> H[اختيار أخضر التزام في full-CI]
    H --> I[تثبيت فرع الإصدار]
    F -.عند التراجع.-> J[تنصيف حسب تجزئة الالتزام]
    J -.عزل الالتزام المسبِّب.-> A

ما الذي انكسر وكيف أُصلح

لم يكن هذا النظام مكتملاً منذ البداية. في مايو 2026، بعد أيام من إصدار v0.20.0، اضطر vLLM لإطلاق رقعتين طارئتين. مشكلتان مرّتا عبر CI مباشرة إلى المستخدمين.

إحداهما كسرت gpt-oss على معالجات Blackwell عند تقسيمه على عدة GPU؛ والأخرى أهبطت معدل معالجة DeepSeek V4 على GB200. في ذلك الوقت لم يكن لدى vLLM خط قياس أداء. اجتازت المشكلتان الاختبارات الوظيفية بنظافة، لكن لم يكن أحد يقيس تلقائياً الأداء والصحة الفعليين على العتاد الحقيقي.

تلك الحادثة هي السبب المباشر لوجود طبقة القياس المستمر. الدرس واضح. معادلة “نجاح الاختبارات = الأمان” لا تصح لمحرك استدلال. الصحة الوظيفية والأداء محوران منفصلان، ويجب وضع بوابة على كل منهما بشكل مستقل.

الأوامر التي يستخدمها المصلحون فعلاً

هذا النظام مكشوف لا كمفهوم فقط بل كأدوات يمكن للمستخدم تشغيلها. أداتان عمليتان لتتبع تراجعات الأداء مفيدتان بشكل خاص.

تُحدَّث لوحة الأداء تلقائياً على طلبات الدمج ذات وسوم معينة. عند كل التزام يحمل وسمَي perf-benchmarks وready معاً، وكلما دُمج طلب دمج في main، يُشغَّل القياس ويُنشَر إلى اللوحة العامة.

# الوسوم التي تُطلق قياسات الأداء (سير عمل PR في vLLM)
perf-benchmarks + ready
# ← تشغيل القياس على نماذج/GPU عديدة لكل التزام ← نشر إلى لوحة الأداء العامة

الأكثر إثارة هو التنصيف حسب الالتزام (bisection). ينشر vLLM عجلات wheel للالتزامات السابقة، لذا فإن تحديد تجزئة التزام في رابط التثبيت يثبّت vLLM كما كان بالضبط عند ذلك الالتزام.

# تثبيت عجلة vLLM عند تجزئة التزام محددة (لتنصيف تراجعات السلوك/الأداء)
pip install https://wheels.vllm.ai/<commit-hash>/vllm-<version>-cp38-abi3-manylinux1_x86_64.whl

# تضييق "متى صار أبطأ؟" بالتنصيف:
#   التزام جيد A ── ؟ ── التزام سيئ B
#   ← ثبّت نقطة وسطى لإعادة الإنتاج ← اقسم النطاق إلى النصف

هنا تظهر القيمة الحقيقية لهندسة الإصدار. يبدأ vLLM أسبوع الإصدار كل يوم اثنين بالتناوب. يراجع مدير الإصدار عمليات full-CI الأخيرة على main ذلك اليوم ويختار أخضر التزام. هذا يؤمّن أصح نقطة انطلاق قبل إضافة أي تغييرات خاصة بالإصدار. ولقطع فروع الإصدار بشكل متكرر فائدة خفية: تتبع التراجع أسهل بكثير حين يكون لديك نحو 500 التزام للتنصيف بدل بضعة آلاف. إيقاع الإصدار نفسه آلية تخفض كلفة تصحيح الأخطاء.

أرقام الحجم التي نشرها vLLM

فيما يلي الأرقام الفعلية التي نشرتها المقالة اعتباراً من يونيو 2026. هذه ليست إعادة إنتاج منّا؛ إنها قيم أبلغ عنها المصلحون، منقولة حرفياً.

ما تقوله هذه الأرقام بسيط. للحفاظ على الجودة عند هذه السرعة، لا يمكن للتحقق أن يعتمد على المراجعة البشرية ويجب استبداله ببوابات حتمية وقياس آلي.

دلالات على منتجات ThakiCloud

تخدم ai-platform من ThakiCloud النماذج لبيئات عملاء متنوعة فوق Kubernetes وجدولة Kueue لوحدات GPU. vLLM هو المحرك الأساسي على مسار الخدمة هذا، لذا فإن كيفية حفاظ vLLM على الجودة تصبّ مباشرة في تصميم سياسة إصداراتنا.

أولاً، افصل تثبيت الإصدار عن بوابة القياس. وفق درس vLLM، لا نرقّي إصداراً جديداً للإنتاج بمجرد نجاح الاختبارات الوظيفية. نشغّل تلقائياً قياسات معدل المعالجة وزمن الاستجابة على أحمال عملاء تمثيلية (تركيبات نموذج/GPU) قبل الطرح، ونضع بوابة تحجب الترقية عند رصد تراجع. هذا ينقل طبقة القياس المستمر في vLLM إلى بوابة في خط النشر لدينا.

ثانياً، ثبّت إصدار vLLM صراحةً في الطرح المبني على GitOps عبر ArgoCD. بدل ملاحقة أحدث التزام على main، نعامل وسم الإصدار الذي تحقق منه vLLM وقطعه بنفسه كمرجع، ونثبّت ذلك الوسم في قيم كل عنقود. الطرح أولاً لعدد قليل من المستأجرين كـ canary، ثم التوسع للجميع فقط حين تكون لوحة القياس خضراء، يعيد إنتاج مبدأ vLLM “اختر أصح التزام” على طبقة النشر.

ثالثاً، استخدم عجلات wheel لكل التزام لتتبع التراجع داخلياً. حين يشير عميل بعينه إلى أنه “صار أبطأ من الأسبوع الماضي”، يمكننا التنصيف بعجلات vLLM لكل التزام لعزل الالتزام المسبِّب. تضييق مسؤولية التراجع بسرعة في بيئة متعددة المستأجرين محوري لثقة التشغيل.

تتقارب هذه الثلاثة على مبدأ واحد. لتشغيل الإنتاج فوق تبعية مصدر مفتوح سريعة التغير، عليك تفويض حكم الجودة لبوابات آلية، لا للحدس البشري.

الحدود والحجج المضادة

لا يُنقَل نهج vLLM بنظافة إلى كل منظمة. هناك قيود واقعية.

الأكبر هو الكلفة. 13 مليون دقيقة CI شهرياً و1400 مشغّل متزامن يفترضان ميزانية بنية تحتية كبيرة. من غير الواقعي لفريق صغير استنساخ مزرعة قياس بهذا الحجم. لذا ما نحتاجه ليس نسخة من الحجم بل قياس تمثيلي مضيّق على الأحمال الأساسية. وضع بوابة على أعلى بضع تركيبات فقط من حركة العملاء الفعلية، بدل مصفوفة نموذج/GPU الكاملة، أجدى بكثير لكل دولار.

ثانياً، تغطية القياس هي حدّه. التراجعات في نماذج أو أطوال تسلسل أو تركيبات دفعات غير موجودة في القياس ما زالت تتسرب. حادثة مايو في vLLM فاتت تحديداً لعدم وجود قياس، وحتى بعد إضافته تبقى التركيبات الغائبة عن اللوحة نقاطاً عمياء. لا تنسَ أبداً أن البوابة تحمي فقط “ما قِسته”.

ثالثاً، إيقاع الإصدار كل أسبوعين هو مقايضة بين الاستقرار والحداثة. قطع الإصدارات بشكل متكرر يسهّل التنصيف، لكنه يبطئ سرعة وصول الميزات الجديدة للإنتاج. إن كان لدى عميل حاجة عاجلة لأحدث تحسين نواة، فقد تصبح سياسة الإصرار على الإصدارات المستقرة فقط عنق الزجاجة ذاته. نقطة التوازن هذه تختلف من منظمة لأخرى.

الخلاصة

عودة إلى مشكلة حماية الإنتاج فوق مصدر مفتوح سريع التغير. لا ينهار vLLM عند 2000 التزام شهرياً ليس لأنه يضيف اختبارات بلا حدود، بل لأنه يملك ثلاث آليات حتمية: بوابة قياس توقف تراجعات الأداء، وتثبيت فرع الإصدار الذي يختار أصح التزام، والتنصيف حسب الالتزام الذي يضيّق السبب.

بالنسبة لمنظمة مثل ThakiCloud تشغّل vLLM كنواة خدمة، فإن الإجراء اليوم واضح. حين ترقّي لإصدار vLLM جديد، لا تعتمد على نجاح الاختبارات الوظيفية وحده؛ أقِم قياساً على أحمال عملاء تمثيلية كبوابة طرح. وبدل ملاحقة main، ثبّت وسم الإصدار الذي تحقق منه vLLM في قيم GitOps لديك. وضع هذين فقط في خط نشرك يتيح لك امتصاص سرعة المنبع مع حماية استقرار المصب. الجودة لا تأتي من مزيد من الاختبارات، بل من بوابة موضوعة في المكان الصحيح.

المصادر

• vLLM Blog, “Keeping vLLM Production Quality: A Look Inside CI, Benchmarking, and the Release Process” (2026-07-16): https://vllm.ai/blog/2026-07-16-keeping-vllm-production-quality
• vLLM Performance Dashboard (docs): https://docs.vllm.ai/en/latest/benchmarking/dashboard/

Source: RT @Lentils80: 🚨 Alibaba released Qwen-Image-3.0 today · twitter

What this means for ThakiCloud

What this means for ThakiCloud

Crisp in-image text is a genuinely useful tool. Point a Paxis agent at a poster or banner and the manual typo hunt just disappears. The catch is never the brush, it’s where the brush lives. Lean on a hosted, per-image API and every picture you generate leaves a receipt on someone else’s ledger. Metis is built to serve open models of the same caliber inside your own rack. Generate all you like, but keep the weights and the GPUs on your premises. That’s the quiet luxury of sovereign on-prem.

An auto-generated comic riffing on this week’s industry news.

Why read this

This post is for developers and platform engineers who draw architecture diagrams often but keep losing time to Mermaid syntax or drag-and-drop drawing tools. It’s meant to help anyone who needs a concrete basis for picking a tool.

Here’s the conclusion up front. Archify’s real value isn’t the convenience of “draw a diagram by describing it in words.” It’s that the renderer forcibly validates the layout an agent produces, so a broken diagram simply cannot be created. When we actually ran it, our first attempt was rejected by the renderer, and that rejection is exactly what makes this tool worth using.

Overview

Architecture diagrams are one of the outputs developers produce most often and dread most. Mermaid requires memorizing syntax. Drawing tools require dragging boxes and lines into place by hand. Even after you finish, dark mode often doesn’t line up, or you have to re-export the file to drop it into a slide deck.

Archify, which recently gained traction in the Chinese developer community, targets exactly this pain point. Give Claude Code or Codex a plain sentence like “read these repositories and draw me a comparison of their architectures,” and out comes a single self-contained HTML diagram that opens right in the browser. You can toggle between dark and light themes, and export to PNG or SVG.

So far, this reads like typical marketing copy. So instead of trusting the copy, we installed it, ran it ourselves, and used it to diagram ThakiCloud’s own ai-platform structure. That process revealed why this tool is different from a simple “AI diagram generator.” This post is both a record of that experiment and a look at how it connects to the design philosophy behind Paxis, ThakiCloud’s agent platform.

What this tool is

Archify is an open source agent skill released under the MIT license by tt-a1i. At the time of our experiment, the version was 2.11.0. It is a fork and rewrite of Cocoon AI’s architecture-diagram-generator v1.0, and it credits Cocoon AI for the original visual language. It installs into several agent runtimes, including Claude, Codex CLI, and opencode.

Understanding its core structure explains why the tool is unusual. Archify doesn’t draw a diagram directly. Instead, it describes the diagram as a JSON-IR (intermediate representation), and a type-specific renderer turns that JSON into HTML. There are five renderers: architecture, workflow, sequence, dataflow, and lifecycle. In other words, “what to draw” lives in structured JSON, and “how to draw it” is owned by validated code.

The five renderers each handle a different kind of diagram. Architecture covers system components and boundaries. Workflow covers procedures like approval chains or CI/CD. Sequence covers request lifecycles or API call ordering. Dataflow covers data movement such as ETL pipelines and event streams. Lifecycle covers state transitions such as deployments or agent execution. Once you know what you’re drawing, the matching renderer and schema kick in, and that schema enforces the shape of the input JSON.

This division of labor creates the decisive difference from Mermaid. Mermaid parses syntax and lays things out automatically (via dagre), but it will happily render a diagram where a line cuts through a box or labels overlap. Archify does the opposite: it makes you specify layout coordinates explicitly, and right before rendering it forcibly checks layout rules. If a rule is violated, it refuses to produce the diagram and raises an error instead.

The overall flow looks like this.

flowchart TB
    A["Natural language request<br/>(read this repo and draw the architecture)"] --> B["Agent<br/>Claude Code / Codex"]
    B --> C["Write JSON-IR<br/>components · connections · boundaries"]
    C --> D["Type renderer<br/>architecture / workflow / sequence / dataflow / lifecycle"]
    D --> E{"Layout validation<br/>edge-node crossings · label overlap"}
    E -.validation failed + fix suggestion.-> C
    E -->|pass| F["Self-contained HTML<br/>dark/light theme · PNG/SVG export"]

Installation and integration

Installation is a single npx command. The global install looks like this.

# Install globally, then pick an agent
npx skills add tt-a1i/archify -g

# Try it once without a permanent install
npx skills use tt-a1i/archify@archify --agent codex

You can also clone the repository directly and verify it with the CLI to pull out examples. Here are the exact commands we ran and their output. Our test environment was Node.js v24.1.0. Archify requires Node 18 or higher, and it has essentially no runtime dependencies (the only dev dependency is ajv, used for schema validation).

git clone --depth 1 https://github.com/tt-a1i/archify.git
cd archify/archify

# Check install status
node bin/archify.mjs doctor

Here is the actual output of the doctor command. All five renderers and the schema validators checked out fine.

Archify doctor

[ok] Node.js v24.1.0 (requires >=18)
[ok] Core template
[ok] Standalone schema validators
[ok] architecture renderer, schema, and example
[ok] workflow renderer, schema, and example
[ok] sequence renderer, schema, and example
[ok] dataflow renderer, schema, and example
[ok] lifecycle renderer, schema, and example

Archify is ready.

Pulling one of the built-in examples produces a single self-contained HTML file, 508KB, that opens directly in a browser with no external server needed.

node bin/archify.mjs demo ./out
# Demo ready: ./out/archify-demo.html   (about 508KB, single HTML)

What we found when we actually ran it

Reading the docs alone makes it seem like that’s the whole story. So instead of using someone else’s example, we wrote out ThakiCloud’s actual ai-platform structure as a JSON-IR by hand and rendered it. We included nine components: GPU scheduling with Kueue, model serving with vLLM, multi-tenant auth with Keycloak, state and events through PostgreSQL and NATS, and GitOps deployment via ArgoCD.

The JSON-IR wasn’t hard for a human to read or write. A component is an object with a type, a label, a position, and a size. A connection carries a source, a destination, and a label. For example, we described the gateway and the GPU-serving piece like this.

{
  "components": [
    { "id": "gateway", "type": "backend", "label": "API Gateway",
      "sublabel": "Go Fiber :8080", "pos": [280, 300], "size": [140, 60] },
    { "id": "vllm", "type": "backend", "label": "vLLM Server",
      "sublabel": "OpenAI API", "pos": [540, 300], "size": [140, 60] }
  ],
  "connections": [
    { "id": "gw-to-vllm", "from": "gateway", "to": "vllm", "label": "route inference" },
    { "id": "vllm-gpu", "from": "vllm", "to": "gpupool", "label": "CUDA", "variant": "emphasis" }
  ]
}

Our first render attempt failed. And this failure is the most important part of this post. Instead of drawing anything, the renderer pointed out three concrete problems.

Error: Architecture layout validation failed:
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "vllm" (unrelated to this relationship)
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "argocd" (unrelated to this relationship)
- Label "publish" overlaps component "gateway"
  Suggested fix: labelDy +24 (below); or labelAt [350, 374]

In other words, the connection from Kueue to the GPU pool cut through the unrelated vLLM and ArgoCD boxes, and the “publish” label overlapped the gateway box. What stands out is that the renderer didn’t just flag the problems, it also suggested how to fix them, down to the exact coordinates for how far to move the label.

We followed the suggestion, added a routing waypoint (via) to the connection, adjusted the label position, and re-rendered. This time it passed. Here are the actual measurements.

To sum up, the render itself takes 73 milliseconds, effectively instant. The output is a self-contained HTML file with no dependency on an image server or CDN, and its only external reference is a single web font for code, so it still opens correctly offline, falling back to the system font. The dark and light themes aren’t cosmetic labels either. They’re implemented with real CSS variables and prefers-color-scheme.

The lesson here is clear. Archify’s validator isn’t a device for producing “a pretty picture.” It’s a gate that blocks a bad diagram, one with tangled lines or overlapping labels, before it ever ships. A visual defect that a human drawing by hand would have simply missed, the code caught every single time, using the same standard.

Implications for ThakiCloud’s products

This tool’s design lines up precisely with a principle ThakiCloud holds to across two products.

Through the Paxis lens (agents and skills). Paxis is ThakiCloud’s Agent-Native Cloud, and it treats skills as first-class resources. It selects from more than 960 skills using BM25, runs them in an isolated sandbox, and routes every action through policy gates and audit logs. Archify is exactly the shape of tool that a skill harness like this is built to select and run. More importantly, look at its internal design. Archify has the model produce content (the JSON-IR), while code owns the format and the validation. This matches a principle ThakiCloud repeats across its batch-output work: separate the freeform generation step from the deterministic validation step. Instead of asking the model to “draw something nice,” you have it produce a structured representation, and code enforces whether that representation follows the rules. Our first render getting rejected was exactly this principle in action.

Through the ai-platform lens (infrastructure and documentation). Self-contained HTML is especially useful in on-premise and sovereign environments. For a customer who can’t upload internal architecture to an external diagramming SaaS, rendering locally and getting a single portable file back is directly usable as a deliverable. And because the JSON-IR is plain text, it’s version-controlled in Git and diffable. Just as ArgoCD manages manifests, you can manage architecture diagrams as code too, tracking and reviewing every change. Instead of redrawing onboarding docs or customer-facing deployment diagrams by hand every time, you just edit the JSON when the structure changes and re-render.

The two lenses reinforce each other. A validated skill (Paxis) produces a reproducible artifact (ai-platform documentation), and that artifact in turn becomes a portable asset for on-premise customers.

Limitations and counterpoints

Archify is, of course, not a silver bullet. It has a few clear weaknesses.

First, you have to specify layout coordinates. Unlike Mermaid’s automatic layout, you have to give the position and size of every component as coordinates, and that layout has to pass validation. As our own first attempt showed, this step is not entirely free. In practice, though, an agent fills in these coordinates for you and fixes them itself when it gets a validation error, so the burden on a human is reduced.

Second, the output isn’t lightweight. A single diagram is roughly 508KB of HTML, because it packs fonts and scripts into a self-contained file. That’s heavier than a plain SVG or a Mermaid block. If you’re dropping several diagrams onto one blog page, that weight can add up.

Third, it isn’t distributed as a library. The package.json is marked private: true, meaning you consume it as a repository skill or CLI rather than pulling it in as an npm package. Wiring it into a pipeline as a library takes some extra thought.

Fourth, it’s a static snapshot. It isn’t a live dashboard that updates with real-time data, but a picture of a structure at a specific point in time. If you just want to sketch something quickly, the strictness of the validation rules can feel like friction. That said, this strictness is also the whole reason the tool exists.

Wrap-up

Having installed Archify ourselves and used it to draw the ThakiCloud stack, here’s our conclusion. The core of this tool isn’t the convenience of “drawing by describing it in words.” It’s the discipline of having a renderer validate every layout an agent produces against the same standard, every time, so a bad diagram never ships. As we said up front, our first render getting rejected was exactly the moment that earned this tool our trust.

So the next step is clear. If you draw architecture diagrams often, and you want those diagrams to live in your docs or repository like code, Archify is worth running once. If instead you’re after a quick sketch or want to stack several diagrams on one page, Mermaid is still the lighter option. The deciding question is whether you want this diagram managed as a reproducible, validated asset. If the answer is yes, then Archify, and the Paxis skill harness that builds the same principle into a product, is the answer.

Sources

• Archify repository: github.com/tt-a1i/archify (MIT, v2.11.0)
• Original tweet: @alin_zone via @hjguyhan
• Experiment log: the commands, output, and measurements in this post were captured from a local run on 2026-07-22 (Node v24.1.0).

Why Read This

This post is for platform engineers and MLOps practitioners who serve LLMs with vLLM, or whose production depends on fast-moving open source. It is for the person who has to decide: “The inference engine we run changes hundreds of times a week. Which version do we upgrade to, and when, without breaking?”

The conclusion first. The key to holding production quality at 2,000 commits a month is not adding tests without limit. It is three deterministic devices: a benchmark gate that catches performance regressions, release-branch pinning to the healthiest commit, and per-commit bisection to isolate a regression when one appears. These are the same operational patterns ThakiCloud can adopt directly when serving vLLM in a multi-tenant setup on Kubernetes.

Overview

On July 16, 2026, the vLLM maintainers published a write-up titled “Keeping vLLM Production Quality.” The numbers alone are staggering. In June 2026, vLLM merged 1,918 commits into main. That is about 64 a day, on par with large open-source projects like PyTorch or Kubernetes. In the same month, CI consumed 13 million job minutes, with 1,400 concurrent runners at peak.

Why does this speed create a problem? It comes from the nature of an inference engine. For a typical web service, “if the tests pass, it is mostly safe” holds. But in an LLM inference engine, a change can pass every test and still make a specific model slower or subtly corrupt its output. Swap one kernel and throughput can halve on a specific GPU architecture, and a regression like that never shows up in a pass/fail unit test.

For an organization like ThakiCloud that depends on vLLM as a core serving dependency, this write-up is not someone else’s story. Every vLLM version we ship governs the latency and throughput of customer workloads. So understanding how vLLM protects itself tells us what we should gate on top of it.

What It Actually Is

vLLM’s quality system splits into three layers. Each layer stops a different kind of failure.

First, broad functional CI. The vLLM CI suite runs 37 test groups and 266 jobs. It covers major components and features from different kernels to speculative decoding to LoRA. This layer verifies “does the code work?”

Second, continuous benchmarking. This layer catches the performance regressions that functional CI misses. It measures performance automatically across many models and GPU devices, and tracks it over time to surface regressions or improvements. This layer verifies “is the code still fast, is the output still correct?”

Third, release engineering. No matter how good CI and benchmarks are, deciding which commit to release to users is a separate call. vLLM entrusts that decision to repeatable rules rather than human intuition.

The diagram below shows how the three layers interlock. Read top to bottom, it is the path a single commit travels to reach a user.

flowchart TB
    A[main branch<br/>1,918 commits/month] --> B{PR CI<br/>37 test groups, 266 jobs}
    B -->|pass| C[merge to main]
    B -->|fail| A
    C --> D[perf-benchmarks + ready labels<br/>benchmark on every commit]
    D --> E[Performance Dashboard<br/>track regressions per model/GPU]
    C --> F[per-commit wheels<br/>for bisection]
    E --> G{every other Monday<br/>release week}
    G --> H[pick greenest full-CI commit]
    H --> I[pin release branch]
    F -.on regression.-> J[bisect by commit hash]
    J -.isolate the culprit commit.-> A

What Broke, and How They Fixed It

This system was not complete from the start. In May 2026, days after releasing v0.20.0, vLLM had to cut two emergency patches. Two problems had sailed straight through CI to users.

One broke gpt-oss on Blackwell GPUs when split across multiple GPUs; the other tanked DeepSeek V4 throughput on GB200. At the time vLLM had no benchmarking pipeline. Both problems passed the functional tests cleanly, but nobody was automatically measuring actual performance and correctness on real hardware.

That incident is the direct reason the continuous benchmarking layer exists. The lesson is clear. The equation “tests pass = safe” does not hold for an inference engine. Functional correctness and performance are separate axes, and each must be gated independently.

The Commands Maintainers Actually Use

This system is exposed not only as a concept but as tooling users can run. Two practical tools for tracking performance regressions are especially useful.

The performance dashboard updates automatically on PRs with specific labels. On every commit that carries both the perf-benchmarks and ready labels, and whenever a PR merges into main, benchmarks run and publish to the public dashboard.

# Labels that trigger performance benchmarks (vLLM PR workflow)
perf-benchmarks + ready
# → run benchmarks on many models/GPUs per commit → publish to public performance dashboard

More interesting is per-commit bisection. vLLM publishes wheels for previous commits, so specifying a commit hash in the install URL installs vLLM exactly as it was at that commit.

# Install a vLLM wheel at a specific commit hash (to bisect behavior/perf regressions)
pip install https://wheels.vllm.ai/<commit-hash>/vllm-<version>-cp38-abi3-manylinux1_x86_64.whl

# Narrow "when did it get slower?" by bisection:
#   good commit A ── ? ── bad commit B
#   → install a midpoint to reproduce → halve the range

Here the real value of release engineering shows. vLLM kicks off release week every other Monday. The release manager reviews the recent full-CI runs on main that day and picks the greenest commit. That secures the healthiest starting point before any release-specific changes are added. Cutting release branches frequently has a hidden benefit: tracing a regression is far easier when you have about 500 commits to bisect rather than a few thousand. The release cadence itself is a device that lowers debugging cost.

The Scale Numbers vLLM Published

Below are the actual figures the write-up published as of June 2026. These are not our reproduction; they are the maintainers’ reported values, quoted verbatim.

What these numbers say is simple. To hold quality at this speed, verification cannot rely on human review and must be replaced by deterministic gates and automated measurement.

Implications for ThakiCloud Products

ThakiCloud’s ai-platform serves models to diverse customer environments on top of Kubernetes and Kueue GPU scheduling. vLLM is the core engine on that serving path, so how vLLM maintains quality feeds directly into our release policy design.

First, separate version pinning from the benchmark gate. Per vLLM’s lesson, we do not promote a new version to production on functional test passes alone. We automatically run throughput and latency benchmarks on representative customer workloads (model/GPU combinations) before rollout, and place a gate that blocks promotion when a regression is detected. This moves vLLM’s continuous benchmarking layer into a gate on our deployment pipeline.

Second, pin the vLLM release explicitly in the ArgoCD-based GitOps rollout. Rather than tracking the latest commit on main, we treat the release tag vLLM has itself verified and cut as canonical, and pin that tag in per-cluster values. Rolling out first to a few tenants as a canary, then expanding to all only when the benchmark dashboard is green, reproduces vLLM’s “pick the healthiest commit” principle at the deployment layer.

Third, use per-commit wheels for in-house regression tracing. When a specific customer signals “it got slower than last week,” we can bisect with vLLM’s per-commit wheels to isolate the culprit commit. Quickly narrowing where a regression’s responsibility lies in a multi-tenant environment is central to operational trust.

These three converge on one principle. To operate production on top of a fast-moving upstream dependency, you must delegate quality judgment to automated gates, not human intuition.

Limits and Counterarguments

vLLM’s approach does not transplant cleanly to every organization. There are real constraints.

The biggest is cost. 13 million CI minutes a month and 1,400 concurrent runners presume a substantial infrastructure budget. It is unrealistic for a small team to clone a benchmark farm at this scale. So what we need is not a replica of the scale but a representative benchmark narrowed to core workloads. Gating only the top few combinations of actual customer traffic, rather than the full model/GPU matrix, pays off far better per dollar.

Second, a benchmark’s coverage is its limit. Regressions in models, sequence lengths, or batch combinations that are not in the benchmark still leak through. vLLM’s May incident was missed precisely because there was no benchmark, and even after adding one, combinations absent from the dashboard remain blind spots. Never forget that a gate protects only “what you measured.”

Third, the biweekly release cadence is a trade-off between stability and freshness. Cutting releases frequently makes bisection easier, but slows how fast new features reach production. If a customer urgently needs the latest kernel optimization, a policy that insists on stable releases only can itself become the bottleneck. That balance point differs by organization.

Wrap-Up

Back to the problem of protecting production on top of fast-moving open source. vLLM does not collapse at 2,000 commits a month not because it adds tests without limit, but because it has three deterministic devices: a benchmark gate that stops performance regressions, release-branch pinning that picks the healthiest commit, and per-commit bisection that narrows the cause.

For an organization like ThakiCloud that runs vLLM as a serving core, the action to take today is clear. When you upgrade to a new vLLM version, do not rely on functional test passes alone; stand up a benchmark on representative customer workloads as a rollout gate. And instead of tracking main, pin the release tag vLLM has verified into your GitOps values. Putting just these two into your deployment pipeline lets you absorb the upstream’s speed while protecting the downstream’s stability. Quality comes not from more tests, but from a gate placed in the right spot.

Sources

• vLLM Blog, “Keeping vLLM Production Quality: A Look Inside CI, Benchmarking, and the Release Process” (2026-07-16): https://vllm.ai/blog/2026-07-16-keeping-vllm-production-quality
• vLLM Performance Dashboard (docs): https://docs.vllm.ai/en/latest/benchmarking/dashboard/

이 두 릴리스를 따로 읽으면 각자 흔한 뉴스입니다. 나란히 놓고 보면 이야기가 달라집니다. 소프트웨어를 만드는 쪽과 그 소프트웨어를 감사하는 쪽이 동시에 에이전트로 넘어가고 있다는 뜻이기 때문입니다. 그리고 두 모델을 모두 자기 인프라에 올려놓는 순간, 아무도 대신 답해 주지 않는 질문이 남습니다. 이 에이전트들은 실제로 누구의 자원 위에서, 어떤 권한으로, 어떤 기록을 남기며 돌아가는가.

같은 날, 정확히 반대편에서

풀사이드의 라구나 S 2.1은 서구권 진영이 내놓은 대응 카드에 가깝습니다. 그동안 딥시크와 큐원 같은 중국계 오픈웨이트 모델이 코딩 에이전트 영역에서 앞서 나가던 흐름을 겨냥한 발표입니다. 외신들은 이 모델을 지난 1년간 나온 서구권 오픈웨이트 모델 가운데 자체 호스팅 에이전틱 코딩용으로 가장 신뢰할 만한 선택지로 소개했습니다. 흥미로운 대목은 성능이 아니라 몸집입니다. 활성 매개변수 80억 개짜리 저활성 구조로 몇 배 큰 경쟁 모델과 벤치마크에서 맞먹었다고 하니, 추론 비용과 온프레미스 구동 부담을 동시에 낮췄다는 점이 진짜 메시지입니다. DGX 스파크급 장비 한 대로 돌릴 수 있다는 대목은 곧 소규모 GPU 파티션에도 전용 코딩 에이전트를 태울 수 있다는 뜻입니다.

시스코의 안타레스는 반대편에서 같은 논리를 폅니다. 온디바이스로 돌아가는 소형 언어모델이 보안 영역에서 거대 범용 모델을 비용과 정확도 양면에서 앞선다는 것입니다. 시스코는 안타레스가 벤치마크에서 십여 개의 대형 오픈·클로즈드 모델을 능가하면서도 훨씬 저렴하게 구동된다고 주장했습니다. 여기서 결정적인 것은 실행 위치입니다. 로컬에서 돌아가므로 소스코드를 외부로 내보내지 않아도 됩니다. 소스코드 반출 규제가 엄격한 금융권과 공공기관에는 이 한 문장이 도입 여부를 가르는 조건이 됩니다.

두 모델은 방향이 반대인데 설계 철학이 똑같습니다. 작게 만들고, 오픈웨이트로 풀고, 남의 클라우드가 아니라 내 인프라에서 돌린다. 배포 전략마저 닮았습니다. 핵심 모델은 오픈웨이트로 공개하되 가장 성능이 좋은 버전은 자사 제품에 남겨 두는 방식은 요즘 보안 스타트업과 대형 벤더가 공통으로 택하는 문법입니다. 생성과 감사가 나란히 셀프호스팅의 규칙으로 재편되고 있는 것입니다.

오픈웨이트가 감사의 규칙을 바꾼 지점

과거의 코드 취약점 스캔은 대개 프런티어 모델을 호출하는 방식이었습니다. 문제는 두 가지였습니다. 비용이 상시 운영을 어렵게 만들었고, 스캔 대상인 소스코드가 외부 API로 흘러 나갔습니다. 국내 보안팀 다수가 예산 제약으로 상시 스캔을 포기했던 이유가 여기에 있습니다. 안타레스는 그 두 병목을 한꺼번에 건드립니다. 로컬 실행으로 반출 문제를 없애고, 소형 모델로 비용을 낮춥니다. 시스코가 대학과 공공 부문, 예산이 부족한 중소 보안팀을 명시적 대상으로 삼은 것도 이 맥락입니다.

같은 논리는 생성 쪽에도 그대로 적용됩니다. 라구나 S 2.1이 허용적 라이선스와 오픈웨이트를 함께 갖췄다는 점은 망분리 환경이나 국정원 요구사항을 충족해야 하는 금융·공공 분야에서 셀프호스팅 코딩 어시스턴트를 구성할 여지를 넓힙니다. 폐쇄형 API에 대한 의존을 줄이는 선택지가 하나 더 생긴 것입니다. 물론 이 자유에는 숙제가 따라옵니다. 국내 유통·지원 생태계와 한국어 코드 주석 대응력이 아직 검증되지 않았기 때문에, 실제 도입은 벤치마크 재현과 한국어 환경 적합성 테스트를 먼저 통과해야 합니다.

다만 시스코는 스스로 선을 그었습니다. 이 모델은 의존성 분석이나 비밀정보 스캔, 동적 테스트를 대체하지 않으며 초기 필터링 단계에 위치해야 한다는 것입니다. 정직한 제한입니다. 그리고 이 제한이 오늘의 진짜 주제로 이어집니다. 생성 모델도 감사 모델도 결국 자기 역할의 조각만 담당할 뿐, 두 조각을 하나의 책임 있는 흐름으로 엮는 일은 별개의 문제라는 사실입니다.

생성도 감사도 메우지 못하는 틈

같은 날의 다른 기사가 그 틈을 정확히 보여 줍니다. 국내 이커머스 플랫폼 아임웹은 개발과 운영 전반에 AI를 투입해 4년 걸릴 일을 3개월로 줄였다고 밝혔습니다. OpenAI와 앤스로픽, 구글의 모델을 상호 검증용으로 동시에 쓰는 보수적 문화까지 갖췄습니다. 그런데 한 문장이 눈에 걸립니다. 인프라 이상을 탐지하면 배포 후 자동 롤백을 사람 승인 없이 즉시 수행한다는 대목입니다. 생산성 관점에서는 자랑거리지만, 거버넌스 관점에서는 경보음입니다. 승인 없이 프로덕션을 되돌릴 수 있는 에이전트는, 승인 없이 다른 일도 할 수 있다는 뜻이기 때문입니다.

공공 쪽 신호는 정반대 방향에서 같은 결론을 가리킵니다. 예금보험공사는 생성형 AI 서비스를 도입하면서 모델 선정보다 데이터 카탈로그 구축과 AI 리스크 관리 체계를 선행 과제로 잡았습니다. 국민 자산을 다루는 기관이 모델보다 통제 체계를 먼저 세운다는 것은, 규제 산업에서 AI 도입의 실제 관문이 성능이 아니라 설명 가능성과 감사 추적이라는 점을 그대로 드러냅니다. 한쪽에서는 자율성이 앞서 나가고, 다른 한쪽에서는 통제가 먼저 자리를 잡습니다. 두 요구가 만나는 지점에 지금은 표준화된 계층이 비어 있습니다.

생성 모델은 코드를 만들고, 감사 모델은 코드의 결함을 찾습니다. 그러나 그 에이전트가 어떤 자율도로 움직이는지, 어떤 정책의 허락을 받고 실행되는지, 무엇을 언제 건드렸는지를 남기는 일은 두 모델 어느 쪽의 소관도 아닙니다. 이것은 모델의 문제가 아니라 실행 계층의 문제입니다.

하드웨어 주권만으로는 닫히지 않습니다

이 공백을 인프라의 규모로 메울 수 있을 것 같지만, 오늘 뉴스는 그렇지 않다고 말합니다. 같은 날 이재용·최태원·이해진 세 총수가 실리콘밸리에서 젠슨 황을 만나 엔비디아 중심의 AI 공급망 동맹을 재가동했습니다. 국내 소버린 AI 인프라 판도를 흔들 큰 움직임입니다. 삼성SDS는 퓨리오사AI의 국산 NPU를 얹은 NPUaaS를 출시하며 GPU 일변도였던 추론 인프라에 국산 대안을 처음 상용화 단계로 올렸습니다. 공공·금융 입장에서는 해외 GPU 의존을 낮출 소버린 옵션이 하나 더 생긴 것이고, 앞으로 정부 클라우드 입찰에서 국산 NPU가 요건으로 등장할 여지도 있습니다.

칩과 데이터센터, 공급망 차원의 주권은 이렇게 빠르게 채워지고 있습니다. 그런데 하드웨어 주권은 질문의 절반만 답합니다. 국산 NPU 위에서 셀프호스팅 코딩 에이전트가 돌아간다고 해서, 그 에이전트가 무엇을 할 권한이 있고 무엇을 남겨야 하는지가 저절로 정의되지는 않습니다. 반출을 막는 것과 실행을 통제하는 것은 다른 층위의 문제입니다. 소버린 인프라가 완성될수록, 그 위에서 움직이는 에이전트의 자율도와 감사를 소프트웨어로 규정하는 계층의 부재가 오히려 더 또렷하게 드러납니다.

실행 계층에서 답을 맞춥니다

ThakiCloud의 Paxis는 바로 이 비어 있는 계층을 다룹니다. Paxis는 에이전트를 위한 클라우드로, Skills와 Tools, Policies, Audit Logs를 일급 리소스로 취급하는 정식 제품입니다. 라구나 S 2.1 같은 코딩 에이전트를 백엔드에 붙이든 안타레스 같은 감사 모델을 스캔 전단에 붙이든, 그 에이전트는 결국 정책 게이트를 통과해 격리된 샌드박스에서 실행되고 모든 행위가 감사 로그에 남습니다. 아임웹 사례의 무승인 자동 롤백이 불안하게 읽혔다면, Paxis의 L0에서 L3까지 이어지는 자율도 거버넌스가 그 불안의 반대편입니다. 어떤 작업은 완전 자율로 두고 어떤 작업은 사람 승인을 강제하는 경계를 코드가 아니라 정책으로 선언할 수 있습니다.

소버린 요구도 같은 계층에서 만납니다. 안타레스가 소스코드 반출 없이 로컬에서 돌아야 의미가 있듯, Paxis는 소버린·온프렘 쿠버네티스 위에서 동작하며 작업별로 모델을 고르는 CostRouter를 갖췄습니다. 저비용 로컬 모델로 의심 파일을 좁힌 뒤 필요할 때만 큰 모델을 부르는 방식은, 시스코가 안타레스를 초기 필터로 위치시키라고 권한 그 설계를 인프라 차원에서 그대로 구현한 것입니다. MCP 커넥터와 스킬 마켓을 통해 새 모델과 도구를 얹더라도 실행과 기록의 규칙은 바뀌지 않습니다. 예금보험공사가 모델보다 먼저 세우려 했던 데이터 거버넌스와 리스크 관리 체계 역시, 개별 프로젝트마다 새로 짜는 것이 아니라 플랫폼이 기본으로 제공하는 정책과 감사 계층으로 흡수됩니다.

여기서 정당한 반론이 나올 수 있습니다. 결국 또 하나의 통제 계층을 얹는 것 아니냐, 오픈웨이트가 어렵게 되찾아 준 속도와 자율성을 정책과 감사라는 이름으로 다시 묶는 것 아니냐는 것입니다. 아임웹이 사람 승인 없이 즉시 롤백하는 방식으로 4년 걸릴 일을 3개월에 끝냈다면, 그 속도야말로 경쟁력의 원천일 수 있습니다. 타당한 지적입니다. 다만 자율도 거버넌스의 목적은 자율을 없애는 것이 아니라 자율의 범위를 명시적으로 그어 주는 데 있습니다. 승인 없이 롤백해도 되는 작업과 반드시 사람을 거쳐야 하는 작업을 구분해 선언해 두면, 안전한 영역에서는 오히려 더 과감하게 위임할 수 있습니다. 경계가 흐릿할 때 팀은 모든 자동화를 의심하지만, 경계가 정책으로 박혀 있을 때 팀은 그 안에서 마음 놓고 달립니다. 통제와 속도는 대립이 아니라, 경계가 선명할 때 함께 커집니다. 예금보험공사가 모델보다 통제 체계를 먼저 세운 것도 도입을 늦추려는 것이 아니라, 도입을 지속 가능하게 만들려는 선택이었습니다.

7월 22일의 두 릴리스는 에이전트가 코드를 쓰는 능력과 감시하는 능력을 동시에 갖추기 시작했음을 알립니다. 반가운 진전입니다. 다만 능력이 늘수록 책임의 공백도 함께 커집니다. 코드를 만드는 에이전트와 감사하는 에이전트가 흔해질수록, 정작 희소해지는 것은 그 에이전트들이 안전하게 실행되고 남김없이 기록되는 자리입니다. 창과 방패를 다 갖춘 다음에 남는 질문은 하나입니다. 이 둘은 결국 누구의 규칙 위에서 싸우는가. 모델을 고르는 일은 갈수록 쉬워지지만, 그 모델이 만든 결과에 책임을 지는 일은 여전히 어렵습니다. 오늘 나란히 걸린 창과 방패가 우리에게 알려 주는 것은, 다음 경쟁의 무대가 더 큰 모델이 아니라 그 모델들이 안전하게 살아 움직이는 실행 계층이라는 사실입니다.

참고 자료

이 글은 아래 뉴스를 종합해 작성했습니다.

• 글로벌경제, 엔비디아, 차세대 AI플랫폼 ‘베라루빈’ 본격 공급 통해 “선두 수성”
• 머니투데이, LGU+·LS일렉트릭, AI 데이터센터 800V DC 공동 개발 나선다
• 글로벌이코노믹, HPE, 슈퍼컴퓨팅 개발환경 통합…소버린 AI 인프라 간소화
• 뉴스웍스, [#클라우드 월드] 삼성SDS-퓨리오사AI ‘NPUaaS’ 출시·LG CNS ‘AI 캠퍼스’…
• 지디넷코리아, “SKT, AI팩토리에 가장 적극적인 통신사…풀스택AI·전국망 경쟁력”
• 약업신문, BMS‧엔비디아, 생명공학 최강 AI 팩토리 구축
• 글로벌이코노믹, 미국 데이터센터 전력 수요 급증… 호남 반도체 허브, 전력망·용수가 …
• 디지털투데이, 풀사이드, 코딩 에이전트용 오픈웨이트 모델 ‘라구나 S 2.1’ 공개
• 이투데이, 키미 쇼크에 ‘AI 2강’ 험로…’특화 AI’ 키우고, 경량화 모델로 차별화…
• 디지털투데이, 포티투마루, 예금보험공사 데이터 관리체계 고도화·생성형 AI 서비스 구…
• 뉴스투데이, 밖에선 AI 인재 찾고 안에선 업무 혁신…NHN의 AX ‘승부수’
• 바이라인네트워크, “4년 걸린 일을 3개월에”…아임웹이 안팎으로 AI 쓰는 법
• IT조선, 내년 지원 불투명한데…정부 ‘모두의 AI’ 출시 서두르나
• EBN, 이재용·최태원·이해진, 美서 젠슨 황 만난다…AI 공급망 동맹 재가동
• 디지털투데이, 시스코, 코드 취약점 탐지 특화 오픈웨이트 소형 모델 ‘안타레스’ 공개
• 뉴스저널리즘, AI가 바꾼 보안 공식…에스원 ‘현장 데이터’로 승부

왜 읽어야 하나

이 글은 아키텍처 다이어그램을 자주 그리지만 Mermaid 문법이나 그리기 도구에 시간을 빼앗기는 개발자와 플랫폼 엔지니어를 위한 것입니다. 도구를 하나 고르기 위한 판단 근거가 필요한 사람에게 도움이 됩니다.

먼저 결론부터 말씀드리겠습니다. Archify의 진짜 가치는 “말로 그림을 그려 준다”는 편의가 아니라, 에이전트가 만든 배치를 렌더러가 강제로 검증해 어긋난 그림을 아예 만들지 못하게 막는다는 점에 있습니다. 실제로 돌려 보니 첫 시도는 렌더가 거부당했고, 그 거부가 이 도구를 쓸 만하게 만드는 핵심이었습니다.

개요

아키텍처 다이어그램은 개발자가 가장 자주 그리면서도 가장 귀찮아하는 산출물입니다. Mermaid를 쓰면 문법을 외워야 하고, 그리기 도구를 쓰면 상자와 선을 손으로 끌어다 맞춰야 합니다. 다 그려 놓아도 다크 모드가 안 맞거나, 발표 자료에 넣으려면 다시 내보내기를 해야 합니다.

최근 중국 개발자 커뮤니티에서 화제가 된 Archify는 이 지점을 겨냥합니다. “이 저장소 몇 개를 읽고 아키텍처 비교도를 그려 줘” 같은 평범한 문장을 Claude Code나 Codex에 던지면, 브라우저에서 바로 열리는 자기완결형 HTML 다이어그램 한 장이 나옵니다. 다크·라이트 테마를 토글할 수 있고, PNG·SVG로 내보낼 수도 있습니다.

여기까지는 흔한 홍보 문구입니다. 그래서 저희는 문구를 믿는 대신 실제로 설치해 돌려 보고, 타키클라우드의 ai-platform 구조를 직접 그려 봤습니다. 그 과정에서 이 도구가 왜 단순한 “AI 그림 생성기”와 다른지가 드러났습니다. 이 글은 그 실험 기록이자, 타키클라우드가 만드는 에이전트 플랫폼 Paxis의 설계 철학과 어떻게 맞닿는지에 대한 정리입니다.

이 도구는 무엇인가

Archify는 tt-a1i가 MIT 라이선스로 공개한 오픈소스 에이전트 스킬입니다. 실험 시점 기준 버전은 2.11.0이며, Cocoon AI의 architecture-diagram-generator v1.0을 포크해 다시 쓴 것으로, 원래의 시각 언어는 Cocoon AI에 크레딧을 남기고 있습니다. Claude, Codex CLI, opencode 등 여러 에이전트 런타임에 설치됩니다.

핵심 구조를 이해하면 이 도구가 왜 특이한지 보입니다. Archify는 그림을 곧바로 그리지 않습니다. 대신 다이어그램을 JSON-IR(중간 표현) 로 기술하고, 타입별 렌더러가 그 JSON을 받아 HTML을 만듭니다. 렌더러는 다섯 종류입니다. 아키텍처(architecture), 워크플로(workflow), 시퀀스(sequence), 데이터플로(dataflow), 라이프사이클(lifecycle)입니다. 즉 “무엇을 그릴지”는 구조화된 JSON이 담고, “어떻게 그릴지”는 검증된 코드가 소유합니다.

다섯 렌더러는 각각 다른 종류의 그림을 담당합니다. architecture는 시스템 구성 요소와 경계를 담고, workflow는 승인 흐름이나 CI/CD 같은 절차를, sequence는 요청 생애주기나 API 호출 순서를, dataflow는 ETL과 이벤트 스트림 같은 데이터 이동을, lifecycle는 배포나 에이전트 실행의 상태 전이를 표현합니다. 그리려는 대상이 정해지면 그에 맞는 렌더러와 스키마가 붙고, 그 스키마가 입력 JSON을 강제합니다.

이 역할 분담이 Mermaid와의 결정적 차이를 만듭니다. Mermaid는 문법을 파싱해 자동 배치(dagre)로 그림을 뽑지만, 선이 상자를 가로지르거나 라벨이 겹쳐도 그대로 그려 냅니다. Archify는 반대로 배치 좌표를 명시하게 하고, 렌더 직전에 레이아웃 규칙을 강제로 검사합니다. 규칙을 어기면 그림을 만들지 않고 오류를 냅니다.

전체 흐름은 다음과 같습니다.

flowchart TB
    A["자연어 요청<br/>(저장소를 읽고 아키텍처를 그려 줘)"] --> B["에이전트<br/>Claude Code / Codex"]
    B --> C["JSON-IR 작성<br/>components · connections · boundaries"]
    C --> D["타입 렌더러<br/>architecture / workflow / sequence / dataflow / lifecycle"]
    D --> E{"레이아웃 검증<br/>선-노드 교차 · 라벨 겹침"}
    E -.검증 실패 + 수정 제안.-> C
    E -->|통과| F["자기완결형 HTML<br/>다크·라이트 테마 · PNG/SVG 내보내기"]

설치 및 통합

설치는 npx 한 줄이면 됩니다. 전역 설치는 아래와 같습니다.

# 전역 설치 후 에이전트 선택
npx skills add tt-a1i/archify -g

# 영구 설치 없이 한 번만 써 보기
npx skills use tt-a1i/archify@archify --agent codex

저장소를 직접 클론해 CLI로 검증하고 예제를 뽑아 볼 수도 있습니다. 실제로 저희가 실행한 명령과 출력은 다음과 같습니다. 실험 환경은 Node.js v24.1.0이었고, Archify가 요구하는 런타임은 Node 18 이상, 런타임 의존성은 사실상 없었습니다(개발 의존성으로 스키마 검증용 ajv 하나만 있습니다).

git clone --depth 1 https://github.com/tt-a1i/archify.git
cd archify/archify

# 설치 상태 점검
node bin/archify.mjs doctor

doctor 명령의 실제 출력입니다. 다섯 개 렌더러와 스키마 검증기가 모두 정상으로 확인되었습니다.

Archify doctor

[ok] Node.js v24.1.0 (requires >=18)
[ok] Core template
[ok] Standalone schema validators
[ok] architecture renderer, schema, and example
[ok] workflow renderer, schema, and example
[ok] sequence renderer, schema, and example
[ok] dataflow renderer, schema, and example
[ok] lifecycle renderer, schema, and example

Archify is ready.

내장 예제를 한 장 뽑아 보면, 외부 서버 없이 브라우저에서 바로 열리는 508KB짜리 자기완결형 HTML 한 파일이 생성됩니다.

node bin/archify.mjs demo ./out
# Demo ready: ./out/archify-demo.html   (약 508KB, 단일 HTML)

실제 실험 결과

문서만 읽으면 여기까지가 전부처럼 보입니다. 그래서 저희는 남의 예제가 아니라 타키클라우드 ai-platform의 실제 구조를 JSON-IR로 직접 기술해 렌더링해 봤습니다. Kueue로 GPU를 스케줄링하고 vLLM으로 모델을 서빙하며, Keycloak으로 멀티테넌트 인증을, PostgreSQL과 NATS로 상태와 이벤트를, ArgoCD로 GitOps 배포를 다루는 아홉 개 구성 요소를 넣었습니다.

JSON-IR은 사람이 읽고 쓰기에도 어렵지 않았습니다. 구성 요소는 종류와 라벨, 위치와 크기를 가진 객체이고, 연결은 어디에서 어디로 가는지와 라벨을 담습니다. 예를 들어 게이트웨이와 GPU 서빙 부분은 다음과 같이 기술했습니다.

{
  "components": [
    { "id": "gateway", "type": "backend", "label": "API Gateway",
      "sublabel": "Go Fiber :8080", "pos": [280, 300], "size": [140, 60] },
    { "id": "vllm", "type": "backend", "label": "vLLM Server",
      "sublabel": "OpenAI API", "pos": [540, 300], "size": [140, 60] }
  ],
  "connections": [
    { "id": "gw-to-vllm", "from": "gateway", "to": "vllm", "label": "route inference" },
    { "id": "vllm-gpu", "from": "vllm", "to": "gpupool", "label": "CUDA", "variant": "emphasis" }
  ]
}

첫 렌더 시도는 실패했습니다. 그리고 이 실패가 이 글에서 가장 중요한 대목입니다. 렌더러는 그림을 그리는 대신 다음과 같은 구체적인 문제를 세 가지 짚어 냈습니다.

Error: Architecture layout validation failed:
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "vllm" (unrelated to this relationship)
- [clean-flow/edge-through-node] connection "kueue-gpu" (kueue -> gpupool)
  crosses component "argocd" (unrelated to this relationship)
- Label "publish" overlaps component "gateway"
  Suggested fix: labelDy +24 (below); or labelAt [350, 374]

즉 Kueue에서 GPU 풀로 가는 연결선이 관계없는 vLLM과 ArgoCD 상자를 관통했고, “publish” 라벨이 게이트웨이 상자와 겹쳤습니다. 주목할 점은 렌더러가 문제만 지적한 게 아니라 어떻게 고치라는 제안까지 함께 줬다는 것입니다. 라벨을 얼마나 내리라는 좌표까지 계산해 줬습니다.

제안대로 연결선에 우회 경로(via)를 주고 라벨 위치를 조정한 뒤 다시 렌더링하니 이번에는 통과했습니다. 실측 결과는 다음과 같습니다.

정리하면, 렌더 자체는 73밀리초로 사실상 즉시입니다. 결과물은 이미지 서버나 CDN에 의존하지 않는 자기완결형 HTML 한 장이며, 유일한 외부 참조는 코드용 웹폰트 하나뿐이라 오프라인에서도 시스템 폰트로 깨지지 않고 열립니다. 다크·라이트 테마는 장식이 아니라 실제 CSS 변수와 prefers-color-scheme로 구현되어 있었습니다.

여기서 얻은 교훈은 분명합니다. Archify의 검증기는 “예쁜 그림”을 만드는 장치가 아니라, 선이 엉키거나 라벨이 겹치는 나쁜 다이어그램을 배포 단계에서 원천 차단하는 게이트입니다. 사람이 손으로 그렸다면 그냥 넘어갔을 시각적 결함을, 코드가 매번 같은 기준으로 잡아냈습니다.

타키클라우드 제품 적용 시사점

이 도구의 설계는 타키클라우드가 두 제품에서 지키는 원칙과 정확히 맞닿습니다.

Paxis 렌즈(에이전트·스킬). Paxis는 타키클라우드의 Agent-Native Cloud로, 스킬을 일급 리소스로 다룹니다. 960개가 넘는 스킬을 BM25로 선택해 격리된 샌드박스에서 실행하고, 모든 행동을 정책 게이트와 감사 로그로 통과시킵니다. Archify는 정확히 이런 스킬 하니스가 선택해 실행하기 좋은 형태의 도구입니다. 더 중요한 것은 그 내부 설계입니다. Archify는 모델이 내용(JSON-IR)을 만들고, 코드가 포맷과 검증을 소유합니다. 이는 타키클라우드가 배치 산출물에서 반복해 강조하는 원칙, 즉 자유도가 높은 생성 단계와 결정론적 검증 단계를 분리하라는 원칙과 같습니다. 모델에게 “예쁘게 그려 줘”라고 부탁하는 대신, 구조화된 표현을 만들게 하고 그 표현이 규칙을 지키는지는 코드가 강제하는 방식입니다. 저희의 첫 렌더가 거부당한 경험이 바로 이 원칙이 실제로 작동한 순간이었습니다.

ai-platform 렌즈(인프라·문서화). 자기완결형 HTML은 온프렘·소버린 환경에서 특히 유용합니다. 외부 다이어그램 SaaS에 내부 아키텍처를 올릴 수 없는 고객에게, 렌더가 로컬에서 끝나고 결과가 단일 파일로 남는 방식은 그대로 반입 가능한 산출물이 됩니다. 또한 JSON-IR은 텍스트라 Git으로 버전 관리되고 diff가 됩니다. ArgoCD로 매니페스트를 관리하듯 아키텍처 다이어그램도 코드로 관리하며, 변경 이력을 추적하고 리뷰할 수 있습니다. 신입 온보딩 문서나 고객용 배포 구조도를 매번 손으로 다시 그리는 대신, 구조가 바뀔 때 JSON만 고쳐 다시 렌더하면 됩니다.

두 렌즈는 서로를 보완합니다. 검증된 스킬(Paxis)이 재현 가능한 산출물(ai-platform 문서화)을 만들고, 그 산출물이 다시 온프렘 고객에게 반입 가능한 자산이 됩니다.

한계 및 반론

물론 Archify가 만능은 아닙니다. 몇 가지 분명한 약점이 있습니다.

첫째, 배치 좌표를 명시해야 합니다. Mermaid의 자동 배치와 달리 각 구성 요소의 위치와 크기를 좌표로 줘야 하고, 그 배치가 검증을 통과해야 합니다. 저희 첫 시도가 실패한 것처럼, 이 과정은 완전히 공짜가 아닙니다. 다만 실무에서는 에이전트가 이 좌표를 대신 채우고 검증 오류를 받아 스스로 고치므로, 사람이 감당할 부담은 줄어듭니다.

둘째, 출력이 가볍지 않습니다. 다이어그램 한 장이 약 508KB의 HTML입니다. 폰트와 스크립트를 자기완결형으로 담기 때문인데, 단순한 SVG나 Mermaid 블록보다는 무겁습니다. 블로그처럼 여러 다이어그램을 한 페이지에 넣는 경우에는 부담이 될 수 있습니다.

셋째, 라이브러리로 배포된 도구가 아닙니다. package.json이 private: true로 표시되어 있어, npm 패키지로 가져다 쓰는 방식이 아니라 저장소의 스킬·CLI로 소비하는 형태입니다. 파이프라인에 라이브러리로 묶으려면 별도 고민이 필요합니다.

넷째, 정적 스냅샷입니다. 실시간 데이터로 갱신되는 대시보드가 아니라, 특정 시점의 구조를 담은 그림입니다. 빠르게 낙서하듯 스케치하고 싶을 때는 검증 규칙의 엄격함이 오히려 마찰이 될 수 있습니다. 물론 그 엄격함이 이 도구의 존재 이유이기도 합니다.

정리

Archify를 직접 설치해 타키클라우드 스택을 그려 본 결론은 이렇습니다. 이 도구의 핵심은 “말로 그림을 그린다”는 편의가 아니라, 에이전트가 만든 배치를 렌더러가 매번 같은 기준으로 검증해 나쁜 다이어그램을 배포 전에 막는다는 규율입니다. 서론에서 말씀드린 그대로, 저희 첫 렌더가 거부당한 경험이 이 도구를 신뢰하게 만든 지점이었습니다.

그래서 다음 행동은 명확합니다. 아키텍처 다이어그램을 자주 그리고, 그 그림을 문서나 저장소에 코드처럼 남기고 싶다면 Archify를 한 번 돌려 볼 값어치가 있습니다. 반대로 빠른 스케치나 페이지에 여러 장을 얹는 용도라면 Mermaid가 여전히 가볍습니다. 판단 기준은 “이 그림을 재현 가능하고 검증된 자산으로 관리할 것인가”입니다. 그렇다면 Archify가, 그리고 같은 원리를 제품으로 만드는 Paxis의 스킬 하니스가 답이 됩니다.

출처

• Archify 저장소: github.com/tt-a1i/archify (MIT, v2.11.0)
• 원 소개 트윗: @alin_zone via @hjguyhan
• 실험 기록: 본문의 명령·출력·측정값은 2026-07-22 로컬 실행(Node v24.1.0)에서 캡처했습니다.

왜 읽어야 하나

이 글은 vLLM으로 LLM을 서빙하거나, 빠르게 움직이는 오픈소스에 프로덕션을 의존하는 플랫폼 엔지니어와 MLOps 실무자를 위해 씁니다. “우리가 쓰는 추론 엔진이 매주 수백 개씩 바뀌는데, 어느 버전을 언제 올려야 안전한가”를 결정해야 하는 사람이 읽을 글입니다.

핵심 결론을 먼저 말씀드리겠습니다. 월 2,000 커밋이라는 속도에서도 프로덕션 품질을 지키는 열쇠는 테스트를 무한정 늘리는 것이 아닙니다. 벤치마크 게이트로 성능 회귀를 막고, 릴리스 브랜치를 가장 건강한 커밋에 고정하며, 회귀가 생기면 커밋 단위로 이등분해 원인을 특정하는 세 가지 결정론적 장치입니다. 이 셋은 타키클라우드가 vLLM을 K8s 위에서 멀티테넌트로 서빙할 때 그대로 차용할 수 있는 운영 패턴이기도 합니다.

개요

2026년 7월 16일, vLLM 유지관리팀은 「Keeping vLLM Production Quality」라는 운영기를 공개했습니다. 숫자부터가 압도적입니다. 2026년 6월 한 달 동안 vLLM은 main 브랜치에 1,918개의 커밋을 병합했습니다. 하루 평균 약 64개로, PyTorch나 Kubernetes 같은 대형 오픈소스와 맞먹는 속도입니다. 같은 달 CI는 1,300만 분(job minutes)을 소비했고, 피크 시점에는 1,400개의 러너가 동시에 돌았습니다.

이 속도가 왜 문제가 되는지는 추론 엔진의 특성에서 나옵니다. 일반적인 웹 서비스라면 “테스트가 통과하면 대체로 안전하다”는 가정이 통합니다. 그러나 LLM 추론 엔진에서는 모든 테스트를 통과하고도 특정 모델이 느려지거나, 출력이 미묘하게 틀어지는 일이 벌어집니다. 커널 하나가 바뀌면 특정 GPU 아키텍처에서만 처리량이 절반으로 떨어질 수 있고, 그런 회귀는 단위 테스트의 통과/실패로는 절대 잡히지 않습니다.

타키클라우드처럼 vLLM을 프로덕션 서빙의 핵심 의존성으로 쓰는 조직에게 이 운영기는 단순한 남의 집 이야기가 아닙니다. 우리가 올리는 vLLM 버전 하나하나가 고객 워크로드의 지연 시간과 처리량을 좌우하기 때문입니다. 그래서 vLLM이 스스로를 어떻게 지키는지 이해하면, 우리가 그 위에서 무엇을 게이트로 삼아야 하는지가 보입니다.

이 기술은 무엇인가

vLLM의 품질 유지 체계는 세 개의 층으로 나뉩니다. 각 층이 서로 다른 종류의 실패를 막습니다.

첫째, 광범위한 기능 CI입니다. vLLM의 CI 스위트는 37개의 테스트 그룹, 266개의 잡으로 구성됩니다. 서로 다른 커널부터 스페큘러티브 디코딩(speculative decoding), LoRA에 이르기까지 주요 컴포넌트와 기능을 모두 덮습니다. 이 층은 “코드가 동작하는가”를 검증합니다.

둘째, 연속 벤치마킹(continuous benchmarking)입니다. 기능 CI가 놓치는 성능 회귀를 잡기 위한 층입니다. 여러 모델과 GPU 디바이스에 걸쳐 성능을 자동으로 측정하고, 시간에 따라 추적해 회귀나 개선을 드러냅니다. 이 층은 “코드가 여전히 빠른가, 출력이 여전히 옳은가”를 검증합니다.

셋째, 릴리스 엔지니어링입니다. 아무리 좋은 CI와 벤치마크가 있어도, 어느 커밋을 사용자에게 릴리스로 내보낼지는 별도의 결정입니다. vLLM은 이 결정을 사람의 직관이 아니라 반복 가능한 규칙에 맡깁니다.

아래 다이어그램이 세 층이 어떻게 맞물리는지 보여줍니다. 세로로 읽으면 커밋 하나가 사용자에게 도달하기까지의 흐름이 됩니다.

flowchart TB
    A[main 브랜치<br/>월 1,918 커밋] --> B{PR CI<br/>37개 테스트 그룹 · 266 잡}
    B -->|통과| C[main 병합]
    B -->|실패| A
    C --> D[perf-benchmarks + ready 라벨<br/>커밋마다 벤치마크 실행]
    D --> E[퍼포먼스 대시보드<br/>모델·GPU별 회귀 추적]
    C --> F[커밋별 wheel 발행<br/>이등분용]
    E --> G{격주 월요일<br/>릴리스 주간}
    G --> H[가장 초록빛 full-CI 커밋 선택]
    H --> I[릴리스 브랜치 고정]
    F -.회귀 발생 시.-> J[커밋 해시로 이등분]
    J -.원인 커밋 특정.-> A

무엇이 실패했고, 어떻게 고쳤나

이 체계는 처음부터 완성돼 있던 것이 아닙니다. 2026년 5월, vLLM은 v0.20.0을 릴리스한 뒤 며칠 만에 두 개의 긴급 패치를 잘라내야 했습니다. 두 가지 문제가 CI를 그대로 통과해 사용자에게 도달했기 때문입니다.

하나는 gpt-oss 모델이 Blackwell GPU에서 여러 장으로 분할될 때 깨지는 문제였고, 다른 하나는 DeepSeek V4의 처리량이 GB200에서 급락하는 문제였습니다. 당시 vLLM에는 벤치마킹 파이프라인이 없었습니다. 두 문제 모두 기능 테스트는 멀쩡히 통과했지만, 실제 하드웨어에서의 성능과 정확성은 아무도 자동으로 측정하지 않았습니다.

이 사건이 연속 벤치마킹 층을 만든 직접적 계기입니다. 여기서 얻을 수 있는 교훈은 명확합니다. “테스트 통과 = 안전”이라는 등식은 추론 엔진에서 성립하지 않습니다. 기능적 정확성과 성능은 별개의 축이며, 각각을 독립적으로 게이트해야 합니다.

유지관리팀이 실제로 쓰는 명령

이 체계는 개념만이 아니라 사용자가 직접 쓸 수 있는 도구로 노출돼 있습니다. 특히 성능 회귀를 추적하는 두 가지 실무 도구가 유용합니다.

성능 대시보드는 특정 라벨이 붙은 PR에서 자동으로 갱신됩니다. perf-benchmarks와 ready 라벨이 함께 붙은 커밋마다, 그리고 PR이 main에 병합될 때마다 벤치마크가 실행되어 공개 대시보드에 게시됩니다.

# 성능 벤치마크를 트리거하는 라벨 (vLLM PR 워크플로)
perf-benchmarks + ready
# → 커밋마다 여러 모델·GPU에서 벤치마크 실행 → 공개 퍼포먼스 대시보드에 게시

더 흥미로운 것은 커밋 단위 이등분(bisect)입니다. vLLM은 이전 커밋들에 대한 wheel을 발행하기 때문에, 설치 URL에 커밋 해시를 지정하면 특정 커밋 시점의 vLLM을 그대로 설치할 수 있습니다.

# 특정 커밋 해시의 vLLM wheel 설치 (동작·성능 회귀 이등분용)
pip install https://wheels.vllm.ai/<commit-hash>/vllm-<version>-cp38-abi3-manylinux1_x86_64.whl

# "언제부터 느려졌나"를 이등분으로 좁힌다:
#   좋은 커밋 A ── ? ── 나쁜 커밋 B
#   → 중간 커밋을 설치해 재현 → 범위를 절반으로

여기서 릴리스 엔지니어링의 진짜 가치가 드러납니다. vLLM은 격주 월요일에 릴리스 주간을 시작합니다. 릴리스 매니저는 그날 main 브랜치의 최근 full-CI 실행들을 검토해 가장 초록빛(greenest) 커밋을 고릅니다. 이렇게 하면 릴리스 특화 변경을 더하기 전에 가장 건강한 출발점을 확보하게 됩니다. 그리고 릴리스 브랜치를 자주 자르는 데에는 숨은 이득이 있습니다. 이등분할 커밋이 수천 개가 아니라 500개 정도일 때 회귀 추적이 훨씬 쉬워진다는 점입니다. 릴리스 케이던스 자체가 디버깅 비용을 낮추는 장치인 셈입니다.

vLLM이 공개한 규모 지표

아래는 vLLM 운영기가 공개한 2026년 6월 기준 실측 수치입니다. 재현 실험이 아니라 유지관리팀이 발표한 값을 그대로 인용합니다.

이 수치가 말하는 바는 단순합니다. 이 정도 속도에서 품질을 지키려면 검증을 사람의 리뷰에 의존해서는 안 되며, 결정론적 게이트와 자동 측정으로 대체해야 한다는 것입니다.

타키클라우드 제품 적용 시사점

타키클라우드의 ai-platform은 K8s와 Kueue GPU 스케줄링 위에서 다양한 고객 환경에 모델을 서빙합니다. vLLM은 그 서빙 경로의 핵심 엔진이며, 따라서 vLLM의 품질 유지 방식은 곧 우리의 릴리스 정책 설계에 직접 반영됩니다.

첫째, 버전 고정과 벤치마크 게이트를 분리합니다. vLLM의 교훈대로 기능 테스트 통과만으로 새 버전을 프로덕션에 올리지 않습니다. 대표 고객 워크로드(모델·GPU 조합)에 대한 처리량·지연 시간 벤치마크를 롤아웃 전에 자동으로 돌리고, 회귀가 감지되면 승격을 차단하는 게이트를 둡니다. 이것은 vLLM의 연속 벤치마킹 층을 우리 배포 파이프라인의 게이트로 옮겨 오는 것입니다.

둘째, ArgoCD 기반 GitOps 롤아웃에 vLLM 릴리스 핀을 명시합니다. main의 최신 커밋을 따라가는 대신, vLLM이 스스로 검증해 잘라낸 릴리스 태그를 정본으로 삼고, 그 태그를 클러스터별 values에 고정합니다. 카나리(canary)로 소수 테넌트에 먼저 올린 뒤 벤치마크 대시보드가 초록빛일 때만 전체로 확장하는 흐름은 vLLM의 “가장 건강한 커밋 선택” 원칙을 배포 층에서 재현하는 것입니다.

셋째, 커밋 단위 wheel을 사내 회귀 추적에 활용합니다. 특정 고객에게서 “지난주보다 느려졌다”는 신호가 오면, vLLM의 커밋별 wheel로 이등분해 원인 커밋을 특정할 수 있습니다. 멀티테넌트 환경에서 회귀의 책임 소재를 빠르게 좁히는 것은 운영 신뢰도의 핵심입니다.

이 세 가지는 결국 하나의 원칙으로 수렴합니다. 빠르게 움직이는 상류(upstream) 의존성 위에서 프로덕션을 운영하려면, 품질 판단을 사람의 감이 아니라 자동 게이트에 위임해야 한다는 것입니다.

한계 및 반론

vLLM의 접근이 모든 조직에 그대로 이식되지는 않습니다. 몇 가지 현실적 제약이 있습니다.

가장 큰 것은 비용입니다. 월 1,300만 CI 분과 1,400개 동시 러너는 상당한 인프라 예산을 전제합니다. 소규모 팀이 이 규모의 벤치마크 팜을 그대로 복제하는 것은 비현실적입니다. 따라서 우리에게 필요한 것은 규모의 복제가 아니라 핵심 워크로드로 좁힌 대표 벤치마크입니다. 전체 모델·GPU 매트릭스가 아니라, 실제 고객 트래픽의 상위 몇 개 조합만 게이트하는 편이 비용 대비 효과가 큽니다.

둘째, 벤치마크는 커버리지가 곧 한계입니다. 벤치마크에 없는 모델·시퀀스 길이·배치 조합에서의 회귀는 여전히 새어 나갑니다. vLLM의 5월 사건도 벤치마크가 없어서 놓친 것이며, 벤치마크를 추가한 뒤에도 대시보드에 없는 조합은 사각지대로 남습니다. 게이트는 “측정한 것”만 지켜 준다는 점을 잊으면 안 됩니다.

셋째, 격주 릴리스 케이던스는 안정성과 최신성의 트레이드오프입니다. 릴리스를 자주 자르면 이등분은 쉬워지지만, 최신 기능을 프로덕션에 반영하는 속도는 느려집니다. 최신 커널 최적화가 급히 필요한 고객이 있다면, 안정 릴리스만 고집하는 정책이 오히려 병목이 될 수 있습니다. 이 균형점은 조직마다 다릅니다.

정리

빠르게 움직이는 오픈소스 위에서 프로덕션을 지키는 문제로 돌아오겠습니다. vLLM이 월 2,000 커밋 속도에서도 무너지지 않는 이유는 테스트를 무한정 늘려서가 아니라, 성능 회귀를 막는 벤치마크 게이트, 가장 건강한 커밋을 고르는 릴리스 브랜치 고정, 원인을 좁히는 커밋 단위 이등분이라는 세 가지 결정론적 장치를 갖췄기 때문입니다.

타키클라우드처럼 vLLM을 서빙 핵심으로 쓰는 조직이 오늘 당장 할 수 있는 행동은 분명합니다. 새 vLLM 버전을 올릴 때 기능 테스트 통과에만 의존하지 말고, 대표 고객 워크로드에 대한 벤치마크를 롤아웃 게이트로 세우십시오. 그리고 main을 따라가는 대신 vLLM이 검증한 릴리스 태그를 GitOps values에 고정하십시오. 이 두 가지만 배포 파이프라인에 넣어도, 상류의 속도를 그대로 흡수하면서 하류의 안정성을 지킬 수 있습니다. 품질은 더 많은 테스트가 아니라, 옳은 곳에 놓인 게이트에서 나옵니다.

관련 슬라이드

본문 내용을 NotebookLM(architectural_mono 스타일)으로 요약한 슬라이드입니다.

출처

• vLLM Blog, “Keeping vLLM Production Quality: A Look Inside CI, Benchmarking, and the Release Process” (2026-07-16): https://vllm.ai/blog/2026-07-16-keeping-vllm-production-quality
• vLLM Performance Dashboard (docs): https://docs.vllm.ai/en/latest/benchmarking/dashboard/

왜 읽어야 하나

이 글은 LLM에 법률·규정 질문을 붙이려는 개발자, 그리고 고위험 도메인의 답변 품질을 책임져야 하는 인프라 담당자를 위해 썼습니다. 결론부터 말씀드리면, 법률 질의에서 LLM이 가짜 조문을 만들어 내는 문제는 모델을 더 큰 것으로 바꿔서 풀리지 않습니다. 답을 검증된 법령 원문에 묶는 근거 기반(RAG) 설계로만 풀립니다. 법제처가 공개한 국가법령정보 Open API를 근거원으로 붙이면, 모델이 조문을 지어내는 대신 실제 조항 번호와 시행일을 인용하게 만들 수 있습니다.

개요

한 소셜 타임라인에서 “ChatGPT나 Claude로 법률 자문을 받고 싶은데 가짜 조문을 만들어낼까 걱정된다면 국내 법령 데이터를 쓰라”는 팁이 돌았습니다. 걱정은 근거가 있습니다. 미국에서는 ChatGPT가 자격 없이 법률 자문을 제공하도록 방치했다는 이유로 OpenAI를 상대로 한 소송이 제기됐고, 전문가들은 법적 문제를 챗봇과 그냥 상의하는 것 자체가 위험할 수 있다고 경고합니다. 모델은 문장을 그럴듯하게 완성하는 데 최적화돼 있을 뿐, 존재하지 않는 조문을 실제 조문처럼 써 내려가는 것을 스스로 막지 못하기 때문입니다.

그런데 같은 시장에서 정반대의 신호도 나옵니다. 한국에서는 Claude가 유료 생성형 AI 시장에서 ChatGPT를 처음으로 앞질렀고, 법률 스타트업 로앤컴퍼니는 Claude를 얹은 AI 법률 비서 SuperLawyer로 출시 180일 만에 국내 변호사의 약 20%에 해당하는 6,000명을 확보했다고 밝혔습니다. 같은 기술을 두고 한쪽은 위험하다 하고 다른 쪽은 실무에 안착시켰다면, 차이는 모델이 아니라 답을 다루는 설계에 있습니다. 이 글은 그 설계, 즉 LLM의 법률 답변을 검증된 원문에 묶는 근거 기반 파이프라인을 국가법령정보 Open API를 예로 들어 뜯어봅니다.

이 기술은 무엇인가

핵심 개념은 단순합니다. 모델에게 “법이 뭐라고 하는지 아느냐”고 묻는 대신, “이 질문에 관련된 조문을 먼저 찾아 온 뒤 그 원문만 근거로 답하라”고 시키는 것입니다. 검색이 답의 재료를 공급하고, 생성은 그 재료 안에서만 이뤄지며, 모든 주장에는 조항 번호와 시행일이라는 인용이 붙습니다. 이렇게 하면 모델이 상상으로 채우던 빈칸이 검증된 텍스트로 대체됩니다.

이때 재료의 신뢰도가 전부를 결정합니다. 아무 웹 문서나 긁어 온 법령 요약본은 개정 전 조문이거나 출처 불명일 수 있습니다. 그래서 근거원은 권위 있는 원본이어야 합니다. 법제처의 국가법령정보 공동활용 Open API는 현행 법령 본문, 조항 번호, 시행일, 개정 이력, 소관 부처를 구조화된 형태로 제공합니다. 특정 날짜 기준으로 그날 효력이 있던 법령을 조회하는 기능까지 있어서, “지금 유효한 조문”과 “당시 유효했던 조문”을 구분해 인용할 수 있습니다. 법률 질의에서 시행일 구분은 사소한 디테일이 아니라 답의 정오를 가르는 축입니다.

전체 흐름을 세로로 정리하면 다음과 같습니다.

flowchart TB
    Q[사용자 질문<br/>예: 계약 해지 위약금 상한] --> R[질의 정규화<br/>쟁점·키워드 추출]
    R --> S[국가법령정보 Open API<br/>관련 조문 검색]
    S --> F[필터<br/>시행일·현행 여부 확인]
    F --> C[컨텍스트 조립<br/>조문 원문 + 조항번호 + 시행일]
    C --> G[LLM 생성<br/>제공된 조문만 근거로 답]
    G --> V[인용 검증 게이트<br/>모든 주장에 조항 매핑 확인]
    V -->|매핑 실패| S
    V -->|매핑 성공| A[답변 + 조항 인용]

기존 접근과의 차이는 검증 게이트에 있습니다. 단순 RAG는 검색한 문서를 프롬프트에 붙이고 답을 받는 데서 멈춥니다. 고위험 도메인에서는 여기에 한 단계를 더 얹습니다. 생성된 답의 모든 법적 주장이 실제로 검색해 온 조문에 매핑되는지 코드로 검사하고, 매핑되지 않는 주장이 하나라도 있으면 그 답을 사용자에게 내보내지 않습니다. 이 게이트가 “모델이 근거 밖에서 지어낸 문장”을 걸러 내는 마지막 방벽입니다.

설치 및 통합

근거원을 붙이는 첫 단계는 API 키 발급입니다. 국가법령정보 공동활용 포털(open.law.go.kr)에서 사용자 등록 후 인증키를 받습니다. 이후 조문 검색과 본문 조회는 URL 기반 호출로 이뤄지며, 공식 가이드는 Python과 Node.js를 포함한 여러 언어의 예시를 제공합니다.

아래는 특정 쟁점 키워드로 현행 법령을 조회한 뒤, 그 원문만 컨텍스트로 조립하는 최소 패턴입니다. 실제 응답 스키마와 파라미터는 포털의 활용가이드를 기준으로 삼습니다.

import requests

LAW_API = "https://www.law.go.kr/DRF/lawSearch.do"

def search_statutes(keyword: str, oc_key: str) -> list[dict]:
    """국가법령정보 Open API로 현행 법령 검색. 조항 원문을 근거원으로 반환."""
    params = {
        "OC": oc_key,          # 발급받은 인증키
        "target": "law",       # 법령 검색
        "type": "JSON",
        "query": keyword,
        "display": 5,
    }
    resp = requests.get(LAW_API, params=params, timeout=10)
    resp.raise_for_status()
    return resp.json().get("LawSearch", {}).get("law", [])

def build_context(hits: list[dict]) -> str:
    """검색된 조문을 인용 가능한 컨텍스트로 조립. 시행일·소관부처를 함께 실어 근거를 명시."""
    lines = []
    for h in hits:
        lines.append(
            f"[{h.get('법령명한글')}] "
            f"시행일 {h.get('시행일자')}, 소관 {h.get('소관부처명')}\n"
            f"{h.get('법령상세링크')}"
        )
    return "\n\n".join(lines)

이 컨텍스트를 프롬프트에 실을 때는 지시를 분명히 못 박습니다. “아래 제공된 조문만 근거로 답하고, 제공되지 않은 조문은 인용하지 말라. 관련 조문이 없으면 없다고 답하라.” 근거가 없을 때 “없다”고 말하게 만드는 지시가 환각을 막는 핵심입니다. 모델이 빈칸을 지어내는 대신 정직하게 비워 두게 하는 것입니다.

마지막으로 검증 게이트를 코드로 소유합니다. 생성된 답에서 인용된 조항 번호를 추출해, 실제로 컨텍스트에 실린 조문 목록과 대조합니다. 목록에 없는 조항을 인용했다면 그 답은 재검색 루프로 되돌립니다. 이 판정은 모델의 자기 보고가 아니라 결정론적 코드가 내려야 신뢰할 수 있습니다.

근거 기반 설계가 만드는 차이

직접 벤치마크를 돌려 새 수치를 만들지는 않았습니다. 대신 이미 공개된 실무 지표가 근거 기반 설계의 효과를 보여 줍니다. 로앤컴퍼니의 SuperLawyer는 Claude를 얹되 답을 판례와 법령에 묶는 방식으로 설계됐고, Anthropic이 공개한 고객 사례에 따르면 출시 180일 만에 6,000명의 변호사(국내 변호사의 약 20%)를 확보했으며, 무료에서 유료로의 전환율 60.2%, 2개월 차 재사용률 79.1%, 첫 180일 동안 누적 230만 시간 절감을 기록했습니다. 전문가가 매일 검증하는 도구에서 이 정도의 유지율이 나온다는 것은, 답이 그냥 그럴듯한 수준을 넘어 실제로 신뢰할 만했다는 신호로 읽힙니다.

반대편에는 근거 없이 법을 답하게 뒀을 때의 비용이 있습니다. 미국의 OpenAI 소송과 “법적 문제를 챗봇과 상의하지 말라”는 경고는, 근거 게이트 없는 법률 답변이 법적 책임 문제로까지 번질 수 있음을 보여 줍니다. 같은 모델이라도 원문에 묶었는가 아닌가에 따라 결과가 이렇게 갈립니다. 지표가 말하는 교훈은 명확합니다. 고위험 도메인에서 품질을 끌어올리는 지렛대는 모델 등급이 아니라 근거 설계입니다.

ThakiCloud 제품 적용 시사점

이 패턴은 ThakiCloud의 두 제품에 자연스럽게 맞물립니다.

Paxis 관점에서 보면, 근거 기반 법률 답변은 Agent-Native Cloud가 다루는 전형적인 워크로드입니다. Paxis는 Skills, Tools, Policies, Audit Logs를 일급 리소스로 취급합니다. 법령 검색은 격리 샌드박스에서 실행되는 Tool로, 인용 검증 게이트는 답을 내보내기 전에 통과해야 하는 Policy로, 그리고 어떤 조문을 근거로 어떤 답을 냈는지는 Audit Log로 남습니다. 법률처럼 책임 소재가 중요한 도메인에서는 “왜 이렇게 답했는가”를 사후에 추적할 수 있어야 하는데, 정책 게이트와 감사 로그가 그 추적성을 기본으로 제공합니다. 모든 주장에 조항 인용을 강제하는 근거 게이트 자체를 재사용 가능한 스킬로 묶어 두면, 법률뿐 아니라 의료·금융·규정 준수처럼 원문 인용이 필요한 다른 고위험 도메인에도 그대로 옮겨 쓸 수 있습니다.

ai-platform 관점도 있습니다. 법령이나 판례 같은 데이터는 외부 API로 나가는 것 자체가 민감할 수 있고, 공공·규제 기관은 데이터 주권과 온프렘 서빙을 요구하는 경우가 많습니다. ThakiCloud의 ai-platform은 K8s와 Kueue 기반 GPU 스케줄링 위에서 모델을 멀티테넌트로 서빙하며, 자체 인프라에서 근거원과 모델을 함께 운용하도록 설계돼 있습니다. 법령 데이터를 내부에 두고 그 위에서 검색과 생성을 모두 돌리면, 근거 기반의 정확성과 데이터 주권을 동시에 지킬 수 있습니다. 낮은 서빙 비용은 이런 도메인 특화 파이프라인을 상시 운용할 수 있게 하는 전제 조건입니다.

한계 및 반론

근거 기반 설계가 만능은 아닙니다. 첫째, 근거원이 최신이 아니면 답도 틀립니다. 국가법령정보 데이터가 개정을 즉시 반영하더라도, 파이프라인이 캐시한 스냅샷이 오래됐다면 폐지된 조문을 인용할 수 있습니다. 시행일 필터와 정기 동기화가 뒷받침돼야 합니다. 둘째, 조문을 정확히 인용한다고 해서 그 해석이 옳다는 보장은 없습니다. 법률 자문의 본질은 조문 검색이 아니라 사안에 대한 적용이며, 그 판단은 여전히 자격 있는 전문가의 몫입니다. 이 파이프라인은 전문가를 대체하는 도구가 아니라 초안을 근거 위에 세우는 보조 도구로 봐야 합니다. 셋째, 검증 게이트가 인용 매핑만 검사한다면, 조문은 맞게 인용하되 논리를 잘못 편 답은 통과시킬 수 있습니다. 게이트는 환각의 하한선을 지킬 뿐 논증의 품질까지 보증하지는 못합니다.

정리

LLM에 법을 물을 때 가짜 조문이 나오는 문제는 모델의 한계가 아니라 설계의 공백입니다. 답을 검증된 원문에 묶고, 근거가 없으면 없다고 말하게 하고, 모든 주장에 인용을 강제하는 게이트를 코드로 소유하면, 같은 모델이 전혀 다른 신뢰도를 냅니다. 한국에서 Claude를 얹은 법률 도구가 실무에 안착한 것과 근거 없는 챗봇 자문이 소송으로 번진 것의 차이가 바로 여기서 갈립니다. 다음 행동은 분명합니다. 고위험 도메인에 LLM을 붙이려 한다면, 더 큰 모델을 찾기 전에 국가법령정보 Open API 같은 권위 있는 근거원을 먼저 연결하고, 인용 검증 게이트부터 세우시기 바랍니다. 지렛대는 언제나 근거 쪽에 있습니다.

출처

• 법제처 국가법령정보 공동활용 Open API
• 법제처 국가법령정보 공유서비스 (공공데이터포털)
• Anthropic 고객 사례: Law&Company
• KED Global: Claude, 한국 유료 생성형 AI 시장에서 ChatGPT 추월
• Forbes: OpenAI 법률 자문 관련 소송

원 뉴스: RT @Lentils80: 🚨 Alibaba released Qwen-Image-3.0 today · twitter

ThakiCloud 제품 적용 시사점

ThakiCloud 제품 적용 시사점

글자까지 또렷한 이미지 생성은 반가운 도구입니다. 파시스의 에이전트에게 포스터나 배너 제작을 맡기면, 사람이 오타를 잡던 수고가 통째로 사라지죠. 문제는 붓이 아니라 붓을 어디에 두느냐입니다. 장당 과금과 데이터 반출이 걸린 호스티드 API에 기대면, 뽑아내는 그림마다 남의 장부에 흔적이 남습니다. 메티스는 같은 급의 오픈 모델을 회사 랙 안에서 서빙하도록 설계돼 있습니다. 그림은 마음껏 뽑되 모델 가중치와 GPU는 내 시설 안에 두는 것, 그게 주권형 온프렘이 주는 여유입니다.

이 만화는 업계 뉴스를 바탕으로 자동 생성된 초안입니다.