AWS, 키로에 개발자 유연성 확대···‘디자인 우선’·‘버그 수정’ 워크플로우 추가

AWS(Amazon Web Services)는 비주얼 스튜디오 코드 기반 에이전틱 IDE인 ‘키로’의 기존 개발 방식이 실제 개발자들의 업무 흐름과는 다르다는 점을 인정했다. 이를 해결하기 위해 기존 프로젝트 작업과 버그 수정 등 현실적인 개발 환경에 맞춘 2가지 새로운 소프트웨어 개발 워크플로우를 키로에 추가했다.

키로는 처음 출시 당시 사양 중심 개발(Spec-Driven Development, SDD)을 핵심 비전으로 제시했다. 개발자가 의도와 요구사항을 사전에 명확히 정의하면, 키로가 이를 바탕으로 구현 과정을 지원하는 구조였다.

그러나 실제 개발 현장은 이와 다른 경우가 많다.

브로드컴(Broadcom)의 사이트 신뢰성 엔지니어 어드베이트 파텔은 “대부분의 개발자는 완전히 새로운 아이디어에서 출발하지 않는다. 이미 존재하는 코드베이스나 복잡하게 얽힌 버그, 혹은 사전에 합의된 설계를 기반으로 작업을 시작한다. 이번 워크플로우는 키로가 현실을 인정하고, 사양 기반 접근법에 대한 진입 장벽을 낮추기 위한 변화로 보인다”라고 설명했다.

AWS의 에이전트형 AI 제품 수석 프로덕트 매니저 안킷 샤르마는 블로그를 통해 첫 번째 신규 워크플로우인 ‘디자인 우선(Design-first)’을 소개했다. 이 워크플로우는 개발자가 이미 구상한 기술 접근 방식을 출발점으로 삼을 수 있도록 설계됐다. 예를 들어 아키텍처 결정 사항이나 구현 스케치가 있다면, 이를 기반으로 키로가 요구사항 정의서와 설계 명세, 작업 계획을 도출해 준다.

반면 ‘버그 수정(Bugfix)’ 워크플로우는 기존 코드베이스를 개선 및 유지하는 브라운필드 개발 환경을 겨냥했다. 이미 운영 중인 시스템을 다루는 엔지니어의 업무 흐름에 맞춘 기능이다.

샤르마는 “버그 수정 워크플로우는 곧바로 코드 변경에 들어가기보다, 현재 동작과 기대 동작, 그리고 변경하지 않아야 할 요소를 먼저 문서화하도록 유도한다. 디버깅 과정을 가벼운 사양 작성 단계로 전환하는 접근”이라고 설명했다.

샤르마는 이번 변화가 사양 구조의 기본 틀은 유지하되, 기존 방식이 충분히 유연하지 않다고 느낀 사용자 의견을 반영한 결과라고 분석했다.

버그 수정 기능이 사양 중심 개발에 대한 수용도를 높일 수 있을까?

분석가들은 이번 변화를 사양 중심 방식을 강화하려는 움직임이라기보다, 클로드 코드, 커서, 깃허브 코파일럿 등 경쟁 도구에 대한 대응으로 봤다. 이들 도구는 엄격한 사양 중심 규범을 요구하지 않으면서도 개발자 사이에서 빠르게 확산되고 있다.

하이퍼프레임 리서치의 AI 스택 부문 리더 스테파니 월터는 “신규 워크플로우는 결국 개발자 행동이 우선한다는 점을 인정한 것”이라며 “사양 중심 개발은 개념적으로는 매력적이지만, 실제 조직 문화에서는 부담이 될 수 있다. 개발자는 점점 더 빠르고 대화형에 가까운 워크플로우를 선호하고 있다. 사용이 간편하고 속도가 빠르기 때문”이라고 분석했다.

월터는 이어 “이번 워크플로우는 개발자가 먼저 아이디어를 구상한 뒤 이후에 이를 형식화할 수 있도록 한 일종의 ‘하이브리드’ 전략이다. 사양 중심 개발의 규범을 완화해 개발자의 진입 장벽을 낮추려는 시도”라고 설명했다.

반면 퓨처럼 그룹(The Futurum Group)의 CIO 프랙티스 부문 부사장 디온 힌치클리프는 이번 기능 추가만으로 개발자 유입을 끌어내기에는 충분하지 않을 것으로 내다봤다. 개발자가 여전히 속도를 중심에 둔 코딩 도구를 선택할 가능성이 높다는 이유에서다.

파텔 역시 동의하며 “개발자는 실용적이다. 도구가 처음부터 끝까지 시간을 절약해 준다면, 결국 그 도구를 선택하게 될 것”이라고 말했다.

톱다운 방식의 개발

다만 개발자가 항상 도구 선택의 주체는 아니며, 일부 도구는 오히려 관리자에게 더 매력적으로 보일 수 있다. 힌치클리프는 키로가 해당 사례에 가깝다고 분석했다. 거버넌스와 감사 가능성이 중요한 환경, 그리고 보다 규율이 엄격한 개발 조직이나 운영 단계의 프로덕션 환경에서 키로가 선호될 가능성이 높다는 설명이다.

힌치클리프는 CIO가 키로의 접근 방식에 주목할 필요가 있다고 언급했다. 그는 “CIO 입장에서 성과에 비용을 지불하는 구조라면, 빠르지만 잘못된 수정은 오히려 더 큰 비용을 초래할 수 있다. 기업이 따져야 할 질문은 도구가 느린지 여부가 아니라, 변경 실패율(Change Failure Rate)과 평균 복구 시간(MTTR)을 실제로 낮출 수 있는지 여부”라고 설명했다.
dl-ciokorea@foundryco.com