Kiro 사용자 인터뷰 #2 - 메가존클라우드 최지연님
프론트엔드 개발자가 Kiro로 상태 관리를 정복하고, BDD + FSD 조합으로 AI 협업의 가이드라인을 만든 이야기
들어가며
두 번째 인터뷰이로 메가존클라우드의 최지연님을 만났습니다. AWS Community Builder 2년차로 활발하게 활동 중인 프론트엔드 출신 AI 아키텍트인데요. 지연님은 Kiro를 현 회사와 전 회사 모두에서 메인 도구로 사용해왔고, Skills와 Spec Mode를 중심으로 본인만의 AI 협업 방식을 정착시켰습니다.
커뮤니티 활동
Q. 커뮤니티 빌더로 활동하면서 가장 기억에 남는 경험이 있나요?
AWS re:Invent 갔던 게 제일 먼저 떠올라요. 다양한 인종과 나라의 사람들이 클라우드 기술 하나로 모일 수 있다는 게 실감이 나더라고요. 나도 열심히 해야겠다는 생각을 많이 했던 것 같아요.
그리고 키노트에서 느낀 것도 있었는데요. 3년 전만 해도 분업화가 미덕이었다면, 지금은 자신만의 무기를 가지면서도 올라운드로 할 수 있는 르네상스 개발자가 되어야 한다는 걸 직접 체감했습니다.
Q. 올해 JAWS DAYS도 다녀왔죠?
일본은 아날로그라는 선입견이 있는데, 생성형 AI를 정말 적극적으로 활용하고 있어서 놀랐어요. 쓰는 방식도 좀 기발했고요. 한국이랑 접근법이 좀 달랐는데, 예를들면 저희는 AI 에이전트에 일을 시킬 것을 고민하는데, 일본에서 본 사례는 자신의 업무를 감독하고 리뷰 할 보스를 만드는 식으로 접근하더라고요.
분위기 자체도 달랐어요. 진짜 축제 같은 느낌이었거든요. 코스프레하고 오는 분도 있고, AWS 관련 웹툰을 출간해서 나눠주기도 하고요. 포스트맨 부스에서는 자체 AI를 오른편에 IDE처럼 임베딩해둔 것도 인상적이었어요. 도구들이 변화하는 모습이 재밌었습니다.
Kiro 첫 경험
Q. Kiro는 어떻게 처음 접하게 됐어요?
AWS 커뮤니티 활동하다 프리뷰 소식을 접했고, 솔직히 귀여운 캐릭터에 대한 호기심도 있었어요.
당시에 프론트 개발자로서 Copilot 같은 자동완성 도구를 쓰고 있었는데, 맥락을 이해 못해서 코드를 만들었다 지웠다를 반복하는 상태였거든요. 주변 개발자들 사이에서도 "단순히 자동완성, 그 이상 그 이하도 아니다"는 평가가 많았고요.
그러다 Kiro에서 스펙이라는 개념을 처음 봤는데, '이게 개발 히스토리의 기준점이 될 수 있겠다'는 생각이 들었어요. 기대를 많이 했는데 실제로 써보니 기대만큼 잘 나왔어요. 다만 기대와 달랐던 점은 애매하게 말하면 평균치만 나온다는 거였는데, 그걸 통해 오히려 도메인 지식을 쌓아야 한다는 것, LLM과 제대로 티키타카를 해야 한다는 것을 처음 배웠어요.
Q. 다른 도구 사용 경험도 있나요?
개선이 됐을 수도 있지만 Codex는 추론이 너무 길어서 기다리다 지쳤었고요. Claude Code는 작업창을 왔다 갔다 하게 되서 작업할 때는 잘 안 쓰게 됐어요. 압도적인 차이라기보다는, Kiro의 사용성이 좋고 Spec Mode가 자연스럽게 트리거가 잘 된다는 게 계속 쓰게 된 이유인 것 같아요.
메인 도구로 자리잡기까지
Q. Kiro를 메인 도구로 쓰는 이유가 뭔가요?
별도 플러그인 추가 없이 그 자체로 완성형이고, 접근성이 너무 쉬웠어요. 저한테 너무 가볍게 다가와서 알아서 만들어주고 눈에 보이고. IDE가 CLI보다는 느릴 수 있지만, 프론트엔드 작업 특성도 있기도 하고 개인적으로는 코드를 보면서 LLM을 하는 게 훨씬 낫거든요. 프론트 작업은 IDE 위주로, 인프라 작업은 CLI로 나눠서 쓰고 있어요.
Skills - 상태 관리 정복
Q. 요즘 제일 자주 쓰는 기능이 뭔가요?
Skills요. 특히 상태 관리 관련 스킬을 등록해서 쓰고 있는데, 프론트에서 상태 관리는 정말 무거운 부분 중 하나거든요. 여러 인터랙션, 서버와 유저 상황에 따라 교집합인 것도 있고 독립적으로 시행돼야 하는 것도 있고. 라이브러리마다 컨셉도 달라서 맨날 개발 문서 읽는 시간이 많이 걸렸어요.
해당 스킬을 등록하고 나서는 맞는 패턴을 바로 찾아주니까 시간이 압도적으로 줄었어요. 그리고 중복 코드도 확실히 줄었고요. 맥락이 비슷하지만 묘하게 다르면 똑같은 걸 반복해서 만드는 경우가 많았는데, 그게 결국 데드 코드가 돼버리잖아요. 프론트는 그런 류의 디버깅이 어려워요. 에러가 아니니까요.
Spec Mode와 시행착오
Q. Spec Mode 쓰면서 가장 어려운 게 뭔가요?
요청 할 스펙을 작업/작업자 단위로 잘 나누는 것이요. 시니어와 주니어의 차이가 결국 전체적인 그림을 보는 것 같은데, Spec Mode에서는 제가 정의하고 잘라주는 쪽이 되어야 하거든요. 그리고 AI 결과를 맹신하지 않으려고 의도적으로 의심하고, 팀과 리뷰하려고 하는데 현실적으로 쉽지 않은 부분도 있어요.
Q. 지금의 방식에 도달하기까지 어떤 시행착오가 있었어요?
여러 AI와 협업할 때 충돌 문제가 있었어요. Gemini랑 같이 코드를 짜봤는데, 서로 만든 코드를 지우는 창과 방패 현상이 벌어지더라고요. 한 AI가 만든 코드를 다른 AI가 지우고, 에러가 빵빵빵 나오고요.
그래서 어떤 LLM이 오더라도 최소한 알아들을 수 있는 가이드라인이 필요하다는 걸 깨달았어요. 그게 제 경우엔 BDD + FSD 조합이 됐는데, 지금은 이게 저만의 노하우가 됐습니다.
Requirement 문서가 중요한 세 가지 이유
Q. Requirement, Design, Task 중 어디에 가장 신경 써요?
Requirement 문서가 제일 중요하다고 생각해요.
첫째, 비개발자와의 소통 도구예요. 이해관계자에게 설명할 때 내가 최초에 이걸 기준으로 코드를 작성했다는 히스토리가 되거든요.
둘째, 개발자 간의 소통이에요. 솔직히 Git 이슈나 PR 올려도 안 읽잖아요. 요즘 AI가 리뷰하는 시대인데. Requirement 문서를 넣어주면 어디까지 했는지를 훨씬 전략적으로 파악할 수 있어요. 장기적으로는 토큰도 아낄 수 있고요.
셋째, 정적인 기준점이에요. Task 파일은 동적이잖아요. 그래서 정적인 기초 기준이 필요한데, 그게 Requirement 파일이에요. 조금 오래 걸리더라도 스펙을 만들어 놓는 건 나중의 소통을 위한 트레이드오프로 충분히 가치 있다고 생각해요.
FSD가 AI 개발에 도움이 된 방식
Q. BDD + FSD가 구체적으로 어떻게 도움이 됐어요?
BDD(Behavior-Driven Development): 비즈니스 요구사항을 자연어로 작성하고 자동화 테스트로 변환하는 프레임워크
FSD(Feature-Sliced Design): 코드를 기능단위로 구조화하는 아키텍처 방법론
바이브코딩을 하면 next create 후 자연스럽게 app/, components/, routing/ 기능 중심 구조가 생기잖아요. 근데 AI한테 컴포넌트의 정의가 어디서 어디까지인지를 명확히 말 안 하면 컴포넌트가 뚱뚱해지거나, 컴포지트가 되거나, 같은 버튼인데 모양이 좀 다르다고 또 만들어버리는 상황이 생겨요.
FSD 구조를 잡아놓으면 Requirement에서 피처 단위로 문서를 작성할 때 최소 단위부터 만들어지고, LLM이 폴더 구조를 찾아서 맥락으로 작업하게 되니까 다시 번복하는 일이 확실히 줄어요.
아직 잘 안 되는 영역 - 애니메이션과 UX
Q. 아무리 시도해도 잘 안 되는 부분이 있어요?
애니메이션이나 세밀한 UI/UX 표현이요. 인간의 언어가 모호하면 LLM도 평균치를 내는 거잖아요. "이걸 쳐서 나와서 훅 들어오고" 같은 애니메이션 효과를 LLM에게 설명하기가 진짜 어렵거든요.
그럴 때는 Spec Mode에서 커버 안 되는 부분은 러프하게 빼놓고, 이후에 세부 작업을 직접 해요. 애니메이션은 div에 번호를 매겨서 "이렇게 이렇게 해줘" 식으로 롤을 부여하는 것도 어떻게 보면 그림을 그리는 거죠. 그다음에 Vibe Mode에서 조금씩 고치거나 하고 있어요.
Figma MCP도 써봤는데, 컴포넌트와 타이포그래피는 잘 가져오더라고요. 근데 애니메이션은 LLM이 임의로 만드는 경우가 종종 있어서, 그 부분은 아직 한계가 있는 것 같아요.
사람들이 Kiro에서 흥미롭게 보는 것
Q. 커뮤니티에서 Kiro 홍보할 때 사람들 반응이 어때요?
제일 많이 반응하는 게 세 가지인 것 같아요.
첫째, 쉽게 시작할 수 있다는 거예요. 이미 완성형으로 나오니까요.
둘째, 캐릭터가 귀엽다는 것. 도구에 애정을 가질 수 있잖아요.
셋째, 문서가 남는다는 점이에요. 히스토리를 추적할 수 있다는 게 개발자들한테는 꽤 매력적인 포인트더라고요.
Kiro 팀에게 요청하고 싶은 것
Q. Kiro 팀에 한 가지 기능을 요청할 수 있다면?
한국어로 물었는데 갑자기 일본어 같은 다른 언어가 섞여 나올 때가 있어요. 물어본 적도 없는데 당황스럽더라고요. 자잘한 이슈지만 계속 고쳐가야 되는 부분인 것 같습니다.
AI 시대에서 나의 커리어
Q. AI 코딩 시대에 프론트엔드 엔지니어로서 어떻게 느끼고 있어요?
POC나 데모, UX/UI처럼 보여주는 것에 있어서는 프론트가 어필하기 좋은 직군이 됐어요. 근데 스페셜리스트 관점에서는 솔직히 위상이 좀 떨어지는 느낌이 있어요. 늘 그랬던 것 같기도 하고.
그래서 커리어 방향을 바꿨어요. AI 에이전트 시대에 이걸 운용할 수 있는 건 결국 인프라라고 판단했거든요. 단순 운영이 아니라, 언젠가 토큰을 만들어낼 수 있는 원천 기술로서의 인프라요. 지금은 SA 역할로 엔지니어링, 컨설팅, 교육, 워크숍 등 다양한 업무를 하고 있어요.
Q. 마지막으로 하고 싶은 말이 있다면?
LLM이 내 자리를 위협한다는 것에 충분히 공감하고, 실제로 그런 낌새가 보이기도 했어요. 그런데 역설적으로 뒤집어보면 빨리 많이 만들 수 있다는 거잖아요. 빨리 많이 만드는 것도 중요하지만, 그것을 고객에게 직접 전달하고 피드백 받아보는걸 해보셨으면 해요. 저에게는 정말 많은 도움이 됐습니다.