플러그인이지 목적지가 아니다

Baidu Comate는 Baidu 자체 언어 모델을 토대로 한 AI 코딩 어시스턴트이고, 공개된 오픈 소스 코드뿐 아니라 회사가 오래 쌓아 온 실제 개발 작업에 관한 데이터로도 훈련되었습니다. 결정적인 것은 전달 방식입니다. 사람들이 이미 쓰고 있는 통합 개발 환경, 즉 Visual Studio Code, IntelliJ IDEA, PyCharm, GoLand, WebStorm, CLion, PhpStorm, Android Studio 등에 플러그인으로 들어가며, 자체 편집기를 품은 별도 응용 프로그램이 되지 않습니다.

이 선택은 겉모양의 문제가 아닙니다. 코딩 어시스턴트는 코드가 쓰이고 있는 맥락을 볼 때만 쓸모가 있고, 별도 편집기는 모든 것을 처음부터 설명받아야 합니다. 기존 환경 안에 살면 열려 있는 파일, 프로젝트 구조, 커서 위치를 그대로 물려받고, 개발자는 자신의 단축키와 디버깅 설정, 습관을 놓지 않아도 됩니다.

완성과 생성은 서로 다른 약속이다

이런 도구가 할 수 있는 일은 두 가지이고 자주 혼동됩니다. 완성은 다음 토큰, 줄의 나머지, 방금 연 블록의 몸체를 제안합니다. 이미 쓰고 있는 것의 연속이고, 값은 가까운 미래를 맞히는 데서 나옵니다. 생성은 설명에서 함수 전체를 만들어 내고, 값은 의도를 제대로 이해하는 데서 나옵니다.

둘 다 같은 원리, 즉 문맥 창 위에서의 예측에 기대고, 같은 실패를 공유합니다. 모델은 존재하지 않는 것에 대해서도 유창합니다. 반쯤 기억하는 라이브러리의 메서드 이름을 지어내는 완성은 완성이 없는 것보다 나쁩니다. 읽는 데 주의력을 쓰고 시험하는 데 시간을 쓰기 때문입니다. 이런 도구를 값어치 있게 만드는 습관은 제안을 더 많이 받아들이는 것이 아니라, 제대로 읽는 것입니다.

주석을 먼저 쓰기

주석에서 코드를 생성하는 것은 요술처럼 들리지만, 실은 이런 모델을 쓰는 가장 규율 있는 방법일 것입니다. 함수가 무엇을 해야 하는지, 무엇을 받고 무엇을 돌려주는지 적은 주석은 작은 명세서입니다. 먼저 쓰면 평소 건너뛰던 사고를 강제하게 되고, 생성된 본체는 위 문장과 대조해 볼 수 있는 초안이 됩니다.

두 번째 이점은 놓치기 쉽습니다. 명세가 남습니다. 나중에 읽는 사람은 의도를 설명하는 그 문장을 받습니다. 우연히 그것을 구현한 코드만이 아니라. 본체를 사람이 썼는지 모델이 제안했는지는 위 문장이 참인지보다 훨씬 덜 중요합니다.

단위 테스트는 생성의 최선의 표적

이 부류의 도구가 내놓는 것 중 테스트가 가장 변호하기 쉽습니다. 이유는 기술적이지 않고 구조적입니다. 테스트는 실행 가능하고 판결이 있습니다. 제안된 함수는 그럴듯하면서 틀려도 한 달 동안 아무도 모르지만, 제안된 테스트는 초록이 되거나 아니거나 둘 중 하나이고, 어느 쪽이든 몇 초 만에 무언가를 배웁니다.

한 함수에도, 모듈 전체에 묶음으로도 테스트를 생성할 수 있다는 것은 만성적으로 건너뛰는 작업의 경제를 바꿉니다. 테스트는 마감 압박에서 가장 먼저 떨어지는 항목입니다. 번거롭고, 그 부재는 훨씬 나중에야 보이기 때문입니다. 첫 초안을 내놓는 도구는, 뻔한 경우와 경계, 일부러 까다로운 입력 한두 개를 담아, 한 시간의 고역을 십 분의 검토와 보강으로 바꿉니다. 검토는 선택이 아닙니다. 생성된 테스트는 있어야 할 동작이 아니라 지금의 동작을 검증하기 쉽고, 그것은 버그가 존재하는 순간 버그에 대한 설명이 됩니다.

