CTC, TMC, PMC 그리고 ...

반도체 설비는 CTC, TMC, PMC로 논리적 분류를 할 수 있다. 물리적으로는 Transfer(반송), Process(공정)으로 분리할 수 있다. 물론 보편적인 설비의 경우이며 특별한 기능을 가진 설비는 다른 형태를 가질 것이다.

용어 관련하여서는 아래 문서를 참고하시라.
http://www.techbase.co.kr/business/business_01.php

CTC는 웨이퍼의 흐름(Route)을 관장하고 TMC가 웨이퍼를 실제로 반송을 담당하고 PMC는 웨이퍼의 공정을 담당한다. 이름은 설비 메이커마다 조금씩 다를 수는 있으나 거의 같은 기능을 가진다. 여기에 자동화(FA, SECS/GEM 등)가 연결되어 설비의 무인화를 완성한다.

한 설비에 TMC, PMC는 여러개 설치가 될 수 있으며 한 가지 공정 혹은 여러 개의 공정을 동시에 처리하고 생산성을 높이기 위한 구성으로 계속 진화한다. 

1995년쯤 내가 처음으로 접한 CTC는 REALTIME PERFORMANCE, INC의 RPCluster라는 소프트웨어이다. 나의 사수가 고객사와 JDP를 통하여 해당 프로그램을 이용하여 설비 제어를 진행하였고 이후 내가 신입으로 프로젝트에 참여하였다. 

 

RPI RPCluster

 

공정을 위한 PMC를 제어하기 위해서는 UNIX 계열의 OS9에 설치되는 제어 프로그램(이름이 기억이 안 남)을 사용하여 설비를 제어하였다. 요즘 사용하는 UMAC 시스템과 유사한 구조였다. VME Bus를 사용하였으며 OS는 OS-9으로 real time processing이 가능하였고 PEP BOX라고 불렸다.  

 

PEP BOX (출저 eBay.com)

 

 

드라이버 개발의 지연, 펌웨어 버그, 서비스 부실등으로 PEP BOX를 대체할 CTC로 PRI CTC를 설비에 적용하였다. 사수는 창업으로 퇴사하였고 혼자 남아 PRI 엔지니어와 설비 제어 프로그램을 개발하였다.

이때는 위의 시스템을 폐기하고 인도국의 PRI 시스템의 순수 PC제어 CTC를 사용하였다. 말이 공동 개발이지 설비에 대해 아는 것이 없는 소프트웨어 엔지니어를 모셔다 프로우차트를 그려주고 그들의 시스템으로 코딩만 하는 수준이었다. 하지만 결과는 나쁘지 않았다. 걸출한 전장 엔지니어가 자체 개발한 optic 통신보드를 이용하여 전체 IO System을 구성하였고 이를 기반으로 제어 프로그램을 구성하였다.

이 IO System으로 상당한 숫자의 설비를 제작하여 양산 라인에 투입하였다. 나름 상당히 안정적으로 이전에 비해 안정적으로 동작하였다. 

소프트웨어, 하드웨어 모두 진짜 많은 시행 착오를 거쳐 양산에 투입하였다. 나중에 안 이야기로 양산을 꿈꾸는 모든 회사가 우리가 사용하는 파츠, 소프트웨어, 인력등을 벤치마킹 하고 있었다고 한다. 국내에서 처음으로 시도되는...

 

---

 

 

Brooks사의 Cluster link를 출시하여 한국에도 영업을 시작하였다. 먼저 사용한 회사의 내용을 들어보니 버그가 좀 많았다고 한다. 당시 OS의 상황을 보면 그게 당연하였다. 이를 설비에 적용하기 위하여 교육을 받고 준비 중에 이전 시스템 기준으로 오더가 나와 이 CTC의 적용이 무한 연기 되었다. 

Brooks사의 ClusterLink3 CTC

 

---

 

이후 CTC를 자체 개발 하려는 시도를 진행하였다. 하지만 아직 인프라의 부족으로 완성에 이르지 못하고 계속 표류하게 되었다. 그 와중에 새로운 시스템 개발을 위하여 KORNIC사의 EasyCluster를 사용하였다. 국내에서는 가장 오래되었으며 지금처럼 많은 인프라가 구성되기 전부터 설비를 운용하여 업계를 대표하는 CTC라고 불러도 될 것 같다. 

