Kiro 사용자 인터뷰 #1 - VPPLAB 정희인님
재생에너지 스타트업에서 Kiro를 팀 단위로 도입하고 Spec-Driven Development로 개발 문화를 바꾼 이야기
들어가며
Kiro Startups Credit Program이 다시 오픈되었습니다. 신청 후 선정된 스타트업은 최대 1년간 Kiro Pro+ 크레딧을 AWS Organization 계정에 자동 적용받을 수 있는 혜택인데요. 실제 이 프로그램에 참여하고 있고, Kiro를 팀 단위로 사용하고 있는 분의 이야기를 들어보고 싶었습니다. 첫 번째 인터뷰이로 재생에너지 IT 플랫폼 스타트업 VPPLAB의 정희인님을 만났습니다.
회사와 역할 소개
Q. 회사 소개를 부탁드립니다.
저희 브이피피랩(VPPLAB)은 재생에너지 IT 플랫폼인 'flow-V'를 서비스하고 있습니다. 쉽게 설명하면 통합발전소(VPP) 플랫폼이라고 보시면 되는데요.
풍력이나 태양광 같은 재생에너지 발전사업자들의 발전량을 예측하고, 전력거래소 시장에서 입찰이나 전력 중개까지 함께 수행하는 역할을 하고 있습니다.
회사는 포스코에너지 사내벤처 1호로 시작했고, 창업한 지는 이제 5년 정도 됐습니다. 재생에너지 시장 자체가 정책 변화나 제도 변화가 굉장히 빠른 분야인데, 특히 제주도가 국내 재생에너지 실증과 테스트베드 역할을 하고 있다 보니 본사는 제주에 두고 있고, 개발과 연구를 위해 서울 연구소도 함께 운영하고 있습니다.
현재는 국내 시장에서도 꽤 의미 있는 규모로 성장했습니다. 전국 기준으로 약 1GW 정도의 풍력 발전량을 예측·운영하고 있는데, 국내에서는 최대 수준의 운영 규모라고 볼 수 있고요. 발전량 예측 정확도 역시 평균적으로 92% 이상을 유지하고 있습니다. 특히 제주 풍력 입찰 시장에서는 약 52% 수준의 점유율을 기록하고 있어서, 실제 시장 안에서도 어느 정도 확실한 위치를 확보한 상태입니다.
재생에너지 시장 자체가 전 세계적으로 굉장히 빠르게 성장하고 있는 분야다 보니, 저희도 그 흐름에 맞춰 플랫폼과 예측 시스템을 계속 고도화하면서 빠르게 성장하고 있습니다. 앞으로의 성장이 더욱 기대됩니다.
Q. 현재 맡고 계신 역할은요?
처음에는 테크 리드 역할과 시니어 백엔드 개발자로 조인했는데, 지금은 데이터 팀장을 겸임하고 있습니다. 팀 내 구성은 개발팀 4명, 데이터팀 3명 포함해서 총 7명 정도가 개발과 데이터 관련 업무를 처리하고 있어요.
Kiro 도입 계기
Q. Kiro를 도입하게 된 계기가 궁금합니다.
AWS에 있을 때 Amazon CodeWhisperer 베타 테스트에 참여한 경험이 있어서 AI 코딩 어시스턴트에 계속 관심을 갖고 있었어요. 그러다 Amazon Q Developer가 나왔을 때 써봤는데 그때는 코드 퀄리티가 너무 안 좋아서 안 쓰다가, Kiro가 나왔을 때 사용해보니 코드 퀄리티부터 사용 편의성이 너무 괜찮았습니다.
그래서 회사에 "이거 써보자"라고 얘기를 했고, 우선 테스트로 1개 계정만 결제해서 사용하려고 서치하던 중 Kiro for Startup Support 프로모션 페이지를 발견해서 신청을 먼저 했어요. 그다음에 AWS 어카운트 매니저한테 문의 메일도 보냈고요. 다행히 메일 보내고 나서 프로모션 페이지가 마감됐는데, 미리 신청한 게 도움이 됐죠.
약 2주 정도 걸려서 승인을 받았고, 신청할 때 들어간 내용은 인원수가 몇 명인지, 시리즈가 어느 정도인지 정도만 물어본 것 같아요. 현재 10명이 1년 동안 쓸 수 있는 크레딧으로 $4,800을 받아서 올해 1월부터 전체 팀에서 사용하고 있습니다.
왜 Kiro인가 - Spec-Driven Development
Q. Kiro에서 가장 만족스러운 부분은 무엇인가요?
스펙 기반 개발(Spec-Driven Development)이 가장 좋았어요. Requirement, Design, Task 문서를 중심으로 개발 흐름이 정리되는 점이 너무 괜찮았습니다. 단순 코드 생성보다 개발 프로세스를 구조화해주는 느낌이 강했어요.
솔직히 Spec-Driven을 안 쓸 거라면 굳이 Kiro를 써야 하나 싶을 정도입니다. 저는 지금도 주로 Kiro IDE에서 스펙을 만들고 그 내용을 확인하고 처리하는 방식으로 사용하고 있어요.
Q. Claude Code 같은 CLI 도구 대비 Kiro의 장점은 뭘까요?
Claude Code는 자유도가 높지만 관리 포인트가 많아지잖아요. 다양한 파일을 만들어야 하는 상황이 벌어지는데, Kiro는 Requirement, Design, Task 딱 세 개 문서만 잘 작성하면 개발이 무리 없이 진행됩니다. 개발자들도 헷갈릴 필요 없고, 프로세스가 딱 잡히니까 훨씬 깔끔해요. 팀 단위 운영에서 특히 강점이 있다고 느낍니다.
팀의 개발 프로세스 변화
Q. Kiro 도입 이후 가장 크게 바뀐 부분은요?
코드를 먼저 시작하는 게 아니고 문서를 먼저 만드는 문화로 바뀌었어요. 현재 프로세스는 이렇습니다:
- 기획에서 기획서 작성
- 개발자가 Kiro에서 Spec 문서 생성
- Requirement / Design / Task 문서 리뷰
- 필요 시 기획과 다시 커뮤니케이션
- Task 단위로 개발 진행
CLI를 주로 쓰는 팀원들도 일단 문서를 가져와서 넣어놓고, 그 문서 기반으로 실행하는 형태가 됐습니다.
Q. 코딩 전 문서를 실제로 읽고 리뷰하고 있나요?
Requirement, Design, Task 세 개 문서는 반드시 읽으라고 팀 규칙을 정해뒀어요. 특히 Requirement는 무조건 읽으라고 하고 있습니다. 요구사항 하나가 잘못되면 결과물이 너무 달라지거든요. Task 실행은 작업 스타일에 따라 자유롭게 진행하지만, 앞단의 Requirement, Design 문서 리뷰는 필수입니다.
팀 단위 운영 팁 - Global Steering 관리
Q. 팀 단위 운영에서 가장 중요한 팁이 있다면?
Global Steering 파일 관리가 가장 중요합니다. 개인이 쓸 때는 빡빡하게 작성하지 않아도 상관없는데, 팀 단위로 할 때는 이걸 어떻게 만드느냐가 결과물을 크게 좌우해요.
구체적인 팁을 말씀드리면:
- 영문으로 압축해서 작성 - 토큰 소비를 줄이기 위해 내용을 압축한 뒤 영문 버전으로 번역해서 넣고 있어요.
- 빌드 폴더 제외 필수 -
build/,bin/같은 폴더를 읽지 않도록 명시해야 합니다. 안 그러면 빌드된 파일까지 다 읽어서 토큰이 두 배 이상 소모되는 경우가 발생해요. - 컨벤션과 아키텍처 규칙 정의 - 모델이 원하지 않는 컨벤션을 작성하는 경우가 많기 때문에, 여러 사람이 같은 프로젝트를 진행할 때 서로 다른 결과물이 나오지 않도록 가이드를 잡아주는 게 가장 먼저 해야 할 작업입니다.
- 절대 수정하면 안 되는 코어 파일 명시 - 수정 시 반드시 사람에게 승인받도록 문구를 넣어뒀어요.
운영 방식으로는 별도 가이드 저장소를 만들고, 레포지토리 클론 시 Global Steering 디렉토리에서 바로 받을 수 있도록 쉘 스크립트를 구성했습니다. 업데이트될 때마다 팀원들에게 동기화하라고 안내하고 있어요.
MCP 활용
Q. MCP도 활용하고 계신다고요?
네, 적극적으로 쓰고 있습니다. Jira, Figma, IDE 등을 MCP로 연결해두고 Kiro 안에서 필요한 정보를 최대한 해결할 수 있도록 방향을 잡고 있어요. 지금은 Kiro 사용에 익숙해지는 적용 단계를 지나서 MCP와 Powers 쪽을 본격적으로 써보려는 중급 단계로 올라가고 있는 중입니다.
실제 생산성 향상 사례
Q. 체감되는 생산성 향상 사례가 있을까요?
데이터 팀에서 사용하던 배치 애플리케이션이 약 25개 있었는데, 전부 단일 Python 스크립트 파일로 되어 있었어요. 이걸 한 달 동안 Kiro만 활용해서 프레임워크를 입히고, 테스트와 시뮬레이션까지 포함해 전체 마이그레이션을 혼자 완료했습니다. 직접 했다면 한 달 만에 끝날 수 있는 작업은 아니었을 거예요.
그리고 기능 추가 시에도 기존에 5일 정도 걸리겠다 싶었던 작업이 2~3일 만에 나오는 경우가 자주 발생합니다. 특히 Claude Opus 4.6 이후부터는 코드 퀄리티가 너무 좋아져서 더 빨라진 느낌이에요.
모델 사용 전략
Q. 모델은 어떻게 선택해서 사용하시나요?
Auto 모드는 거의 사용하지 않습니다. 퀄리티가 기대보다 안 나와서 결국 다시 Opus나 Sonnet으로 해야 하는 상황이 발생하거든요. 그럴 바에는 처음부터 퀄리티 있는 모델을 쓰는 게 낫다고 판단했어요.
실제 사용 패턴은:
- Spec 문서 작성: Sonnet 4.6
- 디버깅: Opus
- 일반 개발: Sonnet, Opus 혼합
팀에도 이렇게 가이드를 줬고, 크레딧을 아끼면서도 퀄리티를 유지하는 방식으로 운영하고 있습니다.
불편한 점과 대응 방법
Q. 사용하면서 불편했던 점은요?
두 가지 정도 있어요.
첫째, 터미널 출력 버그입니다. Python 검증 스크립트 실행 시 출력이 길어지면 중간이 잘리는 문제가 있어요. 지금은 복사해서 직접 실행하는 방식으로 대응하고 있습니다.
둘째, Context 자동 요약 문제입니다. 요약 후 맥락을 잘못 이해하는 경우가 있어서, 컨텍스트 사용량이 70% 정도 됐을 때 직접 전체 컨텍스트를 요약해달라고 한 다음 새로운 컨텍스트를 열어서 진행하는 방식으로 수동 관리하고 있어요.
개인 vs 팀 사용의 차이
Q. 개인 사용과 팀 사용의 가장 큰 차이는 뭘까요?
개인 사용에서는 큰 차이를 못 느낄 수도 있어요. 하지만 팀 단위에서는 컨벤션 통일, 결과물 일관성 유지, Global Steering 관리가 매우 중요하고, 이 부분이 성패를 좌우합니다. 같은 프로젝트 구조 안에서 서로 다른 결과물이 나오는 경우가 많기 때문에, 가이드레일을 잘 설정해주는 게 팀 단위 작업에서 가장 먼저 해야 할 일이에요.
Kiro 추천 대상
Q. 마지막으로 Kiro를 추천하고 싶은 대상이 있다면?
이미 다른 AI 툴에 익숙하다면 굳이 억지로 바꿀 필요는 없다고 생각해요. 하지만 Spec-Driven Development를 해보고 싶거나, 팀 전체의 싱크를 맞춰서 개발하고 싶다면 Kiro를 추천합니다.
비용 관점에서도 AWS를 이미 쓰고 있다면 Kiro 사용료가 AWS Billing에 포함되어 나오기 때문에 따로 비용을 이원화할 필요가 없어서 좋아요.
그리고 한 가지 팁을 드리자면, AWS IAM Identity Center로 조직을 생성해야 하는데 MSP나 통합 빌링 구조에서는 조직 생성이 막혀 있을 수 있어요. 이 경우 MSP사에 요청해서 권한을 열어달라고 하면 해결 가능합니다.
개발 외에도 데이터 분석이나 시뮬레이션 같은 작업에도 활용 가능하니까, 안 써본 분들에게는 적극 추천하고 있습니다.