Frozen design variables in simulation-based optimization: the cost of an unlocated threshold event

공학 설계의 세계에서 컴퓨터는 가상의 풍동 실험실이자 사격장이 되어, 과학자들이 단 하나의 물리적 부품도 실제로 제작하지 않고도 수천 가지의 기계 변형 모델을 테스트할 수 있게 해줍니다. 로켓 엔진이나 총신(gun barrel)과 같은 설계의 최적 버전을 찾기 위해, 엔지니어들은 '그레이디언트(gradient)'라고 불리는 수학적 도구에 의존합니다. 그레이디언트를 최선의 결과를 향해 가리키는 나침반이라고 생각해보십시오. 그것은 컴퓨터에게 총신의 길이 혹은 장약의 무게와 같은 설계 변수를 어떻게 조정해야 결과가 더 좋아질지를 알려줍니다. 만약 나침반이 위를 가리키면 컴퓨터는 변수를 더 크게 만들고, 아래를 가리키면 더 작게 만듭니다. 이 과정은 현대 최적화의 핵심 동력이며, 연료 효율이 높은 자동차부터 더 안전한 항공기에 이르기까지 모든 것을 움직이고 있습니다. 그러나 이 방법은 전적으로 그 나침반의 정확도에 달려 있습니다. 만약 나침반이 고장 난다면, 컴퓨터는 훨씬 더 나은 해결책을 놓친 채 엉뚱한 곳에서 맴돌거나, 이미 최적의 해를 찾았다고 확신하며 움직임을 멈춰버릴 것입니다.

칠레의 폰티피시아 카톨리카 데 발파라이소 대학교(Pontificia Universidad Católica de Valparaíso) 연구진은 가상 시뮬레이션이 특정 유형의 이벤트를 처리하는 방식에서 미묘하지만 치명적인 결함을 발견했습니다. 그들은 컴퓨터가 프로세스가 종료되는 정밀한 순간(예: 투사체가 총신 끝을 빠져나가는 순간)을 시뮬레이션할 때, 그 마지막 순간을 기록하는 방식에서 거의 눈에 띄지 않는 아주 작은 오류를 범한다는 사실을 발견했습니다. 이 오류는 시뮬레이션의 최종 결과에는 눈에 띄는 변화를 주지 않습니다. 즉, 투사체의 속도는 거의 정확하게 산출됩니다. 하지만 이 오류는 나침반을 완전히 망가뜨려 놓습니다. 컴퓨터는 총신의 길이를 바꾸는 것이 투사체의 속도에 아무런 영향을 미치지 않는다고 계산하는데, 이는 물리적으로 불가능한 결론입니다. 컴퓨터는 총신의 길이가 중요하지 않다고 믿기 때문에 조정을 멈추게 되고, 결국 최적의 지점에 도달하지 못한 채 설계가 정체되도록 만듭니다.

연구진은 탄도 내부의 역학(interior ballistics)을 설명하는 표준 모델을 사용하여 이 문제를 조사했습니다. 이 모델은 총이 탄환을 어떻게 추진하는지를 설명합니다. 시뮬레이션 내에서 컴퓨터는 아주 짧은 시간 간격으로 단계를 밟아가며 각 단계에서의 투사체의 위치와 속도를 계산합니다. 투사체가 총신의 전체 길이를 통과하는 순간, 시뮬레이션은 멈추고 최종 속도를 기록합니다. 가장 자연스럽고 단순한 방식은 투사체가 총신을 지나간 직후의 첫 번째 시간 단계(time step)를 확인하여 그 순간의 속도를 기록하는 것입니다. 문제는 이 방식이 "계단 현상(staircase effect)"을 만든다는 점입니다. 만약 총신의 길이를 아주 미세하게 변경하더라도, 투사체가 여전히 동일한 시간 단계 내에 기록될 수 있으며, 이 경우 기록된 속도는 전혀 변하지 않습니다. 속도가 길이에 따라 변하지 않기 때문에, 컴퓨터는 길이에 따른 민감도(sensitivity), 즉 속도가 변화하는 비율을 정확히 '0'이라고 계산하게 됩니다.

