비즈니스 로직에 대한 나의 기준

비즈니스 로직이란 "프로그램이 실제로 해야하는 일의 핵심 규칙과 처리 과정"을 의미합니다.

더 쉽게 설명을 드리자면, 서비스가 제공하려는 본질적인 기능과 규칙을 구현한 부분입니다.

 

바로 위에 말씀드린 두 개의 말이 저의 기준을 나타냅니다.

 

저는 다음 3가지 질문으로 비즈니스 로직을 구분합니다.

 

1. 왜(Why)? - 이 규칙이 존재하는 이유
2. 누가(Who)? - 이 규칙을 정의하는 사람
3. 어디서(Where)? - 이 규칙이 적용되는 범위

 

1. 왜(Why)?

비즈니스 로직을 구분하는 가장 중요한 질문은 "왜 이렇게 동작해야 하는가?"입니다.

export function useDebounce<T>(value: T, delay: number = 500): T {
  const [debouncedValue, setDebouncedValue] = useState<T>(value);

  useEffect(() => {
    const timer = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(timer);
    };
  }, [value, delay]);

  return debouncedValue;
}


export default useDebounce;

 

평범한 Debounce 훅입니다.

그렇다면 저희는 먼저 생각해야 할 것이 Debounce를 "왜"쓰는가 입니다.

다들 아시다시피, 한 번에 많은 이벤트/API 호출이 발생하면 성능 저하와 서버 부하가 발생합니다.

디바운스는 "입력이 멈출 때까지 기다렸다가 한 번만 호출"하여 불필요한 호출을 줄입니다.

 

그렇다면 왜 디바운스를 500ms로 설정했을까요?

성능 최적화와 서버 부하 감소를 위해

이것은 기술적 목적이지, 업무 규칙이 아닙니다.

 

도메인 지식이 필요한가요? 아닙니다.

조직마다 다른 규칙인가요? 아닙니다.

 

따라서 디바운스는 비즈니스 로직이 아닌 기술적인 유틸리티입니다.

 

 

 

2. 누가(Who)?

두번째 질문은 "누가 이 규칙을 정하는가?"입니다.

 

Debounce를 다시 보겠습니다.

 

"검색 입력 시 몇 ms 후에 API를 호출할까요?"

 

이 질문을 도메인 전문가에게 질문할 필요가 있을까요? 혹은 다른 팀장이나 기획자에게 물어볼 필요가 있을까요?

없습니다. 개발자가 성능과 UX 고려를 위해 결정해야할 부분입니다. 

즉, 이것은 단순히 기술적 판단 영역입니다.

 

반면 비즈니스 로직을 보겠습니다.

enum TEAM {
  TEAM_A = 1,
  TEAM_B = 2,
  TEAM_C = 3,
}

export default function Component(){
  const user = getUser();
  
  if(user.teamId === TEAM.TEAM_A){
    return <TeamAComponent/>
  }
  // ...
  else if(user.teamId === TEAM.TEAM_C){
    return <TeamCComponent/>
  }
}

 

"누가 어떤 화면을 볼 수 있나요?"

"누가 어떤 권한을 가지나요?"

 

이에 대한 질문은 개발자가 임의로 판단할 수 없습니다.

"OO팀은 OO화면만 볼 수 있습니다."

이것은 조직 정책입니다.

개발자가 임의로 "아무나 모든 화면을 볼 수 있게 하자"고 결정할 수 없습니다.

 

즉, 개발자가 내린 결정은 기술 로직이 되고,

도메인 전문가가 내린 결정은 비즈니스 로직이 됩니다.

 

 

 

3. 어디서(Where)?

마지막 질문은 "이 규칙이 어디에서나 통용되는가?"입니다.

즉, 이 규칙이 적용되는 범위입니다.

 

디바운스를 다시 보겠습니다.

 

이 코드를 다른 조직, 다른 프로젝트에 그대로 복붙해서 쓸 수 있을까요?

