AI 앱을 위한 비즈니스 규칙을 평이한 언어로 문서화하기

불명확한 규칙이 신뢰할 수 없는 앱을 만드는 이유

비즈니스 규칙은 앱이 실제 상황에서 무엇을 해야 하는지 알려줍니다. 누가 요청을 승인하는지, 총액은 어떻게 계산되는지, 규칙에서 벗어나는 경우에는 어떤 처리를 하는지와 같은 질문에 답합니다.

그 규칙이 모호하면 앱은 여전히 선택을 해야 합니다. 다만 당신이 기대한 선택과는 다를 수 있습니다.

예를 들어 "큰 비용은 매니저 승인이 필요하다"라는 규칙은 사람이 들으면 명확해 보일 수 있습니다. 하지만 구현자는 그렇지 않습니다. 큰 비용이란 $500일까요, $5,000일까요, 아니면 팀 예산을 초과하는 모든 금액일까요? 어떤 매니저인가요: 직속 매니저, 부서장, 재무인가요? 2일 안에 아무도 응답하지 않으면 요청은 기다리나요, 만료되나요, 아니면 다른 사람에게로 넘어가나요?

이런 식으로 모호한 규칙은 신뢰할 수 없는 앱을 만듭니다. 구현자는 받은 지침만큼만 일관될 수 있습니다. 문구가 추측의 여지를 남기면 앱은 오늘은 이렇게 동작하고 조금 다른 사례가 오면 내일은 다르게 동작할 수 있습니다.

가장 큰 문제는 보통 몇몇 영역에서 발생합니다:

• 반올림, 세금, 할인, 날짜 범위 등 세부가 빠진 계산
• 모두가 가정하되 아무도 문서화하지 않은 예외
• 명확한 소유자, 순서, 대체 규정이 없는 승인 단계

간단한 예가 문제를 보여줍니다. 창업자가 내부 비용 앱을 Koder.ai에서 만들며 "여행비는 이상해 보이지 않는 한 환급한다"라고 적었다고 합시다. 듣기에는 합리적이지만, 앱에는 ‘이상하다’를 판단할 신뢰할 수 있는 방법이 없습니다. 한 직원의 택시비는 승인되고, 비슷한 다른 사람의 택시비는 플래그되고, 이유를 아는 사람은 없습니다.

신뢰할 수 있는 동작은 매번 같은 방식으로 따를 수 있는 규칙에서 시작합니다. "큰", "긴급한", "특별한 경우" 같은 단어는 정확한 한도, 조건, 행동으로 대체되어야 합니다. 서로 다른 두 사람이 같은 방식으로 규칙을 적용할 수 있다면 앱도 같은 방식으로 동작할 가능성이 커집니다.

명확한 비즈니스 규칙의 모습

명확한 비즈니스 규칙은 하나의 결정이나 하나의 행동을 다룹니다. 전체 프로세스를 한 규칙에 담으면 문제가 됩니다. 승인, 가격 책정, 예외, 알림을 한꺼번에 다루면 구현자는 어떤 부분이 중요한지 추측해야 합니다.

좋은 규칙은 소리 내어 읽기 쉬워야 합니다. 팀 밖의 누군가가 내부 약어 없이도 이해할 수 있어야 합니다. "패스트트랙", "표준 사례", "매니저 서명" 같은 용어 대신 실제로 어떤 일이 일어나는지 정확히 말하는 평이한 언어를 사용하세요.

대부분의 명확한 규칙은 네 가지 기본 질문에 답합니다:

• 누가 결정을 내리거나 행동을 취하나?
• 언제 규칙이 적용되나?
• 앱 안에서 무엇이 변경되나?
• 다음에는 무슨 일이 일어나나?

이 구조는 규칙을 실제 동작에 묶어 둡니다. "대형 주문은 검토가 필요하다" 대신에 "주문 금액이 $5,000를 초과하면 영업 매니저가 풀필먼트로 보내기 전에 승인해야 한다"라고 쓰세요. 한 문장, 한 결정, 한 결과입니다.

