파운드리 엔지니어가 매일 싸우는 것들 — 5년차 현직자 이야기 ②

파운드리 엔지니어가 매일 싸우는 건 뭘까? 수율과 성능의 Trade-off, 부족한 실험 Data, 끝없이 반복되는 N자 커브. 5년차 공정설계 현직자가 느끼는 이 업계의 현실적인 어려움과 요즘 Tool 변화를 솔직하게 적어본다.

지난 글에서 파운드리 공정설계 엔지니어가 뭘 하는 사람인지 적어봤다. ET Data 분석, Correlation, Virtual Metrology 같은 이야기들. 이번에는 그 일이 왜 어려운지, 그리고 요즘 어떤 Tool로 하고 있는지를 적어보려 한다.

모니터 앞에서 Data랑 씨름하는 게 일상이다 (Photo: ThisisEngineering, Unsplash)

수율과 성능, 왜 둘 다 챙기기 어려울까?

파운드리 프로세스에서 항상 신경 쓰는 게 크게 두 가지다. 수율과 성능. 신뢰성도 물론 중요한데, 수율이 좋으면 신뢰성도 대체로 따라오는 편이라 결국 싸움은 수율 vs 성능 구도가 된다.

문제는 이 둘이 거의 항상 Trade-off 관계라는 거다. 쉬운 예를 하나 들면, 게이트 쪽에 산화막을 두껍게 깔면 절연이 좋아지니까 수율이나 신뢰성은 올라간다. 근데 산화막이 두꺼우면 Gate가 Channel을 제어하는 힘이 약해지니까, 같은 Voltage에서 Drive Current가 줄고 성능은 떨어진다. 반대로 산화막을 얇게 가져가면 성능은 좋아지는데 조금만 결함이 있어도 바로 Leakage가 터져서 수율이 깎인다.

이런 식으로 성능을 올리려면 뭔가를 한쪽 끝단으로 밀어야 하는 경우가 대부분이라, 수율 희생이 거의 따라온다. 큰 설비 변경이나 새로운 물질 도입 같은 Game Changer가 등장하면 둘 다 잡는 경우가 있긴 하다. 근데 그런 일은 솔직히 거의 드물다.

Trade-off만 문제가 아니다

구조적으로도 개선이 쉽지 않은 이유가 많다. 일단 뭔가를 확인하려면 실험을 해야 하는데, Wafer 한 장 만드는 데 돈이 꽤 든다. 그래서 실험에 쓸 수 있는 Wafer가 항상 한정되어 있고, 결국 가고 싶은 실험군의 Data가 너무 적다. 적은 Data에 대해서도 모든 계측값이 있는 것도 아니고.

거기다 결과가 나와도 이게 실험 조건 때문인지 그냥 공정산포인지 애매할 때가 많다. 내부 공정산포도 제법 있고, 가끔 이슈가 발생했는데 Data에 잘 반영이 안 되는 경우도 있다. 워낙 많은 Layer들이 들어가다 보니 전체를 이해하는 것 자체가 쉽지 않다.

솔직히 결정하는 사람이 그 모든 것에 전문가일 수도 없고, 부서 간에 문제가 생기면 면피하려는 Silo도 제법 있다. 이런 것들이 Trade-off 외에도 수율/성능 개선을 가로막는 현실적인 방해물이다.

끝없이 차트를 보면서 원인을 추적하는 일상 (Photo: Stephen Dawson, Unsplash)

끝없이 반복되는 N자 커브

새로운 걸 도입하면 거의 항상 N자 커브가 나온다. 처음에 잘 되다가 떨어졌다가 다시 올라오는 패턴인데, 다양한 조건들을 새로 튜닝해야 하기 때문이다. 하나를 바꾸면 연결된 다른 것들도 다 영향을 받으니까.

