AI 시대의 개발자의 다음 역할인 AI Builder?

여성 의류 쇼핑몰에 한 달 동안 1만 명이 들어왔습니다. 상품을 장바구니에 담은 사람은 1,500명인데, 실제로 구매한 사람은 300명입니다. 구매전환율은 3%. 광고로 사람을 더 데려오기 전에, 이미 들어온 고객이 왜 구매하지 않는지 살펴볼 만한 상황입니다.

여기서 누군가는 “어떤 기능을 만들어 드릴까요?”라고 묻고, 누군가는 “고객이 어디서 망설이는지부터 보죠”라고 말합니다. 이 글에서 말하는 AI Builder는 AI를 활용해 문제를 찾고, 해결책을 만들고, 실제 효과까지 확인하는 사람입니다. 앱을 자동으로 만들어 주는 도구 이름을 뜻하는 것은 아닙니다.

아래 쇼핑몰과 고객 반응, 개발 일정, 전환율·반품률은 역할의 차이를 설명하기 위한 가상 사례입니다. 특정 업체의 실제 성과가 아닙니다.

“AI 사이즈 추천 기능을 만들어 주세요”라는 요청을 받았다면

쇼핑몰 PM이 개발자에게 요청합니다.

“상세페이지에서 이탈하는 고객이 많아요. AI 사이즈 추천 기능을 추가해 주세요.”

기능 구현을 맡은 개발자는 입력 항목을 정하고, DB를 설계하고, API와 화면을 만듭니다. 테스트를 거쳐 배포한 뒤 키와 몸무게를 넣었을 때 추천 사이즈가 제대로 나오는지 확인합니다. 중요한 일입니다. 이 과정이 부실하면 어떤 아이디어도 서비스가 될 수 없습니다.

다만 담당 범위가 ‘기능 완성’까지라면, 배포 후에 남는 질문이 있습니다. 고객은 정말 사이즈 때문에 구매를 망설였을까요? 추천 기능을 넣으니 실제로 더 많이 샀을까요?

AI Builder는 이 질문까지 자신의 일로 가져갑니다. 기존 개발자와 완전히 다른 직종이라는 뜻은 아닙니다. 이미 이렇게 일하는 개발자도 많습니다. 차이는 코딩 실력의 유무보다, 어디서 일을 시작하고 무엇을 확인한 뒤 끝내느냐에 있습니다.

첫 번째 일은 코딩이 아니라, 구매를 망설이는 이유를 찾는 것

앞의 쇼핑몰 숫자를 다시 보겠습니다. 방문자 1만 명, 장바구니에 담은 사람 1,500명, 구매한 사람 300명. 이 숫자만으로 “사이즈가 문제다”라고 결론 내릴 수는 없습니다. 배송비가 예상보다 비쌀 수도 있고, 원하는 색상이 품절이거나 결제 과정이 불편할 수도 있습니다.

그래서 상품 리뷰와 고객 문의를 모아 AI에게 반복되는 불편을 분류하게 합니다. 개인정보를 제외한 자료로 “사이즈·배송·가격·결제 문제를 나누고, 각 분류의 근거 문장도 함께 보여 달라”고 요청할 수 있습니다. 요약만 읽고 끝내지 말고 원문 일부를 직접 확인하는 과정도 필요합니다.

이 가상 사례에서는 다음과 같은 반응이 반복해서 나왔다고 해보겠습니다.

“내 키에 M이 맞을지 모르겠어요.”
“모델은 170cm인데, 제가 입으면 기장이 어느 정도일까요?”
“반품하기 번거로워서 일단 안 샀어요.”

상품 상세페이지를 본 뒤 빠져나가는 흐름과 이런 문의를 함께 살펴보면, 시험해 볼 가설이 생깁니다. ‘내게 맞을지 모르겠다’는 불확실성을 줄이면 구매를 결정하는 데 도움이 될 수 있다. 아직 정답을 찾은 것은 아닙니다. 무엇을 만들어 검증할지 정한 것입니다.

