AI Agent 스터디 1주차

week 1. Agent 설계 기초

• 대상 자료: Anthropic 「Building Effective Agents」

자료의 개념을 다시 설명하기보다, 읽으면서 어디에서 막혔는지, 그리고 아직 무엇을 답하지 못했는지를 적었음.

---

① 에이전트와 워크플로우는 뭘 기준으로 나누는가?

두 용어를 계속 섞어 쓰고 있었는데 차이를 설명해보려니 안 됐음. 에이전트를 실행 단위, 워크플로우를 그 에이전트까지 포함하는 더 큰 흐름이라고 생각했음.

원문을 읽고 나서야 둘을 크기가 아니라 다음 실행 경로를 코드와 LLM 중 누가 결정하는가로 나눈다는 걸 알게 됐음.

해당 기준을 보니, 결정적으로 정의할 수 있는 흐름은 코드가 맡고 workflow-> 사전에 정하기 어려운 판단만 agent에 위임하는 방식으로 설계해야겠다는 생각이 들었음.

개념 Note

Anthropic 원문은 둘을 다음과 같이 구분함.

• workflow — 코드가 미리 정의한 경로로 실행: orchestrated through predefined code paths
• agent — LLM이 다음 행동과 도구 사용을 동적으로 결정: dynamically direct their own processes and tool usage

둘은 포함 관계가 아니라 agentic systems 아래에 놓인 형제 개념임. 위키 0-1의 "대립이 아니라 같은 자율성 스펙트럼 위의 도메인별 분화" 도 같은 구조로 읽을 수 있음.

---

② agent loop와 feedback loop은 어떤 관계인가?

처음에는 feedback loop가 agent loop 안에서 실행 결과를 평가하고 수정하는 별도의 과정이라고 생각했음.

느낀 점

새로운 패턴을 코드에 적용한 것이 아니라, 이미 만든 코드를 설명할 언어를 뒤늦게 찾은 경우에 가까웠음. 또한 평가가 필요하다는 말을 들으면 별도의 LLM 평가자를 먼저 떠올렸는데, 우리 코드는 구조적으로 판정할 수 있는 조건을 결정적 코드로 평가하고 있었음.

개념 Note

agent loop는 실행 결과인 Observation을 다음 판단에 반영하므로 feedback loop의 최소 구현임.

• 암묵적 피드백 — 실행 결과를 다음 판단의 입력으로 되돌림
• 명시적 피드백 — 결과를 평가하고 실패 이유나 수정 방향까지 되돌림

평가자는 반드시 LLM일 필요가 없음. 성공과 실패를 결정적으로 판정할 수 있다면 규칙 기반 코드도 평가자가 될 수 있음.

더 고민해볼 점

가드레일이 요청을 차단하고 끝나면 제약 조건임. 그렇다면 판정 결과를 다음 판단의 입력으로 돌려주는 순간부터는 feedback loop의 일부라고 볼 수 있을까요?

또 실행 결과가 컨텍스트에 돌아오기만 하면 feedback인지, 실패 이유와 수정 방향까지 제공해야 명시적인 feedback이라고 할 수 있는지도 더 고민해보고 싶음.

---

③ 자율성이 높은 에이전트가 더 좋은 에이전트인가?

처음에는 자율성이 높은 에이전트가 더 발전된 형태라고 생각했음. 우선 모델에 넓은 자율성을 주고, 위험한 행동만 가드레일로 막으면 된다고 봤음.

그런데 위키의 프로덕션 사례들은 자율성을 최대화하기보다 업무 특성에 따라 제어권을 다르게 배치하고 있었음.

위키의 프로덕션 사례

• Elastic은 보안 제품의 신뢰성과 예측 가능성을 위해 실행 흐름이 고정된 통제형 그래프를 사용했음.
• Sierra는 모델이 넘을 수 없는 결정적 정책 가드레일을 두고, 작업별로 자율성의 범위를 다르게 설정했음.
• Harvey는 에이전트가 리서치를 수행하지만 중요한 판단 지점에는 변호사의 입력을 넣었음.

이 사례들을 보니 자율성이 높다고 항상 더 좋은 것은 아니었음. 에이전트의 판단이 틀렸을 때 그 사실을 검증할 수 있고 다시 되돌릴 수 있다면 자율성을 넓힐 수 있지만, 결제나 고객 커뮤니케이션처럼 실행 결과를 되돌리기 어렵다면 코드나 사람이 사전에 통제해야 했음.

느낀 점

자율성의 범위는 모델의 능력보다, 실패를 검증하고 복구할 수 있는지에 따라 달라진다고 느꼈음.

개념 Note

Bounded autonomy는 전체 파이프라인의 control flow는 workflow로 설계하고, 특정 작업의 판단과 도구 선택만 LLM에 위임하는 방식임.

위키는 자율성의 범위를 판단하는 기준을 다음과 같이 제시함.

