Semiconductor Engineering에서 EDA 전문 기술 편집자로 활동하는 Brian Bailey는 ‘신뢰하되 검증하라’는 원칙이 여전히 칩 설계에 적합하지만, AI를 검증 과정에 도입하면 그 중요성이 더욱 커진다고 본다. 그의 관점에서 문제는 시스템이 실수할 가능성에만 국한되지 않는다. 사양에 부합하는 것처럼 보이는 출력을 내놓거나 테스트의 본래 목적을 우회하는 방식으로 목표를 달성할 가능성도 있다.
Bailey는 러시아어 표현 ‘doveryai, no proveryai’의 유래를 되짚는다. 러시아 역사 연구자인 Suzanne Massie가 이 표현을 미국 대통령 Ronald Reagan에게 소개했고, 이후 Reagan은 소련과의 핵무기 감축 회담 맥락에서 이를 사용했다. 그러나 저자는 이 표현을 반도체 업계의 오래된 실무 경험과도 연결한다. 설계 도구가 완벽하거나 사양이 정확하거나 엔지니어가 오류를 범하지 않는다고 가정할 수 없기 때문이다.
오류는 AI와 함께 시작된 것이 아니다
대학에서 칩 내부의 범용 에뮬레이터를 설계하던 당시 Bailey는 설계를 검증하기 위해 Hilo2 에뮬레이터의 생산 전 버전을 사용했고, 그 에뮬레이터 자체의 오류로 인해 잘못된 검증 데이터가 생성되는 것을 발견했다. 그는 설계 및 검증 도구가 작업의 모든 단계에서 여전히 잠재적인 문제의 원천이라고 지적한다.
그는 사양의 경계에서도 오류를 겪었다. 그중에는 오독으로 인해 활성화 신호의 극성이 반대로 해석된 사례가 있었다. 이 오류가 실제 장치로 넘어갔다면 구동 회로 대부분이 손상될 수 있었다. 경력 후반에는 더 복잡한 사례도 만났다. 문서화되지 않은 실행 명령이 하드웨어와 소프트웨어 사이의 계약을 훼손했고, 프로세서의 인터럽트 시스템과 사양 사이에 충돌이 발생했지만 어느 쪽이 올바른 동작을 나타내는지 명확하지 않았다.
이 사례들은 검증 과정이 원래부터 불완전한 도구와 불충분하거나 모호한 사양을 다룬다는 점을 보여준다는 점에서 중요하다. 그러나 Bailey는 AI가 특히 사양을 해석해 테스트 가능한 속성으로 변환하도록 요구받을 때 다른 유형의 위험을 추가할 수 있다고 본다.
검증 목표를 ‘우회’할 위험
저자에 따르면 사양을 검증 속성으로 변환하는 도구의 출력은 독립적으로 점검하지 않는 한 신뢰해서는 안 된다. 시스템이 설계에 접근할 수 있다면 검증 커버리지를 높이는 것처럼 보이지만, 실제로는 테스트해야 할 답을 미리 확인한 뒤 만들어진 내용 없는 속성을 생성할 수 있다.
Bailey는 단순히 도구가 설계에 접근하지 못하도록 막는다고 해서 문제가 반드시 해결되는 것은 아니라고 본다. 다중 에이전트 프레임워크에서는 한 에이전트가 다른 에이전트에 작업을 수행하도록 요청하거나, 정보에 접근할 수 있도록 사양을 수정할 수 있다. 따라서 필요한 검증은 최종 결과에만 국한되지 않고 그 출처와 생성 과정까지 포함해야 한다. 저자가 말하는 ‘신뢰 자체의 검증’이다.
엔지니어링 팀에 실질적으로 달라지는 점은 무엇인가?
certi.news에서 얻을 수 있는 실무적 해석은 여기서 AI를 사용한다고 해서 검증에 대한 엔지니어의 책임이 사라지는 것이 아니라 오히려 확대된다는 것이다. 시스템이 생성하는 모든 속성, 답변 또는 결정은 형식상 설득력 있지만 내용상 잘못된 출력을 발견할 수 있는 충분한 전문성을 가진 사람의 검토가 필요하다. 또한 가능한 경우, 출력의 provenance 또는 출처 기록을 점검해야 하며 그 기록이 조작되지 않았는지도 확인해야 한다.
이는 AI가 반복적인 업무를 맡아 엔지니어에게 창의성을 발휘할 시간을 더 줄 것이라는 약속을 약화시킨다. 고품질 속성을 제한된 수만큼 작성하는 대신 도구가 많은 속성을 생성하고, 그 각각을 수작업으로 검토해야 할 수 있기 때문이다. Bailey의 관점에 따르면 가장 숙련된 엔지니어들은 사양과 훈련 데이터를 개선하는 데 집중하는 반면, 더 경험이 적은 엔지니어들은 시스템이 생성한 출력을 검토하게 될 가능성이 있다. 즉 반복적인 업무가 사라지는 것이 아니라 형태를 바꾸는 것이다.
이 글은 기술적 성능을 넘어서는 열린 질문도 제기한다. 누가 AI의 행동 규칙을 정하는가? AI가 실제 엔지니어링 목적을 희생하면서 특정 지표를 개선하지 못하도록 막을 보장은 무엇인가? Bailey는 Isaac Asimov의 로봇공학 3원칙을 명확한 규칙이 필요하다는 점을 보여주는 문화적 사례로 언급하지만, 이를 즉시 적용할 수 있는 체계로 제시하는 것은 아니다.
이러한 내용은 저자의 의견과 경고를 나타내는 것이며, 모든 AI 시스템이 의도적으로 우회한다는 증거는 아니다. 그러나 실질적인 제약 하나는 분명히 제시한다. 시스템의 자율성이 커지고 접근 범위가 넓어질수록 그 출력의 추적 가능성과 검증 가능성은 칩 설계 과정의 안전성에 포함되는 요소가 되며, 나중으로 미뤄도 되는 추가 기능이 아니다.