관련 규칙은 분리해 두는 것이 좋습니다. 승인 규칙은 독립적으로 두고, 이메일 전송 규칙은 따로, 출하 차단 규칙도 따로 두세요. 그렇게 하면 각 규칙을 테스트하고 업데이트하며 수정하기가 더 쉬워집니다.

차이는 분명합니다:

"프리미엄 고객은 우선 처리됩니다"는 모호합니다.

"고객이 프리미엄 플랜인 경우 티켓 생성 시 지원 요청을 높은 우선순위로 표시한다"는 명확합니다.

두 번째 버전은 트리거, 조건, 앱 내부의 변경을 명시합니다. 구현자에게 신뢰할 수 있는 동작이 어떤 모습이어야 하는지 알려줍니다.

채팅 기반 빌더를 사용하는 경우, 이런 문구가 큰 차이를 만듭니다. 명확한 규칙은 법적 문구가 필요하지 않습니다. 한 번에 한 가지 아이디어를 담은 단순한 단어와 한 문장으로 표현 가능한 기대 결과가 필요합니다.

평이한 언어로 계산 쓰기

계산은 단순해 보이지만 실제로 구현하려 하면 복잡해질 때가 많습니다. 가장 안전한 접근은 앱이 정확히 무엇을 해야 하는지 한 문장으로 먼저 쓰는 것입니다.

좋은 규칙은 이렇게 들립니다: "환급 금액은 승인된 마일 수에 마일리지 비율을 곱한 값이다." 이는 "여행비를 계산" 또는 "표준 환급 적용"보다 훨씬 명확합니다.

그 다음에는 앱이 사용해야 할 모든 입력 값을 정의하세요. 구현자가 추측하지 않도록 충분히 구체적으로 적습니다.

모든 계산에서 정의할 항목

각 계산에 대해 다음을 명시하세요:

• 입력값(간단한 이름과 단위 포함)
• 각 값의 출처
• 반올림 규칙
• 최소값 또는 최대값
• 값이 없을 때의 처리

작은 세부가 중요합니다. "최종 금액을 소수점 둘째 자리로 반올림"은 라인 항목마다 반올림하는 것과 다른 결과를 냅니다. 상한이 있다면 앱이 그 상한에서 멈출지 아니면 경고를 보여줄지 명시하세요.

평이한 언어로 작성된 규칙 예시는 다음과 같습니다: "여행 환급 금액은 승인된 마일 수 x $0.67이다. 최종 금액은 소수점 둘째 자리로 반올림한다. 1회 여행당 최대 환급액은 $300이다. 승인된 마일 수가 비어 있으면 금액을 계산하지 않는다. 요청을 미완료로 표시하고 사용자가 마일 수를 입력하도록 요청한다."

그런 다음 실제 숫자를 넣은 예시 1~2개를 추가하세요. 예시는 추상적 공식보다 빠르게 허점을 드러냅니다.

예시 1: "승인된 마일 수가 120이면 환급은 120 x $0.67 = $80.40이다. 이는 $300 한도 이하이므로 최종 금액은 $80.40이다."

예시 2: "승인된 마일 수가 500이면 환급은 500 x $0.67 = $335.00이다. 최대가 $300이므로 최종 금액은 $300.00이다."

이 스타일은 검토자가 이해하기 쉽고 구현자가 앱 동작으로 옮기기 쉽습니다.

혼란 없이 예외 포착하기

대부분의 앱은 기본 규칙에서는 실패하지 않습니다. 엣지 케이스에서 실패합니다.

정상 경로는 단순할 수 있지만 실제 업무는 기한 후 환불, VIP 고객, 누락된 서류, 일회성 승인 등을 포함합니다. 예외를 생략하면 앱이 자체적으로 공백을 채우고, 그때부터 결과가 일관되지 않게 됩니다.

예외를 쓰는 간단한 방법은 짧은 if-then 규칙을 사용하는 것입니다. 각 규칙은 하나의 조건과 하나의 결과에 집중하세요.

