AI가 구현하는 시대, 기획자와 개발자는 어떤 관계가 되어야 할까?

AI 시대의 기획자와 개발자는 요구사항을 전달하고 구현물을 납품하는 관계가 아니다. 서로 다른 불확실성을 줄이면서 제품의 결과를 함께 책임지는 파트너다.

AI는 기획과 개발의 풍경을 동시에 바꾸고 있습니다.

기획자는 자연어만으로 화면과 프로토타입을 만들 수 있습니다. 개발자는 AI 코딩 에이전트를 이용해 여러 파일을 수정하고, 테스트를 실행하며, 오류를 고칠 수 있습니다. 과거라면 며칠이 걸렸을 시제품을 몇 시간 만에 만드는 일도 가능해졌습니다.

표면적으로 보면 기획자와 개발자 사이의 거리가 빠르게 줄어드는 것처럼 보입니다.

기획자가 직접 구현할 수 있고 개발자도 요구사항과 화면 흐름을 빠르게 구성할 수 있다면, 둘의 역할을 굳이 나눌 필요가 있을까요?

반대로 이런 질문도 생깁니다.

기획자가 AI로 동작하는 화면을 만들었으니 개발자는 그대로 제품화하면 되는 것일까요? AI가 코드를 대부분 작성한다면 개발자는 기획자의 요청을 실행하는 운영자에 가까워지는 것일까요?

제 생각은 다릅니다.

AI는 기획자와 개발자 중 한쪽을 불필요하게 만드는 것이 아니라, 두 역할 사이에 있던 문서 전달 중심의 관계를 공동 판단 중심의 관계로 바꾸고 있습니다.

AI가 구현 속도를 높일수록 무엇을 만들지, 어디까지 자동화할지, 어떤 실패를 허용할지, 실제 서비스로 운영해도 되는지를 함께 판단하는 일이 더 중요해지기 때문입니다.

따라서 AI 시대의 관계는 다음 문장으로 정리할 수 있습니다.

기획자는 사용자와 사업의 불확실성을 줄이고, 개발자는 기술과 운영의 불확실성을 줄이며, 두 사람은 제품의 실제 결과를 공동으로 책임진다.

기존의 역할 구분이 흔들리고 있다

전통적으로 기획자와 개발자의 역할은 비교적 단순하게 설명됐습니다.

• 기획자는 무엇을 만들지 정합니다.

• 개발자는 그것을 어떻게 만들지 정합니다.

업무 흐름도 대체로 순차적이었습니다.

1. 기획자가 시장과 사용자를 조사합니다.

2. 요구사항과 화면 설계서를 작성합니다.

3. 개발자에게 문서를 전달합니다.

4. 개발자는 일정과 난이도를 검토한 뒤 구현합니다.

5. 완성된 결과를 기획자가 확인합니다.

제품과 조직의 상황에 따라 다르지만, 이 구조에서는 기획이 개발보다 앞에 있고 개발은 정리된 요구를 구현하는 단계로 취급되기 쉽습니다.

그러나 실제 제품 개발에서 ‘무엇’과 ‘어떻게’는 깔끔하게 분리되지 않습니다.

예를 들어 기획자가 고객 문의를 처리하는 AI 기능을 제안했다고 생각해 보겠습니다. 겉으로는 무엇을 만들지 정한 것처럼 보이지만 아직 중요한 질문이 남아 있습니다.

• 현재 데이터로 어느 정도의 답변 품질을 낼 수 있는가?

• 답변 생성에 몇 초가 걸리는가?

• 한 건을 처리하는 비용은 얼마인가?

• 개인정보를 외부 모델에 전송해도 되는가?

• AI가 잘못 답하면 어떤 피해가 발생하는가?

• 답하지 말아야 할 질문은 무엇인가?

• 언제 상담원에게 넘겨야 하는가?

• 모든 답변의 근거를 기록할 수 있는가?

이 질문에 따라 제품의 대상 사용자와 기능 범위, 화면 흐름과 사업성이 모두 달라집니다.

