키로(Kiro)는 새로운 AWS IDE로, 에이전트 AI를 사용해 소프트웨어 프로젝트를 생성하는 기능을 제공한다. 개발자가 원하는 프로그램의 사양을 작성하면 키로는 클로드 소넷(3.7 또는 4.0)을 사용해 애플리케이션을 빌드하기 위한 일련의 요구사항과 설계 문서, 작업 목록을 반복적 방식으로 생성한다. 개발자는 이 프로세스의 각 단계를 감독하면서 중간에 개입해 사양이나 명령을 변경할 수도 있고, 시스템이 자율적으로 실행되도록 둘 수도 있다.

필자는 키로가 아직 공개 프리뷰 단계에 있을 때 설치했지만, 수요가 급증하면서 지금은 대기 명단에 등록하는 방식으로 바뀌었다. AWS가 키로의 첫 프리뷰가 발표되고 이어진 주말에 용량을 추가했음에도 불구하고 클로드 소넷 API에서 여전히 시간 초과가 발생하는 상황이다. 이 기사에서는 성능 문제보다는 이 IDE의 전반적인 설계와 특성에 초점을 맞춰 살펴본다.

키로 프로젝트 설정

키로는 비주얼 스튜디오 코드의 파생 버전을 기반으로 하는 만큼 VS 코드 사용자라면 어렵지 않게 사용할 수 있다. 키로가 VS 코드 IDE용 플러그인 모음이 아니라 완전히 별개의 제품으로 나온 이유는 확실하지는 않지만 마이크로소프트 자체 코파일럿과의 경쟁을 피하기 위한 것으로 추정된다. 아무튼 기존 VS 코드 환경의 플로그인을 키로로 마이그레이션해서 그대로 사용할 수도 있고, 오픈VSX 마켓플레이스를 통해 설치할 수도 있다.

키로에서 새 프로젝트 폴더를 열면 클로드 소넷 프롬프트가 표시된다. 이 프롬프트를 사용해서 “vibe(가능한 가장 일반적인 방식으로 프로젝트를 설명한 다음 점차 세부적으로 들어가는 방식)” 또는 “spec(앞서 언급한 규격 설계 사용)” 중 하나를 선택할 수 있다. “vibe”는 간단한 일회성 작업에 적합하다. 필자는 vibe를 사용해서 다른 파이썬 프로젝트를 위한 가상 환경의 유효성을 확인하는 파이썬 프로젝트를 생성해봤다. 최근 컴퓨터를 업그레이드한 이후 수십 개의 프로젝트에서 venv가 제대로 동작하지 않는 상황이기 때문에 키로에서 생성한 코드가 실제로 작동하는지 확인하기는 어렵지 않았다.

키로에서 파이썬 프로젝트의 가상 환경이 유효한지 여부를 확인하기 위한 간단한 명령줄 툴 설계하기IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

“spec”에서는 목표를 좀더 높여 명령줄 기반 정적 사이트 생성기 프로젝트를 설정했다. 여기서 키로는 사용자 프롬프트를 사용해 요구사항, 설계, 작업 목록 문서를 생성하고 단계별 생성 프로세스를 설정한다.

“steering” 문서를 생성할 수도 있다. 이 문서는 키로가 사용자의 지시를 어떻게 해석해야 하는지를 규정하는 기준, 즉 프로젝트의 목적, 사용할 스택, 리포지토리 내 파일 배치 방식에 대한 규칙을 제공한다. 이러한 문서는 프로젝트를 시작하는 시점에 만들어져 프로젝트의 개발 방향을 이끄는 데 사용되기도 하고, 사후에 생성돼 AI 기반 코드 개선에 활용되기도 한다.

생성된 요구사항 문서는 애자일 개발에서 흔히 볼 수 있는 “user story”/”WHEN/THEN” 패턴을 따른다.

키로에서 생성된 애자일 요구사항 문서의 예IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

설계 문서는 애플리케이션의 구성요소와 아키텍처를 설명하며, 기술 스택 문서보다 훨씬 더 세부적인 내용을 다룰 수 있다.

키로 설계 문서의 예IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

작업 목록에는 프로젝트 제작의 모든 단계가 자세히 기술된다. 인터랙티브 방식이므로 각 단계에서 자동으로 생성된 “시작” 또는 “다시 시도” 링크를 클릭해서 트리거할 수 있다.

키로 작업 목록에는 애플리케이션 개발의 모든 단계가 세부적으로 기술된다.IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

키로를 위한 개발 프로세스 가이드

키로는 작업 목록의 각 항목에서 현재 하고 있는 일, 편집 중인 파일, 실행해야 하는 명령에 대한 실시간 피드백을 제공한다. 개발자는 모든 단계에서 수동으로 개입해 파일을 변경하거나 실행할 명령을 수정할 수 있다.

키로는 개발 프로세스 전반에 걸쳐 라이브 피드백을 제공한다.IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

키로를 자동 실행으로 두고 최대한 많은 부분을 자율적으로 생성하도록 할 수도 있지만, 필자는 각 단계를 지켜보면서 피드백을 확인하기로 했다. 결과적으로 이 선택은 옳았다. 예를 들어 모든 파이썬 명령이 py(윈도우에서)로 실행되도록 하는 등 수시로 개입해야 했기 때문이다. 키로에 이 작업을 일관적으로 수행하도록 지시해서 제대로 된 결과를 받아본 경우는 딱 한 번이었다. steering 문서를 수정해서 명시적으로 언급해도 별 효과는 없었다.

