Where Projects Become Outcomes

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

분류 전체보기 143

코드와 테스트 증빙 - 개발 산출물 테일러링 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주는 압축의 결과였다애자일 선언의 핵심은 ..

개발 ① Waterfall의 재평가 (06/10)

AI 시대의 프로젝트 방법론 · Ep.06폭포수를 비웃던 팀이,요구 확정 없이 표류했다.개발 ① Waterfall의 재평가 · HFC Consulting킥오프에서 젊은 팀장이 선언했다. "우리는 폭포수처럼 문서에 파묻히지 않겠습니다. 빠르게 만들고 빠르게 고치겠습니다." 여섯 달 뒤, 팀은 세 번째로 같은 화면을 다시 만들고 있었다. 발주 부서마다 요구가 달랐고, 확정된 것이 없었으므로 무엇을 만들어도 틀린 것이 됐다. 그들이 버린 것은 문서가 아니라, 착수 전에 합의한다는 원칙이었다.Waterfall은 소프트웨어 역사에서 가장 오래 조롱받은 이름이다. 조롱을 걷어내고 다시 보면, 누명과 실제 한계가 뒤섞여 있다. 재평가가 필요하다 — 특히 AI가 전제를 바꾼 지금.전제 — 뒤로 갈수록 비싸지는 세계의 ..