AI 팀은 어떻게 일해야 할까?

Part 2. 제품 팀의 역할과 개발 과정의 재구성

Apr 28. 2025

~Part 2. 핵심 요약

- AI 제품은 더 유연하고, 더 병렬적인 실험 구조로 만들어져야 한다.
- PM은 AI의 가능성을 스스로 체험하며 탐색하는 사람이 되어야 한다.
- 빠르게 테스트하고, 사용자 반응을 배우는 루프가 AI 제품을 성장시키는 가장 확실한 방법이다.

제품 개발 방식은 시대에 따라 변해왔다.

한때는 워터폴(Waterfall) 방식이 주류였다. 명확한 요구사항을 문서화하고, 설계·개발·테스트가 순차적으로 이뤄지는 구조였다. 안정성과 예측 가능성을 추구하는 데 강점이 있었다.

그러나 기술은 더 복잡해지고, 시장은 더욱 예측할 수 없게 변했다. 이에 대응하기 위해 애자일(Agile) 방식이 등장했고, 특히 스크럼 기반의 목적 중심 조직은 사용자 중심의 문제 해결을 위한 빠른 실행과 팀 간 경계를 허무는 유연한 협업 구조를 만들어냈다.

하지만 AI 제품을 다루기 시작하면서, 이마저도 다시 경계에 다다랐다. AI 제품은 사전에 정의할 수 없는 불확실성을 품고 있다.

사용자 입력이 매번 달라지고,

모델의 반응 역시 항상 예측할 수 없다.

특히 생성형 AI 시스템은 단순 기능 구현을 넘어, 실시간 반응하고, 사용자 맥락에 따라 추론하며, 지속적으로 학습하는 특성을 지닌다. 이로 인해 기획부터 개발까지의 전체 프로세스는 더 유기적이고 실험 중심적인 구조로 재편되어야 한다.

1. 병렬적인 팀 구조, 문제를 함께 보는 팀

전통적인 제품 팀은 기능적으로 역할이 분리되어, 기획자, 디자이너, 개발자, QA가 순차적으로 작업을 이어가는 구조였다. 이 방식은 안정성과 예측 가능성이 중요한 시대에는 유효했다.

하지만 생성형 AI 제품에서는 이런 '선형적' 협업이 쉽게 한계에 부딪힌다. 프롬프트 하나만 수정해도 UI, UX, 프론트엔드 구현, 테스트 플로우까지 연쇄적으로 영향을 받는다.

프론트엔드 개발자는 모델의 응답 속도나 구조에 맞춰 화면 로딩 방식을 수정해야 할 수도 있고,

디자이너는 예측하지 못한 응답 패턴에 맞춰 화면 구조를 새롭게 설계해야 할 수도 있으며,

QA는 명확한 테스트 케이스 대신, 예상치 못한 시나리오를 가정해 검증해야 할 수 있다.

이처럼 AI 제품은 모든 요소가 유기적으로 연결된 시스템이다. 미세한 수정이 AI의 응답 품질뿐 아니라 제품의 전체 경험에까지 영향을 미칠 수 있기 때문에, 더 이상 역할별로 분리된 선형적 프로세스로는 효율적인 대응이 어렵다. 따라서, 문제를 중심으로 모든 팀이 함께 보고, 함께 실험하며, 실시간으로 조정하는 병렬적 협업 구조가 필요하다.

여기서 말하는 '함께 본다'는 것은 단순히 회의만 자주 한다는 뜻이 아니라, 문제 정의, 실험 설계, 결과 해석까지 모든 과정을 팀 전체가 일관된 맥락 안에서 함께 바라보고 해석하는 것을 의미한다.

2. PM의 새로운 역할: 가능성의 탐색자

AI 제품에서는 PM의 역할도 자연스럽게 달라진다.

더 이상 기능 명세를 작성하고, 그 구현을 관리하는 역할에 그칠 수 없다. AI 제품은 예측 가능한 출력이 보장되지 않고, 입력과 맥락에 따라 반응이 매번 달라진다. 이로 인해 기획과 실행의 경계는 자연스럽게 흐려지고, 그 자리를 실험과 탐색이 채우게 된다.

물론 모든 PM이 완전히 새로운 방식으로 일해야 한다는 뜻은 아니다. 다만 생성형 AI와 같은 기술이 제품의 중심에 놓이는 순간, PM은 사용자 문제와 AI의 역량(capability) 사이에서 의미 있는 접점을 찾는 ‘가능성의 설계자’가 되어야 한다.

PM은 직접 체험을 통해 AI의 가능성을 좁혀가야 한다:

프롬프트 실험으로 AI의 특성과 한계를 경험하고, 어떤 입력 구조가 더 나은 반응을 이끄는지 이해한다.

사용자 시나리오를 구성하고 반복적으로 검증하면서, 사용자의 기대와 AI의 반응 간 간극을 좁힌다.

실험 결과와 사용자 피드백을 축적해 가며, 제품의 신뢰성과 사용자 경험을 점진적으로 개선한다.

더 이상 기능을 중심으로 설계하는 방식이 아니라, AI가 작동할 수 있는 문제 공간을 정의하고, 실험을 통해 그 가능성을 좁혀가는 탐색적 접근이 필요하다. 그리고 그 과정은 완벽함을 추구하는 일이 아니라, 불완전함 속에서 어떤 인사이트를 얻어낼지를 설계하는 일이다.

이 변화는 PM이라는 직무 자체가 바뀐다는 뜻이 아니다. AI라는 기술의 특성에 따라 PM이 집중해야 할 중심축이 이동하고 있다는 신호에 가깝다.

3. 개발 프로세스는 빠른 실험 루프로

팀 구조가 병렬적으로 변했다면, 이제 실제 일하는 방식, 즉 개발 프로세스도 달라져야 한다.

생성형 AI는 같은 입력이라도 맥락이나 온도(temperature), 사용자 이력 등에 따라 다른 응답을 생성한다. 완벽한 설계나 계획만으로는 이 변동성과 불확실성을 다룰 수 없다.

AI 제품에서는 빠르게 가설을 세우고 실험하며 반영하는 — 짧은 피드백 루프가 제품 성공의 핵심이 된다.

예를 들어:

프롬프트 구조별로 결과 품질을 비교하고,

사용자 반응(만족도, 오류율 등)을 즉각 수집하며,

이 데이터를 기반으로 바로 다음 실험이나 수정 방향을 잡는다.

빠른 실험과 순환이 단순한 개발 '속도'를 위한 게 아니다. 빠른 사용자 반응 확인이 곧, AI 제품에서 불확실성을 통제하고 줄여나갈 수 있는 거의 유일한 방법이다.

생성형 AI 제품은 ‘무엇을 만드는가’뿐만 아니라, ‘어떻게 만드는가’까지도 게임의 규칙이 다르다.

AI 제품은 본질적으로 예측 불가능성을 품고 있다. 이런 특성 속에서 PM은 AI의 가능성과 한계를 실험으로 좁혀가는 설계자이자, 팀이 불확실성 속에서도 빠르게 학습하고 적응할 수 있도록 돕는 촉진자가 되어야 한다. 모든 것을 통제하려는 완벽한 기획보다 중요한 건, 실험을 통해 무엇을 발견하고 학습할 수 있느냐다.