Where Projects Become Outcomes

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

IT 인사이트 92

AI 활용 내역서와 프롬프트 기록 - 신설 산출물 1 (06/08)

AI 시대의 방법론 테일러링 · Ep.06AI를 썼습니까.답할 문서가 있습니까.신설 산출물 1 - AI 활용 내역서와 프롬프트 기록 · HFC Consulting하자 분쟁 조정 자리. 발주자 측 대리인이 물었다. "이 모듈, AI로 생성하셨습니까." 수행사 PM이 답했다. "일부는요." 대리인이 다시 물었다. "어느 일부입니까. 그리고 그 일부를 누가 검수했습니까." 회의실에 침묵이 흘렀다. 쓴 것은 사실인데, 어디에 어떻게 썼는지를 증명할 문서가 없었다. 쓰지 않았다고 말할 수도 없고, 제대로 썼다고 증명할 수도 없는 — 가장 나쁜 자리였다.여기서부터 두 편은 기존 산출물 목록에 없던 문서를 다룬다. 빼는 테일러링이 아니라 더하는 테일러링 — 신설 산출물의 첫 편은 AI 활용 자체를 증명하는 문서다.존..

코드와 테스트 증빙 - 개발 산출물 테일러링 2 (05/08)

AI 시대의 방법론 테일러링 · Ep.05테스트는 다 통과했다.아무도 안심하지 못했다.개발 산출물 테일러링 2 - 코드와 테스트 증빙 · HFC Consulting단위테스트결과서가 올라왔다. 테스트 케이스 4,800건, 통과율 100%. 품질 담당자가 몇 건을 열어 봤다. AI가 코드를 쓰고, AI가 테스트를 쓰고, AI가 결과서를 정리한 것이었다. 형식은 완벽했다. 그런데 그 4,800건이 무엇을 확인한 것인지, 확인했어야 할 것을 확인한 것인지는 결과서 어디에도 없었다. 출제자와 응시자와 채점자가 같은 시험이었다.개발 산출물의 두 번째 재단대. 단위테스트결과서, 코드리뷰 기록, 결함 대장 — 품질을 증명하던 문서들이다.존재 이유 — 증빙은 활동이 아니라 판단을 남기는 것이다테스트 증빙의 목적은 "테스..

요구사항과 설계 문서 - 개발 산출물 테일러링 1 (04/08)

AI 시대의 방법론 테일러링 · Ep.04치수를 재지 않고옷부터 지었다.개발 산출물 테일러링 1 - 요구사항과 설계 · HFC Consulting시연회는 성공적이었다. AI로 사흘 만에 만든 프로토타입에 발주 부서가 박수를 쳤다. 석 달 뒤, 검수 회의에서 같은 화면을 두고 싸움이 났다. "이 기능은 저렇게 동작하기로 한 적 없습니다." 근거를 찾으려 요구사항정의서를 폈다. 프로토타입보다 두 달 늦게, 프로토타입을 베껴 쓴 문서였다. 치수를 재기 전에 옷부터 지은 값을 검수 단계에서 치르고 있었다.개발 산출물의 첫 재단대. 요구사항정의서, 요구사항추적표, 화면설계서, 프로그램명세서 — 형해화 논쟁이 가장 뜨거운 문서들이다.존재 이유 — 합의를 증명하는 문서와 의도를 전달하는 문서이 네 문서는 한 묶음으로..

주간보고와 회의록 - 보고 산출물 테일러링 (03/08)

AI 시대의 방법론 테일러링 · Ep.03보고서는 매주 나왔다.결정은 어디에도 없었다.보고 산출물 테일러링 · HFC Consulting사업 종료 후 분쟁이 났다. 발주자가 물었다. "그 기능을 빼기로 한 결정, 언제 누가 했습니까." 수행사가 주간보고 마흔 장을 뒤졌다. 진척률과 금주 실적과 차주 계획은 마흔 번 반복됐는데, 그 결정이 언제 내려졌는지는 어디에도 없었다. 매주 쓴 문서가 정작 물어야 할 순간에 침묵했다.두 번째 재단대에 보고 산출물을 올린다. 주간보고, 회의록, 이슈·리스크 대장. 4기 4화에서 보고 체계의 재설계를 다뤘다면, 이번에는 문서 단위로 판정한다.존재 이유 — 보고 문서는 두 가지를 증명한다보고 산출물의 증명 대상은 둘로 갈린다. 하나는 사실이다. 무엇이 얼마나 진행됐는가. ..

사업수행계획서와 WBS - 계획 산출물 테일러링 (02/08)

AI 시대의 방법론 테일러링 · Ep.02계획서는 두꺼워졌다.약속은 얇아졌다.계획 산출물 테일러링 · HFC Consulting착수 2주 차, 사업수행계획서 협의 자리. 수행사가 내민 계획서는 240쪽이었다. 발주 담당자가 물었다. "이 중에서 지키지 못하면 문제가 되는 쪽수가 몇 쪽입니까." 답이 나오지 않았다. AI로 생성한 상세 일정과 조직도와 방법론 설명이 220쪽, 실제 약속은 20쪽이었다. 계획서가 두꺼워질수록 약속은 찾기 어려워진다.테일러링의 첫 재단대에 계획 산출물을 올린다. 사업수행계획서, WBS, 일정계획서 — 모든 사업이 여기서 시작하고, 형해화도 여기서 시작된다.존재 이유 — 계획서는 문서가 아니라 계약의 연장이다사업수행계획서는 세 산출물 중 성격이 다르다. 발주자와 수급인이 과업범..

