(주)HFC컨설팅

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

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

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

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

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

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

AI 시대의 프로젝트 방법론 · Ep.04보고서를 만드는 데,금요일 오후가 통째로 들었다.관리 ③ 의사소통·보고: 주간보고는 누구를 위한 것이었나 · HFC Consulting금요일 오후 2시. 각 파트 리더들이 주간보고 취합을 시작한다. 진척률 숫자를 맞추고, 이슈의 표현 수위를 다듬고, 지난주 양식에 이번 주 내용을 붓는다. 4시 반, 12페이지 보고서가 완성된다. 월요일 아침 회의에서 그 보고서는 7분간 화면에 떠 있다가 닫힌다. 질문은 두 개였고, 둘 다 보고서에 없는 내용이었다. 여섯 명의 반나절이 7분을 위해 쓰인 셈이다.누구도 게으르지 않았다. 다만 이 의식이 설계된 시대의 정보 환경과 지금의 정보 환경이 다를 뿐이다.전제 — 보고서가 유일한 가시성 수단이던 시대주간보고와 정기 회의는 정보가..

AI 시대의 프로젝트 방법론 · Ep.03게이트는 분기마다 열렸다.결함은 매일 태어났다.관리 ② 품질·리스크: 검토 회의의 재구성 · HFC Consulting단계말 품질 검토 회의. 두 시간 동안 산출물 목록과 표본 검토 결과가 보고되고, 지적 사항 여덟 건이 기록되고, 게이트는 조건부 통과된다. 회의실을 나서던 품질 담당자가 혼잣말을 한다. "이번 분기에 생성된 코드가 30만 줄인데, 우리가 본 것은 3천 줄이다." 표본 1%로 지키는 품질 — 그것이 이 게이트의 실체다.품질 관리가 게을러서가 아니다. 단계말 게이트라는 장치가 설계될 때의 생산량과, 지금의 생산량이 다른 자릿수이기 때문이다.전제 — 검토는 비싸고, 그래서 모아서 한다단계말 게이트와 표본 검토는 하나의 전제에서 나왔다. 품질 활동은 숙..

AI 시대의 프로젝트 방법론 · Ep.02계획은 정교해졌다.현실은 사흘마다 갱신됐다.관리 ① 범위·일정: WBS는 살아남는가 · HFC Consulting착수 회의에서 4단계까지 분해된 WBS가 벽에 붙었다. 작업 패키지 217개, 각각에 공수와 담당자가 적혀 있다. 2주 뒤, PM은 매주 화요일 밤을 일정표 갱신에 쓰고 있다. AI를 잘 쓰는 개발자의 작업은 계획의 3분의 1 만에 끝나고, 검증 작업은 계획에 없던 곳에서 솟아난다. 계획이 틀려서가 아니다. 계획이 전제한 세계가 아니어서다.1편의 프레임대로 묻는다. WBS와 간트차트는 어떤 전제 위에 서 있었고, 무엇이 깨졌고, 무엇이 남는가.전제 — 작업 시간은 예측 가능하다는 믿음WBS의 논리는 명료하다. 큰 일을 작은 작업으로 분해하면 각 작업의 ..

AI 시대의 프로젝트 방법론 · Ep.01절차는 남았다.이유는 잊혔다.방법론은 왜 그렇게 생겼는가 · HFC Consulting방법론 표준 개정 회의. 입사 3년 차 개발자가 손을 든다. "AI로 반나절이면 만드는 화면인데, 설계서 승인에는 왜 일주일이 걸립니까?" 회의실이 조용해진다. PM은 "표준이니까"라고 답하고 싶은 것을 참는다. 그 표준이 왜 그렇게 정해졌는지, 이 회의실에서 정확히 설명할 수 있는 사람이 없기 때문이다. 절차는 20년을 살아남았는데, 절차의 이유는 잊혔다.방법론을 재검토하려면 순서가 있다. 무엇을 바꿀지 묻기 전에, 그것이 왜 그렇게 생겼는지를 먼저 물어야 한다. 이유를 모르고 바꾸면 버려야 할 것을 지키고, 지켜야 할 것을 버리게 된다. 이 연재 전체가 그 순서를 따른다.전제..