AI를 제품에 적용할 때, 어디까지 맡겨야 하는가 by. 엘에스웨어 김원영

 

이제 대부분의 개발자는 AI를 통해 코드를 생성하고, 이를 실제 제품에 반영하는 경험에 익숙해졌을 것이다. 몇 년 전까지만 해도 AI에 대한 의존도에 상당한 거부감을 드러냈던 나 자신만 하더라도, 어느새 충실한 클로드(Claude) 구독자가 되어버렸다.
그렇지만 여전히 제품에 AI 기술을 적용하고자 할 때는 어느 단계에, 어떤 기준으로 AI를 도입해야 하는가가 큰 고민이 아닐 수 없다.
기업 역시 단순한 AI 도입에 그치지 않고 적극적으로 AX(AI Transformation)로 전환하려 하고 있으며, 자사 제품에 AI라는 타이틀을 부여하려 한다.
하지만 AI가 적용된 제품을 너도나도 선보이던 기업들도 어느 순간부터 경쟁력이라는 관점에서는 더 이상 AI 자체가 차별화 요소가 아니라는 사실을 깨닫기 시작했다. 결국 제품이 가지고 있는 핵심 기능과 성능이 여전히 경쟁력을 판단하는 중요한 기준이 되고 있다.
그렇다면 기업이 추구하는 남들보다 앞선 기술의 적용과 고객이 만족할 수 있는 제품 개발을 동시에 달성하기 위해서는 AI를 어디까지 적용해야 할까?
여기서는 몇 가지 실제 업무 경험을 바탕으로 AI 활용의 경계선에 대해 이야기해 보고자 한다.

 

---

온톨로지 모델링에 AI를 적용한다면

만일 회사가 자사의 여러 제품군을 하나로 묶고, 각각의 시스템이 보유한 데이터에서 서로 의미를 공유할 수 있는 정보를 취합한 뒤 그 관계와 분포를 지속적으로 모니터링하는 솔루션을 개발한다고 가정해 보자.
이 경우 개발자는 자연스럽게 온톨로지(Ontology) 개념을 적극적으로 고려해야 할 것이다.
개발자는 먼저 온톨로지의 개념을 숙지하고 핵심 요소를 설계에 반영한 뒤, AI 에이전트를 활용해 개발을 진행할 수 있다.
조금 더 진전시키려면 기존 온톨로지 제품이나 오픈소스를 벤치마킹하여 필요한 기능을 선별하고, 이를 구현 계획에 포함할 수도 있다.
문제는 그다음부터다.
Entity Resolution, Relationship Modeling, Provenance 연결 등 실제 제품의 경쟁력으로 이어지는 온톨로지의 핵심 기술을 AI(LLM)를 통해 자동화하려는 순간, 한 번쯤 크게 주춤하게 된다.
그 이유는 업무 시스템의 기밀 데이터가 외부로 유출되는 것을 방지하기 위해 선택한 사내 오픈소스 LLM이 데이터의 의미를 정확하게 분석하고, 엔티티와 관계를 자동으로 생성하는 작업에서 ChatGPT나 Claude의 최신 모델만큼 만족스러운 결과를 내지 못하는 경우가 많기 때문이다.
AI가 수행해야 하는 작업을 좀 더 구체적으로 나누어 보면 다음과 같다.

단계	AI가 수행해야 할 작업
1	DB 테이블의 스키마와 실제 데이터 분석
2	테이블 및 테이블 간 관계를 분석하여 N개의 일반 엔티티와 추론 엔티티 생성
3	생성된 엔티티 간 관계 모델링 생성
4	엔티티와 실제 DB 데이터를 매핑
5	매핑된 데이터를 그래프 DB에 적재할 수 있도록 데이터 추출 쿼리 생성

결코 쉬운 작업이 아니다.
그럼에도 불구하고 시중의 상당수 온톨로지 제품 홍보 영상을 보면 DB 연결 정보만 입력하고 확인 버튼을 누르면, AI 연동이라는 문구와 함께 화려한 UI에서 엔티티가 자동으로 생성되는 모습을 볼 수 있다.
이러한 모습은 보는 사람으로 하여금 온톨로지 자동화에 대해 지나칠 정도로 큰 기대를 하게 만든다.
물론 연동하려는 DB를 완벽하게 이해하고 있는 사람이 의미론적으로 데이터를 정의한 뒤, 각각의 테이블을 엔티티 생성에 유리한 형태로 사전에 구성했다면 어느 정도 가능할 수도 있다.
하지만 이것은 결국 사람이 상당한 수준의 의미론적 정보를 사전에 제공해야 한다는 것을 의미한다.
예를 들어 엔티티 구성에 필요한 스키마 매핑 정보나 테이블 간 의미적 관계를 사람이 제공하고, AI가 이를 기반으로 엔티티와 관계를 생성하도록 하는 방식이다.
즉, 완전한 자동화라기보다는 사람이 정확한 단서를 제공하고 AI가 복잡한 모델링 작업을 보조하는 형태에 가깝다.
더 큰 문제는 이렇게 어렵게 온톨로지 모델링 자동 생성 루틴을 구축하더라도 이를 또 다른 DB에 그대로 적용하기 어렵다는 점이다.
DB가 달라지면 테이블의 스키마와 데이터 구조, 명명 규칙, 업무적 의미가 모두 달라질 수 있기 때문이다.
결국 모든 종류의 시스템을 대상으로 완전히 일반화된 온톨로지 자동 생성 기능을 구현하는 것은 현실적으로 매우 어렵다.

 