해결책은 ‘AI 기능 추가’보다 구체적이어야 한다

여기서 목표를 “쇼핑몰에 AI 넣기”로 잡으면 기능이 필요 이상으로 커지기 쉽습니다. 목표는 구매자가 자신에게 맞는 사이즈를 고르도록 돕는 것입니다. AI는 그 일을 돕는 수단입니다.

가장 작은 실험은 상품 상세페이지 안에 추천 영역을 하나 넣는 방식일 수 있습니다.

입력 · 키 170cm / 몸무게 65kg / 평소 M / 여유 있는 핏 선호
예시 결과 · “이 상품은 M을 추천합니다. 더 여유 있게 입으려면 L도 비교해 보세요.”

이 문구는 화면을 설명하기 위한 예시입니다. 실제 추천에는 상품별 실측, 소재와 신축성, 핏 정보, 고객이 선호하는 착용감 같은 근거가 필요합니다. 키와 몸무게만 넣었다고 정확한 답이 나오는 것은 아닙니다. 정보가 부족하면 추천을 단정하는 대신 실측표를 비교하도록 안내하는 쪽이 낫습니다.

‘내 체형으로 입은 모습을 보여 주는 AI 착장’도 생각할 수 있습니다. 하지만 처음부터 함께 만들 필요는 없습니다. 보기 좋은 착장 이미지가 실제 착용감까지 보장하지는 않으니까요. 고객이 가장 궁금해하는 것이 기장인지, 품인지, 전체 분위기인지부터 좁히는 편이 실험 결과를 해석하기 쉽습니다.

작게 만들고, 일부 고객에게 먼저 보여 준다

이제 개발을 시작합니다. Claude Code나 Codex 같은 코딩 도구를 활용하는 상황을 가정하면, 화면과 API의 초안, 데이터 구조, 테스트 코드 작성을 나눠 맡길 수 있습니다. 개발자는 생성된 코드를 읽고 기존 쇼핑몰의 로그인·상품·주문 구조와 맞는지 확인합니다.

예를 들어 기존 상품 데이터와 배포 환경이 준비돼 있다면 ‘3일 동안 한 상품군의 추천 흐름만 구현해 보자’는 실험 목표를 세울 수 있습니다. 3일이면 어느 쇼핑몰이든 완성된다는 이야기는 아닙니다. 데이터가 정리돼 있지 않거나 주문 시스템과 새로 연결해야 한다면 기간은 달라집니다.

여기서 MVP는 고객이 눌러 볼 수 있는 화면만 뜻하지 않습니다. 추천이 실패해도 원래 상품 페이지는 쓸 수 있어야 하고, 추천 영역을 본 사람과 사용한 사람, 구매한 사람을 구분해 기록할 수 있어야 합니다. 효과를 확인할 방법까지 있어야 다음 결정을 내릴 수 있습니다.

배포 다음 날부터가 진짜 질문이다

기능이 배포됐습니다. 이제 완료 표시를 붙이는 대신 고객을 무작위로 나눠, 한쪽에는 기존 상세페이지를, 다른 쪽에는 사이즈 추천 기능이 있는 페이지를 보여 주는 A/B 테스트를 생각해 볼 수 있습니다. 비교할 구매전환율의 기준과 실험 기간은 먼저 정합니다.

가령 두 그룹의 결과가 다음과 같았다고 가정해 보겠습니다.

• 기존 페이지 구매전환율: 3.0%
• 사이즈 추천 페이지 구매전환율: 3.8%
• 사이즈 관련 반품률: 12% → 7%

구매전환율은 0.8%포인트 상승한 것입니다. 상대 증가율로는 약 26.7%입니다. 방문자가 각각 1만 명이라고 가정하면 구매자 300명과 380명의 차이, 즉 80명 차이에 해당합니다. 실제 테스트에서는 같은 정의의 방문자와 구매자를 비교해야 합니다.

