현재 근무하는 개발 현장에서 GitHub Copilot을 많이 사용하고 있습니다.
특히 결함 분석(버그 파싱)에 GitHub Copilot을 활용하고 있습니다.
어느 정도 자신에게 맞는 좋은 사용법이 정립되어, 메모 형태로 정리해 보았습니다.
그래서,
본 기사에서는 제가 평소 진행하는 '버그 분석 흐름'에 대해 정리합니다.
기본적으로는 '바로 수정하게 하기보다, 사고 과정과 조사에 대한 벽치(대화 상대)로 삼는다'는 입장에서 AI를 사용하고 있습니다.
버그 분석의 기본 플로우
은 대략 다음과 같은 4가지로 분류할 수 있습니다.
조사 범위 좁히기 → 가설 검증 → 수정 및 동작 확인 → 커밋/풀 리퀘스트 작성
좀 더 세부적으로는 구체적으로 다음과 같은 순서로 분석을 진행하는 경우가 많습니다.
버그 재현 절차 및 상황 전달 → 생각해 볼 수 있는 가능성(가설) 제안 요청 → 각 가능성에 대해 분리 검증 → 가장 가능성이 높은 원인에 대한 임시 구현 → 수정 내용의 효과 확인 (테스트/동작 확인) → 변경 코드 정밀 검토 → 커밋/풀 리퀘스트 작성
버그 분석을 시작할 때, 우선 조사 범위 좁히기부터 진행합니다.
이를 위해 다음과 같은 정보를 AI에게 전달하고 있습니다.
재현 절차 → 기대 동작과 실제 동작
workspace에 소스 코드(Git 클론한 디렉터리)나 사양을 넣어두면 편리하다고 알려주었기에, 그것도 실천하고 있습니다.
Git 히스토리 등도 참조해주기 때문에, 솔직히 상당히 편리합니다.
우선 '조사 범위 좁히기'로 범위를 좁힌 후, 관련 파일이나 함수를 제시합니다.
그리고 다시 다음과 같은 두 가지 정보를 전달하여, 원인으로 생각할 수 있는 가설을 3~5개 정도 제안받습니다.
여러 선택지를 제안받음으로써 시야가 좁아지는 것을 막을 수 있다고 느낍니다.
이때, 명백히 엉뚱한 것은 무시하고 있습니다.
Copilot이 제시한 가설에 대해 하나씩 검증을 진행합니다.
기본적으로 의심스러운 곳에 로그를 삽입하여 버그 재현 및 로그 취득을 합니다.
그리고 그 로그를 바탕으로 원인을 분리합니다.
조건 A일 때는 버그 발생 / 조건 B일 때도 버그 발생 / 조건 C일 때는 버그 미발생
👆처럼, 조금씩 조건을 변화시키며 좁혀나가는 경우도 있습니다.
좁혀진 원인에 대해 수정안을 제시받고, 로컬 환경에서 동작 확인을 합니다.
우선 '가설대로 수정한 것이 현상을 해결하는지'의 확인을 최우선으로 하고 있습니다.
여기서 지나치게 파헤쳐서 목적이 모호해지지 않도록 주의하고 있습니다.
불필요한 생각은 하지 않고, 가설에 대한 수정 코드만 넣으려고 합니다.
실제로 변경한 코드를 실행하여 다음을 확인합니다.
- 버그가 발생하지 않는지?
- 관련 기능에 영향은 없는지?
AI가 작성해 준 코드는 제가 직접 리뷰하려고 노력하고 있습니다.
구체적으로는 다음과 같은 점을 의식하며 정밀 검토합니다.
- 변경 스코프의 국소화: 영향 범위를 한정하기 위해 가능한 한
if / case 등의 좁은 스코프에 가두기 - 기존 함수의 재활용: 불필요한 독자 로직을 늘리지 않고, 기존 메커니즘 활용
이 과정을 통해 불필요한 코드 변경을 방지하는 동시에, 자신만의 코드 이해도를 높이는 것도 목표로 합니다.
커밋/PR 작성은 AI가 출력한 것을 수동으로 다시 작성하려고 노력합니다.
이 과정으로 내용의 이해와 지식의 정착을 노립니다.
AI를 사용하는 것도 효율화이지만, 개발자 본인의 지식이나 직관(第六感)을 단련하는 것 또한 효율화로 이어진다고 생각합니다.
버그 조사에서 Copilot을 사용함으로써 벽치 및 조사의 효율화를 실현할 수 있다고 느낍니다.
기본적으로 다음과 같은 방식으로 역할을 분담하는 경우가 많습니다.
- 로그 특정이나 가설 도출 등, 조사의 고속화는 Copilot에 맡기고 - 변경 스코프 한정이나 기존 코드 재활용 등, 코드의 품질 담보는 인간이 담당하기
이 역할 분담을 통해 조사 속도 향상과 코드 품질 양립이라는 의식을 가질 수 있다고 느낍니다.
만들게 하려고 하면 남의 일처럼 느껴지는 것 같습니다.
