야, 이거 봤어? 최근에 GitHub에서 6만 5천 개가 넘는 스타를 받은 오픈소스 AI 게이트웨이 'OmniRoute' 이야기 말이야. 숫자만 보면 대박이고, 다들 검증된 도구라 생각할 만해. 그런데 이면에 심각한 문제들이 숨어있었어.
실제로는 CRITICAL 등급의 원격 코드 실행 취약점이 발견됐고, 심지어 공급사 약관 위반 위험까지 떠안을 수 있는 구조더라. 스타 숫자만 믿고 도입했다가는 회사 데이터랑 고객 정보까지 위험에 빠뜨릴 뻔한 거지.
이거 보면서 몇몇 생각이 들더라고. 우리가 AI 도구든 뭐든, 뭔가 새로운 기술을 도입할 때 겉으로 보이는 '숫자'에 너무 쉽게 현혹되는 건 아닐까? 인기, 벤치마크 점수, 비용 절감 같은 매력적인 숫자 뒤에 숨겨진 진짜 리스크와 실체는 우리가 얼마나 꼼꼼하게 들여다보고 있는지 말이야.
스타 숫자보다 중요한 것: 누가 책임질까?
OmniRoute 사례를 좀 더 자세히 파고들어 볼 필요가 있어. 이 도구는 여러 AI 모델을 하나의 창구로 연결해서, 구독 한도가 끝나면 API 키로, 그것도 막히면 무료 요금제로 자동 전환해서 작업이 끊기지 않게 해준다고 해. 듣기만 해도 혹하지. 무료 티어를 계속 쓸 수 있다니.
그런데 중요한 건, `CVE-2026-88062`라는 CVSS 4.0 기준 9.5점짜리 CRITICAL 등급 원격 코드 실행 취약점이 등록됐다는 점이야. 인증 없이 요청 한 번으로 서버 안에서 임의 코드를 실행할 수 있는 구조라니, 아찔하지. 더 심각한 건, 패치 여부에 대한 공식 기록조차 서로 엇갈린다는 거야. GitHub 보안 권고문은 패치됐다고 하는데, NVD 본문은 수정 버전이 없다고 적혀 있어. 이런 상황에서는 안전하다고 믿을 근거가 전혀 없는 셈이지.
게다가, 프로젝트 문서에는 Anthropic 같은 주요 공급사 16곳의 프록시·재판매 금지 조항이 정리되어 있지만, 같은 문서가 이 표시는 참고용일 뿐 실제 라우팅을 막지는 않는다고 밝혀. 기본 설정에서는 약관 위반 위험이 있는 공급사로도 요청이 그대로 나간다는 이야기지. 이런 경우, 회사 업무나 고객 데이터를 다루는 환경에서 쓰면 정말 위험한 상황에 빠질 수 있어. 법적 문제까지 이어질 수 있는 부분이라 더 민감하지.
결국, GitHub 스타 6만 개가 넘는 인기 프로젝트라도, 진짜 중요한 건 `보안 취약점 이력`, `패치 검증`, `약관 준수 여부`, `데이터 흐름`이야. 우리 팀에 새로운 AI 도구를 들일 때, 그저 숫자에만 의존하지 말고 CVE 등록 이력, 보안 권고문, 취약점 데이터베이스 원문을 함께 대조하고, 데이터가 어느 경로로 이동하는지, 공급사 약관은 어떤지 꼼꼼히 따져봐야 해. 인기와 검증은 완전히 다른 질문에 대한 답인 거야.
벤치마크 점수만 믿다간: 진짜 업무는 다르다
AI 모델의 성능을 이야기할 때 흔히 벤치마크 점수를 들여다보지. 그런데 최근 `Real-SWE`라는 새로운 벤치마크가 공개됐는데, 이 벤치마크는 비공개 엔터프라이즈 코드베이스에서 AI 모델이 실제 소프트웨어 엔지니어링 작업을 얼마나 잘 수행하는지를 평가하는 거야. 즉, 우리가 흔히 보는 공개 데이터셋이 아니라, 실제 기업 환경에서 엔지니어들이 겪는 문제들을 가지고 테스트한 거지.
결과는 좀 충격적이야. 최첨단 AI 모델들이 실제 기업 환경의 코드 작업에서 아직 기대치보다 제한적인 성능을 보인다는 거야. 어느 댓글에서는 "30%라는 수치는 제 경험과 일치해요. 제가 모델에 너무 많은 기대를 하는 건가 미친 건가 생각했었죠."라는 이야기도 있었어.
이게 뭘 의미하냐면, 우리가 AI 코드 생성 도구에 대해 너무 장밋빛 환상을 품고 있는 건 아닌지 돌아봐야 한다는 거야. 공개된 벤치마크는 대개 잘 정제된 데이터로 이루어져 있고, 특정 문제에 최적화되어 있어. 하지만 실제 기업 코드베이스는 지저분하고, 레거시 코드가 많고, 복잡한 비즈니스 로직이 얽혀 있잖아. 이런 현실적인 환경에서 AI의 성능은 우리가 생각하는 것만큼 압도적이지 않을 수 있어.
AI를 만능 해결사로 기대하기보다는, 보조 도구로서 그 `한계를 명확히 인식`하고 `현실적인 기대치`를 설정하는 게 중요하다고 봐. AI가 못하는 부분은 결국 사람이 메워야 하는 것이고, AI의 도움을 받아도 `검증`과 `수정`은 여전히 우리 몫인 거지.
비용 아끼려다 더 큰 손해? AI에게 일 시키는 법
GPT-6 Astra 같은 새로운 모델들이 나오면서 비용 이야기가 끊이지 않아. "너무 비싸다"는 우려도 많고. 그런데 OpenAI 공식 가이드에는 이 비용을 아끼는 6가지 팁이 자세히 나와 있어. 이게 단순히 모델 가격을 싸게 쓰는 법이 아니라, 우리가 AI에게 `어떻게 일을 시키느냐`에 대한 이야기라는 점이 중요해.
가이드 내용을 보면, 프롬프트에서 AI의 `자율성 범위`, `승인이 필요한 시점`, `지침이 충돌할 때의 기준`, `문체` 등을 아주 구체적으로 지정하라고 조언해. 예를 들어, "사용자의 의도와 작업 범위 안에서 합리적으로 추론하고, 완료할 때까지 진행해줘" 라거나 "맥락상 이미 허용된 작업은 먼저 완료하고, 추가 승인 필요한 부분은 마지막에 검토 가능한 형태로 정리해줘" 같은 식이지.
이건 결국, AI와의 `작업 계약`을 명확히 하는 행위와 같아. AI가 불필요한 확인을 위해 멈추거나, 너무 과도하게 작업하거나, 애매한 지침 때문에 헤매는 것을 줄여서 비용을 아끼는 방법인 거야. 단순히 "알아서 해줘"라고 말하는 것과, 위에서 언급한 것처럼 구체적으로 지시하는 것 사이에는 엄청난 비용 차이가 발생할 수 있어.
이 지점에서 OmniRoute 사례와 연결하면 더 흥미로워져. 단순히 무료 티어를 찾아 헤매거나 싼 서비스를 쫓는 것만이 능사가 아니라는 점이야. 진짜 비용 효율성은 `AI 모델의 가격`뿐만 아니라, `AI에게 일을 시키는 방식`에서 온다는 점을 깨달아야 해. 위험을 감수하고 싼 걸 쓰다가 더 큰 손해를 볼 수도 있고, 비싼 모델이라도 제대로 활용하면 오히려 투자 대비 효율이 더 높을 수 있는 거지.
결국 이 세 가지 이야기가 가리키는 방향은 하나인 것 같아. AI 도구와 모델을 도입하고 활용할 때, `겉으로 보이는 인기나 벤치마크 점수`, `단순한 비용` 같은 숫자에만 매몰되지 말아야 한다는 거야. 그 뒤에 숨겨진 `보안 리스크`, `실제 성능의 한계`, `활용 방식에 따른 효율성`을 냉철하게 파악하고, 우리 워크플로우와 목적에 맞춰 현명하게 접근해야 해.
우리 팀은 지금 AI 도구를 도입하거나 사용하고 있다면, 혹시 이런 부분들을 놓치고 있는 건 아닐까? 우리 스스로 한번 돌아볼 때인 것 같아.
참고
- 정상록 (Sangrok Jung). (2026, September 12). GitHub 스타 ≠ 보안: OmniRoute 사례로 본 위험. LinkedIn. https://www.linkedin.com/feed/update/urn:li:activity:7504517975316529152/
- 이정민 (Jeongmin Lee). (2026, September 8). 비싼 GPT-6 Astra? OpenAI 절약 팁 6가지. LinkedIn. https://www.linkedin.com/feed/update/urn:li:activity:7502631410126688257/
- withspecific.com. (2026, September 12). Real-SWE: Benchmarking AI models on private, real-world, enterprise codebases. withspecific.com. https://withspecific.com/benchmarks/real-swe