내보내는 것과 켜는 것은 같지 않다

앞 글에서 나는 스프린트를 기간이 아니라 효용을 자르는 일로 봤다. 어느 방향으로 잘라야 하는지를 말했고, 조각을 얇게 만드는 법도 셋 적었다. 그런데 어느 축을 잡고 자를지, 잘라 놓은 조각을 무슨 수로 내보낼지는 안 적었다.

세로로 자르자는 데까지 합의하고 다음 회의에서 백로그를 열었다. 조각이 이렇게 올라와 있었다. 첫 주에 목록 화면, 둘째 주에 상세 화면, 셋째 주에 편집 화면. 그 아래 다른 일감은 신청, 검토, 승인, 발송 순서로 네 조각이 나 있었다.

PM: “목록 화면이 나오면 누가 뭘 할 수 있게 되나요?”

개발자: “목록만으로는 볼 게 없죠. 상세가 붙어야 뭐라도 됩니다.”

PM: “신청 쪽은요?”

개발자: “신청서는 넣을 수 있어요. 그런데 검토가 다음 주라, 넣어 놓고 아무 일도 안 일어납니다.”

둘 다 자르긴 잘랐는데 조각 하나가 끝나도 그것만으로는 아무 데도 못 간다. 자를 자리를 찾았다 쳐도 걸리는 게 하나 더 있다. 잘라 놓은 조각을 무슨 수로 내보내느냐다. 결제 화면이 절반만 된 채로 다음 주 월요일에 나갈 수는 없으니 결국 다 모아 두었다가 한 번에 낸다.

실무에서 조각내기가 막히는 자리는 대개 자르는 솜씨가 모자라서가 아니다. 흐름의 단계를 떼는 걸 조각으로 착각하고, 잘라 놓은 조각을 내보낼 데가 없어 결국 다 모아서 내고, 반쯤 켜면 손해인 자리는 아예 못 자른다고 접기 때문이다.

자를 자리는 순서가 아니라 갈라지는 데 있다

일감을 앞에서 뒤로 한 단계씩 떼면 조각마다 앞 조각 없이는 아무것도 못 하는 층이 되고, 대신 그 일에서 여러 갈래로 벌어지는 것을 찾아 하나로 줄이면 조각 하나만으로도 일이 끝까지 간다.

못 자르겠다고 올라오는 일감은 자를 게 없는 게 아니라 이미 잘려 있는 것이 대부분이다. Richard Lawrence와 Peter Green은 못 자르겠다며 가져오는 것들이 알고 보면 일감 행세를 하는 작업이나 부품이더라고 적는다.Richard Lawrence, Peter Green, The Humanizing Work Guide to Splitting User Stories, humanizingwork.com. 2026년 8월 1일에 원문을 열어 확인했다. 화면에 보이는 게시 날짜는 없고 문서 정보에 2020년 10월 22일 게시, 2026년 5월 26일 수정으로 적혀 있다. Step 1 they turn out to be tasks or components masquerading as stories, Pattern #1 the most obvious split—one step at a time from beginning to end—is the wrong way to go, Step 3 Choose the split that lets you deprioritize or throw away a story. 효용이 안 늘어나는 것에서 출발하면 아무리 잘게 썰어도 효용이 느는 조각은 안 나온다. 그럴 때는 먼저 원래 하나였던 일로 도로 합친 다음 다시 자른다.

그다음, 가장 먼저 눈에 들어오는 자르기를 의심한다. 흐름 순서로 한 단계씩 떼는 자르기를 Lawrence는 틀린 방향이라고 못 박는다. 대신 처음과 끝을 잇는 가장 단순한 길 하나를 먼저 내고, 가운데 단계와 예외를 뒤에 붙인다.

그러면 칼은 어디에 넣나. 그 일에서 여러 갈래로 벌어지는 것을 찾는다. 원문이 드는 자리는 규칙, 사용자 종류, 인터페이스, 데이터 종류, 다루는 대상 같은 것들이고 목록은 거기서 닫히지 않는다. 갈래를 세어 놓고 하나만 남긴 것이 첫 조각이다. 앞의 신청 일감이라면 신청과 검토와 승인과 발송을 다 지나가되 신청 종류를 연차 하나로 좁히고 결재선이 한 줄인 경우만 남긴다. 그러면 한 사람이 신청해서 승인까지 받아 본다.

버릴 조각이 생기는 자르기를 고른다

자를 갈래가 여럿 나오면 무엇으로 고르나. 원문은 어림잡는 기준 둘을 든다. 하나는 안 만들어도 되는 것이 드러나는 자르기를 고르라는 것이고, 다른 하나는 크기가 고른 조각이 나오는 자르기를 고르라는 것이다.

내가 실무에서 값을 더 보는 쪽은 앞엣것이다. 어떤 자르기는 안 만들어도 되는 것이 무엇인지 드러내고, 어떤 자르기는 같은 것을 조각마다 조금씩 나눠 숨긴다. 사용자 종류로 갈랐더니 한 종류가 통째로 뒤로 밀리거나 아예 없어질 수 있다면 그쪽이 맞는 자르기다.

