VeriInteresting: An Empirical Study of Model Prompt Interactions in Verilog Code Generation

이 논문은 다양한 언어 모델과 프롬프트 전략 간의 상호작용을 체계적으로 분석하여 Verilog 코드 생성 성능에 영향을 미치는 일반적 경향과 모델별 고유한 특성을 실증적으로 규명했습니다.

핵심

🧱 "VeriInteresting": AI 가 베릴로그 (Verilog) 코드를 잘 쓸까?

이 논문은 **"인공지능 (AI) 이 하드웨어 설계 언어인 베릴로그 (Verilog) 코드를 얼마나 잘 만들어낼 수 있을까?"**를 실험적으로 분석한 연구입니다.

소프트웨어 (파이썬 등) 코드는 AI 가 꽤 잘 작성하지만, 하드웨어 코드는 사정이 다릅니다. 소프트웨어는 버그가 있어도 수정하면 되지만, 하드웨어 칩은 한 번 만들어지면 고치기 어렵고, 작은 실수 하나가 칩 전체를 폐기하게 만들 수 있기 때문입니다.

이 연구는 다양한 AI 모델과 "명령어 (프롬프트)" 조합을 실험하여, 어떤 방법이 가장 효과적인지 지도를 그려냈습니다.

---

🏗️ 핵심 비유: "건축가"와 "명세서"

이 논문의 내용을 이해하기 위해 **건축가 (AI 모델)**와 **건축 도면 (명세서/프롬프트)**의 관계를 상상해 보세요.

1. 연구의 목적: "명령을 어떻게 내리느냐가 중요하다"

AI 는 똑똑하지만, 어떻게 지시하느냐에 따라 결과가 천차만별입니다.

• 일반적인 명령: "이거 만들어줘." (기본 프롬프트)
• 구조화된 명령: "이건 3 층짜리 아파트야. 1 층은 주차장, 2 층은 상가, 3 층은 주거지야. 그리고 엘리베이터는 반드시 필요해." (구조화된 프롬프트)
• 생각하는 시간을 주는 명령: "먼저 구조를 설계하고, 자재는 뭐가 필요한지 생각한 뒤, 도면을 그려줘." (Chain-of-Thought, CoT)

연구진은 이 다양한 명령 방식이 AI 건축가들에게 어떤 영향을 미치는지 확인했습니다.

2. 실험 대상: "초고층 빌딩" vs "전문 공구"

연구진은 18 가지 AI 모델을 테스트했습니다.

• 대형 모델 (LLM): 지식이 방대한 '초고층 빌딩' 같은 AI (예: GPT-4, Claude 등).
• 소형 모델 (SLM): 가볍지만 빠른 '전문 공구' 같은 AI.
• 전문가 모델: 하드웨어 설계만 위해 특별히 훈련된 '전문 공구' (예: VeriReason, VeriThoughts).

3. 주요 발견 (결과 요약)

🔍 발견 1: "크기가 크다고 무조건 좋은 건 아님"

• 비유: 거대한 건축가 (대형 모델) 가 항상 작은 공구 (소형 모델) 보다 낫지는 않습니다.
• 결과: 하드웨어 설계라는 특수한 분야에서는, 전문적으로 훈련된 소형 모델이 거대한 일반 모델보다 더 잘할 때도 있었습니다. 하지만 훈련된 데이터가 부족하면, 오히려 큰 모델이 더 안정적일 수도 있습니다.

🔍 발견 2: "명령을 구체적으로 내리면 성능이 달라진다"

• 구조화된 프롬프트: AI 에게 "이런 형식으로만 써줘"라고 정해두면, 특히 소형 모델들이 훨씬 잘합니다. (건축가에게 "블록 모양만 맞춰서 쌓아"라고 하는 것과 같습니다.)
• 생각하기 (CoT): "생각한 뒤 써줘"라고 하면, 복잡한 논리를 필요로 하는 경우엔 도움이 되지만, 간단한 작업에서는 오히려 헷갈려서 실수를 하기도 합니다.
• 수정 (Refinement): "명령을 먼저 다시 써주고, 그걸로 코드를 만들어줘"라는 방식은 가장 위험했습니다. AI 가 명령을 다시 쓰다가 원래 의도를 잃어버려 (의미가 변질되어) 실패하는 경우가 많았습니다.

