소프트웨어를 사서 쓰던 사람에게, 소프트웨어 회사가 “필요한 앱을 직접 만들어 쓰라”고 권하기 시작했습니다. Microsoft Copilot의 Code 이야기입니다. 매달 구독료를 내던 입장에서는 솔깃합니다. 나에게 필요한 기능만 만들 수 있다면, 여러 기능이 묶인 큰 프로그램을 계속 살 이유가 줄어들까요?
여기에는 흥미로운 반전이 있습니다. 앱을 만드는 문턱이 낮아져도, 그 앱을 고치고 실행하고 관리하는 일에는 여전히 비용이 붙을 수 있습니다. Microsoft 역시 Code를 사용량 기반 과금 대상에 포함했습니다. 소프트웨어 비용이 사라지는지, 다른 곳으로 옮겨 가는지를 구별해야 하는 이유입니다.
컵을 파는 작은 공방으로 이 변화를 따라가 보겠습니다. 필요한 것은 거창한 회사 시스템이 아닙니다. 수량과 단가를 넣고 할인·배송비를 더해 고객 견적을 만드는 작은 계산기입니다. 이 정도라면 직접 만들어도 될 것 같지만, 첫 화면이 나타난 다음부터 선택이 갈립니다.
Copilot이 제안하는 새로운 업무 단위
Microsoft는 9월 25일 Copilot 개편 발표에서 Home·Code·Autopilot을 소개했습니다. 이 중 Code는 필요한 앱, 현황판, 추적 도구, 자동화 작업을 자연어로 설명하면 만드는 기능입니다. 회사가 강조한 대상은 목적이 좁은 작은 업무 도구입니다.
발표에는 혼자 쓰는 데스크톱 도구뿐 아니라 팀에 공유하는 내부 앱도 등장합니다. Microsoft는 이를 실행할 기반으로 조직의 Microsoft 365 환경 안에서 작동하는 Copilot Managed Runtime도 소개했습니다. ‘누구나 앱을 만든다’는 말 뒤에는 만들어진 프로그램을 어디서 실행하고 누가 관리할 것인가라는 문제가 함께 놓여 있습니다.
기존 소프트웨어가 여러 고객이 공통으로 쓸 기능을 묶어 제공했다면, 작은 맞춤 앱은 한 사람의 반복 작업에 범위를 맞출 수 있습니다. 이것이 이 발표에서 주목할 변화입니다. 화면을 만드는 속도가 빨라질수록, 내가 정확히 어떤 작업을 줄이려는지 설명하는 능력이 중요해집니다.
댓글은 기능보다 “라이선스 몇 개?”를 물었습니다
Copilot 개편을 소개한 Reddit 게시글에서 Syren6는 Autopilot과 Cowork, Code와 GitHub Copilot의 차이를 물었습니다. 이어 LightningMcLovin은 여러 제품명을 늘어놓으며 라이선스가 도대체 몇 개나 필요한지 꼬집었습니다. 새 기능이 늘었다는 소식에 구매 목록부터 걱정하는 반응이 붙은 셈입니다. 기능 구분을 묻는 댓글, 라이선스를 꼬집은 댓글
이 댓글에 열거된 제품을 실제로 모두 구매해야 한다는 뜻은 아닙니다. 불만 섞인 농담과 공식 구매 조건은 다릅니다. 다만 “무엇을 할 수 있나”를 소개하는 발표와 “우리 팀은 무엇을 추가로 사야 하나”를 묻는 사용자의 관점 차이는 잘 드러납니다.
Microsoft의 공식 설명에서 Code는 GitHub Copilot과 기반 기술을 공유하면서, 업무용 앱을 자연어로 만들도록 제시된 경험입니다. 이름이 닮았다는 이유로 두 제품의 사용 한도나 계약 조건까지 같다고 추정할 수는 없습니다. 도입 여부를 판단할 때에는 내 계정에 열려 있는 기능, 필요한 실행 환경, 추가 과금 범위를 해당 조건으로 확인해야 합니다. 공식 발표의 Code 설명
같은 댓글 묶음에는 사용자가 이해하지 못하는 오류를 가진 앱이 수없이 생길 수 있다는 우려도 나옵니다. 실제 장애 통계가 아니라 앞으로의 위험을 걱정하는 의견입니다. 이 우려를 공방의 언어로 바꾸면 훨씬 구체적입니다. “계산기는 잘 생겼는데, 할인 규칙이 틀렸다는 건 누가 알아차릴까?”
Windows에서 실행한다는 말의 범위
10월 7일 Windows 발표는 여기에 로컬 모델과 PC의 작업 맥락을 연결하는 방향을 더했습니다. Code에서 요청 하나로 Windows 앱을 만들고, 적절한 작업에 PC에서 실행되는 모델을 활용한다는 구상입니다. 로컬과 클라우드를 함께 쓰므로 모든 처리가 PC 안에서 끝난다는 뜻은 아닙니다.
제공 시점도 나눠 읽어야 합니다. 9월 발표는 Code의 Frontier 배포 계획과 개인 구독자의 연내 미리보기를 안내했고, 10월 발표는 Copilot+ PC의 하이브리드 기능을 향후 수개월에 걸쳐 제공한다고 설명했습니다. 발표문만으로 한국의 모든 계정과 기존 Windows PC에서 즉시 쓸 수 있다고 단정할 수는 없습니다.
Microsoft는 AI 에이전트가 사용할 파일·네트워크·명령의 범위를 정책으로 제한하는 Microsoft Execution Containers(MXC)도 소개했습니다. 실행 범위를 제한하는 장치는 필요하지만, 그 안에서 만든 계산식까지 자동으로 옳게 만들어 주지는 않습니다. 프로그램을 안전한 장소에서 실행하는 문제와 업무 결과가 맞는지 확인하는 문제는 따로 남습니다.
멀쩡하게 돌아가는 계산기가 300원을 틀린다면
다시 공방으로 돌아와 보겠습니다. 다음과 같은 요청을 AI에게 했다고 가정합니다.
컵 수량과 단가를 넣으면 견적을 계산해 주세요. 10개 이상이면 10% 할인하고 배송비를 더해 주세요.
겉보기에는 구체적이지만 할인 대상이 빠져 있습니다. 상품 금액만 할인할까요, 배송비까지 포함한 총액을 할인할까요? AI가 계산을 하지 못하는 문제와, 사람이 정하지 않은 규칙을 AI가 채워 넣는 문제는 구별해야 합니다.
가상의 단가를 1만 원, 수량을 10개, 배송비를 3천 원이라고 정해 보겠습니다. 상품 금액 10만 원에만 10% 할인을 적용한 뒤 배송비를 더하면 9만 3천 원입니다. 배송비까지 더한 10만 3천 원 전체를 할인하면 9만 2,700원이 됩니다. 버튼도 잘 눌리고 결과도 그럴듯하지만, 공방이 정한 규칙에 따라 둘 중 하나는 틀린 견적입니다. 세금과 추가 비용은 이 예시에서 제외했습니다.
이때 필요한 수정은 “더 정확하게 만들어 줘”보다 구체적이어야 합니다. “10개 이상일 때 상품 금액에만 10%를 할인하고, 배송비 3천 원은 마지막에 더해 줘”라고 규칙을 정할 수 있습니다. 이어서 9개와 10개, 수량을 비워 둔 경우와 음수를 넣은 경우를 확인합니다. 일반적인 입력 하나가 맞았다는 것과 경계에서도 올바르게 동작한다는 것은 다릅니다.
이 차이는 300원이라 사소해 보입니다. 하지만 이 예시의 핵심은 손해액이 아니라 오류가 보이는 방식입니다. 화면이 멈추거나 오류 메시지가 뜨지 않아도 업무 규칙은 틀릴 수 있습니다. “잘 실행된다”는 감상만으로 검수가 끝나지 않는 이유입니다.
요청을 고친 뒤에는 정답이 있는 작은 주문 묶음을 남겨 두면 좋습니다. 이 예시에서 9개 주문은 할인이 없어 배송비 포함 9만 3천 원, 10개는 할인 후 같은 9만 3천 원, 11개는 10만 2천 원이어야 합니다. 9개와 10개의 총액이 같다는 뜻밖의 결과도 규칙상 맞습니다. 나중에 할인율이나 배송비를 바꾸면 이 기대값도 함께 바꿔야 합니다.
수량을 비우거나 음수를 넣었을 때는 그럴듯한 금액을 내기보다 입력을 고치도록 안내해야 합니다. 이렇게 정상 주문과 경계·잘못된 입력을 함께 보면, AI가 만들어 준 기능을 업무의 언어로 검토할 수 있습니다. 개발자가 아니어도 내가 정한 판매 조건의 정답은 확인할 수 있습니다.
이 가상 사례의 확인 기준은 어떤 생성 도구를 선택하든 적용할 수 있습니다. 프로그램의 첫 화면보다 내가 손으로 답을 구할 수 있는 예시와 일치하는지가 더 좋은 출발점입니다.
저장과 공유를 붙이면 책임도 커집니다
혼자 쓰는 계산기는 입력을 바꿔 다시 계산하면 그만일 수 있습니다. 그런데 고객별 견적을 저장하고 직원과 공유하기 시작하면 질문이 달라집니다. 창을 닫았다 다시 열어도 견적이 남는지, 다른 직원이 값을 바꾸면 누구의 수정이 남는지, 실수로 지운 자료를 복구할 수 있는지 확인해야 합니다.
앱을 만드는 비용이 줄어도 이 질문들이 사라지지는 않습니다. 고객 주소를 저장하면 접근 범위를 관리해야 하고, 자동 발송을 붙이면 잘못된 견적이 나가지 않도록 확인 단계가 필요합니다. 실제로 어떤 저장·공유·복구 기능을 제공하는지는 선택한 실행 환경과 설정에 달려 있습니다. 화면에 ‘저장’ 버튼이 있다는 이유만으로 백업까지 갖췄다고 생각해서는 안 됩니다.
비용도 같은 방식으로 봐야 합니다. Microsoft의 9월 발표에서 안내한 과금 방식은 Code를 사용량 기반 과금 대상에 포함합니다. 로컬 모델이 일부 작업을 맡을 수 있다는 10월 발표가 구독, 클라우드 사용, 공유 앱의 운영 비용까지 모두 없앤다는 뜻은 아닙니다. 비교할 것은 기존 구독료와 생성 비용 하나가 아니라, 검수·운영까지 포함해 감당할 수 있는 부담입니다.
“이것도 하나만”이 쌓이면 작은 앱이 아닙니다
첫날에는 계산만 하던 도구에 “고객 이름도 저장해 줘”가 붙습니다. 다음에는 “직원도 같이 쓰게 해 줘”, 그다음에는 “견적을 자동으로 보내 줘”가 이어집니다. 하나씩 보면 작은 추가 기능이지만, 끝에는 고객정보·공유·외부 발송을 다루는 업무 시스템이 남습니다. 앞서 공방이 원했던 ‘잠깐 쓰는 계산기’와 운영 부담이 달라집니다.
가령 직원 둘이 같은 견적을 열었다고 합시다. 한 명은 수량을 고치고 다른 한 명은 단가를 고쳤는데 마지막 저장만 남는다면 어느 값이 맞는지 알아야 합니다. 이 장면은 Copilot의 특정 결함을 주장하는 사례가 아닙니다. 공유 앱을 선택할 때 변경 충돌과 이력을 확인해야 하는 이유를 보여 주는 가정입니다.
여기서 편리한 기준은 “AI가 더 만들 수 있나”보다 “문제가 생겼을 때 누가 원상태로 돌릴 수 있나”입니다. 담당자가 휴가일 때도 다른 사람이 데이터를 꺼낼 수 있는지, 수정 전 버전으로 돌아갈 수 있는지, 사용을 중단할 때 자료를 옮길 수 있는지 따져 봅니다. 좋은 시제품과 오래 맡겨 둘 도구를 나누는 차이가 여기에 있습니다.
돈을 아끼려는 계산에도 사람의 시간을 넣어야 합니다. 앱을 생성하는 비용만 낮고 매주 오류를 찾아 고쳐야 한다면 기대한 절약이 줄어듭니다. 반대로 입력이 제한되고 결과를 금방 확인할 수 있는 개인 도구라면 작은 유지 부담으로도 충분한 효용을 얻을 수 있습니다. 모든 업무가 같은 수준의 운영 장치를 필요로 하지는 않습니다.
만들기, 보완하기, 구매하기의 선택 기준
공방의 요구가 ‘수량에 따라 견적 한 번 계산하기’에 머문다면 작은 맞춤 도구를 검토할 만합니다. 다만 같은 일을 기존 스프레드시트의 수식과 입력 칸으로 충분히 해결한다면, 새 앱을 유지할 이유는 약해집니다. AI로 만들 수 있다는 사실과 따로 만들어야 한다는 판단은 같지 않습니다.
고객·재고·결제를 함께 관리하고 여러 사람이 매일 사용하는 핵심 업무라면, 기능뿐 아니라 권한 관리·복구·지원 체계를 비교해야 합니다. 잘 갖춰진 기존 제품을 구매하거나 기존 시스템을 보완하는 쪽이 유리할 수 있습니다. 상용 제품이라고 자동으로 적합한 것도 아니므로 실제 제공 범위와 계약 조건은 확인해야 합니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 작게 만들기 | 범위가 좁고 답을 검증할 수 있음 | 사용자와 입력이 제한적이고 실패해도 쉽게 다시 계산하거나 복원할 수 있는 작업입니다. | 고객정보를 저장하지 않는 개인 견적 계산기 |
| 기존 도구 보완 | 이미 쓰는 자료와 흐름이 있음 | 새 저장소를 늘리기보다 기존 문서·표의 입력과 계산을 개선하는 편이 간단할 수 있습니다. | 가격표에 수량 입력 칸과 검증 수식 추가 |
| 구매·전문 구축 | 공유와 운영 책임이 큼 | 접근 권한, 변경 이력, 복구, 장애 지원이 중요하다면 이 기능까지 포함해 비교합니다. | 직원이 함께 쓰는 고객·재고·결제 관리 |
처음 시도할 때는 ‘우리 회사용 프로그램’을 통째로 요청하기보다 완료 기준을 작게 고정하는 편이 좋습니다. 예를 들어 “고객정보를 저장하지 않고, 세 가지 주문의 계산 결과가 맞으며, 결과를 파일로 내보낼 수 있는 도구” 정도입니다. 저장이 꼭 필요하면 다시 열었을 때 유지되는지와 내보낸 자료로 복원할 방법도 함께 확인합니다.
- 규칙을 정하기누가 무엇을 계산하는지, 할인·배송비처럼 해석이 갈릴 조건을 적습니다.
- 정답과 맞추기평범한 주문, 할인 경계, 잘못된 입력을 준비하고 기대 결과와 비교합니다.
- 운영 범위를 정하기저장·공유·외부 전송이 필요한지 확인합니다. 범위를 넓히면 권한과 복구도 다시 검토합니다.
구독료를 없애겠다고 시작한 일이 나만의 유지보수 업무를 하나 더 만드는 결과가 되어서는 곤란합니다. 반대로 매번 하던 단순 계산을 작은 도구 하나로 끝낼 수 있다면, 큰 제품을 계속 살 필요가 있는지 다시 물을 만합니다.
Copilot Code가 넓히려는 선택지는 필요한 기능을 직접 구체화할 수 있다는 데 있습니다. 소프트웨어를 사는 이유가 사라진다기보다, 작은 맞춤 기능을 얻는 비용과 운영을 맡기는 가치가 더 뚜렷하게 나뉠 가능성이 있습니다. 공방의 계산기처럼 범위가 작고 결과를 확인할 수 있는 일부터 시작하면, 무엇을 만들고 무엇을 계속 구매할지 판단하기 쉬워집니다.
VIEW—
