GitHub Copilot app을 사용하며 느낀, 일상의 마찰이 줄어드는 4가지 요소

서론

2026년 5월 14일에 GitHub Copilot app이 technical preview로서 안내되었습니다.

• GitHub Copilot app is now available in technical preview - GitHub Changelog
• About the GitHub Copilot app - GitHub Docs

공식 문서에서는 GitHub Copilot app을 **GitHub 네이티브 데스크톱 앱 (GitHub native desktop app)**으로 설명하고 있습니다. GitHub Copilot CLI를 토대로 하면서, 여러 세션, Issue / Pull Request, 리뷰, 워크플로우 (workflow)를 한 곳에서 다룰 수 있는 것이 특징입니다. 🧭

저는 지금까지 GitHub Copilot CLI를 자주 사용해 왔습니다. 실제로 터미널 (terminal)에서 그대로 흐름을 이어가고 싶은 상황에서는 지금도 CLI가 적절하다고 느낍니다.

• 다음 큰 작업을 GitHub Copilot CLI에서 시작하고 싶어지는 이유
• GitHub Copilot CLI로 생각하는 다중 에이전트 (multi-agent) 설계
• GitHub Copilot app의 Technical Preview로 에이전트 개발 워크플로우는 어떻게 변하는가

그럼에도 불구하고 GitHub Copilot app을 사용해 보니, 코드를 작성하기 전의 망설임이나 여러 작업을 처리할 때의 마찰이 조금 줄어드는 것처럼 느껴졌습니다. 적어도 지금까지 사용해 온 범위 내에서는 일상적으로 여는 도구로서 GitHub Copilot app을 선택하는 상황이 늘어나고 있습니다.

위의 기사에서는 GitHub Copilot app의 technical preview가 워크플로우 전체를 어떻게 바꿀 것인가라는 관점에서 정리했습니다. 이번 기사에서는 조금 더 앞단으로 다가가, 지금까지 사용하며 일상적으로 느낀 사용 편의성을 소개하고자 합니다.

이번에 특히 쓰고 싶은 내용은 다음 4가지 점입니다.

• 여러 리포지토리 (repository)를 동시에 다룰 때의 인지 부하 (cognitive load)가 낮아진다
• 작업의 입구가 '디렉토리 (directory)'가 아니라 '리포지토리와 세션 (session)'이 된다
• 정형적인 작업을 워크플로우 (workflow)로 만들어 호출할 수 있다
• 일본어 입력 시의 걸림돌을 신경 쓰지 않아도 된다

우선 공식적으로는 무엇이 발표되었는가

Changelog에서는 GitHub Copilot app을 다음 3가지 축으로 소개하고 있습니다.

공식의 축	내용	내가 특히 효과적이라고 느낀 점
🧭 Start from GitHub context	Issue, Pull Request, 기존 세션 등 GitHub 상의 문맥으로부터 시작할 수 있음	"어느 리포지토리에서 시작할지"가 정리됨
...

이에 더해 GitHub Docs에서는 parallel workspaces, session modes, scheduled workflows도 주요 기능으로 정리되어 있습니다.

이 중에서 제가 "이것은 일상의 작업이 바뀌겠구나"라고 느낀 것은, 화려한 자율 실행 그 자체보다도 평소의 작업을 정리하는 발판 부분이었습니다.

여기서부터는 저의 일상적인 사용법 중에서 특히 효과적이었던 4가지를 차례대로 써 내려가겠습니다.

1. 여러 리포지토리를 동시에 다룰 때 인지 부하가 낮아지기 쉽다

CLI를 여러 리포지토리에서 사용할 때, 저는 가끔 "지금 어느 콘솔에서 어떤 작업을 하고 있었나"를 살짝 헷갈리곤 합니다.

물론 터미널의 타이틀을 바꾸거나, 탭을 정리하거나, tmux 또는 Windows Terminal의 운용을工夫(고안)하면 개선할 수 있습니다. 그럼에도 불구하고 여러 리포지토리, 여러 브랜치 (branch), 여러 태스크 (task)가 동시에 돌아가기 시작하면 은근히 인지 부하가 높습니다.

