솔직히 고백하자면, VHDL이나 Verilog로 복잡한 로직을 짜다가 Clock Domain Crossing(CDC) 버그 때문에 며칠 밤을 새워본 엔지니어라면 누구나 한 번쯤 이런 상상을 해봤을 겁니다. “아니, 이걸 왜 시뮬레이션 돌려봐야 아는 거야? 컴파일러가 미리 알려줄 순 없나?”

소프트웨어 엔지니어링에서는 Rust 같은 언어가 등장하면서 Memory Safety를 컴파일 타임에 보장하는 것이 상식이 되었습니다. 하지만 하드웨어 설계, 즉 HDL(Hardware Description Language)의 세계는 여전히 ‘디지털 야생의 서부’와 같습니다. 와이어를 연결하면 전기는 흐르지만, 그게 타이밍에 맞는지, 프로토콜이 호환되는지는 전적으로 설계자의 ‘감’과 지루한 검증 과정에 달려 있죠.

최근 MIT CSAIL에서 나온 Defining Safe Hardware Design 이라는 논문과 이에 대한 Hacker News의 논쟁이 꽤 흥미로워서 가져와 봤습니다. 시니어 엔지니어 관점에서 이 기술이 단순한 학계의 장난감인지, 아니면 차세대 칩 설계의 구세주가 될지 뜯어보겠습니다.

타입 시스템에 ‘시간(Time)‘을 구겨 넣다

이 논문의 핵심 아이디어는 간단하면서도 강력합니다. Temporal Constraints(시간적 제약 사항) 를 타입 시스템의 일부로 편입시키자는 겁니다.

기존의 Verilog에서 reg [7:0]은 그저 8비트 저장공간일 뿐입니다. 하지만 Safe HDL의 세계에서는 이 타입이 훨씬 구체화됩니다. 예를 들어, 어떤 신호가 “3 사이클의 Latency를 가진다”거나 “특정 클럭 도메인에 속한다”는 정보가 타입 시그니처에 포함되는 식이죠.

이게 왜 중요할까요? 파이프라인 설계를 할 때, 실수로 Latency가 다른 신호끼리 AND 연산을 하려고 하면 컴파일러가 Type Error 를 뱉어낼 수 있기 때문입니다. “야, 너 지금 사이클 3짜리 데이터랑 사이클 4짜리 데이터를 섞으려고 해. 이거 레이스 컨디션이야!”라고 말이죠.

이상과 현실의 괴리: Type Theory vs 74LS TTL

하지만 HN(Hacker News)의 댓글들을 보면서 무릎을 탁 쳤던 부분이 있습니다. 한 유저가 지적한 ‘인력 풀의 미스매치’ 문제입니다.

“이 분야의 진보가 더딘 이유는 명확하다. 타입 이론(Type Theory)을 깊게 아는 사람들은 하드웨어가 어떻게 동작하는지 모르고(심지어 관심도 없고), 하드웨어를 잘 아는 사람들은 VHDL에서의 나쁜 기억 때문에 ‘타입’이라면 치를 떤다.”

정말 뼈 때리는 말입니다. 저도 현업에서 Bluespec(BSV) 같은 상위 레벨 HDL을 도입하려다 실패한 경험이 있습니다. 기존 RTL 엔지니어들에게 Haskell 스타일의 타입 시스템을 들이밀면, 그들은 당장 “그래서 이게 Gate Count가 얼마나 늘어나는데요?”부터 묻습니다. 학습 곡선(Learning Curve)이 단순히 높은 게 아니라, 사고방식 자체가 다르기 때문입니다.

Bluespec이 오픈소스로 풀렸음에도 불구하고 여전히 ‘아카데미아의 전유물’처럼 느껴지는 이유도 여기에 있습니다. TTM(Time-to-Market)이 생명인 반도체 회사에서, 엔지니어들이 새로운 추상화 계층을 배우는 데 시간을 쏟기는 쉽지 않습니다.

물리학은 ‘Zero Exception Domain’이 아니다

기술적으로 가장 공감 갔던 비판은 “물리학의 예외성” 에 대한 것입니다. 소프트웨어의 타입 시스템은 논리적인 세계 안에서 완벽할 수 있습니다. 하지만 하드웨어는 결국 물리 법칙의 지배를 받습니다.

• PCB 설계의 예: KiCad 같은 툴에서 넷 클래스(Net Class)로 전압이나 두께를 제한할 순 있습니다. 하지만 실제로는 부품 수급 문제, 조립 공차, 열 설계(Thermal), EMI 이슈 때문에 그 ‘타입’을 어겨야만 하는 상황이 반드시 옵니다.
• 커스텀 실리콘: 칩 내부에서도 마찬가지입니다. 타입 시스템이 논리적으로는 완벽하다고 보장해줘도, 실제로는 Voltage Droop이나 Crosstalk 때문에 타이밍이 틀어질 수 있습니다. 이런 ‘Oddball requirement’들을 전부 타입 시스템으로 정형화(Formalizing)하는 게 과연 가능할까요?

결국 우리는 엄격한 타입 시스템과 유연한 ‘엔지니어링 꼼수’ 사이 어딘가에서 타협해야 합니다. 모든 물리적 변수를 타입으로 정의하려다간, 코드를 짜는 시간보다 타입 정의하는 시간이 더 길어질지도 모릅니다.

나의 결론: 인간보다는 AI를 위한 도구일지도?

그럼에도 불구하고 저는 Safe HDL 의 방향성이 옳다고 봅니다. 다만, 그 사용 주체가 인간이 아닐 수도 있다는 생각이 듭니다.

최근 AI가 칩 설계를 돕는 시도들이 늘어나고 있습니다. LLM이나 AI 에이전트가 Verilog를 생성할 때, 가장 큰 문제는 생성된 코드의 신뢰성입니다. 만약 AI가 생성하는 타겟 언어가 Verilog가 아니라, 강력한 타입 시스템을 갖춘 Safe HDL이라면 어떨까요?

1. AI가 코드를 생성한다.
2. Safe HDL 컴파일러가 타이밍 위반이나 도메인 교차 오류를 잡아낸다.
3. AI가 피드백을 받아 코드를 수정한다.
4. Type-Safe 한 결과물이 나온다.

어쩌면 이 복잡하고 엄격한 타입 시스템은, 우리 같은 ‘Greybeard’ 엔지니어들이 직접 타이핑하라고 만든 게 아니라, 미래의 AI 설계 도구들이 서로 소통하기 위한 Intermediate Representation(IR) 이 될 운명일지도 모르겠습니다.

Verdict: 당장 내일의 프로젝트에 도입하기엔 시기상조입니다. 하지만 당신이 CTO라면, 혹은 툴 체인을 만드는 플랫폼 엔지니어라면 이 흐름을 주시해야 합니다. 하드웨어 설계의 추상화 레벨은 반드시 올라갈 것이고, 그 사다리의 끝에는 결국 ‘Type Safety’가 기다리고 있을 테니까요.