03 · STT 원문 — 에이전트, 개념부터 같이 정리해봐요

슬라이드와 대조해 읽으려면 02 발표 전사, 개념과 설계 논점은 01 개념 정리로 이어집니다.

49:11에는 turbo 전사가 약 30초를 놓친 구간이 있습니다. 그 출력은 그대로 보존하고, 같은 구간을 large-v3로 다시 전사한 결과를 해당 줄 아래 인용으로 덧붙였습니다. 본문에서 원본 출력과 보완 전사를 구분해 읽을 수 있습니다.

[00:00:00] 일단 오늘 테크 밋업 주제는 제가 에이전트 개념부터 같이 정리해보자 라는 좀 이제 어찌 보면 되게 모호한 주제를 잡았는데요. 일단 에이전트를 이 주제로 왜 테크 밋업을 열었는지 일단 배경을 설명을 드릴게요.

[00:00:18] 작년부터였죠. 작년부터 에이전트, 올해는 하네스 이런 용어들이 저희가 일상에서 아무렇지 않게 쓰고 있는데 실제로 뭔가 대화를 하다 보면 각자가 생각하고 있는 에이전트 그리고 하네스에 대한 개념이 조금 다른 것 같아서 내가 잘 이해를 못해서 이분이 얘기하는 걸 잘 못 알아듣는 건가? 아니면 내가 왔는데 이분이 틀린 건가? 이런 것들이 제가 좀…

[00:00:47] 많이 경험을 했었고 그러다가 에이전트 아키텍처라는 스터디를 하게 됐는데 거기서도 용어에 대한 이슈들이 자꾸 생기더라고요. 그래서 이 에이전트랑 하네스 그리고 여기서 계속 잇따라 나오는 용어들이 어딘가 깔끔하게 정리가 되어 있나? 그리고 공통의 개념으로 정리가 되어 있는 건가? 라고 제가 실제로 서베이를 해봤을 때

[00:01:12] 그래서 뭔가 같은 개념들을 각 벤더사나 각 아티클마다 다르게 부르고 있기도 해서 이거를 뭔가 용어에 집중하지 말고 이러한 개념들이 이런 걸 지칭하는구나 라고 좀 이야기할 수 있는 자리가 어딘가 있었으면 좋겠다라고 생각을 해서 제가 정리한 개념이 정확히 맞지 않을 수 있으나 그래도 정리하는 자리라도 있으면 이런 후속 논의가 이어질 수 있을 것 같아서 믿업을 준비를 해봤습니다.

[00:01:41] 그래서 양을 계속 줄이려고 했는데 양이 줄여지지 않아서 90분으로 잡았고요. 혹시 Q&A를 중간에 못 받을 수 있을 것 같아요. 지금 조금 타이트할 것 같아서 채팅에 남겨주시거나 혹은 이후에 메일 같은 걸로 남겨주시면 제가 취합해서 공유를 드리도록 하겠습니다. 그래서 일단 발표를 쭉 이어가 보도록 하겠습니다.

[00:02:05] 그래서 제가 이 발표에 목적이 있어야 되고 그래도 귀한 시간을 내셔서 들어오셨는데 가져가는 것들이 있었으면 좋겠어서 제가 이 발표의 목적을 두 가지로 잡아봤습니다. 첫 번째는 워크플로우와 에이전트를 구분할 수 있다. 각각이 무엇을 하는 건지 개념적으로 알고 있게 됐다. 그리고 두 번째가 하네스가 모델 밖에 어떤 구성 요소를 가리키는지 설명을 할 수 있다.

[00:02:34] 이거에 대한 초점을 뒀습니다. 그래서 오늘 다루는 게 총 크게 3장인데요. 첫 번째는 에이전트에 대해서 설명을 하고 두 번째가 하네스, 세 번째가 도구에 대해서 설명을 하고 간단하게 마무리를 짓도록 하겠습니다. 첫 번째는 에이전트에 대해서 설명을 해볼 건데요. 제가 에이전트는 이거야 라고 설명을 하는 것보다

[00:03:00] 에이전트를 이제 같이 언급을 할 때 워크플로우도 에이전트로 혼용, 혼동해서 같이 이야기가 되는 경우가 꽤 있어서 이걸 일단 개념적으로 먼저 정리를 해보려고 합니다. 일단 개념은 텍스트를 일단 가져왔는데요. 워크플로우와 에이전트, 내부에서 LLM을 다 사용하는 애들입니다. 사실은 워크플로우는 저희가 기존에 파이프라인, 워크플로우 동일하게 부르고 있던 용어이기도 한데요.

[00:03:29] LLM을 쓸 수도 있고 안 쓸 수도 있지만 내부에서 LLM을 쓰는 경우에 에이전트다라고 혼동하는 경우가 있어서 두 가지로 가져와 봤습니다. 그래서 제가 이 두 가지의 가장 큰 차이가 뭘까? 명확하게 어떤 걸로 기준을 둬야 될까라고 생각을 해봤을 때 이 다음 순서를 누가 정하느냐를 기준으로 삼으면 좋겠다라고 생각을 했습니다. 그래서 지금 있는 스테이트에서 다음 스테이트로 넘어갈 때

[00:03:59] 그 순서가 코드로 정해져 있다. 누군가 읽었을 때 이 다음에는 이런 게 진행이 되는구나라고 알고 있으면 워크플로우, 그걸 모르겠다. 코드를 봐도 그런 모델이라고 제가 정의를 내려봤습니다. 그래서 그림으로 보는 게 정확할 것 같아서 하나의 시스템을 두 가지로 풀 수 있는 걸 가져왔는데요. 만약에 같은 환불 문의를 푸는 시스템이라고 했을 때 워크플로우는

[00:04:30] 순서가 코드를 고정하게 됩니다. 그래서 좀 풀어서 설명을 해보자면 저희가 CS 환불 문의를 답변을 해주는 뭔가를 만들겠다고 했을 때 CS 카테고리를 받고 그리고 환불할 상품을 선택을 하고 문의를 작성을 할 수가 있습니다. 그래서 코드가

[00:04:50] 코드 내부로 들어왔었을 때 CS 정책 검색을 하게 되겠죠. 그래서 이 CS 카테고리를 이용해서 환불 정책 검색을 가져오고 거기에 대한 문서를 가져오고 그리고 상품 정보 조회를 가져오게 됩니다. 그래서 프롬프트에 이 정책과 이 상품 정보를 가지고 LLM에게 답변을 생성을 해서 그 답변을 유저한테 넘길 수 있겠죠. 이런 시스템이 있다고 가정을 했을 때.

[00:05:16] 이런 경우에는 워크플로우입니다. 그래서 지금 이 스테이트에 있었을 때 그 다음 스테이트가 뭔지 명확하게 읽히는 경우가 저는 워크플로우라고 생각을 하고요. 그런데 이 워크플로우는 약점이 있겠죠. 만약에 유저가 CS 카테고리를 결제로 잘못 선택을 했어요. 그런데 결제 정책 검색을 가져왔는데 문의 본문은 환불하고 싶어요.

[00:05:40] 그러면 LLM의 가장 큰 단점이죠. 할로시네이션이 발동을 해서 없는 우리 정책대로 답변을 해줄 수 있어요. 그런 부분에 대해서는 약점으로 있을 수 있고요. 에이전트는 카테고리나 상품 선택 없이 저 환불하고 싶어요라는 질의가 들어왔었을 때 최종 답변을 내부에서 저희가 코드로 정의할 수가 없습니다. 그래서 모델에 도구만 지어져요.

[00:06:09] 구매내역을 조회할 수 있는 능력, CS 정책 검색을 할 수 있는 능력, 모호하면 사용자에게 대목기를 할 수 있는 능력을 주게 됩니다. 그 능력을 통해 에이전트가 내부에서 어떠한 순서로 고정하지 않고 자기가 그때그때 판단을 하면서 구구들을 호출을 하는 거예요. 그래서 자기 생각에 이제 답변을 최종적으로 할 수 있다고 판단이 되었을 때 최종 답변을 유저에게 보내게 됩니다.

[00:06:37] 이 에이전트는 워크플로우 대비 이런 카테고리나 이런 것들이 잘못 설정이 되어 있어도 모델이 알아서 관측해서 사용자에게 되물을 수 있다. 그리고 예상답게 케이스들을 조금 더 유연하게 대응할 수 있다는 장점은 있지만 어떤 도구를 조회할지 아니면 똑같은 질의가 들어왔는데도 그때그때 이 내부 동작이 달라질 수 있다는 게 약점입니다.

[00:07:07] 워크플로우 예시는 앞서 설명을 드렸으니 패스를 하고 에이전트가 그래서 내부적으로 어떻게 동작하는지를 한 번 더 풀어봤는데요. 물론 똑같은 입력이 들어왔었을 때 무조건적으로 이 순서를 타진 않습니다. 그냥 예시를 가져온 거고요. 입력으로 저 환불하고 싶어요라고 들어왔었을 때 모델이 생각을 하겠죠. 어떤 상품인지 모른다. 구매 내역부터 봐야 된다고 했을 때 행동을 하게 됩니다.

