오스마니 기술 — 에이전트 한 방 리라이트 전에, 가장 작은 책임 있는 한 걸음 | DAKER 커뮤니티

한 줄 요약. 에이전트에게 저장소 전체를 한 번에 고치라고 맡기기 전에, 틀려도 바로 끌 수 있는 가장 작은 책임 있는 한 걸음을 먼저 밟으십시오. 빠른 팀은 정보를 덜 쓰는 팀이 아니라, 틀린 뒤에도 살아남을 안전장치를 먼저 깔아 두는 팀입니다.

Bias toward action은 무모하게 밀어붙이라는 구호가 아닙니다. 실제 피드백이 나오는 가장 작은 한 걸음을 기본값으로 두고, 가드레일을 미리 약속하는 태도입니다. 오늘 Claude Code 세션에서 「전체 리팩터 한 방에」가 제안될 때, 그 문을 양방향 문으로 바꾸는 법을 정리합니다.

오늘 배울 것

한 방 리라이트와 가장 작은 책임 있는 한 걸음을 구분하는 방법을 배웁니다. 깨짐을 먼저 정의하고, 피처 플래그·작은 PR·1% 범위로 폭발 반경을 묶은 뒤, 이상하면 바로 끄는 순서를 고정합니다.

빠른 팀은 정보를 더 씁니다

빠르게 움직이는 팀은 생각을 건너뛰지 않습니다. 피드백 루프가 짧을 뿐입니다. 연구에서도 빠른 의사결정자는 느린 팀보다 정보를 더 쓰고, 대안을 더 만들며, 원하는 정보의 약 70%에서 작은 것을 내보내고 배웁니다. 차이는 용기가 아니라 기반입니다.

속도는 위험한 배포를 용감하게 하는 데서 나오지 않습니다. 안전한 일을 쉽게 만드는 데서 나옵니다. 피처 플래그, 실제로 알려 주는 모니터링, 연습한 롤백, 깨졌을 때 읽히는 작은 변경이 그 기반입니다. 느린 팀은 매 배포가 무섭습니다. 안전망이 없기 때문입니다.

한 방 리라이트는 일방향 문입니다

대부분의 결정은 설계하면 되돌릴 수 있습니다. 양방향 문은 들어가 보고 별로면 다시 나오면 됩니다. 일방향 문은 신중해야 합니다. 문제는 너무 많은 결정을 일방향처럼 대하는 것입니다.

에이전트에게 「인증·프론트·테스트·네이밍을 한 세션에 전부 고치라」고 하면, 그 세션은 일방향 문이 됩니다. 디프가 수천 줄이고, 어느 파일이 원인을 만들었는지 모르며, 롤백은 커밋 하나를 되돌리는 일이 아니라 하루를 버리는 일이 됩니다. 늦추기 전에 먼저 물으십시오. 이 변경을 되돌릴 수 있게 만들 수 있습니까?

피처 플래그를 넣으면 재배포 없이 끌 수 있습니다.
파일 하나, 모듈 하나, 경로 하나로 범위를 줄이면 1% 카나리와 같습니다.
옛 경로와 새 경로를 잠시 같이 두면 Dual-write처럼 되돌아갈 수 있습니다.

되돌릴 수 있게 만드는 일이 종종 가장 레버리지가 큽니다. 무서운 일방향 문을 안전한 양방향 문으로 바꿉니다.

가장 작은 책임 있는 한 걸음

프로덕션에 여러 번, 비율을 올리며 내보내는 편이 한 번의 신중한 빅뱅보다 안전합니다. 틀렸을 때의 폭발 반경이 작기 때문입니다. 해커톤·로컬 프로토타입에서는 더 단순해도 됩니다. 내보내고, 보고, 이상하면 되돌리면 됩니다. 다만 이미 사용자·제출·공유 브랜치가 있는 코드라면 아래 순서를 지키십시오.

깨짐을 먼저 정의합니다. 테스트, 에러율, p99 지연, 데모 클릭 경로처럼 「여기가 깨지면 중단」하는 기준을 적습니다.
변경을 플래그 뒤에 둡니다. 재배포 없이 끌 수 있어야 합니다. 플래그가 어려우면 작은 브랜치·작은 PR로 범위를 묶습니다.
플래그를 끈 채로 합칩니다. 코드는 들어왔지만 아직 실행되지 않습니다.
1%부터 켭니다. 파일 하나, 엔드포인트 하나, 팀원 로컬 한 명도 1%입니다. 지표가 좋으면 5%·25%·50%·100%로 올립니다.
이상하면 플래그를 끕니다. 원인을 찾는 동안 폭발 반경은 그 1%에 머뭅니다.
안정되면 플래그를 제거합니다. 플래그는 재고입니다. 주인·만료일·목적이 없으면 상태 조합만 늘어납니다.

카나리는 사용자가 실제로 겪는 신호를 봐야 합니다. CPU만 보다가 통과시키고, 특정 클릭 경로에서만 터지는 버그를 놓치는 경우가 많습니다. 실패 모드가 나타날 만큼 충분히 보고, 가능하면 카나리는 한 번에 하나만 켭니다.

에러 예산으로 속도 논쟁을 끊습니다

에러 예산은 「빨리 갈까, 안정시킬까」를 철학 토론에서 숫자로 바꿉니다. 서비스 SLO가 99.9%라면 0.1%가 예산입니다. 예산 안이면 계속 내보냅니다. 예산을 초과하면 기능을 멈추고 신뢰성을 고칩니다. 장애의 약 70%는 변경에서 옵니다. 그래서 변경을 더 안전하게 만드는 장치가 필요합니다.

에이전트 세션에도 같은 규칙을 옮길 수 있습니다. 테스트가 연속으로 실패하거나, 디프가 합의된 파일 집합을 넘거나, 롤백 방법이 사라지면 예산을 쓴 것입니다. 그때는 기능을 더 시키지 말고 검증부터 회복합니다.

가드레일 없이 빨리 가면

2012년 Knight Capital은 배포 실수로 옛 코드가 일부 서버에 남았습니다. 45분 만에 잘못된 주문이 쏟아졌고, 약 4억 6천만 달러가 날아가 회사가 거의 무너졌습니다. 교훈은 「천천히 가라」가 아닙니다. 최악을 묶는 킬 스위치와 배포 통제에 투자하라는 것입니다. 결제·인증·제출 마감처럼 되돌리기 어려운 구간에서는 그림자 모드, 검증한 킬 스위치, 합성 트래픽이 「행동」입니다.

오늘 세션에서 할 일

에이전트에게 맡길 일을 한 문장으로 적습니다. 「전체 리팩터」가 나오면 파일 하나·테스트 하나·경로 하나로 자릅니다.
깨짐 기준 세 개를 먼저 씁니다. 예: 기존 테스트 유지, 데모 클릭 세 칸 통과, 롤백은 플래그 끄기.
프롬프트에 「이 범위 밖 파일은 수정하지 말 것」「실패하면 완료가 아니라 중단으로 보고할 것」을 넣습니다.
첫 패치가 통과해도 제품화·제출을 완료로 부르지 않습니다. 다음 한 걸음만 켭니다.
플래그나 임시 분기를 만들었다면 주인과 제거 시점을 한 줄로 남깁니다.

팀을 실제로 느리게 하는 것

분석 마비도 있지만, 더 자주 느려지는 이유는 큰 변경 묶음, 신뢰할 수 없는 테스트, 관측 공백, 복잡한 롤백, 무시하게 되는 알림입니다. 그것을 고치면 속도는 따라옵니다. 배포가 지루해질 때, 그것이 진짜 Bias toward action입니다.