인공지능(AI)이 소프트웨어(SW) 개발과 업무 자동화를 가속하면서 기업의 SW 관리 전략을 전면 수정해야 한다는 지적이 나왔다. 취약점을 찾아내는 데 그치지 않고 실제 업무에 미치는 영향을 판단해 책임 있는 의사결정과 조치로 연결해야 한다는 것이다. AI가 신뢰할 수 있는 데이터를 확보하기 위한 통합 관리 체계도 핵심 과제로 제시됐다.
전자신문과 한국오픈소스협회가 28일 서울 과학기술회관에서 공동 개최한 'K-오픈소스 AX 2026' 콘퍼런스에서는 SW 리스크 관리와 AI 데이터 플랫폼을 중심으로 기업의 오픈소스 활용 및 관리 전략이 소개됐다.
강윤미 에스코어 오픈소스 거버넌스 파트장은 'AI 시대, 기업의 소프트웨어 관리 전략을 다시 설계하다'를 주제로 기조발표를 했다. 강 파트장은 국내 반도체 대기업의 1000여개 운영 시스템의 오픈소스 리스크를 4~5년간 점검해온 전문가다.
강 파트장은 “어느 기업이든 점검 결과를 보고하면 나오는 질문이 '그래서 우리 서비스는 괜찮으냐'였다”면서 “많은 기업이 점검 정보를 갖고 있지만 최종 의사 결정을 내리는 데 어려움을 겪고 있다”고 짚었다.
그는 이런 문제의 원인을 정보의 분산에서 찾았다. 개발 조직은 소스코드와 라이브러리를, 운영 조직은 설치된 SW를, 보안 조직은 점검 결과를 각각 관리하다 보니 어떤 시스템부터 조치할지, 서비스를 멈추더라도 고쳐야 할지, 당장 고치기 어렵다면 누가 위험을 수용할지 판단하기 어렵다.
강 파트장은 “위험을 발견하는 일과 위험을 관리하는 일은 명확하게 다르다”며 “발견한 위험의 영향을 판단하고 책임 있는 결정을 내려 이행 여부까지 확인하는 과정이 모두 연결돼야 한다”고 강조했다. 시스템이 10~20개를 넘어서면 담당자 개인이 아닌 관리 체계의 문제가 된다는 설명이다.
강 파트장은 네 가지 전략을 제시했다. 첫째는 SW 구성요소 정보를 서비스, 업무 중요도, 책임자와 연결하는 것이다. 소프트웨어 자재명세서(SBOM) 개념을 활용해 어떤 패키지와 버전이 어느 시스템에 포함됐는지, 누가 조치와 위험 수용을 결정할 수 있는지 평소 관리해야 한다는 것이다. 한 기업은 이 정보를 유지해온 덕분에 최근 오픈소스 보안 사고에서 영향 분석과 책임자 안내, 임원 보고까지 2시간 만에 마쳤다.
둘째는 대응 방식의 구분이다. 같은 취약점도 고객이 쓰는 핵심 서비스와 내부 분석 도구에 미치는 영향이 다르기 때문에 기술적 심각도만으로 우선순위를 정해서는 안 된다. 긴급 수정, 보완 통제 후 기한 설정, 관찰과 재평가 등 회사 기준의 대응 방식을 두고 어떤 것을 택하든 근거와 책임자, 다음 확인 시점을 남겨야 한다고 했다.
셋째는 결정이 행동으로 이어졌는지 추적하는 것이다. 수정했다는 보고만으로 끝내지 않고 운영 환경 반영 여부를 확인하고, 새 취약점이 나오거나 시스템이 바뀌면 판단을 재검토해야 한다. 보고서에도 조치율 같은 수치뿐 아니라 미조치 항목이 담당자 부재 때문인지, 일정 조율 중인지 등 이유가 담겨야 한다고 했다.
넷째는 개발 프로세스 안에서의 통제다. AI로 코드 생성과 SW 도입이 쉬워지면서 관리 대상은 늘고 변경 주기는 짧아지고 있다. 강 파트장은 도입·빌드·배포·운영 단계에 검증을 연결하고 반복 점검은 자동화하되 “AI가 검증하니 맡기면 된다고 생각해서는 안 된다”며 업무 영향과 위험 수용 같은 책임 있는 판단은 사람이 맡아야 한다고 당부했다.
이어진 기조발표에서 박정권 인젠트 전무는 'AI-레디 데이터, AI가 신뢰하는 지식은 어디서 오는가'를 주제로 분산된 데이터를 연결하고 품질과 권한을 관리해 AI에 신뢰할 수 있는 정보를 공급하는 전략을 소개했다. 박 전무는 “답은 결국 데이터에서 온다”며 “AI가 즉각적으로 읽고 이해하고 쓸 수 있는 상태의 데이터가 AI-레디 데이터”라고 정의했다.
박 전무는 AI 에이전트의 역할이 검색에서 판단, 업무 처리로 넓어질수록 요구되는 신뢰의 수준도 달라진다고 짚었다. 검색 단계에서는 답변의 근거가, 판단 단계에서는 데이터의 정확성이, 업무 시스템과 연결되는 실행 단계에서는 보안·권한·책임이 보장돼야 한다는 것이다. 사내 규정을 찾아주는 챗봇에서 나아가 여신 한도 증액 가능성을 판단하고 심사 결과를 등록하는 단계까지 위임하려면 이 요건이 모두 충족돼야 한다. 박 전무는 “많은 기업이 개념검증(PoC)까지 성공하고도 이 장벽 때문에 운영 단계로 넘어가지 못하고 있다”고 진단했다.
장벽은 데이터와 권한·책임 두 가지다. 업무별 DB, 운영계와 분석계, 빅데이터가 사일로를 이루고 있고, 같은 용어도 부서마다 의미가 달라 결과가 달라질 수 있다. 문서는 문서대로, DB는 DB대로 따로 움직이는 점도 문제다. 박 전무는 “AI 프로젝트가 과제 중심으로 진행되다 보니 새 과제마다 데이터를 모으고 정제하고 메타데이터를 만드는 작업을 처음부터 반복한다”며 “에이전트와 DB가 늘수록 밑단의 거버넌스는 더 어려워질 것”이라고 말했다.
인젠트가 내놓은 해법은 '연결'이다. 박 전무는 “데이터를 가져오지 않고 기본적으로 연결한다는 사상을 적용했다”고 밝혔다. 한곳에 이관해 모으는 방식으로는 에이전트별 사일로와 데이터 불일치를 해소하기 어렵다는 설명이다. 이에 DB 엔진과 스토리지를 가상화해 연합 쿼리가 가능한 데이터 패브릭 위에, 용어와 지표를 표준화하는 메타데이터·시맨틱 계층을 두고, 그 위에 LLM 서빙과 RAG, 에이전트 런타임을 올리는 구조를 제시했다. 박 전무는 “공통으로 쓸 수 있는 것은 한 번 만들어 공유하고, 새로운 업무는 그 기반 위에 늘려가는 것이 플랫폼 방식”이라고 설명했다.
정형 데이터와 비정형 문서를 함께 활용하는 것도 핵심이다. 한도 증액 여부를 판단할 때 DB만 보면 업종별 규정이나 담보 한도 조항을 놓칠 수 있고, 문서만 보면 최신 재무 수치를 반영하지 못한다. 두 데이터를 결합해 판단 결과와 함께 근거 조항, 재무 수치, 심사의견의 출처까지 제시해야 AI 결과를 신뢰할 수 있다는 설명이다.
이를 구현한 인젠트의 데이터 플랫폼(DMP)에는 포스트그레SQL·트리노·아이스버그·쿠버네티스·MCP 등 오픈소스와 개방형 표준이 적용됐다. 사용자 요청은 먼저 권한과 보안 정책 위반 여부를 검사받고, 통과하면 용어 사전과 시맨틱 정보가 주입돼 LLM에 전달된다.
모든 DB 접근은 MCP 게이트웨이를 통해 통제되며, 텍스트-투-SQL로 생성된 쿼리는 정확한 답이 나올 때까지 수정과 재채점을 반복해 내부 품질 점수를 넘겨야 통과한다. 처리 내용은 감사 로그로 남는다.
박 전무는 “폐쇄망에서는 프로젝트마다 오픈소스를 조합해 해결하는 것이 현실인데, 이를 미리 연결하고 최적의 조합을 정리해 제공하는 것이 DMP의 사상”이라고 밝혔다.
최호 기자 snoop@etnews.com