GitHub Docs에서는 세션이 **리포지토리별로 그룹화 (grouped by repository)**되며, 각 세션은 독립된 워크스페이스 (workspace)로서 동작한다고 설명되어 있습니다. 실제로 사용해 보면 **"지금 어느 작업 공간에 있는가"**를 시각적으로 파악하기 쉽습니다.

관점	CLI 중심에서 느끼기 쉬운 점	GitHub Copilot app에서 느낀 점
🖥️ 작업의 가시성	여러 콘솔이 나열됨	하나의 앱 내에서 repository / session 단위로 보임
...

특히 Issue를 확인하면서 다른 리포지토리의 PR도 신경 쓰고, 동시에 손으로는 또 다른 별건을 진행하는 날에는 이러한 차이가 효과를 발휘합니다.

저는 CLI의 "터미널에서 모든 것을 진행할 수 있는 느낌"을 좋아합니다. 다만, 병렬 작업의 정리라는 의미에서는 app 쪽이 기본적으로 구조화되어 있는 만큼, 저에게는 다루기 더 쉽게 느껴졌습니다. 🗂️

2. 작업의 시작점이 "디렉토리"가 아니라 "리포지토리와 세션"이 된다

GitHub Copilot CLI를 사용할 때는 당연하게도 어느 디렉토리에서 실행할 것인가가 중요합니다.

이는 CLI의 자연스러운 설계이며 나쁜 것은 아닙니다. 다만, 매일 여러 리포지토리를 오가다 보면,

• 지금 어느 디렉토리에 있는가
• 그 장소에서 정말로 Copilot을 실행해도 되는가
• 다른 리포지토리에서 시작할 생각은 아니었는가

를 실행 전에 머릿속으로 확인해야 합니다.

반면, GitHub Copilot app의 getting started에서는 onboarding 시나 나중에 리포지토리를 연결하여 새로운 session을 만들 때는 repository를 선택한 후 시작하는 흐름으로 되어 있습니다. 저에게는 이것이 의외로 큰 차이였습니다.

CLI에서는 "먼저 올바른 위치로 이동하기"가 선행됩니다. app에서는 "어떤 리포지토리에서 작업할지 선택하기"가 선행됩니다.

이 차이는 작아 보이지만, 실제로는 작업 시작까지의 망설임을 줄여줍니다. 특히 평소에 등록해 둔 리포지토리 그룹 사이에서 업무를 전환하는 방식의 사용법에서는 궁합이 좋을 것 같다고 느꼈습니다. 🚀

3. 정형화된 작업은 workflow로 만들어 호출할 수 있다

이 또한 편리하다고 느낀 점입니다.

GitHub Docs의 scheduled workflows에서는 recurring agent tasks를 저장하여 스케줄 실행 또는 수동 실행할 수 있다고 설명되어 있습니다. 저는 여기서 가치를 느낍니다.

정형화된 작업에서는 매번 거의 동일한 프롬프트(prompt)를 쓰고 싶어질 때가 있습니다. 예를 들어,

• 매일 아침 open PR 상태를 확인하여 리뷰 대기 및 CI 실패 사항을 정리하기
• 의존성 업데이트 후보를 보고 영향 범위를 대략적으로 요약하기
• 리포지토리의 issue를 분류하여 다음에 착수하기 쉬운 것을 골라내기

와 같은 작업들입니다.

이럴 때 매번 프롬프트를 다시 입력하는 것보다, workflow로 저장해 둘 수 있으면 편합니다. 예를 들어 다음과 같은 요청입니다.

이 리포지토리의 open pull request를 확인하고,
리뷰 대기, CI 실패, merge conflict 여부를 정리해 주세요.
각각에 대해 다음 액션을 한 줄씩 제안해 주세요.

단순히 입력의 수고가 줄어드는 것만이 아닙니다. 프롬프트 그 자체를 고정 자산으로 만들 수 있다는 점이 좋은 점입니다.

한 번 좋은 형태로 다듬은 요청을 workflow 이름과 함께 저장해 두면, 출력의 입도(granularity)도 흔들리지 않게 됩니다. 개인적으로 이것은 "편리한 단축키"라기보다, 정형 작업의 품질을 통일하는 메커니즘에 가깝다고 느끼고 있습니다. 🔁

