내가 Kiro를 사용하는 방법: 오토파일럿이 아닌 팀원으로서

1. 내가 Kiro를 사용하는 이유

나는 거의 1년 동안 Kiro를 사용해 왔으며, 클라우드 아키텍트 (Cloud Architect)로서 그리고 재미를 위한 사이드 프로젝트 (side projects)를 구축하기 위해 사용하고 있습니다. 다른 도구들보다 Kiro를 사용하는 주된 이유는 이 도구가 엔지니어인 당신과 함께 일하는 방식 때문입니다. 몇 달 동안 Kiro를 사용하는 방식에서 몇 가지 패턴을 발견했습니다. 그것들을 살펴보겠습니다:

1. 내가 Kiro를 사용하는 이유
1. Kiro와의 페어 프로그래밍 (Pair Programming)
1. 기술 (Skills)로서의 반복 가능한 워크플로 (workflows)
1. 플랜 (Plan), 스펙 (Specs) 및 에이전트 (Agents) 사용하기
1. 에이전트 의회 (Council of agents)
1. 문서화, 문서화, 문서화
최종 생각

2. Kiro와의 페어 프로그래밍 (Pair Programming)

내가 Kiro를 사용하는 가장 일반적인 방식은 페어 프로그래밍 (Pair Programming)입니다. 페어 프로그래밍 (Pair Programming)은 2명의 개발자가 동일한 작업에 함께 참여하는 것을 말하며, 이들은 협력하여 작업하거나 한 명이 가이드/계획을 세우는 동안 다른 한 명이 코드를 작성할 수 있습니다. 나의 경우, Kiro를 사용할 때 내가 가이드와 계획을 세우는 역할을 하고 Kiro가 코드를 실행하고 구현하는 역할을 합니다.

나는 또한 Kiro를 나의 러버 덕 (rubber duck)으로 사용하고 있습니다. 새로운 아이디어가 있거나 해결되지 않는 버그 (blocking bug)를 작업하고 있을 때, Kiro에게 말을 걸어 다른 관점을 얻거나, 조사하고, 나를 좋은 관행 (good practices)으로 이끌 수 있도록 합니다.

내가 이런 방식으로 작업하는 주된 이유는 세션이 끝나면 프롬프트 (prompt)/기술 (skill)을 실행하여 세션의 모든 내용을 기록할 수 있기 때문입니다:

Kiro, 이 세션을 요약해서 yyyymmdd 형식의 마크다운 (markdown) 파일로 .memory 폴더에 저장해줘

그러면 우리가 수행한 모든 내용이 그곳에 기록됩니다.

당신은 어제 했던 모든 일을 기억하나요? 아마 그럴 것입니다. 하지만 지난주는 어땠나요? 한 달 전은요? 나는 확실히 기억하지 못합니다.

전형적인 소프트웨어 개발 생명 주기 (Software Development Life Cycle, SDLC)에서는 티켓 (tickets)이 존재하며, 이 모든 정보를 회상할 수 있는 방법도 있습니다. 하지만 왜 그 작업을 수행했는지에 대한 더 상세한 맥락 (context)은 완전히 누락될 것입니다.

이제 Kiro와 같은 도구를 사용하면 이를 기억하는 것이 가능합니다. 모든 세션 (sessions)을 요약해 두는 .memory 폴더를 가지고 있기만 하면 됩니다. 따라서 미래에는 다음과 같은 상황이 발생할 수 있습니다:

아, 두 달 전에 이 클러스터 (cluster)에서 어떤 변경 사항을 적용했는지 기억이 안 나는데, 지금 상사가 그것에 대해 묻고 있어. 두 달 전의 세션들을 바탕으로, 클러스터에서 우리가 무엇을 했는지 날짜순으로 알려줘.

그러면 Kiro가 저를 구해줄 것입니다.

3. 스킬 (Skills)로서의 반복 가능한 워크플로우 (workflows)

DevOps 엔지니어로서의 제 경험은 모든 것을 자동화하도록 가르쳐 주었습니다. 때때로 여러분은 다음과 같은 반복적인 작업을 수행하기 위해 Kiro를 사용할 것입니다:

AWS에 접속하여 과금 상태 (billing state) 및 예산 할당량 (budget quotas) 확인하기;
우리가 사용하는 코드베이스 (codebase) 및 버전들에 대해 최근의 CVE (Common Vulnerabilities and Exposures) 보안 점검 수행하기;
지난주에 발생한 모든 알림 (alerts) 검토하기.