물론 회사 코드를 임의로 유출하는 것은 절대 안되지만 디바운스라는 기술을 자신이 다른 프로젝트에 적용할 수 있을까요?

 

이는 얼마든지 가능합니다.

쇼핑몰이든, 은행이든, 병원이든 성능 최적화가 필요하다면 얼마든지 똑같이 사용할 수 있습니다.

 

디바운스는 도메인과 무관한 범용 기술입니다.

 

반면 비즈니스 로직을 보겠습니다.

enum TEAM {
  TEAM_A = 1,
  TEAM_B = 2,
  TEAM_C = 3,
}

이 팀 구조를 다른 조직에서, 다른 프로젝트에서 그대로 쓸 수 있을까요?

 

불가능합니다.

다른 조직은 팀이 다를 수도, 없을 수도, 더 많을 수도 있습니다.

 

이것은 우리 조직만의 고유한 규칙입니다.

 

즉, 모든 곳에서 동일하게 사용가능하다면 기술 로직입니다.

특정 도메인/조직에서만 적용된다면 비즈니스 로직입니다.

 

 

정리하자면

Debounce는 

1. 왜? -> 성능 최적화
2. 누가? -> 개발자가 결정
3. 어디서? -> 어디에서나 적용 가능

이런 기준으로 기술 유틸리티입니다.

 

반면 팀별 권한은

1. 왜? -> 조직 정책
2. 누가? 도메인 전문가(혹은 기획자)가 결정
3. 어디서? -> 조직 내에서만 적용

이므로 비즈니스 로직입니다.

 

이 세가지 질문 중 하나라도 "비즈니스"에 해당된다면 그것은 비즈니스 로직입니다.

 

 

 

---

왜 기준을 세워야하는가

 

제가 비즈니스 로직에 대해 깊은 생각을 하게 된 계기는 어떤 자바 개발자 분을 만나면서였습니다.

자바 개발자로 들어오셨지만 프론트엔드 또한 관심이 많아 그분에게 여러가지를 알려드리며 저 또한 스프링부트에 대해 여러가지를 배웠습니다.

 

시작은 

"폴더/파일 구조를 왜 이렇게 나누셨나요?" 였습니다.

 

단순하게 UI로직과 그에 해당되는 비즈니스 로직을 나누던 제게 잠시 생각할 시간을 주었지만 저만의 기준이 확고했던 저는 금방 답을 내렸습니다.

얼마 안있어 코드를 리펙토링하는 중 다음 생각이 떠올랐습니다.

 

기준을 왜 정의해야하는가?

직전에 말씀드린 자바 개발자분 덕분에 이에대해 많은 고민을 했었습니다. 취준생이었던 시절, 면접관에게 최대한 깔끔한 코드로 보이기 위해,

취업 이후엔, 협업 또는 유지보수를 위해라고 생각했었습니다.

 

제가 기준을 정한 로직이 누군가는 비즈니스 로직이라 정의하고 누군가는 아니라 말합니다.

세상에 정답이 없듯이 프로그래밍 또한 정답이 없습니다.

누군가 비즈니스 로직이라 정의한다면 비즈니스 로직이 될 것이고, 다른 로직이라하면 그 로직이 될 것입니다.

 

때문에 저희는 저희만의 기준을 세워야합니다.

개인, 또는 조직이 기준을 세우고 그 기준을 지켜나가며 프로그램을 만드는 것이 유지보수 가능한 코드의 시작입니다.

저희가 선택한 기준이 저희가 원하는 정답이 아닐지도 모릅니다. 하지만 기준을 세운 만큼 저희는 저희가 걸어왔던 길을 명확히 알고있고 발자국을 따라 다시 되돌아간 후, 다른 기준을 정하면됩니다.

 

이것이 제가 "왜 기준을 정하는가" 혹은 "왜 기준을 정해야만하는가"에 대한 답입니다.