여러 AI와 함께 일하는 단톡방을 만들었다

지난 글에서는 집에 있는 컴퓨터를 한 화면에서 보고, 스파크가 비면 예약한 일을 돌리는 기능을 정리했다. 이번에는 그 기기와 서비스에서 쓰는 AI들을 한 방에 모았다. 이름은 그냥 단톡방으로 붙였다.

10월 12일 처음 요청한 내용은 이랬다.

즉 자기 프로젝트를 들고 단톡방에 참여할 수 있으면 좋겠다는거야.

같은 클로드라도 사유고를 만들던 대화와 블로그를 쓰던 대화는 알고 있는 내용이 다르다. 새 채팅창마다 프로젝트를 다시 설명하는 대신, 하던 일을 아는 참가자들을 골라 한자리에서 이야기하고 싶었다. 여기에 코덱스, 로컬 큐웬, 딥시크, 그록, Aside를 붙이고 나중에 GLM도 추가했다.

모델과 함께 이어받을 프로젝트 대화도 고른다

참가자는 모델 이름만으로 정하지 않는다. 어떤 실행 도구를 쓸지, 어느 모델인지, 기존 대화를 이어받을지, 방에서 무슨 이름으로 부를지를 함께 고른다. 같은 클로드를 여러 명 넣어도 각자 다른 프로젝트 대화를 이어받을 수 있다. 프로젝트 없이 새 대화로 들어오는 것도 가능하다.

기존 대화를 고르면 기본 설정에서는 복사 세션을 만들어 그쪽에서 대화한다. 단톡방에서 나눈 이야기가 원래 프로젝트 대화에 섞이지 않게 하려는 선택이다. 처음에는 코덱스 대화 파일을 복사해서 쓰려 했지만, 나뉘어 저장된 기록의 참조가 꼬여 실패했다. 공식 세션 분기 기능을 쓰는 쪽으로 바꿨다.

모든 참가자가 같은 방식으로 기억하는 것은 아니다. 클로드·코덱스·그록은 고른 세션을 이어가고, 큐웬·딥시크·GLM·Aside는 호출할 때 방의 최근 대화를 받는다. 큐웬은 어느 기기에서 돌아가는 모델인지도 선택한다. 화면은 하나로 모으고 실행은 각 도구와 모델의 방식에 맞춰 연결했다.

리더가 일을 나누고 작업자의 결과를 다시 받게 했다

처음에는 내가 질문하면 부른 모델들이 답하는 정도였다. 같은 방에 있다고 저절로 서로의 답을 검토하지는 않았다. 그래서 클로드가 코덱스에게 구현을 맡기고, 결과를 보고 다시 수정을 요청하는 흐름을 추가해 달라고 했다.

팀 작업에서는 내가 고른 리더가 요청을 먼저 받는다. 리더는 방에 있는 참가자의 모델, 작업 폴더, 권한을 보고 @이름으로 일을 맡긴다. 작업자들의 응답이 끝나면 결과를 모아 리더에게 돌려준다. 리더는 후속 작업을 맡기거나 내게 보고한다. 방에 참가시키지 않은 모델을 임의로 불러오는 구조는 아니다.

리더를 정해도 화면에 남아 있던 수신자 선택 때문에 모두가 첫 질문에 답한 적이 있었다. 팀 작업의 새 요청은 리더부터 받도록 고쳤다. 작업자는 다른 작업자를 부르지 못하게 하고, 후속 호출 횟수에도 한도를 뒀다.

실제로 코드를 고칠 참가자는 작업 권한을 켠다. 같은 폴더를 여러 참가자가 동시에 고치지 않도록 한 명씩 실행하게 했다. 이 잠금은 단톡방이 실행한 참가자끼리 적용된다. 다른 앱이나 터미널에서 동시에 고치는 작업까지 막는 것은 아니다.

방의 규칙과 기억을 모든 참가자에게 함께 전달했다

프로젝트 대화가 서로 다르다 보니, 방에서 방금 정한 기준을 다음 참가자도 알고 있어야 했다. 10월 13일에는 방마다 ROOM.md와 MEMORY.md를 만들었다.

ROOM.md에는 목적, 범위, 공통 규칙, 완료 기준을 적는다. MEMORY.md에는 결정과 이유, 현재 상태, 다음 작업을 남긴다. 두 문서는 화면에서 직접 읽고 고칠 수 있고, 참가자를 호출할 때마다 최신 버전을 전달한다. 기존 세션을 이어가는 코덱스도 예외가 아니다.

진행 중인 응답은 시작할 때 받은 문서로 계속 일한다. 중간에 규칙을 고쳤다고 이미 실행 중인 모델의 맥락까지 바뀌는 것은 아니다. 바뀐 문서는 다음 호출부터 들어가며, 각 응답에는 어떤 버전을 받았는지 남는다.

참가자가 기억에 추가하라고 보고한 내용에는 작성자와 근거 대화를 붙이고 미검증으로 표시한다. 모델이 적었다는 이유만으로 확정 사실이 되지는 않는다. 실제 확인은 코덱스 Luna와 딥시크 Flash에 문서를 전달하고, 내용을 바꾼 뒤 다시 물어 두 모델이 새 내용을 받았는지 대조했다.

토론은 의견·반론·재답변 순서로 진행하게 했다

팀 작업과 별도로 토론·결정 모드도 만들었다. 질문 하나를 던졌을 때 각자 답을 끝내는 대신, 상대의 주장을 읽고 답을 수정하거나 유지하는 이유까지 말하게 하고 싶었다.

