Where Projects Become Outcomes

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

하자담보책임 7

지적사항과 검수기준의 정합 (06/08)

AI 시대의 감리·PMO 위탁 가이드 · Ep.06감리는 지적했다.검수는 통과시켰다.지적사항과 검수기준의 정합 · HFC Consulting종료 감리 보고서에 지적사항 열두 건이 남았다. 그런데 같은 주에 검수는 합격 처리되었다.두 문서가 서로 다른 말을 하고 있었다. 1년 뒤 분쟁에서, 상대방은 그 둘을 나란히 놓았다.두 판정이 어긋날 때감리의 지적사항과 검수 결과는 원래 이어져 있어야 한다. 감리가 중대한 결함을 지적했다면 검수가 그것을 확인하고, 조치가 끝난 뒤 합격이 나와야 한다. 그런데 현장에서는 둘이 따로 논다. 감리는 감리대로 지적하고, 검수는 일정에 쫓겨 합격을 낸다. 두 문서 사이에 다리가 없다.이 어긋남은 평소에는 조용하다. 문제가 되는 것은 분쟁이 열릴 때다. 승패는 계약서가 아니라 ..

하자냐 신규냐: 무상과 유상의 경계 분쟁 (05/08)

AI 시대의 분쟁·클레임 대응 · Ep.05"하자보수로 처리하세요.""그건 신규 과업입니다."하자냐 신규냐: 무상과 유상의 경계 분쟁 · HFC Consulting오픈 석 달 뒤, 발주기관에서 공문이 왔다. "검색 응답이 현저히 느려짐. 하자보수로 즉시 조치 바람." 수행사가 로그를 확인했다. 오픈 시점 대비 데이터가 세 배로 늘어 있었다. PM이 회신 초안을 썼다. "검수 기준은 충족했으며, 성능 개선은 신규 과업입니다." 보내기 버튼 앞에서 그는 잠시 멈췄다.운영 단계에서 가장 잦은 분쟁은 크지 않다. 대신 끝없이 반복된다. 이 요청은 하자인가, 신규인가.한 건 한 건은 작다. 두어 시간짜리 수정, 반나절짜리 조치. 그러나 운영 3년이면 이런 요청이 수백 건 쌓인다. 판정 기준 없이 수백 번을 결정하..

검수 방어: 검수는 마지막 주에 시작되지 않는다 (08/08)

AI시대의 프로젝트 착수·수행 가이드 · Ep.08검수 기준표가 도착했다.처음 보는 문서였다.검수 방어: 검수는 마지막 주에 시작되지 않는다 · HFC Consulting검수 4주 전, 발주자가 검수 기준표를 보내왔다. 처음 보는 문서였다. 항목 수는 계약서의 검수 조항보다 세 배 많았다. 그날 회의실에서 나온 질문이 이 연재 전체의 요약이다. "이 기준, 언제 합의된 겁니까."검수는 프로젝트의 마지막 행사가 아니라, 첫날부터 쌓아 온 축적의 정산이다. 검수일에 할 수 있는 것은 확인뿐이다. 방어는 열 달 동안 하는 것이다.검수 방어의 세 축첫째 축은 기준의 조기 합의다. 검수 기준·절차·판정 방법을 착수 단계에 서면으로 합의한다. 발주자 관점의 검수기준 설계는 6기 7화에서 다뤘다. 수행사는 그 거울을..

그 코드는 누가 짰습니까?

PMO 실전 노트 · Note 13코드는 훌륭했다.작성자가 없었다.그 코드는 누가 짰습니까 · HFC Consulting통합테스트 3주차에 결함 하나가 눈에 걸렸다. 결함보다 코드가 더 이상했다. 잘 짜여 있었다. 그 팀의 어느 누구와도 다른 방식으로.장면한 금융기관의 정보계 시스템 구축 사업이었다. 결함의 원인을 추적하던 품질 담당이 이상한 점을 보고했다. 문제의 모듈에 리뷰 이력이 없다. 코딩 표준과 미묘하게 어긋난 스타일. 주석은 유창한데 그 팀의 어휘가 아니다. 담당 개발자를 불러 물었다. "이 모듈, 누가 짰습니까." 짧은 침묵 뒤에 답이 나왔다. "일정이 밀려서, 생성형 AI로 초안을 만들고 다듬었습니다."개발자를 탓하기는 어려웠다. 그는 두 달째 야근 중이었고, 일정 지연의 책임은 그의 것만..

PMO 실전 노트 2026.08.10

검수 전날 발견된 결함, 보고할 것인가

PMO 실전 노트 · Note 08결함은 검수 전날 밤에 온다.보고할 것인가, 덮을 것인가.검수 전날 발견된 결함, 보고할 것인가 · HFC Consulting검수는 요식이 아니다. 검수 조서에 적힌 것과 적히지 않은 것이, 이후 일 년의 책임 소재를 가른다. 그 차이가 가장 선명해지는 순간은, 검수 전날 밤이다.장면한 공공기관의 정보시스템 구축 사업. 검수 전날 21시, 테스트 리더가 PMO 사무실 문을 두드렸다. "정산 배치에서 결함이 나왔습니다. 월말 마감 조건에서만 재현됩니다." 수정에는 사흘이 필요했다. 검수는 다음 날 10시였다.회의실에 세 사람이 모였다. 수행사 PM이 먼저 말했다. "검수 시나리오에 없는 조건입니다. 일단 통과하고, 하자보수 기간에 조치하시죠." 발주 담당자는 아직 이 사실..

PMO 실전 노트 2026.08.04

하자담보책임의 경계: AI가 만든 버그는 누구 책임인가 (04/08)

AI 시대의 운영·유지보수 · Ep.04버그는 확실했다.누구의 버그인지가 불확실했다.하자담보책임의 경계: AI가 만든 버그는 누구 책임인가 · HFC Consulting하자보수기간 중 결함이 발견되었다. 수급인은 이것이 새 요구에 가깝다고 했다. 발주기관은 원래 요구의 미구현이라고 했다. 근거로 양쪽 모두 같은 요구사항 문서를 인용했다. 문서는 하나였는데 해석은 둘이었다.이번 화는 하자와 신규 요구를 가르는 경계선에 관한 이야기다.오픈 전 가정 — 하자보수기간이 있으니 문제없다많은 계약이 하자보수기간을 두는 것으로 안심한다. 일정 기간 무상으로 결함을 고쳐준다는 조항이 있으니, 오픈 후의 위험은 이미 관리되었다고 본다. 이 가정은 결함의 정의가 명확하다는 것을 전제한다.오픈 후 현실 — 정의가 흔들리는 ..

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

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