
결론부터 말하면, GitHub Copilot은 새 코드를 많이 쓰는 순간보다 테스트 의도와 실패 조건을 설명할 때 더 빨리 체감될 수 있습니다. 코드 생성보다 우리가 무엇을 검증하려는지 정리하는 데 도움이 됩니다.
먼저 가를 기준
판단 기준은 기능 구현이 막힌 것인지, 검증 케이스 정리가 막힌 것인지입니다. 입력값, 예외상황, 기대 결과가 분명하면 Copilot이 만든 테스트도 훨씬 쓸 만해집니다.
| 상황 | 판정 | 이유 |
|---|---|---|
| 갈래가 여러 개인 경우 | 시간·위치·대상 중 하나를 먼저 고릅니다 | 기준이 없으면 화면을 따라가도 마지막에 다시 갈립니다 |
| 이름이 비슷한 절차가 있는 경우 | 목적에 맞는 항목을 고릅니다 | 이름이 비슷해도 쓰임새가 다르면 대체가 안 됩니다 |
| 결과가 예상과 다른 경우 | 처음 입력한 조건부터 되짚습니다 | 대부분의 오류는 첫 조건 선택에서 생깁니다 |
| 순서 | 볼 것 | 판단 |
|---|---|---|
| 먼저 닫을 것 | 내 상황을 가르는 기준 하나 | |
| 다음에 볼 것 | 공식 화면에서 요구하는 입력값 | |
| 마지막 판단 | 다시 돌아오지 않게 남길 기록 |
실제로 갈리는 부분
실제로 갈리는 부분은 Copilot을 자동 코더로만 보는 경우입니다. 구현 코드는 맥락을 놓칠 수 있지만 테스트 설명과 반복 패턴 생성에서는 사람이 빠뜨린 케이스를 떠올리는 데 도움이 됩니다.
마치며
저는 Copilot의 진짜 가치는 코드를 대신 쓰는 양보다 우리가 확인해야 할 조건을 더 빨리 펼쳐 주는 데 있다고 봅니다. 테스트 기준을 먼저 닫으면 코드 품질도 같이 올라갑니다.











댓글 남기기