(주)HFC컨설팅

발주자를 위한 AI 계약 가이드 · Ep.06AI가 만들었어도,보증은 사람이 한다.AI가 만든 하자, 누가 보증합니까 · HFC Consulting시스템 오픈 3주 차, 월말 정산 배치가 중단됐다. 원인은 날짜 경계를 잘못 처리한 로직. AI 도구가 생성한 코드였다. 하자보수 회의에서 수급인 담당자의 말끝이 흐려진다. "그 부분은 저희 개발자가 직접 작성한 것이 아니라서 원인 파악에 시간이 필요합니다." 발주 담당자가 계약서를 편다. 하자담보책임 조항에 AI에 관한 언급은 없다. 있어야 하는가. 1기 7화에서 던진 질문이 현실이 된 장면이다.원칙은 단순하다. 도구는 책임의 주체가 될 수 없다. 계약 당사자가 책임을 진다. 계약서가 할 일은 이 단순한 원칙에 예외가 생기지 않도록 문장을 세워 두는 것이다...

발주자를 위한 AI 계약 가이드 · Ep.05검수 기준 다섯 줄이면 된다.서명 전이라면.검수 기준 다섯 줄, 계약서에 이렇게 넣습니다 · HFC Consulting납품 검수 회의. 시연이 끝나고 전 기능이 정상 동작한다. 검수확인서에 도장이 찍힌다. 여섯 달 뒤, 기능 추가 요청이 들어오고 개발자가 그 코드를 연다. 구조가 복잡하게 얽혀 있어 손대는 데 일주일이 걸린다. 발주 담당자가 검수확인서를 다시 꺼내 읽는다. 어디에도 코드의 구조를 본다는 말은 없다. 기능이 동작하는 것과 코드가 건강한 것은 다른 문제인데, 계약서는 앞의 것만 물었다.1기 6화의 결론은 "검수 기준은 계약 전에 합의해야 한다"였다. 이번 편은 그 합의를 조항 문구로 완성한다."검사에 합격하여야 한다"의 공백표준 계약서의 검수 조항..

발주자를 위한 AI 계약 가이드 · Ep.04코드는 남았다.의도는 사라졌다.프롬프트도 납품물입니까 · HFC Consulting운영 이관 후 여섯 달. 유지보수 수급인이 소스코드를 연다. 인증 로직이 통상의 구조와 다르게 짜여 있다. 왜 이렇게 설계했는지 확인할 문서가 없다. 설계서에는 해당 내용이 없고, 담당 개발자는 퇴사했다. 그 판단은 어느 오후의 프롬프트 창에서 이루어졌고, 그 창은 닫혔다. 유지보수 수급인은 구조 분석에만 3주를 쓴다. 그 3주의 비용은 발주자가 낸다.1기 3화에서 진단한 문제다. 이번 편은 그 진단을 계약 조항으로 옮긴다.산출물 목록은 프로젝트의 유산 목록이다프로젝트가 종료되면 인력은 떠나고 산출물만 남는다. 계약서의 산출물 목록은 결국 "발주 조직에 남을 유산의 목록"이다. ..

발주자를 위한 AI 계약 가이드 · Ep.03개발비는 줄었다는데,총액은 왜 그대로인가.AI로 반값이 됐다는데, 왜 견적은 그대로입니까 · HFC Consulting견적 협상 자리. 발주 담당자가 기사 하나를 테이블에 올린다. AI 도입으로 개발 생산성이 배가 되었다는 내용이다. "이 정도면 견적이 달라져야 하는 것 아닙니까." 수급인 측 임원이 답한다. "빨라진 것은 코딩이고, 저희가 납품하는 것은 시스템입니다." 양쪽 모두 틀린 말이 아니다. 문제는 계약서의 대가산정 방식이 이 논쟁을 정리할 언어를 갖고 있지 않다는 데 있다.투입 공수(M/M) 단가표는 사람이 코드를 작성하던 시기의 통화다. 그 전제가 흔들리면, 단가표의 신뢰도 함께 흔들린다.투입 공수 산정의 균열동일한 화면 하나를 개발자 A는 AI ..

발주자를 위한 AI 계약 가이드 · Ep.02금지할 필요는 없다.모르는 것이 문제다.RFP에 "AI 써도 됩니까"라고 물어야 합니까 · HFC Consulting제안 설명회가 끝난 질의응답 시간. 발주 담당자가 묻는다. "개발 과정에 AI 도구를 활용하십니까?" 제안사 세 곳의 답변이 전부 다르다. 첫 번째 회사는 "전사적으로 적극 활용합니다"라고 답한다. 두 번째는 "필요 시 제한적으로 활용합니다"라고 답한다. 세 번째는 "내부 정책상 답변이 어렵습니다"라고 답한다. 세 답변을 평가표의 어느 항목으로 비교해야 하는가. 기준이 없다. 제안요청서에 그 질문이 없었기 때문이다.AI 활용 고지 요구의 목적은 금지가 아니다. 세 답변을 비교 가능하게 만들고, 그 답변을 계약의 전제로 삼는 것이다.왜 계약 협상이..

발주자를 위한 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의 제안을 수용한 건 결국 개발자의 판단이다. 그 근거가 기록되지 않으면, 나중에 ..