이 글은 자동 번역되었습니다. 원문은 여기를 클릭하세요.
Copilot adoption에서 가장 유용한 변화 중 하나는 기능 집착에서 벗어나는 것이라고 생각한다.
바로 그래서 이 새로운 .NET 개발자를 위한 GitHub Copilot 가이드가 잘 작동한다.
핵심 아이디어는 간단하다. 어떤 Copilot mode가 가장 멋진지 묻는 대신, 어떤 surface가 작업에 맞는지 묻기 시작하라는 것이다.
이것이 올바른 mental model이다
대부분의 실제 .NET 작업에서 질문은 다음이 아니다.
- chat 아니면 agent?
- Visual Studio 아니면 CLI?
- inline 아니면 cloud?
더 나은 질문은 다음이다.
- 코드를 이해하려는가?
- refactor를 계획하는가?
- tests를 업데이트하는가?
- 깨진 build를 고치는가?
- 여러 파일에 걸친 변경을 조율하는가?
Copilot을 다루는 훨씬 더 생산적인 방식이다.
원문에서 가장 유용한 문장
원문에서 내가 강조할 문장은 이것이다.
“무엇이 가장 advanced한지가 질문이 아니다. 더 나은 질문은 지금 내가 하고 있는 일에 무엇이 맞는가다.”
그게 바로 내가 줄 조언이기도 하다.
많은 AI tooling 혼란은 surface를 도구가 아니라 정체성처럼 취급할 때 생긴다.
Visual Studio, VS Code, CLI, background agent는 각각 다른 순간에 맞는다.
그걸 받아들이면 전체 경험은 훨씬 더 실용적이 된다.
이것이 특히 .NET 팀에 중요한 이유
.NET 작업은 하루 안에 여러 종류의 task를 다루는 경우가 많다:
- legacy service 이해하기
- refactor 계획하기
- test 생성하기
- 깨진 build 고치기
- code, config, docs, infrastructure를 함께 건드리기
즉, 단 하나의 Copilot surface가 모든 것에 가장 좋을 수는 없다.
그래서 이 가이드의 조언이 좋은 이유는 실제 일이 어떻게 일어나는지를 반영하기 때문이다.
내 생각
이 가이드는 Copilot을 그 위에 얹힌 novelty layer가 아니라 실제 .NET development loop의 일부로 다룬다는 점에서 유용하다.
그래서 relevant하다.
그리고 솔직히 말하면, 더 많은 AI guidance가 이런 task-first thinking으로의 전환을 통해 훨씬 나아질 것이다.