[00:07:37] 조회에 해당되는 도구를 가져오고요. 그 도구로 호출을 했을 때 이 사용자는 최근에 티셔츠, 운동화, 모자를 구매를 했고 아직 구매 확정 정의다. 그랬을 때 모델은 또 생각을 하겠죠. 셋 중 무엇을 얘기하는지는 사용자만 안다. 그래서 데모 씁니다. 그래서 티셔츠요라고 했을 때 환불 조건을 이제 확인을 해야 된다고 합니다. 그러면 CS 정책 검색을 이용해서 환불 정책을 가져오겠죠.

[00:08:06] 그래서 7일 이내에 미개공이면 환불 가능하다라는 류의 정책이 들어왔을 때 에이전트 모델은 생각을 합니다. 티셔츠의 주문일이 9월 12일이었고 오늘은 9월 17일이니 조건을 충족했다. 그러면 답을 할 수 있다라고 해서 답변에 환불 가능하다. 접수해드릴까요? 라는 식의 답변을 하게 되겠죠. 그래서 이렇게 좀 유연하게 어떤 질의가 들어왔을까요?

[00:08:33] 이런 과정들이 빠질 수 있겠죠. 그래서 어떤 유저의 발화가 들어와도 좀 더 내부적으로는 유연하게 대응을 할 수 있지만 어떤 조회를 몇 번 하고 몇 턴을 대화할지 문의마다 다르고 심지어 같은 질의인데도 내부적으로 해결하는 방식이

[00:09:02] 그래서 디버깅을 너무 하기 힘들다는 게 단점입니다. 그래서 앞에서 워크플로우랑 에이전트를 봤는데 결국엔 에이전트는 저는 간단하게 내부적으로 그냥 와일루프라고 생각을 해요. 그냥 사용자의 요청이 들어오고 최종 응답까지 나갔을 때 내부적으로는 계속 와일루프를 타는 거예요. 모델이 도구를 부를지 추가적으로 아니면 그냥 끝내서 최종 응답을 하게 될지.

[00:09:33] 이거를 모델이 선택을 하는 거고 그 안에서는 도구를 실행하고 도구 실행 결과를 보고 또 생각하고 이 부분이 반복되게 됩니다. 그래서 에이전트의 실체는 와일루프이고 다만 2절에서 설명드릴 하네스에서는 우리가 이 시스템을 설계할 때 에이전트 내부에서 도구 구출을 한 10번 정도면 최대 바꿀 수 있을 것 같아요.

[00:10:00] 근데 모델이 조금 멍청해서 혹은 우리가 지시를 잘못 내려서 내부적으로 여러 번의 도구를 막 실행을 해요. 20번, 30번. 그래서 막 이렇게 커뮤니티나 어디에서 루프가 터진다라는 표현을 하는데요. 그래서 이 루프가 터지는 거를 시스템적으로 막기 위해 하네스에서는 최대 몇 번, 최대 도구 호출은 여기서는 10번으로 제한하겠다. 그랬을 때는

[00:10:27] 모두 모델이 이걸 판단하지 않고 시스템적으로 10번까지 호출했으면 무조건적으로 최종 응답을 내게 설계를 할 수 있습니다. 근데 이거는 뒤에서 하네스에서 아마 더 이야기가 될 것 같고요. 그래서 이제 이 와일루프 어디서 뭔가 본 것 같은데? 라고 생각을 하실 수도 있어요. 처음에 채찍 PT가 나왔을 때

[00:10:52] 프롬프트 엔지니어링, 지금은 막 컨텍스트 엔지니어링, 그 다음에 하네스 엔지니어링으로 왔지만 처음에는 프롬프트 엔지니어링이었어요. 이 프롬프트 엔지니어링에서 이제 가장 인기가 많았고 지금 채택된 게 거의 이제 리액트라는 건데요. 이 리액트는 이런 식으로 텍스트 규약을 해놓습니다. 생각을 하고 액션을 하고 관측을 하고 계속 반복하다가 파이너에 써라는 프리픽스가 나오면 이 루프는 끝난다.

[00:11:21] 라는 거를 프롬프트로 이제 했어요. 근데 현재는 이런 게 정말 유의미하니까 실제로 LLM이 이걸 학습을 한 거죠. 그래서 모델 표를 보다 보면 툴 콜링이 지연이 된다 안 된다 이런 게 있는데 그런 지연이 된 애들은 내부적으로 툴 콜링이 학습이 된 형태여서 이런 식으로 저희가 이 순서로 답변을 해야 되라는 시스템 프롬프트 없이도 사용을 할 수 있게.

[00:11:49] 그래서 이 부분을 간혹 제가 에이전트 루프를 설명을 드릴 때 이거 리액트예요? 라고 설명하시는 분들이 있어서 한번 추가로 설명을 해봤고요. 그래서 제가 여기 뒤에서 계속 이 예시를 어떤 거를 설명을 드리는 게 좋을까 앞서 환불 시스템 이런 건 너무 추상적이고 눈에 보이지 않아서

[00:12:13] 이 발표에서는 대부분의 예시를 Claude Code로 가져왔습니다. 코덱스도 똑같아요. Claude Code랑 코덱스에서 우리가 보고 있는 게 무엇인지를 설명하는 게 좋을 것 같아서 이렇게 가져와 봤는데요. 실제로 Claude Code에서 사용자가 Claude Code에 지침을 내리고 최종 답변을 얻을 때까지가 결국에는 하나의 루프라고 보시면 됩니다. 그래서 이 동그라미가

[00:12:40] 도구인 거고요. 그래서 여기서 도구는 edit이랑 dash이라는 도구만 쓰입니다. 그리고 이 도구의 결과들이 오죠. 그래서 도구를 호출하고 도구의 결과를 받고 이 과정들이 반복이 돼서 최종적으로 답변을 하게 됩니다. 그래서 저희가 아주 자주 마주치는 것들이 결국에는 그 하나가 에이전트 루프다라고 이해를 하시면 될 것 같습니다.

[00:13:12] 그런데 이제 에이전트를 설명을 해보면 에이전트가 되게 좋아 보이잖아요. 에이전트가 모든 걸 할 수 있을 것 같고 워크플로우는 우리가 귀찮게 다 분기 처리해야 되고 이렇게 생각을 해서 그럼 에이전트로 문제를 다 풀면 되겠다라고 생각을 할 수도 있는데요. 사실 저도 처음에는 그랬습니다. 에이전트가 문제 다 풀어주는데 우리가 굳이 코드로 분기를 태워가면서 해야 될까라고 생각을 했는데 제가

[00:13:40] 작년에도 비슷한 주제로 믿업을 했을 때 그때도 똑같이 말씀을 드렸어요. 우리가 화이트보드 같은데 어떠한 문제를 풀기 위해서 중기를 만약에 그릴 수 있다. 플로우를 명확하게 그릴 수 있다. 그럴 때는 워크플로우가 맞아요. 굳이 왜 에이전트를 써야 할 이유가 없는 거죠. 이렇게 불안정한데. 그래서 그런 부분들은 워크플로우가 맞고 근데 우리가 아무리 막 써도

[00:14:09] 자꾸 분기만 늘어나고 예외 케이스만 늘어나면 그걸 관리하는 게 너무 힘들다면 에이전트가 맞다라고 제가 이렇게 두 가지를 가져와 봤는데요. 근데 이것만 보면 우리 그럼 어떤 AI 이용해서 문제를 풀고 싶은데 여태까지 못 풀었던 거를 그럼 우리는 워크플로우 할래? 에이전트 할래? 라고 논의가.

[00:14:35] 되는 경우가 또 꽤 있더라고요. 근데 저는 그거 두 가지를 정하는 게 아니라 실제로 프로덕션에서는 워크플로우의 안정성, 그리고 에이전트의 유연성을 합쳐서 에이전틱 워크플로우 형식으로 많이 사용을 하게 됩니다. 그래서 파이프라인 전체는 워크플로우로 고정을 하되 판단이 필요한 구간만 에이전트에게 위임을 하는 거예요. 저희가 여태까지 발견한 확실한 엣지 케이스들.

[00:15:03] 그냥 케이스들은 워크플로우로 그냥 저렴하게 가고 추가로 판단이 필요한데 아직 우리가 조건문이나 분기 처리를 할 만한 케이스들을 덜 발견했다. 그런 것들은 이제 에이전트에게 위임할 수 있습니다. 추가로는 이거는 에이전트도 못 풀 것 같아 하면 그때 CS 담당자한테 라우팅을 하거나 이런 식으로 파이프라인을 고정을 할 수…

[00:15:32] 고정된 파이프라인 안에 에이전트에게 위임하는 구간을 만들 수도 있습니다. 그런데 또 그러면 우리는 워크플로우 안에 에이전트에게 넣어야 돼 라고 또 생각을 할 수 있는데 사실은 이거에 반대도 되는 거죠. 에이전트에게 쥐어지는 도구에 이 도구 환불 처리 안에 여기 안에서도 워크플로우 형식으로 가져갈 수 있는 거죠. 그래서 환불 처리라고

[00:16:00] 환불 처리를 해야 되는데 내부적으로 되게 복잡한 워크플로우가 필요하다고 했었을 땐 이게 모델에서는 도구 하나지만 내부적으로 되게 복잡한 워크플로우가 존재할 수 있는 거라고 생각을 해서 가져왔고요. 환불 처리 안에 내부 도구가 내부 도구 워크플로우 안에서 LLM이 여기서 사용되는 걸 예시로 가져왔어요. 이 사용자의 주문 배송을 조회해서