이 '0'이라는 수치는 단순한 실수가 아니라 나침반의 완전한 실패입니다. 연구진은 시뮬레이션을 16배나 더 정밀하게 개선했음에도 불구하고 이 오류가 지속된다는 것을 증명했습니다. 즉, 시간 단계를 극도로 작게 줄여 시뮬레이션을 정교화하더라도 최종 속도 값은 더 정확해졌지만, 민감도는 여전히 완강하게 0에 머물러 있었습니다. 이는 컴퓨터가 엉뚱한 곳을 보고 있기 때문입니다. 즉, 사건이 일어난 정확한 시점의 속도를 읽는 것이 아니라, 고정된 시간에서의 속도를 읽고 있는 것입니다. 연구진은 이 결함이 특정 코드나 특정 종류의 총기에만 국한된 문제가 아님을 입로 증명했습니다. 그들은 다양한 수학적 방법을 사용하여 테스트했으며, 컴퓨터가 사건 발생 직후의 첫 번째 단계에서 결과를 읽는 한, 사건이 일어난 정확한 지점을 보간(interpolation)하여 찾지 않는 이상 민감도는 항상 0이 된다는 것을 발견했습니다.

이 결함의 결과는 측정 가능하며 상당합니다. 통제된 실험에서 연구진은 표준 최적화 알고리즘에게 총 내부의 최대 압력 제한을 준수하면서 최적의 총신 길이를 찾도록 요청했습니다. 알고의 알고리즘이 결함이 있는 '제로 민감도' 데이터를 사용했을 때, 총신의 길이는 시작 값에서 전혀 움직이지 않았습니다. 마치 변수가 그 자리에 얼어붙은 것과 같았습니다. 연구진이 해당 변수를 수동으로 해제하고 올바른 최적의 길이로 이동시켰을 때, 총구 속도(muzzle velocity)는 4.19%에서 6.91% 사이로 증가했습니다. 이 개선은 압력의 증가 없이 이루어졌으므로, 설계 측면에서 엄격하게 더 나은 결과였습니다. 그럼에도 불구하고 최적화 과정은 이를 완전히 놓쳤습니다. 컴퓨터는 훨씬 더 나은 해답이 바로 옆에 있음에도 불구하고, 최적의 해를 찾았다고 믿으며 탐색을 종료해 버린 것입니다.

연구진은 또한 이 문제가 총신의 끝에만 국한되지 않는다는 것을 발견했습니다. 그들은 투사체가 움직이기 시작하는 발사 초기 단계에서도 유사한 문제를 발견했습니다. 만약 시뮬레이션이 압력이 탄환을 움직일 만큼 충분히 높아지는 순간을 정밀하게 찾아내지 못한다면, 속도에 대한 장약량의 민감도는 매우 부정확해지며, 시뮬레이션을 더 정밀하게 만들어도 약 50%의 오차가 개선되지 않고 그대로 남게 됩니다. 이는 이 문제가 단순히 무작위적인 글리치가 아니라, 이러한 시뮬레이션이 구축되는 방식 자체의 구조적 특징임을 확인시켜 줍니다. 이 오류는 서로 다른 시뮬레이션의 최종 결과를 비교하는 표준적인 검사로는 포착할 수 없습니다. 왜냐하면 최종 속도 값 자체는 거의 동일하기 때문입니다. 이 오류를 잡아낼 수 있는 유일한 방법은 설계를 미세하게 조정했을 때 결과가 어떻게 변하는지를 관찰하는 것뿐입니다.