• 비용이 $100 미만이면 자동 승인한다.
• 비용이 $100 미만이지만 제출이 30일 이후라면 수동 검토로 보낸다.
• 직원이 임원팀 소속이면 $100 한도를 적용하지 않고 재무로 라우팅한다.
• 재무 관리자가 청구서를 긴급으로 표시하면 수동 재정의가 적용되어 청구서가 대기열 맨 앞으로 간다.

이 형식은 숨겨진 로직을 드러내고 충돌이 버그로 바뀌기 전에 겹침을 찾는 데 도움됩니다.

같이 중요한 것은 두 규칙이 충돌할 때 어느 규칙이 우선하는지 쓰는 것입니다. 고객이 할인 대상일 수 있지만 주문이 휴일 블랙아웃 기간에 걸릴 수도 있습니다. 우선순위를 평이한 언어로 쓰세요: "휴일 블랙아웃 규칙이 고객 할인 규칙과 충돌하면 블랙아웃 규칙이 우선한다."

한도에 대해 정확히 쓰세요. 날짜, 사용자 유형, 지역, 계정 상태, 수동 재정의 등은 결과를 바꿀 수 있습니다. "지각 제출은 승인이 필요하다" 대신에 "이벤트 후 14일을 초과하여 제출된 요청은 매니저 승인이 필요하다"라고 쓰세요.

또한 각 예외에서 앱이 사용자에게 무엇을 보여줄지도 명시하세요. 좋은 규칙은 결정에서 끝나지 않습니다. "14일 이후 제출. 매니저 승인 필요" 또는 "재무 관리자가 수동 재정의를 적용함" 같은 메시지를 정의하세요.

이렇게 예외를 쓰면 이상한 경우가 더 이상 이상하지 않습니다. 정상적이고 테스트 가능한 동작이 됩니다.

승인 로직을 단계별로 설명하기

승인 로직은 모호한 정책 대신 일련의 결정으로 쓰는 것이 가장 좋습니다. 각 단계는 다섯 가지 질문에 답해야 합니다: 누가 행동하나, 무엇이 검토를 트리거하나, 어떤 제한이 있나, 얼마 동안 응답해야 하나, 결정 후 상태는 무엇인가.

먼저 역할을 이름으로 지정하세요. 팀만 쓰지 말고 역할을 적습니다. "재무가 큰 요청을 검토한다" 대신에 "재무 매니저는 $5,000 초과의 모든 요청을 승인, 반려 또는 반송할 수 있다"라고 쓰세요. 그러면 추측이 사라지고 구현이 쉬워집니다.

그다음 각 단계의 트리거를 정의하세요. 트리거는 요청을 다음 사람에게 보내는 조건입니다. 금액, 부서, 위험 수준, 요청 종류 또는 이들의 조합으로 정할 수 있습니다.

예시:

• 요청이 $500 미만이면 팀 리더가 검토한다.
• 요청이 $500~$5,000이면 팀 리더 승인 후 부서 관리자가 검토한다.
• 요청이 $5,000 초과이면 부서 관리자 승인 후 재무가 검토한다.
• 요청이 높은 위험으로 표시되면 최종 승인 전에 컴플라이언스가 검토해야 한다.

임계값은 정확한 경계가 필요합니다. "큰"이나 "민감한"이라고 쓰지 마세요. "$5,000 초과", "영업 부서에서 발생", "위험 점수 8 이상"처럼 쓰세요. 두 개의 임계값이 동시에 적용될 수 있으면 어느 것이 우선인지 쓰세요. 예: "고위험은 금액이 낮더라도 항상 컴플라이언스로 간다."

타임아웃 규칙도 필요합니다. 아무도 응답하지 않으면 앱이 무한정 대기해서는 안 됩니다. 48시간 또는 영업일 기준 3일 등 정해진 시간 후에 어떤 일이 일어나는지 쓰세요. 요청은 승인자의 매니저에게 에스컬레이션되거나 백업 승인자에게 재할당되거나 자동으로 취소될 수 있습니다.