[00:16:28] LLM이 사유 편정을 해서 라우팅을 하게 됩니다. 물론 이거 코드화 시킬 수 있겠지만 여기서 조금 억지로 뛰어난 감이 있는데 사유 편정을 하고 이 사용자의 의도 자체가 변심이다. 그러면 반품비를 차감해야 되고 이게 하자다. 그러면 전액 당연히 환불해야 되고 오배송이면 당연히 전액 환불해야 되고 근데 실제로 에이전트한테 넘어가는 경우는 이 정도인 거죠. 리펀드가 됐고

[00:16:57] 얼마의 환불금을 줄 거다. 이런 식으로 할 수 있다고 저는 생각을 하고 있습니다. 그래서 저는 에이전트다, 워크플로우가 중요한 건 아니고 우리가 AI 시스템을 설계를 할 때 조금 더 유연하게 어느 부분은 우리가 코드로 정할 수 있는 거, 어느 부분은 아직 정할 수 없는 거 이런 것들을 나눠서 어떻게 조립할지는 시스템의 성격에 따라서 정하면 된다.

[00:17:26] 라는 거를 이 장에서 이야기를 해보고 싶었던 것 같습니다. 그래서 이제 앞에 에이전트가 뭔지 그리고 실제로 프로덕트에 나갈 때 어떤 식으로 설계를 할지에 대해서 이제 능력 기준으로 설명을 해왔는데요. 지금 이제 또 하네스 엔지니어링이 나왔어요. 이 에이전트 나온 지 제 체감상 얼마 안 된 것 같거든요. 이렇게 보편적으로 쓰게 된 지. 근데 하네스라는 게 나왔죠. 그래서 우리 대부분 다.

[00:17:55] 자 우리 하네스 엔지니어링 하자 라고는 이야기를 하는데 실제로 조금 생각이 다 다르더라고요. 그래서 이거를 좀 정리를 해왔는데요. 제가 이 하네스가 중요하다. 그때는 하네스라고 정의하지 않았는데 이거 시스템 설계하는 게 되게 중요하구나 라고 느꼈던 지점이 있어서 여기 한번 써봤습니다. 제가 이제 작년에 저희가 작년만 해서 커더를 썼고 회사 내에서 올해 클로즈 코드로 넘어왔잖아요.

[00:18:26] 근데 작년에 제가 Claude Code를 같이 쓴 회사 내에서 지원을 받아서 두 개를 동시에 쓴 경험이 있는데 그때 당시에도 오프스 똑같은 모델이었어요. 근데 커서에서 하는 거랑 Claude Code에서 하는 거랑 능력이 다른 거죠. 모델은 똑같은데. 저도 그때까지는 모델이 중요한 게 아닌가라고 생각을 했었던 것 같아요, 스스로. 근데 커서에서 Claude Code로 옮겼을 때 같은 모델을 골라도

[00:18:54] 같은 작업을 시켰는데 왜 클로우드 코드가 더 잘한다고 나는 느꼈을까? 라고 생각을 해보니 지금 생각해보니까 하네스 설계의 차이였더라. 라고 제가 느꼈던 거를 가져와 봤고 그래서 하네스 엔지니어링이 뭐야? 아니면 하네스가 뭐야? 라고 했을 때 제가 개념을 되게 많이 찾아봤는데 말하는 게 다 다르더라고요. 그래서 제가 개인적으로 와닿았던 개념, 정의를 가져와 봤는데요.

[00:19:24] AI 모델 자체 추론 능력은 제외. 그냥 그건 제외하고 AI 에이전트가 실제 업무 환경에서 안전하고 그리고 안정적으로 실행되는 주변 환경, 규칙, 보구, 검증자 정치 이걸 설계하는 정체를 통틀어서 말하는 시스템 구축 기술이라고 생각을 해요. 그래서 하네스 엔지니어링이 그냥 스킬 몇 개 추가하면 돼.

[00:19:50] 이게 아니라 전체적으로 시스템 관점에서 봐야 하는 시스템 구축 기술이라고 저는 생각을 하고 있습니다. 이게 하네스 엔지니어링 맨 처음에 나왔을 때 하네스? 약간 어색할 수 있잖아요. 하네스의 어원을 보면 뭔가 말의 마구, 고삐 이렇게 보이니까 얘의 뭔가 AI의 능력을 억누르는 역할만 하는 건가? 라고 생각할 수 있는데요. 사실 그것도 절반 정도는 맞는데.

[00:20:19] 저는 그래서 예측 불가능한 이탈을 막는 것. 이거는 AI의 능력을 억누르는 거죠. 얘가 똑똑한데 예측하지 못하게 행동을 할 수 있으니까 이탈을 막아요. 그런데 저는 그 전에 이 시스템이 올바른 방향으로 유도할 수 있게 하는 제어장치 역할을 한다고 생각을 해요. 그래서 저는 올바른 방향으로 유도하게 하는 것이 먼저고 그다음에 이탈을 막는 게 그다음이라고.

[00:20:47] 생각을 했습니다. 하네스에서 중요하게 봐야 하는 건. 그래서 하네스가 도대체 뭔데, 그래도 뭔데가 나올 수 있어요. 저도 왜냐면 그래서 뭔지 잘 모르겠는 거예요. 그래서 하네스를 구성하는 요소, 하네스 컴포넌트 이런 식으로 검색을 해봤는데 제 마음에 드는 게 너무 없었고 제가 이해한 거 바탕으로 손으로 그림을 그려서 AI에게 깔끔하게 도시카를 해달라고 한 결과가 이거인데요.

[00:21:21] 이거 말고도 더 많겠죠. 근데 제가 생각하는 중요한 것들만 가져왔고요. 이렇게 보면 설명이 너무 어렵고 와닿지 않을 수 있어서 여기에 Claude Code는 어떤 식으로 했는가를 얹혀봤습니다. 이 하네스에서 결국엔 이 Claude Code가 본인들을 에이전틱 하네스라고 부르기도 해요. 그래서 에이전틱하게 동작하는 하네스를 우린 구축한 거다라고 설명을 하는데 이 Claude Code에서 실물로

[00:21:51] 얹혀봤을 때 제가 생각하는 주요 요소들의 예가 있고요. 그래서 하나씩 설명을 간단하게 해보자면 모델은 제외한다고 했죠. 그래서 모델은 제외하되 내부적으로 루프, 아까 얘기했던 루프 같은 거 설계가 요소로 하나 들어가고요. 그리고 도구, 기본적으로 클로드 코드는 대규모 코드 베이스를 도와주는

[00:22:17] 코딩 어시스폰트 도구로서 나온 거잖아요. 그래서 그 코드의 파일을 읽고 편집하고 찾고 만약에 CLI 같은 걸 실행을 해야 되면 배시를 두고 약간 이런 기본 도구들이 얘네가 제공을 하고 사실 이것보다 지금 더 많아지긴 했거든요. 그런데 이런 도구들을 제공을 하고 실제로 MCP라는 도구를 제공을 하죠. 그러니까 MCP라는 도구를 제공하는 것보다

[00:22:44] 사용자가 커스텀하게 도구를 넣을 수 있는 프로토콜을 얘네가 제공을 한다고 보시는 게 정확할 것 같고요. 그리고 컨텍스트가 있습니다. 이 컨텍스트가 결국에는 이 하네스 엔지니어링 전에가 컨텍스트였거든요. 그러니까 원래는 프롬프트였는데 그 컨텍스트가 결국에는 중요하다고 보는 게 이번 호출에 필요한 것만 정제해서 모델에게 넘기는 거예요.

[00:23:13] 그러니까 항상 모델의 입력에는 컨텍스트로 되어 있는 텍스트가 들어가는 거고 이 컨텍스트가 계속 바뀔 수 있다는 거죠. 왜냐하면 컨텍스트는 유한하잖아요. 우리가 아무리 컨텍스트 윈도우가 지금 계속 모델이 늘어나는 추세여도 아무리 아무리 해도 유한하니까 여기에 필요한 것들만 채워서 이번 턴에 넘기는 거예요. 그런 거를 하는 게 컨텍스트 엔지니어링인 거고.

[00:23:41] 그래서 이 컨텍스트를 그럼 어떤 걸로 채우냐. 당연히 시스템 프롬프트 있을 거고요. 저희가 잘 아는. 그리고 AI가 자기가 답변한 거 있을 거고 유저가 물어본 게 있을 거예요. 그거랑 별개로 또 뭐가 있냐면 내부적으로 그 다 클로드 하위에 다 있는 것들이긴 하거든요.

[00:24:02] 실제로 들어가서 보시면 확인할 수 있는데 이거를 외부화 해놓습니다. 그래서 개인 로컬에 사용자의 로컬에 이 파일들을 다 저장을 해놓는데요. 네 가지로 분류를 해봤어요. 첫 번째가 작업 목록입니다. 그러니까 스테이트라고 부르는 것 중에 제일 명확한 게 뭐가 있을까라고 생각을 해보면 저희가 클로드에 플랫모드라는 게 있어요. 바로 에딧하지 말고

[00:24:30] 플래닝을 하라는 거죠. 그래서 이번 세션에서는 사용자가 요청한 거를 플래닝을 해보니 네 단계가 있더라. 그래서 우리가 이 네 단계를 해야 돼. 라고 이 모델이 생각을 했어요. 근데 하다 보면 사람도 똑같잖아요. 아 오늘 이거 첫 번째, 두 번째, 세 번째, 네 번째 해야지 했는데 두 번째 가다 보면 정신력이 흐려져가지고

