Field note · 2026-04

AI-Native를 위한 Agent 만들기: 무엇을 위한 에이전트인가

Upstream과 Downstream 관점에서 바라본 Agentic Workflow 설계 AI로 일하다 보면 이상한 경험을 하게 된다. 처음에는 질문을 잘 하는 사람이 되려고 한다. 프롬프트를 다듬고, 맥락을 잘 전달하고, 더 좋은 답을 끌어내는 방법을 익힌다. 그런데 어느 시점부터 일의 성격이 바뀐다. 반복적인 작업을

AI-Native를 위한 Agent 만들기: 무엇을 위한 에이전트인가

Upstream과 Downstream 관점에서 바라본 Agentic Workflow 설계

0. 어느 순간 나는 "만드는" 사람이 되어 있었다

AI로 일하다 보면 이상한 경험을 하게 된다.

처음에는 질문을 잘 하는 사람이 되려고 한다. 프롬프트를 다듬고, 맥락을 잘 전달하고, 더 좋은 답을 끌어내는 방법을 익힌다. 그런데 어느 시점부터 일의 성격이 바뀐다. 반복적인 작업을 자동화하고, 특정 목적에 맞는 스킬을 만들고, 여러 에이전트가 협력해서 결과물을 내는 구조를 짜게 된다.

개발자가 아닌데도 개발과 닮은 일을 하게 된다.

그리고 여기서 많은 사람이 비슷한 방향으로 빠진다. "에이전트를 만드는 것" 자체에 몰입하게 되는 것. 어떤 도구를 쓸지, 어떻게 연결할지, 얼마나 자동화할지를 고민한다. 잘 작동하는 에이전트에 만족감을 느낀다.

하지만 진짜 병목은 거기에 있지 않다.

에이전트를 만드는 것보다 어려운 것은, 무엇을 위한 에이전트인지를 먼저 아는 것이다.

이것이 AI Native 조직 설계의 출발점이다.

1. AI Native는 에이전트를 잘 만드는 것이 아니다

AI Native를 "에이전트를 잘 만드는 것"으로 이해하면 반쪽짜리가 된다.

기존의 직무 설계가 사람과 직무 사이의 역할을 정의하는 것이라면, 에이전트 시스템 설계는 에이전트가 작동하는 생태계 전체를 구축하는 일이다. 에이전트를 제작하기 전의 '목적 정의'부터, 제작 후 그 결과물이 '조직의 자산'으로 연결되기까지의 전 과정을 동기화하는 것이 핵심이다.

만들기 전에는 이런 질문이 있다. 이 에이전트는 왜 필요한가? 어떤 맥락에서 작동하는가? 무엇을 산출해야 하는가? 만든 후에는 이런 질문이 남는다. 에이전트가 만든 결과물은 어디로 가는가? 쌓이는가, 버려지는가?

이 두 가지를 묶어서 생각하는 관점이 Upstream과 Downstream이다.

2. Upstream: 에이전트가 작동하기 전의 설계

Upstream은 에이전트에게 무엇을 어떻게 주는가의 문제다.

가장 흔한 실수는 에이전트를 먼저 만들고 목적을 나중에 생각하는 것이다. "회의록 정리 에이전트"를 만들었다고 하자. 잘 작동한다. 회의록을 넣으면 깔끔하게 요약해준다. 그런데 한 달 뒤, 누군가 묻는다. "저번 달에 논의된 리스크 항목들이 뭐였지?" 에이전트의 출력에서는 답을 찾을 수 없다. 요약은 있지만, "리스크"라는 분류 자체가 처음부터 없었기 때문이다.

이 에이전트는 잘 만들어진 에이전트다. 하지만 무엇을 위한 에이전트인지가 설계되지 않았다.

Upstream에서 실질적으로 중요한 것은 세 가지다.

목적의 명확성: 이 에이전트가 만드는 결과물을 누가, 언제, 어떤 상황에서 사용하는가. 이것이 불분명하면 에이전트는 "일반적으로 그럴듯한 것"을 만드는 데 그친다.

맥락의 일관성: 에이전트가 작동하는 배경 지식, 조직의 언어, 이전에 결정된 사항들이 일관되게 전달되고 있는가. 매번 새로운 맥락에서 시작하는 에이전트는 매번 처음부터 다시 시작하는 것과 같다.