마지막으로 각 결정 후 상태를 정의하세요. 레이블은 짧고 일관되게 유지하세요:

• Approved: 요청이 진행되거나 완료됩니다.
• Rejected: 요청이 종료되며 추가 조치는 없습니다.
• Sent back: 요청자가 수정 후 재제출해야 합니다.
• Escalated: 요청이 백업 또는 상위 승인자에게 이동합니다.

이렇게 승인 로직을 쓰면 구현자가 추측할 여지가 줄어들고 워크플로가 훨씬 신뢰할 수 있게 됩니다.

재사용 가능한 간단한 규칙 템플릿

일관된 동작을 원하면 모든 규칙에 같은 형태를 부여하세요. 다양한 문체는 다양한 결과를 만들기 쉽습니다.

간단한 형식이 대부분의 경우에 잘 작동합니다: 트리거, 조건, 행동, 결과. 빠르게 쓰기에도 충분히 짧고 나중에 다른 사람이 검토하기에도 명확합니다.

한 규칙은 한 단위로

각 규칙을 별도의 줄, 카드, 블록에 두세요. 여러 아이디어를 한 문단에 넣지 마세요. 하나의 규칙이 가격, 승인, 예외를 동시에 다루면 테스트하기 어렵고 오독하기 쉽습니다.

실용적인 템플릿은 다음과 같습니다:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

항목마다 모든 필드가 필요한 것은 아닙니다. 하지만 같은 순서를 유지하면 사람들이 규칙을 빠르게 훑어볼 수 있습니다.

예를 들어:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

예시는 규칙 내부가 아니라 규칙 아래에 둡니다. 규칙은 깔끔하게 유지되고 예시는 규칙이 어떻게 동작해야 하는지를 증명합니다.

가정은 명확히 표시하세요. "Assumption" 또는 "Needs confirmation" 같은 짧은 표시로 미확인 항목을 빼놓지 마세요.

또한 문구를 일관되게 유지하면 도움이 됩니다. 트리거는 항상 "When"로, 조건은 "If"로, 행동은 "Then"으로 시작하세요. 작은 패턴이 혼란을 줄이는 데 효과적입니다, 특히 규칙을 앱 로직으로 옮길 때 더욱 그렇습니다.

간단한 테스트가 유용합니다: 누군가 이 규칙을 테스트할 수 있는가? 누군가 오독할 수 있는가? 테스트가 불가능하거나 오독될 가능성이 있다면 문구를 더 명확히 하세요.

예: 비용 승인 앱

직원 비용 앱은 정책이 친숙하고 엣지 케이스가 빠르게 드러나기 때문에 좋은 테스트 케이스입니다. 직원들은 식대, 택시, 호텔, 소액 접대비 등을 청구할 수 있지만 각 청구에는 한도, 예외, 승인 단계가 있습니다. 이런 프로세스에서는 평이한 언어가 특히 중요합니다.

샘플 정책

식대 규칙을 이렇게 작성하세요: 직원은 일반 근무일에 일일 최대 $40까지 식대를 청구할 수 있습니다. 앱은 같은 날짜의 모든 식대 영수증을 합산하여 일별 한도와 비교해야 하며, 각각의 영수증을 개별적으로 비교하면 안 됩니다.

예: 화요일에 아침 $12, 점심 $22를 썼다면 합계는 $34로 한도 내입니다. 같은 날 저녁으로 $15를 추가하면 합계는 $49가 되어 한도 초과로 플래그됩니다.

이제 예외를 추가하세요. 식사가 승인된 출장이나 고객 미팅 중에 발생한 경우, 일일 식대 한도는 $75로 늘어납니다. 이 예외는 직원이 Travel day = Yes 또는 Client meeting = Yes를 선택하고 고객명 또는 출장 목적을 짧게 적는 경우에만 적용됩니다.

이 방식은 "특별한 경우 허용될 수 있음" 같은 모호한 표현보다 더 신뢰할 수 있습니다. 예외가 명확한 조건에 연결되어 있기 때문입니다.

