칩을 양산하기 전 수천 개의 설계규칙을 검증하는 일을 자동화하고 싶은 엔지니어라면 이 글을 읽을 가치가 있습니다. Rule2DRC(arXiv:2605.15669, 서울대 송현오 교수팀·삼성 AI센터, ICML 2026)는 자연어로 쓰인 설계규칙을 실행 가능한 DRC 검증 스크립트로 번역하는 LLM 에이전트를, 코드가 얼마나 정답과 비슷하게 생겼는지가 아니라 실제 검증엔진에서 돌려 통과시키는지로 채점하는 대규모 벤치마크입니다. 이 팀은 여기서 그치지 않고 삼성 사내 보안망에 배포할 수 있는 레이아웃 네이티브 에이전트 GUI 앱까지 만들었습니다. 도메인 특화 에이전트가 규제와 보안이 빡센 산업 현장에 실제로 들어가고 있다는 뜻입니다.

자연어 설계규칙이 실행 가능한 검증 코드로 번역되는 흐름을 형상화한 추상 이미지 레이아웃 격자 패턴이 구조화된 검증 로직으로 흘러 들어가는 모습을 형상화했습니다.

왜 읽어야 하나

이 절은 도메인 특화 LLM 에이전트를 규제·보안 환경에 배포하려는 엔지니어와, EDA·반도체 검증 같은 전문 작업을 에이전트로 자동화하려는 플랫폼 담당자를 대상으로 합니다. 전문가의 손을 타던 검증 작업을 에이전트에게 맡기려면, 그 에이전트가 정말 제대로 하는지부터 믿을 수 있어야 합니다. Rule2DRC는 이 질문에 실행으로 답합니다. 에이전트가 만든 스크립트를 실제 검증엔진에서 돌려 기능적 정확성으로 채점하는 것입니다. 그럴듯하게 생긴 코드와 실제로 동작하는 코드는 다르고, 산업 현장에서 필요한 것은 후자입니다.

개요

반도체 칩은 양산에 들어가기 전에 수천 개의 기하학적 설계규칙을 만족하는지 검증받아야 합니다. 이 검증을 DRC, 즉 Design Rule Check라고 부릅니다. 그런데 문제는 규칙 자체가 자연어 문서로 쓰여 있다는 점입니다. “금속 배선 사이의 최소 간격은 얼마 이상이어야 한다” 같은 문장을 KLayout이나 SVRF 같은 전용 검증 언어의 스크립트로 옮겨야 검증 엔진이 실제로 레이아웃을 검사할 수 있습니다.

이 번역 작업이 만만치 않습니다. 공정 노드가 바뀔 때마다, 파운드리가 바뀔 때마다 수천 개의 규칙을 전문가가 손으로 스크립트로 옮겨 왔습니다. 반복적이면서도 고도의 전문성이 필요한 일이라, 자연스럽게 LLM 에이전트로 자동화하려는 시도가 나왔습니다. 규칙 문서를 읽고 검증 스크립트를 생성하고, 틀리면 디버깅까지 하는 에이전트를 만들자는 것입니다.

여기서 진짜 병목은 에이전트를 만드는 것보다 그 에이전트를 제대로 평가하는 것이었습니다. 기존 벤치마크는 두 가지 한계를 안고 있었습니다. 하나는 평가셋이 작다는 것이고, 다른 하나는 생성된 스크립트를 실제로 실행하지 않고 정답 코드와의 유사도로만 채점한다는 것입니다. 게다가 실행 피드백을 쓰려던 기존 방법들은 채점을 위해 정답 테스트 레이아웃을 에이전트의 입력으로 미리 요구하는 경우가 많았습니다. 실전에서는 그런 정답 레이아웃이 주어지지 않는데도 말입니다.

이 벤치마크는 무엇인가

Rule2DRC는 이 두 한계를 정면으로 겨냥합니다. 규칙을 스크립트로 옮기는 태스크 1,000개와, 그 스크립트를 채점하기 위한 칩 레이아웃 13,921개로 구성된 대규모 벤치마크입니다. 채점 방식이 핵심입니다. AI가 생성한 스크립트를 KLayout 검증 엔진에서 실제로 실행해, 레이아웃을 얼마나 올바르게 검사하는지를 기능적 정확성으로 잽니다. 코드가 정답과 비슷하게 생겼는지는 보지 않습니다.

정답 레이아웃을 에이전트의 입력으로 주지 않는다는 점이 특히 중요합니다. 채점하는 쪽에는 방대한 평가용 레이아웃이 있지만, 에이전트는 규칙 문서만 보고 스크립트를 짜야 합니다. 실전 상황을 그대로 재현한 셈입니다. 에이전트에게 정답지를 미리 보여 주고 채점하던 이전 방식과 여기서 갈립니다.