산출물은 왜 존재하는가 - AI 시대의 방법론 테일러링 (01/08)

AI 시대의 방법론 테일러링 · Ep.01문서는 늘었다.증명은 사라졌다.산출물은 왜 존재하는가 · HFC Consulting착수보고를 앞둔 회의. 사업수행계획서 부록의 산출물 목록은 여든일곱 줄이었다. 예전 같으면 목록을 줄이자는 협상이 벌어졌을 자리에서, 이번에는 다른 말이 나왔다. "AI로 다 만들 수 있습니다. 일주일이면 됩니다." 회의실의 누구도 반기지 않았다. 여든일곱 개의 문서가 일주일 만에 나온다면, 그 문서들은 대체 무엇을 증명하는가.4기 완결편에서 방법론은 선택이 아니라 설계라고 했다. 이번 연재는 그 설계를 산출물 단위로 실행한다. 이름은 오래된 실무 용어 그대로, 테일러링이다. 재단사가 몸에 맞춰 옷감을 자르듯, 사업에 맞춰 산출물 체계를 자르는 일 — 다만 이제는 자르는 기준 자체가..

하이브리드 설계 원칙 - 방법론은 선택이 아니라 설계다 (10/10)

AI 시대의 프로젝트 방법론 · Ep.10 (완결)"정답 방법론"을 묻는 질문이,틀린 질문이었다.하이브리드 설계 원칙 · HFC Consulting방법론 표준화 태스크포스의 마지막 회의. 석 달의 검토 끝에 누군가 지친 목소리로 묻는다. "그래서 결론이 뭡니까. 우리는 뭘 쓰면 됩니까." 애자일을 밀던 쪽과 기존 표준을 지키던 쪽이 동시에 좌장을 본다. 좌장이 답한다. "그 질문이 우리를 석 달 동안 묶어 뒀습니다. 전사에 하나의 정답이 있다는 가정 — 그것부터 버려야 합니다."아홉 편의 결론은 하나로 모인다. 방법론은 진열대에서 고르는 것이 아니라 사업의 조건 위에 설계하는 것이다. 완결편은 그 설계에 필요한 도구 — 두 개의 축과 다섯 개의 원칙 — 를 정리한다.선택 매트릭스 — 두 개의 축이 조합을..

개발 ④ AI 네이티브 개발: 스펙이 코드를 만든다 (09/10)

AI 시대의 프로젝트 방법론 · Ep.09코드가 산출물이던 시대가,조용히 끝나가고 있다.개발 ④ AI 네이티브 개발: 스펙이 코드를 만든다 · HFC Consulting장애 대응 회의. 원인이 된 모듈을 어떻게 고칠지 논의가 길어지자, 젊은 개발자가 조심스럽게 말한다. "고치지 말고 다시 생성하면 안 됩니까. 스펙은 그대로 있으니까요." 회의실의 절반은 무슨 말인지 이해하지 못했고, 나머지 절반은 표정이 바뀌었다. 코드를 자산으로 여기고 평생을 일해 온 사람들 앞에서, 코드가 소모품이고 스펙이 자산이라는 세계관이 처음으로 발언권을 얻은 순간이었다.개발방법론 3부작의 마지막은 계보의 끝이 아니라 시작점이다. AI 네이티브 개발 — 아직 이름도 정착하지 않은 이 흐름을, 같은 프레임으로 본다.전제 — 지금까..

개발 ③ DevOps와 파이프라인: 자동화가 표준이 될 때 (08/10)

AI 시대의 프로젝트 방법론 · Ep.08배포는 자동화됐다.신뢰는 자동화되지 않았다.개발 ③ DevOps와 파이프라인: 자동화가 표준이 될 때 · HFC Consulting잘 갖춰진 파이프라인이 있다. 커밋하면 빌드가 돌고, 테스트가 돌고, 배포가 된다. 어느 날부터 커밋의 절반이 AI 생성 코드가 됐다. 파이프라인은 아무 일 없다는 듯 초록불을 켠다. 운영 책임자가 묻는다. "이 초록불은 무엇을 보증하는 겁니까." 빌드가 된다는 것, 기존 테스트가 통과한다는 것 — 딱 그만큼이다. 그 테스트를 누가 만들었느냐고 물으면, 절반은 같은 AI다.DevOps는 이 연재에서 유일하게 지위가 올라가는 방법론이다. 다만 승격에는 조건이 있다.전제 — 사람이 만든 코드를 빠르게 나르는 길DevOps와 CI/CD는 개..

개발 ② Agile은 살아남는가 (07/10)

AI 시대의 프로젝트 방법론 · Ep.072주 스프린트가 끝나기 전에,AI는 세 번을 다시 만들었다.개발 ② Agile은 살아남는가 · HFC Consulting스프린트 리뷰 데모 자리. 개발자가 말한다. "이건 첫 주에 만든 버전이고, 피드백을 예상해서 두 번 더 갈아엎은 버전이 따로 있습니다. 어느 쪽을 보시겠습니까." 스프린트가 약속한 리듬 — 2주마다 만들고, 보여주고, 배운다 — 보다 생산의 리듬이 빨라진 것이다. 스탠드업에서 공유하는 어제의 진척은, 커밋 로그가 이미 어젯밤에 말해 준 내용이다.역설적인 상황이다. 애자일은 느린 개발에 맞서 태어난 방법론인데, 이제 개발이 너무 빨라서 애자일이 느려 보인다. 정신과 의식을 나눠서 봐야 할 때다.전제 — 2주는 압축의 결과였다애자일 선언의 핵심은 ..