오라클 Primavera Unifier란? — 월요일 아침, 설계 변경 한 건에서 시작하는 이야기

월요일 09:00, 평택 현장. 설계 변경 한 건이 떨어진다. 철골 물량이 바뀌었다. 원가는 얼마나 늘고, 일정엔 어떻게 닿고, 누가 승인하는가. 이 한 건이 다섯 부서를 거친다.

흔한 풍경은 이렇다. 현장이 엑셀로 영향금액을 추린다. 메일로 본사에 올린다. 전화로 확인한다. 사흘이 지나도 "지금 누구 차례냐"가 안 보인다. 변경은 쌓이는데 원가 시트는 월말에야 맞는다. 사고가 난 뒤 정산하는 구조다.

Oracle Primavera Unifier는 이 풍경을 바꾼다. 한 줄로 — 자본 프로젝트의 원가·계약·변경·프로세스를 한 곳에서, 진행 중에 통제하게 한다. 무엇을 묶는지 보기 전에, 왜 이 통제가 필요한지부터 짚는다.

왜 '프로젝트 컨트롤'인가 — 자본 프로젝트가 새는 지점

건설·플랜트·인프라 같은 자본 프로젝트(capital project)는 규모가 크고, 계약과 변경이 잦고, 수많은 주체가 동시에 움직인다. 그래서 원가와 일정이 새기 쉽다. 특정 회사의 문제가 아니라 산업 전반에서 반복 관측돼 온 구조적 패턴이다.

산업 연구는 이 패턴을 꾸준히 보고한다. 옥스퍼드의 벤트 플라이비야(Bent Flyvbjerg)는 대형 프로젝트를 두고 "예산 초과, 공기 지연, 반복해서(over budget, over time, over and over)"를 '메가프로젝트의 철칙(iron law)'이라 불렀다. 맥킨지글로벌연구소(MGI)의 Reinventing Construction(2017)도 같은 방향을 가리킨다 — 대형 건설 프로젝트는 일정이 평균 20%가량 더 걸리고 예산은 최대 80%까지 초과하는 경향이 있다는 분석이다. (산업 연구의 추정치로 프로젝트 유형·지역에 따라 편차가 크다. 디티솔루션의 실측치가 아니다.)

원인은 단일하지 않지만 자주 지목되는 공통항이 있다. 정보가 흩어져 있다는 것이다. 원가는 엑셀에, 일정은 공정표에, 계약은 캐비닛에, 승인은 메일함에 있다. 변경 한 건이 이 모두를 동시에 건드리는데도 어디에도 합쳐지지 않으니, 손실은 '진행 중'이 아니라 '사고 난 뒤'에야 보인다. 프로젝트 컨트롤(project controls) — 원가·일정·변경·계약을 한 체계에서 통제한다는 발상 — 이 바로 이 누수 지점을 겨냥한다. Unifier가 서 있는 자리가 여기다.

그럼 Unifier가 구체적으로 무엇을 묶는지 보자.

변경 한 건이 시스템을 지나가는 법

아까 그 철골 변경으로 돌아가자. Unifier에서는 이 한 건이 '변경 비즈니스 프로세스(BP)' 한 장으로 시작된다. 폼을 열고 변경 내용을 적으면, 연결된 원가 코드에서 영향금액이 자동 계산되고, 정해진 결재선을 따라 전자적으로 흐른다.

차이는 결과가 아니라 '시점'에서 난다. 똑같은 변경 한 건이지만, 도구에 따라 이렇게 갈린다.

그래서, Unifier가 다루는 것들 — 모듈별로

변경 한 건을 따라가다 보면 Unifier의 영역이 자연스레 드러난다. 한 줄 요약이 아니라, 모듈별로 무엇을 어떻게 하는지 들여다보자. 전제는 하나다. 이 영역들은 따로 노는 모듈이 아니라 하나의 데이터 모델 위에 얹혀 있다.

① 원가 관리 — Cost Sheet · 현금흐름 · EVM

Unifier 원가 관리의 중심에는 Cost Sheet(원가 시트)가 있다. 행은 원가분류체계(원가 코드/CBS)이고, 열은 예산(Budget)·약정(Commitment)·실적(Actuals)·예측(Forecast) 같은 원가 항목이다. 발주·계약·변경·기성 같은 모든 거래가 정해진 원가 코드에 꽂히면서 이 시트의 셀을 자동으로 채운다. 즉 원가 시트는 사람이 월말에 손으로 맞추는 표가 아니라, 거래가 쌓일 때마다 살아 움직이는 장부다.

