[개발 실무] 함수는 단순한 코드 묶음이 아니다: 클린 코드와 설계의 본질

함수를 단순히 중복 코드를 줄이는 용도로만 사용하고 계신가요? 함수가 가진 '추상화', '단일 책임', '계약'이라는 진짜 의미와 클린 코드를 작성하기 위한 함수의 본질을 알아봅니다.

우리는 프로그래밍을 처음 배울 때, 함수(Function)를 "반복되는 코드를 묶어 재사용하는 것"이라고 배웁니다. 물론 틀린 말은 아니지만, 이는 함수가 가진 기능의 아주 작은 일부일 뿐입니다. 시스템이 복잡해질수록 함수를 단순히 '코드 묶기(서랍 정리)'로만 접근하면 유지보수와 협업에서 큰 벽에 부딪히게 됩니다.

소프트웨어 공학에서 함수의 본질은 '행동을 하나의 의미 있는 단위로 만드는 것'입니다. 즉, 코드를 작성하는 기계적인 도구가 아니라, 인간의 인지적 부담을 줄이고 시스템을 설계하는 인지적 파티셔닝(Cognitive Partitioning) 도구입니다.

이번 글에서는 단순한 코드 묶음을 넘어, 좋은 소프트웨어 설계를 위해 우리가 함수를 어떻게 바라보아야 하는지 5가지 핵심 관점에서 정리해 보겠습니다.

--------------------------------------------------------------------------------

1. 함수는 ‘행동에 이름을 붙이는 도구’다

함수는 단순한 명령어의 나열이 아니라, 의미 있는 행동에 이름을 붙이는 작업입니다. 이름이 붙는 순간 코드는 '설명'이 되며, 좋은 함수 이름은 복잡한 로직을 하나의 문장처럼 읽히게 만듭니다.

복잡하게 뒤엉킨 전선들을 상자 안에 넣고 겉에 '전등 켜기 스위치'를 달아놓는 것을 상상해 보세요. 우리는 내부 전선 구조를 몰라도 스위치의 이름만 보고 목적을 달성할 수 있습니다.

• 《클린 코드(Clean Code)》의 저자 로버트 C. 마틴은 "이름은 그 존재 이유, 수행하는 일, 사용 방법을 모두 알려주어야 하며, 주석이 필요하다면 이름이 의도를 제대로 드러내지 못한 것"이라고 강조했습니다.
• userAccountBalance나 calculateMonthlyPayment()처럼 의도를 드러내는 이름(Intention-Revealing Names)을 사용하면 코드 자체가 훌륭한 문서가 됩니다 (Self-Documenting Code).

--------------------------------------------------------------------------------

2. 함수는 ‘사고를 나누는 경계선’이다

함수는 프로그램을 여러 개 사고 단위로 나누는 역할을 합니다. 즉, 코드를 물리적으로 나누는 것이 아니라 생각을 나누는 것입니다.

요리를 할 때 '재료 손질' → '굽기' → '플레이팅'으로 단계를 분리하듯, 큰 문제 박스를 여러 작은 박스로 분해하는 구조도가 바로 함수의 호출 흐름이 되어야 합니다.

• 단일 책임 원칙 (SRP)과 관심사 분리 (SoC) : 하나의 함수는 '오직 한 가지 역할'만 해야 이해하기 쉽습니다. 코드가 데이터를 검증하고, 계산하고, 포맷을 변경하는 일을 동시에 한다면 이는 분리되어야 합니다.
• 추상화 수준의 대칭성 (Symmetry) : 함수 내의 모든 코드는 동일한 추상화 수준(기술적 세부 사항의 깊이)을 가져야 합니다. 고수준의 비즈니스 로직("A에서 B로 이동하라")과 저수준의 구현 디테일("왼발을 6인치 앞으로 내딛어라")이 한 함수에 섞여 있으면, 뇌는 두 가지 다른 파장 사이에서 멀티태스킹을 강요받아 쉽게 지치고 버그가 숨을 공간이 생깁니다.

--------------------------------------------------------------------------------

3. 함수는 ‘내부를 숨기는 장치(추상화)’다

