안녕하세요, 리키입니다. 오늘은 제가 최근에 접한 AI 네이티브 개발에 대한 흥미로운 이야기를 여러분과 나누려고 합니다. 단순히 인공지능을 코딩의 지름길로 쓰는 것을 넘어, 소프트웨어가 만들어지는 방식 자체를 재창조하는 ‘프런티어 개발팀’들의 사례에 대해 말씀드리겠습니다.
프런티어 개발팀은 AI를 사용해서 코딩 속도를 높이는 수준이 아닙니다. 그들은 소프트웨어가 어떻게 구축되는지 전체적인 틀을 다시 설계하고 있습니다. 이들이 보여준 결과는 정말 놀랍습니다. 단지 몇 명의 엔지니어와 76일 만에 기존에는 1년에서 1년 반 동안 30명의 개발자가 필요했던 프로젝트를 완성해냈더군요. 이는 AI가 단순한 도구가 아니라 작업 방식의 기초로 자리 잡았을 때 나타난 현상입니다.
AI 속도 너머의 병목 현상
물론 AI 코딩 에이전트 덕분에 커밋 속도는 급증하고 CI/CD 파이프라인도 바빠졌습니다. 하지만 문제는 고객에게 제품을 전달하는 속도가 아직 따라가지 못한다는 점입니다. 프로덕션 단계에 투입된 결과물들은 같은 속도를 유지하지 못했죠. 여기서 병목 현상은 에이전트가 코드를 만들어내는 능력에 있는 것이 아니라, AI가 올바른 결정을 내리는 데 필요한 지식에 접근하고, 개발팀이 그 현실에 맞춰 작업을 재구성하려는 의지 부족에서 비롯된다는 것을 알게 되었습니다.
그래서 저는 이러한 문제를 해결한 팀들을 ‘프런티어 개발팀’이라고 부릅니다. 이들은 단순히 똑똑한 사람들이 모인 팀이 아니라, AI 도입을 단순한 도구 출시가 아닌 공학적 투자로 여기고 다양한 산업에서 공통된 모범 사례를 공유하는 팀들입니다. 어떤 규모의 조직이든 프런티어 개발팀이 될 수 있다는 것이죠.
프런티어 팀이 되기 위한 방법
Amazon 같은 곳에서 AI 네이티브 개발을 위해 실험을 진행했을 때, 세 가지 경로를 확인했습니다. 제한된 통제된 실험(패스파인더 방식), 명확한 계획에 따른 구조화된 스프린트, 그리고 기존 접근법과 AI 적응 워크플로우를 반으로 나누는 현장 실험이었는데요. 이 모든 실험에서 공통적으로 도구가 아니라 ‘워크플로우’가 핵심이라는 교훈을 얻었습니다.
결국 프런티어 팀이 되기 위해서는 에이전트가 작업 맥락에 참여하는 장벽을 줄이고, 독립적으로 처리할 수 있는 작업량을 늘려야 합니다. 즉, 에이전트에게 파일과 지식에 투자하고, 명확한 코딩 표준과 테스트를 통해 에이전트가 프로젝트와 지식을 더 쉽게 활용하도록 만드는 것이 중요합니다. 여러분도 이 점을 염두에 두시고 개발 환경을 재구성해 보시길 바랍니다.
참고 원문: https://aws.amazon.com/ko/blogs/korea/how-frontier-teams-are-reinventing-ai-native-development/