판단 기준	통제된 workflow가 적합한 경우	자율 실행이 가능한 경우
신뢰 근거	구조의 예측 가능성과 감사 가능성	자동으로 검증할 수 있는 산출물
적합한 업무	규제·감사·일관성이 중요한 업무	테스트 등으로 결과 검증이 가능한 업무
실패 비용	결제·고객 커뮤니케이션처럼 되돌리기 어려움	샌드박스·git처럼 실패를 되돌릴 수 있음
인간의 역할	실행 중 승인·에스컬레이션	실행 후 결과 리뷰·모니터링

두 방식은 대립하는 구조가 아니라 같은 자율성 스펙트럼 위에 있음. 검증 자동화와 복구 수단이 갖춰질수록 workflow 안에서 LLM에 위임하는 구간을 점진적으로 늘릴 수 있음.

---

④ agent loop가 멈췄다는 것은 목표를 달성했다는 뜻인가?

처음에는 agent loop가 목표를 만족하면 멈춘다고 생각했음. 그런데 "목표를 만족했다는 걸 누가, 어떤 근거로 판단하는가?"를 답해보려니 막혔음.

자료를 다시 보니 루프의 종료 조건과 작업의 성공 조건은 서로 다른 것이었음. 도구를 더 호출하지 않거나 최대 턴 수에 도달하면 실행은 끝낼 수 있지만, 그것만으로 사용자의 목표가 달성됐다고 말할 수는 없음.

여기서 한 가지를 더 구분하게 됐음.

• 종료 조건은 실행을 언제 끝낼지 결정함.
• 성공 기준은 결과를 성공으로 인정할 수 있는지 결정함.

결국 기본 agent loop가 알 수 있는 것은 실행이 끝났다는 사실뿐임. 오류나 최대 턴 도달은 별도의 종료 사유로 기록할 수 있지만, 모델이 최종 응답을 반환한 경우에는 그것이 목표를 달성한 결과인지, 요건을 놓친 채 멈춘 것인지 구분할 근거가 없음. 알고 있던 "목표를 만족하면 멈춘다"는 설명은 모델이 스스로 멈춘 것을 성공으로 간주하고 있었고, 이를 검증할 방법이 빠져 있었음.

그렇다면 우리 에이전트는 지금 모델이 더 이상 도구를 부르지 않는 순간을 성공으로 취급하고 있는 걸까요? 사용자의 목표를 실제로 달성했는지는 별도로 구분할 방법이 없는 걸까요?

개념 Note

기본 agent loop는 다음과 같은 실행 신호를 보고 종료할 수 있음.

• 도구 호출이 없는 최종 응답
• 특정 구조화된 출력
• 오류
• 최대 턴 수 도달

이 조건들은 실행이 끝났다는 사실은 알려주지만 목표가 달성됐다는 사실까지 보장하지는 않음.

목표 달성을 판정하려면 작업에 맞는 성공 기준과 평가 주체가 필요함. 평가 주체는 반드시 별도의 LLM일 필요는 없음.

• 형식·상태처럼 명확한 조건: 규칙 기반 검증
• 코드 산출물: 테스트·정적 분석
• 정성적인 결과: 모델 또는 사람의 평가
• 요구사항이 불명확한 경우: 사용자 확인

평가 결과까지 실행 흐름에 연결하면 통과 → 성공 종료, 실패 → 재시도·재계획, 판정 불가 또는 예산 소진 → 실패·에스컬레이션처럼 종료 상태를 구분할 수 있음.

---

⑤ 멀티 에이전트로 왜 나누는가?

역할별로 에이전트를 나누면 각자 보는 컨텍스트가 줄어드니 기본적으로 더 효율적일 것이라고 생각했음. 그런데 컨텍스트가 국소적으로 줄어드는 것과 시스템 전체가 효율적이 되는 것을 같은 말로 보고 있었음.

그런데 위키에서 멀티 에이전트는 단순히 효율을 얻는 구조가 아니라, 단일 에이전트의 한계를 해결하기 위해 추가 비용을 감수하는 설계에 가깝다는 설명이 인상적이었음. 에이전트를 나누면 모델 호출과 지연이 늘어나고, 각 에이전트의 상태와 작업 결과를 전달하고 조율하는 과정도 필요해짐.

분리한 뒤에는 에이전트 사이의 통신 방식도 설계해야 함.

• 어떤 에이전트가 다음 작업을 맡을지 누가 결정하는가?
• 전체 컨텍스트와 구조화된 결과 중 무엇을 전달하는가?
• 판단의 결론뿐 아니라 근거와 실행 결과도 전달하는가?
• 여러 에이전트의 결과가 충돌하면 누가 조정하는가?

따라서 멀티 에이전트는 역할을 나누는 것만으로 완성되는 구조가 아니라, 분리의 기준과 에이전트 사이의 통신 방법을 함께 설계해야 하는 선택임.

개념 Note

자료는 단일 에이전트의 역량을 먼저 최대화하는 것을 기본값으로 둠. 에이전트를 추가하면 모델 호출, 지연, 상태 관리, 컨텍스트 인계에 드는 비용도 함께 늘어남.

분리를 검토할 대표 조건은 다음 두 가지임.