순서는 허브가 정한다. 먼저 각자의 의견을 받고, 다음에는 상대의 실제 발언을 짚어 반론하게 한다. 그 반론에 다시 답한 뒤 정리 담당이 최종 추천안, 합의한 점, 남은 이견, 미확인 사항을 나눠 적는다. 같은 단계의 참가자에게는 동일한 이전 단계 기록을 준다. 먼저 답한 사람의 의견에 나머지가 곧바로 따라붙는 일을 줄이려는 설계다.

실제 확인에는 코덱스 Luna와 딥시크 Flash를 썼다. 개인 메모 앱을 Markdown 파일로 저장할지 SQLite로 저장할지 묻고, 두 모델의 의견·반론·재답변과 마지막 정리까지 7차례 응답을 받았다. 딥시크는 반론을 읽은 뒤 Markdown을 원본으로 두고 SQLite를 검색용으로 쓰는 쪽으로 추천을 수정했다. 마지막 정리에는 합의뿐 아니라 검색 인덱스를 처음부터 도입할지에 대한 이견도 남았다.

이 시험에서 확인한 것은 상대 발언을 읽고 반론과 수정 의견을 이어가는 동작이다. 토론을 시키면 항상 더 나은 결론을 낸다는 뜻은 아니다. 토론 차례에는 파일 작업과 자동 기억 저장도 막았다. 의견을 주고받는 차례에서 구현이나 게시가 실행되지 않게 구분했다.

끝난 답변이 계속 진행 중으로 보이는 문제를 고쳤다

기능을 붙인 뒤에는 실제로 쓰면서 화면 문제가 드러났다. 답변이 끝났는데 진행 중 표시가 남았고, 새로고침해야 최종 답이 보이기도 했다. 실시간 이벤트를 놓치면 뒤의 갱신만으로는 대화 전체 상태를 복구하지 못하는 구조였다.

실시간 연결을 유지하되 응답 중에는 5초마다 서버 상태를 대조하게 했다. 오래된 응답이 뒤늦게 도착해 완료 상태를 되돌리지 않도록 순서도 검사한다. 완료 알림을 일부러 누락시킨 시험에서는 약 5초 뒤 최종 답변과 완료 표시가 복구됐다. 이 검사는 실제 통신 경로에 시험용 응답을 넣은 것으로, 모델 응답 속도를 측정한 결과는 아니다.

다른 날에는 클로드가 8초 만에 멈췄다. 복사 세션으로 확인하니 8초가 지나도 실행 중이었고 약 46초 뒤 답을 마쳤다. 당시 조작 기록에서는 본문을 드래그하다 멈춤 버튼에서 손을 놓은 동작이 중지 클릭으로 처리됐다. 중지 버튼에서 시작한 클릭만 받도록 바꾸고, 취소 원인도 기록하게 했다. 이 수정은 이벤트 검사로 확인했으며 같은 네이티브 화면에서 드래그를 다시 시험한 기록은 없다.

중단된 요청에는 같은 요청을 다시 보내는 버튼을 붙였다. 새로고침은 저장된 중단 기록을 다시 보여줄 뿐 실행을 재개하지 않는다. 재전송은 별도의 시도로 남기고, 이전 답변과 이미 수행한 작업은 보존한다.

딥시크와 GLM이 HTML을 실제 파일로 저장하게 했다

10월 15일에는 딥시크와 GLM에게 HTML 보고서를 부탁했는데 코드만 답으로 나왔다. 파일을 만들 권한이 없다고도 했다. 확인해 보니 두 모델의 실행 경로에는 웹 검색과 URL 읽기만 있었고 파일 저장 도구가 없었다. 다른 참가자의 작업 권한을 켜는 설정으로 해결할 수 있는 문제가 아니었다.

두 모델에 HTML 보고서 저장 도구를 붙였다. 완성된 문서를 보내면 방의 결과물 폴더에 새 파일을 만들고, 실제 저장된 파일에만 HTML 열기와 다운로드 버튼을 붙인다. 이미 있는 파일을 덮어쓰지 않고, 문서가 불완전하면 저장 실패를 표시한다. 일반 프로젝트 파일을 마음대로 고치는 권한과 보고서 생성 권한도 분리했다.

별도 시험방에서 실제 딥시크와 GLM을 호출해 파일 저장, 열기, 다운로드 응답을 확인했다. 기존 방에서 코드로만 받았던 보고서도 원래 답변을 남긴 채 HTML 사본으로 저장했다. 파일이 열리는 것과 보고서 내용이 사실인지는 다른 검사라서, 저장 성공을 내용 검증으로 표시하지는 않았다.

배운 것

이번에는 질문을 보내는 기능보다 그다음 일을 이어 붙이는 데 손이 많이 갔다. 다른 참가자에게 결과가 전달되는지와 같은 규칙을 읽는지부터 확인했다. 작업이 끝나면 화면의 표시도 바뀌어야 했고, 보고서는 실제 파일로 남아야 했다. 모델의 답변에 완료라고 쓰여 있어도 요청 상태는 검토 대기로 두고, 내가 결과를 확인한 뒤 검토 완료로 바꾸게 했다.

지금은 참가자에게 일을 나누고 결과를 받아보며 쓰고 있다. 다만 모든 모델 조합을 같은 수준으로 시험한 것은 아니다. 토론의 실제 호출 검증은 코덱스와 딥시크, 보고서 저장은 딥시크와 GLM을 중심으로 했다. 여러 모델을 붙였을 때 시간이나 비용이 얼마나 줄었는지도 아직 따로 측정하지 않았다. 실제 작업별로 걸린 시간과 비용, 내가 다시 설명하거나 직접 고친 부분을 비교하는 일은 남아 있다.