미국 캘리포니아주 멘로파크 — 코딩 어시스턴트는 그럴듯해 보이는 코드를 만드는 데 능숙해졌습니다. 코드를 병합해야 하는 개발자에게 더 어려운 질문은 누군가 그 코드를 검증했느냐는 것입니다. Corepass의 코딩 에이전트 Remy는 일종의 증거 기록으로 이 질문에 답합니다. 실행한 검사, 검사가 실패했을 때 변경한 내용, 그리고 검증하지 않은 부분에 대한 명시적인 설명을 남기는 것입니다.
Remy 제품 페이지에 설명된 이 동작은 정해진 순서를 따릅니다. Remy는 코드를 변경한 뒤 관련 테스트, 타입 검사 또는 빌드를 실행합니다. 실패가 발생하면 원인을 찾아 수정하고, 더 쉬운 다른 검사가 아니라 같은 검사를 다시 실행합니다. 제품 페이지는 마지막 단계를 이렇게 분명히 적고 있습니다. “그런 다음 무엇을 실행했는지, 결과가 어땠는지, 무엇을 검증하지 않았는지 알려 줍니다.”
- 검사 실행테스트, 타입 검사 또는 빌드
- 원인 찾기검사가 실패했을 때
- 수정 후 재실행같은 검사를 다시 실행
- 결과 보고무엇을 실행했는지, 결과, 검증하지 않은 부분
실패한 검사를 그대로 다시 실행
같은 검사가 중요한 이유
핵심은 동일한 검사를 반드시 다시 실행한다는 데 있습니다. 수정 후 다른 테스트를 실행하거나 아무 테스트도 실행하지 않으면, 원래의 실패가 사라졌는지 알 수 없습니다. 실패했던 검사를 다시 실행하면 수정과 그 수정이 효과가 있었다는 증거가 연결되고, 그 증거는 리뷰어가 볼 수 있는 곳에 남습니다.
“그런 다음 무엇을 실행했는지, 결과가 어땠는지, 무엇을 검증하지 않았는지 알려 줍니다.”
검증하지 않은 부분을 밝히기
보고의 마지막 부분은 코딩 도구 가운데 가장 드문 요소일 수 있습니다. Remy의 마무리 노트는 검증된 부분과 검증되지 않은 부분을 구분합니다. 제품 자체 시연에서 작업은 두 개의 목록으로 끝나는데, 하나는 “검증됨”, 다른 하나는 “검증되지 않음”이라는 제목이 붙어 있습니다. 예를 들어 어떤 테스트로도 다루지 않는 코드의 변경은 그냥 넘어가지 않고 검증되지 않은 항목으로 명시됩니다.
병합 전 리뷰
검증은 하나의 단계일 뿐입니다. Remy 문서에는 별도의 코드 리뷰 모드가 설명되어 있는데, 이 모드는 발견 사항을 심각도별로 보고하며 각 항목에 위치, 영향, 근거를 함께 제시합니다. 제품 페이지의 작업 흐름에서는 풀 리퀘스트가 나가기 전에 리뷰 봇 Bugbot이 diff를 읽고 테스트가 놓친 부분을 찾습니다.
Corepass는 제품을 만드는 원칙 중 하나로 “작업을 검토 가능하게 유지하기”를 꼽으며, 검증 보고는 제품에서 이 원칙이 가장 분명하게 드러나는 부분입니다. 검사는 에이전트가 하고, 개발자는 병합 여부를 결정하는 데 필요한 기록을 받습니다.