4. 일본어 입력 중 커서가 튀는 현상을 신경 쓰지 않아도 되었다

이것은 완전히 저의 경험에 기반한 이야기입니다.

GitHub Copilot CLI를 콘솔에서 사용하고 있으면, 일본어 입력 시마다 커서가 의도하지 않은 위치로 튀어 버립니다. 일본어로 조금 긴 프롬프트를 작성하고 있으면, 그때마다 사고의 흐름이 끊겨 버립니다.

이는 제 환경에서 항상 발생합니다. **"이제부터 작업을 의뢰한다"**는 바로 입구에서 입력 경험이 불안정하기 때문에, 작더라도 확실하게 스트레스가 됩니다.

GitHub Copilot app은 데스크톱 앱이므로, 적어도 제 환경에서는 이러한 종류의 걸림돌을 거의 느끼지 못했습니다. 프롬프트 창에서 그대로 일본어를 쓰고, 표현을 조금 다듬어서 보내는 흐름이 자연스럽습니다.

에이전트(agent) 계열의 도구에서는 첫 번째 요청의 질이 중요합니다. 그렇기에 입력 그 자체에 불필요한 신경을 쓰지 않아도 된다는 것은 겉보기보다 훨씬 크다고 느끼고 있습니다. ⌨️

상용 도구로서 app을 여는 일이 늘었다

지금까지 app의 장점을 중심으로 써왔지만, CLI를 사용하지 않게 된 것은 아닙니다.

다만, 지금 제 감각으로는 가장 먼저 여는 도구로서 GitHub Copilot app을 선택하는 일이 늘고 있습니다. 대략적으로 정리하자면 다음과 같이 구분하여 사용하고 있습니다.

상황	어느 쪽을 먼저 열고 싶은가	이유
🌞 그날의 작업을 정리하며 시작하고 싶을 때	GitHub Copilot app	repository / session / workflow를 한 곳에서 훑어보기 쉬움
...

즉, 저에게 GitHub Copilot app은 상용의 입구로서 선택하기 쉬운 도구로 보이게 되었습니다. CLI의 가치가 사라진 것은 아니지만, 지금은 일상의 기점은 app, CLI는 필요한 상황에서 사용하는 도구라는 모습으로 조금씩 바뀌고 있습니다.

마치며

GitHub Copilot app을 사용해 보며 제가 처음에 "좋다"고 느낀 점은, 화려한 기능보다는 오히려 다음의 4가지 점이었습니다.

• 여러 리포지토리(repository)를 동시에 다뤄도 어지러워지지 않는다
• 입구가 디렉터리(directory)가 아니라 리포지토리(repository) / 세션(session)이 된다
• 정형화된 작업을 워크플로(workflow)로 만들어 고정할 수 있다
• 일본어 입력 시의 걸림을 신경 쓰지 않아도 된다

모두 하나씩 보면 작은 차이일지도 모릅니다.

하지만 일상적인 작업에서는 이러한 작은 마찰(friction)이 쌓이게 됩니다. GitHub Copilot app은 그 마찰을 줄여서 작업에 들어가기 전까지와 여러 작업을 처리할 때를 정돈하기 쉽게 만들어준다고 느꼈습니다.

CLI를 선호하는 사람일수록 이 차이를 더 쉽게 체감할지도 모릅니다. 만약 평소 GitHub Copilot CLI를 사용하면서 여러 콘솔(console)의 정리나 정형화된 프롬프트(prompt) 처리, 실행 위치에 대한 고민이 조금이라도 있었다면, GitHub Copilot app도 시도해 볼 가치가 있을 것입니다.

적어도 지금까지 사용해 온 범위 내에서는, 상용 도구로서 GitHub Copilot app을 여는 상황이 늘어나고 있습니다. 🧭

참고 링크

• GitHub Copilot app is now available in technical preview - GitHub Changelog
• About the GitHub Copilot app - GitHub Docs
• Getting started with the GitHub Copilot app - GitHub Docs
• Working with agent sessions in the GitHub Copilot app - GitHub Docs
• Using scheduled workflows in the GitHub Copilot app - GitHub Docs