ODW #4: 코파일럿에서 파일럿으로, 에이전틱 코딩으로 구현부터 PR까지 자동화

9 hours ago 7

안녕하세요. LY Corporation의 Hirano입니다. Yahoo! 파이낸스에서 프런트엔드 영역을 개발하고 있으며 스크럼 마스터도 담당하고 있습니다. 또한 LY Corporation 전체 엔지니어를 대상으로 AI 활용을 촉진하기 위한 전사 워크숍 Orchestration Development Workshop(참고)을 운영하는 Orchestration 길드 멤버로도 활동하고 있습니다.

Orchestration 길드는 CTO가 선발한 엔지니어가 모여 현장에서 AI를 더욱 적극적으로 활용할 수 있는 실무 지식을 전사적으로 공유하는 커뮤니티입니다. 워크숍에서 다룰 주제 제안, 바로 적용할 수 있는 실무 사례 공유, 기술 관점에서 품질을 높이기 위한 조언 등을 담당하면서 Orchestration Development Workshop 콘텐츠가 개인에 의존하지 않고 지속적으로 발전할 수 있도록 지원하는 역할을 맡고 있습니다.

이 테크 블로그에서는 Orchestration Development Workshop에서 공유한 ‘코파일럿에서 파일럿으로: 에이전틱 코딩 실천 워크숍’ 내용을 중심으로 기획 배경 팀 내 확산 과정을 함께 소개합니다.

AI 활용과 관련해 안고 있던 과제와 전환점

2025년 여름 무렵, 기존 개발 프로세스를 따르던 저희 팀은 아직 AI를 코딩에 활용하는 데 능숙하지 않았습니다. GitHub Copilot 등을 활용해 코드 일부를 생성하는 것은 가능했지만 여전히 개발의 많은 부분을 사람이 직접 수행하고 있었고, 생산성이 향상됐다는 것을 크게 체감할 수 없었습니다.

이러한 상황에서 개발 방식을 전환한 것은 아래 두 사건 때문입니다.

첫 번째는 명세 주도 개발(specification-driven development, SDD)의 등장입니다. 이 개발 방식은 설계 문서와 같은 문서를 먼저 작성한 뒤 구현을 진행하는 것으로, 의도한 결과물을 보다 쉽게 도출할 수 있는 개발 방식입니다. 저희 팀에서는 처음부터 요구 사항 명세서와 같은 문서를 작성하고 있었기에 필요한 문서는 충분히 갖춰져 있었습니다. 이런 문서를 활용하면 기존 개발 프로세스를 그대로 유지하면서도 AI를 활용한 코드 생성을 효율화할 수 있다고 판단했습니다.

두 번째는 사내 시스템인 Jira와 Confluence를 AI와 MCP(model context protocol)를 이용해 서로 연동할 수 있게 됐다는 점입니다. 앞서 언급한 여러 문서는 Confluence에 정리하고 있었는데 MCP가 등장하면서 AI 코딩 도구와 문서를 쉽고 빠르게 연계할 수 있게 되었습니다.

에이전틱 코딩이란

에이전틱 코딩이란 ‘에이전트가 고수준의 목표를 전달받아 이를 여러 단계로 분해한 뒤 자율적으로 실행하며 피드백을 통해 조정해 나가는 개발 방식’입니다. 기존 개발 보조 도구가 눈앞의 코드 다음 부분을 제안하는 것에 머물렀다면, 에이전트는 코드베이스 전체를 읽고 파일 간의 관계까지 이해하며 명령 실행과 테스트까지 포함해 ‘요구 사항이 충족될 때까지 반복한다’는 점이 특징입니다.

여기서 중요한 점은 AI 에이전트에게 단순히 일부 구현 작업만 맡기는 것이 아니라 ‘프로덕트 기능을 개발하는 일련의 작업 전체’를 맡기는 것입니다. 테스트에 실패하면 다시 수정하고 린터가 지적하면 고치면서 결국 빌드까지 성공하는 전체 사이클을 AI 에이전트가 스스로 반복하도록 만들 때 비로소 AI 에이전트는 파일럿으로 기능할 수 있습니다.

