Kiro: 프로덕션 환경을 망가뜨리지 않는 AI 팀원

저는 제5회에 걸쳐 요하네스버그에서 열린 연례 Amazon Web Services (AWS) Summit 세션을 발표하는 영광을 누렸습니다.

올해 AWS Summit Johannesburg는 예전부터 익숙했던 일반적인 Sandton Convention Centre가 아닌 Midrand의 Gallagher Convention Centre로 장소를 옮겼습니다. 새로운 장소, 더 넓은 공간, 그리고 방에 있는 사람들과 공유된 같은 열정이 있었습니다.

우선 약간의 역사를 말씀드리자면, 5년이라는 시간은 정말 빠릅니다. 작년에는 두 번 발표했습니다. Community Lounge에서 Chaos Engineering을 (현재는 Developer Community Theatre로 더 잘 알려져 있습니다) 다루었고, 메인 무대에서는 고객 및 파트너를 대상으로 MCP에 대해 이야기했습니다. 그전에는 Infrastructure as Code, GenAI, FinOps 등을 다뤘습니다. 주제는 달랐지만, 모든 것에는 같은 흐름이 있었습니다. 바로 기술이 약속하는 것과 실제로 프로덕션 환경에서 마주했을 때 일어나는 일 사이의 간극입니다. 올해 저는 이 간극 한가운데에 서고 싶었습니다. 그 주제는 'AI를 사용해 어떻게 프로덕션을 망가뜨리지 않을까'였습니다. 구체적으로는 Kiro와 함께 말입니다.

Introducing Kiro

아직 사용해 보지 않으셨다면, Kiro는 AWS의 AI 네이티브 통합 개발 환경(IDE)이며, spec-driven, agent-assisted 개발을 위해 커스터마이징된 VS Code 포크입니다. 정말 훌륭합니다. 그리고 그것이 바로 정확히 문제입니다. 이러한 도구들이 코드를 작성하고 배포하는 능력이 좋아질수록, 인간 엔지니어에게 요구했던 가드레일(guardrails) 없이도 프로덕션으로 곧장 진입시키는 것이 쉬워진다는 것입니다.

AI에 대한 저의 실제 문제점

AI에 대한 저의 진짜 문제를 말씀드리겠습니다. SF 영화 같은, 세상을 장악하는 문제는 아닙니다. 훨씬 더 구체적이고 훨씬 더 개인적인 문제입니다. 제가 도움을 요청했던 코드가 완벽하게 작동하고 있었는데도 불구하고 계속해서 코드를 망가뜨린다는 것입니다.

The Real Problem with AI

이것이 한 문장으로 요약되는 전체 내용입니다. 작동하는 무언가를 가지고 있습니다. 작은 변경을 요청합니다. 그 변경과 더불어, 당신이 요청한 적 없는 다른 세 가지가 추가되고, 이제는 작동했던 것이 제대로 작동하지 않게 됩니다.

진짜 문제: 발생해서는 안 될 상황에서도 확신한다는 것

여기서 위험한 점이 나옵니다. AI는 자신이 있을 필요가 없을 때조차 너무 확신합니다.

간단한 그래프를 상상해 보세요. 옆쪽은 AI가 얼마나 자신감 있게 들리는지, 아래쪽은 실제로 얼마나 알고 있는지를 나타냅니다. 두 가지가 함께 상승하기를 바랄 겁니다. 하지만 그렇지 않습니다.

Graph showing the real problem - introducing a lesson

우리가 오늘날 가진 것은 위험한 정점입니다. 이 '바이브 코더(vibe coder)' 세대와 모든 새로운 AI 에이전트는 바로 그 꼭대기에 자리 잡고 있습니다: 최대의 자신감, 최소의 이해도. 한편 시니어 엔지니어들은 계곡 깊은 곳에 있습니다. 조용하고, 차분하며, 약간 겁먹은 상태입니다. 적게 알기 때문이 아니라, 너무 여러 번 당해본 경험 때문에 자신이 모르는 것을 존중하게 되었기 때문입니다.

이는 우리에게 첫 번째 교훈을 주는데, 다른 것은 아무것도 가져가지 않더라도 이것만은 기억하세요: 자신감(confidence)이 역량(competence)은 아닙니다. AI는 맞든 완전히 틀리든 똑같이 들립니다. 같은 어조, 같은 거만한 태도입니다. 경고하는 목소리의 떨림이 없습니다. 당신이 바로 경고 시스템입니다.

