월간 보고서로부터 작업 목록 생성을 자동화하기 위한 로컬 LLM 에이전트 구축 방법 (Jira 연동 포함)

저희 경영진은 수십 개의 개발자 보고서에서 작업 항목("버그 수정(bug fix)", "버전 1 출시(released version 1)" 등)을 수동으로 추출하는 데 수 시간을 소비했습니다. 이 작업은 반복적이고 오류가 발생하기 쉬우며, 클라우드 기반 AI 도구를 사용할 경우 내부 활동을 외부 서버에 노출하게 되므로 보안 위험이 있었습니다. 이를 해결하기 위해, 저희는 자체 서버에서 완전히 실행되며, 혼란스러운 보고서 데이터를 정규화(normalize)하고, 불필요한 노이즈를 필터링하며, Jira에서 설명을 보강하고, 실제 성과에 대한 깔끔한 목록을 생성하는 로컬 LLM 기반 에이전트를 구축했습니다. 이 글에서는 아키텍처를 분석하고, 데이터 프라이버시를 우선시하는 기업 고객에게 왜 CPU 전용 온프레미스(on-premise) 접근 방식이 실용적인지 설명합니다.

문제점: 수동 작업 목록 생성은 느리고, 일관성이 없으며, 안전하지 않습니다.
보통 저희 매니저들은 동일한 루틴을 따랐습니다: 한 달 치의 개발자 보고서를 수집하고, 수백 개의 항목을 수동으로 훑어보며, 실제로 완료된 작업을 나타내는 항목을 골라내는 것입니다. 이 프로세스는 단순했지만 결함이 있었습니다.

첫 번째 문제는 데이터 품질(data quality)이었습니다. 개발자들은 매우 다양한 형식으로 보고서를 작성합니다. 어떤 이들은 상세한 Jira 티켓 ID와 설명을 포함하지만, 다른 이들은 "이슈 수정(fixed issue)"과 같은 모호한 한 줄 문장으로 작성합니다. 프로젝트에 깊이 관여하지 않았던 매니저가 나중에 이 보고서들을 검토할 때, 그 의미가 상실되는 경우가 많습니다. "헤더 조정(adjusted header)"은 무엇을 의미할까요? "코드 리팩토링(refactored code)"은 어떤 기능에 영향을 주었을까요? 저희에게 정말로 필요했던 것은 이러한 비정형 데이터(unstructured data)를 자동으로 처리할 수 있는 AI 기반 작업 관리 방식이었습니다.

두 번째 문제는 중복 작업(duplicate work)이었습니다. 매니저들은 가끔 이전 달에 이미 선언된 작업을 포함하여 중복을 만들기도 했습니다. 또 다른 예로는 며칠에 걸쳐 진행되는 작업이 있습니다. 이 경우 동일한 활동이 반복적으로 기록되어 거의 동일한 항목이 많이 생성될 수 있습니다. 새로운 보고서를 과거 데이터와 비교할 자동화된 방법이 없었습니다.

세 번째 문제는 보안(security)이었습니다.

처음에는 월간 보고서 전체를 ChatGPT에 입력하고, 데이터를 정리하여 최종 목록을 제안하도록 요청하는 방식으로 실험했습니다. 결과는 상당히 괜찮았지만, 한 달 치의 내부 프로젝트 활동 데이터를 클라우드 서비스에 그대로 넘겨주는 셈이었습니다. 금융이나 의료 분야와 같은 많은 기업용 비즈니스(enterprise businesses)의 경우, 이러한 수준의 데이터 노출은 허용될 수 없습니다.

해결책: 보고서 작업 추출을 위한 보안이 강화된 온프레미스 (On-Premise) AI 에이전트