워크숍 목표와 내용

그럼 이번 워크숍에서 무엇을 목표로 삼고 이 목표를 달성하기 위해 어떤 내용을 어떻게 진행했는지 간략히 살펴보겠습니다.

코파일럿에서 파일럿으로, 에이전트 코딩으로 구현부터 PR까지 자동화 워크숍

워크숍 목표

이번 워크숍 목표는 개발 프로세스 중 ‘구현부터 PR(pull request) 작성까지’를 AI가 수행하도록 만드는 경험을 제공하는 것이었습니다. AI가 요구 사항을 정의하고 명세서를 생성하는 것부터 수행하는 개발 방식도 존재하지만, 기존 개발 프로세스를 크게 변경하려면 비용이 많이 듭니다. 이에 저희는 요구 사항 정의 후 명세서 작성은 사람이 담당하고, 테스트/리뷰/릴리스 역시 최종적으로는 사람이 책임지는 한편, 구현 계획 수립/구현/PR 작성/초기 리뷰는 AI에게 맡기는 형태로 구성했습니다. 실제 업무 프로세스와 가까운 형태로 일련의 흐름을 경험할 수 있도록 구성한 것입니다.

다음은 사람과 AI의 작업 분담을 나타낸 그림입니다.

워크숍 내용

에이전틱 코딩을 소개하면서 3단계로 구성한 실습을 진행했습니다. 각 단계를 순서대로 하나씩 살펴보겠습니다.

1단계: 작업 이해 및 구현 계획 작성

에이전틱 코딩을 안정적으로 수행하기 위한 핵심은 초기에 구현 계획을 수립해 재작업을 줄이는 것입니다. 처음부터 작업을 모호하게 지시하면 의도한 것과 다른 결과물이 생성돼 작업을 다시 해야 할 수도 있습니다. 따라서 명세서를 AI에게 전달해 AI가 상세 구현 계획을 작성하게 만든 뒤 이를 사람이 리뷰해서 AI가 의도한 대로 잘 구현할 수 있도록 합니다. 이와 같은 접근 방식은 주요 AI 코딩 도구에서 계획 모드를 제공하고 있다는 점에서도 자연스러운 흐름이라고 할 수 있습니다.

저희는 일반적으로 개발할 때 Jira 티켓에 작업 내용을 기재하고 관련 명세 문서 등은 Confluence에 정리해 놓는데요. AI가 이를 기반으로 구현 계획을 작성하도록 했습니다. 실습에서는 샘플 애플리케이션 리포지토리를 준비하고 Claude Code용과 GitHub Copilot용 커스텀 슬래시 명령어를 마련했습니다. 이를 기반으로 1단계에서는 Jira 티켓 URL을 인자로 명령어를 실행하고, 생성된 계획을 사람이 리뷰하는 단계까지 진행했습니다.

계획용 커스텀 슬래시 명령어

--- description: 작업 계획 수립 시 사용 --- # 개요 당신은 이 프로덕트의 내용에 정통한 엔지니어입니다. 사용자가 입력한 Jira 또는 Wiki의 URL에서 정보를 수집하고 코드를 분석해 작업 계획서를 작성하세요. # 절차 1. Jira 티켓 정보는 jira MCP 도구를 사용해 수집한다. 2. Jira 티켓에 Epic 링크가 존재할 경우 해당 Epic과 관련된 모든 티켓을 수집한다. 3. Jira 티켓에 포함돼 있거나 별도로 입력된 Confluence URL에서 정보를 수집할 때는 confluence MCP 도구를 사용한다. 4. 수집한 정보를 바탕으로 관련 코드를 분석한다. 코드 분석 시 Explore Agent를 사용한다. 5. 분석 결과를 바탕으로 작업 계획서를 작성한다. # 주의 사항 - 작업 계획서 작성 위치는 `specs/{안건명or티켓 번호:영문 숫자 하이픈 구분}/plan.md`이다. - 코드 분석 시 memory가 있다면 이를 확인해 코딩 스타일 등을 파악한 후 진행한다. - 작업 계획서에는 다음 내용을 포함할 것 ``` # 작업계획서: 티켓 ID ## 티켓 정보 ## 개요 ### 배경 ## 대응 영역 ### 대상 URL ### 대상 컴포넌트 ## 수용 조건 ## 관련 Pull request・티켓 ## 기술적 분석 ### 구현이 필요한 영역 ## 작업 태스크 ## 참고 정보 ### 구현 참고 영역 ## 주의사항 ### 영향 범위 ### 테스트 관점 ## 예상 공수 ## 체크리스트 ``` - 다른 리포지터리에 작업이 필요한 부분이 있는 경우 그 내용을 명시하고 별도로 대응하도록 안내할 것 - Wiki를 참조할 때는 프로젝트 사양서 외에 화면 사양서나 컴포넌트 사양서 등도 함께 참고할 것

