에이전트가 세션 시작 시마다 로드하는 파일을 작성하기

Sterling Chin, Postman의 응용 AI 엔지니어이자 선임 개발자 옹호자는 유능한 모델을 언급하지만, 그의 에이전트를 유용하게 만든 것은 모델 선택에 의한 것이 거의 아니라고 말한다. 대부분은 그가 아무것도 입력하기 전에 세션이 로드하는 파일들이다. 그의 에이전트인 Marvin은 Claude Code에서 커스텀 명령어와 마크다운으로 구성되어 있다. Chin은 Marvin의 자체 설명을 소리 내어 읽었다: 화려한 프레임워크는 없고, 단지 마크다운, 파일, bash 스크립트, 그리고 고집만 있을 뿐이다. CLI가 엔진이고, 그 주변을 둘러싼 파일이 실제로 수정할 수 있는 부분이다.

그 시작 파일은 시스템 프롬프트(system prompt)이다: 어시스턴트가 누구인지, 무엇을 해야 하고 무엇을 하지 말아야 하는지, 어떤 도구를 사용할 수 있는지, 그리고 답변을 어떻게 형식화해야 하는지에 대한 내용이다. Chin은 Claude Code의 프로젝트 지침 파일(project instructions file)을 이 프롬프트로 취급한다. 여기에는 그의 작업 컨텍스트와 그가 대화하는 사람들, 심지어 상사인 Quintin까지 포함되어 있어 새로운 세션이 추측할 필요가 없다. 긴 파일은 호출마다 입력으로 청구되므로, 다음 세션에서 틀릴 수 있는 사실들만 간결하게 유지할 것이다.

이것은 내가 시작할 스케치이다. Marvin의 파일도 아니고 Postman이 제공하는 것도 아니다.

# Session manual (sketch)

## Who you are
...

정체성과 우선순위는 무엇을 넣어야 할까요?

Chin은 파일에 행동 양식을 작성했고, 그 행동 양식이 흐트러지면 다시 썼다. Marvin은 사려 깊고(sardonic), 직설적이며, '예스맨' 역할을 거부하도록 구축되었는데, Chin이 브레인스토밍 파트너를 원했기 때문이다. 그러자 에이전트는 비꼬는 것에 과도하게 집중했다. Chin은 여전히 가리키는 한 줄을 추가했다: 우선적으로 도움이 되도록(helpful first), 그다음으로 개성이다(personality second). 나는 드리프트가 감지되는 바로 그날 파일에 수정을 넣을 것이다. 채팅창에서 구두로

능력처럼 보이는 실패는 누락된 사실이다. Postman 모임이 열리기 전 Chin은 샌프란시스코 지역에서 Agents와 APIs에 대해 Marvin에게 이야기했다. 그는 Heidi와 James가 보안을 담당하고 있다고 했다. 그들은 Postman의 경비원들이다. Marvin은 발표 순서를 읽고 슬라이드 덱을 업데이트했으며, 잘못된 전제에 대한 후속 조치를 취했다. Chin은 그것을 주니어 실수라고 부르며, 좋은 주니어도 두 번은 하지 않을 것이라고 말했다. 그는 그들의 역할을 설명했고 Marvin이 작업을 다시 했다. 나의 규칙은 더 나아질 것이다. 에이전트가 행동할 이름은 파일에 역할과 함께 명시되어야 한다. 왜냐하면 채팅상의 대화는 기록이 아니기 때문이다.

어떤 도구는 이름을 지정하고, 어떤 도구는 제외하는가?

처음에 Marvin은 모호한 지시에 실패했다. Chin은 그에게 자신의 Jira 티켓을 가져오라고 했다. Marvin은 어느 것인지 알 방법이 없었다. Atlassian에는 Chin이 모니터링하는 티켓을 포함하여 수천 개의 티켓이 있었다. 그는 검색 공간을 제공하는 것을 멈췄다. 대신, 자신이 작업하는 DevRel 워크스페이스의 전체 Confluence 링크와 칸반 보드를 붙여넣었다.

그 선택은 컨텍스트 엔지니어링 (context engineering)이다. 무엇이 창(window)으로 들어갈지, 그리고 무엇이 빠질지를 결정하는 것이다. 링크는 경계다. '내 모든 티켓'이라고 하는 것은 잘못된 수천 개의 행으로 세션을 오염시키는 방법이다. Chin은 알려진 예산에 맞춰 설계한다. 그의 데모에서 Marvin은 당일의 세션을 추가하고, 체크포인트를 작성하며, Chin은 컨텍스트를 지우거나 압축할 수 있다. 왜냐하면 그가 말했듯이, '20만 토큰밖에 없다는 것을 안다'는 것이다. 체크포인트는 더 큰 창(window)에서도 비용과 집중력 모두에서 효과적이다.

