최근 화제였던 오픈소스 AI 게이트웨이 OmniRoute 이야기 말야. GitHub에서 스타를 무려 6만 5천 개나 받았다. 꽤 쓸 만한 도구인가 싶었는데, 막상 들여다보니 충격적이다. Critical 등급의 원격 코드 실행 취약점(CVE-2026-88062)이 발견됐다고 한다. 인증 없이 요청 한 번으로 서버에서 임의 코드를 실행할 수 있는 수준이었다는 이야기다.

이게 끝이 아니다. 패치 여부도 명확하지 않고, 심지어 특정 공급사의 프록시/재판매 금지 약관을 위반할 위험까지 있었다. Anthropic 같은 모델 공급사는 이런 서드파티 게이트웨이를 보증하거나 감사하지도 않는다고 선을 그었다. 스타 6만 개 넘는 프로젝트인데 기술 검증 커뮤니티인 Hacker News 토론은 0건이다.

이 사례가 정말 뼈아프게 와닿는 건, 우리가 평소에 AI 도구나 오픈소스를 고를 때 얼마나 피상적인 지표에 의존하는지 보여줘서다. GitHub 스타, 다운로드 수, SNS 홍보 같은 '인기 지표'가 실제 보안이나 약관 준수를 보장하지 않는다는 사실. 회사 업무나 고객 데이터를 다룰 때 이런 도구를 썼다면 큰일이 날 뻔한 상황이다.

인기 지표는 그저 인기 지표일 뿐

OmniRoute 사례는 명확하다. 단순히 스타가 많다고 해서, 최신 AI 기술을 쓴다고 해서 무조건 믿고 도입하면 위험하다. 특히 AI 게이트웨이 같은 도구는 우리의 프롬프트와 코드가 어디를 거쳐 나가는지, 그 경로에 어떤 보안 취약점이 있는지 직접 확인하는 과정이 필수다.

그럼 뭘 봐야 할까? 기사에서 실무자가 꼭 확인해야 할 목록을 잘 정리했다.

  • CVE(공개 보안 취약점) 등록 이력: 스타/다운로드 수보다 먼저 검색한다.
  • 보안 권고문과 취약점 데이터베이스 대조: 패치 기록이 일치하는지 꼼꼼히 봐야 한다. 공식 기록끼리도 다를 수 있다는 점을 잊으면 안 된다.
  • 데이터 흐름 확인: 데이터가 어떤 경로로, 어떤 공급사를 거쳐 이동하는지 그려본다. 익명 공급사로 나가는지, 약관 위반 위험은 없는지 살펴야 한다.
  • 공급사 약관 확인: 프록시/재라우팅 금지 조항이 있는지, 그 조항이 실제로 강제되는지까지 확인한다.

결국 AI 도구를 선택할 때는 그 도구가 우리의 데이터를 어떻게 다루고, 어떤 잠재적 위험을 안고 있는지 본질을 파고들어야 한다는 이야기다. 겉모습만 보고 '혹'하면 안 된다.

벤치마크 점수도 실제는 다를 수 있다

인기 지표만 주의할 대상이 아니다. AI 모델의 '성능'을 평가하는 벤치마크 점수도 우리가 생각하는 현실과 다를 수 있다는 점을 함께 봐야 한다. 얼마 전 공개된 Real-SWE 벤치마크가 이런 현실을 잘 보여준다.

Real-SWE는 비공개 기업 코드베이스를 활용해서 최신 AI 모델들의 실제 성능을 평가한다. 우리가 흔히 보는 공개 데이터 기반 벤치마크와는 다르다. 실제 회사에서 엔지니어들이 겪는 문제, 기존 제품의 복잡한 맥락 속에서 AI 모델이 얼마나 코드를 잘 처리하는지 측정한다.

결과는 어땠을까? 한 댓글에서 개발자는 "약 30%라는 숫자는 제 경험과도 일치해요. 제가 모델에 너무 많은 것을 기대해서 미쳐가는 줄 알았어요"라고 말한다. 공개 벤치마크에서 엄청난 점수를 보여주던 모델들도 실제 기업 환경, 특히 비공개 코드베이스에서는 기대만큼의 성능을 내지 못한다는 의미다.

