앱이 4개로 늘어나자 버그 보고를 한곳에 모아 AI로 병렬 처리하게 된 이야기

사용자가 있는 앱이 4개가 되면서, 버그 보고를 한 곳에 모았습니다. 모아보니 처음 알게 된 것은, 보고의 심각도가 4개 앱에서 각각 다른 기준으로 부여되어 있었다는 점입니다. 기준을 통일하여 한 화면에 나열하자, 여러 Claude에게 전달하여 보고된 버그를 하루 만에 처리할 수 있게 되었습니다. 상용 앱을 여러 개 운영하면 운영상의 수고가 이 부분에 집중된다는 이야기를 쓰고자 합니다.

제가 현재 사용자를 보유한 앱은 4개가 있습니다. 음성을 실시간으로 번역하는 LiveTR, 화면을 그대로 일본어로 바꾸는 OLTranslator, 영어 리스닝의 Kikoeru, 그리고 제 서버에서 구동되며 길드의 경매를 관리하는 Discord 봇 AuctionBOT입니다. 앱이 늘어날수록 개발 자체보다 '제대로 작동하고 있는지'가 신경 쓰입니다. 실사용자가 있기 때문입니다.

각 앱의 관리용 read API를 BugHub가 약 3분마다 순회하며, 서명(signature)으로 중복을 통합하고, 대시보드와 /ai에 동일한 기준으로 나열하는 전체 그림

관측 가능한 앱과, 관측 불가능한 앱

4개 중 제가 직접 작동 과정을 추적할 수 있는 것은 1개뿐입니다. AuctionBOT은 제 서버에서 구동되는 Discord 봇이므로, 무엇이 일어나고 있는지 어느 정도 스스로 조사할 수 있습니다. 나머지 3개(OLTranslator・LiveTR・Kikoeru)는 사용자의 단말기/환경에서 작동합니다. 저에게 같은 환경이 없거나, 하나의 환경으로는 재현할 수 없는 버그도 있습니다.

그래서 모든 앱에 '품질 향상을 위해 정보를 전송합니다'라는 흔한 안내 문구를 넣었습니다. 사용자 입장에서는 어렴풋이 OK를 누르곤 했습니다. 개발자 입장이 되니 이것이 도움이 된다는 것을 알았습니다. 버그의 상당수는 스스로 발견하는 것이 아니라, 사용자의 환경에서 올라옵니다. 스스로 관측할 수 없는 부분은 사용자 보고로 보완합니다.

보고가 앱마다 다른 곳에 있는 경우

보고 시스템을 모든 앱에 넣었지만, 이번에는 그 보고가 앱마다 다른 장소에 쌓였습니다. 1명 + AI로 4개를 운영하다 보니, 어떤 앱이 몇 건을 안고 있는지 가로로 비교할 수 없습니다. 고치기 전에 현재 어느 앱에 문제가 발생하고 있는지 확인할 곳이 없었습니다.

그래서 통합 시스템을 만들었습니다. 자택 서버에서 구동되는 읽기 전용 내부 컨테이너로, BugHub라고 명명했습니다. 하는 일은 간단합니다. 각 앱이 LAN 내에 내보내는 관리용 읽기 API를 약 3분마다 순회하며, 전부를 하나의 대시보드에 나열하는 것입니다. 앱 측에서는 'LAN 내・Bearer 인증의 읽기 API'만 하나 내보내면 됩니다. 버그를 서명(fingerprint) 단위로 통합하여 반환합니다. 서명은 '어떤 모듈의, 어떤 종류의, 어떤 메시지 템플릿인지'에 대한 해시이며, 가변값은 포함하지 않으므로 같은 원인의 버그는 같은 값이 됩니다. 각 버그에는 심각도・메시지 템플릿(가변값 및 개인정보 마스킹됨)・누적 발생 수・최종 발생 시각・상태(미해결인지 해결되었는지)가 붙습니다.

BugHub 측에서는 이 형태(signature 형태라고 부릅니다)에 맞으면 가져오기는 한 줄입니다.

