(주)HFC컨설팅

발주자를 위한 AI 계약 가이드 · Ep.01개발 방식은 바뀌었다.계약서는 그대로다.그 계약서에는 AI가 없다 · HFC Consulting계약 체결을 앞둔 검토 회의. 법무 담당자가 표준 용역계약서를 넘긴다. 작년 사업에 쓴 것과 같은 양식이다. 재작년과도 같다. 과업범위, 대가, 산출물, 검수, 하자담보책임. 조항은 빠짐없이 갖춰져 있다. 그 사이 개발 현장은 달라졌다. 제안사 개발 인력의 상당수가 AI 도구로 코드를 생성하고, 요구사항은 프롬프트로 전달되며, 사흘 걸리던 화면이 반나절에 나온다. 계약서의 어느 조항도 이 변화를 다루지 않는다.문제는 계약서가 낡았다는 것이 아니다. 계약서가 전제하는 개발 방식과, 실제 개발 방식이 어긋났다는 것이다. 전제가 어긋난 계약은 분쟁이 생기기 전까지는 멀쩡해..

Domain Expertise · 건설ERP는 있다.원가는, 여전히 안 보인다.HFC Consulting — Hemingway From Cuba월말 정산. 현장소장이 엑셀을 따로 만든다. ERP 숫자와 다르다. 본사 회계팀이 묻는다. "이 차이, 뭡니까." 현장소장이 답한다. "현장 자재비는 저희가 따로 잡습니다. ERP엔 늦게 들어가서요."ERP는 도입됐다. 현장의 실제 숫자는, 여전히 엑셀에 있다.건설 원가는, 시스템이 있어도 잘 안 보이는 경우가 있다. 현장에서 본사로 데이터가 끊기지 않고 흐르는 구조가, 없기 때문이다.우리는 건설 ERP 구축과 원가 관리 체계를 직접 다뤘다. 공사 계약·도급·실행 예산의 흐름을 아는 사람이 요구사항을 정의한다. 그래야 그 엑셀이 따로 안 만들어진다.우리의 방식현장..

AI 시대의 사업관리 · Ep.10 (마지막)결정한 건 사람이다.그건, 바뀌지 않는다.발주자가 AI 활용 여부를 알아야 할까요 · HFC Consulting아홉 편을 거쳐 온 질문들이, 결국 하나로 모인다. 발주자는 개발사의 AI 활용을 알아야 할 권리가 있을까. 개발사는 고지할 의무가 있을까.법적 기준은 아직 없다. 실용적인 답은 정리할 수 있다.알아야 할 이유공수 대비 비용의 투명성. 검수 기준의 차별화. 장기 유지보수 계획. 셋 다 AI 활용 여부를 모르면 세울 수 없다.알지 않아도 될 이유개발 방법론은 개발사의 영역이다. 결과물 품질이 기준이면, 도구 선택에 개입할 이유가 없다. 과도한 고지 의무는, 효율을 막는다.실용적 절충점 — 납품 코드의 주요 모듈만 고지 / 비율보다 위치를 명시 / 품질 ..

AI 시대의 사업관리 · Ep.09단순해질 줄 알았다.관리할 게 더 늘었다.AI 도입 전보다 프로젝트가 더 복잡해졌습니다 · HFC ConsultingPM이 1년 전 계획서를 꺼냈다. 거기엔 이렇게 적혀 있다. "AI 도입으로 관리 부담 경감." 지금의 할 일 목록을 본다. 도구별 접근 권한 관리. 늘어나는 범위 변경 요청. 쌓이는 기술 부채. 팀원 간 활용 격차 조율. 목록은 1년 전보다 길다. 줄어든 것을 찾기가 어렵다. AI는 특정 작업을 단순하게 만든다. 그리고 그만큼의 새로운 관리 과제를 만든다. 이 두 번째 문장이 계획서에는 없었다.복잡성 ① — AI 도구가 하나가 아니다개발자 A는 Copilot을 쓴다. B는 Claude를 쓴다. C는 사내 승인 없이 새로 나온 도구를 쓴다. 도구마다 결과물..

AI 시대의 사업관리 · Ep.08결정은 채팅창에 있다.회의록엔 없다.팀의 절반이 AI로 일한다 — 의사결정 이력은 누가 남깁니까 · HFC Consulting신임 팀장이 묻는다. "이 아키텍처, 왜 이렇게 결정했습니까." 개발자가 답한다. "AI랑 얘기하다가 그렇게 됐습니다." 팀장이 회의록을 찾는다. 없다. 이슈 트래커도 본다. 없다. 그 결정은, 개발자의 노트북 안 채팅창에만 있다.중요한 결정이, 공식 기록 밖에서 이루어지고 있다.비공식 채널에서 결정이 난다회의와 이슈 트래커 대신, AI와의 대화에서 결정이 이루어진다. 공식 기록으로 안 옮겨지면, 프로젝트 이력에 구멍이 생긴다."AI가 그렇게 하라고 해서"의 문제AI의 제안을 수용한 건 결국 개발자의 판단이다. 그 근거가 기록되지 않으면, 나중에 ..

