부서용 월별 잠금 기능이 있는 예산 대 실적 추적기

월별 잠금 없이는 예산 대 실적이 엉망이 되는 이유

예산 대 실적 추적기는 사람들이 숫자를 신뢰할 때만 효과가 있습니다. 문제는 월간 보고를 공유한 뒤에도 비용이 계속 바뀐다는 점입니다. 늦게 온 송장이 다른 코드로 처리되기도 하고, 누군가 공급업체 이름을 고치다 금액을 실수로 바꾸기도 합니다. CSV 임포트를 다시 실행하면 메모가 덮어써지기도 합니다. 지난달 숫자가 계속 변하면 새 보고서는 "뭐가 바뀌었나"를 두고 논쟁이 되지, 다음에 무엇을 할지에 대한 논의가 되지 않습니다.

월별 잠금은 간단한 규칙입니다: 한 달이 닫히면 그 달은 읽기 전용으로 취급합니다. 수정은 여전히 가능하되, 수정은 다음 열린 달에 명확히 표시된 조정으로 기록하거나 통제된 재오픈-재마감 절차로 처리해야 합니다. 이렇게 하면 3월 5일에 제시한 2월 보고서는 3월 20일에도 여전히 2월 보고서로 남습니다.

이 규칙은 빠르고 명확한 결정을 내려야 하는 팀에게 가장 중요합니다. 재무팀은 안정적인 마감 숫자가 필요하고, 부서장은 실제 지출을 명확히 알고 있어야 하며, 운영팀은 추적기가 뒤에서 조용히 바뀌지 않는다는 확신이 필요합니다.

유용한 추적기는 단순한 합계가 있는 스프레드시트 이상입니다. 이전 달을 망치지 않고 비용 라인을 가져오고, 카테고리를 일관되게 유지하고, 마감 기간을 잠그고, 월별로 예산·실제·편차를 한눈에 보기 쉽게 제시하는 등 월간 보고를 신뢰할 수 있게 하는 일상 작업을 지원합니다.

한 번이라도 “지난주랑 숫자가 달라 보인다”라는 말을 들어본 적이 있다면, 잠금이 보통 빠진 조각입니다.

시작 전에 필요한 데이터

월별 잠금이 있는 예산 대 실적 추적기를 만들기 전에 소수의 입력 데이터를 모으고 ‘좋은 데이터’가 무엇인지 합의하세요. 이 단계를 건너뛰면 첫 달에 맞지 않는 합계 때문에 논쟁만 하게 됩니다.

우선 예산 계획을 준비하세요. 부서별 월별 예산이 필요합니다(선택적으로 카테고리별도 가능). 단순하게 유지하세요: 부서, 월, 예산 금액. 예산이 분기별 또는 연간으로 승인됐다면 비교가 공정하도록 월별 숫자로 변환해 두세요.

다음으로 실제 비용은 요약이 아닌 라인 항목으로 수집하세요. 각 라인에는 날짜(또는 게시일), 공급업체나 수령인, 설명, 금액, 부서가 포함되어야 합니다. 라인 항목이 있어야 CSV 임포트, 카테고리 매핑, 감사가 가능합니다.

카테고리는 예산과 실제를 잇는 접착제입니다. 시간이 지나도 안정적으로 유지되는 카테고리 목록을 만들고, 새로운 비용 라인이 어떻게 분류되는지 알려주는 매핑 규칙(예: “Amazon Web Services”는 항상 Cloud Hosting으로 매핑)을 정의하세요. 이 규칙을 문서화해 두면 두 사람이 같은 공급업체를 다르게 분류하는 일을 막을 수 있습니다.

또한 레코드가 열린 달인지 닫힌 달인지 명확히 하는 월별 상태가 필요합니다. 마감은 그 달의 금액, 날짜, 부서, 카테고리에 대한 소급 편집을 방지해야 합니다.

마지막으로 경량 감사 추적을 추가해 변경 사항을 추적 가능하되 번거롭지 않게 하세요. 최소한 누가 라인을 생성했는지와 언제인지, 누가 마지막으로 업데이트했는지와 언제인지, CSV 임포트였는지 수동 입력이었는지를 기록하세요. 가능하면 예외에 대한 짧은 변경 메모 필드를 하나 더 추가하세요.

