서론

지난 기사에서 AVX512-IFMA의 전처리로서 「비트가 채워진 52비트 값의 열을 각 64비트 레인의 하위 52비트로 전개하는」 함수 split_52bit를 소개했다. vpermw와 가변 시프트(variable shift)를 조합하여, 레인의 비트 오프셋이 주기 4로 순환하는 성질을 이용한 구현으로, 개인적으로 상당히 마음에 드는 설계다.

문득 궁금해졌다. 이 구현을 지금의 AI에게 과제로 내준다면 작성할 수 있을까?

나름대로 머리를 짜낸 수법이다. 쉽게 재현된다면 조금 분할 것이고, 되지 않는다면 되지 않는 대로 "역시 인간의 차례가 남아있다"며 안심할 수 있다. 어느 쪽이든 재미있을 것이기에 실험해 보기로 했다.

결과를 먼저 말하자면, AI는 단번에 정답을 맞혔다. 다만 나의 해법과는 조금 다른 경로로 말이다. 이 "차이"가 예상외로 흥미로웠기에, 실험 설계부터 결과 분석까지를 기록으로 남긴다.

실험 설계

과제문

AI에게 전달한 프롬프트는 다음과 같다. 나의 구현 트릭(주기성, 사용 명령어)을 암시하는 어휘를 피하고, 입출력 사양만을 전달하도록 설계했다.

AVX-512를 사용한 C 언어(intrinsics) 구현 과제입니다.
【배경】
AVX512-IFMA 명령어로 다배수 정수 연산(multi-precision integer arithmetic)을 수행하기 위해, 입력 데이터를
...

규칙과 공정성에 관한 주석

• 첫 번째 답변을 그대로 채택. 수정 요청은 하지 않는다.
• 출제한 모델은 Claude Sonnet 5와 Claude Opus 4.8 두 모델이다. 각각 새로운 세션에서 진행했으며, 지난 기사나 나의 구현을 보여주지 않았으므로 프롬프트 정보 외에는 제로 베이스에서 구현한다.
• 「말단 패딩(tail padding)에 의한 오버리드(over-read) 허용」과 「출력 버퍼의 정렬(alignment) 보장」에 대해서는 원래 구현에서 시행착오 끝에 결정한 사항이며, AI에게는 정돈된 문제로 제시했다.
• 정오 판정은 지난 기사의 벤치마크 코드에 포함된 비트 단위의 레퍼런스 구현과 대조하여 기계적으로 수행했다.

결과

정확도: 두 모델 모두 단번에 정답

두 모델의 구현을 검증 하네스(verification harness)에 포함시켜, 랜덤 입력 65,536 레인으로 레퍼런스와 비교했다. 모든 레인이 일치했다. 수정 요청은 0회였다.

성능: 차이 0.8% 미만으로 거의 동일

AWS EC2 c6i.large (Ice Lake 세대 Xeon) / gcc 11.5.0 -O2 환경에서, best-of-5 측정을 5회 실행했다.

차이는 최대 1% 미만으로, 실용상으로는 동일하다고 봐도 무방하다. 흥미로운 점은 5회의 시도 모두 순위가 「나의 구현 > Sonnet 5 > Opus 4.8」로 단 한 번도 바뀌지 않았다는 것이다. 차이는 작지만 재현성은 있다. 원인은 단정할 수 없으나, vpermw와 vpermb의 마이크로아키텍처(microarchitecture)상의 미세한 특성 차이, 그리고 상수 로드(constant load) 처리 방식의 차이가 아닐까 추측하고 있다(어디까지나 가설이다).

그리고 본론: AI는 "다른 해법"이었다

나의 구현은 데이터를 16비트 워드(word)의 격자로 본다. 52 × 4 = 208비트가 13워드에 딱 맞게 들어가기 때문에, 레인 내 오프셋이 {0, 4, 8, 12}의 주기 4로 순환한다. 이 성질을 vpermw (AVX512BW)로 공략했다.

AI 두 모델은 모두 데이터를 바이트(byte)의 격자로 보았다. 52 mod 8 = 4 이므로, 바이트 경계로부터의 오프셋은 {0, 4}의 주기 2가 될 뿐이다. 각 값을 포함하는 8바이트 윈도우(window)를 vpermb (AVX512VBMI)로 모은 뒤, 0 또는 4만큼만 시프트한다.