🔍 발견 3: "전문가는 훈련이 필요하고, 일반인은 명령이 중요"

• 전문가 모델: 하드웨어 전용으로 훈련된 모델은 기본 명령만으로도 잘하지만, 명령을 너무 복잡하게 바꾸면 (구조를 바꾸거나 생각하게 하면) 오히려 망가집니다. 마치 숙련된 요리사에게 "일단 레시피를 다시 써봐"라고 하면 혼란을 겪는 것과 같습니다.
• 일반 모델: 훈련되지 않은 일반 모델은 명령을 잘 정리해주면 전문가 모델과 비슷한 성능을 낼 수 있습니다.

🔍 발견 4: "시험지 한 장만 믿으면 안 된다"

• 연구진은 두 가지 다른 시험지 (벤치마크) 를 사용했습니다. 하나는 "실제 작동 여부"를 보는 것이고, 다른 하나는 "이론적으로 맞는지"를 보는 것입니다.
• 결과: 어떤 모델은 A 시험지에서는 1 등인데, B 시험지에서는 꼴찌였습니다. 즉, 하나의 테스트 결과만으로 AI 의 능력을 판단하면 안 됩니다.

---

💡 이 연구가 우리에게 주는 교훈

1. 하드웨어 코드는 소프트웨어와 다릅니다: 소프트웨어는 "대충 맞으면 고치면 되지만", 하드웨어는 "한 번 실수하면 칩이 망가집니다." 그래서 AI 를 쓸 때 더 신중해야 합니다.
2. 명령 (프롬프트) 은 마법 지팡이가 아닙니다: AI 에게 "생각해 봐"라고 하면 무조건 좋아지는 게 아닙니다. 모델의 종류와 작업의 난이도에 따라 명령 방식을 바꿔줘야 합니다.
3. 전문가 vs 일반인: 하드웨어 설계처럼 특수한 분야에서는, 거대한 AI 를 무작정 쓰는 것보다 작지만 전문적으로 훈련된 AI를 쓰거나, 일반 AI 에게 아주 구체적인 지시를 내리는 것이 더 나을 수 있습니다.

🚀 결론

이 논문은 "AI 가 하드웨어를 다 만들어줄까?"라는 질문에 대해 **"아직은 아니지만, 올바르게 지시하면 충분히 도움을 줄 수 있다"**고 말합니다. 다만, AI 를 믿기 전에 어떤 모델인지, 어떤 명령을 내렸는지, 그리고 어떤 시험을 치렀는지를 꼼꼼히 확인해야 한다는 것을 강조합니다.

마치 건축 현장에서, 거대한 크레인 (대형 모델) 이나 정밀한 드릴 (전문 모델) 을 쓸 때, 시공자 (명령자) 가 정확한 도면과 지시를 내리지 않으면 건물이 무너질 수 있다는 것과 같은 이치입니다.

기술 요약

VeriInteresting: Verilog 코드 생성을 위한 모델-프롬프트 상호작용에 대한 실증 연구

이 논문은 대규모 언어 모델 (LLM) 을 활용한 Verilog 코드 생성의 성능을 평가하고, 모델의 특성 (규모, 전문화) 과 프롬프트 엔지니어링 전략 간의 복잡한 상호작용을 실증적으로 분석한 연구입니다. 하드웨어 설계의 엄격한 정확성 요구사항과 소프트웨어 코드 생성 간의 차이점을 강조하며, 다양한 모델과 프롬프트 기법이 Verilog 생성에 미치는 영향을 체계적으로 규명합니다.

1. 연구 배경 및 문제 정의 (Problem)