여기에 둘이 더해진다. 현금흐름(Cash Flow)은 예산·약정·실적을 일정 곡선에 분배해 기간별 자금 소요와 회수를 예측한다. 획득가치(EVM)는 계획가치(PV)·획득가치(EV)·실제원가(AC)에서 일정성과지수(SPI)와 원가성과지수(CPI)를 산출해, "지금 이대로 가면 끝에 얼마가 될지(EAC)"를 진행 중에 가늠하게 한다. 손실을 끝물이 아니라 한가운데서 보게 하는 장치다.

② 계약 · 약정 관리

발주(Prime Contract)와 하도급(Subcontract), 그에 묶이는 약정(Commitment)을 전자적으로 관리한다. 계약 금액·항목이 곧바로 원가 시트의 약정 열로 흘러가고, 기성(Progress Billing)과 지불(Payment)이 실적으로 누적된다. 계약 변경은 변경 BP를 통해 계약 잔액과 약정을 갱신한다. "이 계약에 얼마가 남았나, 다음 기성은 언제 얼마인가"가 한 곳에서 답이 나온다.

③ 변경 관리 — Change Order

설계·물량·계약 변경(Change Order)을 표준 절차로 통제한다. 앞서 본 철골 변경처럼, 변경 한 건은 폼 한 장으로 시작해 영향금액 자동 산정 → 결재 → 원가 반영의 흐름을 탄다. 핵심은 모든 변경이 원가에 즉시 연결되고 전 이력이 추적된다는 점이다. "이 변경이 예산을 얼마나 갉아먹었나, 누가 언제 승인했나"가 분쟁 없이 남는다.

④ 프로세스 자동화 — uDesigner

위 모든 흐름을 떠받치는 엔진이 uDesigner다. 조직마다 다른 폼·결재선·승인 규칙을 코드 없이(노코드) 설계하게 해 준다. 자세한 건 아래에서 따로 다룬다.

⑤ 문서 관리

도면·제출물(Submittal)·계약문서를 버전·권한과 함께 중앙에서 관리한다. 비즈니스 프로세스(변경·기성·검토)에 문서를 첨부해 함께 흐르게 할 수 있어, "어떤 결정이 어떤 도면 위에서 났는가"가 끊기지 않는다. 대규모 문서 협업은 자매 솔루션 Aconex가 더 깊이 담당하고, Unifier는 원가·프로세스 맥락에서 필요한 문서를 함께 묶는다.

⑥ 자본계획 · 포트폴리오

개별 프로젝트를 넘어, 발주처가 다수 프로젝트의 자본계획·우선순위·예산 배분을 한 포트폴리오로 관리하게 한다. 개별 프로젝트의 원가·일정이 위로 집계돼 포트폴리오 대시보드로 올라오고, "어떤 사업에 자본을 얼마나 태울지"를 데이터로 결정한다.

⑦ 자산 · 시설 관리

프로젝트가 끝나도 끝이 아니다. 준공된 시설·설비는 운영·유지보수로 넘어간다. Unifier는 자산·시설 관리(Facilities & Asset Management)까지 이어, 자산 등록·점검·유지보수 요청·공간 관리를 같은 플랫폼에서 다룬다. 건설(CapEx)에서 운영(OpEx)까지 자산의 전 생애주기를 한 데이터 위에서 잇는다.

이 모든 모듈의 힘은 연결에서 나온다. 변경이 계약을 건드리고, 계약이 원가를 움직이고, 원가가 현금흐름과 대시보드에 뜨는 — 그 연결이 끊기지 않는다.

uDesigner를 한 겹 더 — 노코드로 일하는 방식을 설계한다

Unifier의 진짜 차별점을 하나만 꼽으라면 uDesigner다. 대부분의 패키지 시스템은 "정해진 화면과 절차에 조직을 맞추라"고 요구한다. Unifier는 반대로, 조직의 일하는 방식을 시스템 안에 그려 넣게 한다.

그 단위가 비즈니스 프로세스(BP)다. BP 하나는 곧 하나의 업무 양식 + 그 양식이 흐르는 절차다. uDesigner에서는 코딩 없이 다음을 설계한다.

• 폼(Form) — 어떤 필드를 받을지(텍스트·금액·날짜·드롭다운·첨부), 무엇을 필수로 할지, 레이아웃을 어떻게 둘지.
• 워크플로우(Workflow) — 요청 → 검토 → 승인 → 반영으로 이어지는 단계와 분기, 각 단계의 담당·권한·기한.
• 원가 연결 — 이 BP가 원가 시트의 어느 열(예산·약정·실적·변경)을 움직이는지 매핑.
• 업무 규칙 — 금액 구간별 결재선 분기, 자동 계산식, 상태 전이 조건 등.

