Agent 개념의 등장과 Agent의 중요성

Agent가 왜 튀어나왔나

LLM이 처음 대중적으로 쓰였을 때는 대답 자체가 신기했습니다. 그런데 실제 업무에 붙이면 금방 벽이 보입니다. 모델은 문장을 잘 만들지만 최신 파일 상태를 모르고, 사내 정책을 모르고, 지금 서버가 어떤 응답을 내는지도 모릅니다. 그래서 질문에 답하는 모델만으로는 부족하고, 관찰하고 도구를 쓰고 결과를 확인하는 agent 개념이 필요해졌습니다.

Agent는 LLM 위에 실행 루프를 얹은 구조라고 볼 수 있습니다. 입력을 보고, 필요한 정보를 찾고, action 후보를 만들고, 정책과 권한을 확인하고, 실제 도구를 호출한 뒤 결과를 다시 읽습니다. 여기서 핵심은 모델이 똑똑하다는 사실이 아니라, 똑똑한 후보를 현실 상태와 연결하는 구조입니다.

모든 지식을 내재화할 수는 없다

LLM은 많은 지식을 내부에 품고 있지만, 모든 것을 가중치 안에 넣을 수는 없습니다. 가격, 법령, 광고 정책, API 스펙, 배포 상태, 개인 프로젝트의 파일 구조는 계속 바뀝니다. 이런 정보를 모델이 이미 알고 있다고 믿고 실행하면, 그럴듯한 낡은 지식으로 실제 시스템을 망칠 수 있습니다.

그래서 agent 설계에서는 내재화할 것과 외부에서 확인할 것을 나눕니다. 언어 습관, 일반적 추론 패턴, 위험 감각은 내재화되어도 좋습니다. 반면 최신 정책, 사용자의 현재 파일, 외부 서비스 응답은 실행 시점에 확인해야 합니다. 좋은 agent는 많이 아는 모델이 아니라, 무엇을 모르는지 알고 확인하는 시스템입니다.

중요성은 실행에서 생긴다

LLM의 답변을 꼭 복잡한 확률 관리나 체계적인 점수표로만 분류해야 하느냐고 묻는다면, 내 대답은 아닙니다. Agent의 행동은 아무리 점수화해도 한계가 있습니다. 그래서 입력의 어조에 점수를 붙이는 것보다 먼저 분류해야 합니다. 최신 정보에 가산점을 주는 것보다, 그 정보가 어느 시점의 정보인지 기억해야 합니다.

concept와 relation을 세세하게 정리하고, 주장마다 출처와 주장의 개수를 남겨야 피드백이 가능합니다. 어떤 주장이 하나의 블로그에서 나왔는지, 세 개의 공식 문서와 실행 로그가 같이 지지하는지에 따라 agent의 행동은 달라져야 합니다. Taxonomy는 모델을 복잡하게 보이게 만드는 장식이 아니라, 나중에 왜 그런 행동을 했는지 되짚는 장부입니다.

하드웨어 열풍 뒤의 소프트웨어 문제

한국에서는 Agent 유행이 주식시장의 삼성전자나 하이닉스 호재 정도로 소비되곤 합니다. 하지만 세계적으로 보면 agent 전후로 하드웨어 수요가 폭증한 것은 사회적 문제에 가까운 규모입니다. 누군가는 이렇게 말할 수 있습니다. 그동안 놀고 있던 하드웨어와 마이크로소프트, 애플, 리눅스 생태계의 직무유기가 사회적 비용을 만든 것 아니냐고요.

사람도 기억을 세분화합니다. 지금 본 것, 오래전 겪은 것, 법적으로 하면 안 되는 것, 습관처럼 할 수 있는 것을 다르게 다룹니다. 그런데 소프트웨어는 왜 그 세분화를 충분히 하지 않았을까요. Agent 코딩은 이 지점에서 기존 전략을 바꿔야 합니다. 큰 모델 하나가 모든 것을 품는 방식이 아니라, 기억과 판단과 실행을 나누는 방식으로 가야 합니다.

결국 agent의 중요성은 말솜씨에서 나오지 않습니다. 실행하기 전에 무엇을 알아야 하는지, 무엇은 모른다고 말해야 하는지, 어디서 멈춰야 하는지 정리하는 능력에서 나옵니다. 이 능력은 거대한 모델 하나보다 지저분한 운영 기록과 taxonomy와 postcondition 확인에서 더 자주 자랍니다. 그래서 agent 설계자는 모델 성능표만 보는 사람이 아니라, 실패가 남는 길을 설계하는 사람에 가깝습니다.