즉, 기술적 선택은 단순한 구현 방법이 아니라 제품의 정의 자체를 바꿉니다. 반대로 사용자의 기대와 사업 조건도 아키텍처와 모델, 데이터 처리 방식을 바꿉니다.

AI 제품에서는 ‘무엇’과 ‘어떻게’를 더 이상 순차적으로 결정하기 어렵습니다.

기획자와 개발자가 초기에 함께 탐색하고, 실제 결과를 보면서 문제와 해법을 동시에 조정해야 합니다.

AI는 두 직무를 합치는 것이 아니라 경계를 겹치게 한다

AI를 활용하면 기획자도 구현 영역에 더 가까이 갈 수 있습니다.

• 자연어로 화면 초안을 만듭니다.

• 사용자 흐름을 동작하는 프로토타입으로 표현합니다.

• 간단한 데이터 분석과 SQL 작성을 시도합니다.

• 반복적인 문서 작성과 사례 정리를 자동화합니다.

• 개발 전에 여러 아이디어를 빠르게 비교합니다.

개발자 역시 기획 영역에 더 깊게 참여할 수 있습니다.

• 요구사항의 모순과 빠진 조건을 찾습니다.

• 여러 구현 대안을 빠르게 시험합니다.

• 비용과 성능을 실제 수치로 비교합니다.

• 프로토타입을 통해 사용자 경험의 문제를 확인합니다.

• 제품 지표와 운영 결과를 분석합니다.

그렇다고 두 직무가 완전히 같아지는 것은 아닙니다.

기획자에게는 사용자와 시장, 사업과 조직을 이해하는 전문성이 필요합니다. 개발자에게는 시스템 구조와 데이터, 보안과 운영을 이해하는 전문성이 필요합니다. AI를 사용할 수 있다는 이유로 이 전문성이 자동으로 생기지는 않습니다.

달라지는 것은 상대의 영역을 전혀 몰라도 되는 관계입니다.

기획자는 기술적 제약과 AI의 불확실성을 이해해야 합니다. 개발자는 사용자의 문제와 사업 목적을 이해해야 합니다. 두 역할의 경계는 사라지기보다 서로 겹치는 공동 판단 영역이 넓어집니다.

이를 다음처럼 볼 수 있습니다.

핵심은 담당 영역을 구분하되 결과에 대한 책임까지 분리하지 않는 것입니다.

기획자의 역할은 문서 작성에서 판단 기준 설계로 이동한다

AI 시대의 기획자는 기능 목록을 작성해 개발자에게 전달하는 데서 역할이 끝나지 않습니다.

“AI로 고객 문의를 자동화해주세요”라는 문장은 방향을 제시할 수 있지만, 실행 가능한 기획은 아닙니다. 최소한 다음 질문에 답할 수 있어야 합니다.

• 어떤 사용자의 어떤 문제를 해결하려는가?

• 현재 그 문제를 어떤 방식으로 처리하고 있는가?

• AI를 도입해야 하는 이유는 무엇인가?

• AI가 처리할 업무와 사람이 처리할 업무는 무엇인가?

• 잘못된 결과가 나오면 사용자에게 어떤 피해가 생기는가?

• 어느 정도의 정확도와 응답 시간을 기대하는가?

• 건당 비용은 어느 수준까지 허용할 수 있는가?

• 성공 여부를 어떤 지표로 판단할 것인가?

• 이번 버전에서 의도적으로 제외할 것은 무엇인가?

따라서 기획자의 핵심 산출물은 화면 설계서의 장수가 아닙니다.

개발자와 AI가 일관된 판단을 내릴 수 있도록 문제, 우선순위, 제약 조건, 성공 기준을 명확하게 만드는 것

이것이 더 중요한 기획 업무가 됩니다.

프로토타입은 요구사항이 아니라 대화의 도구다

