서론

2026년 6월 17일, GitHub Copilot app이 GA(일반 제공)되었습니다. Issue를 기점으로 계획 → 구현 → 동작 확인 → PR → 머지(Merge)까지, 에이전트를 "감독"하면서 진행하는 전용 데스크톱 앱입니다.

• GitHub Copilot app: The agent-native desktop experience (GitHub Blog)
• About the GitHub Copilot app (GitHub Docs)

간단하게 일련의 개발 흐름에 따라 사용해 보았습니다.

GitHub Copilot app이란

대략 말하자면, **여러 에이전트 세션(Agent Session)을 병렬로 실행하고 감독하기 위한 콕핏(Cockpit)**입니다. 터미널(Terminal)·IDE·브라우저(Browser)·GitHub를 오가지 않고, 개발 라이프사이클 전체를 이 앱 하나로 완결시킨다는 컨셉입니다.

개념	설명
My Work	활성 세션·Issue·PR·자동화를 일람할 수 있는 대시보드
...	Interactive (협업) / Plan (계획 및 승인) / Autopilot (자동 실행)의 3가지 모드
Canvas	사람과 에이전트가 공동 편집하는 양방향 작업 서피스 (계획·PR·터미널·브라우저 등)
Agent merge	CI 모니터링·리뷰어 추적·체크 대응을 하면서 머지(Merge)까지 가져다주는 기능

특히 유용한 점은 세션(Session)이 git worktree로 격리되어 있다는 점입니다. 병렬로 여러 개를 실행해도 브랜치(Branch)가 간섭하지 않습니다.

그럼 사용해 봅시다---

📝 (Option) Step 1: Issue 작성

Issue 기반으로 개발할 때를 상정하여, 우선 GitHub 상에서 Issue를 만듭니다.

수행할 작업을 GitHub Issue에 작성합니다. 이번에 세운 것은 「포스터 월(Poster Wall) UI 모크업 만들기 (더미 데이터·Canvas / 통합 브라우저로 검증)」입니다.

의식한 점은 배경·스코프(Scope)·수락 조건(Acceptance Criteria)을 제대로 작성하는 것입니다.

• 배경: 「본 영화 / 드라마를 포스터 선반에서 바라보는」 경험의 토대를 우선 더미 데이터로 구축
• 스코프: MovieEntry 타입, 더미 데이터, PosterCard / PosterGrid / Shelf 구현, 렌더링 테스트
• 수락 조건: 화면 너비에 따라 열(Column) 수가 변경됨 / 포스터 누락 시 플레이스홀더(Placeholder) 표시 / any 금지 / npm run dev·test·build 통과

이 Issue가 그대로 「지시서」가 됩니다. 수락 조건을 구체적으로 적을수록 「생각했던 것과 다르다」는 상황이 줄어듭니다. 사람에게 부탁할 때와 마찬가지입니다.

🗂️ Step 2: Plan 모드로 계획 세우기

여기서부터 Copilot app입니다. Issue를 지정하고, 먼저 Plan 모드에서 계획을 세우도록 합니다. 왼쪽은 에이전트와의 대화, 오른쪽은 Canvas입니다. Canvas에는 plan-canvas.md로서 「문제 / 목적」 「방침」 「사전 준비 (테스트 기반)」 「구현 스코프 (todos)」가 정리되며, 오른쪽 끝에는 구현 단계의 체크리스트가 나열됩니다.

Canvas의 좋은 점은 계획이 "결과물"로서 눈앞에 나타난다는 것입니다. 채팅을 거슬러 올라가지 않아도 지금 무엇을 하려고 하는지 한눈에 볼 수 있습니다. 게다가 읽기뿐만 아니라 편집·순서 변경·승인이 가능한 양방향 서피스입니다.

Terminal 탭으로 전환하면 셸(Shell)도 다룰 수 있습니다.

경로가 ...\.copilot\repos\copilot-worktrees\movie-shelf\ktc-hirokinomura-silver-fortnight로 되어 있어, 이 세션 전용 git worktree에서 작업하고 있음을 알 수 있습니다. 표에서 언급한 「세션별 격리」를 실제로 확인할 수 있었습니다.

🤖 Step 3: Autopilot으로 구현

계획에 납득했다면, Autopilot으로 전환하여 구현을 요청합니다. 여기서부터는 에이전트의 자율 주행 단계입니다. 저는 진행 상황을 지켜보며 필요한 부분에만 참견하는 역할을 합니다.

진행 상황은 Canvas의 Plan에서 추적할 수 있습니다.

Setting up test infra → Defining MovieEntry type → Creating sample data → Building PosterCard ... 와 같이, 계획한 단계가 그대로 진행 상황 보드(Progress Board)가 되어 있습니다. 현재 어디를 구현 중인지, 그리고 무엇이 남아 있는지 한눈에 알 수 있어 매우 직관적입니다!

잠시 지켜보는 사이, 타입 정의(Type Definition) · 더미 데이터 · 각 컴포넌트 · 테스트까지 한 차례 완성되었습니다. 여기까지 직접 손으로 작성한 코드는 단 한 줄도 없습니다. 다음은 실제로 동작하는지 확인하겠습니다.

