회의실에서 제가 가장 참기 힘든 순간은 누군가 "일단 일을 잘게 쪼개서 애자일하게 가시죠"라고 말할 때입니다. 그 '쪼갠다'는 기준이 무엇입니까? 단순히 개발자 일정을 맞추기 위한 쪼개기인가요, 아니면 비즈니스 임팩트를 검증할 수 있는 최소 단위인가요? 주니어 PM/PO들이 흔히 범하는 실수는 복잡한 문제를 만났을 때, 논리적 설계 없이 그저 눈앞의 덩어리를 무작위로 타격해 파편화시킨다는 점입니다. 저는 이것을 '기획'이라 부르지 않고 '파괴'라고 부릅니다. 여러분이 Jira 티켓을 생성할 때마다 프로덕트는 견고한 성이 될 수도, 아니면 아무도 밟고 싶어 하지 않는 날카로운 자갈밭이 될 수도 있습니다. 오늘은 수학과 지질학에서 발견한 놀라운 사실을 통해, 왜 우리의 '쪼개기'가 대부분 실패하는지 이야기해보려 합니다.
헝가리의 수학자 가보르 도모코스(Gábor Domokos)와 펜실베이니아 대학교의 지구물리학자 더글러스 제롤막(Douglas Jerolmack)은 2020년, 매우 흥미로운 연구 결과를 발표했습니다. 그들은 자연계의 암석이 깨지는 패턴을 수년간 추적했습니다. 놀랍게도 자연 상태에서 암석이 무작위로 쪼개질 때, 그 파편들은 평균적으로 '큐브(육면체)' 형태에 수렴한다는 사실을 수학적으로 증명해냈습니다. 플라톤이 수천 년 전 "지구는 큐브로 이루어져 있다"고 주장했던 형이상학적 직관이, 현대 과학의 데이터로 입증된 것입니다.
이 연구가 우리에게 시사하는 바는 명확합니다. 자연조차도 무질서하게 붕괴하는 것처럼 보이지만, 그 이면에는 '가장 안정적인 형태'로 수렴하려는 기하학적 질서가 존재한다는 것입니다. 큐브는 빈틈없이 공간을 채울 수 있는(tessellation) 가장 효율적인 구조입니다. 반면, 우리가 만드는 프로덕트 백로그와 사용자 스토리(User Story)는 어떻습니까? 6면체처럼 서로 딱 맞물려 견고한 구조를 이루고 있습니까, 아니면 이리저리 튀어나와 서로 찌르고 틈을 만드는 날카로운 파편들입니까? 저는 카카오페이 재직 시절, 송금 프로세스를 개선하며 뼈저린 실패를 경험했습니다. 당시 빠른 배포에만 매몰되어 기능을 개발자 단위로 무작위로 쪼갰습니다. 결과는 처참했습니다. 각 기능은 독립적으로 동작하는 듯했으나, 통합 테스트 단계에서 데이터 정합성이 깨지고 엣지 케이스가 쏟아져 나왔습니다. 우리는 '큐브'를 만든 게 아니라, 쓰레기 더미를 쌓고 있었던 겁니다.
비즈니스 요구사항을 분해할 때 '감'에 의존하지 마십시오. 자연이 암석을 쪼개는 방식에서 배워야 합니다. 도모코스 교수는 어떤 물체를 무작위로 자를 때, 볼록한 모자이크 형태가 되려면 평균적으로 6개의 면과 8개의 꼭지점을 가진다는 것을 증명했습니다. 이는 소프트웨어 아키텍처나 조직 구조에도 동일하게 적용됩니다. MSA(Microservices Architecture)를 도입한다며 도메인 경계(Bounded Context)를 고려하지 않고 서비스를 나눈 조직들이 겪는 고통을 보십시오. 그들은 빈틈없이 맞물리는 블록을 만드는 대신, 서로 호환되지 않는 인터페이스의 지옥(Integration Hell)을 만듭니다. '쪼갠다'는 행위는 단순히 크기를 줄이는 것이 아니라, 다시 조립했을 때 완벽한 구조물이 되도록 '단위'를 설계하는 과정이어야 합니다.
솔직히 말해, 저도 처음에는 이 개념을 이해하지 못했습니다. 토스에서 대출 비교 서비스를 고도화할 때, 저는 전환율 데이터가 정체되는 원인을 찾지 못해 막막했습니다. 그때 팀원들과 함께 사용자 여정(User Journey)을 다시 뜯어보았습니다. 우리는 사용자가 겪는 단계를 공급자 관점에서 임의로 나누고 있었습니다. 사용자는 '조회-비교-신청'이라는 하나의 흐름으로 인식하는데, 우리는 이를 'API 호출', 'UI 렌더링', '로그 적재'라는 기술적 파편으로 쪼개서 관리하고 있었던 것입니다. 이 파편들을 사용자의 인지 흐름에 맞춰(마치 큐브처럼) 재조립하고 나서야, 비로소 이탈률이 급격히 줄어드는 것을 목격했습니다. 데이터는 거짓말을 하지 않습니다. 여러분의 기획이 삐걱거린다면, 그것은 여러분이 만든 조각들이 서로 맞물리지 않는 기형적인 형태이기 때문입니다.
결론적으로, 프로덕트를 기획한다는 것은 혼돈 속에서 질서를 찾아내는 기하학적 행위입니다. 여러분이 작성하는 PR(Pull Request) 하나, 티켓 하나가 전체 시스템이라는 거대한 구조물 속에서 빈틈없이 채워지는 '큐브'인지 자문해 보십시오. 개발자에게 "이 기능 내일까지 되나요?"라고 묻기 전에, "이 기능은 전체 구조에서 어떤 면을 담당합니까?"라고 스스로 물어야 합니다. 자연은 수억 년의 시간 동안 엔트로피 증가 속에서도 질서를 유지하는 법을 터득했습니다. 고작 몇 주짜리 스프린트를 돌리는 우리가 자연보다 더 무질서하게 일해서야 되겠습니까? 지금 당장 여러분의 백로그를 열어보세요. 그곳에 있는 것은 쌓아 올릴 수 있는 벽돌입니까, 아니면 밟으면 피가 나는 깨진 유리조각입니까?
