핵심 개념: 에이전트를 구성하는 것들

1. 에이전트는 네 가지 축의 설정이다

에이전트를 “만든다”는 말은 코드를 짜는 일처럼 들리지만, 실제로 하는 일은 네 가지 질문에 답하는 것뿐입니다.

네 가지를 다 정해도 그 결과는 눈에 보이는 “에이전트”라는 실체가 아니라 JSON 한 덩어리입니다. 채용 계약서와 같습니다 — 계약서에 없는 능력은 없고, 계약서를 다시 쓰면 담당자가 바뀝니다.

이 네 축은 서로 독립적으로 움직이지 않습니다. 워크스페이스는 에이전트마다 새로 만들 수 있지만 메모리 스토어는 그렇지 않은 경우가 많습니다 — 격리는 원하는 만큼 되는 게 아니라, 시스템이 허용하는 만큼만 됩니다. 에이전트를 여러 개 두는 조직이라면 “무엇을 나눌 수 있고 무엇을 나눌 수 없는가”부터 먼저 확인해야 하는 이유입니다.

2. 세션이 보는 “폴더”는 다섯 가지이고, 승인은 범위도 본다

에이전트를 운영하다 보면 “어느 폴더에서 실행되는가”라는 질문이 반복해서 나옵니다. 이름이 비슷한 개념이 실제로는 다섯 가지로 나뉘어 있기 때문입니다.

값이 우연히 같아 보이는 순간이 있습니다. 프로젝트 폴더가 정상 연결돼 있으면 셸이 실행되는 곳도 그 폴더와 같아지기 때문입니다. 그런데 연결이 풀리는 순간 — 에이전트를 바꾸거나 세션을 새로 열 때 — 다섯 가지는 바로 갈라집니다. “파일을 못 찾겠다”는 보고를 받으면 가장 먼저 확인할 지점이 여기입니다.

승인 경계에도 같은 원리가 적용됩니다. 대부분 “쓰기는 막히고 읽기는 통과한다”고 생각하지만, 정확히는 그렇지 않습니다. 승인은 변경 여부만이 아니라 범위도 봅니다. 연결된 작업 폴더 안의 읽기는 통과하지만, 그 폴더 밖으로 나가는 읽기는 — 삭제나 수정이 전혀 없어도 — 승인이 걸립니다. 유출은 쓰기 없이도 일어날 수 있기 때문입니다.

3. 절차는 스킬로 — on-demand로만 켜진다

반복하는 절차를 매번 프롬프트에 새로 쓰는 대신, 파일 하나로 저장해 두고 필요할 때만 불러오는 방법이 있습니다. 이 방식의 핵심은 두 가지입니다.

스킬은 특별한 실체가 아니라 frontmatter가 붙은 마크다운 파일 하나입니다. 이름·설명·트리거는 파일 머리말이 되고, 절차 본문은 그 아래에 그대로 남습니다. 화면의 생성 폼은 이 파일을 만들어 주는 편집기일 뿐입니다.

만들어진 것만으로는 아무 일도 하지 않습니다. 살아나려면 세 단계를 통과해야 합니다.

1. 생성 — 파일이 디스크에 존재한다
2. 매핑 — 어떤 에이전트가 이 파일을 쓸지 연결한다
3. 로드 — 트리거가 맞거나 직접 호출돼 실제 대화의 컨텍스트에 들어간다

세 단계 중 무엇이 됐는지는 항상 화면에서 확인할 수 있어야 합니다. 로드되는 순간이 표시되지 않는 시스템이라면, 절차가 적용됐는지 매번 추측해야 하기 때문입니다.

그리고 한 가지 한계를 기억해야 합니다. 스킬은 강제 장치가 아니라 모델이 해석하는 문서입니다. 형식·규칙처럼 판별 가능한 지시는 잘 지켜지지만, 정확한 문구까지 보장되지는 않습니다. 스킬 본문에 오타를 심어도 모델이 스스로 올바른 표현으로 고쳐 답하는 경우가 그 증거입니다 — 의도는 통하지만 토씨 하나까지 강제할 수는 없습니다.

4. 규칙은 두 갈래다 — 문장으로 줄지, 명령으로 줄지

“이 규칙은 항상 지켜져야 한다”는 요구가 있을 때, 실제로 선택지는 하나가 아니라 둘입니다. 그리고 둘은 근본적으로 다른 층에서 작동합니다.

