프로젝트 설정: RAG 기반 알고리즘 블랙박스 해소 및 지식 시스템 구축 전략

조직 특화 Agent를 활용한 암묵지(Tacit Knowledge)의 형식지화 및 기술 부채 해소 방안

SW 개발 인력 이탈로 인한 알고리즘 블랙박스 및 기술 부채 문제를 해결하기 위해, 내부 지식(코드, 문서, 결정 이력)을 통합하는 RAG 및 Tool-use 기반 특화 Agent 개발 프레임워크와 단계별 수행 전략을 제시함.

AI
RAG
Agent
Azure
Cloud
저자

Kwangmin Kim

공개

2025년 11월 02일

1 프로젝트 설정

1.1 현상파악

  • SW개발 비전공자가 코딩한 프로그램이 서비스로 운영되어 확장 및 리팩토링 시급
  • SW개발자가 도메인 지식이 없음
  • 도메인 전문가가 프로그램 코드를 이해 못함
  • SW개발자와 도메인 전문가의 명확한 알고리즘에 대한 지식 수준 차이 존재
  • 조직 내 지속적인 이탈자 발생
  • 알고리즘 및 프로그램 원작자 이탈
  • 5년 이상 알고리즘이 블랙박스

1.2 장기적인 문제

지속된 실무자 이탈 → 암묵지 전달 한계 → 도메인 및 알고리즘 정보 희석 → 알고리즘 블랙박스 → 기술 폐기 → 서비스 폐기 → 지적재산 파산

1.3 목표

지식 플랫폼을 만들고 모든 문서 및 지식이 한곳에 모여 실무자들이 한 창구에서 지식을 열람할 수 있는 생태계를 구축한다.

우선 구현 Task: 알고리즘 설명 Agent를 만들어 질의를 할 수 있는 기능을 만든다.

1.3.1 목표 설정에 대한 검토

질문: GitHub 코드의 알고리즘을 분석하는 Agent (RAG + Tools + Reasoning + Action)를 만드는 것은 불필요한가? ChatGPT, Gemini, Claude AI, Copilot 등과 같은 AI 솔루션들이 이미 존재한다.

  • 일반적인 코드 이해·요약·질의응답 목적이라면 불필요에 가까우나, 조직·도메인·책임이 얽힌 분석이라면 여전히 필요하다.
    • 누구를 위해, 어떤 책임 수준의 분석을 하느냐가 핵심 분기점이다.

1.3.1.1 범용 AI 설명

  • 범용 AI 솔루션의 강점: ChatGPT, Gemini, Copilot이 이미 충분히 커버하는 영역
    • 함수/클래스 설명
    • 알고리즘 요약
    • 시간·공간 복잡도 추정
    • 코드 리팩토링 제안
    • 간단한 버그 포인트 지적
  • 범용 AI 솔루션의 한계
    • 구조적 한계: 컨텍스트 윈도우 제약
      • 실제 활용 가능 토큰은 이론치의 60-70% 수준 (Li et al., 2023, “Lost in the Middle”)
      • ChatGPT-4 (128K tokens), Claude 3.5 (200K tokens), Gemini 1.5 Pro (1M tokens)의 이론적 한계
      • 대규모 레포지토리(>100 files, >50K LOC)에서 전체 맥락 파악 불가능
      • “Lost in the Middle” 현상으로 실질적 활용률 저하
    • 조직 특화 지식 부재: 범용 LLM은 다음에만 의존
      • 훈련 데이터
      • 사용자 입력
      • 임시 컨텍스트
    • 반면 조직의 현실은 다층 지식 결합이 필요
      • 코드, 설계 문서, 변경 이력, 규제 문서, 리뷰 코멘트, 내부 합의 사항, GitHub 저장소의 코드베이스, 아키텍처 패턴, 내부 문서, 개발 팀의 컨벤션, 과거 PR 및 이슈 기록
      • 범용 모델은 조직의 코딩 컨벤션, 내부 프레임워크, 아키텍처 패턴에 대한 사전 지식이 없으며, Few-shot learning으로 보완 가능하나 매 세션마다 반복 설명이 필요하다 (context overhead).
    • 보안 및 거버넌스 문제
      • 기업이나 팀이 비공개(Proprietary) 코드를 분석해야 할 경우, 외부의 범용 AI 모델(ChatGPT 등) API에 코드를 전송하는 것은 보안상 큰 위험이다.
      • 외부 API 전송 시 코드 유출 리스크 (특히 금융, 헬스케어, 국방 도메인)
      • GDPR, HIPAA, ISO 27001 준수 요구사항과 충돌 가능
      • 일부 기업은 정책적으로 외부 AI API 사용 금지 (Goldman Sachs, Samsung 사례)
    • 비용 효율성
      • 대규모 코드베이스에 대해 반복적인 분석을 수행할 때, 모든 컨텍스트를 범용 LLM의 컨텍스트 창(Context Window)에 매번 넣는 것은 비효율적이며 비용이 많이 든다.

