AI가 인디해커를 없애지 않는 이유

토니 딘은 AI가 인디해커를 없애지 않을 것이라고 썼다. 그의 표현대로라면 10년의 소프트웨어 개발 경험이 예전과 같은 희소성을 갖지 못할 수는 있다. 그래도 가치 있는 문제를 찾고, 고객을 찾고, 실제로 해결하는 능력은 남는다. AI가 없애는 것은 코딩의 마찰이지, 고객의 문제 자체가 아니다.

임베딩이 보이지 않으면 X 원문에서 확인할 수 있다.

인디해커의 오래된 작업 순서는 대체로 이랬다. 문제를 고르고, 해결 방법을 설계하고, 코드를 쓰고, 제품을 공개하고, 사용자의 반응을 기다린다. 이 중 코드 작성에 시간이 많이 걸렸기 때문에 개발 경험이 곧 실행 속도였다. 혼자 일하는 사람에게는 특히 그랬다.

AI는 이 순서를 압축한다. 화면을 만들고, API를 연결하고, 오류를 고치고, 배포에 필요한 파일을 준비하는 데 드는 시간이 짧아진다. 아이디어를 시험하는 비용이 내려가면 더 많은 사람이 제품을 만들 수 있다. 토니가 말한 “새로운 문제의 종류”는 여기서 시작된다.

만드는 속도가 빨라질수록 고르는 일이 어려워진다

모두가 빠르게 만들 수 있다면 제품의 희소성은 구현 속도에서 다른 곳으로 옮겨간다. 어떤 문제가 반복되고 있는지, 누가 그 문제 때문에 돈과 시간을 쓰는지, 기존 도구가 왜 충분하지 않은지를 알아내야 한다. 코드가 완성됐다는 사실은 고객이 필요로 한다는 증거가 아니다.

AI가 만든 첫 버전은 이 질문을 대신 답해주지 않는다. 오히려 답을 확인하기 전에 구현물이 생겨서, 만든 사람을 착각하게 만들 수 있다. 랜딩 페이지와 결제 화면이 있어도 고객 인터뷰가 없고, 문의가 없고, 반복 사용이 없다면 아직 문제를 찾은 것이 아니다.

그래서 인디해커의 다음 경쟁력은 기술 스택을 많이 아는 데서 나오기보다 문제와 고객을 가까이에서 관찰하는 데서 나올 가능성이 크다. 특정 사용자가 어떤 문장을 반복하는지, 어떤 작업을 엑셀과 메신저로 억지로 이어 붙이는지, 기존 제품에서 무엇을 포기하고 있는지를 알아야 한다. AI는 그 관찰을 제품으로 옮기는 시간을 줄여준다.

새 문제의 종류는 제품 바깥에도 있다

구현이 쉬워지면 경쟁자는 비슷한 기능을 금방 따라온다. 그러면 제품이 해결하는 문제뿐 아니라, 신뢰를 얻는 방식과 유통 경로도 제품의 일부가 된다. 고객이 왜 이 도구를 발견하는지, 기존 업무에 어떻게 넣는지, 결과를 믿고 계속 쓰는지까지 설계해야 한다.

이런 변화는 “개발자는 필요 없다”는 식의 결론과 다르다. 개발자의 가치가 코드 타이핑에만 있었다면 압박을 받겠지만, 문제를 구조화하고 시스템의 한계를 판단하고 고객의 요구를 제품으로 번역하는 일은 여전히 남는다. 오히려 작은 팀에서는 이 판단이 코드보다 더 자주 필요해진다.

토니 딘의 주장은 단순하다. AI는 인디해커의 손을 묶고 있던 마찰을 줄인다. 그만큼 많은 사람이 만들 수 있게 되지만, 무엇을 만들지 결정하는 일은 더 중요해진다. 새 도구를 먼저 고르기 전에 고객이 지금 어떤 문제를 돈을 내고라도 없애고 싶은지부터 찾아야 한다.