Own the Outer Loop: 커밋 이후를 개발자가 직접 소유하기
핵심 요약 Own the Outer Loop는 개발자가 커밋 이후의 CI·리뷰·배포·모니터링까지 직접 책임진다는 개념이다. 이너 루프와의 차이, 소유가 필요한 이유, 파이프라인·기능 플래그·카나리 같은 실무 개선법을 정리했다.
'Own the Outer Loop'는 개발자가 코드를 커밋한 뒤 배포와 운영까지 이어지는 바깥쪽 작업 주기, 곧 아우터 루프를 남에게 떠넘기지 않고 직접 책임진다는 개념으로 통용된다. 로컬에서 코드를 고치고 빌드하고 테스트하는 안쪽 주기가 이너 루프라면, 커밋 이후의 CI, 코드 리뷰, 병합, 배포, 모니터링이 아우터 루프에 해당한다. 핵심은 '빌드가 통과했으니 내 일은 끝'이 아니라, 변경이 실제 사용자 앞에서 제대로 도는 지점까지를 개발자의 완료 기준으로 본다는 데 있다.
이너 루프와 아우터 루프는 어떻게 다른가
이너 루프는 개발자 한 사람이 자기 장비에서 초 단위로 반복하는 편집-빌드-실행-디버그 주기다. 파일을 저장하면 핫 리로드가 화면을 갱신하고 단위 테스트가 몇 초 만에 돌아가는 구간이 여기 속한다. 반대로 아우터 루프는 커밋을 올린 순간부터 시작된다. CI가 전체 테스트를 돌리고, 동료가 리뷰를 남기고, 병합된 코드가 스테이징을 거쳐 프로덕션에 나가고, 대시보드에서 에러율과 지연이 관찰되는 흐름 전체를 말한다.
둘의 결정적 차이는 피드백이 돌아오는 속도다. 이너 루프는 몇 초, 길어야 몇 분이면 결과를 확인한다. 아우터 루프는 파이프라인 대기와 리뷰 지연에 배포 창까지 겹쳐 수십 분에서 하루 넘게 걸리기도 한다. 그래서 많은 팀이 이너 루프 속도만 붙들고 튜닝하지만, 정작 변경이 사용자에게 닿기까지의 총 리드타임은 아우터 루프가 좌우한다.
왜 아우터 루프를 직접 소유해야 하나
배포 이후를 남의 일로 넘기면 책임의 공백이 생기기 때문이다. 예전 방식은 개발자가 기능을 만들어 '벽 너머로' 던지면 운영팀이 배포와 장애 대응을 떠맡는 구조였다. 이러면 코드를 가장 잘 아는 사람과 그 코드를 운영하는 사람이 갈라진다. 새벽에 알람이 울려도 원인을 아는 개발자는 로그를 볼 권한조차 없는 상황이 벌어진다.
아우터 루프를 소유한다는 건 '만든 사람이 운영한다(you build it, you run it)'는 원칙에 가깝다. 이 표현은 아마존의 최고기술책임자가 자사 엔지니어링 문화를 소개하며 쓴 말로 널리 알려져 있다. 자기 변경이 배포되는 경로와 프로덕션에서의 동작을 직접 보게 되면, 관측성 계측을 미리 심고 롤백 절차를 챙기며 배포하기 쉬운 단위로 작업을 쪼개는 습관이 붙는다. 품질이 코드 리뷰가 아니라 운영 현장에서 검증되는 셈이다.
아우터 루프를 개선하는 실무 접근
먼저 손대야 할 곳은 파이프라인 대기 시간이다. 테스트를 병렬로 쪼개고 변경 영향 범위만 골라 돌리면 CI가 붙잡는 시간을 크게 줄일 수 있다. 리뷰가 병목이면 PR을 작게 유지하는 규칙이 배포 자동화보다 먼저다. 리뷰어가 5분 안에 읽을 분량이면 리뷰 지연 자체가 사라진다.
배포 단계에서는 되돌리기 쉬운 구조를 먼저 갖추는 편이 낫다. 실무에서 자주 쓰이는 순서는 대략 이렇다.
- 기능 플래그로 배포와 노출을 분리해, 코드를 내보내도 스위치로 켜고 끈다.
- 카나리 배포로 일부 트래픽에만 먼저 흘려 지표를 관찰한다.
- 핵심 지표에 경보를 걸어 문제를 사람보다 시스템이 먼저 알리게 한다.
- 원클릭 롤백 경로를 늘 열어 두어 판단을 빠르게 만든다.
이 장치들이 갖춰지면 배포는 큰맘 먹고 벌이는 이벤트가 아니라 하루에도 여러 번 하는 평범한 작업이 된다.
소유가 과부하가 되지 않으려면
모든 개발자에게 인프라 전문가가 되라고 요구하면 소유는 금세 번아웃으로 바뀐다. 그래서 최근 플랫폼 엔지니어링 논의에서는 플랫폼 팀이 잘 닦인 길(paved road)을 깔아 두고, 제품 개발자는 그 위에서 자기 서비스를 운영하는 분담이 자주 거론된다. 배포 템플릿과 기본 대시보드, 표준 경보가 미리 준비돼 있으면 개발자는 바퀴를 다시 발명하지 않고도 아우터 루프를 책임질 수 있다.
정리하면 'Own the Outer Loop'는 개발자에게 일을 더 얹는 구호가 아니라, 코드를 만든 사람이 그 코드의 운명을 끝까지 지켜볼 수 있게 도구와 권한을 함께 넘기자는 이야기에 가깝다. 커밋에서 프로덕션까지의 거리를 짧고 안전하게 만드는 일이 다음 개발 생산성의 과제로 남는다.