[00:24:54] 세 번째 해야 되는데 그냥 끝내버리고 오늘 할 일 다 했다. 이런 식으로 끝내버릴 수 있잖아요. 그래서 그런 부분을 막기 위해서 플랫 모드로 했었을 때 네 단계가 있고 지금은 두 번째 단계까지 했고 그다음에 세 번째, 네 번째가 남았어. 를 내부적으로 저장을 하게 됩니다. 그래서 스테이트로 관리를 해서 두 번째 작업이 끝났다라고 판단이 되면 너 지금 첫 번째, 두 번째 이거 했고 그다음에 세 번째.

[00:25:21] 남았고 네 번째 남았어. 이런 식으로 컨텍스트에 넣어주게 된다는 거죠. 그래서 이런 스테이트라는 개념이 있고요. 그리고 트랜스크립트라고 해서 결국에는 이 하나의 세션에서 우리가 질문하고 답변하고 내부적으로 도구를 실행했고 도구의 결과가 뭐가 나왔는지 이런 트랜스크립트 파일로 제이슨 라인 파일로 외부화를 해놓습니다. 이게 있어야

[00:25:49] 그 다음에 만약에 저희가 모르고 터미널을 껐어요. 세션을 꺼버렸어요. 근데 다시 시작하고 싶잖아요. 왜냐면 또 똑같이 기억에 의존해서 질문하고 다시 답변하고 질문하고 답변하고. 근데 문제는 아까 얘기했던 것처럼 모델은 항상 똑같이 행동하지 않아요. 그러니까 그게 안 되는 거죠. 그래서 이거를 외부화를 해놓고 다시 실행할 수 있게 합니다. 그리고 메모리 디렉토리. 이게 이제 메모리라고 선이 부르는 것 중에 롱턴 메모리.

[00:26:18] 관련해서 관리를 해주는데요. 이 메모리 디렉토리는 사용자가 이전에 나랑 같이 얘기했던 것, 패션들, 이 트랜스크립트를 계속 남긴 다음에 어느 정도 주기로 여기에서 이 사용자가 나한테 이거 하지 말라고 했는데, 이거 자꾸 뭐라고 하는데 이런 것들을 다 기억을 해서 메모리 파일로 만들어놔요. 그래서 사용자가 이런 식으로 말을 했을 때 또 혼날 수 있으니 우리는 이렇게 대답을 해야 된다.

[00:26:49] 라고 우리가 클로즈닷 MD 같은데 적어놓는 게 아니라 사용자가 얘가 알아서 롱턴 메모리화를 해놓는 거죠. 사용자용으로. 그리고 그 다음이 날리지입니다. 날리지는 저희가 정말 익숙하게 계속 보던 거예요. 클로즈닷 MD나 스킬 같은 게 날리지에 해당이 되고요. 결국 이 날리지가 필요한 이유는 예를 들어보면 모델이 정말 많은 걸 학습을 했지만

[00:27:16] 우리가 실제로 알고 있는 모든 지식을 알고 있지는 못할 거예요. 예를 들어서 네이버 내부에서만 사용하는 N3R, 아니면 커넥트 이런 것들은 얘가 알 수가 없잖아요. 클로즈가 학습할 수 없는 정보들이에요. 근데 만약에 이런 것들을 지침 문서로 주지 않으면 N3R 이렇게 해서 검색을 일단 해보겠죠. N3R 검색해서 이상한 소리를 할 수 있어요. 근데 여기에 저희가 지식으로 N3R은

[00:27:44] 어떤 플랫폼이고 우리가 이걸 사용하기 위해선 어떻게 쓰면 되라고 스킬을 쥐어주죠. 이런 것들이 이제 Claude.md와 스킬, 그리고 Knowledge라고 부른다고 제가 이제 정리를 해왔습니다. 근데 혹시 이제 Claude Code 문서가 되게 잘 되어 있어요. 그걸 읽다 보면 Claude Code는 Claude.md를 구현상 메모리로 분류를 해요.

[00:28:10] 왜냐하면 세션마다 우리가 뭔가 얘기를 하는 게 아니라 세션 외부에 살아서 매 세션마다 로딩이 돼서 들어가는 거니까 메모리로 분류를 했는데 저는 이걸 정리할 때 메모리로 분류를 안 한 게 에이전트 시스템을 봤을 때 프로젝트 규칙, 작업 절차, 도메인 지식 이런 거 제공하는 게 Claude.md잖아요. 그러니까 그런 것들을 그냥 저는 말리지로 묶어서 정리를 해봤습니다.

[00:28:41] 그리고 클로우, 여기까지가 이제 우리가 에이전트를 사용할 때 알아서 조금 내 말을 찰떡같이 알아듣고 동작할 수 있게 하는 구성 요소였고요. 이 바깥에 있는 것들이 좀 제어하는 장치들입니다. 그래서 권한, 너무 잘 아시죠? 오토모드인지 승인을 받아야 되는지 아니면 도구별로 문제가 있는 도구들은 항상 실행 권한을 받는다든지 이런 권한 같은 것들이 있고

[00:29:10] 상한이 있습니다. 컨텍스트 윈도우는 제가 아까 말씀드렸듯이 유한하다고 했잖아요. 무한한 게 아니잖아요. 그랬을 때 한 80% 이상이 되면 오토컴팩트를 한다든지 내부적으로 루프가 미친 듯이 계속 똑같은 오류를 내뱉는데

[00:29:30] 도구를 계속 호출해서 루프를 터뜨려서 토큰을 먹고 비용을 먹는다든지 이런 것들에 대한 중단할 수 있는 최소한의 제어권을 얘네가 하네스 설계 요소로 담고 있고요. 그래서 사실 아 없으면 그래 알겠어 이거 있으면 좋은 거 알겠고 알겠는데

[00:29:51] 그래서 제가 생각했었을 때 가장 좋은 거는 없으면 어떻게 되는데 를 보는 게 역으로 이게 하네스에서 왜 중요한 요소인지 좀 명시적으로 이해하기 좋을 것 같아서 이걸 가져와 봤습니다. 그래서 간단하게 설명을 해보면 루프가 없으면 이름 호출해서 끝나겠죠. 그냥 사용자 질문하고 그냥 텍스트를 내뱉기만 해요. 그러면 사용자가 요청한 거에 대해서 제대로 작업을 하지 못하고 끝나게 되겠죠.

[00:30:21] 그리고 이 도구가 없으면 말만 해요. 그러니까 기본적으로 LLM은 텍스트가 들어가고 텍스트를 내뱉는 모델이잖아요. 근데 이런 액션을 할 수 있는 도구를 안 주면 말만 하고 아무것도 하지 못해요. 옛날에 TCPT인 거죠. 그리고 이 작업 목록이 없으면 이 스테이트 관리, 현재 상태의 스테이트 관리를 안 하면 어디까지 했는지 잊어버려요. 그리고 대화 이력이 없으면 직전에 어떤 대화를 했는지 기억하지 못해요.

[00:30:51] 그리고 메모리 디렉토리가 없으면 매번 처음 보는 사용자처럼 행동을 해서 맨날 혼나겠죠. 그 세션 안에서. 그리고 이 날리지가 없으면 그럴듯하게 틀린 판단을 해요. 제대로 내 환경에 적합한 지식이 없으니까 그럴듯하게 틀린 판단을 하게 됩니다. 그럼 또 혼나겠죠. 이런 것들 이렇게 되고.

[00:31:17] 권한 같은 경우에는 우리가 돌이킬 수 없는 행동들이 있잖아요. 막 배포를 한다든지 마음대로 어딘가에 위키에 문서를 올린다든지 그런 것들에 만약에 권한 같은 걸 제어를 안 해놨다면 이 에이전트에게 뭘 시켜놓고 갔어. 근데 막 위키에 문서를 미친 듯이 생성을 할 수도 있는 거죠. 그리고 배포를 계속할 수도 있는 거예요. 그런 권한은 사람한테 위임을 하게 막아놓는다. 그리고 상한 같은 경우에는.

[00:31:47] 아까 얘기했던 것처럼 이런 루프 중단 조건 같은 걸 하네스로 설계를 안 해놓으면 무한 루프에 빠지고 무한 루프에 빠지면 결국에는 토큰을 계속 쓴다는 거거든요. 그러면 이제 비용이 엄청 많이 들게 되겠죠. 그런 이슈들이 발생할 수 있어서 전반적으로 하네스에 대한 요소는 그때그때 필요한 거를 가져다 쓰면 되겠다라고 저는 정리를 했습니다.

[00:32:16] 알겠는데 조금 더 자세하게 올해 3월에 아시는 분들은 아시겠지만 Claude Code 소스가 유출이 됐어요. 그때 개발자들 신나서 소스 포크 떠서 리버스 엔지니어링을 했었거든요. 그때 저도 한 게 있는데 거기서 내가 중요하게 생각하는 게 뭐가 있을까? 라고 생각을 해서 세 가지로 가져와 봤습니다. 첫 번째는 도구 부분인데요.

