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” 현상으로 실질적 활용률 저하
- 실제 활용 가능 토큰은 이론치의 60-70% 수준 (Li et al., 2023, “Lost in the Middle”)
- 조직 특화 지식 부재: 범용 LLM은 다음에만 의존
- 훈련 데이터
- 사용자 입력
- 임시 컨텍스트
- 훈련 데이터
- 반면 조직의 현실은 다층 지식 결합이 필요
- 코드, 설계 문서, 변경 이력, 규제 문서, 리뷰 코멘트, 내부 합의 사항, GitHub 저장소의 코드베이스, 아키텍처 패턴, 내부 문서, 개발 팀의 컨벤션, 과거 PR 및 이슈 기록
- 범용 모델은 조직의 코딩 컨벤션, 내부 프레임워크, 아키텍처 패턴에 대한 사전 지식이 없으며, Few-shot learning으로 보완 가능하나 매 세션마다 반복 설명이 필요하다 (context overhead).
- 코드, 설계 문서, 변경 이력, 규제 문서, 리뷰 코멘트, 내부 합의 사항, GitHub 저장소의 코드베이스, 아키텍처 패턴, 내부 문서, 개발 팀의 컨벤션, 과거 PR 및 이슈 기록
- 보안 및 거버넌스 문제
- 기업이나 팀이 비공개(Proprietary) 코드를 분석해야 할 경우, 외부의 범용 AI 모델(ChatGPT 등) API에 코드를 전송하는 것은 보안상 큰 위험이다.
- 외부 API 전송 시 코드 유출 리스크 (특히 금융, 헬스케어, 국방 도메인)
- GDPR, HIPAA, ISO 27001 준수 요구사항과 충돌 가능
- 일부 기업은 정책적으로 외부 AI API 사용 금지 (Goldman Sachs, Samsung 사례)
- 기업이나 팀이 비공개(Proprietary) 코드를 분석해야 할 경우, 외부의 범용 AI 모델(ChatGPT 등) API에 코드를 전송하는 것은 보안상 큰 위험이다.
- 비용 효율성
- 대규모 코드베이스에 대해 반복적인 분석을 수행할 때, 모든 컨텍스트를 범용 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% 향상
- 배경: 대규모 사전 학습 언어 모델의 우수한 성능으로 활용성 증가, 집약적 지식으로 접근의 한계, 근거 출처(Provenance) 및 업데이트 한계
- RAG (검색 증강 생성)의 기본 개념은 여전히 유효할 뿐만 아니라, 2025년 현재 LLM을 실제 기업 환경에 도입하는 데 있어 가장 중요하고 표준적인 기술
- 실시간/최신 정보를 바탕으로 정확하고 사실에 근거한 분석 수행
- “이 함수가 어디에서 호출되는지”, “이 버그는 과거 어떤 PR에서 수정되었는지”와 같은 질문에 답변 가능
- 알고리즘의 의도와 제약을 재현 가능
- Lewis et al. (2020, “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”)
- 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% 개선
- 배경: 오픈소스 LLM의 한계로 LLaMA와 같은 오픈소스 LLM은 기본적인 언어 작업에서는 발전했지만, 외부 도구(API)를 사용하여 사용자 지침을 이행하는 도구 사용 능력이 크게 부족하다는 것을 지적
- 정적 분석 도구(Static Analyzers)를 사용해 호출 그래프(Call Graph)나 제어 흐름 그래프(Control Flow Graph)를 작성하는 등의 코드 특화 분석 작업을 에이전트의 툴로 통합할 수 있다.
- Static analysis tools (SonarQube, PMD), 실행 추적, 프로파일러 결과를 직접 연동
- 컴파일러, 테스트 프레임워크, 코드 포매터(Formatter)와 같은 외부 도구를 호출하여 코드를 검증하고 수정
- 범용 AI는 이런 도구 출력을 해석만 가능, 직접 실행 불가능
- Static analysis tools (SonarQube, PMD), 실행 추적, 프로파일러 결과를 직접 연동
- Zhang et al. (2024, “ToolLLM”) 연구
- Reasoning + Action 루프
- RAG + Tools + Reasoning + Action 구조는 단순한 질의응답을 넘어 복잡한 작업의 자동화를 가능하게 한다.
- ReAct 패러다임 (Yao et al., 2023, NeurIPS): 사고 과정과 행동을 반복적으로 수행
- 알고리즘 복잡도 분석 → 코드 실행 → 병목 지점 식별 → 최적화 제안의 순차적 워크플로우 자동화
- “이 알고리즘에서 잠재적인 성능 병목 현상을 찾아라” (추론) → “병목 현상을 해결하는 코드를 자동으로 수정하여 PR 초안을 생성해라” (액션)
- 범용 AI는 이를 다단계 프롬프팅으로 처리해야 하며 context coherence 저하
- ReAct 패러다임 (Yao et al., 2023, NeurIPS): 사고 과정과 행동을 반복적으로 수행
- RAG + Tools + Reasoning + Action 구조는 단순한 질의응답을 넘어 복잡한 작업의 자동화를 가능하게 한다.
- 도메인 특화 내/외부 지식 통합 가능: RAG는 내부/사설 지식(코드, 문서, 로그, 내부 문서, 과거 코드 리뷰, 아키텍처 결정 기록(ADR), PR 히스토리, Jira / Notion, 설계 변경 이유, Deprecated 결정 근거) 등을 벡터 스토어에서 검색하여 LLM에 프롬프트로 제공한다.
- 특화 Agent의 이점: 규제·검증·감사 대응
- 규제가 필요한 산업: 의료/바이오 (FDA), 금융 (모델 리스크 관리), 제조 (안전 알고리즘), 공공 (감사 추적)
- “이 알고리즘은 이런 이유로 이렇게 동작한다”
- “이 변경은 이 문서에 근거한다”
- “이 수치는 이 로직에서 나온다”
- 출처 추적 + 재현성 + 설명 책임
- “이 알고리즘은 이런 이유로 이렇게 동작한다”
- 기존 LLM은 법적·조직적 책임 주체가 될 수 없다.
- 규제가 필요한 산업: 의료/바이오 (FDA), 금융 (모델 리스크 관리), 제조 (안전 알고리즘), 공공 (감사 추적)
- 보안 통제
- 사용자 지정 RAG 에이전트는 내부 서버나 보안이 있는 클라우드 네트워크 환경에 구축할 수 있어, 코드가 외부로 유출되지 않도록 완벽하게 통제하면서 분석을 수행할 수 있다.
- 사용자 지정 RAG 에이전트는 내부 서버나 보안이 있는 클라우드 네트워크 환경에 구축할 수 있어, 코드가 외부로 유출되지 않도록 완벽하게 통제하면서 분석을 수행할 수 있다.
- 비용 효율
- API 비용 구조:
- GPT-4 Turbo: $10/1M input tokens, $30/1M output tokens
- Claude 3.5 Sonnet: $3/$15
- 대규모 코드베이스를 반복 분석 시 월간 수천 달러 발생 가능
- GPT-4 Turbo: $10/1M input tokens, $30/1M output tokens
- 자체 호스팅 모델:
- RAG는 질문에 가장 관련된 코드 조각만 선별하여 LLM에 전달하므로, API 토큰 사용량을 크게 줄일 수 있음
- API 비용 구조:
1.3.1.3 반대 관점: “범용 AI로 충분하다”는 주장
- Prompt Engineering의 발전
- Wei et al. (2022, “Chain-of-Thought Prompting”)에 따르면 적절한 프롬프트로 복잡한 reasoning 유도 가능
- OpenAI의 System Message, Anthropic의 Constitutional AI로 행동 양식 조정 가능
- Wei et al. (2022, “Chain-of-Thought Prompting”)에 따르면 적절한 프롬프트로 복잡한 reasoning 유도 가능
- 컨텍스트 윈도우 확장 추세
- Gemini 1.5의 1M 토큰, Claude 3.5의 200K 토큰은 대부분의 단일 레포지토리를 커버
- Anthropic (2024) 보고서: 실제 사용자의 95%가 100K 토큰 이하 사용
- 100k~1M 토큰 컨텍스트, 레포 전체 인덱싱 + cross-file reasoning, AST 기반 분석 내장, IDE와 깊은 통합
- Gemini 1.5의 1M 토큰, Claude 3.5의 200K 토큰은 대부분의 단일 레포지토리를 커버
- 개발 및 유지보수 비용
- 특화 Agent 개발: 최소 3-6개월 (설계, 구현, 테스트)
- 모델 업데이트, 인프라 관리, 온콜 대응 등 지속 비용
- Gartner (2023) 추정: 사내 AI 시스템의 TCO가 클라우드 API의 3-5배
- 특화 Agent 개발: 최소 3-6개월 (설계, 구현, 테스트)
- 반박: RAG을 사용해야함
- 컨텍스트 윈도우가 크더라도 “Lost in the Middle” 현상으로 실질적 활용률 저하
- Prompt engineering은 재현성(reproducibility)과 일관성 문제 존재
- TCO 비교는 규모와 사용 빈도에 따라 역전 가능 (breakeven point 분석 필요)
- 컨텍스트 윈도우가 크더라도 “Lost in the Middle” 현상으로 실질적 활용률 저하
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 필요
- 아니오 → 기존 LLM 충분
- Q2. 코드 외 문서가 핵심 판단 근거인가?
- 아니오 → 기존 LLM 충분
- 예 → Agent 필요
- 아니오 → 기존 LLM 충분
- Q3. 동일 질문이 반복적으로 발생하는가?
- 아니오 → adhoc 질의
- 예 → 지식 시스템화 가치 있음
- 아니오 → 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 개발이 정당화된다.
정당화 근거:
- 명확한 pain point: 조직 특수성(내부 프레임워크, 과거 의사결정 맥락)을 범용 AI가 모름
- 보안 요구사항: 헬스케어 도메인에서 코드 외부 전송 리스크
- 반복적 사용: 일회성이 아닌 지속적 코드 분석 필요성
- “코드 읽기용 agent”가 아닌 “조직 기억 + 책임 추론용 agent”가 필요
- 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 개발을 통해 단기적인 현상 해결을 넘어, 조직의 지적 자산을 강화하고 기술 부채를 근본적으로 해소하는 장기적인 효과를 기대
- 지식 연속성 및 조직 효율성 강화 (Business & Organization)
- 암묵지 형식지화: 숙련자의 머릿속에만 있던 알고리즘의 의도, 제약, 과거 결정 근거를 Agent를 통해 형식지화하여 지식 플랫폼에 통합
- 이탈 리스크 완화: 실무자 이탈 시 알고리즘이 블랙박스화되는 문제를 원천적으로 방지하여, 지적 재산의 파산 리스크를 근본적으로 해소
- 온보딩 시간 단축: 신규 개발자가 복잡한 도메인 지식과 코드를 이해하는 데 걸리는 시간을 최소 30% 이상 단축하여 빠른 생산성 확보를 지원
- 협업 비용 절감: SW 개발자와 도메인 전문가 간의 명확한 지식 수준 차이를 Agent가 중재하여 커뮤니케이션 비용을 절감
- 기술적 정확도 및 신뢰성 확보 (Technical & Accuracy)
- 환각(Hallucination) 현상 극복: RAG를 통해 범용 LLM 대비 Factual Accuracy를 30~40% 이상 향상시켜 신뢰도 높은 분석 결과를 제공
- 고급 추론 및 검증: Tool-use를 통합하여 단순 코딩 지원을 넘어 정적 분석 도구 연동, 호출 그래프 추적 등 복잡한 검증 작업과 자동화된 분석을 수행
- 책임 기반 답변: 생성된 답변에 내부 문서 및 코드의 출처를 명확히 명시함으로써, 분석 결과에 대한 법적·조직적 책임 추적 가능성을 확보하고 감사 대응에 활용
- 보안 및 비용 통제 (Risk & Cost Efficiency)
- 보안 리스크 완벽 차단: 비공개(Proprietary) 코드베이스를 외부 범용 AI API로 전송하지 않고 내부 네트워크 환경에서 분석하므로, 금융/헬스케어 등 고보안 도메인의 코드 유출 리스크를 원천적으로 통제
- 운영 비용 최적화: 대규모 코드베이스에 대한 반복적인 분석 시, RAG가 질문과 관련된 핵심 컨텍스트만 선별하여 LLM에 전달하므로, 범용 LLM API 사용 대비 토큰 비용을 획기적으로 절감할 수 있습니다. (장기적인 TCO 관점에서 유리)