너무 긴 함수를 작게 나누는 기본 기준: 초보 코드 리뷰 Before & After
1. 주제 소개
초보 개발자의 코드에서 자주 보이는 패턴 중 하나가 "한 함수에 모든 작업을 다 넣는 구조"입니다. 예를 들어 `submitOrder()` 함수 하나에서 입력 검증, 할인 계산, API 호출, 에러 처리, 화면 갱신, 알림 표시까지 전부 처리하는 경우가 많습니다. 처음에는 흐름이 한눈에 보인다고 느낄 수 있지만, 함수가 길어질수록 수정 포인트를 찾기 어려워지고 작은 변경도 전체 동작에 영향을 주게 됩니다. 결국 디버깅 시간은 늘어나고, 버그는 더 자주 생깁니다.
이번 글은 너무 긴 함수를 작게 나누는 기준을 현실적으로 정리합니다. 핵심은 코드 미학이 아니라 유지보수 가능성입니다. 한 함수는 한 가지 책임만 갖게 만들고, 변경 이유가 다른 로직은 분리한다는 원칙을 적용하면 길이는 자연스럽게 줄어듭니다. 길이를 억지로 줄이기보다, 읽는 사람이 의도를 빠르게 파악할 수 있는 구조를 만드는 것이 목표입니다.
2. 핵심 내용
긴 함수를 분리할 때 가장 먼저 볼 것은 줄 수가 아니라 책임 개수입니다. 40줄이어도 한 가지 일만 하면 유지가 쉽고, 15줄이어도 검증과 저장과 UI 변경이 섞여 있으면 어렵습니다. 그래서 "이 코드가 왜 바뀔 수 있는가"를 기준으로 덩어리를 나눠야 합니다. 예를 들어 정책 변경으로 자주 바뀌는 검증 로직, 외부 환경 영향이 큰 API 호출, 디자인 변경에 따라 바뀌는 UI 렌더링은 각각 변경 이유가 다르므로 분리하는 편이 좋습니다.
두 번째 기준은 입력과 출력이 명확한가입니다. 함수 분리가 어려운 이유는 보통 외부 변수에 의존하거나 중간 상태를 여기저기 수정하기 때문입니다. 이를 줄이려면 함수가 필요한 값을 인자로 받고, 결과를 반환하도록 만드는 습관이 필요합니다. 이렇게 하면 테스트가 쉬워지고 재사용성도 올라갑니다. 세 번째 기준은 이름만 보고 역할이 보이는가입니다. `doProcess()` 같은 이름보다 `validateOrderForm()`, `calculateTotalPrice()`, `renderOrderSummary()`처럼 동사+대상 구조를 쓰면 흐름이 훨씬 명확해집니다.
마지막으로 분리 순서를 작게 가져가야 합니다. 한 번에 전부 쪼개면 회귀 버그 위험이 큽니다. 먼저 부작용이 적은 계산 로직부터 함수로 분리하고, 그다음 검증, 마지막으로 API와 UI 단을 정리하면 안정적으로 개선할 수 있습니다.
3. 적용 방법
실전에서 바로 쓸 수 있는 방법은 다음과 같습니다. 먼저 긴 함수에서 주석 없이도 문단이 나뉘는 지점을 찾습니다. 보통 검증, 계산, 저장, 출력 단위로 자연스럽게 끊깁니다. 다음으로 각 문단 위에 "무슨 일"인지 한 줄로 써보고, 그 문장을 함수명 후보로 사용합니다. 이후 원본 함수에서는 세부 구현을 빼고 "흐름만 남기는 오케스트레이터 함수"로 재구성합니다. 최종적으로는 상위 함수가 시나리오를 읽히게 하고, 하위 함수는 한 가지 책임만 수행하게 만드는 구조가 됩니다.
| 분리 기준 | Before 신호 | After 방향 |
|---|---|---|
| 책임 분리 | 검증, 계산, 저장, UI가 한 함수에 혼재 | 역할별 함수로 분리해 변경 영향 범위 축소 |
| 입출력 명확화 | 외부 상태를 직접 수정하고 의존성 많음 | 인자 입력, 반환값 출력으로 테스트 용이성 확보 |
| 이름 개선 | process, handle, run 등 모호한 이름 | 동작이 보이는 구체적 함수명 사용 |
| 점진 적용 | 한 번에 대규모 리팩터링 시도 | 작은 단위 분리 후 매 단계 검증 |
Before 코드에서는 함수를 위에서 아래로 읽어도 핵심 시나리오가 묻혀서 "지금 어디 단계인지" 자주 놓치게 됩니다. After 코드에서는 상위 함수가 `validate -> buildPayload -> request -> render`처럼 흐름을 설명하고, 각 함수 내부는 짧고 집중되어 이해 속도가 빨라집니다. 이 구조는 기능 추가 시에도 강합니다. 예를 들어 할인 정책이 바뀌면 계산 함수만, 에러 표시 방식이 바뀌면 렌더링 함수만 고치면 됩니다.
4. 정리
긴 함수를 작게 나누는 핵심은 "짧게 만들기"가 아니라 "바꾸기 쉽게 만들기"입니다. 책임이 섞여 있으면 코드가 길어질수록 위험이 커지고, 분리되어 있으면 코드가 조금 길어도 유지보수가 쉽습니다. 오늘 적용할 기준은 네 가지입니다. 변경 이유가 다르면 나눈다, 입출력을 명확히 한다, 이름으로 역할을 드러낸다, 작은 단위로 점진적으로 바꾼다. 이 기준만 지켜도 코드 리뷰에서 이해도와 안정성이 동시에 올라갑니다. 좋은 함수는 멋진 함수가 아니라, 다음 수정자가 안심하고 고칠 수 있는 함수입니다.
5. 자주 묻는 질문
Q1. 함수가 너무 많아지면 오히려 복잡해지지 않나요?
무작정 쪼개면 그럴 수 있습니다. 그래서 기준은 "책임 분리"입니다. 같은 책임은 모으고, 다른 책임만 나누면 함수 수가 늘어도 구조는 더 단순해집니다.
Q2. 몇 줄 이상이면 분리해야 하나요?
절대적인 줄 수 기준은 없습니다. 대신 읽다가 역할 전환이 느껴지거나, 수정 이유가 다른 코드가 섞여 있으면 그 지점이 분리 신호입니다.
Q3. 기존 코드가 너무 얽혀 있어서 분리가 어렵습니다.
계산 로직처럼 부작용이 적은 부분부터 떼어내세요. 그다음 검증, 마지막으로 API와 UI를 정리하면 리스크를 낮추며 단계적으로 개선할 수 있습니다.