Post

자체 평가 엔진 파라미터 변경 AI Agent 설계 - LLM을 production 워크플로우에 적용하기

Posted
By Gyubo Shim
12 min read
자체 평가 엔진 파라미터 변경 AI Agent 설계 - LLM을 production 워크플로우에 적용하기

배경

사내 신용평가 모델에는 수십 개의 입력 파라미터가 있다. 신용분석팀에서 “이 파라미터를 추가해주세요”, “이 필터링 규칙을 바꿔주세요” 같은 변경 요청이 정기적으로 들어온다.

기존 흐름:

flowchart LR
    A["분석팀: Jira 티켓 등록"] --> B["엔지니어: 티켓 분석"]
    B --> C["엔지니어: 영향도 분석"]
    C --> D["엔지니어: 코드 수정"]
    D --> E["엔지니어: PR 생성"]
    E --> F["리뷰 + 배포"]

문제는 변경 요청의 70~80%가 정형화된 패턴이라는 것이다:

  • input 파라미터 추가/삭제
  • 필터링 규칙 추가/변경
  • 기존 값의 계산 로직 수정

이런 패턴은 본질적으로 사람이 아니라 에이전트가 처리할 수 있는 영역인데, 매번 엔지니어 시간을 소비하고 있었다.

접근: 문제를 의제화하고 합의를 이끌어내기

기술적 해결보다 먼저 한 것은 팀 합의다. AI Agent 도입은 엔지니어 혼자 결정할 문제가 아니다.

  1. 팀의 AI 도입 흐름 안에서 “이 영역이 자동화에 적합하다”는 것을 데이터로 보여줌
  2. 최근 6개월 파라미터 변경 티켓을 분류 → 70~80%가 정형 패턴임을 확인
  3. 팀장 합의 도출 → MVP 구현 승인

“기술적으로 가능하니까 해보겠습니다”가 아니라 “이 문제가 반복되고 있고, 이 방식으로 해결할 수 있습니다”로 접근했다.

설계: 결정론적 처리와 LLM 처리의 경계

AI Agent 설계에서 가장 중요한 결정은 LLM에게 맡길 부분과 코드로 처리할 부분을 명확히 나누는 것이다.

flowchart TD
    A["Jira 티켓 트리거"] --> B["요구사항 분석"]
    B --> C["영향도 탐색"]
    C --> D["코드 수정"]
    D --> E["PR 생성 + 리뷰어 할당"]
    style B fill:#e8daef,stroke:#6c3483
    style D fill:#e8daef,stroke:#6c3483
    style C fill:#d5f5e3,stroke:#1e8449
    style E fill:#d5f5e3,stroke:#1e8449
단계처리 방식이유
요구사항 분석LLM자연어 티켓을 구조화된 변경 사항으로 해석
영향도 탐색결정론적 (코드)코드베이스 검색, 의존성 추적은 정확해야 함
코드 수정LLM변경 의도를 이해하고 적절한 위치에 코드 생성
PR 생성결정론적 (코드)GitHub API 호출, 리뷰어 할당은 정확해야 함

왜 이렇게 나누는가

LLM은 “의도를 이해하는 것”에 강하고, “정확하게 실행하는 것”에는 약하다.

flowchart LR
    subgraph llm["LLM이 잘하는 것"]
        A["'DSR 관련 입력값을 추가해주세요'<br>→ 어떤 파라미터를, 어떤 형태로?"]
        B["'기존 로직을 이렇게 바꿔주세요'<br>→ 코드의 어느 부분을, 어떻게?"]
    end
    subgraph code["코드가 잘하는 것"]
        C["이 파라미터가 사용되는<br>모든 파일 찾기"]
        D["GitHub PR 생성 +<br>특정 팀원을 리뷰어로 할당"]
    end

영향도 탐색을 LLM에게 맡기면 “아마 이 파일에서 쓰일 것 같습니다”라는 추측을 한다. 하지만 코드 검색은 grep 한 번이면 100% 정확한 결과를 준다. 확실한 것은 코드로, 판단이 필요한 것은 LLM으로.

아키텍처: 기존 인프라에 붙이기

새로운 인프라를 만드는 것이 아니라, 기존 시스템(Jira, GitHub, 코드베이스)에 Agent를 붙이는 형태로 설계했다.

flowchart TD
    subgraph trigger["트리거"]
        A["Jira Webhook<br>(파라미터 변경 티켓 감지)"]
    end
    subgraph agent["AI Agent"]
        B["Claude API<br>(요구사항 해석)"]
        C["코드베이스 검색<br>(영향도 분석)"]
        D["Claude API<br>(코드 수정 생성)"]
    end
    subgraph output["결과물"]
        E["GitHub PR 생성"]
        F["분석팀 리뷰어 자동 할당"]
    end
    A --> B --> C --> D --> E --> F

    G["운영자가 PR 검토"] --> H["머지 + 배포"]
    F --> G
    style G fill:#fff3cd,stroke:#856404