아래 도표가 Rule2DRC의 평가 흐름을 보여 줍니다.

flowchart TB
    A["자연어 설계규칙<br/>(공정 규칙 문서)"] --> B["LLM 에이전트<br/>스크립트 생성·디버깅"]
    B --> C["DRC 스크립트 후보<br/>(여러 개)"]
    C --> D["SplitTester<br/>변별 테스트 케이스 생성"]
    D --> E["KLayout 실행<br/>기능적 정확성 채점"]
    E --> F["Best-of-N 선택<br/>최적 스크립트 확정"]
    G["평가용 레이아웃<br/>13,921개"] -.채점에만 사용.-> E
    E -.실행 피드백.-> D

여기서 두 번째 기여인 SplitTester가 등장합니다. 에이전트가 여러 후보 스크립트를 내놓았을 때, 어느 것이 가장 좋은지 고르는 일이 생각보다 어렵습니다. 후보들이 비슷하게 동작해서 겉으로는 구분이 안 되는 경우가 많기 때문입니다. SplitTester는 실행 피드백으로 변별력 있는 테스트 케이스를 스스로 생성하는 테스터 에이전트입니다. 구분되지 않던 후보들을 서로 다른 결과가 나오도록 갈라내는 테스트를 만들어, 어느 후보가 진짜 맞는지 드러나게 합니다. 이렇게 후보를 변별하면 여러 개 중 하나를 고르는 Best-of-N 선택 성능이 눈에 띄게 올라갑니다.

논문의 정량 결과에서는 프런티어 모델과 오픈소스 모델 사이의 격차가 뚜렷하게 나타났고, SplitTester를 붙였을 때 후보 선택 성능이 개선됐습니다. 다만 모델별 정확한 통과율 수치는 논문 표를 직접 확인하시길 권합니다. 이 벤치마크는 ICML 2026에 채택됐고, 삼성 AI센터 NPRC 워크숍에서 우수연구상과 최우수포스터상을 받았다고 소개됐습니다.

왜 실행 기반 채점이 중요한가

코드 유사도 채점에서 실행 기반 채점으로 넘어간 것이 이 연구의 진짜 무게중심입니다. 유사도 채점은 “정답과 얼마나 닮았나”를 재고, 실행 채점은 “실제로 통과시키나”를 잽니다. 두 질문은 전혀 다릅니다. 정답과 한 글자도 다르지 않게 생긴 코드가 실행하면 틀릴 수 있고, 완전히 다르게 생긴 코드가 완벽하게 동작할 수 있습니다. 검증이라는 작업의 본질이 “실제로 규칙을 잡아내는가”에 있는 이상, 채점도 실행으로 해야 맞습니다.

이 방향은 반도체 검증에만 국한된 이야기가 아닙니다. 코딩 에이전트 전반의 평가 패러다임이 같은 곳을 향하고 있습니다. 테스트를 통과시키는 코드, 엔드포인트가 기대한 응답을 내는 코드, 데이터베이스에 올바른 행을 남기는 코드처럼 결정론적으로 확인 가능한 결과로 채점하는 흐름입니다. 모델이 “잘 됐다고 봅니다”라고 자기 보고하는 것을 믿지 않고, 실행 결과가 판정을 내리게 하는 것입니다.

이 연구는 벤치마크에서 멈추지 않았습니다. 삼성 사내 보안 환경에서 사내 LLM과 통합해, 레이아웃과 검증 코드를 한 화면에서 다루는 GUI 앱까지 만들어 실제 현장에 배포 가능한 도구로 이어졌습니다. 도메인 특화 에이전트가 규제와 보안이 엄격한 산업에서 실제로 자리를 잡아가고 있다는 신호입니다.

ThakiCloud 제품 적용 시사점

Rule2DRC가 보여 주는 그림은 ThakiCloud가 두 제품으로 겨냥하는 지점과 정확히 겹칩니다. 주제가 도메인 특화 에이전트를 보안 격리 환경에서 운용하는 것이므로, Paxis 렌즈가 중심이고 ai-platform 렌즈가 이를 받칩니다.

