TL;DR

  • AI 코딩으로 아이디어를 빠르게 구현할 수 있는 시대에는 엔지니어링 팀이 개별 기능을 만드는 대신 검증 시스템을 구축하고, 실사용자 실험으로 입증된 아이디어에 집중하는 SDLC가 필요함.
  • McKinsey Technology Trends Outlook 2026에 따르면 에이전트 코딩 도구를 도입한 기업 3곳 중 1곳에서 생산성이 하락함.
  • 새로운 SDLC는 코드와 설정을 안전하게 배포하는 Ship, 기존 기능과 서비스 수준을 보호하는 Guard, 사용자와 비즈니스 지표를 측정하는 Measure의 세 축으로 구성됨.
  • AI로 만든 MVP를 소규모 사용자에게 실험하고, 결과에 따라 중단·수정·확대하면 실패 비용을 며칠과 소액의 토큰 비용으로 제한할 수 있음.
  • 소프트웨어 구축 비용이 낮아진 환경에서 핵심 역량은 더 많은 것을 만드는 일이 아니라 무엇을 출시하지 않을지 판단하는 일임.

스타트업의 개발 과정과 생산성 문제

  • 함께 일한 대부분의 스타트업에서는 아이디어와 논의, 추가 논의, 검토, 합의 형성, 잦은 우선순위 변경이 반복됨.
  • 경영진은 AI가 생산성을 크게 끌어올릴 것으로 기대하지만, 엔지니어링 팀은 시간이 부족하거나 사실상 소진된 상태로 일하는 경우가 많음.
  • McKinsey Technology Trends Outlook 2026은 에이전트 코딩 도구를 도입한 기업 3곳 중 1곳에서 생산성이 하락한다고 밝힘.
  • AI는 소프트웨어 개발 수명 주기(SDLC)에 참여하는 각 개인을 돕지만, 조직 전체의 업무 방식을 통합적으로 개선하지는 못함.

새로운 SDLC: 아이디어를 검증하는 시스템

  • SDLC를 다시 생각할 시점임. 모든 아이디어를 엔지니어링 팀이 직접 구현하는 대신, 아이디어가 스스로 가치를 입증할 수 있는 시스템을 엔지니어링 팀이 구축함.
  • 공장에서 엔지니어가 자동차를 직접 만드는 것이 아니라 자동차를 만드는 시스템을 설계하는 것과 같은 접근임.
  • 새로운 SDLC는 다음 세 축으로 구성됨.
  • Ship: 코드, 설정, 기능 플래그(feature flag)를 안정적이고 격리된 방식으로 프로덕션에 전달하는 플랫폼임.
  • Guard: 기존 기능이 계속 작동하고 핵심 기능이 정의된 서비스 수준 계약(SLA)과 서비스 수준 목표(SLO)를 충족하는지 보장하는 하네스임.
  • Measure: 신뢰할 수 있는 A/B 테스트를 연결하고 중요한 사용자·비즈니스 지표를 정확히 측정하는 실험 엔진임.
  • 이 시스템을 갖추면 아이디어가 있는 누구나 AI로 최소 기능 제품(MVP)을 만들어 실제 사용자 일부에게 배포하고 효용을 검증할 수 있음.
  • 하네스는 AI가 기존 기능을 망가뜨리지 않았는지 확인함. 배포 플랫폼과 기능 플래그 프레임워크는 변경 사항을 안정적으로 프로덕션에 전달하고, A/B 테스트 프레임워크는 실사용자 일부에게 기능을 안정적으로 활성화함. 핵심 경험이 악화되면 실험은 즉시 꺼짐.

작은 실험으로 결정의 위험 낮추기

  • 실험에는 큰 규모가 필요하지 않으므로, 대규모 인프라 변경도 드물게만 필요해야 함.
  • 원칙과 관행을 통해 제안된 기능의 MVP 범위를 지킬 수 있음. 실험에 새로운 데이터 저장소나 ‘핫 캐시’, 서비스 세 개를 추가하려면 CTO 승인을 받는 편이 나음.
  • 아이디어가 지나치게 크다면 일련의 작은 아이디어로 나눠야 함. 그러면 되돌릴 수 없는 단방향 결정을 여러 번의 양방향 결정으로 바꿀 수 있음.
  • 작은 아이디어를 연속해서 검증하면 더 큰 가설도 입증할 수 있음. 이것이 애자일이 원래 지향했어야 할 방식임.
  • MVP는 항상 단순하게 유지되며, 이 제약은 진입 장벽으로 기능함.
  • 실험을 공개한 뒤에는 세 가지 결과가 가능함.
  • 핵심 지표가 악화되면 제안자가 AI로 반복 수정하거나 아이디어를 완전히 포기할 수 있으며, AI가 관련 변경 사항을 정리함.
  • 지표가 ‘평탄’하거나 중립적이면 감지 가능한 피해가 없다는 점을 입증함. 다만 아직 입증되지 않은 상태이므로, 반복 수정하거나 그 결과가 예상된 것이었다면 출시할 수 있음.
  • 지표가 양호하면 이를 바탕으로 다음 작은 실험을 진행하거나, 검증된 기능을 제품 요구사항 문서(PRD)로 전환해 개발자들이 최선의 접근 방식을 논의하고 규모에 맞게 구현할 수 있음.
  • 성공한 실험을 프로덕션 전체 사용자에게 확대하는 일은 여전히 어려움. 새로운 SDLC의 핵심은 엔지니어링 팀 전체가 검증된 아이디어를 인계받아 우선순위를 정하고 작업한다는 점임.