[00:32:46] 이 설계가 없으면 결국에는 그 도구에 배시라는 도구가 하나 있긴 해요. 법룡적으로 쓸 수 있는 거. 이 배시는 cat이라는 명령어를 쓰면 catapi.py라는 걸 하면 읽을 수는 있어요. 근데 그 다음에

[00:33:09] 보통 이제 코드를 읽고 수정을 하는 게 어시스턴트의 역할이잖아요. 근데 캣을 출력을 했는데 어느 부분을 편집을 해야 될지 몰라요. 그래서 여기 보면 리드 했었을 때 이렇게 줄번호 딸려 나오잖아요. 이런 것처럼 리드를 한 다음에 보통 수정하는 게 맞으니까 우리가 줄번호를 친절하게 달아줘야겠다. 이런 식으로 설계를 한 거고 그리고 에딧 같은 경우에도 만약에 어떤 거 수정해줘 라고 했는데 에딧을 바로 도구로 호출을 해요.

[00:33:37] 어? 근데 너 한 번도 읽은 적 없잖아, 그 파일. 근데 어떻게 에디트를 한다는 거야? 라고 해서 도구 내부에서 이렇게 너 파일 안 읽었으니까 읽고 와서 라이팅을 해라. 라는 식으로 내부적으로 도구 설계를 합니다. 그래서 대시라는 공용으로 풀어놓을 수 있는 유연한 도구는 남기되 자주 쓰는 동작은 전용 도구로 만들었어요. 그래서 이 부분을 내부적으로 설계를 했고 그리고

[00:34:07] 실제로 그냥 도구만 지어진 게 아니라 시스템 프롬프트에 이런 것들이 있더라고요. 파일은 cat 말고 리드라는 도구를 사용해 검색은 그랩 말고 그랩 이런 식으로. 배시는 실행에만 남긴다. 이런 식으로 프롬프트로 가르쳐줬더라고요. 그래서 이런 게 우리가 조금 설계할 때 가져올 수 있는 부분이 아닐까라고 생각이 들었고요. 그리고 두 번째는 권한 문제입니다. 권한이자 도구.

[00:34:39] 문제이기도 한데요. 아까 말씀드렸던 것처럼 권한 장치가 없으면 RN-RF, 기프시플스 같이 한 번 실행했을 때 되돌릴 수 없는 액션들이 분명히 있어요. 도구들이. 근데 이런 것들에 권한 관리를 하지 않으면 그냥 에이전트가 어? 너 이거 나한테 도구 줬잖아. 그럼 알아서 막 실행을 하는 거예요. 그럼 이제 나중에 분명 문제가 생기겠죠. 그래서 저희가 이제 Claude Code 사용하다 보면

[00:35:07] 오토로 완전 풀어놓으신 분들도 있겠지만 원래 클로드 코드 초반에는 기프시 이런 거 하면 이렇게 내부적으로 룰들을 따라서 이거는 그냥 바로 실행하는 게 아니라 사용자의 승인을 받고 실행하게 만들었어요. 이런 부분에 대해서 도구별로 권한 정책을 가져갔다. 그리고 실제로 도구별로 리드하는 거 있잖아요. 읽는 거는 한 번에 여러 번 해도 되는데.

[00:35:37] 순차적으로 할 수도 있잖아요. 근데 Edit은 또 한 번에 하면 안 돼요. 막 섞일 수 있으니까. 순차적으로 해야 되는 코드 수정 작업들이 있을 수 있죠. 그런 애들은 이렇게 읽기나 검색같이 수정하지 않는 부분들은 병렬로 하되 수정해야 하는 부분들은 수정해야 하는 도구들은 순차적으로 진행을 해라. 약간 이런 식으로 내부적으로 도구, 컨트랙트 같은 걸 만들어놨더라고요.

[00:36:07] 그래서 도구에 우리가 도구 이름이랑 디스크립션, 스키마 이런 것만 있는 게 아니라 이 도구가 읽기를 하는 엔지 쓰기 하는 엔지 그리고 이 도구를 동시에 병렬로 돌려도 되는지 그리고 이 도구를 실행하기 전에는 어떠한 권한을 얻어야 되는지 아니면 그냥 문제 없이 권한 없이 그냥 실행해도 되는지 이런 도구 컨트랙트를 내부적으로 관리를 하더라고요. 이런 부분은 설계할 때 사용해서 가져와도 되겠다라고.

[00:36:37] 생각을 했고요. 그리고 클로우드 코드에서는 이게 긴 작업, 이 세션이 반드시 깨질 수 있다는 전제로 이렇게 상한 트랜스크립트 관측척을 정비한 게 있어서 가져왔는데요. 컨텍스트 창을 만약에 넘기면 세션이 죽잖아요. 그냥 대화를 하다가 컨텍스트 윈도우 넘어가서 죽어버려요. 그럼 안 되잖아요. 그러니까

[00:37:06] 창이 차면 컨텍스트 윈도우가 어느 정도 차면 대화나 도구 결과를 오토컴팩트하는 기능을 클로드 코드에서 제공을 하고 있고 그리고 파일을 수정을 해요. 저희가 아마 겪어보신 분들도 있을지 모르겠는데 저는 좀 자주 그렇긴 하는데 얘가 뭔가 파일 수정을 하고 있는데 어? 이거 수정 이렇게 하면 안 돼. 방향이 좀 잘못됐어. 그러면 저는 ESG 눌러서 인터넷을 건 다음에 수정하지 마 라고 해요. 근데 분명 도구는 실행 중이었는데

[00:37:35] 다시 파일 수정 전으로 원복이 잘 되더라고요. 그런 건 내부적으로 얘네가 어떤 거를 수정하기 전에는 체크 포인트를 내부적으로 둡니다. 그래서 그 작업이 완료되기 전까지는 이 체크 포인트를 가지고 있고요. 그리고 어제 세션을 이어서 우리가 어제까지 이제 출근해서 작업을 했어요. 근데 다 못 끝냈어요. 그래서 근데 컴퓨터를 껐어요.

[00:38:01] 근데 그 다음에 그걸 또 이어가고 싶잖아요. 그럴 때 리점이라는 기능을 제공을 하는데 이건 이제 어제 세션을 이어서 작업을 할 수 있는 거예요. 이게 되려면 외부화를 해야겠죠. 아까 말씀드렸던 것처럼 트램스크립트를 밖으로 옮겨야 돼요. 이런 것처럼 클로즈 코드는 하나의 세션에서 모든 게 이어지지 않고 다 외부화해가지고 언제든지 이어갈 수 있게 언제든지 작업을 되돌릴 수 있게 설계를 했다.

[00:38:30] 라는 게 저는 좀 배울 점일 것 같아서 우리가 AI 시스템 같은 걸 설계를 하거나 할 때 이런 부분들이 필요하다면 이런 설계를 참고할 수 있겠다라고 생각을 해서 가져왔습니다. 그래서 정리를 해보면 똑같이 좋은 시스템은 좋은 모델에서 절대 나오는 건 아니고 당연히 모델이 좋아지면 시스템 자체 좋아지겠지만 같은 모델을 두고 하넷을 어떻게 구성하느냐에 따라서 시스템의 퀄리티가 높아진다라는 거죠.

[00:39:00] 그래서 이렇게 정리를 해봤고 그런데 약간 이거는 저희가 AI 시스템을 설계하기 전에 그냥 저희 기준으로 클로즈 코드나 코덱스를 사용하는 입장에서 하네스 엔지니어링이 과연 어떤 걸 뜻하느냐. 이거를 저도 헷갈려 했거든요. 약간 모델이 똑똑해지면 하네스는 얇게 가져가야 한다. 우리는 하네스 엔지니어링을 계속해야 된다라고 하는데 제가 처음에 이걸 들었을 때 뭐를 얇게 가져가라는 건지.

[00:39:30] 그래서 이걸 한번 같이 정리해보면 좋을 것 같다라고 생각을 해서 가져왔는데요. 결국엔 예전에 조금 덜 똑똑했던 모델의 실수 때문에 Claude Code에 이런 식으로 절차를 보완을 했어요. 너 모든 코드 수정 전에 네 맘대로 수정하지 말고 계획을 먼저 작성해. 그리고 원인 후보 반드시 3개 제시해야 되고 거기서 구현 에이전트랑 검토 에이전트 따로

[00:39:59] 그리고 검토 결과를 다시 반영하고 또 검토를 하고 또 검토를 하고 이런 것들이 클로즈다 MD나 에이전트 MD에 쌓였다는 거죠. 왜냐하면 모델이 판단을 제대로 하지 못해서 저희가 판단을 할 기준을 계속 넣었던 거죠. 그런데 모델이 똑똑해지면 이런 절차들을 우리가 굳이 할 필요가 없다는 거예요. 이 절차들을 굳이 모델이 똑똑해져서 얘는 목표만 주면 할 수 있는데 이런 것들이 자꾸 있으면

[00:40:28] 또 모델 너무 똑똑해서 얘를 잘 따라요. 그러면 토큰 낭비하고 오히려 더 좋은 결과를 낼 수 있는데 결과가 예전이랑 다를 바가 없다는 거죠. 그래서 모델이 똑똑해져서 뭔가 기대를 하고 작업을 시작을 해봤는데 비슷한데? 라고 느꼈다면 이 하네스를 조금 더 정리할 필요가 있다고 생각이 듭니다. 근데 이런 거 대부분 한 번쯤은 겪어보셨을 것 같아서 제가

