요즘 창업 콘텐츠를 보면 비슷한 말이 계속 나옵니다. AI 덕분에 개발자 없이도 앱을 만들 수 있다, 아이디어만 있으면 혼자서도 스타트업을 할 수 있다, 기술 장벽이 사라졌다. 틀린 말은 아닙니다. 노코드 툴과 AI 코딩 도구를 섞어서 MVP를 빠르게 뽑아내는 사람이 실제로 늘었고, 몇 년 전이면 개발팀이 붙어야 했을 일을 혼자서 훨씬 짧게 해내는 경우도 분명히 있습니다.
그런데 그 말을 반대편에서 보면 좀 불편한 문장이 나옵니다. 누구나 같은 걸 만들 수 있다는 겁니다.
진입장벽이 낮아졌다는 건 저한테만 낮아진 게 아니라 경쟁자한테도 똑같이 낮아졌다는 얘기입니다. 제가 AI로 사흘 만에 만든 걸 다른 누군가도 AI로 사흘 만에 베낄 수 있습니다. 며칠 전에 멀티 에이전트 플랫폼 하나가 통째로 npx 한 줄에 깔리는 구조를 뜯어봤는데, 그 한 줄도 저한테만 열려 있는 게 아니었습니다. 실행 속도로 차별화하던 때는 이미 끝났거나 끝나가는 것 같습니다. 그럼 뭘로 버티나 하는 생각이 들었습니다. 만드는 게 쉬워진 만큼 만든 걸 지키는 건 더 어려워진 것 같은데, 그 얘기는 콘텐츠에서 잘 안 나옵니다. 만드는 장면은 영상으로 찍기 좋고 지키는 장면은 찍을 게 별로 없어서 그런 것 같기도 합니다.
만약 제가 사흘 걸려 만든 걸 누가 하루 만에 그대로 따라 만들었다고 치면, 저는 뭘 들고 그 사람이랑 다르다고 말할 수 있을지 생각해봤습니다. 코드를 들고 가면 코드는 비슷할 겁니다. 같은 도구로 같은 요구를 넣었으니까요. 화면을 들고 가도 비슷할 겁니다. 요즘 도구가 뽑아주는 화면은 다들 어딘가 닮아 있습니다. 먼저 만들었다는 것 정도가 남는데, 그게 사용자한테 무슨 의미가 있는지는 잘 모르겠습니다. 사용자는 누가 먼저 만들었는지 궁금해하지 않고, 지금 자기 문제를 누가 더 잘 풀어주는지만 봅니다.
요즘 딸깍이라는 말을 자주 보는데, 저는 이 말이 좀 묘하다고 생각합니다. 버튼 한 번 누르면 된다는 뜻인데, 그 버튼은 누구 앞에나 똑같이 놓여 있습니다. 제가 누른 딸깍과 남이 누른 딸깍이 같은 결과를 낸다면 그 결과에 제 이름이 붙을 이유가 별로 없습니다. 딸깍이 쉬워질수록 딸깍 말고 제가 한 게 뭐였는지를 묻게 되는 것 같습니다.
장벽이 낮아지면
장벽이 낮아지면 처음엔 들어오는 사람이 늘고, 좀 지나면 가격 싸움이 시작됩니다. 차별화할 게 없으면 가격밖에 안 남고, 가격 싸움은 돈 많은 쪽이 이깁니다. AI라서 생긴 일이라기보다 원래 시장이 그렇게 돌아가는 것 같습니다.
인터넷이 처음 나왔을 때도 이제 누구나 쇼핑몰을 만들 수 있다는 말이 돌았습니다. 맞는 말이었는데 결과는 모든 쇼핑몰이 잘된 게 아니라 아마존과 쿠팡이 독차지한 쪽이었습니다. 기술 장벽이 낮아지자 그 빈 곳을 도메인 깊이와 자본이 채웠습니다. 앱스토어도 비슷했습니다. 개인 개발자가 대기업과 같은 플랫폼에서 경쟁할 수 있게 됐고 초기엔 실제로 개인이 대박을 내기도 했는데, 시간이 지나면서 마켓이 꽉 차고 사용자 한 명 데려오는 비용이 오르고, 결국 마케팅 자본과 브랜드가 있는 곳이 살아남았습니다.
가격 싸움이 쓰는 사람한테는 나쁘지 않은 일이라는 생각도 듭니다. 같은 걸 더 싸게 쓰게 되니까요. 그런데 만드는 쪽에서 보면 그 싸움은 오래 못 버팁니다. 혼자 만든 서비스는 가격을 내릴 여유가 처음부터 얇고, 0원 근처까지 내려가면 버티는 건 다른 데서 돈을 버는 회사뿐입니다. 그러면 쓰는 사람도 처음엔 고를 게 많다가 어느 순간 큰 곳 몇 개만 남은 걸 보게 될 텐데, 그게 쇼핑몰 때 본 그림이랑 크게 다르지 않습니다.
다만 이번엔 그 과정이 훨씬 빨리 지나갈 것 같다는 생각이 듭니다. 쇼핑몰이나 앱스토어 때는 그래도 따라 만드는 데 몇 달은 걸렸으니까, 먼저 들어간 사람이 그 몇 달 동안 사용자를 모으고 이름을 알릴 여유가 있었습니다. 따라 만드는 데 며칠이면 그 여유가 거의 없습니다. 먼저 들어가서 얻는 게 몇 달짜리 독점이 아니라 며칠짜리 독점이 되는 셈인데, 며칠 안에 사용자를 붙잡을 수 있는 서비스는 많지 않을 겁니다. 그러니 같은 결말이라도 이번엔 중간 단계가 짧아서, 개인이 대박을 내던 초기 구간 자체가 잘 안 보일 수도 있겠다는 생각을 했습니다.
AI도 비슷하게 가고 있는 것 같습니다. AI로 만든 제품이라는 것만으로 신기하던 때가 지나가고 있습니다. 초기에 AI 글쓰기 도구, AI 이미지 생성 서비스, AI 요약 툴이 쏟아졌는데, 그중 남은 건 AI를 써서가 아니라 특정 도메인에서 깊이가 있어서 남은 것 같습니다. AI는 수단이었고 차이는 다른 데서 났습니다. 같은 모델 API를 부르는 서비스가 열 개 있으면 모델 쪽에서는 차이가 날 데가 없으니, 남는 건 그 위에 뭘 얹었느냐뿐입니다.
같은 API를 부른다는 건 생각보다 무서운 얘기입니다. 모델이 좋아지면 열 개 서비스가 다 같이 좋아지고, 모델이 나빠지면 다 같이 나빠집니다. 내가 잘해서 좋아진 게 아니라 남이 잘해서 좋아진 거라, 그 좋아진 몫을 내 것이라고 부르기가 어렵습니다. 반대로 모델 회사가 같은 기능을 직접 내놓으면 열 개가 한꺼번에 설 데가 좁아집니다. 그 위에 얹은 게 얇을수록 그날이 빨리 올 거고요. 저는 그래서 그 위에 뭘 얹었느냐는 질문을 그 모델 회사가 직접 하기 귀찮은 게 뭐냐는 질문으로 바꿔서 보는 게 낫다고 생각합니다. 귀찮은 건 대개 특정 업계 안쪽의 사정이라, 거기서 다시 도메인 얘기로 돌아오게 됩니다.
모델 회사가 직접 하기 좋은 건 대개 누구한테나 필요한 일입니다. 요약, 번역, 글 다듬기 같은 것들이요. 그런 쪽에 서비스를 얹으면 언젠가 모델 회사가 같은 걸 기본 기능으로 넣는 날을 기다리는 꼴이 될 것 같습니다. 초기에 쏟아졌던 요약 툴 가운데 남은 게 많지 않은 것도 그런 이유가 아닐까 싶습니다. 누구한테나 필요한 일은 누구나 만들 수 있고, 그중 제일 크게 만들 수 있는 건 모델을 가진 쪽이니까요.
도메인을 AI가 이해해준다는 말
창업 쪽에서 이 말은 대개 이렇게 바뀝니다. 법률 지식 없이도 법률 서비스를 만들 수 있고, 의료 지식 없이도 헬스케어 앱을 만들 수 있고, 금융 전문가가 아니어도 투자 분석 툴을 만들 수 있다. 일부는 맞습니다. AI가 법률 문서를 요약하고, 의학 용어를 풀어주고, 재무제표를 분석하는 건 실제로 되고, 그걸 UI로 감싸서 서비스로 내는 것도 됩니다.
문제는 거기서 멈춘다는 데 있는 것 같습니다. 법률 서비스를 예로 들면, AI가 계약서 검토는 꽤 잘합니다. 그런데 실제로 누가 쓰느냐에 따라 필요한 게 완전히 다릅니다. 스타트업 창업자인지, 중소기업 법무팀인지, 임대차 계약서를 들여다보는 개인인지. 이 사람들이 어떤 말로 묻고, 어떤 모양의 답을 원하고, 그 답을 어디에 쓰는지는 AI가 법률 지식을 갖고 있다고 저절로 풀리지 않습니다. 사용자를 직접 만나고, 실패하고, 피드백 받고, 고치면서 쌓이는 겁니다.
임대차 계약서를 보는 개인을 떠올려보면 이게 좀 더 분명해집니다. 그 사람은 아마 특약의 효력 같은 말로 묻지 않을 겁니다. 이 조항 있으면 나중에 보증금 못 받는 거 아니냐, 집주인이 이거 빼달라고 하면 빼줘야 하냐, 이런 식으로 물을 것 같습니다. 그리고 그 사람한테 필요한 답은 법 조문 해설이 아니라 내일 부동산에 가서 뭐라고 말하면 되는지일 겁니다. AI는 법을 알지만 그 사람이 내일 부동산에서 어떤 표정으로 앉아 있을지는 모릅니다. 그 표정까지 알려면 그런 사람을 여러 번 만나봐야 하고, 그건 서비스를 내놓고 나서야 시작되는 일이라 MVP 만드는 사흘 안에는 들어 있지 않습니다.
창업자와 법무팀은 또 다르게 물을 겁니다. 창업자는 이 계약에 그냥 서명해도 되는지를 알고 싶고, 법무팀은 이미 아는 걸 빨리 확인하고 싶어 할 것 같습니다. 같은 계약서 검토라도 앞쪽에는 쉬운 말로 된 한 줄 답이, 뒤쪽에는 근거 조항이 촘촘히 붙은 정리가 필요할 수 있습니다. 하나의 서비스로 둘 다 만족시키려고 하면 어느 쪽도 다음 날 다시 열지 않을 것 같습니다. 결국 누구를 위한 서비스인지부터 정해야 하는데, 그걸 정하려면 그 사람들을 먼저 알아야 합니다.
의료도 그렇습니다. 증상을 받아서 가능한 질환 목록을 뽑는 건 기술적으로 어렵지 않은데, 그걸 병원에 납품하고, 환자가 쓰게 만들고, 보험 청구 시스템과 붙이고, 의료기기 인증을 받는 과정은 AI가 모르는 영역입니다. 규제와 관행과 이해관계가 엉켜 있고 그걸 아는 사람이 따로 있습니다. 지식을 갖고 있는 것과 그 지식을 특정한 맥락에서 제대로 쓰이게 만드는 건 다른 일이고, 뒤쪽이 없으면 서비스가 아니라 데모에 그칩니다. 데모는 보는 사람을 놀라게 하면 되지만 서비스는 쓰는 사람이 다음 날 또 열어야 하는데, 다음 날 또 열게 만드는 건 대개 기능보다 그 사람 사정을 얼마나 알고 있느냐인 것 같습니다.
의료 얘기를 하다 보면 규제가 늘 장벽처럼 들리는데, 저는 이게 꼭 나쁜 장벽만은 아니라고 봅니다. 사흘 만에 베낄 수 없는 몇 안 되는 것 중 하나가 규제를 통과해본 경험이라서요. 서류를 어떻게 준비하는지, 담당 기관이 무엇을 먼저 보는지 같은 건 AI한테 물어도 일반론만 나올 거고, 한 번 통과해본 사람은 두 번째가 훨씬 쉬울 겁니다. 만드는 사람 입장에선 귀찮은 장벽이 지키는 사람 입장에선 해자가 되는 셈입니다.
밖에서 어떤 업계를 보면 이상해 보이는 게 꼭 있습니다. 왜 아직도 이걸 종이로 하지, 왜 이 단계를 사람이 한 번 더 확인하지, 왜 이렇게 느리게 하지. AI로 창업하려는 사람 눈에는 그게 전부 기회로 보일 겁니다. 이 비효율을 없애주면 되겠다 싶어서요. 그런데 저는 그런 걸 보면 먼저 그게 왜 거기 있었을까가 궁금합니다. 한 번 더 확인하는 단계는 아마 예전에 누가 한 번 크게 틀렸기 때문에 생겼을 거고, 종이로 남기는 건 나중에 누가 책임질지를 정하려고 남겨둔 것일 수도 있습니다. 이유를 모르고 그 단계를 없앤 서비스는 처음엔 빠르고 편해 보이다가, 그 단계가 막고 있던 일이 터지는 날 한꺼번에 값을 치를 것 같습니다.
그 업계 안에 있던 사람은 이걸 압니다. 어떤 단계는 정말 쓸데없어서 없애도 되고, 어떤 단계는 귀찮아 보여도 절대 빼면 안 된다는 걸요. 밖에 있는 사람한테는 둘이 똑같이 비효율로 보입니다. AI한테 물어봐도 아마 둘 다 자동화할 수 있다고 답할 겁니다. 그러니 도메인 깊이라는 게 거창한 전문 지식이라기보다, 어떤 걸 없애면 안 되는지 아는 감각에 더 가까운 것 같다는 생각이 듭니다.
데모와 서비스 사이가 이렇게 멀다는 걸 AI가 오히려 가리고 있는 것 같기도 합니다. 예전엔 데모를 만드는 것부터 힘들었으니까, 데모까지 온 사람은 그동안 그 도메인을 좀 들여다볼 수밖에 없었습니다. 만들면서 막히고, 막힌 데를 물어보러 다니면서 자연스럽게 업계 사람을 만났을 겁니다. 지금은 데모가 너무 쉽게 나와서 그 과정을 건너뛰고도 데모에 도착합니다. 도착하고 나면 다 된 것처럼 보이는데, 실제로는 출발선에 와 있는 거라고 봅니다. 그 착각이 제일 비싼 것 같습니다.
한편으로는 이게 도메인을 아는 사람한테는 기회일 수도 있겠다는 생각이 듭니다. 예전엔 업계를 잘 알아도 만들 줄 몰라서 아이디어로만 끝났던 사람들이 이제는 직접 데모를 만들 수 있으니까요. 그런 사람이 만든 데모는 출발선이 아니라 이미 몇 걸음 나가 있는 상태일 겁니다. 그렇게 보면 AI가 낮춘 장벽의 덕을 제일 크게 보는 건 개발자가 아니라 개발을 모르던 업계 사람일지도 모릅니다.
AI는 장르는 아는데 회사는 모른다는 얘기를 나중에 개발자 쪽에서 따로 적은 적이 있는데, 창업 쪽에서 보면 그게 더 크게 보입니다. 회사 안에 있는 개발자는 적어도 옆 팀에 물어볼 사람이라도 있지만, 혼자 창업한 사람은 물어볼 사람부터 직접 찾아야 하니까요.
부동산 분석 서비스를 만든다면
AI로 부동산 투자 분석 서비스를 만든다고 쳐보겠습니다. 주소를 넣으면 주변 시세, 임대 수익률, 앞으로의 가격 전망을 뽑아주는 서비스입니다. 데이터를 긁어와서 분석하는 부분은 꽤 그럴싸하게 나올 거고 MVP는 2주도 안 걸릴 수 있습니다.
2주면 정말 짧은 시간이고, 그 2주 동안 만드는 사람은 아마 꽤 신이 날 겁니다. 주소를 넣으면 그래프가 나오고 숫자가 나오고 그럴듯한 문장으로 전망까지 붙으니까요. 그 그럴듯함이 오히려 문제를 늦게 알아채게 만드는 것 같습니다. 결과가 엉성하면 뭔가 빠졌다는 걸 바로 아는데, 결과가 매끈하면 빠진 게 있다는 생각 자체를 잘 안 하게 됩니다.
매끈한 결과를 보면 저는 오히려 이게 다 됐다는 말을 믿어도 되나 싶어집니다. 화면에 숫자가 나왔다는 건 계산이 돌았다는 뜻이지, 그 계산이 맞았다는 뜻은 아니니까요. 만드는 사람이 그 차이를 구분할 수 있으려면 적어도 몇 개 주소는 결과가 틀렸다는 걸 알아볼 수 있어야 하는데, 그건 결국 부동산을 아는 사람만 할 수 있는 일입니다.
그런데 실제 사용자가 붙으면 문제가 쌓일 겁니다. 서울의 어떤 재건축 단지는 실거래가와 호가가 극단적으로 차이 나는데, 왜 그런지 모르면 분석이 엉터리가 됩니다. 토지거래허가구역으로 지정됐는지가 투자할 수 있느냐 자체를 바꾸는데, 그 규제가 어디에 어떻게 걸리는지는 공공 API에 깔끔하게 정리돼 있지 않습니다. 재개발 조합원 입주권과 일반 분양의 차이, 분양권 전매 제한 기간, 취득세 중과 기준 같은 게 실제 결정에서 아주 중요한데 AI가 일반적인 부동산 지식을 안다고 이런 맥락까지 알아서 처리하지는 못합니다.
재밌는 건 이런 문제가 만드는 사람 눈에는 거의 안 보일 거라는 점입니다. 만드는 사람이 테스트로 넣어보는 주소는 아마 자기가 아는 동네거나 평범한 아파트일 거고, 거기서는 결과가 그럴듯하게 나옵니다. 문제가 생기는 건 재건축이 걸려 있거나 규제가 붙어 있는 주소인데, 실제로 투자 분석이 필요한 사람은 바로 그런 주소를 넣습니다. 평범한 주소는 굳이 분석을 안 돌려도 대충 감이 오니까요. 그러니 테스트에서 잘 돌던 서비스가 진짜 사용자를 만나는 첫날부터 제일 어려운 경우만 받게 되는 셈입니다.
그러면 사용자는 틀린 결과를 받고 떠나거나, 더 나쁘면 그 결과를 믿고 잘못된 결정을 합니다. 기능은 도는데 도메인이 빠진 서비스라, 겉으로는 그럴싸한데 실제로 쓰는 순간 버티지 못합니다. 게다가 이 약점은 경쟁자도 똑같이 갖고 있습니다. 다들 비슷한 수준에서 싸우게 되고, 그러다 보면 가격을 낮추거나 디자인을 다듬거나 마케팅에 돈을 쓰는 식으로 도메인 바깥에서 차이를 만들려고 합니다. 그 싸움도 결국 돈 많은 쪽이 유리합니다. 혼자 사흘 만에 만든 서비스가 그 싸움에 들어가면 사흘 만에 만든 장점은 금방 의미가 없어지고, 버틸 돈이 얼마나 있느냐만 남습니다.
틀린 결과를 믿고 결정했다는 쪽이 저는 계속 마음에 걸립니다. 부동산은 한 번 결정하면 몇 년을 묶이는 일이라, 앱이 틀렸다고 다음 날 지우고 다른 앱을 깔면 끝나는 문제가 아닙니다. 그때 그 결과를 누가 책임지느냐고 물으면 만든 사람도 할 말이 별로 없을 것 같습니다. AI가 그렇게 분석했다고 하면 사용자는 납득하지 않을 거고, 참고용이라고 적어뒀다고 하면 그럼 이 서비스는 왜 쓰냐는 얘기가 나올 겁니다. 만약 그 업계에서 오래 일한 사람이 같은 서비스를 만들었다면, 아마 처음부터 이 주소는 분석이 어렵다고 솔직하게 말해주는 화면을 먼저 만들었을 것 같습니다. 그런 화면은 기능 목록에는 안 들어가는데, 쓰는 사람한테는 그게 제일 고마운 기능일 수도 있습니다.
만약 그 서비스가 잘돼서 사용자가 늘면 문제는 오히려 커질 수도 있습니다. 사용자가 적을 때는 틀린 결과도 몇 건이지만, 많아지면 틀린 결과를 믿는 사람도 같이 늘어납니다. 성장이 위험까지 같이 키우는 서비스인데, 도메인을 모르면 그 위험이 얼마나 쌓였는지도 모릅니다. 대시보드에 찍히는 건 가입자 수와 사용 시간이지, 틀린 분석의 수가 아니니까요.
속도
AI로 빠르게 만드는 게 경쟁력이라는 말도 많이 듣습니다. 빠른 건 좋습니다. 그런데 빠른 게 오래 가는 우위가 되려면 빨리 쌓은 게 베끼기 어려운 무언가로 이어져야 할 것 같습니다.
빠르다는 게 누구한테 빠른 건지도 좀 생각해보게 됩니다. 만드는 사람한테 빠른 거랑 쓰는 사람 문제가 빨리 풀리는 건 다른 얘기라서요. 사흘 만에 나온 서비스가 쓰는 사람 문제는 하나도 못 풀어줄 수도 있고, 석 달 걸린 서비스가 첫날부터 그 사람 하루를 바꿔놓을 수도 있습니다. 창업 콘텐츠에서 말하는 속도는 대개 앞쪽인데, 쓰는 사람이 느끼는 건 뒤쪽뿐입니다.
스타트업 쪽에서 해자라고 부르는 게 있습니다. 경쟁자가 쉽게 못 넘어오게 만드는 구조적인 우위요. 네트워크 효과, 전환 비용, 규모의 경제, 독점 데이터, 브랜드 같은 것들이 전통적인 해자였습니다. 이 글을 쓰고 며칠 뒤에 그 해자가 하루 만에 얇아지는 장면을 피그마 주가가 8.7% 빠진 날의 기록으로 따로 적었는데, 디자인 도구 하나의 얘기로 끝나지 않았습니다.
그 목록을 하나씩 보면 AI가 얇게 만드는 것과 그렇지 않은 것이 좀 다르게 느껴집니다. 기능을 많이 갖춰서 생기던 전환 비용은 AI가 꽤 쉽게 낮추는 것 같습니다. 옮겨 가는 데 드는 수고를 AI가 대신 해줄 수 있으니까요. 반면 네트워크 효과는 AI가 복사해주지 못합니다. 사람들이 이미 거기 모여 있다는 건 코드로 만들 수 있는 게 아니라서요. 브랜드도 비슷한 쪽에 있다고 봅니다. 그러면 혼자 만든 작은 서비스가 노릴 수 있는 건 뭘까 생각해보면, 네트워크도 브랜드도 처음엔 없으니 결국 아래에 쓰는 도메인 쪽밖에 안 남는 것 같습니다. 브랜드도 처음엔 거기서 시작하는 경우가 많을 것 같습니다. 어떤 업계에서 저 서비스는 우리 사정을 안다는 말을 듣는 게, 작은 서비스가 가질 수 있는 첫 번째 브랜드일 테니까요. 그 말은 광고로 사기 어렵고, 사용자 몇 명이 직접 써보고 나서야 나옵니다.
AI 시대에 새로 붙는 해자가 하나 있다면 도메인 데이터와 도메인 피드백 루프인 것 같습니다. 사용자가 쓸수록 그 도메인에 맞는 데이터가 쌓이고, 그걸로 모델을 파인튜닝하거나 RAG 파이프라인을 다듬으면, 나중에 들어온 쪽이 같은 AI 도구를 써도 따라잡기 어려운 차이가 생깁니다. 다만 이 루프가 돌려면 도메인을 아는 사람이 어떤 데이터를 어떻게 쌓을지를 설계해야 합니다. AI가 혼자 만들어주는 루프는 아닙니다. 뭘 남겨야 나중에 쓸모가 있을지는 그 일을 오래 해본 사람이 제일 잘 알고, 그걸 모르고 쌓은 데이터는 양만 많고 쓸 데가 없는 경우가 많을 것 같습니다.
저는 이 루프에서 제일 값진 게 처음 몇 명의 사용자가 남긴 불만이라고 생각합니다. 처음 쓰는 사람들은 아직 서비스에 길들지 않아서, 어디가 이상한지 제일 솔직하게 말해줍니다. 그 불만을 그냥 버그 목록으로 받으면 고치고 끝이지만, 왜 그 사람이 거기서 막혔는지를 받아 적으면 그게 도메인 지식이 됩니다. 같은 불만을 경쟁자도 받을 수는 있는데, 그걸 버그로 받느냐 지식으로 받느냐는 받는 사람이 그 도메인을 얼마나 아느냐에 달려 있을 것 같습니다. 그러니 속도가 의미 있는 건 그 불만을 남보다 빨리 받기 시작한다는 데까지인 것 같고, 그다음부터는 받은 걸로 뭘 하느냐의 싸움이 됩니다.
속도에 대해 하나 더 떠오르는 건, 빨리 만드는 게 빨리 포기하게도 만든다는 겁니다. 사흘 만에 만든 건 사흘 만에 버려도 아깝지 않습니다. 그게 장점일 때도 있는데, 도메인 지식은 대개 버리고 싶어질 때쯤 쌓이기 시작하는 것 같습니다. 처음 몇 주는 아무도 안 쓰고, 쓰는 사람이 생겨도 불만만 들어오고, 그 불만을 몇 번 고치고 나서야 이 업계가 어떻게 돌아가는지 감이 오는 식이요. 만드는 데 석 달을 쓴 사람은 그 구간을 어떻게든 버티려고 할 텐데, 사흘을 쓴 사람은 그냥 다음 아이디어로 넘어가기 쉽습니다. 그러면 사흘짜리 제품을 열 개 만든 사람이 석 달짜리 하나를 끝까지 붙든 사람보다 도메인을 덜 알게 될 수도 있겠다는 생각이 듭니다.
속도는 처음 들어갈 때는 유리합니다. 그런데 들어간 다음에는 깊이가 살아남느냐를 정하는 것 같습니다. 빨리 만들어서 빨리 배우고 그 배움을 도메인 깊이로 바꾸는 과정이 없으면, 빨리 만들어서 빨리 사라지는 거랑 크게 다르지 않을 겁니다.
아이디어
창업하는 사람들이 아이디어를 너무 크게 보는 경우가 많습니다. 남이 베끼면 어쩌나 걱정하는데, 실제로 아이디어 자체는 거의 보호받지 못합니다. 실행이 전부이고, 실행하면서 쌓이는 도메인 지식이 진짜 자산이라고 봅니다.
아이디어를 감추려는 마음은 이해가 갑니다. 그런데 AI 시대에는 그 걱정이 좀 엉뚱한 데를 보고 있는 것 같습니다. 아이디어를 감춰도 비슷한 생각을 한 사람은 이미 어딘가에 있고, 그 사람도 사흘이면 만듭니다. 감춰서 얻는 건 거의 없고, 감추느라 사용자를 늦게 만나는 손해는 꽤 큽니다. 차라리 아이디어를 일찍 꺼내서 그 도메인 사람들한테 이게 진짜 문제냐고 물어보는 쪽이 낫다고 봅니다. 아니라는 답을 들으면 사흘을 아낀 거고, 맞다는 답을 들으면 처음 사용자가 생긴 거니까요.
AI가 실행 비용을 낮춰준 건 좋은 일입니다. 그런데 그건 아이디어에서 프로토타입까지가 짧아졌다는 뜻이지, 프로토타입에서 살아남는 서비스까지가 짧아졌다는 뜻은 아닌 것 같습니다. 법률 AI, 의료 AI, 부동산 AI, 교육 AI는 이미 카테고리마다 서비스가 수십 개씩 있습니다. 거기서 남는 건 AI를 제일 잘 쓰는 곳이 아니라 그 도메인 사용자를 제일 잘 아는 곳일 겁니다. 사용자가 어떤 맥락에서 쓰는지, 어떤 말로 문제를 꺼내는지, 어디서 막히는지는 그 도메인 안에서 시간을 보낸 사람이 압니다. AI가 장벽을 낮춘 결과가 오히려 도메인 전문성의 값을 올려놓았습니다. 기술로는 더 이상 차이를 못 내니까 남는 게 결국 그것뿐이라서요.
카테고리마다 서비스가 수십 개라는 건 쓰는 사람 입장에서는 고르기가 어렵다는 뜻이기도 합니다. 다 비슷해 보이면 아마 제일 먼저 본 걸 쓰거나 제일 많이 들어본 걸 씁니다. 그러면 다시 마케팅과 브랜드 얘기가 되는데, 저는 도메인 깊이가 거꾸로 마케팅이 되는 경우도 있다고 봅니다. 그 업계 사람들이 쓰는 말로 자기 문제를 정확히 짚어주는 서비스는 광고를 덜 해도 그 업계 안에서 입으로 퍼질 것 같습니다. 업계라는 게 밖에서 보는 것보다 좁아서요. 좁다는 건 거꾸로 한 번 틀리면 그것도 빨리 퍼진다는 얘기일 겁니다. 그 업계 사람들이 보기에 뭘 모르고 만든 티가 나면 그 얘기도 입으로 퍼질 테니까요. 도메인을 모르는 서비스가 좁은 업계에 들어가면 처음 몇 명한테 남긴 인상이 꽤 오래 따라다닐 것 같습니다.
그래서 이런 판에서 창업을 생각한다면 AI로 뭘 만들 수 있나보다 내가 직접 겪은 문제가 뭔가를 먼저 묻게 될 것 같습니다. 직접 겪었다는 건 그 도메인 안에 있었다는 얘기입니다. 그 업계에서 일했거나, 그 서비스를 엄청 많이 썼거나, 그 문제를 계속 만났거나. 10년 동안 병원 원무과에서 일한 사람이 의료 행정 AI 툴을 만드는 것과, 병원을 모르는 사람이 병원에 필요한 AI를 만드는 건 출발점부터 다릅니다. 앞의 사람은 어디서 일이 막히는지, 어떤 규정이 예외를 만드는지, 어떻게 말해야 의사와 간호사가 알아듣는지를 압니다. AI는 그 지식을 키워줄 수는 있어도 없는 지식을 만들어주지는 않습니다. 같은 도구를 손에 쥐어도 어디를 먼저 고쳐야 하는지 아는 사람과 모르는 사람은 첫 주에 만드는 것부터 달라질 것 같습니다.
원무과 얘기를 하고 나니 하나 더 떠오르는 게 있습니다. 그 사람이 AI 툴을 만든다면 제일 먼저 고치고 싶은 건 아마 화려한 기능이 아니라 매일 반복되는 사소한 귀찮음일 겁니다. 밖에서 보면 그게 왜 문제인지도 모를 만큼 작은 거요. 그런데 그 작은 귀찮음이 하루에 수십 번씩 반복되면, 그걸 없애주는 도구는 쓰는 사람한테 아주 크게 느껴집니다. 밖에 있는 사람은 그 귀찮음을 모르니 고칠 생각을 못 하고, 대신 그럴듯해 보이는 큰 기능을 만듭니다. 큰 기능은 베끼기 쉽고 작은 귀찮음을 정확히 아는 건 베끼기 어렵다는 게 좀 아이러니합니다.
이 질문을 저한테 해보면 바로 답이 안 나옵니다. 개발 말고 제가 깊이 안다고 말할 수 있는 도메인이 뭔지 떠올려보면 좀 막막합니다. 개발자는 남의 도메인을 코드로 옮겨주는 일을 오래 해와서, 여러 도메인을 조금씩 아는데 깊이 아는 건 개발 하나뿐인 경우가 많은 것 같습니다. 예전엔 그게 약점이 아니었습니다. 옮겨주는 기술이 귀했으니까요. 그런데 옮겨주는 일을 AI가 많이 가져가면, 옮겨줄 내용을 가진 쪽이 더 유리해집니다. 원무과에서 10년 일한 사람이 AI 도구만 손에 익히면 되는 것과, 개발자가 원무과 10년을 따라잡아야 하는 것 중에 어느 쪽이 빠를지는 잘 모르겠지만, 앞쪽이 더 빠를 것 같다는 쪽으로 자꾸 생각이 기웁니다.
그렇다고 개발자가 할 게 없다는 얘기는 아닌 것 같습니다. 개발 자체를 도메인으로 보면, 개발자가 겪는 불편을 제일 잘 아는 건 개발자입니다. 개발 도구나 개발자를 위한 서비스가 계속 나오는 것도 그래서일 겁니다. 다만 그 시장은 개발자 전부가 들어가려는 곳이라 붐빌 수밖에 없고, 거기서도 결국 누가 그 불편을 더 오래, 더 자세히 들여다봤느냐로 차이가 날 것 같습니다. 어느 도메인으로 가든 같은 질문이 따라오는 셈입니다. 개발자라서 개발 쪽을 고르는 것과, 개발 쪽 불편을 남들보다 오래 붙들고 있어서 고르는 건 출발점이 꽤 다를 것 같습니다.
혼자 만드는 사람한테는 이게 좀 더 무겁게 다가올 것 같습니다. 팀이 있으면 도메인을 아는 사람과 만드는 사람이 나눠서 맡을 수 있는데, 혼자면 둘 다 해야 합니다. AI가 만드는 쪽을 덜어줬으니 그만큼 도메인 쪽에 시간을 쓸 수 있게 됐다고 볼 수도 있고, 그게 제일 좋은 그림일 겁니다. 그런데 실제로는 덜어진 시간을 또 다른 기능을 만드는 데 쓰게 되기 쉬울 것 같습니다. 만드는 게 쉬우니까 자꾸 만들게 되고, 사용자를 만나러 가는 일은 어렵고 어색하니까 뒤로 밀립니다. AI가 만드는 일을 쉽게 만든 게 거꾸로 만드는 일에만 머무르게 하는 쪽으로 작용할 수도 있겠다는 생각이 듭니다.
만약 제가 지금 혼자 뭔가를 만든다면, 만드는 데 쓴 시간과 사용자를 만나는 데 쓴 시간을 따로 적어두고 싶을 것 같습니다. 앞쪽이 뒤쪽보다 훨씬 많아지는 순간을 알아챌 수 있게요. 그렇게 해도 지켜질지는 잘 모르겠습니다. 만드는 쪽은 결과가 바로 보이고 사용자를 만나는 쪽은 결과가 늦게 보이니까, 사람은 아마 바로 보이는 쪽으로 계속 끌려갈 겁니다.
이렇게 적고 보니 AI가 나오기 전에도 하던 얘기랑 크게 다르지 않다는 생각도 듭니다. 도메인을 알아야 한다, 사용자를 만나야 한다는 건 창업 책마다 있던 말입니다. 달라진 게 있다면 예전엔 그 말을 안 지켜도 만드는 게 어려워서 경쟁자가 적었는데, 이제는 만드는 게 쉬워서 그 말을 안 지킨 사람끼리 바로 부딪힌다는 정도인 것 같습니다. 같은 말인데 어겼을 때 치르는 값이 커졌습니다.
AI 도구를 쓴다는 것만으로 특별하던 때는 이미 지났고, 이제는 쓰는 게 기본이고 그 위에서 뭘 만드느냐가 남았습니다. AI는 도메인을 코드로 옮기는 속도를 올려주지만, 도메인을 이해하고 사용자를 만나 피드백을 받고 실패하면서 맥락을 쌓는 일은 줄여주지 못하는 것 같습니다. 빨리 만들어서 빨리 나가는 건 여전히 중요한데, 나간 다음에 도메인을 파고들지 않으면 더 빨리 베낀 쪽한테 밀릴 거라고 봅니다.
댓글
댓글 쓰기