1.3.1.2 특화 Agent 설명

  • 특화 Agent의 구조적 이점
    • 도메인 특화 내/외부 지식 통합 가능: RAG는 내부/사설 지식(코드, 문서, 로그, 내부 문서, 과거 코드 리뷰, 아키텍처 결정 기록(ADR), PR 히스토리, Jira / Notion, 설계 변경 이유, Deprecated 결정 근거) 등을 벡터 스토어에서 검색하여 LLM에 프롬프트로 제공한다.
      • Lewis et al. (2020, “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”)
        • 배경: 대규모 사전 학습 언어 모델의 우수한 성능으로 활용성 증가, 집약적 지식으로 접근의 한계, 근거 출처(Provenance) 및 업데이트 한계
        • 방법론: RAG (검색 증강 생성) 모델을 사용: AI 알고리즘 + 외부지식 검색을 통해 출력 생성
        • 결과: LLM (정확도 점수: 28.9점) 대비 RAG (정확도 점수: 44.5점)이 더 가벼운 연산으로 더 높은 정확도를 보여줌
        • 결론: 도메인 특화 RAG는 범용 모델 대비 factual accuracy 30-40% 향상
      • RAG (검색 증강 생성)의 기본 개념은 여전히 유효할 뿐만 아니라, 2025년 현재 LLM을 실제 기업 환경에 도입하는 데 있어 가장 중요하고 표준적인 기술
      • 실시간/최신 정보를 바탕으로 정확하고 사실에 근거한 분석 수행
      • “이 함수가 어디에서 호출되는지”, “이 버그는 과거 어떤 PR에서 수정되었는지”와 같은 질문에 답변 가능
      • 알고리즘의 의도와 제약을 재현 가능
    • Tool Integration
      • Zhang et al. (2024, “ToolLLM”) 연구
        • 배경: 오픈소스 LLM의 한계로 LLaMA와 같은 오픈소스 LLM은 기본적인 언어 작업에서는 발전했지만, 외부 도구(API)를 사용하여 사용자 지침을 이행하는 도구 사용 능력이 크게 부족하다는 것을 지적
        • 방법론: RAG + Tool (Tool Augmented Reranker) 개발
        • 결과: LLaMA와 같은 기본 LLM에 ToolLLM 프레임워크를 적용했을 때, ChatGPT와 같은 SOTA 폐쇄형 모델과 견줄 수 있는 수준의 도구 사용 성능을 달성
        • 결론: tool-augmented LLM이 코드 분석 정확도 25% 개선
      • 정적 분석 도구(Static Analyzers)를 사용해 호출 그래프(Call Graph)나 제어 흐름 그래프(Control Flow Graph)를 작성하는 등의 코드 특화 분석 작업을 에이전트의 툴로 통합할 수 있다.
        • Static analysis tools (SonarQube, PMD), 실행 추적, 프로파일러 결과를 직접 연동
        • 컴파일러, 테스트 프레임워크, 코드 포매터(Formatter)와 같은 외부 도구를 호출하여 코드를 검증하고 수정
        • 범용 AI는 이런 도구 출력을 해석만 가능, 직접 실행 불가능
    • Reasoning + Action 루프
      • RAG + Tools + Reasoning + Action 구조는 단순한 질의응답을 넘어 복잡한 작업의 자동화를 가능하게 한다.
        • ReAct 패러다임 (Yao et al., 2023, NeurIPS): 사고 과정과 행동을 반복적으로 수행
        • 알고리즘 복잡도 분석 → 코드 실행 → 병목 지점 식별 → 최적화 제안의 순차적 워크플로우 자동화
        • “이 알고리즘에서 잠재적인 성능 병목 현상을 찾아라” (추론) → “병목 현상을 해결하는 코드를 자동으로 수정하여 PR 초안을 생성해라” (액션)
        • 범용 AI는 이를 다단계 프롬프팅으로 처리해야 하며 context coherence 저하
  • 특화 Agent의 이점: 규제·검증·감사 대응
    • 규제가 필요한 산업: 의료/바이오 (FDA), 금융 (모델 리스크 관리), 제조 (안전 알고리즘), 공공 (감사 추적)
      • “이 알고리즘은 이런 이유로 이렇게 동작한다”
      • “이 변경은 이 문서에 근거한다”
      • “이 수치는 이 로직에서 나온다”
      • 출처 추적 + 재현성 + 설명 책임
    • 기존 LLM은 법적·조직적 책임 주체가 될 수 없다.
  • 보안 통제
    • 사용자 지정 RAG 에이전트는 내부 서버나 보안이 있는 클라우드 네트워크 환경에 구축할 수 있어, 코드가 외부로 유출되지 않도록 완벽하게 통제하면서 분석을 수행할 수 있다.
  • 비용 효율
    • API 비용 구조:
      • GPT-4 Turbo: $10/1M input tokens, $30/1M output tokens
      • Claude 3.5 Sonnet: $3/$15
      • 대규모 코드베이스를 반복 분석 시 월간 수천 달러 발생 가능
    • 자체 호스팅 모델:
      • RAG는 질문에 가장 관련된 코드 조각만 선별하여 LLM에 전달하므로, API 토큰 사용량을 크게 줄일 수 있음

