grep

Product

기획서에서부터 Jira 태스크 업로드까지, Tasky

Ddongule여기어때

2026년 3월 10일

원문에서 보기 ↗

안녕하세요 여기어때컴퍼니 프론트엔드 개발자 동글입니다.

개발을 하다 보면 기능 구현보다 더 많은 시간을 잡아먹는 일이 있습니다. 바로 기획 문서를 읽고, 이해하고, 태스크로 쪼개는 과정입니다. Confluence에 정리된 기획서를 읽고, 각 작업자들과 태스크를 나누고, 직접 Jira에서 티켓을 만드는 일은 굉장히 중요하지만 또 반복적이고, 사람에 따라 결과물의 편차도 큽니다. 이 과정을 자동화할 수 있다면 어떨까? 라는 질문에서 Tasky는 시작했습니다.

Tasky는 Confluence 기획 문서를 기반으로 Jira 티켓을 자동 생성하는 AI 기반 워크플로우 자동화 시스템입니다. Tasky의 목표는 단순히 “AI로 티켓을 만들어준다”가 아니라, 팀의 생산성 향상을 위해 팀이 일하는 방식 그대로, 표준화된 태스크를 보다 빠르게 준비하는 것입니다.

Tasky를 만들며 가장 중요하게 본 가치는 세 가지 였습니다.

첫 번째는, 개발자의 생산성 향상입니다.

기획서를 읽고 태스크를 쪼개는 일은 필수적이지만, 매번 처음부터 사람이 하기에는 반복적인 작업입니다. Tasky는 이 과정을 자동화해 개발자가 비즈니스 문제 해결과 구현에 보다 더 집중할 수 있도록 돕습니다.

두 번째는, 빠른 프로젝트 준비입니다.

Confluence 문서를 Jira 티켓으로 옮기는 데에 많게는 수십분까지 걸리던 시간을 수 분 단위로 줄이는 것이 목표였습니다. 기획이 끝나면 곧바로 개발이 시작될 수 있는 상태를 만들 수 있다면 좋겠다는 생각이었습니다.

세 번째는, 일관된 태스크 품질과 표준화 입니다.

사람이 태스크를 만들면 누군가는 크게 범위를 잡아 태스크를 만들고, 누군가는 디테일하게 모든 태스크를 쪼갭니다. 또 종종 중복이 생기거나 누락이 생기기도 합니다. Tasky를 통해 정해진 패턴과 규칙을 기반으로 태스크가 생성된다면, 모든 프로젝트에서 일관된 태스크 구조를 유지할 수 있습니다.

이런 Tasky는 문서를 읽는 단계부터 Jira 등록까지 여러단계를 거치는 파이프라인으로 구성되어 있습니다.

첫 번째 단계는 문서 읽기 단계입니다.

가장 먼저 Tasky는 Confluence API를 통해 기획 문서를 읽어옵니다.

문서의 내용을 조회하고, HTML 태그를 제거해 순수 텍스트로 변환하고, 문서 제목과 본문, Space 정보를 추출해옵니다. 여러 페이지를 누적해서 한 번에 처리할 수도 있습니다.

두 번째 단계는 PRD 생성 단계입니다.

이미 사람이 만든 PRD가 있는데 다시 이 단계가 필요한 이유는, 사람이 작성한 정형화되지 않은 문서를 그대로 AI에게 전달하지 않고, 한번의 워싱을 거쳐 표준화된 형태의 PRD로 만들어 AI에게 전달하기 위함입니다.

이때 AI에게는 역할이 주어지는데요, “당신은 경험 많은 프로덕트 매니저입니다. 문서의 표현은 그대로 유지하면서 구조적인 PRD를 작성해주세요.”와 같은 프롬프트를 통해 역할을 부여합니다. (실제 프롬프트는 조금 더 복잡하지만, 기본적인 의도는 같습니다.ㅎ) 역할이 부여된 AI는 문서를 분석해 프로젝트 개요, 핵심 기능, 사용자 경험, 기술 구조, 개발 로드맵, 기능 간 의존성, 리스크와 대응 방안 등의 내용을 포함한 JSON 형태의 PRD를 생성합니다. 이 결과를 검증한 뒤 표준 PRD 텍스트로 변환해 파일로 저장합니다.

그 다음 단계는 태스크 추출 단계입니다. 표준화된 PRD를 기반으로 AI는 기능별 개발 태스크를 추출하고, 태스크 간 의존성을 설정하며, 우선순위와 예상 소요 시간을 계산합니다. 이 단계에서 만들어지는 태스크는 범위가 다소 넓은 상위 레벨의 태스크입니다. 각 팀 별로 사용하기에는 아직 추상적인 부분이 많고, 실제 개발 단위로 사용하기에는 한번 더 다듬는 과정이 필요합니다.

그래서 Tasky는 한 단계 더 나아가 프론트엔드 태스크를 별도로 생성합니다. (추후 각 팀 별 태스크를 뽑아낼 수 있도록 고도화 할 예정입니다.) 단순히 키워드 매칭만으로 판단하지 않고, 2단계에서 만들어진 태스크의 제목과 설명, 상세 내용을 종합적으로 분석해 UI 개발, 사용자 인터페이스 구현, API 연동, 사용자 인터랙션 등 실제 프론트엔드 개발자가 작업해야 하는 요소들이 포함되어 있는지를 기준으로 프론트엔드 관련 태스크를 추려냅니다.

프론트엔드 관련 태스크를 선별한 이후에는, 기존 태스크를 그대로 사용하는 대신 다시 한 번 분석하고 개선하는 단계를 거칩니다. 이때 참고하는 것이 PRD 파일과 metadata.json 파일인데요, 앞서 생성한 PRD에는 기능의 의도와 배경이 담겨있고, metadata.json에는 실제 프로젝트에서 사용 중인 컴포넌트 구조, API 연동 패턴, UI 패턴 정보들이 정리되어 있습니다. 이 과정은 AI가 우리 프로젝트의 맥락을 이해하면서 태스크를 뽑아내는 데 중요한 역할을 합니다. ( 우리 팀 코드 스타일을 아는 AI 만들기: RAG와 Vector DB 활용기 )

이제 상위 태스크를 뽑았으니, 더 디테일한 상세 태스크를 뽑아낼 단계입니다.

실제로 개발을 시작하려면, 하나의 태스크를 다시 여러 개의 실행 가능한 작업 단위로 쪼개는 과정이 필요합니다. 개발자들은 이 상세 태스크를 보고 개발을 하기 때문에, 이 단계를 가장 중요하게 다뤘습니다. 개발자가 티켓을 열었을 때, 바로 작업을 시작할 수 있는 수준까지 내려가면 좋겠다고 생각했기 때문입니다.

그렇기에 서브태스크 생성 시에는 작업마다 상세 설명에 메타데이터를 바탕으로 만들어진 설명을 함께 넣습니다. 서브태스크를 단순히 해야할 일로만 사용하지 않고, 프로젝트의 맥락이 포함된 설명을 넣어 개발자가 개발을 시작할 때 “어떻게 개발하지?” 라는 고민을 최대한 하지 않고, 바로 개발에 들어갈 수 있게 하는 역할을 하게 하기 위함입니다.

이 과정에서 예상 작업 소요시간이나 중요도도 함께 생성됩니다.

마지막으로, 이렇게 생성된 태스크와 서브태스크는 Jira REST API를 통해 선택된 Epic에 자동으로 등록됩니다. 태스크와 서브태스크의 계층 구조를 유지하면서 우선순위와 예상 소요 시간까지 함께 반영합니다.

이 과정을 마무리하고 나면, 개발자는 Jira에 들어가자마자 바로 일을 시작할 수 있는 상태가 됩니다.

Tasky를 도입한 이후, 가장 크게 달라진 점은 태스크의 품질이 팀 전반에서 표준화되었다는 것입니다. 이제는 티켓만 보고도 전체 맥락을 빠르게 파악할 수 있고, 중복되거나 누락되는 태스크가 거의 사라졌습니다. 무엇보다 기획에서 개발 준비까지 걸리는 시간이 크게 단축되었습니다. 물론 중복 태스크 탐지 고도화나 시작일, 마감일 자동 업데이트, 디자인(Figma) 컨텍스트 연동 등 앞으로 개선하고 싶은 점도 여전히 남아 있습니다.

Tasky는, AI가 모든 것을 대신 결정하는 어떤 도구가 아니라, 우리가 일하는 방식을 안전하게 자동화한 워크플로우라고 할 수 있습니다. 사람이 정한 맥락과 규칙 안에서 정해진 역할만 수행합니다. 문서를 티켓으로 바꾸는 이 단순한 자동화가 팀 전체의 생산성과 일관성을 얼마나 크게 바꿀 수 있는지 그 조그마한 가능성을 Tasky가 보여주고 있다고 생각합니다.