우리의 접근 방식은 보고서를 작업(task)으로 자동 변환하는 콘솔 기반 애플리케이션을 구현하는 것이었습니다. 이 애플리케이션은 내부 서버에서 실행되며, 매월 보고 주기 끝에 크론 잡 (cron job) 또는 선택적인 API 호출에 의해 트리거됩니다. AI 에이전트는 각 활성 프로젝트의 원시 보고서를 처리하고, 일련의 변환 과정을 적용하여 정제된 작업 항목 목록을 출력합니다. 전체 파이프라인은 Ollama를 사용하여 Gemma 4 E2B 모델의 로컬 인스턴스를 서빙하며, CPU 전용 서버에서 실행됩니다. 임베딩 생성 (중복 탐지에 사용됨)을 위해 우리는 크기가 불과 몇 메가바이트에 불과한 tiny nomic-embed-text 모델을 사용합니다. 다음은 프로세스 흐름의 상위 수준 개요입니다:

각 단계를 자세히 살펴보겠습니다.

1. 정규화 (Normalization): 혼돈을 읽기 쉽게 만들기
   단일 프로젝트는 상세 수준이 제각각인 80개 이상의 개별 보고서를 한 달 동안 받을 수 있습니다. 우리 AI 에이전트의 첫 번째 작업은 이러한 이질적인 입력값들을 일관되고 기계가 읽을 수 있는 형식으로 정규화하는 것이었습니다. 이 단계만으로도 자유 형식의 텍스트 뭉치를 나머지 파이프라인이 안정적으로 처리할 수 있는 구조화된 데이터로 변환할 수 있습니다.

2. 청킹 (Chunking): 토큰 제한 내에서 작업하기
   이 지점에서 우리는 첫 번째 주요 기술적 제약에 부딪혔습니다. Ollama를 통해 CPU에서 실행되는 우리의 Gemma 4 모델은 4,096 토큰의 컨텍스트 창 (context window)으로 제한됩니다. 이는 그리 많은 양이 아닙니다. 바쁜 프로젝트의 한 달 치 보고서는 이 수치를 쉽게 초과할 수 있습니다. 우리는 청킹 (chunking)을 통해 이 문제를 해결했습니다. AI 시스템은 결합된 보고서 텍스트의 대략적인 토큰 수를 계산하고, 이를 약 20개의 보고서씩 배치 (batch)로 나눕니다.

이를 통해 LLM (Large Language Model)이 컨텍스트 공간 (context space)을 초과하지 않도록 보장하며, 각 청크 (chunk)가 충분한 주의 (attention)를 받을 수 있도록 합니다. 각 청크 내에서도 한 줄에 여러 작업이 포함된 항목(예: “A를 했고, B를 했으며, C를 함”)은 추가로 분할합니다. 이러한 분할 과정을 거친 결과, 테스트 실행 중 하나에서 22개의 원시 보고서가 94개의 개별 작업 항목으로 변환되었습니다.

3. Jira Enrichment: 누락된 컨텍스트 추가
   우리 AI 에이전트의 가장 가치 있는 기능 중 하나는 Jira로부터 추가적인 컨텍스트를 자동으로 가져오는 능력입니다. 시스템이 보고서에서 Jira 티켓 ID를 감지하면, Jira API를 호출하여 티켓 설명 (description)을 가져옵니다. 개발자들은 종종 티켓 ID만 있으면 충분하다고 가정하고 보고서를 간결하게 작성하곤 합니다. 하지만 해당 보고서가 나중에 “AAA-123 – 완료”와 같이 나타나면 아무런 정보도 전달하지 못합니다. Jira에서 관리자가 작성한 전체 설명을 가져옴으로써, 우리 AI 에이전트는 모호한 항목을 실제로 무엇을 달성했는지에 대한 명확하고 전문적인 요약으로 대체합니다.

4. 노이즈 필터링 (Filtering Out the Noise)
   모든 보고서 항목이 포함될 가치가 있는 것은 아닙니다. “~ 작업 중...” 또는 “후속 조치 중”과 같은 일반적인 문구는 의미 있는 업무를 전달하지 못합니다. 우리는 지능형 문서 처리 (IDP, Intelligent Document Processing) 파이프라인의 핵심 구성 요소 중 하나인 불필요한 단어 필터 (bad-word filter)를 구축했습니다. 이 필터는 이러한 모호한 문구가 포함된 항목을 표시합니다. LLM은 각 청크를 처리하며 제외 목록 (exclusion list)과 일치하는 데이터를 식별합니다. 테스트 결과, 이 필터는 항목의 69.1%를 제거했으며 94개 중 29개의 항목만이 필터링을 통과했습니다. 남은 항목들은 완료된 작업에 대한 구체적이고 명확한 설명들이었습니다.

