프롬프트를 넘어 에이전트가 실제로 어떻게 작동하는지 이해하기

AI 에이전트(AI agents)에 대해 생각할 때 저지르기 쉬운 가장 흔한 실수 중 하나는 응답(response) 단계에서 흥미로운 작업이 일어난다고 가정하는 것입니다.

이는 이해할 수 있는 가정입니다. 응답은 우리가 실제로 볼 수 있는 유일한 부분이기 때문입니다. 에이전트가 코드를 생성하든, 문서를 요약하든, 운영 이슈를 조사하든, 혹은 질문에 답하든, 눈에 보이는 출력물(output)은 자연스럽게 우리의 주의를 집중시킵니다. 우리는 마치 웹사이트의 인터페이스를 보고 그 뒤에서 모든 요청을 조용히 지원하는 인프라를 판단하는 대신 웹사이트를 판단하는 것처럼, 화면에 나타나는 것을 보고 시스템을 판단합니다.

하지만 운영 환경(Production environments)은 다른 이야기를 들려줍니다.

숙련된 빌더(builders)들은 응답이 에이전트 작동에서 종종 가장 흥미롭지 않은 부분이라는 사실을 빠르게 깨닫습니다. 그 몇 줄의 텍스트가 나타날 때쯤이면, 시스템은 이미 대부분의 사용자가 알아차리지 못하는 여러 단계의 처리 과정을 거친 상태입니다. 컨텍스트(Context)가 수집되었고, 지시 사항(instructions)이 해석되었으며, 사용 가능한 도구(tools)들이 평가되었고, 메모리(memory)가 참조되었을 수도 있으며, 실행 제약 조건(execution constraints)이 적용되었고, 단 하나의 토큰(token)이 생성되기도 전에 이미 결정(decisions)이 형태를 갖추기 시작했습니다.

응답은 단순히 그러한 이전 결정들의 가시적인 결과일 뿐입니다.

이러한 구분은 중요한데, 에이전트에 대한 많은 논의가 여전히 추론 모델(reasoning model) 자체를 중심으로 돌아가고 있기 때문입니다. 빌더들은 모델을 비교하고, 추론 성능을 벤치마크(benchmark)하며, 프롬프팅 기술(prompting techniques)을 실험하고, 어떤 파운데이션 모델(foundation model)이 최상의 출력을 만들어내는지 토론합니다. 이는 가치 있는 논의들이지만, 종종 모델이 곧 에이전트라는 인상을 남기곤 합니다.

그러한 사고 모델(mental model)은 대개 첫 번째 실제 배포(deployment)가 이루어질 때까지 유지됩니다.

프로토타입은 통제된 시연(demonstration) 동안 놀라울 정도로 잘 작동할 수 있습니다. 저장소(repository)를 조사하거나, 생소한 코드를 설명하고, 배포 계획을 생성하거나, 여러 도구 호출(tool calls)을 순차적으로 조정할 수도 있습니다. 이러한 경험은 특히 전통적인 자동화(automation)와 비교했을 때 놀라울 정도로 유능하게 느껴집니다.

그러다 환경이 덜 예측 가능해지기 시작합니다.

저장소에는 수년간 쌓인 일관성 없는 아키텍처(architectural) 결정들이 존재합니다. 내부 문서(internal documentation)는 구현 내용과 모순됩니다. 모니터링 시스템은 불완전한 텔레메트리(telemetry)를 보고합니다. 외부 API는 일시적으로 사용할 수 없게 됩니다. 배포가 헬스 체크(health checks)에 실패하기 전까지 부분적으로만 성공하기도 합니다. 모델 자체는 계속해서 일관된 응답을 생성할 수 있지만, 환경이 시연 중에 보여준 깨끗한 시나리오와 더 이상 닮지 않았기 때문에 전체 시스템은 점진적으로 더 약한 결정을 내리기 시작합니다.

결국, 대부분의 빌더(builder)들은 동일한 깨달음에 직면합니다.

에이전트를 구축할 때 어려운 부분은 지능적인 응답을 생성하는 것이 아닙니다. 어려운 부분은 그러한 응답으로 이어지는 모든 결정이 에이전트가 작동하고 있는 환경에 대한 정확한 이해를 바탕으로 이루어지도록 보장하는 것입니다.

그 깨달음은 대화의 주제를 완전히 바꿔 놓습니다.

