코드가 정상이라면, 정말 안전할까? | 비즈니스 로직 취약점이란

코드가 오류 없이 잘 작동한다고 해서, 그 시스템에 반드시 안전하다고 말할 수 있을까요?

많은 보안 취약점은 코드 오류에서 발생합니다. 하지만 실제 공격은 꼭 코드에서만 시작되지 않습니다.
오히려 더 위험한 경우는 코드가 완벽하게 정상적으로 동작할 때 발생합니다.

예를 들어 한 온라인 쇼핑몰의 장바구니 기능을 생각해 보겠습니다.
일반적으로 장바구니에는 구매할 상품의 수량을 입력하고, 시스템은 이를 기반으로 결제 금액을 계산합니다.

그런데 만약 장바구니에 음수 수량을 입력할 수 있다면 어떻게 될까요? 공격자는 이를 이용해 장바구니 금액을 임의로 조작하고 결제 로직을 악용해 부당한 카드 환불을 유도할 수 있습니다. 이 경우 코드 자체에는 오류가 없을 수도 있습니다. 장바구니는 단순히 입력된 수량을 기반으로 가격을 계산할 뿐이지만 시스템이 설계된 비즈니스 규칙이 공격에 악용된 것입니다.

이처럼 각각의 기능만 보면 문제가 없어 보이지만, 여러 기능과 규칙이 연결되는 과정에서 예상하지 못한 공격 경로가 만들어지는 유형의 취약점을 비즈니스 로직 취약점(Business Logic Vulnerability)이라고 합니다.

비즈니스 로직 취약점은 각 요청이나 기능만 놓고 보면 모두 정상처럼 보이지만, 사용자가 시스템의 규칙을 교묘하게 이용해 여러 단계의 행동을 이어가면, 개발자가 의도하지 않은 방식으로 서비스가 악용될 수 있습니다. 결국 문제는 코드의 오류가 아니라, 시스템의 로직이 공격에 활용될 수 있다는 점입니다.

하지만 대부분의 취약점 스캐너들은 개별 요청 혹은 코드 조각만 분석하기 때문에 이런 취약점을 잘 발견하지 못합니다. 최근 등장한 AI 기반 도구들도 상황은 크게 다르지 않습니다. 문제는 실제 로직 기반 탐지 규칙을 만들기 어렵다는 점입니다. 예를 들어 “검증 코드를 다른 곳에 노출하지 말 것” 같은 보안 원칙은 누구나 이해할 수 있습니다. 하지만 이런 원칙은 너무 포괄적이기 때문에, 전통적인 규칙 기반 스캐너가 구체적인 탐지 규칙으로 구현하기 어렵습니다.

왜 기존 취약점 스캐너는 비즈니스 로직 취약점을 놓칠까?

비즈니스 로직 취약점을 찾기 어려운 이유는 간단합니다. 대부분의 경우 코드 자체에는 아무런 오류가 없기 때문입니다. 기능도 정상적으로 동작하고, 예외나 에러도 발생하지 않기 때문에 문제가 전혀 없는 코드처럼 보입니다.

대표적인 코드 분석 도구인 SAST(Static Application Security Testing)도 이런 한계를 가지고 있습니다. SAST는 애플리케이션의 모든 코드를 정적으로 분석할 수 있지만, 기본적으로 규칙 기반(rule-based) 방식으로 동작합니다. 그래서 잘 알려진 안전하지 않은 패턴은 효과적으로 찾아낼 수 있지만, 새롭게 등장한 패턴들은 찾을 수 없습니다. 특히 사용자의 복합적 행동 속에서 발생하는 복잡한 사례를 탐지하기는 더욱 어렵습니다.

또 다른 문제는 결과의 품질입니다. 많은 코드 스캐너는 규칙에 맞지 않는 코드를 최대한 많이 찾아내는 방식으로 동작하기 때문에, 실제로 중요한 취약점과 그렇지 않은 항목이 뒤섞인 수백 개의 경고를 한 번에 출력합니다. 결국 개발팀과 보안팀은 진짜 위험한 이슈를 찾기 위해 방대한 결과를 하나씩 검토해야 하고, 이 과정에서 시간과 리소스가 크게 소모됩니다.

사람이 직접 수행하는 모의해킹의 한계