그래도 이 숫자만 보고 곧바로 “성공했다”고 결론 내리면 곤란합니다. 표본 수와 불확실성을 확인하고, 할인 행사나 유입 경로의 차이가 결과를 흔들지 않았는지 살펴봐야 합니다. 특히 반품은 구매 직후 확정되지 않으므로 충분한 관찰 기간이 필요합니다. 반품률의 분모를 주문 건수로 볼지 상품 수량으로 볼지도 맞춰야 합니다.

구매가 늘어도 할인 비용과 반품 처리 비용, AI 사용 비용이 더 크게 늘었다면 사업적으로 좋은 결과가 아닐 수 있습니다. 전환율, 반품, 비용을 함께 확인한 뒤 확대할지, 고칠지, 중단할지 결정하는 것. 이것까지가 AI Builder의 일입니다.

개발자의 일이 어디까지 넓어지는가

기능 구현을 중심으로 맡는 업무는 대체로 ‘요구사항을 받아 개발하고, 테스트한 뒤 배포하는 흐름’으로 설명할 수 있습니다. AI Builder는 그 앞에 고객의 불편과 원인을 찾는 일을, 뒤에는 효과를 측정하고 개선하는 일을 붙입니다.

그래서 쇼핑몰 운영자가 “장바구니에서 너무 많이 나가요”라고 말했을 때 바로 기능 목록부터 만들지 않습니다. 어느 단계에서 이탈하는지 보고, 고객의 말을 확인하고, 가능한 원인을 좁힙니다. 그다음 가장 작게 시험할 해결책을 만들어 봅니다.

실험 결과 사이즈 추천보다 배송 예정일을 명확하게 보여 주는 것이 더 도움이 된다면, 그쪽을 선택할 수 있어야 합니다. AI 기능을 만들었다는 사실보다 고객의 망설임이 줄었는지가 더 중요하기 때문입니다.

이런 의미에서 AI Builder는 ‘AI를 활용하는 작은 쇼핑몰 사업팀’에 가까운 역할이라고 볼 수 있습니다. 기획, 개발, 데이터 분석의 일부를 연결해 한 번의 개선을 끝까지 진행하는 사람입니다. 혼자 모든 전문가를 대체한다거나 매출 상승을 보장한다는 뜻은 아닙니다. 필요한 사람과 협업하면서도, 자신이 만든 변화가 어떤 결과로 이어졌는지 놓지 않는다는 뜻입니다.

지금 개발자라면 무엇부터 해보면 좋을까

새 도구를 전부 익히는 것부터 시작할 필요는 없습니다. 지금 만드는 기능 하나를 놓고 세 문장을 적어 보세요.

1. 고객이 겪는 불편은 무엇인가?
   “사이즈를 확신하지 못해 구매를 미룬다.”
2. 우리가 시험할 해결책은 무엇인가?
   “상품 실측에 근거한 사이즈 안내를 상세페이지에 제공한다.”
3. 도움이 됐는지 무엇으로 확인할 것인가?
   “구매전환율과 사이즈 관련 반품률을 함께 보고, 운영 비용도 확인한다.”

세 문장이 이어지지 않으면 코드를 더 빨리 만드는 것만으로는 부족합니다. 반대로 이 연결이 분명하면 AI에게 어떤 일을 맡길지, 어디를 직접 검토할지도 훨씬 명확해집니다.

다음 기능을 배포할 때는 “개발 완료” 옆에 질문 하나를 남겨 보세요. “그래서 고객의 어떤 문제가 얼마나 나아졌나요?” 그 답을 확인하는 데까지 자신의 일을 넓혀 가는 것. 쇼핑몰 사례에서 말하는 AI Builder의 방향은 바로 그것입니다.

---

이 글의 수치와 고객 발언은 설명을 위한 가상 예시이며 실제 조사·실험 결과가 아닙니다. 썸네일은 AI 생성 일러스트, 본문 도표는 가상 수치와 역할 설명을 바탕으로 제작했습니다.