Kukie GitOps.03 Merge Approval

0. Contents

1. Overview

1.1 승인에서 결과 표시까지

배경

• 02편은 PR 이 열리는 데서 끝난다. 그 시점까지 클러스터에는 아무 변화가 없다
• 승인 카드를 누르면 Kukie 가 PR 을 머지하고, ArgoCD 가 그 커밋을 sync 한다
• 카드를 만든 뒤 PR 이나 레포가 바뀔 수 있고, sync 는 몇 분이 걸린다

이 글의 질문

• 승인한 내용과 지금 내용이 같은지 어떻게 확인하는가
• 끝나는 데 몇 분 걸리는 일을 HTTP 요청 하나로 어떻게 다루는가
• 머지 직후 AI 답변이 나중에 틀린 말이 되는 문제를 어떻게 막는가

1.2 kubectl 승인과 PR 승인

이 차이가 5장의 장애와 6장의 답변 문제로 이어졌다.

2. Approval Card — 승인 카드

2.1 승인 전 PR 생성

• 승인 전에 PR 을 먼저 연다. 렌더 비교를 통과한 PR 만 카드가 된다
• 그래서 카드에 PR 번호와 링크, 실제 diff 를 싣고, 사용자는 GitHub 에서도 같은 내용을 본다
• 승인과 머지가 같은 일이다. 승인을 누르기 전에는 main 이 바뀌지 않는다

2.2 카드에 싣는 내용

2.3 거절과 만료 시 PR 닫기

세 번째 줄은 리뷰에서 나왔다. 카드가 결정 없이 끝나면 에이전트는 통보를 받지 못한다. 2편의 “같은 파일을 고치는 Kukie PR 이 열려 있으면 기다린다” 규칙 때문에 아무도 닫지 않으면 PR 경로가 영영 막힌다.

3. Recheck — 승인 순간 재확인

3.1 경로 재판단

• 승인 순간 02편 3장의 경로 판단을 다시 돌린다
• 판단 결과가 kubectl 이거나, 대상 앱과 레포의 지문이 카드를 만들 때와 다르면 실행하지 않는다
• 02편의 판단은 AI 를 막는 일이고, 여기는 사용자가 승인한 것과 같은지 대조하는 일이다

3.2 파일 지문과 base 대조

Git 은 파일 내용으로 blob id 를 만든다. 내용이 한 글자만 달라도 값이 달라지므로, 카드를 만들 때 저장한 값과 비교하면 파일이 그대로인지 알 수 있다.

3.3 일시 실패와 재시도

처음에는 승인 순간 조회가 실패해도 STALE 로 닫았다. 일시적 실패로 승인한 변경과 PR 을 버리는 문제가 리뷰에서 나와 나눴다.

3.4 GitHub 에서 먼저 머지된 PR

• 승인한 내용 그대로 머지됐으면 변경은 이미 들어갔다. STALE(“실행 안 함”)은 사실과 다르다
• 그래서 파일 지문과 머지 커밋의 첫 부모가 base_sha 와 같으면 반영으로 보고, sync 지켜보기로 넘어간다
• 첫 부모만 본다. squash 와 rebase 는 부모가 하나이고, 머지 커밋은 [base, PR head] 두 개이기 때문이다
• 다른 내용이나 다른 base 위에 머지됐으면 직접 확인하라고 안내한다

3.5 서버 경로 누락

시험 레포의 PR 에 커밋을 더하고 승인하는 시험을 실제로 돌렸다. 머지는 막혔는데 카드가 “결과를 확인하는 중이에요"에서 끝나지 않았다.

시험 PR #8 의 실제 화면

• 카드는 Plan 상태를 5초마다 읽는다. 끝난 상태가 오지 않으면 약 11분까지 돈다
• 에이전트의 단위 테스트는 가짜 서버를 쓴다. 가짜 서버에는 후속으로 미룬 이 경로가 이미 있었다
• 머지 안전에는 문제가 없었다. 사용자가 멈춘 것으로 오해할 수 있는 표시 문제다

4. Merge Guardrails — 머지의 제약

4.1 브랜치 보호와 PR 유지

브랜치 보호에 걸린 카드 — 우회하지 않고 PR 을 남긴다. 픽스처 화면이며 이름은 예시로 바꿨다

4.2 동시 변경 잠금

4.3 머지 기록 우선 저장

• 기록을 끝내 못 하면 지켜보기를 시작하지 않는다. 얹을 자리가 없기 때문이다
• 이 경우 결과의 stderr 에 경고를 붙이고, 재실행은 차단한다
• 지켜보는 동안 앱은 Plan 의 sync_result 를 읽어 진행을 표시한다