• 하드웨어 설계의 고유한 어려움: Verilog 는 Python 등 소프트웨어 언어와 달리 구조적이고 장문의 문맥을 유지해야 하며, 신호 연결의 정확성이 필수적입니다. 하드웨어 설계는 타이밍 제약, 레이스 조건 (race conditions), 전력/면적/성능 (PPA) 트레이드오프 등 엄격한 제약을 가지며, 단순히 시뮬레이션이 통과하더라도 실제 칩 제작 시 치명적인 오류가 발생할 수 있습니다.
• 데이터 부족과 IP 제약: 하드웨어 설계 데이터는 대부분 폐쇄된 지적재산권 (IP) 으로 인해 공개 학습 데이터가 부족합니다. 또한, 기업들은 민감한 설계 데이터를 제 3 자 모델이나 클라우드 서비스에 제공하는 것을 꺼려, 추론 시간 (Inference-time) 에만 의존하여 성능을 극대화하는 방법이 필요합니다.
• 소프트웨어 중심 기법의 한계: 소프트웨어 코드 생성에서 유효한 프롬프트 기법 (예: 체인 오브 씽킹, 프롬프트 최적화 등) 이 하드웨어 설계 (RTL 생성) 에도 동일하게 적용될지, 혹은 어떤 상호작용이 발생하는지에 대한 체계적인 연구가 부족했습니다.

2. 연구 방법론 (Methodology)

저자들은 18 개의 다양한 언어 모델 (상용 LLM 7 개, 오픈소스 SLM 11 개 포함) 을 대상으로 두 가지 상보적인 벤치마크에서 통제된 실험을 수행했습니다.

2.1. 평가 모델 및 적응 전략

• 모델 범위: 범용 모델, 코드 특화 모델, Verilog 전문화 모델 (VeriReason, VeriThoughts 등) 을 포함하여 규모 (Scale) 와 전문화 (Specialization) 를 비교했습니다.
• 적응 방식:
  • 학습 시간 적응 (Training-time): 파인튜닝된 모델 (SFT, RLHF 등).
  • 추론 시간 적응 (Inference-time): 프롬프트 엔지니어링 및 최적화.

2.2. 프롬프트 전략 (Prompting Axes)

다음과 같은 다양한 프롬프트 구성을 실험했습니다:

1. Base: 기본 단일 패스 프롬프트.
2. Structured Prompting (Struct): DSPy 를 활용한 구조화된 출력 형식 및 모듈화된 프롬프트.
3. Prompt Refinement (Refine): 명세서를 먼저 재작성/정리하고 RTL 을 생성하는 2 단계 파이프라인.
4. Chain-of-Thought (CoT): 코드 생성 전 논리적 추론 단계 추가.
5. In-Context Learning (ICL): 예시 (Few-shot) 추가.
6. GEPA (Genetic-Pareto): 진화적 알고리즘을 통한 프롬프트 자동 최적화.

2.3. 평가 벤치마크

1. Verilog Eval v2: 시뮬레이션 기반 테스트벤치를 사용하여 기능적 정확성을 평가 (동적 검증).
2. VeriThoughts: 형식적 등가성 검증 (Formal Equivalence Checking, LEC) 을 사용하여 모든 입력 상태에 대한 기능적 동등성을 증명 (정적 검증).

3. 주요 연구 결과 (Key Results)

RQ1: 규모 (Scale) vs. 전문화 (Specialization)

• 규모의 효과: 모델 파라미터 수 증가가 일반적으로 성능 향상에 기여하지만, Verilog 전문화 모델은 특정 규모 (예: 7B) 에서 정점을 찍고 더 큰 규모로 갈수록 성능이 정체되거나 하락하는 비단조적 (Non-monotonic) 경향을 보였습니다.
• 전문화의 양면성: VeriThoughts (VT) 모델은 기본 프롬프트에서는 우수한 성능을 보였으나, 구조화된 프롬프트나 복잡한 추론이 요구될 경우 성능이 급격히 저하되었습니다. 이는 특정 벤치마크 데이터에 과도하게 적합 (Overfitting) 되어 일반화 능력이 떨어졌음을 시사합니다. 반면 VeriReason (VR) 모델은 추론 지시를 따르는 능력이 더 뛰어났습니다.

RQ2: 프롬프트 전략에 대한 민감도

