(주)HFC컨설팅

ERP는 돌아가고 있지만, 현장에는 여전히 엑셀을 사용하고 있습니다 (건설)

hfcconsulting — Thu, 9 Jul 2026 15:58:22 +0900

Domain Expertise · 건설

ERP는 있다.
원가는, 여전히 안 보인다.

HFC Consulting — Hemingway From Cuba

월말 정산. 현장소장이 엑셀을 따로 만든다. ERP 숫자와 다르다. 본사 회계팀이 묻는다. "이 차이, 뭡니까." 현장소장이 답한다. "현장 자재비는 저희가 따로 잡습니다. ERP엔 늦게 들어가서요."

ERP는 도입됐다. 현장의 실제 숫자는, 여전히 엑셀에 있다.

건설 원가는, 시스템이 있어도 잘 안 보이는 경우가 있다. 현장에서 본사로 데이터가 끊기지 않고 흐르는 구조가, 없기 때문이다.

우리는 건설 ERP 구축과 원가 관리 체계를 직접 다뤘다. 공사 계약·도급·실행 예산의 흐름을 아는 사람이 요구사항을 정의한다. 그래야 그 엑셀이 따로 안 만들어진다.

우리의 방식

현장 입력 부담을 줄이면서, 본사의 원가 가시성을 확보하는 균형을 찾는다. 균형이 안 맞으면, 현장은 시스템을 안 쓴다.

하는 일

건설 ERP·원가 관리 — 현장별 원가 집계, 실행 예산 관리. 건설업 구조에 맞춰 요구사항을 정의한다.

공정 관리·현장 연계 — 일일 실적이 본사로 실시간으로 흐르도록 구성한다.

BIM·디지털 현장 — BIM 데이터를 ERP·공정 시스템과 연동한다.

건설 AI — 원가 초과를 미리 예측한다. 데이터 표준화부터 살펴본다.

이런 상황이라면

✓ ERP는 있는데 원가 가시성이 확보되지 않는다
✓ ERP 신규 구축이나 재구축을 앞두고 있다
✓ BIM 도입이나 스마트 현장을 검토하고 있다

위 세 가지 중 하나라도 해당된다면, 지금이 이야기를 시작할 때다.

그 엑셀이, 더 이상 필요 없도록.

현재 진행 중인 사업이나 과제를 보내 주십시오. 함께 살펴보겠습니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(10/10) 발주자가 AI 활용 여부를 알아야 할까요?

hfcconsulting — Wed, 1 Jul 2026 15:22:31 +0900

AI 시대의 사업관리 · Ep.10 (마지막)

결정한 건 사람이다.
그건, 바뀌지 않는다.

발주자가 AI 활용 여부를 알아야 할까요 · HFC Consulting

아홉 편을 거쳐 온 질문들이, 결국 하나로 모인다. 발주자는 개발사의 AI 활용을 알아야 할 권리가 있을까. 개발사는 고지할 의무가 있을까.

법적 기준은 아직 없다. 실용적인 답은 정리할 수 있다.

알아야 할 이유

공수 대비 비용의 투명성. 검수 기준의 차별화. 장기 유지보수 계획. 셋 다 AI 활용 여부를 모르면 세울 수 없다.

알지 않아도 될 이유

개발 방법론은 개발사의 영역이다. 결과물 품질이 기준이면, 도구 선택에 개입할 이유가 없다. 과도한 고지 의무는, 효율을 막는다.

실용적 절충점 — 납품 코드의 주요 모듈만 고지 / 비율보다 위치를 명시 / 품질 기준을 도구가 아닌 결과물로 / RFP에 AI 조항을 선제적으로 포함

10편에 걸쳐 다룬 질문들은, 결국 오래된 문제와 맞닿아 있다. 책임 소재를 명확히 하는 것. 품질 기준을 정의하는 것. 변경을 관리하는 것. 의사결정을 기록하는 것.

AI가 결정했든, 사람이 결정했든 — 책임은 사람에게 있다. 사업관리는 그 책임 구조를 명확히 하는 일이다. 그 본질은, AI 시대에도 바뀌지 않는다.

HFC Consulting의 관점

25년간 SI 사업의 기획·PM·PMO를 직접 수행했습니다. RFP, 계약 구조, 검수 기준, PMO 거버넌스 — AI 시대에 맞는 사업관리 체계를 함께 고민합니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(09/10) AI 도입 전보다 프로젝트가 더 복잡해졌습니다.

hfcconsulting — Wed, 1 Jul 2026 15:21:27 +0900

AI 시대의 사업관리 · Ep.09