승인 단계

승인 로직도 똑같이 평이하게 유지할 수 있습니다:

• $100 미만의 청구는 직원의 매니저가 승인합니다.
• $100~$500의 청구는 매니저 승인 후 재무 승인이 필요합니다.
• $500 초과의 청구는 매니저 승인, 재무 승인, 부서장 승인이 필요합니다.
• "travel"로 표시된 모든 청구는 금액이 $100 미만이라도 재무 검토가 필요합니다.

몇 가지 간단한 사례로 규칙을 테스트하세요. 일반 근무일에 첨부된 영수증이 있는 $36 식대 청구는 승인이 되어야 합니다. 출장일로 표시하고 메모를 입력한 $60 식대 청구는 통과해야 합니다. 일반 근무일에 메모가 없는 $60 식대 청구는 반려되거나 수정 요청으로 돌아가야 합니다. $650 호텔 청구는 세 단계의 승인을 모두 거쳐야 합니다.

목표는 동일한 실제 사례로 테스트했을 때 항상 같은 결과가 나오도록 하는 것입니다.

나쁜 결과를 초래하는 흔한 실수

사람에게는 명확하게 들리지만 구현자를 혼란스럽게 하는 규칙이 있습니다. 보통 문서가 모호하거나 여러 아이디어를 한 문단에 담았거나 줄마다 일관성이 없을 때 발생합니다.

흔한 실수 중 하나는 여러 규칙을 긴 문단에 몰아넣는 것입니다. 예: "총액이 높지 않으면 매니저가 승인하고, 재무는 영수증을 확인하며, 긴급 요청은 검토를 건너뛸 수 있다." 이것은 효율적으로 보이지만 여러 결정을 숨깁니다. 각 행동을 별도의 규칙으로 분리하세요.

또 다른 문제는 모호한 언어입니다. 정상, 큰, 긴급, 최근 같은 단어는 정의가 필요합니다. "큰 비용"이 $2,000 이상을 의미하면 그렇게 쓰세요. "긴급"이 24시간 내에 필요함을 뜻하면 그 조건을 명확히 적으세요.

누락된 데이터도 큰 문제입니다. 팀은 종종 정상 경로만 설명하고 정보가 불완전하거나 잘못되었을 때 어떻게 처리할지 쓰지 않습니다. 금액, 부서, 영수증이 없으면 다음에 무슨 일이 일어나는지 규칙에 적으세요.

문제를 일으키는 실수들:

• 여러 규칙을 한 문단에 섞어 적음
• 크기, 시간, 우선순위에 대해 정의하지 않은 용어 사용
• 오류 사례와 누락 필드를 잊음
• 최종 승인 권한을 불분명하게 남김
• 동일한 대상을 문서 중간에 다른 이름으로 부름

최종 권한은 많은 팀이 생각하는 것보다 중요합니다. 매니저와 재무 검토자가 의견이 다르면 누가 최종 결정을 내리나요? 최종 단계를 소유한 사람이 없으면 앱은 정체되거나 작업이 반복될 수 있습니다.

용어를 중간에 바꾸면 조용한 오류가 생깁니다. 처음에 "request"라고 부르다가 나중에 "submission"이나 "ticket"이라고 하면 독자는 서로 다른 항목으로 오해할 수 있습니다. 하나의 용어를 골라 문서 전체에서 일관되게 사용하세요.

채팅 기반 빌더에서는 평이한 언어가 동작을 좌우합니다. 명확한 규칙은 형식적일 필요가 없습니다. 구체적이고, 일관되며, 완전해야 합니다.

빌드 전에 할 빠른 체크리스트

요구사항을 화면, 플로우, 프롬프트로 옮기기 전에 마지막 검토를 하세요. 짧은 확인이 이상한 동작을 고치는 데 드는 시간을 절약해 줍니다.

각 규칙을 테스트 가능하게 만드세요. 각 규칙은 예/아니오, 승인/반려, 수수료 적용/미적용 같은 명확한 결과로 끝나야 합니다. 같은 문장을 두 사람이 읽고 다른 답을 할 수 있다면 규칙을 다듬어야 합니다.

