Cron Agent Dashboard

댓글 속 이메일이 다음 작업자를 가리킬 수 있었습니다

Cron Agent Dashboard에서는 AI CLI에 맡긴 일을 이슈로 만들고, 실행 결과를 댓글로 모았습니다. 다음 담당자를 @Backend처럼 부르는 방식도 넣었습니다. 작업 결과와 인수인계가 같은 곳에 남는 장점이 있지만, 댓글 안의 모든 @가 호출 의도는 아니었습니다.

5월 27일에는 이 경계를 수정했습니다. 이전 판정은 devteam-admin@local이라는 이메일의 뒷부분도 @local 호출로 읽을 수 있었습니다. 계정을 설명하는 댓글이 존재하지 않는 local 에이전트를 찾는 흐름으로 이어질 수 있는 구조였습니다. 개인정보를 가린 u**@example.com도 같은 종류의 오인 후보였습니다.

저는 에이전트를 더 등록하거나 댓글 작성자에게 이메일을 쓰지 말라고 하는 방식 대신 호출 문법을 좁혔습니다. 작업 기록에는 계정과 코드가 자연스럽게 들어옵니다. 기록을 남기는 기능이 자동 실행을 잘못 시작하지 않도록 읽는 쪽을 바꾸는 것이 이 프로젝트의 수정 대상이었습니다.

호출 앞의 경계를 먼저 정했습니다

호출로 인정하는 @ 앞에는 문자열 시작이나 공백이 오도록 했습니다. 이메일처럼 단어 안에 붙은 @는 제외하고, @Backend처럼 독립적으로 적힌 이름을 찾습니다. 에이전트 이름에는 한글을 포함한 문자와 숫자, 밑줄, 하이픈을 유지했습니다.

이 선택은 이름의 종류를 줄이는 것과 다릅니다. 문제는 한글이나 영문 이름이 아니라 설명문 안의 기호가 어디에서 시작하느냐였습니다. 마스킹된 이메일 앞의 별표까지 호출 경계로 인정하지 않도록 공백 조건을 명확히 했습니다.

인수인계 지시는 별도 줄에 쓰는 규칙과도 맞습니다. 예를 들면 ‘데이터 구조 수정을 마쳤습니다’라는 설명을 남긴 뒤 다음 줄에 @Backend를 적는 방식입니다. 사람이 읽어도 다음 담당자가 드러나고 자동 판정도 같은 부분을 읽을 수 있게 만들었습니다.

코드 안의 이름은 실행 지시에서 제외했습니다

공백 경계만으로는 충분하지 않았습니다. 코드 블록에 @QA가 예시로 들어가면 문법상 독립적인 이름처럼 보일 수 있습니다. 저는 여러 줄 코드 블록과 한 줄 코드 구간을 호출 탐색에서 제외했습니다. 코드 내용을 삭제하는 대신 탐색에 사용할 문자열에서 해당 부분을 공백으로 바꾸는 방식입니다.

이렇게 하면 실제 댓글은 그대로 보존하면서 자동 호출에 쓸 텍스트만 구분할 수 있습니다. 코드 안의 이메일이나 핸들을 설명해도 다음 담당자 후보로 읽지 않고, 블록 밖에 적힌 명시적인 호출을 찾습니다. 여러 줄 코드가 닫히지 않은 경우에는 뒤의 내용도 코드로 취급하는 처리 조건을 두었습니다.

이 프로젝트에서는 댓글에서 고른 이름이 실제 실행 대기열로 이어집니다. 이메일이나 코드 예시를 잘못 읽으면 표시만 틀리는 데서 끝나지 않을 수 있습니다. 댓글 내용은 남겨 두되, 다음 담당자를 부르는 문법만 자동 호출에 사용하도록 했습니다.

이름 비교와 호출 찾기를 따로 유지했습니다

호출 후보를 찾은 다음에는 해당 워크스페이스의 에이전트와 이름을 비교합니다. 저는 앞의 @와 주변 공백을 정리하고 대소문자를 맞춰 비교하는 규칙을 유지했습니다. @Writer와 writer가 같은 대상인지 판단하는 일과 이메일의 @를 제외하는 일은 서로 다른 단계입니다.

한 함수에 모든 판단을 섞으면 다음 수정에서 어느 조건이 바뀌었는지 확인하기 어렵습니다. 텍스트에서 후보를 찾는 단계, 이름을 비교하는 단계, 실제 작업을 대기열에 넣는 단계가 연결되어야 합니다. 이름을 찾았다고 무조건 모든 실행 조건이 충족된 것도 아닙니다.

대시보드의 이슈·댓글·실행 결과 구조도 이 구분을 돕습니다. 다음 담당자는 결과를 같은 이슈에서 읽고 맡은 작업을 이어갑니다. 예약 규칙은 시작 시점을 정하는 기능이고, 댓글의 호출은 다음 담당자를 정하는 기능입니다. 둘이 연결되더라도 완료 조건과 실행 결과를 읽는 책임은 남습니다.

정상 호출보다 섞인 댓글을 검사했습니다

검수 조건에는 정상적인 @Writer 호출 외에 이메일, 마스킹된 이메일, 한 줄 코드, 여러 줄 코드를 넣었습니다. 그 뒤 블록 밖에 @Backend나 @QA를 적어 올바른 후보를 선택하는지 확인하도록 했습니다. 한글을 포함한 이름과 대소문자 비교도 별도 조건으로 남겼습니다.

중요한 검수 대상은 ‘이름 하나를 찾는가’보다 ‘설명과 호출이 섞여 있을 때 어느 이름을 고르는가’였습니다. 결과 댓글에는 계정 정보와 구현 설명이 자주 함께 들어갈 수 있습니다. 가장 단순한 문장만 검사하면 이런 작업 기록의 형태를 놓치게 됩니다.

저는 이 수정에서 실제 인수인계를 담는 문법을 먼저 정하고, 그 문법을 흐리는 입력을 검사하는 순서를 택했습니다. 댓글 수나 실행 수를 성과로 삼지 않았습니다. 어떤 문자열이 자동 연결의 근거가 되는지 설명할 수 있어야 다음 오류를 추적할 수 있기 때문입니다.

자동화에 쓰는 글에는 해석 범위가 필요합니다

이 프로젝트는 Go API와 SQLite 저장소, 실행 worker, React 화면으로 구성했습니다. 이슈를 관리하는 화면을 만들면서 동시에 그 안의 문장이 실행에 영향을 주도록 연결했습니다. 따라서 화면에 보이는 글과 자동화가 해석할 부분 사이에 경계를 두는 일이 필요했습니다.

다른 협업 도구에서도 댓글을 트리거나 담당자 선택에 쓴다면 같은 질문을 먼저 해볼 수 있습니다. 예시 속 이름을 호출로 읽는지, 코드 블록을 제외하는지, 호출이 없을 때 임의의 다음 담당자를 만드는지입니다. 자동화가 읽는 문법을 좁히면 사람이 남길 수 있는 설명의 범위도 분명해집니다.

이메일과 코드 예시가 실행 지시로 바뀌지 않도록 작은 판정 조건을 고친 일입니다. 이슈에 맥락을 모으는 도구일수록 그 맥락을 함부로 다음 실행으로 해석하지 않는 기준이 필요했습니다.