위 명령의 핵심은 다음 세 가지입니다. 하나씩 어떤 의미인지 살펴보겠습니다.

MCP 도구를 활용한 문서 조사 지시
코드 조사 시 Explore Agent 활용
구현 계획을 파일로 출력

첫 번째로 위 명령은 도구를 올바르게 사용하도록 만들기 위한 지시를 포함하고 있습니다. 일반적으로 관련 티켓에 Confluence URL을 기재하는 경우가 많기 때문에 관련 자료까지 함께 조사하도록 지시했습니다.

두 번째로 위 명령의 Explore 에이전트는 Claude Code를 위한 지시입니다. Claude Code에 내장된 이 서브 에이전트를 활용하면 메인 세션의 컨텍스트에 영향을 주지 않으면서 경우에 따라 병렬로 코드를 탐색할 수 있습니다.

세 번째로 위 명령과 같이 구현 계획을 파일로 출력하게 만들면 AI가 생성한 계획을 사람이 리뷰할 수 있고, 세션을 새로 시작해도 지속적으로 활용할 수 있다는 장점이 있습니다. 또한 관련 자료를 함께 정리해 두면 이후 AI에게 PR 작성을 맡길 때 그대로 활용할 수 있다는 장점도 있습니다.

이 글 작성 시점을 기준으로 Claude Code의 경우 Plan Mode를 사용하면 ~/.claude/plan 경로에 계획을 파일로 작성하고, Explore 에이전트를 자동으로 사용하게 돼 있기 때문에 위 요구 사항을 충분히 충족할 수 있습니다. 따라서 문서 조사 부분만 커스텀 슬래시 명령어나 서브 에이전트로 분리하고 Plan Mode를 활용하는 방식도 가능합니다.

2단계: 구현 및 PR 생성

1단계에서 AI가 작성하고 사람이 검토한 구현 계획서를 AI에게 전달해 이를 기반으로 코드를 생성하고 간단히 검증하도록 합니다. 이 단계에서도 구현하고 PR을 생성하기 위한 명령어를 준비해 활용했습니다.

구현용 커스텀 슬래시 명령어

1단계에서 생성한 구현 계획서의 파일 경로를 인자로 전달해 실행합니다.

--- description: "인자로 지정한 구현 계획서를 기반으로 구현을 수행한다." --- $ARGUMENTS에 정리된 구현 계획을 기반으로 구현을 진행하세요. ▼구체적인 절차 1. 구현 계획서 내용을 확인하고 필요한 구현 범위를 파악한다. 2. 구현 계획서를 바탕으로 코드를 구현한다. 3. 필요한 범위의 테스트 코드를 추가하거나 수정한다. 4. test 명령어를 실행해 모든 테스크를 통과하는지 확인한다. 5. 구현을 완료한 뒤 lint 명령어와 build 명령어를 실행해 배포할 수 있는 상태인지 확인하고 문제가 있으면 수정한다.