AI로 만든 프로토타입은 매우 유용합니다. 문장과 그림만으로 설명하던 아이디어를 실제로 누르고 확인할 수 있기 때문입니다.

다만 동작하는 화면이 곧 완성된 제품은 아닙니다.

AI가 빠르게 만든 프로토타입에는 흔히 다음 요소가 빠져 있습니다.

• 사용자 인증과 접근 권한

• 개인정보와 민감 정보 보호

• 실제 데이터의 정합성

• 오류와 예외 상황

• 동시 접속과 성능

• 장애 대응과 복구

• 관리자와 운영 도구

• 로그와 모니터링

• 외부 서비스 비용과 사용 한도

• 장기적인 유지보수 구조

따라서 “프로토타입이 하루 만에 나왔으니 실제 서비스도 금방 만들 수 있다”고 판단해서는 안 됩니다.

프로토타입은 개발 일정을 증명하는 결과물이 아니라 가설과 사용자 흐름을 빠르게 검증하고, 기획자와 개발자가 같은 대상을 보며 대화하게 만드는 공통 작업물입니다.

기획자는 정상 흐름보다 실패 경험까지 설계해야 한다

AI 제품은 정상적으로 작동할 때만 설계해서는 부족합니다.

AI가 답을 모를 때, 확신이 낮을 때, 잘못된 도구를 선택했을 때, 외부 시스템이 응답하지 않을 때 사용자가 어떤 경험을 하게 될지도 기획의 일부입니다.

• AI가 모른다고 말할 수 있는가?

• 근거를 확인할 수 있는가?

• 사용자가 결과를 수정하거나 거절할 수 있는가?

• 사람에게 도움을 요청할 수 있는가?

• 실행 전에 미리 확인해야 하는 행동은 무엇인가?

• 이미 실행된 행동을 취소할 수 있는가?

실패를 개발자의 예외 처리 문제로만 넘기면 제품 경험이 끊어집니다.

AI 시대의 기획자는 성공 경로뿐 아니라 거절, 보류, 승인, 수정, 복구, 인간 인계의 경험까지 설계해야 합니다.

개발자의 역할은 구현에서 제품의 현실성 설계로 확장된다

개발자도 “기획서에 있는 대로 구현했습니다”라고 말하는 것으로 책임을 다했다고 보기 어렵습니다.

AI가 구현 작업을 빠르게 수행할수록 개발자는 더 이른 단계부터 제품 논의에 참여해야 합니다.

• 이 기능이 사용자의 문제를 실제로 해결하는가?

• AI 없이 더 단순하게 해결할 수는 없는가?

• 현재 확보한 데이터로 구현할 수 있는가?

• 어떤 조건에서 품질이 급격히 떨어지는가?

• 운영 환경에서 감당할 수 있는 비용인가?

• 실패했을 때 원인을 추적할 수 있는가?

• 자동화보다 사람에게 넘기는 것이 나은 구간은 어디인가?

• 사용자가 늘어나도 유지할 수 있는 구조인가?

개발자는 기획자의 요구를 평가하거나 거절하는 사람이 아닙니다. 기술적 선택이 사용자 경험과 사업에 미치는 영향을 선택지와 대가의 형태로 설명하는 사람이어야 합니다.

예를 들어 기획자가 “가장 정확한 모델을 사용하자”고 제안했을 때 개발자는 단순히 가능한지 답하는 데서 그치지 않아야 합니다.

좋은 개발자는 가장 화려한 기술을 선택하는 사람이 아닙니다.

현재 문제에 맞는 균형점을 제시하고, 왜 그런 선택을 했는지 제품 언어로 설명할 수 있는 사람입니다.

가장 중요한 변화는 요구사항 전달에서 완료 기준 공동 작성으로의 전환이다

기획자와 개발자의 갈등은 종종 서로 다른 ‘완료’의 정의에서 발생합니다.

기획자에게는 사용자가 화면에서 기능을 사용할 수 있으면 완료로 보일 수 있습니다. 개발자에게는 정상 동작뿐 아니라 보안과 성능, 데이터 정합성, 장애 대응까지 준비돼야 완료일 수 있습니다.

