반도체 레시피 관리, 변경 하나가 로트 전체를 바꾸는 이유

집집마다 대대로 쓰는 요리 노트가 하나쯤 있습니다. 김치찌개는 물 몇 컵에 간장 몇 숟가락이라고 적혀 있는데, 누군가 슬쩍 간장 양을 고쳐 적으면 그날부터 온 식구의 저녁이 달라지죠.

반도체 공장에서 장비가 읽는 공정 조건표가 이 노트와 같은 역할을 하고, 반도체 레시피 관리는 그 노트를 누가 어떻게 고치고 어느 판이 최신인지를 다루는 일입니다. 같은 노트를 읽는 장비가 하루에 수십 개의 로트를 처리하므로 한 줄의 변경은 곧바로 대량의 웨이퍼로 번집니다.

요리는 맛을 보고 바로 고칠 수 있지만 반도체는 수십 번의 공정을 더 거쳐 전기 시험을 하고 나서야 문제를 알게 됩니다. 이 시간 차이가 비유와 가장 다른 점이고, 변경을 미리 통제해야 하는 이유이기도 합니다.

반도체 레시피 관리가 필요한 이유, 조건 한 줄이 웨이퍼를 바꾼다

레시피(Recipe)는 장비가 웨이퍼 한 로트를 처리할 때 따르는 공정 조건의 묶음입니다. 온도와 압력, 가스 유량, 전력, 시간 같은 값이 순서와 함께 들어 있어서, 같은 장비라도 레시피가 달라지면 전혀 다른 결과를 만듭니다.

팹에서는 수백 개의 공정 단계마다 레시피가 따로 있고, 장비 종류와 챔버가 늘어날수록 관리할 레시피도 함께 크게 늘어납니다. 공정이 변하지 않았다는 전제가 흔들리면 SPC 같은 통계 관리도 의미를 잃습니다.

그래서 레시피는 공정 엔지니어의 작업 노트가 아니라 변경 이력이 추적되고 승인된 사람만 바꿀 수 있는 관리 대상으로 다룹니다. 이 관점을 구성 관리(Configuration Management)라고 부르고, 소프트웨어의 형상 관리와 뿌리가 같습니다.

레시피의 구성, 단계와 파라미터와 허용 범위

레시피는 보통 여러 단계(Step)로 나뉘고, 단계마다 목표 값과 허용 범위가 들어 있습니다. 식각 장비의 예를 들어 개념만 정리하면 아래와 같습니다.

레시피에는 목표 값 외에 허용 범위와 경고 한계도 함께 두는 경우가 많습니다. 값이 범위를 벗어나면 장비가 멈추거나 경고를 올려 문제가 번지기 전에 사람이 확인하게 하죠.

레시피 이름 하나가 가리키는 범위도 구분해야 합니다. 장비가 읽는 장비 레시피와 로트가 거쳐 갈 공정 순서를 담은 흐름 정보가 따로 있고, 어느 단계에서 어떤 장비 레시피를 부를지는 흐름 정보가 정합니다.

버전 관리와 골든 레시피, 기준이 되는 한 벌

버전 관리, 이름이 같아도 내용이 다른 문제

레시피는 한 번 정하면 끝나는 파일이 아니라 수율 개선과 장비 상태 변화에 맞춰 조금씩 바뀝니다. 그래서 파일 이름이 같아도 어떤 판인지 구분되도록 버전 번호를 붙이고, 이전 판은 지우지 않고 보존합니다.

버전 관리가 허술하면 같은 이름의 레시피가 장비마다 조금씩 다른 값을 갖게 되는 일이 생깁니다. 장비 안에 저장된 판과 호스트가 가진 기준 판을 비교하는 절차를 두면, 누군가 장비 화면에서 값을 직접 고친 경우를 찾아낼 수 있습니다.

골든 레시피, 모두가 맞춰 가는 기준 한 벌

골든 레시피(Golden Recipe)는 검증을 마치고 승인된, 기준이 되는 판을 가리키는 말입니다. 같은 공정을 여러 장비와 챔버에서 돌릴 때 모두 이 기준에 맞춰 결과가 같아지게 장비를 조정하는 일이 장비 매칭입니다.

다만 같은 레시피를 쓴다고 같은 결과가 나오지는 않습니다. 챔버의 마모와 부품 교체 이력이 달라서, 같은 입력에도 출력이 어긋나는 경우가 있기 때문입니다.

변경 통제 절차, 바꾸기 전에 확인하고 바꾼 뒤에 확인한다

변경 통제(Change Control)는 레시피나 장비 설정을 바꿀 때 지켜야 하는 승인 절차입니다. 회사마다 세부는 다르지만 일반적인 흐름은 아래와 같습니다.

절차가 번거로워 보이지만 각 단계는 서로 다른 실패를 막습니다. 영향 평가는 의도하지 않은 곳에 퍼지는 변경을 막고, 첫 로트 확인은 검증 시험에서 보이지 않던 문제가 양산에서 나타나는 경우를 막습니다.