이를 해결하기 위해 연구진은 엔지니어들이 자신의 시뮬레이션 코드에 직접 실행해 볼 수 있는 간단한 9단계 감사(audit) 절차를 제안했습니다. 이 과정은 코드 내에서 임계값(threshold)에 근거하여 결정이 내려지는 모든 순간(예: "투사체가 총신을 떠났는가?" 또는 "압력이 한계치를 초과했는가?")을 목록화하는 것으로 시작합니다. 각 순간에 대해, 코드가 단순히 사건 발생 후의 첫 번째 데이터 포인트를 가져오는 것이 아니라, 정확한 교차 지점(crossing point)을 계산하는지 확인해야 합니다. 만약 코드가 "첫 번째 포인트" 방식을 사용하고 있다면, 이는 결함으로 분류됩니다. 해결책은 간단합니다. 코드는 사건을 둘과 세 번째 시간 단계 사이에서 보간(interpolate)하여 정확한 교차 시점을 찾아내야 합니다. 이렇게 하면 민감도 계산이 울퉁불퉁한 계단 형태가 아닌, 매끄럽고 연속적인 변화를 바탕으로 이루어질 수 있습니다.

이 연구는 시뮬레이션 소프트웨어의 검증 방식에 존재하는 중대한 공백을 조명합니다. 엔지니어들은 시뮬레이션이 실제 데이터와 일치하는지, 혹은 수치가 변하지 않을 때까지 시간 단계를 정밀하게 줄였는지 등을 확인하여 시뮬레이션이 올바른 숫자를 생성하는지 일상적으로 검토합니다. 그러나 본 논문은 그러한 검사들이 최적화를 위해서는 불충분하다는 점을 보여줍니다. 시뮬레이션은 올바른 최종 속도를 산출할 수는 있지만, 그 속도를 개선하기 위한 지도(map)는 완전히 잘못된 것을 제공할 수 있습니다. 연구진은 이것이 물리 법칙이나 수학의 실패가 아니라, 연속적인 물리 세계와 이를 시뮬레이션하기 위해 사용되는 이산적인(discrete) 디지털 단계 사이의 인터페이스에서 발생하는 실패라고 강조합니다. 이러한 유형의 오류를 식별하고 수정함으로써, 엔지니어들은 이전에는 보이지 않았던 성능 향상을 실현할 수 있으며, 자신들의 가상 설계가 최대한 견고하고 효율적이 되도록 보장할 수 있습니다.

이 연구 결과는 시뮬레이션이 구성되는 방식에 특화된 것이며, 기초가 되는 물리 모델 자체가 틀렸음을 의미하는 것은 아닙니다. 연구진은 코드를 검증하는 것(코드가 수학적으로 의도한 대로 작동하는지 확인하는 것)과 모델을 타당성 검토(validation)하는 것(모델이 실제 현실과 일치하는지 확인하는 것) 사이의 차이를 명확히 구분했습니다. 그들의 작업은 검증(verification) 연구로서, 소프트웨어가 보고하는 민감도 계수가 잘못된 대상의 도함수(derivative)임을 입증한 것입니다. 그들은 결론에 도달하기 위해 실제 발사 데이터를 사용하지 않았으며, 대신 고정밀 수학적 비교와 내부 일관성 검사를 활용했습니다. 이러한 접근 방식은 실험적 불확실성과 독립적으로, 코드 자체 내에서 오류의 정확한 원인을 찾아낼 수 있게 해주었습니다.

궁극적으로 이 연구는 첨단 컴퓨팅 시대에 우리가 사용하는 도구들 역시 설계물만큼이나 엄격한 검증을 거쳐야 한다는 점을 상기시켜 줍니다. 아무 곳도 가리키지 못하는 나침반은 잘못된 방향을 가리키는 나침반만큼이나 위험합니다. 높은 이해관계가 걸린 공학의 세계에서 6%의 성능 향상을 놓치는 것은 성공적인 임무와 실패 사이의 차이를 만들 수 있습니다. 해결책은 이 강력한 시뮬레이션 도구들을 포기하는 것이 아니라, 우리가 사용하는 디지털 지도가 실제 지형만큼 정확하도록 검증 방식을 정교화하는 것입니다.