AI 기능에서는 완료 기준이 더 모호합니다.

일반 소프트웨어는 같은 입력에 같은 결과가 나오는 경우가 많습니다. 반면 생성형 AI는 같은 요청에도 다른 결과를 만들 수 있고, 대부분의 상황에서 잘 작동하다가 특정 질문에서 위험한 답변을 내놓을 수 있습니다.

“잘 작동한다”거나 “답변이 자연스럽다”는 표현만으로는 출시 여부를 판단하기 어렵습니다.

개발을 시작하기 전에 기획자와 개발자가 다음 기준을 함께 작성해야 합니다.

제품 기준

• 어떤 사용자의 어떤 문제를 해결하는가?

• 사용자는 기존 방식보다 무엇이 좋아졌다고 느껴야 하는가?

• 이 기능을 사용하지 말아야 하는 상황은 무엇인가?

• 어떤 사용자 행동이나 사업 지표를 성공으로 볼 것인가?

AI 품질 기준

• 대표 질문과 위험 질문은 무엇인가?

• 어떤 평가 데이터를 사용할 것인가?

• 어느 수준을 통과 기준으로 볼 것인가?

• 답을 모를 때 어떤 행동을 해야 하는가?

• 금지해야 할 답변과 행동은 무엇인가?

• 사람에게 넘겨야 하는 조건은 무엇인가?

기술·운영 기준

• 응답 시간의 허용 범위는 얼마인가?

• 요청 한 건당 비용 상한은 얼마인가?

• 외부 모델과 도구가 실패하면 어떻게 처리할 것인가?

• 어떤 로그와 지표를 기록할 것인가?

• 이상을 어떻게 감지하고 이전 상태로 복구할 것인가?

• 개인정보와 민감 정보는 어떻게 보호할 것인가?

기획자는 사용자가 기대하는 결과와 사업적 한계를 설명합니다. 개발자는 이를 측정 가능한 테스트와 지표, 시스템 조건으로 변환합니다. 그리고 둘이 현실적인 기준에 합의합니다.

완료 기준은 한쪽이 작성해 전달하는 문서가 아닙니다.

기획자와 개발자가 함께 작성하는 제품의 품질 계약입니다.

AI의 권한은 기술 설정이면서 제품 정책이다

AI 에이전트가 메일을 보내고, 파일을 수정하고, 결제나 환불을 처리한다면 권한 설계는 개발자만의 보안 설정이 아닙니다.

어떤 일을 AI가 자동으로 처리하고 어떤 일을 사용자나 담당자에게 확인받을지는 제품 정책이자 사용자 경험입니다.

예를 들어 AI가 고객의 환불 요청을 처리한다고 생각해 보겠습니다.

• 일정 금액 이하는 자동으로 환불할 것인가?

• 반복 환불이나 이상 패턴은 누가 검토할 것인가?

• 사용자는 실행 전에 환불 금액과 조건을 확인할 수 있는가?

• 잘못 환불했을 때 취소하거나 복구할 수 있는가?

• AI가 어떤 근거로 결정했는지 담당자가 확인할 수 있는가?

개발자는 최소 권한과 승인 절차, 감사 로그와 실행 한도를 구현해야 합니다. 기획자는 어떤 행동이 사용자에게 허용 가능하고, 어느 지점에서 확인과 설명이 필요한지 정해야 합니다.

둘 중 한쪽만으로는 충분하지 않습니다.

기획자가 위험을 정의하지 않으면 개발자는 모든 예외를 알 수 없습니다. 개발자가 기술적 실패 가능성을 설명하지 않으면 기획자는 현실적인 정책을 만들기 어렵습니다.

AI의 자율성은 기능 목록이 아니라 사업 위험, 사용자 신뢰, 기술 안전성을 함께 반영한 공동 결정이어야 합니다.

