Jane Street는 주기적으로 기술 퍼즐을 공개하는데, 이번에 화제가 된 것은 "ASIC을 역설계할 수 있는가"라는 도전이었다. ASIC은 특정 용도에 맞춰 설계한 맞춤형 집적회로, 흔히 말하는 반도체 칩이다. 금융 기업이 범용 장비보다 높은 성능을 얻기 위해 이런 칩을 직접 설계하는 일은 드물지 않다. 챌린지는 칩의 물리적 구조를 담은 GDS 파일을 주고, 그 칩이 무슨 동작을 하는지 거꾸로 알아내 최종적으로 숨겨진 답을 찾아내는 구조였다. 한 참가자가 약 한 달에 걸쳐 이 문제를 푼 과정을 공개했는데, 하드웨어 설계와 소프트웨어 엔지니어링이 만나는 지점을 보여주는 사례라 실무자 입장에서도 참고할 만하다.
낯선 파일 포맷에서 실마리를 찾다
출발점은 파일 안에 반복적으로 등장하는 익숙한 단어들이었다. clk(클럭), rst(리셋), VPWR·VGND 같은 전원·접지 신호, 그리고 sky130_fd_sc_hd__ 라는 접두어에 or, not 같은 논리 소자 이름이 붙은 항목들이었다. 파이썬 라이브러리 gdstk로 GDS 파일을 열자 워밍업 문제에는 27개의 요소가 들어 있었다. 별도로 제공된 VCD 파일은 시뮬레이션 입출력으로 보이는 텍스트였는데, 그 안의 ASCII로 의심되는 값을 간단한 C 프로그램으로 뽑아내자 'TRY AGAIN'이라는 메시지가 나왔다. 회로 자체가 메시지를 담고 있다는 확인이었다.
여기서 필자는 스스로 인정하듯 '어려운 길'을 택했다. sqlite3을 구동 엔진으로 삼은 회로 시뮬레이터를 직접 만들고, 회로를 기술할 자체 언어와 파서, 테스트 하네스, 심지어 raylib 기반 GDS 뷰어까지 손대다가 결국 대부분의 자작 도구를 버렸다. 파형은 surfer라는 기존 뷰어로, GDS 확인은 Jane Street 블로그가 안내한 뷰어로 돌아온 것이다. 이 대목은 역설계 작업에서 도구를 처음부터 만드는 유혹이 얼마나 큰지, 그리고 그것이 얼마나 본질에서 멀어지게 하는지를 잘 보여준다.
기하학을 회로로 되돌리는 과정
결정적 진전은 문서를 제대로 읽으면서 왔다. sky130은 칩을 만들기 위한 표준 설계 요소 모음으로, 각 소자가 무엇을 하는지 설명까지 담고 있었다. and는 짐작이 가지만 o21bai 같은 소자는 문서 없이는 알기 어렵다. 필자는 gdstk가 요소를 SVG로 내보내며 라벨 텍스트를 함께 담아준다는 점, 그리고 두 요소가 2D 공간에서 겹치는지 검사할 수 있다는 점을 활용했다. 라벨이 중심점 기준으로 배치되어 있어, 겹침 검사만으로 소자의 입출력 위치를 상당히 정확하게 매핑할 수 있었다. 눈으로는 연결이 보이지 않는 배선까지 잡아낸 것이 특히 유효했다.
실제 회로 추출은 인접한 층에서 서로 겹치는, 즉 '맞닿은' 요소를 찾아내는 문제로 귀결됐다. 맞닿은 배선 조각들을 하나의 배선으로 합치는 단순화 단계를 거쳐 연결 그래프를 구성했고, 여기서 그래프 알고리즘 경험이 실질적인 도움이 됐다. 최종적으로 회로는 하드웨어 기술 언어 Verilog로 옮겨져 '이 핀을 높이면 저 핀이 낮아진다' 같은 기본 시뮬레이션 검증이 가능해졌다. 워밍업 회로의 정체는 두 개의 시프트 레지스터, 덧셈기, 그리고 comparitor496이라는 이름에서 드러나듯 합이 496이 되어야 통과하는 비교기였다. 정답 자체는 단순한 산수였지만, 여러 부품을 하나의 시뮬레이션에서 함께 돌리는 일이 진짜 난관이었다.
규모가 커지면 드러나는 것들
본 문제는 차원이 달랐다. 부품 종류가 20여 개에서 81개로, 개수는 약 1천 개에서 1만 개 가까이로 늘었다. 워밍업용 스크립트를 대부분 재사용하려면 검증 로직을 잠시 꺼야 했고, 회로 추출 시간도 2초에서 1분 가까이로 늘어났다. 필자는 배선 조각 수집 단계를 재구성해 3.4초를 0.03초로 100배 앞당겼는데, 바이트 단위로 동일한 결과를 보장한다는 점을 근거로 버그가 없다고 확신했다. 다만 연결 요소 탐색이라는 병목은 그대로여서, 오히려 그 단계에 대한 신뢰를 쌓아 실행 횟수를 줄이는 전략을 택했다. 새로 필요한 40여 개 소자는 문서를 보고 일일이 옮겨 구현했다.
검증을 다시 켜자 흥미로운 발견이 나왔다. 어떤 배선이 두 입력 핀에만 연결된 채 아무것에도 구동되지 않는, 값이 정해지지 않은 상태였다. 보통은 값이 필요 없더라도 배선을 특정 값으로 고정하지 자체를 끊어두지는 않는다. 게다가 이웃 핀에는 입력도 출력도 아닌 연결이 붙어 있었다. 필자는 자기 코드의 버그라고 의심하면서도 조심스레 이를 Jane Street에 제보했고, 다음 날 실제 설계상의 오류가 맞다는 확인 메일을 받았다. 결과에는 영향이 없다는 단서가 붙긴 했지만, 역설계로 원 설계의 실수를 짚어낸 셈이다. 마지막 국면에서 필자는 '성공' 신호로 이어지는 배선이 6개이며 그중 2개는 일정 클럭 이후 자동으로 충족된다는 점을 파악해, 문제를 나머지 4개 배선을 어떻게 켤 것인가로 좁혀 나갔다.
이 사례가 주는 실무적 시사점은 분명하다. GDS·VCD·Verilog·sky130처럼 소프트웨어 개발자에게 낯선 스택도 결국 파일 파싱, 그래프 탐색, 공개 문서 독해라는 익숙한 기술의 조합으로 풀린다는 것이다. 동시에 한계도 뚜렷하다. 도구를 처음부터 만들려는 충동은 진도를 크게 늦췄고, 검증을 끄고 진행한 구간은 나중에 부담으로 돌아왔다. 표준 라이브러리와 공식 문서를 먼저 확인하는 평범한 절차가 결국 가장 빠른 길이었다는 점은, 화려한 자작 도구보다 기본기가 문제 해결의 핵심임을 다시 상기시킨다.