그렇다면 사람이 직접 수행하는 모의해킹은 어떨까요?

전문 레드팀은 시스템의 맥락을 이해하고 공격 시나리오를 상상하는 데 강점이 있습니다. 하지만 현대 애플리케이션의 규모를 생각하면 현실적인 한계가 있습니다. 수십만 줄에서 수백만 줄에 이르는 코드베이스를 사람이 일일이 검토하는 것은 시간과 비용 측면에서 매우 부담이 크기 때문입니다.

결국 모든 코드를 완전히 점검하는 것은 사실상 불가능하고, 그 결과 코드베이스에는 충분히 검토되지 않은 영역이 남게 됩니다. 이런 부분은 자연스럽게 보안의 사각지대로 이어지며, 공격자가 노릴 수 있는 잠재적인 공격 표면이 될 수밖에 없습니다.

최신 AI 도구들도 아직은 역부족

최근에는 Claude Code, Copilot, Gemini 같은 LLM 기반 도구를 활용해 코드의 버그나 취약점을 확인하는 개발자들도 많습니다. 이런 도구들은 분명 코드 검토에 도움을 줄 수 있습니다.

하지만 구조적인 한계도 분명합니다. 대부분의 LLM 기반 도구는 한 번에 작은 코드 조각을 분석하거나, 전체 코드를 대략적으로 살펴보는 수준에 머무르는 경우가 많습니다. 컨텍스트 윈도우의 제한 때문에 애플리케이션의 모든 코드를 동시에 깊이 있게 분석하기 어렵기 때문입니다.

결국 이런 방식은 한 번에 하나의 작업만 처리하는 단일 작업자와 비슷합니다. 일정 범위의 코드는 잘 살펴볼 수 있지만, 대규모 코드베이스 전체를 맥락 속에서 동시에 분석하는 데에는 한계가 있고, 이러한 LLM 기반 도구를 활용해 취약점을 찾고자 한다면 개발자가 직접 세세하게 질문을 던져야합니다.

Xint: 인간처럼 이해하고 SAST처럼 확장하다

그렇다면 단순히 LLM을 코드 검토에 사용하는 방식으로는 부족하다면, Xint는 어떻게 이 문제를 해결했을까요?

핵심은 대규모 병렬 분석 구조입니다. Xint는 수천 개의 AI 에이전트를 동시에 조율해 대규모 코드베이스를 병렬로 분석합니다. 이를 통해 LLM의 맥락 이해 능력을 활용하면서도, 단일 모델이 처리할 수 있는 범위를 훨씬 뛰어넘는 규모로 분석을 수행할 수 있습니다.

그 결과 Xint는 수백만 줄 규모의 코드베이스도 12시간 이내에 전체 분석을 완료할 수 있습니다. 또한 단순한 패턴 기반 탐지를 넘어, 코드의 흐름과 기능 간 상호작용까지 분석해 비즈니스 로직이 실제 공격에 악용될 수 있는 지점을 찾아냅니다.

이 분석 방식에는 티오리 보안 연구팀이 10년 이상 실제 해킹 연구와 모의해킹을 통해 축적해 온 공격자의 관점이 반영되어 있습니다. 단순히 취약한 코드 패턴을 찾는 것이 아니라, 공격자가 시스템을 어떻게 우회하고 악용할지까지 고려해 취약점을 식별하는 것이 Xint의 핵심입니다.

이러한 접근 방식 덕분에 Xint는 기존 보안 도구가 놓치기 쉬운 새로운 공격 방식이나 비즈니스 로직 악용 사례까지 발견할 수 있습니다.

예를 들어 Xint는 한 글로벌 이커머스 기업의 장바구니 시스템에서 상품 수량에 음수를 입력할 수 있는 구조를 발견했습니다. 이 경우 공격자는 음수 값을 이용해 결제 흐름을 악용하고, 결과적으로 부정한 카드 환불을 유도할 수 있는 상황이 발생할 수 있습니다. 코드 자체에는 오류가 없었지만, 체크아웃 로직이 의도하지 않은 방식으로 악용될 수 있었던 것입니다.