출력 형식의 명시성: "잘 정리된 문서"와 "의사결정 항목, 미결 사항, 다음 액션이 구분된 문서"는 완전히 다른 결과물이다. 형식이 명시되어 있을 때만 출력은 나중에 쓸 수 있는 형태가 된다.

Upstream이 잘 설계되지 않으면, 에이전트가 아무리 잘 작동해도 그 결과물은 처음부터 자산화 불가능한 형태로 생성된다.

3. Downstream: 에이전트 결과물의 행방

Downstream은 에이전트가 만든 것이 어디로 가는가의 문제다.

지금 대부분의 Agentic Workflow에서 에이전트 출력은 채팅창에 뜨고, 복사되어 어딘가에 붙여넣어지거나 파일로 저장된다.

그리고 대체로 거기서 끝이다.

이렇게 되면 아무리 정교한 에이전트를 만들어도 조직 입장에서는 매번 비슷한 작업을 처음부터 반복하게 된다. 에이전트가 만든 결과물이 쌓이지 않기 때문이다.

반면 결과물이 자산(Asset)이 된다는 것은 구체적으로 다음을 의미한다.

나중에 찾을 수 있다: 지난달 에이전트가 분석한 결과를 지금 다시 참조할 수 있다. 단순히 파일이 존재하는 게 아니라, 검색하고 연결할 수 있는 형태로 남아있다.

다른 결과물과 연결된다: 이번 분석이 지난 분석과 비교되고, 에이전트 A의 출력이 에이전트 B의 입력이 된다. 결과물이 고립된 단편이 아니라 더 큰 지식 구조의 일부가 된다.

시간이 지나도 살아있다: 새로운 정보가 들어오면 업데이트되고, 낡은 판단은 갱신된다. 한 번 만들어진 뒤 묵혀지는 것이 아니다.

어떻게 만들어졌는지 추적할 수 있다: 이 결과물이 어떤 정보를 바탕으로, 어떤 과정을 거쳐 나왔는지 되짚을 수 있다. 출처를 모르는 결과물은 중요한 판단에 쓰기 어렵다.

이 네 가지 조건이 갖춰질 때, 에이전트 Output은 비로소 Asset이 된다.

4. Upstream과 Downstream은 하나의 질문으로 연결된다

Upstream과 Downstream을 따로 보면 입력 품질과 출력 활용의 문제처럼 보인다. 하지만 실제로는 하나의 질문으로 이어진다.

이 에이전트는 무엇을 위해 만들어졌고, 그 결과물은 어디로 가는가?

이 질문에 명확한 답이 없는 에이전트는 일회성 도구에 그친다. 반면 이 질문에 답이 있는 에이전트는 처음부터 자산화 가능한 구조 위에서 작동한다.

결국 자산화는 Downstream 처리 단계에서 사후적으로 결정되는 것이 아니다. Upstream 설계 단계에서 이미 의도되어 있어야 하고, Downstream에서 비로소 실현된다. 의도 없이 만들어진 에이전트는 Downstream에서 아무리 잘 처리해도 쌓이는 데 한계가 있다.

5. 결론

AI-Native 환경에서 우리는 점점 "만드는" 사람이 된다. 스킬을 만들고, 에이전트를 만들고, 워크플로우를 만든다. 이 경험은 개발과 닮아있지만, 기술 역량이 핵심은 아니다.

핵심은 설계 판단이다.

에이전트가 작동하기 전에 무엇을 위해 만드는지 명확히 하는 것(Upstream), 그리고 에이전트가 만든 결과물이 자산으로 쌓이는 구조를 갖추는 것(Downstream). 이 두 가지를 의도적으로 설계할 때, 에이전트는 일회성 도구를 넘어 조직의 지식 인프라가 된다.

에이전트를 잘 만드는 조직과, 에이전트 Output이 복리로 쌓이는 조직의 차이는 기술력이 아니라 "무엇을 위한 에이전트인가"를 먼저 묻는 습관에서 만들어진다.

참고문헌

Agentic Workflow & Memory Architecture

Agent Design & Purpose Specification

Industry Reports