이전 판으로 되돌리는 롤백 경로를 미리 마련해 두는 것도 중요합니다. 되돌릴 수 없는 변경은 시험적으로도 시도하기 어려우니까요.

잘못된 레시피가 로트 손실로 번지는 구조

잘못된 레시피가 만드는 손실은 장비 한 대에서 끝나지 않고, 문제가 드러나기까지 걸리는 시간 동안 쌓입니다. 가상의 숫자로 이 구조를 계산해 보겠습니다.

실제 팹에서는 계측이 빠르게 끝나는 공정도 있고, 문제가 뒤 공정에서야 드러나는 경우도 있어서 숫자는 상황에 따라 크게 달라집니다. 중요한 것은 문제가 드러나는 시간 지연이 길수록 영향받는 양이 시간에 비례해 커진다는 구조입니다.

레시피 이름을 잘못 지정하거나 다른 제품용 레시피를 부르는 사고도 같은 구조로 번집니다. 그래서 호스트가 로트와 레시피의 조합이 맞는지 시작 전에 점검하는 방식이 쓰입니다.

이력과 감사 추적, 누가 언제 왜 바꿨는지 남기기

감사 추적(Audit Trail)은 레시피의 변경 이력을 누가, 언제, 무엇을, 왜 바꿨는지까지 남기는 기록입니다. 값이 바뀐 사실뿐 아니라 승인자와 근거까지 있어야 나중에 문제의 원인을 거슬러 올라갈 수 있습니다.

수율이 갑자기 달라졌을 때 가장 먼저 확인하는 것이 같은 시기에 바뀐 것이 있는지이고, 이 이력이 근본 원인 분석의 출발점이 됩니다. 고객 감사에서도 같은 공정 조건으로 만들었다는 근거로 이 기록이 쓰입니다.

기록이 의미를 가지려면 아무나 고칠 수 없도록 권한을 나누는 일이 함께 필요합니다. 조회만 가능한 사람, 변경을 요청할 수 있는 사람, 승인할 수 있는 사람을 구분해 한 사람이 요청과 승인을 모두 하지 못하게 하는 방식이 흔합니다.

레시피 관리를 둘러싼 흔한 오해

첫째는 작은 값 하나를 고치는 일은 승인 없이 해도 된다는 생각입니다. 변경의 크기와 결과의 크기는 비례하지 않고, 작은 변경이 민감한 공정에서는 큰 영향을 줄 수 있습니다.

둘째는 이름이 같으면 같은 레시피다라는 이해입니다. 이름은 같아도 버전이 다르거나 장비 안에서 따로 수정되었을 수 있으므로, 이름이 아니라 버전과 내용 비교로 확인해야 합니다.

또 한 가지는 레시피를 한 번 잘 만들어 두면 반도체 레시피 관리는 끝난다는 믿음입니다. 장비 부품의 마모와 소재 변화에 따라 최적 값이 움직이기 때문에, 레시피는 정기적으로 점검하고 필요할 때 통제된 절차로 갱신하는 대상입니다.

레시피 통제 요소별 비교 표

구분	버전 관리	골든 레시피	변경 통제	감사 추적
목적	어느 판이 최신인지 구분	기준이 되는 승인판 확보	승인되지 않은 변경 차단	변경의 근거와 책임 확인
주요 방법	버전 번호, 이전 판 보존, 장비와 호스트 판 비교	검증을 마친 판을 지정하고 장비를 이에 맞춤	요청, 영향 평가, 검증, 승인, 적용 후 확인	변경자와 시각과 사유와 승인자 기록
없을 때의 위험	같은 이름에 다른 내용이 섞임	장비마다 결과가 어긋남	검증 없는 변경이 로트 단위로 번짐	원인을 거슬러 찾을 수 없음
함께 필요한 것	권한 관리	장비 매칭과 정기 점검	변경 후 첫 로트 확인	접근 권한 분리와 기록 보존

핵심 정리

반도체 레시피 관리는 공정 조건의 묶음을 버전으로 구분하고, 기준이 되는 골든 레시피를 정하고, 변경은 통제된 절차로만 허용하고, 모든 이력을 남기는 네 가지로 이루어집니다. 한 줄의 변경이 같은 장비를 거치는 모든 로트에 영향을 주고 결과는 한참 뒤에야 드러나므로, 사전 검증과 변경 직후의 확인이 손실을 줄이는 핵심입니다.

요리 노트를 누구나 고쳐 쓰면 어느 판의 맛이 맞는지 모르게 되듯, 팹에서도 기준 판과 이력이 없으면 수율 변동의 원인을 찾을 수 없습니다. 현업에서 레시피를 다루게 되면 값을 바꾸는 기술보다 바꾸기 전후에 무엇을 확인하는지를 먼저 익히시기 바랍니다.

면접 대비 질문