Where Projects Become Outcomes

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

AI사업관리 10

(10/10) 발주자가 AI 활용 여부를 알아야 할까요?

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

(09/10) AI 도입 전보다 프로젝트가 더 복잡해졌습니다.

AI 시대의 사업관리 · Ep.09단순해질 줄 알았다.관리할 게 더 늘었다.AI 도입 전보다 프로젝트가 더 복잡해졌습니다 · HFC ConsultingPM이 1년 전 계획서를 본다. "AI 도입으로 관리 부담 경감." 지금 그의 할 일 목록을 본다. 더 길다. 도구별 접근 권한, 범위 확장 요청, 기술 부채, 팀원 간 격차. 줄어든 게 없다.AI는 특정 작업을 단순하게 만든다. 동시에 새로운 관리 과제를 만든다.AI 도구가 하나가 아니다개발자마다 다른 도구를 쓴다. 결과물의 일관성과 접근 권한, 새로 관리할 항목이 늘어난다.빠른 프로토타입이 기대를 키운다빠르게 보여주면, 요구가 더 구체적이고 높아진다. 범위가 슬며시 늘어난다.기술 부채가 빨리 쌓인다검토 안 된 AI 코드가 쌓인다. 새 기능을 더할 때마다..

(08/10) 팀의 절반이 AI로 일한다 — 의사결정 이력은 누가 남깁니까?

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

(07/10) AI가 잘못 만들었을 때, 책임은 개발사입니까 AI입니까?

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

(06/10) 납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까?

AI 시대의 사업관리 · Ep.06기능은 통과했다.여섯 달 뒤, 코드는 못 열어봤다.납품물이 AI 생성 코드일 때, 검수 기준은 무엇입니까 · HFC Consulting납품 검수 회의. 모든 기능이 작동한다. 도장이 찍힌다. 여섯 달 뒤, 새 요청사항이 온다. 개발자가 그 코드를 연다. 구조가 너무 복잡하다. 손대는 데 일주일이 걸린다. 처음 개발보다 오래 걸린다.기능이 작동하는 것과, 코드가 건강한 것은 다른 이야기다.기능 동작 ≠ 코드 품질납품 시점엔 다 작동한다. 구조가 복잡하면, 유지보수 비용이 개발 비용을 넘어선다.보안 취약점이 그대로 들어온다AI는 학습 데이터의 패턴을 따른다. 오래된 보안 취약점 패턴도 같이 따른다.라이선스 문제가 숨어 있다강한 라이선스 조건의 오픈소스가 섞여 들어오면, 상용..

(05/10) 개발자가 AI로 만들었다고 합니다 — 공수 산정은 어떻게 합니까?

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

(04/10) AI Agent가 결정한 것, 변경관리 대상입니까?

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

(03/10) 요구사항을 프롬프트로 썼습니다 — RD 산출물은 어디 있습니까?

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

(02/10) AI가 사흘 만에 만들었다는데, 일정은 왜 늘어납니까?

AI 시대의 사업관리 · Ep.02개발은 사흘 걸렸다.일정은 그대로 두 달이다.AI가 사흘 만에 만들었다는데, 일정은 왜 늘어납니까 · HFC Consulting발주 담당자가 일정표를 본다. 개발 구간은 줄었다. 전체 일정은 그대로다. 그가 PM에게 묻는다. "AI 쓰면 빨라진다면서요." PM이 화면을 가리킨다. 검증, 테스트, 현업 확인 — 그 칸들은 줄지 않았다.AI가 빠른 구간과, 여전히 느린 구간이 따로 있다.빠르게 만들수록, 검증이 늘어난다하루에 500줄이 나온다. 그 500줄이 요구사항과 맞는지 확인하는 일은, 줄에 비례해서 늘어난다.요구사항이 불명확하면, AI는 반복 수정을 부른다프롬프트가 흐리면, 결과도 흐리다. 고치고 또 고친다. 처음부터 요구사항을 명확히 하는 것보다, 시간이 더 든다...

(01/10) 바이브 코딩으로 만든 코드, 누가 검수합니까?

AI 시대의 사업관리 · Ep.01코드는 빨리 나왔다.리뷰어는 멈춰 섰다.바이브 코딩으로 만든 코드, 누가 검수합니까 · HFC Consulting코드 리뷰어가 화면을 본다. 함수 하나가 눈에 띄게 깔끔하다. 그가 작성자에게 묻는다. "이거 직접 짠 겁니까." 작성자가 잠시 멈춘다. "AI가 짰는데, 검토는 했습니다." 리뷰어는 다음 줄로 넘어가지 못한다. 무엇을 어디까지 봐야 할지, 기준이 없다.바이브 코딩이 빨라진 만큼, 검수 기준은 그대로다. 셋 다 어려워졌다.코드의 출처가 안 보인다AI가 만든 코드와 사람이 짠 코드는 겉모습이 같다. 리뷰어는 그것을 개발자의 판단으로 읽는다. 프로젝트 고유의 규칙을, AI는 모른다.설계서와 코드의 연결이 끊겼다개발자가 설계서 대신 프롬프트를 썼다. 그 프롬프트는 ..