“초기부터 AI가 존재했다면”：코드 비용이 저렴해져도 무엇을 구축할지 결정하는 것이 더 어려워지지 않았는가

소프트웨어 역사 대부분에서 비용이 많이 드는 부분은 만드는 일이었습니다. 팀은 아이디어를 작동하는 코드로 바꾸는 데 몇 달을 썼고, 부족한 개발 역량은 업무를 조직하는 방식 전반을 결정했습니다.

로드맵은 가용한 엔지니어링 역량에 맞춰 순서를 정했습니다. 아키텍트는 다른 사람이 모르는 시스템을 이해했기에 중요한 의사결정에 참여했습니다. 제품 관리자는 모호한 사업 요청을 개발자가 실행할 수 있는 형태로 바꾸며 한 주 한 주를 보냈습니다. 코드 작성이 병목이었으므로 영향력도 자연스럽게 그곳에 있었습니다.

이제는 그렇지 않습니다. 변화는 대부분의 엔지니어링 리더가 충분히 이해할 시간보다 빠르게 일어났습니다.

AI 코딩 도구는 구현 비용을 크게 낮췄습니다. 엔지니어 팀이 몇 주 걸리던 일을 이제 에이전트가 몇 시간 안에 합니다. 더 빨리 만들면 가치도 더 빨리 전달할 것이라는 예상은 자연스러웠습니다.

그러나 실제 상황은 더 복잡합니다. 팀은 활용 방향을 정할 수 있는 것보다 더 많은 소프트웨어를 만들어 낼 수 있게 됐고, 속도를 늦추는 요인은 조용히 다른 곳으로 옮겨갔습니다.

“망가진 프로세스에 AI를 적용할 수는 없습니다”라고 말한 사람은 글로벌 소프트웨어·AI 솔루션 스타트업 intive의 미주 기술 책임자 Pablo Gamba입니다. “일꾼에게 더 빠른 삽을 주는 것과 같습니다. 더 빨리 일하겠지만 잘못된 방향으로 더 빨리 나아갈 뿐입니다.”

실행은 빨라져도 제약은 남는다

인터넷, 클라우드, 해외 업무 이전 등 기술의 주요 전환점은 같은 양상을 보였습니다. 비싸던 것이 거의 하룻밤 사이에 저렴해지면 기업은 그 비용을 전제로 만든 구조를 허물고 다시 세워야 했습니다.

Gamba는 이번에 저렴해지는 것이 기술적 지능의 실제 적용 자체라고 주장합니다. 서비스 기업과 엔지니어링 팀이 수십 년간 대가를 받아 온 바로 그 역량입니다.

실행 비용이 낮아져도 제약은 사라지지 않습니다. 눈에 덜 띄는 곳으로 이동할 뿐입니다. 코딩이 빨라지면 코드 검토가 병목이 됩니다. 검토를 자동화하면 시험과 배포에서 나타납니다. 그것도 자동화하면 결국 에이전트가 따를 명세를 작성하는 사람에게 도달합니다.

에이전트는 추측하지 않고 행동할 수 있을 만큼 정확히 설명된 것만 만들 수 있기 때문입니다.

많은 팀이 알아차리지 못한 채 이 함정에 들어가고 있습니다. 거의 무엇이든 예전보다 훨씬 짧은 시간에 만들 수 있으면 잘못된 것을 만드는 비용은 내려가기보다 올라갑니다. 틀렸음을 더 빨리 알게 되지만 그때 이미 배포한 것도 더 많기 때문입니다.

몇 주의 수동 코딩 과정에서 천천히 드러나던 가정이 이제는 누가 의문을 제기하기도 전에 핵심 기반 구조가 될 수 있습니다. AI 투자가 제값을 하는지는 단순한 산출량보다 우선순위 결정에 달리게 됩니다.

Gamba는 이런 상황에서 기업이 개발 속도만이 아니라 의도에서 실제 운영까지의 전체 주기를 추적해야 한다고 봅니다. “개발을 빠르게 해도 QA가 병목이면 QA에 더 빨리 도착한 것뿐입니다. QA를 고치면 병목은 요구사항으로 옮겨갑니다.”

수치도 이를 뒷받침합니다. Cloud Security Alliance의 연구 에 따르면 AI 지원 개발을 사용하는 Fortune 50 기업은 다른 기업보다 커밋을 3~4배 빠르게 제공하지만 새 보안 문제는 약 열 배의 비율로 발생시킵니다.

명확한 목적지 없는 속도는 노력만 낭비하는 것이 아닙니다. 대부분의 보안팀이 따라잡기 어려운 속도로 위험을 누적시킵니다.

AI가 실제로 실행할 수 있는 언어로 요구사항을 정의한다

진짜 제약이 정의 단계에 있다면 해결책은 문서를 더 많이 쓰는 것이 아닙니다. AI가 스스로 빈칸을 채우지 않고 실행할 수 있는 다른 형태의 문서가 필요합니다.

사람이 판단으로 해석하도록 쓰던 요구사항 문서를 구조화된 인수 기준, 명시적 도메인 모델, 계약 테스트로 바꿔야 합니다. 기능이 해야 할 일만큼 절대 해서는 안 되는 일도 분명히 써야 합니다.

에이전트도 초급 엔지니어처럼 자신 있는 추측으로 모호함을 채웁니다. 그러나 초급 엔지니어의 추측에는 주저함, 선임에게 보내는 신호, 뭔가 잘못됐을지 모른다는 감각이 함께합니다.

에이전트의 추측은 그렇지 않습니다. 틀렸어도 깔끔하고 유창하며 완성된 코드로 나타납니다. 어디에도 불확실하다는 표시가 없습니다.