숙련된 팀들은 에이전트가 얼마나 지능적으로 보이는지를 묻는 대신, 다른 질문들을 던지기 시작합니다.

• 컨텍스트(context)는 어디에서 왔는가?
• 어떤 도구(tools)가 결정에 영향을 미쳤는가?
• 검색된(retrieved) 정보가 여전히 유효했는가?
• 시스템이 이전 실행으로부터 어떤 가정을 이어받았는가?
• 왜 다른 행동 대신 이 행동을 선택했는가?

이러한 질문들은 중요한 무언가를 드러냅니다.

에이전트는 단일한 사고 개체가 아닙니다.

에이전트는 추론 모델(reasoning model)이 답변을 생성하기 시작하기도 전에 정보를 지속적으로 교환하는 협력 시스템들의 집합체입니다.

이러한 내부적 협력을 이해하는 것이 인상적인 시연을 만드는 것과 신뢰할 수 있는 운영 시스템(operational systems)을 구축하는 것을 구분 짓는 핵심입니다.

에이전트가 가장 먼저 받는 것은 프롬프트가 아닙니다

사람들은 흔히 에이전트와 상호작용하는 것을 _프롬프트(prompt)를 주는 것_이라고 설명하지만, 에이전트가 대화형 인터페이스(conversational interfaces)를 넘어설수록 그러한 설명은 정확도가 떨어지게 됩니다.

프롬프트는 운영 에이전트(operational agent)가 받는 정보의 아주 작은 부분일 뿐입니다.

저장소 분석(repository analysis) 에이전트에게 풀 리퀘스트(pull request)가 머지(merge)되기 전에 검토해 달라고 요청하는 상황을 상상해 보십시오. 자연스러운 가정은 사용자의 요청이 주요 입력값이 된다는 것입니다. 하지만 실제로 요청은 이용 가능한 정보 중 가장 정보량이 적은 조각인 경우가 많습니다.

에이전트는 저장소 자체, 제안된 코드 변경 사항, 커밋 히스토리(commit history), 아키텍처 컨벤션(architectural conventions), 의존성 그래프(dependency graphs), 이슈 트래커(issue tracker) 참조, 코딩 표준(coding standards), 보안 정책(security policies), 이전 리뷰 코멘트, 지속적 통합(continuous integration) 결과, 그리고 아마도 다른 시스템에 의해 수행된 이전 분석의 출력값 등을 함께 받을 수 있습니다. 추론(reasoning)이 시작될 때쯤이면, 원래의 프롬프트는 수많은 신호 중 하나가 되어 있을 뿐입니다.

동일한 패턴이 다른 도메인에서도 나타납니다.

배포(deployment) 에이전트는 인프라 상태, 환경 설정(environment configuration), 릴리스 히스토리(release history), 상태 확인(health checks), 롤백 정책(rollback policies), 서비스 의존성(service dependencies), 그리고 모니터링 데이터의 영향을 받습니다. 연구(research) 에이전트는 사용자의 의도와 검색된 문서, 출처의 신뢰성(source credibility), 이전 연구 결과, 그리고 사용 가능한 검색 도구를 결합합니다. 고객 지원(customer support) 에이전트는 어떻게 응답할지 결정하기 전에 과거 대화 내역, 제품 문서, 계정 정보, 에스컬레이션 규칙(escalation rules), 그리고 조직 정책을 고려합니다.

각 사례에서 에이전트는 질문을 고립된 상태로 받는 것이 아닙니다.

에이전트는 상황(situation)을 받고 있는 것입니다.

이러한 차이는 개발자들이 입력값(inputs)에 대해 생각하는 방식을 변화시킵니다.

전통적인 소프트웨어는 보통 명확하게 정의된 파라미터(parameters)를 기대합니다. 엔드포인트(endpoint)는 요청을 받고, 데이터를 검증하며, 예측 가능한 작업을 수행하고, 결과를 반환합니다. 주변 환경도 중요하지만, 그것이 애플리케이션의 의사 결정 과정의 일부가 되는 경우는 드뭅니다.

에이전트 (Agents)는 환경 자체가 추론 (reasoning)에 영향을 미치기 때문에 다르게 작동합니다.

