AI 시대, SI 업계 PM과 기획자를 위한 ‘새로운 개발 패턴’ 안내서: 현업에 바로 적용 가능한 실무 예시 중심 설명
AI 기술이 가져오는 개발 환경의 변화는 단순히 코드를 빠르게 작성하거나 테스트를 자동화하는 수준을 넘어, 시스템의 전반적인 설계 방식과 협업 모델, 요구사항 관리 방식에 이르기까지 전방위적인 재편을 요구하고 있습니다. 특히 SI 업계에서 활동 중인 PM(프로젝트 매니저)이나 기획자는 전통적인 역할에서 벗어나, AI와의 협업을 중심으로 한 새로운 개발자 패턴을 적극적으로 이해하고, 실무에 반영할 준비가 되어 있어야 합니다. 이 글에서는 a16z의 ‘AI 시대의 새로운 개발자 패턴’을 기반으로 하여, SI 업계 PM과 기획자를 위한 AI 기반 개발 협업 가이드로서 PM과 기획 실무자들이 실제 프로젝트에서 바로 적용 가능한 사례와 함께 9가지 핵심 변화 포인트를 자세히 설명 드리겠습니다.
전통적인 형상관리에서는 개발자가 작성한 코드의 버전 및 변경사항을 Git을 통해 관리하고, 그 커밋 로그를 바탕으로 기능의 구현 여부나 변경 범위를 파악하는 것이 일반적이었습니다. 하지만 AI가 코드를 대량으로 자동 생성하게 된 현시점에서는, 어떤 ‘프롬프트’가 코드의 출발점이 되었는지가 훨씬 더 중요해졌습니다. PM은 단순히 코드 변경 내역을 보는 것을 넘어서, 기능 구현의 ‘의도’와 그에 대한 ‘입력 텍스트(프롬프트)’를 추적하고 관리해야 합니다.
AI가 코드를 짜는 시대, 형상관리는 이제 ‘프롬프트’ 기준
예를 들어, 기존에는 “로그인 기능 추가”라는 요청을 받고, 그에 대한 커밋 이력을 확인하며 개발 여부를 판단했다면, 이제는 “로그인 기능 구현을 위한 프롬프트는 무엇이었는지, 어떤 테스트를 통과했는지”를 중심으로 관리해야 합니다. Git에서는 이제 코드뿐 아니라 프롬프트 로그, 테스트 스위트 결과가 함께 기록되고, 이 조합이 하나의 형상관리 단위가 됩니다.
즉, PM은 이제 요구사항 문서를 작성하는 것이 단순 명세가 아니라, ‘AI에게 전달할 프롬프트를 설계하는 일’임을 인식해야 합니다. 문장의 뉘앙스, 조건의 표현 방식 하나하나가 코드 품질에 직접적인 영향을 미치게 되는 시대입니다.
기존의 운영 대시보드는 다양한 KPI를 시각화하기 위해 복잡한 필터, 차트, 테이블로 구성되어 있어 실무자가 아닌 PM이나 기획자가 이해하고 활용하기 어려운 구조를 가지고 있었습니다. 보고서를 만들기 위해서는 GA나 BigQuery 같은 툴에 직접 접속하여 필터를 설정하고, 쿼리를 작성하거나 분석팀에 요청해야 했죠.
차트와 필터가 사라지는 대시보드, 이제는 AI에게 물어보세요
하지만 AI가 자연어 질의에 응답하여 실시간으로 데이터를 요약하고 설명하는 시대에서는 이런 방식이 점점 사라지고 있습니다. “어제 신규 가입자는 몇 명?”, “지난주 로그인 실패율은?” 같은 질문을 텍스트로 입력하면, AI가 데이터셋에서 직접 분석한 결과를 명확한 설명과 함께 제공합니다.
이를 위해 PM이 챙겨야 할 핵심은, 여전히 ‘데이터의 구조화’입니다. 아무리 강력한 AI라도, 구조화되지 않은 지표, 명확하지 않은 KPI 설정, 기준이 중복된 필드 등을 가지고는 정확한 답을 낼 수 없습니다. 따라서 초기 설계 단계에서 ‘무엇을 측정할 것인가’, ‘그 지표는 어떤 필드로 계산할 것인가’라는 메트릭 정의 작업이 필수입니다.
요구사항 문서가 ‘AI 에이전트를 위한 매뉴얼’로 바뀐다
기획자나 PM이 작성하는 요구사항 문서는 그 형식과 내용이 기존과는 완전히 달라지고 있습니다. 전통적으로는 기능 항목별로 필요한 입력, 출력, 조건 등을 구체적으로 기술하고, 이는 개발자에게 전달되어 코드 구현의 기준이 되었습니다. 그러나 AI가 요구사항을 기반으로 직접 코드를 생성하는 현재, 문서는 AI가 ‘이해할 수 있도록’ 설계되어야 합니다.
요구사항 문서가 ‘AI 에이전트를 위한 매뉴얼’로 바뀐다
자연어 기반의 명세서가 필요하며, 이 문서에는 단순 기능 설명을 넘어서 ‘왜 그런 기능이 필요한가’에 대한 의도, ‘어떤 상황에서 어떻게 동작해야 하는가’에 대한 시나리오, 그리고 그 결과에 대한 기대 효과까지 포함되어야 합니다.
예를 들어 단순히 “로그인 시 3회 실패하면 CAPTCHA 출력”이 아니라, “로그인 실패가 3회 이상일 경우, 자동화 공격 가능성이 있다고 판단하여 CAPTCHA를 출력하되, 정상 사용자의 UX를 해치지 않도록 로그인 버튼 아래 자연스럽게 나타나야 함”과 같이 기술해야 합니다.
템플릿 선택에서 벗어나, 원하는 기능을 말로 입력
기존에는 프로젝트를 시작할 때 어떤 프레임워크를 사용할지, 어떤 디렉토리 구조로 구성할지, 어떤 라이브러리를 연동할지를 먼저 결정하고 세팅한 후에 본격적인 개발에 들어갔습니다. 하지만 AI가 주도하는 개발 방식에서는, 기획자가 원하는 기능을 자연어로 설명하는 것만으로도 자동으로 프로젝트 구조가 세팅되는 시대가 왔습니다.
템플릿 선택에서 벗어나, 원하는 기능을 말로 입력
“재고 관리가 포함된 B2B 전용 쇼핑몰 어드민”이라고 입력하면, AI는 자동으로 Next.js 기반 프로젝트를 생성하고, 인증은 Clerk, DB는 Supabase, UI 프레임워크는 Tailwind 등으로 구성하여 초기화할 수 있습니다. 이로 인해 PM은 기술 스택 결정에서 자유로워지고, ‘기능 조합 중심’의 사고방식으로 전환하게 됩니다.
중요한 것은, 어떤 기능이 필요하고, 사용자에게 어떤 흐름을 제공하고자 하는지를 명확히 설명할 수 있는 능력입니다. 즉, 더 이상 템플릿이나 레퍼런스를 찾는 대신, 목적 중심의 요구를 정확히 기술하는 것이 중요한 시대가 되었습니다.
.env 파일 대신, AI가 필요한 인증만 가져간다
기존에는 개발 환경 설정을 위해 .env 파일에 DB 연결 주소, API 키, 인증 토큰 등을 저장하고, 이를 통해 시스템이 외부 서비스와 연동되도록 했습니다. 그러나 이 방식은 실수로 소스코드와 함께 업로드되었을 때 보안 문제가 생기기 쉬웠습니다.
.env 파일 대신, AI가 필요한 인증만 가져간다
AI 기반 개발 방식에서는, 에이전트가 특정 기능 실행에 필요한 ‘제한 권한 토큰’만을 받아서 사용하는 방식으로 전환되고 있습니다. 예를 들어 “결제 기능을 사용하되, 금액 변경은 불가”와 같은 식으로 세분화된 권한을 설정한 토큰을 AI에게 전달함으로써, 보안 사고의 위험을 현저히 줄일 수 있습니다.
PM이 설계 단계에서 고려할 사항은 다음과 같습니다. 첫째, API 키 전달 방식은 파일 기반이 아닌 토큰 기반으로 전환되어야 하며, 둘째, 각 기능별로 에이전트에게 어떤 권한을 부여할 것인지 명확히 정의하는 ‘권한 범위 모델’을 수립해야 합니다.
접근성 기능이 ‘AI 에이전트의 눈’이 된다
과거 macOS나 Windows에서의 접근성 기능은 주로 장애인을 위한 화면 읽기, 키보드 네비게이션 같은 보조적 기능이었습니다. 그러나 AI가 UI를 제어할 수 있도록 하는 새로운 방식에서는, 접근성 API가 ‘에이전트의 눈’이 됩니다.
접근성 기능이 ‘AI 에이전트의 눈’이 된다
예를 들어 Granola 같은 툴은 macOS의 접근성 API를 활용하여 AI가 UI의 버튼, 리스트, 폼 등을 파악하고 조작할 수 있게 만듭니다.
기획자가 해야 할 일은 단순합니다. UI 요소들을 시멘틱하게 구성하는 것입니다. 버튼은 button, 링크는 a, 제목은 h1~h3 등 명확하게 정의하고, 각 컴포넌트에 의미 있는 네이밍을 부여함으로써, AI가 이를 탐색하고 인지할 수 있도록 만들어야 합니다.
동기식 협업에서 비동기 ‘요청-응답’ 협업으로
기존 협업 방식은 대부분 실시간 의사소통을 기반으로 했습니다. PM이 구두나 문서로 개발자에게 요청을 전달하고, 개발자는 이를 구현한 후 결과를 공유하는 구조였습니다. 하지만 AI와 협업하게 되면서, 슬랙에 남긴 한 줄 메시지가 자동으로 코드로 반영되고, Figma에 남긴 코멘트가 곧바로 UI 스타일에 적용되는 등, 요청-응답 구조의 비동기 협업 방식이 주류가 되고 있습니다.
PM의 역할은 이제 ‘작업을 지시하는 관리자’가 아니라, ‘작업 흐름 전체를 기획하고 조율하는 오케스트레이터’로 변화합니다. 각 도구 간 통합 방식, 요청 방식의 표준화, 결과의 검증 흐름 등을 설계하는 것이 PM의 핵심 업무가 됩니다.
도구 간 통합을 위한 새로운 표준: MCP
기존에는 서로 다른 시스템이나 SaaS 툴 간 연동을 위해, 각각의 API 명세서를 참고하고 직접 통신 코드를 작성해야 했습니다. 하지만 MCP(Model Context Protocol) 방식에서는, AI 에이전트가 자연어로 툴에게 요청을 보내면, 툴 내부의 MCP 스펙에 따라 자동으로 응답을 처리합니다.
예를 들어 “신규 가입자는 프로 요금제에 자동 등록하고, 일주일 후 이메일을 발송해줘”라는 문장이 MCP 인터페이스를 통해 전송되면, 각 도구가 알아서 이를 해석하고 실행하게 됩니다. PM 입장에서는 기술적 디테일에 얽매이지 않고, 전체 워크플로우를 기획하는 데 집중할 수 있는 환경이 마련된 것입니다.
인증, 결제, 저장소 같은 기능은 ‘추상화된 블록’이 된다
마지막으로, 기존에는 인증 시스템을 직접 개발하거나 외부 솔루션을 수동으로 연동해야 했습니다. 하지만 AI 에이전트가 필요한 기능을 자동으로 연결하는 시대에서는, 인증은 Clerk, 결제는 Stripe, DB는 Supabase로 ‘추상화된 기능 블록’처럼 자동 구성됩니다.
기획자의 역할은 이런 블록들을 이해하고, 어떤 기능이 필요한지를 명확히 정의하는 것입니다. “회원가입 후 자동 결제까지 이어지는 흐름이 필요하다”는 요구만으로도, 관련 블록들이 자동으로 연결됩니다. 따라서 다양한 SaaS의 기능, 한계, 연동 포인트 등을 깊이 있게 이해하는 것이 중요합니다.
정리하며: SI PM/기획자의 역할은 이렇게 변합니다
정리하며: SI PM/기획자의 역할은 이렇게 변합니다
기존 역할
변화된 역할
기능 상세 명세 정리
사용자/시스템의 의도 정의
개발 일정 조율
AI와의 협업 구조 설계
코드 검토·요구
테스트 기준 정의 및 결과 검증
개발자-디자이너 연결
작업 오케스트레이션과 맥락 공유
시스템 보안 설계
에이전트 권한과 시크릿 모델 설계
맺음말: AI 시대, PM과 기획자의 ‘새로운 언어’를 배워야 할 때
지금까지 SI 업계 PM과 기획자를 위한 AI 기반 개발 협업 가이드 로서 PM과 기획 실무자들이 실제 프로젝트에서 바로 적용 가능한 사례와 함께 9가지 핵심 변화 포인트를 자세히 설명 드렸습니다.
AI가 단순한 도구나 보조 수단을 넘어, 실제 개발 파트너로 자리 잡고 있는 지금, PM과 기획자의 역할 또한 근본적으로 바뀌고 있습니다. 단지 기술 트렌드에 따라가는 수준이 아니라, 실질적인 ‘협업 대상’이 변화하고 있는 셈입니다. 이제 PM은 사람이 아니라 AI에게 요청서를 작성해야 하며, 코드가 아니라 프롬프트를 설계해야 하고, 일정 관리보다는 흐름과 의도를 조율하는 역할이 중심이 됩니다.
기획자는 더 이상 개발자의 손을 빌려 기능을 구현하는 사람이 아니라, AI에게 정확한 목적과 문맥을 전달해 원하는 결과를 끌어내는 ‘설계자’이자 ‘조율자’가 되어야 합니다. 이 과정에서 문서 작성 방식, 회의 방식, 도구 선택 기준, 데이터 구조화 능력 등 전방위적인 역량이 재편되고 있습니다.
이 글에서 소개한 9가지 변화는 단순한 유행이나 이론이 아닙니다. 이미 실무에 빠르게 녹아들고 있으며, AI 도구를 도입한 프로젝트에서 하나씩 현실화되고 있는 흐름입니다. 따라서 지금 이 시점에서 PM과 기획자가 해야 할 일은 분명합니다. 기존의 틀을 벗고, AI 시대의 문법과 도구에 익숙해지는 것. 그리고 팀과 함께 그 변화를 적극적으로 이끄는 것입니다.
더 이상 ‘기능 설명서’만 잘 쓰는 기획자가 아니라, ‘AI와 협업하는 방법을 아는 설계자’로 성장해 보세요. 그것이 AI 시대의 SI 기획자와 PM이 가져야 할 진짜 경쟁력입니다.
FAQ: PM과 기획자를 위한 AI 기반 개발 협업 관련 자주 묻는 질문
Q1. 이 글은 어떤 직무를 대상으로 하나요?
A1. 이 글은 SI 업계에서 활동 중인 PM(프로젝트 매니저)과 기획자 직군을 주요 대상으로 합니다. 특히 AI 기반 도구나 개발 환경 변화에 따라 실무 방식에 적응해야 하는 중급 이상 실무자에게 적합합니다.
Q2. 왜 프롬프트가 중요한 형상관리 기준이 되었나요?
A2. AI가 실제 코드를 생성하게 되면서, 어떤 ‘프롬프트’를 기반으로 코드가 만들어졌는지가 기능 구현의 핵심 단서가 됩니다. 이는 기존의 커밋 로그나 버전 관리와는 다른 새로운 추적 방식으로, 요구사항 문서가 곧 코드 품질을 좌우하는 중요한 입력이 됩니다.
Q3. AI 대시보드는 기존 차트 기반 대시보드와 어떻게 다른가요?
A3. AI 대시보드는 사용자가 자연어로 질문하면 데이터를 요약하고 해석해서 리포트를 제공하는 방식입니다. 더 이상 복잡한 필터나 그래프를 조작하지 않아도, 실시간으로 KPI를 확인하고 분석할 수 있어 실무 속도와 이해도를 높입니다.
Q4. 기존 기획 문서와 AI 시대의 명세서는 어떤 차이가 있나요?
A4. 기존 문서는 사람이 이해하기 쉬운 기능 중심의 문서였다면, AI 명세서는 ‘의도 중심’, ‘시나리오 중심’으로 작성되며 자연어로 AI가 이해할 수 있어야 합니다. 예외 처리, 사용자 흐름, 조건 등을 명확히 기술하는 것이 핵심입니다.
Q5. PM이 기술 스택을 몰라도 되는 시대가 정말 올까요?
A5. AI가 프로젝트 구조를 자동 생성해주는 만큼, 기술 스택에 대한 깊은 이해가 없어도 기능 중심의 설명만으로 프로젝트가 시작될 수 있습니다. 하지만 주요 SaaS 도구(예: Supabase, Clerk, Stripe 등)에 대한 개념은 알고 있어야 효율적인 설계가 가능합니다.
Q6. AI는 보안을 어떻게 다루나요? API 키는 안전한가요?
A6. 기존처럼 .env에 직접 API 키를 저장하기보다는, AI 에이전트가 ‘기능 단위 권한 토큰’을 받아 필요한 범위만 접근하는 방식으로 보안 수준이 높아졌습니다. PM은 기능별 권한 범위 설계를 명확히 정의해야 합니다.
Q7. Granola 같은 접근성 기반 툴은 무엇을 하나요?
A7. Granola는 macOS의 접근성 API를 활용해 AI가 UI를 ‘읽고 조작’할 수 있도록 돕는 툴입니다. 이는 단순한 사용자 보조 기능을 넘어서, AI가 앱을 제어하는 인터페이스로 진화하고 있으며, UI 구성에 시멘틱한 설계가 필요합니다.
Q8. 슬랙이나 피그마에 남긴 메시지가 실제 코드로 반영되나요?
A8. 네. 요즘 도입되는 AI 워크플로우에서는 슬랙 메시지나 피그마 코멘트가 백그라운드에서 AI 작업으로 전환되며, 자동 코드 수정 및 PR 생성까지 이어질 수 있습니다. 요청은 간단하지만, 실행은 자동화되어 생산성을 높입니다.
Q9. MCP는 무엇이고, 왜 중요한가요?
A9. MCP(Modular Command Protocol)는 다양한 SaaS 도구와 AI가 자연어 명령을 통해 연동되는 프로토콜입니다. 덕분에 기획자가 기술 지식 없이도 복잡한 연동 흐름을 직접 설계하고 운영할 수 있습니다.
Q10. 앞으로 기획자나 PM이 가장 중점적으로 배워야 할 역량은?
A10. 가장 중요한 것은 ‘AI에게 정확하게 전달하는 커뮤니케이션 능력’입니다. 즉, 프롬프트 설계 역량, 요구사항을 자연어로 구조화하는 능력, 그리고 다양한 SaaS 기능을 조합해 서비스 흐름을 설계하는 전략적 사고가 핵심입니다.