[00:40:57] 이 앞에 하네스, 그 클로즈다 MD는 좀 안 와닿는 분들이 많으실 것 같아서 실제로 우리가 하네스를 얇게 가져가 본 적이 있다라는 예시로 가져와 봤는데요. 저희가 그 MCP 맨 처음에 나왔을 때 OSS에 접근해서 뭔가를 할 수 있어라고 해서 그 GitHub MCP를 다 붙이셨잖아요. 근데 지금은 GitHub MCP 안 붙이고 GH 커맨드 라인으로 CLI로 지금 넘어간 분들이 많은 것 같아요.

[00:41:26] 결국에는 이유는 이거는 MCP가 보면 도구가 되게 많아요. 특정 목적별로 도구를 하나하나 세분화를 시켜놓은 거예요. 그래서 이슈만 하더라도 이슈를 생성하는 거, 이슈를 리스트업하는 거, 이슈를 가져오는 거, 이슈에 코멘트하는 거 이게 지금 다 도구로 되어 있었고 실제로 도구마다 이 이름뿐만 아니라 디스크립션, 인풋 스키마 이런 것들이 다 컨텍스트로 차질하잖아요. 근데 그게 몇십 개였어요.

[00:41:56] 근데 이거를 모델한테 매번 줬던 거죠. 근데 그때 당시에는 왜 이런 방식을 썼냐면 명령을 구성하고 결과를 처리하는 게 모델이 그때 당시에는 어려웠던 거예요. 그래서 작업별로 정해진 입력을 받는 도구를 만들어줬는데 지금은 좀 모델이 똑똑해지면서

[00:42:17] 그냥 GHCLI를 써라. 그냥 Claude.md에. 그럼 기터 작업은 GHCLI로 한다라고 써두면 이 배시라는 이미 우리가 어떠한 도구들을 주지 않아도 이 배시라는 법령 도구를 이용해서 이렇게 사용할 수 있다는 거죠. 셀프를 해서 사용법은 CLI에서 읽게 되고 이거 기준으로 명령어 CLI를 구성을 해서

[00:42:43] 자유롭게 동적으로 가공을 할 수 있는 능력이 생겼다는 거예요. 그래서 MCP, 이런 많은 도구에서 법령적인 도구 하나로, 그리고 CLI로 넘어간 게 저희가 공통적으로 겪었던 하네스를 얇게 가져간 예시라고 생각을 해서 가져와 봤습니다.

[00:43:05] 톡톡해지면 그냥 거의 이런 거 작성 안 하고 그냥 가도 되겠네. 도구 그렇게 크게 필요 없고 다 CLI 붙이고 이러면 되겠네. 근데 그것도 맞는데요. 하네스를 계속 얇게 가져가느냐. 또 그건 다른 일이죠. 실제로 페이블 5가 나왔을 때 얘가 너무 똑똑한 거예요. 일부 생물학 과제에서 전문가를 능가해요. 그래서 클로즈 코드에 페이블 붙일 때

[00:43:32] 거의 모든 생물학 질의를 차단을 했다고 합니다. 이거 말고도 혹시 저만 경험을 했던 건지는 모르겠는데 데이터 관련된 도구들을 사용을 하다 보니 페이블이 맨 처음에 너무 똑똑해서 그런가? 데이터 관련된 도구를 호출해야 할 때 그냥 자동으로 오프스로 변환이 돼버리더라고요. 약간 그런 것처럼 생물학 관련 요청이 들어왔었을 때 내부적으로 클로즈가 이런 하네스 장치를 끼웁니다. 안전분류기.

[00:44:00] 그래서 어떤 의도로 이 도구를 호출했고 호출했는지 판별을 한 다음에 조금 얘는 악의적인 의도가 없는 것 같다라고 하면 페이블 5 그대로 사용할 수 있게 하고 좀 악의적인 것 같다라고 했을 때는 오프스 5로 모델이 변경이 되게 됩니다. 이걸 아무리 페이블로 바꿔도 계속 오프스로 넘어가요. 이런 것처럼 오히려 모델이 너무 똑똑.

[00:44:28] 그래서 이 안전분류기, 이 클래시파이어 같은 경우에도 계속 엔트로픽에서도 처음엔 두껍게 가져가다가 점점 이거를 정말 의도만 잘 파악해서 이런 악의적인 의도가 있을 때만 통과할 수 있도록 이 분류기 자체도 얇게 계속 가져가려고 내부적으로 연구를 한다고 합니다. 그래서 이거는 가져와 봤고요.

[00:44:55] 그래서 이제 앞으로 우리가 어떻게 될 거냐라고 보면 얇아지는 건 모델을 보조하던 절차. 그러니까 모델이 조금 멍청해서 우리가 가이드를 줘야 되는 절차들은 계속 얇아질 건데 모델이 너무 똑똑해서 자꾸 임의로 자기가 뭔가 우회해서 하려고 한다. 그런 것들을 통제하는 층이 두꺼워질 거라고 저는 생각을 하고 있습니다. 그래서 마지막 절인데요.

[00:45:30] 제가 원래는 에이전트랑 하네스만 다루고 넘어 그냥 이번 믿업은 끝낼까라고 생각을 했는데 내부적으로 이 도구에 대한 의견들이 되게 생각외로 되게 얘기가 많더라고요. 그래서 도구에 대해서 도구가 되게 그냥 간단한 것처럼 보이는데 저는 이 도구 설계를 되게 잘해야 된다라는 생각을 가지고 있어서

[00:45:56] 이번 하네스에서 도구만 따로 빼서 이야기를 해보려고 합니다. 여기서 뒤에 MCP 이야기도 나오고 MCP랑 같이 혼동돼서 나오는 A2A 이야기도 나옵니다. 저는 이 도구가 왜 중요하다, 중요하냐라고 생각을 하냐면 에이전트에게 어떤 도구를 주느냐에 따라서 에이전트가 할 수 있는 일이 너무 달라져요. 예를 들어 클로드 코드에서도 리드하는 도구만 줬으면 파일을

[00:46:26] 읽기만 하고 어떤 식으로 수정하세요 라고 텍스트로만 줬을 거예요. 이 코드를 이렇게 바꿔보세요. 이 파일에서. 옛날에 채취피티처럼요. 근데 Edit이라는 도구를 줬죠. 그래서 이 Edit이라는 도구를 줬으니까 파일을 실제로 수정할 수 있는 권한을 얻게 된 것처럼 저는 에이전트에게 제일 첫 번째로 중요한 거는 어떤 도구를 지어줬느냐에 따라서 능력이 되게 달라진다고 생각을 합니다. 그래서 모델에게 똑같이.

[00:46:53] 환불하고 싶어요라는 문의가 들어왔었을 때 만약에 도구 집합이 조회하는 것만 있다면 가이드만 줄 수 있겠죠. 7일 이내에 미개봉이라 환불 가능하니까 어디 어디 들어가서 어떻게 어떻게 환불하세요라는 가이드는 줄 수 있겠죠. 근데 만약에 여기에 환불 처리를 실제로 대행해서 할 수 있는 도구가 들어온다면

[00:47:19] 이렇게 이렇게 환불 가능한데 혹시 환불 처리 해드릴까요? 라고 했을 때 사용자가 나 환불 처리 대신 해줘 라고 하면 환불을 실제로 실행까지 할 수 있다는 거죠. 그래서 저는 모델을 이런 거는 모델을 더 똑똑하게 만들어도 이런 행동은 생기지 않는 거잖아요. 그래서 모두 도구 집합이 곧 에이전트가 할 수 있는 행동의 범위이기 때문에 뭔가 우리가 AI 이용해서

[00:47:47] 어떤 문제를 푸는 프로덕트를 만들고 싶다 했을 때 어떤 문제를 풀 건지 그리고 이 문제를 풀기 위해서 어떤 도구가 필요한지 좀 더 에이전틱하게 저희가 만들어보고 싶어 하잖아요. 그랬을 때 어떤 도구가 필요한지를 리스트업을 하는 게 저는 가장 첫 번째라고 요즘에 느끼고 있어서 이걸 가져와 봤습니다. 근데 사실은 저희가 만약에 AI 시스템을 만든다고 했을 때 이 구매내역 조회, CS 정책 검색, 환불 처리.

[00:48:16] 이런 것들 사실 정책 검색은 애매하지만 이런 거 다 내부적으로 API로 따져 있잖아요. 그래서 또 질문이 들어올 때가 있습니다. 그러면 API에 랩핑해가지고 그냥 디스크립션이랑 인풋 스키마만 주면 도구 아니야? 라고 생각을 하시는 분들이 있는데 일부 맞는 말이긴 합니다. 실제로 맞아요. 그렇게 해도 돌아가는데 저는

[00:48:44] 기존 API랑 도구의 가장 큰 차이점은 API는 호출을 사람이 쓴 코드가 불러요. 처음 API 명세를 읽고 우리가 코드를 따서 그 코드가 한번 맞게 개발하면 이 API 호출하는 거 문제가 없다는 거예요. API 스펙이 바뀌지 않는 이상. 근데 에이전트의 도구는 호출자가 모델이에요. 얘는 이 도구의…

[00:49:11] 그래서 그걸 읽어서 모델에게 전달을 합니다. 모델이