비슷한 사례는 금융 시스템에서도 발생할 수 있습니다. 예를 들어 계좌 잔액에 새로운 거래 금액을 더하는 구조가 있다고 가정해 보겠습니다. 만약 공격자가 음수 금액을 송금할 수 있다면 어떻게 될까요? 결과적으로 돈을 보내는 대신 계좌 잔액이 증가하는 상황이 발생할 수도 있습니다.

이처럼 단순한 숫자 연산 자체는 규칙을 위반하지 않기 때문에, 규칙 기반 보안 시스템은 이를 문제로 인식하지 못합니다. 하지만 Xint는 코드의 흐름과 맥락을 함께 분석하기 때문에 음수 송금과 같은 비정상적인 비즈니스 로직 악용 시나리오까지 식별할 수 있습니다.

티오리의 보안 연구원은 수십 년에 걸친 실제 공격 연구와 모의해킹 경험을 바탕으로, 기업 보안팀이 실제로 무엇을 필요로 하는지 잘 알고 있습니다.

보안팀의 목표는 가능한 취약점을 최대한 많이 나열하는 것이 아닙니다. 실제로 많은 전통적인 SAST 도구는 수백 개의 잠재적 이슈를 보고하지만, 그중 실제 취약점으로 이어지는 경우는 10% 미만인 경우도 많습니다.

결국 보안팀은 다음과 같은 작업에 상당한 시간을 쓰게 됩니다.

• 취약점이 실제로 위험한지 검증

• 각 취약점의 심각도를 평가해 우선순위를 정하고

• 중요한 취약점을 선별해 대응하고 패치하는 작업

이 과정은 이미 리소스가 부족한 보안팀에게 큰 부담이 됩니다.

그래서 Xint는 단순히 취약점을 나열하는 대신, 실제로 어떻게 공격이 가능한지와 그 공격이 어떤 영향을 가져오는지까지 함께 제공하도록 설계되었습니다. Xint가 제공하는 Trigger / Impact 리포트는 취약점이 어떻게 악용될 수 있는지와 공격자가 얻을 수 있는 결과를 명확하게 보여줍니다.

이를 통해 보안팀은 취약점의 발견 이후에 필요한 검증, 영향 분석, 우선순위 판단 과정을 훨씬 빠르게 진행할 수 있습니다.

중요한 점은 Xint가 보안팀이나 레드팀을 대체하려는 도구가 아니라는 것입니다.
오히려 보안 전문가가 가진 판단력과 공격자 관점을 확장하는 역할에 가깝습니다.

현실적으로 사람이 수백만 줄에 이르는 코드 전체를 하나하나 살펴보며 공격 가능성을 검토하는 것은 불가능합니다. 시간과 비용의 한계 때문입니다. 그 결과 많은 애플리케이션에는 충분히 분석되지 않은 코드 영역이 남게 되고, 이는 곧 보안의 사각지대로 이어집니다.

Xint는 바로 이 지점을 해결합니다.
사람이 수행하기 어려운 규모의 코드 전문를 분석하고, 기능 간의 흐름과 상호작용까지 고려해 공격 가능성을 찾아냅니다. 단순히 취약한 코드 패턴을 찾는 것이 아니라, 공격자가 실제로 시스템을 어떻게 악용할 수 있는지까지 분석하는 것입니다.

이렇게 자동화된 분석을 통해 보안팀은 사람이 반드시 수행해야 하는 전략적 판단, 고난도 공격 분석, 대응 의사결정에 더 집중할 수 있습니다.

결과적으로 Xint는 기존처럼 연 1~2회 수행되는 점검 중심의 AppSec에서 벗어나, 애플리케이션 전체를 지속적으로 검증하는 지속적인 보안 생태계를 가능하게 합니다.

결국 보안은 단순한 코드 오류 수정을 넘어, 시스템이 가진 본연의 목적과 비즈니스 의도를 보호하는 과정입니다. 기존의 도구들이 코드의 문법적 무결성에만 집중했다면, 이제는 서비스 전체의 흐름과 사용자 시나리오를 입체적으로 읽어내는 맥락 중심의 보안이 필요합니다. 인간 전문가의 날카로운 공격자 시각과 대규모 병렬 분석 기술이 결합될 때, 우리는 비로소 보이지 않던 논리적 허점을 찾아내고 보안의 사각지대를 완전히 걷어낼 수 있습니다.