내보내는 시점과 켜는 시점을 따로 잡는다

조각을 잘라 놓고도 결국 다 모아서 내보내는 이유는 조각이 나갈 때마다 사용자가 그걸 봐야 한다고 믿기 때문인데, 코드가 나가는 시점과 기능이 켜지는 시점을 따로 잡으면 그 믿음이 성립하지 않는다.

반쯤 만든 걸 사용자한테 보이라는 거냐는 반문이 나온다. 정당한 반문이고, 답은 조각을 더 잘 자르는 쪽이 아니라 내보내기와 켜기를 떼는 쪽에 있다.

새 기능으로 가는 길을 코드에 넣되, 그 길로 갈지 말지는 코드 밖 스위치로 정하게 한다. 그 스위치를 기능 플래그라고 부른다. 코드는 기능이 꺼진 채로 매일 나가고 켜는 결정은 며칠이나 몇 주 뒤에 따로 한다. Pete Hodgson은 릴리스용 스위치를 이렇게 쓰는 것이 배포에서 공개를 떼어 낸다는 연속 배포의 원칙을 구현하는 가장 흔한 방법이라고 적는다.Pete Hodgson, Feature Toggles (aka Feature Flags), martinfowler.com, 2017년 10월 9일. 2026년 8월 1일에 원문을 열어 확인했다. Using Release Toggles in this way is the most common way to implement the Continuous Delivery principle of separating [feature] release from [code] deployment. 대괄호는 원문 것이다.

코드는 여덟 번 나갔고 켜는 결정은 두 번 있었다. 여덟 번 다 아무도 모르는 채로 운영 환경에 들어갔고, 사용자가 달라진 걸 알아챈 것은 스위치를 올린 그 두 날이다.

켜는 것도 전부 아니면 전무가 아니다. 먼저 팀 안에서만 켜서 운영 환경에서 직접 만져 본다. 그다음 소수에게 켜고 지켜본다. Danilo Sato는 이렇게 조금씩 넓혀 가는 공개를 카나리라고 부르고, 문제가 생기면 사용자를 옛 판으로 도로 보내면 된다고 적는다.Danilo Sato, Canary Release, martinfowler.com, 2014년 6월 25일. 2026년 8월 1일에 원문을 열어 확인했다. slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure, 되돌리기는 simply to reroute users back to the old version until you have fixed the problem. 원문은 자동 롤백 같은 다른 수단도 함께 든다.

앞 글에서 나는 결제와 로그인과 권한을 반쯤 켜면 손해인 자리로 꼽고, 그래서 다 되기 전에는 아무것도 못 내보낸다고 적었다. 못 내보낸다는 그 대목이 배포와 공개가 한 몸일 때만 참이다. 둘을 떼면 절반짜리 로그인이 아무에게도 안 켜진 채로 운영 환경에 이미 들어가 있다. 팀은 그 로그인을 매일 만지고, 다 만든 날 스위치 하나로 켠다. 효용 기준이 안 선다는 판단은 그대로 남는다. 여기서 잘린 것은 사용자가 쥐는 효용이 아니라 마지막 날에 몰려 있던 통합 작업이다.

앞 글이 인정한 고정비도 한 항목이 준다. 앞 글은 릴리스와 회귀 테스트와 안내와 컨텍스트 전환 넷을 들었는데, 그중 릴리스는 배포 절차가 매번 같아서 자동으로 돌면 조각 수에 비례해 늘지 않는다. 나머지 셋은 그대로고 회귀 테스트는 오히려 뒤에서 늘어난다.

쓰던 것을 걷어내야 할 때는 효용 대신 위험을 자른다

데이터를 실제로 옮기거나 돌아가던 시스템을 걷어내야 하는 자리에서는 조각을 아무리 잘 잘라도 사용자가 매주 쥐는 것이 안 늘고, 거기서 잘리는 것은 효용이 아니라 한 번에 지는 위험이다.

인터페이스 하나를 바꿔야 하는데 쓰는 곳이 열두 군데면 한 번에 다 고치는 것 말고는 길이 없어 보인다. Sato가 적은 방식은 이렇다. 옛 인터페이스를 그대로 둔 채 새것을 나란히 세우고(확장), 쓰는 쪽을 한 군데씩 옮기고(이전), 다 옮긴 다음에 옛것을 지운다(수축).Danilo Sato, Parallel Change, martinfowler.com, 2014년 5월 13일. 2026년 8월 1일에 원문을 열어 확인했다. 확장과 이전과 수축(expand, migrate, contract)으로 나눠 뒤로 호환되지 않는 변경을 안전하게 한다고 적는다.