제기될 수 있는 반론

  • 기술 스택이 복잡하다는 반론: 그럴 수 있지만, 경험상 복잡성은 제품 요구사항보다 여러 해 동안 코드를 덧붙여 온 데서 비롯되는 경우가 많음. 기존 스택을 감싸는 세 축을 구축하면 이후 안전하게 단순화할 기회도 생김. 이 방식을 구현하기 위한 공개 사양과 AI 스킬을 작성 중이며, 조직에 적용하는 방안을 논의할 수 있음.
  • AI가 프로덕션을 망가뜨릴 수 있다는 반론: 그럴 수 있음. 다만 오늘날에도 프로덕션은 망가질 수 있으며, 필요한 대응은 하네스를 강화하는 것임.
  • 팀 리드는 CTO처럼 생각해야 함. CTO가 작성된 모든 코드 줄을 아는 것은 아니며, 개발자와 문화라는 적절한 하네스를 마련함. 팀 리드도 같은 관점에서 기능부터 사용자 데이터까지 모든 것을 보호하는 하네스를 고려해야 함.
  • 나쁜 MVP가 좋은 아이디어를 죽일 수 있다는 반론: 맞는 지적임. 더 적절한 범위의 MVP는 반복 과정에서 발전하며, 사람들의 대화가 아이디어를 다듬는 데 전통적인 SDLC가 더 나을 수도 있음. AI로 반복하거나 실험 설계와 결과를 소규모 집중 그룹에서 논의하는 방식으로 보완할 수 있음. 중립적인 결과가 반드시 나쁜 것은 아님.

실험 중심 접근의 이점

  • 실제 사용자를 대상으로 며칠 안에 측정할 수 있음. 아이디어 테스트가 개별 기여자(IC)의 활동이 되며, 좋은 아이디어가 있는 누구나 가설을 강화할 수 있음.
  • 아이디어를 항상 수치로 뒷받침하면 ‘만약 그렇다면’ 식의 논쟁을 데이터로 정리할 수 있음.
  • 규모가 크고 확신에 찬 베팅보다 작고 측정 가능한 베팅이 나음. 엔지니어링 조직 전체가 성공하지 못한 대담한 아이디어에 막대한 노력을 쏟는 사례는 많음. 작고 측정 가능한 베팅은 성공 가능성이 더 높은 아이디어에 조직의 시간을 씀.
  • 실패한 실험은 한 사람의 며칠과 소액의 토큰 비용으로 끝날 수 있지만, 전통적인 프로젝트의 실패는 팀의 한 분기를 소모할 수 있음.
  • 실패한 각 실험은 효과가 없었던 조건과 악화된 지표를 기록으로 남김. 이 맥락은 미래의 실험에 반영되며, 무엇이 됐고 되지 않았는지, 그 이유가 무엇인지 검색할 수 있는 의사결정 기록이 됨.

적용 범위와 결론

  • 실험 우선 접근은 경력 대부분을 보낸 소비자 대상 제품에서 특히 가치가 큼. 다만 무엇이 효과가 없을지 알아내도록 SDLC를 조정한다는 핵심 원리는 많은 소프트웨어 기업에도 유효함.
  • 광물 탐사 기업 KoBold Metals는 광물이 발견되지 않은 시추공(Dry Hole)도 정보의 보고로 다룸. 목표는 ‘모든 것을 예측’하고 ‘불확실성을 정량화’하는 것이며, 광물 발견 여부와 관계없이 각 시추 결과를 모델 개선에 활용함. 이 방식은 향후 거짓 양성도 줄이는 데 도움이 됨.
  • 소프트웨어 구축 비용이 낮아진 세계에서 어려운 일은 무엇을 만들지보다 무엇을 출시하지 않을지 판단하는 일임.