반도체 장비 소프트웨어: 제어, 비전, 팹 호스트를 움직이는 C++스택

코드를 이해하던 사람은 이미 떠났다

너무나 익숙한 장면입니다. 누군가 레거시 센서 테스트 시스템을 새로 맡게 되었는데, 이전 담당자와의 인수인계는 이미 끝나버린 뒤입니다.

전자·제조 기업의 디렉터인 Roger Swann의 경험은 인상적이어서, 이번 달 초에 사례 연구로 정리해 발행했습니다.

여기서 멈추지 않고 논의를 조금 더 넓혀보려 합니다. 그 사례에서 오래 남은 것은 스파게티 코드가 아니었습니다. 이런 상황이 산업용·제조용 소프트웨어에서 얼마나 흔한 일인지, 그런데도 이에 대해 쓰는 사람은 얼마나 드문지였습니다.

반도체 장비는 보통 하드웨어의 성취로 다뤄집니다. 나노미터 단위의 정밀도, EUV 광원, 인류가 만든 가장 복잡한 기계. 소프트웨어도 그에 못지않게 흥미롭지만 거의 다뤄지지 않습니다. 그리고 그 소프트웨어는 업계에서 가장 까다로운 C++ 중 하나입니다.

반도체 제조에서 가장 중요한 지표는 가동률과 반복성입니다. 이 요구는 기계에서 끝나지 않습니다. 코드 안에 그대로 녹아들어야 하고, 그것이 바로 이 코드가 작성한 사람보다 오래 살아남는 이유입니다.

이 글에서는 하나의 장비 소프트웨어가 동시에 감당하는 네 가지 일을 하나씩 살펴봅니다.

장비의 동작 순서 제어

다음에 어떤 동작이 일어날지 결정하고, 조건이 충족되지 않으면 그 동작을 막는 부분입니다. 레시피 실행, 상태 머신, 인터록, 알람 처리, 그리고 웨이퍼나 기판이 장비를 통과하는 흐름 같은 표현으로도 불립니다. 이런 일에 대한 채용 공고나 벤더 문서에서 기업들이 흔히 요구하는 것들이기도 합니다.

EFEM — Equipment Front End Module(장비 전단 모듈). 웨이퍼가 캐리어와 공정 챔버 사이를 오가는, 장비 앞쪽의 밀폐된 구역입니다. 보통 로봇 암이 이 이송을 담당합니다. 공장의 물류와 장비 내부의 물류가 만나는 지점입니다.

정밀하게 움직이기

축 동기 제어, 스테이지, 로봇 암, 웨이퍼 이송의 영역입니다. 타이밍 요구가 워낙 엄격해서 기술 선택 전체를 좌우할 정도입니다.

이는 모션 컨트롤 벤더들이 내놓는 제품에서 확인할 수 있습니다. 이런 종류의 장비 대부분은 밀폐된 산업용 장치가 아니라 일반적인 Windows PC에서 동작하는 모션 컨트롤러로 구동되고, 해당 컨트롤러 벤더들은 이를 프로그래밍할 수 있는 C++인터페이스를 제공합니다(예: PC 기반 EtherCAT 모션 컨트롤러인 Robotic Systems Integration의 RMP). 실시간성, PC 기반, C++ 인터페이스라는 이 조합이 엔지니어링 문제의 성격을 규정합니다. 잘못된 순간의 지연이나 끊김은 곧 충돌로 이어질 수 있습니다.

보기

보다 능동적인 검사, 계측, 정렬에 해당하는 영역입니다. 카메라가 공정을 지켜보고, 소프트웨어가 지금 보이는 것이 허용 범위 안에 있는지 판단합니다.

대형 머신 비전 소프트웨어 기업 중 하나인 MVTec은 이 작업을 “웨이퍼 공정과 리소그래피부터 패키징과 최종 테스트까지” 생산 체인 전체에 걸쳐 이어지는 일로 설명합니다. 작은 결함도, 작은 정렬 오차도 모두 수율로 이어지기 때문입니다.

AOI — Automated Optical Inspection(자동 광학 검사). 사람이 직접 눈으로 확인하는 대신, 카메라와 영상 처리로 결함을 찾아내거나 대상이 제자리에 있는지 확인하는 것을 말합니다. 이 분야에서 매우 자주 등장하는 용어이며, 보통 AOI로 줄여 부릅니다.

