시리즈 · AI 시대의 프로젝트 관리론
2회 · AI 시대의 프로젝트 관리론 2 - 금융·공공 SI가 만든 현대화
AI 시대의 프로젝트 관리론 2 - 금융·공공 SI가 만든 현대화
AI 시대의 프로젝트 관리론 2부는 금융·공공 프로젝트가 수많은 실패를 비용으로 지불하며 축적한 관리 역량과, 기존 문제가 해결되기 전에 밀려온 기술 현대화를 함께 다룹니다. 문서와 테스트, Jira, Git, 코드리뷰는 분명 프로젝트를 개선했습니다. 그러나 국내의 짧은 일정은 그 방법론을 충실히 운영할 시간을 주지 않았고, 모바일 시장의 폭발은 준비되지 않은 조직까지 새 플랫폼으로 밀어 넣었습니다.
이 역사는 “과거는 무능했고 새 도구가 구원했다”는 이야기가 아닙니다. 관리론은 실패를 줄이기 위해 발전했고, 기술은 그 발전 속도를 기다리지 않았습니다. 국내 SI의 현대화는 두 흐름이 충돌하고 타협한 결과입니다.
실패의 누적은 발주자와 수행사의 경험치가 됐다
금융·공공 시스템은 같은 업무를 한 번만 전산화하지 않습니다. 차세대 구축, 채널 개편, 규제 대응, 데이터 전환, 성능 고도화가 반복됩니다. 발주사는 이전 프로젝트에서 빠진 요구, 검수 때 다툰 범위, 전환일에 실패한 데이터, 운영 인수 뒤 떠넘겨진 장애를 기억합니다. 수행사도 어떤 요구가 후반에 폭발하고 어떤 증적이 대금을 지키는지 학습합니다.
이 경험은 RFP, 요구사항 템플릿, 표준 산출물, 보안·접근성 체크리스트, 테스트 등급, 데이터 이행 계획과 운영 인수 기준으로 남았습니다. 전자정부표준프레임워크와 공통 컴포넌트도 모든 문제의 해답은 아니었지만, 프로젝트마다 기반을 처음부터 만드는 비용을 줄였습니다.
필자의 경험상 10억 원 미만 중소형 개발은 4~6개월 일정이 많아졌고 현장에서도 하나의 기준점으로 받아들여졌습니다. 이것은 공인 시장 통계가 아닙니다. 프로젝트 유형, 기존 시스템 재사용, 조달 방식과 범위에 따라 크게 달라집니다. 기간 단축이 학습과 재사용의 성과일 수도 있지만, 범위를 숨기거나 인력과 야근을 압축한 결과일 수도 있습니다.
짧은 일정은 성숙도의 증거가 될 수도 있고, 관리·검증 시간을 견적에서 지운 결과일 수도 있습니다. 기간만으로 프로젝트의 발전을 판단할 수 없습니다.
문서는 발주사의 품질선이자 수행사의 방어선이다
요구사항 문서화의 목적을 “정리 정돈”으로만 보면 현장의 절박함을 놓칩니다. 발주사에게 요구사항 ID와 추적행렬은 납품물의 최소 품질을 지키는 마지노선입니다. 누락된 기능, 자의적으로 바뀐 규칙, 테스트하지 않은 예외를 지적할 계약 근거가 됩니다.
수행사에게도 같은 문서는 방패입니다. 합의된 요건을 이행했다는 증거이며, 계약 범위에 없던 요구를 무제한 무상 수행하지 않아도 되는 근거입니다. REQ-117이 UI-023, API-014, TC-308로 이어지고 변경 이력이 남으면 “해줬다/안 해줬다”의 기억 싸움이 증거의 대화로 바뀝니다.
일본과 비교하면 시간의 문제가 선명해집니다. IPA의 2024 소프트웨어 동향조사는 일본에서 워터폴형 개발이 여전히 주류라고 설명합니다. IPA는 사용자를 위한 요구사항 정의 가이드에서 상류공정의 문제와 해결 관점, 문서의 종류와 흐름을 세밀하게 제시합니다.
다만 일부 경험담에서 “일본은 설계만 항상 1년 이상 한다”는 주장을 뒷받침할 전국 통계는 확인하지 못했습니다. 대형 프로젝트의 장기 상류공정 사례와 현장 평판으로는 말할 수 있어도 국가 전체의 관행으로 일반화해서는 안 됩니다.
국내에서는 비용과 납기를 이유로 중소형 프로젝트를 6개월 이상 늘리기 어렵습니다. 분석, 설계, 검토, 문서 동기화에 필요한 시간을 방법론대로 확보하기가 사실상 어렵습니다. 필자는 KB국민은행 관련 프로젝트에서 설계와 문서화를 강하게 요구했지만, 구현 변경을 따라가지 못한 문서가 유지비만 드는 계륵으로 남는 사례를 여러 번 보았습니다. 이는 KB 전체의 공식 실패가 아니라 필자의 제한된 현장 경험입니다.
중요한 점은 그럼에도 문서화 시도를 포기하지 않았다는 사실입니다. 문서가 불필요해서 실패한 것이 아니라 문서를 살아 있게 유지할 관리시간을 예산과 일정에 포함하지 못했습니다. 문서량을 품질로 착각하는 형식주의와 시간이 없다는 이유로 추적성을 버리는 무관리 사이에서, 최소한의 살아 있는 증거를 선택해야 했습니다.
애자일과 Jira는 명세를 보이게 했지만 관리시간을 요구했다
2010년이 지나면서 간간히 회자되던 애자일 선언은 문서와 계획을 없애자고 하지 않습니다. 프로세스와 도구보다 개인과 상호작용, 방대한 문서보다 작동하는 소프트웨어, 계약 협상보다 고객 협업, 계획 고수보다 변화 대응에 더 높은 가치를 둔다고 말합니다. 국내 SI에서는 스프린트, 스크럼, 칸반이 계약형 폭포수 위에 부분적으로 얹힌 하이브리드가 많았습니다. 어찌보면 애자일을 주장하는 사람도 이 방법론을 채택한 고객도 그 정확한 의의를 설명하지 못하는 경우가 많았습니다.
문제는 “애자일”이 때때로 짧은 납기를 정당화하는 마케팅 용어가 됐다는 점입니다. 백로그를 정제할 시간도, 고객이 매주 판단할 권한도, 작은 릴리스를 운영에 내보낼 구조도 없는데 회의 이름만 데일리 스크럼으로 바꿨습니다.
관리의 문제와 프로젝트의 사후 비용이 폭발하는 것을 반복 경험한 시장에서 Jira 보드는 할 일과 진행 중, 완료를 선명하게 드러내는 X-Ray의 역할로 각광받았습니다. 그러나 Jira의 본질은 예쁜 칸반판이 아니라 이슈 유형, 상태, 담당자, 수용 기준, 선후관계, 완료 정의를 관리 스펙으로 만드는 데 있습니다. 이슈를 분해하고 백로그를 정제하며 증적을 연결하고 상태를 갱신하는 시간도 작업입니다. 이 공수를 WBS와 견적에서 빼면 Jira는 현실을 추적하는 도구가 아니라 회의 직전에 꾸미는 보고판이 됩니다.
과거 관리와 절차에 지쳐 애자일을 외치며 프로토타입을 만들기도 혹은 다시 Jira로 돌아가 상세한 관리도구를 들이밀던 시대의 경험은 오늘의 바이브 코딩과 스펙 기반 개발에서 되풀이 되는 듯 합니다. 바이브 코딩은 실행 결과를 빠르게 만들지만 요구·설계·회귀 기준이 약하면 후반 테스트의 위험이 커집니다. 스펙 기반 개발은 수용 기준과 추적성을 먼저 만들고 TDD를 결합해 안정성을 높일 수 있지만 분석·관리 시간이 필요합니다.
결국 안정성을 포기하지 못하는 현대 개발방법론이 더 점수를 주는 TDD는 작은 테스트-구현-리팩터링의 개발 주기이며 스펙 기반 개발 전체와 같은 뜻은 아닙니다. 스펙 기반 개발은 요구에서 설계, 코드, 테스트와 릴리스까지 더 넓은 관계를 관리합니다. 두 접근은 속도와 명시성 사이에서 소프트웨어 방법론이 반복해 온 선택입니다.
Git과 코드리뷰는 변경을 팀의 증거로 바꿨다
Git의 도입은 구현·테스트·이행의 비용 구조를 크게 바꿨습니다. 분산 저장소와 브랜치 덕분에 작업자는 독립적으로 변경을 만들고, pull/merge request에서 차이를 검토하며, main·staging과 태그로 릴리스 기준선을 남길 수 있게 됐습니다. Git의 역사가 강조하듯 분산과 비선형 개발은 협업 모델 자체를 바꿨습니다.
Git 자체가 CI/CD를 제공하는 것은 아닙니다. Git은 변경과 분기·병합의 이력을 제공하고, GitHub·GitLab 같은 호스팅과 자동화 플랫폼이 빌드, 테스트, 보안 검사, 환경 승인, 배포와 롤백을 실행합니다. GitHub의 지속 배포 문서는 환경 보호 규칙과 승인 게이트를 포함한 배포 흐름을 설명합니다.
코드리뷰도 개인의 코드를 팀의 지식으로 바꿨습니다. PR에는 무엇을 왜 바꿨는지, 어떤 테스트를 통과했는지, 누가 어떤 위험을 지적했는지가 남습니다. 좋은 리뷰는 스타일 논쟁보다 결함, 보안, API 호환성, 동시성, 데이터 이행과 운영 가능성을 먼저 봅니다.
새 병목도 생겼습니다. 너무 큰 PR, 형식적 승인, 리뷰 권력, 대기열이 속도를 늦춥니다. 자동화 검사와 동료 리뷰는 대체 관계가 아닙니다. 기계는 반복 가능한 규칙을 빠르게 검사하고, 사람은 변경 의도와 도메인 위험을 판단해야 합니다. 최근의 CodeRabbit AI PR 리뷰는 이 경계가 다시 이동하고 있음을 보여줍니다. AI가 없던 시절에는 결국 진정한 팀웍을 가능하게 만드는 대단한 도구가 나왔지만 여전히 시장에서 휴먼체크의 병목으로 인해 제 능력을 온전히 발휘하지는 못하는 모습을 자주 보았습니다.
현대 웹은 JSP 일변도의 시장을 여러 플랫폼으로 갈랐다
1부의 숙련·책임·피드백 문제가 해결될 때까지 모바일 시장은 기다려주지 않았습니다. 스마트폰과 태블릿, 웹 표준, Angular·React·Node 생태계가 확산되면서 서버에서 JSP를 렌더링해 한 채널에 제공하던 국내 시장은 여러 플랫폼으로 분화했습니다.
서버는 API 계약을 통해 웹, 모바일, 외부 파트너에 데이터와 업무 기능을 제공하기 시작했습니다. JPA는 객체·도메인 모델 중심 영속성 설계의 확산을 상징했습니다. 그러나 JPA를 사용한다고 도메인 설계가 자동으로 생기는 것은 아닙니다. OAuth는 비밀번호를 모든 서비스에 나누지 않고 권한을 위임하는 표준을 제공해 다채널 생태계의 연결 가능성을 높였습니다. 이는 성능 확장성과는 다른 의미입니다.
서버를 단순 데이터 컨테이너로만 보면 안 됩니다. 도메인 규칙, 트랜잭션, 권한, 감사, 외부 연계의 책임은 여전히 서버에 있습니다. 반면 프론트엔드는 화면 렌더링과 상태 관리를 서버 템플릿에서 분리해 백엔드 구현에 대한 직접 의존을 줄였습니다. 비동기 데이터 처리, 부드러운 전환, 애니메이션과 클라이언트 렌더링은 UI 품질을 높였습니다.
결과적으로 JSP 중심 화면 개발은 SPA, 모바일 네이티브·하이브리드, API 서버, BFF로 파편화·전문화됐습니다. 독립성은 커졌지만 API 버전, 계약 테스트, CORS, 토큰 보안, 분산 관측성, 프론트·백엔드 조직 조율이라는 새 관리비용도 생겼습니다. 웹 기술 변천사는 기술 목록이 아니라 책임 경계가 늘어난 역사이기도 합니다. 사실 관리비용의 증가는 고객채널의 다변화에 따른 추가비용을 의미합니다.
관리론의 발전과 강제된 현대화는 동시에 일어났다
국내 프로젝트 관리는 분명 발전했습니다. 실패는 요구사항과 테스트 기준으로 남았고, 잘못된 애자일의 용례로 인한 실패로 채택한 Jira는 작업을 선명하게 했으며, Git과 코드리뷰는 팀을 통합하며 조직원들의 변경을 통합된 재현 가능한 증거로 만들었습니다. 현대 웹은 백엔드와 프론트의 강한 결합을 끊어 내고 화면과 서버, 여러 매체의 독립성을 높였습니다.
그러나 1부의 문제는 사라지지 않았습니다. 짧은 일정, 부족한 교육시간, 문서와 구현의 불일치, 경계 업무의 책임 공백 위에 새 도구와 직군이 추가됐습니다. 방법론이 정교해질수록 사람이 관리해야 하는 정보와 관계도 늘었습니다. 예전에 없던 다양한 접근채널 역시 분화되었습니다.
이것이 국내 SI 프로젝트 관리가 축적한 역설입니다. 요구사항 문서화, Git 배포 자동화, 현대 웹 아키텍처는 각각 실패를 줄였지만 관리해야 할 관계도 늘렸습니다. 3부의 질문은 여기서 시작합니다. 요구사항, 화면, 디자인, 코드, 테스트, 배포의 관계가 너무 많아 사람이 끝까지 동기화하지 못했다면, 이 방대한 양을 동시에 읽고 갱신하는 AI는 프로젝트 관리의 단계를 어떻게 다시 결합할 수 있을까요.
댓글 없음:
댓글 쓰기