이것들은 제가 수행하는 반복적인 일들이며, Kiro에게 계속해서 요청하는 특정 스크립트 (scripts)나 명령 (commands)들이 있습니다.
우리는 이를 프롬프트 (prompt)나 스킬 (skill)로 기록함으로써 자동화할 수 있습니다. Kiro를 사용하면 저는 그저 이렇게 말할 수 있습니다:

좋아, 방금 이 모든 작업을 마쳤어. 이제 이것을 스킬이나 프롬프트로 기록해 줘.

그렇게 하면 다음에 과금을 검토하거나 알림을 검토해야 할 때, 저는 Kiro에게 이렇게 요청하기만 하면 됩니다:

알림을 검토하자, alerts_review.md 스킬을 사용해줘.

그러면 Kiro는 해당 스킬을 읽고 우리가 이미 설계한 대로 작업을 시작할 것입니다. 처음 수행했을 때 제대로 작동했다면, Kiro가 동일한 단계를 사용하도록 보장하는 데 도움이 되며, 이는 환각 (hallucination) 현상이나 주요 목표에서 벗어나는 현상을 줄여줍니다. 만약 반복 가능한 작업이라면, 이를 기록하여 나중에 다시 사용할 수 있도록 만드세요.

4. Plan, Specs 및 Agents 사용하기

저는 보통 세 가지 주요 단계를 따라 새로운 작업을 시작합니다:

첫째, 플랜 모드 (plan mode, CLI 내장 기능)로 들어갑니다. 작업의 요지를 전달하면 Kiro와 함께 질의응답 (question-answer) 세션을 진행하며 목표, 공백(gaps), 그리고 구현 사항을 명확히 합니다. 개인적으로 이 기능을 매우 좋아하는데, 이러한 주고받는 피드백 과정은 단순히 계획을 제대로 세우는 것을 넘어 제가 문제를 깊이 생각하게 도와줍니다. 계획이 끝나면 이를 스펙 (Spec)으로 작성하도록 요청합니다.
IDE에서의 대안은 내장된 스펙 (Spec) 기능을 사용하는 것입니다. 이는 Requirements.md, Design.md, Task.md를 생성하며, 각 파일 뒤에 중단점(breaks)을 두어 내용을 읽고 검증할 수 있게 해줍니다. 스펙 (Specs)은 당면한 작업을 정의하는 데 유용할 뿐만 아니라, 작업을 구현하기 위해 내려진 결정 사항들을 기록으로 남기는 데도 유용합니다.
마지막 단계는 Kiro가 제가 만든 커스텀 서브 에이전트 (sub-agents)를 사용하도록 확인하는 것입니다. Kiro에게 작업 목록을 검토하고, 서브 에이전트 (sub-agents)와 병렬 실행 (parallel executions)을 사용하도록 최적화해달라고 요청합니다. 저는 이 경우에 매우 유용하게 사용할 수 있는 수많은 커스텀 에이전트 (custom agents)를 담은 Kiro Context를 위한 레지스트리 (registry for Kiro Context)를 구축해 두었습니다.

저는 완전히 자동 승인(auto-approve) 방식으로 진행하지는 않습니다. 저는 그것이 실제로 무엇을 하고 있는지, 그리고 어떻게 수행하고 있는지를 직접 확인하는 것을 선호하며, Kiro가 도구로서 이 부분을 매우 잘 수행한다고 생각합니다. Kiro는 단순히 한 번에(one-shot) 느낌대로 코딩(vibe-code)해버리는 도구가 아닙니다. 무엇을 하고 있는지 보여주고, 피드백과 권한을 요청하는 도구입니다. 엔지니어로서 저는 이러한 방식이 저를 과정에 계속 참여(in the loop)시켜 주기 때문에 정말 높게 평가합니다.

작업 구현이 끝나면 저는 두 가지를 수행합니다:

코드 리뷰 (code review): 스테이징된(staged) 모든 변경 사항을 코드 리뷰하고, 이를 TODO 리스트로 추가하여 하나씩 수정해 나갈 수 있도록 하는 프롬프트를 사용합니다. 저는 '제2의 관점'을 얻기 위해 이 작업을 다른 모델로 수행하는 경향이 있습니다.
프리모템 (Pre-Mortem): 작업 구현이 실패했다고 가정하는 시나리오를 실행합니다. 사후 분석(post-mortem)과 유사하지만, 일이 실제로 일어나기 전에 수행합니다.

5. 에이전트 의회 (Council of agents)

