0.1나노의 공학, 그리고 미분 불가능한 코드의 최적화

이 글을 쓰게 된 이유

삼성전자 메모리사업부. 0.1nm 단위의 물리적 한계를 극복하고 HBM 같은 제품을 만들어내는 곳이다. 근데 화려한 스펙 뒤에서 실제로 뭘 하고 있냐면...

수천 명의 석/박사 엔지니어가 Verilog 타이밍 맞추려고 밤새 시뮬레이션 돌리고, 테라바이트급 로그에서 특정 헥사값 찾으려고 정규식이랑 씨름한다. 이른바 **'Human-in-the-loop Optimization'**의 극한이다.

왜 반도체 설계/검증에 AI Agent 도입이 필연적인지, 그리고 그게 어떻게 '미분 불가능한 코드'를 최적화하는지 정리해보려고 한다.

현장의 병목: 코드를 짜는 게 아니라 규격을 번역하고 있다

메모리 반도체 개발의 70%는 창의적인 설계가 아니다. 방대한 스펙(JEDEC, Internal Spec)을 RTL 코드로 변환하고, 그 변환이 맞는지 검증하는 'Translation & Validation' 과정이다.

여기에 Claude Code 같은 에이전틱 툴이 들어오면 어떻게 되는지 살펴봤다.

Case 1: RTL Design (Parameter Mapping & FSM Logic)

DRAM 컨트롤러 설계할 때, 스펙이 바뀌면 타이밍 파라미터(tRFC, tREFI 등)랑 State Machine 로직을 수정해야 한다. 단순한데 휴먼 에러가 가장 많이 나는 지점이다.

[Before: Human Engineer] 엔지니어가 PDF 듀얼 모니터에 띄워두고, 계산기로 클럭 사이클 계산해서 하드코딩한다. 실수하면 디버깅에 며칠 날린다.

[After: Agentic Workflow] 에이전트한테 **"DDR5 Spec Rev 1.2 참조해서, 3200MHz 기준 Refresh FSM 재설계해"**라고 시킨다.

// Generated by Agent (Context: DDR5 Spec Rev 1.2, Target: 3200MHz)
module dram_refresh_ctrl (
    input logic clk,
    input logic rst_n,
    output logic ref_req
);
    // [Agent Insight] 3200MHz (Period: 0.3125ns) 기준 tREFI 3.9us 계산
    // 3900ns / 0.3125ns = 12480 cycles
    localparam int REF_PERIOD_CYCLES = 12480;

    // Timer Logic
    logic [13:0] timer; // Agent가 bit-width도 자동 최적화 (12480 담기에 충분한 14bit)

    typedef enum logic [1:0] {IDLE, COUNT, REQ_ASSERT, WAIT_ACK} state_t;
    state_t current_state, next_state;

    // FSM State Logic (생략: 에이전트가 Spec 맞게 자동 생성)
    // ...
endmodule

에이전트가 단순 코딩만 하는 게 아니라, REF_PERIOD_CYCLES 계산 근거를 주석으로 남기고, timer 비트 폭까지 최적화해서 합성 시 면적 낭비를 줄인다. 이런 게 좀 인상적이었다.

Case 2: Verification (UVM Sequence for Corner Cases)

검증 엔지니어 시간은 대부분 **"어떻게 하면 이 디자인을 망가뜨릴까"**에 쓰인다.

[Before: Human Engineer] 커버리지 리포트 분석하고, 뚫리지 않은 구멍 채우려고 수동으로 시퀀스 작성한다.

[After: Agentic Workflow] 에이전트한테 **"Coverage 92%다. Bank Conflict 상황에서 Random Write/Read 섞이는 시퀀스 만들어서 hole 채워"**라고 시킨다.

// Generated by Agent (Objective: Maximize Bank Conflict Coverage)
class heavy_conflict_sequence extends uvm_sequence #(mem_transaction);
    `uvm_object_utils(heavy_conflict_sequence)

    task body();
        mem_transaction tr;
        int prev_bank = -1;

        repeat(5000) begin
            tr = mem_transaction::type_id::create("tr");
            start_item(tr);
            if (!tr.randomize() with {
                // [Agent Insight] 이전 트랜잭션과 동일한 Bank 강제 → Conflict 유도
                if (prev_bank != -1) { bank == prev_bank; }
                // Row Address는 다르게 → Page Miss 유도
                row_addr inside {[0:32'hFFFF]};
                op_type dist {WRITE:=60, READ:=40};
                delay == 0; // Back-to-back으로 파이프라인 부하 극대화
            }) begin
                `uvm_error("SEQ", "Randomization failed")
            end
            prev_bank = tr.bank;
            finish_item(tr);
        end
    endtask
