표 한 줄로 적은 Kiro 철거에 네 차례가 걸렸다

질문

Kiro 체험 레인 철거는 커밋과 정리 기록으로 세면 네 차례 걸렸다.
9월 28일에 커밋 두 개, 10월 2일, 10월 6일이다.
레인을 붙이던 때 적어 둔 철거 비용은 표 한 줄이었다.
이 판정은 그 한 줄이 실제로 든 일과 맞았는지를 가른다.
표에 적은 줄 자체는 하루 안에 그대로 이뤄졌지만 철거 비용을 추정하기에는 모자랐다.

판정

표에 적은 줄은 맞았다.
프로바이더 블록은 9월 28일 revert 커밋으로 지워졌고
1분 38초 뒤 정리 커밋과 같은 작업에서 프록시 서비스가 내려갔다.
설정과 프로세스만 놓고 보면 하루 안에 끝난 일이다.

어긋난 것은 표 밖의 일이다.
revert는 이후 커밋과 부딪혀 네 파일에서 충돌이 났고
문서 세 곳과 모델 목록 캐시 DB(데이터베이스)에는 Kiro 값이 남아 있었다.
10월 2일에는 프록시 리포의 에이전트 지침 파일을,
10월 6일에는 Kiro 앱의 자동 시작과 셸 통합 줄을 따로 걷어냈다.
표가 틀렸다기보다는, 표가 비용을 센 범위가 설정과 프로세스에서 멈춰 있었다.

시작도 예정일에 맞춰 오지 않았다.
철거 예정일을 넘긴 9월 27일에 BK는 "키로도 일단 냅둬"라며 철거를 미뤘고
28일의 철거는 Opus 5.5가 gjc 카탈로그에 왜 없는지 묻다가 시작됐다.

근거

철거 방법은 처음부터 한 줄이 아니었다.
레인을 붙인 커밋은 철거 방법을 이 커밋의 revert와 체크리스트로 적었고
그 체크리스트는 손으로 걷어낼 항목 여섯 개였다.
그 철거 절이 처음 고쳐진 것은 26분 뒤다.
gjc 설정의 enabledModels에 kiro/*를 더한 커밋이 그 단일 커밋 밖에 생겼는데,
이 커밋은 revert로 지워지지 않으므로 그 한 줄을 빼는 단계를 절차에 넣었다.

revert 충돌은 목록을 만든 뒤에 바뀐 파일에서 났다.
충돌한 세 파일은 전부 9월 27일 커밋이 손댄 파일이다.
TeamClaude 디렉터리를 지운 커밋이 셋 모두를 바꿨고
gjc 모델 목록은 opencodex 블록을 넣은 커밋도 바꿨다.
충돌은 철거하던 에이전트가 직접 풀었다.

10월 6일에 걷은 것 중 철거 절에 적힌 것은 하나도 없다.
Kiro 앱의 자동 시작 항목은
RunAtLoad로 Kiro CLI 앱을 띄우고 있었고
앱 프로세스는 3일 6시간 40분째 돌고 있었다.
철거 절이 Kiro 자체를 걷는 항목으로 적은 것은
kiro-cli 로그아웃, 패키지 제거, 설정 폴더 삭제 세 줄이었다.
셸 설정 파일 중 .profile과 .zprofile은 8월 25일 18시 9~10분에 고쳐졌다.
이는 레인 커밋(18:45)보다 앞선 시각이다
(수정 시각만으로 Kiro가 고쳤다고 단정할 수는 없다).

한계·재검토 트리거

이 판정은 지금 남은 것을 걷어낼 때 다시 열린다.
2026-10-20 현재 레인 포트의 리스너와 Kiro 자동 시작 항목은 없다.
남은 것은 Kiro CLI 앱과 실행 파일, kiro-cli 설정 폴더와 홈 폴더의 Kiro 설정 폴더,
프록시 작업 사본, 사용량 장부, 비공개 GitHub 리포, 셸 설정 파일의 주석 줄,
10월 6일 백업 폴더다.
이것들은 철거 절 3·4·5번이 다루는 대상이다.
로컬 아티팩트, 구독을 끊을 때의 Kiro 자체,
보관하려면 생략하는 비공개 리포가 그 셋이다.
이 세 항목을 집행할 때도 철거 절에 없는 일이 나온다면,
표 밖의 비용이 이 한 건에서만 생긴 우연이 아니었다는 쪽으로 무게가 옮겨 간다.

2026-10 기준 / 재검토 트리거: 남은 앱·리포를 걷어낼 때 철거 절에 없는 작업이 나온다