Kiro IDE로 오픈 소스 Kahoot 대안을 만들었습니다. 성공한 점과 실패한 점을 공유합니다.

저는 뱅갈로르(Bangalore)에서 많은 밋업(Meetup)을 운영하고 있는데, 분위기를 환기하고 경품(Swag)을 나눠줄 때 항상 찾게 되는 것이 바로 인터랙티브 퀴즈 도구입니다. Kahoot, Slido, Mentimeter 모두 이 기능을 잘 수행하지만, 모두 유료 서비스입니다. 저는 직접 셀프 호스팅(Self-host)하고 수정할 수 있는 무언가를 원했습니다.

그래서 실시간 인터랙티브 퀴즈를 위한 오픈 소스(Open source) 대안인 Hoot를 만들었습니다. 이벤트를 생성하고, 질문을 추가하고, 게시한 뒤, QR 코드나 참여 코드를 공유하면 청중이 자신의 휴대폰으로 실시간 참여할 수 있습니다. 표준적인 형식이며, 마지막에는 리더보드(Leaderboard)가 제공됩니다.

라이브 버전: hoot-the-quiz.vercel.app
소스 코드: github.com/PriteshKiri/hoot

비디오 가이드를 먼저 보고 싶으시다면 여기 있습니다:

흥미로운 점은 앱 자체보다 제가 이를 어떻게 만들었느냐 하는 것입니다. 저는 채팅 우선(Chat-first) 방식 대신 사양 우선(Spec-first) 접근 방식을 취하는 AWS의 에이전틱 IDE(Agentic IDE)인 Kiro를 사용했습니다. 이 포스트에서는 Hoot이 무엇을 하는지, Kiro의 워크플로우(Workflow)가 실제 빌드 과정을 어떻게 형성했는지, 그리고 제가 Kiro가 개선해주길 바라는 점들을 솔직하게 나열해 보겠습니다.

Hoot이 하는 일

흐름은 Kahoot 스타일의 도구에서 기대할 수 있는 것과 거의 유사합니다.

로그인하면 이벤트 대시보드(Dashboard)로 이동합니다. 이벤트는 단일 퀴즈 세션에 범위가 지정된 일련의 질문들을 담는 컨테이너일 뿐입니다. 클릭 몇 번만으로 "Python Meetup"이라는 이벤트를 만들고, 테마와 그라데이션(저는 노을 색상을 선택했습니다)을 고른 뒤 질문을 추가하기 시작할 수 있습니다.

각 질문은 유형(단일 선택 또는 다중 선택), 시간 제한, 옵션, 정답을 가집니다. 질문이 모두 입력되면 이벤트를 게시합니다. 게시를 하면 QR 코드와 참여 코드가 생성됩니다. 참가자들은 코드를 스캔하거나 입력하고, 이름을 선택한 뒤 로비(Lobby)에서 대기합니다. 세션을 시작하면 모두가 휴대폰으로 답을 하고, 라운드 사이마다 정답 여부와 속도에 따라 리더보드가 업데이트됩니다.

이것이 제품의 전부입니다. 획기적인 것은 없지만, 잘 작동하며, 무료이고, 코드는 오픈 소스입니다.

Kiro의 스펙 워크플로우(spec workflow)가 빌드 과정을 어떻게 형성했는가

저는 지금까지 수많은 AI 코딩 도구들을 사용해 왔습니다. Kiro에서 가장 눈에 띄는 점은 코드로 시작하지 않는다는 것입니다. Kiro는 스펙(spec)에서 시작합니다.

제가 Hoot을 설명하는 초기 롱 프롬프트(long prompt)를 입력했을 때, Kiro는 곧바로 파일로 뛰어들어 컴포넌트(component)를 작성하기 시작하지 않았습니다. 대신 .kiro/specs/ 폴더를 생성하고 세 개의 파일을 만들었습니다:

