대부분의 엔지니어링 팀은 AI 코딩 어시스턴트가 전반적인 개발 속도(delivery velocity)를 급증시킬 것이라고 기대했습니다. 하지만 실제로는 개발자들이 코드를 더 빠르게 작성하고 있지만, 팀 차원의 전달 성과는 여전히 정체되어 있습니다.
진짜 문제는 역사적으로 코드 작성이 소프트웨어 개발 수명 주기(software development lifecycle)의 주요 병목 지점이었다는 것입니다. 이러한 제약 때문에 엔지니어링 팀들은 인간이 속도를 결정하는 작성자 중심의 리뷰 및 승인 프로세스를 설계해 왔습니다. AI 코딩 도구를 도입하면 코드가 빠르게 생성되고 변경하기 쉬워지지만, 다운스트림(downstream) 리뷰 파이프라인은 변하지 않은 채 남아 있습니다. 이 제약은 사라지지 않았고, 단지 풀 리퀘스트(pull request) 대기열로 직접 이동했을 뿐입니다.
예전에는 예측 가능한 양의 pull request를 관리하던 시니어 엔지니어들은 이제 기계가 생성한 코드의 엄청난 백로그에 파묻히게 되었습니다. 단순히 리뷰하는 사람을 늘리는 것은 증상만 치료할 뿐이므로, 팀들은 코드가 생성되기 훨씬 이전 단계에서 발생하는 마찰(friction)을 해결해야 합니다:
처음부터 명세(specification)를 명확하게 작성하라: 인간 엔지니어들은 역사적으로 모호한 요구사항을 비공식적인 판단이나 채팅 스레드를 사용하여 채워왔습니다. AI 에이전트는 쓰여진 그대로 정확히 구축하기 때문에, 모호한 명세는 낭비되는 반복 작업과 결함 있는 코드로 이어집니다.
구현 시작 전에 비엔지니어(non-engineer)를 참여시켜라: 코드 작성이 느렸을 때는 제품, 디자인, 보안 관련 이해관계자들을 리뷰 단계에 포함시키는 것이 합리적이었습니다. 하지만 코드가 빠르게 생성될 때는, 기술적 배경이 없는 이해관계자들이 생성이 시작되기 전에 정의를 형성하는 데 도움을 주어야 합니다.
늦은 변경 비용(cost of late changes)에 최적화하라: 단순히 pull request의 양이나 리뷰 처리량을 측정하는 것을 멈추십시오. 진정으로 중요한 지표는 불분명하거나 불완전한 명세에서 시작된 작업을 방향 전환시키는 데 얼마나 많은 비용이 드는지입니다.
요구사항의 모호성을 상류(upstream)에서 해결하면, 시니어 리뷰어들을 보호하고 빠른 코드 생성이 리뷰 교착 상태가 아닌 실제 배포되는 소프트웨어로 변모하도록 보장할 수 있습니다.
전체 기사 읽기:
upsun.com