LY Corporation에서는 지금까지 AI 활용 역량 향상 워크숍인 Orchestration Development Workshop (ODW)를 통해, 개인이 AI를 활용해 개발과 검토를 진행할 수 있는 기반을 넓혀 왔습니다. 실제로 이미 일선 곳곳에서는 코드 자동 완성과 테스트, 문서 작성 등의 영역에서 AI 코딩 에이전트를 널리 사용하고 있습니다.
이제 다음 과제는 이러한 활용 사례가 개인의 노하우에서 멈추지 않도록 조직 차원에서 재현 가능한 형태로 끌어올리는 것입니다. 조직 차원에서 AIDD(AI-driven development)를 추진하려면 단순히 도구를 배포하는 것만으로는 충분하지 않습니다. AI가 다룰 수 있도록 사양, 설계, 용어, 판단 기준, 기존 코드와의 관계 같은 컨텍스트를 정리하며 ‘AI Ready 환경’을 조직 차원에서 갖춰야 합니다.
이와 같은 환경 정비 작업은 현장의 엔지니어만으로 끝낼 수 있는 작업이 아닙니다. 어떤 업무를 대상으로 할지, 어디까지 정비할지, 누가 판단하고 어디서 합의할지 같은 논점에는 조직장과 기획자를 포함한 의사결정이 필요합니다.
이에 따라 저희는 2026년 6월 30일부터 7월 1일까지 LY Corporation에서 AIDD 워크숍을 열었습니다. LINE Plus를 포함한 총 21개 팀, 112명이 참여했고, 각 팀은 실제 업무 주제를 가져와 AIDD를 조직적으로 추진하기 위한 전제 조건을 검증했습니다.
이 글에서는 AIDD 자체를 일반론적으로 설명하기보다는 왜 지금 LY Corporation에서 팀 단위 워크숍이라는 형식을 택했는지 소개하고, 워크숍 과정에서 도출된 AIDD 조직 도입의 조건을 공유하고자 합니다.
AIDD를 어떻게 정의하는가
저희는 AI를 요구 사항 정리부터 설계, 구현, 리뷰까지 개발 프로세스 전반의 협력자로 활용하는 접근 방식을 AIDD라고 부릅니다.
AIDD는 AI에 일을 통째로 맡기는 개발 방식이 아닙니다. 기존 개발 프로세스 안에서 단순히 보조 도구로만 활용하는 것도 아닙니다. ‘AI가 초안을 만들고, 사람이 의도와 제약 조건을 부여하며 중요한 판단을 내리고, 그 결과를 다음 단계로 연결한다.’ 이 흐름을 각각 단절된 작업이 아니라 하나의 통합된 개발 프로세스로 설계하는 데 의미가 있습니다.
이번 워크숍에서 중심에 둔 것은 AIDD의 개념 자체를 설명하는 것보다는 이를 ‘조직 차원의 실무에 적용하려면 무엇이 필요한가’라는 것이었습니다.
AIDD는 AI와 사람의 역할 분담을 설계하면서 개발 프로세스 전체를 주도해 나가는 사고방식입니다.
AI를 보조적으로 사용하는 것이 아니라, 개발 프로세스 전체에 내재화해 진행하는 것이 AIDD의 핵심입니다.
왜 지금 LY Corporation에서 AIDD 워크숍을 열었는가
최근 1년 남짓 사이, AI 코딩 에이전트를 쓰는 것 자체는 많이 일반화되었습니다. 개인 차원에서는 이미 많은 엔지니어가 코드 자동 완성이나 리서치, 테스트, 문서 작성 등에서 AI의 도움을 받고 있습니다.
하지만 조직 차원에서 보면 다음과 같은 상태에서 성장이 정체되기 쉬운 것도 사실입니다.
- 사용하는 사람은 있지만 팀의 개발 프로세스로는 연결되지 않음
- AI의 출력을 어떻게 리뷰해야 하는지 여전히 모호함
- 기존 제품에 어떻게 적용해야 할지 감이 오지 않음
- 시도는 해봤지만 기대만큼 활용되지 않아 결국 개인의 노하우 수준에서 끝남
- ‘편리해 보인다’ 이상으로 나아가지 못해 조직 차원의 투자 판단으로 이어지지 않음
즉 AI 활용은 시작되었지만 개인 활용에서 조직적 실천으로 넘어가는 단계에서 막히기 쉽다는 뜻입니다.
ODW가 개인의 AI 활용을 넓히는 자리였다면, 이번 워크숍은 이를 조직 차원에서 작동하기 위해 ‘AI Ready’ 전제 조건을 확인하는 자리였습니다.
이번 워크숍은 바로 이 장벽을 넘기 위해 기획했습니다. 단순히 AI 도구 데모를 보여주는 것이 아니라, 각 팀별로 실제 프로젝트 주제를 가져와 현장의 맥락을 바탕으로 ‘우리 개발 프로세스에 어떻게 내재화할 것인가’를 고민하는 장으로 만들고자 했습니다.
왜 팀 단위 참여로 설계했는가
AIDD를 조직에 도입할 때 개인의 이해만으로는 앞으로 나아가기 어려운 순간이 많습니다. AI 활용의 가치는 단발성 프롬프트 작성이 아니라, 어떤 정보를 전달할지, 어디서 사람이 리뷰할지, 누구의 산출물을 최종 산출물로 볼지, 기존 프로세스에 어떻게 피드 백할지와 같은 실무 흐름 속에서 비로소 명확해지기 때문입니다.
또한 이런 설계에는 엔지니어뿐 아니라 기획, 요구 사항 정리, 디자인, 리더십 등 다양한 직군의 관점이 필요합니다. 나아가 어디서부터 시작할지, 어디에 시간을 투자할지, 어디까지 표준화할지 판단하려면 의사결정권자의 참여가 필수입니다.
따라서 이번에는 개인이 아닌 의사결정자를 포함한 팀 단위 참여를 전제로 했습니다. 실제 업무를 앞에 두고 직군을 넘나들며 대화할 수 있는 장을 만들어 단순히 ‘AI를 쓸 수 있는가’를 넘어 ‘조직 차원에서 무엇을 정비해야 하는가’까지 조망할 수 있도록 유도했습니다.
이틀간의 프로그램을 어떻게 설계했는가
이번 워크숍은 단순히 AI 도구를 다뤄보는 실습에 그치지 않고 이해하고, 실무 주제를 가져와, 검증하고, 공유하는 과정을 이틀 동안 순환하는 구성으로 설계했습니다.
첫 번째 날에는 문제 정의와 컨텍스트 정리에 집중하고 두 번째 날에는 자율적으로 검증하며 실제 업무에 적용할 수 있는 형태를 만드는 데 중점을 두었습니다.
이번 워크숍 역시 팀이 실제로 손을 움직이며 진행하는 실천의 장으로 설계했으며, Orchestration 길드 멤버들이 큰 역할을 맡았습니다. 길드는 각 사업 도 메인의 엔지니어가 전사적으로 참여해 현장의 실천 지식을 바탕으로 콘텐츠를 다듬고 참가 팀의 멘토링과 학습 공유를 지원하는 역할을 합니다. Developer Relations와 길드, 기술 품질을 담당하는 Technical Directors가 함께 움직이면서 재현 가능한 학습의 장을 만들었습니다. 이와 관련된 자세한 내용은 AI 활용 능력을 높이기 위한 사내 워크숍, 'Orchestration Development Workshop' 기사 목록을 참고해 주세요.
워크숍에서 참가 팀이 깊이 절감한 네 가지
이번 워크숍을 통해 몇 가지 명확해진 사실이 있습니다. 그중 특히 중요했던 네 가지를 살펴보겠습니다.
가장 큰 가치는 구현 자체보다 그 이전 단계에 있다
AI 코딩 에이전트 이야기를 하면 아무래도 ‘코드를 얼마나 빨리 작성할 수 있는가’에 시선이 쏠리기 쉽습니다.
물론 그 자체에도 가치가 있지만, 이번 워크숍에서 참여 팀이 더 깊이 체감한 것은 오히려 그 앞단의 과정이었습니다. 예를 들어 모호한 요구 사항을 각 논점으로 분해하고, 요구 사항을 언어로 명확히 정의하고, 팀 내부 인식을 맞추고, 무엇을 먼저 결정해야 하는지 정리하고, 다음 작업 단위로 구체화하는 작업입니다. 이는 새로운 이론을 발견했다기보다는 실제 주제를 가져와 시도했기 때문에 이를 자신의 구체적인 과제로 체감했다고 보는 편이 맞겠습니다.
AIDD의 가치는 AI가 전진을 돕고 사람이 중요한 판단과 책임을 맡는 구조를 만드는 데 있습니다. 그렇기에 구현 단계뿐 아니라 그 전 단계의 정리 작업이 성과를 좌우한다는 사실이 현장의 감각으로 공감대를 얻었습니다.
병목은 도구가 아니라 컨텍스트다
또 하나 많은 팀이 공통으로 직면한 것은 AI 스킬만 추가한다고 개발 속도가 빨라지지는 않는다는 점이었습니다.
AI의 출력 품질은 제공한 컨텍스트의 질에 크게 의존합니다. 사양, 용어, 제약 조건, 설계 의도, 기존 코드와의 관계, 운영 규칙 등이 정리되어 있지 않은 상태에서는 AI가 그럴듯한 답을 내놓더라도 실무에 바로 쓸 수 있는 수준이 되지는 못합니다.
이 점 역시 머리로는 알고 있던 사실입니다. 하지만 실제로 자기 팀의 프로젝트 주제로 직접 시도해 보면서 컨텍스트 부족이 불안정한 출력과 리뷰 부담으로 그대로 돌아오는 것을 절감할 수 있었습니다. 많은 팀에게 단순히 ‘알고 있던 사실’이 아니라 ‘실무의 고통’으로 체감된 순간이었습니다.
그렇기 때문에 사양과 용어, 제약 조건을 정리하는 일 자체를 부수적인 준비가 아니라 조직적인 AI 활용의 기반을 다지는 핵심 작업으로 다뤄야 합니다.
팀 단위로 참가하면서 보인 논점이 있다
이번 워크숍은 개인 참가가 아니라 팀 참가를 전제로 했습니다. 이 점 역시 매우 중요한 설계 요소였습니다.
AI 활용은 개인의 작업 효율화에서 시작할 수 있지만, 현장에서 실제로 의미 있는 결실을 맺으 려면 한 사람의 시각만으로는 부족합니다. 비즈니스, 기획, 디자인, 엔지니어, 리더 등 다양한 역할의 관점과 암묵지가 드러나야 어디에 AI를 쓸지, 누가 리뷰할지, 어떤 산출물을 기준으로 삼을지, 기존 흐름에 어떻게 반영할지를 구체화할 수 있습니다.
개인적으로 시도할 때는 드러나지 않던 합의 형성과 책임 경계 설정에 대한 논점이 팀이 같은 주제를 함께 다루면서 비로소 선명하게 드러났습니다.
조직 도입에는 의사결정자의 참여가 효과적이다
또 하나 의미 있었던 점은, 의사결정자나 리더급이 참여한 팀일수록 워크숍 이후에 실질적인 액션으로 이어지기 쉬웠다는 점입니다.
AI 활용은 현장 수준에서 머물면 그저 ‘편리했다’로 끝나기 쉽습니다. 실제로 조직 전체로 확산하려면 어떤 영역부터 시작할지, 어디에 시간을 투자할지, 무엇을 표준화할지, 어디까지 운영에 내재화할지 같은 판단을 해야 합니다.
이번 워크숍에는 그런 판단을 내릴 수 있는 사람이 처음부터 함께 참여했기에 워크숍 이후의 논의가 단순히 ‘재미있었다’에서 멈추지 않고 다음 실행 단계로 자연스럽게 연결될 수 있었습니다.
운영해 보며 새롭게 보인 것
이번 워크숍에서 인상적이었던 것은 AIDD의 실무 검증뿐 아니라 한자리에 모여 대화하는 과정 자체가 팀이 앞으로 나아갈 수 있는 필수 조건이라는 것을 알게 되었다는 것입니다.
실제 주제를 앞에 두면 평소 명시되지 않았던 전제나 역할별로 다른 인식이 자연스럽게 수면 위로 드러납니다. 이러한 차이를 현장에서 바로 대화를 통해 조율하는 시간이 AIDD를 시도하는 것 이상으로 큰 의미를 지닌 순간이 많았습니다.
또한 휴식과 식사를 포함 해 팀이 같은 공간에서 대화를 이어갈 수 있는 여백이 있었다는 점도 무시할 수 없었습니다. 형식적인 회의에서는 잘 나오지 않는 가벼운 상담이나 잡담 속에서, 다음에 시도할 일과 조직적으로 정비해야 할 논점이 드러나는 경우가 많았습니다.
AIDD를 조직에 성공적으로 안착시키기 위해 필요한 것
적용하기 쉬운 주제부터 시작할 것
처음부터 모든 업무에 AI를 적용하려고 하면 잘 풀리지 않습니다. 요구 사항이나 쟁점 정리의 여지가 큰 주제나 관계자 간 인식을 맞추는 것이 중요한 주제, 기존 정보를 어느 정도 모을 수 있는 주제, 작게 한 사이클을 검증해 볼 수 있는 주제부터 시작하는 것이 효과적입니다.
가볍게 시작할 수 있는 진입점을 만들 것
AIDD라고 하면 자칫 큰 변화처럼 보입니다. 하지만 처음부터 풀 세트를 도입할 필요는 없습니다. 기능 하나, 요구 사항 정리 하나, 리뷰 관점 정리 하나처럼 작게 시작할 수 있는 진입점이 있을 때 오히려 더 빠르게 확산됩니다.
컨텍스트 정비를 공식 업무로 다룰 것
사양, 용어, 제약 조건, 설계 의도, 판단 이유를 정리하는 일은 AI 활용만을 위한 추가 작업이 아닙니다. 본래 팀의 개발 역량을 강화하기 위한 필수 자산화 과정입니다.
다만 중요하다는 것을 알면서도 일상 개발 업무에서는 후순위로 밀리기 쉽습니다. 그렇기 때문에 이를 개인이 자발적으로 수행하는 선의나 취미 영역에 남겨두지 말고, 팀과 조직 차원에서 반드시 시간을 투자해야 하는 공식 업무로 다뤄야 합니다.
마치며
이번 워크숍을 통해 다시 한번 느낀 점은, AI 활용의 본질이 단순히 강력한 도구를 도입하는 것에 있지 않다는 사실입니다. 핵심은 AI에게 무엇을 전달할지, 어디에서 사람이 판단할지, 팀에서 어떻게 운영할지, 그 체계를 어떻게 조직에 뿌리내리게 할지를 함께 설계하는 데 있습니다.
AIDD는 단순한 개발 효율화 기법이 아니라, 제품을 만들어가는 방식 자체를 재정의하는 시도라고 느낍니다. 따라서 실제 주제를 가져와 팀 차원에서 시도하고, 시행착오를 겪으며 전진하는 이번 워크숍과 같은 자리는 큰 의미를 갖습니다. AI로 무엇을 할 수 있는지를 넘어서 ‘우리 개발 프로세스에 무엇이 부족한지’를 함께 파악할 수 있기 때문입니다.
앞으로도 AI 활용을 단발성 실험으로 끝내지 않고, 현장에서 지속해서 실행할 수 있는 형태로 만들어 가기 위한 시도를 계속해 나가고자 합니다.
