비즈니스 로직은 진짜 제품이다 (그래서 나는 logicrepo를 만들었다)

Source: Dev.to

버그가 비즈니스 규칙 때문에 발생했는데 아무도 설명할 수 없었다면, 이 글이 도움이 될 것입니다.

가격 규칙이 프로덕션에서 깨집니다.
고객에게 영향을 미칩니다.
모두가 급히 대응합니다.

그때 가장 끔찍한 질문이 나옵니다:

누가 이것을 바꿨고… 왜 바꿨나요?

때로는 로직이 서비스 레이어에 파묻혀 있습니다.
때로는 검증기와 피처 플래그에 나뉘어 있습니다.
때로는 아무도 신뢰하지 않는 Confluence 문서에 살아 있습니다.

이것은 도구 문제가 아닙니다.
구조적인 문제입니다.

비즈니스 로직은 일급 객체가 아니다

대부분의 코드베이스에서 비즈니스 로직은:

• 프레임워크 및 인프라 코드와 뒤섞여 있다
• 고립된 상태로 리뷰하기 어렵다
• 테스트가 부실하거나(간접적으로) 테스트된다
• 별도로 문서화된다 — 어쩌면 전혀 문서화되지 않을 수도 있다

PR을 리뷰할 때 구현 방식은 보이지만 실제로 어떤 규칙이 바뀌었는지는 보이지 않습니다. 이는 위험합니다. 비즈니스 로직이 바로 실제 제품이기 때문입니다.

AI 시대에 왜 더 중요한가

AI는 컨트롤러, 서비스, 검증기를 생성할 수 있습니다.
하지만 도메인 의도는 생성하지 못합니다.

비즈니스 로직은 다음을 인코딩합니다:

• 가격 결정
• 자격 기준
• 위험 제약
• 제품 전략

코드 생성 비용이 낮아질수록 의도에 대한 명확성이 더 가치 있게 됩니다 — 줄어드는 것이 아니라.

아이디어: 의도와 구현을 분리한다

비즈니스 규칙은 다음과 같아야 합니다:

• 명시적
• 버전 관리됨
• 테스트됨
• 리뷰 가능
• 프레임워크에 구애받지 않음

그 결과가 logicrepo 입니다.

logicrepo란?

logicrepo는 간단한 CLI로, 다음을 할 수 있게 해줍니다:

• YAML로 비즈니스 규칙 정의
• 해당 규칙에 대한 테스트 작성
• CI에서 검증

런타임 매직 없음. 프레임워크 종속성 없음. 단순히 명확히 표현된 규칙만.

예시 (단순화)

rules:
  discount:
    when:
      user.plan: "pro"
    then:
      apply_discount: 20

테스트는 구현 세부 사항이 아니라 의도에 초점을 맞춥니다.

왜 YAML인가?

트렌드라서가 아니라. YAML은:

• 사람이 읽기 쉬움
• PR에서 diff하기 쉬움
• 엔지니어가 아닌 사람도 리뷰 가능

규칙이 바뀔 때, PM과 도메인 전문가가 실제로 무엇이 바뀌었는지 이해할 수 있습니다 — 단순히 무언가 바뀌었다는 사실만이 아니라.

CI를 방어선으로

실행은 의도적으로 지루하게 설계되었습니다:

npx logicrepo check

로컬에서 실행하고 CI에서도 실행합니다. 비즈니스 규칙이 깨지면:

• 빌드가 실패합니다
• 변경 사항이 눈에 띕니다
• 의도가 문서화됩니다

이제 조용한 로직 드리프트는 없습니다.

이것은 규칙 엔진이 아니다

logicrepo는 런타임에 비즈니스 로직을 실행하지 않습니다. 다음과 같은 역할을 합니다:

• 진실의 원천
• 계약
• 비즈니스 규칙에 대한 명세

애플리케이션이 이를 소비하거나, 단순히 자체 검증에 사용할 수 있습니다.

사용해 보기

npx logicrepo check

여러분의 생각을 듣고 싶습니다:

• 오늘날 여러분의 비즈니스 로직은 어디에 있나요?
• 로직 드리프트 때문에 고통받은 적이 있나요?
• 이런 것이 팀에 도움이 될까요?