Kurashiru 사에서 Android 엔지니어를 하고 있는 kenzo입니다.

앱을 개발하다 보면, 방침을 정한 규모가 큰 리팩터링 (Refactoring)을 화면마다 적용하여 코드 전체로 넓혀가는 작업이나, lint 및 detekt의 정적 체크 (Static Check)에서 나오는 수정 등, 반복적으로 수행하고 싶은 작업들이 있습니다. 대상은 달라도 할 일은 정해져 있고, 판단의 여지는 작으며 절차도 정해져 있습니다. 지금까지는 직접 실행하거나, 스킬을 사용하여 수정하고 PR을 작성해 왔지만, 집중해야 할 것은 작업 그 자체보다 그 변경이 문제 없는지 확인하는 것이었습니다.

그래서 브랜치를 생성하여 commit하고 PR을 만드는 단계까지는 자동화에 맡기고, 그 이후를 사람이 수행하는 형태로 만들었습니다.

수정을 PR로 만드는 공통 메커니즘

이 메커니즘에서는 수정과 PR 생성을 분리했습니다. 수정 측에서는 코드 변경을 수행하고 전달용 파일 하나를 생성합니다. 이 파일에 PR의 제목, 브랜치 이름의 접두사, 라벨, 담당자 등의 메타 정보와 PR 본문을 작성해 둡니다. 나머지는 브랜치를 생성하여 commit하고, push하여 PR 생성까지를 공통 스크립트(gh CLI 기반의 shell)가 수행합니다.

수정과 PR 생성이 분리되어 있기 때문에, 수정 방법은 묻지 않고 이 메커니즘을 사용할 수 있습니다. 결정적인 툴로 만든 변경이든, AI가 만든 변경이든, 전달용 파일을 생성하기만 하면 OK입니다. 새로운 자동화는 '변경을 만드는 단계' 부분을 만들면 동작합니다.

스케줄이나 동시 실행도 CI 측에서 설정할 수 있기 때문에, 팀에서 평소 이용하고 있는 GitHub Actions에서 실행하고 있습니다.

이 '변경을 만드는 단계'를 교체할 수 있는 덕분에, 서두에 언급한 리팩터링이나 정적 체크 수정에 더해, 문서 표기의 노후화 체크 등 다루는 대상과 판단의 무게가 다른 수정들도 하나의 동일한 메커니즘으로 동작시키고 있습니다.

확인 작업을 가볍게 만들기

PR이 생성되어도 확인에 시간이 걸리면 방치되기 쉽습니다. 과거에 라이브러리 버전 업그레이드 PR이 대응되지 않은 채 늘어가는 상황을 몇 번이나 목격했습니다. 그래서 사람이 확인하기 위해 필요한 것들을 자동화 측에서 미리 준비하도록 했습니다.

• 봐야 할 관점을 적어두기: 차이점(diff)으로부터 리뷰 관점과 동작 확인 체크리스트를 PR 본문에 생성합니다 (리팩터링 이관 시에는 대상에 맞춰 생성).
• 동작하는 결과물을 자동으로 배포하기: 변경 후의 debug 빌드를 자동으로 배포하여, 확인하는 사람이 즉시 실기기에서 만져볼 수 있도록 하고 있습니다. 수동으로 내려받아 빌드하고 실행하는 것은 의외로 번거로운 일입니다.
• 확인 가능한 속도로 한 건씩 진행하기: 완료해야 할 대상이 많은 이관 작업에서는, 남아 있는 대상 목록을 메커니즘 외부에 두고 '미대응' 항목을 한 건씩 선택하여 진행하며, 차이점이 없으면 자동으로 되돌립니다. 한꺼번에 대량의 PR을 만들지 않고, 확인 가능한 속도로 진행합니다. 목록을 두는 곳은 '미대응·대응 중 상태를 가질 수 있고, 한 건씩 꺼낼 수 있는' 것이라면 무엇이든 상관없습니다.
• 담당자를 정해 멘션하기: Draft 상태로 생성한 후 담당자를 한 명 할당하고, Slack으로 해당 인원에게 개인 멘션을 보냅니다. '누군가 하겠지'라며 흘려보내는 것을 방지하고, 확인 요청이 한 사람의 손에 확실히 전달되게 합니다.

할당받는 입장에서는 메인 태스크 외에 별도의 태스크가 끼어드는 것이 됩니다. 따라서 확인에 필요한 것들은 자동화 측에서 미리 준비하여, 사람의 손에 남는 수고를 최소화하고 있습니다.

안전성에 대하여

이 메커니즘 자체가 AI를 통한 수정을 전제로 한 것은 아니지만, AI에게 변경을 만들게 하는 것은 상정하고 있었습니다. 사람이 지켜보는 단발성 실행이라면 AI에게 맡겨서 문제가 생겨도 즉시 알아차릴 수 있지만, 무인으로 반복해서 자동 실행하게 되면 이야기가 달라집니다.

그래서 AI에게는 파일의 편집과 읽기 권한만 허용하고, commit, push, PR 생성, 명령 실행 등은 하지 못하도록 했습니다. AI의 턴(turn) 안에 실행 수단을 두지 않음으로써, 설령 외부 입력에 섞인 지시로 유도되더라도 작업(job) 내에서 임의의 코드가 실행되지 않도록 하고 있습니다. 편집과 읽기로 한정하면 AI가 만든 변경은 PR 형태가 되어, 인간의 리뷰와 머지(merge)를 거친 후에 반영됩니다.

이것으로 완전히 안전해지는 것은 아닙니다. 리뷰 전에 동작하는 프로세스는 남아 있으며, 편집을 허용하는 이상 막아야 할 구멍은 다른 곳에도 있습니다. 별도의 기사로 작성하였으니 자세한 내용은 해당 기사를 참조해 주세요.

마치며

이 방식을 도입한 이후, 정체되기 쉬웠던 이관 작업이 조금씩 움직이기 시작했습니다. 이전에는 사람이 시작할 때의 번거로움이 커서 뒤로 미뤄지기 일쑤였지만, 지금은 한 건씩 PR이 생성되므로 확인하고 머지하기만 하면 됩니다. 이 메커니즘으로 만든 PR도 여러 건 머지되었습니다.

수정과 PR 생성을 분리함으로써, 변경 사항을 만드는 방식을 교체하는 것만으로 새로운 자동화를 적용할 수 있게 되었으며, 이는 뒤로 미뤄지기 쉬운 개선 사항들을 앞으로 나아가게 하기 위한 토대가 되었습니다.

Discussion