Where Projects Become Outcomes

"프로젝트를 성과로 전환하다"

IT계약 7

서명 전 마지막 점검 - AI 계약 체크리스트 총정리 (08/08)

발주자를 위한 AI 계약 가이드 · Ep.08 (완결)서명하기 전,여덟 줄만 확인한다.서명 전 마지막 점검 — AI 계약 체크리스트 총정리 · HFC Consulting계약서 최종본이 도착했다. 서명은 내일 오전이다. 조항 전체를 처음부터 다시 읽을 시간은 없다. 법무 검토는 끝났지만, 법무의 관점은 법률 리스크이지 사업 리스크가 아니다. AI와 관련해 사업 담당자가 직접 확인해야 할 항목이 있다. 이 연재의 일곱 편을 그 목적에 맞게 한 장으로 압축했다.계약의 진행 순서대로 따라가면 된다. RFP에서 유지보수까지, 여덟 줄이다.단계별 종합 체크리스트단계확인 질문근거 편1. RFPAI 도구·공정·데이터의 3요소 고지 요구가 있었는가, 그 답변이 계약 문서에 편입되는가Ep.022. 대가검증·보안·문서화 공..

우리 데이터가 남의 AI를 학습시키고 있다면... (07/08)

발주자를 위한 AI 계약 가이드 · Ep.07우리 데이터가남의 도구 안에 있다.우리 데이터가 남의 AI를 학습시키고 있다면 · HFC Consulting개발자가 재현되지 않는 오류를 붙잡고 있다. 원인 파악이 늦어진다. 그가 운영 데이터 한 조각을 복사해 AI 채팅창에 붙여넣는다. "이 데이터에서 왜 오류가 발생하는지 분석해줘." 오류는 잡힌다. 그 데이터에 고객 계좌번호가 포함되어 있었다는 사실은 아무 기록에도 남지 않는다. 유출 신고도, 보고도 없다. 유출이라는 자각 자체가 없었기 때문이다.악의가 아니라 습관이다. 습관이기 때문에 더 자주 일어난다. 계약이 이 장면을 다뤄야 하는 이유다.비밀유지 조항이 잡지 못하는 이유기존 계약서에도 비밀유지 조항은 있다. 그러나 그 조항이 상정하는 유출은 사람이 사..

AI가 만든 하자, 누가 보증합니까? (06/08)

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

검수 기준 다섯 줄, 계약서에 이렇게 넣습니다 (05/08)

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

프롬프트도 납품물입니까? (04/08)

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

AI로 반값이 됐다는데, 왜 견적은 그대로입니까? (03/08)

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

계약서에는 AI가 없다 (01/08)

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