large-v3 재전사(48:43–49:49): 저는 기존 API랑 도구의 가장 큰 차이점은 API는 호출을 사람이 쓴 코드가 불러요. 처음 API 명세를 읽고 우리가 코드를 짜서 그 코드가 한 번 맞게 개발하면 이 API 호출하는 거 문제가 없다는 거예요. API 스펙이 바뀌지 않는 이상. 근데 에이전트의 도구는 호출자가 모델이에요. 얘는 이 도구의 응답이나 이런 걸 잘 몰라요. 어떤 의미, 어떤 거를 뜻하는지 잘 모른다는 거죠. 그래서 에이전트의 도구의 호출자는 모델이다라는 거를 항상 명심했으면 좋겠다라고 적어왔는데 이거를 보는 이유가 저희가 모델에 컨텍스트로 넣을 때 도구의 명세를 넣고 실제로 사용자가 환불하고 싶어요라고 질문을 하잖아요. 그래서 그걸 읽어서 모델에게 전달을 합니다. 모델이 도구 목록을 보고 하나 골라요. 그래서 이 도구 결과를 보고 컨텍스트로, 컨텍스트로 담은 다음에 모델이 어, 나 그 다음

[00:49:41] 도구 목록을 보고 하나 골라요. 그래서 이 도구 결과를 보고 컨텍스트로 담은 다음에 모델이 나 그 다음에 어떻게 행동하지? 이 루프를 계속 판단 말이에요. 그래서 첫 번째는 제일 중요한 건 도구 명세. 도구 명세를 읽고 모델이 필요한 도구를 고르기 때문에. 그리고 두 번째는 성공이든 실패든 응답이 다음 행동을 정해요. 그래서 이 응답을 잘 설계를 해야 된다라고 생각을 하고요.

[00:50:10] 그리고 명세도, 응답도 다 컨텍스트를 차지하고 유한함으로 좀 불필요한 정보들을 삭제해야 된다라는 게 그게 필요하다고 생각을 합니다. 그래서 실제로 구글을 설계를 할 때

[00:50:28] 이미 동작하는 것들이 있어요. API 내부나 DB 조회나 이미 구현된 층이 있을 거란 말이에요. 분명. 근데 그때 우리가 어떤 걸 설계해야 되느냐. 기본적으로 네임 디스크립션 인포 스키마 알겠어. 이 API 이용할 때 이 도구한테 이 도구가 어떤 도구인지 디스크립션 작성하고 어떻게 채워야 되는지 스키마 주는 거 알겠어. 근데 그거 말고도 저는 제일 중요하게 생각하는 거는 리스폰스. 응답이 어떻게 내려갈래? 그리고 에러.

[00:50:58] 어떻게 내려갈래? 이 에러를 보고 그다음에 내가 도구 호출 잘못했으니까 에러를 보고 그다음에 어떻게 또 행동을 할지 모델이 정하잖아요. 그런 부분에 대해 설계를 잘 해줘야 된다고 생각을 합니다. 그래서 보면 예시를 하나 가져와 봤는데요. 오류 코드 관련해서 사용자가 최근 3개월 구매 내역을 확인해 주라고 했어요. 그런데 이 도구는 내부적으로

[00:51:28] 리소스 이슈 때문에 한 번에 최대 7일만 조회할 수 있는 도구라고 가정을 해볼게요. 근데 만약에 이 오르 코드만 이렇게 이 104라는 코드만 반환을 했어요. 근데 원래 사람이 짜던 코드는 내부적으로 커뮤니케이션을 하면서 아니면 혹시 문서에 이 104가 뭐예요? 라고 했을 때 아 이거 어떤 뜻이에요? 7일만.

[00:51:53] 조회해야 돼요. 하면서 저희가 이 에러 코드에 대한 그다음 분기를 태우겠죠. 근데 모델은 모르는 거예요. 이게 뭔지. 그래서 같은 요청을 다시 무의미하게 부르거나 실패했습니다로 끝내요. 그래서 제대로 어떻게 무엇을 바꿔서 호출해야 되는지 모델은 알 수 없는 거죠. 그래서 리스폰스를 이렇게 고치면 더 좋은 도구로서 설계를 한 거다라고 제가 예시를 가져온 게 에러 코드를 조금 더

[00:52:23] 사람이 봐도 직관적이게 에러 코드를 설계를 하고 메시지로 그 다음 행동을 어떻게 하면 좋을지 힌트를 주면 제일 좋다라고 생각을 합니다. 그래서 이 에러 코드 그냥 데이터 레인지 투라지. 약간 이것만 주는 게 아니라 메시지로 조회 기간을 7일 이하로 나누어서 다시 호출하세요. 하면 모델이 아 이거는 7일 이하로 나눠서 부르면 되겠구나. 라고 생각하고 응답만 읽고 스스로 고치게 됩니다. 그래서 에이전트 도구에서는

[00:52:52] 복구에 필요한 조건을 응답이 주는 것까지 저는 도구 설계라고 생각을 했습니다. 이거 말고도 사실 되게 뭐가 많아요. 도구를 설계할 때 고려하면 좋을 것들이 많은데 다섯 가지로 제가 가져와 봤습니다. 첫 번째는 도구 하나의 크기예요. 만약에 예를 들어서 저희가 캘린더에 어떤 일정을 추가할 수 있는 액션이 가능한 에이전트를 만든다고 했을 때 도구 내에

[00:53:21] API는 이렇게 따질 수 있거든요. 유저의 아이디를 가져오고 캘린더의 아이디를 가져온 다음에 그 다음에 이 캘린더 아이디 기준으로 일정을 등록하는 도구를 분리할 수는 있죠. 근데 만약에 이 GetUserID와 GetCalenderID가 다른 액션에서 활용되지 않고 정말 그냥 이 일정을 등록하는 데에만 필요하다면

[00:53:47] 굳이 이렇게 나눌 필요는 없다는 거예요. 굳이 아토믹하게 나눌 필요는 없고. 왜냐하면 이 순서를 항상 모델이 추론을 해야 되고 그 과정에서 토큰을 소비하게 되니까. 그래서 이렇게 되면 더 좋겠다라고 제가 베스트 케이스를 가져온 게 크리에이트 이벤트라는 걸 가져오고 작업 단위 하나로 셋을 안에서 부게 설계를 하는 게 더 좋은 설계다라고 정리를 해왔봤고요. 그리고 두 번째가 선택입니다.

[00:54:16] 가장 많이 일어나는 거예요. 저도 그랬거든요. 저도 약간 개발자로 일을 하다 보니까 보고 펑션 이름을 굉장히 불친절하게 하는 습관이 있었어요, 저도. 그래서 막 get 데이터, patch 데이터, load 데이터 이런 것들이 있는데 비슷한 것 중에 아무거나 고르게 되겠죠, 당연히. 그래서 불러보고 어, 이거 아니네? 그러면 그 다음에 patch 불러봐야지. 그 다음에 load 불러봐야지.

[00:54:44] 이런 식으로 토큰을 불필요하게 낭비를 한다는 거죠. 그래서 가장 좋은 건, 뭐, Get, Perchase, History, 이런 것처럼 이름이랑 설명만 읽고 명확하게 다른 도구다라는 걸 알 수 있는 게 제일 좋고요. 이거는 아마 많이 겪어보셨을 거예요. 그리고 복구는 아까 얘기한 것처럼 똑같은 거여서 넘어가고요. 그리고 출력입니다. 실제로 컨텍스트 윈도우는 유한하기 때문에

[00:55:12] 이 5,000권, 만약에 우리가 구매내어 키스토리를 가져올 때 5,000권을 내려주는 만약에 API를 랩핑해서 그냥 제공을 했다고 할게요. 근데 이 5,000권이 필요하진 않잖아요. 근데 컨텍스트 윈도우는 불필요하게 잡아먹어요. 그러니까 이런 것들을 리밋이나 필터 기능을 달아서 도구를 제공을 하든지 그리고 결과에 이렇게 불친절하게 이게 뭐지? 약간 약어로 이렇게 뜻을 모르는 응답을 내려주면

[00:55:41] 모델이 그냥 대충 유추해가지고 해독을 하게 되겠죠. 그러면 그 다음 행동에 영향이 가게 되겠죠. 그래서 이렇게 읽히는 값으로 친절하게 내보내줄 필요가 있다라고 저는 이제 가져와 봤고 그리고 부작용인데요. 만약에 이제 이건 리드는 아니고 라이트 할 때 도구 설계입니다. 실제로 에이전트가 나를 대신해서 액션을 해줄 때

[00:56:07] 크리에이트 오더라는 주문을 생성하는 도구가 있다고 했을 때 뭔가 이슈가 있었어요. 이 도구를 실행하다가 중간에서 문제가 돼서 세일됐다고 떨어졌는데 이걸 만약에 재시도를 했었을 때 그래도 안전한가. 저희가 기존의 API 설계했을 때랑 비슷한 건데 그래서 재시도가 중복 실행되지 않도록 일부 반영된 건지 이런 것들을 좀 더 생각을 기존에 설계했던 대로 하면 좋겠다라는.

[00:56:36] 이거를 좀 이렇게 가져왔고요. 제가 이걸 가져온 게 제 생각으로 가져온 건 아니고 그 엔트로픽이 그 라이팅 이펙티브 툴스라는 걸로 아티클을 엄청 친절하고 길게 냈어요. 그래서 이거를 보면 저 내용들이 다 나오는데 심지어 얘네는 고구를 하나의 펜컷셋으로 측정해서 반복적으로 계속 릴리지 할 때마다 고치더라고요. 그 디스크립션, 네임, 응답 구조.

