최근에는 GitHub Copilot이나 Claude Code와 같은 AI 에이전트에게 코드를 작성하게 하는 개발 스타일이 확산되고 있습니다.

하지만 실제 개발 업무에는 요구사항 및 배경 파악, 구현 후 보고, 지식의 문서화 등 코드를 작성하는 것 외에도 많은 작업이 있습니다. 구현만 빨라진다고 해도 업무 전체에는 여전히 효율화의 여지가 남아 있습니다.

제 업무에서는 프로젝트 관리에 Backlog를 사용하고 있으며, 요구사항과 배경, 작업 기록, 지식 등이 이슈(Issue)·댓글·Wiki에 축적되어 있습니다. AI 에이전트가 Backlog의 정보를 참조·업데이트할 수 있게 된다면 개발 워크플로우 전체를 더욱 원활하게 만들 수 있지 않을까 생각하여 방법을 조사해 본 결과, bee (Backlog CLI) + Agent Skills 구성이 딱 맞았습니다.

이 기사에서는 그 연동 방법과 실제 개발 업무를 상정한 5가지 활용 사례를 소개합니다.

이 기사에서 사용 중인 Backlog 화면과 이슈는 제가 개인적으로 등록한 Backlog에 생성한 더미 프로젝트의 것입니다. 실제 업무 프로젝트와는 일절 관계가 없습니다.

Backlog는 Nulab이 제공하는 프로젝트·태스크 관리 도구입니다. 이슈 관리를 중심으로 스케줄 관리, 문서 공유, 소스 코드 관리 등 프로젝트에 필요한 기능이 하나로 모여 있습니다. 개발뿐만 아니라 디자인이나 마케팅 등 폭넓은 업무에서 이용되고 있습니다.

이슈 관리 (Issue Management): 태스크에 담당자·기한·상태를 설정하여 관리. 상위/하위 이슈를 통한 구조화도 가능 -
간트 차트 / 칸반 보드 (Gantt Chart / Kanban Board): 스케줄이나 진척도를 시각적으로 파악 -
Wiki: 사양이나 설계, 운용 절차 등의 정보를 축적·공유 -
Git / Subversion: 소스 코드나 커밋 이력 관리, 코드 리뷰, 풀 리퀘스트(Pull Request) 대응

이 기사에서는 주로 이슈·댓글·Wiki에 축적된 정보를 AI 에이전트로부터 참조·업데이트합니다.

bee는 Backlog를 커맨드 라인(Command Line)에서 조작하기 위한 CLI 도구입니다. 이슈나 Wiki, 문서, Git 리포지토리 등을 터미널에서 조작할 수 있으며, GitHub CLI (gh)와 유사한 사용감을 제공합니다.

Backlog에는 공식 MCP 서버도 있어 Claude Desktop 등 MCP 대응 클라이언트에서 이용할 수 있습니다.

단, 2026년 7월 시점의 공개 도구 목록에서는 이슈 댓글의 편집·삭제, Wiki의 업데이트·삭제, 문서의 업데이트·삭제에는 대응하지 않습니다.

bee는 폭넓은 서브 커맨드(Subcommand)를 갖추고 있을 뿐만 아니라, CLI에서 대응하지 않는 조작도 bee api를 통해 Backlog API를 직접 호출하여 보완할 수 있습니다. 이번 사례와 같이 터미널을 조작할 수 있는 AI 에이전트로부터 Backlog를 폭넓게 다루는 용도로는 bee가 더 적합했습니다.

Agent Skills는 AI 에이전트에게 "특정 태스크를 어떻게 진행할 것인가"라는 절차를 SKILL.md로서 전달하기 위한 오픈 표준입니다.

bee는 AI 에이전트용으로 using-bee 스킬을 배포하고 있습니다. 이를 추가하면 에이전트가 필요할 때 bee의 조작 방법을 읽어 들여 Backlog를 조작할 수 있게 됩니다. 동일한 스킬을 Claude Code나 GitHub Copilot 등에서도 재사용할 수 있다는 점이 장점입니다.

bee 이용을 위해서는 Node.js 20.18 이상이 필요합니다. 설치 방법은 공식 "시작하기"를 참조해 주세요.

다음은 API 키 인증을 사용하는 경우의 예시입니다. API 키는 Backlog의 "개인 설정 → API"에서 발행할 수 있습니다.

# Backlog에 로그인
bee auth login
# 기본 스페이스·프로젝트 지정 (임의)
...

OAuth를 사용하는 경우에는 사전에 OAuth 애플리케이션을 등록한 후 bee auth login --method oauth를 실행합니다. 자세한 내용은 인증 가이드를 참조해 주세요.

using-bee는 프로젝트 고유의 규칙이 아니라 bee 자체의 사용법을 정의하는 스킬이므로, 여기서는 -g를 붙여 사용자 단위로 추가하고 있습니다. 설치 시 평소 사용하는 에이전트를 선택해 두면, "Backlog"나 이슈 키를 포함한 지시에 따라 스킬이 읽혀집니다.

