원가는 먼저, 매출은 나중에 — CMiC에서 손실이 생기는 자리

원가는 먼저 확정되고 매출은 나중에 확정된다 — CMiC 변경관리 대표이미지

1편에서 CMiC가 무엇인지 정리했습니다. 이번 편은 아무도 안 보고 있을 때 실제로 돈이 새는 지점 하나에 관한 이야기입니다.

어렵지 않습니다. 원가가 매출보다 먼저 확정됩니다. CMiC가 현장 도구가 아니라 장부라는 것부터 보시면 이해가 빠릅니다. 아래 내용은 전부 이 한 문장에서 나옵니다.

두 갈래 경로, 그런데 커밋을 만드는 건 하나뿐

변경은 PCI(Potential Change Item)로 시작합니다. PCI 디테일 라인에서 두 필드가 서로 다른 일을 합니다.

  • Final Amount는 해당 코스트 코드의 원가 예산을 조정합니다
  • Billing Amount는 오너 계약의 매출을 조정합니다

외부 PCI를 post하면 — CMiC 공식 타입명은 EXT, 화면 표기는 External CO입니다 — 둘 다 움직입니다. 원가 예산이 오르고 예상 매출도 오릅니다. 내부 PCI(INT)는 원가 예산만 건드리고 오너 계약은 그대로 둡니다.

그런데 PCI가 하지 않는 일이 있습니다. 커밋을 만들지 않습니다. 아직 아무 벤더도 책임지지 않은 상태입니다. 커밋은 다음 단계로 가야 생깁니다.

PCI → SCO 또는 신규 서브계약 → post → committed cost

CMiC 하도급 문서에도 그대로 적혀 있습니다. 서브계약을 post해야 그 잡의 커밋 원가가 갱신된다고요. 그 전까지는 예산은 잡혔는데 아무도 그 일을 하기로 계약하지 않은 상태이고, 원가 현황 조회 화면이 그 갭을 그대로 보여줍니다.

시차 문제

깔끔한 세상이라면 PCI를 내고, 오너 승인을 기다리고, 그다음에 서브계약을 내보냅니다. 매출 확정 다음에 원가 확정, 이 순서죠.

그런데 공정은 그렇게 안 굴러갑니다. 일은 시작해야 하고 하도급은 투입돼야 합니다. 그래서 오너 변경 승인이 결재선을 도는 동안 서브계약이 먼저 나갑니다.

원가 확정과 매출 확정 시점이 어긋나는 타임라인 도해. 서브계약 post 시점부터 OCO 승인 전까지가 노출 구간
두 쪽의 확정 시점이 다릅니다. 그 사이가 노출입니다.

그 서브계약을 post하는 순간 원가는 실재하는 숫자가 됩니다. 계약됐고, 장부에 올라갔고, 하도급이 이미 서명한 금액이라 깎을 수도 없습니다.

매출은 여전히 추정치입니다. EC에 적었던 금액일 뿐이고, OCO(Owner Change Order)가 승인돼야 실재가 됩니다.

OCO가 낮게 나오면

오너가 EC 금액보다 적게 승인하는 경우가 있습니다. 검토 과정에서 범위가 잘리거나, 한 항목이 다퉈지거나, 단가가 조정되면서요.

승인된 OCO가 EC 금액보다 낮을 때 차액이 손실이 되는 구조를 나타낸 막대그래프
매출은 움직였고 원가는 못 움직입니다.

그 차액이 손실입니다. 나중에 만회할 편차가 아니라 손실입니다. 원가 쪽에 여지가 없기 때문입니다. 서브계약은 서명된 금액 그대로입니다.

여기가 일찍 몸에 익혀둘 부분입니다. 노출을 만든 건 오너가 금액을 깎은 게 아니라 시차입니다. OCO가 서브계약보다 먼저 나왔다면 승인된 금액에 맞춰 하도급 단가를 잡거나, 범위를 다시 짰을 겁니다.

결론은 하지 말라는 게 아닙니다

여기서 규칙 하나로 끝내면 편합니다. OCO 전에는 절대 커밋하지 마라. 그런데 그 규칙은 쓸모가 없습니다. 실제 공정에서는 기다릴 수 없는 경우가 많고, 윗사람들도 그걸 이미 알고 있습니다.

쓸모 있는 버전은 다릅니다. 먼저 진행하는 건 정상적인 상업적 판단입니다. 얼마나 노출돼 있는지 모르는 게 문제입니다.

그래서 추적할 숫자는 하나이고, PM 앞에 올릴 숫자도 이겁니다.

원가 쪽은 커밋됐는데 아직 승인된 OCO가 없는 EC 금액이 얼마인가

숫자 하나입니다. 미승인 변경에 서브계약이 post되면 올라가고 OCO가 승인되면 내려갑니다. 아무도 이걸 달라고 하지 않습니다. 먼저 들고 가는 것이 코디네이터로서 빠르게 신뢰를 얻는 방법 중 하나입니다.

어느 컬럼을 봐야 하나

Budget & Cost Management의 원가 현황 조회 화면에는 컬럼이 열세 개 있습니다. 대부분은 나머지를 설명하려고 있는 숫자입니다.

CMiC Cost Status Query의 13개 컬럼 중 실무에서 매일 보는 네 개를 강조한 표
컬럼은 열세 개, 일하는 건 네 개.
컬럼이게 답하는 질문
Current Budget확정된 변경까지 반영해서, 얼마를 써도 되는가
Committed이미 벤더와 계약돼 되돌릴 수 없는 금액은 얼마인가
Spent/Committed사실상 나간 돈 — 쓴 돈 + 계약됐지만 아직 안 쓴 돈
Calculated Projection이 코스트 코드가 끝나면 얼마가 되는가
나머지 아홉 개(Original Budget, External CO, Internal·Transfer CO, Pending·Pre-pending, Projected Budget, Spent, Committed Remaining, Amount To Complete)는 이 넷이 어떻게 그 값이 됐는지 설명하는 숫자입니다.

한 줄 빠르게 읽는 법. Current Budget은 올랐는데 Committed는 그대로면 변경 예산은 잡혔고 아직 아무도 계약되지 않은 상태입니다. 이쪽이 안전한 방향입니다. 불편한 방향은 OCO가 승인되지 않은 변경에 Committed가 올라가는 경우입니다.

실제로 할 일

  1. 미승인 변경에 서브계약이 나가기 전에 어떤 EC 금액에 커밋하는지 적어둔다
  2. 잡 전체에서 OCO 없이 커밋된 금액의 누계를 관리한다
  3. 요청받기 전에 PM 보고서에 올린다
  4. OCO가 승인되면 EC와 비교한다. 낮게 나왔다면 편차는 이미 실재하므로 준공 때가 아니라 그 보고 주기에 알린다

여기에 특별한 권한이 필요하지 않습니다. 시스템이 이미 보여주고 있는 갭을 알아채기만 하면 됩니다. 아직 어떤 도구를 배울지 고르는 중이라면 현장 도구 비교는 별개의 이야기이고, 이 일이 AI로 대체되는지는 따로 써둔 글이 있습니다.

다음 마지막 편에서는 숫자가 어긋나는 또 다른 자리를 다룹니다. 월 기성과 회계가 실제로 지급한 내역이 안 맞을 때, 그리고 금액보다 클라이언트보다 먼저 잡는 것이 왜 더 중요한지.