1.3.1.3 반대 관점: “범용 AI로 충분하다”는 주장

  • Prompt Engineering의 발전
    • Wei et al. (2022, “Chain-of-Thought Prompting”)에 따르면 적절한 프롬프트로 복잡한 reasoning 유도 가능
    • OpenAI의 System Message, Anthropic의 Constitutional AI로 행동 양식 조정 가능
  • 컨텍스트 윈도우 확장 추세
    • Gemini 1.5의 1M 토큰, Claude 3.5의 200K 토큰은 대부분의 단일 레포지토리를 커버
    • Anthropic (2024) 보고서: 실제 사용자의 95%가 100K 토큰 이하 사용
    • 100k~1M 토큰 컨텍스트, 레포 전체 인덱싱 + cross-file reasoning, AST 기반 분석 내장, IDE와 깊은 통합
  • 개발 및 유지보수 비용
    • 특화 Agent 개발: 최소 3-6개월 (설계, 구현, 테스트)
    • 모델 업데이트, 인프라 관리, 온콜 대응 등 지속 비용
    • Gartner (2023) 추정: 사내 AI 시스템의 TCO가 클라우드 API의 3-5배
  • 반박: RAG을 사용해야함
    • 컨텍스트 윈도우가 크더라도 “Lost in the Middle” 현상으로 실질적 활용률 저하
    • Prompt engineering은 재현성(reproducibility)과 일관성 문제 존재
    • TCO 비교는 규모와 사용 빈도에 따라 역전 가능 (breakeven point 분석 필요)

1.3.2 범용 vs. 특화 비교표

특징 범용 AI 솔루션 (ChatGPT, Copilot) 사용자 지정 RAG Agent
지식 범위 광범위하고 일반적 (학습 데이터 기반) 특정 코드베이스와 내부 문서에 특화
최신성 학습 시점에 따라 정적일 수 있음 RAG를 통해 실시간/최신 데이터 반영 가능
보안 외부 API에 코드 노출 위험 내부 네트워크에 구축하여 보안 통제 가능
자동화 코딩 지원에 중점 분석 후 자동 PR 생성, 테스트 실행 등 복잡한 액션 가능
비용 장문/반복 분석 시 토큰 비용 부담 RAG로 관련 컨텍스트만 전달하여 비용 최적화 가능

1.3.3 쓸모 있는 Agent의 정의

  • 불필요한 Agent: “이 GitHub 레포 코드 설명해줘” 또는 “깃헙 코드 읽어주는 agent”
  • 의미 있는 Agent: “이 레포의 알고리즘이 어떤 설계 가정 위에 있고, 어떤 변경 이력을 거쳐, 어떤 리스크를 가지며, 어떤 문서에 의해 정당화되는지 조직 기준으로 설명해줘”

이때 Agent의 역할은 분석가 + 감사 대응자 + 지식 통합자다.