AI 시대의 사업관리 · Ep.07"AI가 그렇게 짰습니다."그 말로는, 끝나지 않는다.AI가 잘못 만들었을 때, 책임은 개발사입니까 AI입니까 · HFC Consulting운영 중 오류가 반복된다. 원인을 추적한다. 특정 엣지 케이스에서 로직이 잘못됐다. 개발사에 묻는다. "AI 코딩 도구로 생성한 부분인데, 거기서 문제가 생겼습니다." 계약서를 편다. AI 생성 코드에 대한 조항은, 어디에도 없다.계약서는 아직 이 상황을 모른다.하자 책임은 누구에게 있는가납품물의 품질 책임은 개발사에 있다. 도구가 무엇이든 변하지 않는다. 쟁점은 "충분히 검토·검증했는가"다.발주자가 AI 사용을 알아야 하는가AI로 하루 만에 만든 코드를 사흘치로 청구하는 게 합당한지, 아직 업계 기준이 없다.Agent의 결정도 같은..

AI 시대의 사업관리 · Ep.06기능은 통과했다.여섯 달 뒤, 코드는 못 열어봤다.납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까 · HFC Consulting납품 검수 회의. 모든 기능이 작동한다. 도장이 찍힌다. 여섯 달 뒤, 새 요청사항이 온다. 개발자가 그 코드를 연다. 구조가 너무 복잡하다. 손대는 데 일주일이 걸린다. 처음 개발보다 오래 걸린다.기능이 작동하는 것과, 코드가 건강한 것은 다른 이야기다.기능 동작 ≠ 코드 품질납품 시점엔 다 작동한다. 구조가 복잡하면, 유지보수 비용이 개발 비용을 넘어선다.AI생성 코드에서 이 간극은 더 커진다. AI는 "돌아가는 코드"를 빠르게 만든다. "고치기 쉬운 코드"를 만들라고 지시받은 적이 없다면, 그렇게 만들지 않는다. 사람이 짠 코드라면 ..

AI 시대의 사업관리 · Ep.05하루 걸렸다.청구서엔 사흘이라 적혔다.개발자가 AI로 만들었다고 합니다 — 공수 산정은 어떻게 합니까 · HFC Consulting발주 담당자가 청구서를 본다. 사흘치 공수다. 개발사 PM에게 묻는다. "이거 며칠 걸렸습니까." PM이 솔직히 답한다. "AI로 하루 만에 했습니다." 담당자는 청구서를 다시 본다. 어떤 숫자가 맞는 건지, 그도 모른다.투입 시간 기준의 공수 산정은, AI 도구 사용을 반영하지 못한다.빠른 게 곧 싼 건 아니다빠르게 만든 코드도, 검증·테스트·문서화는 별도다. 표면적으로 줄어 보여도, 총 비용은 줄지 않을 수 있다.발주자는 속도보다 품질을 본다결국 중요한 건 납품물의 가치다. 공수 논쟁보다, 품질 기준을 명확히 정의하는 게 먼저다.공수 산정..

AI 시대의 사업관리 · Ep.04새벽 두 시,Agent가 라이브러리를 바꿨다.AI Agent가 결정한 것, 변경관리 대상입니까 · HFC Consulting아침. 개발자가 출근한다. 빌드가 깨져 있다. 로그를 본다. 새벽에 AI Agent가 의존성 라이브러리를 최신 버전으로 올렸다. 누가 승인했는지 찾는다. 아무도 승인하지 않았다. Agent가 스스로 했다.변경관리는 사람의 결정을 전제로 만들어졌다. AI Agent가 스스로 결정하면, 그 전제가 흔들린다.경계를 미리 그어야 한다변경관리 대상 — 외부 인터페이스, 데이터 모델, 보안 정책, 의존성 메이저 업데이트, 배포 구성.기록만 남기고 허용 — 내부 리팩터링, 코드 스타일, 마이너 업데이트.사전 차단 — 운영 DB 직접 접근, 외부 API 키 변경,..

AI 시대의 사업관리 · Ep.03기능은 있다.그걸 왜 만들었는지는, 없다.요구사항을 프롬프트로 썼습니다 — RD 산출물은 어디 있습니까 · HFC Consulting새 개발자가 코드를 연다. 로그인 함수가 복잡하다. 왜 이렇게 짰는지 궁금하다. 깃 히스토리를 본다. 커밋 메시지는 "로그인 기능 추가"다. 전임자에게 묻는다. 전임자는 이미 퇴사했다. 그날 AI에게 뭐라고 물었는지는, 아무 데도 안 남았다.요구사항을 프롬프트로 쓰면, 문서가 사라진다.검수 기준이 없어진다설계 문서가 없으면, 검수는 "맞는 것 같다"는 느낌으로 한다. 발주자와 개발사의 기준이 다르면, 분쟁이 된다.유지보수가 어려워진다의도가 기록되지 않으면, 코드는 블랙박스가 된다. 6개월 뒤, 누구도 그 함수를 건드리고 싶어 하지 않는다.변..