Aikido Altar는 왜 ‘데이터를 밖으로 내보내지 않는 보안 AI’를 만들겠다고 하나요?

요약 보기

이 글에서 Aikido Labs가 내세우는 핵심은 단순히 ‘보안용 LLM 하나를 공개했다’가 아니에요. Altar는 고객사가 통제하는 인프라 안에서 돌아가는 보안 모델로 소개되고, 특히 Aikido Machine이라는 자사 침투테스트 장비 안에서 민감한 코드와 내부 문맥을 외부 추론 서비스로 보내지 않고도 방어적 보안 업무를 하게 만드는 것이 목표예요. 글쓴이들은 이걸 ‘sovereign security intelligence’라고 부르는데, 쉽게 말하면 보안을 맡은 조직이 자기 환경 안에서만 보안 AI를 굴릴 수 있어야 한다는 생각이에요. 인터넷과 분리된 환경이나, 코드 반출 규정이 엄격한 조직을 염두에 둔 주장으로 읽으면 이해가 쉬워요.

여기서 배경이 되는 문제는 ‘성능 좋은 최전선 모델’과 ‘내 환경 안에 둘 수 있는 모델’이 자주 같은 것이 아니라는 점이에요. 글에 따르면 닫힌 형태의 최전선 모델은 대개 다른 누군가의 인프라에서 실행돼요. 그러면 소스코드, 내부 아키텍처 문서, 아직 고치지 못한 취약점 정보가 조직의 네트워크 밖으로 나가게 되죠. 어떤 회사는 그걸 감수할 수 있겠지만, 은행처럼 데이터 거주성 규정이 있거나 병원처럼 처리 규제가 엄격한 곳, 또는 아예 인터넷 경로가 없는 운영 환경은 그런 선택 자체가 허용되지 않을 수 있다는 게 저자들의 문제의식이에요. 그래서 이 글의 질문은 ‘더 좋은 모델이 있느냐’보다 ‘그 모델을 실제 규정과 인프라 안에서 돌릴 수 있느냐’에 더 가까워요.

왜 이런 배치 격차가 생기느냐를 이해하려면 모델 구조를 조금 봐야 해요. 글은 GLM-5.3 같은 큰 모델이 엄청난 메모리를 요구한다고 말해요. 특히 mixture-of-experts 구조에서는 ‘전문가’ 역할을 하는 작은 신경망들이 많이 들어 있는데, 토큰 하나를 처리할 때는 그중 일부만 실제로 쓰여도 전체 전문가 묶음은 메모리에 올려 두어야 해요. 보안 업무는 그중 일부 능력만 주로 쓰는데도 전체 모델을 통째로 떠받쳐야 한다는 뜻이죠. 여기에 에이전트 방식까지 붙으면 상황이 더 빡빡해져요. 에이전트는 자신이 본 것과 한 일을 길게 문맥으로 들고 다니는데, 그 문맥도 같은 GPU 메모리를 차지하거든요. 비유하자면, 이 글의 설명은 커다란 공구 창고를 싣고 다니는 작업차와 비슷해요. 실제 현장에서 매번 쓰는 공구는 일부인데 창고 전체가 트렁크를 차지하면, 정작 작업 중 생기는 메모나 재료를 실을 공간이 줄어드는 셈이에요. 그래서 저자들은 모델 자체를 줄여서, 보안 조사 과정에서 함께 늘어나는 문맥과 도구 사용을 위한 여유를 확보하려는 거예요.

Altar를 만드는 직접적인 방법은 양자화와 가지치기였어요. 출발점은 GLM-5.3이고, 원래 모델 크기는 1.51TB라고 해요. 먼저 양자화는 가중치를 더 적은 비트로 저장해서 공간을 줄이는 방식이에요. 글에서는 BF16의 16비트 가중치를 주로 4비트로 저장하는 AWQ 방식을 썼다고 설명해요. 이건 전문가를 없애는 게 아니라 숫자를 더 압축해서 적는 쪽에 가깝죠. 그다음 가지치기는 전문가 일부를 실제로 제거하는 단계예요. 다만 어려운 점은 ‘무엇을 버려도 되는가’예요. 잘못 자르면 코드는 잘 보는데 특정 언어 문서를 이해하지 못하는 식의 불균형이 생길 수 있다고 저자들은 경고해요. 그러니까 이 글의 주장은 단순히 작게 만들었다가 아니라, 보안 업무에 필요한 추론 품질을 최대한 보존하는 방향으로 줄였다는 데 있어요.

