FAQ
자주 묻는 질문
AI Insight
코드는 AI가 짜는데
왜 레포지토리는 여전히 사람이 관리할까?
AI는 이제 복잡한 알고리즘 문제도 풀고,
코드 수정까지 수행할 수 있는 수준에 가까워지고 있습니다.
그런데 실제 개발 현장에서는
이슈를 전달하고, 담당자를 찾고, 처리 상태를 확인하는 일을
여전히 사람이 직접 챙기는 경우가 많습니다.
이슈가 사라지는 흔한 상황 2가지
중복되는 알림으로 확인이 지연되고
실시간으로 처리 상태를 파악이 어려워집니다.
담당자가 오류를 발견해도
그 내용이 DM, Notion, Jira, GitHub, Sentry에 흩어지면
이슈의 현재 상태를 한눈에 파악하기 어렵습니다.
그렇다면 문제의 본질은 무엇일까요?
문제는 '이슈'가 아니라 '주소'와 '상태'입니다
여기서 말하는 주소와 상태는 다음을 의미합니다.
주소: 이슈가 어느 제품, 어느 레포지토리의 문제인가
상태: 현재 어디까지 처리되었는가
주소와 상태, 이 두 가지가 명확하지 않으면 자동화가 시작되기 어렵습니다.
에이전트가 읽을 수 있는 상태 머신이 필요합니다
코딩 에이전트를 바로 연결한다고
무인 운영이 완성되는 것은 아닙니다.
먼저 이슈가 접수되고, 분류되고,
레포지토리와 연결되고, 처리 상태가 갱신되며,
결과가 다시 제보자에게 돌아가는 흐름이 필요합니다.
즉, 사람이 기억으로 관리하던 업무를
에이전트가 읽을 수 있는 상태 머신으로 바꿔야 합니다.
1. 모든 이슈가 단일 창구로 접수
2. 제품, 담당, 팀, 우선순위 정리
3. 실제 레포지토리와 연결
4. 사람과 에이전트 상태 동기화
5. 최초 제보자에게 결과 회신
이 다섯 가지가 갖춰지면,
이슈는 사람의 기억이 아니라 에이전트가 다룰 수 있는 데이터가 됩니다.
사용자는 VIT에 한 번만 제보합니다
VIT는 이슈를 한곳에서 접수하고
단일 이슈 ID를 부여하는 사내 이슈 트래커입니다.
사용자는 증상과 재현 절차를 한 번만 입력하면 됩니다.
이후 제품·팀·레포지토리 매핑, 중복 정리, 우선순위 판단,
처리 상태 갱신과 결과 회신은 시스템이 이어받습니다.
VIT는 한 번의 제보가 처리까지 이어지도록 만듭니다.
이슈는 PR과 검증으로 이어집니다
VIT에서 구조화된 이슈는
실제 GitHub 레포지토리와 연결됩니다.
이후 agent-maintainer가 이슈를 분류하고,
코딩 에이전트에 작업을 배정하며,
수정 패치와 테스트, PR 검증 과정을 이어갑니다.
1. TRIAGE | 이슈 분류
이슈를 확인하고 작업 가능한 상태로 정리합니다.
2. DISPATCH | 배정
코딩 에이전트에게 작업을 전달합니다.
3. PATCH | 수정
오류를 재현하고 코드를 수정합니다.
4. REVIEW | 검증
독립 검증과 증거 묶음을 생성합니다.
5. LAND | 병합
기준 브랜치에 안전하게 반영합니다.
6. RECOVER | 복구
실패 시 다시 수정 루프로 돌아갑니다.
완벽한 완료는 PR 머지가 아닙니다
무인 운영에서 PR 머지와 CI 통과는
완료를 위한 중간 단계일 뿐입니다.
정말 중요한 것은
처음 제보된 이슈가 실제 환경에서
사라졌는지 확인하는 것입니다.
그래서 시스템은 스테이징 환경에서
최초 제보의 재현 절차를 다시 수행하고,
결과를 기준에 따라 판정합니다.
FIXED
문제가 사라진 경우, 완료 처리하고 제보자에게 알립니다.
NOT FIXED
문제가 남아 있는 경우, 이슈를 다시 열고 후속 작업을 만듭니다.
INCONCLUSIVE
환경 변화 등으로 판단이 어려운 경우, 조건을 맞춰 다시 검증합니다.
무인 운영에도 사람이 지키는 경계는 있습니다
무인 운영은 모든 일을 AI에게 맡기는 방식이 아닙니다.
반복 가능하고 기준이 명확한 작업은 자동화하되,
불확실성이 큰 판단과 고위험 변경,
되돌리기 어려운 작업은 사람의 영역으로 남겨야 합니다.
결국 무인 레포지토리 운영은
사람이 이슈를 더 열심히 관리하는 것이 아니라,
이슈가 맞는 레포지토리로 흐르고
결과가 제보자에게 돌아오게 만드는 구조입니다.
이슈의 주소와 상태가 정리될 때,
접수부터 PR·검증·피드백까지 이어지는 AI 기반 무인 운영 루프가 완성됩니다.