• requirements.md: 제품이 수행해야 할 기능들을 평이한 언어로 구조화하여 분석한 문서
• design.md: 코드 작성 전의 아키텍처(architecture), 데이터 모델(data model), 컴포넌트 계층 구조(component hierarchy) 및 모든 설계 결정 사항을 담은 문서
• tasks.md: 우선순위가 지정된 작업 목록으로, 선택 사항은 별도로 표시됨

작업 목록(task list)은 저를 놀라게 한 부분이었습니다.

이 목록은 포괄적이고 정확했으며, Kiro가 하나씩 처리하며 완료 표시를 할 수 있도록 작은 단위(chunks)로 나뉘어 있었습니다. Kiro는 마치 신중한 엔지니어처럼 행동합니다. 즉, 계획하고, 분해하고, 실행하고, 완료를 표시합니다.

빌드 자체는 약 2주간의 파트타임 작업이 소요되었습니다. 한 가지 덧붙이자면, 각 계정당 50 크레딧만 제공되기 때문에 5개의 무료 계정을 소진했다는 점입니다. Hoot은 50 크레딧으로 끝낼 수 있는 프로젝트가 아니었습니다.

Powers와 MCP

제가 의존했던 Kiro의 또 다른 기능은 Powers였습니다.

Powers는 Kiro가 외부 도구 및 통합(integrations)을 처리하는 방식입니다. 에이전트(agent)를 많은 MCP 서버에 연결할 때 발생하는 일반적인 문제는 컨텍스트 과부하(context overload)입니다. 만약 에이전트가 항상 20개의 도구에 접근할 수 있다면, 매 요청마다 무엇이 관련 있는지 결정하는 데에만 컨텍스트를 소모하게 되며, 응답은 더 느려지고 정확도는 떨어지게 됩니다.

Kiro의 접근 방식은 도구 컨텍스트를 필요할 때만 로드하는 것입니다. 프롬프트를 제출하면 Kiro는 작업을 분석하고 그와 관련된 Powers만 활성화합니다. Hoot의 경우, 스키마(schema) 변경이나 실시간 구독(realtime subscriptions) 작업을 할 때는 Supabase Power가 활성화되었고, 그 외의 경우에는 방해되지 않도록 비활성 상태를 유지했습니다.

Powers 패널에는 설치 가능한 카탈로그가 포함되어 있습니다: Supabase, Neon, Netlify, Postman, Datadog, Figma 등이 있습니다. 설치는 클릭 한 번으로 이루어지며, 설정은 짧은 양식(form)을 작성하는 방식입니다. 저는 1분도 채 되지 않아 IDE 내부에서 Supabase를 네이티브로 실행할 수 있었고, 이는 제가 창 사이를 복사하여 붙여넣는 대신 Kiro가 직접 SQL 마이그레이션(migrations)과 스키마 스크립트를 실행할 수 있음을 의미했습니다.

Kiro가 더 잘했으면 하는 점

경험이 모두 매끄럽지는 않았기에 솔직해지고 싶습니다. 몇 가지 방해 요소가 있었습니다.

권한에 대한 "항상 허용" 기능 부재. Kiro가 수행하는 모든 작업은 명시적인 승인을 요청합니다. 계획하고 실행하도록 설계된 에이전트형 IDE(agentic IDE)임에도 불구하고, 몇 초마다 앉아서 '수락'을 클릭해야 하는 것은 작업 흐름(flow)을 끊습니다. Cursor와 Claude Code는 모두 이를 위해 권한 계층 시스템(permission tier system)을 갖추고 있습니다. Kiro도 그래야 합니다.

컨텍스트가 가득 차면 채팅 기록이 사라집니다. 채팅이 컨텍스트 제한(context limit)에 도달하면, Kiro는 관련 컨텍스트를 새로운 채팅으로 가져가지만 이전 채팅은 사라집니다. 이로 인해 이전에 입력했던 프롬프트(prompts)를 확인할 수 없게 되었는데, 이는 특정 결정이 왜 내려졌는지 기억하려고 할 때 문제가 됩니다. 요약본은 계속 유지되어야 하며, 채팅 자체는 삭제되는 것이 아니라 아카이브(archived)되어야 합니다.