그럼 어떤 전문가를 남겼느냐가 핵심이 되는데, 여기서 저자들이 꽤 강조하는 부분이 있어요. 고객 데이터를 넣어 학습한 것이 아니라, 자사 침투테스트 하네스가 내부 벤치마크를 수행할 때 남긴 실행 흔적을 이용해 어떤 입력이 실제 보안 업무를 대표하는지 잡았다고 해요. 코드, 도구 호출, 에이전트 응답 같은 흐름을 바탕으로 전문가 선택을 보정했다는 뜻이죠. 하지만 기술 입력만 보면 언어 이해가 무너질 수 있으니, 프랑스어·네덜란드어 같은 다국어 텍스트도 추가했다고 설명해요. 또 단순히 ‘자주 호출된 전문가’를 남기는 게 아니라, REAP라는 기법으로 라우터의 가중치와 전문가 출력 크기를 함께 보고 기여도를 계산했다고 해요. 이 대목이 중요한 이유는 사이버보안, 코딩, 언어 능력이 깔끔하게 따로 떨어진 전문가 세트로 존재하지 않는다고 저자들이 보기 때문이에요. 즉, 크기만 줄인다고 되는 게 아니라 어떤 능력이 어떤 예제 묶음에서 유지되는지까지 봐야 한다는 주장입니다.

그 결과 수치상으로는 꽤 큰 축소가 나왔어요. 글에 따르면 Altar는 각 backbone expert layer에서 원래 256개 routed experts 중 168개를 남기고 88개를 제거했어요. 저장 크기는 풀 정밀도 GLM-5.3의 1,506.7GB에서 Altar의 328.0GB로 줄었고, 이미 AWQ로 양자화한 488.2GB 기준으로도 추가로 160GB가 감소했다고 해요. 저자들은 이걸 단순 저장 절약보다 운영 효율의 문제로 보고 있어요. 모델이 차지하는 몫이 줄어야 긴 문맥, 여러 병렬 조사, 도구 호출 같은 주변 작업에 메모리를 더 쓸 수 있기 때문이죠. 배포 면에서는 Altar 가중치를 공개했고, 4개의 H200 GPU가 있는 노드와 vLLM으로 무난하게 서빙할 수 있다고 안내해요. 다만 이건 글쓴이 측의 배포 가이드이지, 모든 환경에서 똑같이 쉽다는 보장은 아니에요.

성능 평가는 ‘얼마나 작아졌나’보다 ‘보안 능력을 얼마나 유지했나’를 보려는 방식이에요. 글에 따르면 내부 CVE 벤치마크는 30개 저장소에 걸친 알려진 취약점 32개를 대상으로, 각 사례를 세 번씩 실행해 취약점 재발견 능력을 봤어요. Altar는 실행당 평균 재현율 60.4%, 세 번 중 한 번 이상 다시 찾은 취약점은 32개 중 23개였다고 해요. 비교군인 양자화된 GLM-5.3 AWQ는 평균 재현율 61.5%로 약 1%포인트 높았지만 커버한 취약점 수는 똑같이 23개였고, 원래 풀 정밀도 GLM-5.3은 평균 65.6%, 25개를 커버했다고 제시돼요. 그래서 저자들은 488GB에서 328GB로 더 줄이면서도 AWQ 기준 취약점 커버리지는 유지했고, 원본 부모 모델이 커버한 취약점의 92%를 남겼다고 해석해요. 이 숫자는 ‘같은 취약점을 한 번이라도 찾았는가’와 ‘매번 안정적으로 찾는가’를 구분해서 봐야 한다는 점도 함께 읽어야 해요.

다만 이 평가를 넓게 과장해 읽으면 안 돼요. 저자들 스스로 이 벤치마크는 특정 CVE를 목표로 다시 찾아내는 능력을 재는 것이지, 전체 코드베이스에서 아무 단서 없이 새로운 취약점을 맹목적으로 찾는 성능을 뜻하지는 않는다고 선을 그어요. 또 취약점을 실제 익스플로잇해 검증하는 단계나, 수정안을 제안하는 단계까지 측정한 것도 아니라고 해요. 게다가 이 파이프라인의 주변 단계에는 다른 모델들도 쓰인다고 밝히고 있어서, 여기서 나온 수치를 Altar 단독의 종합 보안 능력으로 읽기는 어려워요. 배포 직후 고객 운영 환경의 침투테스트에서 치명적 취약점 하나를 찾아냈다는 일화도 나오지만, 그건 현장 사례 하나이지 체계적 성능 증명과는 구분해야 해요. 이후 계획으로는 더 낮은 비트 형식, 서빙 최적화, 보안 워크플로용 파인튜닝, 장기 추론과 도구 사용 강화, 자가학습 파이프라인 등을 탐색하겠다고 하는데, 이 역시 앞으로의 연구 방향을 말한 것이지 이미 입증된 결과는 아니에요.