문장형 규칙은 항상 컨텍스트에 실려 모델이 매번 다시 해석합니다. 규칙 두 개가 충돌하면 — 예를 들어 “형식을 지켜라”와 “마지막에 인사를 붙여라”가 동시에 걸리면 — 어느 쪽이 이길지는 모델의 몫이고 실행마다 결과가 달라질 수 있습니다. 반대로 명령형 규칙은 해석의 여지가 없습니다. 이벤트가 발생하면 그냥 실행되고, 실행 횟수는 보낸 요청 수와 정확히 일치합니다.

여기서 실무적인 결론이 나옵니다. 지켜졌으면 하는 규칙은 문장으로, 어겨지면 안 되는 규칙은 명령으로 겁니다. 정말 중요한 규칙이라면 둘 다 씁니다 — 문장으로 적어 두고, 명령으로 한 번 더 확인합니다.

한 가지 더 — 모델은 자신에게 걸린 명령형 규칙의 존재를 모릅니다. 명령은 컨텍스트를 거치지 않고 시스템 층에서 곧바로 실행되기 때문입니다. “방금 그 알림이 뭐야”라고 물어도 모델은 답하지 못합니다. 컨텍스트(모델이 아는 것)와 실행(시스템이 하는 것)은 서로 다른 층에 있습니다.

5. 파일에 남는 기억과, 시스템이 스스로 쌓는 기억

에이전트가 무언가를 “기억한다”고 할 때, 그 기억은 두 가지 서로 다른 곳에 있을 수 있습니다.

마지막 줄이 가장 중요합니다. 사람이 쓰지 않은 규칙이 다음 세션의 행동을 바꿀 수 있다는 뜻이기 때문입니다. 파일 기억에는 이 문제가 없습니다 — 저장소에 없는 규칙은 애초에 존재하지 않습니다.

그렇다고 시스템이 스스로 쌓는 기억이 항상 나쁜 것은 아닙니다. 커밋할 가치가 없거나 커밋하면 안 되는 것 — 개인의 말투 선호, 이 기기에만 해당하는 사실 — 은 오히려 그 자리가 알맞습니다. 판별 기준은 하나입니다. 팀원이 이 설정을 그대로 물려받아도 되는가. 그렇다면 파일로, 아니라면 시스템 기억으로 둡니다. 다만 시스템 기억은 스스로 쌓이는 만큼, 가끔 무엇이 쌓였는지 직접 조회해 보는 습관이 필요합니다 — 실제로 아무 실습도 하지 않은 새 환경에서 조회했는데도 이미 레슨이 쌓여 있던 경우가 있었습니다. 사람이 시키지 않아도 쌓인다는 증거입니다.

6. 대화는 세션과 함께 사라지지만, 파일은 남는다

세션이 끝나면 그 세션의 대화 기록도 함께 닫힙니다. 다음 세션은 이전 대화를 전혀 모릅니다. 그런데도 작업을 이어가야 한다면, 남길 수 있는 것은 파일뿐입니다.

인계가 성립하려면 세 가지를 적어야 합니다.

1. 완료 — 지금까지 끝낸 일
2. 다음 할 일 — 이어서 진행할 일
3. 주의 — 지켜야 할 제약

세 가지를 파일로 남기면, 이전 대화를 전혀 모르는 새 세션도 그 파일을 읽고 다음 할 일만 정확히 실행할 수 있습니다. 그런데 이 방식이 성립하려면 전제 조건이 하나 있습니다. 양쪽 세션이 같은 폴더를 보고 있어야 합니다. 인계 문서를 쓴 세션과 읽는 세션의 작업 폴더가 다르면, 파일은 존재해도 다음 세션은 그것을 찾지 못합니다.

인계 문서의 품질이 곧 다음 세션의 품질입니다. “다음 할 일”이 모호하면 다음 세션은 넓게 해석해 과잉 실행하거나, 스스로 범위를 정해 일부만 하거나, 되묻습니다. 어느 쪽이든 쓴 사람의 의도는 보장되지 않습니다. 사람에게 인계할 때와 똑같이, 완료·다음 할 일·주의를 구체적으로 씁니다.

정리

여섯 가지는 결국 하나의 질문으로 이어집니다. 세션이 끝나도 남아야 할 것을 어디에 둘 것인가. 설정은 config로, 절차는 스킬로, 지켜야 할 규칙은 Steering이나 Hooks로, 작업 상태는 인계 문서로 — 무엇을 어디에 두느냐가 에이전트를 설계하는 일의 대부분입니다. Lab 4부터는 이 위에 지식(Knowledge)과 자동화(Loop·Schedule)를 쌓습니다.