머지 뒤의 승인 카드 — sync 결과가 Plan 에 쌓이면 카드가 바뀐다. 픽스처 화면이며 이름은 예시로 바꿨다

5. Incident — 머지 승인 HTTP 504

5.1 첫 실제 시험의 60초 끊김

시험 레포의 첫 PR 을 승인했더니 화면에 504 가 떴다. 머지는 성공했고, 클러스터 반영도 정상이었다.

변경은 성공했는데 사용자에게는 실패로 보였다. 다시 누르면 머지를 또 시도할 위험도 있었다. 그때까지 테스트와 픽스처로만 확인했고, 픽스처에는 CloudFront 의 시간 제한과 ArgoCD 의 조회 주기가 없었다.

5.2 sync 대기와 CloudFront 제한

제한을 늘리는 방법은 쓰지 않았다. CloudFront 를 늘려도 ALB 의 유휴 제한(60초)이 남고, 그동안 사용자는 도는 버튼만 본다.

5.3 응답과 지켜보기의 분리

• 앱은 진행 스트림이 아니라 Plan 을 읽는다. 새로고침해도 같은 상태를 보여 주기 위해서다
• 끊긴 요청의 핸들러는 취소되지 않는다. uvicorn 소켓을 띄운 시험으로 확인했다
• 배포 순서는 서버 → 에이전트 → 앱이다. 에이전트가 먼저 나가면 sync-result 가 404 라 Plan 이 syncing 에 남는다

5.4 재시작 복구와 중복 머지 방지

에이전트가 재시작되면 메모리의 승인 티켓과 지켜보기가 사라진다. 기동할 때 서버에 끝나지 않은 PR 경로 계획을 물어 닫는다.

6. Stale Answer — 카드와 다른 AI 답변

6.1 카드 “정상"과 답변 “아직 4개”

504 를 고친 뒤 시험 PR #3 에서 카드와 답변이 서로 다른 말을 했다.

6.2 충돌한 지시

6.3 코드 문장으로 교체

02편과 같은 판단이다. 안내문과 프롬프트 5번도 고쳤지만, 화면에 나가는 문장은 코드가 정한다. 실행 단계 블록을 코드가 채우는 자리가 이미 있어 같은 곳에 넣었다.

시험 PR #4 에서 이 문장이 나왔고, 머지 뒤 응답은 약 10초에서 약 5초로 줄었다. 한 번 잰 값이다.

6.4 교체하면 안 되는 경우

첫 구현은 “머지 결과가 syncing 이면 교체"였다. 리뷰 세 판에서 지적 9건이 나왔고, 대부분 교체하면 설명이 사라지는 경우였다.

형식 재시도는 코드로 읽어서는 확신할 수 없어, 실제 흐름을 재현하는 시험을 넣어 확인했다.

7. Discussion

7.1 확인 범위

7.2 채팅 승인과 GitHub 리뷰 생략

• Kukie 의 승인은 GitHub 리뷰를 대신한다. App 이 리뷰 없이 머지한다
• 브랜치 보호가 리뷰를 요구하면 머지하지 않고 PR 을 남긴다. 팀의 규칙을 우회하지 않기 위해서다
• 카드의 diff 를 사람이 읽는다는 전제가 남는다. 작은 변경에서는 편하고, 큰 변경에서는 약한 지점이다

7.3 AI 호출을 없애는 구조

지금 구조는 AI 를 한 번 부른 뒤 그 글을 버린다.

• 쓰지 않을 답에 비용과 대기 시간이 든다
• 대화 기록의 출력 툴 인자에 원래 글이 남아, 다음 턴에 모델이 볼 수 있다
• 머지 앞에서 ToolFailed 로 끝난 다른 변경은 정상 재시도와 구분되지 않아, 그 설명이 덮일 수 있다

머지가 끝나면 모델을 부르지 않고 코드가 바로 답하면 앞의 둘이 사라진다. 수정 범위가 커서 비용과 대기 시간이 문제가 될 때 한다.

핵심 메시지

• 승인의 대상: 커밋이 아니라 내용과 전제
  • 파일 지문, base, 브랜치, 경로가 모두 같아야 머지한다
• 긴 작업: 제한을 늘리지 않고 요청과 분리
  • 응답은 머지까지, 결과는 Plan 에 쌓고 화면이 읽는다
• 기록 순서: 머지한 사실이 먼저
  • 어디서 죽어도 재시도가 다시 머지하지 않는다
• 고정되는 글: 바뀌는 상태를 적지 않는다
  • 카드가 맡는 상태는 답변에 쓰지 않고, 코드로 막는다
• 가짜 서버의 한계: 시험을 통과해도 경로가 없을 수 있다
  • 504 와 STALE 은 모두 실제 시험에서 처음 드러났다

8. References