한줄 요약
AI든 외주 개발이든, 결과물의 수준은 요청의 수준을 절대 넘지 못한다.
본문
외주 개발을 의뢰하는 방식과 AI에 프롬프트를 입력하는 방식은 구조가 놀랍도록 닮아 있다. 둘 다 "내가 원하는 것"을 상대방에게 전달하는 행위이고, 둘 다 입력이 부실하면 결과도 부실하게 돌아온다. 그런데 많은 클라이언트가 AI에게 하는 것과 똑같은 방식으로 개발사에 요청을 넣는다. 빠르게, 간단하게, 대충 맥락만 던지고 알아서 잘 해주길 기대하는 방식이다.
"알아서 잘 해주세요"가 가장 위험한 요청인 이유
앱 개발 외주를 맡기는 클라이언트들이 가장 자주 하는 요청 유형이 있다. "우버 같은 거요", "토스 느낌으로요", "깔끔하고 쓰기 편하게요" 같은 말들이다. 방향은 어렴풋이 담겨 있지만, 판단은 없다.
이 요청의 문제는 요청이 짧다는 게 아니다. 핵심 조건이 빠져 있다는 거다. 누가 쓸 것인지, 어떤 상황에서 쓸 것인지, 핵심 기능이 무엇인지, 어떤 건 절대 하지 말아야 하는지, 성공 기준이 무엇인지가 없다. 그 상태에서 개발사가 할 수 있는 건 가장 보편적인 가정을 하고, 가장 무난한 결과물을 만드는 것이다. 유사 앱을 참고해서 구조를 잡고, 일반적인 UX 패턴을 가져오고, 결과적으로 "뭔가 아닌 것 같은" 앱이 나온다.
이게 외주 개발 실패의 가장 흔한 패턴이다. 개발사 탓이 아니다. 재료가 없는 요리사한테 맛있는 요리를 기대한 것이다.
좋은 요청서는 문장이 많아서가 아니라 판단이 담겨 있다
요청서를 두껍게 만들면 좋은 요청이 되는 게 아니다. 중요한 건 밀도다. 다음 다섯 가지가 담겨 있으면 짧아도 좋은 요청이 된다.
누가 쓰는가. 같은 예약 기능이라도 50대 자영업자가 쓰는 것과 20대 직장인이 쓰는 것은 구조 자체가 달라진다. "일반 사용자"라는 말은 대상이 아니다.
무엇을 하게 해야 하는가. 예쁜 앱을 만드는 것과 첫 방문 사용자가 3분 안에 첫 결제를 완료하게 만드는 것은 완전히 다른 작업이다. 형태가 아니라 목적을 말해야 한다.
무엇이 제일 중요한가. 신뢰를 쌓는 게 먼저인지, 빠른 가입 전환이 먼저인지, 재방문율이 먼저인지를 순서 있게 말해줘야 한다. 다 중요하다는 건 아무것도 중요하지 않다는 말과 같다.
무엇은 하면 안 되는가. 경쟁사처럼 보이면 안 된다, 특정 기능은 넣지 마라, 특정 UI 패턴은 피해달라. 이 금지 조건이 없으면 결과물은 시장 평균으로 수렴한다.
어떤 기준으로 잘 됐다고 판단하는가. "좋아 보이면"이 아니라, 사용자가 로그인 없이도 핵심 가치를 이해할 수 있어야 한다거나, 주문 완료까지 3탭 이내여야 한다거나 하는 구체적인 기준이 있어야 한다.
이 다섯 가지가 갖춰진 요청서는 개발사가 불필요한 가정을 최소화하게 만들고, 결과물이 처음부터 목적에 가깝게 만들어지게 한다.
수정이 많은 프로젝트는 대부분 첫 요청이 문제였다
웹 개발 업체나 앱 개발 업체와 일하다 보면 수정 횟수가 많을수록 비용이 올라가고 납기가 밀린다. 그런데 수정 요청의 내용을 들여다보면 대부분 기술적인 문제가 아니다. "뭔가 느낌이 아니에요", "좀 더 우리 브랜드스럽게요", "처음 의도랑 달라요" 같은 말들이다.
이건 개발이 잘못된 게 아니라, 처음 요청이 불완전했던 것이다. 클라이언트의 머릿속에만 있던 기준이 중간에 갑자기 튀어나오는 것이다. 처음 요청서에 그 기준이 담겨 있었다면 애초에 발생하지 않았을 수정이다.
좋은 요청은 프로젝트 시작 전에 클라이언트 스스로 결정을 내리게 만든다. 우선순위를 정하고, 타협 가능한 것과 불가능한 것을 구분하고, 성공의 기준을 언어화하는 것. 이게 갖춰졌을 때 외주 개발의 성공률이 올라간다.
두 번째 요청이 진짜 요청의 시작이다
처음 결과물이 나왔을 때 어떻게 피드백하느냐도 요청만큼 중요하다. "이건 아닌 것 같아요"는 요청이 아니다. 결함의 위치를 짚어주는 것이 진짜 피드백이다.
전체 구조는 좋은데 첫 화면에서 핵심 기능이 바로 안 보인다거나, 플로우는 맞는데 특정 단계에서 사용자가 왜 이걸 해야 하는지 이해가 안 될 것 같다는 식의 말이 개발사가 실제로 작동할 수 있는 피드백이다.
개발 외주를 맡길 때 클라이언트에게 필요한 역량은 요구사항을 많이 쓰는 것이 아니다. 나온 결과물을 보고 어디서 목적과 어긋났는지 판단하는 능력이다. 그 판단을 언어로 정확하게 전달할 수 있을 때, 프로젝트는 처음부터 올바른 방향으로 수렴해간다.