의사 결정의 품질은 사용자가 무엇을 요청했는지뿐만 아니라, 시스템이 세상의 현재 상태에 대해 무엇을 알고 있는지에 따라 달라집니다. 만약 그 이해가 불완전하거나, 시대에 뒤처져 있거나, 일관되지 않다면, 기반이 되는 모델 (model)이 아무리 유능하더라도 추론 과정은 결함이 있는 토대 위에서 시작됩니다.

이것이 프로덕션 에이전트 (production agents)가 실험실에서의 시연 (demonstration)과 다르게 행동하는 경우가 많은 이유 중 하나입니다.

시연 중에는 개발자들이 주변 환경을 통제하는 경우가 많습니다. 컨텍스트 (Context)는 의도적으로 선택되고, 도구 (tools)는 예측 가능하게 작동하며, 문서 (documentation)는 정확하고, 외부 시스템은 협조적입니다. 시스템에 입력되는 정보가 이미 깨끗하기 때문에 추론 모델 (reasoning model)은 높은 성능을 발휘합니다.

하지만 운영 환경 (Operational environments)에서 그런 사치를 누리는 경우는 드뭅니다.

정보는 모순과 함께 도착합니다. 일부 데이터 소스 (data sources)는 서로 일치하지 않습니다. 중요한 세부 사항이 누락되어 있습니다. 로그 (Logs)에는 노이즈 (noise)가 포함되어 있습니다. 문서 (Documentation)는 구현 (implementation) 속도를 따라가지 못합니다. API는 일관성 없게 응답합니다. 인간의 결정은 그 어떤 문서에도 담기지 않는 예외 사항을 만들어냅니다.

에이전트는 다음에 무엇을 할지 결정하기 전에, 이러한 불완전한 현실을 해석해야 합니다.

경험 많은 개발자들은 결국 프롬프트 (prompts)를 개선하는 데 쓰는 시간보다 에이전트에 도달하는 정보의 품질을 개선하는 데 더 많은 시간을 쓰고 있다는 사실을 깨닫게 됩니다. 더 나은 검색 전략 (retrieval strategies), 더 깨끗한 저장소 (repositories), 더 강력한 문서 (documentation), 더 신뢰할 수 있는 통합 (integrations), 그리고 잘 정의된 운영 경계 (operational boundaries)가 프롬프트 개선을 한 번 더 반복하는 것보다 결과물을 더 효과적으로 개선하는 경우가 많습니다.

따라서 에이전트의 해부학 (anatomy)을 이해하는 첫 번째 교훈은 놀라울 정도로 단순합니다.

에이전트는 생성되기를 기다리는 답변과 함께 시작되지 않습니다.

에이전트는 이해되기를 기다리는 환경과 함께 시작됩니다.

A central AI processing core receives multiple structured information streams simultaneously

지능보다 컨텍스트(Context)가 보통 더 중요합니다

만약 두 명의 빌더(builder)가 정확히 동일한 추론 모델(reasoning model)을 사용함에도 불구하고 완전히 다른 결과를 만들어낸다면, 즉각적으로 떠오르는 가정은 둘 중 한 명이 더 나은 프롬프트(prompt)를 작성했을 것이라는 점입니다.

때로는 그것이 사실일 수도 있습니다.

하지만 더 빈번하게는, 그 차이가 다른 곳에 존재합니다.

컨텍스트(Context)는 모델이 추론을 시작하기 전에 무엇을 알 수 있는지를 결정하며, 이는 컨텍스트를 모든 에이전트 아키텍처(agent architecture) 내에서 가장 영향력 있는 구성 요소 중 하나로 만듭니다. 지능은 오직 자신이 받는 정보 위에서만 작동할 수 있습니다. 주변 컨텍스트가 변하면, 기반이 되는 모델이 동일하더라도 추론의 품질은 그에 따라 변합니다.

동일한 기능 요청(feature request)을 검토하는 두 개의 코딩 에이전트(coding agent)를 가정해 봅시다. 두 에이전트 모두 동일한 모델로 구동되며 동일한 사용자 지침을 받습니다. 첫 번째 에이전트는 저장소 구조(repository structure), 아키텍처 가이드라인(architectural guidelines), 의존성 관계(dependency relationships), 최근 풀 리퀘스트(pull requests), 코딩 컨벤션(coding conventions), 그리고 이슈 이력(issue history)에 접근할 수 있습니다. 반면 두 번째 에이전트는 기능 요청과 몇 개의 고립된 파일만을 전달받습니다.

