왜 릴리스 노트를 준비하는 것이 여전히 번거로운 작업인가?

모든 엔지니어링 팀은 결국 릴리스 직전에 동일한 상황에 직면합니다.

누군가는 겉보기에 단순해 보이는 질문에 답해야 합니다: "무엇이 바뀌었는가?"

불행하게도, 그 질문에 답하는 것은 결코 간단하지 않습니다.

개발자들은 병합된 풀 리퀘스트 (Pull Requests)를 검색하기 시작합니다. 누군가는 비즈니스 맥락을 이해하기 위해 Jira를 엽니다. 다른 엔지니어는 커밋 메시지 (commit messages)를 훑어봅니다. 제품 관리자 (Product managers)는 고객 친화적인 요약을 요구합니다. QA는 기술적인 변경 로그 (changelog)를 원합니다. 경영진은 릴리스 하이라이트를 원합니다.

정보는 이미 존재합니다. 단지 여러 시스템에 흩어져 있을 뿐입니다. 그 결과, 매 릴리스마다 수 시간이 소요되는 수동 프로세스가 발생합니다.

문제점

전형적인 릴리스 노트 준비 과정은 다음과 같습니다:

• 병합된 풀 리퀘스트 (Pull Requests) 검색
• 모든 PR 설명 읽기
• 해당하는 Jira 스토리 열기
• 비즈니스 요구사항 이해하기
• 커밋 히스토리 (commit history) 읽기
• 관련 기능 그룹화하기
• 비즈니스 사용자를 위해 기술적 언어를 다시 쓰기
• 릴리스 문서 준비하기

릴리스 규모가 커질수록 이 프로세스는 더 길어집니다. 아이러니하게도, 이 작업 중 그 어느 것도 소프트웨어를 만드는 작업이 아닙니다. 이는 이미 존재하는 정보로부터 구축되는 문서화 작업일 뿐입니다.

에이전트가 맥락 수집을 수행한다면 어떨까?

엔지니어에게 수동으로 릴리스 노트를 조립하도록 요청하는 대신, 필요한 모든 맥락을 자동으로 수집할 수 있는 AI 에이전트를 원했습니다.

워크플로우는 다음과 같습니다:

Merged Pull Requests
        │
        ▼
...

엔지니어는 단순히 릴리스 범위를 지정하기만 하면 됩니다. 나머지는 에이전트가 수행합니다.

AI 릴리스 노트 에이전트 구축하기

구현 방식은 이전 기사에서 소개한 것과 동일한 설계 철학을 따릅니다. 기사를 찾아보시는 것을 강력히 추천합니다.

모든 곳에 맞춤형 통합 (custom integrations)을 만드는 대신, 에이전트는 기존의 개발자 도구들을 오케스트레이션 (orchestrates)합니다.

현재 구현 사항:

• GitHub CLI
• GitHub Copilot CLI
• Jira REST API
• Python 3.11+

상위 수준 아키텍처 및 설계 (High-Level Architecture And Design)

                Engineer

                    │
...

에이전트는 어떤 정보를 수집하는가? (What Information Does the Agent Collect?)

단순히 커밋 메시지 (commit messages)를 이어 붙이는 전통적인 스크립트와 달리, 에이전트는 여러 소스로부터 컨텍스트 (context)를 수집합니다.

GitHub로부터:

• 풀 리퀘스트 (Pull Requests)
• 머지 커밋 (Merge commits)
• 변경된 파일 (Changed files)
• 작성자 (Authors)
• 라벨 (Labels)

Jira로부터:

• 스토리 설명 (Story descriptions)
• 수락 기준 (Acceptance criteria)
• 비즈니스 요구사항 (Business requirements)
• 에픽 정보 (Epic information)

이러한 풍부한 컨텍스트 덕분에 생성된 릴리스 노트 (release notes)는 단순히 무엇이 (what) 변경되었는지가 아니라, 기능이 왜 (why) 구현되었는지를 설명할 수 있습니다.

GitHub CLI 활용 (Leveraging GitHub CLI)

구현은 GitHub CLI에 크게 의존합니다.

예를 들어,

머지된 풀 리퀘스트 (merged pull requests) 조회:

gh search prs --state merged

PR 정보 조회:

gh pr view

커밋 (commits) 조회:

gh pr view --json commits

GitHub CLI가 인증 (authentication)과 리포지토리 컨텍스트 (repository context)를 처리하므로, Python 코드는 오케스트레이션 (orchestration)에만 집중할 수 있습니다.

에이전트 워크플로우 (Agent Workflows)

저는 여러 유형의 릴리스 노트 (Release Notes)를 생성하도록 에이전트를 설계했습니다.

