에이전틱 프로그래밍 시대의 개발팀 재창조

소프트웨어 작성 속도의 큰 향상은 더 이상 개발팀이 직면한 유일한 과제가 아니다. Cursor와 같은 도구가 개발 환경 안에서 코드를 제안하는 단계에서 사양과 티켓을 바탕으로 전체 작업을 실행하는 단계로 넘어가면서, 문제는 조직이 무엇을 만들 가치가 있는지 정하고, 이를 테스트하고, 안전하게 배포한 뒤 운영하고 유지보수할 수 있는 역량에 있을 수 있다.

이것이 Hannah Foxwell의 «개발팀 재창조»라는 발표의 핵심이다. 이 발표는 에이전트 자체의 능력보다 에이전틱 프로그래밍이 사람과 프로세스에 미치는 영향에 더 초점을 맞춘다. Foxwell은 도구가 아무리 빨라지더라도 여전히 중요하다고 보는 세 가지 축을 바탕으로 주장을 전개한다.

속도 부족에서 역량 과잉으로

Foxwell은 1년에 두 번 소프트웨어를 출시하던 팀에서 출발해 Agile, 클라우드 컴퓨팅, DevOps, 지속적 배포를 거쳐 하루에도 여러 차례 배포하는 운영으로 이어진 경로를 설명한다. 그녀는 한때 먼 목표로 제시되던 높은 속도가 현실이 되기 시작했지만, 조직은 아직 이를 어떻게 활용해야 할지 알지 못한다고 본다.

에이전틱 프로그래밍 모델에서는 에이전트가 사양을 세분화하고, 코드와 테스트를 작성한 다음, 배포와 모니터링을 지원할 수 있다. 그러나 이러한 역량은 제품 관리에 역압력을 만들 수 있다. 개발팀이 조직이 명확하고 적격한 요구사항을 제공하는 속도보다 더 빠르게 작업을 실행할 수 있기 때문이다. 따라서 Foxwell은 모든 아이디어나 요청을 받아들이는 것이 해법이라고 보지 않는다. 그렇게 하면 비대하고 집중력이 약한 제품으로 이어질 수 있다.

첫 번째 축: 만들 가치가 있는 것을 만들기

Foxwell은 코드가 목적이 아니라 사용자의 실제 문제를 해결하기 위한 수단이라고 강조한다. 아이디어를 테스트하는 비용이 낮아질수록, 아이디어를 제품 안에서 장기적인 약속으로 전환하기 전에 프로토타입을 만들고 사용자와 함께 시험하는 편이 낫다.

이 글이 제시하는 방식 중 하나는 아이디어와 테스트 사이의 거리를 줄이는 «프로토타입을 프로그래밍하는 제품 관리자»다. 아이디어가 빠른 모델링의 역량을 넘어설 경우에는 제품 관리자와 개발자를 짝지을 수 있다. 또한 고객 가까이에서 일하며 고객의 문제를 해결할 권한을 가진 엔지니어인 현장 엔지니어의 역할과, 제품을 사용하거나 사용자와 가까이 있기 때문에 제품 형성에 참여하는 «제품 엔지니어»도 언급한다.

Foxwell은 팀 규모와 구성 비율을 재검토하는 실험도 소개한다. 6~8명의 개발자와 1명의 제품 관리자로 구성된 팀 모델 대신 일부 조직은 더 작은 팀을 시험하고 있으며, Andrew Ng는 여러 에이전트로 구성된 함대를 조율할 수 있는 개발자 1명과 제품 관리자 2명으로 이루어진 반대의 모델을 제안했다. 이러한 모델들은 고정된 규칙이 아니라 병목 지점이 개발 역량에서 요구사항의 명확성과 의사결정 속도로 이동하고 있음을 반영하는 실험으로 제시된다.

반면 이 글은 기능을 출시한 뒤 사용 현황을 검토하지 않고 즉시 다른 작업으로 넘어가는 관행, 모든 고객 요청을 받아들이는 관행, 가장 높은 급여를 받는 책임자의 의견을 우선순위의 기준으로 삼는 관행을 경고한다. 소프트웨어 작성이 빨라지는 환경에서는 사용자 조사와 사용성, 가치 검증 능력이 실행 속도 자체보다 더 중요한 차별화 요소가 될 수 있다.

두 번째 축: 속도에는 안전이 필요하다

변경 규모가 커지려면 이를 따라갈 수 있는 프로덕션 경로가 필요하다. Foxwell은 테스트 커버리지의 공백과 수작업 단계가 배포 경로를 병목으로 만들어 변경 사항이 사용자에게 도달하기 전에 쌓이게 할 수 있다고 경고한다.

따라서 이 글은 속도와 자동화된 테스트를 연결한다. 에이전트를 활용해 지속적인 테스트를 만들고, 팀이 기술 부채를 처리하며, 레거시 플랫폼에서 마이그레이션하고, 코드베이스를 리팩터링하도록 지원하는 사례도 언급한다. 핵심은 느린 프로세스 위에 인공지능을 추가하는 것이 아니라, 새로운 변경률을 감당할 수 있도록 프로덕션으로 가는 경로를 재설계하는 데 있다.

Foxwell은 신뢰성과 보안이 속도를 위해 받아들일 수 있는 맞교환 대상이 아니라고 강조한다. 서비스 수준 목표 지표와 오류 예산을 활용하고, 허용 가능한 실패 수준을 초과했을 때 조직이 무엇을 할지 정하는 문서화된 정책을 마련할 것을 제안한다. 예를 들어 출시를 늦추거나 자원을 신뢰성과 복원력에 투입하는 방식이다.

또한 점진적 배포, 기능 플래그, A/B 테스트, 블루-그린 배포가 많은 변경 사항을 모든 사용자에게 한꺼번에 노출하지 않고 관리하는 데 도움이 된다고 본다. 사이트 신뢰성 엔지니어링 팀과 내부 플랫폼 팀의 역할도 재검토한다. 이들은 개발팀에 안전하고 잘 정비된 경로를 제공하는 자문 및 지원 기능으로 볼 수 있다.

실제로 무엇이 달라지는가?

발표에서 얻을 수 있는 편집상의 결론은 에이전트만으로 개발팀이 더 작아지거나 일자리가 사라진다는 사실이 입증되지는 않는다는 것이다. 확실한 점은 병목 지점이 이동한다는 것이다. 코드 생산에서 문제 선택, 가치 검증, 테스트 확장, 신뢰성 관리, 신속한 의사결정으로 이동한다.

열린 질문은 조직이 새로운 역량을 활용해 더 나은 제품을 만들고 아이디어를 테스트할지, 아니면 더 많은 기능을 쌓는 방식으로 대응할지다. 개발자와 제품 관리자, 플랫폼 팀, 신뢰성 팀 사이의 새로운 비율도 아직은 실험이며 입증된 결과가 아니다. 따라서 에이전틱 프로그래밍을 도입하려면 단순히 코드 줄 수나 출시 속도에 만족하지 말고 제품 품질, 사고, 사용자 경험에 미치는 영향을 측정해야 한다.