완전 자동화보다 인간 개입을 함께 설계해야 한다

AI 제품을 기획할 때 자동화율이 높을수록 좋은 제품처럼 생각하기 쉽습니다.

그러나 자동화율을 95%에서 99%로 올리는 데 막대한 비용이 들고, 남은 1%의 실패가 치명적이라면 사람이 개입하는 구조가 더 안전하고 경제적일 수 있습니다.

로보택시가 대표적인 사례입니다.

운전석이 비어 있어 완전히 자동화된 서비스처럼 보이지만 실제 운영에서는 공사 구간, 경찰의 수신호, 승객의 도움 요청처럼 예상하지 못한 상황이 발생합니다. 이런 예외를 처리하기 위해 원격 지원과 현장 운영 인력이 필요합니다.

운전자가 사라졌다고 노동이 사라진 것이 아닙니다. 노동의 위치가 차량 내부에서 관제와 예외 처리 영역으로 이동한 것입니다.

AI 서비스도 같습니다.

기획자와 개발자는 다음을 함께 정해야 합니다.

• AI가 독립적으로 처리해도 되는 일은 무엇인가?

• 어떤 위험과 불확실성을 감지하면 멈춰야 하는가?

• 누구에게 판단을 넘길 것인가?

• 담당자는 어떤 맥락과 실행 기록을 확인해야 하는가?

• 사용자는 기다리는 동안 어떤 안내를 받아야 하는가?

• 사람이 수정한 뒤 AI가 작업을 이어갈 수 있는가?

• 반복되는 예외를 제품과 시스템 개선에 어떻게 반영할 것인가?

좋은 자동화는 사람을 무조건 제거하는 시스템이 아닙니다.

AI가 잘하는 일과 사람이 책임져야 할 일을 구분하고, 둘 사이의 인계를 자연스럽게 만드는 시스템입니다.

여기에서도 기획자는 인계 경험과 운영 정책을, 개발자는 감지 조건과 기록·복구 구조를 맡되 전체 흐름은 함께 검증해야 합니다.

피해야 할 두 가지 관계

AI 시대에 특히 경계해야 할 태도가 있습니다.

기획자의 “AI에게 시키면 금방 되잖아요”

AI가 코드와 화면을 빠르게 생성하는 것은 사실입니다. 그러나 생성 속도와 제품 완성 속도는 같지 않습니다.

안정적인 서비스에는 다음 작업이 필요합니다.

• 실제 데이터와 기존 시스템 연결

• 인증과 권한 관리

• 오류와 예외 처리

• 보안과 개인정보 보호

• 성능과 비용 최적화

• 테스트와 품질 평가

• 배포와 모니터링

• 장애 복구와 고객 대응

AI는 구현 비용을 낮출 수 있지만 책임과 운영 비용까지 없애지는 않습니다.

기획자가 AI 프로토타입만 보고 일정과 난이도를 단정하면 보이지 않는 작업이 개발 후반으로 밀립니다. 결국 일정 지연과 품질 저하로 돌아옵니다.

따라서 “AI로 얼마나 빨리 만들 수 있는가?”뿐 아니라 **“이 결과를 실제 사용자에게 제공하고 계속 운영하려면 무엇이 필요한가?”**를 함께 물어야 합니다.

개발자의 “그건 기획에서 정해주세요”

기술적 선택이 사용자 경험과 비용, 사업 모델을 바꾼다면 개발자도 기획 과정에 참여해야 합니다.

AI의 오류 가능성, 데이터 부족, 모델 비용, 응답 지연, 공급자 의존성은 기획자가 혼자 판단하기 어려운 문제입니다. 개발 후반에 기술적 한계를 통보하면 선택 가능한 대안이 이미 줄어든 뒤일 수 있습니다.

개발자는 단순히 어렵다고 말하는 사람이 아니라 다음 구조로 설명할 수 있어야 합니다.

1. 현재 요구를 그대로 구현할 때의 위험

2. 선택 가능한 대안