이 차이를 견딜 만큼 정밀한 명세 작성은 제품 개요보다 계약서 작성에 가까워집니다. 모든 참여 주체를 명시하고 시스템에 허용되는 모든 상태 전이를 정리하며, 일반적인 정상 경로만 가정하지 않고 예외 상황까지 다룹니다.

이를 귀찮은 문서 업무로 취급하는 팀은 모호한 의도가 기계의 속도로 모호한 소프트웨어를 만든다는 사실을 힘들게 배웁니다.

생산성 향상을 실제로 얻는 팀은 명세 작성 자체를 엔지니어링 분야로 취급합니다. 과거 코드에만 적용하던 버전 관리, 검토 주기, 엄격한 시험을 똑같이 적용합니다.

Gamba의 표현대로 AI 네이티브는 절차를 생략할 허가가 아니라 처음부터 다시 설계하라는 요구입니다. “많은 조직이 기존 프로세스에 AI를 적용하려 합니다. 그것은 혁신이 아닙니다. AI 네이티브 조직은 다른 질문에서 시작합니다. 처음부터 AI가 있었다면 오늘 이 프로세스를 어떻게 설계할까요?”

백로그 관리자를 넘어 의도를 선별하고 구체화하는 사람으로

제품, 아키텍처, 엔지니어링은 명확하게 인계되는 세 기능이었습니다. 제품 조직이 무엇을 만들지 정하면 아키텍처가 방법을 정하고 엔지니어링이 출시했습니다.

구현이 저렴하고 빨라지면 이런 인계가 전체 과정에서 가장 느린 부분이 됩니다. 중요한 사람은 전체 그림을 한꺼번에 파악하고, 의도를 에이전트가 실행할 형태로 바꾸며, 잘못된 가정이 아무도 원하지 않은 배포 코드가 되기 전에 잡아내는 사람입니다.

이 재설계는 누가 정의를 맡는지, 그 업무가 무엇인지까지 조용히 바꾸고 있습니다.

Gamba는 “소프트웨어 엔지니어의 역할 변화를 생각해 보라”고 말합니다. “이제 코드만 쓰지 않습니다. 에이전트의 결과를 감독하고 명세를 정하고 시험을 준비하고 결과를 검증합니다. 과거 별개였던 세 역할이 하나로 합쳐지고 있습니다.”

이제 가치 있는 것은 업무 티켓 작성법이나 스프린트 운영법을 아는 데 그치지 않습니다. 시작 전에 훌륭한 결과가 무엇인지 알고, 지적으로 흥미로운 것과 고객이 실제로 필요한 것을 구분하며, 기준에 못 미치는 아이디어를 신속히 접을 용기가 중요합니다.

이런 판단은 과거 제품 관리자, 아키텍트, 기술 리드가 의견을 나누며 분담했습니다. 점점 처음부터 일을 정의하는 데 가장 가까운 사람에게 모이고 있습니다.

그렇다고 직함이 사라지는 것은 아닙니다. 다만 역할 사이의 경계를 유지하기는 어려워지고 있습니다. 이 흐릿해진 경계에서 잘하는 사람은 의도를 선별하고 구체화하는 사람입니다.

안전장치 없는 빠른 실행은 성과가 아니다

의도가 명확하고 AI 개발 과정이 원활히 돌아갈 때 놓치기 쉬운 위험이 있습니다. 빠르고 잘 정의된 실행도 더 느리고 사람이 더 많이 개입하는 과정에서는 우연히라도 잡혔을 실패를 만들어 낼 수 있습니다.

관련 수치는 아직 기대에 크게 못 미칩니다. Veracode의 2026년 봄 시험 은 주요 모델에 명시적 보안 지침을 주지 않았을 때 코드 생성 과제의 55%만 안전한 결과를 냈다고 보고했습니다. 기능 정확도는 크게 좋아졌지만 이 수치는 2년 동안 거의 변하지 않았습니다.

문법을 맞추는 일은 이미 어려운 부분이 아닙니다. 사람 엔지니어가 코드를 쓰며 본능적으로 내리던 보안·규정 준수·어떤 데이터가 어떤 시스템에 닿아도 되는지에 관한 판단을 대체하기가 어렵습니다.

따라서 무엇을 만들지 정의할 때의 엄격함을 무엇이 금지되는지에도 적용해야 합니다. 규정 준수 경계, 데이터 처리 규칙, 윤리적 제약을 기능 요구사항만큼 신중하게 명시해야 합니다.

이를 암묵적으로 남겨 두고 에이전트가 잘 추론하기를 바라는 것은 제품 요구사항을 모호하게 둔 채 어떻게든 제대로 만들어지기를 바라는 것과 같은 실수입니다.

리더십에 필요한 것

이 이야기는 AI로 개발을 가속하는 것에 반대하지 않습니다. 개발은 어느 때보다 빠르고 저렴해졌으며 이 변화를 되돌릴 수 없습니다.

하지만 무엇을 만들 가치가 있는지 정밀하게 결정하고, 기계가 충실히 실행할 만큼 잘 설명하며, 실행 중 넘어서는 안 될 경계를 정하는 일은 쉬워지지 않았습니다. 오히려 더 어려워졌다고 볼 수 있습니다.

기업에서 앞서가는 팀은 가장 빠른 코딩 에이전트를 가진 팀이 아닙니다. 정의가 더 어려운 문제가 될 것임을 경쟁자보다 먼저 깨닫고 그에 걸맞게 다루기 시작한 팀입니다.