핵심 설계 원칙:

  • 사람이 최종 검토한다: Agent가 PR을 생성하지만, 머지는 반드시 사람이 한다
  • 기존 인프라 활용: 새로운 서비스를 띄우지 않고 Jira API + GitHub API + Claude API 조합
  • 실패해도 안전하다: Agent가 잘못된 PR을 만들어도 리뷰에서 잡힘. 최악의 경우 “사람이 직접 하던 것으로 돌아가기”

구현: Claude API 활용

요구사항 해석

1
2
3
4
5
6
7
8
9
10
11
12

# Jira 티켓의 자연어 설명을 구조화된 변경 사항으로 변환
prompt = """
다음 Jira 티켓의 내용을 분석하여 파라미터 변경 사항을 추출하세요.

티켓 내용: {ticket_description}

응답 형식:
- action: add | remove | modify
- parameter_name: ...
- parameter_type: ...
- description: ...
"""

영향도 탐색 (결정론적)

1
2
3
4
5
6
7
8
9
10
11
12

# LLM이 아니라 코드로 정확하게 검색
def find_impact(parameter_name: str) -> list[str]:
    # 1. 파라미터가 정의된 파일 찾기
    definition_files = grep(parameter_name, "apps/")
    
    # 2. 해당 파라미터를 사용하는 서비스 찾기
    usage_files = grep(parameter_name, "services/")
    
    # 3. 테스트 파일 찾기
    test_files = grep(parameter_name, "tests/")
    
    return definition_files + usage_files + test_files

코드 수정 생성

영향도 분석 결과를 Claude에게 전달하여, 정확한 위치에 정확한 코드를 생성하도록 한다.

1
2
3
4
5
6
7
8

prompt = """
다음 파일들에 파라미터 '{param_name}'을 추가해야 합니다.

영향 받는 파일들:
{impact_files_with_context}

기존 파라미터 추가 패턴을 참고하여 코드 변경 사항을 생성하세요.
"""

현재 진행 상황

MVP: Claude Code Skills로 구현

현재는 Claude Code의 Skills 기능을 활용하여 파라미터 변경의 일부를 자동화한 상태다. 엔지니어가 Claude Code에서 Skills를 실행하면, 코드베이스를 분석하고 변경 사항을 생성해준다.

1
2

현재 흐름 (Skills 적용):
  Jira 티켓 확인 → Claude Code Skills 실행 → 코드 수정 생성 → 엔지니어 검토 → PR

완전 자동화는 아니지만, 엔지니어가 직접 코드를 분석하고 수정하는 시간이 줄었다. 현재 이 Skills는 팀 전체에 공유되어 본인뿐 아니라 모든 팀원이 파라미터 변경 작업 시 사용하고 있다.

향후 방향: 풀 자동화 Agent

위에서 설계한 Jira 트리거 → 자동 분석 → PR 생성 파이프라인은 Skills MVP를 검증한 뒤 다음 단계로 구현할 계획이다. Skills에서 검증된 프롬프트와 도구 구조를 그대로 Agent로 옮기면 된다.

단계상태설명
문제 발굴 + 팀 합의완료데이터 기반으로 팀장 합의 도출
Claude Code Skills MVP완료엔지니어가 수동 트리거, 코드 생성 자동화
Jira → Agent → PR 자동화설계 완료, 구현 예정트리거부터 PR 생성까지 풀 자동화

느낀 점

LLM Agent에서 가장 중요한 것은 “경계 설계”다

LLM에게 모든 것을 맡기면 “대부분 맞지만 가끔 틀린” 시스템이 된다. 결정론적으로 처리할 수 있는 부분(코드 검색, API 호출)은 코드로 처리하고, 판단이 필요한 부분(요구사항 해석, 코드 생성)만 LLM에게 맡기면 신뢰성이 올라간다.

Skills MVP부터 시작하는 게 맞았다

처음부터 풀 자동화 Agent를 만들려 했으면 scope이 너무 커서 진행이 안 됐을 것이다. Claude Code Skills로 “프롬프트와 도구 구조가 실제로 동작하는가”를 먼저 검증하고, 그 위에 자동화를 얹는 방식이 현실적이다.

기술보다 합의가 먼저다

“이걸 자동화할 수 있습니다”보다 “이 문제가 반복되고 있고, 이만큼의 시간이 소비되고 있습니다”가 팀을 설득하는 데 훨씬 효과적이다. 데이터로 문제를 보여주고, 해결책을 제안하고, 합의를 이끌어내는 과정이 코딩보다 더 중요했다.

“사람이 최종 검토한다”는 안전장치가 도입을 가능하게 한다

금융 시스템에서 AI가 자동으로 코드를 수정하고 배포한다? 아무도 동의하지 않을 것이다. 하지만 “AI가 코드를 생성하고 사람이 검토한다”면 리스크는 기존과 동일하면서 속도만 빨라진다. Skills MVP도 이 원칙을 따르고, 향후 Agent도 마찬가지다.

Engineering Notes
ai-agent llm claude-api automation workflow
This post is licensed under CC BY 4.0 by the author.