윈도우+VC6 조합으로 장점은 상당히 안정적이었다. 이전 시스템에 비해 오래 살아 있었다. 개발 초기부터 한 달 이상 유지 되었다. 이후 계속 생존 시간을 늘려 나갔다. 이전의 시스템을 생생히 기억하는 터라 시스템이 한 달 이상 유지 된다는 것은 실로 경이롭기 까지 하였다. 카피당 라이선스 비용이 다소 비싸기는 하지만 가장 안정적이고 가장 오래된 시스템이다.

현재도 이 시스템으로 설비를 개발하여 납품하는 것으로 알고 있다. 그런 와중 반도체는 자체 CTC를 개발하여 많은 설비에 적용하여 양산 퀄까지 진행하기도 했다.

 

코닉오토메이션의 EasyCluster

 

---

 

자의적 이직후  처음 접한 또 다른 CTC가 솔루더스의 REX이다. 그 당시는 다른 이름이었던 것 같은데 지금 찾아보니 REX로 명명돼 있다. 초기 BROOKS KOREA에서 자체 개발한 솔루션 이었는데 해당 부서가 없어지면서 그 개발자 중 한 분이 이를 더 발전시킨 것으로 알고 있다. 

잠깐 사용한 것이라 자세한 내부 구조는 이해하지 못했다. 설비가 거의 완성된 직후 인수인계 받은거라 최적화와 GUI에 많은 작업을 한 것 같다. 
http://www.soludus.co.kr/company/company01_01.php

 

---

 

디스플레이 업계는 설비가 한개의 공정 모듈 개념으로 반도체에 비해 단순한 개념으로 구성된다. 물론 반도체와 똑같은 Cluster 구조를 가지는 진공 설비도 있으나 로더/인덱서로부터 전달받은 한 장을 기본으로 운전하기 때문에 상대적으로 단순하다는 것이지 설비 자체가 단순한 것은 아니다. 이러다 보니 설비를 제어하는 제어 프로그램의 내제화가 보다 쉬우며 기능의 독립도 가능해졌다.

단동설비(한대의 공정 모듈)를 제어 프로그램과 별도로 제작이 가능한 CIM(FA)등이 각자 개발 환경을 형성하여 인프라가 구성되고 이로 인하여 보다 쉬운 프로그램 내재화(회사내부에서 개발하는)가 가능해졌고 이러한 개발 경험이 있는 인원이 널리 퍼져 업계의 개발 능력을 상향 평준화 하게 되었다.

실제로 후공정 쪽 설비를 접하다 보니(Furnace, Oven, AOI 등) 유사한 프로그램이 많이 보인다. 설비별로 프로그램이 유사한 구조를 가지고 있다. 아마 많은 시간을 들여 구조화된 포맷을 사용하여 개발한 프로그램이 널리 퍼진 듯하다.

한 회사에 속해 있다 보면 타사 설비의 코드를 보는 것이 불가하지만 지금은 여러 회사 설비의 코드를 보고 유지보수 및 개발을 진행하다 보니 전에 볼 수 없던 내용이 보이기 시작한다. 프로그램을 보다 보면 개발자가의 고심과 딥빡이 보이듯이...

 

---

 

업계에 발을 담근 지도 25년이 넘었다. 개발 초기에는 구조화, 공학, 계층화 등 제어 프로그램을 개발하는데 많은 기술을 적용하여 보다 쉽고 효율적으로 개발을 하려 했다. 외산 설비에 맞추어 대응하려면 그랬어야만 했다. 

하지만 이제는 많은 환경이 변하였다. 충분히 양산 설비의 제어 프로그램을 자체 개발도 가능하다. 보다 쉽게 프로그램을 구매하여 적용할 것인지를 결정하면 된다. 비용과 시간의 문제이지 기술은 상당 한 수준으로 높아졌다.

원치 않았지만 업계에 발을 담그는 순간 국내 최초의 양산형 제어 프로그램을 경험하였다. 그때에 비하면 굉장한 발전이 있었다. 비용과 시간이 문제이다. 이제 무엇이든 할 수 있다. 의지만 있다면...