스스로 판단하는 프로그램을 언제, 어떻게 세울 것인가

1.1 워크플로냐 에이전트냐 — 고정 파이프라인이 이기는 순간

워크플로(workflow)는 개발자가 미리 짜 둔 순서대로 모델을 호출하는 방식이고, 에이전트(agent)는 모델이 스스로 다음 행동과 도구를 고르며 목표까지 경로를 정하는 방식입니다. 판단 기준은 단순합니다. 처리할 일의 단계가 미리 정해져 있고 입력마다 흐름이 크게 달라지지 않는다면, 고정 파이프라인이 더 빠르고 비용도 예측됩니다. 반대로 어떤 단계가 필요한지 실행 전에 알 수 없고 중간 결과에 따라 경로가 갈린다면 에이전트의 자율이 값을 합니다. 자율은 공짜가 아니어서 호출 횟수와 지연이 늘고 결과의 편차도 커집니다. 먼저 워크플로로 풀리는지 따져 보고, 안 될 때만 자율을 얹는 순서가 안전합니다.

1.2 에이전트의 핵심 루프와 설계 패턴 — 도구 사용 루프·메모리·컨텍스트 관리

에이전트의 뼈대는 도구 사용 루프(tool-use loop)입니다. 모델에 목표와 쓸 수 있는 도구 목록을 주면, 모델이 도구 호출을 결정하고 실행 결과를 다시 모델에 넘겨주는 과정을 목표가 끝날 때까지 반복합니다. 이때 두 가지가 관건입니다. 하나는 메모리(memory)로, 여러 차례의 호출을 넘나들며 지금까지 한 일과 알아낸 사실을 남겨 두는 장치입니다. 다른 하나는 컨텍스트 윈도우(context window, 모델이 한 번에 참고하는 정보의 범위) 관리입니다. 루프가 길어질수록 지난 결과가 쌓여 창이 가득 차므로, 중간 요약으로 줄이거나 오래된 내용을 걷어 내거나 큰 자료는 밖에 두고 필요할 때만 불러오는 식으로 다뤄야 합니다.

1.3 매니저-서브에이전트 계층으로 작업을 나누기

복잡한 일은 하나의 에이전트가 끝까지 붙들기보다, 매니저(manager) 에이전트가 일을 쪼개 여러 서브에이전트(subagent)에게 나눠 맡기는 편이 낫습니다. 매니저는 목표를 하위 작업으로 나누고, 각 서브에이전트에 좁은 역할과 자기만의 컨텍스트 윈도우를 줍니다. 이렇게 하면 서브에이전트마다 깨끗한 창에서 자기 일에만 집중하고, 한 갈래가 실패해도 다른 갈래로 번지지 않으며, 독립적인 작업은 나란히 실행할 수도 있습니다. 마지막에 매니저가 각 결과를 모아 하나의 답으로 정리합니다. 다만 계층을 깊게 쌓을수록 호출과 조율 비용이 늘어나므로, 정말 나눌 만한 일에만 계층을 세우는 절제가 필요합니다.

1.4 Claude Agent SDK와 커스텀 루프·하네스로 에이전트 만들기

Claude 에이전트를 만드는 길은 크게 둘입니다. 하나는 Claude Agent SDK를 쓰는 것입니다. 도구 사용 루프, 컨텍스트 관리, 서브에이전트, 훅 같은 골격을 미리 갖춰 두어 개발자는 도구와 지침을 정의하는 데 집중하면 됩니다. 이 SDK는 Claude Code의 얼개에서 나온 검증된 루프를 씁니다. 다른 하나는 커스텀 루프(custom agent loop) 또는 하네스(harness)를 직접 짜는 것입니다. Messages API 위에서 반복문을 짜, 모델이 내놓은 tool_use 응답을 읽어 도구를 실행하고 결과를 다음 호출에 넣는 과정을 손수 구현합니다. 자유도는 최고지만 재시도·오류 처리·기록 관리 같은 배관을 모두 스스로 책임져야 합니다.

1.5 훅으로 결정론적 동작 보장하기

모델의 판단은 확률적이어서, '매번 반드시 이렇게 하라'는 규칙을 지침에만 맡기면 가끔 어깁니다. 훅(hook)은 이 틈을 메웁니다. 에이전트가 작동하는 동안 정해진 시점 — 도구를 부르기 직전과 직후, 세션이 시작하거나 끝날 때 등 — 에 개발자가 심어 둔 코드를 반드시 실행하는 장치입니다. 모델의 선택과 달리 훅은 조건이 맞으면 언제나 같은 동작을 하므로, 결정론적(deterministic, 같은 입력에 늘 같은 결과) 보장이 필요한 일에 씁니다. 위험한 명령을 실행 직전에 가로막거나, 모든 도구 호출을 기록으로 남기거나, 산출물의 형식을 검사해 어긋나면 되돌리는 식입니다. 지침으로 '부탁'하는 대신 훅으로 '강제'하는 셈입니다.

1.6 배포 모델과 추상화 프레임워크

에이전트를 어디서 실행할지도 설계의 일부입니다. 자체 호스팅(self-hosted)은 회사 인프라에서 실행 환경을 직접 운영하는 방식으로, 데이터가 밖으로 나가지 않고 망·비밀키·확장을 전부 통제하지만 운영 부담도 팀이 집니다. 반대로 Anthropic이 관리하는(managed) 실행 환경에 얹으면 구축과 운영이 가벼워지는 대신, 실행이 관리형 서비스를 거칩니다. 데이터 주권과 규정 요건이 무거운 조직일수록 자체 호스팅으로 기웁니다. 여러 단계를 엮는 일에는 추상화 프레임워크가 쓰입니다. Strands, LangGraph, PydanticAI 같은 라이브러리는 상태·분기·타입이 붙은 출력 같은 골격을 API 위에 얹어, 복잡한 흐름을 그래프나 상태 기계로 정리하게 돕고 대개 특정 모델 제공자에 매이지 않습니다.

! 흔한 함정

• 에이전트가 늘 더 낫다고 여기는 것 — 단계가 정해진 일에 자율을 얹으면 비용·지연·결과 편차만 커집니다. 워크플로로 풀리는지 먼저 따지는 것이 정석입니다.
• 지침에 '반드시 ~하라'고 적으면 모델이 지킬 거라 믿는 것 — 모델 판단은 확률적이라 어길 수 있습니다. 꼭 지켜야 할 규칙은 훅으로 강제해야 합니다.
• 서브에이전트를 잘게 나눌수록 좋다고 여기는 것 — 계층이 깊어질수록 조율 비용과 호출 수가 늘어, 정말 나눌 만한 일에만 써야 합니다.
• 컨텍스트 윈도우를 무한한 기억으로 착각하는 것 — 루프가 길어지면 창이 가득 차 오래된 정보가 밀려납니다. 요약이나 외부 메모리로 관리해야 합니다.