1.3.4 전략적 판단을 위한 체크리스트

  • Q1. 이 분석 결과에 조직이 책임을 져야 하는가?
    • 아니오 → 기존 LLM 충분
    • 예 → Agent 필요
  • Q2. 코드 외 문서가 핵심 판단 근거인가?
    • 아니오 → 기존 LLM 충분
    • 예 → Agent 필요
  • Q3. 동일 질문이 반복적으로 발생하는가?
    • 아니오 → adhoc 질의
    • 예 → 지식 시스템화 가치 있음

1.3.5 특화 Agent의 한계 및 불확실성

  • 대부분 연구가 영어 코드베이스 중심 (한국어 주석 환경에서의 효과는 불명확)
  • 실제 기업 환경에서의 ROI 측정 연구 부족 (대부분 학계 벤치마크)
  • GPT-5, Claude 4 등 차세대 모델의 발전 속도가 빠르므로 현재 격차가 축소될 가능성
  • Long-context LLM의 실질적 성능: 이론적 컨텍스트 윈도우 vs 실제 정보 활용 능력의 간극이 여전히 연구 중
  • Agentic AI의 신뢰성: ReAct, AutoGPT 등의 다단계 추론 시스템이 production 환경에서 얼마나 안정적인지 장기 데이터 부족
  • 실제 엔터프라이즈 환경에서의 범용 AI vs 특화 Agent RCT(Randomized Controlled Trial) 부재
  • 한국어 코멘트 + 영어 코드 혼합 환경에서의 성능 비교 연구 필요
  • Agent 유지보수 비용에 대한 장기 추적 연구 필요

1.3.6 최종 결론

본 프로젝트 상황(높은 턴오버로 인한 알고리즘 블랙박스 문제)에서는 특화 Agent 개발이 정당화된다.

정당화 근거:

  1. 명확한 pain point: 조직 특수성(내부 프레임워크, 과거 의사결정 맥락)을 범용 AI가 모름
  2. 보안 요구사항: 헬스케어 도메인에서 코드 외부 전송 리스크
  3. 반복적 사용: 일회성이 아닌 지속적 코드 분석 필요성
  4. “코드 읽기용 agent”가 아닌 “조직 기억 + 책임 추론용 agent”가 필요
  5. RAG의 대상은 코드가 아니라 의사결정의 흔적을 추적할 때 의미가 있음

고려사항:

  • 하이브리드 접근: 범용 AI (GPT-4)를 백엔드 LLM으로 사용하되, RAG + Tools로 augment하는 방식이 현실적
  • 투자 대비 효과 측정: 개발 전 pilot으로 범용 AI 대비 정량적 개선 확인
  • 장기 유지보수 전략: 모델 업데이트, 프롬프트 드리프트 대응 계획 필수

핵심 원리:

  • 사용자 지정 RAG + Agent는 단순히 존재하는 솔루션을 모방하는 것이 아니다.
  • 특정 조직/프로젝트의 필요에 맞춰 정확도, 보안, 자동화 수준을 극대화하는 전략적인 고도화 작업이다.
  • LLM 시대에 살아남는 Agent는 똑똑하게 읽는 도구가 아니라 조직이 기억하고 설명할 수 있게 만드는 장치다.
  • 만들 가치가 있는지는 기술 문제가 아니라 책임 구조의 문제다.

1.4 수행전략

  • 코드 분석기 Agent 개발은 단순한 코딩이 아닌, 조직 지식의 구조화와 고도화된 추론 능력 확보를 목표
  • 각 단계는 RAG의 기본 구현에서 시작하여 Tool-use 기반의 복잡한 추론 능력 확보로 이어진다.