5. 최적의 후보 선정
   정제된 후보 세트가 확보되면, 제시할 상위 N개의 항목을 선택해야 합니다. N의 숫자는 프로젝트마다 다르며 우리의 내부 보고 데이터베이스에 저장됩니다. 다음 단계에서의 추가 필터링을 고려하여, 우리는 보통 80개와 같이 더 큰 풀 (pool)을 선택합니다.

6. 벡터 중복 탐지 (Vector Duplicate Detection): 반복 방지
   이것은 중복 항목이 발생하는 것을 방지하는 비법 (secret sauce)입니다.

목록을 확정하기 전에, AI 에이전트는 각 후보 항목을 해당 프로젝트를 위해 우리가 제출했던 모든 작업 항목의 이력 데이터베이스 (historical database)와 비교합니다. 작동 방식은 다음과 같습니다: 임베딩 생성 (Embedding Generation). 각 작업 항목은 nomic‑embed‑text 모델을 사용하여 벡터 (vector, 숫자 리스트)로 변환됩니다. 이 벡터는 텍스트의 의미론적 의미 (semantic meaning)를 포착합니다; 유사도 계산 (Similarity Calculation). 시스템은 새로운 후보의 벡터를 해당 프로젝트에 대해 이전에 저장된 모든 데이터의 벡터와 비교합니다; 임계값 결정 (Threshold Decision). 유사도 점수가 0.85 (85%)를 초과하면, 해당 후보는 중복으로 표시되어 제거됩니다. 이 임계값은 정확히 일치하는 항목뿐만 아니라, 근본적인 아이디어는 동일하지만 문구 나 단어 순서가 바뀐 유사 중복 항목 (near‑duplicates)까지 잡아냅니다. 이력 데이터는 project_id, text (최종 설명), embedding (벡터), 그리고 created_at (생성 날짜)라는 몇 개의 필드만 포함된 경량 PostgreSQL 테이블에 저장됩니다. 중복 제거를 거치면, 진정으로 고유하고 품질이 높은 작업 항목 세트만 남게 됩니다. 이 항목들은 이후 프로젝트 매니저에게 최종 전달될 수 있도록 형식이 지정됩니다.

실제 성능: 테스트 실행이 말해주는 것
수치가 실제로 어떻게 작동하는지 확인하기 위해 실제 테스트 실행 과정을 살펴보겠습니다. 이 테스트 실행 결과는 AI 보고서 분석 도구가 노이즈가 많고 일관되지 않은 입력값이 있더라도 보고서를 작업(task)으로 어떻게 요약할 수 있는지를 보여줍니다.

기술적 심층 분석: CPU 전용 배포가 작동하는 이유
로컬 LLM을 실행할 때 가장 흔한 반대 의견 중 하나는 값비싼 GPU 하드웨어가 필요하다는 인식입니다. 우리는 비용을 관리 가능한 수준으로 유지하고, 온프레미스 (on-premise) AI가 상당한 인프라 투자를 필요로 하지 않는다는 것을 증명하기 위해 의도적으로 CPU 전용 배포를 선택했습니다.

모델 선택: Gemma 4 E2B
우리는 여러 로컬 모델을 평가한 끝에 Gemma 4 E2B를 선택했습니다. 그 이유는 다음과 같습니다:
크기 (Size). 50억 개의 파라미터 (5 billion parameters) 규모로, GPU 없이도 RAM에 여유롭게 들어갑니다. 우리 서버에는 모델을 위해 특별히 할당된 추가 메모리가 있습니다.
성능 (Performance). 배치 처리 (batch processing)를 수행하기에 충분히 빠릅니다.
품질 (Quality).

모델은 JSON 출력을 안정적으로 처리하며, 최소한의 환각 (hallucination)으로 상세한 프롬프트 (prompt)를 따릅니다. 참고: 다국어 팀과 협업하는 경우, 사용하는 모델이 대상 언어를 모국어 수준으로 이해하는지 확인해야 합니다.

