Clean Coders - Function

develkkm·2025년 10월 17일

CleanCoders

목록 보기
2/6

왜 함수 설계가 중요한가

함수는 프로그램의 최소 단위이자, 개발자의 사고방식을 가장 직접적으로 드러내는 부분이다.
클린 코더스 강의는 “함수는 한 가지 일만 해야 한다”라는 원칙을 중심으로 전개된다.

“함수는 작아야 하고, 한 가지 일만 해야 하며, 잘해야 한다.”

좋은 함수는 작고 명확하다.
그렇기 때문에 읽는 사람이 내용을 단번에 이해할 수 있다.
읽는 사람이 이해하기 쉽다면, 유지보수는 자연스럽게 쉬워진다.


한 가지 일만 해야 한다 (Do One Thing)

함수는 오직 하나의 책임만 가져야 한다.
여러 기능이 한 함수에 섞여 있다면, 그 함수는 이미 역할을 잃은 것이다.

// 나쁜 예시
public void processOrder(Order order) {
    if (order.isPaid()) {
        updateInventory();
        sendEmail(order);
    } else {
        System.out.println("결제되지 않았습니다.");
    }
}

이 함수는 주문 확인, 재고 관리, 이메일 전송까지 모두 처리한다.
이런 형태는 한눈에 파악하기 어렵고, 수정할 때 버그를 유발하기 쉽다.

개선된 예시

public void processOrder(Order order) {
    if (order.isPaid()) {
        completeOrder(order);
    } else {
        handleUnpaidOrder(order);
    }
}

private void completeOrder(Order order) {
    updateInventory();
    sendEmail(order);
}

private void handleUnpaidOrder(Order order) {
    System.out.println("결제되지 않았습니다.");
}

→ 각 기능을 별도의 함수로 추출해 “한 가지 일만” 하도록 만든다.
이 과정에서 함수가 짧고 단순해지며, 읽히는 흐름이 생긴다.


작을수록 좋다 (Smaller Is Better)

함수는 작을수록 읽기 쉽다.
클린 코더스 강의에서는 극단적으로 “4줄짜리 함수”를 목표로 하라고 말한다.
그 이유는 함수가 짧을수록 다음과 같은 장점이 있기 때문이다.

  • 한눈에 읽을 수 있다.
  • 테스트하기 쉽다.
  • 유지보수 시 부담이 적다.

“작을수록 좋고, 작을수록 더 읽히며, 작을수록 변경에 강하다.”

큰 함수를 본다면 먼저 나눌 수 있는 부분을 찾고,
더 이상 추출할 수 없을 때까지 분리해야 한다.

private void generateReport() {
    collectData();
    calculateStatistics();
    printResult();
}

이처럼 함수가 “자연스럽게 한 단계를 설명할 정도”로만 작으면 충분하다.


추상화 수준을 일관되게 유지하라

함수는 내부에서 다루는 추상화 수준이 일관되어야 한다.
상위 수준의 동작과 하위 수준의 구현이 섞이면 읽는 사람이 혼란을 느낀다.

// 나쁜 예시
void processPayment() {
    if (balance > 0) {        // 구체적인 로직
        sendPaymentRequest(); // 높은 수준의 행위
        log("결제 요청 완료");  // 낮은 수준의 세부 처리
    }
}

위의 코드는 서로 다른 추상 수준의 코드가 섞여 있다.
이 경우 하위 세부 로직은 별도의 함수로 추출하는 것이 좋다.


함수 이름은 의도를 표현해야 한다

좋은 이름은 함수를 설명하지 않아도 이해되게 만든다.
함수 이름이 명확하면 주석이 필요 없다.

// 나쁜 예시
void handle() {}

// 좋은 예시
void sendOrderConfirmationEmail() {}

짧은 이름보다 “서술적인 이름”이 더 낫다.
길더라도 읽는 사람이 내용을 예측할 수 있다면 좋은 이름이다.

“함수 이름은 길어져도 좋다. 대신 읽히는 문장이 되어야 한다.”

함수 이름은 처음부터 완벽할 필요는 없다.
처음에는 명확히 쓰고, 나중에 리팩토링하며 다듬으면 된다.


중괄호는 항상 추출의 기회다

if, while, for 블록이 중첩될수록 함수는 복잡해진다.
중괄호 {}가 등장할 때마다 “이 코드를 별도의 함수로 추출할 수 있을까?”를 생각해야 한다.

// before
if (isWeekend()) {
    if (isHoliday()) {
        applyDiscount();
    }
}

// after
if (isWeekendAndHoliday()) {
    applyDiscount();
}

추출된 함수는 읽는 사람에게 의도를 명확히 전달한다.


함수 추출과 클래스화

큰 함수를 보면 “어떻게 나눌까?”가 아니라
이건 새로운 클래스의 신호일 수 있다”라고 생각해야 한다.

class ReportGenerator {
    void generate() {
        readData();
        calculate();
        print();
    }
}

이 경우 readData, calculate, print
각각 독립적인 역할을 가진다면,
별도의 클래스로 나누어 더 높은 응집도를 가질 수 있다.


읽는 사람을 위한 코드

함수는 쓰는 사람이 아니라 읽는 사람을 위해 존재한다.
함수가 실제 사용되는 코드라면, 한 번 작성된 뒤 수십 번 이상 읽히게 된다.


정리

원칙설명
한 가지 일만 수행함수는 하나의 책임만 가져야 한다
작을수록 좋다극단적으로 작게, 읽기 쉽게
추상 수준 일관성상하위 수준이 섞이지 않게 유지
서술적 이름함수 이름으로 의도를 표현
중괄호는 기회조건문, 반복문은 추출 포인트
클래스 추출큰 함수는 클래스로 분리 고려
읽는 사람 중심작성보다 읽기가 많다는 사실 인식
profile
알던것을 더 확실하게

0개의 댓글