커스텀 슬래시 명령의 내용은 간단한데요. 여기서 중요한 것은 작업 단계를 명시하는 것입니다. 구현하고, 테스트하고, 린트와 빌드를 통과하는 과정을 통해 최소한의 품질을 유지하면서 AI가 자율적으로 작업을 진행하도록 합니다. 이와 같이 처음에 단계를 명확히 제시하면, Claude Code나 GitHub Copilot과 같은 코딩 에이전트는 할일 목록을 생성해서 수행해야 할 작업을 빠뜨리지 않고 진행합니다.

PR 생성 커스텀 슬래시 명령어

구현을 완료한 뒤 내용을 확인하고 문제가 없으면 PR 생성용 커스텀 슬래시 명령어를 실행해 PR을 생성합니다. 이 명령어는 Orchestration Development Workshop 1회에서 소개된 것을 활용합니다(참고).

이 명령어는 템플릿을 따라 설명문을 작성해 준다는 점에서 유용합니다. 저희 팀에서는 템플릿에 관련 자료를 기재하는 항목을 마련해 뒀는데 AI가 1단계에서 조사한 내용을 여기에 작성하도록 만들어서 번거로운 작업을 줄일 수 있었습니다.

3단계: AI 리뷰 및 지적 사항 대응

Orchestration Development Workshop 1회에서는 AI 스크리닝 리뷰용 커스텀 슬래시 명령어를 소개했습니다(참고). 여기서도 이 명령어를 사용합니다. 이 명령어는 이미 작성된 코멘트도 함께 가져오도록 구성된 프롬프트입니다. 따라서 AI가 2단계에서 생성한 PR를 셀프 리뷰하면서 남긴 코멘트나 다른 팀원의 리뷰 코멘트도 읽을 수 있습니다.

AI는 리뷰 완료 후 수정해야 한다고 판단한 부분과 PR에 먼저 달려 있던 코멘트에 대한 자신의 판단 을 출력합니다. 이 코멘트를 사람이 확인한 뒤 실제로 수정해야 할 항목이 있다면 그대로 수정하도록 지시합니다. 이와 같이 리뷰뿐 아니라 수정 작업 자체도 AI에 맡기면 수정 대응 비용도 줄일 수 있습니다.

에이전틱 코딩의 장점과 도입 시 주의 사항

워크숍에서 소개한 에이전틱 코딩을 도입하면 크게 두 가지 장점이 있습니다.

하나는 코드 생성 속도 향상입니다. 이 프로세스에서는 AI 에이전트가 자율적으로 작동하기 때문에 사람이 확인하고 지시하는 횟수가 줄어듭니다. 따라서 AI가 구현을 진행하는 동안 다른 작업을 수행하거나 여러 에이전트를 병렬로 실행해서 이전보다 더 많은 코드를 얻을 수 있습니다.

다음으로 구현 계획을 사전에 수립하면 어떤 작업을 진행할지 미리 구체적으로 그려보는 데에도 도움이 되며, 미처 파악하지 못했던 작업이나 리스크를 조기에 발견할 수도 있습니다.

한편 주의해야 할 점도 있습니다. 현재 시점에서는 AI가 대량으로 작성한 코드를 사람이 리뷰해야 하기 때문에 리뷰 부담이 증가하며, 개발 경험이 기존과 크게 달라진다는 점이 스트레스로 다가올 수도 있습니다. 또한 AI가 작성한 코드를 사람이 책임을 진다는 인식이 반드시 필요합니다. 프로덕트의 품질을 유지하는 것은 매우 중요하며, 저품질 코드는 리뷰어의 부담을 증가시키고 프로덕트의 기술 부채로 이어질 수 있습니다.

워크숍 성과

이번 워크숍은 사전 준비를 전제로 한 실습 중심의 실전편과 보다 세심한 지원을 제공하는 도입편으로 나눠 총 두 번 진행했고, 약 2,500명이 참여했습니다. 참가자를 대상으로 학습 및 실습 내용을 업무에 적용했거나 앞으로 적용할 의향이 있는지 묻는 설문 조사를 실시했고 결과는 다음과 같습니다.

선택 항목비율

