당신을 기다리는 일을 위한 받은편지함

14:10에 Payments API에서 관리형 실행을 시작하고 하던 일로 돌아갑니다. 14:25에 에이전트가 질문 하나에서 멈춥니다. 재시도가 수신 측의 4xx 응답까지 다뤄야 하는가, 아니면 5xx와 타임아웃만인가? 당신은 다른 탭에 있습니다. 실행에 리뷰 루프가 생겼을 때 설명했듯이, 한 시간 안에 아무도 답하지 않은 질문은 에이전트가 자기 판단으로 계속 진행하게 하고, 한 시간 안에 아무도 검토하지 않은 계획은 실행을 실패시킵니다. 15:25에 에이전트는 혼자 결정합니다.

고장 난 것은 없었습니다. 실행 페이지에는 내내 응답 대기 중이라고 표시되어 있었습니다. 당신이 실행 페이지에 없었을 뿐입니다.

실행은 Archyl 전반에서 사실이 된 어떤 일의 한 사례입니다. 일이 사람을 기다립니다. 아키텍처 변경 요청은 편집 권한이 있는 누군가가 검토할 때까지 열린 채로 있습니다. 다이어그램 요소에 남긴 코멘트에 답글이 달려도 작성자는 끝내 보지 못합니다. 지금까지 알아내는 방법은 두 가지였습니다. 직접 가서 보거나, 이메일 알림을 켜는 것입니다. 이메일 알림은 조직 전체의 아키텍처 변경을 그대로 비추기 때문에, 당신이 처리할 일이 아닌 것까지 아주 많이 알려 줍니다.

이제 Archyl에 세 번째 방법이 생겼습니다. 앱 헤더 오른쪽 끝, 모든 페이지에 있는 종 아이콘이고, 읽지 않은 개수가 붙습니다. 그 뒤에는 당신을 기다리는 일이나 당신이 한 일에 대한 답만 담는 받은편지함이 있습니다.

패널의 모습

종을 클릭하면 알림이라는 제목의 패널이 열립니다. 알림 하나가 한 줄입니다. 누가 무엇을 했는지 말하는 문장, 발췌, 프로젝트 이름, 그리고 얼마나 전인지. 있을 법한 어느 오후를 보여 드립니다. 문장은 앱이 실제로 표시하는 것입니다. 이름, 프로젝트, 발췌는 예시입니다.

알림                                               모두 읽음으로 표시

● 에이전트가 답변을 기다리고 있습니다
  Should retries also cover 4xx responses from receivers, or only
  5xx and timeouts?
  Payments API · 12분 전

● Marie Laurent 님이 #14에 변경을 요청했습니다
  Billing shouldn't call the ledger database directly. Route it
  through the Ledger API container.
  Billing · 2시간 전

● Sam Okafor 님이 토론에 답글을 남겼습니다
  That queue was replaced by the outbox table in March, the
  diagram is behind.
  Checkout · 3시간 전

  에이전트 실행이 완료되었습니다
  Document how to set up and run the service locally.
  Billing · 어제

줄을 클릭하면 읽음으로 표시되고 그 알림이 가리키는 페이지가 열립니다. 실행, 변경 요청, 또는 토론입니다. 모두 읽음으로 표시는 패널 헤더에 있고, 읽지 않은 줄에 마우스를 올리면 읽음으로 표시 버튼이 나타나서 열지 않고 치우고 싶은 것에 쓸 수 있습니다. 아무것도 없을 때는 패널이 그렇게 말합니다. "기다리는 일이 없습니다".

무엇이 알림을 보내는가

출처는 세 가지이고, 전체 목록은 여기에 다 실을 수 있을 만큼 짧습니다.

관리형 에이전트 실행은 실행을 시작한 사람에게 알립니다.

취소된 실행은 아무것도 보내지 않습니다. 누군가 멈추기로 한 것이고, 그 사람에게는 알려 줄 필요가 없습니다.

아키텍처 변경 요청은 두 방향으로 알립니다. 요청이 열리면 작성자를 제외하고 프로젝트를 편집할 수 있는 모든 사람에게 알려집니다. 검토에는 편집 권한이 필요하므로, 요청이 기다리는 사람이 바로 그들입니다. 그때부터는 요청에 일어나는 일이 작성자에게 전해집니다.

토론은 답글에 대해 알립니다. 답글은 토론을 시작한 사람과 그 토론에 이미 답글을 단 모든 사람에게 전해지고, 그 답글이 발췌가 됩니다. 링크는 개별 답글이 아니라 토론을 열기 때문에 스레드 전체에 도착하게 됩니다.

세 가지 모두에 적용되는 규칙이 하나 있습니다. 자신이 한 행동에 대해서는 절대 알림을 받지 않습니다. 동료의 변경 요청을 승인하면 동료는 그 소식을 듣습니다. 당신은 듣지 않습니다.

왜 활동 피드가 아닌가