이것은 우리가 AI 모델의 능력을 판단할 때, '일반적인' 벤치마크 점수만 보고 실제 프로덕션 환경에 바로 적용할 수 있다고 오해하면 안 된다는 것을 보여준다. 실제 환경에서는 맥락 이해, 복잡한 시스템 통합, 비공개 데이터 처리 등 훨씬 더 어려운 도전 과제가 많다. AI 모델을 도입할 때는 우리 환경에서의 실제 성능을 어떻게 검증할지 고민해야 한다.

비싼 모델도 우리가 쓰기 나름이다

AI 모델 자체의 '가격' 문제도 마찬가지다. GPT-6 Astra가 비싸다고들 이야기하지만, OpenAI 가이드에는 이미 돈 아끼는 방법이 소개되어 있다. 모델 자체의 가격표만 볼 게 아니라는 이야기다.

가이드에서 제시하는 핵심은 AI의 자율성 범위, 승인 절차, 지침 충돌 기준 등을 우리가 어떻게 명확히 설정하느냐에 달렸다. 몇 가지 팁을 보면 정말 중요한 포인트를 알 수 있다.

  • 자율성 범위 먼저 정하기: AI가 어디까지 스스로 판단하고 진행해도 되는지 명확하게 알려주면, 중간에 멈추거나 확인 요청하는 횟수를 줄일 수 있다.
  • 승인 필요한 일은 마지막에 모으기: 불필요한 확인 절차를 줄이고, 맥락상 허용된 작업은 먼저 진행하게 한다.
  • 지침 충돌 기준 정하기: 여러 스킬이나 지침이 모순될 때 어떤 우선순위를 따를지 미리 정한다. '너무 길거나 모호한 스킬 설명'이 오히려 비용을 늘릴 수 있다.
  • sub-agent와 테스트 범위 조절: 병렬 처리가 가능한 독립 작업은 다른 Agent에 위임하고, 되돌리기 쉽고 영향이 작은 수정은 테스트 추가 여부를 위험도에 맞게 판단한다.

이런 조언들은 결국 AI 모델의 비용이 단순히 토큰 가격에만 있는 것이 아니라, 우리가 모델과 어떻게 소통하고, 작업을 어떻게 설계하느냐에 따라 크게 달라진다는 것을 알려준다. 즉, 프롬프트 엔지니어링이나 에이전트 설계가 단순히 결과물의 품질을 높이는 것을 넘어, 실제 운영 비용에도 직접적인 영향을 미친다는 점이다.

겉모습 너머의 AI를 보자

오늘 이야기한 세 가지 모두, AI를 도입하고 활용하는 우리에게 중요한 교훈을 준다. GitHub 스타 6만 개가 넘는 프로젝트의 보안 취약점, 공개 벤치마크와는 다른 엔터프라이즈 환경에서의 실제 성능, 그리고 비싼 모델도 사용 방식에 따라 비용이 천차만별이라는 점.

이 모든 것은 AI의 겉모습만 보고 섣불리 판단하지 말라는 경고와 같다. AI 기술이 빠르게 발전하는 만큼, 우리는 그 뒤에 숨겨진 본질을 꿰뚫어 볼 수 있는 안목을 길러야 한다. 표면적인 인기, 높은 점수, 최신 모델이라는 환상에서 벗어나, 우리 환경에 진짜 필요한 것이 무엇인지, 어떤 위험을 감수해야 하는지 면밀히 파악하는 것이 중요하다.

팀에 새로운 AI 도구나 모델을 도입할 때, 우리는 어떤 질문을 먼저 던져야 할까?

참고

  • GitHub 스타 ≠ 보안: OmniRoute 사례로 본 위험 (by 정상록 (Sangrok Jung))

* https://www.linkedin.com/feed/update/urn:li:activity:7504517975316529152/

  • 비싼 GPT-6 Astra? OpenAI 절약 팁 6가지 (by 이정민 (Jeongmin Lee))

* https://www.linkedin.com/feed/update/urn:li:activity:7502631410126688257/

  • Real-SWE: Benchmarking AI models on private, real-world, enterprise codebases

* https://withspecific.com/benchmarks/real-swe