시리즈 · AI 시대의 프로젝트 관리론
1회 · AI 시대의 프로젝트 관리론 1 - 전통적 SI 단계와 실패의 구조
AI 시대의 프로젝트 관리론 1 - 전통적 SI 단계와 실패의 구조
AI 시대의 프로젝트 관리론은 전통적 SI의 단계와 한계, 금융·공공 프로젝트가 축적한 현대화, AI가 요구사항부터 검증까지 다시 결합하는 과정을 역사와 실무 관점에서 추적하는 3부작입니다. 첫 글은 제안, 분석, 설계, 구현, 테스트, 이행이라는 익숙한 순서가 왜 만들어졌고 왜 반복해서 병목을 낳았는지부터 살펴봅니다.
과거의 방법론을 낡았다고 비웃기는 쉽습니다. 그러나 금융과 공공 시스템은 예산, 계약, 감사, 보안, 개인정보, 검수, 여러 수행사의 책임을 동시에 다뤄야 했습니다. 단계와 문서는 이런 복잡성을 통제하기 위한 장치였습니다. 실패의 원인은 단계가 존재했다는 사실보다, 단계 사이에서 지식이 늦게 돌아오고 책임이 흐려졌다는 데 있었습니다.
제안에서 이행까지, 실제로 이동한 것은 문서와 책임이었다
전통적 프로젝트를 여섯 단계로 나누면 각 단계에서 만드는 물건보다 다음 사람이 믿고 사용할 기준이 보입니다.
| 단계 | 핵심 질문 | 대표 산출물 | 흔한 실패 |
|---|---|---|---|
| 제안 | 무엇을 얼마에 언제까지 할 것인가 | 제안서, 견적, WBS, 가정·제외 범위 | 불명확한 범위를 낙관적 가격으로 약속 |
| 요구사항 분석 | 고객이 실제로 필요로 하는 것은 무엇인가 | 요구사항 정의서, 용어사전, RTM | 구두 합의, 누락, 상충 요구 |
| 설계 | 요구를 어떤 화면·데이터·연계로 구현할 것인가 | 화면·API·DB·배치·권한 설계 | 정상 흐름만 설계하고 예외를 누락 |
| 구현 | 설계를 실행 가능한 코드로 옮길 수 있는가 | 코드, 형상 기준선, 단위 테스트 | 설계 해석 차이와 프레임워크 제약 |
| 테스트 | 계약한 품질을 증명할 수 있는가 | 테스트 계획·결과, 결함, 재시험 증적 | 테스트 오라클과 현실 데이터 부족 |
| 이행 | 운영에서 되돌릴 수 있는가 | 전환·배포·롤백 계획, 운영 인수서 | 권한·데이터·복구 책임의 공백 |
이 과정에서 가장 어려운 일은 문서를 쓰는 일이 아닙니다. 고객의 요구가 기술적으로 가능한지, 얼마나 많은 노동이 필요한지, 일정과 비용이 견딜 수 있는지, 규제와 운영 위험을 누가 떠안을지를 판단하는 일입니다. 예컨대 RFP-042 → REQ-117 → UI-023/API-014 → TC-308 → 릴리스 1.2처럼 하나의 요구가 화면·API·테스트·배포까지 이어져야 변경 영향도 계산할 수 있습니다.
문제는 요구사항 개수를 진척률로 바꾸는 순간 시작됩니다. “분석 90% 완료”라고 보고해도 남은 10%가 인증, 정산, 데이터 이행처럼 시스템의 경계를 결정한다면 실제 위험은 대부분 남아 있습니다. 미정 항목을 숨기고 문서 완료를 선언하면 불확실성이 사라지는 것이 아니라 구현과 테스트 단계로 이동합니다.
워터폴의 진짜 약점은 직선이 아니라 늦은 피드백이었다
워터폴의 상징으로 자주 인용되는 Winston Royce의 1970년 논문을 읽으면 통념과 다른 부분이 보입니다. Royce는 요구사항에서 운영까지 이어지는 순차 모형을 제시했지만, 단순히 한 번씩 통과하면 된다고 권하지 않았습니다. 예비 설계, 시제품, 두 번 만들기, 문서화, 테스트 계획, 고객 참여와 이전 단계로의 피드백을 강조했습니다. Royce 원문의 문제의식도 대규모 시스템에서 뒤늦게 발견되는 오류의 비용이었습니다.
계약 기준선과 검수는 필요합니다. 하지만 “요구사항 문서가 승인됐다”와 “사용자와 개발팀이 같은 문제를 이해했다”는 다른 상태입니다. 화면이 실제로 움직여 보기 전에는 사용자가 자신의 요구를 정확히 설명하지 못할 수 있고, 개발자는 데이터와 예외 흐름을 보기 전에는 구현 난도를 알기 어렵습니다.
따라서 워터폴의 한계는 문서를 만들었다는 데 있지 않습니다. 문서가 피드백을 대신했다고 믿고, 변경을 학습이 아니라 통제 실패로만 취급한 데 있습니다. 이 점은 오늘날의 AI 코딩에서도 반복됩니다. 실행 결과를 빨리 만드는 것과 올바른 문제를 해결하는 것은 여전히 다릅니다.
한국의 기술은 교육과 조직의 갱신 주기를 기다려주지 않았다
“교수는 늙었고 현업은 정답을 모른다”는 표현은 분노를 전달하지만 원인을 설명하지 못합니다. 국내 IT 환경은 교육과 조직이 지식을 갱신하는 속도보다 훨씬 빠르게 움직였습니다. 교수와 현업 개발자 개인의 성실성보다 정책, 시장, 영문 기술자료, 번역, 교육과정, 기업 표준, 조달 기준의 시간이 서로 달랐던 것이 핵심입니다.
정책의 변화부터 빨랐습니다. 행정안전부 전자정부지원사업 자료에 따르면 20012002년 전자정부 11대 과제에 이어 20032007년 31대 로드맵이 추진됐습니다. 2008년 장애인차별금지법 시행은 웹 접근성을 사업 요구로 끌어왔고, 2009년 6월에는 전자정부표준프레임워크가 처음 공개됐습니다. 공공 시스템은 단순한 전산화에서 기관 간 연계, 표준화, 접근성과 공통 프레임워크로 짧은 시간 안에 확장됐습니다.
같은 시기 국제 기술도 연속적으로 바뀌었습니다. Apache Struts는 2000년 시작됐고 Spring Framework 1.0은 2004년 공개됐습니다. Node.js는 2009년 등장했고 React는 2013년 오픈소스로 공개됐으며, 2014년에는 Spring Boot 1.0과 HTML5 권고가 나왔습니다. 국내 현장에서는 EJB, 벤더·회사별 프레임워크, Struts와 자체 MVC, Spring으로 갈아타는 경험이 짧은 간격으로 누적됐습니다. 이 흐름은 기존 웹 기술 변천사와도 이어집니다.
필자가 체감한 기술 세대의 간격은 약 3년이었지만 이를 전국 통계로 말할 수는 없습니다. 영문 원자료가 번역되고, 서적과 강의로 소개되고, 기업 표준과 공공 발주에 반영될 때쯤 다음 세대가 등장했다는 현장 경험에 가깝습니다. 지금처럼 소셜 미디어와 동영상 강의가 즉시 확산되지 않던 시기에는 한글 문화권의 정보 지연이 더 컸습니다.
교수가 최근 10년의 기술을 공부했더라도 현대 웹의 실무 협업 방식을 모두 가르치기는 어려웠고, 현업 개발자도 현재 프로젝트를 끝내는 동안 다음 프레임워크를 맞았습니다. 이는 나이를 실력의 대리변수로 삼을 문제가 아닙니다. 교육과정 개편과 연구·강의 준비는 길고, 상용 프로젝트 도구의 교체 주기는 짧았습니다. 최신 프레임워크를 안다는 것과 대규모 협업·운영을 이해한다는 것 또한 서로 다른 역량입니다.
카드대란과 IT 인력 확대는 사실과 기억을 분리해야 한다
흔히 “2000년 카드사태”라고 부르지만 시점은 2002~2003년 신용카드 부실 사태로 바로잡는 편이 정확합니다. KDI와 IMF의 2004년 한국 보고서는 카드 이용 급증, 연체 차주와 부실자산 확대, 카드사 유동성 위기가 이 시기에 집중됐음을 보여줍니다. IMF 보고서는 2003년 11월 기준 연체 차주 약 230만 명과 부실자산 비율 34.2%를 기록했습니다.
정부의 당시 정책 기록을 보면, 2001년 정부가 2005년까지 IT 인력 부족을 전망하고 대규모 인력양성 정책을 추진한 사실도 확인됩니다. 전자정부 사업이 확대되고 IT 교육과 취업 전환이 늘어난 것 역시 당시의 큰 흐름입니다. 다만 카드사태로 일자리를 잃은 사람을 IT·SI 산업이 대규모 흡수했다는 인과를 직접 증명할 통계는 확인하지 못했습니다.
필자는 현장에서 비전공 전환 인력이 대거 유입되는 장면을 보았습니다. 그러나 이것은 필자의 기억과 해석으로 남겨야 합니다. 확인된 정책과 경기 사건을 한 문장으로 연결해 국가적 인과처럼 만들면 글은 선명해지지만 사실은 약해집니다. 더 중요한 논점은 산업이 빠르게 인원을 늘릴 수는 있어도 깊은 숙련, 역할 표준, 교육 시간을 동시에 만들기는 어려웠다는 점입니다.
개발 테스트와 운영 TA가 섞이면 책임이 사라진다
테스트와 이행을 WAS, 커넥션 풀, 메모리, 스레드, 파일, 모니터링 같은 단어로 나열하면 전문 용어 자랑에 그칩니다. 실무 질문은 “누가 언제 무엇을 검증하며, 실패하면 누가 권한을 가지고 복구하는가”입니다.
개발팀은 기능의 완결, 단위·통합·계약·회귀 테스트, 애플리케이션의 메모리 누수와 스레드 안전성, 파일 생성·보존 정책, 로그·메트릭·트레이스 계측을 책임져야 합니다. 운영·플랫폼팀은 운영 접근권한, WAS와 로드밸런서 토폴로지, 배포 승인, 인프라 용량, 백업·복구, 경보와 런북을 소유해야 합니다.
DB 커넥션 풀, 성능 목표, 부하·복구 시험, 관측성 스키마는 경계 업무입니다. 커넥션 풀은 애플리케이션 설정이지만 DB 세션 한도와 WAS 인스턴스 수에 의해 결정됩니다. 메모리 문제도 코드 누수인지 런타임 한도인지 증거 없이 한 팀에 밀어낼 수 없습니다.
운영 코드, 서버·DB 권한, 모니터링과 튜닝을 외부 개발사에 모두 맡기는 조직은 서비스 소유권을 포기합니다. 반대로 자신이 모르는 영역을 전부 “내 역할이 아니다”라고 밀어내는 운영자도 직무를 다했다고 보기 어렵습니다. 개인의 무지를 조롱해서 해결할 수 있는 문제는 아닙니다. 명확한 RACI, 승인권, 교육시간, 런북과 장애 지휘 체계를 조직이 제공해야 합니다.
전통적 프로젝트 관리의 핵심 실패는 단계가 많았다는 사실이 아닙니다. 단계 사이의 피드백이 늦었고, 문서가 실제 지식과 동기화되지 않았으며, 경계 업무의 최종 책임자가 불명확했다는 점입니다.
과거 관리론의 한계 위에서 다음 기술이 시작됐다
전통적 관리론은 정답이 없어서 무의미했던 것이 아닙니다. 계약과 검수, 대규모 협업과 운영 위험을 다루기 위해 필요한 최소한의 언어였습니다. 다만 사람이 문서를 갱신하고 모든 의존관계를 기억하며 단계 사이의 번역을 수행하는 비용이 너무 컸습니다.
이 문제들이 해결될 때까지 기술은 기다려주지 않았습니다. 모바일, 웹 표준, Git, SPA와 API가 기존 조직 위로 들어왔습니다. 이 글이 다룬 전통적 프로젝트 관리, SI 프로젝트 단계, SI 요구사항 분석은 특히 금융 공공 SI에서 계약과 운영을 지탱한 최소 구조였습니다. 2부에서는 반복된 실패를 통해 문서화와 테스트를 강화하면서도, 짧은 일정과 새로운 플랫폼을 동시에 감당해야 했던 현대화 과정을 살펴보겠습니다.
댓글 없음:
댓글 쓰기