이것을 만드는 뻔한 방법은 Archyl이 이미 기록하고 있는 변경 히스토리를 가져다 종 아래에 보여 주는 것입니다. 우리는 일부러 그렇게 하지 않았습니다.

조직의 히스토리는 대부분 다른 사람들의 일이 잘 진행되고 있다는 기록입니다. 누군가 container 이름을 바꿨고, 누군가 관계를 추가했고, 디스커버리가 컴포넌트 열두 개를 제안했고 팀원이 승인했습니다. 모두 사실이지만 당신이 필요한 일은 거의 없습니다. 그것을 읽지 않은 개수 아래에 두면 그 개수는 아무 의미도 없어집니다. 우리 대부분은 다른 어떤 도구에 그런 종을 하나씩 갖고 있습니다. 그 위에 붙은 숫자는 읽지 않게 된 지 오래입니다.

그래서 받은편지함에는 무엇이 들어오는지를 가르는 좁은 기준이 있습니다. 당신이 행동할 때까지 막혀 있는 일이거나(에이전트의 질문, 계획, 당신이 검토할 수 있는 변경 요청), 당신이 시작한 일에 대한 답이거나(당신의 요청에 대한 리뷰, 당신의 실행 종료, 당신의 토론에 달린 답글). 두 기준 중 어느 것도 통과하지 못한 변경은 한 줄도 얻지 못합니다.

넓게 보는 방법은 여전히 있고 바뀌지 않았습니다. 이메일 알림과 히스토리 페이지가 계속해서 조직 전체의 활동을 보는 곳입니다. 받은편지함은 나머지 절반, 곧 당신 앞으로 온 부분입니다.

몇 가지 세부 사항

조직마다 받은편지함이 따로 있습니다. 두 조직에 속해 있다면, 종은 지금 들어가 있는 조직의 것을 세고 나열합니다.

문장은 당신의 언어를 따르고, 발췌는 따르지 않습니다. 앱은 아홉 개 언어로 제공되며, 각 줄의 문장은 당신의 인터페이스 언어로 표시됩니다. 알림은 완성된 영어 문자열이 아니라 무슨 일이 일어났는지를 저장합니다. 그래서 프랑스어로 작업하는 리뷰어와 일본어로 작업하는 작성자가 각자 자기 언어로 "변경을 요청했습니다"를 읽습니다. 발췌는 누군가의 말이고, 쓰인 언어 그대로 남습니다.

알림이 복사하는 내용은 원본과 똑같이 보호됩니다. 한 줄에는 변경 요청의 제목이나 코멘트의 일부가 반복됩니다. 그것들이 저장 시 암호화되는 곳에서는, Archyl Cloud가 그런 경우인데, 받은편지함 안의 사본도 같은 방식으로 암호화됩니다.

개수는 푸시가 아니라 폴링입니다. 읽지 않은 개수는 30초마다 새로 고쳐지고, 탭으로 돌아올 때 한 번 더 새로 고쳐집니다. 따라서 새 알림이 종에 나타나기까지 최대 30초가 걸릴 수 있습니다. "리뷰어가 변경을 원한다"는 알림이라면 그 정도면 충분히 빠르고, 열려 있는 탭마다 장시간 유지되는 연결을 두지 않아도 됩니다. 읽음으로 표시하면 자신의 브라우저에서는 개수가 바로 갱신됩니다.

아직 하지 못하는 것

에이전트가 MCP 서버를 통해 연 변경 요청은 리뷰어에게 알리지 않습니다. 앱에서 연 요청은 알립니다. 에이전트가 MCP로 연 요청은 프로젝트 목록에 나타나지만, 누구의 종도 움직이지 않습니다.

유형별 설정이 없습니다. 한 종류의 알림만 끌 수는 없습니다. 위의 목록이 받게 되는 전부입니다.

@멘션이 없습니다. 코멘트에서 누군가의 이름을 불러도 그 사람에게 알림이 가지 않습니다. 현재는 이미 토론에 참여한 사람만 답글 소식을 듣습니다. 멘션은 받은편지함 로드맵의 다음 항목이고, 날짜는 정하지 않겠습니다.

어디서 찾나

설정할 것은 없습니다. 종은 헤더 오른쪽 끝에 있고, 당신 앞으로 무언가 올 때까지 비어 있습니다. 동작을 가장 빨리 확인하는 방법은 계획 먼저 검토를 켠 프로필에서 관리형 실행을 시작하고, 다른 페이지로 옮겨 가서 개수가 뜨기를 기다리는 것입니다.

채팅에서 실행을 시작한다면, 이것은 스레드 업데이트를 대체하지 않고 나란히 동작합니다. Slack이나 Teams에서 시작한 실행은 여전히 해당 스레드에 보고하고, 실행을 시작한 사람은 받은편지함에서도 그 줄을 받습니다.

관련 글: 실행이 기다리는 계획과 질문에 대해서는 에이전트가 일하는 동안 리뷰하기를, 이 알림들이 따르는 리뷰 워크플로에 대해서는 아키텍처 변경 요청을 참고하세요.