Telegram을 통한 코딩 에이전트, 파트 3: 일상적인 운영 계약

파트 2를 마치셨으므로, 이제 메시지를 입력하면 코딩 에이전트가 답변하고 창(pane)을 제어하는 주제를 갖게 되었습니다. 이 포스트는 운영 계약(operating contract)에 관한 것입니다. 즉, 릴레이(relay)가 이해하는 작은 어휘 집합, 첫날 모두를 혼란스럽게 만드는 단 하나의 라우팅 규칙, 그리고 (이것은 셸에 연결된 전화기이기 때문에) 절대 보내지 말아야 할 짧은 목록을 다룹니다. 이것은 튜토리얼이 아니라 계약입니다. 한 번만 읽으면 자신 있게 이것을 제어할 수 있을 것입니다.

파트 1의 멘탈 모델(mental model)을 머릿속에 두십시오: 당신은 릴레이 에이전트를 통해 tmux 창에 있는 코딩 에이전트에게 말을 걸고 있는 것입니다. 릴레이는 전령입니다. 당신이 입력하는 대부분은 창으로 직접 전달되며, 몇 가지 단어들만 릴레이 자체에서 처리됩니다.

릴레이가 직접 처리하는 단어들

이것들은 _로컬 제어(local control)_입니다. 릴레이는 이 단어들을 전달하는 대신 직접 동작합니다. 이 단어들은 릴레이의 AGENTS.md(파트 2에서 작성한 명령 테이블)에서 가져오므로, 정확한 문구는 당신이 조정할 수 있습니다:

당신이 입력하는 것	발생하는 일
`status` / `what's in tmux?`	릴레이가 창을 캡처하고, 터미널 포맷을 제거한 뒤, 에이전트가 현재 무엇을 하고 있는지 요약합니다
...

status는 당신이 가장 많이 의존하게 될 명령입니다. 파트 4에서 자동 모니터(automatic monitors)를 추가하기 전까지, status는 상태를 확인하는 방법입니다: 아직 진행 상황 알림(progress pings)이 없으므로, 직접 물어봐야 합니다.

주의해야 할 점 하나: status는 지금 바로 창에 있는 내용을 보여줍니다. 그것은 스냅샷이지 증거가 아닙니다. 에이전트가 테스트를 통과했다고 _주장_하는 내용을 보고할 수는 있지만, 실제로 통과했는지 여부는 알려줄 수 없습니다. 그 주장을 신뢰하기보다는 검증해야 할 대상으로 취급하는 것이 바로 파트 5의 핵심입니다.

어떤 제어(control)를 언제 사용할 것인가? 에이전트가 잘못된 행동을 하고 있거나 안전하지 않은 단계를 밟으려 할 때는 interrupt를 사용하세요. 즉, *이번 턴(this turn)*을 중단하고 방향을 재설정해야 할 때입니다. restart는 패널(pane)이나 세션(session)이 정말로 멈춰버렸을 때만 사용하세요. 이는 동일한 세션을 재개하므로 컨텍스트(context)를 유지할 수 있습니다. 대화가 길어지고 있지만 계속 진행하고 싶을 때는 compact를 사용하고, 완전히 새로운 관련 없는 작업을 시작하려면 new session을 사용하세요.

그 외의 모든 것은 에이전트에게 전달됩니다

위의 제어 명령어(control words)에 해당하지 않는 모든 내용은 패널로 토씨 하나 틀리지 않고 그대로 전달됩니다. "업로드 클라이언트에 재시도(retry) 로직을 추가하고 테스트를 실행해줘"라는 문장은 릴레이(relay)가 해석하는 명령어가 아닙니다. 이는 코딩 에이전트(coding agent)를 위한 지침이므로, 릴레이는 이를 단순히 입력하고 에이전트가 작업하도록 둡니다. 이것이 기본 동작이며, 여러분이 수행하는 작업의 대부분입니다.

첫 메시지를 잘 작성된 티켓(ticket)처럼 취급하세요. 리포지토리(repo)와 브랜치(branch) 이름, 원하는 변경 사항, 테스트 기대 결과, 그리고 모든 제약 조건을 명시하세요. 에이전트는 여러분이 제공한 정보에 따라 행동하므로, 수다스러운 프롬프트(prompt)보다는 정확한 프롬프트가 훨씬 효과적입니다.

(만약 에이전트에게 문자 그대로의 제어 명령어를 보내야 한다면, 예를 들어 status라는 텍스트 자체를 보내야 한다면? send status를 사용하세요. 그러면 릴레이 자체의 status 명령을 트리거하는 대신, 해당 텍스트를 패널에 입력합니다.)

주의할 점 하나: 옵션 답변은 에이전트의 것입니다

이것은 첫날 모든 사람을 혼란스럽게 만드는 유일한 지점이니, 지금 바로 숙지하세요.

코딩 에이전트(패널 내부)가 여러분에게 무언가를 물어볼 때(예: A / B 옵션을 출력하거나, Proceed? 또는 yes/no를 묻는 경우), 여러분의 짧은 답변은 에이전트를 위한 답변이며, 릴레이는 이를 그대로 전달합니다. 릴레이 스스로가 그 답변에 따라 동작하는 것이 아닙니다.

에이전트가 옵션을 보여준 후 다음과 같이 입력하면:

A, B, yes, no, do it, sorry, B → 여러분의 선택으로서 패널로 직접 전달됩니다.