함수의 가장 강력한 기능 중 하나는 바로 내부 구현을 숨기는 것(Information Hiding)입니다. 우리는 자동차 엔진의 원리를 몰라도 운전대를 잡을 수 있고, 커피 머신의 내부 기어 작동 원리를 몰라도 버튼 하나로 커피를 내릴 수 있습니다.

함수 역시 마찬가지입니다. 호출하는 쪽에서는 결과(Output)만 알면 되며, 내부 구현이 바뀌더라도 사용하는 쪽은 영향을 받지 않아야 합니다.

• 시스템 설계 관점에서 존 아우스터하우트(John Ousterhout) 교수는 "깊은 모듈(Deep Modules)"을 강조합니다.
• 훌륭한 함수는 인터페이스는 극도로 단순하면서도 그 이면에 복잡하고 강력한 구현을 숨기고 있는 '깊은' 형태를 띠어야 합니다. 복잡성을 함수 내부로 끌어내려 사용자(다른 개발자)의 삶을 편하게 만들어야 합니다.

--------------------------------------------------------------------------------

4. 함수는 단순한 재사용 도구가 아니라 ‘계약’이다

초보 개발자들은 종종 함수를 '재사용'의 목적으로만 바라봅니다. 하지만 함수는 입력을 받고 출력을 내놓는 일종의 약속이자 계약(Contract)입니다.

자동 판매기에 돈을 넣으면 원하는 음료가 나온다는 신뢰 구조가 있듯, 함수 역시 "이 값을 넣으면 반드시 이 결과가 나온다"는 신뢰를 바탕으로 작동합니다.

• 버트란드 마이어(Bertrand Meyer)가 제창한 계약에 의한 설계(Design by Contract, DbC) 개념에 따르면, 소프트웨어의 신뢰성은 각 요소 간의 엄격한 계약(사전 조건, 사후 조건, 불변성)에 의해 보장됩니다.
• 이렇게 명확한 계약을 맺은 함수는 독립적으로 테스트 가능(Testable)해지며, 시스템 전체의 견고함을 높입니다.

--------------------------------------------------------------------------------

5. 입문자가 흔히 하는 함수에 대한 오해 5가지

PDF 자료와 여러 코드 리뷰 사례를 종합해 보면, 입문자들이 함수에 대해 흔히 하는 오해는 다음과 같습니다.

1. 함수는 그냥 코드 정리용이다 : 단순히 긴 코드를 접어두는 폴더가 아닙니다. 독립된 행동의 단위입니다.
2. 함수는 무조건 짧아야 한다 : 무조건적인 길이 단축이 능사는 아닙니다. 무의미하게 작게 쪼개진 얕은(Shallow) 함수들은 오히려 인지 부하를 높이고 인터페이스만 복잡하게 만듭니다. '의미 있는 단위'인가가 핵심입니다.
3. 함수 안에서 모든 걸 처리하려 한다 : 플래그(Boolean) 매개변수를 넘겨 한 함수 안에서 if/else로 여러 동작을 처리하는 것은 '한 가지 일만 하라'는 원칙을 위배하는 전형적인 안티 패턴입니다.
4. 함수의 역할을 명확히 나누지 않고 덩어리로 만든다 : 응집도는 높이고 결합도는 낮추어 관심사를 명확히 분리해야 합니다.
5. return을 단순 출력으로 오해한다 : return은 단순히 콘솔에 값을 찍는 것이 아니라, 계약의 결과물이자 다음 로직으로 이어지는 데이터의 흐름입니다.

--------------------------------------------------------------------------------

마무리: 이 개념을 이해하면 무엇이 달라질까?

함수가 단순한 코드 묶음이 아니라는 사실을 깨닫는 순간, 개발자의 태도는 코드를 '작성(Writing)'하는 것에서 '설계(Designing)'하는 것으로 바뀝니다.

혼자만 알아보던 엉킨 실타래 같은 메모장 수준의 코드가, 누구나 알아볼 수 있는 다이어그램 같은 설계도로 변모합니다. 그 결과 코드는 읽기 쉬워지고, 유지보수에 드는 막대한 비용이 줄어들며, 진정한 의미의 팀 협업이 가능해집니다.

기억하세요. "함수는 코드를 묶는 도구가 아니라, 행동을 하나의 의미 단위로 만드는 장치입니다."