키로의 자동화된 동작 중 상당수는 완료하는 데 몇 분이 걸리므로 확인이 필요할 때 시스템 트레이에 알림을 표시하도록 설정해 두고 다른 창으로 전환해서 다른 작업을 수행할 수 있다. 하던 일을 중지했다가 다시 이어서 해야 하는 경우(예를 들어 업데이트를 위한 시스템 재시작 시) 키로는 프로젝트 문서를 다시 읽어 어디서 작업이 중지됐는지를 파악한다. 그러나 이 작업에도 몇 분이 걸린다. 필자의 경우 세션을 이어서 하려고 시도하는 과정에서 API 시간 초과를 여러 번 경험했다.

키로가 코드를 다루는 방식에서 한 가지 이상한 문제는 코드를 실행하기 전에 기계적인 린팅이나 구문 검사를 시도하지 않는다는 점이다. 소스 코드와 테스트 코드를 불문하고 많은 코드 예제에는 별도의 린팅 단계가 있었다면 쉽게 잡아냈을 구문 오류가 있었다.

키로가 생성한 파이썬 코드의 구문 오류IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

키로의 테스트 중심 개발

키로는 프로젝트 생성의 모든 단계에서 단위 테스트를 작성하고 검증을 시도한다. 테스트가 실패하면 키로는 잘못된 부분을 판단해 설명하고 테스트를 수정한 후 다시 시도한다.

문제가 있던 초기 테스트 중 하나는 정적 사이트 생성기를 위한 프리뷰 서버와 관련된 테스트다. 테스트가 완료된 후 서버를 중지해야 한다는 점을 고려하지 않고 테스트가 작성된 것으로 보인다. 필자가 이 문제를 설명하자 키로는 다음과 같은 몇 가지 수정안을 제시했다.

IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

처음으로 제안한 수정안은 문제 해결에 도움이 되지 않았다. 그러자 키로는 테스트를 완전히 다시 작성할 것을 제안했다.

IDG

<이미지를 클릭하시면 크게 보실 수 있습니다>

다시 작성한 테스트도 여전히 실패하자 키로는 다른 방식을 시도했다. 이 과정에서 실패한 테스트에 대한 모든 호출을 교체해야 했으며 그에 따른 여러 번의 재시작도 필요했다(클로드 시간 초과도 두 번 발생). 이후 또 다시 시간 초과가 발생하자 키로는 테스트가 아직 멈춰 있는 상태라고 잘못 판단했다(실제로는 그렇지 않았음). 결국 필자는 더 큰 문제를 피하기 위해 전체 단계를 다시 시작할 수밖에 없었다.

또한 생성된 테스트 묶음은 어떤 부분은 매우 잘 다루지만 어떤 부분은 전혀 다루지 않는다. 예를 들어 최종 통합 단계에서 정적 사이트 생성기용으로 생성된 샘플 콘텐츠에 템플릿이 없다는 이유로 테스트가 실패했는데, 테스트에서 이 문제가 제기되었음에도 불구하고 키로는 마지막 체크리스트 항목을 완료할 때까지 누락된 템플릿 중 어느 하나도 생성하지 않았다. 또한 “파이썬 베스트 프랙티스”에 대한 샘플 게시물 중 하나는 내용이 전혀 맞지 않았다.

맺음말

이제는 대부분의 사람들이 AI가 생성한 코드의 한계와 위험을 인지하고 있다. 키로는 반복적인, 그리고 문서와 가이드라인을 중심으로 하는 설계를 통해 이 두 가지 문제를 모두 해결하고자 하지만 이러한 해결책에도 마찬가지로 한계가 있다. 예를 들어 생성형 AI의 컨텍스트 크기 제한은 파일 수가 많은 프로젝트를 빌드할 때 여전히 문제를 일으킨다. 또한 설계 문서는 모델에 전송되는 다른 지침과 동일한 방식으로 평가되기 때문에 평가의 일관성도 보장되지 않는다.

AI 생성 코드는 장황하거나 오버엔지니어링되는 경향이 있는데, 키로가 생성한 코드도 마찬가지다. 키로가 생성한 가상 환경 검사기는 파이썬 코드 230줄로 작성됐다. 이 검사기에 포함된 다양한 명령줄 스위치(JSON으로 내보내기 옵션 등)는 편리하고 유용하긴 하지만 필자가 명시적으로 요청하지 않은 스위치다. 기본적인 기능만 한다면 20줄 정도의 코드로 충분했을 것이다.

키로의 또 다른 중대한 문제는 모든 유용한 기능이 클로드 소넷 API를 통해 제공되는 상황에서 시간 초과와 컨텍스트 손실이 끊임없이 발생해 사용하기가 매우 불편하다는 점이다. 정식 출시와 함께 백엔드 용량이 확장되면 이 부분을 포함해 키로를 재평가해 볼 가치가 있을 것이다. 다만, 성능이 괜찮은 컴퓨터를 보유한 사람들을 위한 컴팩트한 로컬 모델 기반의 경쟁 제품이 등장할 가능성도 충분히 상상할 수 있다.

dl-itworldkorea@foundryco.com