Backlog 표기법을 사용하는 프로젝트에서는 backlog-notation

스킬도 추가할 수 있습니다. Backlog 표기법을 사용하는 것은 자동으로 판정되지 않으므로, 프롬프트(Prompt)로 명시하거나 각 에이전트가 참조하는 지시 파일에 기재해 둡니다.

가장 기본적이면서도 효과적인 사용법은, 이슈(Issue) 그 자체를 작업 지시서로 읽게 하는 것입니다.

"이슈 PROJ-123을 구현해줘"라고 의뢰하면, 에이전트가 using-bee 스킬을 통해 이슈 정보를 읽어 들여, 무엇을 해야 하는지 이해한 후 구현에 들어갑니다.

실제로 다음과 같은 이슈를 작성하여 에이전트에게 구현을 의뢰해 보겠습니다.

[IMG:1]

이슈의 요구사항을 정확히 읽고 지시대로 구현해 주었습니다.

[IMG:2]

이번에는 작업 내용에 "375px 너비와 1280px 너비에서 표시 확인하기"라는 요구사항이 포함되어 있었기 때문에, VS Code의 browser agent tools를 사용하여 지정된 화면 너비에서의 표시 확인까지 수행했습니다. 이 기능에서는 에이전트가 Integrated Browser를 조작하여 스크린샷을 찍거나 페이지 내용을 읽을 수 있습니다.

구현이 끝나면 그 내용을 이슈의 댓글(Comment)로 작성하게 할 수도 있습니다.

"대응 내용을 이슈에 댓글로 달아줘"라고 의뢰하면, 변경점의 요약이나 대응 관점을 정리하여 게시해 줍니다. 작업 기록이 이슈에 남기 때문에 리뷰어(Reviewer)나 나중에 확인하는 사람과의 공유가 원활해집니다.

[IMG:3]

Case 1의 이어서 지시를 내려 보겠습니다.

[IMG:4]

댓글이 게시되었습니다. 대응 내용과 확인한 관점이 정리되어 있습니다.

주의할 점으로, 댓글 작성자는 AI 에이전트가 아니라 bee로 인증된 사용자 본인의 계정이 됩니다. "앞머리에 『🤖 Generated by GitHub Copilot』을 붙여줘"와 같이 AI 생성물임을 알 수 있는 문구를 넣도록 설정해 두면, 나중에 보는 사람이 사람의 댓글과 구분할 수 있어 투명성 측면에서도 안심할 수 있습니다.

댓글의 형식을 통일하고 싶다면, Case 3와 같은 방식으로 자체 제작 스킬(Custom Skill)에 템플릿을 분리할 수 있습니다.

단발적인 이슈 댓글뿐만 아니라, Wiki에 대응 로그를 모아서 축적하는 방식으로도 사용할 수 있습니다.

"이번 대응을 Wiki의 『불량 대응 로그』에 남겨줘"라고 의뢰하면 Wiki를 업데이트해 줍니다. 댓글이 이슈 단위의 흐름 정보(Flow Information)라면, Wiki는 횡단적으로 참조되는 스톡 정보(Stock Information)입니다. 이 둘을 구분하여 사용함으로써 지식(Knowledge)이 흘러가 버리지 않고 쌓이게 됩니다.

[IMG:5]

불량 보고가 올라온 이슈를 바탕으로 조사부터 Wiki 기록까지 의뢰해 보겠습니다.

[IMG:6]

새로운 Wiki 페이지가 생성되고 조사 내용이 기록되었습니다.

[IMG:7]

이후 실제 수정 작업과 Wiki 추가 기입까지 의뢰하여, 이슈 대응이 완료될 때까지의 과정을 일련의 플로우(Flow)로서 맡길 수도 있습니다.

Wiki로의 출력을 그대로 의뢰하면, 작성할 때마다 헤더(Heading) 구성이 흔들릴 수 있습니다. 매번 동일한 포맷으로 맞추고 싶다면, 템플릿을 작은 자체 제작 스킬로 분리해 두는 것이 안정적입니다.

---
name: backlog-incident-log
description: Backlog의 불량 대응 로그를 Wiki에 남길 때 사용한다. 하위 페이지의 정형 포맷과 상위 인덱스의 업데이트 규칙을 정의한다.
...

using-bee가 "bee의 사용법"을 담당하는 반면, 이러한 자체 제작 스킬은 "우리 팀에서의 사용법"을 담당합니다. 스킬을 역할별로 나누어 두면 운영 규칙을 바꾸고 싶을 때 자체 제작 스킬 쪽만 수정하면 되므로 유지보수가 편리합니다.