이 프로그램을 처음부터 직접 만드는 회사는 거의 없습니다. 대부분 상용 머신 비전 라이브러리를 구매해 그 위에 자사의 검사 소프트웨어를 얹습니다. 시장을 양분하는 HALCON과 VisionPro는 둘 다 C로 작성되었고, 둘 다 C++ 를 일급 제어 수단으로 제공합니다. 이 점을 눈여겨볼 만합니다. 검사 시스템의 중심에 있는 라이브러리가 C++ 라이브러리라면, 그것을 감싸는 애플리케이션도 결국 C++ 애플리케이션이 되는 경우가 많습니다.

공장과 대화하기

팹 현장의 모든 장비는 정해진 방식으로 공장 호스트에 보고해야 하고, 그 표준이 SECS/GEM입니다.

SECS/GEM — 생산 장비와 공장의 중앙 컴퓨터가 서로 통신하는 합의된 방식으로, 업계 표준화 기구인 SEMI가 발행합니다. 이 표준들은 세 가지를 규정합니다. 표준을 준수하는 장비가 어떻게 동작해야 하는지, 메시지는 어떤 형식인지, 그리고 그 메시지가 양쪽 사이를 어떻게 오가는지입니다. 전달 방식은 두 가지가 명시되어 있는데, 네트워크 연결과 더 오래된 시리얼 케이블입니다.

구체적인 문서 번호가 필요한 경우: E30은 동작 모델, E5는 메시지 형식, E37은 네트워크 전송, E4는 시리얼 전송을 정의합니다.

SEMI가 직접 작성한 소개 자료는 이를, 서로 완전히 다른 제조사의 장비들이 각자 무슨 일을 하든 동일한 공장 컴퓨터에 보고할 수 있게 해주는 계층으로 설명합니다. 두 전달 방식 중 오래된 쪽은 시리얼 케이블입니다. 20년 전 일반 PC에서 사라진 바로 그 9핀 커넥터입니다. 그런데도 여전히 표준에 남아 있습니다.

Two transports, one standard. The RS-232 path is still specified.

Four separate engineering problems, maintained as one application.

왜 Windows 위의 C++, 그리고 Visual Studio인가

Windows 기반 C++가 여전히 가장 보편적인 구성으로 남아 있는 데에는 몇 가지 이유가 겹쳐 있습니다.

타이밍 요구 때문에, 곤란한 순간에 멈출 수 있는 선택지는 애초에 제외됩니다. 또한 소프트웨어가 하드웨어에 직접 닿아야 합니다. 카메라 카드, 모션 카드, 디지털 입출력과 중간 계층 없이 통신해야 합니다. 앞서 본 것처럼 비전과 모션 라이브러리가 C++ 라이브러리이므로 애플리케이션도 자연히 그쪽을 따라갑니다. 그리고 특정 장치를 지원하기 위해 20년 넘게 축적된 코드가 오직 한 곳에만 존재합니다. 바로 지금 가지고 있는 그 코드베이스입니다.

특히 Windows는 타협이 아니라 의도적인 선택입니다. 하드웨어 벤더들이 Windows용 드라이버를 작성하고, 장비 오퍼레이터가 실제로 마주하는 화면은 Windows 데스크톱 애플리케이션입니다. 건물보다 비싼 장비 옆에 그 화면이 놓여 있습니다.

이 코드베이스는 왜 오래되고, 왜 그대로 남는가

가장 널리 알려진 사례는 ASML입니다. 회사가 직접 이야기하기 때문입니다. ASML은 자사의 임베디드 소프트웨어가 장비를 조종하고 제어한다고 설명하면서, 그 코드베이스가 “지난 30년간 개발되어 왔으며” “현재 수백만 줄의 코드로 이루어져 있다”고 밝히고 있습니다. 채용 자료에는 사용 언어가 C, C++, Python, Java, MATLAB으로 명시되어 있습니다.

30년이면 개발 도구로 네다섯 세대에 해당합니다. 코드는 그 모두보다 오래 살아남았습니다.

그 아래 깔린 것들은 더 오래되기도 했습니다. Microsoft는 MFC를 계속 지원하지만, 자사 표현으로는 “새 기능을 추가하거나 문서를 갱신하지 않는다”고 밝히고 있습니다. 그런데도 MFC는 산업 제어 소프트웨어에서 여전히 현역입니다. 많은 장비 애플리케이션에서 UI 계층은 지금의 팀원이 합류하기 훨씬 전에 만들어진 것입니다.

사실 금융기관과 은행이 새로운 기술을 더디게 도입하는 것과 정확히 같은 이유입니다. 즉시 계좌이체나 상호 연동되는 QR 코드를 스타트업과 소규모 기업이 먼저 선보였던 것을 눈치채신 적 있으신가요? 임베디드 소프트웨어와 마찬가지로, 이런 금융 시스템도 수십 년 된 시스템 위에서 돌아가기 때문입니다. 그대로 유지하는 것만으로도 이미 상당한 유지보수가 필요한 데다, 바꾸려면 대규모 리팩터링까지 따라옵니다.

