AI 도구론, 모두가 빌더가 되지는 않는다

모두가 소프트웨어 빌더가 된다는 상상

Benedict Evans의 글은 AI 도구 담론의 과열된 가정을 찌른다. 메타 설명에 드러난 요지는 선명하다. 누구나 모델에게 필요한 소프트웨어를 만들라고 말할 수 있으니 기존 앱이 사라진다는 상상은, 사람들이 실제로 문제를 정의하고 조직 안에서 소프트웨어를 운영하는 방식을 과소평가한다는 것이다.

AI 코딩 도구가 강력해진 것은 사실이다. GitHub Copilot, OpenAI Codex, Anthropic Claude Code 같은 도구는 개발 속도와 접근성을 바꾸고 있다. 그러나 접근성이 곧 조직 변화는 아니다. 좋은 문화가 AI보다 큰 생산성 해킹이라는 주장에서 다룬 것처럼 생산성은 도구보다 작업 분해와 의사결정 방식에 크게 묶인다.

앱은 죽기보다 더 잘게 쪼개진다

AI가 만드는 변화는 앱의 소멸보다 기능 단위의 재배치에 가깝다. 보고서 작성, 데이터 정리, 코드 초안, 고객 응대 같은 일부 흐름은 대화형 인터페이스로 이동한다. 하지만 권한 관리, 감사 로그, 승인 워크플로, 요금제, 통합, 법적 책임은 여전히 제품이 맡아야 한다.

에이전트 시대 API는 더 명시적이어야 한다는 앱과 에이전트가 만나는 접점의 계약을 강조했다. AI가 사용자 대신 버튼을 누르고 데이터를 조작할수록, 앱은 화면보다 정책과 상태의 원천으로 중요해진다.

한국 SaaS에는 방어보다 재포장이 필요하다

한국 SaaS와 업무 도구 기업은 AI를 단순 부가기능으로 붙이는 데서 멈추면 위험하다. 사용자는 점점 "이 화면에서 무엇을 눌러야 하나"보다 "이 업무를 끝내 달라"고 말한다. 이때 제품의 핵심 자산은 UI 컴포넌트가 아니라 데이터 모델, 권한 체계, 업무 상태, 도메인 규칙이다.

Bild AI 채용공고, 제품 엔지니어가 AI의 병목이다는 AI 시대에도 제품 엔지니어의 역할이 커진다고 봤다. Evans의 논지도 비슷하게 읽힌다. 누구나 초안을 만들 수 있어도, 조직이 믿고 반복 사용할 도구로 만드는 일은 여전히 제품 역량이다.

개발자는 프롬프트보다 조직 모델을 봐야 한다

개발자에게 이 논쟁은 직업 안정성의 문제가 아니라 일의 초점 이동이다. 코드는 더 빨리 만들어지지만, 무엇을 만들어야 하는지, 어떤 데이터를 다뤄야 하는지, 실패 시 누가 책임지는지는 더 어려워진다. McKinsey의 생성형 AI 보고서는 많은 기업이 AI 가치를 얻기 위해 워크플로 재설계와 거버넌스가 필요하다고 반복해서 지적해 왔다.

그래서 한국 기업의 AI 전환은 사내 챗봇 배포보다 업무 지도 작성에서 시작해야 한다. 반복 업무, 예외 처리, 승인권자, 데이터 민감도, 실패 비용을 먼저 나누면 어떤 부분을 AI 도구에 맡길 수 있는지 보인다.

자주 묻는 질문

Q1: AI가 앱을 완전히 대체할까요?

A: 일부 간단한 도구는 대체될 수 있지만, 권한과 책임이 있는 업무 앱은 API와 워크플로 계층으로 계속 중요해질 가능성이 큽니다.

Q2: 비개발자가 직접 소프트웨어를 만들 수 있나요?

A: 작은 자동화와 프로토타입은 가능해집니다. 다만 운영 가능한 제품은 데이터, 보안, 유지보수 역량이 필요합니다.

Q3: 개발자의 역할은 줄어드나요?

A: 단순 구현 비중은 줄 수 있지만 시스템 설계, 검증, 통합, 운영의 중요도는 커집니다.

Q4: 한국 SaaS 기업의 대응은 무엇인가요?

A: 화면 중심 기능보다 에이전트가 안전하게 호출할 수 있는 API, 권한, 감사 로그를 제품화해야 합니다.

Q5: AI 전환의 첫 단계는 무엇인가요?

A: 자동화하고 싶은 업무를 예외, 승인, 책임, 데이터 민감도 기준으로 나누는 일입니다.