출력 결과의 차이가 지능만으로 발생할 가능성은 낮습니다.

한 에이전트는 자신이 작동하고 있는 환경을 이해합니다. 다른 에이전트는 예측을 통해 누락된 간극을 강제로 채워야만 합니다.

이것이 숙련된 빌더들이 점차 컨텍스트를 보조 정보로 취급하는 것을 멈추고, 운영 인프라(operational infrastructure)로 취급하기 시작하는 이유입니다. 좋은 컨텍스트는 불필요한 예측을 줄여줍니다. 나쁜 컨텍스트는 모델로 하여금 존재하지 않는 연속성을 억지로 만들어내도록 강요합니다.

많은 프로덕션 실패 사례에서, 모델은 설계된 대로 정확히 동작했습니다. 모델은 자신에게 가용 가능한 정보를 바탕으로 추론했습니다. 문제는 가용 가능한 정보가 더 이상 현실을 반영하지 못하고 있었다는 점입니다.

그러한 관찰은 왜 컨텍스트 엔지니어링 (context engineering)이 현대 에이전트 개발에서 가장 중요한 분야 중 하나가 되고 있는지를 설명해 줍니다. 시스템이 커질수록 과제는 더 많은 정보를 제공하는 것이 아닙니다. 과제는 이해도를 높이지 못하면서 노이즈 (noise)만 증가시키는 모든 것을 걸러내면서, 적절한 시점에 적절한 정보를 제공하는 것입니다.

사용 가능한 모든 문서를 받는 에이전트가 신중하게 선택된 하위 집합을 받는 에이전트보다 반드시 더 많은 정보를 알고 있는 것은 아닙니다. 사실, 과도한 컨텍스트 (context)는 종종 그 자체로 문제를 일으킵니다. 무관한 정보가 주의 (attention)를 끌기 위해 관련 정보와 경쟁하고, 오래된 가정이 새로운 가정을 가리며, 검색 시스템 (retrieval systems)은 중요도 대신 익숙함을 드러내기 시작합니다.

이러한 트레이드오프 (trade-off)를 이해하면 빌더들이 에이전트 시스템을 설계하는 방식이 바뀝니다. 모델의 컨텍스트 윈도우 (context window) 안에 얼마나 많은 컨텍스트를 넣을 수 있는지를 묻는 대신, 실행 과정 전반에 걸쳐 컨텍스트를 어떻게 수집하고, 순위를 매기고, 검증하고, 갱신해야 하는지를 묻기 시작합니다.

그제서야 에이전트가 실제로 그 이해를 어떻게 의사결정으로 전환하는지 살펴보는 것이 의미가 있습니다. 왜냐하면 추론 (reasoning)은 결코 고립되어 수행되지 않기 때문입니다. 추론은 이를 둘러싼 제약 조건 (constraints), 우선순위 (priorities), 그리고 운영상의 현실에 의해 지속적으로 형성됩니다. 바로 그 지점에서 에이전트 해부학의 다음 계층이 시작됩니다.

Show two identical AI reasoning cores.

의사결정은 대부분 제약 조건 관리이다

빌더들이 프롬프트 (prompts)와 응답 (responses) 너머를 바라보기 시작하면, 또 다른 가정이 사라지기 시작합니다.

에이전트가 사람과 거의 동일한 방식으로 _생각한다_고 상상하기 쉽습니다. 우리는 에이전트가 대안을 저울질하고, 가능성을 고려하며, 결국 최선의 경로를 선택하는 모습을 그립니다. 현대의 추론 모델 (reasoning models)이 확실히 인상적인 형태의 분석을 수행할 수 있는 것은 사실이지만, 에이전트가 실제 운영 환경 (production environment) 내에서 작동하기 시작하면 그러한 정신적 모델 (mental model)은 유용성이 떨어지게 됩니다.

대부분의 결정은 완전한 자유 상태에서 내려지지 않습니다.

결정은 경계 (boundaries) 안에서 내려집니다.

새로운 서비스를 배포하는 책임을 맡은 인프라 에이전트 (infrastructure agent)를 생각해 보십시오. 목표는 매우 간단해 보입니다: 최신 버전을 성공적으로 배포하는 것. 하지만 어떤 조치를 취하기 전에, 시스템은 놀라울 정도로 많은 제약 조건 (constraints)을 조율해야 합니다.