[AI 활용법 7] 모듈화 임계값 — AI가 짠 코드를 쪼개는 시점

시리즈 7편. “이 파일 너무 커요”는 의견이다. 숫자가 들어가면 합의가 된다.

왜 숫자가 필요한가

LLM은 한 파일에 모든 걸 몰아넣는 경향이 있다. 그게 첫 응답에 잘 작동하기 때문이다. 그런데 그 파일이 다음 PR에서 모두를 괴롭게 만든다.

“좀 쪼개 줘”라고만 하면 LLM은 두 개로 쪼갠다. 어떻게 쪼개야 하는지에 대한 합의가 없으면 결과가 들쭉날쭉이다. 숫자 기반 임계값 이 가장 단순한 합의다.

임계값 4종

이 숫자는 절대 진리 가 아니라 공용 트리거 다. “넘었으니 자동으로 쪼갠다”가 아니라 “넘었으니 쪼갤지 의논한다”.

컴포넌트 책임의 분리

프런트엔드에서 가장 자주 발생하는 패턴 — 한 컴포넌트가 다음 셋을 동시에 한다:

1. 렌더 (UI)
2. 데이터 페칭 (서버 통신)
3. 전역 상태 변경

이 셋은 각자 다른 이유로 변한다. 하나가 바뀌면 다른 둘도 흔들린다.

분리 후:

Page                  ─ 데이터 페칭 + 라우팅 책임
└─ FeatureContainer   ─ 비즈니스 로직, 상태 조립
   └─ FeatureView     ─ 렌더, 입력만 (props만 받는 순수)
      └─ <Button/>    ─ 디자인 시스템 단위

테스트와 재사용성이 동시에 올라간다. 가장 위 두 계층은 AI에게 시키기 좋고, 가장 아래는 디자인 시스템에 들어간다.

백엔드 — 5계층 분리

LLM에게 “이 엔드포인트 만들어 줘”라고만 시키면 5계층을 하나의 함수 로 합치기 쉽다. 명시적으로 5계층 구조를 알려 주면 결과가 달라진다.

SOLID — 외워야 할 5글자

LLM에게 “이 코드 SOLID 위반 있나?”라고 질문하기 전에, 먼저 어떤 변경이 자주 일어나는가 를 묻는 게 더 유용하다. SOLID는 변경에 반응하는 능력 을 다룬다.

DRY · KISS · YAGNI — 그러나 균형

• DRY — 중복을 피하라. 단, 섣부른 추상화 가 더 나쁘다 (Rule of Three: 같은 패턴이 3번 보이면 그때 추상화)
• KISS — 단순한 것을 우선 (Keep It Simple, Stupid)
• YAGNI — 필요하지 않은 것은 만들지 마라 (You Aren’t Gonna Need It)

LLM은 과도한 추상화 를 사랑한다. 인터페이스, 추상 클래스, 팩토리. 명시적으로 막아 두자: “현재 문제보다 2단계 이상 앞선 추상화 금지”.

순환 의존성 금지

이건 협상 불가다. 모듈 A가 B에 의존하면, B는 A에 의존하지 않는다.

순환 의존성이 보이면:

• 공통 추상 을 위로 끌어올린다 (third module C로 추출)
• 또는 이벤트/콜백 으로 방향을 한쪽으로 만든다

LLM이 무심코 순환을 만든다면, 그건 경계가 잘못 그려졌다 는 신호다. 임시 패치 말고 구조를 본다.

단일 파일이 허용되는 경우

다음 셋이 다 만족되면 단일 파일이 합리적일 수 있다:

• 사용자가 명시적으로 그렇게 요청
• 100줄 미만의 단일 목적 스크립트
• 빌드 도구 없이 그대로 실행 되어야 함

그 외엔 분리가 디폴트.

예시 — LazyClaude의 단일 HTML

LazyClaude는 배포 단위 가 단일 HTML이지만, 개발 시점 에는 논리적으로 여러 섹션으로 나뉜다 (탭별 모듈, 상태 관리, API 클라이언트, 디자인 토큰). 배포의 단일성 과 개발의 모듈화 는 다른 차원의 문제다.

한 줄 요약

“쪼개세요”는 의견. 300줄 / 50줄 / 3단계 / 2책임 은 합의.

다음 편: AI 활용법 8 — 성능 예산과 측정 우선 최적화 이전 편: AI 활용법 6 — ADR