코드 분석기 agent를 개발
- phase1(3개월): 지식 기반 구축 및 Factual RAG 구현 (기반 다지기)
* RAG 기본 엔진 구축: 코드베이스, 설계 문서, PR/이슈 기록 등 내부 문서 소스 수집 및 정제 (Chunking, Metadata).
* 산출물: 조직 특화 Knowledge Base (KB) 구축 완료
* Vector DB 및 적합한 임베딩 모델(Embedding Model) 선정 및 구축.
* 산출물: 코드 및 내부 문서에 대한 일반 질의응답 (Factual RAG) Agent 프로토타입
* 단순 코드 요약, 함수/클래스 정의 설명 등 범용 LLM이 커버하는 영역에서 정확도 및 속도 벤치마킹 (Baseline 확보).
* 기본 RAG Agent의 정확도(Factual Accuracy) 검증 리포트
- phase2(3개월): 도메인 전문가 및 개발자의 요구사항을 반영한 고도화 tool을 개발하여 특화 agent 개발
* Tool 개발: 실무진 Needs에 맞는 Tool 개발
* 산출물: 실무진 요구사항
* Tool-use 통합: RAG + Tools 구현
* 산출물: Tool-use 기능 (정적 분석, 코드 추적) 통합 및 검증 완료
* 고급 추론 기능 구현: ReAct (Reasoning + Action) 패러다임을 적용하여 다단계 추론 및 자기 수정(Self-Correction) 로직 개발.
* 산출물: 알고리즘 분석 및 추론 Agent (병목 지점 식별, 로직 흐름 설명 등)
* 지식 통합: 과거 결정 이력(ADR, PR 히스토리) 검색 기능을 고도화하여 알고리즘의 ‘의도와 제약’까지 재현 가능하게 함.
* 산출물: 의사결정 근거 추적 기능 및 내부 합의 사항 반영.
- phase3(3개월): phase1,2에서 얻은 lesson & learn 기반으로 타부서로 서비스 범위 확장
* 보안 및 통제 강화: Agent가 내부 서버/보안 클라우드 환경에서만 작동하도록 시스템 배포 및 보안 감사 추적 기능 내재화.
* 산출물: 보안 통제 환경에서 작동되는 Agent 구현
* 비용 효율성 입증: Agent도입전/후 비교 생산성 및 만족도 조사 및 평가
* 산출물: 평가 지표에 의한 보고서
* 서비스 확장: Phase 1, 2에서 얻은 Lesson & Learn 기반으로 타 부서의 코드/규제/운영 문서 등 타 도메인으로 서비스 범위 확장
* 산출물: 전사적 지식 플랫폼으로의 확장 로드맵 제시

1.5 기대효과

본 특화 Agent 개발을 통해 단기적인 현상 해결을 넘어, 조직의 지적 자산을 강화하고 기술 부채를 근본적으로 해소하는 장기적인 효과를 기대

  1. 지식 연속성 및 조직 효율성 강화 (Business & Organization)
  • 암묵지 형식지화: 숙련자의 머릿속에만 있던 알고리즘의 의도, 제약, 과거 결정 근거를 Agent를 통해 형식지화하여 지식 플랫폼에 통합
  • 이탈 리스크 완화: 실무자 이탈 시 알고리즘이 블랙박스화되는 문제를 원천적으로 방지하여, 지적 재산의 파산 리스크를 근본적으로 해소
  • 온보딩 시간 단축: 신규 개발자가 복잡한 도메인 지식과 코드를 이해하는 데 걸리는 시간을 최소 30% 이상 단축하여 빠른 생산성 확보를 지원
  • 협업 비용 절감: SW 개발자와 도메인 전문가 간의 명확한 지식 수준 차이를 Agent가 중재하여 커뮤니케이션 비용을 절감
  1. 기술적 정확도 및 신뢰성 확보 (Technical & Accuracy)
  • 환각(Hallucination) 현상 극복: RAG를 통해 범용 LLM 대비 Factual Accuracy를 30~40% 이상 향상시켜 신뢰도 높은 분석 결과를 제공
  • 고급 추론 및 검증: Tool-use를 통합하여 단순 코딩 지원을 넘어 정적 분석 도구 연동, 호출 그래프 추적 등 복잡한 검증 작업과 자동화된 분석을 수행
  • 책임 기반 답변: 생성된 답변에 내부 문서 및 코드의 출처를 명확히 명시함으로써, 분석 결과에 대한 법적·조직적 책임 추적 가능성을 확보하고 감사 대응에 활용
  1. 보안 및 비용 통제 (Risk & Cost Efficiency)
  • 보안 리스크 완벽 차단: 비공개(Proprietary) 코드베이스를 외부 범용 AI API로 전송하지 않고 내부 네트워크 환경에서 분석하므로, 금융/헬스케어 등 고보안 도메인의 코드 유출 리스크를 원천적으로 통제
  • 운영 비용 최적화: 대규모 코드베이스에 대한 반복적인 분석 시, RAG가 질문과 관련된 핵심 컨텍스트만 선별하여 LLM에 전달하므로, 범용 LLM API 사용 대비 토큰 비용을 획기적으로 절감할 수 있습니다. (장기적인 TCO 관점에서 유리)

Subscribe

Enjoy this blog? Get notified of new posts by email: