티켓 주도 개발
(Ticket-Driven Development, TiDD)
- 작업의 최소 단위를 티켓으로 만들어서 프로젝트를 관리하는 방식
일반적인 소프트웨어 개발 티켓 구조
-
제목(title)
작업의 성격과 핵심 내용을 한눈에 파악할 수 있도록 직관적으로 설계해야 함 -
배경 및 맥락(Context/Description)
소스 코드만으로는 알 수 없는 비즈니스 요구사항이나 문제의 본질을 설명
이러한 이유는 시간이 흐른 뒤에도 코드가 왜 이렇게 작성되었는지 설명 -
수락 기준(Acceptance Criteria, AC)
티켓 작성 시 가장 중요한 부분
작업을 완료했다고 판단할 수 있는 구체적인 체크리스트 -
참고 자료 및 제약 사항(Reference & Constraints)
관련 설계 문서나 기술 표준을 링크, 우선순위 같은 메타데이터를 명시하여
프로젝트의 투명성을 높임
티켓을 중심으로 개발의 모든 행위가 수렴하는 시스템 중력을 만드는 것이 핵심임
또는 시스템 중력, 티켓 센트릭
실천해야 할 원칙
1) 선행 발급(Ticket First)
행위 이전에 목적을 정의할 것
신기능 개발, 버그 수정 등 모든 변경 사항은 티켓에 기록된 목적에 기반
원인 분석(root cause analysis)이 먼저 되어야 함
2) 1:1 매칭(Linking)
1 commit = 1 ticket
모든 코드의 탄생에는 그 근거인 티켓이 있어야 함
이를 코드의 출생신고서 라고 부르기도 함
-
1:1 원칙이라는 물리적인 숫자 제한보다는
코드의 변경 단위가 티켓의 목적 범위를 절대 벗어나서는 안 된다는 의미
커밋 메시지 첫 머리에 티켓 번호를 명시할 것 -
코딩을 하던 도중 티켓의 범위에 없는 버그를 발견했을 때,
그 자리에서 고치면 안됨
3) 세분화(Granularity)
하나의 작업을 우리가 충분히 관리할 수 있는 아주 작은 단위로 나눌 것
프로젝트 관리 도구에 따라 이 티켓을 이슈라고 부르기도 함
TiDD workflow
AI와 함께하는 TiDD workflow
1) 이슈 발행
- 라벨링(Labeling)
AI는 생성된 티켓의 내용을 스스로 분석하여, 이 작업이 "신규 기능"인지
혹은 "버그 수정"인지를 판단하는 시각적 분류
사람이 수동적으로 문서를 작성하고 분류할 때 발생하던 정보의 누락이나 의사소통의 왜곡이 완전히 사라지게 됨
2) 브랜치 생성
- 티켓이라는 설계도와 물리적 작업 공간을 논리적으로 연결하는
강력한 시스템 그래비티의 실천
3) 구현과 테스트
4) 커밋
- 추적 가능성(Traceability)
커밋 메시지에 이슈 번호를 포함하는 순간,
저장소의 코드는 이슈(또는 티켓)와 양방향으로 연결됨
5) PR 작성
- AI 기반 PR 생성/스마트 리뷰/안전한 머지
