개발할 때 '공개 함수에서 다른 공개 함수 호출'을 피해야 하는 이유

요약 소프트웨어 모듈을 작성할 때 흔히 발생하는 설계 실수 중 하나는 한 public 함수(foo)가 다른 public 함수(bar)의 기능을 일부 필요로 할 때, 중복을 피하려는 본능(DRY)으로 인해 foo 내부에서 bar를 직접 호출해 버리는 패턴입니다. 글쓴이는 이러한 방식이 결국 장기적인 문제를 유발한다고 지적합니다. public API의 목적은 외부 호출자가 가장 쓰기 편한 인터페이스를 제공하는 것인데, API 내부 구현을 위해 다른 public API를 재사용하기 시작하면 '외부 사용자의 편의성'과 '내부 추상화 내부에서의 편의성' 사이에 충돌이 발생하기 때문입니다. 결국 외부 사용자는 손댈 필요도 없는 옵션 파라미터들이 점점 늘어나면서 인터페이스가 오염되기 십상입니다. 이를 방지하기 위한 실무 팁으로 글쓴이는 공통 기능을 담당하는 별도의 private 헬퍼 함수를 만들고, 두 public 함수가 모두 그 private 헬퍼를 호출하도록 선제적으로 리팩터링할 것을 제안합니다. private 함수는 인터페이스를 수정하더라도 로컬 범위 내에서 가볍게 고칠 수 있어 유지보수가 훨씬 수월합니다. 단, 자주 쓰이는 public 함수 호출들을 단순히 묶어둔 '단축(shortcut) API'의 경우에는 반대로 순수하게 public 호출만 체이닝해야 중간 계층의 혼란을 막을 수 있습니다. 한편 글쓴이는 이 주제와 관련된 스택 오버플로 질문도 소개했습니다. 가장 많은 추천을 받은 답변에서는 '단일 메서드 격리 테스트를 위한 모킹(mocking)이 어려워지기 때문'에 나쁘다고 설명했으나, 글쓴이는 메서드가 아닌 I/O를 모킹해야 하며 개별 메서드가 아니라 실제 소프트웨어 기능을 테스트해야 한다고 반박했습니다. 또한 조직이나 업계 표준 문서에 적혀 있지 않다고 해서 맹목적으로 규칙을 무시하거나 따르는 태도를 경계하며, 지침의 밑바탕에 깔린 근본적인 이유를 스스로 생각하고 적용해야 한다고 강조했습니다.