/* AI(두 모델 공통) 접근 방식의 골자 */
static const uint8_t perm_idx[64] = {
0, 1, 2, 3, 4, 5, 6, 7, /* k=0: byte 0부터 */
...

놀라운 것은, 두 모델의 perm 테이블과 시프트 상수가 완전히 일치했다는 점이다. 독립된 세션에서 출제했음에도 불구하고, 양측은 동일한 해답으로 수렴했다. 그리고 둘 다 나의 워드 격자·주기 4 방식에는 도달하지 못했다.

생각해 보면 바이트 격자는 가장 자연스러운 첫 단계다. 비트 위치를 바이트로 나누는 것부터 시작하면 순수하게 주기 2에 도달하게 된다. 게다가 vpermb가 있다면 그것으로 완결된다.

16비트 조작으로 구현을 진행했던 이유는 개발 당시의 제약 때문이었다. 이 구현을 작성한 것은 벌써 10년 전쯤, AVX-512가 막 출시되었을 무렵이다. 당시 수중에 사용할 수 있었던 것은 Skylake-SP 세대까지였고, 개발은 기본적으로 에뮬레이터 상에서 이루어졌다. Skylake-SP는 AVX-512BW까지만 지원하며 vpermb (VBMI)가 존재하지 않는다. 바이트 단위의 permute라는 선택지가 처음부터 사라졌기에, vpermw로 구성할 수 있는 형태를 찾아 워드 격자(word lattice)에서 문제를 재검토했고, 그 과정에서 주기 4의 구조가 떠올랐다.

"10년 전의 구현을 이제 와서?"라고 생각할지도 모른다. 하지만 이번 실험에 있어서 그 오래됨은 오히려 좋은 조건이었다. 현대의 명령어 세트(Instruction Set)를 자유롭게 사용할 수 있는 AI와, 당시의 제약 하에서 태어난 해법을 나란히 배치함으로써, 제약이 해법의 형태를 어떻게 결정하는지를 극명하게 드러낼 수 있었기 때문이다.

참고로 명령어 세트 요구 사항의 차이(BW vs VBMI)는 IFMA 전처리의 맥락에서는 실질적인 의미를 갖지 않는다. IFMA 대응 CPU(Cannon Lake 이후 / Zen 4 이후)는 모두 VBMI도 갖추고 있기 때문이다. BW 버전이 유효한 경우는 IFMA 없이 이 변환만을 오래된 환경(Skylake-SP 등)에서 사용할 때로 한정된다.

부록: 모델 간에 프로세스가 달랐다

결과는 같더라도 두 모델의 행동에는 차이가 있었다. Sonnet 5는 구현과 설계 해설을 제시하고 끝냈다. 반면 Opus 4.8은 직접 컴파일을 통과시키고, 로직을 스칼라(scalar)로 재현하여 랜덤 테스트를 2,000회 돌린 뒤에 제출해 왔다. 후자의 자기 검증(self-verification)은 나의 하네스(harness)를 통해서도 확인되었기에 진짜였다. 정답이라는 결과뿐만 아니라, 검증 태도에서도 개성이 나타난다는 점은 흥미로운 관찰이었다.

이 실험에서 인간에게 남은 작업은 무엇이었나

실험을 마치고 정리해 보면, 이번에 내가 한 일은 다음과 같다.

• 문제를 사양(specification)으로 정의한다 (이때 트릭을 누락하지 않는다)
• 정확성을 기계적으로 판정하는 레퍼런스(reference)와 하네스(harness)를 준비한다
• 성능을 동일한 조건에서 측정하는 환경을 구축한다
• 도출된 해법을 격자의 관점에서 분석한다

구현 그 자체는 이제 더 이상 희귀한 일이 아닐지도 모른다. 하지만 "무엇을 만들지 결정하고, 정확성을 보장하며, 결과를 해석하는" 부분은 이번에 모두 인간의 몫이었다.

마치며

직접 만든 비장의 카드를 AI에게 출제하는 것은 솔직히 조금 무서웠다. 결과는 "단번에 정답, 하지만 별개의 해법". 분함과 안도감이 반반 섞인, 예상보다 깊은 맛이 나는 착지였다.

이번에 시도한 것은 Anthropic의 두 모델뿐이기에, 다른 모델들이 어떤 격자로 향할지는 알지 못한다. 모든 모델이 바이트 격자로 수렴할 것인지, 아니면 어딘가에서 주기 4를 찾아내는 모델이 있을 것인지. 검증 하네스는 지난번과 마찬가지로 GitHub에 올려두었으니, 혹시 괜찮으시다면 가지고 계신 모델로 테스트한 결과 등을 알려주시면 감사하겠습니다.

리포지토리

(compare_split3.c가 본 기사의 비교 하네스입니다. 3가지 구현의 검증과 측정이 한 번의 명령어로 실행됩니다.)

Discussion