더 골치 아픈 건, 이렇게 프로세스를 한번 잡아놔도 다음 제품이 오면 또 N자 커브가 생긴다는 거다. 프로세스가 설계자한테 일종의 키트를 제공하는 구조인데, 제품마다 이 키트의 사용 비율이 다르다. 비율이 달라지면 환경 자체가 변하기 때문에 기존에 잡아놓은 최적점이 다시 흐트러진다. 전에 없던 불량이 툭툭 튀어나오기도 하고. 끝이 없는 느낌이랄까.

반도체가 유독 힘든 이유가 여기에 있다. 이 업이라는 게 항상 새로운 걸 적용해야 하고, 거의 물리적 한계의 끝단에서 싸우는 첨단기술이다. 지금 쓰는 공정이 이미 원자 몇 개 수준의 정밀도를 요구하는데, 거기서 또 한 단계 더 가야 한다. 그걸 극복하는 게 쉬울 리가 없다.

Spotfire, Python, In-house Tool... 그리고 요새는 LLM, LLM, LLM

업무에서 주로 쓰는 Tool을 꼽자면 Spotfire, Python, 그리고 여러 In-house Tool들이 있다. Spotfire는 대용량 Data 시각화에서 여전히 강력하고, Python은 자유도가 높아서 Custom 분석에 좋다. 점점 Python 비중이 늘고 있는 추세다.

근데 요즘 진짜 체감되는 건 LLM이다. 솔직히 요즘 LLM 없이 코딩하라고 하면 좀 막막할 거 같다. 기획만 잘하면 웬만한 자동화 Script는 뚝딱 나온다. 체감상 뭔가를 생각하는 게 8, 실제로 만드는 게 2 정도 되는 느낌이다. 예전에는 구현하는 데 시간이 많이 들었는데, 이제는 "뭘 만들지"를 고민하는 게 핵심이 됐다.

Python 코드를 보는 시간이 점점 늘고 있다 (Photo: Pankaj Patel, Unsplash)

근데 코딩 말고, 본업인 반도체 Data 분석 쪽은 어떨까? 실제로 요새는 많은 부분에 AI를 적용하고 개선하려고 정말 많이 노력하고 있다. 근데 솔직히 가시적으로 큰 성과를 내는 부분은 아직 작다. 그래도 방향 자체는 맞다고 본다. 1등급에서 100점 맞으려고 가는 느낌이랄까.

지금까지는 단순히 1:1이나 N:1 Correlation을 보는 수준이었다면, 궁극적으로는 수많은 Layer 간의 교호작용까지 조절하고 반영하려는 방향으로 가고 있다. 근데 반도체 Data가 워낙 방대하고, 아직은 경험치적인 Commonality, 그리고 Physics 기반 판단이 훨씬 중요하다. 공정구조, Process, 물성에 대한 이해 없이 Data만 넣어서는 의미 있는 결과가 안 나온다.

물론 Claude 수준의 LLM을 대대적으로 잘 세팅한다면 가능성이 있을 수도 있다. 근데 그건 회사의 실 Data라는 moat(해자)를 스스로 포기하는 거라, 결국 내부 LLM Tool을 만들고 Agentic하게 시도하는 방향으로 가고 있는 거 같다. 아직은 좀 멀었지만, 가벼운 Code 생성이나 Refactoring 같은 건 내부 LLM도 꽤 올라온 느낌이다. 1-2년 전에 비하면 확실히 좋아졌다.

1편에서 내가 뭘 하는 사람인지 적었고, 이번 글에서는 왜 이 일이 만만치 않은지를 적어봤다. 적다 보니까 결국 이 업의 본질은 끝이 없다는 것인 거 같다. 해결하면 또 새로운 문제가 오고, 그걸 또 풀어야 하고.

근데 그게 이 직업의 묘한 매력이기도 하다. 같은 일의 반복 같으면서도 매번 다른 문제를 만난다.

다음에는 좀 더 구체적으로 Spotfire로 ET Data 분석하는 방법이나, Python으로 자동화한 경험 같은 것도 적어볼까 한다.