AI 학습 데이터 정제·버그 감소: Sonar의 SonarSweep 소개

출처: The New Stack

대형 언어 모델은 새로운 장난감에서 소프트웨어 개발의 일상 인프라로 빠르게 전환되었습니다. 이제 우리는 AI를 채팅 창에서 단일 질문에 답하는 용도로만 사용하지 않습니다. 서비스, 인프라 구성, 테스트 케이스, 그리고 프로덕션 코드를 생성하는 데 활용하고 있으며, 그 속도는 전통적인 검토 프로세스가 감당하도록 설계되지 않은 수준에 이르고 있습니다.

모델이 코드를 생성할 수 있다는 것은 입증되었습니다. 문제는 팀이 그 결과물을 신뢰할 수 있느냐입니다. 이 도전 과제의 큰 부분은 모델을 학습시키는 데이터(Garbage In, Garbage Out 패러다임)의 상류 단계에서 시작됩니다. 이는 Sonar AI 연구팀이 깊이 탐구하고 SonarSweep 라는 기술을 구축한 사례입니다.

공개 코드 저장소는 모델에 다양한 언어와 프레임워크에 대한 방대한 폭을 제공하지만, 동시에 오래된 라이브러리, 보안에 취약한 패턴, 부서진 구현, 그리고 유지보수가 부실한 습관도 포함하고 있습니다. 모델은 이 모든 것을 학습합니다. 그리고 건전한 엔지니어링을 반영한 예시와 단순히 컴파일만 되는 예시를 신뢰성 있게 구분하지 못합니다.

이는 중요한 문제입니다. 기능적인 코드는 프로덕션에 바로 투입될 수 있는 코드와 동일하지 않기 때문입니다. 기업 환경에서는 코드가 보안성, 유지보수성, 그리고 실제 운영 상황에서의 복원력을 갖추어야 합니다. 이러한 특성이 학습 데이터에 일관되지 않다면, 출력물 역시 일관되지 않을 수밖에 없습니다.

검증되지 않은 코드의 위험

LLM은 본질적으로 정교한 통계 시스템입니다. “좋은” 엔지니어링과 “나쁜” 엔지니어링을 스스로 이해하지 못합니다. 제공된 컨텍스트와 학습 데이터에서 파생된 패턴을 기반으로 가장 확률이 높은 해결책을 최적화합니다.

따라서 학습 코퍼스의 약점은 모델 행동에 그대로 남아, 쉽게 과소평가될 수 있습니다. 지난해 말 발표된 Anthropic 연구 결과 등은 비교적 작은 규모의 “오염된” 혹은 저품질 데이터 샘플이라도 모델 내부 표현에 인코딩되어 위험한 행동을 유발할 수 있음을 시사합니다.

제가 지난해 공동 저술한 논문 “Assessing the Quality and Security of AI-Generated Code: A Quantitative Analysis*”*에서는 바로 이 현상을 관찰했습니다. 연구에 포함된 모든 모델은 단순 버그와 복잡한 버그, 취약점, 그리고 코드 냄새(유지보수성 문제)를 혼합해 생성했으며, 실험실마다 보안 성능을 우선시하거나 유지보수 가능한 코드를 쓰는 경향이 다르게 나타났습니다.

이 문제의 복잡성을 보여주는 예로 경로 탐색 취약점을 생각해 보세요. 이를 탐지하려면 입력 소스에서 민감한 싱크까지 흐름을 추적하는 taint analysis가 필요합니다. LLM이 특정 기능을 올바르게 수행하는 코드를 생성했더라도, 검증되지 않은 사용자 입력이 파일 경로나 악성 명령을 조작할 수 있는 상황을 고려하지 못할 수 있습니다.

“모델은 겉보기에 올바른 코드를 생성하고, 제한된 테스트를 통과하더라도 검토 시간, 기술 부채, 보안 노출을 증가시키는 문제를 초래할 수 있다.”

기업 팀에게 이것이 실제 위험입니다. 모델이 겉보기에 정상적인 코드를 만들고 좁은 테스트를 통과하더라도, 기술 부채 와 보안 노출을 증가시킵니다. 규모가 커질수록 이러한 결함은 고립되지 않고 풀 리퀘스트, 내부 도구, 하위 시스템 전반에 퍼집니다.

데이터 품질 엔지니어링이 중요한 이유

조직들은 자체 AI를 구축하고 소유하려는 관심이 커지고 있습니다. AI‑지원 코딩이 컨텍스트를 인식하고, 신뢰할 수 있으며, 비용 효율적이길 원한다면 코드와 기타 데이터를 핵심 자산으로 취급해야 합니다. 즉, 모델이 데이터셋을 학습하기 전에 품질 관리를 적용해야 합니다.