단순해질 줄 알았다.
관리할 게 더 늘었다.

AI 도입 전보다 프로젝트가 더 복잡해졌습니다 · HFC Consulting

PM이 1년 전 계획서를 본다. "AI 도입으로 관리 부담 경감." 지금 그의 할 일 목록을 본다. 더 길다. 도구별 접근 권한, 범위 확장 요청, 기술 부채, 팀원 간 격차. 줄어든 게 없다.

AI는 특정 작업을 단순하게 만든다. 동시에 새로운 관리 과제를 만든다.

AI 도구가 하나가 아니다

개발자마다 다른 도구를 쓴다. 결과물의 일관성과 접근 권한, 새로 관리할 항목이 늘어난다.

빠른 프로토타입이 기대를 키운다

빠르게 보여주면, 요구가 더 구체적이고 높아진다. 범위가 슬며시 늘어난다.

기술 부채가 빨리 쌓인다

검토 안 된 AI 코드가 쌓인다. 새 기능을 더할 때마다, 기존 코드와 부딪힌다.

팀 내 활용 격차가 갈등이 된다

잘 쓰는 사람과 못 쓰는 사람의 생산성 차이가, 코드 리뷰와 일정 조율에서 새로운 마찰을 만든다.

관리 체크포인트 — 팀 내 AI 도구 사용 기준 수립 / 범위 변경 게이트 강화 / 기술 부채 정기 점검 / 팀 AI 역량 표준화

PM의 역할이 줄지 않았다. 관리해야 할 것의 종류가 바뀌었다.

HFC Consulting의 관점

AI가 만드는 새로운 복잡도를, 어떤 체계를 더하고 어떤 걸 단순화할지 함께 고민합니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(08/10) 팀의 절반이 AI로 일한다 — 의사결정 이력은 누가 남깁니까?

hfcconsulting — Wed, 1 Jul 2026 15:20:25 +0900

AI 시대의 사업관리 · Ep.08

결정은 채팅창에 있다.
회의록엔 없다.

팀의 절반이 AI로 일한다 — 의사결정 이력은 누가 남깁니까 · HFC Consulting

신임 팀장이 묻는다. "이 아키텍처, 왜 이렇게 결정했습니까." 개발자가 답한다. "AI랑 얘기하다가 그렇게 됐습니다." 팀장이 회의록을 찾는다. 없다. 이슈 트래커도 본다. 없다. 그 결정은, 개발자의 노트북 안 채팅창에만 있다.

중요한 결정이, 공식 기록 밖에서 이루어지고 있다.

비공식 채널에서 결정이 난다

회의와 이슈 트래커 대신, AI와의 대화에서 결정이 이루어진다. 공식 기록으로 안 옮겨지면, 프로젝트 이력에 구멍이 생긴다.

"AI가 그렇게 하라고 해서"의 문제

AI의 제안을 수용한 건 결국 개발자의 판단이다. 그 근거가 기록되지 않으면, 나중에 책임 소재를 못 가린다.

개인 도구와 프로젝트 기록의 분리

개인 계정의 AI 대화는, 담당자가 바뀌면 접근할 수 없다. 프로젝트의 지식이 흩어진다.

거버넌스 체크포인트 — AI 보조 의사결정 기록 기준 수립 / 팀 공용 AI 도구 사용 체계 / 주요 프롬프트 로그 관리 규칙 / 정기 AI 활용 현황 공유

AI가 조언했어도, 결정한 건 사람이다. 그 근거를 남기는 책임도 사람에게 있다.

HFC Consulting의 관점

PMO 거버넌스 설계 경험을 바탕으로, AI 협업 환경에서 의사결정 이력 관리와 책임 체계를 함께 고민합니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(07/10) AI가 잘못 만들었을 때, 책임은 개발사입니까 AI입니까?

hfcconsulting — Wed, 1 Jul 2026 15:19:37 +0900

AI 시대의 사업관리 · Ep.07

"AI가 그렇게 짰습니다."
그 말로는, 끝나지 않는다.

AI가 잘못 만들었을 때, 책임은 개발사입니까 AI입니까 · HFC Consulting

운영 중 오류가 반복된다. 원인을 추적한다. 특정 엣지 케이스에서 로직이 잘못됐다. 개발사에 묻는다. "AI 코딩 도구로 생성한 부분인데, 거기서 문제가 생겼습니다." 계약서를 편다. AI 생성 코드에 대한 조항은, 어디에도 없다.

계약서는 아직 이 상황을 모른다.

하자 책임은 누구에게 있는가