// 이 형태를 내보내는 앱은, 소스 목록에 1줄 추가만 하면 표시됨
const SOURCES = [
{
name: 

레이블을 통일하고 나면, 다음 과제는 "이 공통 사양을 수정하는 측에 어떻게 전달할 것인가"가 된다. 수정하는 것은 내가 아니라 AI다. 프로젝트마다 별도의 VSCode와 별도의 Claude가 실행되므로, 매번 구두로 사양을 설명한다면 통일한 의미가 없다.

이것도 하나의 페이지로 만들었다. `GET /ai`를 호출하면, AI를 위해 작성된 하나의 Markdown이 반환된다. 내용의 핵심 구성은 다음과 같다.

- 4단계 심각도 기준 (위의 내용)
- 수정 절차: ① 미해결 사항 취득 → ② 해당 앱의 프로젝트 수정 → ③ 운영 환경(Production)에 배포하여 재발 여부 확인 → ④ 확인 완료 후 앱 측에 해결 기록. 해결 기록을 먼저 남기지 않는다. 확신이 없는 것은 건드리지 않는다.
- 이 시점에서의 미해결 목록 (각 항목에 해결 명령 포함)

여기에 더해, 앱별로 "해결 기록을 어디에 남길 것인가"에 대한 테이블과, "새로운 앱을 연동하려면"에 대한 공통 사양도 같은 페이지에 올려두었다.

AI에게 수정을 맡기고 배포까지 위임하는 메커니즘 자체는 이전에 작성했다. 이번에 그 위에 추가한 것은, 여러 앱의 보고를 동일한 기준으로 집약하여 하나의 URL로 전달할 수 있게 만든 부분이다. 다른 앱에 대해 "이것을 BugHub에 집약할 수 있도록 해줘"라고 말하면, AI는 이 페이지의 공통 사양에 따라 앱 측의 API를 구현한다. 새로운 앱의 통합도 동일한 하나의 URL을 전달하는 것만으로 끝난다.

해결 기록은 BugHub가 아니라 앱 측에 기록한다. 앱 측이 정(正)이며, BugHub는 그 상태를 복사하여 표시할 뿐이다. BugHub 측에서 삭제하더라도 다음 순회(巡回) 시 앱 측의 상태로 덮어씌워져 돌아오며, 앱 측에서 재발을 감지하면 자동으로 "미해결" 상태로 돌아간다.

![同じ /ai のURLを複数のVSCode/Claudeに渡し、それぞれが担当アプリを取得→修正→デプロイ→検証→解決記録まで回す。解決はアプリ側に記録する](https://res.cloudinary.com/zenn/image/fetch/s--DnUNItey--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://blog.kitepon.dev/post/bughub/serve.png?_a=BACMTiAE)

*동일한 /ai URL을 여러 개의 VSCode/Claude에 전달하여, 각각이 담당 앱을 취득 → 수정 → 배포 → 검증 → 해결 기록까지 수행한다. 해결은 앱 측에 기록한다.*

## 여러 개의 Claude에게 맡겨 하루 만에 해결했다

이 정도를 갖춘 뒤, 보고된 버그들을 처리하기 시작했다. 여러 개의 VSCode에 각각 Claude를 띄우고, 모두에게 `/ai` URL을 전달하며 "이것을 보고 수정해"라고 지시했다. 동일한 목록을 동일한 기준으로 보고 있으므로, 어떤 Claude라도 미해결 사항을 가져와 자신의 담당 앱을 수정하고, 배포하고, 검증한 뒤, 해결 기록을 남긴다. 이를 병렬로 돌렸더니, 단 하루 만에 한 차례의 작업이 모두 마무리되었다.

순회 컨테이너 안에는 LLM이 없다. 약 3분마다 이루어지는 순회도, 급증이나 신규 발생에 대한 즉시 알림도 순수하게 임계값(Threshold) 규칙에 따라 작동한다. AI가 관여하는 것은 외곽 부분뿐이며, 버그를 수정하는 측과 주 1회 진행하는 Codex 정리뿐이다.

## 지금 가장 손이 많이 가는 부분

개인이 상용 앱을 여러 개 운영하면, 운영의 수고가 이 부분에 집중된다. 신기능을 추가하는 시간보다 올라오는 보고를 처리하는 시간이 더 늘어난다. 만드는 속도에 대한 이야기는 이전에 썼지만, 그 후속 작업으로서 계속 운영하는 측에도 동일한 정리가 필요하다. 그것이 현재의 상황이다.

지금은 4개 분량의 미해결 사항이 동일한 기준으로 한 화면에 나열되어 있으며, URL 하나만 전달하면 AI가 거기서부터 수정하러 간다. 사용자가 이용할 때 막연하게 OK를 눌렀던 "품질 향상을 위해 정보를 전송합니다"는, 개발 측에서는 이런 방식으로 사용되고 있었다.

### Discussion

![](https://static.zenn.studio/images/drawing/discussion.png)