에이전트의 본체는 코드가 아니라 '로그'였다

AI 에이전트를 만들어 본 분이라면 이런 경험 있으실 겁니다. 코드는 멀쩡한데 에이전트가 왜 그런 결정을 내렸는지 도무지 모르겠는 순간이요. 그런데 최근 개발자 커뮤니티에서 “에이전트의 본체는 코드가 아니라 로그”라는 도발적인 관점이 등장했습니다. 발상을 뒤집는 이 이야기, 오늘 같이 뜯어보겠습니다.

솔직하게 먼저 밝히자면, 이 주제는 아직 커뮤니티 대규모 토론으로 번진 단계는 아닙니다. 지난 30일간 레딧이나 해커뉴스에서 활발한 스레드는 거의 없었는데요. 다만 지난 6월 AI Engineer 컨퍼런스에서 Omnara의 이샨 세갈(Ishaan Sehgal)이 발표한 “The Log Is The Agent” 세션이 조회수 4천 회를 넘기며 조용히 관심을 끌고 있습니다. 아직 무르익지 않았기에 오히려 지금 짚어둘 가치가 있는 얘기입니다.

우리는 왜 에이전트를 ‘코드’라고 착각하는가

일반적인 개발에서는 코드가 곧 프로그램입니다. 함수를 짜면 그 함수가 하는 일이 정해져 있죠. 입력이 같으면 출력도 같습니다. 예측 가능합니다.

그런데 LLM 에이전트는 다릅니다. 같은 프롬프트를 넣어도 매번 다른 경로로 움직입니다. 어떤 도구를 부를지, 몇 번 반복할지, 중간에 방향을 틀지가 실행 순간에 결정됩니다. 즉 코드는 에이전트의 ‘가능성’만 정의할 뿐, 실제로 무슨 일이 벌어졌는지는 담고 있지 않습니다.

여기서 핵심 발상이 나옵니다. 에이전트가 실제로 ‘한 일’은 코드가 아니라 실행 과정에 남은 흔적, 즉 로그에 있다는 겁니다. 어떤 판단을 했고, 어떤 도구를 불렀고, 무슨 결과를 받았는지의 시간순 기록. 그것이 그 순간의 에이전트 그 자체라는 거죠.

‘로그가 본체’라는 말의 진짜 의미

이걸 좀 더 실감 나게 풀어보겠습니다. 세 가지 층위로 나눠서 생각하면 이해가 쉽습니다.

첫째, 재현성입니다. 에이전트가 이상하게 굴었을 때, 코드만 봐서는 원인을 못 찾습니다. 하지만 그 실행의 로그를 그대로 다시 재생하면 어디서 어긋났는지가 보입니다. 버그를 잡는 단위가 ‘코드 라인’이 아니라 ‘실행 기록’으로 옮겨가는 겁니다.

둘째, 상태(state)입니다. 전통적 프로그램은 변수에 상태를 담습니다. 에이전트는 지금까지의 대화와 도구 호출 이력, 즉 로그 전체가 상태입니다. 다음 행동을 결정하려면 로그를 통째로 다시 읽어야 합니다. 로그를 잃으면 에이전트는 자기가 누구였는지 잊어버립니다.

셋째, 정체성입니다. 두 에이전트가 똑같은 코드로 돌아가도, 서로 다른 로그를 쌓았다면 완전히 다른 존재가 됩니다. 한쪽은 고객 환불을 처리 중이고 다른 쪽은 코드를 리뷰 중일 수 있죠. 이들을 구분 짓는 건 코드가 아니라 각자가 걸어온 로그입니다.

관점을 바꾸면 도구가 바뀐다

이 발상이 흥미로운 이유는 단순한 철학 놀이가 아니기 때문입니다. 관점이 바뀌면 만들어야 할 도구도 바뀝니다.

지금까지 에이전트 개발 도구는 대부분 ‘코드를 잘 짜게’ 돕는 데 초점이 있었습니다. 프레임워크, 프롬프트 관리, 오케스트레이션 라이브러리 같은 것들이요. 그런데 로그가 본체라면, 진짜 중요한 도구는 로그를 잘 보고 다루는 도구가 됩니다.

실행 과정을 실시간으로 들여다보고, 중간에 개입하고, 문제가 생긴 지점부터 다시 돌리는 기능 말입니다. 앞서 언급한 Omnara 같은 팀이 파고드는 지점도 바로 여기입니다. 에이전트가 사람 없이 오래 돌아가는 시대가 오면, “지금 얘가 뭘 하고 있지"를 아는 능력이 곧 통제력이 됩니다.

IBM Technology가 6월에 올린 ‘에이전트 시스템 확장의 도전 과제’ 영상이 5만 회 넘게 재생된 것도 같은 맥락입니다. 조회수 자체가 이 고민이 업계 공통 화두라는 신호인데요. 에이전트를 하나 만드는 건 쉬워졌지만, 여러 개를 동시에 돌리고 관리하는 순간 ‘무슨 일이 벌어지는지 보이지 않는’ 문제가 폭발합니다. 그 답의 상당 부분이 로그를 어떻게 설계하느냐에 달려 있습니다.

아직은 관점, 그러나 방향은 분명하다

정직하게 말하면, 아직 이 아이디어가 정설로 굳어진 건 아닙니다. 컨퍼런스 발표 하나와 소수의 실무자 논의 수준이고, 대규모 커뮤니티 검증은 지금부터입니다. 반론도 충분히 가능합니다. “그냥 옵저버빌리티(관측 가능성)를 멋지게 포장한 것 아니냐"는 시각도 있을 수 있죠.

그럼에도 이 관점이 매력적인 이유는, 에이전트를 다루는 사고의 무게중심을 옮겨주기 때문입니다. ‘어떤 코드를 짤까’에서 ‘무슨 일이 벌어졌는지 어떻게 볼까’로요.

여러분이 만약 에이전트를 운영 중이라면, 한번 자문해 보시죠. 지금 우리 에이전트가 어젯밤 세 시에 정확히 무엇을 했는지, 로그만 보고 완벽히 재구성할 수 있나요. 그 질문에 자신 있게 “네"라고 답하지 못한다면, 어쩌면 우리는 에이전트의 본체를 아직 붙잡지 못하고 있는 건지도 모릅니다.