납품물의 품질 책임은 개발사에 있다. 도구가 무엇이든 변하지 않는다. 쟁점은 "충분히 검토·검증했는가"다.

발주자가 AI 사용을 알아야 하는가

AI로 하루 만에 만든 코드를 사흘치로 청구하는 게 합당한지, 아직 업계 기준이 없다.

Agent의 결정도 같은 문제다

"AI가 결정했다"는 설명이 면책이 될 수 있을까. 지금은 아니다.

계약서 체크포인트 — 납품물 품질 기준 명시 / 코드 검토·테스트 의무 명시 / AI 도구 사용 고지 의무 / 하자 범위 명확화 / 지식재산권 조항

AI가 만들었든, 사람이 만들었든 — 납품물의 품질 책임은 개발사에 있다. 그 원칙이 실효성을 가지려면, 계약서에 기준이 명시돼야 한다.

HFC Consulting의 관점

RFP와 계약서의 품질 기준 조항이, 이 변화를 반영하고 있는지 함께 검토합니다. 계약 이전 단계에서 정의되지 않은 것은, 분쟁이 생겼을 때 발주자에게 불리하기 때문입니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(06/10) 납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까?

hfcconsulting — Wed, 1 Jul 2026 15:18:26 +0900

AI 시대의 사업관리 · Ep.06

기능은 통과했다.
여섯 달 뒤, 코드는 못 열어봤다.

납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까 · HFC Consulting

납품 검수 회의. 모든 기능이 작동한다. 도장이 찍힌다. 여섯 달 뒤, 새 요청사항이 온다. 개발자가 그 코드를 연다. 구조가 너무 복잡하다. 손대는 데 일주일이 걸린다. 처음 개발보다 오래 걸린다.

기능이 작동하는 것과, 코드가 건강한 것은 다른 이야기다.

기능 동작 ≠ 코드 품질

납품 시점엔 다 작동한다. 구조가 복잡하면, 유지보수 비용이 개발 비용을 넘어선다.

보안 취약점이 그대로 들어온다

AI는 학습 데이터의 패턴을 따른다. 오래된 보안 취약점 패턴도 같이 따른다.

라이선스 문제가 숨어 있다

강한 라이선스 조건의 오픈소스가 섞여 들어오면, 상용 제품에서 분쟁이 된다.

검수 체크포인트 — 기능 검수(기존) / 코드 품질 검수(컨벤션·복잡도) / 보안 취약점 스캔(SAST) / 오픈소스 라이선스 검토 / AI 생성 코드 비율 고지

검수 기준은 계약 전에 합의해야 한다. 납품 후에 "이것도 검수 범위였다"는 주장은, 분쟁의 시작이다.

HFC Consulting의 관점

RFP 설계 단계에서, AI 생성 코드를 포함한 납품물의 검수 기준을 구체적으로 정의합니다. 계약 이후에 논의하면 늦기 때문입니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(05/10) 개발자가 AI로 만들었다고 합니다 — 공수 산정은 어떻게 합니까?

hfcconsulting — Wed, 1 Jul 2026 15:13:29 +0900

AI 시대의 사업관리 · Ep.05

하루 걸렸다.
청구서엔 사흘이라 적혔다.

개발자가 AI로 만들었다고 합니다 — 공수 산정은 어떻게 합니까 · HFC Consulting

발주 담당자가 청구서를 본다. 사흘치 공수다. 개발사 PM에게 묻는다. "이거 며칠 걸렸습니까." PM이 솔직히 답한다. "AI로 하루 만에 했습니다." 담당자는 청구서를 다시 본다. 어떤 숫자가 맞는 건지, 그도 모른다.

투입 시간 기준의 공수 산정은, AI 도구 사용을 반영하지 못한다.

빠른 게 곧 싼 건 아니다

빠르게 만든 코드도, 검증·테스트·문서화는 별도다. 표면적으로 줄어 보여도, 총 비용은 줄지 않을 수 있다.

발주자는 속도보다 품질을 본다

결국 중요한 건 납품물의 가치다. 공수 논쟁보다, 품질 기준을 명확히 정의하는 게 먼저다.

공수 산정 체크포인트 — Output 기반 산정 전환 검토 / AI 사용 구간과 비사용 구간 분리 산정 / 품질 기준과 대금 지급 연동 / 절감 효과 공유 방식 논의

"AI를 쓰면 싸야 한다"는 전제보다, 결과물의 가치와 품질을 기준으로 논의하는 게 양측 모두에게 공정하다.

HFC Consulting의 관점

25년간 공급사 선정과 계약 협상 현장에 있었습니다. RFP 단계에서 공수 산정 방식과 품질 기준을 같이 고민합니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(04/10) AI Agent가 결정한 것, 변경관리 대상입니까?