• 구조화된 프롬프트 (Structured Prompting): 작은 규모의 오픈소스 모델 (특히 Qwen-Coder 계열) 에서는 성능을 크게 향상시켰으나, VeriThoughts 와 같은 전문화 모델에서는 오히려 성능을 저하시켰습니다.
• 프롬프트 정제 (Refinement): 명세서 재작성 단계는 많은 모델 (특히 GPT-5m, VT 계열) 에서 성능 저하를 초래했습니다. 이는 재작성 과정에서 명세 왜곡 (Specification Drift) 이 발생하거나, 모델이 테스트벤치 생성 등 불필요한 작업을 수행하여 실패를 유발했기 때문입니다.
• Chain-of-Thought (CoT): 구조화된 프롬프트와 결합 시 작은 모델의 성능을 안정화시키는 효과가 있었으나, 형식적 검증 (VeriThoughts) 환경에서는 불필요한 가정을 도입하여 오히려 해가 될 수 있었습니다.
• ICL (In-Context Learning): 안정된 프롬프트 템플릿과 결합 시 소규모 모델의 성능을 향상시켰으나, 기본 프롬프트나 전문화 모델에서는 효과가 없거나 부정적일 수 있었습니다.

RQ3: 파인튜닝 vs. 강력한 프롬프트

• 상호 보완적 관계: 강력한 프롬프트 전략 (Struct + CoT) 은 파인튜닝되지 않은 범용 모델의 성능을 크게 끌어올려 파인튜닝 모델과의 격차를 줄일 수 있었습니다.
• 한계: 그러나 특정 벤치마크 (Verilog Eval v2) 에 최적화된 파인튜닝 모델 (VR, VT) 은 프롬프트만으로는 달성하기 어려운 추가적인 성능 향상을 보였습니다. 이는 추론 시간 최적화가 파인튜닝을 완전히 대체할 수는 없음을 의미합니다.

RQ4: 벤치마크 간 안정성

• 벤치마크 간 차이: 두 벤치마크 (시뮬레이션 vs 형식 검증) 간의 모델 순위는 높은 상관관계 (r=0.868) 를 보였으나, 절대적인 성능 차이는 컸습니다. 특히 Verilog Eval v2(시뮬레이션) 가 VeriThoughts(형식 검증) 보다 더 어려운 것으로 나타났습니다.
• 단일 벤치마크의 위험: 특정 벤치마크에 최적화된 모델은 다른 벤치마크에서는 성능이 크게 떨어질 수 있으므로, 단일 벤치마크에 의존한 평가는 신뢰할 수 없습니다.

4. 주요 기여 및 의의 (Contributions & Significance)

1. 하드웨어 생성의 고유성 규명: Verilog 생성은 소프트웨어 코드 생성과 질적으로 다른 작업 regime 임을 증명했습니다. 소프트웨어에서 유효한 프롬프트 기법 (예: 명세서 재작성) 이 하드웨어에서는 오히려 해가 될 수 있음을 보여주었습니다.
2. 모델-프롬프트 상호작용 지도 (Empirical Map): 모델의 규모, 전문화 정도, 프롬프트 전략 간의 복잡한 상호작용을 실증적으로 매핑했습니다. 특히 "전문화 모델은 특정 프롬프트 변화에 취약하다"는 중요한 통찰을 제공했습니다.
3. 실무적 가이드라인 제공:
   • 하드웨어 설계에 LLM 을 도입할 때는 단일 벤치마크가 아닌 다중 벤치마크 평가가 필수적입니다.
   • 프롬프트 전략은 모델에 따라 다르게 적용해야 합니다 (예: 작은 모델은 구조화/CoT 활용, 전문화 모델은 간결한 프롬프트 유지).
   • 추론 시간 최적화는 비용 효율적인 첫 단계이지만, 특정 도메인 (하드웨어) 에 최적화된 성능을 얻기 위해서는 파인튜닝이 여전히 필요합니다.
4. IP 보호 및 비용 효율성: 학습 데이터가 부족한 하드웨어 분야에서, 파인튜닝 없이 추론 시간 전략만으로 얼마나 성능을 끌어올릴 수 있는지에 대한 구체적인 데이터를 제공했습니다.

5. 결론

이 연구는 Verilog 코드 생성을 위한 LLM 활용이 단순한 프롬프트 엔지니어링의 문제가 아니라, 모델의 아키텍처, 학습 데이터, 그리고 하드웨어 설계의 엄격한 제약 조건이 교차하는 복잡한 영역임을 강조합니다. 하드웨어 설계 자동화를 위한 LLM 배포 시에는 모델 선택, 프롬프트 전략, 그리고 평가 방법론을 신중하게 조합하고, 특정 벤치마크에 대한 과적합을 경계해야 함을 시사합니다.