모든 계산을 명시하세요. 입력값 이름, 공식, 계산 시점, 반올림, 통화, 날짜 처리, 값이 없거나 0일 때의 처리를 적습니다.

예외는 분리하세요. 기본 규칙을 먼저 쓰고 예외를 별도로 추가하세요. 주요 지출 한도가 계약자, 긴급 구매, 사전 승인된 출장 같은 특수 사례 안에 숨겨지지 않도록 하세요.

전체 승인 경로를 맵으로 그리세요. 각 임계값에 대해 누가 승인하며 다음에 무슨 일이 일어나는지 명확히 적습니다. 경계도 정확히 적으세요: 규칙이 $500 초과부터 적용되는지, $500 이상부터 적용되는지 등.

그다음 새 팀원 테스트를 하세요. 문서를 모르는 사람에게 규칙을 주고 자신의 말로 설명해 보라고 하세요. 추가 설명이 필요하면 규칙이 아직 모호한 것입니다.

작은 예시가 이유를 보여줍니다. "매니저가 큰 비용을 승인한다"는 문장은 $500가 큰 비용인지 묻는 질문으로 이어집니다. 반면에 "매니저는 $500 초과 비용을 승인한다. 이사(Director)는 $2,000 초과 비용을 승인한다. $500 이하의 비용은 자동 승인된다"는 문구는 오류 여지를 훨씬 줄입니다.

규칙을 작동하는 앱으로 전환하기

규칙이 명확해지면 실제 프로세스를 사용하는 사람들과 검토하세요. 매니저, 코디네이터, 재무 담당자, 승인자는 종종 정책 문서에 빠진 작은 세부를 알아차립니다. 그 세부가 앱을 매끄럽고 사용하기 쉽도록 만들거나 짜증나게 만드는 주된 원인입니다.

규칙 문서는 한 번 작성한 초안이 아니라 작업 지침으로 다루세요. 문서에는 어떤 일이 일어나는지, 누가 결정하는지, 예외는 무엇인지, 정보가 누락되었을 때 앱이 무엇을 해야 하는지 설명해야 합니다.

전체 앱을 빌드하기 전에 최근 업무에서 몇 가지 실제 시나리오를 테스트하세요. 깨끗한 사례와 복잡한 사례를 모두 사용하세요: 통과해야 할 표준 요청, 정보가 누락된 요청, 수동 검토가 필요한 예외, 지출 한도나 승인 임계값을 넘는 사례.

이 단계는 허점을 조기에 잡아냅니다. 문서에서는 명확해 보이던 규칙도 실제 요청이 예상 패턴에 맞지 않으면 깨질 수 있습니다.

그 시나리오들이 유지되면 빌더에 옮기세요. Koder.ai 같은 채팅 기반 플랫폼을 사용한다면 명확한 규칙 세트는 빌드를 훨씬 빠르게 만듭니다. 그 이유는 상황별로 즉석에서 결정을 내리며 만들지 않고 정의된 프로세스를 화면, 액션, 승인으로 번역하기 때문입니다.

출시 후에도 문서를 진실의 출처로 유지하세요. 정책이 변경되거나 승인자가 추가되거나 한도가 업데이트되면 먼저 문서를 바꾸고 앱을 업데이트하세요. 그러면 미래의 수정이 더 간단해지고 서로 다른 사람들이 규칙을 달리 기억하는 위험이 줄어듭니다.

작은 습관 하나가 도움이 됩니다: 프로세스가 변경될 때마다 규칙을 검토하세요. 앱이 깨질 때만 수정하는 것이 아니라 변화가 생길 때마다 작은 업데이트를 하면 나중에 혼란을 고치는 것보다 훨씬 쉽습니다.

문서가 최신으로 유지되면 앱은 시간에 따라 테스트하기 쉽고 개선하기 쉽고 신뢰할 수 있게 됩니다.