Where Projects Become Outcomes

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

형상관리 7

납품 목록에 프롬프트는 없었다

PMO 실전 노트 · Note 36시스템은 인계되었다.지능은 인계되지 않았다.납품 목록에 프롬프트는 없었다 · HFC Consulting운영 이관 2주 전이었다. 인수인계 회의 테이블에 산출물 목록이 펼쳐져 있었다. 설계서, 소스, 테스트 결과서. 목록의 모든 줄에 확인 표시가 붙어 있었다. 운영사 담당자가 목록에 없는 것을 물었다.장면한 공공기관의 상담 지원 시스템 구축 사업. 핵심 기능은 생성형 AI가 상담 답변 초안을 만드는 것이었고, 품질은 안정권에 들어 있었다. 운영사 담당자가 물었다. "프롬프트 원본은 어느 산출물에 있습니까. 답변 품질을 확인하실 때 쓰신 평가 데이터는 어디 있습니까."수행사 PL이 잠시 머뭇거렸다. "프롬프트는 담당 개발자의 작업 공간에 있습니다. 평가 데이터는 엑셀로 관리..

PMO 실전 노트 2026.10.12

48,000개 파일이 103초에 사라졌다 - 개발 산출물은 형상관리 안에 있는가

HFC 이슈 브리핑 · Brief 30명령은 복사본 정리였다.지워진 것은 원본이었다.48,000개 파일이 103초에 사라졌다 · HFC Consulting미국의 개발자 커뮤니티에 복구 기록 하나가 올라왔다. 밤 10시 10분 31초, AI 코딩 에이전트가 정리 스크립트를 실행했다. 10시 12분 14초에 작업이 끝났다. 103초였다. 파일 55,550개가 지워졌고, 그중 48,218개는 운영 중인 실제 작업 파일이었다.백업은 없었다.이슈 요약테크레이더 2026년 9월 27일 보도에 따르면, 한 개발자가 앤트로픽의 AI 코딩 도구 클로드 코드에 주식옵션 분석 프로그램 11건의 수리를 지시했다. 마지막 과업은 테스트용 복제 환경, 이른바 미러의 재구축이었다. 에이전트가 실행한 정리 스크립트는 이전 복사본을 ..

장애는 하나였다, 책임질 곳은 없었다

PMO 실전 노트 · Note 15세 회사 모두 옳았다.그래서 아무도 책임지지 않았다.장애는 하나였다, 책임질 곳은 없었다 · HFC Consulting장애는 새벽에 왔다. 통합테스트 3주차, 계정계에서 채널계로 넘어가는 이체 거래가 전문 오류로 멈췄다. 아침 회의실에는 세 회사의 노트북이 나란히 열렸다.장면한 금융기관의 차세대 사업이었다. 계정계 수행사, 채널계 수행사, 대외 중계 솔루션 벤더. 세 회사가 하나의 거래를 나눠 지고 있었다. 장애 자체는 두 시간 만에 우회 조치로 풀렸다. 문제는 그다음이었다. 재발 방지 대책을 내려면 원인을 확정해야 했고, 원인을 확정하는 자리는 곧 책임을 묻는 자리가 되었다. 원인 규명 회의는 세 시간을 넘겼다.계정계는 말했다. 전문을 규격대로 송신했다. 채널계는 말했..

PMO 실전 노트 2026.08.17

그 코드는 누가 짰습니까?

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

PMO 실전 노트 2026.08.10

변경관리: 운영 중의 변경이 개발 때보다 무겁다 (07/08)

AI 시대의 운영·유지보수 · Ep.07패치는 세 줄이었다.영향은 세 시스템에 걸쳐 있었다.변경관리: 운영 중의 변경이 개발 때보다 무겁다 · HFC Consulting세 줄짜리 패치였다. 사소해 보였고, 변경통제위원회를 거치지 않고 담당자 판단으로 배포되었다. 이틀 뒤, 연계된 다른 시스템에서 이상 동작이 보고되었다. 원인을 추적하니 그 세 줄이었다. 개발 단계였다면 리뷰 한 번으로 걸러졌을 문제가, 운영 단계에서는 이미 퍼진 뒤에야 발견되었다.이번 화는 운영 중 변경관리가 왜 개발 중 변경관리보다 무거워야 하는지에 관한 이야기다.오픈 전 가정 — 개발 때 쓰던 절차를 그대로 쓰면 된다많은 조직이 운영 단계의 변경관리를 개발 단계 절차의 축소판으로 설계한다. 규모가 작으니 승인 단계도 줄이고, 리뷰도 ..

가장 중요한 결정은 회의록에 없었다

PMO 실전 노트 · Note 02가장 중요한 결정은회의록에 없었다.복도에서 난 결정, 그리고 6개월 뒤 · HFC Consulting회의가 끝났다. 사람들이 회의실을 나섰다.발주사 팀장과 수행사 아키텍트가 복도에서 잠깐 섰다. 두 사람이 나눈 대화는 3분이었다. "그 부분은 그냥 이렇게 가죠." 아키텍트가 고개를 끄덕였다. 팀장이 먼저 걸어갔다.그 3분이 시스템의 핵심 구조를 바꿨다. 회의록에는 없었다.6개월 뒤, 아무도 기억하지 못했다통합 테스트 단계였다. 특정 모듈의 처리 방식이 설계 문서와 달랐다. PM이 원인을 추적했다. 개발자는 말했다. "아키텍트한테 그렇게 하라고 들었습니다." 아키텍트는 말했다. "팀장님이 그렇게 가자고 하셨습니다." 팀장은 말했다. "그런 얘기를 한 적이 없는데요."세 사..

PMO 실전 노트 2026.07.21

관리 ④ 변경·형상: 변경통제위원회의 속도 문제 (05/10)

AI 시대의 프로젝트 방법론 · Ep.05변경요청서가 접수됐을 때,변경은 이미 배포돼 있었다.관리 ④ 변경·형상: 변경통제위원회의 속도 문제 · HFC Consulting월간 변경통제위원회. 안건 14건이 상정됐다. 심의 중에 간사가 곤란한 얼굴로 보고한다. "이 중 아홉 건은 이미 반영되어 운영 중입니다. 사후 승인 안건입니다." 위원장이 묻는다. "그러면 우리는 지금 무엇을 심의하는 겁니까." 아무도 답하지 않는다. 위원회가 무력해서가 아니다. 변경이 생기는 속도가 위원회가 모이는 속도를 추월했기 때문이다.변경관리는 방법론의 마지막 방어선이다. 범위도 일정도 품질도 결국 변경을 통해 무너지기 때문이다. 이 방어선이 형식이 되는 순간, 앞의 모든 관리가 장부상의 것이 된다.전제 — 변경은 드물고 비싸다..