예: 마케팅이 220건의 카드 거래가 담긴 CSV를 임포트합니다. 각 라인에 날짜, 공급업체, 금액, 부서가 있으면 “Meta”와 “Google”을 광고로 매핑하고, 달을 닫은 뒤 누가 어느 한 라인을 왜 바꿨는지 추적할 수 있습니다.

먼저 규칙을 정하세요(그래야 추적기가 일관됩니다)

수식에 손대기 전에 몇 가지 규칙에 합의하세요. 부서가 여러 곳에서 비용 라인을 임포트하기 시작하면, 모두 같은 플레이북을 따를 때만 월별 잠금이 효과를 발휘합니다.

카테고리부터 시작하세요. 급한 마음에 카테고리를 계속 늘리지 말고 작고 안정적으로 유지하세요: Payroll, Software, Travel, Contractors, Office, Other 같은 작은 계정표가 좋습니다. 새로운 공급업체가 보일 때마다 카테고리를 만들면 보고가 시끄러워지고 월간 비교가 의미를 잃습니다.

다음으로 소유권을 정의하세요. 각 부서에는 카테고리 변경을 승인하고 예외를 기록할 책임자가 한 명 있어야 합니다. 다른 사람이 임포트를 제출하도록 허용할 수는 있지만, 예산·매핑·닫힌 달의 편집 권한은 소수에 제한해야 합니다.

앞으로 대부분의 논쟁을 막는 결정은 간단합니다:

• 카테고리 거버넌스: 누가 카테고리를 추가하거나 이름을 바꿀 수 있는지, 얼마나 자주 가능한지
• 편집 권한: 누가 임포트를 편집할 수 있는지, 누가 매핑을 변경할 수 있는지, 누가 달을 닫거나 다시 열 수 있는지
• 마감과 컷오프 일정: 비용이 언제까지 들어와야 하는지, 달을 언제 잠그는지
• 늦은 송장 처리: 그것들이 조정으로 들어가는지, 어떻게 라벨링할지
• 명명 규칙: 공급업체당 하나의 이름, 개념당 하나의 카테고리 이름

늦은 송장과 수정에는 명확한 정책이 필요합니다. 실용적인 옵션은 마감 후 원래 거래는 변경하지 않는 것입니다. 대신 다음 열린 달에 분명히 표시된 조정 라인을 기록하세요(예: “12월 정정 - 공급업체 크레딧”). 이렇게 하면 잠긴 달은 일관되게 유지되면서도 진실은 드러납니다.

예: 재무팀이 마감을 영업일 기준 3일에 합니다. 마케팅이 6일에 빠진 송장을 찾습니다. 담당자는 12월로 태그된 1월 조정 항목을 메모 열에 추가하고 12월을 다시 열지 않습니다.

CSV에서 비용 라인 임포트하기(골치 아픈 문제 없이)

CSV 임포트는 처음에는 간단해 보이지만 첫 파일에 컬럼이 빠져 있거나, 이상한 통화 기호가 있거나, 중복이 발생할 때 문제가 시작됩니다. 추적기를 깔끔하게 유지하는 가장 쉬운 방법은 임포트를 단조롭고 반복 가능하게 만드는 것입니다.

하나의 CSV 형식을 정하고 그것을 고수하세요. 최소한 날짜, 설명, 금액, 부서를 요구하세요. 가능하면 참조 ID(송장 번호나 거래 ID)를 추가하세요. 그 한 컬럼이 중복을 잡는 데 큰 도움이 됩니다.

임포트 전에 간단한 정리 과정을 거치세요. 가장 흔한 문제는 작지만 나중에 큰 문제를 일으킵니다: 설명에 쉼표가 들어 있는 경우, 금액 필드에 통화 기호가 들어 있는 경우, 일관되지 않은 날짜 형식, 빈 행이 빈 레코드로 입력되는 경우 등.

간단한 수락/거부 체크리스트가 도움이 됩니다:

• 날짜가 하나의 일관된 형식으로 유효한 날짜인지
• 금액이 통화 기호나 괄호 없이 숫자만인지
• 부서가 허용된 부서 이름과 정확히 일치하는지
• 설명이 비어 있지 않은지
• 맨 끝에 빈 행이 없는지