돌아가던 시스템을 통째로 갈아야 할 때도 모양이 같다. Martin Fowler는 새것을 다 만들어 한 번에 갈아 끼우는 계획이 대개 불타 무너지는 것을 봤다고 적는다. 교체는 오래 걸리는데 그동안 사용자는 새 기능을 기다려 주지 않는다. 그래서 새것을 옛 시스템 옆에 세우고 동작을 조금씩 옮겨 간다.Martin Fowler, Strangler Fig, martinfowler.com, 2024년 8월 22일. 2026년 8월 1일에 원문을 열어 확인했다. 통째 교체를 두고 we’ve seen this simple-sounding plan go down in flames most of the time이라고 적는다. 덧대기와 갈아엎기를 저울질하는 이야기는 kludge 글에 따로 적었다.

이 자르기에는 안 넘어가는 선이 하나 있다. 이렇게 자른 조각은 사용자 쪽 효용을 안 늘린다. 확장 단계가 끝나도 화면은 어제와 같다. 앞 글에서 나는 학습을 조각낸 것과 효용을 조각낸 것을 갈라 적고, 학습 쪽은 안에서 하는 일이라 내 주장이 아니라고 했다. 갈리는 데는 한 군데다. 확장 단계가 끝난 코드는 팀 안에만 있는 게 아니라 운영 환경에서 돌고 있고, 그래서 세 단계 어디서 멈춰도 제품이 선다. 한 번에 지던 위험을 나눠 지고 중간에 설 수 있다는 것, 이 글이 앞 글에 더하는 것은 그 하나다.

플래그를 달아도 못 자르는 팀이 있다

이 글이 든 도구는 전부 코드에 거는 것이라, 자르기를 막는 것이 코드가 아니라 분기 단위로 못 박힌 로드맵이나 릴리스 승인 절차인 팀에서는 스위치를 아무리 달아도 켜는 날짜가 그대로다.

플래그를 달면 코드는 매일 나간다. 그런데 켜는 날짜가 분기 계획에 박혀 있고 켜려면 승인 회의를 거쳐야 하면 달라지는 게 없다. 배포는 자유로워졌는데 공개는 그대로다. 조직이 쥐고 있는 결정을 코드에 거는 도구로는 못 연다. 그런 팀에서 먼저 바꿀 것은 코드가 아니라 켜는 날을 누가 정하느냐다.

스위치도 재고다

플래그 자체가 비용이라는 것도 같이 적어야 공평하다. Hodgson은 능숙한 팀이 코드에 든 플래그를 재고로 보고 그 재고를 최대한 낮게 유지한다고 적는다. 릴리스용 스위치는 대개 한두 주를 크게 넘겨 두지 말라고 하되, 제품 성격의 스위치는 더 오래 둘 수 있다고 덧붙인다.Hodgson, 같은 글. Savvy teams view the Feature Toggles in their codebase as inventory which comes with a carrying cost and seek to keep that inventory as low as possible. 수명은 should generally not stick around much longer than a week or two이고, 곧바로 although product-centric toggles may need to remain in place for a longer period이라는 예외를 단다. 스위치가 하나 늘 때마다 코드가 가질 수 있는 상태는 곱으로 는다. 그 조합을 다 시험할 필요는 없다고 같은 글이 바로 덧붙이지만, 지워야 할 재고가 쌓이는 것은 그대로다.

그러니 앞에서 줄어든 것처럼 보인 고정비는 없어진 게 아니다. 조각마다 치르던 릴리스 비용이 스위치를 심고 걷어내는 일로 옮겨 갔고, 회귀 테스트 쪽은 오히려 가팔라졌다. 앞 글은 조각 크기를 정보와 고정비를 저울에 올려 정하라고 했다. 이 글이 실제로 한 일은 그 저울의 눈금을 옮긴 것이지 저울을 치운 게 아니다.

마무리

조각내기가 막히는 자리는 대개 칼이 무뎌서가 아니다. 자를 자리를 흐름의 순서에서 찾고 있었거나, 잘라 놓고도 내보낼 데가 없었거나, 반쯤 켜면 손해인 자리를 못 자르는 자리로 접어 뒀거나다.

자를 자리는 여러 갈래로 벌어지는 데 있고, 그중에서는 안 만들어도 되는 것이 드러나는 쪽을 고른다. 코드가 나가는 날과 기능을 켜는 날을 떼면 절반짜리도 매일 내보낼 수 있다. 쓰던 것을 걷어내는 자리에서는 효용 대신 위험을 나눠 진다. 다만 켜는 날을 조직이 쥐고 있으면 셋 다 안 듣는다.

첫 회의의 백로그를 다시 보면 두 일감은 각각 다르게 풀린다. 목록과 상세와 편집으로 끊긴 쪽은 이미 층으로 잘려 있으니 한 일로 도로 합친 다음 다시 잘라야 하고, 신청부터 발송까지 끊긴 쪽은 연차 하나가 신청에서 승인까지 가는 길로 다시 잘린다. 그리고 어느 쪽이든 첫 조각은 아무에게도 안 켠 채 화요일에 내보내면 된다.