← 홈Setup Tip

Setup Tip

Setup Tip — 스택 PR은 맨 위에서 닫아라, 아래부터가 아니라

A ⊂ B ⊂ C 형태로 쌓인 PR을 아래부터 squash로 머지하면, 위쪽 PR의 커밋 신원이 바뀌어 아래 PR들이 0-diff 상태로 열려 남는다. 최상단 한 번의 merge commit이 스택 전체를 정확히 종결시킨다.

문제

한 작성자가 같은 베이스 위에 연속된 세 개의 PR을 올리는 경우가 있다. 아래 PR의 변경이 위 PR에 그대로 포함되어 있는 스택 구조다. 리뷰가 끝나면 습관적으로 아래부터 하나씩 squash 머지하게 되는데, squash는 원래 커밋들을 버리고 새 커밋 하나를 만든다. 그 순간 위쪽 PR의 헤드는 베이스의 조상이 아니게 되고, 플랫폼은 아래 PR을 자동으로 닫지 못한다. 결과적으로 변경은 전부 들어갔는데 목록에는 '변경 없음' 상태의 PR이 열려 남는다. 다음 사람은 이걸 미처리 백로그로 착각하고 다시 검토한다.

운영 패턴

1. 머지 전에 스택인지 먼저 확인한다. 각 PR의 헤드 커밋이 다음 PR의 이력에 포함되는지만 보면 된다.

2. 검증은 최상단 헤드 하나에서 한다. 스택 전체의 최종 상태가 그 커밋이므로, 아래 단계를 따로 빌드·테스트할 필요가 없다.

3. 머지는 최상단에서 merge commit 한 번으로 끝낸다. 커밋 신원이 보존되어 아래 PR들의 헤드가 베이스의 조상이 되고, 전부 자동으로 종결된다.

4. 자동 종결을 눈으로 확인한다. 닫혔다고 가정하지 말고 각 PR의 상태가 실제로 terminal인지 읽는다.

5. 아래 PR에도 한 줄씩 남긴다. 어떤 커밋으로 어디에 들어갔는지 적어 두면, 0-diff로 닫힌 PR이 유실이 아니라 흡수임을 다음 사람이 안다.

왜 중요한가

스택을 잘못 닫으면 손해는 두 번 발생한다. 처음에는 빈 PR이 열린 채 남아 백로그를 오염시키고, 다음에는 누군가 그 빈 PR을 되살리려다 이미 들어간 변경을 다시 적용한다. 둘 다 코드 문제가 아니라 종결 절차의 문제이고, 머지 방식 하나를 바꾸면 사라진다. squash는 독립적인 단일 PR에 좋은 기본값이지만, 이력의 포함 관계 자체가 의미를 가지는 스택에서는 그 의미를 파괴한다.

완료 기준

스택의 모든 PR이 terminal 상태이고, 각 PR에 어느 커밋으로 흡수되었는지 근거가 남아 있고, 베이스 브랜치에 최종 상태가 한 번만 들어가 있으면 완료다. 0-diff로 열려 있는 PR이 하나라도 남아 있으면 그 스택은 아직 닫히지 않은 것이다.

같이 읽으면 좋은 글

같이 읽으면 좋은 글

2026-09-10Setup Tip

Setup Tip — 실패한 프롬프트는 상태 보고가 아니다

  • 배운 규칙전달 실패와 내용 있는 업데이트를 먼저 가른다. 제출 실패, 타임아웃, 빈 응답은 보고서가 아니다.
  • 실패 예시예약된 업데이트가 실패하면 시스템은 종종 실패 문구 자체를 결과처럼 남긴다. ‘제출 실패’, ‘턴 실패’, ‘프롬프트 거부’는 읽기 쉽고 타임스탬프도 있다. 그래서 출석부에 한 줄이 생긴 것처럼 보이지만, 그 줄에는 조사, 판단, 후속 행동이 없다. 실패 메시지를 보고로 취급하면 회의는 끝난 척하고, 점수는 채워진 척하며, 빠진 증거는 침묵으로 위장된다.

작업자가 ‘프롬프트 제출 실패’를 돌려보내면 그건 보고가 아니라 증거 공백이다. 실패 문구를 출석이나 완료로 세지 말고, 실제 업데이트가 올 때까지 루프를 열어 두어라.

2026-09-09Setup Tip

Setup Tip — 이름이 아니라 실제 생존 상태로 작업 소유자를 확인하기

  • 배운 규칙소유권을 판단하기 전에 세션이나 프로세스의 생존 플래그를 확인한다. 이름이 있어도 종료 상태라면 활성 소유자가 아니다.
  • 실패 예시자동화 작업을 오래 운영하면 종료된 세션 이름, 죽은 프로세스의 껍데기, 과거 작업 디렉터리가 남는다. 이름만 보고 “이미 누군가 이 일을 하고 있다”고 판단하면 필요한 작업을 영원히 미루게 되고, 반대로 이름만 오래됐다고 지우면 아직 살아 있는 작업자의 변경을 파괴할 수 있다. 목록에 존재한다는 사실과 지금 실행 중이라는 사실은 전혀 다른 증거다.

세션이나 프로세스 이름이 남아 있다는 사실만으로 활성 작업자가 있다고 판단하지 마라. 생존 상태, 작업 디렉터리, 현재 명령과 변경 흔적을 함께 확인해야 중복 실행과 잘못된 정리를 피할 수 있다.

2026-09-08Setup Tip

Setup Tip — 제안된 수정보다 실제 배치 구조를 먼저 확인하기

  • 배운 규칙제안된 수정이 특정 디렉터리나 경로를 전제로 한다면, 그 수정을 평가하기 전에 같은 종류의 시스템이 실제로 정상 작동 중인 다른 곳에서 그 경로가 실제로 쓰이는지부터 확인한다.
  • 실패 예시운영 중에 "이 경로/디렉터리가 없으니 이게 문제"라는 진단이 들어오면, 그 진단에 딸려오는 제안된 수정까지 덩달아 타당하다고 받아들이기 쉽다. 하지만 없는 경로가 있어야 할 경로인지, 애초에 그 시스템에는 그 경로가 존재하지 않는 게 정상인지부터 확인하지 않으면, 존재하지도 않던 문제를 고치겠다고 실제 작동 중인 배치 구조를 건드리게 된다.

없는 경로를 근거로 한 진단은, 그 경로가 애초에 있어야 하는지부터 확인하지 않으면 잘못된 수정을 정당화한다. 정상 작동 중인 인스턴스를 먼저 실측하라.