이미 지속적으로 활용하고 있음	9.5％
이미 일부를 시도해 봄	34.7％
아직 시도하지 않았지만, 가까운 시일 내에 시도할 예정	48.5％
아직 시도하지 않았고, 시도할 계획도 없음	5.8％
기타	1.5％

코딩 관련 워크숍이어서 많은 분들이 벌써 익숙하게 사용하고 있던 작업이 포함돼 있었기 때문인지 40% 이상이 어떤 형태로든 이미 워크숍 내용을 적용하거나 활용하고 있는 것으로 나타났습니다. 또한 이번 워크숍에서는 MCP 서버 활용 방법과 에이전트에 작업을 전달하는 방식 등 코딩 영역에서 활용하는 방법을 보다 구체적으로 다뤘는데요. 이를 통해 AI를 어떻게 활용할지 조금 더 구체적으로 생각해 볼 수 있었다는 의견도 있었습니다. 반면 약 절반 정도는 아직 실천하지 못하고 있는 상태로 나타났는데요. 이 분들이 앞으로 실제 업무에서 적용하고 활용해 나갈 모습이 기대됩니다.

워크숍을 준비하며 얻은 인사이트

팀을 대상으로 한 실행 내용을 기반으로 Orchestration Development Workshop을 준비하는 과정에서 얻은 인사이트를 소개합니다.

저희 팀에서는 스크럼의 확장 프레임워크인 LeSS(large-scale scrum)를 채택했고, 개발 작업을 사용자 스토리로 다루며 상세한 수용 조건을 티켓에 기재하는 것이 규칙입니다. 이러한 환경에서는 Jira 티켓에 수행해야 할 작업의 상세한 정보를 정리해 놓아야 하기 때문에 AI에 Jira 티켓만 전달해도 어느 정도 안정적으로 개발할 수 있습니다. 만약 Jira 티켓에 모호한 정보만 기재해 놓았다면 AI에게 그대로 개발을 맡기는 것이 어려울 것입니다. AI를 잘 활용하려면 AI가 정보를 잘 참조할 수 있는 환경을 구축하는 것이 중요하다는 것을 다시 한번 확인할 수 있었습니다.

마치며

AI 모델과 관련 도구는 매우 빠른 속도로 발전하고 있으며, 이와 관련해 너무 많은 사람이 정보를 쏟아내고 있어서 사례를 접한 뒤 실제로 도입하거나 실무에 적용하는 데 어려움을 느끼는 경우가 많습니다. 또한 사내 여건 등의 문제로 도입 자체가 어려운 경우도 적지 않을 것입니다.

그럼에도 이 속도를 따라가지 못하면 시대의 변화에 뒤쳐질 수 있다는 위기감이 듭니다. 그래서 AI와 관련 도구를 업무에 한 번 활용해 보려고 할 때 주로 부딪히는 두 가지 문제는 ‘구체적으로 어떻게 도입해야 할지 머리에 그려지지 않는 문제’와 ‘기존 업무에 쫓겨 도입 및 활용 준비에 시간을 할애하기 어려운 문제’입니다.

이 문제를 해결하려고 한번에 큰 변화를 시도하면 도입하기도 적응하기도 어려울 것입니다. 이에 이번 워크숍에서는 기존 개발 프로세스를 크게 변경하지 않으면서도 간결하게 도입할 수 있는 형태로 구성해 일상 업무 속에서 자연스럽게 적용할 수 있도록 준비했습니다.

이와 같은 접근 방식은 코딩 업무에만 국한되지 않는다고 생각합니다. 기존 업무의 어떤 부분을 어떻게 변화시킬 수 있을지 구체적으로 머리에 그려지도록 만들면서 또한 쉽게 도입할 수 있도록 준비하면 AI 활용을 더욱 촉진할 수 있을 것입니다. 개선은 도입 이후에도 얼마든지 가능합니다. 우선은 최소한의 범위로 빠르게 도입하고 변화를 체감하면서 AI와 함께 개발하는 시대에 적응해 나가야 합니다.