여기서 데이터 품질 엔지니어링이 필수적입니다. 공개 코드 코퍼스(및 자체 데이터)를 그대로 받아들이는 대신, 팀은 학습 데이터를 검사·필터링·개선하여 모델이 더 강력한 예시를 학습하도록 할 수 있습니다.

저희 팀은 SonarSweep을 통해 이를 실천하고 있습니다. SonarSweep은 모델이 데이터를 보기 전에 “스윕”하는 접근법으로, 학습 데이터가 철저히 검증되도록 합니다. 이는 에이전트 기반 개발 관행을 이해하고 개선하려는 기업에 매우 중요합니다. 데이터셋 스윕은 네 가지 핵심 단계로 이루어집니다.

• 코드를 깊이 분석한다. 단순 키워드 필터링을 넘어, 정적 분석을 통해 대규모 데이터셋에서 버그, 보안 취약점, 유지보수 문제를 식별합니다.
• 예시를 합성한다. 대표성이 낮은 작업·도메인에 대해 고품질 학습 예시를 만들고, 필요시 조직 자체 코드베이스를 활용해 모델에 특정 이해를 주입합니다.
• 수정 가능한 부분을 보완한다. 보안에 취약하거나 오래된 패턴을 자동으로 교정할 수 있다면, 모델은 결함이 아닌 개선된 버전을 학습합니다.
• 적극적으로 큐레이션한다. 모든 예시가 동일한 가중치를 가져야 하는 것은 아닙니다. 품질 게이트를 통해 저신호 데이터를 제거하고 다양성을 극대화합니다.

효과는 측정 가능하다

이론적인 주장만은 아닙니다. 지난해 말에 공개한 모델 릴리스에서 “스윕”된 데이터를 사용한 결과, 모델이 생성한 코드의 보안 취약점 밀도가 41%, 버그 밀도가 41% 감소했습니다.

이러한 개선은 기술적인 ROI를 넘어 운영적인 ROI를 제공합니다. 에이전트 기반 코딩 세션에서 모델이 버그와 취약점이 적은 코드를 작성하면, Agent Centric Development Lifecycle (AC/DC)(https://www.sonarsource.com/blog/the-future-is-ac-dc-the-agent-centric-development-cycle?utm_medium=referral&utm_source=newstack&utm_campaign=ss-agent-centric-dev-cycle-acdc26&utm_content=media-training%20data-2606-&utm_term=&s_category=Organic&s_source=External%20Referral&s_origin=press) 내에서 반복적인 검토와 토큰 사용이 크게 감소합니다. AC/DC는 오늘날 소프트웨어 개발 방식을 위한 프레임워크로, AI 에이전트가 대부분의 코드를 생성하고 팀은 Guide → Verify → Solve의 세 단계에서 개발 루프를 관리합니다.

또한, 자체 코드베이스로 모델을 학습시키면 토큰 사용량이 줄어들고 세션 시작 시 조직의 아키텍처와 베스트 프랙티스에 빠르게 적응할 수 있습니다. 깔끔하고 구조화된 코드는 토큰 소모를 감소시키는데, 이는 에이전트가 파일을 재읽거나 컨텍스트를 재구축하는 데 드는 시간을 절감하기 때문입니다.

Sonar의 연구에서도 이를 확인했습니다. 6개의 매칭된 코드베이스와 약 660개의 Claude Code 작업 실행을 비교했을 때, SonarQube‑검증 코드베이스에서 작업한 에이전트는 입력 토큰을 약 7%, 출력 토큰을 8% 적게 사용했으며, 작업 완료율에는 의미 있는 차이가 없었습니다.

처음부터 품질을 만들다

AI 코딩의 다음 경계는 단순히 더 큰 모델이나 더 빠른 생성이 아닙니다. 더 나은 기반이 핵심입니다. 이제 조직이 생산할 수 있는 코드 양이 한계가 아니라, 그 코드를 얼마나 신속히 검증하고 진행 여부를 판단하느냐가 한계가 되고 있습니다.

“AI 코딩의 다음 경계는 단순히 더 큰 모델이나 더 빠른 생성이 아니다. 더 나은 기반이다.”

신뢰 격차를 해소하려면, 조직은 배포 전 모델 행동을 형성하는 데이터셋을 포함해 시스템 전반에 품질을 처음부터 내재시켜야 합니다. 이를 잘 수행하는 팀이 바로 다음을 주도하게 될 것입니다.