리팩터링 제안과 동등성이라는 난제

이 도구는 업계에서 말하는 나쁜 냄새, 즉 너무 길어진 함수나 평평하게 펼 수 있는 중첩 조건을 찾아 재구성을 제안합니다. 예를 들어 긴 함수를 이름이 분명한 여러 개로 나누는 것입니다. 문제의 모양을 보는 방법으로서 이것은 정말 유용합니다. 긴 함수가 읽기 어려운 것은 바로 그 부분에 이름이 없기 때문입니다.

위험은 분명히 적어야 합니다. 리팩터링은 동작이 변하지 않을 때만 옳고, 모델은 그것을 보장할 방법이 없습니다. 읽기는 아름답지만 경계 조건을 미묘하게 바꾸는 코드를 만들 수 있습니다. 특히 오류 처리, 널 값, 부수 효과가 일어나는 순서 주변에서. 그래서 실제로 통하는 조합은 리팩터링과 테스트입니다. 크게 실패하는 테스트 묶음이 있으면 재구성은 몇 초 만에 검증할 수 있는 제안이 되고, 없으면 정리인 척하는 다시 쓰기입니다.

코드를 읽는 일은 작업의 나머지 절반

함수를 전체로 또는 선택 범위로 설명하게 하는 것은 쉽게 과소평가되는 비용에 답합니다. 다른 사람이 쓴, 혹은 반년 전 내가 쓴 코드를 이해하는 일입니다. 설명은 프로그램에 대한 진실이 아니라 그것에 대한 가설이고, 진실은 프로그램 쪽에 있습니다. 다만 일상 언어로 쓰인 가설은 어디를 볼지 정하기 전에 사람이 필요로 하는 바로 그것입니다.

기술 질의응답도 같습니다. 오류 메시지나 API에 대해 물으면 곧바로 읽을 수 있는 것이 돌아오고, 검색하고 탭 네 개를 열어 답을 재구성하던 예전의 고리보다 낫습니다. 조심은 그대로입니다. 라이브러리 동작에 대한 답은 가장 자신 있게 틀리는 종류의 답이고, 문서가 여전히 권위입니다.

언어의 폭은 실무의 문제다

백 가지를 훨씬 넘는 언어 지원은 광고 문구가 아닙니다. 백엔드의 C, C++, Java, Python, Go, PHP에서 Rust까지, 프런트엔드의 HTML, JavaScript, CSS에서 각종 스타일시트와 템플릿 방언까지, 모바일의 Objective-C, Kotlin, Swift까지. 대부분의 실제 프로젝트는 단일 언어가 아닙니다. 저장소에는 응용 프로그램, 빌드 스크립트, 설정, 데이터베이스 마이그레이션, 문서가 네다섯 가지 서로 다른 문법으로 들어 있습니다. 그중 하나만 말하는 어시스턴트는 자꾸 사라지는 어시스턴트입니다.

정직한 단서는 폭과 깊이가 서로 경쟁한다는 점입니다. 가장 널리 쓰이는 언어에서 성능이 가장 좋은 것은 그곳의 훈련 데이터가 가장 빽빽하기 때문이고, 드문 방언에서의 제안은 Java에서의 제안보다 더 의심하며 읽어야 합니다.

어디에 맞고, 무엇을 고치지 않는가

이 도구가 다루는 것은 소프트웨어를 쓰는 일의 기계적인 부분입니다. 첫 초안 만들기, 상용구 채우기, 아무도 쓰고 싶지 않은 테스트 쓰기, 낯선 것 설명하기. 프로그램이 무엇을 해야 하는지는 정하지 않고, 내놓은 것에 대한 책임도 지지 않습니다. 두 가지 결과가 따릅니다. 내놓는 모든 것은 낯선 사람이 쓴 것처럼 검토해야 합니다. 실제로 낯선 사람이 썼으니까. 그리고 모델에서 온 코드는 동료의 코드가 좀처럼 받지 않는 질문을 받을 값이 있습니다. 이것은 어디서 왔고, 어떤 라이선스를 지녔는가. 출처를 따지는 조직에서 반드시 문제가 되고, 그것은 어시스턴트가 대신 답할 수 없는 유일한 것입니다.