3. 각 대안의 비용과 장점

4. 빠르게 확인할 수 있는 실험 방법

5. 지금 결정해야 할 사항과 나중에 바꿀 수 있는 사항

기술적 불확실성을 제품 언어로 번역하는 것도 개발자의 중요한 역할입니다.

가장 좋은 협업은 짧은 공동 검증의 반복이다

AI 시대에는 기획 문서를 완성한 뒤 개발팀에 넘기는 긴 순차 과정보다, 작은 가설을 함께 검증하는 방식이 더 효과적입니다.

1. 문제를 한 문장으로 정의한다

기획자가 대상 사용자와 현재의 불편, 기대하는 변화를 설명합니다.

예를 들어 “고객 문의를 AI로 자동화한다”보다 다음 문장이 낫습니다.

반복적으로 들어오는 배송 문의에 10초 안에 근거가 있는 답변을 제공해 상담원의 단순 조회 업무를 줄인다.

대상과 문제, 기대 결과가 드러나기 때문입니다.

2. 사실과 가정을 구분한다

현재 알고 있는 사실과 아직 검증하지 않은 가정을 나눕니다.

• 문의 중 배송 관련 비중은 실제로 얼마인가?

• 답변에 필요한 데이터가 시스템에 존재하는가?

• 사용자는 AI 답변을 신뢰하는가?

• 잘못된 답변의 피해는 어느 정도인가?

기획자는 사용자·사업 가정을, 개발자는 데이터·기술 가정을 중심으로 정리합니다.

3. 가장 위험한 가정부터 시험한다

완성된 제품을 만들기 전에 실패 가능성이 큰 부분을 작은 실험으로 확인합니다.

• 실제 문의 100건으로 답변 품질을 평가합니다.

• 외부 모델 사용 시 비용과 응답 시간을 측정합니다.

• 개인정보가 포함된 사례를 분류합니다.

• 상담원이 AI의 답을 얼마나 자주 수정하는지 확인합니다.

AI가 프로토타입과 평가 도구를 빠르게 만드는 데 도움을 줄 수 있습니다.

4. 완료 기준과 중단 기준을 함께 정한다

성공 조건만 아니라 출시를 보류해야 하는 조건도 합의합니다.

• 정확도가 기준보다 낮은 경우

• 위험 질문을 안정적으로 차단하지 못하는 경우

• 비용이 사업적 상한을 넘는 경우

• 실패 원인을 추적할 로그가 없는 경우

• 상담원에게 안전하게 넘길 수 없는 경우

5. 제한된 범위에서 운영한다

처음부터 모든 사용자와 업무를 자동화하지 않습니다.

대상 사용자와 업무 범위를 제한하고, 필요한 경우 사람이 결과를 검토합니다. 실제 환경에서 품질과 비용, 예외 유형을 확인한 뒤 권한과 자동화 범위를 넓힙니다.

6. 실패를 다음 기준으로 전환한다

발생한 문제를 단순히 수정하는 데서 끝내지 않습니다.

• 반복되는 오류는 테스트 사례로 만듭니다.

• 자주 필요한 절차는 재사용 가능한 스킬로 만듭니다.

• 잘못된 기억과 데이터는 수정하거나 만료시킵니다.

• 사람이 개입한 이유를 새로운 인계 조건에 반영합니다.

• 기획 가정이 틀렸다면 기능 범위와 성공 지표를 수정합니다.

이 과정을 반복하면 기획과 개발은 문서를 주고받는 단계가 아니라 같은 가설을 서로 다른 전문성으로 검증하는 하나의 팀이 됩니다.

회의와 문서도 달라져야 한다

협업 방식을 바꾸려면 일상적인 회의와 문서의 형태도 바뀌어야 합니다.

기능 설명보다 결정 기록을 남긴다

무엇을 만들었는지만 기록하면 시간이 지난 뒤 왜 그런 구조를 선택했는지 알기 어렵습니다.

다음 내용을 함께 남기는 것이 좋습니다.

