더 잘게 쪼갠다고 다 좋은 게 아니에요 — ‘세분화의 비용’이라는 함정

무슨 이야기냐면요

개발하다 보면 ‘더 잘게 나누면 더 좋다’는 믿음이 은근히 깔려 있어요. 큰 덩어리 코드(모놀리식)보다 마이크로서비스, 뭉툭한 권한보다 세밀한 권한, 뭉뚱그린 지표보다 잘게 쪼갠 지표처럼요. 그런데 ‘세분화(granularity)에는 반드시 비용이 따른다’는 관점이 있어요. 잘게 쪼갤수록 얻는 게 분명 있지만, 그만큼 눈에 잘 안 보이는 대가도 같이 커진다는 거죠. 여기에 게임 이론(Game Theory, 사람들이 규칙 안에서 자기 이익을 좇아 어떻게 행동하는지를 다루는 학문)의 시각을 얹으면 이야기가 더 또렷해져요.

세분화가 뭐고 왜 그렇게 끌릴까요

세분화는 쉽게 말해 ‘얼마나 잘게 쪼개느냐’예요. 권한을 예로 들면, ‘관리자 / 일반 사용자’ 둘로만 나눌 수도 있고, ‘글 읽기 / 글 쓰기 / 글 삭제 / 댓글 달기 / 설정 변경…’처럼 잘게 나눌 수도 있어요. 잘게 나누면 정밀하게 통제할 수 있으니 당연히 좋아 보이죠. 보안에서 말하는 ‘최소 권한 원칙’에도 맞고요. 그래서 우리는 본능적으로 ‘더 세밀하게’가 곧 ‘더 잘 설계된 것’이라고 느껴요.

그런데 어디서 비용이 새어 나올까요

문제는 쪼갠 조각이 늘어날수록 그것들을 조율(coordination)하는 비용이 기하급수적으로 커진다는 거예요. 권한을 50개로 쪼개 놓으면 정작 누구한테 뭘 줘야 할지 아무도 정확히 모르는 ‘관리 지옥’이 와요. 마이크로서비스를 잘게 쪼개면 배포는 독립적이 되지만, 서비스끼리 네트워크로 통신하면서 지연·장애 추적·분산 트랜잭션 같은 새로운 골칫거리가 생기고요. 모니터링 지표에 태그를 잘게 붙이면(이걸 카디널리티가 높다고 해요) 저장·조회 비용이 폭발해요.

여기서 게임 이론이 등장해요. 규칙이 세밀해질수록 사람들은 그 규칙의 빈틈을 파고들어 ‘규칙에 최적화된 행동’을 하게 돼요. 측정 지표를 잘게 쪼개 평가에 쓰면, 사람들은 진짜 목표가 아니라 그 지표 숫자만 올리는 쪽으로 움직이죠. ‘측정이 목표가 되는 순간 좋은 측정이 아니게 된다’는 굿하트의 법칙(Goodhart's Law)이 딱 이거예요. 세분화는 통제력을 주는 대신, 통제 대상이 그 틈을 비집고 들어올 표면적도 같이 넓혀 버려요.

실무에서 비교해 보면

같은 원리가 곳곳에서 반복돼요. 가격 정책을 너무 잘게 쪼개면(요금제 12개!) 고객은 오히려 고르기를 포기해 버려요. 함수를 지나치게 잘게 쪼개면 한 동작을 이해하려고 파일 열댓 개를 왔다 갔다 해야 하고요. 반대로 너무 안 쪼개면 거대한 한 덩어리가 돼서 또 손대기 무섭죠. 그래서 핵심은 ‘쪼개느냐 마느냐’의 이분법이 아니라, 이 쪼갬이 주는 이득이 따라오는 조율 비용보다 큰가를 그때그때 따지는 거예요.

한국 개발자에게 주는 시사점

설계 회의에서 ‘일단 잘게 나눠두면 나중에 편하겠지’라는 말이 나오면, 한 번쯤 멈춰서 물어보면 좋아요. ‘이걸 나누면 누가, 얼마나 자주, 어떤 비용을 치르며 조율해야 하지?’ 적정 입도(right-sizing)를 찾는 감각은 마이크로서비스, 권한 모델, API 설계, 지표 설계 등 거의 모든 설계 결정에 그대로 적용돼요. 세분화는 공짜 옵션이 아니라 비용을 동반한 트레이드오프라는 걸 기본값으로 깔고 보는 것, 이게 시니어와 주니어를 가르는 작은 차이이기도 해요.

한 줄 정리

세분화는 정밀함을 주지만, 그 대가로 조율 비용과 ‘규칙을 파고드는 행동’을 함께 키워요. 잘게 쪼개기 전에 ‘이 정밀함, 정말 그 비용을 치를 만한가?’를 먼저 물어보세요.

여러분은 어떤 영역에서 ‘너무 잘게 쪼개서 오히려 손해 봤던’ 경험이 있으세요? 마이크로서비스, 권한 관리, 아니면 코드 구조 어디였나요?