이것이 바로 여러분이 원하는 방식입니다. 여러분은 코딩 에이전트 (coding agent)의 질문에 답하는 것이지, 릴레이 (relay)에 새로운 명령을 내리는 것이 아닙니다. 이 점을 명시해야 하는 이유는 이를 통해 방지할 수 있는 오류 모드 (failure mode) 때문입니다. 이 규칙이 없다면, 단순한 A라는 입력이 _릴레이_에 대한 지시로 오해받을 수 있으며, 릴레이가 여러분의 선택을 전달하는 대신 스스로

운영(Production) 및 스테이징(Staging) 환경은 읽기 전용(read-only)입니다. 에이전트에게 운영 또는 스테이징 환경의 그 어떤 것도 적용(apply), 삭제(delete), 편집(edit), 패치(patch), 확장(scale) 또는 재시작(restart)하도록 요청하지 마십시오. 오직 검사(inspect) 및 디버깅(debug)만 수행하십시오.
공유 브랜치(shared branches)에 대한 푸시(push)나 머지(merge)는 금지됩니다. 기능(feature) 브랜치나 버그 수정(bugfix) 브랜치는 괜찮습니다. main / dev / GitOps 브랜치는 반드시 사람에 의해서만 머지되어야 합니다. GitOps 브랜치로의 머지는 곧 배포(deploy)를 의미합니다.
공유 인프라에는 사람이 필요합니다. 게이트웨이(Gateways), API 게이트웨이(API gateways), 그리고 다른 팀에서 사용하는 모든 것: 명시적인 사람의 승인 없이는 어떠한 변형(mutations)도 허용되지 않습니다.
릴레이 토픽(relay topic)에 절대 비밀 정보(secrets)를 붙여넣지 마십시오. 자격 증명(Credentials)은 운영 에이전트(ops-agent)의 영역이며, 그 영역에서도 보호된 경로를 통해 전달될 뿐, 결코 에코(echo)되거나 릴레이되지 않습니다. 릴레이 토픽은 잘못된 장소입니다. 그것으로 끝입니다.

만약 릴레이가 지시를 거부하거나 확인을 요청한다면, 이에 맞서지 마십시오. 그것은 계약(contract)이 제대로 작동하고 있다는 증거입니다. 현재 그 계약은 에이전트의 AGENTS.md에 명시된 가이드라인과 여러분 자신의 운영 규율(operator discipline)입니다. 이 시리즈의 마지막 조각(감독자, supervisor)은 이러한 판단을 자동화하고 우회하기 어렵게 만들 것입니다.

일상적인 모습

파트 2 설정만 갖춘 상태에서 실제로 느껴지는 경험은 다음과 같습니다:

커피숍 대기 줄에서 토픽을 열고 작업을 입력합니다: "업로드 서비스(upload service)의 S3 클라이언트(S3 client)에 지수 백오프(exponential backoff)를 추가하고 단위 테스트(unit tests)를 실행해줘." 릴레이가 이를 전달하면 에이전트가 시작됩니다.
몇 분 후 status를 입력합니다. 릴레이가 요약해 줍니다: 테스트 실행 중, 2개 실패.
에이전트가 재시도 상한선(retry ceiling)을 5로 올릴지 10으로 올릴지 묻습니다. 여러분은 5라고 답합니다. 명령이 창(pane)으로 전달되고 에이전트가 작업을 계속합니다.
다시 status를 입력합니다: 창에 테스트가 통과(green)되었다고 보고됩니다. 에이전트에게 기능(feature) 브랜치를 열고 푸시하도록 요청하면, 에이전트가 수행합니다.
오래된 프로세스(stale process)로 인해 한 번 막혔을 때, restart를 입력하자 동일한 세션에서 다시 작동했습니다.

터미널도, SSH도 없이, 모든 루프가 휴대폰에서 이루어집니다. 파트 4에서는 진행 상황과 최종 요약을 자동으로 푸시하는 모니터(monitors)를 추가할 것이므로, 더 이상 status로 상태를 확인할(poll) 필요가 없게 될 것입니다. 하지만 위의 루프는 이미 오늘 바로 작동합니다.

세션 시작 전

Part 2의 준비 상태 확인(readiness gate) 항목들을 여전히 충족할 수 있다면 준비가 된 것입니다:

봇이 해당 토픽의 status에 응답합니다.
실제 명령(instruction)이 창(pane)에 도달하고 에이전트가 이에 따라 동작합니다.
라우팅(Routing)이 올바릅니다 (에이전트가 사용자의 토픽을 처리했습니다).
그룹이 보안 설정되었습니다: 허용 목록(allowlist), 사용자 ID 전용, @mention 불필요.
위의 루프를 처음부터 끝까지 구동할 수 있습니다.

작동하는 루프의 민감 정보가 삭제된(redacted) 스크린샷을 "준비 완료" 증빙물로 준비하세요. 만약 진행이 막힌다면, 증상과 함께 Node/pnpm 버전, 그리고 마지막 몇 줄의 (민감 정보가 삭제된) 게이트웨이 로그(gateway log)를 보내주세요. 그래야 실습실에 들어가기 전에 문제를 해결할 수 있습니다.

이것으로 사전 작업이 끝났습니다. 라이브 세션에서는 단일 전달자(courier)를 넘어설 것입니다. Part 4에서는 에이전트를 진정으로 유능하게 만들며 (로드 가능한 기술(loadable skills), 도구 서버(tool servers), 토픽별 메모리(per-topic memory), 그리고 자동으로 알림을 보내는 모니터(monitors)), Part 5는 그 결실을 보는 단계입니다. 에이전트의 증거를 감사(audit)하고, 확신에 차 있지만 틀린 답변이 사용자에게 도달하기 전에 차단하는 회의적인 감독관(skeptical supervisor)을 다룹니다.