🔍 Step 4: 서버를 실행하여 동작 확인

체크가 모두 그린(Green)이라 하더라도, 테스트를 통과하는 것과 화면이 의도한 대로 보이는 것은 별개의 문제입니다. 구현 중인 앱을 그대로 실행하여 확인합니다.

Copilot App에는 통합 브라우저(Integrated Browser)가 내장되어 있어, 별도의 브라우저를 열지 않고도 앱 내에서 프리뷰(Preview)할 수 있습니다. 에이전트가 개발 서버를 실행했고, 오른쪽에 movie-shelf가 표시되었습니다.

더미 포스터가 격자 형태로 나열되어 있습니다. The Grand Budapest Hotel, Spirited Away, Parasite, Blade Runner 2049 ... 각각에 제목 · 공개 연도 · ★ 평점이 붙어 있으며, 포스터 이미지가 없는 것은 "poster" 플레이스홀더(Placeholder)로 채워져 있습니다. 수락 조건(Acceptance Criteria)인 "포스터 누락 시 플레이스홀더 표시"가 그대로 적용되어 있습니다.

왼쪽 로그에서는 에이전트 스스로도 "테스트를 2회 실행하여 통과했으며, 빌드(Build)도 OK, 통합 브라우저로 검증 가능한 상태"라고 정리해 주었습니다. Issue → 계획 → 구현 → 동작 확인이 앱을 벗어나지 않고 연결되어 있음을 체감할 수 있습니다.

🔀 Step 5: PR 작성

외관과 동작 모두 문제가 없어 보이므로, PR(Pull Request) 작성을 요청합니다. 화면 우측 상단의 버튼을 누르자 「Creating PR...」로 바뀌며 작성이 시작되었습니다.

상단 탭에는 Changes (+1455 / -265), Plan, Terminal, plan-canvas.md, preview 등 이번 세션의 결과물들이 나열됩니다. 주소창이 localhost:5174를 가리키고 있어, 방금 전의 통합 브라우저가 여기에 연결되어 있다는 것도 알 수 있습니다.

PR 작성 과정은 왼쪽 로그를 통해 추적할 수 있습니다.

"먼저 변경 사항을 커밋(Commit) 및 푸시(Push)하겠습니다"라고 선언한 뒤,

• git status로 변경 사항 확인
• .github 하위의 PULL_REQUEST_TEMPLATE을 찾아 템플릿에 따라 본문 준비 - 변경 사항 커밋
• 브랜치를 push하고 upstream 설정
• PR 생성 (ktc-hirokinomura/poster-wall-mock → origin/main)

을 순차적으로 수행하고, 마지막으로 "PR을 생성했습니다. 커밋 및 푸시가 완료되었으며, npm test / build / lint 모두 green입니다"라고 보고합니다.

🚀 Step 6: Agent merge로 머지(Merge)

마지막은 머지입니다. Canvas로 전환하면 생성된 PR의 내용을 그대로 읽을 수 있습니다.

PR 본문에는 필터 / 정렬 로직의 위치, 테스트 프레임워크로 Vitest를 선택한 이유, 검증 결과(npm test 11 passed, build 성공, lint clean 및 any 미사용)까지 부족함 없이 요약되어 있습니다. AGENT.md의 분리 방침(표시는 src/components, 로직은 src/lib, 데이터는 src/mocks)도 준수되었으며, "실제 데이터(library.json) 연결은 별도 Issue(#4)에서 대응 예정"이라는 스코프(Scope) 외 사항에 대한 선언까지 덧붙여져 있었습니다. 하단의 Check Status에서는 CI / build가 pull_request와 push 모두에서 성공했음을 보여줍니다. GitHub Actions의 원시 로그(Raw Log)까지는 추적할 수 없지만, 상태를 파악하기에는 충분합니다.

그리고 이번에 가장 직접 사용해 보고 싶었던 것이 바로 Agent merge입니다. 「Merge pull request」 옆에 있는 토글입니다.

Agent will address reviews, fix CI, and resolve conflicts automatically.

에이전트가 리뷰 지적에 대한 대응, CI 수정, 충돌 해결(Conflict resolution)까지 수행해 주는 기능입니다. 이번에는 Ready to merge / All checks passed / Unresolved review comments 0 상태로 문제가 없었기에 그대로 머지(Merge)했습니다.

요약

movie-shelf의 "포스터 월 UI 목업 만들기" 이슈(Issue)를 주제로,

이슈 생성 → 플랜(Plan)으로 계획 → Autopilot으로 구현 → 통합 브라우저로 동작 확인 → PR 생성 → Agent merge로 머지

과정을 거의 앱 하나 안에서 돌려보았습니다.

이슈를 작성한 이후에는 거의 이 앱을 벗어나지 않고 작업을 진행할 수 있었습니다. 코드를 작성하는 속도보다 무엇을 만들 것인지를 언어화하는 능력(이슈와 AGENT.md를 정리하는 능력)이 더 중요하게 작용한다는 것을 새삼 느꼈습니다.

Discussion