에이전트 관점에서 보면 Paxis가 이 수요를 그대로 받습니다. Paxis는 ThakiCloud의 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, Skills와 Tools, Policies, Audit Logs를 일급 리소스로 다룹니다. 삼성 사례의 “레이아웃 네이티브 GUI 앱 더하기 사내 LLM 통합”은 Paxis의 Agent Builder와 온프레미스 배포 모델 그 자체입니다. Rule2DRC의 실행 기반 채점은 Paxis의 검증 설계와 같은 철학을 공유합니다. Paxis는 스킬을 평가할 때 결과물이 정답과 비슷한지가 아니라 결정론적 실행 결과, 즉 assertion과 DB 행, 엔드포인트 출력으로 채점하는 방향을 이미 취하고 있습니다. SplitTester가 실행 피드백으로 후보를 갈라내 Best-of-N을 끌어올리는 방식은, Paxis의 멀티에이전트 오케스트레이터에서 Evaluator가 후보 산출물을 실행 결과로 변별하는 로직으로 참고할 만합니다.

인프라 관점에서는 ai-platform이 이 그림을 떠받칩니다. 사내 LLM을 검증 에이전트의 백엔드로 서빙하려면 온프레미스에서 안정적으로 도는 추론 스택이 필요합니다. ai-platform은 K8s와 Kueue 기반 GPU 스케줄링 위에서 vLLM 서빙과 scale-to-zero를 제공하고, 멀티테넌트로 격리된 환경에서 모델을 운용합니다. 토큰 과금형 클라우드 API로는 삼성 사내망 같은 에어갭 요건을 맞출 수 없습니다. 낮은 서빙 비용에서 경쟁력을 갖는 온프렘 추론이 이런 도메인 에이전트의 경제성을 만듭니다. 저비용 서빙이 에이전트의 상시 운용 가능성을 열고, 그 위에서 Paxis의 정책 게이트와 감사 로그가 규제 대응을 책임지는 구조입니다.

이 사례가 보여 주는 것은 범용 챗봇이 아니라 보안 격리 환경에서 도는 도메인 특화 에이전트가 산업 현장에 필요하다는 증거입니다. Paxis의 Sandbox Runtime과 자율성 레벨, Policy Engine, 온프레미스 감사 로그가 정확히 이 수요를 향합니다.

한계 및 반론

이 연구를 과대평가하지 않으려면 반대편도 봐야 합니다. Rule2DRC의 핵심 기여는 벤치마크와 채점 방법론이지, 검증 자동화가 이제 완성됐다는 뜻은 아닙니다. 프런티어 모델조차 모든 규칙을 완벽하게 스크립트로 옮기지 못했고, 격차가 있다는 것은 아직 인간 전문가를 대체할 단계가 아니라는 뜻이기도 합니다.

실행 기반 채점에도 전제 조건이 있습니다. 검증 엔진과 평가용 레이아웃이 갖춰져 있어야만 가능하기 때문입니다. Rule2DRC는 13,921개의 레이아웃을 준비했지만, 새로운 공정이나 다른 도메인에서 같은 규모의 실행 가능한 평가셋을 구축하는 일은 그 자체로 큰 비용입니다. 실행 채점이 유사도 채점보다 옳다는 것과, 그 실행 환경을 모든 곳에서 값싸게 갖출 수 있다는 것은 별개의 문제입니다.

사내망 배포 GUI 앱이 나왔다는 것과, 그것이 실무에서 전문가의 수작업을 실제로 얼마나 줄였는지는 다른 질문입니다. 논문 단계의 실증과 현장 운영의 신뢰성 사이에는 여전히 거리가 있고, 그 거리를 메우는 것은 벤치마크가 아니라 오래 쌓은 운영 데이터입니다.

정리

Rule2DRC의 메시지를 한 문장으로 줄이면, 도메인 특화 에이전트는 그럴듯한 코드가 아니라 실제로 통과시키는 코드로 채점해야 하고, 그렇게 채점할 수 있을 때 비로소 규제·보안 현장에 배포할 수 있다는 것입니다. 자연어 규칙을 실행 스크립트로 옮기는 전문 작업을, 정답 레이아웃 없이도 실행 결과로 평가하는 벤치마크와, 그 위에서 후보를 변별하는 SplitTester, 그리고 사내망 배포 GUI 앱까지 이어진 한 줄기가 이를 보여 줍니다.

여러분이 도메인 특화 에이전트를 설계하고 있다면, 다음 행동은 분명합니다. 산출물을 유사도가 아니라 실행 결과로 채점하는 게이트를 먼저 세우고, 후보가 여럿일 때는 그것들을 갈라내는 변별 테스트를 붙이는 것입니다. ThakiCloud는 이 두 가지를 Paxis의 Evaluator와 ai-platform의 온프렘 서빙으로 이미 실무에 녹이고 있습니다. 검증을 자동화하고 싶다면, 실행이 판정하게 하십시오.

출처

태그: DRC, EDA, KLayout, LLM 에이전트, 도메인 특화 에이전트, 반도체, 벤치마크, 설계검증, 실행 기반 채점, 온프레미스

카테고리:

업데이트:

참고