• Complex logic — 프롬프트의 조건 분기가 계속 늘어 템플릿을 확장하기 어려울 때
• Tool overload — 도구의 개수 자체보다 유사성·중복 때문에 선택 오류가 반복될 때

따라서 multi-agent는 더 발전된 등급이라기보다, 단일 에이전트에서 확인된 문제를 해결하기 위해 추가 비용을 지불하는 선택임.

---

아직 답하지 못한 질문

⑥ 사람의 개입이 줄어들면 비용도 줄어드는가?

처음에는 에이전트의 자율성이 높아질수록 사람의 개입이 줄어들고, 그만큼 운영 비용도 줄어들 것이라고 생각했음.

그런데 위키에서는 자율성이 커져도 감독이 사라지는 것이 아니라 위치가 이동한다고 설명했음. Agentic Workflow에서는 사람이 단계별로 승인하거나 에스컬레이션을 처리하지만, 장시간 자율 실행 에이전트에서는 시작과 종료 시점에만 관여함.

개입 횟수만 보면 장시간 자율 실행 에이전트가 더 효율적으로 보임. 하지만 단계별 승인은 자주 발생하는 대신 한 번에 확인할 범위가 작고, 종료 시점의 리뷰는 횟수는 적지만 수십 분에서 수십 시간 동안 만들어진 결과를 한꺼번에 검토해야 함. 이때 문제가 발견되면 어느 시점부터 잘못됐는지 다시 추적하고 수정하는 비용도 생길 수 있음.

그렇다면 사람의 개입 비용은 단순히 몇 번 개입했는가로 비교할 수 없는 것 같음. 한 번에 검토해야 하는 양, 작업의 맥락을 다시 파악하는 비용, 오류를 발견한 시점과 되돌리는 비용까지 함께 봐야 함.

지금의 임시 답은 결과를 자동으로 검증하고 되돌릴 수 있는 작업이라면 장시간 자율 실행이 유리하고, 중간 오류의 영향이 크거나 되돌리기 어려운 작업이라면 단계별 승인이 더 유리할 수 있다는 것임. 하지만 두 방식의 사람 비용을 실제로 어떻게 측정하고 비교해야 하는지는 아직 모르겠음.

자주 개입하되 조금씩 검토하는 방식과, 시작과 종료에만 개입하되 많은 결과를 한꺼번에 검토하는 방식 중 실제 사람의 비용은 어느 쪽이 더 클까요?

개념 Note

두 방식은 사람의 감독을 없애는가가 아니라 어디에 배치하는가에서 차이가 남.

구분	Agentic Workflow	장시간 자율 실행 에이전트
개입 방식	단계별 승인·에스컬레이션	시작·종료 시점의 정의·리뷰
개입 빈도	높음	낮음
한 번의 검토 범위	비교적 작음	비교적 큼
오류 발견	실행 도중 비교적 빠름	종료 후 늦게 발견될 수 있음
적합한 작업	중간 통제가 필요한 작업	자동 검증·복구가 가능한 작업

따라서 사람의 개입 비용을 비교하려면 승인 횟수뿐 아니라 검토량, 대기 시간, 맥락 복원, 오류 발견 지연, 재작업 비용을 함께 고려해야 함.

테스트는 독립적인 검증자인가?

처음에는 테스트를 통과하면 에이전트의 결과를 자동으로 검증할 수 있으므로, 사람이 확인해야 할 양도 줄어들 것이라고 생각했음. 그런데 에이전트가 구현 코드와 테스트를 함께 작성한다면, 테스트 통과가 무엇을 검증하는지 의문이 들었음.

테스트는 구현이 에이전트가 스스로 해석한 성공 기준과 일치한다는 것은 보여줄 수 있지만, 그 기준이 사용자의 요구와 일치하는지까지 보장하지는 못함. 에이전트가 구현뿐 아니라 자신의 채점 기준도 함께 만든 셈이기 때문임.

그렇다면 사람은 구현 코드뿐 아니라 테스트와 성공 기준까지 확인해야 함. 실제로 큰 diff에서는 구현 로직을 먼저 보고 테스트 코드를 자세히 읽지 못할 때도 있는데, 장시간 자율 실행으로 변경량이 커질수록 자동 검증이 검토를 줄이기보다 검토해야 할 대상을 넓히는 것은 아닐까 생각했음.

개념 Note

위키 0-1은 두 흐름의 신뢰 근거를 다음과 같이 구분함.

• Agentic Workflow — 워크플로우 구조의 예측 가능성과 감사 가능성
• 장시간 자율 실행 에이전트 — 테스트 통과와 PR diff 리뷰처럼 검증 가능한 산출물

장시간 자율 실행이 가능한 배경에는 다음과 같은 검증·복구 수단이 있음.

• 컴파일러와 테스트를 통한 실행 중 자동 검증
• 샌드박스와 git을 통한 실패 복구
• PR diff 리뷰를 통한 사람의 최종 확인

즉 테스트는 단순한 코드 품질 확인 수단을 넘어, 사람의 감독을 단계별 승인에서 종료 시점의 리뷰로 옮길 수 있게 하는 신뢰 근거임.