endclass

'Bank Conflict'라는 추상적 의도를 이해하고, 이걸 유도하기 위한 구체적 조건을 constraint로 변환하는 게 꽤 잘 된다.

왜 이제야 가능한가

왜 지난 수십 년간의 자동화 툴은 이걸 못 했고, LLM 기반 에이전트가 해결하는 걸까. '코드의 불연속성' 때문이라고 보고 있다.

반도체 개발은 거대한 SA(Simulated Annealing) 과정이다

개발 프로세스가 담금질 기법이랑 비슷하다는 생각이 들었다.

1. Global Search (High Temperature): 아키텍트가 "HBM4는 16단 적층", "공정은 1c 나노" 같은 큰 구조 변경을 한다.
2. Local Optimization (Cooling): 수천 명의 엔지니어가 PPA 목표 맞추려고 파라미터를 미세 조정한다.

기존 알고리즘의 한계

문제는 이 Local Optimization 단계다. 물리적 수치(전압, 길이)는 미분 가능하니까 기존 알고리즘으로 최적화가 쉽다. 근데 코드(RTL/Script)는 미분 불가능하다.

• if (cnt > 5) 에서 5를 5.1로 바꾸면 문법 에러다.
• 기존의 기계적 탐색(GA 등)은 문법과 의미가 결합된 '코드 공간'을 탐색할 수 없었다.
• 그래서 "문법에 맞게 코드 수정하면서, 의도를 달성할 수 있는" 유일한 실행기가 인간 엔지니어였다.

LLM: Semantic Optimization의 시작

LLM 기반 에이전트가 다른 이유는, 코드를 텍스트가 아닌 의미의 공간에서 다루기 때문인 것 같다.

• "Setup Time Violation 났으니 데이터 패스에 버퍼 추가해"라는 의미론적 지시를 이해한다.
• 이걸 문법적으로 완벽한 코드로 변환한다.
• 즉, **'코드라는 불연속적 공간에서 미분이 가능해진 것'**이라고 볼 수 있다.

비슷한 흐름들

이런 변화가 반도체만의 얘기는 아닌 것 같다. **"완벽한 공식을 버리고, 최적의 근사를 찾는다"**는 Inverse Design 흐름이 여러 분야에서 보인다.

Bio: DeepMind AlphaFold

단백질 구조를 물리학(슈뢰딩거 방정식)으로 풀려면 우주 나이만큼 걸린다.

AlphaFold는 물리 공식을 버렸다. 20만 개의 단백질 구조 데이터를 학습해서 패턴을 찾았고, 실험 없이 구조를 99% 정확도로 예측했다.

Semiconductor: Google AlphaChip

칩 내부 배치(Floorplanning)는 수십 년간 인간 엔지니어의 감에 의존했다.

AI가 칩 설계를 바둑처럼 인식하고 강화학습을 했다. 결과물은 인간이 보기엔 괴상망측한 배치였는데, 시뮬레이션 돌려보니 전력 효율과 성능이 인간 설계를 압도했다.

Aerospace: SpaceX

완벽한 설계도 그리느라 몇 년 쓰는 NASA 방식 대신, Iterative Design을 택했다.

3D 프린팅으로 빠르게 시제품 만들고, AI로 테스트 데이터 분석하고, 다음 날 바로 수정 버전을 띄운다.

일단 여기까지 정리하면

엔지니어의 역할이 "스펙을 코드로 구현하는 사람"에서 **"문제를 정의하고, AI가 내놓은 결과의 물리적 타당성을 검증하는 사람"**으로 이동하고 있다는 생각이 든다.

보안 이슈로 아직은 사내 망에 갇혀 있지만, 기술적 효율성의 압력이 결국 이 댐을 넘어서게 될 것 같다.

"공식은 죽었고, 근사는 승리했다."

맨아워 갈아 넣는 시대랑 작별하고, 에이전트라는 새로운 동료랑 0.1나노의 극한을 탐험할 준비를 해야 하지 않을까. 일단 그렇게 보고 있다.