중복은 보이지 않는 살인자입니다. 두 사람이 같은 은행 내보내기를 임포트하면 지출이 하룻밤 사이에 두 배가 될 수 있습니다. 실용적인 규칙은 (날짜 + 금액 + 설명 + 부서)를 지문으로 간주하고 그 지문이 이미 존재하면 경고하는 것입니다. 참조 ID가 있으면 그것을 기본 중복 검사로 사용하세요.

저장하기 전에 항상 미리보기 단계를 포함하세요. 처음 20~50개 행을 보여주고 문제(부서 누락, 잘못된 날짜)를 강조해 사용자가 CSV를 고친 후에 데이터로 저장하게 하세요.

또한 배치별로 임포트 메타데이터를 저장하세요: 파일 이름, 임포트 시간, 누가 임포트했는지, 어떤 기간을 임포트하려 했는지. 누군가가 “이 라인은 어디서 왔어?”라고 물으면 빠르게 대답할 수 있어야 합니다.

카테고리를 배정하고 유지보수 가능하게 만들기

카테고리는 월별 잠금이 있는 예산 대 실적 추적기가 유용해지느냐 아니면 끊임없는 정리가 필요한 도구가 되느냐를 결정합니다. 목표는 단순합니다: 모든 비용 라인은 하나의 명확한 버킷으로 들어가고, 그 버킷에 들어가는 규칙이 나중에도 이해하기 쉬워야 합니다.

대부분 팀은 수동 지정과 자동 매핑 두 가지 경로가 필요합니다. 수동은 예측할 수 없는 경우(새 공급업체, 일회성 이벤트, 복잡한 메모)에 사용하고, 자동 매핑은 매달 같은 패턴으로 반복되는 항목(예: 같은 공급업체)을 처리합니다.

오래 보아도 읽기 쉬운 설정 예시는 다음과 같습니다: 새 라인은 기본적으로 미분류로 두고, 공급업체나 메모에 알려진 키워드가 포함되면 자동 매핑(예: “Uber” → Travel)하고, 마감 전에 여전히 미분류로 남아 있는 항목은 검토 대상으로 플래그하세요. 카테고리별로 예산을 관리한다면 하나의 청구서를 여러 카테고리로 분할할 수 있게 하세요.

분할은 사람들이 생각하는 것보다 중요합니다. 한 청구서에 소프트웨어 라이선스와 온보딩 서비스가 함께 있을 수 있습니다. 한 카테고리에 억지로 집어넣기보다 라인을 두 개로 분할해 예산에 맞게 배분하세요. 원래 총액은 보여줘서 검토자가 쉽게 대조할 수 있게 하세요.

매핑 규칙은 보이게 하고 편집 가능하게 하되 보호하세요. 작은 규칙 테이블(keyword, 매칭 필드(공급업체 vs 메모), 대상 카테고리, 활성 플래그)은 숨겨진 수식보다 유지보수가 쉽습니다. 누가 규칙을 편집할 수 있는지 제한하고 규칙 변경 시 기록을 남기세요. 그렇지 않으면 한 번의 선의의 수정으로 수개월치 지출이 재분류될 수 있습니다.

예: 운영팀이 CSV를 임포트하고 “ACME Office Supplies - Jan”과 “ACME - Breakroom”을 봅니다. “ACME” 하나만으로 규칙을 만들면 너무 광범위합니다. 두 개의 더 구체적인 키워드(“Office Supplies”, “Breakroom”)를 만들면 매달 수동 작업을 줄이면서 정확도를 유지할 수 있습니다.

사람들이 실제로 사용할 월별 예산 대 실적 뷰 만들기

사람들이 실제로 쓰는 뷰는 하나의 질문에 빨리 답합니다: “이번 달 우리는 계획대로 가고 있나?” 메인 화면은 월별 합계에 집중하고, 필요할 때만 카테고리로 드릴다운할 수 있게 하세요.

부서별로 한 줄의 월간 요약을 시작점으로 하세요: 예산(Budget), 실제(Actual), 편차(Actual minus Budget). 5% 또는 $2,000 같은 임계값을 정해 “OK” 또는 “검토 필요” 같은 간단한 상태 표시를 추가하세요. 규칙을 일관되게 유지하면 사람들이 화면을 신뢰합니다.

요약 아래에 같은 부서와 달의 카테고리 분해를 보여주세요. 카테고리는 은행 레이블이 아니라 부서가 지출을 보는 방식과 일치해야 합니다(Software, Contractors, Travel). 이 분해에서 이야기를 발견합니다: 한 카테고리의 급증이 편차를 설명하는 경우가 많습니다.