응답 내 파일 참조가 클릭 가능하지 않습니다. Kiro가 응답에서 특정 파일을 언급할 때, 저는 탐색기(explorer)에서 수동으로 해당 파일로 이동해야 합니다. 다른 IDE들은 이러한 참조를 바로 이동할 수 있는 점프 링크(jump-to links)로 만듭니다. 사소한 문제지만 마찰(friction)이 큽니다.

음성 입력이 없습니다. 저는 현재 원하는 바를 말하면서 코딩을 많이 합니다. 긴 프롬프트를 직접 타이핑해야 하는 것은 역행하는 느낌입니다. 음성 기능이 추가된다면 정말 큰 업그레이드가 될 것입니다.

Powers 인식 기능이 일관적이지 않습니다. 때때로 Kiro는 워크스페이스(workspace)에 어떤 Powers가 설치되어 있는지 잊어버려, 제가 직접 "이 작업에는 Supabase Power를 사용해줘"라고 명시적으로 말해야 할 때가 있습니다. 스스로 알고 있어야 합니다. 이것이 무료 플랜의 제한 사항일 수도 있지만, 눈에 띄는 부분이었습니다.

오래된 의존성(dependencies)을 가져왔습니다. Kiro가 프로젝트를 초기화할 때 Next.js, Tailwind 및 기타 몇몇 패키지의 최신 안정 버전을 선택하지 않았습니다. 나중에 제가 수동으로 버전을 올려야(bump) 했습니다. 프로덕션 준비가 된(production-ready) 앱을 스캐폴딩(scaffold)하기 위한 도구라면, 이것은 기본 설정이어야 합니다.

때때로 느렸습니다. 치명적인 수준은 아니었지만, 인지할 수 있을 정도였습니다. 가끔 단순한 프롬프트조차 스트리밍(streaming)이 시작되기까지 오랜 시간이 걸렸습니다. 이런 현상이 언제 발생하는지에 대한 패턴은 파악하지 못했습니다. 무료 플랜 때문일 수도 있습니다.

채팅에서 이미지가 너무 많은 공간을 차지합니다. 채팅창에 스크린샷을 넣으면 패널의 절반을 차지해 버립니다. 클릭하면 확대되는 썸네일(thumbnails) 방식이 훨씬 더 나을 것입니다.

새 채팅을 위한 "의도 (intent)" 선택기가 없습니다. 제가 새 채팅을 시작할 때, Kiro는 제가 버그를 수정 중인지, 리팩터링 (refactoring) 중인지, 아니면 새로운 기능을 추가 중인지 알지 못합니다. 새 채팅 상단에 의도(버그 수정, 기능 작업, 리팩터링, 문서 업데이트)를 설정할 수 있는 작은 드롭다운 메뉴가 있다면, 에이전트 (agent)에게 유용한 사전 정보 (prior)를 제공하여 제가 매번 일일이 설명하지 않아도 응답 품질을 개선할 수 있을 것입니다.

결론 (Closing)

여러 가지 미흡한 점에도 불구하고, Kiro에서 Hoot을 구축하는 것은 채팅 우선 (chat-first) 도구들과는 진정으로 다른 경험이었습니다. 명세 기반 (spec-driven) 흐름은 코드를 생성하기 전에 제품에 대해 깊이 생각하도록 강제했으며, 이는 결과적으로 제가 얻은 코드가 일반적인 산만한 출력물보다 더 일관성 있게 만들어 주었습니다. 스티어링 파일 (steering files) 덕분에 Kiro는 세션 전반에 걸쳐 경로를 유지할 수 있었습니다. Powers 시스템은 컨텍스트 (context)를 깔끔하게 유지해 주었습니다.

모임, 컨퍼런스 또는 워크숍을 운영하며 직접 호스팅하고 수정할 수 있는 퀴즈 도구를 찾고 있다면, Hoot을 한 번 사용해 보세요. PR (Pull Requests)은 언제나 환영합니다.

• Hoot GitHub: github.com/PriteshKiri/hoot
• Hoot 라이브 데모: hoot-the-quiz.vercel.app
• Kiro: kiro.dev