'컨퍼런스 부스용 iOS 앱'을 보고 처음 드는 반응은 대부분 비슷하다. 오버엔지니어링 아닌가? 그런데 dev.to에 올라온 한 개발자의 회고가 정확히 그 직관을 뒤집는다. 문제는 앱이 아니었다. 문제는 '이 정도 규모면 만들 가치가 있는가'를 판단하는 오래된 기준이었다.
그 기준은 소프트웨어가 비쌀 때 만들어졌다. 6개월짜리 개발 비용을 정당화하려면 SaaS여야 하고, 확장 가능해야 하고, 수천 명이 써야 했다. 그런데 AI 지원 개발이 그 방정식을 조용히 바꾸고 있다. 재고 관리 도구, 이민 서류 추적기, 한 학기짜리 가계부—이런 것들은 예전이라면 만들 가치가 없었다. 지금은 다르다. 주말 하나면 된다.
이 변화의 핵심은 단순히 개발 속도가 빨라졌다는 게 아니다. 병목이 이동했다. 과거의 병목은 '어떻게 만드는가'였다. 점점 더 중요해지는 병목은 '무엇이 존재해야 하는가'다. 코드를 가장 많이 생성하는 개발자가 아니라, 실제 문제를 관찰하고, 마찰 지점을 식별하고, 가장 작은 유용한 해결책을 설계하고, 아무것도 만들지 않아야 할 때를 아는 개발자가 유리해진다.
디자인 에이전시인 플러스엑스가 전사 세미나에서 꺼낸 문장이 이 흐름을 정확히 압축한다. "도구는 평준화되어도, 판단은 평준화되지 않았다." 이 회사는 바이브코딩 시대를 맞아 디자이너에게 개발 리터러시를 가르치고, 바이브코딩 7원칙과 스타터 키트를 만들고, 사내 개발자 플랫폼(PlusX Developers)까지 구축했다. 그 이유는 디자이너를 개발자로 만들기 위해서가 아니다. 기술이 더 이상 구현의 단계가 아니라, 어떤 경험을 제안하고 실행할 수 있는지를 결정하는 조건이 됐기 때문이다.
플러스엑스의 사례에서 흥미로운 지점은 조직이 두 방향을 동시에 움직인다는 것이다. 한편으로는 진입 장벽을 낮춘다—shadcn/ui 기반 디자인 시스템, 인프라 발급을 추상화한 내부 플랫폼, 세션 간 컨텍스트를 유지하는 스타터 키트. 다른 한편으로는 판단 역량을 조직 자산으로 내재화한다—"이게 왜 좋은 디자인인지, 어떤 문제를 해결하는지, 비즈니스에 어떤 가치를 주는지를 설득력 있게 설명할 수 있는 능력." 실행 속도와 판단 깊이를 동시에 끌어올리는 구조다.
그렇다면 AI 도구의 실제 가치는 어떻게 측정해야 할까. dev.to에서 제안된 한 가지 접근이 날카롭다. GitHub Copilot의 '제안 수락률'은 좋은 지표가 아니다. 수락은 사건이지 지속 가능한 결과가 아니기 때문이다. 더 의미 있는 단위는 '유지된 작업당 비용(cost per retained task)'—도구 비용 + 리뷰 인건비 + 재작업 비용을 14일 후에도 살아남아 롤백 없이 통과한 변경으로 나눈 값. 수락 → 병합 → 24시간 유지 → 14일 유지로 이어지는 퍼널로 보면, AI가 실제로 팀에 얼마나 기여하는지가 훨씬 선명하게 드러난다.
이 세 흐름—소프트웨어 가치 판단의 변화, 디자인 에이전시의 조직 전환, AI 도구의 실질적 측정—이 동시에 가리키는 방향은 하나다. AI가 실행 비용을 낮추면 낮출수록, 판단의 비중은 반대 방향으로 커진다. 무엇을 만들지, 언제 멈출지, 만든 것이 실제로 작동하는지를 판단하는 역량이 개발자의 핵심 자산이 된다.
지금 당장 실무에서 체크해볼 만한 질문 세 가지. 첫째, 이 기능이 정말 제품이어야 하는가, 아니면 워크플로우 문제인가. 둘째, 팀이 AI 도구를 평가할 때 '수락률'이 아닌 '유지율' 기반 메트릭을 갖고 있는가. 셋째, 개발자가 아닌 구성원도 프로토타입을 만들 수 있는 환경이 팀의 인프라로 설계되어 있는가. 이 질문들에 답하는 과정이, AI 시대 개발자가 실제로 올려야 할 판단의 무게를 만드는 연습이다.