hfcconsulting — Wed, 1 Jul 2026 15:11:49 +0900

AI 시대의 사업관리 · Ep.04

새벽 두 시,
Agent가 라이브러리를 바꿨다.

AI Agent가 결정한 것, 변경관리 대상입니까 · HFC Consulting

아침. 개발자가 출근한다. 빌드가 깨져 있다. 로그를 본다. 새벽에 AI Agent가 의존성 라이브러리를 최신 버전으로 올렸다. 누가 승인했는지 찾는다. 아무도 승인하지 않았다. Agent가 스스로 했다.

변경관리는 사람의 결정을 전제로 만들어졌다. AI Agent가 스스로 결정하면, 그 전제가 흔들린다.

경계를 미리 그어야 한다

변경관리 대상 — 외부 인터페이스, 데이터 모델, 보안 정책, 의존성 메이저 업데이트, 배포 구성.

기록만 남기고 허용 — 내부 리팩터링, 코드 스타일, 마이너 업데이트.

사전 차단 — 운영 DB 직접 접근, 외부 API 키 변경, 계약 관련 설정.

거버넌스 체크포인트 — AI Agent 자율 결정 범위 사전 정의 / 활동 로그 의무화 / 정기 변경 검토 프로세스 / 롤백 체계 확보

AI가 결정했다고, 변경관리에서 빠지지 않는다. 결정 주체가 바뀐 것이지, 영향은 여전히 시스템에 남는다.

HFC Consulting의 관점

변경관리 프로세스 설계와 운영 경험을 바탕으로, AI Agent 환경에서 그 범위를 어떻게 다시 정할지 함께 검토합니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(03/10) 요구사항을 프롬프트로 썼습니다 — RD 산출물은 어디 있습니까?

hfcconsulting — Wed, 1 Jul 2026 15:10:54 +0900

AI 시대의 사업관리 · Ep.03

기능은 있다.
그걸 왜 만들었는지는, 없다.

요구사항을 프롬프트로 썼습니다 — RD 산출물은 어디 있습니까 · HFC Consulting

새 개발자가 코드를 연다. 로그인 함수가 복잡하다. 왜 이렇게 짰는지 궁금하다. 깃 히스토리를 본다. 커밋 메시지는 "로그인 기능 추가"다. 전임자에게 묻는다. 전임자는 이미 퇴사했다. 그날 AI에게 뭐라고 물었는지는, 아무 데도 안 남았다.

요구사항을 프롬프트로 쓰면, 문서가 사라진다.

검수 기준이 없어진다

설계 문서가 없으면, 검수는 "맞는 것 같다"는 느낌으로 한다. 발주자와 개발사의 기준이 다르면, 분쟁이 된다.

유지보수가 어려워진다

의도가 기록되지 않으면, 코드는 블랙박스가 된다. 6개월 뒤, 누구도 그 함수를 건드리고 싶어 하지 않는다.

변경 요청의 영향도를 못 잰다

문서가 있으면 영향 범위를 안다. 없으면, 코드를 직접 따라가며 추적해야 한다.

문서화 체크포인트 — 프롬프트 로그 관리 / 기능 단위 수용 기준(Acceptance Criteria) 문서화 / 아키텍처 결정 기록(ADR) / 산출물 목록에 AI 사용 내역 추가

문서의 형태는 바뀔 수 있다. 무엇을 왜 만들었는지 추적할 기록은, 반드시 남아야 한다.

HFC Consulting의 관점

AI 코딩 환경에서도, 기능별 수용 기준과 결정 기록이 사업관리의 핵심 산출물입니다. PMO 설계 단계에서 같이 정의합니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(02/10) AI가 사흘 만에 만들었다는데, 일정은 왜 늘어납니까?

hfcconsulting — Wed, 1 Jul 2026 15:03:26 +0900

AI 시대의 사업관리 · Ep.02

개발은 사흘 걸렸다.
일정은 그대로 두 달이다.

AI가 사흘 만에 만들었다는데, 일정은 왜 늘어납니까 · HFC Consulting

발주 담당자가 일정표를 본다. 개발 구간은 줄었다. 전체 일정은 그대로다. 그가 PM에게 묻는다. "AI 쓰면 빨라진다면서요." PM이 화면을 가리킨다. 검증, 테스트, 현업 확인 — 그 칸들은 줄지 않았다.

AI가 빠른 구간과, 여전히 느린 구간이 따로 있다.

빠르게 만들수록, 검증이 늘어난다