페어 프로그래밍 (pair programming)과 고무 오리 디버깅 (rubber duck method) 방식이 보통 잘 작동하지만, 때로는 다른 관점을 보고 싶거나 새로운 아이디어를 브레인스토밍하고 싶을 때가 있습니다. 이 특정한 경우를 위해 저는 '에이전트 의회 (The Council of Agents)'라고 부르는 것을 구축했습니다.

저는 Opus를 사용하는 서브 에이전트(sub-agent), Sonnet을 사용하는 서브 에이전트, Haiku를 사용하는 서브 에이전트 등을 생성했습니다.
그다음, 특정 작업을 위해 이 서브 에이전트들을 호출하는 의회 통치자(council ruler) 역할을 할 서브 에이전트를 둡니다.

이 방식은 매우 잘 작동합니다. 왜냐하면 그들이 유사한 점들을 볼 수 있으면서도, 각자 보통 서로 다른 무언가를 발견하기 때문입니다. 그런 다음 저는 각 에이전트의 결과물 중 가장 좋은 것을 선택합니다. 이를 통해 심각한 환각 (hallucinations)이 발생할 가능성을 줄입니다.

6. 문서화, 문서화, 문서화

문서화 (Documentation)는 우리 모두가 좋아하지만 실제로 수행하기는 어려운 일입니다. 기존 프로젝트에서 작업을 시작할 때, 저는 보통 모든 문서를 읽으며 더 이상 사용되지 않거나 (deprecated), 사용되지 않는 기능들을 찾아내고, 시스템의 오래된 버전을 접하게 됩니다.

Kiro를 사용하여 제가 이 문제에 접근하는 방식은 코드베이스 (codebase)에 대한 분석을 요청하고 두 가지 주요 마크다운 (Markdown) 파일을 생성하는 것입니다:

Mermaid를 사용한 간단한 다이어그램 (diagram)이 포함된, 이 코드베이스 로직에 대한 매우 높은 수준 (high-level)의 상세 정보.
Mermaid 아키텍처 다이어그램 (Architecture diagrams)과 코드 스니펫 (code snippets)이 포함된, 코드베이스에 대한 매우 깊은 수준 (deep-level)의 상세한 설명.

Kiro가 모든 정보를 수집하여 이 두 개의 마크다운 파일에 넣고 나면, 저는 제가 읽기 쉬운 방식으로 이를 표시할 수 있도록 몇 가지 HTML 파일을 만들어 달라고 요청할 것입니다. 저는 다크 테마 (dark-themed)를 선호하며, 시작 부분에는 요약 (TLDR)을, 마지막에는 피드백/주의 사항 (feedback/gotchas) 포인트를 두는 것을 선호합니다.

그 단계부터는 제가 원하는 특정 사항들에 대해 더 자세히 들어갈 수 있습니다.

어쩌면 저는 다이어그램만 보고 싶을 수도 있고, draw.io 형식으로 확장하거나, 시스템이 어떻게 상호 연결되는지 확인하거나, 코드 스니펫을 표시하거나, SDK 또는 타사 문서를 위한 링크를 추가하고 싶을 수도 있습니다. 따라서 제가 무엇을 하고 싶은지 또는 무엇을 보고 싶은지에 따라, 저는 그것을 요청하고 더 많은 문서를 생성할 것입니다.

마치며

이것이 바로 저가 Kiro를 사용하는 방식입니다. 저에게 있어 이것은 단순히 AI 도구에게 코드를 작성해 달라고 요청하는 것만이 아닙니다. 그것은 제 워크플로 (workflow)의 다양한 부분에서 어떻게 이를 활용할 수 있는지에 더 가깝습니다.

그것이 저에게 중요한 부분입니다. 저는 도구가 그냥 사라져서 모든 것을 스스로 구축하기만을 원하지 않습니다. 저는 그것이 무엇을 하고 있는지 보고 싶습니다. 피드백을 주고 싶습니다. 컨텍스트 (context)를 유지하고 싶습니다. 그리고 잘 작동하는 것들을 재사용하고 싶습니다. 그것이 바로 Kiro가 제 작업 방식에 부합하는 이유입니다.

다른 사람들이 일상생활에서 Kiro나 다른 AI 도구를 어떻게 사용하고 있는지 정말 궁금합니다. 제가 언급한 방식 중 사용하시는 것이 있나요? 여러분에게 잘 작동하는 AI 협업 방식이 있나요? 댓글로 공유해 주세요.