10-200 룰

 

베어코드님의 OOP 영상을 보다가 알게 된 규칙이에요.

 

• 함수는 10줄 이내
• 클래스(파일)는 200줄 이내

 

처음 들었을 때는 *"그게 가능해?"* 싶었어요.

실무에서 100줄짜리 함수도 흔하고, ViewController 하나가 500줄을 넘는 것도 드문 일이 아니니까요.

 

근데 이 룰의 핵심은 숫자 자체가 아니라, 그 숫자를 지키려고 노력하는 과정에서 코드가 좋아진다는 거예요.

 

왜 10줄인가

 

함수가 10줄을 넘기 시작하면 대부분 두 가지 이상의 일을 하고 있어요.

 

예를 들어 이런 코드:

 

def load_user_profile(self):
    user_id = self.storage.get("user_id")
    if not user_id:
        return
    url = f"https://api.example.com/users/{user_id}"
    headers = {"Authorization": f"Bearer {self.token}"}
    response = requests.get(url, headers=headers)
    if response.status_code != 200:
        return
    data = response.json()
    user = User(
        name=data["name"],
        email=data["email"],
        profile_image=data["profile_image_url"]
    )
    self.name_label.text = user.name
    self.email_label.text = user.email
    self.profile_image_view.load(user.profile_image)

 

이 함수 하나에 사용자 ID 가져오기, HTTP 요청, 응답 파싱, 객체 생성, UI 업데이트가 전부 들어있어요.

10줄 룰을 지키려고 하면 자연스럽게 쪼개게 되죠.

 

def load_user_profile(self):
    user_id = self.get_current_user_id()
    if not user_id:
        return
    user = self.fetch_user(user_id)
    self.update_ui(user)

 

쪼개는 과정에서 각 함수가 하나의 일만 하게 돼요.

이게 결국 단일 책임 원칙(SRP)으로 이어지는 거죠.

 

SRP는 SOLID 원칙의 첫 번째이자 가장 기본이 되는 원칙이에요.

"모든 모듈은 변경의 이유가 하나여야 한다."

 

근데 이걸 머릿속으로만 이해하고 코드에 적용하기는 쉽지 않거든요.

10줄 룰은 SRP를 구체적인 숫자로 체감하게 해주는 장치예요. 10줄 안에 두 가지 일을 넣는 건 물리적으로 어려우니까요.

 

추상화 수준을 맞춘다는 것

 

라면 조리법을 생각해보면:

"물 550ml를 끓인다"

 

이 한 줄 안에는 사실 냄비 꺼내기, 정수기에서 물 받기, 가스 켜기 같은 세부 사항이 숨어 있어요.

근데 조리법에는 그런 디테일을 안 쓰잖아요. 같은 추상화 수준으로 묶어서 한 줄로 표현하는 거죠.

 

함수도 마찬가지예요.

한 함수 안에 고수준 로직(정책 결정)과 저수준 로직(구현 세부 사항)이 섞여 있으면 읽는 사람이 혼란스러워져요.

10줄 룰을 지키려고 하면 자연스럽게 추상화 수준을 맞추게 돼요.

 

왜 200줄인가

 

클래스가 200줄을 넘기면 보통 여러 역할을 떠안고 있다는 신호예요.

 

어떤 언어든 마찬가지예요.

네트워크 호출, 데이터 가공, UI 업데이트, 유저 인터랙션 처리가 전부 한 파일에 있는 상태.

 

200줄을 지키려고 하면 자연스럽게 역할을 분리하게 되거든요.

• 네트워크 → Repository
• 데이터 가공 → Service / UseCase
• UI 로직 → ViewModel
• 뷰 → View / Controller

 

이 과정에서 아키텍처가 자연스럽게 정리돼요.

200줄이라는 숫자가 아키텍처를 강제하는 셈이죠.

 

OOP에서 자주 말하는 높은 응집도(High Cohesion)와 낮은 결합도(Low Coupling)도 결국 이 과정에서 만들어져요.

한 클래스가 하나의 역할만 갖고 있으면 응집도가 높아지고, 역할이 분리되면 클래스 간 의존성이 줄어들어 결합도가 낮아지거든요.

 

200줄을 의식하는 것만으로 이 두 가지가 자연스럽게 따라온다는 게 이 룰의 매력인 것 같아요.

 

self를 안 쓰면 빼라

 

클래스 다이어트에 도움이 되는 팁 하나.

메서드 안에서 self를 사용하지 않는다면 그 메서드는 해당 클래스에 있을 이유가 없어요.

 

class UserController:
    # self를 안 쓰는 메서드 → 이 클래스에 있을 필요가 없음
    def format_date(self, date):
        return date.strftime("%Y.%m.%d")

 

이런 메서드는 별도의 유틸리티 모듈이나 함수로 빼는 게 맞아요.

이것만 의식해도 클래스가 꽤 가벼워지거든요.

 

현실적으로

 

솔직히 모든 함수를 10줄, 모든 클래스를 200줄 안에 넣는 건 불가능해요.

복잡한 비즈니스 로직이나 레거시 코드에서는 어쩔 수 없이 넘길 때가 있죠.

 

근데 이 룰의 가치는 숫자 자체를 지키는 데 있는 게 아니에요.

10줄, 200줄을 의식하면서 코드를 쓰면, 자연스럽게 함수를 쪼개고, 역할을 분리하고, 추상화 수준을 맞추게 돼요.

 

그 과정이 결국 SRP를 지키는 것이고, 읽기 좋은 코드를 만드는 거죠.

 

SOLID, OOP 원칙, 클린 코드 — 다 좋은 개념인데, 실무에서 *"그래서 어떻게 적용하는데?"* 하는 순간이 많잖아요.

10-200 룰은 그 질문에 대한 가장 단순한 답인 것 같아요.

숫자가 목적이 아니라 수단. 근데 그 수단이 꽤 강력해요.