하루에 500줄이 나온다. 그 500줄이 요구사항과 맞는지 확인하는 일은, 줄에 비례해서 늘어난다.

요구사항이 불명확하면, AI는 반복 수정을 부른다

프롬프트가 흐리면, 결과도 흐리다. 고치고 또 고친다. 처음부터 요구사항을 명확히 하는 것보다, 시간이 더 든다.

공수 산정 기준이 안 바뀌었다

AI가 줄인 시간은 일정표에 반영됐다. AI가 새로 만든 검증 작업은, 아직 반영되지 않았다.

일정 관리 체크포인트 — AI가 빠른 구간과 느린 구간을 나눠서 협의한다 / 검증 작업을 일정에 별도로 넣는다 / 요구사항 정의 시간을 줄이지 않는다 / 통합 테스트와 현업 검증은 따로 보호한다

병목은 AI가 빠른 구간이 아니다. 항상 다른 곳에 있다. 그곳을 찾는 게 PM의 일이다.

HFC Consulting의 관점

요구사항을 명확히 하고, 변경을 관리하고, 리스크를 미리 보는 일은 AI 시대에도 사라지지 않습니다. 그 체계를 같이 고민합니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

(주)HFC컨설팅

ERP는 돌아가고 있지만, 현장에는 여전히 엑셀을 사용하고 있습니다 (건설)

ERP는 있다.원가는, 여전히 안 보인다.

하는 일

이런 상황이라면

(10/10) 발주자가 AI 활용 여부를 알아야 할까요?

결정한 건 사람이다.그건, 바뀌지 않는다.

알아야 할 이유

알지 않아도 될 이유

(09/10) AI 도입 전보다 프로젝트가 더 복잡해졌습니다.

단순해질 줄 알았다.관리할 게 더 늘었다.

AI 도구가 하나가 아니다

빠른 프로토타입이 기대를 키운다

기술 부채가 빨리 쌓인다

팀 내 활용 격차가 갈등이 된다

(08/10) 팀의 절반이 AI로 일한다 — 의사결정 이력은 누가 남깁니까?

결정은 채팅창에 있다.회의록엔 없다.

비공식 채널에서 결정이 난다

"AI가 그렇게 하라고 해서"의 문제

개인 도구와 프로젝트 기록의 분리

(07/10) AI가 잘못 만들었을 때, 책임은 개발사입니까 AI입니까?

"AI가 그렇게 짰습니다."그 말로는, 끝나지 않는다.

하자 책임은 누구에게 있는가

발주자가 AI 사용을 알아야 하는가

Agent의 결정도 같은 문제다

(06/10) 납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까?

기능은 통과했다.여섯 달 뒤, 코드는 못 열어봤다.

기능 동작 ≠ 코드 품질

보안 취약점이 그대로 들어온다

라이선스 문제가 숨어 있다

(05/10) 개발자가 AI로 만들었다고 합니다 — 공수 산정은 어떻게 합니까?

하루 걸렸다.청구서엔 사흘이라 적혔다.

빠른 게 곧 싼 건 아니다

발주자는 속도보다 품질을 본다

(04/10) AI Agent가 결정한 것, 변경관리 대상입니까?

새벽 두 시,Agent가 라이브러리를 바꿨다.

경계를 미리 그어야 한다

(03/10) 요구사항을 프롬프트로 썼습니다 — RD 산출물은 어디 있습니까?

기능은 있다.그걸 왜 만들었는지는, 없다.

검수 기준이 없어진다

유지보수가 어려워진다

변경 요청의 영향도를 못 잰다

(02/10) AI가 사흘 만에 만들었다는데, 일정은 왜 늘어납니까?

개발은 사흘 걸렸다.일정은 그대로 두 달이다.

빠르게 만들수록, 검증이 늘어난다

요구사항이 불명확하면, AI는 반복 수정을 부른다

공수 산정 기준이 안 바뀌었다

ERP는 있다.
원가는, 여전히 안 보인다.

결정한 건 사람이다.
그건, 바뀌지 않는다.

단순해질 줄 알았다.
관리할 게 더 늘었다.

결정은 채팅창에 있다.
회의록엔 없다.

"AI가 그렇게 짰습니다."
그 말로는, 끝나지 않는다.

기능은 통과했다.
여섯 달 뒤, 코드는 못 열어봤다.

하루 걸렸다.
청구서엔 사흘이라 적혔다.

새벽 두 시,
Agent가 라이브러리를 바꿨다.

기능은 있다.
그걸 왜 만들었는지는, 없다.

개발은 사흘 걸렸다.
일정은 그대로 두 달이다.