참고로 using-bee 스킬은 글로벌(Global)에 넣었지만, 이러한 운영 규칙을 담은 자체 제작 스킬은 프로젝트의 .agents/skills 하위에 두고 리포지토리(Repository)에 커밋함으로써 팀 전체가 공유할 수 있습니다.

GitHub Copilot이나 Codex 등은 .agents/skills를 그대로 참조할 수 있지만, Claude Code의 경우에는 .claude/skills로 복사하거나 심볼릭 링크(Symbolic Link)를 생성해야 합니다.

연동의 효과는 구현 중에만 머무르지 않습니다. 축적된 이슈나 Wiki를 정보원으로 활용한 질의응답도 매우 편리합니다.

"이 기능의 사양은 어땠지?", "그 불량의 대응 경위를 알려줘"와 같은 질문에 대해, 에이전트가 관련 이슈나 Wiki를 검색하여 답변해 줍니다. 검색창에 키워드를 넣고 직접 기사를 찾아다니는 것보다 빠르며, 여러 이슈에 걸친 정보도 횡단적으로 정리해 줍니다.

개발 중일 때뿐만 아니라, 나중에 사양을 확인하거나 과거 의사결정의 경위를 되짚어보는 용도로도 사용할 수 있다는 점이 매력적인 포인트입니다.

구현 작업뿐만 아니라 이슈 관리 그 자체도 맡길 수 있습니다.

큰 규모의 상위 과제 (Parent Issue)를 전달하며 "이것을 태스크로 분해해서 하위 과제를 만들어줘"라고 요청하면, 작업을 적절한 입도 (Granularity)로 분할하여 하위 과제 (Sub-task)로 기표해 줍니다. 태스크를 나누는 작업은 은근히 머리를 써야 하는 작업이므로, 초안을 자동으로 만들어 주면 계획 수립이 훨씬 수월해집니다.

다음과 같은 상위 과제를 작성하여 하위 과제로의 분해를 요청해 보겠습니다.

분할된 하위 과제들이 기표되었습니다. 중간에 내린 기간 변경 지시도 반영되어 있습니다.

Case 3과 마찬가지로, 단순히 지시만 내리면 입도나 명명 규칙이 흔들릴 수 있습니다. 분할 규칙을 자작 스킬 (Custom Skill)에 작성해 두면 출력이 안정되어 사용하기 편리해집니다.

---
name: backlog-subtask
description: Backlog의 상위 과제를 태스크로 분해하여 하위 과제를 기표할 때 사용한다. 입도·명명·기본 설정 규칙을 정의한다.
...

• 과제 본문·댓글·Wiki를 한꺼번에 참조할 수 있어, 프롬프트에 정보를 일일이 옮겨 적는 수고가 줄었다

• 작업 보고나 대응 로그를 Backlog에 남길 수 있어, 구현 후의 기록을 정리하기 쉬워졌다

• 과거의 과제나 Wiki를 횡단하여 조사할 수 있어, 사양이나 대응 경위를 확인하기 쉽다

• 동일한 Agent Skills를 GitHub Copilot이나 Claude Code 등에서 재사용할 수 있어, 에이전트가 바뀌어도 운영 규칙을 공유할 수 있다

• bee api를 사용함으로써, CLI에 전용 명령어가 없는 조작도 Backlog API를 통해 보완할 수 있다

• bee 1.0.0에서는 여러 줄의 본문을 플래그로 전달할 경우 첫 번째 줄에서 잘리는 경우가 있다. 댓글·Wiki·문서에서는 stdin을, 과제 설명에서는 REST API를 사용하는 등 조작에 따른 회피 방법이 필요하다

• bee는 CLI 도구이므로, 쉘 명령어를 실행할 수 있는 AI 에이전트를 전제로 한다. Claude Desktop 등에서 이용할 경우에는 MCP 서버가 더 적합하다

• Backlog에 대한 조작은 bee로 인증된 사용자의 권한으로 실행된다. 업데이트나 삭제를 맡길 경우에는 실행 전에 내용을 제시하여 확인하도록 하는 운영 방식을 취하면 안심할 수 있다

bee와 Agent Skills를 사용하여 Backlog와 AI 에이전트를 연동한 활용 사례를 소개했습니다.

• 과제를 작업 지시서로 읽게 하여 구현을 의뢰한다
• 작업 보고나 대응 로그를 과제 댓글·Wiki에 남긴다
• 축적된 정보를 바탕으로 질문에 답변하게 한다
• 상위 과제를 분해하여 하위 과제를 기표하게 한다

Backlog에는 개발에 필요한 요구사항이나 경위, 작업 기록이 이미 축적되어 있습니다. 이것들을 AI 에이전트의 입력과 출력 모두에 사용함으로써, 활용 범위를 코드 생성뿐만 아니라 그 전후의 개발 업무까지 넓힐 수 있습니다.

Backlog를 사용하고 계신 분들은 우선 과제를 읽게 하는 것부터 시도해 보세요.