[GeekNews 요약] AI 에이전트 180개로 하루 만에 iOS 앱 버그 55개 발견 및 수정한 검증 파이프라인
1
설명
21개 언어로 운영되는 13만 줄 규모의 iOS SNS 앱에서 약 180개의 LLM 에이전트를 활용하여 하루 만에 55개의 버그를 발견하고 수정하는 혁신적인 검증 파이프라인이 구축되었습니다. 이 파이프라인은 단순히 버그를 찾는 것을 넘어, '찾았다는 주장을 반박하는 AI'의 중요성을 강조하며, 생성자와 검증자의 유인을 분리하고 '반박 실패'를 판정 기준으로 삼는 독창적인 접근 방식을 채택했습니다.
### 배경 설명
최근 소프트웨어 개발 분야에서는 코드베이스의 복잡성이 증가함에 따라 기존의 정적 분석 도구나 수동 코드 리뷰만으로는 모든 버그를 효과적으로 탐지하고 수정하는 데 한계가 있다는 인식이 확산되고 있습니다. 특히 13만 줄에 달하는 21개 언어 지원 iOS SNS 앱과 같이 방대한 규모의 프로젝트에서는 사람이 모든 코드를 깊이 있게 검토하는 것이 물리적으로 불가능합니다. 이러한 배경 속에서 LLM(거대 언어 모델)을 활용한 자동화된 코드 감사 및 검증 파이프라인에 대한 관심이 높아지고 있습니다. 기존의 LLM 기반 버그 탐지 시도는 환각 보고, 얕은 스캔, 반복 발견, 성실한 오답 등의 실패 모드로 인해 실질적인 효과를 거두기 어려웠습니다. 본 글에서 소개하는 파이프라인은 이러한 LLM의 한계를 극복하고, 실제 운영 환경에서 유의미한 성과를 달성했다는 점에서 주목할 만합니다. 특히, '빌드가 불가능한 환경'이라는 제약 조건 하에서 순수 정적 분석만으로 버그를 탐지했다는 점은 이 방법론의 실용성을 더욱 높입니다.
### 1. 파인더 Fan-out: 렌즈를 직교로 설계하여 커버리지 극대화
이 파이프라인의 핵심 발상은 '버그를 찾아라'는 모호한 프롬프트 대신, 각 파인더 에이전트에게 '무엇을 어떤 각도에서 볼지'를 명확히 규정하는 '렌즈(lens)'를 배정하는 것입니다. 렌즈는 명시적으로 설계되어 각기 다른 관점을 제공하며, 이 렌즈들은 서로 겹치지 않으면서도 전체 코드베이스를 포괄하도록 직교(orthogonal)하게 설계되었습니다. 하루 동안 6라운드에 걸쳐 다양한 축을 기준으로 렌즈를 변경하며 코드를 분석했습니다. 첫 번째 라운드(R1)에서는 '도메인 축'을 사용하여 피드, 댓글, 채팅 등 기능 영역별로 코드를 분할하여 분석했고, 두 번째 라운드(R2)에서는 '고장 유형 축'으로 크래시, 데이터 유실, 침묵 실패 등 결함의 종류별로 코드를 재검토했습니다. 특히 세 번째 라운드(R3)의 '계열 축'은 이전 라운드에서 발견된 버그와 유사한 패턴을 코드베이스 전체에서 찾아내는 방식으로, 가장 생산적인 발상으로 평가받았습니다. 이후 R4에서는 '신규 12렌즈'를 통해 보안, 소켓 핸들러, 캐시 마이그레이션 등 iOS 앱에서 흔히 발생하는 잠재적 문제 지점들을 탐색했으며, 마지막 두 라운드(R5, R6)에서는 '자유 탐색'을 통해 에이전트 스스로 새로운 관점을 발명하도록 하여 커버리지를 더욱 확장했습니다. 이러한 다층적이고 직교적인 렌즈 설계를 통해 '얕은 스캔' 실패 모드를 효과적으로 봉쇄했습니다.
### 2. 구조화된 출력 강제: JSON 스키마와 '빈 배열이 정답'으로 환각 방지
LLM 에이전트가 자유로운 산문 형식으로 보고할 경우, 결과 집계가 어렵고 불확실한 정보가 혼재될 수 있습니다. 이를 방지하기 위해 모든 파인더는 사전에 정의된 JSON 스키마에 따라서만 보고하도록 강제되었습니다. 스키마에는 severity, title, file, line, description, evidence 필드가 포함되어 있으며, 특히 'file'과 'line' 필드를 필수로 요구함으로써 에이전트가 실제 코드를 열어보고 근거를 제시하도록 유도했습니다. 또한, 프롬프트에 '확신이 없으면 보고하지 마라. 빈 배열이 정답이다(empty array is a valid, correct answer)'라는 문구를 명시적으로 추가하여, LLM의 '뭐라도 내놓으려는' 성향으로 인한 환각 보고를 효과적으로 억제했습니다. 이는 '환각 보고' 실패 모드에 대한 첫 번째 방벽 역할을 하며, 두 번째 방벽은 다음 단계의 '적대 검증 투표'에서 구현됩니다.
### 3. 적대 검증 투표: '반박 실패'를 기준으로 성실한 오답 차단
파인더가 아무리 정밀해도 '성실한 오답', 즉 진지하게 분석했지만 결론이 틀린 경우를 완벽히 걸러내기 어렵습니다. 이 파이프라인의 핵심은 이러한 '성실한 오답'을 걸러내기 위해 '생성자(파인더)'와 '검증자'의 유인을 분리하는 것입니다. 파인더는 버그를 '찾는' 유인으로 움직여 위양성(false positive)에 편향될 수 있지만, 검증자는 '이 발견을 반박하라. 불확실하면 기각하라'는 정반대의 프롬프트를 받습니다. 검증자의 임무는 발견을 확인하는 것이 아니라 반박하는 것이며, 반박에 실패했을 때만 발견이 최종적으로 확정됩니다. 판정 기준은 '몇 명이 찬성했나'가 아닌 '반박이 실패했나'입니다. HIGH/MED 등급의 발견마다 독립된 검증자 2명이 각자 반박을 시도하고, 둘이 갈릴 경우 3번째 검증자가 타이브레이크를 합니다. 이 구조를 통해 '성실한 오답'이 사용자에게 도달하기 전에 효과적으로 차단되며, 실제 운영 환경에서 오탐으로 인한 사용자 피해가 0건으로 보고되었습니다.
### 4. 기지 목록 주입 및 Fix 후 재검증 루프: 반복 발견 방지 및 수리의 완전성 확보
라운드를 거듭하며 동일한 버그가 반복적으로 발견되는 것을 막기 위해, 매 라운드마다 '이미 알려졌거나 이미 수리된 이슈 목록'을 프롬프트에 주입하고 이를 누적하여 사용했습니다. 이를 통해 파인더는 이미 처리된 영역을 제외하고 미개척지에 집중하게 되어 탐색 효율성을 높였습니다. 또한, 대부분의 감사 파이프라인에서 간과하기 쉬운 '수리 자체에 대한 검증' 단계를 도입했습니다. '이 fix가 정말 버그를 고쳤는가? 그리고 그 과정에서 다른 것을 깨뜨리진 않았는가?'라는 질문으로 수리된 코드를 다시 검증자에게 태워 반박하게 했습니다. 이 'fix 후 재검증 루프'를 통해 '반쪽 수리'나 '치명적 회귀'와 같은 문제들을 다수 발견하고 수정할 수 있었습니다. 예를 들어, 타임존 버그의 1차 수리가 다른 지역에서는 오히려 문제를 야기하는 반쪽 수리였음을 검증자가 4상한 시뮬레이션을 통해 밝혀냈고, SwiftUI 래퍼 전환 과정에서 발생한 else 누락으로 인한 콘텐츠 증발 회귀도 타입의 모양을 재구성하는 정적 분석으로 잡아냈습니다. 이는 발견만큼이나 수리의 완전성을 확보하는 데 결정적인 역할을 했습니다.
### 가치와 인사이트
이 파이프라인의 가장 큰 가치는 LLM의 잠재력을 극대화하면서도 그 한계를 명확히 인지하고 보완하는 설계에 있습니다. '버그를 찾는 AI'가 아닌 '찾았다는 주장을 반박하는 AI'에 집중함으로써, 기존의 자동화 도구가 놓치기 쉬운 '성실한 오답'과 '반쪽 수리'를 효과적으로 걸러낼 수 있었습니다. 이는 단순히 버그를 많이 찾는 것을 넘어, 실제 사용자에게 도달하는 버그의 수를 '0'으로 만드는 데 기여했습니다. 또한, 렌즈의 직교화, 구조화된 출력 강제, 적대 투표, 기지 목록 누적, 그리고 fix 후 재검증이라는 각 단계별 설계는 LLM 감사 파이프라인 구축 시 고려해야 할 핵심적인 요소들을 제시합니다. 특히, 생성자와 검증자의 유인 분리 및 '반박 실패'를 판정 기준으로 삼는 접근 방식은 향후 AI 기반의 코드 품질 관리 시스템 설계에 중요한 시사점을 제공합니다. 개발자는 이 파이프라인을 통해 LLM을 단순한 탐지 도구가 아닌, 복잡한 코드베이스의 품질을 체계적으로 관리하고 개선하는 강력한 파트너로 활용할 수 있습니다.
### 기술·메타
- LLM 에이전트 약 180개
- Swift 언어 기반 iOS 앱 (약 13만 줄, 131개 Swift 파일)
- 정적 분석 환경 (빌드 불가능)
- 오케스트레이션 도구 (코드로 작성)
- 동시 실행 캡: 약 10개 에이전트
### 향후 전망
이 파이프라인은 LLM 기반 코드 감사 분야의 새로운 가능성을 제시하며, 향후 더욱 발전할 것으로 기대됩니다. 첫째, '렌즈 설계'의 자동화 또는 반자동화 연구가 진행될 수 있습니다. 현재는 사람이 렌즈 설계를 담당하지만, 라스트콜 라운드에서처럼 LLM이 스스로 새로운 관점을 발명하도록 하는 범위를 넓히는 방안을 고려해볼 수 있습니다. 둘째, '적대 투표' 메커니즘의 효율성을 높이는 연구가 필요합니다. 검증자 수를 줄이거나, 더 정교한 타이브레이크 시스템을 도입하여 비용 대비 효과를 개선할 수 있을 것입니다. 셋째, '정적 게이트'와 '실기기 게이트'의 연계성을 강화하는 방안도 모색될 수 있습니다. 정적 분석으로 위험 후보를 좁힌 후, 실제 실행 환경에서의 테스트 자동화와 연동하여 발견 및 수정의 정확도를 더욱 높이는 방식입니다. 규제 측면에서는, AI 기반의 코드 감사 결과가 소프트웨어 품질 보증 프로세스에서 어느 정도의 신뢰도를 가질 수 있는지에 대한 표준화 논의가 필요할 수 있습니다. 경쟁 구도에서는, 이러한 고도화된 LLM 기반 감사 솔루션을 제공하는 기업들이 시장에서 우위를 점할 것으로 예상됩니다. 다만, LLM의 지속적인 발전과 함께 새로운 실패 모드가 등장할 수 있으므로, 파이프라인은 지속적인 업데이트와 개선이 필요할 것입니다. 궁극적으로는 AI가 코드 작성부터 감사, 수정까지 전 과정에 걸쳐 개발자의 생산성과 코드 품질을 혁신적으로 향상시키는 데 기여할 것으로 전망됩니다.
📝 원문 및 참고
- 원문: [링크 열기](https://velog.io/@soungjunban/%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8-%ED%95%A8%EB%8C%80%EC%9D%98-%ED%95%B4%EB%B6%80-AI-180%EA%B0%9C%EB%A1%9C-%ED%95%98%EB%A3%A8%EC%97%90-%EB%B2%84%EA%B7%B8-55%EA%B0%9C%EB%A5%BC-%EC%9E%A1%EC%9D%80-%EA%B2%80%EC%A6%9D-%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8)
- GeekNews 토픽: [보기](https://news.hada.io/topic?id=31393)
---
출처: GeekNews ([원문 링크](https://velog.io/@soungjunban/%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8-%ED%95%A8%EB%8C%80%EC%9D%98-%ED%95%B4%EB%B6%80-AI-180%EA%B0%9C%EB%A1%9C-%ED%95%98%EB%A3%A8%EC%97%90-%EB%B2%84%EA%B7%B8-55%EA%B0%9C%EB%A5%BC-%EC%9E%A1%EC%9D%80-%EA%B2%80%EC%A6%9D-%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8))
신고 · 불법·유해·아동 안전(CSAE) 관련 콘텐츠
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.