메모는 숫자와 결정의 차이입니다. 메모는 짧게(한두 문장) 유지하고, 편차가 임계값을 넘을 때만 필수로 하세요. 예: “1월 출장비 과다 발생—연례 세일즈 킥오프 관련, VP 승인(1월 5일).”

화면을 보기 쉽게 유지하려면 필수 컨트롤만 남기세요: 월 필터, 부서 필터, 선택적 카테고리 드릴다운, 월말 스냅샷용 내보내기.

달을 닫을 때 화면에서 보이던 것(요약과 카테고리 합계, 메모 포함)과 일치하는 스냅샷을 내보내 공유하고 보관하세요. 이렇게 하면 마감 시점의 숫자가 무엇이었는지에 대한 논쟁을 줄일 수 있습니다.

월별 잠금: ‘마감’은 어떻게 작동해야 하나

월별 잠금은 도움이 되는 추적기와 끊임없는 논쟁을 낳는 도구를 구분합니다. “달 닫기”는 한 가지 의미여야 합니다: 한 달이 닫히면 권한 있는 사람이 다시 열기 전까지 그 달의 숫자는 바뀌지 않습니다.

정확히 무엇을 차단할지 정의하세요. 가장 깔끔한 규칙은 닫힌 달에 날짜가 포함된 모든 비용 라인의 편집(금액, 공급업체, 날짜, 부서, 카테고리)을 차단하는 것입니다. 가능하면 그 달의 라인 삭제도 차단하세요. 삭제는 숨겨진 편집일 뿐입니다.

권한을 엄격하고 명확하게 유지하세요. 마감과 재오픈은 Finance와 부서 소유자 같은 특정 역할로 제한해야 합니다. 다른 사람은 닫힌 달에 대해 보기 전용이어야 합니다.

실무적인 월말 통제 세트는 다음과 같습니다:

• 달별로 명확한 상태: Open 또는 Closed
• 마감 동작은 사유를 요구(예: "GL에 대조 완료, 1월 마감")
• 시스템은 closed_by와 closed_at을 기록
• 재오픈 동작은 사유를 요구하고 reopened_by와 reopened_at을 기록
• 선택적: 매핑 규칙을 닫힌 달에 대해 잠그기(매핑 변경이 과거 합계에 영향을 줄 경우)

마감 후에도 무엇을 변경할 수 있는지 결정하고 ‘명확성’과 ‘금전’ 관련 변경을 분리하세요. 좋은 타협은 마감 후 메모 추가는 허용하되 총액을 바꾸는 모든 것은 막는 것입니다. 실수 수정을 해야 한다면 재오픈을 요구하고, 변경 후 다시 닫아 감사 추적을 명확히 하세요.

예: 영업팀이 3월을 4월 3일에 닫았습니다. 4월 10일에 $120 지출이 Travel로 분류돼야 할 것을 Software로 분류된 것을 발견했습니다. 즉시 메모를 추가할 수는 있지만(설명 추가) 3월 합계를 바꾸려면 Finance가 사유를 적어 3월을 재오픈하고 라인을 수정한 뒤 다시 마감합니다.

흔한 함정과 피하는 방법

월별 잠금이 있는 예산 대 실적 추적기는 사람들이 조용히 역사를 덮어쓰지 못하게 할 때만 작동합니다. 대부분 문제는 기술적이기보다 작은 습관에서 시작되어 쌓입니다.

한 가지 흔한 편법은 닫힌 달을 피해 열려 있는 달로 거래 날짜를 옮기는 것입니다. 거래 날짜가 닫힌 달에 해당하면 날짜 필드를 수정하려 해도 시스템에서 검증해 차단해야 합니다. 날짜가 닫힌 달에 속하면 라인은 읽기 전용(또는 거부)되어야 합니다.

또 다른 실수는 너무 일찍 마감하는 것입니다. 예상 공급업체 송장이 들어오고 급여 배분이 게시되고 카드 피드가 정리될 때까지는 마감하지 마세요. 늦은 항목이 정상적이라면 늦은 조정은 허용하되 사유와 승인자를 요구하세요.