AI를 사용하는 가장 큰 장점 중 하나는 에이전트가 동일한 릴리스 내에서도 서로 다른 대상에 맞춘 여러 결과물을 만들어낼 수 있다는 점입니다.

고객용 릴리스 노트 (Customer Release Notes)

최종 사용자 (end users)를 위해 설계되었습니다.

예시:

설정 가능한 알림 기본 설정 지원이 추가되었습니다.

대규모 데이터 세트에 대한 대시보드 성능이 향상되었습니다.
...

엔지니어링 변경 로그 (Engineering Changelog)

개발자 (developers)를 위해 설계되었습니다.

포함 사항:

• PR 번호
• 기술적 구현 (Technical implementation)
• 파괴적 변경 사항 (Breaking changes)
• 의존성 업데이트 (Dependency updates)

내부 관리 요약 (Internal Management Summary)

전달 (delivery)에 초점을 맞춥니다.

예시:

• 24개의 풀 리퀘스트 (Pull Requests) 머지됨
• 18개의 Jira 스토리 완료됨
• 2개의 버그 수정 (Bug fixes)
• 4개의 기능 개선 (Enhancements)
• 파괴적 변경 사항 (Breaking changes) 없음

예상 출력 구조 (Expected Output Structure)

Executive Summary

New Features
...

이것이 커밋 메시지보다 나은 이유 (Why This Is Better Than Commit Messages)

커밋 메시지 (Commit messages)는 개발자를 위해 작성됩니다. 릴리스 노트 (Release notes)는 사람들을 위해 작성됩니다. 이 둘은 근본적으로 대상 독자 (audiences)가 다릅니다. AI는 구현 세부 사항 (implementation details)을 노출하는 대신, 기술적인 작업 내용을 고객, 제품 관리자 (product managers), QA 팀, 그리고 경영진이 즉시 이해할 수 있는 언어로 다시 작성할 수 있습니다.

이것을 에이전트라고 간주하는 이유 (Why I Consider This an Agent)

오늘날 많은 애플리케이션이 LLM을 감싸고 이를 "AI 에이전트 (AI Agent)"라고 부릅니다. 저는 그 정의가 조금 더 엄격해야 한다고 생각합니다.

유용한 엔지니어링 에이전트 (engineering agent)는 다음과 같은 능력을 갖추어야 합니다:

• 독립적으로 정보 수집
• 외부 도구 (external tools) 호출
• 여러 시스템으로부터의 정보 결합
• 워크플로 (workflow) 결정 수행
• 지속적인 인간의 가이드 없이 의미 있는 결과물 생성

이 프로젝트는 단순히 LLM에 프롬프트 (prompts)를 보내는 것이 아닙니다. 이는 GitHub, Jira, 그리고 Copilot을 오케스트레이션 (orchestrating)하여 반복적인 엔지니어링 작업을 제거하는 워크플로를 구축하는 것입니다.

제 관점에서, 바로 그 지점이 에이전트가 진정으로 유용해지는 지점입니다.

보안 고려 사항 (Security Considerations)

현재 구현 방식은 Pull Request Review Agent와 동일한 가드레일 (guardrails)을 따릅니다.

• 읽기 전용 (Read-only) GitHub 작업
• 읽기 전용 (Read-only) Jira 쿼리
• 자동 리포지토리 (repository) 쓰기 금지
• 임시 파일 정리
• 명시적인 보고서 생성

에이전트는 소스 코드나 배포 아티팩트 (deployment artifacts)를 절대 수정하지 않습니다.

향후 개선 사항 (Future Enhancements)

이것은 단지 첫 번째 반복 (iteration)일 뿐입니다.

향후 개선 사항에는 다음이 포함됩니다:

• 자동 릴리스 감지
• Slack 공지
• Confluence 게시
• 마크다운 (Markdown) 생성
• PDF 릴리스 보고서
• 이메일 배포
• 관련 기능의 의미론적 그룹화 (Semantic grouping)
• 멀티 리포지토리 릴리스 집계

향후 전망 (Looking Ahead)

이 시리즈의 다음 몇 편의 글을 통해, 우리는 다음과 같은 소프트웨어 개발 수명 주기 (software development lifecycle)의 다른 부분들을 자동화하는 실용적인 엔지니어링 에이전트들을 계속해서 구축해 나갈 것입니다:

Jira 스토리에서 첫 번째 Pull Request까지

목표는 엔지니어를 대체하는 것이 아닙니다. 엔지니어가 의미 있는 문제를 해결하는 데 더 많은 시간을 할애할 수 있도록 반복적인 작업을 제거하는 것입니다.

만약 여러분도 이와 유사한 워크플로우를 구축하고 있거나, 자동화할 수 있는 엔지니어링 작업에 대한 아이디어가 있다면 댓글로 들려주세요.

저자 소개