---

그렇다면 AI를 어디에 적용해야 하는가?

바로 이 지점에서 AI 적용의 경계선을 설정할 필요가 있다.

앞서 설명한 프로젝트에서는 AI(LLM)의 적용 영역을 엔티티 자동 생성 자체보다는 온톨로지를 활용하는 소비(Consumption) 영역에 더 집중하는 것이 유리하다고 볼 수 있다.
즉, 일정 부분 SI 성격을 가진 작업인 엔티티 구성, DB 매핑, 관계 모델링, 그래프 DB 적재까지는 사람이 주도하여 안정적으로 구축한다.
그 이후 사용자가 자연어로 질문하면 AI(LLM)를 활용하여 사용자의 질문을 관계 그래프 쿼리인 Cypher Query로 직접 변환하거나, 중간 표현식(IR, Intermediate Representation)을 생성하여 그래프 탐색에 활용하는 것이다.
이를 구조적으로 표현하면 다음과 같다.

영역	주요 작업	AI 적용 방향
데이터 이해	DB 스키마 및 데이터 분석	제한적 활용
온톨로지 설계	엔티티 및 관계 정의	사람 주도
데이터 매핑	엔티티 ↔ DB 데이터 매핑	사람 주도 + AI 보조
데이터 적재	그래프 DB 적재	규칙 기반 자동화
자연어 질의	사용자의 질문 해석	AI 적극 활용
질의 생성	자연어 → Cypher / IR	AI 적극 활용
탐색 및 분석	관계 그래프 기반 추론 및 분석	AI 적극 활용

핵심은 AI가 제품의 핵심 데이터를 결정하도록 하는 것과, 이미 정의된 데이터를 AI가 활용하도록 하는 것은 전혀 다른 문제라는 것이다.

 

---

SAST에 AI를 적용한다면

또 다른 사례로 소스코드 보안 취약점 분석(SAST)에 AI를 활용하는 경우를 생각해 보자.
만약 기업에 SAST 도구 개발 과제가 급하게 주어졌다고 가정해 보자.
다소 과장해서 표현하면 가장 단기간에 MVP(Minimum Viable Product)를 만드는 방법은 AI에게 소스코드 전체의 취약점을 분석하도록 하고, 그 결과를 보기 좋은 UI/UX로 포장하는 것이다.
즉, 담당 개발자는 LLM 연동 부분과 UI/UX 개발을 AI 에이전트에게 맡기고, 실제 취약점 분석 엔진의 역할은 LLM에게 맡기는 것이다.
과연 결과는 어떨까?
실제로 Claude Opus 5.0을 이용하여 OWASP Benchmark 테스트 코드 중 CWE-89, CWE-327, CWE-328 세 가지 유형을 대상으로 분석을 진행해 보았다.
물론 소스 파일 유출에 민감하거나 외부 인터넷 연결이 허용되지 않는 환경이라면 Claude 대신 성능이 우수한 로컬 LLM을 사용하는 것이 적절하다.

LLM 기반 분석 결과

항목	결과
분석 방식	LLM
총 분석 파일	2,766개
총 코드 라인	283,895 LOC
총 탐지 건수	518건
CRITICAL	369건
HIGH	88건
MEDIUM	61건
분석 시간	약 25분
TP	491
FN	40
FP	27
TN	431
재현율 (TP / (TP + FN))	92.5%
오탐율 (FP / (FP + TN))	5.9%

 

레포트 생성까지 AI에게 맡겼는데, 취약점이 발생한 코드 라인과 연관 관계까지 상당히 보기 좋게 정리되었다.

 

---

전통적인 SAST 엔진과 비교

비교를 위해 전통적인 소스코드 분석 알고리즘으로 동작하는 간단한 SAST 엔진을 Claude 에이전트를 이용해 만들어 실행해 보았다.
이 엔진은 JAVA 언어의 문법만 파싱할 수 있으며, 마찬가지로 CWE-89, CWE-327, CWE-328 세 가지 유형에 대한 취약점 탐지 룰만 적용한 비교적 단순한 엔진이다.
크게 Lexer, Parser, Analyzer 의 구조이며, 총 95개 파일과 14,863라인으로 구성되었다.

전통적인 SAST 엔진 분석 결과

항목	결과
분석 방식	Rule-based Engine
총 분석 파일	2,766개
총 코드 라인	283,895 LOC
총 탐지 건수	582건
CRITICAL	241건
HIGH	228건
MEDIUM	113건
분석 시간	약 5초 (4.93초)
TP	460
FN	71
FP	0
TN	455
재현율 (TP / (TP + FN))	86.6%
오탐율 (FP / (FP + TN))	0%