그렇다면 왜 아무도 새로 만들지 않는가 하는 질문이 자연스럽게 나옵니다. 답은 “그럴 여유가 없어서”보다 훨씬 규율 있는 것입니다. 현장에 나가 있는 장비는 인증되고 검증된 소프트웨어 이미지로 동작합니다. 그 이미지를 바꾸면, 고객사와 공정에 따라 장비가 인증된 대로 동작한다는 것을 다시 증명해야 할 수도 있습니다. 그 비용은 재작성 비용 위에 얹히고, 대개 이 부분이 논의 자체를 없애버립니다.

간단히 말하면 이렇습니다. 소프트웨어를 건드리는 것은 곧 장비를 다시 증명하는 일이므로, 손대기 위한 기준선이 일반적인 소프트웨어보다 훨씬 높습니다. 이미 신뢰하고 있는 코드를 확장하는 쪽이 대개 합리적인 선택이고, 그래서 이 코드베이스는 교체되기보다 계속 자랍니다.

The tooling turns over. The codebase doesn’t.

그 안에서 일하는 사람들에게 이것이 의미하는 것

세 가지 결과가 따라옵니다. Roger의 인수인계 이야기가 좋은 예시지만, 사실 우리가 인정하고 싶은 것보다 훨씬 자주 일어나는 일입니다. 그는 소프트웨어를 수정해야 했는데, 수정을 하려면 공장 현장을 직접 방문해야 했습니다. 효율적인 구조라고 보기는 어렵습니다.

대부분의 경우 자기 책상에서 그것을 실행해볼 수 없습니다. 장비는 어딘가의 공장이나 고객사 현장에 있고, 문제를 재현하는 데 필요한 하드웨어는 비싸고 이미 예약이 차 있습니다. 시뮬레이터가 그 간극의 일부를 메워주지만, 전부를 메우지는 못합니다.

노하우와 유일한 참조 자료가 결국 코드 안에만 남게 됩니다. 알려줄 수 있었던 사람들이 이미 떠났기 때문입니다. Roger의 사례는 유독 극단적이었지만, 그 형태 자체는 드물지 않습니다. 원 작성자에게 연락이 닿지 않는데, 시스템은 바뀌어야 하는 상황입니다.

그리고 익숙해지는 데 오랜 시간이 걸립니다. Roger의 이야기가 우리가 가진 가장 분명한 근거입니다. 그는 규모가 작고 복잡도가 낮은 변경부터 시작했는데, 본인 표현으로는 그 작업이 “사실상 코드를 익힐 시간을 벌어준 셈”이었습니다. 공장 이전 작업을 마무리하고 나서야 비로소 고객이 더 큰 일을 맡길 만큼 자신을 신뢰한다고 느꼈다고 합니다. 정작 맡기로 한 일에 착수하기까지 몇 달의 준비 기간이 있었던 셈입니다.

반도체 제조는 보통 설계, 팹, 조립, 테스트로 이어지는 파이프라인으로 설명됩니다. 이 설명에는 그 모두가 딛고 서 있는 소프트웨어 계층이 빠져 있습니다. 각 단계가 실제로 일어나게 만드는 C++를, 누군가는 IDE 앞에 앉아 작성하고 있습니다. 소프트웨어는 공정 주위에 배치된 무언가가 아닙니다. 코드로 표현된 공정 그 자체입니다.

업계를 다루는 글에서 그 사람이 등장하는 일은 거의 없어서, 그들이 실제로 어디에 앉아 있는지 잊기 쉽습니다. 클린룸도, 팹 현장도 아닙니다. 평범한 Windows 머신 위의 Visual Studio 솔루션이고, 자신이 작성한 코드가 돌아갈 장비와는 다른 나라에 있는 경우도 많습니다.

그리고 그들의 하루는 대부분 새로운 알고리즘을 작성하는 시간이 아닙니다. 기존 코드를 읽는 시간입니다. 어떤 동작이 무엇 때문에 일어나는지 거슬러 올라가고, 스무 군데를 건드리지 않으면서 한 곳만 바꾸고, 건물보다 비싼 장비에 도달하기 전에 그 변경이 안전하다는 것을 스스로 납득하는 시간입니다.

