
AI로 빠르게 만들 수 있게 된 수탁 개발 회사는 다음에 무엇을 팔 것인가
요약
AI로 인해 개발 속도가 비약적으로 상승하면서 기존의 인월(Man-month) 기반 수탁 개발 모델이 위기에 직면했습니다. 단순 구현 속도가 아닌, 모호한 요구사항을 명확히 정의하고 결과물의 완성도를 보증하는 역량이 미래 개발사의 핵심 경쟁력이 될 것입니다.
핵심 포인트
- AI 도입으로 개발 시간이 수십 분의 일로 단축되어 기존 수익 모델 붕괴
- 속도는 차별화 요소가 아닌 기본 전제가 됨
- AI는 인풋의 품질을 증폭하므로 모호한 요구사항은 잘못된 결과로 이어짐
- 미래의 가치는 단순 구현이 아닌 사양의 완성도와 결과물에 대한 보증에 있음
실제 운영 중인 네이티브 앱의 Web 버전을 코드 한 줄 쓰지 않고 약 10시간 만에 만들었다.
구현 담당 엔지니어가 산정한 견적은 프론트엔드(Frontend)만 약 40인일(Man-day)이었다.
지난 기사에 그 전말을 적었다.
글을 다 쓰고 나서 계속 생각하고 있는 것이 있다.
구현이 수십 분의 일의 시간으로 끝나는 세상에서, 수탁 개발 회사는 무엇을 팔아서 돈을 벌 것인가.
확정된 것은 아무것도 없다.
다만, 상상해 본 미래 속에서 사라지는 판매물과 남는 판매물의 구분은 생기기 시작했다.
처음 떠올린 것은 속도 그 자체를 파는 것이었다.
"우리는 AI로 빠르다"를 간판으로 내걸면 당분간은 이길 수 있지 않을까.
생각하면 할수록 무리라는 것을 알게 되었다.
이유는 두 가지가 있다.
첫 번째는 속도를 숨길 수 없다는 점이다.
구현이 수십 분의 일로 줄어든다는 사실은 공표되는 순간 확산되기 시작한다.
세세한 절차를 모르더라도 "할 수 있다"는 것을 아는 것만으로 각 기업은 스스로 도달한다.
도구는 누구나 살 수 있고, 필요한 것은 특별한 재능이 아니라 착수의 빠르고 느림뿐이기 때문이다.
오늘의 차별화는 내년의 당연함이 된다.
두 번째는 우리가 청구할 수 있는 시간도 함께 줄어든다는 점이다.
40인일을 10시간 만에 납품하면, 청구의 근거는 40인일 분량이 사라진다.
단가를 3배로 올려도 청구할 수 있는 시간이 10분의 1이라면 받는 금액은 줄어든다.
인월(Man-month)로 장사하고 있으면 생산성을 높일수록 수익이 줄어든다.
속도는 판매물이 아니라 전제가 된다.
그렇다면 모두가 빨라진 세상에서 고객은 무엇에 돈을 지불할 것인가.
답을 찾기 위해 그 10시간의 내용을 떠올려 본다.
지난 프로젝트에서 AI가 정확하게 만들 수 있었던 것은, 실제로 작동하고 있는 실물 소스 코드라는, 이보다 더할 나위 없는 품질의 인풋(Input)이 처음부터 존재했기 때문이다.
AI는 전달받은 것을 그대로 증폭한다.
인풋이 실물이라면 정확성이 증폭되고, 인풋이 인간의 모호한 기억이라면 모호함이 자신만만하게 증폭된다.
쓰레기를 전달하면 쓰레기가 10시간 만에 완성된다.
느려지는 것이 아니다.
쓰레기가 빠르게 나오는 것이다.
즉 AI가 보증하는 것은 속도뿐이며, 완성은 보증하지 않는다.
나온 것이 나와야 할 것이었는지 어떤지는 인풋의 품질에 의해 결정되어 버린다.
게다가 신규 개발 현장에는 대개 실물이 없다.
있는 것이라고는 고객의 머릿속과 회의에서의 발언, 그리고 거기서 인간이 작성한 문서뿐이다.
AI가 아무리 발전해도 회의 자리에 앉는 것은 인간이고, 고객의 말을 끌어내는 것도 인간이다.
여기서 놓친 것은 이후의 어떤 공정에서도 복원되지 않는다.
이전이라면 놓치더라도 구제받을 수 있는 일이 있었다.
손으로 구현하는 엔지니어는 적혀 있지 않은 부분에서 손이 멈추기 때문이다.
예를 들어 회원 가입 화면을 만들고 있는데, 이미 등록된 이메일 주소가 입력되었을 때의 동작이 사양서 어디에도 적혀 있지 않다.
적혀 있지 않으면 구현할 수 없으므로 "이것은 어느 쪽입니까"라고 물으러 온다.
엔지니어가 견적을 낸 40인일 안에는 이러한 문답이 수십 번 포함되어 있었다.
질문이 올 때마다 결정되지 않았던 것들이 하나씩 결정되어 간다.
구현 기간은 코드를 쓰는 시간인 동시에, 사양의 누락이 발견되어 가는 기간이기도 했다.
AI는 손을 멈추지 않는다.
적혀 있지 않으면 그럴싸한 동작을 스스로 결정하고 앞으로 나아간다.
지난 프로젝트에서도 문서화하지 않았던 방침을 AI가 자체적인 해석으로 메워온 장면이 있었다.
10시간 후에 도착하는 것은 질문 뭉치가 아니라, 완성품의 얼굴을 한 성과물이다.
물어보기 전에 전부 되어 버린다.
그렇다면 판매물은 여기에 있다.
AI가 보증하지 않는 완성을 만드는 측에서 보증하는 것이다.
"우리는 이런 방식으로 만들기 때문에, 완성되어야 할 것이 완성되어 있음을 보증할 수 있습니다".
이 한 문장을 근거를 가지고 말할 수 있는 회사가 된다.
나는 이것을 완성 보증이라고 부르기로 했다.
AI로 빠른 것을 파는 것이 아니라, AI를 써도 망가지지 않는 것을 판다.
보증의 내용은 크게 두 가지로 나뉜다.
입구에서는 인풋의 품질을 높인다.
회의에서 고객의 말을 끌어내는 것은 인간의 일로 남아 있지만, 놓치지 않는 일은 시스템에 맡길 수 있다.
회의 기록으로부터 결정된 것과 미결정된 것을 분류하게 한다.
지난 결정과 모순되는 발언에 표시를 하게 한다.
결정하지 않은 것을 결정한 것처럼 착각한 채 앞으로 나아가지 못하게 한다.
인간은 끌어내는 것에 집중하고, 기억과 주의력에 대한 의존을 시스템으로 없애 나간다.
출구에서는 나온 것을 검품한다.
만든 것과 결정한 것을 기계로 대조하여, 차이가 있다면 인간의 눈에 닿기 전에 멈춘다.
체크리스트를 나눠주며 "주의합시다"라고 말하는 것이 아니라, 쓰레기가 발생하기 어려운 구조를 공정 그 자체에 심어 넣는다.
판단을 사람의 주의력에 맡기는 순간, 보증은 근거를 잃기 때문이다.
이러한 방식은 실력 있는 개인이라도 실현할 수 있다.
다만, 개인의 실력은 담당한 프로젝트 하나를 좋게 만드는 데 그친다.
그것을 시스템(仕組み)으로 바꾸어, 누가 담당하더라도 동일한 수준이 나오게 하면 회사 전체의 출력이 밑바닥부터 끌어올려진다.
프로젝트 단일의 이익과, 전사의 이익.
회사의 판매물이 되는 것은 후자 쪽이다.
그렇다면, 이 보증의 좋고 나쁨을 고객은 계약 전에 어떻게 판별할 것인가.
판별할 수 없다,는 것이 답이라고 생각한다.
제안서에는 어느 회사든 "요건 정의에 강하다", "품질에는 자신 있다"라고 쓸 수 있다.
쓸 수 있는 이상, 읽어도 차이를 알 수 없다.
인풋(Input)의 질도, 검수 시스템도, 프로젝트가 실제로 진행되기 전까지는 외부에서 보이지 않는다.
보이지 않을 때, 고객은 대안을 본다.
그것이 실적이다.
스포츠 업계의 앱을 만들고 싶은 회사가, 그 업계의 실적이 10건 있는 회사와 0건인 회사를 나란히 두었다고 가정해보자.
최종 결정은 가격이나 제안의 질, 혹은 그날의 미팅에서 결정된다.
다만, 제안을 받을 확률이 다르다.
제안을 받지 못한다면, 제안의 질은 상관없다.
10건의 실적은 단순한 경험치가 아니다.
"이 회사는 우리 업계의 언어를 이해한다. 그러니 우리의 이야기를 정확하게 받아줄 것이다"라는 추정의 근거가 된다.
고객은 외부에서 보이지 않는 인풋의 질을 실적으로 대신 측정하고 있다.
게다가 이 추정은 대체로 맞는다.
10건을 수행한 업계라면, 고객이 말하는 것을 잊어버리는 항목들의 목록을 이미 손에 쥐고 있기 때문이다.
0건인 업계에서는 그것을 실전에서 배우게 된다.
실적은 질이 높다고 생각하게 만드는 재료인 동시에, 실제로 질을 높이는 축적(蓄積)이기도 하다.
그리고 이 실적은 구현 속도가 빨라진다고 해서 줄어들지 않는다.
공수(Man-hour)가 수십 분의 일로 줄어든다고 해서, 실적이 10배의 속도로 늘어나는 것은 아니기 때문이다.
실적이 늘어나는 속도를 결정하는 것은 개발 기간이 아니라, 문의(Inquiry)부터 수주까지의 사이클이다.
그 부분은 AI가 빠르게 만들지 못한다.
따라서 영업의 순서는 다음과 같다.
먼저, 현재 가지고 있는 실적을 정리하여 외부에 알린다.
어느 업계에서, 몇 건, 몇 년 동안, 어떤 고객과 지속해왔는지.
"무엇이든 합니다"가 아니라, 숫자로 말할 수 있는 영역을 만들어 자리를 잡는다.
첫 미팅에는 그 업계의 언어로 말할 수 있는 사람을 배치하여, 첫 단계부터 신뢰를 얻는다.
자리를 잡은 뒤에야 비로소 인풋과 아웃풋(Output)을 어떻게 보증할지를 전달하며 프로젝트로 연결한다.
실적이 자리를 만들고, 보증이 프로젝트를 결정한다.
완성 보증도, 그것을 뒷받침하는 시스템도, 글로 쓰면 전달될 정도로 언어화할 수 있다.
그렇다면 숨기고 싶어진다.
공들여 만든 차별화 요소를 왜 외부에 공개하는가.
하지만 "할 수 있다"는 사실이 알려진 시점에서, 확산은 이미 시작된 것이다.
절차를 숨긴다 해도, 조만간 모두가 같은 지점에 도달하게 된다.
그렇다면 절차를 숨길 의미는 없다.
어차피 모두가 도달할 장소를 숨기며 몇 달을 버는 것보다, 처음에 말한 회사로 알려지는 편이 제안을 받을 확률과 채용의 질 모두에 효과적이다.
수탁 개발의 원가는 사람이므로, 채용의 질은 곧바로 이익률이 된다.
게다가 공개해서 나가는 것은 시스템의 형태(型)뿐이다.
형태는 모방할 수 있어도, 실적은 모방할 수 없다.
이 업계에서는 어디서 넘어지는지, 고객은 무엇을 말하는 것을 잊어버리는지에 대한 목록은 기사로 쓸 수는 있어도, 읽는 것만으로는 손에 넣을 수 없다.
프로젝트를 거치지 않으면 늘어나지 않기 때문이다.
공개적으로 나누어주는 것은 지도일 뿐, 땅 그 자체가 아니다.
이 변화가 언제 올지는 나 자신도 말할 수 없다.
지금의 변화 속도로는 시기를 입에 올린 예측은 대개 틀린다.
다만, 순서라면 말할 수 있다.
도태는 변화를 이해하는 것이 늦은 회사부터 차례로 찾아온다.
그리고 이해하고 있는 회사들은 이미 움직이기 시작했다.
'속도'를 간판에서 내리고, '보증'과 '실적'을 간판에 올리는 작업을 조용히 진행하고 있다.
자사는 무엇을 파는 회사인가.
이 질문에 인월(Man-month) 이외의 언어로 답할 수 있는가.
답할 수 있는 회사부터 차례로 다음 시대로 살아남을 것이라고 생각한다.
본문은 사고방식에 관한 이야기였으므로, 마지막으로 저라면 이렇게 하겠다라는 절차를 생각해 보았기에 아래에 기재합니다.
프라임(Prime) 프로젝트 실적이 어느 정도 이상 있고, 회의록이나 과제 관리, 사양 변경 기록이 사내에 남아 있는 회사를 가정한다.
저라면 다음과 같은 순서로 만들겠습니다.
1. 실적을 정리(棚卸し)한다.
과거 프로젝트 실적을 업계별로 다시 분류하여, 건수, 지속 연수, 리피트(Repeat) 여부를 집계한다.
"무엇이든 합니다" 중에서 숫자로 말할 수 있는 영역을 2~3개 특정한다.
이것이 간판의 후보가 된다.
2. 과거 프로젝트를 발굴한다.
선택한 영역의 프로젝트에 대해 회의록, 사양 변경 이력, 장애 보고서를 AI에게 읽힌다.
추출하는 것은 세 가지다.
도중에 뒤집힌 결정, 나중에 발견된 누락된 발언, 실무(Production)에서 빠진 함정.
이것들을 업계별 목록으로 굳힌다.
500건의 기록은, 여기서 영업 실적 수에서 시스템의 원료로 변한다.
3. 입구의 시스템을 만든다.
회의 기록으로부터 결정 사항과 미결정 사항을 자동으로 분류하게 한다.
분류된 미결정 사항을 2에서 만든 목록과 대조한다.
"이 업계라면, 이 시점에서 결정되어 있어야 할 것"이 결정되어 있지 않다면, 다음 회의의 의제로 기계적으로 올라온다.
고객의 누락된 발언을, 고객보다 먼저 찾아내는 상태를 만든다.
4. 출구의 시스템을 만든다.
결정 목록과 결과물을 기계로 대조하여, 불일치가 있다면 사람의 눈에 닿기 전에 멈춘다.
이때, 찾아낸 건수만을 성적으로 삼지 않는다.
판정을 완화하면 건수는 얼마든지 늘어나므로, 오탐(False Positive)의 적음과 세트로 관리한다.
5. 사람을 배치한다.
실적이 가장 두터운 영역에, 해당 업계의 언어로 말할 수 있는 사람을 한 명 배치한다.
신규 첫 회의에는 반드시 이 사람이 참석한다.
첫 단추의 신뢰는 시스템만으로는 만들 수 없다.
6. 외부에 공개한다.
실적 수치와 시스템의 모델을 기사로 작성하여 공개한다.
숨겨서 지킬 수 있는 것은 원래 없다.
이 절차를 통해, 제로(Zero)에서 만드는 것은 거의 없다고 생각합니다.
원료는 과거 프로젝트로서 이미 사내에 존재하며, AI를 그것을 발굴하는 도구로 사용함으로써 위와 같은 일을 달성할 수 있을 것입니다.
저도 지금 몸담고 있는 회사에서 실제로 이러한 움직임을 할 수 있다면 좋겠습니다.
Twitter도 하고 있으니 가능하면 팔로우 부탁드립니다!
에노모소@enomoso
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기