---

최종 성능 비교

재현율에서 오탐율을 차감한 지표를 단순 비교 지표라고 정의하면 다음과 같다.

분석 방식	재현율	오탐율	단순 비교 지표
LLM	92.5%	5.9%	0.866
Engine	86.6%	0%	0.866

※ 단순 비교 지표 = 재현율 - 오탐율

 

보다시피 취약점 탐지 성능 자체는 두 방식이 거의 비슷한 수준으로 나타났다.
하지만 분석 속도에서는 전통적인 엔진 방식이 압도적이다.
LLM에게 이러한 결과를 지적하면 다음 분석에서는 이번 분석에서 생성한 스크립트를 그대로 사용할 수 있기 때문에 분석 시간이 획기적으로 단축될 것이라고 이야기한다.
하지만 이 부분은 치명적인 환각(Hallucination)의 한 형태로 볼 수 있다.
이대로 프로젝트를 진행한다면 나중에 되돌리기 힘든 설계 오류를 범할 가능성이 있다.

 

---

AI가 만든 분석 엔진의 함정

이를 검증하기 위해 AI가 생성한 스크립트를 직접 분석해 보면 문제를 금방 발견할 수 있다.
해당 스크립트는 분석 대상이었던 특정 소스 파일들을 처리하기 위해 파싱과 토큰화를 수행하는 일회성 로직에 가깝게 만들어져 있었다.
즉, 분석 대상 소스 파일의 구조나 코딩 패턴이 이전 테스트와 달라지면 수많은 파싱 오류가 발생한다.
이후 AI는 발생한 오류를 해결하기 위해 기존 스크립트를 수정하거나 아예 다시 작성하는 작업을 반복하게 된다.
결과적으로 대부분의 시간이 실제 취약점 분석이 아니라 분석 스크립트를 수정하는 데 소비되는 상황이 발생할 수 있다.
최악의 경우 분석 대상 소스 파일의 개수와 코드 라인이 많아지면 분석 시간이 기하급수적으로 증가하거나, 아예 분석 자체가 실패할 수도 있다.
이것이 바로 MVP 단계에서는 그럴듯해 보이지만 제품 단계에서는 치명적인 문제가 될 수 있는 AI 활용 방식이다.
이 실험은 상용 SAST 제품과 LLM을 직접 비교하기 위한 벤치마크가 아니라, 동일한 취약점 유형을 대상으로 LLM을 분석 엔진으로
직접 사용했을 때와 규칙 기반 엔진을 사용했을 때의 특성을 비교하기 위한 실험이었다.

 

---

AI의 한계를 말하는 것이 아니다

여기에서 다시 한 번 강조하고 싶은 부분이 있다.
앞서 수행한 테스트는 AI(LLM)의 한계를 지적하기 위한 것이 아니다.
오히려 중요한 것은 AI를 어디에 활용해야 제품의 경쟁력을 제대로 견인할 수 있는지를 판단하는 것이다.
AI는 매우 강력한 도구다.
하지만 강력하다는 이유만으로 제품의 모든 핵심 기능을 AI에게 맡기는 것이 반드시 좋은 설계는 아니다.
특히 제품의 핵심 경쟁력이 정확성, 일관성, 성능, 재현성에 있다면 AI가 담당해야 할 영역과 전통적인 알고리즘이나 규칙 기반 엔진이 담당해야 할 영역을 명확하게 구분해야 한다.
결국 중요한 것은 AI를 얼마나 많이 사용하는가가 아니라, AI가 가장 잘할 수 있는 영역에 얼마나 정확하게 적용하는가이다.

 

---

AI 시대의 개발자가 기억해야 할 세 가지

현재도 개발 프로젝트를 진행하고 있는 입장에서, AI 전문가가 어디선가 들려준 다음 세 가지 조언을 항상 명심하게 된다.
첫째, 도메인 전문성
AI가 아무리 발전하더라도 해당 제품이 해결하려는 문제와 도메인을 가장 잘 이해해야 하는 사람은 결국 개발자와 도메인 전문가다.
둘째, 맥락의 주도권
AI에게 무엇을 시킬 것인가보다 중요한 것은 어떤 맥락과 제약 조건을 제공할 것인가다.
AI가 제품의 방향을 결정하도록 하는 것이 아니라, 사람이 제품의 방향과 맥락을 결정하고 AI를 그 안에서 활용해야 한다.
셋째, 비판적 수용
AI가 제시한 결과를 무조건 정답으로 받아들이지 말아야 한다.
특히 제품의 핵심 로직과 아키텍처를 AI에게 맡길수록 결과에 대한 검증과 반론이 중요하다.
AI를 적극적으로 활용하되, AI가 결정해서는 안 되는 영역까지 넘겨주지 않는 것.
어쩌면 앞으로의 개발자에게 가장 중요한 역량 중 하나는 바로 이 AI 활용의 경계선을 결정하는 능력이 아닐까 생각한다.

---