미분류된 비용은 추적기가 죽어가는 곳입니다. 아무도 소유하지 않으면 항목은 영원히 쌓이고 보고서는 무의미해집니다. 각 부서(또는 비용 센터)에 하나의 소유자를 지정해 미분류 항목을 정해진 기간 내에 정리하도록 하세요.

임포트는 또한 문제가 됩니다: 사람들이 이전 임포트를 덮어쓰거나 추적성을 잃거나 보이지 않는 중복을 도입하면 문제가 커집니다. 추가만 허용하는(append-only) 임포트와 간단한 임포트 로그(파일 이름, 임포트 날짜, 소스 기간, 누가 임포트했는지)를 선호하세요. 그러면 라인이 어디서 왔는지 추적하기 쉽습니다.

속도를 늦추지 않으면서 대부분 문제를 막는 가벼운 통제들:

• 라인의 거래 월이 닫혔으면(심지어 누군가가 날짜를 바꿔도) 편집을 차단
• 팀에 버퍼가 필요하면 “소프트 클로즈”(검토)와 “하드 클로즈”(잠금)를 구분
• 미분류 항목에는 소유자와 기한을 지정
• 임포트 ID를 저장하고 저장 전 중복 경고 표시
• 누가 달을 재오픈했는지 제한하고 매번 짧은 메모를 요구

이 기본 사항들이 숫자를 안정적으로 유지하고 월말 대화를 짧게 만듭니다.

빠른 월말 체크리스트

월말 마감은 분 단위로 끝나야 하고, 논쟁으로 몇 시간씩 걸려선 안 됩니다. 목표는 단순합니다: 모두가 그 달의 숫자가 최종이라는 데 동의하고, 놀라움은 간단한 문장으로 설명됩니다.

매달 같은 날(또는 다음 영업일)에 이 체크리스트를 실행하세요:

• 달 상태가 Closed인지 확인하고, 소유자만 재오픈할 수 있게 설정
• 미분류 거래를 정리. 모든 항목이 매핑되었거나 소유자와 기한이 있는 검토 대기열로 이동돼야 함
• 의미 있는 편차 검토 및 큰 변동에 대해 짧은 메모 추가(예: "일회성 소프트웨어 갱신" 또는 "채용 시작일 변경")
• 그 달의 보고 스냅샷 저장(화면에 보이던 것과 일치하도록)하여 공유 및 보관
• 늦은 비용 규칙(발생주의 vs 다음 달 조정)을 일관되게 적용

예: 서포트 팀이 9월을 10월 1일에 닫았습니다. 10월 3일에 9월 사용분에 대한 두 건의 송장이 도착했습니다. 규칙이 "$200 미만은 다음 달로, $200 초과는 발생 처리"라면 예외 논쟁을 피하고 추세를 정직하게 유지할 수 있습니다.

한 부서에 대한 예시 워크플로

다음은 월별 잠금이 있는 예산 대 실적 추적기를 사용하는 영업팀의 간단한 리듬입니다. 목표는 주간 작업을 작게 유지하고 월말을 깔끔하게 만드는 것입니다.

월요일 아침에 영업 운영 책임자가 지난주의 법인카드 거래를 CSV로 내보냅니다(날짜, 공급업체, 금액, 메모, 비용 센터). 이를 추적기에 임포트하면 라인들이 “검토 대기(Unreviewed)” 상태로 들어갑니다.

한 달 동안 매핑이 대부분의 반복 작업을 처리합니다. “Google Ads”, “LinkedIn”, “HubSpot”은 올바른 카테고리로 할당됩니다. 새로운 항목(예: 일회성 이벤트 스폰서)은 미분류로 남아 잘못된 버킷에 조용히 들어가는 일을 막습니다.

주간 작업은 단순합니다: CSV 임포트, 합계가 명세서와 일치하는지 확인, 미분류 라인 검토, 이상 항목에 대한 짧은 메모 추가(환불, 중복 청구, 출장, 다른 부서 소속 항목 등).

월말에는 영업 매니저가 예외만 검토합니다: 미분류 항목, 예산 대비 큰 편차, 플래그된 라인. 그들은 짧은 문장으로 맥락을 추가(예: "컨퍼런스 부스 보증금으로 추가 지출 발생")하여 재무팀이 나중에 문의하지 않게 합니다.

