시리즈 · AI 시대의 프로젝트 관리론
3회 · AI 시대의 프로젝트 관리론 3 - 병목을 없애는 프로젝트 AI
AI 시대의 프로젝트 관리론 3 - 병목을 없애는 프로젝트 AI
AI 시대의 프로젝트 관리론 마지막 글은 전통적 단계와 현대화된 도구를 하나의 AI 피드백 루프로 다시 연결합니다. 2부까지 살펴본 방법론의 병목은 각 방법이 틀려서라기보다 사람이 처리하고 변환해야 할 정보의 양이 너무 많다는 데 있었습니다.
수백·수천 개 요구사항을 취합·분석·추적하고, 화면설계로 바꿔 기획자와 업무담당자의 승인을 받고, 다시 디자인 파일과 HTML로 옮기고, 개발자가 기능을 입히고, 테스트 결과를 요구사항에 되돌려 연결했습니다. 매 단계에서 같은 의도가 다른 형식으로 복제됐고 기다림, 해석 차이와 버그가 누적됐습니다.
AI는 이 “양의 장벽”을 처음 정면에서 무너뜨리는 기술입니다. 모호하고 저해상도인 요구를 구조화하고 방대한 관계를 추적하며 화면, 디자인, 코드, 테스트 초안을 연속 생산할 수 있습니다. 이 글은 필자가 실제로 운영하는 파이프라인을 기준으로 이미 대체된 생산·변환·추적의 범위와, 인간에게 남는 의미·위험·수용의 판단을 구분합니다.
소프트웨어 개발의 병목은 정보량과 변환 횟수였다
현대 방법론은 실패를 줄이기 위해 더 많은 증거를 요구했습니다. 요구사항 ID, 추적행렬, 화면 상태, 디자인 시스템, API 계약, 테스트 케이스, PR 리뷰, 배포 기록과 관측성은 모두 필요합니다. 그러나 통제가 늘수록 관리해야 할 관계도 늘었습니다.
| 병목 | 사람이 반복하던 변환 | 대표 손실 |
|---|---|---|
| 요구사항 | 회의·RFP·매뉴얼을 요구 ID와 수용 기준으로 변환 | 누락, 충돌, 최신본 혼선 |
| 화면설계 | 업무 요구를 화면·상태·사용자 흐름으로 변환 | 컨펌 대기, 정상 흐름 편향 |
| 디자인·퍼블리싱 | 화면설계서를 디자인 파일과 HTML/CSS로 재작성 | 중복 노동, 해석 차이 |
| 구현 | 화면과 API에 도메인 규칙·오류·권한을 결합 | 불일치, 버그, 재작업 |
| 테스트 | 실행 결과를 요구와 결함·릴리스 증거로 역추적 | 반복 실행, 고아 테스트 |
AI의 혁명성은 한 문서를 빨리 요약하는 데 있지 않습니다. 텍스트, 화면, 코드, 테스트와 운영 증거의 관계를 같은 컨텍스트에서 읽고 함께 갱신하는 데 있습니다. 인간은 요구사항 1,000개의 링크를 계속 기억할 수 없지만 기계는 식별자와 변경 그래프를 반복 검사할 수 있습니다.
필자는 Claude Design과 Stitch 수준의 일반 업무화면 목업·와이어프레임이 이미 인간 실무 수준에 도달했고, 반복 생산 업무에서는 숙련도 하위 약 60%의 결과를 대체할 수 있다고 평가합니다. 이 수치는 벤치마크가 아니라 필자의 결과물 비교입니다. 브랜드 전략, 사용자 연구, 독창적 상호작용을 포함한 상위 디자인 전체가 사라졌다는 뜻은 아닙니다.
개발 구현은 필자의 현재 프로젝트 범위에서는 이미 100% AI 수행이 가능합니다. 여기서 100%는 산업 전체 개발자 대체율이 아니라 필자가 코드를 직접 타이핑하지 않고 SPEC, 에이전트, 테스트와 리뷰로 결과를 만드는 작업 방식입니다. 기존 MoAI ADK 분석에서 설명했듯, 핵심은 모델에게 모든 자유를 주는 것이 아니라 저장소의 지식·계약·실행·검증을 하네스로 묶는 데 있습니다.
요구사항에서 프로토타입까지가 하나의 대화가 된다
과거에는 RFP와 회의록을 분석한 뒤 요구사항 정의서를 만들고, 화면 목록과 화면설계서를 만들고, 디자이너가 Figma로 옮기고, 퍼블리셔가 HTML을 만든 뒤에야 사용자가 움직이는 결과를 봤습니다. 잘못 이해한 요구를 발견하는 데 몇 주가 걸릴 수 있었습니다.
텍스트 LLM은 입력 자료를 정규화하고 중복·충돌을 찾으며, 기능·비기능 요구를 나누고 수용 기준과 질문 목록을 만들 수 있습니다. 중요한 것은 자동 생성 문서의 양이 아니라 양방향 추적입니다. 요구가 바뀌었을 때 관련 화면, API, 도메인 규칙, 테스트와 릴리스를 함께 표시해야 합니다.
Claude Design은 대화형 화면 제작, 팀 공동 편집, 디자인 시스템과 웹 캡처를 한 작업 공간에 묶는 방향을 보여줍니다. Google Stitch는 텍스트나 이미지로 UI를 만들고 디자인·개발 도구로 넘기는 흐름을 제시합니다. Google은 이후 Stitch 결과를 AI Studio와 Antigravity 같은 개발 도구로 연결하는 방향도 소개했습니다.
Google Antigravity는 에이전트가 에디터, 터미널과 브라우저에서 계획·실행·검증하는 개발 플랫폼입니다. Stitch와 Antigravity는 하나의 제품이 아닙니다. 전자는 UI 생성과 디자인 흐름, 후자는 에이전트 기반 개발 실행에 가깝습니다. 중요한 변화는 요구를 본 사람과 실행 결과를 본 사람이 더 이상 몇 단계 떨어져 있지 않다는 점입니다.
프로토타입은 운영 가능한 제품이 아닙니다. 빈 상태, 로딩, 오류, 권한 없음, 중복 제출, 타임아웃, 접근성, 개인정보와 감사 요구까지 검증해야 합니다. 하지만 사용자와 기획자, 디자이너, 개발자가 같은 움직이는 화면을 보며 결정 로그를 남기면 문서 회람보다 피드백이 훨씬 빨라집니다.
필자가 운영하는 1인 AI 프로젝트 파이프라인
필자는 요구사항 분석부터 실행 가능한 프로토타입까지 다음 흐름을 하나의 저장소 파이프라인으로 운영합니다.
- RFP, 회의록과 현행자료에서 요구사항·용어·미결정 질문을 구조화합니다.
- 기능 목록과 화면 상태를 만들고 Claude Design으로 와이어프레임을 검증합니다.
- 필요한 경우 Figma 또는 Stitch로 디자인 핸드오프를 수행합니다.
- 품질속성과 배포환경을 포함한 아키텍처를 설계합니다.
- 도메인 경계, 불변식, 상태 전이, 권한과 실패 의미를 정의합니다.
- MoAI로 도메인 분석을 SPEC화하고 완료 조건과 변경 파일, 테스트를 연결합니다.
- 에이전트가 구현하고 자동 테스트·정적 분석·리뷰를 반복합니다.
- 실행 가능한 미리보기에서 이해관계자가 수용 여부를 판단하고 피드백을 요구사항으로 되돌립니다.
도구 이름을 나열하는 것만으로 파이프라인이 되지는 않습니다. REQ-117이 UI-023, 도메인 정책 POL-08, API-014, TC-308, PR과 릴리스까지 이어져야 합니다. 어느 단계에서 실패하면 코드만 고치는 것이 아니라 잘못된 요구나 설계 결정으로 되돌아가야 합니다.
이 사례를 조직 전체의 생산성 통계로 일반화할 수는 없습니다. 필자는 도메인과 아키텍처를 설계하고 결과를 검증할 경험이 있으며, 작은 의사결정 체계를 혼자 통제합니다. 대규모 조직에서는 규제 승인, 직무 분리, 데이터 접근권한과 다수 이해관계자의 결정 시간이 남습니다. 그럼에도 한 사람이 과거 여러 직군의 초안 생산과 동기화를 운영할 수 있게 됐다는 사실은 역할 경계가 크게 변했음을 뜻합니다.
설계부터 이행까지는 AI와 Git의 증거 파이프라인이 된다
AI가 빨리 만드는 것만으로 프로젝트는 완성되지 않습니다. 생성 결과가 SPEC, 코드, 테스트, 인프라 설정, 릴리스 노트, 배포·롤백 기록과 버전으로 연결돼야 합니다. Git은 이 증거의 시간축을 제공합니다.
PR마다 타입·정적 분석, 단위·계약·회귀 테스트, 의존성과 보안 검사, AI 코드리뷰, 미리보기 환경 배포를 단계화할 수 있습니다. CodeRabbit 문서는 PR 요약, 잠재 결함·보안·품질 분석과 새 커밋에 대한 증분 리뷰를 설명합니다. CodeRabbit AI PR 리뷰를 실제로 쓸 때도 확률적인 리뷰 제안과 결정적 검사를 구분해야 합니다.
정적 분석과 테스트는 정의된 규칙과 입력에서 재현 가능한 결과를 냅니다. AI의 검토 결과는 저장소 문맥을 폭넓게 해석하지만 확률적이며 틀릴 수 있습니다. 따라서 “CodeRabbit을 통과했다”가 품질 보증의 전부가 아니라, 어떤 테스트와 보안 규칙, 인간 승인이 함께 있었는지를 봐야 합니다.
운영 TA의 지식 장벽도 크게 낮아졌습니다. Git 작업, CI/CD, 로그·메트릭·트레이스, 대시보드·경보, WAS·DB 설정과 진단 초안을 AI가 설명하고 생성할 수 있습니다. 필자의 업무에서는 TA 지식에 접근하고 구현하는 진입장벽이 사실상 제거됐습니다.
그러나 권한, 보안, 비용, SLO, 용량과 장애 지휘 책임까지 사라진 것은 아닙니다. 망 분리와 개인정보, 레거시가 있는 금융·공공 환경에서는 승인과 독립 검증이 더 중요합니다. AI가 잘못된 명령도 빠르게 실행할 수 있으므로 작은 가역적 변경, 최소 권한, 승인 게이트, 감사와 롤백이 필수입니다. AWS 운영 우수성 원칙이 강조하는 관측, 작은 변경과 운영 준비는 AI 시대에도 유효합니다.
자동 검증 이후 마지막 병목은 인간의 수용이다
자동화할 수 있는 검증은 계속 늘어납니다. 문법과 타입, 정적 분석, 단위·계약·회귀 테스트, 알려진 보안 규칙, PR 초벌 리뷰, 배포와 롤백 기록은 파이프라인에 넣을 수 있습니다. 그 뒤에도 “이 시스템이 실제 업무에 맞는가”라는 질문은 남습니다.
사람은 업무 의미, 사용자 만족, 예외가 합리적인지, 법과 정책을 어떻게 해석할지, 어떤 위험을 받아들일지, 운영팀이 실제로 복구할 수 있는지를 판단합니다. UAT를 문자 그대로 유일하게 남은 테스트라고 할 수는 없습니다. 탐색 테스트, 접근성, 규제 검증, 복구 리허설도 필요합니다. 다만 자동 검사 이후 최종 업무 수용은 AI가 가장 대체하기 어려운 책임입니다.
코드가 실행된다는 사실과 사용자가 원하는 업무가 완성됐다는 사실은 다릅니다. 대표 사용자가 현실 데이터와 실패 시나리오로 사용하고, 결과를 인수하며, 누가 위험을 소유할지 서명해야 마지막 간극이 닫힙니다.
인간이 만든 방법론은 AI의 속도에서 비로소 꽃을 피운다
요구사항 관리, 추적성, 설계 표준, TDD, 코드리뷰, CI/CD와 관측성은 인간이 실패를 겪으며 만든 지식입니다. 국내에서는 짧은 일정과 방대한 관리량 때문에 사람의 손만으로 모든 문서·코드·테스트를 끝까지 동기화하기 어려웠습니다. “모두 실패했다”는 말은 방법론이 무가치했다는 뜻이 아니라 인간의 시간과 인지력만으로 완전하게 실행하기 어려웠다는 뜻입니다.
AI는 그 방법론을 폐기하지 않습니다. 오히려 요구, 화면, 코드, 테스트와 운영 증거를 빠르게 함께 갱신함으로써 과거의 이상을 실행 가능하게 만듭니다. 사람이 만든 관리론이 AI의 처리속도를 만나 비로소 꽃을 피우는 모양새입니다.
앞으로는 요구사항 수집, 프로토타입, 아키텍처·도메인 설계, 구현, 테스트, 배포와 관측을 하나의 프로젝트 AI 에이전트가 연결할 가능성이 큽니다. 현재 완성된 단일 제품이 있다는 뜻은 아닙니다. Claude Design, Stitch, Antigravity, MoAI, Git과 검증 도구가 보여주는 통합 방향에 대한 전망입니다.
개발 분야 IT 전문가의 핵심 역량도 이동합니다. 모든 산출물을 직접 생산하는 속도보다 AI가 프로젝트를 어떻게 수행하는지, 무엇을 근거로 결정했는지, 어디에서 실패하는지, 어떤 증거가 있어야 결과를 인수할 수 있는지를 이해하는 능력이 중요해집니다. 하네스 엔지니어링과 프로젝트 수행력은 개발자의 부가 역량이 아니라 기본 역량이 될 것입니다.
결국 AI 프로젝트 관리의 핵심은 요구사항 자동화와 AI 코드리뷰를 따로 도입하는 데 있지 않습니다. 두 흐름을 설계·구현·배포 증거와 연결하고 마지막 휴먼 수용 테스트에서 업무 의미를 인수하는 데 있습니다. AI 시대의 프로젝트 관리는 단계를 지우는 일이 아닙니다. 인간이 만든 방법론 전체를 AI의 속도로 실행하고, 자동화의 경계와 인간의 승인점을 설계하는 일입니다.
댓글 없음:
댓글 쓰기