효과는 양방향이다. 조직마다 제각각인 결재선과 양식을 패키지에 맞춰 굽힐 필요 없이 그대로 구현할 수도, 반대로 표준 프로세스를 새로 이식할 수도 있다. 사람이 외워서 돌리던 절차가 시스템 위에서 자동으로 흐른다. uDesigner가 Unifier를 '원가 장부'가 아니라 '프로젝트 운영체제'로 만드는 지점이 여기다.

P6와 뭐가 다른가

같은 Primavera지만 역할이 다르다. P6는 '언제'(일정·공정)를, Unifier는 '얼마에·어떤 절차로'(원가·계약·프로세스)를 맡는다. 대체가 아니라 두 축이다.

둘을 연계하면 P6의 진척이 Unifier의 기성·획득가치(EV)로 흘러든다. 일정 지연(SPI)과 예산 초과(CPI)를 따로따로 보는 게 아니라 한 모델에서 본다. 대형 EPC가 손실을 끝물에야 발견하던 고질이, 이 통합 덕에 조기 경보로 바뀔 수 있다 — 진척이 곧 원가로 환산되어 보이기 때문이다. 단, 그 효과는 데이터가 제때 입력될 때 비로소 난다.

통합 PMIS라는 그림 — P6 · Aconex · Unifier

Unifier는 혼자 쓰기도 하지만, 진가는 같은 Primavera 생태계 안에서 묶일 때 드러난다. 세 축으로 나뉜다.

• Primavera P6 — 일정. 공정·자원·임계경로(CPM)로 "언제 끝나는가"를 잡는다.
• Oracle Aconex — 문서·협업. 도면·제출물·서신·검토를 발주처·EPC·협력사가 한 곳에서 주고받고 누가 무엇을 언제 봤는지 추적한다.
• Primavera Unifier — 원가·계약·프로세스. "얼마에, 어떤 절차로"를 통제하고, 위 둘에서 들어온 일정·문서를 원가 맥락으로 엮는다.

세 축이 묶이면 비로소 일정 × 비용 × 문서가 하나의 통합 PMIS가 된다. 일정이 밀리면 원가가 흔들리는 게 보이고, 그 결정의 근거 문서가 바로 붙어 다닌다. 흩어진 시스템 셋을 쓰는 것과, 연결된 한 체계를 쓰는 것의 차이가 여기서 갈린다.

어떻게 도입하나 — 방법론과 고려사항

도구를 깐다고 저절로 좋아지지 않는다. Unifier 도입의 성패는 제품보다 데이터와 프로세스 설계에서 갈린다. 실무에서 짚어야 할 단계는 대략 이렇다.

원가 코드 체계(CBS) 설계

모든 원가 흐름이 꽂힐 원가분류체계를 먼저 세운다. 너무 잘게 쪼개면 입력 부담이, 너무 굵으면 분석이 안 된다. WBS(일정)·계약 구조와의 정합도 이 단계에서 잡아야 P6 연계가 매끄럽다.

표준 프로세스(BP) 정립

변경·기성·구매요청·검토 등 핵심 업무를 표준 BP로 정의한다. 현행 결재선을 그대로 옮길지, 이 기회에 표준으로 정리할지를 성숙도에 맞춰 정하고 uDesigner로 구현한다.

데이터 이행

진행 중인 프로젝트라면 기존 예산·계약·실적을 이행(migration)해야 한다. 어느 시점을 기준선(baseline)으로 잡고 과거 이력을 어디까지 옮길지 범위를 정하는 게 관건이다.

단계적 롤아웃

전사·전 모듈을 한 번에 켜기보다 파일럿·핵심 모듈부터 검증 후 확대하는 편이 안전하다. 원가·변경관리처럼 효과 큰 영역을 먼저 정착시키고 포트폴리오·자산으로 넓혀 간다.

변화 관리

가장 자주 간과되는 단계다. 엑셀·메일에 익숙한 현장이 시스템 위에서 일하게 하려면 교육·매뉴얼·초기 운영지원이 필요하다. 시스템이 아니라 사람이 바뀌어야 효과가 난다.

제대로 정착했을 때 달라지는 것은 분명하다. 흩어진 원가·계약·승인이 단일 진실원천으로 모이고, 결재가 전자화·표준화되며, 변경과 원가가 월말이 아니라 실시간으로 보인다. 모든 처리에 감사 추적(audit trail)이 남아 "누가 언제 무엇을 승인했는가"가 분쟁 없이 남는다. 클라우드·온프레미스를 모두 지원해 도입 형태도 고를 수 있다.