그 후 재무팀이 달을 닫습니다. 마감은 그 달의 합계를 고정하고 해당 달의 임포트된 라인과 카테고리 할당에 대한 소급 편집을 방지합니다. 마감 후 재무팀은 스냅샷(카테고리별 편차, 메모, 승인)을 공유합니다.

다음 달에 지난달 소프트웨어 갱신에 대한 늦은 송장이 도착하면 닫힌 달을 편집하지 않고, 합의된 방식대로 "지난달 관련 늦은 송장" 태그와 메모를 달아 현재 달 라인으로 기록합니다.

가볍게 유지되는 거버넌스와 통제

월별 잠금이 있는 예산 대 실적 추적기는 사람들이 숫자를 신뢰하고 무엇을 변경할 수 있는지 이해할 때만 작동합니다. 목표는 관료주의가 아니라 우발적 손상을 막는 몇 가지 명확한 규칙입니다.

간단한 권한 체계부터 시작하세요. 대부분 팀은 세 가지 역할이면 충분합니다:

• Viewers(조회자): 필터, 내보내기, 코멘트는 가능하지만 데이터 변경 불가
• Editors(편집자): CSV 임포트 및 열린 달에 대한 매핑·메모 수정 가능
• Closers(마감자): 달을 닫고 다시 열 수 있음(보통 Finance와 부서 책임자)

마감자 그룹은 작게 유지하세요. 누구나 달을 재오픈할 수 있으면 잠금은 제안에 불과해집니다.

감사 추적은 빠르게 효과를 보는 또 다른 가벼운 통제입니다. 모든 작은 편집을 기록할 필요는 없습니다. 나중에 “무엇이 왜 바뀌었나?”에 답할 수 있도록 핵심 이벤트만 기록하세요: 누가 어떤 파일을 임포트했는지, 몇 건이 추가되었는지, 어떤 매핑 규칙이 편집되었는지, 언제 달이 닫히거나 재오픈되었는지 등.

가장 흔한 오류를 차단하는 몇 가지 검증을 추가하세요. 날짜는 선택된 달 안에 있어야 하고, 금액은 숫자여야 하며(환불은 명확히 표시), 카테고리와 부서는 필수이거나 눈에 띄는 예외 버킷에 있어야 하며, 중복은 저장 전에 경고를 발생시켜야 합니다.

규모에 대비하되 첫 버전을 지나치게 복잡하게 만들지 마세요. 여러 부서와 여러 예산 버전(원본 예산, 수정 예산, 예측)을 어떻게 다룰지 미리 결정하세요. 실용적인 규칙은 월별로 하나의 예산 버전이 활성화되고 이전 버전은 읽기 전용으로 두는 것입니다.

마지막으로 진실의 출처(source of truth)가 어디인지 문서화하세요. 회계 시스템이 권위적이라면 추적기는 그것을 반영하고 차이를 설명해야 합니다. 추적기가 작업 레이어라면 데이터가 임시인지 게시된 것인지 명확히 하세요.

다음 단계: 이 추적기를 내부 앱으로 전환하기

스프레드시트는 모두가 완벽하게 행동할 때는 괜찮습니다. 문제는 누군가가 지난달을 편집하거나 카테고리 레이블을 변경하거나 같은 CSV를 두 번 임포트할 때 시작됩니다. 추적기가 불안해지기 시작하면, 이미 정의한 규칙을 강제하는 앱으로 옮기는 것이 다음 단계입니다.

간단한 내부 앱은 보통 세 가지 이점을 제공합니다: 비용 라인에 대한 단일 진실 저장소, 사람들이 일관된 카테고리에 입력하도록 안내하는 폼, 우발적으로 우회할 수 없는 실제 월 잠금 기능.

수동으로 모두 코딩하지 않고 진행하고 싶다면 AppMaster (appmaster.io) 같은 노코드 플랫폼이 핵심 테이블(부서, 카테고리, 예산, 비용 라인, 월 상태)을 모델링하고 역할 및 월말 잠금을 워크플로의 일부로 강제하는 데 도움이 될 수 있습니다.

이번 주에 움직이려면 작게 시작하세요: 카테고리 목록을 확정하고, 달을 닫고 다시 열 수 있는 사람들을 정한 다음 한 부서 한 달로 파일럿을 실행하세요. 규칙이 실제 사용에서 작동하면 기본을 바꾸지 않고 다른 팀으로 확장할 수 있습니다.