• 해결하려던 사용자 문제

• 고려한 대안

• 선택한 방법과 이유

• 포기한 것과 남은 위험

• 성공·실패를 판단할 지표

• 나중에 다시 검토할 조건

AI는 과거 문서를 검색하고 요약하는 데 유용하지만, 애초에 결정의 이유가 기록되지 않았다면 올바른 맥락을 복원하기 어렵습니다.

정상 사례만 보여주는 데모를 피한다

AI 제품의 데모에서는 잘 되는 대표 사례뿐 아니라 다음도 확인해야 합니다.

• 답을 모르는 질문

• 데이터가 부족한 요청

• 외부 시스템이 실패한 상황

• 악의적이거나 위험한 입력

• 권한이 없는 사용자의 요청

• 사람이 개입해야 하는 상황

성공 화면만 확인하면 제품의 실제 운영 가능성을 평가하기 어렵습니다.

일정이 아니라 불확실성도 공유한다

AI 기능은 초기에는 품질과 비용을 정확히 예측하기 어려울 수 있습니다.

개발자가 임의의 확정 일정을 제시하거나, 기획자가 하나의 날짜만 요구하기보다 다음을 구분해야 합니다.

• 이미 방법을 알고 있는 구현 작업

• 실험을 통해 확인해야 하는 기술 가정

• 데이터나 외부 조직에 의존하는 사항

• 품질 기준에 따라 범위가 달라질 수 있는 부분

불확실성을 숨기지 않고 작은 검증 일정으로 나누는 편이 결과적으로 더 예측 가능한 개발을 만듭니다.

출시 이후에는 결과를 공동으로 운영해야 한다

제품이 출시되면 기획은 끝나고 개발은 유지보수만 담당한다는 구분도 AI 제품에는 맞지 않습니다.

AI의 품질은 실제 사용자의 질문과 데이터 변화, 모델 업데이트, 외부 도구의 상태에 따라 달라질 수 있습니다. 출시 시점에 통과한 평가가 몇 달 뒤에도 그대로 유지된다는 보장이 없습니다.

기획자와 개발자는 출시 이후 다음 지표를 함께 봐야 합니다.

사용자와 사업 지표

• 실제 사용률과 재사용률

• 문제 해결률

• 사람이 다시 처리한 비율

• 사용자 수정·거절 비율

• 고객 만족도와 불만 유형

• 매출 증가 또는 업무 시간 절감

AI와 기술 지표

• 평가 데이터 기준 정확도

• 위험한 답변과 행동의 발생률

• 사람에게 인계된 비율과 이유

• 응답 시간과 작업 완료 시간

• 요청당 모델·인프라 비용

• 실패율과 재시도율

• 장애 탐지와 복구 시간

한쪽 지표만 보면 잘못된 결론을 내릴 수 있습니다.

기술 품질이 높아도 사용자가 필요로 하지 않으면 실패한 제품입니다. 사용률이 높아도 비용이 감당할 수 없거나 위험한 행동이 반복되면 지속 가능한 제품이 아닙니다.

기획자는 사용자와 사업의 변화를 해석하고, 개발자는 시스템의 행동과 원인을 분석합니다. 두 결과를 함께 봐야 다음 제품 결정을 내릴 수 있습니다.

좋은 관계를 판단하는 실무 질문

기획자와 개발자의 협업이 제품 중심으로 작동하고 있는지는 다음 질문으로 점검할 수 있습니다.

문제와 목표

• 대상 사용자와 해결할 문제가 한 문장으로 합의돼 있는가?

• 기능이 아니라 기대하는 결과를 설명할 수 있는가?

• 사실과 아직 검증하지 않은 가정을 구분했는가?

범위와 우선순위

• 이번 버전에서 제외할 범위가 명확한가?

• 기술적 난이도와 사용자 가치를 함께 고려했는가?

• 프로토타입과 운영 제품의 차이를 이해하고 있는가?

품질과 안전

