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

한 줄 답: 에이전트가 코드를 빠르게 바꿔 주는 시대일수록, 무엇을 먼저 바꿀지 정하는 기준이 더 중요해졌습니다.

데이콘·DAKER 커뮤니티 기준으로 정리한 안내입니다.

에이전트가 코드를 빠르게 바꿔 주는 시대일수록, 무엇을 먼저 바꿀지 정하는 기준이 더 중요해졌습니다. 저장소 전체를 한 번에 고치게 하는 일은 얼핏 효율적으로 보이지만, 실제로는 원인 추적과 롤백을 어렵게 만들어 팀을 더 느리게 할 수 있습니다.

지금 필요한 것은 속도를 늦추는 태도가 아니라, 틀려도 바로 멈추고 되돌릴 수 있는 방식으로 속도를 내는 태도입니다. 오늘 Claude Code 세션에서 전체 리팩터 제안이 나왔을 때, 그 변경을 어떻게 더 작은 책임 있는 한 걸음으로 바꿀지 정리합니다.

빠른 팀은 정보를 덜 쓰는 팀이 아니라, 틀린 뒤에도 살아남을 안전장치를 먼저 깔아 두는 팀입니다.

가장 작은 책임 있는 한 걸음

빠른 팀은 생각을 건너뛰지 않습니다

Bias toward action은 무모하게 밀어붙이라는 뜻이 아닙니다. 실제 피드백이 나오는 가장 작은 한 걸음을 기본값으로 두고, 가드레일을 먼저 약속하는 태도에 가깝습니다.

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

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

한 방 리라이트는 왜 위험한가

대부분의 결정은 되돌릴 수 있게 설계할 수 있습니다. 들어가 보고 아니면 다시 나올 수 있는 양방향 문처럼 다루면 됩니다. 반대로 한 번 들어가면 되돌리기 어려운 일방향 문은 더 신중해야 합니다. 문제는 너무 많은 변경을 처음부터 일방향 문처럼 만들어 버린다는 점입니다.

에이전트에게 인증, 프론트, 테스트, 네이밍을 한 세션에서 전부 고치라고 맡기면 그 세션은 사실상 일방향 문이 됩니다. 디프는 수천 줄로 커지고, 어느 파일이 문제의 원인인지 알기 어려워지며, 롤백은 커밋 하나를 되돌리는 일이 아니라 하루를 버리는 일이 됩니다.

늦추기 전에 먼저 물어야 할 것은 이 변경을 되돌릴 수 있게 만들 수 있는가입니다.

되돌릴 수 있게 만드는 방법은 거창하지 않습니다. 피처 플래그를 넣으면 재배포 없이 끌 수 있고, 파일 하나나 모듈 하나, 경로 하나로 범위를 줄이면 1% 카나리처럼 다룰 수 있습니다. 옛 경로와 새 경로를 잠시 함께 두면 Dual-write처럼 되돌아갈 여지도 생깁니다. 종종 가장 큰 레버리지는 변경 자체보다, 그 변경을 되돌릴 수 있게 만드는 데 있습니다.

가장 작은 책임 있는 한 걸음의 순서

프로덕션에는 여러 번, 비율을 올리며 내보내는 편이 한 번의 신중한 빅뱅보다 안전합니다. 틀렸을 때의 폭발 반경이 작기 때문입니다. 해커톤이나 로컬 프로토타입에서는 더 단순하게 움직여도 되지만, 이미 사용자, 제출, 공유 브랜치가 있는 코드라면 순서를 분명히 두는 것이 좋습니다.

1. 깨짐을 먼저 정의합니다

무엇이 실패인지 먼저 적어 두어야 합니다. 테스트, 에러율, p99 지연, 데모 클릭 경로처럼 여기가 깨지면 중단한다는 기준이 있어야 합니다.

2. 변경을 플래그 뒤에 둡니다

재배포 없이 끌 수 있어야 합니다. 플래그가 어렵다면 작은 브랜치나 작은 PR로 범위를 묶는 편이 좋습니다.

3. 플래그를 끈 채로 합칩니다

코드는 들어왔지만 아직 실행되지는 않는 상태입니다. 이 단계가 있어야 배포와 노출을 분리할 수 있습니다.

4. 1%부터 켭니다

파일 하나, 엔드포인트 하나, 팀원 로컬 한 명도 1%입니다. 지표가 좋으면 5%, 25%, 50%, 100%로 올리면 됩니다.

5. 이상하면 바로 끕니다

원인을 찾는 동안에도 폭발 반경은 그 1%에 머뭅니다. 이 점이 작은 변경의 핵심입니다.

6. 안정되면 플래그를 제거합니다

플래그는 재고와 같습니다. 주인, 만료일, 목적이 없으면 상태 조합만 늘어납니다.

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

에러 예산이 속도 논쟁을 끝냅니다

에러 예산은 빨리 갈지, 안정시킬지를 철학이 아니라 숫자로 바꿉니다. 서비스 SLO가 99.9%라면 0.1%가 예산입니다. 예산 안이면 계속 내보내고, 예산을 초과하면 기능보다 신뢰성 복구를 우선합니다. 장애의 약 70%는 변경에서 오기 때문에, 변경을 더 안전하게 만드는 장치가 중요합니다.

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

에이전트 세션에서도 롤백이 사라지는 순간, 속도는 더 이상 장점이 아닙니다.

가드레일 없이 빠르게 가면 생기는 일

2012년 Knight Capital은 배포 실수로 옛 코드가 일부 서버에 남았습니다. 45분 만에 잘못된 주문이 쏟아졌고, 약 4억 6천만 달러가 날아가 회사가 거의 무너졌습니다. 여기서 얻을 교훈은 천천히 가라는 말이 아닙니다. 최악을 묶는 킬 스위치와 배포 통제에 투자해야 한다는 점입니다.

결제, 인증, 제출 마감처럼 되돌리기 어려운 구간에서는 그림자 모드, 검증된 킬 스위치, 합성 트래픽이야말로 실제 행동입니다. 빠르게 움직이되, 멈출 수 있어야 합니다.

오늘 세션에서 바로 적용할 기준

에이전트에게 맡길 일을 먼저 한 문장으로 적고, 전체 리팩터처럼 범위가 커지면 파일 하나, 테스트 하나, 경로 하나로 잘라 보는 것이 좋습니다. 그다음 깨짐 기준 세 개를 먼저 씁니다. 예를 들면 기존 테스트 유지, 데모 클릭 세 칸 통과, 롤백은 플래그 끄기처럼 적을 수 있습니다.

프롬프트에는 이 범위 밖 파일은 수정하지 말 것, 실패하면 완료가 아니라 중단으로 보고할 것 같은 조건을 넣어 두면 됩니다. 첫 패치가 통과해도 제품화나 제출을 완료라고 부르기보다, 다음 한 걸음만 여는 편이 안전합니다. 플래그나 임시 분기를 만들었다면 주인과 제거 시점도 한 줄로 남겨 두는 것이 좋습니다.

팀을 실제로 느리게 하는 것

팀을 느리게 만드는 원인은 분석 마비만이 아닙니다. 더 자주 문제를 만드는 것은 큰 변경 묶음, 신뢰할 수 없는 테스트, 관측 공백, 복잡한 롤백, 무시하게 되는 알림입니다. 이런 부분을 고치면 속도는 따라옵니다.

배포가 지루해질 때, 그것이 진짜 Bias toward action입니다.

출처