일관성을 위한 적절한 모델 설정 및 프롬프트 엔지니어링 (Prompt Engineering)
각 파이프라인 단계에는 다음과 같은 내용이 포함된 정교하게 설계된 자체 프롬프트가 있습니다:

• 명확한 역할 정의 (예: "당신은 전문 데이터 파싱 엔진입니다")
• 기대되는 출력의 좋은 예시와 나쁜 예시
• 명시적인 형식 규칙 (JSON 구조, 필드 이름)
• 창의성을 배제하기 위한 지침 (temperature를 0으로 설정)

금칙어 필터 (bad-word filter)를 위해, 우리는 금지된 용어와 그 유의어 목록을 제공합니다: "working on", "following up", "in progress", "discussed" 등. LLM은 단순히 의미론적 이해 (semantic understanding)를 갖춘 패턴 매처 (pattern matcher) 역할을 수행합니다. 예를 들어, "still working on the header"가 개념적으로 "in progress"와 유사하다는 것을 인식하고 그에 따라 플래그를 표시할 수 있습니다. 또한, 이와 같은 데이터 처리 작업의 경우

1. 완전한 데이터 주권 (Data Sovereignty) 온프레미스 (On-premise) 인공지능 솔루션을 사용하면 데이터가 인프라 외부로 절대 유출되지 않습니다. LLM (Large Language Model)은 로컬에서 실행되고, 임베딩 모델 (Embedding model)도 로컬에서 실행되며, 히스토리 데이터베이스는 자체 PostgreSQL 서버에 상주합니다.

2. 벤더 종속성 탈피 (No Vendor Lock-in) 클라우드 AI 서비스는 예고 없이 가격을 변경하거나, 모델을 지원 중단(Deprecate)하거나, API를 수정합니다. 로컬 AI 에이전트와 Ollama를 사용하면 전체 스택에 대해 완전한 제어권을 유지할 수 있습니다. 내일 당장 다른 모델로 교체해야 하나요? 그저 새로운 모델을 풀(Pull)하고 설정만 업데이트하면 됩니다.

3. 예측 가능한 비용 (Predictable Costs) 지속적으로 발생하는 유일한 비용은 서버를 가동하는 전기료뿐입니다. 토큰당 API 비용, 월간 구독료, 혹은 업무량이 많았던 달에 발생하는 예상치 못한 청구서가 없습니다. 매년 수천 개의 보고서를 처리하는 조직의 경우, 절감되는 비용은 상당합니다.

4. 워크플로우 맞춤화 (Customizable to Your Workflow) 코드를 직접 소유하고 있기 때문에, 파이프라인을 특정 보고 형식에 맞게 조정하고, 기존 프로젝트 관리 도구와 통합하며, 산업별 용어에 맞춰 프롬프트 (Prompt)를 미세 조정 (Fine-tune)할 수 있습니다. 이를 통해 건설에서 의료에 이르기까지 다양한 분야에서 비즈니스 프로세스 자동화 (Business process automation)를 위해 AI를 활용할 수 있습니다.

수동 작업에서 자동화된 정밀함으로 (From Manual Chore to Automated Precision) 이전에는 혼란스러운 개발자 노트를 깔끔한 보고서로 바꾸기 위해 지루한 수동 작업과 민감한 데이터를 클라우드 AI에 노출하는 것 중 하나를 선택해야 했습니다. 문서 분석을 위한 우리의 프라이빗 AI 에이전트는 제3의 길을 제시합니다. 바로 안전한 온프레미스 자동화입니다. 표준 CPU 하드웨어에서 구동되는 Gemma 4를 벡터 기반 중복 탐지 및 직접적인 Jira 데이터 보강 (Enrichment)과 결합함으로써, 우리는 매달 몇 시간씩 걸리던 검토 작업을 손을 대지 않아도 되는 프로세스로 전환했습니다. 이 시스템은 모호한 항목을 정규화하고, 노이즈를 필터링하며, 작업 설명이 중복되지 않도록 보장합니다.