• “잘 작동한다”를 측정 가능한 기준으로 정의했는가?

• 정상 사례뿐 아니라 실패·위험 사례도 테스트하는가?

• AI가 멈추고 사람에게 넘길 조건이 있는가?

• 권한과 개인정보 처리 방식을 함께 검토했는가?

비용과 운영

• 품질뿐 아니라 응답 시간과 건당 비용을 측정하는가?

• 로그와 모니터링, 중단과 복구 방법이 있는가?

• 외부 모델이나 도구가 실패할 때 대안이 있는가?

책임과 학습

• 왜 이 방법을 선택했는지 기록돼 있는가?

• 문제가 발생했을 때 담당과 대응 절차가 명확한가?

• 실패가 테스트와 정책, 다음 기획에 반영되는가?

• 출시 이후 제품·사업·기술 지표를 함께 보는가?

많은 질문에 답하기 어렵다면 개인의 협업 태도보다 공동 판단 구조가 부족한 것일 수 있습니다.

결국 두 사람은 서로 다른 불확실성을 줄이는 파트너다

AI가 구현 속도를 높일수록 기획자와 개발자의 관계는 더 중요해집니다.

코드와 화면을 만드는 비용이 낮아지면 시도할 수 있는 아이디어가 늘어납니다. 그러나 모든 아이디어가 사용자에게 가치가 있는 것은 아니고, 모든 프로토타입이 안전하게 운영될 수 있는 것도 아닙니다.

가능성이 많아질수록 선택과 검증이 중요해집니다.

기획자는 다음에 더 큰 책임을 집니다.

• 왜 이 문제를 해결해야 하는가?

• 누구에게 어떤 가치를 제공할 것인가?

• 무엇을 성공으로 판단할 것인가?

• 어떤 실패 경험과 운영 정책이 필요한가?

개발자는 다음에 더 큰 책임을 집니다.

• 이 문제를 어떤 구조로 구현할 것인가?

• AI에 어떤 데이터와 도구, 권한을 줄 것인가?

• 결과가 맞고 안전하다는 것을 어떻게 증명할 것인가?

• 문제가 생기면 어떻게 중단하고 복구할 것인가?

그러나 최종 제품의 결과는 공동 책임입니다.

기획자는 “개발팀이 잘못 만들었다”는 말로 끝낼 수 없습니다. 개발자도 “기획서대로 만들었다”는 말로 끝낼 수 없습니다. 사용자에게 전달된 결과가 두 역할 사이에서 만들어졌기 때문입니다.

AI 시대의 좋은 기획자와 개발자는 서로의 역할을 침범하는 관계가 아닙니다.

상대방의 전문성을 이해하고, 중요한 결정이 어느 한쪽의 문서나 코드 속에 갇히지 않도록 만드는 관계입니다.

기획자는 사용자의 문제를 기술이 다룰 수 있는 판단 기준으로 바꿉니다. 개발자는 기술의 가능성과 제약을 제품이 선택할 수 있는 언어로 바꿉니다. 두 사람은 작은 실험으로 가정을 검증하고, 실제 운영 결과를 보며 제품을 계속 수정합니다.

결국 관계의 핵심은 다음 한 문장으로 정리할 수 있습니다.

기획자는 올바른 문제를 선택하고, 개발자는 그 문제를 안전한 시스템으로 바꾸며, 두 사람은 사용자에게 실제 가치가 전달됐는지를 함께 증명하고 책임진다.

AI는 기획자와 개발자 사이의 경계를 없애지 않습니다.

대신 문서를 전달하고 책임을 나누던 경계를, 같은 결과를 함께 설계하고 검증하는 접점으로 바꿉니다.

앞으로 강한 제품팀은 AI를 가장 많이 사용하는 팀이 아닐 것입니다.

기획과 개발이 문제·제약·완료 기준·운영 결과를 함께 소유하면서, AI가 만든 가능성을 안전한 사용자 가치로 바꿀 수 있는 팀일 것입니다.