AI가 앱을 무한정 찍어내도, 결국 부족한 건 코드가 아니라 관심이다

• AI가 코드를 더 많이 쓰게 만든 건 맞는데, 그게 곧 사람들이 쓰는 제품이 늘었다는 뜻은 아님

  • 전미경제연구소 워킹 페이퍼를 바탕으로 한 분석에 따르면, 에이전트형 AI 이후 iOS 앱 출시 수는 폭발적으로 늘었음
  • 그런데 앱 리뷰 수나 실사용 앱 수는 거의 같이 늘지 않았음
  • 결론은 꽤 냉정함. 앱은 더 많아졌는데, 새로 쓰는 사람은 별로 안 생김

• 개발자 생산성을 “코드 몇 줄 더 썼냐”로 재면 AI 시대에는 착시가 심해짐

  • 깃허브 개발자 10만 명 이상을 추적한 연구에서 AI 자동 완성, 대화형 에이전트, 자율 에이전트는 순수 코딩 활동을 확실히 끌어올렸음
  • 커밋 기준 누적 효과는 각각 40%, 140%, 180%까지 나왔음
  • 숫자만 보면 “와, 생산성 혁명이다” 싶은데, 실제 릴리즈까지 가면 이야기가 달라짐

• 연구자들은 이걸 “약한 고리 문제”라고 봄

  • 강한 고리인 코드 작성은 AI 덕분에 훨씬 강해졌음
  • 하지만 무엇을 만들지 정하고, 시스템에 통합하고, 검증하고, 유지보수하고, 사용자의 신뢰를 얻는 일은 여전히 사람이 해야 함
  • AI와 인간 노력 간 대체 탄력성 추정치는 0.25였는데, 쉽게 말하면 “AI가 사람을 대체한다”보다 “AI와 사람이 서로 보완한다”에 가까움

• 소프트웨어가 무한 공급에 가까워질수록 진짜 희소한 건 코드가 아니라 관심, 신뢰, 갈아탈 이유임

  • 사용자의 시간과 예산은 그대로인데 앱만 늘어나면, 선택받는 난이도는 더 올라감
  • 그래서 브랜드, 유통 채널, 문서화, 커뮤니티, 기술 교육 같은 개발자가 종종 낮게 보는 영역이 더 중요해짐
  • 오픈소스 프로젝트도 마찬가지임. “코드는 깃허브에 있으니 알아서 오겠지”는 이제 거의 판타지에 가까움

• 리싱크DB 사례가 이 논점을 잘 보여줌

  • 리싱크DB는 정확성, 단순성, 일관성 측면에서 기술적으로 훌륭한 데이터베이스였다고 평가받았음
  • 그런데도 몽고DB에 시장에서 밀렸고, 창업자는 나중에 “좋은 제품”을 사용자 기준이 아니라 기술 기준으로 정의한 게 문제였다고 돌아봤음
  • AI 시대에는 이런 작은 리싱크DB가 더 빠르게, 더 그럴듯한 랜딩 페이지까지 달고 쏟아지는 셈임

• 개발자들이 싫어하는 건 마케팅 전체가 아니라, 개발자를 얕게 보는 마케팅에 가까움

  • 깊이 있는 튜토리얼, 실습 중심 교육, 현장 엔지니어링 지원도 넓게 보면 전부 마케팅임
  • 몽고DB와 오라클에서 개발자 릴레이션 팀이 했던 일도 결국 개발자가 기술을 이해하고 써보게 만드는 활동이었음
  • 유명 스포츠 경기 광고만 마케팅인 게 아니라, “이걸 왜 써야 하는지”를 제대로 전달하는 모든 과정이 마케팅임

• 엔보이(Envoy) 창시자 맷 클레인의 경험도 비슷함

  • 2016년과 2017년 초 프로젝트를 키우기 위해 했던 핵심 작업은 순수 기술 작업이 아니었다고 함
  • 리더십, 홍보, 마케팅, 문서화 같은 일이 대부분이었고, 혼자 감당하다 거의 쓰러질 뻔했다고 회상함
  • 결국 성공한 오픈소스 뒤에는 코드 밖의 일이 엄청나게 많음

• 그래서 AI 코딩 도구를 쓰지 말자는 얘기가 아님. 오히려 개발자라면 써야 함

  • 다만 AI가 제품을 시장에서 성공시키는 지루한 일을 대신해주진 않음
  • AI가 찍어낸 비슷비슷한 결과물이 넘쳐날수록, 무엇을 만들지 않을지 아는 취향이 경쟁력이 됨
  • 결국 승부는 “만들었다”가 아니라 “누가 왜 이걸 선택해야 하는지 설득했다”에서 갈림

---

기술 맥락

• 이 글에서 말하는 핵심 선택은 AI 코딩 도구를 도입하느냐 마느냐가 아니라, 생산성 지표를 어디에 둘 거냐예요. 커밋 수나 앱 출시 수만 보면 좋아 보이지만, 사용자가 실제로 쓰는 제품까지 연결되지 않으면 조직 입장에서는 가치가 덜 생기거든요.

• 왜 릴리즈 증가율이 커밋 증가율보다 훨씬 낮게 나오냐면, 소프트웨어 개발은 코드 작성 하나로 끝나지 않기 때문이에요. 설계, 리뷰, 통합, 배포, 운영, 문서화, 고객 설득이 전부 이어져야 하는데 AI는 아직 이 전체 흐름을 같은 속도로 밀어주지 못해요.

• 오픈소스 프로젝트나 개발자 도구를 만드는 팀이라면 이 얘기가 더 직접적으로 와닿아요. 기술적으로 더 나은 프로젝트가 반드시 이기는 게 아니라, 사용자가 이해하고 믿고 도입할 수 있게 만드는 문서·예제·커뮤니티가 같이 있어야 해요.

• 그래서 앞으로의 병목은 “코드를 얼마나 빨리 쓰나”보다 “선택받을 만큼 명확한 제품을 만들었나”에 가까워질 가능성이 커요. AI로 만들 수 있는 양이 늘어날수록, 안 만들 것과 공개하지 않을 것을 고르는 판단도 더 중요해져요.