그의 slash start 명령어는 작업 이메일, 캘린더, 그리고 작업 현황을 담은 상태 파일을 가져오는 bash를 실행한다. slash end는 하루를 마감한다. slash update는 방금 완료한 청크(chunk)를 작성한다. 날들은 세션이다. 주말 보고서는 지난 다섯 번의 세션을 압축한다. 반복되는 워크플로우는 스킬즈 디렉토리(skills directory)에 마크다운 절차로 보관되며, 시작 파일과는 분리되어 있다. 이는 그가 멘토들로부터 받은 조언으로, 두 번 하는 모든 것을 자동화하라는 것이다.

항상 동일한 소스를 가져오는 시작 스크립트는 고정된 경로입니다. 로봇 프로세스 자동화 (RPA)는 이전 세대와 같아서, 레이아웃이나 케이스가 변경될 때 결정론적이며 취약합니다. 매뉴얼은 스크립트가 실행될 수 있는 곳과 에이전트가 멈춰야 하는 곳을 명시하는 곳입니다. Chin이 들려준 보안 검토 후기는 범위 설정에 대한 답변이었습니다. Claude Code는 이미 승인되었고, Marvin은 추가적인 작업을 수행하지 않았으며, 명확하게 정의된 공간 내에 머물렀습니다. 그 공간을 문서화하세요. '승인됨'이라는 것은 도구 목록이 아닙니다.

다음 세션이 오래된 인수인계를 물려받았을 때는, 태스크를 추가하기 전에 상태 파일(state file)을 복구해야 합니다. 에이전트의 컨텍스트 최신 유지는 그 복구 과정을 안내합니다.

보고서에는 무엇이 포함되어야 하는가?

Chin은 동료가 제공하는 것, 즉 변경된 내용에 대한 간략한 설명이 담긴 보고서를 좋아합니다. 그의 콘텐츠 서브 에이전트는 스타일 규칙을 포함하여 절대적인 규칙들을 가지고 있으며, 여기에는 대시(em dashes)를 쉼표, 마침표 또는 콜론으로 대체하는 스타일 규칙도 포함됩니다. 이 에이전트는 Chin이 싫어하는 대비 패턴 규칙에 따라 초안 문장을 경계선상이라고 표시했고, 그는 그것을 되돌려 보냈습니다. 그 플래그는 보고서 형식에 포함되어야 합니다. 무엇을 변경했는지, 무엇을 가정했는지, 그리고 인간 사용자가 무엇을 읽어야 하는지 명시하세요.

숫자는 느슨하게 다루세요. Chin에 따르면 Marvin은 이제 업무 시간의 90% 이상을 처리하며, 첫 주 이후 Marvin 자신의 주간 보고서에는 190개 이상의 항목이 나열되었습니다. 첫 번째는 그의 추정치이고 두 번째는 에이전트가 스스로 계산한 것입니다. 만약 이 보고서가 에이전트가 얼마나 효과적인지를 결정하는 기준이라면, 자체 출력을 계산하는 에이전트는 약점이 됩니다. 파일에 가정을 보여달라고 요청하고, 그런 다음 그것들을 확인하세요.

Marvin은 주로 Claude Code로 실행되며, Chin에 따르면 Codex나 Gemini CLI에서도 실행될 수 있습니다. 엔진은 바뀔 수 있지만, 저는 시작 파일을 가져가는 것이 가장 중요할 것이라고 예상합니다. 저는 엔진을 기다리지 않을 것입니다. 제가 그 파일을 작성하고, 첫 실제 세션에서 무엇이 잘못되는지 확인할 것입니다.

체크리스트

• 세션 시작 시 로드하는 파일: 에이전트의 정체성, 관련 인물 및 역할, 우선순위, 허용되는 링크, 거부 사항, 보고서 형식 등을 포함합니다.
• 'get my tickets'를 실제로 사용하는 공간 URL과 보드 URL로 교체하세요.
• 수정사항(톤, 잘못된 역할, 금지된 행동 등)이 고착되면 해당 날짜에 파일을 편집하세요.
• 이름 붙일 수 있는 토큰 예산 대비 체크포인트를 설정하세요. Chin은 20만 개를 기준으로 계획했습니다.
• 가정 사항을 확인하기 위해 보고서를 읽으세요. 에이전트가 자체 작업량으로 계산한 것을 결과로 취급하지 마세요.

더 자세한 설명과 에피소드 클립은 Chain of Thought에서 확인할 수 있습니다. 이 내용은 이 에피소드를 바탕으로 작성되었습니다.

에피소드 스크립트를 기반으로 AI의 도움을 받아 초안 작성됨.