작동하던 코드를 계속 망가뜨리는 이유

그 모든 것 아래에는 하나의 근본 원인이 깔려 있습니다. 당신과 에이전트가 '경계'에 대해 합의한 적이 없다는 것입니다. 무엇을 변경해도 괜찮은지, 그리고 무엇은 정확히 그대로 유지되어야 하는지 말입니다. 아무도 그 선을 긋지 않았기 때문에, 에이전트가 예상치 못한 곳에 자신만의 선을 그어버린 것입니다.

Why it keeps breaking working code

발표의 모든 내용은 바로 그 선을 긋는 것에 달려 있습니다.

해결책은 단 하나의 문장으로 요약됩니다

코드를 작성하기 전에 계획을 세우도록 하세요.

제가 저지른 거의 모든 실수는 정반대로 행동했기 때문이었습니다. 계획 없이, 느낌만으로 진행하다가 나중에 제가 수정해야 할 diff(차이점)를 만들곤 했습니다. 먼저 계획을 세우게 하고, 에이전트가 중요한 것에 손대기 전에 그 사고 과정을 보여주도록 해야 합니다.

Kiro에게 코드를 요청하지 말고, 계획을 요청하세요.

바로 여기서 Kiro의 가치가 빛을 발합니다.

코드 대신 계획을 요청하세요. 계획은 논쟁할 수 있는 것이지만, 디프(diff)는 정리해야 하는 것입니다.
이해하고, 테스트한 다음, 변경하세요. 이 순서로요. 아직 이해하지 못한 것을 절대 수정하지 마세요.
배포할 것은 명세화하고, 느낌만으로 버릴 것들을 판단하세요. 프로덕션에 갈 모든 것에 대해서는 명세(Spec)-주도 방식이 필요합니다. '느낌'으로 코딩하는 것은 폐기할 프로토타입에는 괜찮습니다.

규칙은 한 번, 조향 장치(steering)를 통해 가르치세요. Kiro의 steering 파일에 표준을 넣어 반복적으로 프롬프트를 입력하지 않도록 하세요.

게이트는 2에서 나갈 때만 의미가 있습니다. 항상 0으로 종료되는 검사(check)로는 빌드를 실패시킬 수 없습니다. 그것은 게이트가 아니라 장식품입니다.
틀렸을 때도 똑같이 들립니다. 그래서 당신이 리뷰어 역할을 유지해야 합니다. 언제나요.

감사합니다, 그리고 내년에 만나요

이번 행사는 방에 있는 사람들에 의해 그 가치가 결정되며, 올해 참석자들은 정말 대단했습니다. 세션 후 질문들은 날카로웠고, 몇몇 분들은 당신의 게이트가 실제로 2에서 나가는지 논쟁하기 위해 남아 있었습니다. 그것이 제가 정확히 원했던 대화입니다.

Don't ask Kiro for Code

James Hickman에게 놀라운 기조연설과 전날 파트너 서밋(Partner Summit)을 열어준 것에 감사드립니다. 당신과의 만남, 그리고 진정한 고객 집착(customer obsession), 에너지, 열정, 브랜드에 대한 사랑을 경험하는 것은 정말 하이라이트였습니다. 멋진 인간이 되어주시고 항상 미소와 함께 해 주셔서 감사합니다.

AWSome 커뮤니티

AWSome community members

AWS 팀, Natalia Stones, Echo Pan, Francesca Sassi, Veliswa Boya, Olivier Leplus에게 진심으로 감사드립니다. 이번 행사를 함께 준비하며 정말 멋진 경험을 했습니다. 특히 고객사분들, 빌더분들, 그리고 강연에 참석해주신 모든 분들께 특별히 감사의 말씀을 전합니다.

수년 동안 만나온 소중한 인연들에게 항상 감사함을 느낍니다: Phyllis Madaba, Thoko Mathenjwa, Rejoice Mucheri, Henri Zietsman.

Henri Zietsman

AWS 커뮤니티 남아프리카 팀과 회원 여러분: 여러분 덕분에 제가 계속해서 이 자리에 설 수 있습니다.

AWS Summit Johannesburg 2026을 마무리합니다. 내년에도 같은 무대, 같은 기대감, 같은 질문이 있을 것입니다.

Summit 2027에서 만나요. 프롬프트(prompt)뿐만 아니라 여러분의 계획들을 가지고 오세요.