바로 이 마지막 지점에서 이 환경은 대부분의 소프트웨어와 갈라집니다. 보통은 에디터에서 코드를 작성하고 런타임에서 배웁니다. 실행해보고, 잘못 동작하는 것을 지켜보고, 그렇게 이해가 깊어집니다. 그런데 런타임이 접근할 수 없는 웨이퍼 핸들러라면, 이해의 상당 부분을 개발 환경 자체에서 얻어야 합니다. 심볼 해석, 참조 찾기, 호출 계층을 통해서 말입니다. 실행해서 답에 도달하는 대신, 읽어서 답에 도달하게 됩니다.

그래서 이런 코드베이스는 IDE에 유독 큰 부담을 지웁니다. 그것도 IDE 도구가 가장 혹독하게 시험받는 규모와 연식에서 그렇습니다.

장비의 요구사항은 코드 안으로 들어왔습니다. 그리고 한 걸음 더 나아가, 그 코드를 유지보수하는 사람들이 자신의 도구에 요구하는 것으로 이어집니다.

우리가 다루는 영역

이 마지막 부분이 저희의 영역입니다. 저희는 Visual Studio용 C++ 생산성 확장 프로그램인 Visual Assist를 만듭니다. 위에서 설명한 바로 그 문제를 위해 존재합니다. 기본 도구가 제 역할을 하기에는 너무 크거나, 너무 오래되었거나, 너무 불완전한 코드를 읽고 탐색하는 문제입니다.

이것이 장비 소프트웨어에서 실제로 어떻게 펼쳐지는지는 그 자체로 하나의 주제여서, 따로 정리해 두었습니다: 장비를 실행할 수 없을 때 레거시 장비 제어 코드베이스에서 일하는 법.

Visual Assist 사용해보기 30일 무료 체험 · 신용카드 불필요

자주 묻는 질문

장비 제어 코드베이스는 다른 대형 C++ 코드베이스와 무엇이 다른가요?

세 가지입니다. 첫째, 코드가 하드웨어에 묶여 있고 그 하드웨어를 자기 책상에서 실행해볼 수 없는 경우가 많습니다. 그래서 디버거가 이해를 위한 주된 수단에서 빠지게 됩니다. 둘째, 코드를 변경하면 장비를 다시 인증해야 할 수 있어서, 변경 비용이 코드 밖으로까지 확장됩니다. 셋째, 예상 수명이 수십 년 단위여서 코드베이스에 훨씬 많은 이력이 쌓입니다. 언어는 대개 Windows 위의 C++이고, Visual Studio나 그와 유사한 IDE로 개발됩니다.

SECS/GEM이 무엇인가요?

생산 장비와 공장의 중앙 컴퓨터가 메시지를 주고받는 합의된 방식으로, 반도체 업계 표준화 기구인 SEMI가 발행합니다. 표준을 준수하는 장비가 어떻게 동작해야 하는지, 메시지는 어떤 형식인지, 그리고 네트워크 연결이나 더 오래된 시리얼 케이블 중 어느 쪽으로 오가는지를 규정합니다. 관련 문서는 SEMI E30, E5, E37, E4입니다.

반도체 장비는 왜 여전히 Windows와 MFC에서 돌아가나요?

하드웨어 벤더들이 Windows용 드라이버를 작성하고, 오퍼레이터가 사용하는 화면이 Windows 애플리케이션이며, 상용 비전·모션 라이브러리도 Windows를 기준으로 만들어졌기 때문입니다. MFC가 남아 있는 이유는 Microsoft가 여전히 지원하고 있고, 승인된 소프트웨어 이미지 안의 인터페이스 계층을 교체하면 장비를 다시 승인 절차에 올려야 하기 때문입니다. 그 비용이 정당화되는 경우는 드뭅니다.

장비 제어 코드베이스는 규모가 어느 정도인가요?

장비에 따라 편차가 매우 큽니다. 가장 명확한 공개 기준점은 ASML로, 지난 30년간 개발되어 온 수백만 줄 규모의 임베디드 코드베이스를 보유하고 있다고 밝히고 있습니다. 대부분의 장비는 이보다 훨씬 작지만, 규모만 다를 뿐 같은 종류의 문제를 안고 있습니다.

반도체 제조에서 소프트웨어 개발은 어디에 위치하나요?

그 모든 것의 아래에 있습니다. 증착, 식각, 검사, 테스트, 물류를 포함한 모든 공정 단계는 누군가 작성했고 지금은 다른 누군가가 유지보수하는 제어 소프트웨어가 실행합니다. 개발자들은 대체로 팹 현장에 있지 않습니다. 평범한 Windows 머신의 IDE 앞에서 일하며, 자신의 코드가 돌아갈 장비와 멀리 떨어져 있는 경우가 많습니다.