소프트웨어 개발에서 공개 함수(public function)끼리 서로를 직접 호출하는 방식은 피해야 한다는 경험칙이 강조되고 있습니다. 대신, 여러 공개 함수가 공통으로 사용하는 로직이 있다면 이를 비공개 헬퍼 함수(private helper function)로 추출하여 두 함수가 모두 해당 헬퍼를 호출하도록 하는 것이 권장됩니다. 이는 공개 API(Application Programming Interface)의 목표인 '외부 호출자의 사용 편의성'과 내부 구현의 '코드 재사용성'이라는 두 가지 요구사항이 충돌하는 것을 방지하기 위함입니다.
이러한 충돌은 주로 공개 API에 사용자가 설정해서는 안 되는 선택적 매개변수(optional parameter)가 늘어나거나, 초기 코드 공유 이후 인터페이스가 악화되는 형태로 나타날 수 있습니다. 예를 들어, `foo`라는 공개 함수가 `bar`라는 다른 공개 함수의 일부 작업을 처리할 때, DRY(Don't Repeat Yourself) 원칙에 따라 `foo`에서 `bar()`를 호출하고 싶을 수 있습니다. 하지만 이 방식은 `bar`의 공개 인터페이스가 `foo`의 내부 구현 요구사항에 맞춰 불필요하게 복잡해지거나 변경될 위험을 만듭니다. 반면, 공통 로직을 비공개 헬퍼로 분리하면, 이 헬퍼 함수의 시그니처(signature) 변경은 내부적인 문제로 국한되어 외부 API의 안정성을 해치지 않습니다.
이 원칙은 특히 안정적인 API를 제공해야 하는 공개 라이브러리 개발에서 중요합니다. 공개 API의 잘못된 설계는 장기적으로 호환성 문제를 일으키고, 수정 비용이 매우 커질 수 있기 때문입니다. 물론, 흔히 사용되는 공개 함수 호출 조합을 단축(shortcut) API로 제공하는 경우는 예외입니다. 이때는 오히려 비공개 함수를 호출하지 않아야 진정한 단축 경로를 유지할 수 있습니다. 궁극적으로 모든 지침과 모범 사례는 그 배경과 이유를 이해하고 개발자 스스로의 판단에 따라 적용해야 하며, 맹목적으로 따르는 것은 지양해야 합니다.