AWS AI-DLC가 가리키는 다음 흐름: 개발자에서 전 직군으로
"AI-DLC를 활용하여 7시간 안에 서비스 완성하기"
AWS Summit Seoul 2026, AI-DLC 빌딩 세션 안내문
코엑스, 2026년 5월 20일. AWS 서밋 서울의 이 빌딩 세션은 오전 11시 10분에 시작해 오후 6시에 끝났습니다. 참가자들은 자신의 아이디어 하나를 들고 입장해, 같은 날 작동하는 서비스를 가지고 자리에서 나왔습니다.
이 세션이 증명한 것은 단순히 "AI가 빠르다"는 사실이 아니었습니다. 요구사항 정의부터 아키텍처, 코드, 테스트에 이르는 전 과정에서 AI가 속도를 내고, 사람은 각 단계의 결정과 검증을 맡는 방식이었습니다. AWS가 "AI-DLC(AI-Driven Development Life Cycle)" 라 부르는 새로운 개발 표준이, 한국 청중 앞에 정식으로 소개된 자리였습니다. LG전자 MS 사업본부는 이미 이 방식으로 생산성을 2배 끌어올렸다고 발표한 바 있습니다.
7시간이라는 숫자는 "AI의 사용성이 좋아졌다”는 메시지가 아닙니다. AI 시대에 빨리 움직이는 사람들의 비밀은 의외로 단순하다는 메시지입니다. 그들의 일이 이미 AI가 읽을 수 있는 형태로 옮겨져 있었기 때문입니다.
이 글에서는 AWS가 한국에 막 발표한 AI-DLC가 진짜로 가리키는 다음 흐름을 살펴봅니다. 왜 어떤 사람의 일은 AI 시대에 7시간 만에 끝나고, 어떤 사람의 일은 그렇지 못하는 걸까요?
AI-DLC는 무엇인가
이름이 다소 생소하지만, AI-DLC가 다루는 일 자체는 단순합니다. AI 코딩 에이전트(Claude Code, Kiro 등)가 소프트웨어를 만들 때 따라야 할 표준 작업 절차서입니다. 코드가 아니라, 코드를 짜는 방법을 다룬 마크다운 묶음입니다.
AI-DLC는 작업을 세 단계로 나눕니다.
Inception(착수): 무엇을, 왜 만들 것인가. 요구사항을 정리하고, 유저 스토리를 쓰고, 위험과 복잡도를 평가합니다.
Construction(구축): 어떻게 만들 것인가. 컴포넌트 설계, 코드 생성, 빌드.
Operations(운영): 배포와 모니터링.
각 단계 사이에는 사람이 통과시켜야 다음 단계로 넘어가는 검증 게이트가 있습니다. AI가 폭주하지 않도록 막는 장치입니다. 챗 창에 자유롭게 묻고 답하는 것이 아니라, 구조화된 객관식 질문이 파일로 던져지고, 사람이 답을 골라야 다음으로 갑니다.
AWS 서밋 빌딩 세션에서 7시간 안에 작동하는 서비스를 만들 수 있었던 것은, 이 게이트들이 매 단계마다 결정에 필요한 가장 작은 한 가지만 사람에게 묻고, 나머지는 AI가 처리하도록 설계되어 있었기 때문입니다.
참조: https://github.com/awslabs/aidlc-workflows
"도구"가 아니라 "매뉴얼"이다
여기서 한 가지를 짚고 가겠습니다. AWS가 공개한 awslabs/aidlc-workflows 레포에는 실행 가능한 코드가 한 줄도 들어있지 않습니다. 마크다운 파일들의 묶음일 뿐입니다.
그 마크다운들은 AI 코딩 에이전트들에게 "이 회사는 이런 순서로 일한다"고 알려주는 일을 합니다. Cursor의 Rules 파일, Claude Code의 CLAUDE.md, Amazon Q의 Project Rules, Kiro의 Steering Files, GitHub Copilot의 Instructions, OpenAI Codex의 AGENTS.md까지 6개 코딩 환경에 같은 규칙을 같은 방식으로 주입할 수 있게 형식이 표준화되어 있습니다.
이 사실의 함의는 생각보다 큽니다. AI-DLC는 AI를 위한 새 도구가 아닙니다. AI가 회사처럼 일하게 만드는 사내 매뉴얼 1호에 가깝습니다. 사람이 신입사원에게 일하는 방식을 가르치는 매뉴얼을 주듯, AI 에이전트에게 동일한 매뉴얼을 마크다운으로 전달합니다.
이 흐름은 AI-DLC 단독의 현상이 아닙니다. 지난 두 달 동안 X에서는 "CLAUDE.md를 어떻게 쓸 것인가"를 다룬 글들이 5,000회 이상의 좋아요를 모으며 수렴해 왔습니다. AI에게 회사의 일하는 방식을 어떻게 주입할 것인가가 새로운 표준으로 부상하고 있다는 신호입니다. AWS가 이 시점에 자신의 표준을 공개한 것은, 그 흐름의 정점에 있다는 뜻입니다.
AWS가 코드부터 손댄 이유
그렇다면 한 가지 질문이 남습니다. AI가 일을 거들 수 있는 도메인은 코드 외에도 많은데, 왜 AWS는 코드부터 표준화에 나섰을까요.
답은 의외로 단순합니다. 개발자의 일은 이미 텍스트였기 때문입니다.
소프트웨어 개발은 코드 자체가 텍스트입니다. 함수, 변수, 주석, 커밋 메시지, 풀 리퀘스트 설명, 이슈 티켓, 코드 리뷰, 기술 문서까지 일의 거의 모든 산출물이 LLM이 그대로 읽을 수 있는 텍스트로 남습니다. AI는 텍스트를 먹고 자라기 때문에, 텍스트로 된 일이 가장 먼저 변환의 사정권에 들어옵니다.
이 단순한 전제는 숫자로도 확인됩니다. Anthropic은 사내 직원의 70~90%가 매일 Claude Code를 쓴다고 공개했습니다. 일부 팀에서는 풀 리퀘스트의 70%가 AI가 만든 코드입니다. 같은 회사, 같은 모델인데도 마케팅·세일즈·운영팀에서는 이런 숫자가 나오지 않습니다.
개발자가 AI 시대의 첫 수혜자가 된 이유는 모델이 그들 편이어서가 아닙니다.
그들의 일이 이미 LLM이 읽을 수 있는 형태로 옮겨져 있었기 때문입니다.
AI-DLC가 한 단계 더 나아간 지점
여기서 AI-DLC가 한 단계 더 나아갔다는 사실이 중요해집니다.
코드 자체가 텍스트인 것은 출발선입니다. 그 위에 있는 코드 작업의 결정과 흐름, 즉 "이 회사는 어떤 순서로 요구사항을 정의하고, 어떤 기준으로 아키텍처를 선택하고, 어느 단계에서 사람이 검증해야 하는가"는 보통 머릿속에 있거나, 노션 문서에 흩어져 있거나, 시니어와 주니어의 1:1 대화에 떠 있습니다. 코드 자체는 텍스트지만, 코드를 짜는 방법은 텍스트가 아닌 경우가 많았습니다.
AI-DLC가 표준화한 것이 정확히 그 부분입니다. 코드뿐 아니라, 코드를 짜는 결정 흐름까지 마크다운으로 옮겨 AI가 읽을 수 있게 만든 일입니다. AWS가 한국 청중 앞에서 보여준 7시간 빌딩 세션은, 코드 도메인의 두 번째 텍스트화가 가능하다는 것을 증명한 자리였습니다.
이 관점에서 보면 AI-DLC는 도구 한 개의 출시가 아니라, 한 도메인 안에서 일하는 방식 전체를 LLM이 읽을 수 있게 옮긴 완성형 사례입니다. 그리고 AWS가 이 시점에 그 사례를 공개했다는 것은, 같은 변환이 곧 다른 도메인에서도 시도될 것이라는 신호입니다.
그러면 코드 밖의 도메인은
이쯤에서 자연스럽게 따라오는 질문이 있습니다. 코드가 아닌 일들은 어디에 있는가.
이전 글 왜 우리의 AX 전환은 10%에서 멈추는가에서 다뤘던 진단이 정확히 이 자리를 가리킵니다. 비즈니스 맥락의 90%는 디지털화되어 있지 않은 대화에서 발생하고 즉시 소실됩니다. 회의에서 결정된 합의, "왜 그렇게 정했는지"의 이유, 시니어가 신입에게 한 마디 던졌던 가이드, 고객이 PoC 마지막 미팅에서 흘린 결정적 단서. 이런 것들은 Notion에도, Linear에도, CRM에도 남지 않습니다.
코드 도메인이 AI-DLC라는 매뉴얼을 통해 결정 흐름까지 텍스트화하고 있을 때, 코드 밖의 도메인은 그 첫 단계인 대화의 텍스트화조차 아직 표준화되어 있지 않습니다. 회의록 도구는 있지만, 그것은 사람이 다시 읽을 요약본을 만드는 일이지 AI 에이전트가 검색하고 추론에 쓸 수 있는 LLM-Ready 데이터를 만드는 일은 아닙니다.
코드 도메인에서 AWS가 AI-DLC로 메운 자리. 그 자리는 코드 밖에서 아직 비어 있습니다.
티로가 채우는 자리
티로(Tiro)는 그 빈자리의 첫 단계, 즉 대화의 LLM-Ready 변환을 다룹니다.
회의에서 발생하는 음성을 단순히 텍스트로 받아 적는 일이 아닙니다. 화자를 분리하고, 주제별로 묶고, 의사결정과 액션 아이템을 추출하고, 참여자·회의 ID·날짜 같은 메타데이터를 붙이고, 마지막으로 검색 가능한 벡터로 저장하는 일까지 일관된 파이프라인으로 가져갑니다. 이 파이프라인의 끝에서야 AI 에이전트가 활용할 수 있는 데이터가 됩니다. 저희는 이 단계를, 조직 내 언어를 통일하는 Ontology(AI-DLC 또한 여기에 해당됩니다)를 만들기 이전 단계, Pre-Ontology로 정의했습니다.
AI-DLC가 코드 도메인에서 일하는 방식 전체를 마크다운으로 옮긴 시도라면, 티로는 회의 도메인에서 같은 변환을 시도하는 인프라입니다. 한쪽은 코딩 에이전트가 회사처럼 일하게 만들고, 다른 쪽은 회의가 끝난 뒤에도 그 결정과 맥락이 AI 에이전트의 추론에 그대로 흘러 들어가게 만듭니다.
같은 흐름이 도메인을 옮겨 가며 반복되고 있다는 것이, AWS 서밋 2026이 한국 청중에게 정식으로 보여준 메시지입니다.
정리
AI-DLC를 7시간짜리 빌딩 세션의 신기한 시연으로만 보면, 한 번 들렀다 잊는 컨퍼런스 토픽 한 줄로 남습니다.
같은 사건을 왜 코드부터였는가, 그리고 다음은 어디인가라는 질문으로 보면, 그것은 AI 시대 전반의 흐름을 가리키는 좌표가 됩니다.
AI 시대의 경쟁력은, 자기 일을 LLM이 읽을 수 있는 형태로 옮긴 사람과 조직에게 주어집니다. 개발자가 첫 수혜자가 된 것은 그들의 일이 이미 텍스트였기 때문이고, AI-DLC가 이 시점에 표준이 된 것은 그 변환이 코드 도메인의 결정 흐름까지 도달했다는 신호입니다. 다음 변환은 코드 밖에서, 우리가 매일 입으로 주고받는 대화 위에서 시작됩니다.
다음 회의가 끝났을 때, 그 회의가 말로만 떠 있다가 사라지는 90%에 포함될지, 아니면 AI가 읽고 추론에 쓸 수 있는 자산으로 남을지 한 번 떠올려 보시면 좋겠습니다.
출처: AWS DevOps Blog, "Open-Sourcing Adaptive Workflows for AI-DLC" · GitHub awslabs/aidlc-workflows · AWS Summit Seoul 2026 강연 목록
티로 시작하기