[00:57:05] 이런 것들을 내부적으로 이렇게 루프를 돌리면서, 루프를 돌린다기보다 릴리즈 할 때마다 평가를 하면서 수정을 해서 릴리즈를 한다고 합니다. 그래서 저희가 이제 잘못, 저도 맨 처음에 잘못 알고 있었던 건 그냥 도구정의 한번 쓰고 그냥 그대로 배포해서 잘 동작하면 되는 거 아닌가라고 생각할 수 있는데 실제로 모델이 아까 하네스에서 얘기했던 것처럼 원래는 모델이 조금 똑똑하지 못해서

[00:57:34] 디스크립션에 주절주절주절 한 10줄, 20줄 디스크립션 썼어요. 너 이거 부를 때 이거 생각해야 되고 이거 생각해야 되고 이런 식으로 썼는데 모델이 똑똑해지면 그 도구 디스크립션 같은 것도 조금 더 얇아져도 된다는 거죠. 그 정도만 있어도 충분히 얘가 알아서 부를 수 있으니까. 그래서 반복해서 고치는 대상이 도구도 포함이 된다는 거를 말씀을 드리고 싶었던 것 같고요. 근데 이것뿐만 아니라

[00:58:03] 아까 Claude Code도 보면 내부적으로 도구 컨트랙트를 관리를 한다고 했죠. 그래서 저희도 만약에 이제 도구 같은 거에 그냥 네임이랑 디스크립션만 응답, 에러 이런 것만 관리하는 게 아니라 거기에 위에 얹어서 이런 실행 정책을 붙이면 나중에 좀 더 우리가 권한 제어하거나 할 때 좋겠다라고 생각을 해서 필수적인 것만 가져왔습니다.

[00:58:33] 읽기만 하는 도구인지 쓰기만 하는 도구인지 그리고 병렬이 가능한 도구인지. 근데 여기서는 병렬이 yes or no만 있는데 혹시 병렬로 호출할 수 있다면 최대 몇 개를 동시에 호출할 수 있는지까지도 컨트랙트로 관리가 되면 좋겠다라고 생각을 하고 있고 그리고 권한도 항상 사용자한테 뭔가 승인을 받고 실행해야 하는 도구인지까지도 정책으로 붙으면 좋겠다.

[00:59:02] 라고 이렇게 정리를 해왔습니다. 물론 이거는 컨트랙트는 당연히 어떻게 관리하느냐에 따라서 달라질 것 같고 추가로 필요한 메타들은 더 있을 수 있을 것 같습니다. 그리고 제가 이제 MCP를 가져와 봤는데요. 그 MCP 도구랑 MCP에 대해서 조금 헷갈려하는 분들도 있고 저도 사실 원래 엄청 헷갈렸던 부분이라 저희가 AI 시스템을 설계해야 하는 관점에서

[00:59:38] 한번 가져와 봤습니다. 만약에 이제 이건 예시예요. 회사 내부 이런 진행되고 있는 과제는 아니고 그냥 이제 쇼핑 어신스턴트, 그러니까 에이전트, 고객센터 에이전트 같은 것들이 있을 때 내부적으로 만약에 똑같은 도구들이 필요해요. 근데 이 도구들이 조직 내에 이미 여기 조직별로 API가 따져 있는 거예요.

[01:00:03] 그래서 우리 이거 에이전트 개발할 때 이 API를 랩핑하고 설명도 예쁘게 달고 입력 스키마도 달고 해가지고 직접 이 에이전트 조직에서 관리를 하게 됩니다. 이 고객센터도 똑같이 이런 식으로 관리를 했어요. MCP가 없을 때는. 근데 만약에 구매 조직의 API가 바뀌었어요. 그러면 내부 실행 동작이 바뀌어서 여기 수정해야 됐을 때

[01:00:31] 여기 에이전트에서 여기 에이전트에서 직접 개발하고 직접 관리를 해야 되는 포인트가 생기는 거죠. 근데 MCP를 두면 어떻게 되냐면 쇼핑 어시스턴트랑 고객센터 어시스턴트 이 에이전트들은 실제로 이 도구의 내부를 관리할 필요는 없고 구매 조직, 환불 조직, 배송 조직별로 MCP 서버를 둬서 내부적으로 관리를 하는 거예요. 그러니까 도구를 만들고 설명을 관리하고 응답을 제어하는 게 쓰는 쪽이 아니라

[01:01:02] 관리하는 쪽으로 옮겨가게 될 수 있게 된 거죠. 사실 이 에이전트를 만드는 조직이나 지금 이 API를 가지고 있는 조직이랑 보통 다를 수 있잖아요. 그런 경우에는 이렇게 MCP로 내부에서 관리를 하고 내부 변경 사항은 내부에서 그냥 수정을 하고 배포를 하고 이 에이전트들은 어떤 도구를 사용할지 어떤 MCP를 가져올 수 있을지 그것만 판단해서

[01:01:31] 가져오면 되는 역할을 해주는 게 MCP라고 저는 AI 시스템을 만약에 설계를 한다고 하면 이렇게 이해를 하는 게 좋을 것 같습니다. 근데 이게 보니까 비슷하게 작년에 엔트로픽이 MCP 내고 엄청 핫해지고 하니까 구글에서 급하게 A2A라는 프로토콜을 냈어요. 근데 이게

[01:01:57] MCP나 A2A랑 비슷하게 생각하는 경우가 있어서 요거를 한번 길게는 못 다룰 것 같고 짧게 가져와 봤는데요. 만약에 같은 요청이 들어와요. 배송이 너무 늦는데 취소하고 환불받을 수 있을까라는 거를 부르면 MCP한테 기대하는 거는 이 부분이라는 거예요. 이 주문의 배송 상태를 조회할 수 있는 기능. 그래서 특정 기능 실행을 기대하는 거죠.

[01:02:24] 그래서 에이전트가 이 MCP의 도구를 호출했었을 때 이 도구의 결과가 그대로 오게 됩니다. 스키마대로. 근데 A2A는 애초에 프로토콜의 전제는 어떠한 에이전트에게 목표를 위임하는 거예요. 그래서 약간 이런 식으로 취소 환불이 가능한지 확인하고 가능하면 동의를 받아서 진행을 해줘라.

[01:02:54] 자기 도구와 자기 루프와 본인 컨텍스트를 가지고 있는 별도의 에이전트라는 거죠. 그래서 이 에이전트가 판단한 결과만 가져오는 거고 실제로 이 에이전트 B가 어떠한 생각으로 어떠한 과정으로 최종 결과를 냈는지는 이 에이전트는 알 수가 없어요. 그래서 정말 믿고 맡기고 작업을 위임할 수 있는 경우에만 A2A를 쓰는 게 저는…

[01:03:23] 그런 이제 다른 점이 있다라고 분리를 해야 같습니다. 네, 그래서 생각보다 좀 빨리 끝났는데 마무리는 그냥 이제 혹시 여기 들으시는 분들 중에서 에이전트 시스템을 설계할 때 어떠한 질문들을 들고 가면 좋을까를 제가 4개 정도로 리스트업을 해봤는데 이거는 제가 발표자료 위키에 올려뒀으니 그거 한번 혹시 필요하실 때 꺼내보시면 좋을 것 같고요.

[01:03:50] 저는 결국에는 이 발표에서 말씀드리고 싶었던 건 에이전트는 모델이 다음 행동을 선택하는 시스템이고 실행 경로를 미리 그릴 수 있으면 굳이 에이전트를 쓰지 않는 게 비용적인 측면에서 맞는 프로젝트고 그리고 모델은 생각하지만 하네스가 일하게 만듦으로 물론 어느 정도 적당한 좋은 모델이 필요하긴 하겠지만 이 하네스를 설계하는 거에도 우리가 관심을 가지면 좋겠다라고 오늘 말씀을 드리고 싶었던 것 같아요.

[01:04:19] 사실 오늘 제가 얘기한 게 어떤 분들은 내가 이해하고 있던 거랑 다른데? 라고 생각하시는 분들도 있을 것 같아서 걱정이 되는데요. 그냥 피드백을 메일로 메신저로 주셔도 되니까 그 피드백은 마음껏 주시면 될 것 같습니다. 그래서 일단 오늘은 이렇게 맞춰보고요. 식단이 조금 남아서 혹시 채팅으로 질문 주실 게 있으면 질문을.

[01:04:48] 주시면 될 것 같고 없으면 요거는 이제 끝내고 혹시 개인적으로 질문을 해주시면 될 것 같습니다. 막 올라온 것도 없고 계속 기다리긴 좀 모호해서 나중에 유니에 녹화 돼서 올라갑니다. 그리고 요거 참고로 제가 시간이 날 때 오늘 얘기했던 거를 텍스터로 풀어서 위키에 공유를 하긴 할 거예요. 그래서 혹시 오늘 얘기했던 것 중에 제가 막

[01:05:20] 임의로 발표하면서 뺀 부분이 있을 것 같아서 그건 조금 더 친절하게 풀어서 텍스트로 공유를 하도록 하겠습니다. 그러면 오늘 발표 들어주셔서 감사하고 이상으로 발표를 마치겠습니다. 감사합니다.