Kiro 사용자 인터뷰 #4 - 우아한형제들 김민태님
배달의민족 백엔드 엔지니어가 AI-DLC로 레거시 시스템을 재편하고, 에이전트 스킬로 AI 협업을 완성해가는 이야기
들어가며
네 번째 인터뷰이로 우아한형제들(배달의민족)의 김민태님을 만났습니다. 현재 커머스 관련 고객 경험 개선 업무를 담당하는 백엔드 서버 엔지니어로, AWS한국사용자모임 - 아키텍처 모임의 오거나이저로도 활동 중입니다. AWS Summit Seoul 2026 키노트에서 AI-DLC(AI-Driven Development Life Cycle)를 소개하며 주목을 받았고, 사내에서 Kiro 관련 지식과 활용 노하우를 전파하며 팀 내 AI 도입을 이끌어온 분입니다. 도구에 끌려가지 않고 Computer Science 근본 위에서 AI를 협업 파트너로 활용하는 관점이 흥미로웠습니다.
자기소개
Q. 자기소개와 현재 역할을 부탁드립니다.
우아한형제들에서 백엔드 서버 개발을 하고 있고요. 지금은 커머스에 관련된 고객 경험을 개선하는 작업들을 많이 하고 있습니다. 예를 들면 주문취소율 개선, 배달 품질 관련 작업들을 주로 맡고 있는 서버 엔지니어입니다.
AWS 아키텍처 모임 오거나이저도 하고 있어요. AWS의 모든 아키텍처를 같이 이야기하고 리뷰하는 모임인데, 초보자분들도 오셔서 이야기해 주시면 좋습니다. 아키텍처라고 하면 초보자분들이 접근하기 어려워하시는 부분도 있어서 모임 운영에 고민이 많습니다.
Kiro 선택 이유
Q. Kiro를 조직에 도입하게 된 배경이 뭔가요?
작년 기준으로, 구입을 검토했던 AI 툴이 세 가지가 있었어요. Kiro, Cursor, 그리고 JetBrains Junie입니다. 저희 회사는 Java를 많이 사용하는 회사다 보니, Cursor는 VS Code 기반이라 Java 엔지니어링에 적합한 환경이 아니었어요. Junie는 IntelliJ 기반이라 기대했지만 당시에는 초기 버전이라 기능적인 부분에서 완성도 있게 작업하기가 굉장히 어려웠고요.
Kiro는 CLI로도 작동시킬 수 있고, Anthropic 포함 다양한 모델 프로바이더를 가지고 있다는 장점이 있었어요. 저희가 AWS를 굉장히 많이 쓰는 회사다 보니 자연스럽게 Kiro를 접하게 됐고, 사내에 전파하는 챔피언 역할을 맡으면서 장단점을 모두 직접 체감하게 됐습니다.
현재 전사 표준으로는 두 가지를 쓰고 있어요. 개인마다 다르게 사용하는 편입니다. 대체적으로 코드 작업에는 Kiro와 Claude를 병행하면서 사용하고, 문서 작업이나 개발자 간 소통에는 Claude를 쓰고 있습니다. Claude Code 스킬을 통해 설명을 전달하는 방식으로 쓰는데, 비개발직군 분들도 Claude Code를 쓰시는 분들이 많다 보니 그쪽이 더 편하거든요.
AI-DLC: AI-Driven Development Life Cycle
Q. AWS Summit Seoul 2026 키노트에서 AI-DLC를 소개하셨는데, 어떻게 업무에 정립하게 됐나요?
기능 조직에서 백엔드 엔지니어 10~12명과 함께 일할 때, 어떻게 하면 AI를 효과적으로 사용해서 팀 전체의 생산성을 높일 수 있을까를 굉장히 많이 고민했어요.
저는 LLM 위키라는 개념이 나오기 전부터 이런 노하우들을 문서로 저장하고 팀에 공유하기 시작했어요. 요구사항이나 설계 단계를 먼저 분류하고, 우리가 지금 힘들어하는 것들이 무엇인지 확인하고, 그걸 AI에게 질문하고 해석해서 다시 전파하는 사이클을 반복했습니다. 그러다 보니 자연스럽게 Kiro의 스펙 작성 방식과 맞물리면서 지금의 AI-DLC 형태로 발전됐어요.
Kiro의 Requirement, Design, Task 구조를 그대로 쓰면서, 인셉션 단계와 컨스트럭션 단계를 좀 더 명확히 구분해서 활용하고 있어요.
Q. 요구사항 분석 단계에서 Kiro와 어떻게 협업하시나요?
저희는 ADR(Architecture Decision Record)을 적극적으로 사용했어요. 지금까지 갖고 있던 히스토리와 앞으로 나아가야 할 방향성이 항상 기록돼 있거든요. 이걸 팀에 던져주고 같이 해석하면서 다음 스텝을 협의하는 방식으로 많이 진행했고, MCP로 Confluence를 연결해서 누구나 접근할 수 있게 관리하고 있습니다.
레거시 배치 시스템 전환
Q. 레거시 배치 시스템을 전환하는 작업에서 Kiro를 어떻게 활용하셨나요?
5년 전 소스 코드를 그대로 마이그레이션하는 작업이었는데, 봐야 되는 파일이 수백 개였어요. 그때는 서브에이전트 개념이 나오기 전이라 세션을 여러 개 켜놓고 소스를 하나하나 분석시켰습니다.
방식은 이랬어요. 리스트를 먼저 만들어놓고, 관련 도메인을 추론시켜서 제거 대상 도메인과 마이그레이션 대상 도메인으로 분류했습니다. 사용하지 않는 테이블도 분류하고, 테이블을 내연에서 외연으로 확장하는 방식으로 시스템 전체를 분석했어요. 파일 드롭시킨 게 수십 개가 됐고, 필요한 것들도 이중으로 검증해서 확인했습니다.
결과적으로 두 달 걸릴 작업을 혼자서 한 달 이내에 완료했어요. 이걸 경험하면서 "개발자가 대체될 수 있겠구나" 싶었다가도, Hallucination이나 딥한 아키텍처 설계에서는 아직 사람의 손길이 더 많이 필요하다는 걸 다시 느꼈습니다. 시스템 도메인 전체를 컨텍스트에 넣기가 힘들거든요.
코딩 전에 스펙 먼저
Q. 컨스트럭션 단계에서 기존 개발 방식과 가장 크게 달라진 점이 뭔가요?
사실 저희 회사는 원래부터 코드 스파이크나 설계를 먼저 작성하고, 팀 리뷰를 통해 진행하는 문화가 있었어요. 그래서 크게 달라진 느낌은 없었는데요.
달라진 건 옆에 항상 협업 파트너가 생긴 느낌이에요. 우리가 주의해야 할 점들을 함께 학습시켜서, 놓치는 부분을 같이 잡아주는 페어 프로그래밍 파트너처럼 활용하게 됐습니다. 조직 전체 전파를 위한 활동까지는 못했지만, 적어도 함께 작업하는 분들과는 문서와 노하우를 공유하면서 진행했어요.
에이전트 스킬: 반복을 자산으로
Q. 에이전트 스킬은 어떤 방식으로 만들어나가시나요?
개발 과정에서 발견된 문제들을 스킬로 계속 평가하고 깎아나가는 방식입니다. 스킬 크리에이터 스킬을 활용해서, 문제가 됐던 사례들을 넣어주고 계속 평가하면서 개선해요. 멀티턴으로 이런 과정을 반복하다 보면 언젠가 컨텍스트가 복잡해지고 오염되는 날이 오긴 하겠지만, 아직까지는 이 사이클을 통해서 개선해 나가고 있어요.
팀 리소스로 관리하고, 사내에는 전체 스킬을 관리하는 스킬 허브도 있어서 거기 등록해서 공유합니다.
Q. 본인만의 에이전트와 스킬 활용 사례를 소개해 주신다면?
요즘은 TPM 에이전트 하나를 만들어서 쓰고 있어요. 팀장님이 휴가 갔을 때 팀장 자리를 채우기 위해 만들었는데, 제 작업을 리뷰해주는 역할을 합니다. 굉장히 유용해서 팀 내에 스킬로 공유하기로 했어요.
또 시니어 엔지니어 에이전트도 만들어서 쓰고 있어요. "너는 시니어 엔지니어야, 클린 코드 원칙 N개를 지켜야 해"처럼 정의하고, 에이전트 내 인덱스 파일을 만들어서 유연하게 읽을 수 있게 구현해놨습니다. 세션이 시작됐을 때 컨텍스트 분기가 많아지지 않도록 줄이는 게 목적이에요.
개발자가 요즘은 코드를 넘어 아키텍처도 봐야 되고 커뮤니케이션도 중요한 시대가 됐다고 생각하거든요. 의사결정도 더 빠르게, 데이터 기반으로 이뤄지다 보니 봐야 되는 채널도, 문서도, 참여하는 회의도 더 많아졌어요. 그 시간을 줄이고 아키텍처에 집중할 수 있는 시간을 만드는 게 지금 제 에이전트 설계의 방향입니다.
도구를 고르는 시각: 특정 프로바이더에 종속되지 않기
Q. AI 툴을 선택할 때 가장 중요하게 보는 기준이 무엇인가요?
모든 걸 해결하는 만능툴은 없다고 생각해요. Claude Code는 모델 프로바이더로서 굉장히 좋은 영향력을 끼치고 있지만, 더 좋은 AI 모델이나 툴이 나오면 언제든 바뀔 수 있거든요.
최근에도 GPT-5.5가 좋은 반응을 보였다가 Opus 4.8이 나오고 나서 다시 흐름이 바뀌고, 또 다른 신규 모델이 나오는 일들이 계속 있잖아요. 특정 프로바이더에 종속되면 시스템 마이그레이션도 굉장히 어려워지고요. 그래서 저는 서드파티 도구에 의존을 최소화하고 원하는 결과를 만들어가는 방향을 선호합니다.
Kiro 팀에게 바라는 점
Q. Kiro에 가장 하고 싶은 말이 있다면?
CLI UX가 불편하다는 게 가장 큰 불만이에요. 사용자 친화적이지 않다고 생각하거든요. 예를 들면 과거에는 ESC로 작업 취소가 안 됐어요. Ctrl+C를 누르면 세션이 그냥 닫혀버려서 당황한 적도 있고요. 사소한 것일 수도 있는데 지금보다 더 사용성이 직관적이고 개선됐으면 합니다.
그리고 업데이트 주기보다는 한 발 앞서가는 방향성이 중요한 것 같아요. 모델 성능에 따라 트렌드가 빠르게 바뀌잖아요. 컨텍스트, 하네스, 루프 엔지니어링 이런 흐름에 빠르게 대응하는 모습이 필요합니다.
보여지는 AWS 제품 로드맵에서는 Kiro 보다는 Bedrock 기반 DevOps Agent, Security Agent 같은 쪽에 특화된 Agent 출시에 더 포커스가 맞춰진 느낌이었는데, Kiro 사용자 입장에서는 좀 찬밥 같은 느낌이 드는 게 솔직한 심정입니다.
우아한형제들 안에서의 R&R 변화
Q. AI 시대에 조직 내 R&R 경계가 흐려지는 현상은 어떻게 보세요?
의지가 있다면 다른 영역의 코드도 다룰 수 있는 시대가 됐어요. 저 같은 경우, 백엔드 엔지니어지만 데이터 엔지니어링 쪽을 많이 들여다보게 됐어요.
백엔드 엔지니어가 데이터를 기반으로 기능을 구현하는 경우가 많아졌다 보니, "이 데이터가 왜 이렇게 발생했지? 어떤 데이터를 기반으로 코드를 짜면 문제를 더 잘 해결할 수 있을까?" 같은 접근이 자연스럽게 생겼어요. 앞단의 기획과 전체적인 흐름을 이해하고자 하는 노력입니다.
코드 베이스보다는 인프라와 아키텍처 설계 영역에서 백엔드 엔지니어의 역할이 더 유리한 것 같아요. 그 영역에서 우리 도메인만의 특성을 살릴 수 있는 에이전트를 만들어서 백엔드 생활을 풍요롭게 하는 방향으로 확장하고 있습니다. 이런 유연성을 갖지 못하는 엔지니어는 점점 어려워질 것 같아요.
AI 시대 개발자의 역량
Q. AI 시대 개발자에게 가장 중요한 역량은 뭐라고 생각하세요?
문제를 끝까지 파고드는 역량이요.
AI가 코드를 생성하더라도, 결국 시스템 위에서 동작하는 근본 원리를 모른다면 가장 쉽게 대체될 수 있는 엔지니어가 된다고 생각해요. AI와 협업하는 것이지 AI에 의존하는 사람이 되면 안 된다는 거죠. 윗세대 엔지니어들이 항상 "CS가 제일 중요하다"고 했던 말이, 지금 AI 시대에도 그대로 살아있더라고요. 프레임워크는 변하고, 코드는 변하지만, 토픽과 도메인은 변하지 않습니다.
인간 개발자만의 역할은 회사와 프로덕트의 고유한 특성을 빠르게 파악하고 데이터를 해석해서 프로그램에 녹이는 것이라고 생각해요. 유저 행동 패턴은 AI가 온전히 대신할 수 없거든요. 세상을 바라보는 눈과 그것을 읽어내는 지혜, 그리고 빠르게 분석하고 결정하는 선택 역량이 더 중요해질 것 같습니다.
마치며
민태님과 대화하면서 인상 깊었던 것은, "AI를 적극 사용하되 끌려가지 않는다"는 태도였습니다. 트렌드에 흔들리지 않고 잃지 않아야 할 것을 지키면서도, 반복을 자산으로 바꾸고 에이전트를 실무에 녹여내는 것이 민태님이 AI 시대에 개발자로 일하는 방식이었습니다.